- Notifications
You must be signed in to change notification settings - Fork353
Limit for the sample count mask#932
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
base:main
Are you sure you want to change the base?
Uh oh!
There was an error while loading.Please reload this page.
Conversation
Kangz commentedJul 17, 2020
At least in Vulkan the sample count, the set of supported |
kvark commentedJul 17, 2020
I'dlike 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 formatsmay not support MSAA-8x, while other formats guarantee to support it. Concluding:
|
kainino0x commentedJul 20, 2020
So what would this PR mean? That that sample count is supported for all formats? Or that it may be supported for any format? |
kvark commentedJul 21, 2020
@kainino0x supported for allrenderable formats |
Kangz commentedJul 21, 2020
I think that Vulkan and D3D12 might prevent such a semantic (apart for 1 and 4) |
kvark commentedJul 21, 2020
@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. |
Kangz commentedJul 21, 2020
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? |
kvark commentedJul 21, 2020
We don't have that in the spec today. |
kvark commentedJul 28, 2020
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. |
kvark commentedSep 1, 2020
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
| :<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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
| Maximum size of a texel block that a texture can have. | |
| Maximum sizein bytesof 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
It's certainly not the only restriction. I need to see how to fit Metal in there...
kdashg commentedJul 30, 2021
@kvark Is this done? |
kvark commentedAug 4, 2021
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 reviewCo-authored-by: Kai Ninomiya <kainino1@gmail.com>
Uh oh!
There was an error while loading.Please reload this page.
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