| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
|
|
This is always true now that we can only render with a buffer.
|
|
|
|
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?
|
|
It's possible that we don't have an EGLDevice if we created the
EGL context from a GBM device. Let's ensure all GPU-accelerated
renderers always have a DRM FD to return by falling back to GBM's
FD.
|
|
This was used by the legacy rendering API. Since begin()/end()
only need to set current_render_buffer and nothing else, we can
drop all of these bits.
|
|
Many files used to require wlr_matrix but no longer do.
|
|
These aren't really tied to wlr_output.
|
|
|
|
|
|
|
|
|
|
All built-in renderers now implement the new API.
|
|
When a texel from the Vulkan format VK_FORMAT_B8G8R8A8_SRGB is read,
the sRGB to linear conversion is applied independently to the R, G,
and B channels; the A channel has no influence on this. However,
DRM_FORMAT_ARGB8888 buffers are, per Wayland protocol, not encoded
in this fashion; one must first unpremultiply the color channels
before doing sRGB to linear conversion. This commit switches to
handling ARGB8888 and ABGR8888 formats using the general fragment
shader conversion from electrical to optical values.
|
|
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.
|
|
References: #3386
|
|
|
|
|
|
sRGB encoding/decoding needs to happen with straight alpha, not
pre-multiplied alpha.
|
|
When the backend and renderer would need GBM but it's disabled at
compile-time, log a message to make this situation easier to debug.
|
|
It can be a bit confusing to debug when the user requests an
explicit renderer but it's disabled at build-time. Log an error
when that happens.
|
|
This commit only applies to the render pass API.
|
|
Pixman won't be chosen by default if the system has a valid render node
but gles2 and vulkan creation failed.
|
|
|
|
|
|
|
|
Fixes: #3697
|
|
|
|
Specfically, VUID-vkCmdBlitImage-srcImage-00247.
|
|
The flags passed to vkCreateImage() must match the flags used when
querying formats. Make this clearer by using the same variable.
|
|
Ported from wlr_render_rect().
|
|
This optimization also fixes an validation error with the Vulkan
renderer by ensuring vkCmdClearAttachments does not receive empty
regions.
|
|
Only open a render node if we actually need one (ie, if we're about
to attempt GLES2 or Vulkan).
|
|
We could potentially leak a display here, but not really because the
display acts as a singleton that will be returned next time a renderer
of the same device is created.
|
|
Display is always NULL here since egl_init is always last to be called.
|
|
If the compositor were to try to handle a GPU reset within the lost
signal (by recreating the renderer) we should avoid referencing renderer
resources after the lost signal. This prevents use after free for such
compositors.
|
|
|
