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

A Taste of WebGPU in Firefox

hacks.mozilla.org

Post reply on HN
Print view View original

41–50 of 80 posts

Re: A Taste of WebGPU in Firefox

#41

Post by fulafel »

MaxBarraclough wrote: post #11
ericflo wrote: post #4

Earlier quoted context omitted.

Whether or not the API is opt-in is orthogonal to its security hardening - this is a false dichotomy.

I'm not suggesting any false dichotomy, I'm trying to reason about the likely security consequences given what we saw with WebGL in Firefox: serious security flaws in its implementation, with the features enabled in the browser by default. See my links above, one of which summarises with anyone running Firefox 4 with WebGL support is vulnerable to having malicious web pages capture screenshots of any window on their…

Running firefox 4 (or any other comparably old browser), this would be the least of your security problems, it's not even RCE. The stream of discovered vulnerabilities is constant.

Re: A Taste of WebGPU in Firefox

#42

Post by fulafel »

notyourday wrote: post #21
MaxBarraclough wrote: post #2

Will this API be opt-in, or can we expect another security disaster like with WebGL? https://news.ycombinator.com/item?id=16457791 , https://www.contextis.com/en/blog/webgl-a-new-dimension-for-... , https://www.contextis.com/en/blog/webgl-more-webgl-security-... Edit I should have given a quote from one of the articles covering the issue, so here's one: > anyone running Firefox 4 with WebGL support is vulnerable to h…

Browsers should be run in a VM, via a fake GPU which is mapped to a window ( possibly root window ) of a main desktop. Giving code fetched from the internet in real time full access to hardware, especially complex hardware, is lunacy. I'm shocked that neither Google nor Mozilla still have internalized this lesson.

Interestingly, this is not far from how things currently work with webgl - the sandbox, separate renderer process & browser internal safe GL implementation. No doubt webgpu will use similar things. It'd of course be a nonstarter to give full access to hardware or anything of the sort.

I agree that it would be nice to see stronger hypervisor based sandboxes.

Re: A Taste of WebGPU in Firefox

#44

Post by gpugpugpugpu »

kvark wrote: post #8
dchyrdvh wrote: post #6

I know some people coded up raytracers with glsl texture shaders, but rayracers are massive parrallel with no shared state needed algorithms (the entire scene is tiny in those examples). Would this new API enable shared state (to some extent)? For example, someone may want to solve numerically the diff equation of the liquid flow. This usually involves dealing with big lattices where parts of the lattices can be upda…

We are exposing writable storage buffers and textures in all shader stages (there is a caveat discussion [1] on the topic though), which means you can write data out directly. Sharing data between shader threads can be efficiently in the compute shaders (via the shared group memory), which are included in the core of WebGPU. P.S. vange-rs [2] is written on wgpu-rs and uses ray-tracing in fragment shaders for the terr…

> writable storage buffers and and textures in all shader stages

Beware the behaviour of writes will not be consistent between vendors or shader stages, and may be surprising.

Re: A Taste of WebGPU in Firefox

#45

Post by kvark »

gpugpugpugpu wrote: post #44
kvark wrote: post #8

Earlier quoted context omitted.

We are exposing writable storage buffers and textures in all shader stages (there is a caveat discussion [1] on the topic though), which means you can write data out directly. Sharing data between shader threads can be efficiently in the compute shaders (via the shared group memory), which are included in the core of WebGPU. P.S. vange-rs [2] is written on wgpu-rs and uses ray-tracing in fragment shaders for the terr…

> writable storage buffers and and textures in all shader stages Beware the behaviour of writes will not be consistent between vendors or shader stages, and may be surprising.

Yes, we are fully aware of that. There must be a line drawn somewhere between work that we can make portable, and the work that is platform-dependent. Enforcing any ordering on storage writes is completely unfeasible.

Re: A Taste of WebGPU in Firefox

#46

Post by hutzlibu »

m_eiman wrote: post #13
jeswin wrote: post #9

Earlier quoted context omitted.

But that's not what parent was saying, I think. He was saying that WebGL not being opt-in was a security disaster; while saying nothing about the security hardening of the WebGL module itself. Even when a module is well tested, I'd like non-essential modules to be opt-in too.

I’d like Javascript to be opt-in. Turning it on by default was a mistake.

You are free to disable it as a very small minority.

The web is not a static document viewing anymore. Now I agree, that sites should have a static fallback, as I also do not want to run a full webapp, when all I want is a static article for example. But this is because of a different problem - the financing of most of the web, through advertisment and not the fault of javascript.

Re: A Taste of WebGPU in Firefox

#47

Post by kvark »

suyash wrote: post #43

This is not working for me on Safari even with turning on the experimental feature, when will this land on regular Safari ? Excited to see WebGPU possibilities.

Safari implements a large surface of the API ([1]), but they don't accept SPIR-V shaders. When WGSL design is complete, and we have it supported in the browsers, it will be time for truly cross-browser applications.

[1] https://webkit.org/blog/9528/webgpu-and-wsl-in-safari/

Re: A Taste of WebGPU in Firefox

#48

Post by MaxBarraclough »

fulafel wrote: post #41
MaxBarraclough wrote: post #11

Earlier quoted context omitted.

I'm not suggesting any false dichotomy, I'm trying to reason about the likely security consequences given what we saw with WebGL in Firefox: serious security flaws in its implementation, with the features enabled in the browser by default. See my links above, one of which summarises with anyone running Firefox 4 with WebGL support is vulnerable to having malicious web pages capture screenshots of any window on their…

Running firefox 4 (or any other comparably old browser), this would be the least of your security problems, it's not even RCE. The stream of discovered vulnerabilities is constant.

What's your point? Do you really think I was suggesting that people are still running Firefox 4?

When WebGL was first implemented in Firefox - long ago - it shipped with serious security flaws. This struck many people as sadly predictable, as graphics APIs like OpenGL are not intended to be accessible from untrusted code. WebGPU seems awfully similar to WebGL in this respect: it's trying to wrap a low-level graphics API in a secure sandboxed API. This isn't the equivalent of a routine addition like a new feature in CSS.

Re: A Taste of WebGPU in Firefox

#49

Post by e12e »

_jal wrote: post #34
vasco wrote: post #28

Earlier quoted context omitted.

Why don't you say the same about CPU or RAM? In the end it's just resources that are abstracted away to the user, used with the purpose of performing tasks in the most efficient way possible.

Because some resources have mature security controls around them, and some don't. Why do you care if someone can see your bank account number? In the end they're just numbers.

> Because some resources have mature security controls around them

So we thought, then ROWHAMMER arrived..

Re: A Taste of WebGPU in Firefox

#50

Post by sidewaysgc »

dchyrdvh wrote: post #6

I know some people coded up raytracers with glsl texture shaders, but rayracers are massive parrallel with no shared state needed algorithms (the entire scene is tiny in those examples). Would this new API enable shared state (to some extent)? For example, someone may want to solve numerically the diff equation of the liquid flow. This usually involves dealing with big lattices where parts of the lattices can be upda…

Shameless plug of my own WebGL based ray/path tracer: https://github.com/apbodnar/FSPT Compute shaders will allow for some performance wins over my current fragment shader version by being able to do a ray binning/sorting pass to shoot rays coherently allowing for better cache behavior and shared shader state.
Post reply on HN