Return a texture instead of a view by the swapchain

[kvark]

As a follow-up to #88, we should start aligning this API closer to upstream.
Switching to a texture from a view is one such step.

typedef WGPUTextureView (*WGPUProcSwapChainGetCurrentTextureView)(WGPUSwapChain swapChain);

Should be:

typedef WGPUTexture (*WGPUProcSwapChainGetCurrentTexture)(WGPUSwapChain swapChain);

[Kangz]

Sounds good, we should also match the new merged GPUCanvasContent and GPUSwapChain by changing from creating a new swapchain on each configure to instead reconfiguring the same swapchain.

And also decide how to give signals about the swapchain being suboptimal / outdated.

[kainino0x]

I don't remember the exact rationale for returning texture views, but that's no longer a concern?
https://github.com/webgpu-native/webgpu-headers/pull/13/files#r336157359

[kvark]

It was me basically pushing for the views, that's all the reason it was. But it turns out, people do want to do more with swapchain images, even if it's slow.

[lisanlow]

Hi @kvark and @kainino0x, may I check with you if there has been any decision made on providing native API to return texture (instead of view) from the swapchain?
With reference to the discussion in this issue, is there any change in general direction to keep native API to be render-only?

I am currently working on a project where code is structured for primitives to be rendered to a texture followed by copying the texture to the swapchain for display on browser.
Existing wgpuCommandEncoderCopyTextureToTexture API supports only copying from texture to texture but not texture view.

[kainino0x]

I think we already decided to make this change, just no one has implemented it. But more than changing Texture to TextureView, we also wanted to change the swapchain interface to match more closely to the upstream API. Yet it hasn't been a priority for us (Chromium) to fix this because this isn't used when implementing the JS API on top of the C API.

[litherum]

Would be nice to have a resolution for this. We're running into it.

[Kangz]

I'm surprised you are running into it while implementing WebKit. Browsers need a lot more special logic to implement the GPUCanvasContext than what any reasonable WGPUSwapChain would give. For example on macOS my understanding is that the canvas textures are internally IOSurfaces that have been wrapped in an MTLTexture themselves wrapped in a GPUTexture. The browser compositor is in control of these IOSurfaces so they can't come from a WGPUSwapChain. Am I missing something? Happy to talk about it offline too if you'd like.

[tuankiet65]

Hi, I'm spearheading the effort to get GPUCanvasContext working in WebKit as part of my internship. You aren't missing anything - I'm following how WebGL is implemented in WebKit, which is "draw into an IOSurface then use that as the canvas content". This requires access to the IOSurfaces in the swap chain. At first, I tried to have to have the swapchain entirely within WGPUSwapChain and have private API to wrangle the IOSurface out of it. It worked but was super clunky, so right now I just moved the swap chain into WebKit itself.

One issue going down this path is that we need to extend the WebGPU texture creation API to optionally accept an IOSurface so we can create a texture out of it. If somebody else were to replace our WebGPU implementation with Dawn or wgpu, then it wouldn't work because Dawn/wgpu doesn't support that exact private API. I'm curious on how Chrome does it - does Chrome uses Dawn APIs that are not exposed through this header or not? (quick glance through the code says yes but I'm unsure)

[Kangz]

In Dawn / Chromium there are a number of private APIs that are used to create WGPUTextures from platform objects. For Metal/IOSurfaces, it would be WrapIOSurface. Note that you'll also need an equivalent of the function below it for proper ordering of Metal commands between parts of WebKit. The private APIs for other backends are in the same folder if you're interested.

In the future we could define webgpu.h APIs for platform texture import and export, but IMHO we should wait a little bit until all browsers have figured out how they want to do it. Otherwise we'll have extension we keep modifying as browser needs change.

[tuankiet65]

Note that you'll also need an equivalent of the function below it for proper ordering of Metal commands between parts of WebKit

Can you expand more on this?