Hmm... I wouldn't want a random webpage to start mining bitcoin on my computer. How would we protect against that?
Feasibility of low-level GPU access on the Web
31–40 of 133 posts
Re: Feasibility of low-level GPU access on the Web
#32It 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…
You are being downvoted, but it is important to remember that graphics APIs were not developed with security as a first class requirement. They tend to be large, arcane, and often interfacing with large binary blob drivers on the system. Their threat surface is enormous. IMHO it is just a matter of time until exploits for WebGL and the like start showing up regularly.
Re: Feasibility of low-level GPU access on the Web
#33What 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).
So we are back at VRML?
Re: Feasibility of low-level GPU access on the Web
#34Earlier quoted context omitted.
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.
WebGL can cover 87.3% of game revenue.
Re: Feasibility of low-level GPU access on the Web
#35Canvas 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 s…
Canvas was introduced and inspired by Apple's drawing tech, so you might want to check that.
Re: Feasibility of low-level GPU access on the Web
#36WebGL 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
khronos said they were working on compute for webgl2, who knows when it will be ready though.
Re: Feasibility of low-level GPU access on the Web
#37Earlier quoted context omitted.
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.
> Easier implementation is the goal. There are currently only four companies working on a web implementation.
Easier implementation of a browser? You might find it interesting to see what Servo has chosen to implement and what they have not. Some things you'd think would be easily removable (such as document.write) turn out to not be so simple to skip.
One of the most valuable things about the Web is the care taken around backwards compatibility.
I do think it'd be quite interesting if you had a user agent that did the DOM differently (not sure what you have in mind specifically re: "documents didn't automatically gain the same privileges as applications") and focused just on providing a GL canvas and audio APIs.
I think you might find that these APIs aren't quite as nice when it comes to re-implementing things that CSS and DOM make easy, and it'd be hard for such a browser to really compete with existing browsers given the backwards-compat situation on the web (mandating GL would leave some devices behind, and web authors as a whole don't really adapt all that quickly).
In any case I think it might still be useful as a reference implementation / proof-of-concept on how minimal a web user agent can be, if it was just focused on hosting applications.
Re: Feasibility of low-level GPU access on the Web
#38i think the web browser is the modern terminal and it should make use of all capabilities of the device, including hardware accelerated rendering. i think the current webgl is too low level though and only needed if you want to make your own 3d engine. if it was a higher level 3d renderer it would be easier for browser wendors to make secure and optimize, and easier for developers to use.
Re: Feasibility of low-level GPU access on the Web
#39This 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…
> Like tomorrow someone will come with practical voxel based system instead of current abstract vector ones, what will we do?
For one thing, any new approach will still have to solve the same problems around data transfer and formats that make up a lot of current APIs.
And for another, no matter how good this hypothetical new approach is, the old one will still be around to handle existing content and workflows forever anyway.
Re: Feasibility of low-level GPU access on the Web
#40Earlier quoted context omitted.
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).
So we are back at VRML?
Which crashed and burned for a reason, it was incredibly pointless, current vr is just a novelty at a 2.0 stage