<linkmauve>
The background is also a shader, which doesn’t render correctly compared to what I get on Intel.
<linkmauve>
I’ll try to isolate it in order to make a better reproduction testcase.
<enunes>
linkmauve: cool, what exactly are we looking at, did you do the optimization on shaders and it performs better now? anything you plan to push to gtk? anything that seems like a lima issue remaining?
<enunes>
shader thing seems fair enough, if it's a compiler bug please file the issue in mesa, maybe a separate one than the current gtk4-demo one would be better
<enunes>
what I still dont understand is the entire 'performs worse than software' thing and if this work that you did also addresses that
<linkmauve>
We’re looking at gtk4-demo --run=gltransition.
<linkmauve>
There are two bugs visible in this screenshot that I would consider Lima bugs.
<linkmauve>
The shadertoy at the top right should render clocks, it obviously doesn’t.
<linkmauve>
And the background should render like plasma balls.
<linkmauve>
I haven’t investigated either yet, what do you use to investigate potential shader miscompilation?
<linkmauve>
As for the gradient I haven’t tried to fix it yet, because I don’t have any way to compare for now. :/
<enunes>
well that looks like one, ideally if you could get a gles2 apitrace and run in intel and it works but in lima glitches like that, seems like a shader (or something else) issue in lima
<enunes>
but if it's easy enough as running that command maybe thats enough too
<enunes>
would be better to ensure it's running the same thing though, not GL 3 in one and GLES2 in another for example
<linkmauve>
On Intel I’m testing with GLES 3.2.
<enunes>
and this is still with the same debug build that allows gles? I'm kinda curious how it would perform with a release build that also allows gles2
<linkmauve>
Yes.
<enunes>
on my laptop if I do MESA_GL_VERSION_OVERRIDE=2.1 gtk4-demo --run=gltransition I also get some weird things
<enunes>
so if that needs GL3 to work... maybe it wont work
<linkmauve>
enunes, in gdk/gdkglcontext.c, move force_gles = GDK_DISPLAY_DEBUG_CHECK (display, GL_GLES); (around line 698) outside of the #ifdef, and set it to TRUE.
<linkmauve>
enunes, here I get Gsk-Message: 14:02:32.108: Failed to realize renderer of type 'GskGLRenderer' for surface 'GdkWaylandToplevel': Unable to create a GL context
<enunes>
I get pink background, wind and crosswarp show the image, radial and kaleidoscope nothing
<linkmauve>
enunes, btw they’re working on a new renderer named “next”, with which they’re planning on automatically choosing between GL and GLES.
<linkmauve>
Yes, you’re now using the cairo software renderer.
<linkmauve>
No GL anymore.
<enunes>
ah, I see
<enunes>
GL 2 would also be kind of ok for lima if it sticks to the GLES2 subset
<linkmauve>
It doesn’t.
uis has joined #lima
<enunes>
linkmauve: ok I did a build and I think I have an environment to test now, I'll continue some time later... so if I understand correctly that complicated shader is in fact just for that transition effect?
monstr has joined #lima
monstr has quit [Remote host closed the connection]
monstr has joined #lima
monstr has quit [Read error: Connection reset by peer]
monstr has joined #lima
<linkmauve>
There are multiple complicated shaders in this demo.
<linkmauve>
It’s the one most likely to cause issues to Lima.
<linkmauve>
Btw --run=gears is where I see the 8.5 fps on my PinePhone.
kaspter has joined #lima
uis has quit [Ping timeout: 264 seconds]
monstr has quit [Remote host closed the connection]
kaspter has quit [Quit: kaspter]
uis has joined #lima
Pak0st has joined #lima
enty has joined #lima
ente has quit [Read error: Connection reset by peer]