mdp has quit [Read error: Connection reset by peer]
mdp has joined #etnaviv
pcercuei has quit [Quit: dodo]
mupuf has joined #etnaviv
_whitelogger has joined #etnaviv
lfa has joined #etnaviv
lfa has quit [Read error: Connection reset by peer]
lynxeye has joined #etnaviv
pcercuei has joined #etnaviv
juanrubio_ has joined #etnaviv
<daniels>
mntmn: the main difference between rootless + rooted Xwl is that in rooted mode, it uses an EGLSurface to render into + calls eglSwapBuffers to present; in rootless mode, it's a bit more YOLO - it binds gbm_bo -> EGLImage -> FBO, and renders into that
<mntmn>
ah!
<daniels>
unfortunately that's kind of painful, because there's not really a good synchronisation point for FBOs when you need to do copies like etnaviv does
<daniels>
and there's also the issue that legacy X11 apps will just render directly into the frontbuffer, maybe whilst the compositor is already scanning out of them
<daniels>
so in that sense some kind of flickering nightmare is 'expected'
<daniels>
however
<daniels>
it might be at least strongly mitigated by the wlroots xwl support implementing one of the ewmh/netwm protocols
<daniels>
this allows the WM and the client to synchronise their drawing via the magic synchronisation mechanism of window properties
<daniels>
doing that might well give a bit less collision between clients rendering and wlroots displaying at least?
<daniels>
but unfortunately Xwl + FBO is one of those things we just don't really have a good answer for - X11 wants to bash things directly into the active frontbuffer at random times, Wayland wants you to use separate buffers, etnaviv wants strong end-of-frame markers so it can do copies between render target + texture source
<daniels>
(well, the 'good answer' is to not use X11 but I guess that's not super helpful for you)
<mntmn>
yeah, x11 is used in all kinds of places. for example, while chromium itself is fine, the file/folder dialog it uses has the same repaint issues
<mntmn>
what i found interesting is that bailing out at the top of glamor composite operations fixes it
<mntmn>
(introduces a significant slowdown in some places, though)
<mntmn>
the composite operation seems to be doing a number of blits using quads/triangle fans, right
<mntmn>
so is it technically possible that xwayland would copy out the fbo that these quads get rendered to before it is finished rendering?
<daniels>
right, if you bail out of Glamor composite, then you fall back to software uploads, which are pretty strongly synchronised
<mntmn>
ok, that makes some sense
<daniels>
I think the failure mode is more:
<daniels>
- Glamor is writing to the active window buffer at the same time wlroots is reading from it
<daniels>
- etnaviv needs to track the outstanding rendering operations to the X server's view of the active window buffer (an FBO) and do blits to wlroots's view of the active window buffer (a texture) to translate between tile modes (unless this isn't a problem on imx8 anymore)
<daniels>
- wlroots is displaying from the active window buffer (because there's only one, X11 clients aren't double-buffered unless they're using GLX)
<mntmn>
how does wlroots decide when to read? so there's no way to force a refresh of the window FBO at the end of these GL operations, because that's only possible with double buffering? (??)
berton has joined #etnaviv
<daniels>
well, Xwayland does send attach + damage + commit, but it will be of the same buffer
<daniels>
so wlroots knows when to update, but there's no guarantee Xwl won't be scribbling all over the active buffer before that update happens
<daniels>
unfortunately etnaviv doesn't know that it needs to update its shadow texture though ...
berton has quit [Remote host closed the connection]
<mntmn>
by shadow texture you mean the one with a different tiling format, that gets blitted at the end?
<mntmn>
this sure sounds like a lot of moving parts
berton has joined #etnaviv
<daniels>
yeah
<daniels>
three sets which each have a lot of moving parts, none of them on speaking terms with each other :P what could possibly go wrong?
<daniels>
one thing you could do is try hacking wlroots to attach its textures with GL_TEXTURE_EXTERNAL_OES rather than GL_TEXTURE_2D
<daniels>
that will make native apps massively slower, but it _might_ fix Xwl apps
<mntmn>
interesting, let me see
<mntmn>
that seems non-trivial to do
<mntmn>
btw just checked, wayland gnome3 exhibits the same problem, so not wlroots-only
<mntmn>
(BTW the gnome3 desktop works really nicely now on imx8mq)
<daniels>
\o/
<mntmn>
i think if i could disable this glamor compositing just for certain applications, that would already be a step forward.
<mntmn>
daniels: on panfrost, you don't have this problem?
<mntmn>
you can see it for example very nicely in the (pre-gtk3) GIMP, where it thrashes the whole drawing canvas
<mntmn>
gtk3 gimp resolves it
<mntmn>
daniels: it is a sync issue. i forced all composite ops to be copies, which is easier to debug but shows the same problem. putting a glamor_prepare/finish_access() at the end of glamor_copy_fbo_fbo_draw() mitigates it
<mntmn>
but this makes everything very slow.
<mntmn>
it shows that the renders themselves are fine though, they’re just not flushed/synced before being copied out by whatever mechanism
<daniels>
mntmn: we don't have that problem because we don't have shadow copies :\
<mntmn>
ok, got it
<mntmn>
ok i found a solution
<mntmn>
daniels: if i read 1 pixel from the dst pixmap fbo via glReadPixels after the composite operations, the problem is fixed
<mntmn>
and it is still fast
<daniels>
nice!
<daniels>
yeah, ReadPixels is like a superflush :P
<mntmn>
daniels: ../hw/xwayland/xwayland-glamor-gbm.c:159:40: warning: passing argument 1 of ‘xwl_glamor_egl_make_current’ from incompatible pointer type [-Wincompatible-pointer-types]
<mntmn>
is that ok?
<daniels>
yeah, it should be xwl_screen rather than xwl_screen->screen
<mntmn>
i guess i'll remove the ->screen
<mntmn>
ok
<daniels>
right
<mntmn>
nope, i'm sorry
<mntmn>
(doesn't do the job)
<daniels>
oh well :(
<mntmn>
but thanks for the effort!
<daniels>
np!
shoragan_ is now known as shoragan
mauz555 has joined #etnaviv
<mntmn>
daniels: what do you think, i'll just make a issue + PR with that single glFlush and maybe in the discussion a better solution can be found?