Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Feasibility of low-level GPU access on the Web

kvark.github.io

Post reply on HN
Print view View original

121–130 of 133 posts

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

#121

Post by zxxon »

jacquesm wrote: post #71
colordrops wrote: post #42

Earlier quoted context omitted.

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.

It's not about eye-candy, the Web has become an application platform (against all resistance) and it can't thrive on standards bodies to deliver every bit and piece required. Even in 2018, web applications are shunned by many professionals for their poor quality and performance.

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

#122

Post by slavik81 »

stillkicking wrote: post #104
slavik81 wrote: post #89

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 agree, yet I still don't understand how WebGPU is going to get buy-in from Apple and Microsoft if previous attempts at defining cross-platform APIs could not. Any web API will be open and cross-platform. If WebGPU is well-designed, it could very well be adopted as the next OpenGL.

I would rather target WebGPU and write my program once rather than implement my logic three times in Metal, DirectX and Vulkan. But, Apple and Microsoft don't want me doing that, so why would they support WebGPU?

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

#123

Post by pjmlp »

slavik81 wrote: post #122
stillkicking wrote: post #104

Earlier quoted context omitted.

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 agree, yet I still don't understand how WebGPU is going to get buy-in from Apple and Microsoft if previous attempts at defining cross-platform APIs could not. Any web API will be open and cross-platform. If WebGPU is well-designed, it could very well be adopted as the next OpenGL. I would rather target WebGPU and write my program once rather than implement my logic three times in Metal, DirectX and Vulkan. But, App…

These discussions always forget that Sony and Nintendo are also interested parties in what concerns 3D APIs.

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

#124

Post by Marat_Dukhan »

fulafel wrote: post #94
Marat_Dukhan wrote: post #24

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…

It is possible to perform some computations using OpenGL ES 3.0 / WebGL 2.0, but many types of operations (e.g. anything that involves random-access writes) are impossible, and many others (anything that normally requires shared memory) are very inefficient. Programming GPU through WebGL 2.0 is akin to programming desktop GPUs pre-CUDA: it is too intricate to take off.

Compute shader extension for WebGL 2.0 would be cool, but it would require to port a large part of OpenGL ES 3.1: OpenGL ES 3.0 / WebGL 2.0 doesn't include even random access buffers (SSBOs)

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

#125

Post by indemnity »

sitkack wrote: post #99
thristian wrote: post #84

Earlier quoted context omitted.

The lesson of the Web is that when you expose some interface for people to use, they will start depending on documented features, undocumented features, and downright bugs of the first popular implementation. Second and subsequent implementations will need to spend a bunch of time reverse-engineering those bugs so they can be documented and reliably implemented in future so that existing websites keep working. The on…

The W3C attempted to say version X.Y.Z of SQLite will be the SQL standard for the web, mandating 1) that it be frozen in time 2) that the only way to be compliant was to put SQLite into all browsers, bit for bit, there would be no other way to be compliant. As much as I wanted it, and was bummed that Mozilla protested so much, they were/did/are doing the right thing by saying that SQLite cannot be used as a standard…

As someone who works on a product which compiles SQLite to JS to read a SQLite based file format in the browser - this is a terrible, terrible “solution” and doesn’t scale for files larger than X MB, where X is the device dependent limit based on memory available to the browser.

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

#126

Post by sitkack »

indemnity wrote: post #125
sitkack wrote: post #99

Earlier quoted context omitted.

The W3C attempted to say version X.Y.Z of SQLite will be the SQL standard for the web, mandating 1) that it be frozen in time 2) that the only way to be compliant was to put SQLite into all browsers, bit for bit, there would be no other way to be compliant. As much as I wanted it, and was bummed that Mozilla protested so much, they were/did/are doing the right thing by saying that SQLite cannot be used as a standard…

As someone who works on a product which compiles SQLite to JS to read a SQLite based file format in the browser - this is a terrible, terrible “solution” and doesn’t scale for files larger than X MB, where X is the device dependent limit based on memory available to the browser.

Those memory limits are independent of and orthogonal to SQLite, but I totally understand the frustration.

https://www.html5rocks.com/en/tutorials/offline/quota-resear...

https://developer.chrome.com/apps/offline_storage

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

#127

Post by jcoffland »

gambiting wrote: post #5
jcoffland wrote: post #2

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.

A fair number of people are already running the Chrome NaCl client in their browsers but it is CPU only.

http://folding.stanford.edu/nacl

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

#128

Post by vetinari »

pjmlp wrote: post #116
vetinari wrote: post #115

Earlier quoted context omitted.

1. So basically the biggest Android vendor? 2. Both of them... If you are gamer, you are going to Steam (and Valve is not a friend of the Windows store idea). I'm not happy with this situation either, as I prefer GoG, and GoG is a distant second. 3. Doom, Wolfenstein II, F1 2017, The Talos Principle from the other side of genre spectrum or the upcoming Star Citizen. Vice versa is more true, there's no DX12 game worth…

1. Not everyone is rich enough to buy flaghship phones. 2. Lots of gamers just use XBox or PS4 (no Vulkan there). And on PC, not everyone uses Steam. Plus Microsoft already started to be more agressive regarding games on Windows 10, with Age of Empires remaster being the first example. 3. Well it is a matter of taste, not everyone craves for FPS, then there is also the small matter that Vulkan is not supported on XBo…

1. Then a game console is not much relevant either.

2. Age of Empires is Microsoft's game in the first place. Of course they will want their assets to use their technologies. 3rd party adoption is a rounding error. On the PC, except for 1) hardcore indie games players and 2) games locked to the publisher's platform, everyone uses Steam. In the second case, where the games are exclusive to a publishing platforms (Origin, Uplay), they have similar attitude to Windows store as Steam.

Windows store is an existential threat to them. They will ignore it as long as possible.

3. Sure, that's why I mentioned The Talos Principle (a puzzle game). Xbox API will be handled exactly as PS API is.

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

#129

Post by erikpukinskis »

colordrops wrote: post #42
c-smile wrote: 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.

I’ve actually noticed a return recently to simple “HTML native” UI design on the web. Not as many people trying to emulate an “OS native” experience by adding a bunch of extra DOM elements to render borders and effects and such.

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

#130

Post by fulafel »

Marat_Dukhan wrote: post #124
fulafel wrote: post #94

Earlier quoted context omitted.

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…

It is possible to perform some computations using OpenGL ES 3.0 / WebGL 2.0, but many types of operations (e.g. anything that involves random-access writes) are impossible, and many others (anything that normally requires shared memory) are very inefficient. Programming GPU through WebGL 2.0 is akin to programming desktop GPUs pre-CUDA: it is too intricate to take off. Compute shader extension for WebGL 2.0 would be…

I agree that "too intricate" is the other main problem in WebGL uptake. But we're not even seeing WebGL versions of textbook GPU applications that are straightforward to implement with the tools WebGL 2 gives.

For example, here's WebGL compatibility stats from a site that has counters on technical web sites and graphics programming web sites: http://webglstats.com/ - As you can see, WebGL 2 compatibility is only at 40%, despite having been enabled in stable Firefox/Chrome for over a year. WebGL 1, a 7 year old standard, is now at 97%. (And even for the nominally WebGL-enabled browsers, users often report browser or OS crashes, so the percentages are upper bounds).

From an armchair quarterback position, if I wanted to effect GPU compute uptake, I'd work on compiler tech and tools targeting WebGL GLSL.

Post reply on HN