Confused by LoadOp, StoreOp

[Mark Sibly]

Hi,

Through a process of trial and error, I've found this works for my 'opaque' rendering pass (depth comparisons with depth updates):

m_colorAttachment.loadOp = wgpu::LoadOp::Clear;
m_depthAttachment.depthLoadOp = wgpu::LoadOp::Clear;
m_depthAttachment.depthStoreOp = wgpu::StoreOp::Store;
m_depthAttachment.depthReadOnly = false;

...while this works for my alpha blended rendering pass (depth comparisons only, no depth update)...

m_colorAttachment.loadOp = wgpu::LoadOp::Load;
m_depthAttachment.depthLoadOp = wgpu::LoadOp::Undefined;
m_depthAttachment.depthStoreOp = wgpu::StoreOp::Undefined;
m_depthAttachment.depthReadOnly = true;

But I'm a bit confused about a few things...

Why does depth buffering work on the opaque pass when depth LoadOp is 'clear', doesn't this mean the depth comparisons will always be comparing with the depth clear value?

The docs talk about 'loads the clear value into the renderpass' but what does 'into the renderpass' mean?!?

AFAICT, depth LoadOp = clear means 'clear before render pass' while depth LoadOp = load means 'don't clear before render pass'. In both cases
depth values can still be read (or 'loaded') from the depth value so why call it 'Load'?

In fact, why not just have a boolean clear and a boolean readonly for attachments? What am I missing here?

More questions but I suspect I'm gonna have an aha moment any time soon so I'll save myself even more future embarassment and leave it at that for now...

Bye!
Mark

[Corentin Wallez]

Hey Mark,

Note that if you use the C++ wrapper you don't need to set the ::Undefined values, they are set for you.

The mental model is that a render pass has a separate region of memory it uses to operate on attachment. That's how tiler GPUs work: they have a region of memory that's close to the ALUs and contains attachment data, so at the beginning of the render pass they need to initialize that region of memory either by loading from the attachment or clearing it to something, then at the end of the render pass they need to do something with the data, either discard it or store it to the attachment. That's why the spec says "load the value in the render pass" although it could be a bit more clear.

There are other loadOp and storeOp that could be added in the future, for example expanding the resolveTarget 1x MSAA to a 4x MSAA attachment, or something else so that's why it isn't booleans.

These old slides could maybe help explain in more detail.

Cheers,

Corentin

--
You received this message because you are subscribed to the Google Groups "Dawn Graphics" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dawn-graphic...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dawn-graphics/1efd2c29-9e0c-4620-863f-672f214c22ean%40googlegroups.com.

[Mark Sibly]

> The mental model is that a render pass has a separate region of memory it uses to operate on attachment

Thanks, exactly the info I was after, it all makes much more sense now...