Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WebGPU Fundamentals

webgpufundamentals.org

Post reply on HN
Print view View original

111–120 of 211 posts

Re: WebGPU Fundamentals

#111

Post by thewebcount »

> It is expected you already know JavaScript before you read this article. Concepts like mapping arrays, destructuring assignment, spreading values, async/await, es6 modules, and more will be used extensively.

So in other words, it’s just like Vulkan where the beginner tutorials have you set up your own allocators, deal with fencing, and use a swap chain just to put a single triangle on the screen? What the actual fuck? This doesn’t sound at all like “fundamentals” and makes me not want to ever use it if the very basics require all of the above. I think your average programmer, even one who does 3D graphics, is going to look at this and just be turned off.

Re: WebGPU Fundamentals

#112

Post by chris37879 »

mpldr wrote: post #41
Dalewyn wrote: post #40

Earlier quoted context omitted.

At some point we're going to have to drop the pretense of running an operating system underneath because the browser is the operating system.

Blink is my operating system and Linux is its bootloader.

How’s chromeos treating you?

Re: WebGPU Fundamentals

#113

Post by moron4hire »

SquareWheel wrote: post #39
mpldr wrote: post #19

Question for discussion: when have we reached the point where the Browser Feature-creep is too much and we say "okay, a browser probably doesn't need this"? Because after seeing WebUSB and WebGPU I think my personal limit has been reached.

I tend to feel that way mainly towards new features that are very similar to ones that already exist. eg. WebGPU being a more advanced form of WebGL. Yes they work differently, but they generally solve the same problem. Eventually I'd like to see WebGL deprecated, and perhaps an extension released to reimplement it. Or it could be adapted to translate calls to WebGPU, rather than having a completely separate implemen…

That's actually not unreasonable, as WebGL under the hood is already implemented through Vulkan, Metal, and DX12.

Re: WebGPU Fundamentals

#114

Post by moron4hire »

chii wrote: post #30
dvngnt_ wrote: post #20

Earlier quoted context omitted.

I don't see a problem you don't have to use it

the more important question is whether the browser's surface area for bugs and perhaps security vulnerabilities are worth the marginal increase in features that most people might not use!

It's not like native OS features don't have security vulnerabilities. At least all the major browser have at some major portion of their implementations that are open source projects. So if you're stuck working on Windows or MacOS, at least you can know that Web browsers aren't limited to one vendor finding and fixing those defects.

Re: WebGPU Fundamentals

#115

Post by inportb »

mpldr wrote: post #19

Question for discussion: when have we reached the point where the Browser Feature-creep is too much and we say "okay, a browser probably doesn't need this"? Because after seeing WebUSB and WebGPU I think my personal limit has been reached.

I think WebCPU is where it's at. First class virtualization in the browser so you don't have to emulate :)

Re: WebGPU Fundamentals

#116

Post by qz_kb »

billti wrote: post #101

This looks heavily geared towards graphics. I’m interested in the compute capabilities of WebGPU to build an in-browser simulator (e.g. physics/quantum). Anyone know of any good resources for that? (Samples, best practices, etc.)

This is usually done with shaders and a circle of buffers which maintain state.

Re: WebGPU Fundamentals

#117

Post by waboremo »

thewebcount wrote: post #111

> It is expected you already know JavaScript before you read this article. Concepts like mapping arrays, destructuring assignment, spreading values, async/await, es6 modules, and more will be used extensively. So in other words, it’s just like Vulkan where the beginner tutorials have you set up your own allocators, deal with fencing, and use a swap chain just to put a single triangle on the screen? What the actual fu…

Most of those concepts are foundational to web programming, yes.

I also believe that for most people who "just want a triangle on the screen" they'll be utilizing other higher level tools to do so, and those tools will then do the "dirty" work of using WebGPU. Think, Figma making it easy for people to design but behind the scenes it's incredibly complex using C++ (might be outdated on this) compiled to WebAssembly.

Same will apply here, most people who want lower level access to the GPU aren't really doing so just because of simple triangles or basic graphics work. There are already engines and frameworks for them.

Re: WebGPU Fundamentals

#118

Post by shepherdjerred »

thewebcount wrote: post #111

> It is expected you already know JavaScript before you read this article. Concepts like mapping arrays, destructuring assignment, spreading values, async/await, es6 modules, and more will be used extensively. So in other words, it’s just like Vulkan where the beginner tutorials have you set up your own allocators, deal with fencing, and use a swap chain just to put a single triangle on the screen? What the actual fu…

This is a beginner tutorial for WebGPU, not JavaScript. It's entirely reasonable to assume knowledge of language features.

Re: WebGPU Fundamentals

#119

Post by sgc »

wongarsu wrote: post #89
pmoriarty wrote: post #62

Can this somehow be leveraged to crowd-train LLMs or maybe do something like SETI@home within the browser?

No, distributed training is one of these holy grails nobody has quite figured out yet. You can split training across multiple GPUs in the same computer, or multiple computers in close proximity connected by infiniband, but that's about as much latency as we can handle right now. We need some breakthrough to make it possible for internet-connected computers to usefully collaborate. If it did work we wouldn't be waitin…

Pardon my naivety. The only reason individuals would willingly participate at a large scale, would be for an open source AI project. Does that mean once the problem is solved, everybody will likely be able to run their own state of the art AI, or are the real-time calculations too intensive for a single server?
Post reply on HN