hyprwm
/
wlroots-hyprland
mirror of https://github.com/hyprwm/wlroots-hyprland.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
7,014 Commits 3 Branches 0 Tags 13 MiB
Commit Graph

175 Commits

Author SHA1 Message Date
David96 dce1372e35 render/vulkan: Implement vulkan_read_pixels 2022-10-07 15:59:39 +00:00
Simon Ser 6832ae14aa render: drop wlr_renderer_read_pixels() flags 
These are unused.
 2022-10-04 09:15:19 +02:00
Simon Ser e4efb6b601 render/vulkan: use addon for wlr_vk_texture 
Avoids having to walk the list of all textures.
 2022-09-30 14:02:51 +00:00
Simon Ser 7899b97d20 render/vulkan: use addon for wlr_vk_render_buffer 
Avoids having to walk the list containing all of the render buffers.
 2022-09-30 14:02:51 +00:00
Simon Ser 8d6d2101bc render/vulkan: add error handling for vulkan_find_mem_type() 
The function returns -1 if it doesn't find a suitable memory type.
 2022-09-19 10:33:29 +00:00
Simon Ser bca60c4eec render/vulkan: improve format logging 2022-09-14 12:13:48 +02:00
Simon Ser 8026953df7 render/vulkan: remove unnecessary casts 
No need to go back to the generic wlr_renderer/wlr_texture when
passing a Vulkan renderer/texture to an internal function.
 2022-09-07 14:00:46 +00:00
Simon Ser 30769723c1 render/vulkan: fix format features check for shm textures 
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.
 2022-09-07 15:46:38 +02:00
Simon Ser ed018a3ee2 render/vulkan: drop wlr_vk_device.extensions 
We don't need to store the list of enabled extensions.

While at it, rename variables to be less confusing.
 2022-09-07 14:41:40 +02:00
Simon Ser e19007dede render/vulkan: drop ext params from vulkan_device_create() 
These are unused.
 2022-09-07 14:39:58 +02:00
Bernardo Meurer eee0f5e71f
render/vulkan: fix memory type detection 
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
 2022-08-28 16:32:09 -03:00
Simon Ser 98cf38601f render: replace wlr_texture_write_pixels with update_from_buffer 
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.
 2022-08-12 08:41:32 +00:00
Simon Ser 29291cb47c render/texture: drop wlr_texture_is_opaque 
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.
 2022-06-16 14:43:24 +02:00
bi4k8 f295aff762 Add missing & 2022-06-11 20:41:16 +00:00
bi4k8 35d1bcff6f render/vulkan/pixel_format: do not leak props->... 
`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.
 2022-06-11 20:25:35 +00:00
Simon Ser 96b594110d matrix: remove wlr_matrix_projection() 
69477051cc ("matrix: deprecate wlr_matrix_projection") marked it
as deprecated. 1 year later, we can now remove it from our public
API.
 2022-06-08 19:27:36 +00:00
zccrs 48c811ffb6 render/vulkan: fix undefined reference to wlr_texture_is_vk 
Added the  implement of wlr_texture_is_vk.

Fixes: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3419
 2022-05-01 14:46:18 +08:00
Simon Ser d8d30463ac render/vulkan: log physical device driver name 
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
 2022-01-19 13:08:46 +01:00
nyorain 9988eb3378 vulkan: Fix imported image layout 2021-12-26 13:21:54 +01:00
Joshua Ashton f132d66816 render/vulkan: Optimize vertex shader 
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>
 2021-11-23 15:46:24 +00:00
Simon Ser 5332935afc render/vulkan: quiet glslangValidator 
This suppresses the output filename printed to stdout. Errors and
warnings should still be printed to stderr as usual.
 2021-11-23 15:38:56 +00:00
Simon Ser a04cfca4da Remove support for DMA-BUF flags 
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.
 2021-11-17 16:12:59 +00:00
Simon Ser 36cf387427 render/vulkan: check vulkan-headers dependency 
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
 2021-10-19 06:51:14 -06:00
Joshua Ashton b62ce3c3c8 render/vulkan: Use image view swizzles instead of shader hack 
Signed-off-by: Joshua Ashton <joshua@froggi.es>
 2021-10-18 15:57:46 +02:00
nyorain 8e34692250 render/vulkan: add Vulkan renderer 
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>
 2021-10-18 11:51:13 +02:00