WebGPU Multiple windows sharing resources

49 views
Skip to first unread message

Robert Conde

unread,
Jan 7, 2020, 6:46:43 PM1/7/20
to Dawn Graphics
In WebGPU what is the model for sharing resources? Is it possible to have multiple scenes which share a texture object for example?

Thanks,
Rob Conde

Kai Ninomiya

unread,
Jan 7, 2020, 11:38:09 PM1/7/20
to Robert Conde, Dawn Graphics
WebGPU on the Web will support driving multiple <canvas> elements with a single WebGPU context ("device"). This will be the most efficient way to share resources between WebGPU devices. However, I don't think Chrome supports it just yet.

This is the Dawn mailing list (webgpu list here), so perhaps you're interested in driving multiple OS windows with one Dawn device. We haven't tried to do this, but I think it should be possible, at least on some OSes. If you are interested, I'd suggest diving into Dawn, as it is not on our priority list.

Dawn also supports importing resources from external objects, such as ID3D12Resource, Vulkan external images, MTLTexture, or IOSurfaceRef. However, it's probably much easier to use a single Dawn/WebGPU device to drive multiple windows if you're only interested in using Dawn, as it reduces the amount of platform specific code you would have to write.

Hope this helps!

--
You received this message because you are subscribed to the Google Groups "Dawn Graphics" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dawn-graphic...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dawn-graphics/b8ac857c-f6b6-44d0-81c0-01b8e42bc7fb%40googlegroups.com.

Stephen White

unread,
Jan 8, 2020, 10:39:29 AM1/8/20
to Kai Ninomiya, Robert Conde, Dawn Graphics
I've tried this in Dawn, and it seems to work on Mac/Metal and Linux/Vulkan. Haven't tried on D3D12.

You can even draw to both windows from the same CommandBuffer (with separate render passes, of course) submitted to a single Queue.

Stephen

Robert Conde

unread,
Jan 8, 2020, 11:29:28 AM1/8/20
to Dawn Graphics
Thanks for the answers!! All very useful information.


On Tuesday, January 7, 2020 at 11:38:09 PM UTC-5, Kai Ninomiya wrote:
WebGPU on the Web will support driving multiple <canvas> elements with a single WebGPU context ("device"). This will be the most efficient way to share resources between WebGPU devices. However, I don't think Chrome supports it just yet.

This is the Dawn mailing list (webgpu list here), so perhaps you're interested in driving multiple OS windows with one Dawn device. We haven't tried to do this, but I think it should be possible, at least on some OSes. If you are interested, I'd suggest diving into Dawn, as it is not on our priority list.

Dawn also supports importing resources from external objects, such as ID3D12Resource, Vulkan external images, MTLTexture, or IOSurfaceRef. However, it's probably much easier to use a single Dawn/WebGPU device to drive multiple windows if you're only interested in using Dawn, as it reduces the amount of platform specific code you would have to write.

Hope this helps!

On Tue, Jan 7, 2020 at 3:46 PM Robert Conde <needsmo...@gmail.com> wrote:
In WebGPU what is the model for sharing resources? Is it possible to have multiple scenes which share a texture object for example?

Thanks,
Rob Conde

--
You received this message because you are subscribed to the Google Groups "Dawn Graphics" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dawn-g...@googlegroups.com.

Dominic Cerisano

unread,
Jan 8, 2020, 6:47:49 PM1/8/20
to Dawn Graphics
The WebGPU API seems to be very closely modeled after Metal.
Dawn is a wrapper around Metal, Vulkan, DX12 etc.

The driving intent behind WebGPU seems to be multi-threaded compute functionality with minimal context switching overhead.
As per your question, multiple scenes sharing a single texture is essentially compute: equivalent to multiple threads (contexts) sharing a single buffer.

When diving into Dawn, it is perhaps better to view scenes and textures as specialized threads and buffers. Again, this seems to be the driving intent - to make graphics really just another application of compute.

