Re: WebWorker and Device

crbug.com/new

Component: Blink>WebGPU if you can set it, but please just email me the bug
link once filed. Thanks!

On Sat, Apr 18, 2020, 3:12 PM Rob Conde <jaha84@gmail.com> wrote:

> Thanks for that clarification. Would it be useful for me to add an issue
> for the overhead? If so, which bug tracker would be appropriate.
>
> Rob
>
> On Apr 18, 2020, at 5:51 PM, Kai Ninomiya <kainino@google.com> wrote:
>
> 
> Yes, the spec will support single device with many workers and many
> canvases. The GPUDevice and other objects will be cloneable.
>
> But we do not have any support in Chrome yet for multiple workers, and for
> that matter I'm not sure if multi-canvas is tested, so we should test to
> make sure we don't break it.
>
> I'm surprised the per-device overhead is so high; I don't think it should
> be. I guess we have something else to investigate there.
>
> On Sat, Apr 18, 2020, 2:31 PM Robert Conde <jaha84@gmail.com> wrote:
>
>> Using chrome canary, I've been playing with using multiple webgpu
>> canvases in the same page. If I make a separate get adapter/device call for
>> each canvas it has a very high overhead (at least on Windows the gpu
>> process was 1.7 GB for 20 canvases each drawing a single triangle). Using a
>> single shared device across all canvases works and greatly alleviates the
>> problem.It also made initialization of each canvas significantly faster.
>>
>> As of now offscreen canvas support for webgpu is not implemented in
>> chrome (https://bugs.chromium.org/p/chromium/issues/detail?id=1064109).
>> However, I was setting up a demo just to confirm this was still broken and
>> to have a test to periodically try. I found that I would get a "GPUDevice
>> object could not be cloned." error trying to pass the GPUDevice to the
>> worker. The GPUDevice can't be passed to transfer because it's not
>> transferable (but this seemed like the wrong thing to do anyhow).
>>
>> So mainly what I'm trying to understand is whether sharing a single
>> device instance with multiple workers is meant to be supported somehow from
>> a webgpu perspective.
>>
>> Thanks,
>> Rob Conde
>>
>