[Discussion] Getting rid of GLX

[9ary]

I've noticed your notes on trying out Vulkan and EGL. Here are my personal findings on the matter.

The DRI3 extension can export X Pixmaps as kernel dma-buf objects. This is very useful, as you can use a pair of extensions in EGL and Vulkan to import those objects and use them for texturing. This is the same mechanism that is used by PRIME for multi-GPU systems (eg integrated + discrete graphics) to share buffers between devices, and by Wayland for both multi-GPU support and compositing.

Unfortunately NVIDIA's proprietary driver does not support dma-buf (for licensing reasons), so DRI3 is not available either on that driver. They do support another, standard, EGL_KHR_stream extension which is completely different. I don't know if that can be used to export X11 Pixmaps in the same way. All relevant DRM-based (i915/i965, radeon/amdgpu, nouveau) drivers support dma-buf and DRI3. It's not clear whether they support EGL_KHR_stream. This is a problem for Wayland compositors as well, as it requires a lot of duplicate effort to support both extensions, and most of them have decided not to support the proprietary driver at all.

Things apparently look a little better for Vulkan, but I'm not entirely sure if that helps us at all on X.

Relevant extensions:

• EGL_EXT_image_dma_buf_import / EGL_EXT_image_dma_buf_import_modifiers
• VK_EXT_external_memory_dma_buf / VK_EXT_image_drm_format_modifier

[yshui]

Thanks, this is very useful.

[yshui]

This is a problem for Wayland compositors as well

Right, I remember there was some controversy regarding the EGLStream extension. I don't think it is implemented by any of the open source drivers.

[clapbr]

There is this https://github.com/ilia-glushchenko/VulkanCompositor but I couldnt make it work yet, its really new

[9ary]

It looks like there isn't even any X code or proper rendering in there yet.

[yshui]

I think that probably isn't meant to be a X compositor.

[clapbr]

https://cgit.kde.org/kwin.git/log/?h=fredrik/vulkan - kwin vulkan initial work, looks abandoned but might be useful

[9ary]

Ah yes I remember that being a thing. I'll check out how it works.

[9ary]

This isn't directly relevant, it would maybe make writing a Vulkan renderer a little easier, but it's not very likely to change the initial problem which is gaining meaningful access to the framebuffer of other applications.

[clapbr]

another project to borrow ideas from https://www.phoronix.com/scan.php?page=news_item&px=Chamferwm-Vulkan-WM

[absolutelynothelix]

https://github.com/absolutelynothelix/picom/issues/1

let's see how it'll go.

[absolutelynothelix]

after a few weeks of work and about 1500 lines of code there is a somewhat initial vulkan backend implementation. currently it's only capable of alpha blending and somewhat vsync, asking it for more will likely result in a segfault. if someone wants to try to run it there is a recommended scenario:

git clone https://github.com/absolutelynothelix/picom.git picom-vulkan
cd picom-vulkan
git checkout vulkan
git submodule update --init --recursive
CFLAGS=-DDEBUG_VULKAN_BACKEND meson setup --buildtype=debug build
ninja -C build
build/src/picom --config=/dev/null --backend=vulkan --log-level=INFO

use with A LOT OF care, it's very fragile :)

random devlogs are still available at absolutelynothelix#1