[zed]

excellant stuff, on a related note Ild never even heard of O3d until now

[BRiT]

Congratulations! This is good news indeed.

[HolySmoke]

Originally Posted by Scali

Yea, that's what one would think. However, when I was playing around on my Intel X3100,
I noticed that Crysis ran slower in D3D10 mode than in D3D9 mode, even at the lowest settings.

So I conducted a small test on my own. I rendered the exact same scene with the exact same shaders in D3D9 and D3D10, and D3D9 was around 10% faster.
And I literally mean the exact same shaders. With the D3DX compiler you can compile the exact same sourcecode for D3D9 or D3D10.
The shaders were very trivial anyway, just per-pixel diffuse lighting. Nothing beyond SM2.0, although I compiled them for SM3.0 and SM4.0.

Makes me wonder where the extra overhead comes from in D3D10. Is it just poor Intel drivers, or does D3D10 really do something different?
One would think that D3D10 would be faster, because my code would theoretically work more efficiently in D3D10. I update all shader constants in one call, and I don't need BeginScene()/EndScene(), and things like that.

I've also tried it on my 8800GTS. The difference between D3D9 and D3D10 was minimal, but still the D3D9 was a smidge faster in Vista.
When running the D3D9 code on XP Pro or XP x64, it was faster than either D3D9 or D3D10 in Vista. I've only tried it in windowed mode so far, though... Perhaps the Vista desktop is a limiting factor in performance, I'll have to see what happens when I run both in fullscreen to eliminate that factor.

Crysis has a major confound when judging D3D10 performance in the form of it's in-engine texture streamer. It's disabled at the lower two texture settings and kicks in at the higher two.

It is a major confound because DX10 already does a form of streaming of it's own in addition to the engine based one. Disabling texture streaming in the engine brings memory usage up to ~1.5gb in DX9 while remaining at 1gb in DX10 mode at the highest texture detail settings. The in-engine streamer also introduces artifacts so it becomes an apples-to-oranges scenario.

The same memory usage behavior is true of all DX10 games I've tried, but with nowhere near the performance drop. Far Cry 2, for example, drops from ~700mb to ~400mb going from DX9 to DX10 while still managing to perform faster.

[Scali]

Doesn't that have to do with the virtual videomemory system in D3D10 though?
From what I understood, in DX9 all texturememory is mapped into the virtual address space at all times. But with DX10 they aren't mapped into the address space at all unless you specifically Map() them...?

[CouldntResist]

Can we stop with the video memory "virtualization" once and for all? It's been established as WDDM 2.x vaporware.

[HolySmoke]

Originally Posted by Scali

Doesn't that have to do with the virtual videomemory system in D3D10 though?
From what I understood, in DX9 all texturememory is mapped into the virtual address space at all times. But with DX10 they aren't mapped into the address space at all unless you specifically Map() them...?

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.

[Davros]

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)

[Scali]

Originally Posted by Davros

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.

[Demirug]

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.

[angrylion]

Originally Posted by Nick

That might become a good idea in the near future. Currently we have a whitepaper explaining the overall architecture, but we exchange optimization details on a per-customer/application basis.

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?

[Nick]

Originally Posted by angrylion

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.

[Novum]

Are you actually still working on it? SM 3?

[Nick]

Originally Posted by Novum

Are you actually still working on it? SM 3?

Yes, I'm still working on it (ANGLE 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.

[angrylion]

Originally Posted by Nick

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. .

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.

[Nick]

Originally Posted by angrylion

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.