So now there are three incompatible graphics APIs in the browsers which are also incomplete in different ways. Each of them is a huge chunk of code that needs to maintained and updated.
WebGPU – All of the cores, none of the canvas
31–40 of 137 posts
Re: WebGPU – All of the cores, none of the canvas
#32WebGPU is a textbook case of Embrace Extend Extinguish performed by Apple to kill Kronos and SPIRV, and everybody is cheering it on. Crazy.
The WebGPU spec is currently edited by two Google employees and one Mozilla employee. I am not sure how to make sense of your accusation.
Re: WebGPU – All of the cores, none of the canvas
#33For those looking for a complete 3D engine already supporting WebGPU and with a WebGL fallback if needed, there is BabylonJs (you'll need the 5.0 version still in the release candidate state) : https://doc.babylonjs.com/advanced_topics/webGPU/webGPUStatu... ThreeJs is alwo working on its WebGPU renderer
Im excited for Bevy engine too. It uses wgpu, which has many backends, including webgpu.
Re: WebGPU – All of the cores, none of the canvas
#34Is this API going to have a permissions lock, like access to the video camera or microphone APIs do? If it doesn't, I'm not looking forward to the future where every website I visit tries to pull a big chunk of my graphics card to mine cryptocurrencies without my explicit authorization.
While I understand why it's necessary, I feel that the UX of security needs a serious overhaul. It seems like an increasing share of the time I spend using technology involves jumping through hoops.
There is a push-and-pull because the ideal of how the web should work slammed head-on into the reality of how the worst actors will exploit the ideal.
Ideally, the web is a fabulous location-destroying architecture. The common protocol for both communications and content rendering really flattened the universe of data sources; doesn't matter if you're on CNN, Fox, Wikipedia, Google, or Hacker News, they all "feel" the same. Common top-level UX metaphor (underneath which customizations can be built), common language under-the-hood; the web really became a sort of global operating system for transactional communications.
In practice, letting arbitrary actors run arbitrary code on your machine at the speed of the web can be arbitrarily bad, so we tacked on a permissions architecture based on data source (delegating to the domain name service plus secret certificates to tell us who the data source is). And because the proper level of paranoia for strangers online is "zero trust by default," every domain you visit is a new trust relationship with its own security story to wrangle.
So these two features (flat experience where domain doesn't matter and zero-trust security model where domain matters a bunch) are directly at odds with each other. Sucks but it's the best we've got right now (how to improve? Hypothetically, we could add a meta-trust layer... "Here's an allow-list of sites that are trusted, so sayeth Goodsites.com". But nobody's written that spec yet).
GDPR-compliant cookies, as a concrete example, are a huge pain-in-the-ass because we retrofitted them onto site internal code itself instead of adding the concept of "required" vs "optional" cookies to the cookie jar design, which would have allowed user agents to put optional cookies behind a trust barrier like your microphone or video. But cookies are a legacy web feature and making changes to the implementation is hard (and, of course, there's the human element... I'm not 100% sure the people who hold the reigns of the W3C are on the same page with the people who hold the power to create and enforce the GDPR vis-a-vis goals).
Re: WebGPU – All of the cores, none of the canvas
#35One request for the author: Please don't hide the scroll bars on websites you make like this!
I am not! I have no styles that should affect scrollbar visibility. What browser & OS are you on?
Re: WebGPU – All of the cores, none of the canvas
#36If I'm already familiar with Rust, how is WebGPU as an introduction to graphics programming if you aren't already familiar with any of the backends that it wraps? Should I try just learning Vulcan first? Is the abstraction layer just going to introduce additional confusion for a newbie?
I think one of WebGPU's greatest strengths is learning, as you can get started pretty easily, and you actually learn a modern approach to GPU. Vulkan requires a significant amount of boilerplate just to establish a connection to the GPU and set up basic resources like the ability to allocate buffers. In WebGPU, the latter is one or two lines of code. That said, there are some really nice learning resources for Vulkan…
Is WebGPU ready? It's been a bit, but last time I looked it was pretty unstable and not well supported.
Re: WebGPU – All of the cores, none of the canvas
#37WebGPU, all the bare metal crashes/exploits and none of the broad support. Browsers should not be operating systems and the move to make them so will end up making them just as exploitable as your host OS only much slower due to the additional abstraction layers.
WebGPU is not significantly more "bare metal" than WebGL is. There are still going to be several layers of abstraction between user code and the GPU in all cases. No operating system implements WebGPU or WGSL directly so there's always a translation and verification layer in the browser, and then there's the OS API layer, and then the driver layer (and probably multiple layers inside each of those layers). In fact, on operating systems that implement OpenGL, WebGL is actually closer to the OS/driver interface than WebGPU is.
WebGL has been around for a long time and the feared exploits never materialized. It's been no worse than other parts of the browser and better than many.
Re: WebGPU – All of the cores, none of the canvas
#38If I'm already familiar with Rust, how is WebGPU as an introduction to graphics programming if you aren't already familiar with any of the backends that it wraps? Should I try just learning Vulcan first? Is the abstraction layer just going to introduce additional confusion for a newbie?
"Is the abstraction layer just going to introduce additional confusion for a newbie?" As a newbie you probably don't want to deal with WebGPU directly, but rather use (wait for) a framework, that takes care of the details.
depends on your objective, doesnt it? if you eant to learn how things work & what the fundamnetals are, im not sure that a big engine or framework "taking care of the details" is going to be as illuminating.
also, from the article, some poditive reinforcement about trying WebGPU:
> I got my feet wet and found that I didn’t find WebGPU significantly more boilerplate-y than WebGL, but actually to be an API I am much more comfortable with.
sometimes, there aint nothing like going to the source, finding out for yourself. is it the fastest way to get a job done? perhaps not. but the school of lifelong learning & struggles has it's upsides, can be a path towards a deeper mastery.
Re: WebGPU – All of the cores, none of the canvas
#39Earlier quoted context omitted.
True, but this API will make that use case simple and obvious. Given the tradeoffs, probably worth it for user agents to permission-gate it.
You can always disable hardware acceleration in your browser.
That's a big red lever that disables all sites' ability to use WebGL also, isn't it? That kind of thing is the kind of thing I imagine one would want at site-by-site granularity.
Re: WebGPU – All of the cores, none of the canvas
#40Earlier quoted context omitted.
I think one of WebGPU's greatest strengths is learning, as you can get started pretty easily, and you actually learn a modern approach to GPU. Vulkan requires a significant amount of boilerplate just to establish a connection to the GPU and set up basic resources like the ability to allocate buffers. In WebGPU, the latter is one or two lines of code. That said, there are some really nice learning resources for Vulkan…
Is WebGPU ready? It's been a bit, but last time I looked it was pretty unstable and not well supported.
It's still in origin trials on Chrome and behind flags in Firefox and Safari. That said it's pretty stable at this point, for reference Chrome plans on enabling it for all sites and users by default towards the end of May.