Live data from Hacker News

Feasibility of low-level GPU access on the Web

kvark.github.io

71–80 of 133 posts

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

#71
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…

HTML and CSS are slowly losing ascendancy as the main render surface for web apps. The canvas provides a standard pixel buffer for both JS and compiled applications, making HTML's limitations no longer a restriction.

The whole point of the web was not to have people write directly to bitmaps, to leave the presentation up to the rendering platform.

In the quest for eye candy we're losing what made the web great to begin with.

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

#72
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.

I've gotten pretty far doing exactly this (only-those-apis browser in Node): https://github.com/modulesio/exokit

Not released yet, but there's basic Windows, macOS, Linux, Android and iOS support. Contributions welcome!

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

#73
post #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.

Monero isn't efficiently mined on GPUs (it works better on CPUs which is why it's so popular for browser mining already), but other cryptos with equihash algorithms, sure.

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

#74
post #44

Well, as a small developer I'd love to see a higher-level, easier-to-use API (than Vulkan) that can be used as a modern, cross platform replacement for OpenGL. If it could be used both in a browser and standalone even better. If it was available outside of a browser (even as a Vulkan/Metal wrapper), I think it could become a no-brainer replacement for where OpenGL ES is used today. I understand that engine developers…

If you are making a commercial product Vulkan + MoltenVK should be perfectly serviceable as a target. There are also free software attempts to make a wrapper.

At this point, so long as Apple is in your target market, there will never be an everywhere API because Apple does not want there to be one. The whole point of Metal is to make your life harder so developers currently writing for Apple first are less likely to port their software elsewhere.

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

#75
post #70
post #63

Earlier quoted context omitted.

I don't believe that's true for any modern browsers. They all use hardware accelerated rendering in the common case of drawing to a canvas that will be composited on-screen, and make a copy into process memory only when you access the pixels with a call like getImageData().

