Age | Commit message (Collapse) | Author |
|
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.
|
|
They are never used in practice, which makes all of our flag
handling effectively dead code. Also, APIs such as KMS don't
provide a good way to deal with the flags. Let's just fail the
DMA-BUF import when clients provide flags.
|
|
|
|
|
|
For `required` to disable search the value needs to be of `feature` type.
Checking `gles2` via `in` keyword returns a `bool` but `required: false`
makes the dependency optional instead of disabled.
|
|
calloc is moved to right before egl is called to avoid requiring to free()
unused memory.
Found via scan-build
|
|
Found via scan-build
|
|
There's no pkg-config file we can check for sadly, so check
vulkan/vulkan.h as a fallback.
Closes: https://github.com/swaywm/wlroots/issues/3272
|
|
Signed-off-by: Joshua Ashton <joshua@froggi.es>
|
|
This new renderer is implemented with the existing wlr_renderer API
(which is known to be sub-optimal for some operations). It's not
used by default, but users can opt-in by setting WLR_RENDERER=vulkan.
The renderer depends on VK_EXT_image_drm_format_modifier and
VK_EXT_physical_device_drm.
Co-authored-by: Simon Ser <contact@emersion.fr>
Co-authored-by: Jan Beich <jbeich@FreeBSD.org>
|
|
This allows us to obtain a new DRM file description without relying
on filesystem permissions.
|
|
If we aren't trying to create a dumb buffer allocator, and if the
DRM device has a render node (ie, not a split render/display SoC),
then we can use the render node instead of the primary node. This
should allow wlroots to run under seatd when the current user
doesn't have the permission to open primary nodes (logind has a
quirk to allow physically logged in users to open primary nodes).
|
|
This reverts commit 833437d5921339f2862ccfb0493617630ea3937d.
|
|
This reverts commit ea7357b70366588069c83f158e6a4eb2d3a702b3.
|
|
This reverts commit 780052d4da0c93f9210dd87d2100b116af7ff308.
|
|
This reverts commit 6d281d96cb93b8de972039d5cb00bfce49d9a58c.
|
|
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 allows callers to specify the operations they'll perform on
the returned data pointer. The motivations for this are:
- The upcoming Linux MAP_NOSIGBUS flag may only be usable on
read-only mappings.
- gbm_bo_map with GBM_BO_TRANSFER_READ hurts performance.
|
|
Makes it easier to find out which branch is taken when debugging
issues like [1].
[1]: https://github.com/swaywm/wlroots/issues/3156
|
|
Closes: https://github.com/swaywm/wlroots/issues/3156
|
|
Using the same DRM file description for the DRM backend and for the
GBM allocator will result in GEM handle ref'counting issues [1].
Re-open the DRM FD to fix these issues.
[1]: https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/110
|
|
This will be necessary for the next patch, to avoid messing up BO
handles shared between the GL implementation and the DRM backend.
|
|
Add render/allocator/ and include/render/allocator/ to hold
everything allocator-related.
|
|
|
|
Saves us from walking a list.
|
|
Add a bunch of new formats for Pixman: a few missing 32-bit ones,
some 16-bit and 32-bit formats as well.
Mostly based on a Weston patch [1].
[1]: https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/664
|
|
These will be added to Pixman in the next commit.
|
|
The half-float formats depend on GL_OES_texture_half_float_linear,
not just the GL_OES_texture_half_float extension, because the latter
does not include support for linear magni/minification filters.
The new 2101010 and 16161616F formats are only available on little-
endian builds, since their gl_types are larger than a byte and thus
endianness dependent.
|
|
This change introduces a new function to check whether the renderer
has the needed GL extensions to read a given pixel format.
|