Age | Commit message (Collapse) | Author |
|
No need to go back to the generic wlr_renderer/wlr_texture when
passing a Vulkan renderer/texture to an internal function.
|
|
We were checking whether any of the features was supported. We need
to check if all of them are.
This makes the check consistent with query_modifier_support() above.
|
|
We don't need to store the list of enabled extensions.
While at it, rename variables to be less confusing.
|
|
These are unused.
|
|
I think the second parameter of the function should be void* instead of
void **, because we use it as a right value in the function.
Signed-off-by: fakechen <chenzigui@kylinos.cn>
Signed-off-by: sunzg <sunzhigang1@kylinos.cn>
|
|
|
|
From a comment by emersion:
> There is a logic error here: we pass 0xFFFFFFFF to vulkan_find_mem_type, which
> returns an index, and then we logical-and that with mem_reqs.memoryTypeBits.
> Instead we should pass mem_reqs.memoryTypeBits to vulkan_find_mem_type and use
> the result for the memoryTypeIndex field directly. Ideally checking for errors
> (-1 return value) in case no memory type is suitable.
Closes: #3470
|
|
|
|
|
|
This lets the renderer handle the wlr_buffer directly, just like it
does in texture_from_buffer. This also allows the renderer to batch
the rectangle updates, and update more than the damage region if
desirable (e.g. too many rects), so can be more efficient.
|
|
GL_ALPHA_BITS is the number of bits of the alpha channel of the
currently bound frame buffer's color buffer -- which is precisely
renderer->current_buffer->rbo . Thus, instead of binding the color
buffer and checking its properties, we can query the already bound
frame buffer.
Note that GL_IMPLEMENTATION_COLOR_READ_{FORMAT,TYPE} are also
properties of frame buffer's color buffer.
|
|
|
|
Instead of checking whether the wlr_egl dependencies are available
in the GLES2 code, introduce internal_features['egl'] and check
that field.
When updating the EGL dependency list, we no longer need to update
the GLES2 logic.
|
|
The GLES2 renderer depends on EGL, which depends on GBM for device
selection.
|
|
Whether a texture is opaque or not doesn't depend on the renderer
at all, it just depends on the source buffer. Instead of forcing
all renderers to implement wlr_texture_impl.is_opaque, let's move
this in common code and use the wlr_buffer format to know whether
a texture will be opaque.
|
|
|
|
|
|
`vulkan_format_props_query` calls `query_modifier_support` which
initializes fields of `props` with allocated memory. this memory is
leaked if `query_modifier_support` does not find a supported format
and shmtex is not supported, as in this case `add_fmt_props` ends
up being false and the allocated fields of `props` are never freed.
|
|
69477051ccff ("matrix: deprecate wlr_matrix_projection") marked it
as deprecated. 1 year later, we can now remove it from our public
API.
|
|
Instead of computing the projection, then flipping, just provide
the correct transform to wlr_matrix_projection().
|
|
|
|
Replace them with wlr_signal_emit_safe, which correctly handles
cases where a listener removes another listener.
Reported-by: Isaac Freund <ifreund@ifreund.xyz>
|
|
Now that the DRM backend no longer depends on GBM, we can make it
optional. The GLES2 renderer still depends on it because of our EGL
device selection.
This is useful for compositors with their own renderers, and for
compositors using the Vulkan renderer.
|
|
This allows compositors to integrate with the wlroots GLES2
renderer, if they need to perform custom GL rendering.
|
|
These formats require EXT_texture_norm16, which in turn needs OpenGL
ES 3.1. The EXT_texture_norm16 extension does not support passing
gl_internalformat = GL_RGBA to glTexImage2D, as can be done for
formats available in OpenGL ES 2.0, so this commit adds a field to
wlr_gles2_pixel_format to provide a more specific internalformat
parameter to glTexImage2D.
|
|
Added the implement of wlr_texture_is_vk.
Fixes: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3419
|
|
Ensures there is no field left to its previous undefined value after
calling an init function.
|
|
|
|
The lease_fd is currently being leaked to child processes
Link: https://github.com/swaywm/sway/issues/4286#issuecomment-1065987957
|
|
Closes: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3389
|
|
This removes an artificial limitation in form of an assert that disallowed the
creation of textures while the renderer is rendering.
A consumer might run its own rendering pipeline and after start of the renderer
still want to create textures for internal usage.
|
|
This can be useful to figure out why a required feature is missing,
e.g. as in [1].
We check VK_EXT_physical_device_drm availability after printing
the driver name.
[1]: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3358
|
|
commit 44e8451cd93e ("render/gles2: hide shm formats without GL
support") added the is_gles2_pixel_format_supported() function to
render/gles2/pixel_format.c, whose stated purpose is to "check whether
the renderer has the needed GL extensions to read a given pixel format."
It then used that function to filter the pixel formats returned by
get_gles2_shm_formats().
The result of this change is that RGB formats are no longer reported for
GL drivers that don't implement EXT_read_format_bgra, even when those
formats are supported for rendering (which they have to be for
wlr_gles2_renderer_create() to succeed). This is a pretty clear
regression, since wlr_renderer_init_wl_shm() fails when either of
WL_SHM_FORMAT_ARGB8888 or WL_SHM_FORMAT_XRGB8888 are missing.
To fix the regression, change is_gles2_pixel_format_supported() to
accept all pixel formats that support rendering, regardless of whether
we can read them or not, and move the check for EXT_read_format_bgra
back into gles2_read_pixels(). (There's already a check for this
extension in gles2_preferred_read_format(), so we're not breaking any
abstraction that wasn't already broken.)
Tested on the NVIDIA 495.46 proprietary driver, which doesn't support
EXT_read_format_bgra.
Fixes: 44e8451cd93e ("render/gles2: hide shm formats without GL support")
|
|
|
|
This allows compositors to initialize wl_shm without initializing
other globals like linux-dmabuf.
|
|
This intersects two DRM format sets. This is useful for implementing
DMA-BUF feedback in compositors, see e.g. the Sway PR [1].
[1]: https://github.com/swaywm/sway/pull/6313
|
|
Support for EXT_image_dma_buf_import_modifiers doesn't necessarily
indicate support for modifiers. For instance, Mesa will advertise
EXT_image_dma_buf_import_modifiers for all drivers. This is a trick
to allow EGL clients to enumerate supported formats (something
EXT_image_dma_buf_import is missing). For more information, see [1].
Add a new wlr_egl.has_modifiers flag which indicates whether
modifiers are supported. It's set to true if any
eglQueryDmaBufModifiersEXT query returned a non-empty list.
Use that flag to figure out whether the buffer modifier should be
passed to the EGL implementation on import.
[1]: https://github.com/KhronosGroup/EGL-Registry/issues/142
|
|
The backends and allocators use INVALID, but the renderer uses
LINEAR. Running a compositor with WLR_RENDERER=pixman results in:
00:00:00.744 [types/output/render.c:59] Failed to pick primary buffer format for output 'WL-1'
|
|
This allows creating a wlr_egl from an already-existing EGL display
and context. This is useful to allow compositors to choose the exact
EGL initialization parameters.
|
|
The next commit will split extension lookup and context
initialization.
|
|
This was used to make the intersection of INVALID and LINEAR result
in LINEAR. We can now just require LINEAR to be in both lists.
|
|
|
|
See [1] for the motivation.
[1]: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/75
|
|
|
|
This env var allows to override the DRM node used by the GLES2 and
Vulkan renderers. It's especially useful to select a DRM node when
running with the headless backend.
References: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/2656
|
|
If the backend doesn't have a DRM FD, fallback to the renderer's.
This accomodates for the situation where the headless backend hasn't
picked a DRM FD in particular, but the renderer has picked one.
|
|
If the backend hasn't picked a DRM FD but supports DMA-BUF, pick
an arbitrary render node. This will allow removing the DRM device
selection logic from the headless backend.
|
|
This ends up being a horrible global load:
s_getpc_b64 s[4:5] // 000000000000: BE841C80
v_add_u32 v0, s2, v0 // 000000000004: 68000002
v_sub_co_u32 v1, vcc, 0, v0 // 000000000008: 34020080
v_max_i32 v1, v0, v1 // 00000000000C: 1A020300
v_and_b32 v1, 3, v1 // 000000000010: 26020283
v_cmp_lt_i32 s[0:1], v0, 0 // 000000000014: D0C10000 00010100
v_sub_co_u32 v0, vcc, 0, v1 // 00000000001C: 34000280
v_cndmask_b32 v0, v1, v0, s[0:1] // 000000000020: D1000000 00020101
v_lshlrev_b32 v1, 3, v0 // 000000000028: 24020083
v_mad_u32_u24 v0, v0, 8, 4 // 00000000002C: D1C30000 02111100
v_min_u32 v1, 32, v1 // 000000000034: 1C0202A0
v_min_u32 v0, 32, v0 // 000000000038: 1C0000A0
s_getpc_b64 s[0:1] // 00000000003C: BE801C00
s_add_u32 s0, s0, 0x0000003c // 000000000040: 8000FF00 0000003C
s_addc_u32 s1, s1, 0 // 000000000048: 82018001
global_load_dword v1, v[1:2], s[0:1] // 00000000004C: DC508000 01000001
global_load_dword v0, v[0:1], s[0:1] // 000000000054: DC508000 00000000
v_mov_b32 v2, 0 // 00000000005C: 7E040280
v_mov_b32 v3, 1.0 // 000000000060: 7E0602F2
s_waitcnt vmcnt(0) // 000000000064: BF8C0F70
exp pos0, v1, v0, v2, v3 done // 000000000068: C40008CF 03020001
exp param0, off, off, off, off // 000000000070: C4000200 00000000
s_endpgm // 000000000078: BF810000
v_cndmask_b32 v0, s0, v0, vcc // 00000000007C: 00000000
v_cndmask_b32 v0, s0, v0, vcc // 000000000080: 00000000
v_add_f16 v192, s0, v0 // 000000000084: 3F800000
v_cndmask_b32 v0, s0, v0, vcc // 000000000088: 00000000
v_add_f16 v192, s0, v0 // 00000000008C: 3F800000
v_add_f16 v192, s0, v0 // 000000000090: 3F800000
v_cndmask_b32 v0, s0, v0, vcc // 000000000094: 00000000
v_add_f16 v192, s0, v0 // 000000000098: 3F800000
v_cndmask_b32 v0, s0, v0, vcc // 00000000009C: 00000000
With some bit magic, we can get something much nicer:
v_add_u32 v0, s2, v0 // 000000000000: 68000002
v_add_u32 v1, 1, v0 // 000000000004: 68020081
v_and_b32 v1, 2, v1 // 000000000008: 26020282
v_cvt_f32_i32 v1, v1 // 00000000000C: 7E020B01
v_mul_f32 v1, 0.5, v1 // 000000000010: 0A0202F0
v_and_b32 v0, 2, v0 // 000000000014: 26000082
v_cvt_f32_i32 v0, v0 // 000000000018: 7E000B00
v_mul_f32 v0, 0.5, v0 // 00000000001C: 0A0000F0
v_mov_b32 v2, 0 // 000000000020: 7E040280
v_mov_b32 v3, 1.0 // 000000000024: 7E0602F2
exp pos0, v1, v0, v2, v3 done // 000000000028: C40008CF 03020001
exp param0, off, off, off, off // 000000000030: C4000200 00000000
s_endpgm // 000000000038: BF810000
The above output was based on just shoving it in ShaderPlayground -- I was not able to use pipeline feedback as I was unable to get RenderDoc working due to the EXT_physical_device_drm requirement.
I additionally considered using >> 1 instead of * 0.5, but AMD has dedicated modifiers to merge a * 0.5, * 2.0, etc in a single instruction. (Albeit, not taken advantage of in the code above, but might with ACO)
Signed-off-by: Joshua Ashton <joshua@froggi.es>
|
|
This suppresses the output filename printed to stdout. Errors and
warnings should still be printed to stderr as usual.
|
|
A wlroots user can easily get confused and think that `cap` refers to
wlroots buffer capabilities, not array capacity.
|