Old roadmap, good chance that they've changed.Rys said:
The Rumor Roundup
- Thread starter Tim Murray
- Start date
Well, keep in mind that these are roadmaps, and the names are probably designed specifically to keep in line with the current naming scheme to give people who aren't familiar with model numbers an idea of what sort of chips these are.Rys said:
Anyway, I think FX6000 would be a poor choice of name for the next FX. Something more along the lines of FX 6800 might be better, but I think it would be even better for nVidia to distance their next line further from the previous line.
If you remember, nVidia originally was saying that the NV30 would no longer keep the GeForce name. This turned out not to happen. nVidia may have realized too late that the FX was not all it was meant to be, and so decided to call it a GeForce still.
If this next product makes up for the failures of the GeForce FX, then I think it would be smart for nVidia to distance themselves from the previous product by choosing a different name.
As for ATI, I think this shows just how much they've painted themselves into a corner with their naming scheme. It's got to change soon.
At the same time, if the rumors of pixel shader support are true, then "Radeon 9900" may be an appropriate name.
StealthHawk
Regular
Chalnoth said:
I agree 100%
Mintmaster
Veteran
Joe DeFuria said:
I assume you're talking about reading pixel shader results back into the vertex shader via texture access in VS 3.0.
Remember that even though the PS is FP24, the texture storage format is still plain old IEEE fp32. You'll just get the least significant bits set to 0 in the mantissa, and most significant non-sign bit in the exponent set to 0. That's how they map s16e7 to s23e8.
In other words, no compatibility issues. You just won't get the precision, and when it comes to vertex position, precision issues can be noticeable.
"The NV40 will have eight physical pipelines, but they can act like 16, according to the sources."
http://www.digitimes.com/NewsShow/Article.asp?datePublish=2004/03/24&pages=A1&seq=2
These "sources" are said to be "familiar" with the roadmaps of both companies, but the overall tone of this blurb is too reminiscent of the rumour mill.
http://www.digitimes.com/NewsShow/Article.asp?datePublish=2004/03/24&pages=A1&seq=2
These "sources" are said to be "familiar" with the roadmaps of both companies, but the overall tone of this blurb is too reminiscent of the rumour mill.
thatdude90210
Regular
Digitimes
Reliability: High
Reliability: High
Joe DeFuria said:
Yes, in theory, I think there's a problem like you suggested. There's likely a scenario in which PS's precision could affect the result of VS' calculation: the render to VB routine which was introducted in nVIDIA's GDC2004 presentation. But I think as long as PS doesn't touch the texture used in VS, everything should be fine. This also implies that once some data travels through VS to PS and then is stored as texture, a precision loss could be expected at the PS stage, and re-use the data in VS may introduce artifacts.
Mintmaster
Veteran
Damnit Chalnoth, you did it again. Read my WHOLE post, will you?
FP24 may cause some visibly discrete positions when something is moving like in cloth simulation, but only in certain situations. Some extreme, dynamic displacement mapping situations may also suffer similar problems. Changing texture coordinates may also show a little jerkiness.
Anyway, all these situations will probably make very small changes that are only noticeable during gaming in pathological cases.
Mintmaster said:
FP24 may cause some visibly discrete positions when something is moving like in cloth simulation, but only in certain situations. Some extreme, dynamic displacement mapping situations may also suffer similar problems. Changing texture coordinates may also show a little jerkiness.
Anyway, all these situations will probably make very small changes that are only noticeable during gaming in pathological cases.
aaronspink
Veteran
digitalwanderer said:
This is pretty doubtfull. It just doesn't make much design sense nor will it provide much benefit.
A little fuel for the fire though... Has anyone thought of the possibility of the R420 having multiple clock domains? If they are reusing pretty much intact the architecture of the R300 for the pipelines, then that means they would have had on the order of 18 months to do custom circuit work. What if the pixel pipes are double pumped? That would certainly be extreme in my opinion, the limitation on pixel output to memory is 12 pixels per cycle.
Imagine an 8 pipe R420 running at 500-600 Mhz able to run its pixel pipes at 1000-1200 Mhz with a 12 pixel output per cycle. Should easily be able to get 2-3x the performance of R360. It would also explain the rumors of 700-800 Mhz GDDR3 for it as well.
Aaron Spink
speaking for myself
Uttar said:R420: 3x4x(1+2FP24) + 1x4x(Z) (name: FX 6800? or maybe PCX 6900?)
NV40: 4x4x(1+?FP32) + 4x4x(Z) (name: Radeon X800?)
I'm not sure at all about the R420 thing though. Heck, just call that very unlikely speculation
Uttar
Are your labels switched? or the possible names? Most likely its the possible names. later,
epic
dominikbehr
Newcomer
991060 said:
render to VB is nothing new
ATI presented it in OpenGL at last year's GDC
http://www.ati.com/developer/gdc/GDC2003-DisplacementMapping.pdf
Similar threads
- Locked
