9 ms·

I'm curious how you would relate in-browser WebGL performance vs. performance of native software such as Unreal. Is running it in a browser 10x worse? or 100x?

peoplewindow 9y ago
WebGL isn't trying to be competitive with full blown game engines, is it? For one, game engines normally don't use OpenGL unless they have to. The GL drivers on PC tend to be very weak. High end games target Direct3D on Windows/Xbox and these days are moving to Vulkan/Metal, even on mobile. On Windows the GL driver situation is so bad that Chrome translates GL to Direct3D. This obviously will impose some overhead and complicate the driver bug situation still further. Even when games do target GL they tend to exploit lots of vendor specific extensions and be tested against very specific graphics card/driver combos to enable them to workaround bugs and performance cliffs. Does WebGL even expose driver specific extensions? I don't think it does. So you are not going to be competing with native apps on the web anytime soon in this area (as with all other areas...)
- skocznymroczny 9y ago
  The recently released Doom game is using OpenGL (and Vulkan).
  - zanny 9y ago
    id has always made opengl engines. They get to deal with endless driver breakage. When Rage came out I believe AMD cards didn't work at all for over a week.
    - slavik81 9y ago
      Bioshock was a DirectX game and I recall that shadows were broken on AMD at launch. There are some OpenGL-specific problems with driver breakage, but AMD would be in much better shape today if that's all it was. If you read through the patch notes for your video card drivers, you'll probably notice that every major game release gets special support right in the driver. NVIDIA has three advantages: 1. Most PC gamers have NVIDIA cards, so developers test primarily against NVIDIA cards. 2. NVIDIA has a boatload of driver developers to hack game-specific fixes and improvements right into their driver. They work around game bugs, rewrite slow shaders, and other stuff like that. I assume that's part of why the graphics driver is now well over a hundred megabytes. 3. NVIDIA sends developers to major game studios to optimize and add graphical effects to their games. For instance, volumetric lighting in Fallout 4 was added by an NVIDIA employee. I think AMD does much of the same, but they just don't have the money to do it to the same extent. That means more breakage and slower fixes.
