SIMD anyone?

[stgatilov]

Forgive me for my pessimism, but I heavily doubt that your work would be useful. I used to play with SSE in TDM and concluded that SSE did not play important role in TDM performance nowadays.

 

First of all, Doom3 engine uses its own private (statically linked) version of idLib. So your changes will only affect TDM code which uses SIMD code rarely.

 

Second, I tested TDM with SSE completely off (there is a cvar to disable SIMD optimization in both idLib instances). The performance was the same as with SSE enabled. I believe that most of the today TDM is RAM-bound (including Tels's ModelGenerator) and rewriting code in SSE won't help performance even a tiny bit. SSE won't increase performance of linear algorithm unless the data is loaded from cache (which is unlikely).

 

And the last idea is about writing SSE code in asm. IMO it is VERY bad decision . You'd have done everything in intel SSE intrinsics (MSDN page). They are very portable (MSVC, GCC, ICC, SunStudio and whatever else). They save vast amount of coding time. And I think that by using them you can get better performance because compiler will handle register allocation (it knows this topic much better than humans).

 

Note that ID decided to use hand-coded assembly instead of intrinsics only because they started coding Doom3 on MSVC6 compiler (13 years old now) which had very bad intrinsics support. Modern compilers have become much better.

[MoroseTroll]

Well, I understand your point of view. Yes, my code is still useless until id Tech 4 will become open. I hope this will happen this year, and then we will see how (in)efficient my code is .

 

You see, I still hope that by boosting Doom 3 itself, I could boost TDM as well. Moreover, if someone from TDM team will learn that some hot function works too slow, I would help to improve it by implementing it in the idSIMD library.

 

Yes, I know that due to the suboptimal size of the idDrawVert class (60 bytes instead of 64), any massive manipulations with it (as in ModelGenerator) can fool CPU hardware prefetchers, and because of this they can be RAM-bound. But I hope that it can be resolved when (if) the Doom 3 source will be released.

 

As for ASM-code versus intrinsics I should say that it is not so important. If my code will be efficient enough, I will make it available on Linux and Mac versions of TDM, one way or another.

[stgatilov]

Yes, I know that due to the suboptimal size of the idDrawVert class (60 bytes instead of 64), any massive manipulations with it (as in ModelGenerator) can fool CPU hardware prefetchers, and because of this they can be RAM-bound. But I hope that it can be resolved when (if) the Doom 3 source will be released.

 

CPU prefetchers take data from L1 cache. To get there the data must go through path: (hard drive) -> RAM -> L2 -> L1. And I suppose that RAM -> L2 is bottleneck (and it is MUCH slower than prefetching unaligned data you mention).

 

For example, this code can be greatly accelerated by SSE because it works with the same 4Kb of data many times:

 

 for (int i = 0; i<20<<10; i++) for (int j = 0; j < 1<<10; j++) sum += arr[j]; 

 

But this code won't work faster with SSE because the huge 80Mb array is accessed once:

 

 for (int i = 0; i<20<<20; i++) sum += arr[i]; 

 

So I mean that everything might be slow because of small RAM bandwidth. In case of TDM small chunks of memory allocated in the heap are accessed in random patterns. So the effective bandwidth may be even less.

 

By the way I have intel CPU, so I don't know how slow idSIMD is on AMD processors. Perhaps optimizing SSE can improve performance for AMD users. Anyway I wish you good luck!

[MoroseTroll]

Thanks for the good wishes .