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

81–90 of 133 posts

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

#81

Post by bobajeff »

avaer wrote: post #72
bobajeff wrote: 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!

Your ideas is actually really cool (very tech noir).

But that's not what my idea is. My idea isn't really a browser. It's just a separate format/mimetype (.app or .game) for a app runtime.

Small projects could implement it. We can have it embeddable as a object in browsers. Clients other than major web browsers (Gopher, Dillo) could embed it. Embedded devices (Roku) could include support for it. It could even be used in a physical media like SDcards or DVDs.

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

#82

Post by pdkl95 »

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.

> compiled applications

A lot of HN comments dismissed my prediction[1] that WebAssembly will bring opaque "compiled applications" that treat the canvas as a "standard pixel buffer", allowing adblocking CSS and request filters to be bypassed.

A lot of people seem to be focusing on the benefits of new technological changes ("no longer a restriction"), when they should first be concerned with the potential risks that change will create.

[1] https://news.ycombinator.com/item?id=10211050

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

#83

Post by gruez »

pdkl95 wrote: post #82
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.

> compiled applications A lot of HN comments dismissed my prediction[1] that WebAssembly will bring opaque "compiled applications" that treat the canvas as a "standard pixel buffer", allowing adblocking CSS and request filters to be bypassed. A lot of people seem to be focusing on the benefits of new technological changes ("no longer a restriction"), when they should first be concerned with the potential risks that c…

>my prediction[1] that WebAssembly will bring opaque "compiled applications" that treat the canvas as a "standard pixel buffer", allowing adblocking CSS and request filters to be bypassed.

They could already do that. It's called serving the whole page as an image

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

#84

Post by thristian »

ZenoArrow wrote: post #80
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…

> "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 only alternative is to make sure all new interfaces have multiple, popular implementations simultaneously, so that authors can't afford to take advantage of bugs in one implementation. This is the sort of activity you see in WHATWG these days.

The problem with "a SQL dialect" being available for use on the Web is that every browser intended to use SQLite as the backend. Nobody wanted to invest the time and effort to write a second, compatible, equally-reliable implementation; nobody wanted to exhaustively research and document bugs and flaws in that specific version of SQLite; nobody wanted to commit to back-porting security fixes from later versions, or forward-porting the required bugs to later versions.

And since nobody wanted to do the work to make it possible, using SQL for local storage remains impossible.

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

#85

Post by digi_owl »

paulie_a wrote: post #40
digi_owl wrote: post #33

Earlier quoted context omitted.

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

Yeah i am more excited about the AR glasses Intel recently unveiled than anything VR.

But in the end the problem with be battery life...

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

#86

Post by kevingadd »

tlb wrote: post #75
c-smile wrote: post #70

Earlier quoted context omitted.

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.

Last I checked, many browser vendors only GPU accelerate specific blend modes. If you do anything fancy your canvas ops silently drop to software.

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

#87

Post by kevingadd »

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…

The SQL situation is a bummer. It made sense to avoid a monoculture, but indexedDB is a near-useless wreck due to its terrible performance and it has no meaningful querying primitives at all so you get to implement them yourselves and the performance is even worse.

Wish we could've just had two SQL implementations. There are other ones out there - Microsoft ships JET and an embeddable version of MSSQL, someone could've embedded postgres or something. As-is people who care about performance are just going to compile SQLite down to wasm/asm.js and run it in a worker.

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

#88

Post by avaer »

bobajeff wrote: post #81
avaer wrote: post #72

Earlier quoted context omitted.

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!

Your ideas is actually really cool (very tech noir). But that's not what my idea is. My idea isn't really a browser. It's just a separate format/mimetype (.app or .game) for a app runtime. Small projects could implement it. We can have it embeddable as a object in browsers. Clients other than major web browsers (Gopher, Dillo) could embed it. Embedded devices (Roku) could include support for it. It could even be used…

Awesome, thanks for the clarification.

Here's what I'm trying to reconcile: if the idea is to break off the awesome subset of multimedia web tech, because it would be easier to implement than a full browser -- I 100% agree! -- then why is there a need for a new mimetype/format?

Many things could be done better than the current HTML-as-laundry-list approach, but if we invent a new format, that adds the extremely difficult problem of getting everyone on board, rewriting things for it. The brilliance of asm.js (which gave birth to WASM) was that everyone had already implemented it before it existed.

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

#89

Post by slavik81 »

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're building on top of a big mess. Though, my impression is that the WebGPU initiative is basically just another battleground in that struggle. I don't have any faith that this is being done for the good of users. It's just strategic ground to capture.

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

#90

Post by bobajeff »

avaer wrote: post #88
bobajeff wrote: post #81

Earlier quoted context omitted.

Your ideas is actually really cool (very tech noir). But that's not what my idea is. My idea isn't really a browser. It's just a separate format/mimetype (.app or .game) for a app runtime. Small projects could implement it. We can have it embeddable as a object in browsers. Clients other than major web browsers (Gopher, Dillo) could embed it. Embedded devices (Roku) could include support for it. It could even be used…

Awesome, thanks for the clarification. Here's what I'm trying to reconcile: if the idea is to break off the awesome subset of multimedia web tech, because it would be easier to implement than a full browser -- I 100% agree! -- then why is there a need for a new mimetype/format? Many things could be done better than the current HTML-as-laundry-list approach, but if we invent a new format, that adds the extremely diffi…

Like you say it would be a subset. It's all just standard WebAssembly. The APIs of course would need to be made callable from WebAssembly but that's already planned for in browsers anyway.

Until browsers supported the mimetype they could just be served as .wasm files. Not that the mimetype is important at all I just think it more clearly states it's intended use.

Post reply on HN