Polygon Throughput limit

Have you tried the usual checks to actually make sure you''re vertex rate limited?
Like, does changing the CPU increase/decrease your speed (if it does your CPU bound) or changing the window size (will tell you if you''re fillrate bound) etc.

25000 triangles per batch does seem a little excessive actually, I seem to remember statistics that should ''optimal'' batch size around the low thousands (1000 - 5000 say) but I guess if you''ve got better results before from the same code that''s not the case (unless something has become fu''d in the drivers of late).

Apart from that, are all your allocation pools OK, have you flagged stuff as WRITEONLY and only written to the static resources once (if you write to them multiple times I think they get knocked down to AGP mem, or was that a myth?).

OK, I''m out of ideas now, hope some of that helped

-Mezz

Oh, and by 30MTri/Sec do you actually mean running at 1fps or an interactive framerate?

-Mezz

Thanks Mezz
I still get interactive framerates.
THe problem occurs even when I use a limited dataset (ie, the same triangles repeated over and over).
By the way, I checked : increasing batch size does increase performance. It is always (measurably) better when convenient to do (have not checked above 65536 vertices though) since it does reduce batch overhead.
I allocated in default pool, write only, pure device, hw_vertex_precessing.
I''ll see if it is cpu bound, good idea, but I doubt it, because it would mean that the cpu is used, as I measured, in the driver, transforming stuff. With some of the complex shaders I used, 30MPoly/s is too high of a figure, since I tried with shaders above 50 vector ops.
What I really would like is to measure the AGP transfer size, but I don''t know how to do that.
I''ll see if that multiple write thing is a myth since I sometimes update (not once a frame, rest assured) static VBs
BTW, have you tried such a benchmark with your code?

OK, if you''re getting interactive framerates then you aren''t ''really'' getting those figures per second, if you''re hitting 30MTris running at 20fps, then you''ve really got 600MTris/Second (did I just calculate that right?). That also means that your calculation for bandwidth (30M/s*32bytes = 960MB/s) would also be incorrect. Using 20fps again, it''d actually be (600M/s*32bytes = 19.2GB/s) which is almost at the memory bandwidth limit for a Radeon 9800, but then the Radeon 9800 isn''t supposed to be able to transform 600MTris/Sec anyway (The 6800 is supposed to though)

If you''re using hardware vertex processing then your CPU time spent in the driver won''t be transforming vertices... it''ll just be generating traffic to the graphics card.

If you''re ever locking & updating your static VB during rendering, it may be going in AGP memory, or you might just be seeing the stalls from the Lock() calls - I don''t really know how oftern you''re doing it, but even if it''s less than once a frame, you may still see a performance penalty.

It sounds like you *aren''t* vertex rate limited because if you can run very long shaders without a significant performance drop then it''s almost certainly something else eating your time.

-Mezz

It''s polygons per second, not per frame. I know, I wrote "second" and not "s" or "sec"

Yes I agree, my cpu can''t be spending time transformming vertices. I suppose it''s passing data through the AGP, but I don''t see why it would do that.
btw, the 6800 is not able to run 600MTris/s with anything more than a very simple vertex shader. If I managed to get 150~200MTri/s, that would be as good as possible.

OK, so you''re on 30MTris/sec, sorry, I thought maybe there was some math missed out somewhere.

If you are ending up with things in AGP memory, then it''s probably a good bet that your CPU is spending a bunch of time generating the traffic for the bus.

So, why would it be doing that?
Well, if you are changing your static VBs more than once then they might be ending up in AGP memory. That''s about all I can think of.
Erm, how many batches are you drawing per frame, roughly (number of DIP calls)?

-Mezz

I render 100 batches/frame in this case so about 3000 batches/s
I can go up to about 10 times that and still have CPU.
The problem is that even though I have been working in this field for years, for the first time I do not know how to figure out how this happens. I do not lock VBs more than once. So I guess it''s the cpu spending time generating traffic. There''s no way I know of to check if it is really the case. Maybe I''ll have to write a minimal test that bypasses the game engine...

If you''re rendering 3000 batches per second, and each of your batches are at least 25000 triangles, then you have 75MTris right there. Or did I miss something?

If I did, then yeah, I guess the best bet is probably to write a small test app that you can eliminate all other potential variables from.

-Mezz

is your IndexBuffer optimized to maximize Post-T&L cache efficiency ?

the hardware has is vertex/sec performance indexed on frequency/vertex transform cost.

but final triangle throughput is dependant and the vertex throughput and Post-T&L cache hit... (a bad scenario on the IndexBuffer could make you have half the triangle throughput....)

i was talking about approx batch count and size.
What counts is less than 100 batches per frame. Total of 30MTri/s.
The IB is post tnl cache optimized.