That's pretty much what I meant. What I was getting at (poorly, now that I re-read the post) was that because the game features an in-engine streamer you may have to control for it.

From what I understand, this built-in streaming engine was introduced to prevent the game from crashing at the 32-bit limit in DX9 mode at the higher texture settings. While I've never experienced it myself, I know that some setups can't run the game at full detail with streaming disabled for that reason. But while it's a fine solution to a DX9 issue, it's wholly unnecessary when running in DX10 while still being enabled by default. So, ideally, you'd want to disable in-engine texture streaming manually during testing (edit: setting textures to low or medium achieves the same result).

Don't get me wrong, I've never managed to get Crysis to run faster under DX10 than DX9 and I think it's definitely an engine issue. But if you want to test the actual rendering section of the engine (especially since you're using custom shaders) then you'd want to make sure that the streaming portion is disabled because it's a performance affecting workaround to an altogether unrelated problem.

wouldnt the crysis devs know about streaming in dx10 and disable it in preference of their own streaming
plus the 32bit limit in dx9 would surely still exist in dx10 (vista32)

Not if you only map memory when required.
As long as the CPU doesn't need to access the videomemory, there's no reason for it to take up address space on the CPU side.

All I know is that he has a point.
I have a PC with a Radeon X1900XTX, which reports WAY higher memory usage than when running Crysis on a GeForce 8800.
The Radeon goes over 1.5 GB, sometimes close to 2 GB, while the GeForce uses about 1 GB to 1.2 GB. I don't know what causes it, but the DX9 machine just uses way more memory than the DX10 one does, despite having higher detail.

How many times this is comes up again?

The typical video memory window is 256 MB. It needs to be mapped to the address space of any application that uses Direct3D. Vista is somewhat smarter here as it can dynamically change the size of the mapped window. But this can although cause crashes if the window needs to grow and there is no address space left.

When it comes to resource allocation Direct3D 9 and 10 behaves different.

10 is quite easy as any resource needs its own size of the address space. This is even true for textures that are in the video memory. The reason for this is that the virtual video memory manager must be able to swap the resource to the system memory. For different reasons they are swapped to the process that owns the resource.

9 is more complicated. Before SP1 any managed resource needs twice the address space. One time for the system memory copy and one time for the real video resource. This was done for compatibility reasons. But with graphics cards that contain a large amount of video memory and only 2 GB address space you run in problems. Therefore there was a hotfix that becomes part of SP1. This hotfix tries to eliminate the address space requirement for the real resource when possible. But it still needs more address space then 10.

I don’t have the exact numbers for BattleForge here but it requires significant less address space with Direct3D 10 compared to 9.

Sorry to bring the old topic up, but am I right that this whitepaper (mentioned also on several other sites, sometimes with quotations) has never been available for free?

I'm not sure if it was ever made available publicly, but you might be able to easily get a copy by e-mailing swiftshader@transgaming.com. Much of it has been quoted on some sites anyway and if I recall correctly it didn't contain proprietary information.

Anyway, do you have a specific question about SwiftShader? I might be able to clarify some technical aspects.

Are you actually still working on it? SM 3?

Yes, I'm still working on it (ANGLE (http://code.google.com/p/angleproject/) was an short diversion). I'm not sure if I'm at liberty to publicly talk about new features though, but again, feel free to contact swiftshader@transgaming.com for any inquiries.

I e-mailed at that address more than a month ago and didn't receive a reply. I'd appreciate if you could consider uploading the whitepaper. Of course, if it's indeed free and not confidential.

To avoid pulling attention to this aging version of SwiftShader we won't upload the whitepaper at this time, but please send a request to swiftshader@transgaming.com again. Your previous e-mail appears to not have made it through. Sorry for the hassle.