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

91–100 of 133 posts

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

#91

Post by rhelmer »

bobajeff wrote: post #61
rhelmer wrote: post #37

Earlier quoted context omitted.

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

The idea is a external format for applications that can be embedded as a object. Not a replacement for web browsers in any way.

Ah, ok. That's interesting too!

There's interest in wasm-land about having "non-web embeddings", which wouldn't assume things like JS APIs exist at all.

I think in that sort of world, you could probably find nicer APIs to target than WebGL and WebAudio... however if you don't mind still having a JS interpreted available then it'd probably be easy to build this sort of thing today using Node.

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

#92

Post by bobajeff »

rhelmer wrote: post #91
bobajeff wrote: post #61

Earlier quoted context omitted.

The idea is a external format for applications that can be embedded as a object. Not a replacement for web browsers in any way.

Ah, ok. That's interesting too! There's interest in wasm-land about having "non-web embeddings", which wouldn't assume things like JS APIs exist at all. I think in that sort of world, you could probably find nicer APIs to target than WebGL and WebAudio... however if you don't mind still having a JS interpreted available then it'd probably be easy to build this sort of thing today using Node.

Probably, but they also still need to be runnable in browsers. Besides I doubt I could design better safe portable GL and Audio APIs.

This is just a subset. I'm mainly curious if this would be easier to implement or not. Using Node would be cheating.

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

#93

Post by leoc »

thristian wrote: post #84
ZenoArrow wrote: post #80

Earlier quoted context omitted.

> "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 i…

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…

Is there a JS SQL/relational library out there that saves to local storage?

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

#94

Post by fulafel »

Marat_Dukhan wrote: post #24
fulafel wrote: post #23

WebGL 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

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 some meeting slides at least: https://www.khronos.org/assets/uploads/developers/library/20...

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

#95

Post by pjmlp »

vetinari wrote: post #77
pjmlp wrote: post #69

Earlier quoted context omitted.

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.

1. Basically Google and Samsung

2. UWP requirements apply to any Windows store game and Microsoft already started to be more bully about it

3. There is hardly any Vulkan game worth playing that isn't DirectX 12 as well.

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

#96

Post by seanmcdirmid »

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…

Canvas is immediate mode rendered and already breaks through the DOM. There are also popular movements to make the DOM appear more as an immediate mode abstraction (React). In contrast, most retained mode 3D abstractions are seen as pretty bad.

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

#97

Post by pjmlp »

seanmcdirmid wrote: post #96
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…

Canvas is immediate mode rendered and already breaks through the DOM. There are also popular movements to make the DOM appear more as an immediate mode abstraction (React). In contrast, most retained mode 3D abstractions are seen as pretty bad.

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 those are the ones that get to write AAA game engines, but many don't.

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

#98

Post by pjmlp »

stu_k wrote: post #54
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.

Except that rendering everything to canvas is not accessible to people with certain disabilities. Also mentioned recently here https://news.ycombinator.com/item?id=16347216

Sadly, I would that 99% of companies don't care, unless mandated by government regulation.

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

#99

Post by sitkack »

thristian wrote: post #84
ZenoArrow wrote: post #80

Earlier quoted context omitted.

> "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 i…

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, it isn't a spec.

What one can do, is compile SQLite to emscripten or wasm, or write a SQL engine in JS and use that in the browser. That is totally fine.

https://github.com/kripken/sql.js

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

#100

Post by monocasa »

pjmlp wrote: post #97
seanmcdirmid wrote: post #96

Earlier quoted context omitted.

Canvas is immediate mode rendered and already breaks through the DOM. There are also popular movements to make the DOM appear more as an immediate mode abstraction (React). In contrast, most retained mode 3D abstractions are seen as pretty bad.

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.

Post reply on HN