Skip to content
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

WebGPU Support #6443

Closed
36 of 38 tasks
sebavan opened this issue Jun 4, 2019 · 53 comments
Closed
36 of 38 tasks

WebGPU Support #6443

sebavan opened this issue Jun 4, 2019 · 53 comments
Assignees
Labels
enhancement in progress Someone is currently working on this issue rendering engine WebGPU
Milestone

Comments

@sebavan
Copy link
Member

sebavan commented Jun 4, 2019

Here is the work which will happen until the release regarding our the WebGPU support:

  • Shader Auto Upgrade:
    • Create Processor
    • Auto attribs upgrade
    • Auto varyings upgrade
    • Auto textures upgrade
    • Auto uniforms upgrade
    • Auto UBOs detection
    • Binding Upgrades
    • Manage UBO in vertex + fragment
    • Manage Array in UBOs for bones
    • Manage Array in UBOs for morph targets
  • Manage Texture Sampling Modes
  • Manage Blending
  • Handle Canvas Resizing
  • Update WebGPU.d.ts
  • GLB support
  • Fix Full Build
  • Playground support
    • Merge in Master
  • Dynamic Materials -> Defines Changes
  • Texture Support without WebGL back-end
  • Mapped Buffers
  • Render target support
  • Post Process support
  • First Cleanup and TODO WEBGPU pass
  • Raw Textures
  • Dynamic Texture Sampler Setting -> Filtering and Wrapping
  • Safari Preview Support (if shader choice has been made Support for WebGPU on Safari tech preview.. #6695) (Not ready)
  • Compute Shader support
  • Support all the left over states (clear, stencil, depth, culling...)
  • Transform feedback and Occlusion Queries
  • Optimize uniform buffers and groups (dynamic buffer index)
  • Big Cleanup, tests, and docs
  • Command buffer "Reuse-Like" mechanism
  • Spector.js Support
  • Last Optimization phase
  • Optimize UBOs (like IBL/Scene and so on)
  • ** Release \o/**

If you are interested to contribute one of them, no problem, I am all about sharing ;-)

@sebavan sebavan added enhancement rendering engine in progress Someone is currently working on this issue WebGPU labels Jun 4, 2019
@sebavan sebavan added this to the 4.1 milestone Jun 4, 2019
@sebavan sebavan self-assigned this Jun 4, 2019
@furcatomasz
Copy link

is it (list) already up to date?

@sebavan
Copy link
Member Author

sebavan commented Aug 5, 2019

Yep, I am almost ready to post the shader conversion which will enable most of our webgl shaders to be compatible. As soon as it is done I will finally be able to create a playground for WebGPU.

@sebavan
Copy link
Member Author

sebavan commented Aug 6, 2019

It is definitely getting there despite a still growing list of todos:
image

@sebavan
Copy link
Member Author

sebavan commented Aug 7, 2019

Playground for WebGPU (requires Chrome Canary with the flags turned on on MacOS)

https://playground.babylonjs.com/indexWebGPU.html

Lots of features are preventing a lot of PGs to run correctly but if you only use Mesh with materials and simple textures (jpg/png) it should be all good :-)

@davidworkman9
Copy link

@sebavan any chance you'd be able to release a NPM version with this? I'd love to try it out in the context of my current project.

@sebavan
Copy link
Member Author

sebavan commented Aug 7, 2019

No, unfortunately, it is currently too early too release to npm. I plan to do it once I can merge in master after the WebGPU group decides what shader language that want to use :-)

You can nevertheless consume the file from the cdn : https://playground.babylonjs.com/js/babylonWebGpu.max.js

@sebavan
Copy link
Member Author

sebavan commented Aug 7, 2019

Custom shaders working back : https://www.babylonjs-playground.com/indexWebGPU.html#XEU8N9#1

@sebavan
Copy link
Member Author

sebavan commented Aug 8, 2019

With now support for the inspector and the node Material with its awesome editor:
https://playground.babylonjs.com/indexWebGPU.html#TY9I71

@BabylonJS BabylonJS deleted a comment Aug 22, 2019
@cx20
Copy link
Contributor

cx20 commented Nov 10, 2019

Since the specification of WebGPU has been changed recently, it seems that an error occurs when Playground is run on Canary version of Chrome.
https://github.com/gpuweb/gpuweb/commits/master/spec/index.bs
https://github.com/chromium/chromium/commits/master/third_party/blink/renderer/modules/webgpu

@sebavan
Copy link
Member Author

sebavan commented Nov 10, 2019

This is weird i fixed it on Thursday to adapt to latest setVertexBuffer. Are you on latest canary ?

@cx20
Copy link
Contributor

cx20 commented Nov 10, 2019

I tried the WebGPU sample and Babylon.js Playground with the following browser versions.

browser version WebGPU Samples Babylon.js Playground WebGPU
Chrome Canary Chrome/80.0.3964.0
Edge Canary Chrome/80.0.3956.0

WebGPU Samples seems to have been updated on 11/9.
https://github.com/austinEng/webgpu-samples/commits/master/src/examples

old name new name
vertexInput vertexState
stride arrayStride
attributeSet attributes

@sebavan
Copy link
Member Author

sebavan commented Nov 10, 2019

Ok i ll fix it tomorrow :-) thanks for the report

@sebavan
Copy link
Member Author

sebavan commented Nov 12, 2019

All fixed on Chrome Canary, we ll have to wait for Edge Canary to reach Chrome latest changes.

@cx20
Copy link
Contributor

cx20 commented Nov 14, 2019

Unfortunately, the latest version of Chrome Canary seems to have errors in Babylon.js Playground.

browser version WebGPU Samples Babylon.js Playground WebGPU
Chrome Canary Chrome/80.0.3968.0
Chrome Canary Chrome/80.0.3967.0
Chrome Canary Chrome/80.0.3966.0
Edge Canary Chrome/80.0.3966.0
BJS - [21:35:31]: Babylon.js v4.1.0-beta.2 - WebGPU engine
D3D12 closing pending command list failed with -2147467259
WebGL: CONTEXT_LOST_WEBGL: loseContext: context lost

[2019.11.16] The status has been updated because the sample is now working in Edge Canary.

@deltakosh
Copy link
Contributor

cc @sebavan

@sebavan
Copy link
Member Author

sebavan commented Nov 14, 2019

It works for me
image

It might be only on your GC and is not (I do not think) related to Babylon directly. You might try to provide your info on a chromium bug report for Windows. Please also disable the skia composition in your chrome flags to run WebGPU on Windows at the moment.

@cx20
Copy link
Contributor

cx20 commented Nov 14, 2019

I tried both enable / disable skia composition settings, but the problem was not solved.
image
I am using ThinkPad X260's built-in GPU (Intel HD Graphics 520). I don't have any other environment to try, so I'll wait for a little more time for the new Chrome Canary.
I also reported the problem in the Chromium bug report.

@sebavan
Copy link
Member Author

sebavan commented Nov 18, 2019

Heads up as I will update the apis tomorrow due to a rename in the spec so you can expect Chrome canary to be ok tomorrow and it will probably take a bit more time for the new edge to follow.

@cx20
Copy link
Contributor

cx20 commented Nov 23, 2019

Chrome Canary 80.0.3975.0 seems to have improved the WebGPU error. Now, Babylon.js WebGPU sample can be displayed with ThinkPad X260 built-in GPU.
With Edge Canary 80.0.3971.0, WebGPU still has an error, so it seems to need to wait a little longer.

@sebavan
Copy link
Member Author

sebavan commented Nov 23, 2019

Yep it is related to my previous message and would probably need a week or two to go in :-) but good to know it works on more devices.

@cx20
Copy link
Contributor

cx20 commented Nov 29, 2019

I recently got a new environment (MacBookAir), so I tried WebGPU with Babylon.js.
However, Babylon.js PlayGround GPU does not seem to work on MacBookAir + BootCamp + Windows 10 + Chrome Canary.

image

Please let me know if there is a solution.
I wanted to disable "Skia API for OOP-D compositing", but it seems that the flag does not exist in the latest version of Chrome Canary.

[2019.12.08] The latest version of Chrome Canary seems to solve the above problem. Currently it is all green.
image

@sebavan
Copy link
Member Author

sebavan commented Nov 29, 2019

No idea as here it is pretty specific :-( might be worth reaching out to the chromium team for those as it might be driver related ?

for us, we are trying to stay as much as we can in sync with the first release being Chrome on Mac. Then we are pretty confident it should work a couple of days later on Chrome Windows and finally on Edge for windows a bit after that.

@sebavan
Copy link
Member Author

sebavan commented Mar 23, 2020

Ok so I ll try to fix it at least for MacOS as on Windows for me, I can not make it run at the moment. (none of your samples.)

@sebavan
Copy link
Member Author

sebavan commented Mar 24, 2020

Ok so I commited the glslang fix but it is soon to be deployed.

@RaananW , the file https://preview.babylonjs.com/glslang/glslang.js is not the same as https://github.com/BabylonJS/Babylon.js/blob/preview/dist/preview%20release/glslang/glslang.js

I can not think of any good reason aside of the deploy process ? any idea ? I can not debug as it seems it is not yes from the common subscription... I guess :-) Would really appreciate if you can have a look.

@sebavan
Copy link
Member Author

sebavan commented Mar 24, 2020

@RaananW I forced a manual purge and all good... no idea, do not ask :-) ... So @cx20 it should be all good. I might nevertheless fail on windows like other webgpu projects related to the previous chromium ticker: https://bugs.chromium.org/p/chromium/issues/detail?id=1064110

@cx20
Copy link
Contributor

cx20 commented Mar 24, 2020

@sebavan Thanks. I have confirmed that Babylon.js Playground WebGPU can be displayed again on both Windows and Mac Chrome Canary.

[2020.03.25] Unfortunately, Chrome Canary in the Windows environment seems to work on some PCs and not on others.
image

@cx20
Copy link
Contributor

cx20 commented Apr 29, 2020

WebGPU has come to work recently with Firefox Nightly.
However, Babylon.js WebGPU Playground does not display with an error.
It seems that setSubData cannot be used with the latest WebGPU API.
Even Chrome Canary has deprecated setSubData, so I hope you can migrate to the latest WebGPU API.

@deltakosh
Copy link
Contributor

cc @sebavan

@sebavan
Copy link
Member Author

sebavan commented Apr 29, 2020

I will migrate next week as there is a quite large refactor of the APIs in process. The setSubData has already been fixed but not deployed due to the other required changes.

The main issue is the ecosystem fragmentation and I do not know at what extends testing on all the platforms is fully relevant as they are all evolving separately.

I have great hopes that after the shader language changes, things would be less fragmented.

@sebavan
Copy link
Member Author

sebavan commented May 12, 2020

Just migrated and merge with master, it is uptospec so there might be issues with not uptodate browsers ;-) but at least it has been updated.

@cx20
Copy link
Contributor

cx20 commented May 13, 2020

@sebavan Thank you for updating. I have confirmed that the warning has been resolved in Chrome Canary.
BTW, when displaying Babylon.js WebGPU Playground in Firefox Nightly, it seems that an error appears in the part that is not related to WebGPU.

babylonWebGpu.max.js:1:1
Uncaught SyntaxError: invalid regexp group 

@sebavan
Copy link
Member Author

sebavan commented May 14, 2020

@cx20, so no more issue on this side but firefox now just crashes on Windows, you might ping them as it sounds on their side :-(

@cx20
Copy link
Contributor

cx20 commented May 14, 2020

@sebavan Thank you for fixing regexp. I have made a separate bug report regarding the crash.
https://bugzilla.mozilla.org/show_bug.cgi?id=1637972

@ghost
Copy link

ghost commented Jun 3, 2020

maybe fun fact for anybody who is interested, firefox nightly with webgpu works on linux, although when I try any of the babylon.js links the tab crashes. Sort of trying to figure out if I can get more verbosity out of firefox (running from command line) not really sure how to though.

@sebavan
Copy link
Member Author

sebavan commented Jun 3, 2020

@0x00002152 looks like it has been ack as a bug on the firefox side: https://bugzilla.mozilla.org/show_bug.cgi?id=1637972

@thomlucc thomlucc modified the milestones: 4.2, Future Aug 11, 2020
@cx20
Copy link
Contributor

cx20 commented Sep 5, 2020

Currently, Playground is experiencing an error due to a change in the WebGPU API specification.
https://playground.babylonjs.com/indexWebGPU.html

mainWebGPU.js:1 
TypeError: this._device.createBufferMapped is not a function
    at t._createBuffer (babylonWebGpu.max.js:1)
    at t.createUniformBuffer (babylonWebGpu.max.js:1)

The versions of browsers I have tried are as follows
Browser : Chrome Canary 87.0.4255.1

The recent changes to the WebGPU API may be helpful in the following articles

PSA for Chromium / Dawn WebGPU API updates 2020-07-28
https://hackmd.io/szV68rOVQ56GYzPJMBko8A

@Popov72
Copy link
Contributor

Popov72 commented Sep 6, 2020

It has already been corrected but the code is not deployed yet.

@sebavan
Copy link
Member Author

sebavan commented Sep 6, 2020

We actually wont be redeploying the WebGPU PG before the merge to master planned to happen right after our 4.2 release and then full steam on WebGPU :-)

@cx20
Copy link
Contributor

cx20 commented Sep 6, 2020

@Popov72 @sebavan Thanks for letting me know. I'm looking forward to 4.2 being released.

@stefansundin
Copy link
Contributor

Hello. I am testing WebGPU using electron 15 and the version of Babylon.js that is served from preview.babylonjs.com, and there's a small problem with the content-type for glslang.wasm. It is printing a warning/error in the console but I am unsure if there's any actual problems.

glslang.js:36 wasm streaming compile failed: TypeError: Failed to execute 'compile' on 'WebAssembly': Incorrect response MIME type. Expected 'application/wasm'.

$ curl -I -s https://cdn.babylonjs.com/glslang/glslang.wasm | grep content-type
content-type: application/wasm
$ curl -I -s https://preview.babylonjs.com/glslang/glslang.wasm | grep content-type
content-type: application/octet-stream

@Popov72
Copy link
Contributor

Popov72 commented Nov 12, 2021

No it's ok even with this warning (I get it also).

I will see if we can change the mime type of the preview CDN.

@RaananW
Copy link
Member

RaananW commented Nov 15, 2021

The mime type was changed to application/wasm

@thomlucc
Copy link
Member

Delivered by @Popov72. Thanks!!!!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement in progress Someone is currently working on this issue rendering engine WebGPU
Projects
None yet
Development

No branches or pull requests

10 participants