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.
You’re right, but it’s not by design, it’s just a little buggy and a lot complicated. There are still easy ways to lock a browser up with CPU code too. It’s harder to crash the OS, but it does happen.
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.
If you're doing any kind of graphics work, the GPU is actually the less "expensive resource" as it will do it faster and more efficiently.
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.
That’s a strange framing, I’m not sure I understand what you mean. The reason for WebGL is much faster graphics for me, I don’t ask why because I want GPU in the browser. Which third party are you talking about? What does the expense of a component have to do with anything? If you’re assuming a malicious GPU computation done without the user’s intent, maybe state that assumption, but that’s not what the parent thread was talking about. I’m certain that if GPU abuse were to become a thing, the browsers will immediately deny default access and request user permission, just like with audio. In the mean time, you can currently turn off GPU access in your browser settings if you’re afraid of something.
Yes, GPU.js is built on top of WebGL. So this exposes no new functionality, only new convenience. And yes, the context is GPU.js, general purpose compute for the GPU. That doesn't mean you're "providing" resources to any third party, right? The primary reason to want general purpose GPU compute in the browser are the same as the reasons to want GPU graphics - to make my own experience faster.
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...
That's not to mention that it's just fun in the spirit of hacking to figure out how to use your systems in weird ways. The cool part about GPU.js is the GPU access with transparent CPU fallback - you get to write GPU-CPU agnostic code in javascript. It's neat that they implemented in javascript a way to cross compile javascript to a shader.
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.
GPU drivers are insane complicated beasts. While doing my advanced graphics, OpenGL with my nvidia card has locked my machine many times.
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.
Browsers do a lot of blacklisting of drivers with known problems.
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.
There is no useful subset that doesn't have the same problem (see my longer response). We did an investigation back when making O3D (before WebGL) if there was a smaller subset that was both performant and didn't have the issue. The answer was no. It does not require shaders to trigger the GPU issue mentioned in my other comment and there's no performant way to check if geometry submitted to some fixed pipeline is going to trigger the "too long" issue or not.
Pixel and vertex and other shaders that run on the GPU are....mostly benign. They can’t be used to take down a computer unless there is a bug in the hardware or graphics card driver, the latter being very common unfortunately.
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.
Earlier versions of WebGL were less powerful, but that made it hard to do anything useful with them. So now, we have this. Vendors are busy adding a Vulkan-style web API now so we'll have even more fun
Blame Apple. They have the worst graphics stack when it comes to stuff like this.
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.
>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.
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.
It's amazing how quickly my attitude toward the idea of GPU-accelerated JavaScript flipped from "awesome idea, let's check out the comments!" to "how about no."
- 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.
Same. MBP2018/FF65. Hard reboot needed to get back up. Interestingly when it soft-crashed FF had a dangling process which wouldn't let it me open the app again (~"Only one FF can be running").
Worked fine on my MacBook Pro (Retina, 13-inch, Early 2015)–apparently the GPU was 367.95x faster. Might be something with your discrete graphics card, or your use of Firefox?
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.
3-6 times faster on my iPhone X in the Chrome in texture mode, 1.2 times faster in default mode.
11 times faster in default mode in Safari, 5.5 times in texture mode.
Results above are for battery-powered device, but repeating tests with charger plugged in didn't help to Chrome, but improved result for Safari up to 60 times.
It looks like results vary significantly from time to time.
Chrome on iOS is just a UI around Safari's rendering engine, per Apple rules. I'm going to hazard a guess you were just seeing normal variation between tests.
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.