<mntirc>
ok, so ETNA_MESA_DEBUG=no_linear_pe,no_ts actually makes the wdisplays corruption go away, but it does not fix the bad svg rendering in chromium
<mntirc>
these issues appear to be 2 separate ones.
<mntirc>
it looks like the chromium problems are caused by the MSAA related patches
<mntirc>
on 7221cc6526c547f402daa60be7177893a78edbc5, everything is still fine
cphealy has quit [Ping timeout: 480 seconds]
<mntirc>
austriancoder: > c2387e6b3c47e4180484ff11fd089487f20f9d0b is the first bad commit
<mntirc>
so the commit that turns on MSAA again causes chromium to mess up svg rendering
<mntirc>
is there a flag to disable msaa?
cphealy has joined #etnaviv
cphealy has quit [Read error: No route to host]
cphealy has joined #etnaviv
cphealy_ has joined #etnaviv
cphealy has quit [Read error: Connection reset by peer]
cphealy has joined #etnaviv
cphealy_ has quit [Read error: Connection reset by peer]
cphealy_ has joined #etnaviv
cphealy has quit [Read error: Connection reset by peer]
cphealy_ has quit []
cphealy has joined #etnaviv
lynxeye has joined #etnaviv
<lynxeye>
mntirc: Nope, no flag to disable MSAA. At least not yet, we might add it if it turns out to break more stuff.
<lynxeye>
mntirc: Is Chromium using desktop GL or GLES in your setup?
pcercuei has joined #etnaviv
JohnnyonFlame has quit [Ping timeout: 480 seconds]
mvlad has joined #etnaviv
JohnnyonFlame has joined #etnaviv
Leopold_ has quit [Remote host closed the connection]
<mntirc>
lynxeye: i have rebuilt mesa main tip with c2387e6b3c47e4180484ff11fd089487f20f9d0b reverted and chromium renders fine now, with TS enabled.
<mntirc>
for some reason the wayland mode of chromium (ozone) does ~not~ work with TS. it endless loops on startup after spitting out a lot of > [2532:2532:1111/173649.435001:ERROR:gl_display.cc(508)] EGL Driver message (Error) eglCreateContext: dri2_create_context
<mntirc>
with xwayland winsys it works fine
<lynxeye>
mntirc: Thanks. I'm looking into the MSAA issue and I'm trying to understand the things Skia is doing that might be problematic. There are a few different code paths keyed by the GL version.
<lynxeye>
mntirc: I'm amazed at the number of things the TS sharing managed to break. :/
<mntirc>
maybe those are related?
<mntirc>
i have to say that we still have the glFinish() patch in xwayland, i can also try to take it out... not sure if that will improve things though
<lynxeye>
mntirc: I don't think taking out the glFinish will change anything. At most the TS sharing should reduce the amount of resource flushes we do on the glFlush/Finish.
<mntirc>
ok
<lynxeye>
So maybe it's the other way around and the TS sharing breaks the side effect of the glFinish that you were relying on to get things to work correctly.
<lynxeye>
IIRC nobody really got a grip on why this glFinish was even needed, right?
<mntirc>
hmm i thought daniels kind of understood it
<mntirc>
iirc there was no synchronization method between glamor rendering to front buffer and etnaviv flushing things
<lynxeye>
Yea, I remember some patches from him that tried to get away without the full finish, but iirc they didn't really fix things.
<mntirc>
and rectangles were sometimes just not being rendered, so parts of UI were just missing
<mntirc>
tbh the best solution would be to be able to disable glamor 2d rendering while being able to keep glx
<mntirc>
because the 2d accelerated stuff doesn't really speed things up in practice
<mntirc>
unfortunately one can't turn it off without losing glx
<lynxeye>
wasn't one of the igalia guys working on being able to disable glamor, but keep accelerated client graphics?
<lynxeye>
Though I'm not sure if bad glamor performance is also a result of not enough driver support by etnaviv. From some of my experiments it's all the fallback paths that need to read back GPU renderbuffers that really kill glamor performance right now.
<lynxeye>
Maybe if etnaviv supported a bit more of the glmor HW accelerated stuff it wouldn't look that bad compared to pure SW.
<mntirc>
pure SW is fine for most GUIs though, in my experience, even on cortex-a53
<mntirc>
and gtk3+ and qt do their own gl based rendering i believe?
<lynxeye>
Yes, real xrender is getting less common as most modern apps/frameworks do their own rendering to support the wayland way of life.
<mntirc>
yeah, that's why i'm not sure that it's worth a lot of engineering effort to hw accelerate those old UIs if SW drawing suffices for them
<cphealy>
What's missing in etnaviv to support glamor HW acceleration?
<lynxeye>
cphealy: glamor does work on etnaviv. It's just that some xrender operations need more GL support than what is currently provided by etnaviv to be accelerated. The constant bouncing between HW accelerated operations and SW fallbacks results in suboptimal performance.
<lynxeye>
To the point where xrender can actually be faster if it's forced into full SW mode, instead of trying to accelerate some of it.
<cphealy>
So, some GL features are missing with etnaviv? Any specific features?
<lynxeye>
I don't have a list ready. IIRC there are quite a few glamor acceleration parts that only get unlocked with gles3, as there are no extensions available to expose the functionality on a gles2 context.
<cphealy>
ack
<lynxeye>
But then as mntirc said: xrender loses relevancy from day to day and we really only need it to keep old apps running.
<cphealy>
ack
<cphealy>
Is there much left for getting to gles3?
<lynxeye>
TBH I lost track of the status there. Too much other things going on right now, I would need to check where we actually still have gaps.
<cphealy>
;-)
<mntirc>
gles/gl3 would definitely be much more useful than making old xrender uis fast.
<mntirc>
gimp UI is broken in the same way as kicad's, as expected
<mntirc>
inkscape is fine, apparently it is gtk3.
<mntirc>
there's another regression where a game that's worked fine before (technobabylon with ags engine) loses its flip sync, so front and back buffer order is wrong
<mntirc>
it looks a bit like when you deinterlace a pal video and have the order of half frames wrong
lynxeye has quit [Quit: Leaving.]
mvlad has quit [Remote host closed the connection]
JohnnyonFlame has quit [Read error: No route to host]