There's an open Gallium nine bug: https://github.com/iXit/Mesa-3D/issues/138 It looks like pipe_context->clear called with PIPE_CLEAR_COLOR isn't applied immediately to the buffer. As nine mimics swap-chains, the buffer is reused after some frames resulting in "delayed" presentation. The problem doesn't exist with R600_DEBUG=notiling and it doesn't exists when using pipe_context->clear_render_target instead. Tested with mesa git: https://github.com/iXit/Mesa-3D/
(In reply to Patrick Rudolph from comment #0) > There's an open Gallium nine bug: https://github.com/iXit/Mesa-3D/issues/138 > > It looks like pipe_context->clear called with PIPE_CLEAR_COLOR isn't applied > immediately to the buffer. That's correct. nine needs to resolve the clear using the pipe->flush_resource hook. > The problem doesn't exist with R600_DEBUG=notiling Fast clear only works with tiled surfaces. > and it doesn't exists when using pipe_context->clear_render_target instead. IIRC that's currently a software fallback.
(In reply to Michel Dänzer from comment #1) > That's correct. nine needs to resolve the clear using the > pipe->flush_resource hook. > Nine does call it before sending the buffer to the server.
Ok, after discussion with Michel we realized the problem is that flush_resource should be called before flushing, and not after.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.