feat(extensions/webgpu): swapchain support

[crowlKats]

No description provided.

[EnzoAlbornoz]

Fantastic work! Is there anything missing yet? Maybe I could help. I was trying to do something like this and I've found this PR.

[crowlKats]

@EnzoAlbornoz currently only the JS code is missing, but this where it gets tricky: we want to be web compatible, but the spec wasn't designed to work with native windowing, so we are waiting for discussion by the webgpu people in regards to this issue

[EnzoAlbornoz]

There already is a discussion opened in the WebGPU repository that I could track? Or we need to open it?

[crowlKats]

@EnzoAlbornoz webgpu-native/webgpu-headers#88

[EnzoAlbornoz]

This struct shouldn't be public? I mean, how can I integrate with Winit Window with this struct? When I tried to use the Winit window this error occurred:

error: Uncaught (in promise) BadResource: Bad resource ID

[EnzoAlbornoz]

I tried to use this implementation, but TypeId from dynamic load libraries is different.
Rc<WebGpuRawWindowHandle> in Deno binary -> 1254897155336868536
Rc<WebGpuRawWindowHandle> in Extension/Plugin lib -> 12790201640706278645

Because they have different ids, the resource table returns bad_resource_id.

There is some way to solve this? I'm trying to test this for more than two days

[lucacasonato]

There is some way to solve this? I'm trying to test this for more than two days

Yeah this is a limitation of Rust compilation. @eliassjogreen had some unsafe workaround for it via means of casts, but I don't remember what exactly.

[eliassjogreen]

Yes, the unsafe workaround is as follows:

  let resource_dyn = state
    .resource_table
    .get_any(args.rid)
    .ok_or_else(bad_resource_id)?;
  let resource_ptr = &resource_dyn as *const Rc<_> as *const Rc<WebGpuRawWindowHandle>;
  let resource = unsafe { &*resource_ptr };

It is however pretty safe because the ResourceTable is keyed by ResourceId instead of TypeId like GothamState is which means as long as you pass a valid window resource with the same internal types the TypeId shouldn't matter. The workaround is pretty much the same thing as ResourceTable::get does internally but without the TypeId check. Another solution could be using something like unique-type-id or checking TypeName instead of TypeId when downcasting in the ResourceTable.

[EnzoAlbornoz]

Yes, the unsafe workaround is as follows:

  let resource_dyn = state
    .resource_table
    .get_any(args.rid)
    .ok_or_else(bad_resource_id)?;
  let resource_ptr = &resource_dyn as *const Rc<_> as *const Rc<WebGpuRawWindowHandle>;
  let resource = unsafe { &*resource_ptr };

It is however pretty safe because the ResourceTable is keyed by ResourceId instead of TypeId like GothamState is which means as long as you pass a valid window resource with the same internal types the TypeId shouldn't matter. The workaround is pretty much the same thing as ResourceTable::get does internally but without the TypeId check. Another solution could be using something like unique-type-id or checking TypeName instead of TypeId when downcasting in the ResourceTable.

It worked!. But now I'm having the following problem:

• Window created
• Call to create surface (no panic) (execution stopped in instance.instance_create_surface)
• Window closes instantly (Using denosaurs/pane)

Anyone had this problem too?

[eliassjogreen]

I have played around with my module too and had the same problem, when looking at the exit code it usually exits with a segfault if I am not mistaken.

[stale]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.

[smolck]

Any plans to continue working on this in another PR, or what's the status here?

[crowlKats]

This is still stuck on webgpu-native/webgpu-headers#88

[chances]

Looks like there's progress on the blockers. 🎉 See webgpu-native/webgpu-headers#164

[DiThi]

This should be reopened. Progress is slow but there is progress. The stale bot only made this more difficult to find...

[itsjoekent]

Seems like it's merged?

webgpu-native/webgpu-headers#203