Age | Commit message (Collapse) | Author |
|
Replacement for wlr_gles2_renderer_get_current_fbo(). Wayfire uses
it for instance.
|
|
|
|
Sadly, the new API is not backwards compatible with the old API. Since
we have already switched all users in wlroots to the new API compositors
are already practically mandated to implement the new API. Let's get rid
of the old one since there is no point.
|
|
|
|
Also get rid of gles2_texture.owns_texture. We only use the tex/fbo
|
|
This is useful for e.g. lazily blitting a texture for readback
purposes while rendering.
|
|
These comments were a bit misleading:
- "GL_TEXTURE_2D == mutable": not really, imported non-external-only
DMA-BUFs would also use this target, but are not mutable.
- "Only affects target == GL_TEXTURE_2D": same here.
- "If imported from a wlr_buffer": not really, would be NULL if
imported from a shm wlr_buffer.
Adjust these comments to better reflect reality and adjust the check
in gles2_texture_update_from_buffer().
|
|
Let's us share more code with the other code path
|
|
Since wlr_gles2_buffer is now managing importing for us, there is
no reason for us to continue doing this.
|
|
We can get it from the buffer
|
|
We can double import a dmabuf if we use it as a texture target and
a render target. Instead, let's unify render targets and texture dmabuf
imports to use wlr_gles2_buffer which manages the EGLImageKHR
|
|
Since imported textures will be based off of gles2_buffer we have
to destroy textures first or else they will have an invalid reference
to the buffers they are imported from.
|
|
We can't do it while we're creating them because we'll want to use
gles2 buffers for textures soon.
|
|
|
|
If the external-only flag is set, then the EGLImage is only
supported for use with GL_TEXTURE_EXTERNAL_OES texture targets.
In particular, the EGLImage cannot be bound to a RBO.
|
|
Why track the alpha here when we can already get that information
elsewhere?
|
|
Many files used to require wlr_matrix but no longer do.
|
|
These aren't really tied to wlr_output.
|
|
|
|
Not needs set GL_DEPTH_TEST, Because when rendering to a framebuffer
that has no depth buffer, depth testing always behaves as though
the test is disabled, The initial value for each capability with
the exception of GL_DITHER is GL_FALSE.
|
|
|
|
Fixes: #3697
|
|
With this, errors should be properly wrapped in the debug scope.
|
|
Let's not allow renderer implementations to mutate the passed in
options.
|
|
This slightly improves type safety.
The culprits were found with:
git grep -E '\([a-z0-9_ ]+ \*\)\W?[a-z]'
|
|
We can just refer to the struct field here.
|
|
This is a bit more type-safe.
|
|
|
|
|
|
|
|
|
|
Based on five calls:
wlr_render_timer_create - creates a timer which can be reused across
frames on the same renderer
wlr_renderer_begin_buffer_pass - now takes a timer so that backends can
record when the rendering starts and finishes
wlr_render_timer_get_time - should be called as late as possible so that
queries can make their way back from the GPU
wlr_render_timer_destroy - self-explanatory
The timer is exposed as an opaque `struct wlr_render_timer` so that
backends can store whatever they want in there.
|
|
|
|
|
|
|
|
Avoids us needing to transpose.
|
|
Some formats like sub-sampled YCbCr use a block of bytes to
store the color values for more than one pixel. Update our format
table to be able to handle such formats.
|
|
Setting the GLESv2 parameter GL_PACK_ALIGNMENT to 1 ensures that the
stride of the glReadPixels output matches the value computed in
`pack_stride`. Since the default value of GL_PACK_ALIGNMENT is 4, this
does not make a difference under normal use; but without this patch
the stride can be incorrect; for example, with RGB565 buffers and
screenshots of regions with odd width.
|
|
The spec [1] says that the maximum value for a mediump float
is at least 2¹⁴ in section 4.5.2. However, when using a 4k
resolution texture coordinates will exceed this value. This causes
issues on drivers which implement mediump as a 16-bit [2].
Switch to highp. There's a twist: on GLES2, support for highp is
optional. So we need to guard it with cute GL_FRAGMENT_PRECISION_HIGH
ifdefs.
[1]: https://registry.khronos.org/OpenGL/specs/es/2.0/GLSL_ES_Specification_1.00.pdf
[2]: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21082
|
|
Doesn't matter a lot, but let's try to be consistent with the
GL headers.
|
|
|
|
We'll use this function from wlr_shm too.
Add some assertions, use int32_t (since the wire protocol uses that,
and we don't want to use 16-bit integers on exotic systems) and
switch the stride check to be overflow-safe.
|
|
Call glGetGraphicsResetStatusKHR in wlr_renderer_begin to figure
out when a GPU reset occurs. Destroy the renderer when this
happens (the OpenGL context is defunct).
|
|
Make it return a bool to indicate success/failure. Adapt the
various implementations to check errors.
|
|
|
|
The vertex shaders for quads and textures are identical.
|
|
We have no use for a v_color varying. We can use the uniform
directly from the fragment shader without getting the vertex shader
involved.
|
|
Instead of having a C file with strings for each shader, move each
shader into its own file. Use a small POSIX shell script to convert
the files into C strings (can't wait for C23 #embed...).
The benefits from this are:
- Improved readability and syntax highlighting.
- Line numbers in shader compiler errors are easier to make sense of.
- Consistency with the Vulkan renderer.
- Shaders will become more complicated as we add color management
features.
|
|
|
|
The target is set to GL_TEXTURE_EXTERNAL_OES when
EGL_EXT_image_dma_buf_import_modifiers [1] returns an external_only
flag. That spec states:
> In order to support imports for the GL_TEXTURE_EXTERNAL_OES target, a
> compatible OpenGL ES implementation supporting GL_OES_EGL_image_external
> must be present.
Fail hearder when a driver doesn't follow the spec instead of
skipping rendering.
See [2].
[1]: https://registry.khronos.org/EGL/extensions/EXT/EGL_EXT_image_dma_buf_import_modifiers.txt
[2]: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/3631#note_1584343
|