geekcomputing
[H]ard|Gawd
- Joined
- Aug 30, 2004
- Messages
- 1,100
pretty simple.. vote.
Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature may not be available in some browsers.
PRIME1 said:I have been putting off my new computer build for DirectX 10 & Conroe. Conroe is here and if NVIDIA can come through in a few weeks.....woo hoo. To bad ATI could not launch at the same time, so we could have one big loud next gen love fest.
ElMoIsEviL said:R600 will be faster but arrive a few months later.
So I definitely won't get a GeForce 8800 until I see everything the R600 brings to the table. No sense in wasting cash on an 8800 if the R600 is as good as it's rumored to be, most peeps are doing the same thing.
Most sites are also leaning towards the R600, dunno why but it seems ATi is going to take this generation by storm.
TotallyPulledItOuttaHisButt.comgorilla show said:Can you post a couple of links to those sites? I wanna read about that since i haven't read much about R600![]()
PRIME1 said:TotallyPulledItOuttaHisButt.com![]()
Killdozer said:Neutral. NVidia hasn't wowed me since the Ti4200
personally the 6800 blew me away on a tech level but yea the 4200 was rocking for the price.
Ummm no. If you just read comments from the most knowledgeable peeps in the Video Card community (mainly Beyond3D members) you'll see that most have this sneeking suspicion with regards to R600. Mainly because R600 is soo secretive and the words coming out of Orton's mouth.PRIME1 said:TotallyPulledItOuttaHisButt.com![]()
Why here talking about this instead of five years ago? These problems are becoming more relevant to a broader audience. Research has been done. GPU has evolved to being multiple processors. 48 today, general FP engines. Direction now is to move to common elements for geometry, raster processing. Today, it's 48, future, maybe it's 96.
CPUs are now talking about two, four cores.
We have 375 gigaflops, 64 GB/s. We're about a third of a teraflop. Next generation will exceed half a teraflop on a single GPU.
This class of problems scales very well for parallel processors.
The R600 is estimated to be the largest GPU ever made. Production based on an 80 nm process with ATI having 65 nm clearly in sights
ElMoIsEviL said:Ummm no. If you just read comments from the most knowledgeable peeps in the Video Card community (mainly Beyond3D members) you'll see that most have this sneeking suspicion with regards to R600. Mainly because R600 is soo secretive and the words coming out of Orton's mouth.
96 Unified Complex Shaders, 512-bit memory interface and over 500GFlops (Half a TeraFlop). These alone would push R600 ahead. This is what Orton hinted about.
Then the power Requirments. R600 takes almost twice the power of G80 and has been declared as being the most advanced and LARGEST GPU/VPU ever conceived.
I didn't pull any of this out of my butt.
CLICKME!
Wikipedia R600
G80 will be the fastest GPU for a few months... when R600 strikes I doubt G80 will still be the fastest. All of ATi's shortcomings have also been fixed. Native Crossfire support with no dongle and integrated Compositing engine are also part of the package.
from ortan's interview so lets just say the r600 will end up around 2 times the performance of an r580. The g80 will do quite a bit more then 500 gigaflops as well, both cards will be close in performance, highly dependent on what clock speeds each GPU is run at of course.exceed half a teraflop
I explained the quantities:
The GPU presumably consists of groups of pipelines in order to provide some kind of physical locality, e.g. four groups each of which consists of:
8x quad-scalar ALU processors
3x quad-TMU/ROP fetch/store processors
2x VB/CB fetch/store processors
So that's 32 ALU, 12 TMU/ROP and 2 VB/CB processors per group, with 4 groups, total: 128, 48 and 8 respectively.
It's worth pointing out that you don't really need 3x four separate TMU/ROP fetch processors, you prolly actually have 3 processors, each of which delivers a quad (or multiple thereof) of data. A similar thing goes for the VB/CB processors. They don't necessarily just fetch one item of data, they prolly fetch a block of data, e.g. 32 bytes, 128 bytes, etc. (Something similar to this happens in Xenos with VB/CB.) So the two VB/CB processors will each be able to fetch/store some data in parallel.
As for clock speeds, ALU and VB/CB-fetch are at 1350MHz and TMU/ROP-fetch is at 575MHz. I am just guessing to "match the numbers" here...
The key thing to note in my hypothesis is that a lot of the die that is normally taken up with TMU/ROP pipelining (perhaps half the total area of G71?) is now given over to ALUs, with very compact fetch/store processors which at most only have to perform some simple integer arithmetic, and which have a far less troubled time hiding latency. These fetch/store processors are smaller than TMUs/ROPs because they are only working out what memory addresses to access and then reading/writing. Being dedicated like this, and with the thread scheduler responsible for working out how to hide latency, these units are only minimally pipelined, too.
---
I really do think G80 will be a FLOPzilla due to programmable TMU/ROP, utterly dwarfing R600. Is now the right time for fully programmable TMU and ROP?
One of the intriguing things about this kind of architecture is that whereas R600 has VS, GS and PS threads to switch amongst, G80 would have VS, GS, PS, TMU and ROP threads. The increased quantity of choice might look awkward, but it actually provides a good opportunity for more finely-grained time-slicing of work.
NVidia appears to be building a GPU that prefers not to thread out of order (i.e. it won't thread PS out of order if there's the slightest chance of a problem with overlapping triangles resulting in the wrong results - see my earlier posting about the PIOR flag). ATI's solution to this problem is, I guess, buffering the finished pixels and sorting them back into the correct order.
So, G80 looks like it will process a lot of PS threads in order. Which theoretically presents a bit of a problem when texturing latency, for example, is encountered. Now the set of pixels in flight for threading is constrained to just those pixels that are part of the same "step" (e.g. somewhere else on the same triangle). But, with both TMU and ROP work now available as choices for the ALU pipes to execute, you have a wealth of other work to fill the latency gap. The ALUs can now work on some texture filtering or some AA sample generation. Since TMU and ROP work are both separately queued (and kept in order) everything (PS, TMU and ROP) marches along roughly together and order is maintained, e.g.: