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

61–70 of 133 posts

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

#61

Post by bobajeff »

rhelmer wrote: post #37
bobajeff wrote: post #16

Earlier quoted context omitted.

Easier implementation is the goal. There are currently only four companies working on a web implementation. Also, I think users would have more control if documents didn't automatically gain the same privileges as applications.

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

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

#62

Post by andrewmcwatters »

guidedlight wrote: post #60

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.

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

#63

Post by tlb »

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

by its specification mandates pixel buffer to be placed in memory with per pixel access. This reduces GPU acceleration options to the ground.

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().

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

#64

Post by Matheus28 »

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

by its specification mandates pixel buffer to be placed in memory with per pixel access. This reduces GPU acceleration options to the ground.

What are you talking about? You’re able to access random pixels, yes, but first you need to copy them to normal RAM. Canvas 2D and WebGL are both hardware accelerated.

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

#65

Post by [deleted] »

orbitur wrote: post #56
revelation wrote: post #22

Earlier quoted context omitted.

This is a bit of a rambling mess, but to just make one point: the winner has been chosen. Android is implementing Vulkan, and so Vulkan it will be.

If Vulkan is the future, I wonder how mobile devs will make money if they can't target iOS.

[deleted]

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

#67

Post by pjmlp »

orbitur wrote: post #56
revelation wrote: post #22

Earlier quoted context omitted.

This is a bit of a rambling mess, but to just make one point: the winner has been chosen. Android is implementing Vulkan, and so Vulkan it will be.

If Vulkan is the future, I wonder how mobile devs will make money if they can't target iOS.

It is a non issue thanks middleware.

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

#68

Post by pjmlp »

dleslie wrote: post #29
revelation wrote: post #22

Earlier quoted context omitted.

This is a bit of a rambling mess, but to just make one point: the winner has been chosen. Android is implementing Vulkan, and so Vulkan it will be.

It will be Vulcan and Dx12. Microsoft is nothing if not a stubborn 800 lbs gorilla.

Just like Apple, Sony and Nintendo.

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

#69

Post by pjmlp »

revelation wrote: post #30
dleslie wrote: post #29

Earlier quoted context omitted.

It will be Vulcan and Dx12. Microsoft is nothing if not a stubborn 800 lbs gorilla.

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.

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

#70

Post by c-smile »

tlb wrote: post #63
c-smile wrote: post #59

Earlier quoted context omitted.

by its specification mandates pixel buffer to be placed in memory with per pixel access. This reduces GPU acceleration options to the ground.

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.
Post reply on HN