Dementor has quit [Read error: Connection reset by peer]
Dementor has joined #asahi-gpu
stipa is now known as Guest5516
stipa has joined #asahi-gpu
Guest5516 has quit [Ping timeout: 480 seconds]
kesslerd_ has joined #asahi-gpu
kesslerd has quit [Ping timeout: 480 seconds]
DarkShadow4444 has quit [Ping timeout: 480 seconds]
ktz has joined #asahi-gpu
<ktz>
its incredible how buttery smooth my desktop experience has been with sway running on alpine, to the extend that it felt like a big downgrade a couple of weeks ago back when I tried the drivier
<ktz>
I'm really curious why that happens tho, I haven't been able to reproduce the performance of this combination in other ways, be it different compositors in combination with other distros
<ktz>
running different wms for example or the exact same setup on alarm feels like a borderline torture by the constant tearing and the low frame rates
DarkShadow44 has joined #asahi-gpu
<ktz>
the way I go about measuring any actual numbers is pretty simple and most likely not a real indicator but the results feel on par with my experience
<ktz>
it really makes me wonder what could be the exact cause that with other setups it struggles to even hit consistent 60 frames and frequently hangs sub-40frames while it puts out such an astronomical performance in my case https://ibb.co/7RWSwnT
<marcan>
ktz: if you were getting tearing, you were using xorg. xorg is broken in several ways that nobody plans to fix.
<marcan>
alarm with kwin on wayland is buttery smooth
<marcan>
(with the drivers)
<ktz>
no, it was sway and I also got the xwayland option explicitly disabled
<marcan>
wayland cannot tear
<marcan>
do you still have that install?
<ktz>
not sure if by tearing I mean the same thing with you
<ktz>
yeah
<ktz>
I'm running on it
<marcan>
run asahi-diagnose and check whether it shouts at you
<ktz>
ohh, I'm using alpinelinux
<marcan>
but you mentioned alarm?
<ktz>
the exact same setup on asahi is borderline unusable in comparison, no idea why
<marcan>
do you still have that asahi install?
<ktz>
ah, no sadly, I've always had asahi installed as well but I had to change machine and I got just alpine now
<marcan>
my bet is you screwed around with expert mode while installing it and ended up with unsupported firmware which means the drivers never actually worked
<ktz>
I can put in some time and get alarm running as well and make a more detailed report
<marcan>
either that or you didn't get stuff installed properly (new kernel, new mesa, and grub config update)
<ktz>
this is something that I've been wondering for quite some time now, out of curiosity, how does this https://testufo.com/ perform on your machine?
hightower2 has quit [Ping timeout: 480 seconds]
<marcan>
firefox?
<ktz>
yeah
ktz has quit [Remote host closed the connection]
ktz has joined #asahi-gpu
<ktz>
it was capped on 60fps back when I tried it with the driver
<marcan>
rock solid 60fps on asahi
<kesslerd_>
same here
<ktz>
its capped on 60? running with the driver?
<marcan>
what do you mean by capped?
<marcan>
>60 doesn't make any sense, the screen only does 60 (on the laptops)
<ktz>
I mean a limit, being capped at 60 and not getting past it even if its possible
<marcan>
(promotion 120 is not supported yet in the kernel)
<marcan>
there is no point to going past 60, that's just burning power for no reason
<marcan>
if you want a smooth desktop you want 60
<marcan>
unless you're talking about a desktop with a >60Hz monitor
<marcan>
testufo detects 60 and shows 60/30/15 and the 60 bar is perfectly smooth which is the optimal experience
<ktz>
well, I my experience varied even with constant 60 fps, not sure how much improvement one can percieve technically but even capped on 60fps back when I ran the driver felt much more sluggish in comparison
<marcan>
... the screen only does 60, are you saying alpine is giving you more than 60 on a laptop?
<ktz>
for example its night and day versus chromium which must have a cap at 60
<marcan>
which machine is this?
<ktz>
yeah, I don't know if the screen keeps up refresh wise but its more than 60
<ktz>
macbook air m1
<marcan>
then alpine is broken and giving you a worse experience and you are placebo effecting yourself into thinking it's better :p
<marcan>
there is no way to go above 60 on that machine
<marcan>
that is the hardware limit and trying to go higher will only increase judder or give you tearing
<marcan>
this is a physical limitation
<ktz>
I sent an image shot a couple of minutes ago, did you check it?
<marcan>
yes, because without the display output driver there is no vsync at all so it goes wild
<marcan>
so that means you were probably running without the driver
<marcan>
which means you got tearing
<ktz>
well, if you could reproduce it on your machine in person maybe you would change your opninion, even if in papper it doesn't make much sense due to the supposed 60hz refresh rate
<marcan>
... look, I'm looking at the same exact machine right now with all the drivers and it is perfectly smooth and I know how refresh rates work and am very picky about judder
<marcan>
either your setup was broken or you are confusing yourself
Dementor9 has joined #asahi-gpu
<marcan>
do I need to waste my time taking a high-speed video of my screen now to prove to you that it's a solid 60fps?
<ktz>
hehe no I got no reason to doupt you, I'm just not entirely sure that you wouldn't change your mind if you were to reproduce it
Dementor has quit [Ping timeout: 480 seconds]
Dementor9 is now known as Dementor
<ktz>
mind you I'm running asahi for a year now, I've done countless installs, both alarm as well as alpine, its not just a couple of times I've set it up, and its been consistent this way
<marcan>
well the drivers with proper vsync have only been available for a couple months
<marcan>
as has the GPU driver
<ktz>
no I'm talking gpu-less, I've only tried gpu two times, one in alpine and one in alarm
<marcan>
we don't care about gpu-less :p
<marcan>
I'm trying without the drivers now on kwin_x11 and it's a juddery mess and still capped at 60, sure
<marcan>
I assume sway interacts differently with the dumb framebuffer driver and whatever metadata firefox ends up with means nothing gets capped
<marcan>
that will indeed make it "smoother"
<marcan>
we don't care, that experience is broken anyway (framebuffer driver), that's why the new edge kernel has a real display driver with real buffer swaps
<marcan>
there is no point in wasting time in improving the dumb framebuffer experience here, that's all obsolete
<ktz>
no idea about x11 stuff, I only tried a couple of wm's to just see if I could get anywhere near the numbers I normally get in an attempt to poinpoint the reason that this particular combination yields such supersonic results hehe
<marcan>
"uncapped fps" is a bad thing, not a good thing
<ktz>
I'll be back with more anecdotal feedback once I got some experience running on gpu
<marcan>
and again we just don't care about simpledrm setups any more, that's going to be discontinued soon
<ktz>
yeah understandable, makes sense
<marcan>
vsync on simpledrm is a lie, it has *no* vsync, I think it just reports 0Hz
<marcan>
it's up to compositors to do something with that
<marcan>
they will naturally do different things, all wrong
<marcan>
because there is no right thing to be done
<marcan>
so yeah, I believe you that it looks better on sway than on kwin, but that's not because sway is doing anything right, it's just because it breaks in a different way (burning power and getting smoothness out of it by accident)
<ktz>
how to take a high speed video like you said? any recorder in particular?
<marcan>
most phones these days can do 120Hz at least
<marcan>
some cameras can too
<marcan>
my point is, whatever video you take of your setup isn't going to look any better than what I'm seeing on kwin *with* all the proper drivers
<marcan>
and that's what matters
<ktz>
yeah people make a big deal about refresh rates on their phones for some reason, I'm not really using one to such extends but it definitelly feels night and day on my air
<ktz>
yeah if that's really the case then the discussion has no further reason to take place
<marcan>
your comparison is "broken 60Hz" and "less broken 60Hz"
<marcan>
get the drivers and that's "proper 60Hz"
<ktz>
hope that's indeed the case, this is why I've shared my experience
<ktz>
I should have done that a couple of months ago before the gpu was really a thing in case others could benefit
<marcan>
or get a 14"/16" laptop once we support promotion and then *that* will be 120Hz which *is* a noticeable improvement :-)
<marcan>
by the way, none of this has anything to do with the gpu
<marcan>
this is about the display controller driver
<marcan>
(which is also in linux-asahi-edge)
<marcan>
the gpu driver doesn't affect vsync
<marcan>
the thing is counterintuitively, you get a worse experience with the proper display controller driver and no gpu driver, because when software rendering is borderline able to keep up, the additional vsync from a real driver actually ends up making it feel less smooth
<marcan>
that's why we never shipped that until the gpu driver was ready
<ktz>
hmm, good to know, then maybe alpine could somehow differ config wise in relation to the controller driver in theory? I can't wrap my head around why it only behaves like that in alpine but in alarm it wouldn't
<kesslerd_>
is there a timeline for promotion? I don't see anything in wiki/Feature-Support
<marcan>
it's sway or something alpine does with those builds. whatever frame rate you get out of firefox in any case without the display driver is fake
<marcan>
there is no correct framerate
<ktz>
yeah what you just described could be the case I didn't really like my experience at constant 60fps back when I test drived the gpu
<marcan>
it sounds like you never actually got a working setup
<marcan>
and you've been comparing broken setups all along :p
<ktz>
well, its a possibility yeah but I did it two times both on asahi and alpine
<ktz>
I remember I checked inxi -G for example which checked out with mps's info just for a cross check
<ktz>
its likely I had it working
<marcan>
kesslerd_: there is no timeline for anything
<ktz>
the only reason you can really tell for yourself is if you had alpine installed and I handed you over my sway config and saw for yourself
<ktz>
in case it was indeed what you ended up experiencing as well
<marcan>
look please just trust me that what I'm seeing here is the limits of the physical screen and you *cannot* do better
<TellowKrinkle>
macOS is always available as a "definitely working" comparison point
<marcan>
either you've been comparing broken setups, or you somehow like a broken setup over the best case
<marcan>
I've been doing this for a while, I know how to spot judder and framerate issues
<ktz>
yeah I do trust you, I know you're right in theory it can't really be otherwise
<marcan>
and there is no physical way to do more than 60Hz on a 60Hz screen
<ktz>
but I can't convince myself unless you'd evaluate and then confirm that by your experience as well
<marcan>
well you could make sure you have a working setup and try that first :p
<ktz>
but yeah there's no real reason discussing it more as is
<ktz>
I will yeah, I'll report back in case I find anything interesting
<marcan>
and really I've had these kinds of "but you need to see what I'm seeing" discussions more than once and it never goes anywhere, it's always either someone was doing something wrong or placebo effect or something that cannot be confirmed with proper testing
<marcan>
like the 300fps number on there could easily be biasing your brain into thinking it's better
<marcan>
that's a thing that happens
<ktz>
yeah it could certainly be the case
<ktz>
our brain likes monkeying like that I'm sure
<TellowKrinkle>
Do you have any actual 120+ hz displays you could compare to? That might help make it more obvious
<marcan>
I would take a high-speed video if I had suspicions about judder, but testufo is actually a very clear test case and I know how to evaluate it with my eyes and be confident that it's objectively smooth (I've had my fair share of staring at panning images like that and noticing the little details of framerate mismatch judders and such, it's why e.g. I have my home projector set up to sync its ...
<marcan>
... frame rate with the frame rate of what I play, because for example 24Hz material on 60Hz *does* cause judder)
<marcan>
basically if you can track the ufo with your eyes and there are no "jumps" and it looks like a consistently horizontally blurred image, that's a good indicator you have proper frame pacing
<ktz>
god bless you my man, sending hugs and love to your way, thanks for blessing us with this, it still feels unreal to this day.. it has been such an incredible experience really, I'm very grateful for that. I was rarely touching my air and now I'm daily driving it ever since my mobo broke.. feels like a dream lol
<marcan>
(to be fair I'm pretty sure I've seen the odd dropped frame and such, but it's not a consistent bad pacing thing, that's just a "browser and desktop stacks are still kind of bad at hard realtime deadlines" issue)
<marcan>
which is incidentally another thing I'm interested in improving, especially in the context of audio, longer term (hard realtime breaks)
<marcan>
it's also why we had a discussion here earlier about CPU scheduler stuff with GPU apps
<marcan>
so don't get me wrong, there's definitely work to be done in making things smoother more often and improving performance of various workloads
<marcan>
it's just that at least testufo is already as good as it's going to get :)
<ktz>
hehe, thanks for elaborating buddy, appreciate your time, you're the man
<marcan>
Also another counterintuitive thing: with a 300+FPS uncapped setup like yours, you'll be pegging the CPUs, which means you will actually have fewer chances of higher latency problems when the scheduler downclocks CPUs or tries to run things on the e-cores (this is what we were talking about earlier)
<marcan>
so it's possible you have fewer of those rare dropped frames than I do, though it would be a very minor difference, and definitely not worth burning CPU for it, and we can fix that with the scheduler tweaks we discussed
<marcan>
(or you could get the same experience forcing the CPU governor to performance and tasksetting everything that matters to the p-cores, even with the drivers)
<marcan>
lots of subtleties
<ktz>
oh by the way since we're here, something I wanted to ask for some time now, is there any other antenna I can physically locate besides the two main ones which plug on the mainboard? even when physically unplugging the machine can do wireless with no problem
<marcan>
I have no idea lol, there may be one on the board? I've never taken one of these machines apart
<marcan>
probably best on #asahi or #asahi-offtopic though
<ktz>
if you ever need to reproduce it there goes my sway config https://git.sr.ht/~ktz/sway, rest is typical, both with rtkit and without if that makes any difference
<ktz>
really? I should have sent you some pictures then, I did many surgeries on my poor machine hehe, its resting in peace now
<ktz>
yeah you're right, that's all from me, wish you the best once more!
cylm has joined #asahi-gpu
ktz has quit [Remote host closed the connection]
ktz has joined #asahi-gpu
ktz has quit []
possiblemeatball has quit [Quit: Quit]
VinDuv has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
VinDuv has joined #asahi-gpu
zalyx has quit [Quit: later alligator]
zalyx has joined #asahi-gpu
bisko has joined #asahi-gpu
i509vcb has quit [Quit: Connection closed for inactivity]
bisko has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
nyilas has joined #asahi-gpu
MajorBiscuit has joined #asahi-gpu
darkapex1 has joined #asahi-gpu
darkapex has quit [Read error: Connection reset by peer]
jnn is now known as jn
nyilas has quit [Remote host closed the connection]
nyilas has joined #asahi-gpu
nyilas has quit [Remote host closed the connection]
nyilas has joined #asahi-gpu
nyilas has quit [Remote host closed the connection]
kesslerd_ has quit [Remote host closed the connection]
kesslerd has joined #asahi-gpu
kesslerd_ has joined #asahi-gpu
kesslerd has quit [Remote host closed the connection]
kesslerd_ has quit [Read error: Connection reset by peer]
kesslerd has joined #asahi-gpu
kesslerd has quit [Remote host closed the connection]
kotleni has joined #asahi-gpu
kesslerd has joined #asahi-gpu
stipa is now known as Guest5558
stipa has joined #asahi-gpu
Guest5558 has quit [Ping timeout: 480 seconds]
nyilas has joined #asahi-gpu
nyilas has quit [Quit: nyilas]
kotleni has quit [Quit: Leaving]
bisko has joined #asahi-gpu
hightower3 has quit [Ping timeout: 480 seconds]
nyilas has joined #asahi-gpu
bisko has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
nyilas has quit [Remote host closed the connection]
bisko has joined #asahi-gpu
nyilas has joined #asahi-gpu
mairacanal has joined #asahi-gpu
hightower2 has joined #asahi-gpu
possiblemeatball has joined #asahi-gpu
stipa is now known as Guest5565
stipa has joined #asahi-gpu
Guest5565 has quit [Read error: Connection reset by peer]
kesslerd has quit [Remote host closed the connection]
kesslerd has joined #asahi-gpu
stipa is now known as Guest5568
stipa has joined #asahi-gpu
possiblemeatball has quit [Quit: Quit]
Guest5568 has quit [Ping timeout: 480 seconds]
possiblemeatball has joined #asahi-gpu
bluetail51 has joined #asahi-gpu
bluetail5 has quit [Ping timeout: 480 seconds]
<lina>
alyssa: Explicit sync should be fixed! ^^
<lina>
The actual big bug was really obvious, that only took an hour or so to find... I wasn't clearing ctx->batch so after a submission things kept getting piled onto the same batch.
<lina>
But then there was a much subtler thing that had me stuck for a while... some dEQPs would flake, rarely. The symptom on at least some tests was that a vertex would be processed as all-0, rarely (but always the same one for any given test).
<lina>
My conclusion was that the USC caches persist and are not invalidated when you queue things back to back on the GPU, so if the CPU writes some vertices to a VBO, submits a batch, writes some more, submits another batch, the first one could load a whole cache line before the second one's vertices were written, and then the second one would read those (usually just the first vertex) as zero from the cache.
<lina>
I don't know what the "official" way to fix this is, it's possible macOS just never hits it because it never actually pipelines GL commands into hardware queues? (It might always roundtrip through the CPU)
<lina>
But trying random stuff I found out that one bit in the VDM barrier command you found fixes everything, so now I always put one of those at the beginning of every batch.
<lina>
So now we're back to passing the dEQPs, GLES2 and EGL, except now with no flakes and with gallium sync = flush, not sync ^^
<lina>
glmark2 got another speed bump too, and I saw terrain at over 180 FPS now
<lina>
That mystery didn't take up my whole day, so I still had time to implement render stats and fault feedback ^^
<lina>
So now with ASAHI_MESA_DEBUG=stats you get this:
<kotleni>
Hello. Driver now integrated to linux kernel?
<kotleni>
I builded all PKGBUILDs from github, but driver for gpu not installed (i still use llvmpipe for rendering.
<marcan>
kotleni: this is not a support channel, see the blog for how to install the driver (you don't need to build anything) or go to #asahi if you have questions.
<kotleni>
Sorry, :>
<kotleni>
It's just not regular questions...
kotleni has left #asahi-gpu [#asahi-gpu]
<marcan>
sure it is, unless you're actively developing the driver it goes in #asahi
mkurz has quit [Ping timeout: 480 seconds]
kesslerd has quit [Quit: Leaving]
kesslerd has joined #asahi-gpu
hightower2 has quit [Ping timeout: 480 seconds]
kesslerd has quit [Quit: Konversation terminated!]
kesslerd has joined #asahi-gpu
kesslerd has quit []
kesslerd has joined #asahi-gpu
kesslerd has quit []
kesslerd has joined #asahi-gpu
kesslerd has quit [Remote host closed the connection]
kesslerd has joined #asahi-gpu
mkurz has joined #asahi-gpu
possiblemeatball has quit [Quit: Quit]
<cwabbott>
lina: I don't know how things work in GL, but for vulkan, there's a line in the spec that all user writes become visible to the GPU upon submit, so if your GPU has any sort of non-coherent cache then you have to invalidate it at the beginning and flush it at the end of a submission
<cwabbott>
there's probably a similar sort of requirement with gallium
hightower2 has joined #asahi-gpu
<cwabbott>
there should be a flush and invalidate/clean command and you probably also need to flush at the end of a submission in addition to cleaning at the beginning
<lina>
I think the flushing is handled by the firmware, I already ran into that with compute and it seems to be related to a sequence number in some firmware structures.
<cwabbott>
ah, maybe just need to clean?
<cwabbott>
I know on freedreno flushing is handled by the kernel too
<lina>
Yeah, that's what that VDM barrier seems to accomplish. I don't know if there is another way, like a field in the firmware structs...
<lina>
At least none of the pending unknowns I have helped
<lina>
The VDM barrier is userspace, firmware structs are kernel
MajorBiscuit has quit [Quit: WeeChat 3.6]
possiblemeatball has joined #asahi-gpu
cylm has quit [Ping timeout: 480 seconds]
possiblemeatball has quit [Quit: Quit]
kode54 has quit [Quit: Ping timeout (120 seconds)]
kode54 has joined #asahi-gpu
mkurz has quit [Ping timeout: 480 seconds]
mkurz has joined #asahi-gpu
mkurz has quit [Remote host closed the connection]
zzywysm has quit [Ping timeout: 480 seconds]
zzywysm has joined #asahi-gpu
nyilas has quit [Remote host closed the connection]