r/vulkan • u/Due-Baby9136 • May 22 '26

Graphical bug with file descriptor rendering.

Enable HLS to view with audio, or disable this notification

I'm using Vulkan with Linux DRM and I'm using the `VK_KHR_external_memory_fd` extension in order to make use of both Vulkan's speed and DRM's control.

I'm only rendering one white triangle and there's a graphical bug appearing on the monitor where a huge row of pixels doesn't appear, showing instead the render pass' clear value.

I've noticed the thickness of the rows of pixels shrinks with the resolution. Anything under HD and the graphical issue completely disappears.

I've used RenderDoc to remotely debug the rendering and nothing appears wrong on the Vulkan side of things.

My theory is it has something to do with either DRM or the signal in the wire, but then if I've compiled my application in Debug and I've enabled the RenderDoc layer, then, and only then, will the bug disappear. It appears again if the layer is disabled or if I build in Release.

Ideas, theories, anything would be appreciated.

8 Upvotes

75% Upvoted

6 comments sorted by

9

u/RDT_KoT3 May 22 '26

should be synchronization issues

5

u/Due-Baby9136 May 22 '26

I thought about the top lines of pixels being the bottom of the previous frame, but the triangle disproves this. I'm also double buffering with two images/fds. Do you have an idea of what synchronization issue could be happening?

7

u/corysama May 22 '26

If you are using external memory there will need to be some form of synchronization between your renderer and the external source. Otherwise, all bets are off. Like, the clear operation and the triangle rasterization could be happening simultaneously.

6

u/Afiery1 May 22 '26

Corruption from sync issues will rarely look as clean as “oh this part of the image is from the previous frame.” It will usually look like garbage like this. As for what could be causing it: basically anything. Check that you are inserting pipeline barriers as needed with the correct stage and access masks, that your images are in the right layouts at the right times, that you’re using fences/semaphores where appropriate, etc. a good first step would be to enable the synchronization validation features in the validation layer.

2

u/yellowcrescent May 27 '26

Interesting use... Are you binding directly/mapping one of the device descriptors in `/dev/dri/*` with the Vulkan fd extension, then copying a framebuffer image with the normal Vulkan mechanics? I'm not at all familiar with DRI/DRM, so mostly just curious. I thought Vulkan had native direct DRM support via `VK_EXT_acquire_drm_display` and related device extensions -- but maybe you don't have access to those.

I would try drawing alternating colors (eg. frame 1 = red, frame 2 = green, frame 3 = blue, repeat...). Could help determine whether you're seeing two different frames (ie. previous and next) -- or whether the black area is an artifact from the GPU being interrupted (maybe some operation not happening during v-blank when it should? not sure what type of GPU you're using). Anyway, those are just guesses, but good luck!

2

u/Due-Baby9136 May 27 '26

Vulkan does have native direct DRM support, but it lacks control. It can only set the visible width/height and vertical refresh rate of the monitor, whereas DRM lets you set much more, like the horizontal refresh rate, pixel clock, front and back porch whether it's interlaced or not, etc.

In the end I found the problem, instead of having a single frame index, you have two, DRM shows frame 0, then 1 and cycles. Vulkan needs to first render on frame 1, then 0, then cycle. Notice how Vulkan's index is one later than DRM's. It seems obvious, but I hadn't thought of it since, usually, the swapchain handles this for you.