<mntirc>
on imx8mplus (gc7000 6204), i'm getting quite bad on-screen performance but really ok off-screen performance with glmark2-es2-wayland -s 1920x1080. why would that be?
<mntirc>
with --off-screen: [build] use-vbo=true: FPS: 1251 FrameTime: 0.799 ms
<mntirc>
with --fullscreen: [build] use-vbo=true: FPS: 249 FrameTime: 4.019 ms
<mntirc>
can wayland really be eating 1000fps?
<mntirc>
if i move the window to a hidden workspace on sway, the FPS doubles to 500
<mntirc>
(the same problem exists on weston btw)
<mntirc>
so there is some kind of massive performance loss somewhere just by blitting or detiling (not sure how it is done) the rendered buffer?
<mntirc>
cc marex
<mntirc>
ok, shared_ts also gets us to 500, but why, and where's the other half?
<mntirc>
and another question that remains is what does chromium-wayland do that is so bad that it hangs up the gpu with shared_ts
<mntirc>
ok, updated to chromium 113 and that problem has solved itself as it now requires GLES3
<mntirc>
bizarrely, sdl2 apps don't show with shared_ts. they run, but they are never presented
<mntirc>
hmm, keepassxc also doesn't show up. so probably this is xwayland related
<mntirc>
yeah, with SDL_VIDEODRIVER=wayland, testgles2 from libsdl2-tests shows up. but with shared_ts, it has a randomly blinking background color. looks like the clear goes wrong
JohnnyonFlame has joined #etnaviv
JohnnyonF has quit [Ping timeout: 480 seconds]
<mntirc>
here is a very simple demo that does not render correctly with shared_ts, due to something odd with the glClear(GL_COLOR_BUFFER_BIT)
<mntirc>
this happens _only_ if glClearColor's rgb is 0,0,0
<mntirc>
is that special cased in the driver?
<mntirc>
i.e. setting one of the channels to 0.1 fixes it
* marex
resumes from low power state
<marex>
mntirc: you interrupted ?
<marex>
mntirc: isn't the offscreen rendering just doing as-much-as-the-GPU-can-crank-out into a memory buffer, while on-screen has to deal with passing that buffer to scanout ?
<marex>
the off screen rendering is usually significantly faster
<mntirc>
marex: ok, but i don't think it should be this extreme
<mntirc>
marex: just wanted to know if you had the same experience on imx8mplus or if i am holding it wrong
<cphealy>
mntirc: It could be related to the cost to render linear vs render tiled. With the i.MX8Mplus, there is no scanout support for tiled buffers so the GPU has to either render linear or render tiled, then perform detile. So, it could be that rendering linear is expensive with GPU or it could be that detiling is expensive on GPU, or it could be DRAM bandwidth limit, or some combination.
<cphealy>
Also, IIRC, the GPU in i.MX8Mplus has DEC400 but the display HW does not. If this is the case, rendering offscreen would take substantially less DRAM bandwidth than rendering for scanout.
<marex>
mntirc: I have mx8mp on my desk now, so I can try
<cphealy>
Regarding DRAM bandwidth, the i.MX8MPlus includes a perf PMU event driver that exposes DRAM bandwidth. This might be useful for determining the DRAM bandwidth as well as load percentage under various use cases.