David Rosca

> These are in one lock So fast its almost never really preempted, its releasing the texture once we have submitted the frame to ffmpeg that requires the lock again....

Looks good now, thanks.

> Mesa 23.6.3 This is not a valid version. (23.2 -> 23.3 -> 24.0 -> ...) > I managed to trace the problem to a failed call to av_hwframe_ctx_init() in...

Log: ``` [Gamescope WSI] Creating Gamescope surface: xid: 0x400002 [Gamescope WSI] Atom of T was wrong type. Expected XCB_ATOM_CARDINAL. wlserver: [types/wlr_compositor.c:692] New wlr_surface 0x5573179d8b10 (res 0x557317af04e0)[Gamescope WSI] Made gamescope surface...

This happens also when there is one single window with no sub windows/surfaces, so bypass doesn't make a difference.

What's the status of this? It would be great to have it merged. Currently the issue in Mesa is that mapping all buffers read+write leads to bad performance on dGPUs.

That sounds good, thanks! My interest for this PR is radeonsi but it will benefit all Mesa drivers, so that also includes vaon12.

This PR came up in discussion of this MR: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25597 Context: Mesa always mapped the buffer as write-only. Up until recently vaDeriveImage was not implemented for multi-planar formats on radeonsi,...

Mesa implementation: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25620

I think that would be nice to have, patches welcome!