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

171–180 of 211 posts

Re: WebGPU Fundamentals

#171

Post by mindcrime »

inportb wrote: post #115
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 :)

Why not? People are already running VM's and other OS's in the browser.

https://github.com/atrosinenko/qemujs

https://jamesfriend.com.au/pce-js/ibmpc-games/

https://leaningtech.com/webvm-server-less-x86-virtual-machin...

and so on...

Re: WebGPU Fundamentals

#172

Post by raphlinus »

coffeeaddict1 wrote: post #169
raphlinus wrote: post #18

Earlier quoted context omitted.

One of the most exciting features of WebGPU, especially over WebGL, is the ability to run compute shaders. That opens up an entire class of 2D vector graphics rendering techniques using compute shaders, including Vello. It's still in early stages, but the current code does include text rendering. There's a very rough demo at https://levien.com/vello-demo (the demo doesn't do variable fonts but the code can), and we'l…

Is it (will it be) possible to use Vello from C++ or is this firmly Rust only?

There are no active plans to do this, but it's all open source and there are tools such as cbindgen, so if there is sufficient interest there's a good chance it will happen.

Re: WebGPU Fundamentals

#173

Post by spiralganglion »

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…

WebGPU is not meant to be a high-level, beginner-accessible graphics API. It's meant to be a low-level GPU API that expert users can build nice tooling atop. It's an embodiment of the extensible web manifesto's principle that browsers ought to expose lower level hooks to enable API experimentation in user space, like we had with Promises starting out as a constellation of competing approaches in libraries.

Re: WebGPU Fundamentals

#174

Post by wilg »

nequo wrote: post #168
wilg wrote: post #167

Ah, this brings back memories of being blocked by Jonathan Blow on Twitter for poking fun at him for being really mean to the people who worked on WebGPU. https://i.imgur.com/ZDgXBXH.png

What is the “pollution” by WebGPU that he was referring to?

You’d have to ask him (I don’t recommend it) but I think he means the API is badly designed so it makes computers in worse general.

Re: WebGPU Fundamentals

#175

Post by zx8080 »

whitemary wrote: post #66
cleanchit wrote: post #61

Earlier quoted context omitted.

> I am already seeing websites drop support for Firefox Examples?

The Honda Financial website is Chrome-only. https://honda.americanhondafinance.com

It's sad that there are specific browser-oriented websites (and development processes, obviously) instead of the standards-oriented ones.

(Sure, it's Chrome-oriented ones. We've seen similar previously with IE, by the way.)

We have standards for the web. Real ones: the docs, which are discussed and approved in the industry. We have them for a long time!

So if some browser does not comply to the standards, it's really not the best strategy to adapt a site to the browser instead of the standards.

We are in the situation when (effectively) one company (Google/Alphabet) can lead anything to the whole market, step by step (even when changes contradict the web standards that are in place). The market is not the browsers market, of coyrse, but the internet ads through browsers control, which brings the most money to Google. By projecting its power to each and any aspect of it, Google ensures the uninterrupted market control for years ahead. So Google will continue to do. In the long run, we need to rely on standards instead of specific browsers. Otherwise it's just the monopoly of Google and web tech "market" is just their own backyard. That will bite us all hard.

Re: WebGPU Fundamentals

#176

Post by Kamq »

kajaktum wrote: post #45
capableweb wrote: post #33

Earlier quoted context omitted.

> Because after seeing WebUSB and WebGPU I think my personal limit has been reached. Sure, but where do you draw the line really? For me, having WebUSB and WebMIDI for example is useful, I want to be able to interact with synths over MIDI in the browser, or be able to access other accessories. I also love the idea of GPU access, so my personal limit has not been reached. Multiply this by every vendor, developer and u…

Browsers are just “standardised” OS at this point. Really, what is the difference? It seems to me that people basically wants a 1 to 1 mapping between every OS feature to browsers. I wouldn’t be surprised if this standard will fall apart in the next decade once Chrome runs everything. That is to say Chrome is the standard. I am already seeing websites drop support for Firefox and won’t even load using it.

I wonder if you could just duct tape a kernel to a modern browser and boot right into it. Ok, well, I know you can do that, but I wonder if you could get people to use it.

You'd need some tinkering to open a new browser window per monitor, couple of routes on 127.0.0.1 for config.

Re: WebGPU Fundamentals

#177

Post by kajaktum »

zx8080 wrote: post #175
whitemary wrote: post #66

Earlier quoted context omitted.

The Honda Financial website is Chrome-only. https://honda.americanhondafinance.com

It's sad that there are specific browser-oriented websites (and development processes, obviously) instead of the standards-oriented ones. (Sure, it's Chrome-oriented ones. We've seen similar previously with IE, by the way.) We have standards for the web. Real ones: the docs, which are discussed and approved in the industry. We have them for a long time! So if some browser does not comply to the standards, it's really…

Having a standard is not even possible technically when you have 1 player that is too good. Due to Hyrum’s Law, any small divergence from the spec will be observed and relied on. Why would you work against the spec which is nebulous, when you could be testing against 99% of what your user use?

Re: WebGPU Fundamentals

#178

Post by nightski »

kajaktum wrote: post #45
capableweb wrote: post #33

Earlier quoted context omitted.

> Because after seeing WebUSB and WebGPU I think my personal limit has been reached. Sure, but where do you draw the line really? For me, having WebUSB and WebMIDI for example is useful, I want to be able to interact with synths over MIDI in the browser, or be able to access other accessories. I also love the idea of GPU access, so my personal limit has not been reached. Multiply this by every vendor, developer and u…

Browsers are just “standardised” OS at this point. Really, what is the difference? It seems to me that people basically wants a 1 to 1 mapping between every OS feature to browsers. I wouldn’t be surprised if this standard will fall apart in the next decade once Chrome runs everything. That is to say Chrome is the standard. I am already seeing websites drop support for Firefox and won’t even load using it.

The difference is that it is not a "standardized" OS interface. Rather it's a complex layer on top of operating systems offering dumbed down and less performant versions of what is available all of which is interfaced by a dynamic and not so performant language.

If it was something like a modern POSIX I don't think you'd have much complaining. But it's a lot heavier than that.

Re: WebGPU Fundamentals

#180

Post by visarga »

MrResearcher wrote: post #158
catwell wrote: post #154

Earlier quoted context omitted.

WebGPU does not play in the same league as tfjs, it is a successor to WebGL, the technology tfjs is implemented with. There is already a WebGPU backend for tfjs: https://www.npmjs.com/package/@tensorflow/tfjs-backend-webgp... There are also several ONNX runtimes using WebGPU in case you want to run models written with PyTorch.

Exactly, the lack of the deep learning frameworks to train decent models on the client side forces us to use pytorch on the server, leading to centralized data collection, privacy concerns, copyright and data ownership issues. Imagine the world where you could trivially train a model entirely on the client side, without uploading all that data to the cloud. Then we can settle on federated learning or simply use ensem…

> Imagine the world where you could trivially train a model entirely on the client side, without uploading all that data to the cloud.

You just rediscovered "Federated Learning", but FL also allows you to benefit from the training being executed in other edge nodes, all without disclosing any data.

Instead of sending the data to the training server, they send the model to the users to train on a few batches of user data, then average the models from everyone.

Post reply on HN