No post body was provided.
WebGPU – All of the cores, none of the canvas
11–20 of 137 posts
Re: WebGPU – All of the cores, none of the canvas
#12Is 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.
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.
Re: WebGPU – All of the cores, none of the canvas
#13With the "fun" to rewrite all WebGL shaders into WGSL.
You can use the SPIR-V compiler toolchain to just transpile from GLSL to WGSL :)
Re: WebGPU – All of the cores, none of the canvas
#14Will there be an http203 episode about this? ;-)
Re: WebGPU – All of the cores, none of the canvas
#15Earlier quoted context omitted.
Isn't there something like SciPy which you can run on WebGPU?
At this point, there are very few tools actually running on WebGPU, as it's too new. One to watch for sure is IREE, which has a WebGPU backend planned and in the works.
There is wonnx a rust based webgpu enabled onnx runtime for ml stuff.
Re: WebGPU – All of the cores, none of the canvas
#16WebGPU, 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.
Re: WebGPU – All of the cores, none of the canvas
#17WebGPU, 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.
One benefits is that web browsers have to respect a standard set of APIs which abstract the hardware and makes them all inter-operable (except the usual incompatibilities obviously).
Now POSIX was arguably successful, but it was limited in scope (not including the UI aspect of things). Also: Windows...
Additionally, the absence of that big global state which is the filesystem makes the development of portable applications way more easier. There's always been limitations to what browsers can do, but personally I don't regret iTunes, Outlook or all those desktop app advantageously replaced by SPAs. I can log from any computer/smartphone and I get my apps. No installation process, configuration, the usual missing/corrutped library/dlls, etc.
And the problem of data ownership is not a technical problem. If we didn't have browsers, software companies would have moved those data away from you and have desktop app access them remotely anyway.
I get that abstraction levels suck. But only if the cost/benefits ratio is bad. Java applet had awful UX AND they were slow. Now SPAs can be quite responsive and some of them a pretty cool to use.
Re: WebGPU – All of the cores, none of the canvas
#18WebGPU, 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, all the bare metal crashes/exploits
It's a goldmine. Think of all the future jailbreak entrypoints this will make possible.
Re: WebGPU – All of the cores, none of the canvas
#19Earlier quoted context omitted.
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.
Isn't there something like SciPy which you can run on WebGPU?
https://wgpu-py.readthedocs.io/en/stable/guide.html :
> As WebGPU spec is being developed, a reference implementation is also being build. It’s written in Rust, and is likely going to power the WebGPU implementation in Firefox. This reference implementation, called wgpu-native, also exposes a C-api, which means that it can be wrapped in Python. And this is what wgpu-py does.
> So in short, wgpu-py is a Python wrapper of wgpu-native, which is a wrapper for Vulkan, Metal and DX12, which are low-level API’s to talk to the GPU hardware.
So, it should be possible to WebGPU-accelerate SciPy; for example where NumPy is natively or third-partily CUDA-accelerated
edit: Intel MKL, https://Rapids.ai,
> Seamlessly scale from GPU workstations to multi-GPU servers and multi-node clusters with Dask.
Where can WebGPU + IDK WebRTC/WebSockets + Workers provide value for multi-GPU applications that already have efficient distributed messaging protocols?
"Considerable slowdown in Firefox once notebook gets a bit larger" https://github.com/jupyterlab/jupyterlab/issues/1639#issueco... Re: the differences between the W3C Service Workers API, Web Locks API, and the W3C Web Workers API and "4 Ways to Communicate Across Browser Tabs in Realtime" may be helpful.
Pyodide compiles CPython and the SciPy stack to WASM. The WASM build would probably benefit from WebGPU acceleration?
Re: WebGPU – All of the cores, none of the canvas
#20Question 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?
Depends what you do the analysis with. The state of the art is a neural network, and the best there are transformers which do parallelize (as opposed to the previous generation, LSTMs which don't parallelize as well)
The limiting factor is usually parallelism, to utilize a GPU well you need to be running something on the order of 10000 threads in parallel.