Way to check if device supports Persistent Threads

[atlv24]

Is your feature request related to a problem? Please describe.
Currently, we gate persistent threads usage by checking target != macos because mac does not support it. This misses some amd igpus that also do not support it, and presumably many other cases. We have no good way of actually checking support for this, and just get parent device lost errors when we use it on an unsupported platform.

Describe the solution you'd like
A wgpu Feature bit.

Describe alternatives you've considered
Maintaining a bunch of userspace platform conditionals.

Additional context
I have no idea if this is something a platform can check for, but we could at least make an attempt to build the list of checks somewhere everyone can contribute to and benefit from.

[SludgePhD]

How are you using persistent threads? WebGPU barriers never cross workgroup barriers, so cross-workgroup communication is not guaranteed to work by the specification. Does wgpu make more guarantees than the base spec here?

I don't think APIs currently support querying information about scheduling properties, but the work done in https://dl.acm.org/doi/10.1145/3485508 seems to suggest that all GPUs they tested have at least some fairness guarantees that can be relied on (and later required by specifications). What behavior are you relying on, exactly?

[cwfitzgerald]

don't think APIs currently support querying information about scheduling properties

Formally, all graphics apis do not guarantee forward progress and as such we can't offer it as a guarentee. In practice it seems like all desktop gpus outside of apple support it (edit: confirmed by the paper; qualcomm also doesn't support it).

[SludgePhD]

I'm fairly sure you can implement the persistent threads pattern under the OBE model investigated in the paper (but it requires dynamic occupancy detection). Apple and ARM do support that model, but not the stronger (and easier-to-use) LOBE, at least according to the paper.

The difference is that OBE guarantees fair scheduling of all threads that have started execution, while LOBE guarantees fair scheduling of all threads that have started execution and of all threads with a lower ID.

So I think the only missing link to get useful persistent threads working on Apple is the lack of inter-workgroup storage barriers in Metal, which are the reason WebGPU's barriers only have workgroup scope (gpuweb/gpuweb#2297). On non-Metal APIs those memory barriers would have to be added as an extension to make persistent threads work on wgpu.

[cwfitzgerald]

Yeah, so we'd need some kind of place to put advisory information - things we think are true about the adapters, but we can't guarentee. I agree this is something we likely should centralize the checks for, if only through the utils module.