Chip Comparison Chart
- Thread starter Dave Baumann
- Start date
olivier said:
Thats product details. That will come at a later date.
Anyone know the code names for TNT/TNT2?
DaveBaumann said:
You need to intersperse the column headings every 12-15 rows methinks... will make reading the table a whole lot easier. Less scrolling up and down.
Add the market name also. I can't remember what NV14 or Avenger actually was in the stores.
OpenGL guy
Veteran
Inefficient does not imply 256x1.mczak said:
That's a lot better than guessing, isn't it?Well, nobody said otherwise - you'd think ATI would have pointed that out to show the Radeon is superiour to the GeForce2. But if you insist, I have a Radeon (SDR) around here, so I can use the DMM on that too
Edit: Fixed quote formatting.
Digital multi meter?
Yes, the "the" is only because I refered to the same DMM as before (well I only have oneMuFu said:I dunno, that's why I asked.
Yah... I missed his first post and was thrown by the *the* suffix. Thought he was referring to a methodology rather than what I think of as a DMM, lol.
MuFu.
).But, grammar aside, I'll try to figure that out next weekend, just for fun. Unfortunately, the results can not be trusted 100% as I won't rip off all components on the graphic card, so it might be possible the measurements will indicate zero resistance between the address pins on all chips but the chip could still have a dual memory channel interface, but I guess that's _very_ unlikely.
PVR_Extremist
Newcomer
Just a quick question.
Should the STG4800 be considered a T&L chip since it had a T&L solution on board, albeit a software one? And if so, should it qualify to comply with the DX7 API?
Should the STG4800 be considered a T&L chip since it had a T&L solution on board, albeit a software one? And if so, should it qualify to comply with the DX7 API?
Dave,
Concerning texture filtering did you include anisotropic filtering capabilites based on the number of samples? If not KYRO´s and GF2´s were actually capable of 16-tap trilinear/anisotropic. Performance is another chapter of course, I could find on other chips slow performing features too that are in fact listed.... .)
Concerning texture filtering did you include anisotropic filtering capabilites based on the number of samples? If not KYRO´s and GF2´s were actually capable of 16-tap trilinear/anisotropic. Performance is another chapter of course, I could find on other chips slow performing features too that are in fact listed.... .)
dave,
i'm not particularly sure of the value of the API compliance field in its present form when being measured in DX compliance - it doesn't really say anything which is not already in the pixel or vertex capabilites fields (e.g. all 'dx7' constitues is just hw T&L, 'dx8' - integer shaders, 'dx9' - fp shaders), plus is too much single-platform-centric (imagine the reader is not a d3d guy). if one really needs some form of 'generations' or 'advancement' measure, one would need more than just dx version compliance. OTH, expanding the pixel/vertex columns w/ extra info would be nice, be it at the expence of droping the API field altogether.
btw, you surely meant avenger's filtering method to be 'trilinear', not 'bilinear'.
on the layout, could you, pretty please, change the blue-on-dark-blue color config of the first column of the list to something more contrasting; highlighting in cyan is nice, but it'd be nice to see things even when not highlighted.
i'm not particularly sure of the value of the API compliance field in its present form when being measured in DX compliance - it doesn't really say anything which is not already in the pixel or vertex capabilites fields (e.g. all 'dx7' constitues is just hw T&L, 'dx8' - integer shaders, 'dx9' - fp shaders), plus is too much single-platform-centric (imagine the reader is not a d3d guy). if one really needs some form of 'generations' or 'advancement' measure, one would need more than just dx version compliance. OTH, expanding the pixel/vertex columns w/ extra info would be nice, be it at the expence of droping the API field altogether.
btw, you surely meant avenger's filtering method to be 'trilinear', not 'bilinear'.
on the layout, could you, pretty please, change the blue-on-dark-blue color config of the first column of the list to something more contrasting; highlighting in cyan is nice, but it'd be nice to see things even when not highlighted.
Sorry, just a quick note: this is still very much a work in progress (that I have to delay for a short while, for reasons which will become clear later), however, I'm not sure if you are aware but the Chip Codename column is now a link which breaks out more information for that chip.
The API compliance is meant as a 'snapshot' quick reference as to its base spec (which also broadly hints at its capabilities), however it is intended to also include OpenGL compliance, but I'm never quite sure exactly which version of OGL the chips are "compliant" to. Suggests are welcome.
When I get back next week hopefully I'll have time to normalise the database tables a little more, clean up the presentation and the really set about getting as much relavent data in there as possible.
The API compliance is meant as a 'snapshot' quick reference as to its base spec (which also broadly hints at its capabilities), however it is intended to also include OpenGL compliance, but I'm never quite sure exactly which version of OGL the chips are "compliant" to. Suggests are welcome.
When I get back next week hopefully I'll have time to normalise the database tables a little more, clean up the presentation and the really set about getting as much relavent data in there as possible.
Ok, I've now examined the R9000pro with the multimeter. It has (drum roll please...) a 2*64bit memory interface (one channel consists of the 4 chips above the RV250 (2 front side, 2 on the back), the other of the 4 chips to the right).
Now, if the R8500 also has a 2*64bit memory interface (I don't have a 8500 nor a 7500 so I can't measure that) I'm left wondering why the R9000 is less efficient in single texturing - maybe just way lower ram timings? Of course the memory controller could still be different, but is it likely?
mczak
P.S: will examine the original Radeon (unfortunately only SDR) tomorrow - if this thing also has 2 channels, I'm going to be surprised...
Now, if the R8500 also has a 2*64bit memory interface (I don't have a 8500 nor a 7500 so I can't measure that) I'm left wondering why the R9000 is less efficient in single texturing - maybe just way lower ram timings? Of course the memory controller could still be different, but is it likely?
mczak
P.S: will examine the original Radeon (unfortunately only SDR) tomorrow - if this thing also has 2 channels, I'm going to be surprised...
Would anyone care to comment on the xbit-labs comment on interleaving I quoted on the second page? I'm not sure how the width of the memory chips affects interleaving, and how interleaving affects the memory controller (which was always reported to be inferior to the GF3's 4x32 Crossbar switch, IIRC).
The width of the memory chips doesn't affect memory interleaving. All you need to do interleaving is memory chips which have 4 internal banks (for 4-way interleaving). All 64mbit and up sdr sdram have 4 banks, and ddr sdram AFAIK doesn't even exist with less than 4 banks.Pete said:
This is the theory, the practice could be more complicated. If you use 32bit wide chips, you need only 4 chips instead of 8 16bit wide chips. This could make it possible to use more aggressive timinigs, as the capacitive load is smaller. It might also be possible interleaving doesn't work stable on cheaply designed pcbs.
Similar threads
