Valve's L4D2 Linux Presentation Slides

[phoronix]

Phoronix: Valve's L4D2 Linux Presentation Slides

Here are the slides that Valve presented at SIGGRAPH LA 2012 about their Left 4 Dead 2 / Source Engine porting to Linux...

http://www.phoronix.com/vr.php?view=MTE1ODI

[johnc]

"Our performance is currently highest on NVIDIA's GL driver"

[snuwoods]

"Our performance is currently highest on NVIDIA's GL driver"

Way to stir up some flamewar shit Valve!

[FourDMusic]

Michael, please add some transparency to the "Phoronix" watermark! It's covering parts of the text on the slides. And people have had trouble with the watermark covering up pictures in the past, too.

Merci beaucoup

Here's the link to the original slides in PDF from the khronos website: http://www.khronos.org/assets/upload...RAPH_Aug12.pdf

[entropy]

"Our performance is currently highest on NVIDIA's GL driver"

asdx to the rescue!

[Danny3]

Michael, please add some transparency to the "Phoronix" watermark! It's covering parts of the text on the slides. And people have had trouble with the watermark covering up pictures in the past, too.

Merci beaucoup

I was about to say the same thing. Please Michael, it's really annoying when it's covering text.

[AJSB]

Michael, please add some transparency to the "Phoronix" watermark! It's covering parts of the text on the slides. And people have had trouble with the watermark covering up pictures in the past, too.

Merci beaucoup

Here's the link to the original slides in PDF from the khronos website: http://www.khronos.org/assets/upload...RAPH_Aug12.pdf

Thanks very much for the slides w/o the darn watermark

Interesting stuff that was added to what we already knew...only two more points...

1 The complete title of the presentation is based in the complete title of Stanley Kubrick movie "Dr. Strangelove"

2. Valve is hiring....in special OpenGL, Kernel and drivers programmers...i have a felling that soon we will have a new distro called SteamOS...both for PCs and for the Steam console

[elanthis]

Way to stir up some flamewar shit Valve!

It's really not a secret at all that NVIDIA has the better GL drivers by a huge margin. They are faster, support newer versions of the standard sooner, and are the place to find most of the cutting edge GL extension proposals which might end up in later versions of the standard, e.g. NV assembly shaders which are great for higher-level tools to target vs source-compiling to GLSL, and bindless graphics and DSA which every serious OpenGL professional is praying to $DEITY will finally be in GL 5.0. Most graphics developers tend to learn towards NVIDIA.

I've seen game teams hold lotteries to see which "unlucky" developer got stuck with the fastest AMD GPU (to ensure at least one dev was testing on AMD regularly) while the others got more modest NVIDIA GPUs, both because of the difference in driver quality and because of NVIDIA's vastly superior graphics developer tools. As someone who turned into an AMD fanboy back in the days when r300 was The Shiznit for Linux users preferring FOSS drivers, I suppose I might opt for the AMD card if offered a choice (especially as I use AMD on my home workstation for hobby stuff and already have a decent grasp on what breaks their drivers). I suppose these days if I were still a Linux user I'd probably be an Intel fanboy since that driver appears to be the best FOSS one now... but it's close to impossible to be an Intel graphics fan if you're on Windows where their GL driver is the largest steaming pile of horseshit that has ever been produced by a driver team in the history of PC hardware.

The only issue I have with NVIDIA in direct comparison to other GL drivers is that their GLSL compiler is much looser and accepts invalid code that the other drivers generally reject. It's less painful to develop with NVIDIA because you run into less (though not zero) stupid bugs, but it's at times less painful to develop on AMD since your shader code will be forced into being more portable.

In general, if you're doing PC/Windows graphics development, just make sure you have one of each of NVIDIA, AMD, and Intel around to test on (sounds obvious, but you'd be surprised even how many professionals forget to test regularly on a variety of hardware until late in alpha or even beta). The drivers are just too different in quality and supported features to only test on just one. I mean, if it works on Intel it'll probably work anywhere, but if it works on Intel it's probably because all you're doing is calling glClear. (Okay, that's a teensy bit overstated, but seriously, Intel's Windows GL driver sucks.)

Also, insert usual OpenGL commentary blah blah wish Khronos would have just made a standard cross-platform ICD library with shader frontend and API loader but its way too late to get the vendors on board even if they did blah blah

[89c51]

@elanthis

Whats your opinion on the Mesa implementation?

[elanthis]

89c51
@elanthis

Whats your opinion on the Mesa implementation?

It's been some time since I've actually had a Linux desktop machine (as you may have already picked up on, I became very disillusioned with Linux as a non-toy desktop OS last year), so I don't have much of an opinion on Mesa right now. What I've read and seen in the code all looks fairly good, but it's hard to say without actually using it for anything serious.

I am impressed with the general speed of development on Mesa, specially from the Intel team lately, and I enjoy keeping up on the git changesets. I want to make clear that while I very strongly despise the Intel Windows GL driver, I harbor no disrespect for the Intel Linux driver team. Seems like all good work so far.

I have been mulling getting a small Mac Mini like machine with Ivy Bridge (maybe the Giada i53 if it's available soon) specifically for Linux as I'd like to do some porting work, so I'll be experimenting with Mesa's features and quality quite a bit then. If I find problems there, though, export bug reports rather than forum bitching.

The only problem I'm aware of with Intel's Linux support right now is that I'd really like Intel to switch to Gallium, so that any "better than OpenGL but not D3D" API/state-tracker experiments I might decide to try could actually be done with Intel hardware and not just softpipe/llvmpipe.

[edit: I can't remember if you're with AMD or not, but if you are, I also had good experiences with r600. it was definitely very buggy and the DRI/Mesa model makes it way too easy for bugs to cause kernel oopses, but this was over a year ago, so again I don't have an educated opinion on today's state of the driver.]