Age | Commit message (Collapse) | Author |
|
When importing a DMA-BUF wlr_buffer as a wlr_texture, the GLES2
renderer caches the result, in case the buffer is used for texturing
again in the future. When the wlr_texture is destroyed by the caller,
the wlr_buffer is unref'ed, but the wlr_gles2_texture is kept around.
This is fine because wlr_gles2_texture listens for wlr_buffer's destroy
event to avoid any use-after-free.
However, with this logic wlr_texture_destroy doesn't "really" destroy
the wlr_gles2_texture. It just decrements the wlr_buffer ref'count.
Each wlr_texture_destroy call must have a matching prior
wlr_texture_create_from_buffer call or the ref'counting will go south.
Wehn destroying the renderer, we don't want to decrement any wlr_buffer
ref'count. Instead, we want to go through any cached wlr_gles2_texture
and destroy our GL state. So instead of calling wlr_texture_destroy, we
need to call our internal gles2_texture_destroy function.
Closes: https://github.com/swaywm/wlroots/issues/2941
|
|
Make it so wlr_gles2_texture is ref'counted (via wlr_buffer). This
is similar to wlr_gles2_buffer or wlr_drm_fb work.
When creating a wlr_texture from a wlr_buffer, first check if we
already have a texture for the buffer. If so, increase the
wlr_buffer ref'count and make sure any changes made by an external
process are made visible (by invalidating the texture).
When destroying a wlr_texture created from a wlr_buffer, decrease
the ref'count, but keep the wlr_texture around in case the caller
uses it again. When the wlr_buffer is destroyed, cleanup the
wlr_texture.
|
|
This centralizes the wlr_texture initialization.
In future commits, more fields will need to get initialized.
|
|
We require the ext in the renderer init function.
|
|
The NULL check already exists in wlr_texture_destroy, no need to
duplicate it in each impl
|
|
|
|
The compositor shouldn't write to client buffers if the client
attaches a DMA-BUF to a wl_surface, then attaches a shm buffer.
Make gles2_texture_write_pixels return an error to prevent this
from happening.
|
|
This is unused in wlroots, and the use-cases for compositors are
pretty niche since they can access the original DMA-BUF via the
wlr_buffer.
|
|
|
|
|
|
|
|
|
|
If the stride is too small, the driver could end up segfaulting
(e.g. radeonsi segfaults in __memmove_sse2_unaligned_erms).
|
|
Mesa provides YUV shaders, and can import multi-planar YUV DMA-BUFs
as a single EGLImage. Remove the arbitrary limitation.
If the driver doesn't support importing YUV as a single EGLImage,
the import will fail and the result will be the same anyways.
|
|
Clamping texture coordinates prevents OpenGL from blending the left and
right edge (or top and bottom edge) when scaling textures with GL_LINEAR
filtering. This prevents visual artifacts like swaywm/sway#5809.
Per discussion on IRC, this behaviour is made default. Compositors that want
the wrapping behaviour (e.g. for tiled patterns) can override this by doing:
struct wlr_gles2_texture_attribs attribs;
wlr_gles2_texture_get_attribs(texture, &attribs);
glBindTexture(attribs.target, attribs.tex);
glTexParameteri(attribs.target, GL_TEXTURE_WRAP_S, GL_REPEAT);
glTexParameteri(attribs.target, GL_TEXTURE_WRAP_T, GL_REPEAT);
glBindTexture(attribs.target, 0);
|
|
It can be surprising and unexpected that texture operations (such as
texture upload and import) change the current EGL context, especially
when it's done under-the-hood by wlroots in response to wl_surface
requests.
To prevent surprises, save and restore the previous EGL context.
|
|
These aren't used anymore.
|
|
We implicitly depended on this extension.
|
|
Move the global into wlr_gles2_renderer. This removes global state and
allows us to have multiple renderers with different GL loaders.
|
|
|
|
|
|
These functions are unused by compositors (see e.g. [1]) and prevent
wlr_gles2_texture from accessing wlr_gles2_renderer state. This is an
issue for proper teardown [2] and for accessing GLES2 extensions.
[1]: https://github.com/swaywm/wlroots/pull/1962#issuecomment-569511830
[2]: https://github.com/swaywm/wlroots/pull/1962
|
|
EGL_EXT_image_dma_buf_import_modifiers tells us whether we should use
GL_TEXTURE_2D or GL_TEXTURE_EXTERNAL_OES. Using the right texture target
can fix some failures and/or improve performance on some drivers.
This does the same as a Weston commit [1].
[1]: https://gitlab.freedesktop.org/wayland/weston/commit/40c519a3e613
Closes: https://github.com/swaywm/wlroots/issues/2173
|
|
This function can be called after wlr_egl_make_current to cleanup the
EGL context. This avoids having lingering EGL contexts that make things
work by chance.
Closes: https://github.com/swaywm/wlroots/issues/2197
|
|
Instead of requiring compositors to call wlr_texture_get_size each time
they want to access the texture's size, expose this information as
wlr_texture fields.
|
|
Keeping textures bound results in hard-to-debug situations where some GL
operations incorrectly affect the texture.
|
|
Remove glapi.sh code generation, replace it with hand-written loading
code that checks extension strings before calling eglGetProcAddress.
The GLES2 renderer still uses global state because of:
- {PUSH,POP}_GLES2_DEBUG macros
- wlr_gles2_texture_from_* taking a wlr_egl instead of the renderer
|
|
This requires functions without a prototype definition to be static.
This allows to detect dead code, export less symbols and put shared
functions in headers.
|
|
Prior to this commit, compositors needed to render the texture to an
intermediate off-screen buffer using wlr_renderer APIs if they wanted to
use a custom rendering path (e.g. render to a 3D scene).
A new wlr_gles2_texture_get_attribs exposes the GL texture target and ID
so that compositors can render wlr_textures with their own shaders. An
example of a compositor doing so is available at [1].
[1]: https://git.sr.ht/~sircmpwn/wxrc/tree/3db905b7842ac42cf1878876e647005b41f00a52/src/render.c#L227
|
|
We don't need our own enum for types. Instead we just use
GL_TEXTURE_{2D,EXTERNAL_OES}, which already describes usage.
Also fixes a situation where we were using GL_TEXTURE_2D in a situation
we should not have. wl_drm buffers are always GL_TEXTURE_EXTERNAL_OES,
no matter if they're RGB or any other format.
|
|
When a texture is destroyed between wlr_egl_make_current and
wlr_egl_swap_buffers, it resets the current EGL surface to NULL. This
makes wlr_egl_swap_buffers fail.
If the EGL context is already current, there's no need to reset it.
|
|
|
|
Also rephrase the write_pixels comment.
|
|
It's not allowed to change the format of a texture so remove
the confusing parameter.
|
|
Texture functions, that create and manipulate textures should switch
the current context if necessary.
thanks to: @emersion
Fixes #934
|
|
|
|
|
|
|
|
|
|
|
|
|
|
It's possible to implement it outside the renderer, by creating a
texture and destroying it right away. This reduces the API surface
of the renderer.
|
|
|
|
|
|
|
|
|
|
|
|
This allows external renderers and potential future GL-based
renderers to re-use this function.
|
|
- Textures are now immutable (apart from those created from raw
pixels), no more invalid textures
- Move all wl_drm stuff in wlr_renderer
- Most of wlr_texture fields are now private
- Remove some duplicated DMA-BUF code in the DRM backend
- Add more assertions
- Stride is now always given as bytes rather than pixels
- Drop wl_shm functions
Fun fact: this patch has been written 10,000 meters up in the air.
|
|
|