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

81–90 of 211 posts

Re: WebGPU Fundamentals

#81

Post by softfalcon »

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 using a shader to compute the font rendering. This is basically moving the font raster from CPU to GPU and there are various shader examples for this in GLSL (popular shader format used by WebGL/OpenGL) that you can use.

Re: WebGPU Fundamentals

#82

Post by abirch »

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!

You can find a security focused browser that don't implement these.

Re: WebGPU Fundamentals

#83

Post by jeroenhd »

archerx wrote: post #73

I wish they had kept the c/c++ syntax style for WGSL, the rust syntax is just awful and alienating.

I much prefer the new syntax. The C based shader languages always end up in some kind of uncanny valley where it looks like C and C++ but behaves completely differently.

It's not exactly Rust either, the @annotations aren't written like that in Rust for example.

The let-syntax is closer to Javascript with type annotations, so that makes more sense for web programming than doing C style variable definitions. Using let and var instead of let and cons is a bit of a weird choice, though.

Other than the variable definition syntax, this syntax may as well have been C++-based without all the verbose names that C++ likes to add to its namespaces. Shades will usually mostly be math code, though, so it shouldn't even matter all that much in practice.

Re: WebGPU Fundamentals

#84

Post by danielvaughn »

RGamma wrote: post #44
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.

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.

there's native filesystem access?

edit: wow, I had no idea and I've been a web dev for over a decade lol

Re: WebGPU Fundamentals

#85

Post by tiagod »

reaperducer wrote: post #60
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…

I want to be able to interact with synths over MIDI in the browser Help me understand why this is. Is it because there aren't native programs for the platform you're using? Is it to allow plug-ins or other abilities that wouldn't otherwise be available? Is it so that you can sync up with other musicians and play together in a way that wouldn't be possible without a browser? choose a browser that doesn't implement tho…

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.

Re: WebGPU Fundamentals

#86

Post by ptato »

cleanchit wrote: post #61
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 am already seeing websites drop support for Firefox Examples?

I've found enough Firefox-only bugs when doing things through spanish government sites that I started using Chrome for them preemptively.

Re: WebGPU Fundamentals

#87

Post by Kiro »

kajaktum wrote: post #75
adwn wrote: post #69

Earlier quoted context omitted.

Firefox 112 doesn't seem to have any problems rendering it. What do you mean by "Chrome-only"?

I mean it doesn’t do any QA on them. My banking website won’t load on Firefox for example.

What's your bank considering we still haven't been given an example? The Honda one works fine in Firefox.

Re: WebGPU Fundamentals

#88

Post by awhitty »

magicalhippo wrote: post #80
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.

WebUSB was actually useful to me not long ago. I installed Home Assistant and its ESPHome[1] companion, and ESPHome had support for using WebUSB to upload the firmware to a blank ESP8266 I had. I didn't have to install or set up anything on my Windows machine, and the whole process was very quick and convenient. It seems clear to me that the main issue here is that a lot of programs aren't closely tied to the hardwar…

I had a similar pleasant experience with a Wooting 60HE keyboard I purchased recently. Updated my keyboard’s firmware and settings right in Chrome! So much nicer than downloading icky gaming peripheral software. I’ve been told a lot of that stuff is borderline spyware.

Excited to try it out with some ESPHome projects too now.

Re: WebGPU Fundamentals

#89

Post by wongarsu »

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 waiting around for WebGPU, it would already exist as a desktop program.

Re: WebGPU Fundamentals

#90

Post by jeroenhd »

TachyonicBytes wrote: post #9

This is great! I have been meaning to get more into WebGPU! One question: Does anyone know more details about the Firefox WebGPU story? Even on this site's homepage, if you access it from Chromium with WebGPU enabled, you get nice floating rotating triangles, if you access it from Firefox stable, you get, understandably, static triangles. But if you access from Firefox nightly, with WebGPU enabled, you get a dark bac…

Firefox doesn't implement that method yet: https://developer.mozilla.org/en-US/docs/Web/API/GPU/getPref...

You can probably use "bgra8unorm" where getPreferredCanvasFormat isn't available, that seems to be the preference for at least Blink and WebKit.

Chrome doesn't support rgba8unorm on Mac, probably because Apple seems to have chosen bgra8unorm as their format for their Metal API for some reason, so you'll have to use BRG rather than RGB if you want to support Apple hardware at the moment.

Post reply on HN