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

191–200 of 211 posts

Re: WebGPU Fundamentals

#191

Post by caspar »

Kamq wrote: post #176
kajaktum wrote: post #45

Earlier quoted context omitted.

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.

That's basically ChromeOS, right? Some people seem to use it.

Re: WebGPU Fundamentals

#192

Post by fulafel »

AgentME wrote: post #170
superzamp wrote: post #121

Earlier quoted context omitted.

Total graphics / shaders / GPU noob here. Does that mean you'll essentially get free visualisations (albeit non-sensical ones) as a byproduct of your computations?

If you wanted to do compute in a shader before WebGPU with WebGL instead, then I think the answer is kind of yes. It wasn't "for free" without any code but it was required to do. But now WebGPU supports compute shaders properly so you don't have to do compute in a shader that produces textures.

A texture in WebGL is just a memory buffer that can be accessed by shaders. It doesn't end up on screen automatically.

Re: WebGPU Fundamentals

#193

Post by pjmlp »

capableweb wrote: post #189
pjmlp wrote: post #129

Earlier quoted context omitted.

Snap, Flatpack, iOS sandbox, Android sandbox, UWP/Windows sandbox,...

Unfortunately, none of those are cross-platform... Closest we get to something similar to the web is either the JVM or APE (Actually Portable Executable) but then those are generally not as isolated as the alternatives you mentioned, sadly.

Or CLR, or now the fashionable WebAssembly.

Plus, plenty of languages have cross-platform runtimes and libraries, so not a big issue, not everything needs to be JavaScript.

Re: WebGPU Fundamentals

#194

Post by chefandy »

MikeSchurman wrote: post #105
cleanchit wrote: post #61

Earlier quoted context omitted.

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

I'm not sure if these are examples of dropped support, but I run into issues on websites that prevent me from doing something I really need to do: - I could not unsubscribe from amazon prime yesterday using firefox. The page where you select the option was not rendering correctly. It was white for half the page vertically and the link/button I need to press was absent. - about 6 months ago I could not sign into apple…

In my experience, problems like that are almost always a matter of cookie/cache sticking around when it shouldn't or plugin interference. The only sites I ever have have blocking trouble with in FF are shitty web interfaces for local device configuration, old automatically generated webpages like from MS Access or some other super old enterprise abomination. I worked on a team of web developers that generally developed using FF and then tested heavily in chrome-- everything from simple pages augmented with JS to complex SPAs-- and the differences were pretty minimal.

Re: WebGPU Fundamentals

#195

Post by bobajeff »

Razengan wrote: post #64

Regarding all the arguments about ever-increasing browser complexity and the resulting inefficiency: Why is nobody asking the reverse question: How to make operating systems more like browsers?? From the end user's PoV (consider someone who isn't computer savvy) what are the actual objective differences in usability, between the OS and browser? -- • OS: Apps have their own windows and menu bars. • Browser: Multiple a…

The better question is do we even need so many apps to begin with? Do we need YouTube, Dailymotion, TikTok, Vimeo all to be their own app? Or should they all just use the something like NNTP but for video sites?

Re: WebGPU Fundamentals

#196

Post by pfarrell »

visarga wrote: post #180
MrResearcher wrote: post #158

Earlier quoted context omitted.

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 d…

It’s Hadoop all over again. Send the code to the data. To be clear, I think that’s an excellent idea and good to see it coming backs again.

Re: WebGPU Fundamentals

#197

Post by yellowapple »

Cloudef wrote: post #102
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.

WebGPU in browser isn't really interesting to me. But I do like WebGPU in native applications, as we are yet again in scenario where Windows prefers DX, OSX their own Metal and Vulkan is yet again mostly linux only player, and popular WebGPU implementations have backends to all of these (+ more).

Yep. I just read through the entirety of this guide specifically to better understand Mach, which uses Google's WebGPU implementation for everything graphics-related.

Re: WebGPU Fundamentals

#199

Post by kimown »

pjmlp wrote: post #50
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…

Thanks to Google blocking WebGL compute shaders adoption. We could have had them three years ago.

Yes, I also don't understand why google abandon webgl compute shader, just because webgpu will have same, so they force developer using newer api.

Re: WebGPU Fundamentals

#200

Post by pjmlp »

akomtu wrote: post #188
qz_kb wrote: post #116

Earlier quoted context omitted.

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

Fragment shaders can only go so far. Can you do in webgpu something like this? outputTexture2d[inputTexture2d[inputPosition]]++ In other words, if you have a large texture with (x,y) coordinates of points, can you draw another texture that shows a density cloud of these points? In webgl2 it becomes a phd level problem.

One needs to do multiple passes, not sure if that is to be considered a PhD level problem.
Post reply on HN