<cphealy>
mntirc: out of curiosity, are you seeing any difference in FPS for apps that stress the GPU now that TS buffer sharing is enabled?
<mntirc>
cphealy: not sure, but a weird thing: on dcss->hdmi, i get less fps (~30) than on lcdif->mipi (>40fps) for the same resolution and demo (webgl blobs)
<mntirc>
but this was the same before
<cphealy>
In the case where you are getting less FPS, is the display resolution the same or just the demo resolution?
<mntirc>
cphealy: exactly the same display resolution (1920x1080). the only difference is refresh rate, on HDMI it is 60hz. on lcdif it is lower, around 42hz
<cphealy>
One theory is that with the 60Hz display, the use case takes slightly more than 16.6 milliseconds so drops to 30 fps doing every other while on the 42Hz display, having the use case take 17 milliseconds/frame is fine and it still hits every single vsync. (Just a theory)
<cphealy>
Can you drop the VSYNC rate with HDMI to 42Hz? If so, you can test to see if FPS goes up with the use case.
<mntirc>
interesting theory, i can try to set it to 50 probably
<mntirc>
cphealy: i think you are right, with 50hz, i get 40+ fps on hdmi
<cphealy>
Even a blind squirrel finds a nut once in a while... (I'm the blind squirrel) ;-)
<cphealy>
So, the next question then is how do you get sufficient performance to get the workload done in under 16.6 milliseconds so you can hit 60Hz.
<cphealy>
without knowing where the actual bottleneck is, have you tried running the GPU at 1GHz?
<mntirc>
haha, thanks for the idea!
<lynxeye>
mntirc: screenshot from the gtk3 app looks like the TS buffer is read with a wrong offset or something like that. I had some hope that those bugs are all gone with the latest revision of the patchset. Hope crushed.
<mntirc>
lynxeye: sorry for crushing it!
<lynxeye>
mntirc: Just to check the obvious thing: you don't see any complaints on stderr from the app or compositor, right?
<mntirc>
the corrupted graphics are intermittent btw, it _can_ draw the UI correctly but it goes in and out of that state
<mntirc>
it looks like it also depends on the size of the window. if it is lets say >1000, it's fine
<mntirc>
pixels width / stride, that is
<mntirc>
i've tried some other gtk3 apps like gedit and gnome-tweaks, and they are fine. gnome-control-center (gtk4) sometimes renders a green flash instead of the mask for it's shadow outline
<mntirc>
lynxeye: i didn't see any complaints in stderr or in dmesg
<lynxeye>
mntirc: since I don't think I can reproduce this easily here, you could try to capture an apitrace if that isn't too much to ask. Maybe I'm able to figure out what going wrong by looking at what the app does.
<mntirc>
ok!
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #etnaviv
frieder has quit [Remote host closed the connection]
<mntirc>
lynxeye: might be related to TS after all, looking at this pattern
<mntirc>
yeah, after disabling dark reader, the google logo is also corrupted like that
<mntirc>
it's a bit like the clipping or alpha mask or something is not detiled correctly, but i'm no expert
lynxeye has quit [Quit: Leaving.]
<austriancoder>
mntirc: ETNA_MESA_DEBUG=no_ts should fix the rendering
<mntirc>
austriancoder: interesting, will try. will this undo the whole perf increase of that patch?
mvlad has quit [Remote host closed the connection]
<austriancoder>
mntirc: disables TS and as consequence TS sharing thing
lynxeye has joined #etnaviv
<lynxeye>
mntirc: Could you try running Chromium with ETNA_MESA_DEBUG=no_linear_pe set?
lynxeye has quit [Quit: Leaving.]
<mntirc>
ETNA_MESA_DEBUG=no_linear_pe doesn't work for chromium, but perhaps i have to run xwayland with it
<mntirc>
nope, that doesn't help
<mntirc>
austriancoder: ETNA_MESA_DEBUG=no_ts also doesn't help
<mntirc>
so it's something else
<austriancoder>
mntirc: if it worked with an older mesa version maybe it's time for a git bisect?
<mntirc>
austriancoder: yep
<mntirc>
austriancoder: lynxeye: here is the wdisplays apitrace, i can't seem to replay it (doesn't open a window) but the size is substantial http://dump.mntmn.com/wdisplays.trace.gz