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

151–160 of 211 posts

Re: WebGPU Fundamentals

#151

Post by jazzyjackson »

2h wrote: post #96
saiojd wrote: post #32

Earlier quoted context omitted.

Why does it bother you that browsers have many features? At this point browsers are essentially a cross-platform VM and it really seems like this trend will only accentuate in the future.

because I want limited scope tools. if I want something on the GPU, I can just write a native tool. I dont need the browser to do anything beyond web browsing.

well you should have no problem implementing your own static web browser then, why complain about the binaries others are running?

Re: WebGPU Fundamentals

#152

Post by unconed »

pavlov wrote: post #13
itronitron wrote: post #11

Earlier quoted context omitted.

Some people have been using signed distance fields (sdf) to define fonts on the GPU.

Note that this approach is useless on its own if your app needs to render user-created text because nowadays everybody expects emojis to work and look roughly the same as on Apple’s platforms, which means detailed multi-colored layered vector shapes that SDF font renderers can’t handle.

Use.GPU handles this just fine: it uses a subpixel SDF mask with a plain color image. You get crisp edges, just the interior is a bit blurry.

Re: WebGPU Fundamentals

#153

Post by RGamma »

2h wrote: post #95
RGamma wrote: post #44

Earlier quoted context omitted.

Free yourself from the notion that a web browser purely browses The Web. It's nowadays also a cross-platform insta-deployment GUI application runtime environment with mostly bad native OS integration and performance characteristics (both ~improving, there's even native filesystem access now). In any case it's Good Enough (C), so it sticks.

> Free yourself from the notion that a web browser purely browses The Web. Free yourself from the notion that a web browser should do anything more than browsing the web. native applications have existed for decades, no reason to bloat the scope of a browser.

I wish it wasn't true either.

Seeing a semi-technical acquaintance use in-browser software for daily productive work hurts my programmer's soul. It's alright for some light things, like vacation planning, but remote desktop or an IDE...

Then there's that other scourge of Electron-like apps with gigantic memory budgets and all. I have resigned to throwing more hardware at it when I can't guarantee a lighter replacement (i.e. in a work setting):

All my productive systems have 32GB RAM and 8+ threads now and with browser, Teams, Outlook, IDE and dev containers the air's getting thin again :/

Re: WebGPU Fundamentals

#154

Post by catwell »

MrResearcher wrote: post #134

It's a pity that tfjs never truly developed any decent ops. E.g. you need lgamma to implement the cap for zero-inflated poisson regression and tfjs simply doesn't have that: https://github.com/tensorflow/tfjs/issues/2011 Those guys simply dropped the ball on the floor, and the further framework development fizzled out. I tried to find if WebGPU could be a replacement, but it's very hard to find a good description of…

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.

Re: WebGPU Fundamentals

#156

Post by skybrian »

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.

Even if Chrome were the standard, there would still be variety due to plugins. A lot of sites have glitches in Chrome too, if you install the wrong plugins or turn stuff like third-party cookies off.

I'm not sure I trust people who say something doesn't work in Firefox, unless they tried it in a fresh profile with default settings.

Re: WebGPU Fundamentals

#157

Post by galangalalgol »

javajosh wrote: post #124
cleanchit wrote: post #61

Earlier quoted context omitted.

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

Firefox has a better plugin ecosystem, and it's plugins that cause a lot of site issues. It's a very clear trade-off in the hands of the user, which is correct.

Yeah, with one exception it has always been dark reader that caused a page to render wrong in Firefox. The exception was some misconfigured oauth stuff that didn't work.

Re: WebGPU Fundamentals

#158

Post by MrResearcher »

catwell wrote: post #154
MrResearcher wrote: post #134

It's a pity that tfjs never truly developed any decent ops. E.g. you need lgamma to implement the cap for zero-inflated poisson regression and tfjs simply doesn't have that: https://github.com/tensorflow/tfjs/issues/2011 Those guys simply dropped the ball on the floor, and the further framework development fizzled out. I tried to find if WebGPU could be a replacement, but it's very hard to find a good description of…

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 ensembles of models trained on different clients, all without sharing data with the server.

BTW, I did have some experience with ONNX, also ran into problems with some ops (like nn.SELU not working correctly in the browser - https://pytorch.org/docs/stable/generated/torch.nn.SELU.html...).

Re: WebGPU Fundamentals

#159

Post by charcircuit »

softfalcon wrote: post #81
vbezhenar wrote: post #10

How do I render text with GPU? Do I render text on texture with CPU and then send that texture to GPU? Do I vectorize it and draw millions of tiny triangles to approximate those vectors? It's interesting for me to explore WebGPU as a canvas for app development, but it's not obvious to me how to draw text and text is everywhere.

Most web games use the dom as a layer over top of the 3D canvas and then use 3D to 2D projections to align the elements. This allows you to use regular HTML and CSS for a lot of text elements. Also, you can render and rasterize fonts + dynamic text to a texture and UV map it to a quad in 3D space if you need to. This is pretty inexpensive and easy to do as well. Lastly, the most difficult but performant option is usi…

This doesn't work for webxr.

Re: WebGPU Fundamentals

#160

Post by galangalalgol »

wpm wrote: post #123
tiagod wrote: post #85

Earlier quoted context omitted.

Because it's really cool to try out experimental instruments other poeple have made by simply opening a webpage, without having to execute untrusted native code that could have bad consequences.

Instead, you're executing untrusted browser code, which is hardly better.

I'm interested if this is true. It seems like the js sandbox is pretty well implemented now in most cases. Webgl had some problems at first leaking host data, but the willingness to sacrifice performance for security seems pretty ingrained in these consortiums?
Post reply on HN