Composite operations ( https://developer.mozilla.org/en-US/docs/Web/API/CanvasRende... ) are achievable only on bitmap/frame buffers. And OpenGL's frame buffers are not famous for their performance.

I was referring to compositing the DOM objects onto the screen, which is GPU-accelerated in most cases.

The internal canvas compositing operations you mention are also GPU-accelerated in most cases.

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

#76
post #44

Well, as a small developer I'd love to see a higher-level, easier-to-use API (than Vulkan) that can be used as a modern, cross platform replacement for OpenGL. If it could be used both in a browser and standalone even better. If it was available outside of a browser (even as a Vulkan/Metal wrapper), I think it could become a no-brainer replacement for where OpenGL ES is used today. I understand that engine developers…

Maybe I could have explained this better since it's getting downvoted. Right now the two big modern graphics APIs are Metal (iOS / Mac) and Vulkan (Win / Linux / Android). These aren't the only ones, there are more for game consoles, UWP apps, etc, but they are arguably the most important ones.

Metal and Vulkan are not at the same level of abstraction. If you look up the code needed to draw a triangle on the screen (maybe the most basic graphics task), it is much, much more long and difficult to do it in Vulkan than Metal. Vulkan is a lower-level API. It gives engine developers more flexibility, at the cost of making basic things time-consuming and complicated.

OpenGL was the previous cross platform API. WebGL is almost identical to OpenGL. OpenGL still runs on Mac / iOS, but Apple has stopped supporting newer versions. The newer versions of OpenGL have closed the gap some with Vulkan and Metal (it won't catch up entirely, but it added some important features like compute shaders and it's easier to use it efficiently). OpenGL is still easier to use than Vulkan. The problem is the newer versions are not cross-platform, since Apple wants to focus on Metal.

Apple does not want to support Vulkan. Metal came out before Vulkan did, and it is a higher-level API. It's arguable if Apple should support it or not, but that's how it is. Microsoft also wants to focus on DirectX 12 (their API).

I was making the argument that a higher level API, Metal-style, would be a good base for the new web standard. Metal couldn't be used directly, at the very least it would have to be changed from Swift/Obj-C. But the idea of roughly basing it on Metal as mentioned in the article doesn't seem unreasonable, even Vulkan was based on a previous AMD technology called Mantle.

A low-level standard like Vulkan is hard to use directly, its adoption will depend mostly on people using frameworks / engines that use Vulkan. It's possible that due to its low-level nature there would be some performance advantage, although games using Metal also seem to get good performance on iOS. The disadvantage of Vulkan is that it is much harder to use than WebGL.

A fair amount of the WebGL content is not web specific. It is possible to write OpenGL content and compile it for desktop / mobile and the web. The most popular game engines, Unity and Unreal, both support compiling to the web and desktop from the same codebase.

In my view, there is no good replacement for OpenGL, now that new versions are not cross platform. Vulkan is much more work and does not work on Apple platforms, while Metal is easier but only works on Apple platforms. If they could provide a standard that is both easy and cross platform (by providing a C API library in addition to the web standard), it would provide the best of both worlds. The main downside is that it might leave some performance on the table compared to a low level API, and it would be yet another standard (which is why it would be important to provide a native library too, so developers have the choice of coding to only one API).

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

#77
post #69

Earlier quoted context omitted.

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.

1. Vulkan is an optinal 3D API on Android 7.0 and later devices. 2. Vulkan is not allowed on UWP apps 3. Even on Switch, Vulkan is not the primary 3D API.

1. It is mandatory if the device claims to support VR mode;

2. Nobody (in Joel's on Software sense) is writing high performance 3D UWP apps anyway.

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

#78
post #74
post #44

Well, as a small developer I'd love to see a higher-level, easier-to-use API (than Vulkan) that can be used as a modern, cross platform replacement for OpenGL. If it could be used both in a browser and standalone even better. If it was available outside of a browser (even as a Vulkan/Metal wrapper), I think it could become a no-brainer replacement for where OpenGL ES is used today. I understand that engine developers…

If you are making a commercial product Vulkan + MoltenVK should be perfectly serviceable as a target. There are also free software attempts to make a wrapper. At this point, so long as Apple is in your target market, there will never be an everywhere API because Apple does not want there to be one. The whole point of Metal is to make your life harder so developers currently writing for Apple first are less likely to…

Yeah that seems like that might be the best option right now, and it doesn't look like it will be too expensive either. What I probably would like more is the reverse, a Metal wrapper for Vulkan, since it seems so much easier to get started with Metal. Too bad Metal is a Swift/Obj-C API so it's not straightforward how to make it cross platform.

I don't know how much bad faith I want to assume on Apple's part, since there are probably some legitimate technical reasons why they don't want to support a lower level API (and they came out with Metal first). Vulkan is such a pain to use anyway that it's probably mostly used by engine developers who generally don't have a problem supporting multiple APIs like Metal / DirectX etc.

But at the very least, it would be nice if they upgraded their OpenGL version, since they already support that and it's only them holding back some of the newer features.

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

#79

There is an upcoming Xbox game (Crackdown 3) that uses web-based GPU processing to share compute amongst players in a multiplayer game.

What does that even mean? It's an Xbox, they all literally have the same variations of hardware. There aren't 8000 different build specs, there's at most, what 8? How could compute sharing provide any possible enhancement in experience at all? If anything, it's eating frame budget and it shouldn't.

When it was first announced, there was talk of off-loading certain tasks to (presumably) Azure. That may be what OP is thinking of.

I'd also wonder if you could share the power of any Xbox One Xs connected to a multiplayer session, given the gap between an original Xbox One and the X is rather large (seems like it'd be far more trouble than it's worth though).

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

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

Can you elaborate on the arguments against a dialect of SQL being available for use with local storage? I can only think of arguments in favour of it. Would be good to understand the grounds on which the idea was dropped.

Post reply on HN