One request for the author: Please don't hide the scroll bars on websites you make like this!
WebGPU – All of the cores, none of the canvas
21–30 of 137 posts
Re: WebGPU – All of the cores, none of the canvas
#22Question 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?
Yes, in fact GPUs are perfect for this. Here is a Monte Carlo financial simulation I built in WebGL 2. https://james.darpinian.com/money/ (Warning, programmer UI) It performs one million Monte Carlo runs instantly every time you move a slider. Each run is one execution of a pixel shader and they all happen in parallel.
WebGPU will make this kind of thing more accessible. It's kind of a pain to do it in WebGL, but even so it's still totally possible and worthwhile because you can easily get 20 times the performance in many cases and handily beat native CPU code even on the web.
Re: WebGPU – All of the cores, none of the canvas
#23Earlier 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.
You can always disable hardware acceleration in your browser.
Re: WebGPU – All of the cores, none of the canvas
#24Question 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?
GPUs are largely best suited for providing high throughput for doing similar computations across wide datasets. So if you can break down your algorithm into a series of steps which are largely independent and have limited flow-of-control it might be well suited to the task. If you need to have a lot of random access, or branching logic, it may not work so well. But often times it's possible to re-structure an algorithm designed for CPU to perform better on GPU.
But how many stocks even are there? You might not even have enough parallel operations to saturate a modern GPU.
Out of curiosity, why use WebGPU for this? If you're really trying to do something high performance, why not reach for something like CUDA?
Re: WebGPU – All of the cores, none of the canvas
#25If I'm already familiar with Rust, how is WebGPU as an introduction to graphics programming if you aren't already familiar with any of the backends that it wraps? Should I try just learning Vulcan first? Is the abstraction layer just going to introduce additional confusion for a newbie?
Re: WebGPU – All of the cores, none of the canvas
#26WebGPU is a textbook case of Embrace Extend Extinguish performed by Apple to kill Kronos and SPIRV, and everybody is cheering it on. Crazy.
Re: WebGPU – All of the cores, none of the canvas
#27For those looking for a complete 3D engine already supporting WebGPU and with a WebGL fallback if needed, there is BabylonJs (you'll need the 5.0 version still in the release candidate state) : https://doc.babylonjs.com/advanced_topics/webGPU/webGPUStatu...
ThreeJs is alwo working on its WebGPU renderer
Re: WebGPU – All of the cores, none of the canvas
#28If I'm already familiar with Rust, how is WebGPU as an introduction to graphics programming if you aren't already familiar with any of the backends that it wraps? Should I try just learning Vulcan first? Is the abstraction layer just going to introduce additional confusion for a newbie?
"Is the abstraction layer just going to introduce additional confusion for a newbie?"
As a newbie you probably don't want to deal with WebGPU directly, but rather use (wait for) a framework, that takes care of the details.
Re: WebGPU – All of the cores, none of the canvas
#29Is 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.
While I understand why it's necessary, I feel that the UX of security needs a serious overhaul. It seems like an increasing share of the time I spend using technology involves jumping through hoops.
Re: WebGPU – All of the cores, none of the canvas
#30If I'm already familiar with Rust, how is WebGPU as an introduction to graphics programming if you aren't already familiar with any of the backends that it wraps? Should I try just learning Vulcan first? Is the abstraction layer just going to introduce additional confusion for a newbie?
I think one of WebGPU's greatest strengths is learning, as you can get started pretty easily, and you actually learn a modern approach to GPU. Vulkan requires a significant amount of boilerplate just to establish a connection to the GPU and set up basic resources like the ability to allocate buffers. In WebGPU, the latter is one or two lines of code.
That said, there are some really nice learning resources for Vulkan as well, so if you're motivated and determined, it's also not a bad way to learn modern GPU.