Corentin Wallez

unread,
Jan 9, 2020, 9:36:50 AM1/9/20
to Dominic Cerisano, Dawn Graphics
On Thu, Jan 9, 2020 at 12:47 AM Dominic Cerisano <dcer...@gmail.com> wrote:
The WebGPU API seems to be very closely modeled after Metal.

WebGPU is at around the same level of abstraction as Metal but is designed by looking at D3D12, Metal and Vulkan and finding a portable way to target all three.
 
Dawn is a wrapper around Metal, Vulkan, DX12 etc.

The driving intent behind WebGPU seems to be multi-threaded compute functionality with minimal context switching overhead.
As per your question, multiple scenes sharing a single texture is essentially compute: equivalent to multiple threads (contexts) sharing a single buffer.

Not really, it's just that contrary to OpenGL, all other APIs see swapchains just as regular textures so there are no restriction to rendering multiple ones with the same device. This has nothing to do with compute but more about how the API is structured to not have a default framebuffer. The driving intent of WebGPU is to have a high-performance GPU API for the Web that exposes both graphics and compute functionality. 

When diving into Dawn, it is perhaps better to view scenes and textures as specialized threads and buffers. Again, this seems to be the driving intent - to make graphics really just another application of compute.


On Tuesday, January 7, 2020 at 6:46:43 PM UTC-5, Robert Conde wrote:
In WebGPU what is the model for sharing resources? Is it possible to have multiple scenes which share a texture object for example?

Thanks,
Rob Conde

--
You received this message because you are subscribed to the Google Groups "Dawn Graphics" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dawn-graphic...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dawn-graphics/72788a16-c543-44b8-8142-880005856a40%40googlegroups.com.

Dominic Cerisano

unread,
Jan 9, 2020, 4:22:27 PM1/9/20
to Dawn Graphics


On Thursday, January 9, 2020 at 9:36:50 AM UTC-5, Corentin Wallez wrote:
On Thu, Jan 9, 2020 at 12:47 AM Dominic Cerisano <dcer...@gmail.com> wrote:
The WebGPU API seems to be very closely modeled after Metal.

WebGPU is at around the same level of abstraction as Metal but is designed by looking at D3D12, Metal and Vulkan and finding a portable way to target all three.

Yeah, no its pretty much Metal - that is why it currently is only available on Safari and Chromium for OSX.  DX12 and Vulkan implementations are lagging!
 
 
Dawn is a wrapper around Metal, Vulkan, DX12 etc.

The driving intent behind WebGPU seems to be multi-threaded compute functionality with minimal context switching overhead.
As per your question, multiple scenes sharing a single texture is essentially compute: equivalent to multiple threads (contexts) sharing a single buffer.

Not really, it's just that contrary to OpenGL, all other APIs see swapchains just as regular textures so there are no restriction to rendering multiple ones with the same device. This has nothing to do with compute but more about how the API is structured to not have a default framebuffer. The driving intent of WebGPU is to have a high-performance GPU API for the Web that exposes both graphics and compute functionality. 

Yeah, no again. The whole point of WebGPU is compute. The G really stands for Generic. Rendering is just really just an application of compute, as it really always has been. That is why we are moving away from OpenGL - it is too specialized for generic compute. Anyone who has tried to do distributed compute tasks with WebGL knows the value and reason for WebGPU. is a distributed compute pipeline.
 

When diving into Dawn, it is perhaps better to view scenes and textures as specialized threads and buffers. Again, this seems to be the driving intent - to make graphics really just another application of compute.


On Tuesday, January 7, 2020 at 6:46:43 PM UTC-5, Robert Conde wrote:
In WebGPU what is the model for sharing resources? Is it possible to have multiple scenes which share a texture object for example?

Thanks,
Rob Conde

--
You received this message because you are subscribed to the Google Groups "Dawn Graphics" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dawn-g...@googlegroups.com.

