Last week my team and I spent some time in Bellvue working with Valve's Linux team on their port of Left 4 Dead 2.
It was the most successful work trip I've ever had. The guys at Valve were amazing to work with. They are sharp, driven, and have an aggressive plan. Looking at how far they've come and the short amount of time in which they've done it, I have every confidence that they're going to kick their plan right in the butt. It's going to be a good time to be a Linux gamer.
We had three main goals going in:
- Help them tune their game for our driver / hardware.
- Find out where our performance is lacking.
- Find out what OpenGL features they need / want.
I think we scored on every point. We helped them find some performance bugs in their vertex buffer management (which also affected other GPUs / drivers) and some places where the accidentally triggered shader recompiles. This gave some healthy performance improvements.
We also found some areas where our driver really, really needs to improve. They have a couple shaders that devolve into register spilling nightmares. There are also a few places where we eat way, way too much CPU. A lot of these problems mirror issues that we've seen with other game engines (e.g., Unigine).
These have been a lot easier to diagnose on L4D2 because we have access to their source code. Being able to take a profile that shows times in the driver and in the application makes a world of difference. Being able to tweak little things in the app (what happens if I do this...) is also helpful for diagnosing performance problems. Eric has already started landing patches for L4D2 performance, and there will be many more over the coming weeks.
The funny thing is Valve guys say the same thing about drivers.
There were a couple times where we felt like they were trying to
convince us that open source drivers are a good idea. We had to
remind them that they were preaching to the choir. 
Their problem with
closed drivers (on all platforms) is that it's such a blackbox that
they have to play guess-and-check games. There's no way for them to
know how changing a particular setting will affect the performance.
If performance gets worse, they have no way to know why. If they can
see where time is going in the driver, they can make much more
educated guesses.
We also got some really good feedback about features. The biggest
feature they want is better output from
GL_ARB_debug_output.
They really want to know when they do things that fall off performance
paths, trigger shader recompiles, etc. We hacked out some initial
versions of this, and it was a big help. Some patches in that area
should hit the mailing list soon.
They're also interested in what they call "smart vsync." Swaps that
are scheduled soon enough will have vsync, and the application will be
vsync limited. Swaps that are scheduled too late happen immediately.
In their words, "Tearing is bad, but dropping to 30fps is worse." On
GLX, we can expose this with
GLX_EXT_swap_control_tear.
I fully agree: The more information we as developers can get about what is going on in the drivers, the easier it is to make our code fast and bug-free. Reading that sentence again, this comes off as somewhat self-evident.
What appears to not be entirely self-evident, is the fact that driver-devs often spend great effort tweaking drivers for specific games. PC driver-devs oftentimes mention the large effort they have to put into creating workarounds for bugs in games. Gamedevs bizarrely have less information available on the PC-platform compared to consoles (ps3/x360). This coupled with a lower priority for the platform, and thus less time to develop the tools themselves, results in games running on exactly the drivers available at release-date... if that.
I thoroughly believe a great way of remedying this situation, is to provide information through the opengl-debug-context. Using the dbg-context as a verbose-mode, warning about hw-specific performance-issues, doing additional internal error-checking etc. and reporting it all to the game-developer. Using a legacy-part of OpenGL that is emulated (slowly)? Warn the user. I think this could help further the development of the OpenGL-API too.
An interesting effect of the existence of the dbg-context is that it opens up for new changes to the API; it is no longer a complete no-no that you can crash the driver, as long as the dbg-context is able to catch and warn about the error. Examples of this are the Nvidia bindless vertex-attributes and texture- extensions, exposing great performance-improvements while catching driver-crashing errors in the debug-context. Gamedevs also working on consoles are used to this level of responsibility, as long as the information is there.
It was a great joy to see that the new Intel4000HD drivers support the debug-context, and I look very much forward to using it to improve future games.
Best regards,
I am curious to hear about how you profile something as complex as kernel drivers and something as messy as game code.
Some in house Intel tools?
Thanks for the feedback! My team was at your talk at the OpenGL BoF at SIGGRAPH last year. We took a lot of notes.
You should come to the BoF again this year. It's going to be... big.
Any chance of Brink coming to Linux?
Quote: "In their words, "Tearing is bad, but dropping to 30fps is worse." "
In my opinion tearing is much worse. I realize this is a matter of taste and you can't really discuss about it. So please make Smart-VSync optional and VSync still enforceable.
Very exciting development!
Carmack have for years pushed GPU vendors for direct memory access, so he can update a texture without having to go though OpenGL, and just change a pointer directly.
Have you talked with him about what features he would like to see?
vblank_mode. I don't expect that would change. People often want to turn vsync off for benchmarking, etc. Keep in mind that the use case for the smart vsync is when there are a couple frames that occasionally take too long. The trade-off is an occasional tear (maybe... games tend to put menus, etc at the top to mask this) vs an occasional stutter. In a twitch action game, I'll take the occasional tear every time.It's really hand in hand work that is going to improve the situation, for both developers, vendors and end-users. That's a first step in the right direction, but we should definitely head toward more openess.
Keep up the good work!
Go Intel! Go Valve! Looking forward to L4D2 (and others!) on Linux.