Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WebGPU – All of the cores, none of the canvas

surma.dev

Post reply on HN
Print view View original

121–130 of 137 posts

Re: WebGPU – All of the cores, none of the canvas

#121

Post by pjmlp »

j-pb wrote: post #69
dassurma wrote: post #32

Earlier quoted context omitted.

The WebGPU spec is currently edited by two Google employees and one Mozilla employee. I am not sure how to make sense of your accusation.

The author list and W3C document are pretty much irrelevant, the actual working group is what counts. After thinking about it some more, I've come to the conclusion that I've actually not been strong enough in my initial accusation, and that Apple is trying to smother any threat that WebGPU poses to its native App supremacy. The story is essentially: Apple wants SPIRV dead. Mozilla wants SPIRV alive. Google wants SPI…

> Mozilla and Google agree, because they'll all compile down to SPIRV anyways, except for Apple which will target Metal.

Nope, on Windows/XBox they will have to compile to DirectX, on PS3 to LibGNM and on the Switch to NVN.

Re: WebGPU – All of the cores, none of the canvas

#122

Post by javierluraschi »

faeyanpiraat wrote: post #2

Question for someone with gpu programming experience: is it feasible to analyze time series data (eg.: run a trading algorithm through a series of stock prices) in parallel (with the algorithms receiving different parameters in each core)? If not then what is the limiting factor?

We have a few examples of time series data processing in Hal9 with WebGL (no support for WebGPU just yet):

- Simple regression with TensorFlow.js: https://hal9.com/hal9/historic-temperature-analysis - LSTM with TensorFlow.js: https://hal9.com/hal9/bitcoin-prediction - ARIMA with Pyodide.js: https://hal9.com/hal9/ai-fundamentals-arima

If you have question or would be open to considering using Hal9 to do time series analysis in JavaScript, let me know! You can find me in Twitter at https://twitter.com/javierluraschi

Re: WebGPU – All of the cores, none of the canvas

#123

Post by autoexec »

prox wrote: post #59
wlesieutre wrote: post #56

Earlier quoted context omitted.

Already a thing, it's just been CPU based and now can be GPU based. Firefox (and probably other browsers) have systems to attempt to block them. https://blog.mozilla.org/futurereleases/2019/04/09/protectio... The people sneaking this shit into webpages don't care if it burns $1 of electricity and destroys your battery to generate $0.0000001 of Monero because all of those costs are paid by someone else.

Is there a toggle extension like I have for JS?

I'm keeping an eye out too. I've seen a few vulnerabilities mentioned already for this tech. This site (https://hacks.mozilla.org/2020/04/experimental-webgpu-in-fir...) suggests that setting the options “dom.webgpu.enabled = true” and “gfx.webrender.all = true” to false (where needed) could prevent it from running. I'm also guessing it's use will depend on javascript which I block by default.

Re: WebGPU – All of the cores, none of the canvas

#124

Post by autoexec »

dman wrote: post #16
superkuh wrote: post #9

WebGPU, all the bare metal crashes/exploits and none of the broad support. Browsers should not be operating systems and the move to make them so will end up making them just as exploitable as your host OS only much slower due to the additional abstraction layers.

That ship has long sailed.

Doesn't mean people can't drop anchor and get off the boat. Lots of terrible ideas were popular and later became uncommon.

Re: WebGPU – All of the cores, none of the canvas

#125

Post by autoexec »

bacan wrote: post #97

Another thing to turn off in FireFox. Already have WebRTC, WebGL, WASM, ServiceWorkers etc disabled. Most sites are so much faster without all this junk

I'm with you. It's obnoxious to have to disable a long list of things with every install, but if Firefox didn't support something everyone else does they risk driving people who want that functionality away. I don't mind the bloat as long as it's easily disabled and they go out their way to notify users of the risks when they don't have it disabled by default.

I want firefox to keep giving people the option to do whatever they want, I just don't want them forcing anything on people, making them more vulnerable by default, or not being clear about things they've added support for.

Re: WebGPU – All of the cores, none of the canvas

#127

Post by account42 »

shadowgovt wrote: post #39
skywal_l wrote: post #23

Earlier quoted context omitted.

You can always disable hardware acceleration in your browser.

That's a big red lever that disables all sites' ability to use WebGL also, isn't it? That kind of thing is the kind of thing I imagine one would want at site-by-site granularity.

I'm still hoping that someone will revive uMatrix and add new columns for GPU access and other webshittery.

Re: WebGPU – All of the cores, none of the canvas

#128

Post by account42 »

TurningCanadian wrote: post #64
shadowgovt wrote: post #7

Is this API going to have a permissions lock, like access to the video camera or microphone APIs do? If it doesn't, I'm not looking forward to the future where every website I visit tries to pull a big chunk of my graphics card to mine cryptocurrencies without my explicit authorization.

Couldn't you make the same argument about being able to perform computation on the CPU?

Yes, hence why extensions like NoScript and uMatrix exist(ed).

Re: WebGPU – All of the cores, none of the canvas

#129

Post by kvark »

Waterluvian wrote: post #115

Re: compute vs. Graphics pipelines: “and also considerably understates that these pipelines are physically different circuits in your GPU” Wait what?? Can someone fill me in? Why would they have different hardware? Compute is compute, even if the computer is mostly good at triangles.

Render pipelines use the same compute cores for running the shaders as of long ago. However, they also involve fixed-function pieces (some implemented in hardware) that compute shaders don’t have access to. Such as: rasterizer, blending, depth/stencil testing.

Re: WebGPU – All of the cores, none of the canvas

#130

Post by kvark »

flohofwoe wrote: post #50
dassurma wrote: post #13

Earlier quoted context omitted.

You can use the SPIR-V compiler toolchain to just transpile from GLSL to WGSL :)

Minor nitpick: this translation happens in separate libraries/tools which just make use of the SPIRVTools library for some SPIRV processing tasks, but not the actual translation to WGSL. Tint (Google, implemented in C++): https://dawn.googlesource.com/tint/ Naga (Mozilla(?), implemented mostly in Rust): https://github.com/gfx-rs/naga Both are a bit similar to SPIRV-Cross, except that they also support WGSL.

Naga (a community project) translates GLSL directly into WGSL, unlike other tools.
Post reply on HN