Live data from Hacker News

WebGPU – All of the cores, none of the canvas

surma.dev

51–60 of 137 posts

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

#51
post #26

WebGPU is a textbook case of Embrace Extend Extinguish performed by Apple to kill Kronos and SPIRV, and everybody is cheering it on. Crazy.

WebGPU has almost nothing in common with Apple's proposal (which was essentially "WebMetal", while WebGPU is basically the common subset of Vulkan, D3D12 and Metal).

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

#52
post #26

WebGPU is a textbook case of Embrace Extend Extinguish performed by Apple to kill Kronos and SPIRV, and everybody is cheering it on. Crazy.

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 WebGPU Shading Language spec is edited by Google and Apple, Mozilla were the ones proposing straight SPIRV and are not among the editors in this case.

Still doesn't make any sense but it has nothing to do with who the editors are.

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

#53
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.

There's very little that GPUs can do that CPUs can't do so far as exploitation is concerned. The GPU driver runs in a sandboxed userland process just like the browser engine does, and the GPU respects process isolation just like the CPU does. There is no “bare metal” here!

Now, sure, there must be plenty of memory-safety issues in GPU drivers, but why find an exploit in a driver only some users have installed, when you can find an exploit in the browser everyone has installed? The GPU driver exploit doesn't give you higher privileges.

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

#54
post #10

With the "fun" to rewrite all WebGL shaders into WGSL.

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

Yes I know, even more fun dealing with additional kludges, because 3D on the Web versus native doesn't have enough of them already.

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

#55
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.

WebGPU has the same sandboxing in place as WebGL, e.g. despite the name there is no "direct GPU access" (minus any implementation bugs of course, which will hopefully be ironed out quickly).

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

#56

Am I understanding this right, that websites can now run a crypto miner in the background when I visit them?

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.

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

#57
post #8

Earlier quoted context omitted.

It's already the case. Any web page can use WebGL1/2 for general computation. As the author said: > Using GPUs for calculations of any kind is often called General-Purpose GPU or GPGPU, and WebGL 1 is not great at this. If you wanted to process arbitrary data on the GPU, you have to encode it as a texture, decode it in a shader, do your calculations and then re-encode the result as a texture. WebGL 2 made this a lot…

True, but this API will make that use case simple and obvious. Given the tradeoffs, probably worth it for user agents to permission-gate it.

I think the problem is presenting this to users in terms they’ll all understand. “This site wants to do a special kind of processing”? “Use more resources”? I can’t think of many good answers. Anything involving the term “GPU” is immediately going to confuse most.

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

#58

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?

This depends on the algorithm. If it has lots of branching and control flow, then it's unlikely to run well. If it's based on something like FFT or any sort of linear algebra really, then it should run really well. WebGPU is accessible enough maybe you should try it! You'll learn a lot either way, and it can be fun.

Since you mentioned FFT, I wondered whether GPU-based computation would be useful for audio DSP. But then, lots of audio DSP operations run perfectly well even on a low-end CPU. Also, as one tries to reduce latency, the buffer size decreases, thus reducing the potential to exploit parallelism, and I'm guessing that going to the GPU and back adds latency. Still, I guess GPU-based audio DSP could be useful for batch processing.

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

#59

Am I understanding this right, that websites can now run a crypto miner in the background when I visit them?

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?
Post reply on HN