marcan changed the topic of #asahi to: Asahi Linux: porting Linux to Apple Silicon macs | "Does XXX work yet?": https://alx.sh/fs | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Topics: #asahi-dev #asahi-re #asahi-gpu #asahi-alt #asahi-stream #asahi-offtopic | Keep things on topic | Logs: https://alx.sh/l/asahi
fortich has quit [Quit: Leaving]
turo has joined #asahi
turo has quit []
Hibyehello has quit [Ping timeout: 480 seconds]
Hibyehello has joined #asahi
derzahl has joined #asahi
Urriellu has joined #asahi
Urriellu has quit []
julio7359 has joined #asahi
Urriellu has joined #asahi
Urriellu has quit []
Urriellu has joined #asahi
brad_ has quit [Ping timeout: 480 seconds]
dorkbutt has joined #asahi
dorkbutt has quit [Max SendQ exceeded]
derzahl has quit [Remote host closed the connection]
MichaelLong has quit [Remote host closed the connection]
MichaelLong has joined #asahi
ptudor has joined #asahi
chip_x has joined #asahi
chip_x has quit [Max SendQ exceeded]
chip_x has joined #asahi
chipxxx has quit [Ping timeout: 480 seconds]
pg12 has quit [Quit: pg12]
ptudor has quit [Ping timeout: 480 seconds]
ptudor has joined #asahi
axt has joined #asahi
giskard has joined #asahi
Zopolis4 has quit []
<mkurz>
I think I found another bug (?): I had A LOT of chrome windows and tabs open and also three IntelliJ instances. Suddenly I was not able anymore to open more browser windows or activate any other application windows (like HexChat which had it's windows hidden). In the logs I got "RM_IOCTL_MODE_CREATE_DUMB failed: Cannot allocate memory"
jelly has quit []
<mkurz>
The strange thing is I cold open more chromium tabs of existing windows but couldn't create new windows. I mean I could see the window in the kde task bar but I couldn't "activate" it, I could see the window border but could not interact with it.
<mkurz>
Now I closed chrome completly and now I can open other applications again
<mkurz>
Is it possible I ran out of (GPU) memory or something?
<mkurz>
OK I can still not open IntelliJ, still same error
<mkurz>
and I have 14Gi memory available according to free -mh
<mkurz>
I will open an issue after restart
jelly has joined #asahi
<mkurz>
Oh and it's just the above error but also each time "Failed to create scanout resource"
mkurz has quit [Quit: Leaving]
pg12 has joined #asahi
mkurz has joined #asahi
mkurz has quit [Quit: Leaving]
mkurz has joined #asahi
mkurz has quit []
mkurz has joined #asahi
c10l has quit [Ping timeout: 480 seconds]
nsklaus has joined #asahi
mkurz has quit []
<nsklaus>
if i remember correctly, recently marcan talked about a base distro change for asahi, replacing arch for something else. was there any news about that ?
<j`ey_>
no news in terms of when it will happen
<nsklaus>
j`ey_ thanks for telling
<nsklaus>
i had a 2 or 3 more general questions, one about speaker support, i saw a livestream about marcan trying to tackle it, but i was wondering if that was made available for the general public yet or is it still living only on marcan's personal tree ?
<marcan>
it's not ready yet
<nsklaus>
another question about the shortcomings of metal and moltenvk compared to vulkan, there's missing functions, like geometry shaders, transform_feedback and little things like that. i was wondering if we were at the point of having asahi trying to fill those gaps yet ?
<marcan>
the speaker stuff will not be made available to anyone who isn't building their own kernels until it is fully tested and validated on all platforms we intend to enable it on. this is a safety thing and I will *not* be blowing up anyone's speakers.
<marcan>
(other than my own)
<nsklaus>
marcan : safety first, that is all good stance
<marcan>
transform feedback is already implemented in dev trees, other stuff will come in due time
<nsklaus>
ah wow, that is very nice to hear :)
<marcan>
(thank alyssa for that :p)
<nsklaus>
so there's hope for a full vulkan implementation on asahi, i take it ? if yes then awesome
<marcan>
that was always the plan, yes
<nsklaus>
i feared asahi would inherit the same limitations than moltenvk. good to hear
<nsklaus>
i see alyssa made quite good progress lately, experimenting with fex and all
<nsklaus>
marcan: yes, sorry for the confusion, i meant lina. but both are doing good job on the gpu front
<dottedmag>
nsklaus: that's one of many advantages of talking to hardware instead of talking to metal driver talking to hardware
<nsklaus>
dottedmag : i see. makes sense. i hadn't thought of it but now that you mention it, of course linux do not use apple gfx stack.
<marcan>
there's this pervasive myth that Apple GPUs are "Metal GPUs" or something, which is completely wrong
<j`ey_>
well it talks to firmware, not hardware, but still!
<marcan>
j`ey_: it definitely talks to hardware, all the command streams are processed by hardware
<j`ey_>
oh
<ChaosPrincess>
isn the 'metal gpu' meme mostly because they are 1. tilers, 2. lack hardware support to do geometry shaders and need it emulated in sw?
<marcan>
if it were a "metal gpu" it would have mesh shaders, which it doesn't
<marcan>
the meme is just because people make stuff up about apple stuff, along the same lines as "m1s are amazingly only because macos is so optimized for them"
<marcan>
-y
<nsklaus>
for what it's worth, i'm not sure if you followed the nintendo switch emulator ryujinx, they made a release implementing all the missing stuff from moltenvk and it works fast.
<marcan>
yes, I saw that
<marcan>
evidently you *can* emulate geometry shaders and TF, there's just many ways of doing it and your options are better when you're talking directly to hardware
<marcan>
(apple didn't even try though, their GL runs geometry shaders on the CPU as far as I know)
<marcan>
j`ey_: actually come to think of it, there is *less* firmware on apple than on AMD, as far as what the firmware actually does
<marcan>
AMD has a pile of little blobs running the actual 3D command pipeline on their custom F32 cores, on Apple that's all hardware.
<marcan>
(I know because I reverse engineered F32 way back :p)
<j`ey_>
:D
<marcan>
the firmware on apple GPUs just handles scheduling and submission and preemption etc, not the actual rendering
<marcan>
(and power management, but everyone does that in firmware)
nyilas has joined #asahi
<nsklaus>
i was also wondering about the recent change marcan did about removing mailbox system for underlying infrastructure inter processes communication (if i understand correctly) i was wondering if there was some feedback about it yet ? (if it's available for everyone to try it out ? )
<j`ey_>
that one isnt as exciting, hopefully you wont notice a difference :P
mkurz has joined #asahi
<j`ey_>
but the latest release has the new mailbox
<nsklaus>
j`ey_ yes, except for general stability, in relation to race conditions, and missing timeframes things like that, if i understand it correctly
<nsklaus>
ok, good to know it's already available to all
mkurz has quit [Remote host closed the connection]
<nsklaus>
if there were problem folks would be discussing it, i take that change went well. seemed pretty deep
<nsklaus>
*i take it that ..
<nsklaus>
last time i tried asahi there was no real possibility to change display resolution
<nsklaus>
even using the dev tree for gfx stack
<Retr0id>
is it just me or does firefox have some really janky text input behaviour sometimes? I've just tried to send a tweet and a) the cursor keeps disappearing b) the contents of the tweet as-sent were different to the content I saw when I was editing! (it sent a prior version) I still haven't figured out what's triggering it but it seems to be related
<Retr0id>
to clipboard actions
<nsklaus>
it may have been how things are done on wayland though ? i'm not yet used to wayland.
chip_x has quit [Ping timeout: 480 seconds]
<nsklaus>
but i remember wondering why i could not really change resolutions, there was just an option on zoom or dpi something something.. not real resolution change. was it just me or there still a limitation on that front ?
<chadmed>
it was because we were using the firmware framebuffer
<nsklaus>
chadmed: you used past tense, is it different now ?
<chadmed>
yes, the display controller driver has been enabled for quite a while now
mkurz has joined #asahi
<nsklaus>
but, when i tried asahi last time it was maybe two months ago, maybe 3.. and i tested the dev tree for accelerated gfx stack (which was working well)
<nsklaus>
i was under the assumption that this dev tree gfx stack was not using the framebuffer either, was i wrong about it ?
<nsklaus>
maybe it's time i try a more up to date asahi
<nsklaus>
about the speakers, if i build kernel with speaker support, and i generaly keep volume to a low to mid level at all time (i mean never max up the levels) would that still be considered hazardous ?
<ah->
zoom around a little and you'll get "FWLog: ERROR: PIO poll from agfPollFenderReg timeout after 250us [type:0 reg:0x10080 expected:0x0 got:0x3 max:250us], continue wait"
<nsklaus>
marcan : ok i will not try that then. i don't have enough money to buy a new laptop or pay for expensive repairs
<ah->
not sure if you're looking for bug reports like this yet, probably it's too early and there's too much known issues too fix
<marcan>
ah-: that's not a GPU crash, that's a GPU fault. mesa bug or firefox bug.
<marcan>
I think that one is already reported on the github issue
<nsklaus>
marcan: thank you for telling .. i would have tried it if you hadn't warned against.
<marcan>
changing the resolution is supported on desktops/external monitors. changing the resolution of the internal panel is not supported nor does it make any sense.
<marcan>
if you want to make things larger/smaller, change the display scale
<nsklaus>
marcan : ah so i remembered right. so things and behavior changed ? we don't change resolution anymore ?
<marcan>
changing the resolution on LCD panels hasn't made sense since LCD panels were invented
<marcan>
that's a legacy concept inherited from CRTs
<marcan>
the only reason we had it is OSes not supporting UI scaling properly
<marcan>
they do now, so that's obsolete
<nsklaus>
but, in terms of bandwidth, usualy, when we use high (fixed) resolution, things are less fast than when we use a lower resolution, is it not ?
<marcan>
yes, which is why games *do* usually let you render at a lower resolution than the display, and that all works perfectly fine on wayland
yuka_ has quit [Remote host closed the connection]
<marcan>
but it makes no sense for UIs
yuka has joined #asahi
<nsklaus>
marcan : ok, i take note: we don't change resolution anymore, and games will be able to make necessary resolution changes to work as they should
<nsklaus>
that's new to me (not changing resolution anymore), but ok
<marcan>
approximately zero laptop panels support changing the resolution, intel/AMD/nvidia drivers just emulate it with internal scaling. there's no reason to emulate that in the driver any more since compositors can configure scaling like that themselves if they really want to.
<marcan>
so if you really want to render your UI at a lower resolution and scale it, in principle nothing stops wayland compositors from offering that option
<marcan>
but it no longer is the driver's job to pretend a screen that only has one mode can do more modes like other laptops do
<marcan>
remember x86 is a pile of legacy upon legacy upon legacy in all dimensions, and our job here is to not be burdened by that kind of stuff and do things right
<nsklaus>
i understand, i'm not fighting it, it's just i didn't know those details. you give proper reasoning on how things actualy work. i was still stuck on these old concept and took them for some sort of general rule that would not change. and it seems i was wrong. thank you for giving the details.
<marcan>
like literally on Intel you can xrandr switch to an 800x600 mode on a 1080p laptop screen, or xrandr create a virtual 800x600 screen and scale it to 1080p with a 1080p mode selected, and they are the *same thing* as far as I know, at the hardware.
<marcan>
it's just two ways of doing the same thing, one legacy. we're not doing legacy.
<jannau>
scaling in the display processor might save memory and memory bandwidth
<marcan>
yes, and that is supported in the dcp driver, isn't it?
<nsklaus>
marcan : fine by me. your approach and stance seems all good to me
<nsklaus>
(about leaving some unecessary legacy stuff behind)
chipxxx has joined #asahi
<marcan>
I think in principle if say $game sets up a 1024x768 framebuffer and wants to present via DCP on Wayland it should be possible for the compositor to configure that surface as the primary plane if all the moving parts work right (not sure if they do)
<jannau>
not right now, the frembuffers dcp sees are always panel resolution so the scaling has to happen in the gpu
<marcan>
oh, I thought we had scaling hooked up
<marcan>
then we should do that at some point, yeah
<nsklaus>
good thing i mentioned the topic it seems :)
<marcan>
eh, framebuffer compression is more important than scaling for performance anyway :p
<marcan>
should probably throw that one at lina
<nsklaus>
even though i had some old misconception that needed a refresh
<chadmed>
is she going to rewrite dcp in rust? :p
<marcan>
I think she keeps taunting jannau with it :p
<marcan>
but I meant that one specifically because DCP and AGX need to agree on the compression format
<jannau>
I think scaling should work if kms use source and destination rectangle to set it up
<marcan>
yeah, it's in there isn't it? I thought it was
<marcan>
so it *should* work though I'm not sure if it's been tested
<jannau>
it's not tested in the sense that I haven't seen an application using differently sized src/dest rects
<marcan>
that reminds me we need to do something about kwin showing fake modes for the screen
<marcan>
(that don't work)
<nsklaus>
so, considering i need to refresh my outdated concept on that subject, how would you name that issue you're talking about right now ? if i cannot call it "resolution change" ?
<nsklaus>
"resolution scaling" maybe ?
<nsklaus>
in case i want to check what's happening on that front later on, how do i even name it ?
<jannau>
marcan: is it just kwin/kscreen under x11? under wayland it shows jsut the native panel resolution
<marcan>
not for me, I see a pile of dummy resolutions on wayland
<marcan>
I remember finding the code that did that
<marcan>
might depend on the device? j314 here
<jannau>
setting a fake mode should just fail
<marcan>
it does
<marcan>
but KDE still shows it in the list
<marcan>
it just doesn't do anything when you try
<nsklaus>
jannau : for what it's worth, when i last tested asahi, i tested both x11 and wayland, and had the same issue which i erroneously called "inability to change resolution"
<jannau>
I'm on j314 as well, kwin 5.26.5 just lets me change the refresh rate
<nsklaus>
i see .. i have now a 14" macbookpro m2 pro (had an original 13" macbookpro M1 base model before, but i could not stand the touchbar, i had to get rid of the darn thing)
<jannau>
it has an info text next to resolution saying 3024x1890 is the only supported resolution and that changing to an unsupported resolution was possible in the plasmay x11 session
<nsklaus>
i have a french azerty keyboard by the way if that's of any interest for testing keymapping issues.. i think i saw a request for feedback on that front recently
<marcan>
the drm backend pretends those are supported resolutions
<marcan>
jannau: 5.27.3 here
<jannau>
apparently it was "fixed" in kwin 5.27, seeing that as well on j493 with kwin 5.27.3
<nsklaus>
where can i get a list of the different models in the same wording as jannau is using ? (was about to ask which model is j493 ;)
<chadmed>
j314 shows all those bogus resolutions here too on 5.27.3
<marcan>
9130b947e02bd9f4313e6cdb15d692c4ea7953b9 is the problem
<marcan>
I'll just file a bug, that whole idea is ridiculous
<j`ey_>
chadmed: my bad, I searched, but that page didnt show up, or i missed it
<marcan>
jannau: that's their problem then
<chadmed>
it's in the sidebar :P
<nsklaus>
is asahi support for 14" macbookpro "M2 pro" on par with what it was for original 13" macbookpro M1 base models by the way ? can i just proceed with install like i did before with the m1 and all will be working ?
<nsklaus>
(minus speakers)
<jannau>
m2 pro/max are not supported at all atm
<nsklaus>
last time i tried asahi, on that M1 everything did work quite well
<nsklaus>
jannau : ah.. i'll have to wait a bit then.. ok
<chadmed>
i managed to get the m2 pro mini to boot headless and tethered but getting pcie and dcp to work is beyond my pay grade so we just sit and wait patiently
<j`ey_>
chadmed: sidebar shmidebar
<nsklaus>
chadmed : understood
<jannau>
looks like even before 9130b947e02bd9f only the refresh rates saved us from the fake modes on j314/j316. 13" mbp and air would have the fake modes since thay report only a single mode
<marcan>
jannau: yeah, I saw it before that on the non-promotion systems already
<marcan>
jannau: AMD also supports scaling (I know because I use it on amdgpu on xorg) so this fake mode business still makes no sense
mohit8 has quit []
mohit8 has joined #asahi
<jannau>
I suppose behavior like kwin might be blamed for that. I just spotted it while looking at the AMD driver and remembered it due to its weirdness
<nsklaus>
anyone knows if multitouch support for the trackpad allows replicating macos 3fingers drag behavior ? anyone tested that ? that's one of the thing i grew quite fond of, alongside using cmd+c and cmd+v instead of ctrl+c and ctrl+v, that 3fingers drag feature is neat.. for moving windows around, using 3finger drag on windows border, or for selecting text too, those kind of things
<chadmed>
you can swap ctrl and cmd in the plasma system settings
<chadmed>
as for multitouch gestures thats all dependent on software
<chadmed>
eg three finger click is mapped to mouse wheel click (button 3) by default in plasma
<nsklaus>
i was able to make it long time ago using modified libinput, iirc but that was a bit hacky
<nsklaus>
not sure if recent linux desktop, with wayland and all still use libinput
<nsklaus>
ah- thanks for the link, i'll look for it all and tinker with that idea of having 3fingers drag on linux when i'll be able to install asahi again on that laptop. that's a side thing. i just wondered about it. but there's more pressing issues first i guess. priorities makes the order.
<nsklaus>
i bet the new distro base will be fedora :)
<nsklaus>
i'll see how that bet goes later on i guess
<nsklaus>
if i'm right that quite a change away from the arch aproach
<nsklaus>
not sure if i'm a fan of their package manager either, compared to pacman
<chadmed>
yeah neither, but at least things will bloody work...
<chadmed>
and theyre more than willing to actively work *with* us constructively
<chadmed>
those are more important than package manager ergonomics tbh
<nsklaus>
yes
<chadmed>
but hey either way i use gentoo :p
axt has quit [Quit: Leaving.]
<nsklaus>
i have kept having to try an up to date gentoo desktop experience in the todo list for some time
<nsklaus>
distro hoping, being part of what linux users like to do
<nsklaus>
i said it before but, last time i tried gentoo, was just before they introduced use flags
<nsklaus>
that was a while ago ;)
<nsklaus>
another source distro i tried and liked was gobo linux
<nsklaus>
they did some heretic things with it, but the result was interesting
Moprius has joined #asahi
<nsklaus>
but yes, using fedora as new base would provide substantial improvements in terms of infrastructure, and people, some big names too, behind the distro releases, in support and all
amarioguy has joined #asahi
Brainium has joined #asahi
<MichaelLong>
chadmed, oh another gentoo user, still some left I see :)
<chadmed>
MichaelLong: i'm maintaining the gentoo overlay for asahi too
<MichaelLong>
great to hear, thanks for your effort!
chipxxx has quit [Ping timeout: 480 seconds]
chipxxx has joined #asahi
chipxxx has quit [Remote host closed the connection]
Brainium has quit [Quit: Konversation terminated!]
sdomi has joined #asahi
linuxgemini13 has joined #asahi
giskard has joined #asahi
linuxgemini1 has quit [Ping timeout: 480 seconds]
brad_ has joined #asahi
<winter>
jannau: did you see my messages wrt the HiDPI issue btw? just curious what the issue is :) thanks again!
brad_ has quit [Quit: Konversation terminated!]
chipxxx has quit [Remote host closed the connection]
<jannau>
winter: the issue is that the panel dimensions are parsed on startup from the device tree but is overwritten when the display powers down
chipxxx has joined #asahi
chipxxx has quit [Remote host closed the connection]
chipxxx has joined #asahi
<tpw_rules>
marcan: i am pretty certain something did change with nvme on the latest kernels which has created an incompatibility
<marcan>
no, what happened is newer kernels started hitting the pmgr nonsense more
<marcan>
there is a device tree hack to work around that now
<marcan>
I need to actually fix that bug, it's a fundamental flaw in the genpd subsystem
<marcan>
arm64: dts: apple: HACK: Make ans2 PD always on
<marcan>
that change is probably what you need
<tpw_rules>
well can you upload a new uefi installer image with the hacked device tree?
<marcan>
once I get around to making a new build in general :p
<tpw_rules>
oh, that is a recent fix?
<marcan>
which requires testing and probably calamares nonsense
<marcan>
yes, that was added with the recent kernel push
<tpw_rules>
but is not in the PKGBUILDs yet
<marcan>
it is, it's in the latest kernels already
<marcan>
but it's random depending on probe order and other nonsense whether you hit it or not
<marcan>
lina found another one
<marcan>
the whole thing is just broken
<tpw_rules>
are you saying that hack is not complete? because if it's in the PKGBUILDs then my kernel does have it
<marcan>
that hack is a device tree change
<marcan>
so it's not in the uefi image
<tpw_rules>
i see
<marcan>
what I meant is when I get around to doing a new build of install images
<marcan>
but that might wait until M2 Pro/Max support is in, that's a good time to do that
<marcan>
and by then I might have gotten around to fixing the actual bug instead
<tpw_rules>
ok we will see. the problem seemed to be hit persistently. do the older kernels hit it less often?
<marcan>
it's consistent depending on the kernel build it seems
<marcan>
since that determines probe order
<marcan>
older kernels hit it with DCP only
<marcan>
now NVMe and lina found another one with DCP
<j`ey_>
doesnt the DT determine probe order?
<marcan>
no, it's parallel AIUI
<marcan>
I think the way it works is drivers regiter in initcall order which depends on link order and such, but then the actual probing is parallelized or something since some time ago
<tpw_rules>
so my kernel build just got unlucky
<winter>
jannau: interesting, thanks. it looks like an issue isn't filed for this (in the main repo or the edge thread), should i file one so this is tracked?
julio7359 has quit [Read error: Connection reset by peer]
Brainium has joined #asahi
artemist has quit [Ping timeout: 480 seconds]
julio7359 has joined #asahi
possiblemeatball has quit [Quit: Quit]
i509vcb has joined #asahi
jamespmo_ has quit [Ping timeout: 480 seconds]
julio7359 has quit [Remote host closed the connection]