Live data from Hacker News

Feasibility of low-level GPU access on the Web

kvark.github.io

11–20 of 133 posts

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

#11
post #7

It has same downside as WASM. Running precompiled bytecode is a bad for security as it always been. It was no more than a year when a remotely exploitable WASM hole was exposed (derivatives of Spectre and co.) Knowledgeable people told that ISA level hole that can be exploited remotely over the web will be "a one minute global IT disaster" if somebody would resort to propagating it through a big adnet or paid traffic…

Weren't Meltdown/Spectre exploitable via Javascript?

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

#12
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".

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

#13
post #11
post #7

It has same downside as WASM. Running precompiled bytecode is a bad for security as it always been. It was no more than a year when a remotely exploitable WASM hole was exposed (derivatives of Spectre and co.) Knowledgeable people told that ISA level hole that can be exploited remotely over the web will be "a one minute global IT disaster" if somebody would resort to propagating it through a big adnet or paid traffic…

Weren't Meltdown/Spectre exploitable via Javascript?

Yes

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

#14

Earlier quoted context omitted.

How many people do you think are actually interested in running the client in browser? I have Folding@Home on about 5-6 machines and I can't imagine a situation where I could run a web client but not a full client.

Chromebooks?

Those are pretty woefully underpowered for folding..

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

#15

For the Folding@home project we would love to have GPU compute access widely available from the browser.

How many people do you think are actually interested in running the client in browser? I have Folding@Home on about 5-6 machines and I can't imagine a situation where I could run a web client but not a full client.

It's not an incredibly common use case, but many computers exist simply to show a dashboard or visualization. It would be excellent to say "drop this script tag on your page" and you instantly turn that Mac Mini into less of a waste.

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

#16
post #8
post #4

I have this idea that if they split off WebAssembly, WebGL and WebAudio into a external format for applications it would be easier to implement than a full browser.

You could probably do this now as a standalone Node app, if you want more explicit control over which APIs are available and where code can be run from. The browser is indeed quite complex (and not just because of the massive historical baggage), but its job is to give the user control while safely downloading untrusted code and running it locally. So, if your goal is to just have a simple standalone app I think you…

Easier implementation is the goal. There are currently only four companies working on a web implementation.

Also, I think users would have more control if documents didn't automatically gain the same privileges as applications.

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

#17

For the Folding@home project we would love to have GPU compute access widely available from the browser.

How many people do you think are actually interested in running the client in browser? I have Folding@Home on about 5-6 machines and I can't imagine a situation where I could run a web client but not a full client.

It isn't for you. It is for the person who can open a tab, but doesn't want to run a full client. Installation, sandboxing, laziness, etc.

A university or corp could push a tab open script to thousands of desk tops, while they wouldn't push Folding@Home client.

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

#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 close but different.

Like the WebGL that is (more or less unified) OpenGL. But even that looks too foreign to HTML/CSS/script - immediate mode rendering in architecturally retained display model of web documents.

And conceptually: HTML5 umbrella is large but not infinite. 3D rendering is too far from HTML "endless flat text tape" model.

I remember those days when browser was used as a component delivery platform for stuff that does not fit into DOM and structured yet styled text. That was conceptually the right way "to grasp the immensity".

These days, with WebAssembly, we have another incarnation of the idea and I think GPU functionality belongs to it rather than to HTML. GLSL to be expressed in WebAssembly bytecode terms but not in JS.

Web standards have to be backward compatible and I doubt that current still ugly GPU paradigms will survive on the long run. Like tomorrow someone will come with practical voxel based system instead of current abstract vector ones, what will we do?

Post reply on HN