You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now we have tables of texture format info that include both static info (like block sizes) and device-dependent info (like whether bgra8unorm can be used as storage - #3847). In the static tables, the capability info is that for a "base" device (no device descriptor).
I am not exactly sure how to do this - it requires passing a device in order to get data out of the table, but right now we're depending heavily on typescript to do nice type narrowing things when we access the table.
I was going to do this as a followup to #2495 but it seems I never filed it separately.
The text was updated successfully, but these errors were encountered:
Note that just device is often not sufficient given that compat/non-compat is only passed in on the adapter
So far, if the query needs to know compat/core then I've had a required bool argument that you must pass in to try to make it clear it's compat/core dependent.
We should probably try to fix that in the compat proposal - GPUDevice has features and limits so it should also have a way of determining it's compat - either a boolean, or the lack of a 'everything-from-compat-to-core' feature.
Right now we have tables of texture format info that include both static info (like block sizes) and device-dependent info (like whether bgra8unorm can be used as storage - #3847). In the static tables, the capability info is that for a "base" device (no device descriptor).
I am not exactly sure how to do this - it requires passing a device in order to get data out of the table, but right now we're depending heavily on typescript to do nice type narrowing things when we access the table.
I was going to do this as a followup to #2495 but it seems I never filed it separately.
The text was updated successfully, but these errors were encountered: