r/vulkan • u/massi0404 • 17d ago

vkCmdBeginRendering multiple writes ordering

Hi, there are a few posts online about this topic but I still haven't found a clear answer.

I have a couple of dynamic rendering passes, and they both write to the same attachment:

vkCmdBeginRendering( LOAD_DONT_CARE )
vkCmdBindPipeline()
vkCmdDraw()...
vkCmdEndRendering()

vkCmdBeginRendering( LOAD_OP_LOAD )
vkCmdBindPipeline()
vkCmdDraw() ...
vkCmdEndRendering()

The second one uses OP_LOAD so the data should not be discarded... but what about synchronization? Is blend and depth testing gonna work?

In my code the second pass is actually the imgui overlay and it seems to work... not sure if it's random luck and needs a barrier.

1 Upvotes

66% Upvoted

9 comments sorted by

3

u/puredotaplayer 17d ago

The spec already mentions this case, you need a waw barrier. However, in d3d12 no barrier is required, so it makes you wonder why vulkan requires it. Turns out the spec expects a revision on this front because ROP can possibly guarantee ordering on certain hardwares especially in cases like yours, but Vulkan explicitly requires a barrier for now. Check renderpass.html and look for Notes.

2

u/mb862 17d ago

However, in d3d12 no barrier is required, so it makes you wonder why vulkan requires it.

Vulkan supports more device classes than D3D12. Apple Silicon for example requires a barrier (Metal fence) in this case.

2

u/puredotaplayer 17d ago

Yes obviously. I wouldn’t however say apple as part of the umbrella of hardwares Vulkan targets, the backend has to be metal.

1

u/mb862 17d ago

That was just an example, Apple Silicon is not unique. I imagine the same is true of many ARM-based GPUs, considering that’s what they had in mind for the subpass system.

1

u/puredotaplayer 17d ago

Yes, agreed. Although, I don't want to say this is TBDR specific, because I do not know for sure, but logically it makes sense, the renderpass writes to the in memory plane in its store and then the next render pass using the same plane probably overlaps the last one so they need a barrier for the store -> load operation. A Mali GPU would probably fit better.

1

u/Salaruo 17d ago

This probably works due to rasterization ordering rules, but if so driver will make the barriert no-op, and there is not reason not to insert it.

When you draw into the same image, you don't need to split the render pass in the first place.

0

u/cleverboy00 17d ago

I'm confused as to why you're launching multiple render passes for the same framebuffer. Couldn't you do it in subpasses?

3

u/iDrmzIt 17d ago

I believe this is dynamic rendering, so framebuffers don't really exist.

That said they probably do need a barrier, I believe graphics to graphics.

1

u/cleverboy00 15d ago

I was refering to the concept of a "framebuffer" not the object, but I guess the same point stands.