Drivers for SOURCE

[bob saget]

HI guys, I was wondering which drivers are best for source-engined games like the HalfLife2 series, CSS, DODS. I am currently running 163.69, and getting 80-100 fps. My friend is running a very similar setup and he is getting in the 120s. He is running 32bit vista, while i am running 64, dont know if that makes a difference.

Antialiasing= 4xMSAA
Filtering= Trilinear
Vertical Sync= disabled
Everything else on high. These are the settings steam picked for me. I am playing on a 19inch LCD with resolution 1280x960. The desktop resolution is 1440x900.
Any tips to make Source engine run faster are appreciated. Thanks

[Dragunov]

Just try the latest beta driver

[PowerK]

Source engine is one of those that actually perform *worse* in 64-bit environment compared to 32-bit.

One of the recent thread I've found few days ago.
http://www.hardforum.com/showthread.php?t=1231909
The internals of the CPU don't actually handle anything other than qwords, just as 32-bit x86 since the Pentium Pro don't handle anything other than dwords internally
The smaller word sizes exist only in the x86 translation layer, not inside the actual arithmetic units, cache, load/store units etc (the internal registers, used in the register renaming file, are qword-only, and smaller data units will be extracted from these registers, or inserted. This may in some cases incur a 'partial register stall').
So for all intents and purposes, the internals of the x64 processors are identical to 'native' 64-bit processors. The main difference is in the x86 translation layer, but you already incurred that extra performance hit in the 32-bit processors. There's no additional penalty for 64-bit, so to say.

One of the biggest problems with 64-bit processors today is that 32-bit processors already were superscalar and had 64-bit databuses. This means that most of the theoretical gain from 64-bit computing was already implemented in 32-bit processors since the Pentium.
This leads to the irony that 64-bit code is sometimes slower than 32-bit code, because certain operations now require qwords, where 32-bit processors used dwords.

The most obvious example of this is a recursive function. On a 64-bit processor, every argument to that function is stored as a qword on the stack. On a 32-bit processor they are dwords. So obviously the 64-bit processor needs twice as much memory on the stack, and therefore also twice as much bandwidth. But the 32-bit processor already has a 64-bit databus, so it has the same bandwidth as the 64-bit processor, and the 32-bit processor can store two dwords on the stack in a single clockcycle because it is superscalar.
The workaround for this would be to implement your own 32-bit stack instead of using the default stack.
I've encountered this in my own code... it was slower when compiled to 64-bit... after analyzing the code, the stack turned out to be the culprit. After rewriting it to minimize bandwidth/memory usage in the recursive function, it ended up about 20% faster than the 32-bit version. Which makes sense... In theory 64-bit does give better performance because of the extra registers, which make it rely less on the stack and cache.
In practice, most 32-bit code probably has 'pitfalls' like these, and will be slower when just blindly recompiled to 64-bit (which we see with many 64-bit applications today, one of the saddest examples being Half Life 2 in 64-bit. In Lost Coast my average framerate drops from 160 to about 120 fps when comparing 32-bit to 64-bit). Developers will have to be educated in how to optimize their code for 64-bit.

[dxx]

Of course, you do realise that your LCD won't be able to display framerates higher than 60fps anyway, so you could pull a tweak to make it go ten times faster and it'd still look exactly the same?