Dynamic Branching Benchmark

Sleep(0) : A value of zero causes the thread to relinquish the remainder of its time slice to any other thread of equal priority that is ready to run. If there are no other threads of equal priority ready to run, the function returns immediately, and the thread continues execution. (MSDN)

Sleep(1) will wait for 1millisec each time it is being called etc

Since you're programming you cannot not know how this affects performace in any given app... ?! right ..?

 

For an empty loop, Sleep(1) us long. For a real rendering loop that takes much time, Sleep(1) can be nothing, while freeing the CPU time for other applications. Probably

 

On a related note, I've found that turning on vsync gives the driver a better chance at giving some time back to the OS, but even in that case on some previous (unnamed ) cards, 100% CPU was still taken.

In any case, this isn't so much of an issue with multi-core CPUs becoming the norm. Vista/DX10 might handle it better as well.

 

Another option is Sleep(0) - that'll misbehave in FreeBSD and perhaps some other OSs though.


Uttar

 

In that case a single sleep(1) would have a really minor effect..
Remember it's the OS which is handing out chunks of CPU time to each running process based on its priority. So even if you're really trying hard to get 100% CPU in reality you cannot if there are other processes running.
(Then again DX9 code integrates in the Kernel itself thereby maybe complicating things a little further)

 

X1900XTX at 672/859, CAT7.1, E6400@3280
DB OFF 1938, ON 3897
Both cores at ~50%
Shadows are indeed very blocky.

 

This is very interesting. The question is, how in the world could Nvidia not notice that, esp. with all the complaints about DB performance?

 

what if that high performance was due to a bug ie incorrect handling of DB in certain situations?

And after all - how many real-world DB examples we have?
maybe NV decided to lower results and keep it secret until/when a real app becomes available in order to claim "driver improvement"

 

Hmm, doesn't that resembles the sentence it's not a bug, it's a feature, then?

So, now there are two odd occasions with DB, on presumably "inferior" NV hardware -- the slightly positive ratio on GF6 series, and now the GF7. Well, they are far cry from what the R500 chippery is showing, and G80 is by my mean fillrate/bandwidth limited in this test.

 

To improve DB performance you need smaller batches, to have smaller batches you need to use more registers..as long as you can hide texturing latency.
Wouldn't be suprised if the driver would artificially inflate the number of registers used by a shader to improve DB performance..

 

And now:

GF8GTX FW 97.92

DB ON: 5473
DB OFF: 4164

 

I've always wonder of how much the fixed batch size (1K fragments) on GF7 marchitecture is contributing over the previous 4K [NV40] one. Not that 1K is much (if any better) than 4K, but having more than one program counter in the fragment core is sure to be helpful.