KhronosGroup / KhronosGroup/OpenGL-Registry

Visibility of changes to targets created from EGLImages is underspecified

Open
#566 13 comments 0 reactions 1 assignee Claimed by @stonesthrow View on GitHub
Dominant language
C
Stars
854
Forks
302
PR merge metrics
No merged PRs in 30d

Description

EGL specifies that modifications to one sibling of a EGLImage are visible to all other siblings:

`If an application specifies an EGLImage sibling as the destination for rendering
and/or pixel download operations (e.g., as an OpenGL or OpenGL ES framebuffer
object, glTexSubImage2D, etc.), the modified image results will be observed by all
EGLImage siblings in all client API contexts.`

However, I can't find any language on when a modification to one target must become visible
to other targets.

E.g. a texture object shared between two GL contexts that aren't in the same share group via an EGL image export/import. While we can serialize access to the resource via the known EGL synchronization primitives, we can still effectively create the situation that is solved by `glTextureBarrier` by having a target bound for rendering in one context and have another target bound for sampling in the other context. Do we need to issue a texture barrier after the rendering command in one context and another texture barrier before sampling in the other context to make sure that render/sampler caches are flushed/invalidated so the changes become visible?

`OES_EGL_image_external` explicitly includes language to specify that modifications to the texture object must become visible at (re-)bind time:
`Sampling an external texture which has been modified since it was
bound will return samples which may correspond to image values either
before, during, or after the modification. Binding (or re-binding if
already bound) an external texture by calling BindTexture after all
modifications are complete guarantees that sampling done in future
draw calls will return values corresponding to the values in the
buffer at or after the time that BindTexture is called.`

There is no such language for non-external textures created via OES_EGL_image. So there is some ambiguity on when changes must be visible. Are `gltextureBarrier` and/or `glMemoryBarrier` the right primitives to enforce visibility of modifications, or is there any other way? What about GL/GLES contexts that don't implement those primitives?

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.