Change the name of CreateReady*Pipeline to Create*PipelineAsync - #1336

The reason that this was not done originally is that it strongly implies that the non-async version of create*Pipeline are synchronous. They are not: both versions are asynchronous, it's just that only one tells you when it's ready.

Well, the regular createXxxPipeline is not more async than any other method we have. In fact, it's as if it's sync, so naming the alternative "async" still makes sense to me.

No resolution yet in the meeting. Still some feelings on both sides.

Editors discussion: I've made my peace with Create*PipelineAsync; I think it would be an okay name. In particular, it shouldn't be a detriment to use the Promise version if you can in the context, which makes it okay for developers who assume "async" is always better if they can use it in the context. (Though I'm a little worried about a developer refactoring to be able to use the "Async" version and that breaking their requestAnimationFrame because rAF won't wait for async.)

I think we should also consider (hopefully with input from engine developers) whether it would be more convenient to be able to get the GPU*Pipeline object immediately (e.g. to stow it off in an engine's Material object) even if waiting for compilation to complete. In that case, an API (proposed by Brandon I think) that simply adds a callback member to the pipeline descriptor (device.createRenderPipeline({ ..., onReady: () => ... })) would likely be preferable. Or alternatively an descriptor option which has create*Pipeline return a pair of e.g. [GPURenderPipeline, Promise<void>].

I think we should also consider (hopefully with input from engine developers) whether it would be more convenient to be able to get the GPUPipeline object immediately (e.g. to stow it off in an engine's Material object) even if waiting for compilation to complete. In that case, an API (proposed by Brandon I think) that simply adds a callback member to the pipeline descriptor (device.createRenderPipeline({ ..., onReady: () => ... })) would likely be preferable. Or alternatively an descriptor option which has createPipeline return a pair of e.g. [GPURenderPipeline, Promise].

I have concerns that this approach, like adding a .destroy() on the GPURenderPipeline object, will require us to add submit-time validation that the pipeline used by the command buffers are ready. The current Async version has been designed in such a way that the application cannot start using the pipeline before the object is ready.

I forgot to mention, I was intending that it would behave the same way as any other pipeline creation, in that it would block until the pipeline is ready (not fail validation). But Dzmitry wasn't sure about taking that approach.

I forgot to mention, I was intending that it would behave the same way as any other pipeline creation, in that it would block until the pipeline is ready (not fail validation). But Dzmitry wasn't sure about taking that approach.

I think this would be great. I prefer closer to a single codepath than multiple.

I forgot to mention, I was intending that it would behave the same way as any other pipeline creation, in that it would block until the pipeline is ready (not fail validation). But Dzmitry wasn't sure about taking that approach.

I think this would be great. I prefer closer to a single codepath than multiple.

Blocking if the pipeline isn't ready raises a lot of issues: when is the waiting done? If it's during command encoding then it reduces the usefulness of the asynchrony since it will be easy to make the GPU process silently block (or if we it makes command encoder creation asynchronous, it's even more complicated). If command encoding doesn't block on the pipeline creation then there are behavioral differences between the pipeline result being a success and an error, and whether it happened to be finished before encoding or not.

That's way I think the semantic that's currently in the spec is the correct one.

Editors resolution: Accept