Corentin Wallez

unread,
Jan 9, 2020, 4:31:48 PM1/9/20
to Dominic Cerisano, Dawn Graphics
On Thu, Jan 9, 2020 at 10:22 PM Dominic Cerisano <dcer...@gmail.com> wrote:


On Thursday, January 9, 2020 at 9:36:50 AM UTC-5, Corentin Wallez wrote:
On Thu, Jan 9, 2020 at 12:47 AM Dominic Cerisano <dcer...@gmail.com> wrote:
The WebGPU API seems to be very closely modeled after Metal.

WebGPU is at around the same level of abstraction as Metal but is designed by looking at D3D12, Metal and Vulkan and finding a portable way to target all three.

Yeah, no its pretty much Metal - that is why it currently is only available on Safari and Chromium for OSX.  DX12 and Vulkan implementations are lagging!
 
Check webgpu.io again :) It's available on Windows. Also it's kinda bold to make statements like "WebGPU is basically Metal" when half of the people designing WebGPU are in this mailing list and we know that statement is untrue.
 
Dawn is a wrapper around Metal, Vulkan, DX12 etc.

The driving intent behind WebGPU seems to be multi-threaded compute functionality with minimal context switching overhead.
As per your question, multiple scenes sharing a single texture is essentially compute: equivalent to multiple threads (contexts) sharing a single buffer.

Not really, it's just that contrary to OpenGL, all other APIs see swapchains just as regular textures so there are no restriction to rendering multiple ones with the same device. This has nothing to do with compute but more about how the API is structured to not have a default framebuffer. The driving intent of WebGPU is to have a high-performance GPU API for the Web that exposes both graphics and compute functionality. 

Yeah, no again. The whole point of WebGPU is compute. The G really stands for Generic. Rendering is just really just an application of compute, as it really always has been. That is why we are moving away from OpenGL - it is too specialized for generic compute. Anyone who has tried to do distributed compute tasks with WebGL knows the value and reason for WebGPU. is a distributed compute pipeline.

See comment above.
 

When diving into Dawn, it is perhaps better to view scenes and textures as specialized threads and buffers. Again, this seems to be the driving intent - to make graphics really just another application of compute.


On Tuesday, January 7, 2020 at 6:46:43 PM UTC-5, Robert Conde wrote:
In WebGPU what is the model for sharing resources? Is it possible to have multiple scenes which share a texture object for example?

Thanks,
Rob Conde

--
You received this message because you are subscribed to the Google Groups "Dawn Graphics" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dawn-g...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dawn-graphics/72788a16-c543-44b8-8142-880005856a40%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Dawn Graphics" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dawn-graphic...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dawn-graphics/10a3b9e0-c57a-4141-adec-91847fd69278%40googlegroups.com.

Dominic Cerisano

unread,
Jan 9, 2020, 9:20:45 PM1/9/20
to Dawn Graphics


On Thursday, January 9, 2020 at 4:31:48 PM UTC-5, Corentin Wallez wrote:
On Thu, Jan 9, 2020 at 10:22 PM Dominic Cerisano <dcer...@gmail.com> wrote:


On Thursday, January 9, 2020 at 9:36:50 AM UTC-5, Corentin Wallez wrote:
On Thu, Jan 9, 2020 at 12:47 AM Dominic Cerisano <dcer...@gmail.com> wrote:
The WebGPU API seems to be very closely modeled after Metal.

WebGPU is at around the same level of abstraction as Metal but is designed by looking at D3D12, Metal and Vulkan and finding a portable way to target all three.

Yeah, no its pretty much Metal - that is why it currently is only available on Safari and Chromium for OSX.  DX12 and Vulkan implementations are lagging!
 
Check webgpu.io again :) It's available on Windows. Also it's kinda bold to make statements like "WebGPU is basically Metal" when half of the people designing WebGPU are in this mailing list and we know that statement is untrue.

