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…
Feasibility of low-level GPU access on the Web
11–20 of 133 posts
Re: Feasibility of low-level GPU access on the Web
#12Re: Feasibility of low-level GPU access on the Web
#13It 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
#14Earlier 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?
Re: Feasibility of low-level GPU access on the Web
#15For 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.
Re: Feasibility of low-level GPU access on the Web
#16I 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…
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
#17For 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.
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
#18Re: Feasibility of low-level GPU access on the Web
#19Few sites even use WebGL for anything interesting.
Re: Feasibility of low-level GPU access on the Web
#20As 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?