Live data from Hacker News

Feasibility of low-level GPU access on the Web

kvark.github.io

101–110 of 133 posts

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

#101
post #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 s…

I suggest https://love2d.org/

I think you meant this, love2d running in the browser.

http://tannerrogalsky.com/mari0/

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

#102
post #78
post #74

Earlier quoted context omitted.

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 t…

Vulkan is such a pain that one of the GDC 2018 talks is "Getting explicit: How hard is Vulkan really?".

https://www.khronos.org/news/events/gdc-2018

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

#103
post #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 (…

I would add to your remark that the very fact that OpenGL ES ever took off was because of Apple.

Before iOS, most mobile devices were having their own experiments with 3D APIs, Nokia N95 was the very first with OpenGL ES compatibile GPU, but it was thanks to iOS games that it ever took off.

Apple was also pursuing Quickdraw 3D before the NeXT acquisition, so not too keen on OpenGL anyway.

Their OpenGL's adoption was mostly survival related, now they are back on top, they can afford to dictate their 3D APIs just like all other console vendors.

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

#104

I don't understand why this is a priority when WebGL is still so rough. Maybe we wouldn't need a new API for performance if WebGL worked better. There seems to be lots of room for improvement. My WebGL programs were much slower and were harder to write than the native versions of the same programs. We should also probably sort out the native low-level APIs before setting the standard for the web, because otherwise we…

Because WebGL is an evolutionary dead end, for a variety of reasons. The initial idea was to track OpenGL ES, but that isn't really true anymore. Because of Windows, WebGL has to stick to a subset that can be easily translated to Direct3D. Because of GPU process sandboxing, anything that flows back from GPU to CPU is a huge synchronization problem. On top of that, mobile GPU drivers continue to suck badly, which means most of the extensions that were supposed to expand WebGL's scope into this decade are still out of reach, with 50% or less support in practice.

On the flipside, the native low-level APIs have all diverged. Vulkan, D3D12 and Metal each made different decisions, so it's pretty much inevitable that a 4th standard will have to be created to unify them. It will probably be higher level than any of the 3, and it will still be subject to strong sandboxing limitations.

Personally I think the big issue is that people stare themselves blind on the traditional graphics pipeline. Modern renderers have evolved past this, with various compute-driven and/or tiled approaches common place now. They're a nightmare to implement against current APIs, because a small change in strategy requires a rewrite of much of the orchestration code. The job of figuring out how to map your desired pipeline onto the hardware's capabilities should be the job of a compiler, but instead people still do it by hand. Plus, for GPU compute-driven graphics to be useful for interactive purposes beyond just looking pretty (i.e. actual direct manipulation), you absolutely need to be able to read back structured data efficiently. It's not just about RGB pixels.

There's an immense amount of potential locked inside, but the programming model is a decade or two out of date. Only AAA game companies and the vendors themselves have the resources to do novel work under these constraints. Everyone else has to throw together the scraps. Even the various attempts at LISPy GPU composition fall short, because they don't attempt to transcend the existing pipeline.

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

#105
post #97

Earlier quoted context omitted.

The majority of game engines scene graphs are retained mode 3D abstractions. Everyone thinks that they can do better with an immediate mode API, then we start building some kind of data structure to track down what needs to be drawn and when, with the result being similar to the traditional joke of half-implemented Lisp or ORMs, but applied to retained mode rendering. Sure, some experts manage to get it right, and th…

But, the real difficulty seems to be writing a retained mode abstraction that actually fits everyone's use case. I can't think of a retained mode API that works as well for RTS games as it does for FPSs, to say nothing of non-game uses like CAD.

What are the issues you think Unity, Unreal, CryEngine, Cocos2d-X, ligGDX, OGRE, SceneKit have with RTS rendering?

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

#106
post #3

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

If you just care about GPU compute and not much about the shape of the API or it's overhead, then something like OpenGL ES 3.1 Compute Shaders or WebCL would be much easier to reach than WebGPU, technically.

Mozilla won't support WebCL in favor of compute shaders, but that announcement has been over 4 years ago and there still is no general compute in browsers: https://bugzilla.mozilla.org/show_bug.cgi?id=664147

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

#107
post #94

Earlier quoted context omitted.

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

The OpenGL compute shader feature is not needed for doing GPU compute. It's just another type of shader that is not connected to other GL rendering that may be happening at the same time. People have been going GPGPU with the traditional types shaders for a long time. And WebGL 2.0 is a huge upgrade from 1.0 from a GPGPU point of view. Also, a compute shader extension may be coming[1] for WebGL 2.0, it's mentioned in…

> The OpenGL compute shader feature is not needed for doing GPU compute

but it is needed for doing GPU compute efficiently for many workloads.

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

#108

I don't understand why this is a priority when WebGL is still so rough. Maybe we wouldn't need a new API for performance if WebGL worked better. There seems to be lots of room for improvement. My WebGL programs were much slower and were harder to write than the native versions of the same programs. We should also probably sort out the native low-level APIs before setting the standard for the web, because otherwise we…

Because WebGL is an evolutionary dead end, for a variety of reasons. The initial idea was to track OpenGL ES, but that isn't really true anymore. Because of Windows, WebGL has to stick to a subset that can be easily translated to Direct3D. Because of GPU process sandboxing, anything that flows back from GPU to CPU is a huge synchronization problem. On top of that, mobile GPU drivers continue to suck badly, which mean…

I would like to hear more about this. I was quite surprised how difficult things were when I started dabbling in Opengl and I thought that there has to be a better way. I know that there are libraries that build on top of Opengl and the like, but then always its a sacrifice of the power that you could have. It seems weird to me that it is so difficult because conceptually it seems to me that the model could be closer to the CPU/Memory model that everyone is already familiar with. You just have some RAM and some processor(s) that are going to do some computations right? Although I guess what really makes it a mess is that there needs to be a connection between what the GPU and the CPU are doing. I don't know, I was a bit surprised by how difficult it was. Perhaps I just don't understand it well enough.

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

#110
post #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 s…

I built exactly that a few years ago: V8 with WebGL bindings that passed through to OpenGL ES. It was to enable WebGL experiences on the GearVR, where a full browser wouldn't cut it.

I've got sample using an OS X window but it should be easy enough to do the same for Windows

It's been sitting in a private repo since then but I can give you access if you'd like

That being said, I think a better alternative for a thin graphics scripting environment would be haxe with Lime or snowkit (which provides OpenGL, SDL and windowing). I've used these in the past and loved working then

Post reply on HN