Queue kinds and discovery #1306
Conversation
|
|
||
| <script type=idl> | ||
| dictionary GPUCommandEncoderDescriptor : GPUObjectDescriptorBase { | ||
| GPUQueueKind kind = "general"; |
There was a problem hiding this comment.
So we would have exactly one queue family of each type?
There was a problem hiding this comment.
Correct, yes. That matches D3D12, and I think it matches the Vulkan adapter geometry in practice, i.e. a recent AMD card has 1 general queue, one compute queue family with 2 queues, and 1 transfer queue family with 2 queues.
|
@kvak, the IPR bot complains because the Working Group just switched to the new Patent Policy, which means that you have to re-join the working group. |
| [SameObject] readonly attribute GPUAdapterFeatures features; | ||
| //readonly attribute GPULimits limits; Don't expose higher limits for now. | ||
|
|
||
| readonly attribute unsigned long computeQueueCount; |
There was a problem hiding this comment.
So the application doesn't opt-into having more queues, but just receives them, always? That a portability hazard and imho it should be something you request as part of device creation.
There was a problem hiding this comment.
Even better I think applications should just be able to request a compute or transfer queue, even if the system doesn't have one. The number of queues in the system would just be a hint (or would disappear to avoid fingerprinting).
@Kangz this is clearly a part of MQ story, and it's nice to discuss things with a semi-concrete proposal in mind, even if we decide that the whole MQ is delayed till after MVP or V1.
It's an interesting and complicated topic. Unlike the story with limits, the multiple queues can't be used "blindly". The developer always opts into them in code. How do you imagine developers using the API? Here is what I expect:
How many applications do you expect to just ask for one extra compute queue, for example, and not bother using more compute queues if available?
I think that ruins the explicit nature of MQ: the only reason we are trying to expose it is so the advanced users can benefit from it. If we do what you suggest, they don't really know if that queue is really a separate queue or just an useless API construct. |
Sure, what I'm meant is that we shouldn't land these as part of the spec until we decide we want MQ because otherwise, well, it is part of the spec and has to be implemented. I thought the
I expect most applications would use a single queue of each type, if they decide to use multiple queues. There isn't a lot of benefit to using multiple transfer queues, and all the engines I've heard using async compute do it on a single queue (even when AMD hardware has more than 1 compute queue). In a sense you get the most advantage from the first queue of a new type you use, with diminishing returns or even disadvantages when you use more due to the additional synchronization overhead.
It doesn't prevent the adapter from exposing whether the there are true compute and transfer queues in addition to the default queue and developers can use that data on the adapter to choose whether to use the MQ code path or not. Always allowing MQ even when the hardware doesn't have has several benefits:
|
|
Closing stale PR; we will revisit this as a proposal when we get to looking back at the |
This PR adds unimplemented stubs for the `acos` builtin. Issue: gpuweb#1212
Addresses one of the major blockers mentioned in #1298
Closes #1278
Related to #1169
This is a relatively basic proposal for exposing the queue families. Like D3D12, it associates queue classes to queue families (which are separate concepts in Vulkan), which simplifies our API without losing much power.
Note: the PR needs a few more words on validation, but I wanted to get feedback on the approach first.
Preview | Diff