Edit: System details
Retina Mid-2015 15" - MJLT2LL/A - MacBookPro11,5 - A1398 - 2910
Firefox 65.0.1 (64-bit)
The hang occurred when running the benchmark with Texture Mode enabled. The spinning gear froze after a few seconds, then the display went black and the fan was maxed.
It was a pain in the ass to recover: my only option seemed to be to power down and power back up again, at which point OSX helpfully remembered the state my machine was in and dropped me back into the blacked-out display and maxed fan. Some combination of NVRAM reset, SPC reset and safe mode was required to get back in.
Something's gone very wrong with ours software.
There also shouldn’t be ways to crash the internet or a large scale redundant network service like the ones Google & Amazon have set up with a single microservice or database corruption or flaky cache or router, yet cascading failures are happening all the time and getting long post analysis write-ups featured on HN, even.
The main thing that’s “wrong” is complexity, but it’s also here to stay, there’s no going back, there’s just tightening up the sandboxes and hardening the APIs. GPU resource management is still a bit more raw than what the OS & CPU have, but it’s steadily improving every year. And aside from crashing sometimes, browsers have become very careful about GPU sandboxing for privacy.
In short, it has only gotten better over time, it won’t be long before a webpage really can’t crash the OS just by using the GPU.
Why should they should provide such expensive resources to any third party?
Any kind of <canvas> work, graphs/charts, browser games, animations, and video all will perform better with some GPU assistance. The alternative is run everything on a CPU and get a more limited experience and have your CPU maxed out to 100% a lot more.
Does this actually build on top of WebGL?
The security risks of WebGL has been discussed for years, so as concerning as it is that's not what I'm interested in.
If you as the developer of a web application need the power of a GPU, then aside from graphics my question is why?
The power draw of GPUs isn't trivial and the vast majority of browsers are hand-held devices.
Aside from minimalist sites like hacker news, websites already drain my phone's battery very quickly.
If it's meant for desktops, then to what end?
First, I agree completely that the web has insane amounts of bloat relative to the size of the content you request. Most people here would agree; frameworks and ads and analytics are crazy. This is true, but irrelevant to GPU.js.
Second, GPGPU applications numerous. There are several listed here in the comments and on the GPU.js site, e.g., ray tracing, matrix multiplication. A really obvious one for HN would be neural network traing and/or inference, or any other optimization technique. It's useful for physics sims, video editing, and image processing. Here's a longer list: https://en.wikipedia.org/wiki/General-purpose_computing_on_g...
You're right that the power draw of a GPU isn't trivial, but the watts per megaflop is lower than CPU, for well-crafted highly parallel compute applications, even on mobile devices. I don't imagine using GPU.js on a phone, my personal assumption is that GPU.js is mostly meant for developers playing around on desktops right now. The benchmark specs on the GPU.js page describe a desktop system.
WebGL propagates that. There’s nothing chrome can do, since those webgl calls are essentially proxies to the GPU which is also used to display the rest of OS
Most GPUs don’t have a strong sandbox, and things blow up.
Things are slowly improving, especially as browsers themselves, especially Firefox, steadily do more GPU stuff (putting pressure on the driver makers to fix things), but there’s a reason why it’s been very rare for non-game UIs to target GPUs for rendering: GPU drivers are atrocious. Even if they don’t crash, the number of absolutely fundamental and critical bugs that they have is very impressive. As an example of a fundamental thing being broken, try https://github.com/tomaka/winit/pull/332#issuecomment-341383... and later on down in the thread where a driver update fixed it.
Shader language is pretty simple, there is no way to really subset it. The only safe alternative is not executing user provided shader code on the GPU, but that just means making it completely unavailable.
Most GPUs are not pre-emptable (maybe that's changing?). Because they are not pre-emptable if you give them something to do they will do it until finished. There is no interrupting them, saving state, switching to something else like with a CPU.
Microsoft realized this and so Microsoft built into the OS a timeout. If the GPU is given something to do and doesn't come back in a few seconds then they reset the GPU (like shut the power off and turn it back on, or rather send a PCI reset). You need to be aware of this in Windows programming if you have data you need on the GPU. Most games don't and can just re-upload their data if told their data was ejected but some GPGPU calculation will at least get told "sorry, GPU reset, start over"
Apple didn't implement anything like that in OSX (now MacOS) for the longest time. The entire OS is built around the idea that all apps are well behaved (LOL). If a single app gives the GPU 30minutes of work to then the GPU is going to do 30 minutes of work and your option was only hold the power button.
They tried retrofitting in a timeout but AFAICT there's just too many parts of the OS that expect no one will ever hog the GPU and it filters back to CPU land when the CPU tries to do something (queue drawing some windows) and the GPU doesn't respond for .5 a second, 1 second, 20 seconds, etc and stuff piles up etc...
Linux had (has?) exactly the same problem. I don't know how much progress has been made on either MacOS nor Linux to deal with this.
Now comes WebGL which you guys won't like but basically any page can give your GPU something that takes a few minutes to run and your machine (if it's not Windows) may crash. The mitigating factor is it doesn't help the bad guys. It's not like they can steal your info. The most they can do is convince you never to visit their site again so it's a mostly self correcting problem. The hard spots are if the person making the site was targeting a top end GPU and you visit with a low-end GPU.
There are really only 2 real solutions. The OSes need to handle the fact that GPUs are non-preemptable or we need preemptable GPUs.
Some will argue get rid of WebGL. I'd argue the issue is mostly self correcting and that Google Maps is pretty awesome and it gets that awesomeness from being able to render with the GPU. There's plenty of other 2D and 3D visualizations WebGL enables. So I'm happy to live with the self correcting problem for the benefits while I wait for pre-emptable GPUs for the real fix.
This is actually one place where I'm surprised there are cloud GPUs since they'd have the same issue. I've never used one but they must have some way of being reset. They must also not be shared? Or you just have to accept that some other process on the machine can completely hog the machine.
All my AMD GPUs have been issued GPU resets for years. I know that in 2013 my Radeon 5870 (the card I had at the time) was issued soft resets, which was logged in dmesg as a success. The problem with that is that whatever program caused the GPU lockup would continue to run (unless it crashes, which is frequently the case) until the kernel had reset the GPU so many times, the only option left is a hard reset.
On Windows, the way GPU lockups are dealt with is also by resetting the GPU, and it's the same there too, if it keeps locking up several times within a certain time span the kernel panics and you either get a BSOD or a complete system lockup.
This is why computing on the GPU with code loaded by a web page isn't a good idea.
No virtualization yet, very little memory safety, expected use case is single big task.
I don’t know what else it is, but it is a great DDoS tool for batteries.
They seem to have the highest computing power to battery size ratio among mobile devices in general.
One one hand it's great because they're powerful, on the other this here happens.
Around Christmas there was this sand game which was really neat, but sucked my SO's battery dry in moments going a stable 40fps.
My Galaxy S8 ran it slower and choppier, but considerably longer.
- macOS 10.14.3 (18D109)
- MacBook Pro 15-inch 2017 (Intel HD Graphics 630 1536 MB + Radeon Pro 555 2048 MB)
- Chrome 72.0.3626.96 (Official Build) (64-bit)
The page definitely got more choppy with Texture Mode enabled (guessing the perf delta is higher, so they run a more intensive test to get significant results. I'd test on Firefox, but currently at work, so I don't want to risk it haha.
FireFox 65 seems to be the common denominator I see for these crashes.
Guess I was well overdue for a reboot anyway...
Edit: works fine for me in Firefox Nightly.
In my experience, Apple's OpenGL drivers are incredibly unstable. On Windows I'll often see incorrect results, but generally the drivers have not crashed for normal inputs. When I've run my (admittedly kinda avant-garde) shaders on iOS and OSX devices, there's a good chance that the whole system will halt at some point. I honestly don't know how they have problems like this.
GPU is x105 the speed of CPU according to this benchmark.
It looks like results vary significantly from time to time.