How Valve Made L4D2 Faster On Linux Than Windows

[gamerk2]

Seriously I was expecting a better design from valve. If you have seen irrlicht or ogre renderer for example, you would have known that a renderer should be independent from opengl or dx. you write abstract classes that you then implement for opengl 1.5 or 2.0 or dx 9 or dx 11 and so on. If valve would have done so there would be no sense in translating dx calls to opengl. I mean WTF kind of design is that? Are they using any kind of OOP design at all? It just shows that sometimes even the "best" programmers fuck it up. Valve you dissapoint me...

Using an even higher level API incurs a performance penalty when translating to OGL/DX/WhateverGraphicalAPI. For games, where performance matters, this is unacceptable.

[log0]

No not really. Implementing some abstract classes won't kill performance. Do you actually think irrlicht and ogre are so inefficient? Any reasonable developer wraps the api in something else. In their case they didn't wrap it correctly enough so they could rewrite the implementation without rewriting the higher level api. That means bad design. And implementing a translator between d3d to opengl really does incurs a performance penalty. More than doing it right the first time with abstract classes...

My guess is that the Source engine wasn't meant to be cross platform. Thus there was no point in wrapping Win API calls.

[AJSB]

My guess is that the Source engine wasn't meant to be cross platform. Thus there was no point in wrapping Win API calls.

Exactly...so their options was to do something like they did or rewrite everything from ground up....that last option was not an economical good option .

.....and if they achieved the kind of performance that they seem to got , it really doesn't matter.

[RealNC]

No not really. Implementing some abstract classes won't kill performance. Do you actually think irrlicht and ogre are so inefficient?

Well, I have to wonder how on earth can an XBOX 360, that comes with an ancient GPU of equivalent power to a Radeon X1950 or Intel HD 3000, pull off those "OMG WOW!" graphics it does while there's no fscking way to do those graphics on an actual X1950 or Sandy Bridge with HD3000.

It's a natural response to blame the PC APIs for this.

Edit:
In other words, can you use Ogre/Irrlicht to implement Skyrim, or the latest Assassin's Creed, or Mass Effect 3, or even Race Driver Grid (runs at constant 60FPS on XBOX360 even when there's 20 cars on screen) on an Intel HD3000 CPU? The XBOX can do those on its old hardware.

[elanthis]

Using an even higher level API incurs a performance penalty when translating to OGL/DX/WhateverGraphicalAPI. For games, where performance matters, this is unacceptable.

You clearly have no clue what you're talking about. Please don't go around telling people "facts" if you aren't even remotely an expert in the field. Then other people just have to go and clean up the misinformation you spread.

Every modern high-end engine has an internal graphics interface. Neither D3D nor OpenGL are suitable for being the direct interface the graphics programmer uses for rendering, as they are both just low level hardware abstraction layers. The highs end engines abstract away shaders and effects systems, render queues, etc.

If you think that an extra layer on vertex buffer creation and the like is a bottleneck, you are wrong. The bottlenecks are in places that are called tens to hundreds of thousands of times per frame. The graphics API is called only a few hundred times, maybe a couple thousand times, if you're doing your job right as a graphics programmer.

[RealNC]

I don't really see what are you trying to prove? you can play those on xbox because you program more to the metal in xbox and don't have to worry so much about a lot of layers that exist on pc. On pc you don't target a specific hardware configuration so that is why for consoles they can optimize better. But don't worry, they still abstract the graphics api especially if they write the engine for both xbox360 and ps3.

So this is why I'm saying valve did a poor job abstracting the api. They shouldn't have gotten to the point where they translate d3d calls to opengl.

My point was a reply to whoever claimed that abstractions upon abstractions don't hurt performance. It seems they do. OpenGL and D3D seem to be too high level and performance seems to suffer greatly as a result?

[Gps4l]

You clearly have no clue what you're talking about. Please don't go around telling people "facts" if you aren't even remotely an expert in the field. Then other people just have to go and clean up the misinformation you spread.

Every modern high-end engine has an internal graphics interface. Neither D3D nor OpenGL are suitable for being the direct interface the graphics programmer uses for rendering, as they are both just low level hardware abstraction layers. The highs end engines abstract away shaders and effects systems, render queues, etc.

If you think that an extra layer on vertex buffer creation and the like is a bottleneck, you are wrong. The bottlenecks are in places that are called tens to hundreds of thousands of times per frame. The graphics API is called only a few hundred times, maybe a couple thousand times, if you're doing your job right as a graphics programmer.

Maybe you can help me out.

I am getting confused.

Valve claims for years their game engines supports opengl and direct X

Why do they need to translate direct X calls then?
Or is this just simpler then adopting the game to opengl ?

I build some maps for a game, I cant imagine it being that hard.
You wont have to rebuild the levels ?

[elg2001]

Why has no one suggested smart preprocessor usage to eliminate the abstraction layer completely without harming portability? Why make an abstract class that decides when it's called "what platform am I running on?". That's what a preprocessor is for.

If you want to compile once for all platforms, you're doing it wrong.

[Chaosenemy]

Why has no one suggested smart preprocessor usage to eliminate the abstraction layer completely without harming portability? Why make an abstract class that decides when it's called "what platform am I running on?". That's what a preprocessor is for.

If you want to compile once for all platforms, you're doing it wrong.

This. I'm confused by everything that's being said here. Direct3D translators? What is all this crazy talk?

void DrawSomething()
{
    #if defined(WIN32)
        D3D9Blahblah();
    #elif defined(__linux__)
        glBlahblah();
    #elif defined(__APPLE__)
        glBlahblahAPPLE();
    #endif
}

Certainly this is what most devs do right?

[kwahoo]

My guess is that the Source engine wasn't meant to be cross platform. Thus there was no point in wrapping Win API calls.

AFAIK leaked 2003 Source (Half-Life 2 beta) had a D3D/OpenGL/Software switch.