WebGPU essentially a wrapper around a subset of the Metal API, which you know is true, which makes it basically Metal.  The Windows implementation is marked as "In Progress" rather than "Available", also no benchmarks, so yeah.
 
Dawn is a wrapper around Metal, Vulkan, DX12 etc.

The driving intent behind WebGPU seems to be multi-threaded compute functionality with minimal context switching overhead.
As per your question, multiple scenes sharing a single texture is essentially compute: equivalent to multiple threads (contexts) sharing a single buffer.

Not really, it's just that contrary to OpenGL, all other APIs see swapchains just as regular textures so there are no restriction to rendering multiple ones with the same device. This has nothing to do with compute but more about how the API is structured to not have a default framebuffer. The driving intent of WebGPU is to have a high-performance GPU API for the Web that exposes both graphics and compute functionality. 

Yeah, no again. The whole point of WebGPU is compute. The G really stands for Generic. Rendering is just really just an application of compute, as it really always has been. That is why we are moving away from OpenGL - it is too specialized for generic compute. Anyone who has tried to do distributed compute tasks with WebGL knows the value and reason for WebGPU. is a distributed compute pipeline.

See comment above.

See comment above. 

When diving into Dawn, it is perhaps better to view scenes and textures as specialized threads and buffers. Again, this seems to be the driving intent - to make graphics really just another application of compute.


On Tuesday, January 7, 2020 at 6:46:43 PM UTC-5, Robert Conde wrote:
In WebGPU what is the model for sharing resources? Is it possible to have multiple scenes which share a texture object for example?

Thanks,
Rob Conde

--
You received this message because you are subscribed to the Google Groups "Dawn Graphics" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dawn-g...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dawn-graphics/72788a16-c543-44b8-8142-880005856a40%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Dawn Graphics" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dawn-g...@googlegroups.com.

Dominic Cerisano

unread,
Jan 9, 2020, 9:44:31 PM1/9/20
to Dawn Graphics


On Thursday, January 9, 2020 at 4:31:48 PM UTC-5, Corentin Wallez wrote:
On Thu, Jan 9, 2020 at 10:22 PM Dominic Cerisano <dcer...@gmail.com> wrote:


On Thursday, January 9, 2020 at 9:36:50 AM UTC-5, Corentin Wallez wrote:
On Thu, Jan 9, 2020 at 12:47 AM Dominic Cerisano <dcer...@gmail.com> wrote:
The WebGPU API seems to be very closely modeled after Metal.

WebGPU is at around the same level of abstraction as Metal but is designed by looking at D3D12, Metal and Vulkan and finding a portable way to target all three.

Yeah, no its pretty much Metal - that is why it currently is only available on Safari and Chromium for OSX.  DX12 and Vulkan implementations are lagging!
 
Check webgpu.io again :) It's available on Windows. Also it's kinda bold to make statements like "WebGPU is basically Metal" when half of the people designing WebGPU are in this mailing list and we know that statement is untrue.

It not "available" in any production browser on Windows, only "in progress" on an experimental Chrome Canary stream, and marked as "unsafe" even there. What do you know about that? Kind of bold to make statements like "It's available on Windows" when anyone reading this knows it is not :) Great work on Canary though. Could we get some official benchmarks for OSX vs WIN10? The Animometer benchmark would be a start, thanks.

 
Dawn is a wrapper around Metal, Vulkan, DX12 etc.

The driving intent behind WebGPU seems to be multi-threaded compute functionality with minimal context switching overhead.
As per your question, multiple scenes sharing a single texture is essentially compute: equivalent to multiple threads (contexts) sharing a single buffer.

Not really, it's just that contrary to OpenGL, all other APIs see swapchains just as regular textures so there are no restriction to rendering multiple ones with the same device. This has nothing to do with compute but more about how the API is structured to not have a default framebuffer. The driving intent of WebGPU is to have a high-performance GPU API for the Web that exposes both graphics and compute functionality. 