- iainmerrick 9y ago
  WebGL isn't trying to be competitive with full blown game engines, is it? Sure it is! Not right now maybe, but the web standards people working on it would love to be a viable platform for AAA games. Every so often they tout a new WebGL port of a well-known game as the harbinger of things to come.
  - bflesch 9y ago
    I'd love to build webgl multiplayer games. I hope to get the chance working on these things in the future.
  - peoplewindow 9y ago
    Then why are they implementing an API that's been unpopular for years and is now being phased out entirely (for AAA games)? I think they're more concerned with the politics of it than the technical requirements of that userset. Games are heavy users of driver and card specific extensions for instance. But that'd be at odds with the web's portability commitments.
    - iainmerrick 9y ago
      (I'm mostly playing devil's advocate here, I don't actually think HTML will be suitable for high-end games in the near future. But I think there are decent arguments to be made...) Then why are they implementing an API that's been unpopular for years and is now being phased out entirely (for AAA games)? Mobile. They picked OpenGL ES 2.0 for WebGL because it had comprehensively won on mobile. Apple went with ES 2.0 and Android followed. It's taking a long time for the mobile industry to migrate to ES 3 (which would allow WebGL 2) but ES 2 has been a decent stable baseline for a good few years now. That's quite unusual, and very helpful, given how fast-moving everything in tech is. [Edit to add: ES 2 is based on GL 3, which was the first version to add programmable shaders. That was a huge API change, and an admission that the D3D approach was better. It's barely 10 years old. So any "GL is unpopular" arguments based on the old fixed-function pipeline are a red herring, I think.] Mobile was and is more important than either desktops or consoles, because the mobile market is huge and growing, while desktops and console are at best stable. Google came up with a clever technical solution (the ANGLE library) to emulate ES 2.0 on top of Direct3D, so that sidesteps the technical problems of OpenGL on Windows. Now, for AAA games, desktops and consoles are obviously far more important. I think there are two responses to that: First, a bet that mobile will gradually catch up and become equally important. There are a lot of factors involved, but on raw technical terms it's not such a bad bet. Mobile hardware iterates very fast, and some mobile CPUs are getting very competitive with desktops (recent iPads and iPhones especially). Sustained performance is an issue, as mobile devices have much stricter thermal limits; but you can put the same mobile SoC in a bigger box, like the TV set-top boxes that Google, Apple, Amazon and others are experimenting with. Second, there's no reason WebGL 3 couldn't be based on Vulkan. WebGL 2 hasn't even been fully adopted yet, so it would obviously take a number of years to make that happen. Maybe desktops and consoles will have moved on to something newer and better by then, but maybe they won't. The big question is whether mobile+web is catching up on desktop+console, or if it'll always be a generation or two behind. I think you'd have to be pretty brave to bet against them ever catching up. I think they're more concerned with the politics of it than the technical requirements of that userset. I'm sure politics plays into it, but for WebGL specifically, it must have been a pretty easy technical decision. Do you pick the 3D standard used on Windows, or do you pick the lower-end one used by iOS and Android (and can be made to work on Windows)? You could ask why GL rather than D3D won on mobile in the first place. For that you have to look at Microsoft and ask why Windows Mobile failed (in all its different versions). I don't think you can blame that entirely on politics. Games are heavy users of driver and card specific extensions for instance. But that'd be at odds with the web's portability commitments. That's a good point. From a web standards standpoint, it's a very tough conflict to resolve. I think the web people are pushing for common standards. That takes time and it can get very political, but I don't see a better solution. And if they can get it right, portability is a good thing! I don't see why that necessarily means you'll always be behind the curve on performance. A more standardized, portable system can catch up via economies of scale -- it might be easier to learn, have better tooling, a bigger potential market, etc.
lmm 9y ago
It's not going to be a simple constant factor. The ideal case will be the same - ultimately the CPU is doing the same work (so provided the JIT picks it up correctly it'll be executing the same instructions) and the GPU is running literally the same shaders, so performance should be identical. It's more a question of how much work you have to do to hit that happy path, and what edge cases pull you off it.
- fulafel 9y ago
  The CPU is going to do some more work because WebGL can't allow the GL app to crash the machine or break into the OS kernel, which regrettably current OpenGL (And DirectX, And Metal, and Vulkan...) drivers allow.
  - lmm 9y ago
    Allowing a userspace application to crash the machine or break into the OS kernel is also a security violation that needs to be prevented; the consequences are less severe than when a web page does it, but it still shouldn't happen. So that should also be the same work in either case.
    - fulafel 9y ago
      I agree with the "should" of course - the state of GPU drivers is just horrible and shows no signs of rapid improvement.
maccard 9y ago
I'm afraid I'm nowhere near competent enough in browser technology to comment on the comparison, sorry.
- bflesch 9y ago
  Thanks anyways, I see peoplewindow has pointed out some important issues around my question!
iainmerrick 9y ago
In principle WebGL should be competitive with OpenGL. Once it hits the GPU, it's the same. Some of the bottlenecks in WebGL are: - Javascript. Modern JS engines are great, so the overall speed can be good, but you're still missing things like 64-bit ints, SIMD and threads. (Do game engines make heavy use of threads though? I don't know, but many influential games programmers seem to be wary of them!) - The WebGL -> OpenGL translation layer takes some time. In Chrome it sanity checks your input (which you definitely want in a browser! GPU drivers are very insecure) and executes it in a separate process. Not as expensive as you might think, especially if you minimize your draw calls, which is good practice anyway. - WebGL is basically OpenGL ES 2.0 (and WebGL 2 is ES 3.0), which is missing some useful features of full OpenGL, and doesn't offer the low-level, low-overhead access of Vulkan or Metal. Depending on what you're doing, I'd guess WebGL might be no more than 2x slower (assuming plenty of optimization work). Some fiddly things might be 10x slower, or just not possible at all within the WebGL API. WebGL 2 has a lot of very important new features, but support for that still seems to be patchy, and it's only just catching up with mainstream mobile graphics. It's a generation behind Vulkan. Apart from that, an AAA game will have massive amounts of graphical and audio assets. Delivering that over the network is a pain and HTML5 caching is a pain. Doable, but hardly comparable to just loading it from local storage. Oh, and one more thing! A big game wants sound as well as graphics, and WebAudio is a mess. And audio mixing is typically done in a background thread, so that's one area where the lack of threads in JS is a real problem. Overall WebGL is very nice, it was a great choice to follow OpenGL ES closely (security problems aside).
- sho_hn 9y ago
  > Do game engines make heavy use of threads though? Boy do they, yes.
  - iainmerrick 9y ago
    Can you go into more detail? (Or point me at some up-to-date books or blog posts!) I'm specifically curious about CPU-intensive stuff that is sharded out to multiple threads. That's your classic multithreaded programming, the sort of thing you'd do in scientific computing, but I always got the impression games people were skeptical about it, due to unpredictable performance and the high risk of bugs.
fulafel 9y ago
Unreal can target WebGL: https://www.pcper.com/news/General-Tech/Epic-Games-Releases-Zen-Garden-Demo-WebAssembly https://www.pcper.com/news/General-Tech/Epic-Games-Releases-... (There are also older demos for asm.js + WebGL 1)
corysama 9y ago
Unreal has support for compiling to WebAssembly. Not sure how solid it is. But, you can check out a demo here: https://s3.amazonaws.com/mozilla-games/ZenGarden/EpicZenGarden.html https://s3.amazonaws.com/mozilla-games/ZenGarden/EpicZenGard... 200MB download. Probably requires FireFox. In general, WebGL and asm.js have done a great job of keeping up with the capabilities of whatever is the current-gen iPad.

peoplewindow 9y ago

WebGL isn't trying to be competitive with full blown game engines, is it? For one, game engines normally don't use OpenGL unless they have to. The GL drivers on PC tend to be very weak. High end games target Direct3D on Windows/Xbox and these days are moving to Vulkan/Metal, even on mobile. On Windows the GL driver situation is so bad that Chrome translates GL to Direct3D. This obviously will impose some overhead and complicate the driver bug situation still further. Even when games do target GL they tend to exploit lots of vendor specific extensions and be tested against very specific graphics card/driver combos to enable them to workaround bugs and performance cliffs. Does WebGL even expose driver specific extensions? I don't think it does. So you are not going to be competing with native apps on the web anytime soon in this area (as with all other areas...)

skocznymroczny 9y ago
The recently released Doom game is using OpenGL (and Vulkan).
- zanny 9y ago
  id has always made opengl engines. They get to deal with endless driver breakage. When Rage came out I believe AMD cards didn't work at all for over a week.
  - slavik81 9y ago
    Bioshock was a DirectX game and I recall that shadows were broken on AMD at launch. There are some OpenGL-specific problems with driver breakage, but AMD would be in much better shape today if that's all it was. If you read through the patch notes for your video card drivers, you'll probably notice that every major game release gets special support right in the driver. NVIDIA has three advantages: 1. Most PC gamers have NVIDIA cards, so developers test primarily against NVIDIA cards. 2. NVIDIA has a boatload of driver developers to hack game-specific fixes and improvements right into their driver. They work around game bugs, rewrite slow shaders, and other stuff like that. I assume that's part of why the graphics driver is now well over a hundred megabytes. 3. NVIDIA sends developers to major game studios to optimize and add graphical effects to their games. For instance, volumetric lighting in Fallout 4 was added by an NVIDIA employee. I think AMD does much of the same, but they just don't have the money to do it to the same extent. That means more breakage and slower fixes.
iainmerrick 9y ago
WebGL isn't trying to be competitive with full blown game engines, is it? Sure it is! Not right now maybe, but the web standards people working on it would love to be a viable platform for AAA games. Every so often they tout a new WebGL port of a well-known game as the harbinger of things to come.
- bflesch 9y ago
  I'd love to build webgl multiplayer games. I hope to get the chance working on these things in the future.
- peoplewindow 9y ago
  Then why are they implementing an API that's been unpopular for years and is now being phased out entirely (for AAA games)? I think they're more concerned with the politics of it than the technical requirements of that userset. Games are heavy users of driver and card specific extensions for instance. But that'd be at odds with the web's portability commitments.
  - iainmerrick 9y ago
    (I'm mostly playing devil's advocate here, I don't actually think HTML will be suitable for high-end games in the near future. But I think there are decent arguments to be made...) Then why are they implementing an API that's been unpopular for years and is now being phased out entirely (for AAA games)? Mobile. They picked OpenGL ES 2.0 for WebGL because it had comprehensively won on mobile. Apple went with ES 2.0 and Android followed. It's taking a long time for the mobile industry to migrate to ES 3 (which would allow WebGL 2) but ES 2 has been a decent stable baseline for a good few years now. That's quite unusual, and very helpful, given how fast-moving everything in tech is. [Edit to add: ES 2 is based on GL 3, which was the first version to add programmable shaders. That was a huge API change, and an admission that the D3D approach was better. It's barely 10 years old. So any "GL is unpopular" arguments based on the old fixed-function pipeline are a red herring, I think.] Mobile was and is more important than either desktops or consoles, because the mobile market is huge and growing, while desktops and console are at best stable. Google came up with a clever technical solution (the ANGLE library) to emulate ES 2.0 on top of Direct3D, so that sidesteps the technical problems of OpenGL on Windows. Now, for AAA games, desktops and consoles are obviously far more important. I think there are two responses to that: First, a bet that mobile will gradually catch up and become equally important. There are a lot of factors involved, but on raw technical terms it's not such a bad bet. Mobile hardware iterates very fast, and some mobile CPUs are getting very competitive with desktops (recent iPads and iPhones especially). Sustained performance is an issue, as mobile devices have much stricter thermal limits; but you can put the same mobile SoC in a bigger box, like the TV set-top boxes that Google, Apple, Amazon and others are experimenting with. Second, there's no reason WebGL 3 couldn't be based on Vulkan. WebGL 2 hasn't even been fully adopted yet, so it would obviously take a number of years to make that happen. Maybe desktops and consoles will have moved on to something newer and better by then, but maybe they won't. The big question is whether mobile+web is catching up on desktop+console, or if it'll always be a generation or two behind. I think you'd have to be pretty brave to bet against them ever catching up. I think they're more concerned with the politics of it than the technical requirements of that userset. I'm sure politics plays into it, but for WebGL specifically, it must have been a pretty easy technical decision. Do you pick the 3D standard used on Windows, or do you pick the lower-end one used by iOS and Android (and can be made to work on Windows)? You could ask why GL rather than D3D won on mobile in the first place. For that you have to look at Microsoft and ask why Windows Mobile failed (in all its different versions). I don't think you can blame that entirely on politics. Games are heavy users of driver and card specific extensions for instance. But that'd be at odds with the web's portability commitments. That's a good point. From a web standards standpoint, it's a very tough conflict to resolve. I think the web people are pushing for common standards. That takes time and it can get very political, but I don't see a better solution. And if they can get it right, portability is a good thing! I don't see why that necessarily means you'll always be behind the curve on performance. A more standardized, portable system can catch up via economies of scale -- it might be easier to learn, have better tooling, a bigger potential market, etc.

lmm 9y ago

It's not going to be a simple constant factor. The ideal case will be the same - ultimately the CPU is doing the same work (so provided the JIT picks it up correctly it'll be executing the same instructions) and the GPU is running literally the same shaders, so performance should be identical. It's more a question of how much work you have to do to hit that happy path, and what edge cases pull you off it.

fulafel 9y ago
The CPU is going to do some more work because WebGL can't allow the GL app to crash the machine or break into the OS kernel, which regrettably current OpenGL (And DirectX, And Metal, and Vulkan...) drivers allow.
- lmm 9y ago
  Allowing a userspace application to crash the machine or break into the OS kernel is also a security violation that needs to be prevented; the consequences are less severe than when a web page does it, but it still shouldn't happen. So that should also be the same work in either case.
  - fulafel 9y ago
    I agree with the "should" of course - the state of GPU drivers is just horrible and shows no signs of rapid improvement.

maccard 9y ago

I'm afraid I'm nowhere near competent enough in browser technology to comment on the comparison, sorry.

bflesch 9y ago
Thanks anyways, I see peoplewindow has pointed out some important issues around my question!

iainmerrick 9y ago

In principle WebGL should be competitive with OpenGL. Once it hits the GPU, it's the same. Some of the bottlenecks in WebGL are: - Javascript. Modern JS engines are great, so the overall speed can be good, but you're still missing things like 64-bit ints, SIMD and threads. (Do game engines make heavy use of threads though? I don't know, but many influential games programmers seem to be wary of them!) - The WebGL -> OpenGL translation layer takes some time. In Chrome it sanity checks your input (which you definitely want in a browser! GPU drivers are very insecure) and executes it in a separate process. Not as expensive as you might think, especially if you minimize your draw calls, which is good practice anyway. - WebGL is basically OpenGL ES 2.0 (and WebGL 2 is ES 3.0), which is missing some useful features of full OpenGL, and doesn't offer the low-level, low-overhead access of Vulkan or Metal. Depending on what you're doing, I'd guess WebGL might be no more than 2x slower (assuming plenty of optimization work). Some fiddly things might be 10x slower, or just not possible at all within the WebGL API. WebGL 2 has a lot of very important new features, but support for that still seems to be patchy, and it's only just catching up with mainstream mobile graphics. It's a generation behind Vulkan. Apart from that, an AAA game will have massive amounts of graphical and audio assets. Delivering that over the network is a pain and HTML5 caching is a pain. Doable, but hardly comparable to just loading it from local storage. Oh, and one more thing! A big game wants sound as well as graphics, and WebAudio is a mess. And audio mixing is typically done in a background thread, so that's one area where the lack of threads in JS is a real problem. Overall WebGL is very nice, it was a great choice to follow OpenGL ES closely (security problems aside).

sho_hn 9y ago
> Do game engines make heavy use of threads though? Boy do they, yes.
- iainmerrick 9y ago
  Can you go into more detail? (Or point me at some up-to-date books or blog posts!) I'm specifically curious about CPU-intensive stuff that is sharded out to multiple threads. That's your classic multithreaded programming, the sort of thing you'd do in scientific computing, but I always got the impression games people were skeptical about it, due to unpredictable performance and the high risk of bugs.

fulafel 9y ago

Unreal can target WebGL: https://www.pcper.com/news/General-Tech/Epic-Games-Releases-Zen-Garden-Demo-WebAssembly https://www.pcper.com/news/General-Tech/Epic-Games-Releases-... (There are also older demos for asm.js + WebGL 1)

corysama 9y ago

Unreal has support for compiling to WebAssembly. Not sure how solid it is. But, you can check out a demo here: https://s3.amazonaws.com/mozilla-games/ZenGarden/EpicZenGarden.html https://s3.amazonaws.com/mozilla-games/ZenGarden/EpicZenGard... 200MB download. Probably requires FireFox. In general, WebGL and asm.js have done a great job of keeping up with the capabilities of whatever is the current-gen iPad.