Valve Shares Performance Numbers On Port of Left4Dead 274
New submitter nschubach writes in with an update on Valve's progress porting one of their games to GNU/Linux. From the article: "One factor in creating a good gaming experience is throughput. This post discusses some of what we've learned about the performance of our games running on Linux. ... After this work, Left 4 Dead 2 is running at 315 FPS on Linux. That the Linux version runs faster than the Windows version (270.6) seems a little counter-intuitive, given the greater amount of time we have spent on the Windows version. However, it does speak to the underlying efficiency of the kernel and OpenGL. Interestingly, in the process of working with hardware vendors we also sped up the OpenGL implementation on Windows. Left 4 Dead 2 is now running at 303.4 FPS with that configuration."
nschubach adds "It seems there are good things coming out of this for both Operating Systems!"
Interesting bit from the article (Score:5, Informative)
What I found interesting was how much an improvement this is from their initial port.
Their very first version ran at a full six frames per second (167ms/frame). They've now gotten it up to 315 fps (3.17ms/frame).
That's some pretty impressive work. Pity the article is so light on the details of how they did it (I'll spare you reading the article: they found places where it ran slow due to the kernel, they found places where it ran slow making OpenGL calls, and they found places in the driver itself that ran slowly - that's about as much detail as the actual article gives you).
Re:What about quality? (Score:4, Informative)
From what I understand, OpenGL has more features because they support extensions where Direct3D has to wait for Microsoft support. Granted, this requires that the developer actually use those extensions. The blog is rather light on details/screenshots.
Re:What does it tell you? (Score:5, Informative)
OpenGL sits over the top of DirectX on Windows
No, it doesn't. That was the plan when they developed Vista, but it was scrapped after an outcry from half the industry. The OpenGL driver is just as low level as the DirectX driver on Windows.
Re:Ehhhhhh. (Score:3, Informative)
We developers knew this for a long time.. (Score:5, Informative)
This approach was proven again very succesful with mobile hardware, where vendors such as Qualcomm, PowerVR or Tegra or ARM (Mali) produce graphics chips that comply with OpenGL but at the same time use the higher level abstaction of the API to their advantage, by supplying very different backends each (Immediate Rendering, Deferred and Tile Based Deferred) as means to improve performance (per watt and silicon space) to levels much higher than the desktop counterparts.
Added to that, programming games under Linux is a joy for those used to it, as the tools are fantastic (command line scripting, gdb with hardware watchpoints, valgrind, strace, etc) and the fact the OS manages the heavy load of games much better. Many companies I worked with, and even big ones such as Naughty Dog (makers of Uncharted) develop their games primarily under Linux, even if the final versions are released for Windows, Mac and Consoles.
Re:Efficiency (Score:5, Informative)
Much of the engine design dates back to the Quake 2 engine, but none of the code does.
History time!
First came Quake, which was coded completely from scratch. Then came Quake ][, which was a significant overhaul and massive rewrite. Some of the code was saved, but the engine design itself was changed quite a bit. Both of those engines were written by id Software.
Valve licensed the Quake ][ engine, and improved on it, adding a new renderer (a DirectX one, IIRC, but they kept the OpenGL and software renderers) and several other nice features. They used this for Half-Life, Team Fortress Classic, Counter-Strike 1.6, etc., and also offered it for relicensing under the name GoldSrc.
Over the years and years it took to make Half-Life 2, they rewrote literally the entire engine. Not a single line of code remains from Quake ][. They rewrote the renderer (several times), added all kinds of animation goodies, integrated Havok physics, and so on. But they kept the same basic client/local server/server design, the same general layout. It's much like how GNU made the basic Linux toolset - they copied the design of UNIX, but did not use any code from it.
Valve has continued to use and upgrade this engine, calling it Source to confuse everyone. They've offered it for license, and at one point were seen as a decent competitor, but they've really fallen behind in the post-UnrealEngine 3 world. I half-suspect they'll be either doing a total engine redesign, or giving up and licensing someone else's engine.
Re:Year of... (Score:5, Informative)
Valve projects run on the basis of "work on what you think brings value to our customers and to the company", so someone would have to have decided "I think a Linux port is a good idea, so I will start working on one" and encouraged other people to join the project. All of their desks are on wheels, so people working on stuff can move their desks together - they just unplug from where they are and plug in where they go.
Valve has a flattened hierarchy, there are no managers. Team leaders aren't appointed, they just happen because the naturally turn out to be the team leader. Remuneration is based on perceived worth by your peers. Their employee handbook is an interesting read - the PDF of it was publicly available, last time I checked.
Re:Interesting bit from the article (Score:5, Informative)
Let's be careful with statements, please. They didn't say it ran slow due to the kernel or OpenGL, that is BS. They are acknowledging their own errors, not OpenGL's and not the kernels. They also did say exactly what they did to fix the situation.
I'll spare you on your details with the reality of what they said:
Their goals:
Performance improvements fall into several categories:
Modifying our game to work better with the kernel
Modifying our game to work better with OpenGL
Optimizing the graphics driver
The results:
An example of the first category would be changing our memory allocator to use more appropriate Linux functions. This was achieved by implementing the Source engine small block heap to work under Linux. The second category would include reducing overhead in calling OpenGL, and extending our renderer with new interfaces for better encapsulation of OpenGL and Direct3D.
The third category is especially interesting because it involves working with hardware manufacturers to identify issues in their drivers and, as a result, improving the public driver which benefits all games. Identifying driver stalls and adding multithreading support in the driver are two examples of changes that were the result of this teamwork. That's not a valve benefit, that's "all linux games" benefit.
Re:Interesting bit from the article (Score:5, Informative)
What I found interesting was how much an improvement this is from their initial port.
Their very first version ran at a full six frames per second (167ms/frame). They've now gotten it up to 315 fps (3.17ms/frame).
That's some pretty impressive work.
That happens on nearly every Engine port. For example - Mortal Kombat on the Playstation VITA Handheld Console.
I worked on the team porting Unreal from PS3 / XBOX 360 to PS Vita at Netherrealm Studios (which we did in house separate from Epic's efforts). We ported over a NULL driver and then got the basic graphics up and running. Our initial port ran at 6 FPS. The shipped game ran at 60FPS with frame syncing and 80-90FPS at Speed-of-Light (frame syncing off).
You write a lot of code quickly to just get things working and once they are, you figure out the bottle necks and optimize code and assets from there.
Re:What does it tell you? (Score:5, Informative)
Re:Interesting bit from the article (Score:3, Informative)
Wrong, he said they only worked with Intel specifically on OSS drivers. They've been working with ATI and nVIDIA on PROPRIETARY drivers very much, and have made that very clear.