Define conventions/rules for features that add new limits #4613
Conversation
|
Revised and ready for review, I think! |
|
@toji I did some rewriting, please take another look. Sorry it was messier than I realized before. |
GPU Web WG 2024-05-08 Pacific-time
|
This is useful for application code like this:
`{ requiredLimits: { someLimit: adapter.limits.someLimit } }`
in several situations:
- A limit was removed (gpuweb#4688)
- A limit exists in one browser, but another browser doesn't know about it
- Possibly, depending on future designs:
a limit is part of a feature, and the feature isn't available (gpuweb#4613)
3ed27ff to
a904b81
Compare
|
Previews, as seen when this build job started (82c2394): |
7a795db to
1599744
Compare
This is useful for application code like this:
`{ requiredLimits: { someLimit: adapter.limits.someLimit } }`
in several situations:
- A limit was removed (gpuweb#4688)
- A limit exists in one browser, but another browser doesn't know about it
(though it provides very limited protection against this)
- Possibly, depending on future designs:
a limit is part of a feature, and the feature isn't available (gpuweb#4613)
This is useful for application code like this:
`{ requiredLimits: { someLimit: adapter.limits.someLimit } }`
in several situations:
- A limit was removed (gpuweb#4688)
- A limit exists in one browser, but another browser doesn't know about it
(though it provides very limited protection against this)
- Possibly, depending on future designs:
a limit is part of a feature, and the feature isn't available (gpuweb#4613)
1599744 to
82c2394
Compare
This is useful for application code like this:
`{ requiredLimits: { someLimit: adapter.limits.someLimit } }`
in several situations:
- A limit was removed (gpuweb#4688)
- A limit exists in one browser, but another browser doesn't know about it
(though it provides very limited protection against this)
- Possibly, depending on future designs:
a limit is part of a feature, and the feature isn't available (gpuweb#4613)
|
how is this going? ATM chrome reports For example: device = await (await navigator.gpu.requestAdapter()).requestDevice();
console.log(device.limits.maxSubgroupSize); // prints 4294967295Like, if it reported zero then you could write code like adapter = await navigator.gpu.requestAdapter();
const requiredFeatures = [];
if (adapter.features.has('subgroups')) {
requiredFeatures.push('subgroups');
}
device = adapter.requestDevice({requiredFeatures});
...
if (device.limits.maxSubgroupSize > 0) {
// use subgroups
} |
For info, #4963 suggests we're adding new properties for adapter info, not limits for I agree though it would be nice to solve this issue regardless of subgroups. |
This question came up on #4963. I think there are two main possibilities when unsupported: undefined or default values. For subgroups, the default values make a lot of sense. I could envision that each feature might have a different answer though. So maybe the requirement is just that the getAdapterInfo() algorithm describes how the fields are populated when the feature is unsupported. |
|
For limits, IIRC this proposal is still what I want to do. However, we shouldn't try to figure this out until we actually have a feature that adds limits; subgroups will not. We should discuss what subgroups does with adapter properties on #4963 (sorry I have put off looking at it) |
|
Closing, no need for this right now. |
See the included design doc for the high-level explanation and worked case studies.
Came from this discussion on
clip-distances: #4588 (comment)