Age | Commit message (Collapse) | Author |
|
Since we only use the backend capabilities here we can simply pass
them in directly. This allows other locations to create an allocator
even if they don't have a backend. They can simply specify the caps
they want instead.
|
|
Some opaque pixel formats (nv12, p010) require per-plane bytes_per_block
info. However, it doesn't make sense to store them in
wlr_pixel_format_info, as they will never be useful (currently, this
info is used for shm, which doesn't have a concept of multi-planar
buffers.)
Let's define a separate array and function for determining whether a
pixel format has alpha.
|
|
This is the last of a set of commits which ensures that both textures
and render buffers can be accessed through _UNORM and _SRGB image
views. While _UNORM image views are not yet used for 8-bpc image
formats, they will be needed in the future to support color transforms
for both textures and render buffers.
|
|
|
|
|
|
Later commits will start using _SRGB image views again,
where appropriate.
|
|
|
|
|
|
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().
|
|
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
|
|
We can't do it while we're creating them because we'll want to use
gles2 buffers for textures soon.
|
|
|
|
Why track the alpha here when we can already get that information
elsewhere?
|
|
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.
|
|
All built-in renderers now implement the new API.
|
|
This commit only applies to the render pass API.
|
|
|
|
The flags passed to vkCreateImage() must match the flags used when
querying formats. Make this clearer by using the same variable.
|
|
|
|
Now that we are dynamically creating pipeline layouts, we need separate
texture views for each pipeline layout we choose to use with a texture.
|
|
These will happen lazily when pipelines get created.
|
|
This will become necessary when we switch away from scissoring. For the
time being, this cleans things up a bit and allows for a trivial
blending implementation for textures when that comes.
|
|
|
|
If we ever wanted to handle dynamic state that requires new pipelines
such as using different texture filters those can be added here with more
ease.
|
|
|
|
Closes: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3644
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Will make it easier to add more pipeline layouts for other YCbCr
formats.
|
|
This will make it easier to create one pipeline layout (plus related
objects) per YCbCr format.
|
|
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.
|
|
|
|
This is implemented by a two-subpass rendering scheme; the first
subpass draws (and blends) onto a linear R16G16B16A16_SFLOAT buffer,
while the second subpass performs linear->srgb conversion, writing
onto the actual output buffer.
|
|
Now it takes a reference to a destination format
|
|
|
|
|
|
|
|
|
|
This simplifies the vkQueueSubmit call, removing the need to pass
timeline semaphore point values as separate arrays.
|
|
|
|
This logic is used twice.
|
|
Add a render pass implementation which leverages the legacy
rendering API. This is helpful during the migration.
|