Conversation
|
At least in Vulkan the sample count, the set of supported |
|
I'd like to be able to reason about the API orthogonally here, i.e. for a format - either it supports multisampling in general or not, and for the sample count - which are supported. But of course, the reality is more complicated. In D3D12, 128-bit formats may not support MSAA-8x, while other formats guarantee to support it. Concluding:
|
|
So what would this PR mean? That that sample count is supported for all formats? Or that it may be supported for any format? |
|
@kainino0x supported for all renderable formats |
|
I think that Vulkan and D3D12 might prevent such a semantic (apart for 1 and 4) |
|
@Kangz right, so with this semantic we'd expose:
This is not capturing the full extent of device capabilities, surely. We may need something more detailed, on a per-format basis. But I think this could be a good starting point until we get that more complicated solution in place. If we don't have that mask in the limit, we basically have no way at all to use multi-sampling. |
We do, WebGPU guarantees that a sample mask of 4 is allowed (except when explicitly disallowed for compressed and array textures). Am I missing something? |
We don't have that in the spec today. |
|
Marking as "needs investigation" for the limit that @Kangz mentioned about the total byte size of the exported pixel. My hope is that we can have that limit landing orthogonally from MSAA. |
|
Updated with the new limit that would let us expose DX12's MSAA capabilities. |
| The default limit supports MSAA levels of 4 and 1 (non-multisampled), resulting in the mask value of 5. | ||
|
|
||
| One mask is [=better=] than the other if it fully includes it. | ||
| : <dfn>maxTexelBlockSize</dfn> |
There was a problem hiding this comment.
| : <dfn>maxTexelBlockSize</dfn> | |
| : <dfn>maxTexelBlockSize</dfn> |
| One mask is [=better=] than the other if it fully includes it. | ||
| : <dfn>maxTexelBlockSize</dfn> | ||
| :: | ||
| Maximum size of a texel block that a texture can have. |
There was a problem hiding this comment.
| Maximum size of a texel block that a texture can have. | |
| Maximum size in bytes of a texel block that a texture can have. |
| GPUSize32 maxUniformBuffersPerShaderStage = 12; | ||
| GPUSize32 maxUniformBufferBindingSize = 16384; | ||
| GPUSize64 sampleCountMask = 5; | ||
| GPUSize64 maxTexelBlockSize = 64; |
There was a problem hiding this comment.
It would be good to have confirmation from the D3D12 and Metal team that this is the only additional restriction we can see in the future. Same thing for the Vulkan WG.
There was a problem hiding this comment.
Yesterday I suggested describing the limit this way in prose (or just not at all for now), but not exposing API surface for it in GPULimits. It doesn't serve any purpose until we have 8x MSAA (the largest texel block size we have right now is 4x rgba32float = 64 bytes). That way we can change how we describe it if needed.
There was a problem hiding this comment.
It's certainly not the only restriction. I need to see how to fit Metal in there...
|
@kvark Is this done? |
|
I think the consensus here is that we don't have a consensus for how to expose MSAA counts :) |
* Adds some device.destroy and lost tests. - Changes the tests to save the entire lost info interface instead of just the message so that we can identify the reason for device lost and suppress failures when tests expect devices to be destroyed. Issue: gpuweb/cts#882 * First round comment fixes/revisions. * Apply suggestions from code review Co-authored-by: Kai Ninomiya <kainino1@gmail.com>
4 participants
Related to the investigation in #108
We know that we can universally support MSAA x4, but we'd want to use higher levels if available, too.
This shouldn't be a portability concern, since most applications are written to support various sample counts, so they can trivially adjust to platforms that have different mask than the developers machine.
Preview | Diff