View Full Version : GeForce FX rumored to be 4x2
Hellbinder
02-10-03, 06:22 PM
Its being discussed at Beyond3d righ now. It seems that the GFFX is only kicking out 4 pixels per clock under fillrate tests. And that more than one source is reporting it.
Perhaps its not actually a 4x2, but has 4 broken pipelines??? Thus explaining why some of the shader performance is so low, among some of the other odities??? It could explain why Nvidia is insisting their drivers need work. A coverup perhaps?? Who knows.
Wierd.
suburbanguy
02-10-03, 09:07 PM
You don't mean GFFX aka NV30 do you? because that's an 8:1
configuration, like R300/Radeon9700. that is, 8 pipelines each with 1 texture unit.
perhaps its the 128-bit memory bus of GFFX that only allows so much fillrate to be used. like around half.
gokickrocks
02-10-03, 09:28 PM
yes we are talking about the nv30 gf fx...pr has lead everyone to believe its 8x1, but things seem to point to a 4x2 configuration
SurfMonkey
02-11-03, 07:07 AM
The way I see it there are three possible reasons for the dissapointing shader, fill rate results.
a) The NV30 (not the QuaddroFX though), has a 4x2 architecture and nvidia are having a laugh.
b) The NV30 is, like the QuaddroFX, an 8x1 architecture but only displays the characteristics of a 4x2 architecture. This is either due to hardware problems or because the drivers aren't optimised enough to swap between architetctures depending on what kind of precision is required (FP16 or FP32).
c) It's becoming a bit redundant to talk about GPU\VPU architecture in terms of 8x1, 4x1, 4x4 etc. The NV30s pipeline may not be that mundane. It is supposed to be fully programmable and may be a collection of generalised units that can be reconfigured for the task in hand, and this isn't optimally supported in the drivers.
SnakeEyes
02-11-03, 03:50 PM
Originally posted by SurfMonkey
c) It's becoming a bit redundant to talk about GPU\VPU architecture in terms of 8x1, 4x1, 4x4 etc. The NV30s pipeline may not be that mundane. It is supposed to be fully programmable and may be a collection of generalised units that can be reconfigured for the task in hand, and this isn't optimally supported in the drivers. [/B]
I thought that this was exactly what I'd read about the chip? I was pretty sure that the nV30 was supposed to be very general in nature, in exactly this way, allowing greater flexibility for different situations. This would mean that if drivers were optimized correctly, it could effectively be a 4x2 where situations demanded, and still be an 8x1 in others.
(Dunno, been reading a lot of different things lately, about tons of hardware, so I could always be wrong).
StealthHawk
02-11-03, 06:55 PM
Originally posted by SnakeEyes
I thought that this was exactly what I'd read about the chip? I was pretty sure that the nV30 was supposed to be very general in nature, in exactly this way, allowing greater flexibility for different situations. This would mean that if drivers were optimized correctly, it could effectively be a 4x2 where situations demanded, and still be an 8x1 in others.
(Dunno, been reading a lot of different things lately, about tons of hardware, so I could always be wrong).
yes, what you state above applies to the NV30 :) so no, you're not crazy.
http://www.theinquirer.net/?article=7920
Ouch...
Originally posted by SnakeEyes
This would mean that if drivers were optimized correctly, it could effectively be a 4x2 where situations demanded, and still be an 8x1 in others.
8x1 is at least as efficient than 4x2 is at most. No point for using 4x2 in some situations.
Woah, it sounds like that B3D thread pretty much concluded the NV30 is a 4x2, but with 8 FP16 shader calculators which can unite themselves to become 4 FP32 shader calculators.
Poor, poor nVidia...
Uttar
T-Spoon
02-21-03, 04:30 PM
So if it's 4x2, does it still mean that the GFFX is DX9.0 compliant? I thought 8-pipes was a minimum for DX9?
NickSpolec
02-21-03, 04:48 PM
Just what the hell was Nvidia thinking?
They REALLY screwed this thing up..
digitalwanderer
02-21-03, 05:03 PM
Could someone explain the effects/importance IF it is 4x2 instead of 8x1? In little words, for the little-brain thickies such as myself to understand?
I don't get it, it's a little too technical or I ain't had enough coffee. :confused:
In singletexturing 8x1 is two times as fast as 4x2 design. Future games are towards using singletexturing. Someone else could explain why. I think it's related with the use of shaders.
digitalwanderer
02-21-03, 06:04 PM
No need to explain the why, "two times as fast" covers it adequately for me.
I sort of thought that's what it meant from the numbers, but I really hate making assumptions like that since they usually turn out to be wrong. Thank you for clearing that up for me.
Dang, this would really bite for nVidia wouldn't it? :(
StealthHawk
02-21-03, 06:41 PM
Originally posted by breez
In singletexturing 8x1 is two times as fast as 4x2 design. Future games are towards using singletexturing. Someone else could explain why. I think it's related with the use of shaders.
8X1 is more efficient than 4X2, as it provides more overall gain.
games are NOT moving towards single texturing, as they are using more and more texture layers.
Originally posted by StealthHawk
8X1 is more efficient than 4X2, as it provides more overall gain.
games are NOT moving towards single texturing, as they are using more and more texture layers.
Maybe I worded it wrong, but what I meant is that shaders are taking the place of traditional texturing in future games. I'm really not sure of this all, but it does make sense because we are moving to more pipes/less TMU's per pipe design. 8x1 is more transistor expensive than 4x2 so there has to be some real advantages. Someone more knowledgeable should clear this up.
Originally posted by StealthHawk
8X1 is more efficient than 4X2, as it provides more overall gain.
games are NOT moving towards single texturing, as they are using more and more texture layers.
No they're not, they're moving towards using no textures layers (as such) at all!
breez's explanation was fine: 8x1 offers the same multi-textured throughput as 4x2 but twice the single-textured rate. As games become more shader-centric, texture mapping will become obsolete and what we think of as TMUs will no longer feature in GPU architectures. Eventually all textures will be procedurally generated.
MuFu.
silence
02-21-03, 07:42 PM
Originally posted by MuFu
No they're not, they're moving towards using no textures layers (as such) at all!
breez's explanation was fine: 8x1 offers the same multi-textured throughput as 4x2 but twice the single-textured rate. As games become more shader-centric, texture mapping will become obsolete and what we think of as TMUs will no longer feature in GPU architectures. Eventually all textures will be procedurally generated.
MuFu.
does that mean that FX is less future oriented then nvidia is saying.......and what about all the programability of FX in that case?
>>me needs to learn more<<
Originally posted by silence
does that mean that FX is less future oriented then nvidia is saying.......and what about all the programability of FX in that case?
Yes.
It is still pretty mind-blowing in terms of programmability. The scope for crazy-assed effects is there, it's just going to be pretty slow when running them. 3D pipelines are so flexible these days they can pretty much do anything given enough time - of course, the problem in gaming situations is that you don't have an unlimited amount of time between frames. :-\
MuFu.
The Tech-Report has the scoop from Nvidia themselves on this issue, sometimes its 8x1 and other times not!
GeForce FX is 4 pipes by 2 texture units?
by Scott "Damage" Wasson - 05:42 pm, February 21, 2003
After seeing this report at The Inquirer, we asked NVIDIA for clarification: Does the GeForce FX have four rendering pipes with two texture units each or eight with one each, as the world was led to believe? Here's the answer we received from NVIDIA:
GeForce FX 5800 and 5800 Ultra run at 8 pixels per clock for all of the following:
a) z-rendering
b) stencil operations
c) texture operations
d) shader operations
For advanced applications (such as Doom3) *most* of the time is spent in these modes because of the advanced shadowing techniques that use shadow buffers, stencil testing and next-generation shaders that are longer and therefore make the apps "shading-bound" rather than "color fill-rate" bound.
Only color+Z rendering is done at 4 pixels per clock, all other modes (z, stencil, texture, shading) run at 8 pixels per clock.
The more advanced the application, the less percentage of total rendering is color, because more time is spent texturing, shading and doing advanced shadowing/lighting.
We will unpack this statement for you shortly, but it appears Fraud at The Inq got this one right.
http://tech-report.com/news_reply.x/4782/
Originally posted by noko
The Tech-Report has the scoop from Nvidia themselves on this issue, sometimes its 8x1 and other times not!
The Inquirer are so full of crap it actually hurts. :rolleyes:
See Beyond3D for the original "scoop".
MuFu.
Yep, Beyond3d did open up this bag of worms, still this is now official from Nvidia.
StealthHawk
02-22-03, 04:10 AM
Originally posted by MuFu
No they're not, they're moving towards using no textures layers (as such) at all!
breez's explanation was fine: 8x1 offers the same multi-textured throughput as 4x2 but twice the single-textured rate. As games become more shader-centric, texture mapping will become obsolete and what we think of as TMUs will no longer feature in GPU architectures. Eventually all textures will be procedurally generated.
MuFu.
when do you forsee this transition starting? is it a long time in coming or a short time? how soon will games do all texturing through shaders?
will games that do this require DX8 hardware as a baseline?
Hi Everyone
This is my first post and I wanted to speculate on this topic.
OK here it goes. Looking at the NV30 OpenGL extensions
specification I was very surprised to see that the following are
still there:
Texture Shaders
Texture Enviroment Application
Two sets of register combiners(for legacy and FCP1.0 modes).
Those modes are now in I12 format, but still looks like overkill for
such a programmable chip as the NV30. Then I hear this about
4x2. Well it makes perfect sense to me because there would
absoliutely no point in having 8 legacy pipelines. However in
FCP1.0 mode there should be 8 register combiner sets
because there are 8 pixels output in shader mode(acording to
rumours). This let Nvidia build a very flexible shader model
probably with alot of resources shared(like instruction space)
because you could make the shaders go faster when
they are combined with FCP1.0. Furthermore to enhance
the performance even more they added the FP16 mode.
But all of this requires alot of optimizations and thus CG
was born and thats why Nvidia is so keen on making the
developers use it.
Sorry went a little of topic there but I just wanted to share
some of my ideas on this.:D
silence
02-22-03, 07:48 AM
ok....me again,with more questions:D
is it possible that they made chip with architecture that doesn't really have 4x2 or 8x1 ,but can work in given situation like any of those depending on input?is that possible?i know i read from one magazine here in croatia that they don't really have pipelines, but large array of fp32 processors (i hope i wrote this correctlly) that ACT like 8 pipelines.....
sorry if this is dumb:confused: ,but i am so much interested lately in this stuff that i had to ask:cool:
StealthHawk
02-22-03, 07:54 AM
Originally posted by silence
ok....me again,with more questions:D
is it possible that they made chip with architecture that doesn't really have 4x2 or 8x1 ,but can work in given situation like any of those depending on input?is that possible?i know i read from one magazine here in croatia that they don't really have pipelines, but large array of fp32 processors (i hope i wrote this correctlly) that ACT like 8 pipelines.....
sorry if this is dumb:confused: ,but i am so much interested lately in this stuff that i had to ask:cool:
read noko's post quoting Tech-Report. that is exactly what nvidia is saying ;)
vBulletin® v3.7.1, Copyright ©2000-2012, Jelsoft Enterprises Ltd.