| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
This makes grepping much easier.
|
|
Instead of returning a primary node from wlr_renderer_get_drm_fd(),
prefer to return a render node if any.
|
|
We've had this struct for a while. It'd be useful for compositors
if they want to manage the swap chains themselves instead of being
forced to use wlr_output's. Some compositors might also want to use
a swapchain without an output.
|
|
The Vulkan spec doesn't guarantee that the driver will wait for
implicitly synchronized client buffers before texturing from them.
radv happens to perform the wait, but anv doesn't.
Fix this by extracting implicit fences from DMA-BUFs, importing
them into Vulkan as a VkSemaphore objects, and make the render pass
wait on these VkSemaphores.
|
|
|
|
struct wlr_vk_format_props contains a mix of properties for shm
and dmabuf, and it's not immediately clear which fields are for
which kind of buffer. Use a nested struct to group the fields.
|
|
|
|
|
|
"format" is already in the name, no need to repeat ourselves.
`format->vk_format` sounds a bit redundant.
|
