First few GFX benches
- Thread starter Ollo
- Start date
- Status
Doomtrooper
Veteran
More like trying to educate the educated.. :?
Doomtrooper,
3dmark was created to show off system capabilities under dx7/8 situations. I wouldn't think it's the applications fault if anyone results to wrong conclusions from it's scores. In that sense 3dmark is not the only application from which many have drawn conclusions.
Since you mentioned KYRO: would PVR tomorrow create a benchmark suite where they would add numerous iterations of their techdemos (like FableMark, VillageMark etc etc.) and someone would see a KYRO getting far better scores than numerous competing sollutions, it would be his fault and his alone if he'd conclude that KYRO is faster across the board than the rest.
Does that make sense as a parallel?
3dmark was created to show off system capabilities under dx7/8 situations. I wouldn't think it's the applications fault if anyone results to wrong conclusions from it's scores. In that sense 3dmark is not the only application from which many have drawn conclusions.
Since you mentioned KYRO: would PVR tomorrow create a benchmark suite where they would add numerous iterations of their techdemos (like FableMark, VillageMark etc etc.) and someone would see a KYRO getting far better scores than numerous competing sollutions, it would be his fault and his alone if he'd conclude that KYRO is faster across the board than the rest.
Does that make sense as a parallel?
DemoCoder said:
You know what makes me look the most stupid? That I knew there were between 10 ( NV10 ) and 16 ( NV20 ) Vertex Caches which are FIFO ( BTW, I wonder how many the NV30 got... ) .
And that's precisely why I supposed all that insane ( and ridiculous ) idea to store thousands of vertices in memory before using the indices. And yes, it's completely dumb. But that was the only explanation I could find for that thing in the patent.
Your explanation actually makes sense: they would refer to a cache larger than most others by saying "memory". I don't quite understand why they'd do that ( they've always called cache as buffers before ) - but it still sounds a lot more logical than everything I've said.
Everything is as most people ( but me
) supposed: the vertices waiting to get in Triangle Setup are in a Vertex Cache.The *only* bandwidth cost of T&L, thus, is reading static VBs ( and IBs )
So, let's consider a 32B FVF. And consider the GFFX limit 350M vertices/s at 60FPS ( 5.8M vertices/frame )
That's, err, impossible. It would require 177MB of storage
Err... And let's consider AGP 8X 2GB/s limit. At 60FPS, that's only 1M Vertices/frame...
Okay, so assuming we can use 75% of AGP 8X ( the remaining being used for textures ) and 64MB of memory for stored vertices ( that's really a best case scenario, you couldn't play at high res at all with that ) - how many vertices per frame and per second can we have?
We can have 2.75M Vertices/frame and 165M Vertices/s
However, that costs 64*60MB: 3840MB/s - 24% of the GFFX bandwidth!
And having 64MB for static data would probably not be logical unless you've got 256MB of RAM on your GPU. And 75% of AGP 8X would only be possible if there are nearly no texture uploads, so you'll also need 256MB of RAM on your GPU there too.
Also, it's highly unlikely every single static vertex is going to be drawn in a real world game. So, in practice, it might be something like 30% of them being drawn in the same frame ( thus resulting in barely 1.35 Vertices/frame ... )
Sounds like it was required to make the switch to better polygons, and not more polygons!
I really, really hope I didn't do an error here again. I'd look so stupid if I did...
I did reread all of this, so I think it's less likely there's any major error.I'm sorry for having done so many errors in past threads and messages. I won't post things unless I'm absolutely certain of it, and checked every single spot on the planet to make sure.
Uttar
NV30 can store 24 vertices in cache if I remember correctly.
And as you found out it's nearly impossible reach that high vertex counts since both memory and bandwidth become an issue (also remember that 32 byte vertex is bare minimum). Also remember that you need a minimal vertex shader to achieve this 350 million vertices per second mark (about 4 instructions - transformation + color output).
And as you found out it's nearly impossible reach that high vertex counts since both memory and bandwidth become an issue (also remember that 32 byte vertex is bare minimum). Also remember that you need a minimal vertex shader to achieve this 350 million vertices per second mark (about 4 instructions - transformation + color output).
MDolenc said:
Of course
But my point is that not any synthetic benchmark could even get anywhere near 350 Million vertices/second.
And if they're all dynamic, like in Benmark, it couldn't get more than 60M Vertices/s ( which might result in higher triangle counts than 60M/s, because BenMark uses the Vertex Cache very effectively AFAIK )
Uttar
joozoo: I just checked, and we're both wrong.
http://developer.nvidia.com/docs/IO/1307/ATT/GDC2001_Optimization.pdf ( about 650KB )
I think it's at page 15
TNT: 16 Vertex Caches
GeForce: 10 *effective* Vertex Caches
GeForce 3: 18 *effective* Vertex Caches
However, we got no number for the GF4, and one of the big highlights was better cache efficiency. I suppose the cache is the same size as on the GF3, but who knows...
Uttar
You could reach 350 million vertices per second mark and Benmark would probably come quite close (it doesn't use dynamic vertices unless you told him to). Of course you might need to disable stuff like color writesUttar said:
. You just render same (static) object multiple times per frame (different matrix every time), you could also use 16 bit floats to save some memory and bandwidth (so each vertex would be 12 bytes or less)... Not that it would be particularly useful for anything...Joozoo: Interesting. So, in each case, the effective count is 6 less than the actual count. Any idea why?
---
EDIT: Thanks Hyp-X for that explanation Makes sense, seeing how many nVidia patents say a single Transform/Lighting/Vertex Shading unit is able to work on 3 vertices at the same time in optimal conditions.
---
MDolenc: Oh, right, Benmark is static. I think I confused it with another similar benchmark, not sure.
Hmm, yeah, it might be possible to get at 350 Million vertices/second. It's easy to get a 24 Bytes FVF ( by not using texturing ) , and you could transform&draw the same vertices many time.
That would make it possible to get at 350M Vertices/s
But then, why doesn't the Radeon 9700 Pro get more than 115M Vertices/s at BenMark? Maybe there are too little vertices on screen, and fillrate becomes a problem. So yeah, disabling color writes... Or maybe there are too many triangles on screen, and Triangle Setup becomes the bottleneck.
Evyl!
Uttar
---
EDIT: Thanks Hyp-X for that explanation
Makes sense, seeing how many nVidia patents say a single Transform/Lighting/Vertex Shading unit is able to work on 3 vertices at the same time in optimal conditions.---
MDolenc: Oh, right, Benmark is static. I think I confused it with another similar benchmark, not sure.
Hmm, yeah, it might be possible to get at 350 Million vertices/second. It's easy to get a 24 Bytes FVF ( by not using texturing ) , and you could transform&draw the same vertices many time.
That would make it possible to get at 350M Vertices/s
But then, why doesn't the Radeon 9700 Pro get more than 115M Vertices/s at BenMark? Maybe there are too little vertices on screen, and fillrate becomes a problem. So yeah, disabling color writes... Or maybe there are too many triangles on screen, and Triangle Setup becomes the bottleneck.
Evyl!
Uttar
http://babelfish.altavista.com/babe...s/xNews.php?act=shownews&id=6&lp=de_en&tt=url
Can this be true? 3DMark that high isn't possible on todays CPU's.
Can this be true? 3DMark that high isn't possible on todays CPU's.
breez said:
It was determined for a LOT of reasons that those were fakes. And it was determined that way by a LOT of sites and people.
Gainward PCBs are red, not green. All of those images are stolen from nVidia launch documents. Also, the gainward manual is the one of a GeForce 4 ( and not even one with AGP 8X... )
The Unreal score doesn't show the level. And the GF4 is way too fast at it.
Uttar
Doomtrooper
Veteran
Reverend said:
There is more to AA then performance, lets add IQ to that also....or lets move up the comparison to 6X AA.
Doomtrooper
Veteran
Ailuros said:
Support for Microsoft DirectX®8.1.
A new DirectX8.1 feature test showing Vertex Shaders & Pixel Shaders 1.4. *
Featuring 3 game tests plus a 4th game test using DirectX®8.0 hardware accelerated features. *
Directx8.0 feature tests showing Vertex Shaders, Pixel Shaders 1.1 and Point Sprites. *
Two game tests use Ipion real-time physics by Havok.
* A fully DX8 compliant 3D accelerator is required for running this test
No that does not make a parallel IMO, any IHV could make a benchmark that would put their hardware in the best light, be it Nvidia or ATI.
This benchmark is not written by a IHV, it is supposed to be a neutral and fair benchmark yet there is more politics flying around there it would make the CIA look like childs play.
I love the system requirements..
Intel® compatible 500MHz or faster processor
Intel compatible processor ...LOL...its called X86..
Politics baby.
- Status