-
Notifications
You must be signed in to change notification settings - Fork 43
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Swapchain / Surface questions #24
Comments
@rajveermalviya there are a few things left in this issue that I think are not answered by #203, you might be interested in trying to resolve them |
A note from the meeting:
|
Most of these have already been answered and implmented but coming back to it today,
Without changes in the header, we can't do more than returning null and log the error, or defer reporting error till surface configure. But if we do allow changes then:
Current webgpu.h doesn't expose swapchains anymore.
It's already in webgpu.h as
webgpu.h currently contains
Need more context here but in general, IMO prefer avoiding implicit behavior, but makes sense from webgpu POV. |
Nov 16 meeting:
|
I think this is sufficient since it should be possible to write a program that never hits an error condition. Maybe there can be dynamic errors but nullptr is probably enough for an application to know it needs to retry.
One note about this - in the JS API, to avoid breaking content, Regardless, we are likely to need some configurability here in the future that we don't have right now. If wgpu already wants to return srgb formats here (which differs from the JS API) then maybe we should make it configurable now so the default behavior can match. |
Additional question from #295
|
Could the supported usages ever change according to other settings, like which format/alphaMode/presentMode is used? Or should there be no additional restrictions over what the device can do (e.g. whether it has bgra8unorm-storage)? |
I can only see the format causing restrictions. My assumption is that we'd validate the combination for format + usage the same way we do it for regular textures. Note that neither D3D12 nor Metal have a query for what a swapchain can do, and that Vulkan has the query return the allowed usages independently from the formats. |
May 23 meeting (sorry for delay):
|
Jun 6 meeting:
|
I've started to implement swapchains in Dawn and ran into a bunch of questions.
Q: How do we report surface creation errors?
Tentative-A: We return a nullptr surface? But it doesn't allow reporting a string message to explain what went wrong. Alternatively surface creation can never go wrong and errors are always exposed when the swapchain is created on the surface.
Q: Can we have multiple swapchains on the same surface?
A: No, there is always a single current swapchain. Creating a new swapchain on the surface invalidates the previous one (this includes destroying the "current texture").
Q: Can we have subsequent swapchains on a surface be on different backends?
Tentative-A: No, it is a validation error. (this is to not deal with backend-compatibility stuff)
Q: Do we have the equivalent of
GPUCanvasContext.getPrefferredSwapChainFormat
?A: Maaaybe? But then is it synchronous or async? Or we could just have a list of formats that we guarantee always work (and do blits)?
Q: How do we handle window resizes and minimization?
A: No clue, Vulkan has the "outdated" swapchain concept, but there's no clear way to do this in webgpu.h that would also match the Web where the application sets the size of the canvas directly. Also we should take care on Windows, where Vulkan for example requires the size of the swapchain to match exactly the size of the window.
Q: Do we do things for the user like resize blits, format blits etc?
The text was updated successfully, but these errors were encountered: