3 ms·

If you need the GPU within the browser, then the user should be asking why? Why should they should provide such expensive resources to any third party?

dahart 8y ago
That’s a strange framing, I’m not sure I understand what you mean. The reason for WebGL is much faster graphics for me, I don’t ask why because I want GPU in the browser. Which third party are you talking about? What does the expense of a component have to do with anything? If you’re assuming a malicious GPU computation done without the user’s intent, maybe state that assumption, but that’s not what the parent thread was talking about. I’m certain that if GPU abuse were to become a thing, the browsers will immediately deny default access and request user permission, just like with audio. In the mean time, you can currently turn off GPU access in your browser settings if you’re afraid of something.
- nobodyandproud 8y ago
  The context here is the GPU js library, which is a general purpose computing using the GPU. Does this actually build on top of WebGL?
  - dahart 8y ago
    Yes, GPU.js is built on top of WebGL. So this exposes no new functionality, only new convenience. And yes, the context is GPU.js, general purpose compute for the GPU. That doesn't mean you're "providing" resources to any third party, right? The primary reason to want general purpose GPU compute in the browser are the same as the reasons to want GPU graphics - to make my own experience faster.
    - nobodyandproud 8y ago
      Thanks for clarifying. The security risks of WebGL has been discussed for years, so as concerning as it is that's not what I'm interested in. If you as the developer of a web application need the power of a GPU, then aside from graphics my question is why? The power draw of GPUs isn't trivial and the vast majority of browsers are hand-held devices. Aside from minimalist sites like hacker news, websites already drain my phone's battery very quickly. If it's meant for desktops, then to what end?
      - dahart 8y ago
        I guess there's two different topics in there. First, I agree completely that the web has insane amounts of bloat relative to the size of the content you request. Most people here would agree; frameworks and ads and analytics are crazy. This is true, but irrelevant to GPU.js. Second, GPGPU applications numerous. There are several listed here in the comments and on the GPU.js site, e.g., ray tracing, matrix multiplication. A really obvious one for HN would be neural network traing and/or inference, or any other optimization technique. It's useful for physics sims, video editing, and image processing. Here's a longer list: https://en.wikipedia.org/wiki/General-purpose_computing_on_graphics_processing_units#Applications https://en.wikipedia.org/wiki/General-purpose_computing_on_g... That's not to mention that it's just fun in the spirit of hacking to figure out how to use your systems in weird ways. The cool part about GPU.js is the GPU access with transparent CPU fallback - you get to write GPU-CPU agnostic code in javascript. It's neat that they implemented in javascript a way to cross compile javascript to a shader. You're right that the power draw of a GPU isn't trivial, but the watts per megaflop is lower than CPU, for well-crafted highly parallel compute applications, even on mobile devices. I don't imagine using GPU.js on a phone, my personal assumption is that GPU.js is mostly meant for developers playing around on desktops right now. The benchmark specs on the GPU.js page describe a desktop system.
nacs 8y ago
If you're doing any kind of graphics work, the GPU is actually the less "expensive resource" as it will do it faster and more efficiently. Any kind of <canvas> work, graphs/charts, browser games, animations, and video all will perform better with some GPU assistance. The alternative is run everything on a CPU and get a more limited experience and have your CPU maxed out to 100% a lot more.
schwartzworld 8y ago
Check out the examples on the three.js site, lightning fast 3d rendering. You can't do that on the cpu.

dahart 8y ago

That’s a strange framing, I’m not sure I understand what you mean. The reason for WebGL is much faster graphics for me, I don’t ask why because I want GPU in the browser. Which third party are you talking about? What does the expense of a component have to do with anything? If you’re assuming a malicious GPU computation done without the user’s intent, maybe state that assumption, but that’s not what the parent thread was talking about. I’m certain that if GPU abuse were to become a thing, the browsers will immediately deny default access and request user permission, just like with audio. In the mean time, you can currently turn off GPU access in your browser settings if you’re afraid of something.

nobodyandproud 8y ago
The context here is the GPU js library, which is a general purpose computing using the GPU. Does this actually build on top of WebGL?
- dahart 8y ago
  Yes, GPU.js is built on top of WebGL. So this exposes no new functionality, only new convenience. And yes, the context is GPU.js, general purpose compute for the GPU. That doesn't mean you're "providing" resources to any third party, right? The primary reason to want general purpose GPU compute in the browser are the same as the reasons to want GPU graphics - to make my own experience faster.
  - nobodyandproud 8y ago
    Thanks for clarifying. The security risks of WebGL has been discussed for years, so as concerning as it is that's not what I'm interested in. If you as the developer of a web application need the power of a GPU, then aside from graphics my question is why? The power draw of GPUs isn't trivial and the vast majority of browsers are hand-held devices. Aside from minimalist sites like hacker news, websites already drain my phone's battery very quickly. If it's meant for desktops, then to what end?
    - dahart 8y ago
      I guess there's two different topics in there. First, I agree completely that the web has insane amounts of bloat relative to the size of the content you request. Most people here would agree; frameworks and ads and analytics are crazy. This is true, but irrelevant to GPU.js. Second, GPGPU applications numerous. There are several listed here in the comments and on the GPU.js site, e.g., ray tracing, matrix multiplication. A really obvious one for HN would be neural network traing and/or inference, or any other optimization technique. It's useful for physics sims, video editing, and image processing. Here's a longer list: https://en.wikipedia.org/wiki/General-purpose_computing_on_graphics_processing_units#Applications https://en.wikipedia.org/wiki/General-purpose_computing_on_g... That's not to mention that it's just fun in the spirit of hacking to figure out how to use your systems in weird ways. The cool part about GPU.js is the GPU access with transparent CPU fallback - you get to write GPU-CPU agnostic code in javascript. It's neat that they implemented in javascript a way to cross compile javascript to a shader. You're right that the power draw of a GPU isn't trivial, but the watts per megaflop is lower than CPU, for well-crafted highly parallel compute applications, even on mobile devices. I don't imagine using GPU.js on a phone, my personal assumption is that GPU.js is mostly meant for developers playing around on desktops right now. The benchmark specs on the GPU.js page describe a desktop system.

nacs 8y ago

If you're doing any kind of graphics work, the GPU is actually the less "expensive resource" as it will do it faster and more efficiently. Any kind of <canvas> work, graphs/charts, browser games, animations, and video all will perform better with some GPU assistance. The alternative is run everything on a CPU and get a more limited experience and have your CPU maxed out to 100% a lot more.

schwartzworld 8y ago

Check out the examples on the three.js site, lightning fast 3d rendering. You can't do that on the cpu.