> GL and GLES are not relevant. What is relevant is EGL, which defines
> interfaces to make things work on the native platform.
Yes and no. This is what EGL spec says about sharing a texture between contexts:
"OpenGL and OpenGL ES makes no attempt to synchronize access to
texture objects. If a tex
> vkAcquireNextImageKHR() [...] it's the application's decision whether it
> wants a fence, a semaphore, both or none
Correction: "or none" is not allowed
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/list
> That's not true; you can post back a sync token every time the client
> buffer is used by the compositor.
Technically, yes but it's very cumbersome and invasive to the point
where it becomes impractical. Explicit sync is much cleaner solution.
> For instance, Mesa adds the `wl_drm` extension, wh
> As long as we can fall back to not using fences then we should be fine.
Buffers written by the camera are trivial because you control what
happens - just don't attach fence, so that the capture can be used
immediately. For recycled buffers there's an extra bit of work to do
because won't be up
Hi Jason,
I've been wrestling with the sync problems in Wayland some time ago, but
only with regards to 3D drivers.
The guarantee given by the GL/GLES spec is limited to a single graphics
context. If the same buffer is accessed by 2 contexts the outcome is
unspecified. The cross-context and cross
