View Full Version : G80 to be called GeForce 8800GTX and specs.
Maverickman
02-20-06, 05:59 PM
Some preliminary specs for the GeForce 8800GTX to be released later this year:
It will definitely be compatible with the new DX10 API in WIndoes Vista
Core clock = 1000MHz
Memory = GDD4 @ 2000MHz
Pixel Pipelines = 32 of course
Shader Units = 10-12 not sure exactly
This monster will offer approx. 2X the performance of the 7800GTX 512 MB and 1.5X the 7900GTX. Not bad at all.
CaptNKILL
02-20-06, 06:01 PM
Source? :eek2:
I thought it was going to have unified shaders?
Yeah it's unfied with 48 pixle lines. Coreclock is abit optimisitc i must say. 1GHz? to be compatible with DX10 it has to be unfied.
Rakeesh
02-20-06, 06:21 PM
Whats a unified shader?
slaWter
02-20-06, 06:56 PM
Where did you get this info? I think it's a little too optimistic.
Any info about the release date?
keith33
02-20-06, 07:09 PM
Where did you get this info? I think it's a little too optimistic.
Any info about the release date?
QFT:)
Whats a unified shader?
I think it means that the pipelines are capable of running either pixel or vertex shaders. Someone correct me if I am wrong. :)
Source? :eek2:
Thin air? :)
Whats a unified shader?
It's a shader that's unified :angel:
superklye
02-20-06, 08:21 PM
I think it means that the pipelines are capable of running either pixel or vertex shaders. Someone correct me if I am wrong. :)
Pretty sure that's right.
hordaktheman
02-20-06, 08:34 PM
Pretty sure that's right.
It is. The idea is that you could have each shader do a pixel or vertex operation interchangably so that if a given scene needs more vertex power than pixel power the GPU can allocate it's resources in that fashion.
I call shens on the specs though.
According to Xbit labs (http://www.xbitlabs.com/news/video/display/20060220100915.html) G80 is not a unified shader architecture but it will incorporate 48 pixel shader processors and an unknown number of vertex shader processors.
As far as I'm aware, DX specs do not dictate how the hardware does it's job. As long as the API is unified for both Vertex and Fragment operations, it doesn't matter if the hardware isn't.
I've never heard anyone say DX10 forces the hardware to use unifed shader hardware for both vertex and pixels. That just sounds dumb.
1Ghz core?! Yeah right! Not a chance in hell if they're adding more pipes.
killahsin
02-21-06, 09:54 AM
One would hope it would be 48 unified. but it will most likely just be 48. As the benefits from unification most liekly won't appear in the first year of vista.
I think it means that the pipelines are capable of running either pixel or vertex shaders. Someone correct me if I am wrong. :)
That is absolutely correct. Unification allows basically, no downtime.
AFAIK, as Nutty said, DX10 requires unification at the driver level.
Which means with a driver that exposes it, even a mere GF3 could have unified shaders, from DX10's point of view (but it wouldn't run faster).
"Unification" is a wide concept, and there's infinite possibilities - from no unification at all to total hardware unification. Now, which possibility yields the best perf. isn't a religious question (i.e. "simple, it's all the way toward this principle", whatever the principle is) but a pragmatic one (i.e. what are the programs you're running and how to improve the perf. of these programs).
There's always have been at least some unification in programmable shader units, it's just growing a bit those days - the exposure given to the VS-PS unification goes into that trend.
IMHO the main advantage expected from this unification at the hardware level is a better responsiveness, and it's good for the simultaneous use of the GPU by several different programs (as in Vista). The advantages that it might give at this time in game performance are (still IMHO) rather debatable (but that's an interesting debate!).
Oh, and by the way, these G80 specs doesn't look real to me.
When will we get Embedded DRAM? G150?
That is absolutely correct. Unification allows basically, no downtime.
It would seem to me that in a unified architecture, you would need to have a pretty beefy scheduler to keep the right distribution of shader resources to prevent starvation and erratic framerates. And the overhead of that scheduler could be more than the performance gain from trying to keep every shader perfectly busy.
So a little downtime for a shader or two may be better than the overhead of a heavy-handed scheduler.
Since this is all speculation, though, there's an equal probability that I have it completely backwards :)
When will we get Embedded DRAM? G150?
Well, I don't whish to disapoint you of course, but... It looks to me like spending a few million transistors just to do antialiasing isn't really a priority, particularily when we already have a decent antialiasing with a lot less transistors...
Also, one may notice that a tiler (you're thinking of a tiler, right?) isn't anymore an immediate mode renderer, as it needs to sort the whole scene by tile in a way or another - and that's something that does have its cost. As long as the framebuffer bandwidth isn't a common limiting factor, we're probably better without a tiler...
Of course, if in the future deferred rendering became standard for instance, the framebuffer bandwidth might become more of a problem, and a tiler more desirable - but we're not there yet.
Ideally, that would become more interesting if we could embbed the whole framebuffer because we would then be back to a true immediate mode renderer. However, that's a not just a few transistors we're speaking of: if we count in 2 video outputs x 2 buffers per output (front buffer + back buffer) x 12 bytes per pixel (RGBA fp16 + 24 bits zbuffer + 8 bits stencil) x 2073600 pixels per buffer (true 1080p resolution), then we already have three quarters of a gigabit...
vBulletin® v3.7.1, Copyright ©2000-2012, Jelsoft Enterprises Ltd.