Yeah, no again. The whole point of WebGPU is compute. The G really stands for Generic. Rendering is just really just an application of compute, as it really always has been. That is why we are moving away from OpenGL - it is too specialized for generic compute. Anyone who has tried to do distributed compute tasks with WebGL knows the value and reason for WebGPU. is a distributed compute pipeline.

See comment above.
 

When diving into Dawn, it is perhaps better to view scenes and textures as specialized threads and buffers. Again, this seems to be the driving intent - to make graphics really just another application of compute.


On Tuesday, January 7, 2020 at 6:46:43 PM UTC-5, Robert Conde wrote:
In WebGPU what is the model for sharing resources? Is it possible to have multiple scenes which share a texture object for example?

Thanks,
Rob Conde

--
You received this message because you are subscribed to the Google Groups "Dawn Graphics" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dawn-g...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dawn-graphics/72788a16-c543-44b8-8142-880005856a40%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Dawn Graphics" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dawn-g...@googlegroups.com.

Kai Ninomiya

unread,
Jan 9, 2020, 11:18:01 PM1/9/20
to Dominic Cerisano, Dawn Graphics
On Thu, Jan 9, 2020 at 6:44 PM Dominic Cerisano <dcer...@gmail.com> wrote:
On Thursday, January 9, 2020 at 4:31:48 PM UTC-5, Corentin Wallez wrote:
On Thu, Jan 9, 2020 at 10:22 PM Dominic Cerisano <dcer...@gmail.com> wrote:
On Thursday, January 9, 2020 at 9:36:50 AM UTC-5, Corentin Wallez wrote:
On Thu, Jan 9, 2020 at 12:47 AM Dominic Cerisano <dcer...@gmail.com> wrote:
The WebGPU API seems to be very closely modeled after Metal.

WebGPU is at around the same level of abstraction as Metal but is designed by looking at D3D12, Metal and Vulkan and finding a portable way to target all three.

Yeah, no its pretty much Metal - that is why it currently is only available on Safari and Chromium for OSX.  DX12 and Vulkan implementations are lagging!
 
Check webgpu.io again :) It's available on Windows. Also it's kinda bold to make statements like "WebGPU is basically Metal" when half of the people designing WebGPU are in this mailing list and we know that statement is untrue.

It not "available" in any production browser on Windows, only "in progress" on an experimental Chrome Canary stream, and marked as "unsafe" even there. What do you know about that? Kind of bold to make statements like "It's available on Windows" when anyone reading this knows it is not :) Great work on Canary though.
 
To clarify, in Chrome on both macOS and Windows, WebGPU can be used only in Canary/Dev only (it is not present in Beta or Stable), is only available with an enabled "unsafe" flag, and is indeed still unsafe/insecure on both OSes.

So it is equally "available" on both macOS and Windows (regardless of your definition of "available").

That said, yes, you *can* generally expect the Metal implementation to be more stable: since Metal is higher level, our Metal backend has less required complexity and therefore is closer to final.
In addition, system integration (displaying images on the canvas) is simpler on macOS due to its graphics system architecture.

Could we get some official benchmarks for OSX vs WIN10? The Animometer benchmark would be a start, thanks.

There is a port of Animometer to WebGPU, which is linked from webgpu.io. YMMV: Right now, this is actually crashing on my machine (Chrome Canary 81.0.4022.0/macOS 10.14/Intel Iris Plus 655).
However I would not call it an "official" benchmark, given there is no "official" WebGPU API yet :)

On Thu, Jan 9, 2020 at 6:20 PM Dominic Cerisano <dcer...@gmail.com> wrote:
WebGPU essentially a wrapper around a subset of the Metal API, which you know is true, which makes it basically Metal.

