As the browser becomes more like an operating system, we are seeing more deep features being built into them. For example, you can now do a form of assembly language for the browser. Sophisticated graphics have been around using WebGL since around 2011, but some people find it hard to use. [Surma] was one of those people and tried a new method that is just surfacing to do the same thing: WebGPU.
[Surma] liked it better and shares a lot of information in the post and — oddly — the post doesn’t use WebGPU for graphics very much. Instead, the post focuses on using GPU cores for fast computation, something else you can do with WebGPU. If your goal is to draw on the screen, though, you need to know the basics and the post links to a site with examples of doing this.
Remember that you may have to do something special to turn on WebGPU in your browser or switch browsers. While WebGL was a thin wrapper over OpenGL, WebGPU is an abstraction that can drive Vulkan, Metal, or DirectX 12 — all popular ways to talk to a GPU, depending on your operating system.
The post is long and covers topics like shaders, pipelines, and staging buffers. Of course, the API is in draft and not stable, but it seems substantial enough that what you learn now will probably be useful in the future, too.
We’ve seen GPU processing used to do neural networks in the browser. You might also be interested in checking out GPU.js.
GPU’s have a very large attack surface. Sometimes they can be configured to write to shared memory that is read only to the CPU. Allowing unfettered access to your GPU from the internet, could be very risky.
It’s going to be a CORNUCOPIA of driver and hardware specific vulnerabilities. Absolutely spectacular to behold.
I’m turning this misfeature off.
Sounds like the browser needs a virtualized GPU. Somethings much more limited and controlled.
What in your opinion is a “virtual GPU” and why is webgpu not that? It’s an abstraction that’s implemented on top of other abstractions. (Vulkan, metal, dx12, opengl)
It is designed to be more limited, sacrificing speed for security. I don’t see how it’s anything but a virtual GPU.
I don’t see how a API implementing a subset of the shared features between various graphics APIs with a focus on security and modern features, is anything but a virtual GPU. Mind elaborating on your definition of a virtual GPU, and why it would be more secure than this?
I don’t see how a API implementing a subset of the shared features between various graphics APIs with a focus on security and modern features, is anything but a virtual GPU. Mind elaborating on your definition of a virtual GPU, and why it would be more secure than this?
This is a valid concern.
Why websites would need such access is a bit dubious as well.
After all, what fancy graphics do one run as to need an actual GPU?
A lot of vendors I work with are including 3D model views on their websites of components. It can actually be pretty handy, as you can see a disqualifying feature quickly, instead of spending 1-2min (or 4min at my old job on a different CAD system) downloading and importing it.
That said, I think that this will be pretty disastrous security-wise for a year or two after initial widespread adoption, with a continual trickle of vulnerabilities thereafter.
Sounds like what Curl was trying to achieve.
https://en.wikipedia.org/wiki/Curl_(programming_language)
3D models? Brings back memories of VRML from the 90s. :)
https://en.wikipedia.org/wiki/VRML
There are a bunch of people who believe that a Web site should basically have the same access to all resources as a native program, usually because they want all applications to *be* Web sites. They don’t want any abstractions, because abstractions might reduce their capabilities in some tiny way versus those of native programs.
This is the mindset that created a RAW USB API for browsers.
Most of those people are simply evil and want to turn everything in the world into a subscription. The rest are just clueless cheerleaders
Well MS did have a fear of the browser being a viable alternative and subjugating it’s dominance.
https://www.cnet.com/tech/computing/aol-deep-sixes-netscape-browser/
It’s not about subscriptions, it’s about making use of what is already the beat cross platform system ever, essentially, and expanding the abilities of self hosted IoT devices(Once we figure out how to give them secure contexts).
We could someday make apps for all platforms just by making a website and clicking convert, if there’s no need for any special APIs web can’t do.
For open source, that’s a good thing, because FOSS doesn’t have unlimited budgets, and large GUI apps are very hard to do using the usual bazaar model(Since coders don’t seem to enjoy working on them).
I’m a big fan of WebUSB, Bluetooth, and Serial.
This is a poorly thought out plan. WebGL was bad but exposing the GPU is madness. It’s just one more “feature” that I’ll be sure to disable.
brb, off to write the next agar.io/slither.io that is actually a front to mine crypto… :-D
A 3D buffer would surely be helpful on the hardware . For fast action Games with alot of shaders on the GUI . Mobile webgl is aint so dad.. but so thats my take ..it I guess interms of hardware and cloud computing and rendering..thats a world .. so Webgl can be writen a new stack . Maybe some work needs done interms of user based issues on the www and iot cloud . Not so bad . Servers and builders ca n be hardware intensive . Can be hard to Repeat testing . It could low out the screen and eat up your batteries on runtime. So perso na’ ..as for 3s s and mia shaders I like to use the legacies and s9.e random Brusehes ..lighting too super uber important in a scene . 3d is best under great hardware that can real e assertive to the gpu to keep going .
ne for the PC and desktop crowds. .Its intents to be the buffer that blows out on the monikter . Hehe .
WebDirectX
For context: WebGL is based on OpenGLES, which was designed for the previous paradigm of graphics hardware. WebGPU could be thought of as WebVulkan, in that it is surely designed for the same paradigms that led to the drafting of Vulkan. In the words from the draft: “The API is designed from the ground up to efficiently map to (post-2014) native GPU APIs.” However, often has it been stated that Vulkan itself exposes too much, so would be impossible to secure if exposed directly. Plus, Apple has never supported Vulkan, in favor of it’s own Metal, and Windows has always had better DirectX support.
But even WebGL had issues when it was OpenGLES exposed near-directly. Browser developers had to create ANGLE, a translator between OpenGLES and DirectX. Since this secure virtual-driver layer already has to exist, It makes little sense to hold back development to support the older paradigm of graphics programming. WebGPU looks to be an API that will make the virtual-driver layer fit better with current hardware, simplifying it and exposing more functionality. And yes, doing so cross-platform, securely.
If you actually take the time to open up the page and first section after the introduction, you can see that security is their first consideration. In their words it is “non-negotiable”.
Agreed with this