Subgroup limits aren't really limits
The subgroups proposal currently introduces new limits to the API for subgroups. These don't really fit the idea of limits since there isn't a clear definition of a better value.
Internally as we've been designing other possible features other values like this have emerged. There is an obvious analogy to properties in Vulkan. It is likely that other features will have values that programmers need to know about the device, but aren't configurable. Perhaps it would make sense to transition subgroups (or whichever feature that needs it comes first, or even the base API) to use properties instead.
Similar to limits this interface would be extended as new features are added to API.
cross-link to subgroups issue #4306
Yes, I agree we should add properties (as a separate concept from limits) as soon as we need them.
For info, webgpu.h has GPUAdapterProperties which were the previous names of GPUAdapterInfo: https://source.chromium.org/chromium/chromium/src/+/main:third_party/dawn/third_party/webgpu-headers/webgpu.h;l=1568;drc=8049c324dc7b3c09dc96ea04cb02860f272c8686 We may want to be careful about the naming to not confuse developers Maybe GPUAdapterSettings or GPUAdapterAttributes ?
I like "Properties" because that matches the naming in Vulkan. The webgpu.h concern is temporary and I don't think it will cause significant problems.