That's more or less correct. However, it's also essentially a wrapper around a subset of Vulkan, and of D3D12. (Though, in some places, it's not a subset of Metal, Vulkan, or D3D12.)

The strongest resemblance is to Metal due to Metal's relative restrictiveness, WebGPU's higher-level nature relative to Vulkan, and D3D12's lack of features for tiling architectures until recently.

Just to clarify, WebGPU *did* previously refer to an API that *was* extremely similar to Metal. From Wikipedia (disclaimer, I wrote much of this):

> On February 7, 2017, Apple's WebKit team proposed the creation of the W3C community group to design the API. At the same time they announced a technical proof of concept and proposal under the name "WebGPU", based on concepts in Apple's Metal.[5][6][7] The WebGPU name was later adopted by the community group as a working name for the future standard rather than just Apple's initial proposal.[2] The initial proposal has been renamed to "WebMetal" to avoid further confusion.[8]
 
The Windows implementation is marked as "In Progress" rather than "Available", also no benchmarks, so yeah.

The Mac implementation is also marked as "In Progress."

The reason for this is that WebGPU is still constantly changing at the API level, the specification is only just started, and the conformance tests are only just started. They will be "in progress" until the API development is much closer to a stable 1.0 release.
 
Dawn is a wrapper around Metal, Vulkan, DX12 etc.

The driving intent behind WebGPU seems to be multi-threaded compute functionality with minimal context switching overhead.
As per your question, multiple scenes sharing a single texture is essentially compute: equivalent to multiple threads (contexts) sharing a single buffer.

Not really, it's just that contrary to OpenGL, all other APIs see swapchains just as regular textures so there are no restriction to rendering multiple ones with the same device. This has nothing to do with compute but more about how the API is structured to not have a default framebuffer. The driving intent of WebGPU is to have a high-performance GPU API for the Web that exposes both graphics and compute functionality. 

Yeah, no again. The whole point of WebGPU is compute. The G really stands for Generic. Rendering is just really just an application of compute, as it really always has been. That is why we are moving away from OpenGL - it is too specialized for generic compute. Anyone who has tried to do distributed compute tasks with WebGL knows the value and reason for WebGPU. is a distributed compute pipeline.

See comment above.

See comment above.

You're arguing that GPUs and GPU programming APIs have moved more toward general computing, and this is most certainly true. However, there is still a huge portion of the API which is dedicated to graphics features in particular, due to the presence of specialized graphics hardware, especially on older and lower-power-consumption GPUs.

There isn't a strong direct relationship between the generalization from GPU to GPGPU and the generalization from single-window to the possibility for zero-or-more windows per context. However, yes, both are informed by the increased flexibility of hardware after, say, circa 2000.

When diving into Dawn, it is perhaps better to view scenes and textures as specialized threads and buffers. Again, this seems to be the driving intent - to make graphics really just another application of compute.


On Tuesday, January 7, 2020 at 6:46:43 PM UTC-5, Robert Conde wrote:
In WebGPU what is the model for sharing resources? Is it possible to have multiple scenes which share a texture object for example?

Thanks,
Rob Conde

--
You received this message because you are subscribed to the Google Groups "Dawn Graphics" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dawn-g...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dawn-graphics/72788a16-c543-44b8-8142-880005856a40%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Dawn Graphics" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dawn-g...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dawn-graphics/10a3b9e0-c57a-4141-adec-91847fd69278%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Dawn Graphics" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dawn-graphic...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dawn-graphics/c9ba8761-f114-4a83-9cd3-89c1922a04d7%40googlegroups.com.

Dominic Cerisano

unread,
Jan 9, 2020, 11:28:52 PM1/9/20
to Dawn Graphics
Thank you very much for your considerate reply Mr. Ninomiya, it is as I thought.

I posted a couple of new topics concerning the Linux Chrome Canary protoype and also compatibility with webgpu for NodeJS, which just got a big push.

I am very grateful for the progress that has been made, as I am sure are many others who have been hoping for this kind of progress. 

Thanks again!

Reply all
Reply to author
Forward
0 new messages