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

141–150 of 211 posts

Re: WebGPU Fundamentals

#141

Post by IlliOnato »

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.

Whatever features browsers have, it does not prevent you from writing native tools.

But browsers don't limit themselves to serving your needs only, and they are not in the business of promoting your approach to computing among their users. Why would they?

Re: WebGPU Fundamentals

#142

Post by 1066 »

earthling8118 wrote: post #128
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'm not going to argue against these features, but I find that last argument you raise to be a rather dull and useless one. Yeah, I'll just go ahead and pick from one of the hundreds of competing implementations to find one that doesn't. Oh, wait, they don't exist. It's like saying "if you don't like the laws(/taxes/whatever) where you live, go somewhere else" and acting as if I can just hop on over to Mars. I can't.

That is exactly what they are saying. Having control over your relative experience is the only thing people want.

As we all spend most of our time inside of browser interfaces its not a surprise we see app, features and interfaces move to that process portal to. (Online IDEs, Cloud, Photo editing, etc.) Sure you can use your solution but in general, as always, its whats most efficient for the masses.

Re: WebGPU Fundamentals

#143

Post by jimmySixDOF »

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.

But the web is where the stuff I want is. Just about everything else gets in the way.

Re: WebGPU Fundamentals

#144

Post by mpldr »

abirch wrote: post #82
chii wrote: post #30

Earlier quoted context omitted.

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.

Please, let me know which one!

Re: WebGPU Fundamentals

#145

Post by pmoriarty »

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…

What are the main obstacles they need to be overcome to make this a reality?

Re: WebGPU Fundamentals

#146

Post by illiarian »

flohofwoe wrote: post #35
illiarian wrote: post #22

Earlier quoted context omitted.

> Neither Firefox nor Safari are first, WebGPU is literally built in top of work done by Safari and Firefox.

Apple and Mozilla were the first to have prototypes (one "inspired" by Metal, the other by Vulkan), both looked quite different from the final WebGPU spec though.

--- start quote ---

On January 24, 2017, Khronos hosted an IP-free meeting dedicated to discussion of "WebGL Next" ideas, collided with WebGL working group meeting in Vancouver.[8] Google team presented the NXT prototype implementing a new API that could run in Chromium with OpenGL, or standalone with OpenGL and Metal. NXT borrowed concepts from all of Vulkan, Direct3D 12, and Metal native APIs. Apple and Mozilla representatives also showed their prototypes built on Safari and Servo correspondingly, both of which closely replicated the Metal API

--- end quote ---

(Note: Unlike Chrome, Apple and Mozilla followed the actual standards route: two independent implementations)

--- start quote ---

On February 7, 2017, Apple's WebKit team proposed the creation of the W3C community group to design the API. At the same time they announced a technical proof of concept and proposal under the name "WebGPU", based on concepts in Apple's Metal.

--- end quote ---

And so on https://en.wikipedia.org/wiki/WebGPU

Apple is literally at the forefront of this entire initiative with Mozilla close second. Chrome grudgingly agreed to join the others a full year later.

Re: WebGPU Fundamentals

#147

Post by kvark »

flohofwoe wrote: post #35
illiarian wrote: post #22

Earlier quoted context omitted.

> Neither Firefox nor Safari are first, WebGPU is literally built in top of work done by Safari and Firefox.

Apple and Mozilla were the first to have prototypes (one "inspired" by Metal, the other by Vulkan), both looked quite different from the final WebGPU spec though.

This isn’t correct. All 3 parties had prototypes. Mozilla’s first prototype was based on Metal and implemented in Servo. Then we (Mozilla) proposed a Vulkan-like API and had another WIP in Servo, but it was also thrown out.

Re: WebGPU Fundamentals

#148

Post by throwaway60134 »

mpldr wrote: post #140
jesse__ wrote: post #135

Earlier quoted context omitted.

Why exactly would programs running in web browsers not want the ability to access the most powerful piece of hardware in a users machine? WGPU unlocks an enormous amount of space for userland programs to explore. I agree there have been some questionable 'advancements' in the web spec recently (web workers as a solution to multithreading, for example, were hilariously inadequate for quite a while), but as far as I ca…

At least for me a browser should be an interactive document viewer. Not CAD, not file conversion, not writing OS images to an SD card, not generating GCode. Ingesting HTML, CSS, and JS and turning it into an interactive view of that XML document nothing more, nothing less.

[dead]

Re: WebGPU Fundamentals

#149

Post by depressedpanda »

jesse__ wrote: post #136
softfalcon wrote: post #81

Earlier quoted context omitted.

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…

From personal experience, if you're trying to make a game that cares about its frame rate, do not ever use the DOM for anything, ever. It routinely takes several frames to layout a single absolutely positioned element. I recommend the second option. Rasterize your font with stb_truetype to a bitmap, and draw quads yourself

I'm curious, isn't something like a HUD a perfect thing to render in a DOM overlay?

It shouldn't matter that much if it takes a few frames to layout and/or update your ammo count or whatever.

Re: WebGPU Fundamentals

#150

Post by kvark »

dist-epoch wrote: post #21
rvz wrote: post #14

[flagged]

The writing is on the wall. Firefox will ditch it's engine and just become a skin over Chrome, just like Edge did.

Gecko engine looks pretty healthy to me overall. And WebGPU in particular is the least of a concern, given that Firefox's implementation is based on wgpu [1], which has great community and a lot of users within and outside of Rust ecosystem. I'm confident Firefox can ship it soon (tm).

[1] https://github.com/gfx-rs/wgpu

Post reply on HN