Live data from Hacker News

Feasibility of low-level GPU access on the Web

kvark.github.io

21–30 of 133 posts

Re: Feasibility of low-level GPU access on the Web

#21

Maybe GPUs need to be fundamentally redesigned to allow multi-user access with enforceable security boundaries. I'm sure this would be highly non-trivial to implement, but it would be great for other scenarios like shared access to GPU compute resources in "the cloud".

This is called GPU virtualization, and there have been experiments ("Sugar" [1]) of using it for WebGL. We looked into it, consider it promising but not urgent. It addresses some of the security concerns at the cost of performance (and implementation complexity), but the portability issues are unchanged.

[1] http://newport.eecs.uci.edu/~amowli/hpcfactory/publication/a...

Re: Feasibility of low-level GPU access on the Web

#22
post #20

This situation reminds me days when we, at W3C HTML5 WG, were trying to sneak SQL specification into HTML5 "umbrella". And one particular flavor of it - the SQLite's SQL as it was defined at the moment of writing. Haven't got through for many good reasons as we know. As of GPU exposure to the Web ... It makes sense only when we will have stable and unified GPU abstraction. As for now DirectX.12, Vulcan and Metal are…

This is a bit of a rambling mess, but to just make one point: the winner has been chosen. Android is implementing Vulkan, and so Vulkan it will be.

Re: Feasibility of low-level GPU access on the Web

#24
post #23

WebGL 2 already gives you pretty good GPU gfx & compute. The use is limited by implementation quality in browsers. Let's give it time.

WebGL 2 is based on OpenGL ES 3.0, it doesn't give you compute. Compute shaders were added in OpenGL ES 3.1

Re: Feasibility of low-level GPU access on the Web

#25

Maybe GPUs need to be fundamentally redesigned to allow multi-user access with enforceable security boundaries. I'm sure this would be highly non-trivial to implement, but it would be great for other scenarios like shared access to GPU compute resources in "the cloud".

That has existed for over a decade. In fact that's sort of the point of Vulkan, et al.; with all user code being behind an MMU context, it's safe to provide a more console like 'bare metal' API. There are bugs, but the infrastructure is all there. The end goal is that you can only crash your own process.

The issue with this in the browser is that the API isn't part of the JavaScript/WebASM, and just exposing it in the same way will allow you to subvert the sandboxing of the VM>

Re: Feasibility of low-level GPU access on the Web

#26
Canvas and webgl is lovely in the way it quickly lets you get something on the screen... Pixel pushing on canvas is, easy and accessible.

It makes me wonder if anyone has created some sort of port to a standalone app with no browser involved where you could use javascript/canvas-api/webgl to draw pixels on a canvas-like surface... without the fatness of the browser. Just spawning some window, that would be a lovely scripting/game-dev environment, maybe with some sdl-bindings or whatever. Anyway just rambling, does such a project exist? Anyone knows? :)

Re: Feasibility of low-level GPU access on the Web

#27
post #19

What problem does this solve for the end user? Few sites even use WebGL for anything interesting.

Most of these fads seem to be driven not by what's good for the user but what's good for the advertiser and the developer.

Low level GPU access will just make it easier for them to run montero miners on my browser.

Re: Feasibility of low-level GPU access on the Web

#28
post #19

What problem does this solve for the end user? Few sites even use WebGL for anything interesting.

The future of AR/VR exists in 3D worlds. If the web wants to be part of that future, developers will need access powerful 3D APIs. Otherwise, the web will miss another tech wave like it missed mobile (as native mobile was the clear winner over web mobile).

Re: Feasibility of low-level GPU access on the Web

#29
post #20

This situation reminds me days when we, at W3C HTML5 WG, were trying to sneak SQL specification into HTML5 "umbrella". And one particular flavor of it - the SQLite's SQL as it was defined at the moment of writing. Haven't got through for many good reasons as we know. As of GPU exposure to the Web ... It makes sense only when we will have stable and unified GPU abstraction. As for now DirectX.12, Vulcan and Metal are…

This is a bit of a rambling mess, but to just make one point: the winner has been chosen. Android is implementing Vulkan, and so Vulkan it will be.

It will be Vulcan and Dx12. Microsoft is nothing if not a stubborn 800 lbs gorilla.

Re: Feasibility of low-level GPU access on the Web

#30
post #29

Earlier quoted context omitted.

This is a bit of a rambling mess, but to just make one point: the winner has been chosen. Android is implementing Vulkan, and so Vulkan it will be.

It will be Vulcan and Dx12. Microsoft is nothing if not a stubborn 800 lbs gorilla.

Eh, not for WebGL it won't. Nobody even implements DX other than high-powered desktop GPUs.

Will it live on? Sure, we will still have games and Xboxes. But if you're going to pick a standard that can work on mobile and desktop, there is no contender other than Vulkan.

Post reply on HN