PDA

View Full Version : G90/92: Is this why 8800s are being sold off here?


Pages : 1 [2]

retsam
06-03-07, 07:51 AM
Well that's where NVIDIA said they were headed by 2010. So, regardless if it's needed now or not...that's where we're headed.
who said that at nvidia?...

MUYA
06-03-07, 11:34 PM
who said that at nvidia?...
Rets...since u are technical..and I am not. Multi core GPU....normal thinking is that GPUS are multi cored anyway in terms of blocks..were in pre unified architecture...even so now in unified architecture...essentially GPUS are multi cored! However, talking in terms of multicore alal CPU style would you think that would mean that if indeed NV or ATI for that matter are talking about multi it would be SLI/crossfire enabled on die? With each GPU however having shared memory ratehr than seperate need for famre buffers erm video mem? would this be a performance advantage over a physically implemented (outside of the die) SLI or crossfire?

ephmrl
06-04-07, 12:20 AM
Multi-cored anything is going to be a general trend for larger designs (modern cpu's or gpu's) as a means to address defect density and reduce impact on yields. Depending on the particular design, process, and manufacturer, it may make more sense to push products that are multicored (glue'd, sli'd, etc) regardless of how inherently parallelized the underlying architecture already is as a means to produce a higher skewed product...

rhink
06-04-07, 12:52 AM
Rets...since u are technical..and I am not. Multi core GPU....normal thinking is that GPUS are multi cored anyway in terms of blocks..were in pre unified architecture...even so now in unified architecture...essentially GPUS are multi cored! However, talking in terms of multicore alal CPU style would you think that would mean that if indeed NV or ATI for that matter are talking about multi it would be SLI/crossfire enabled on die? With each GPU however having shared memory ratehr than seperate need for famre buffers erm video mem? would this be a performance advantage over a physically implemented (outside of the die) SLI or crossfire?

GPU's aren't really multicore in the same sense as CPU's, and I don't think it makes sense to do it that way either (completely independent processors on the same die). It does make a lot of sense to have multiple functional blocks that can be enabled/disabled if that section has a defect (and NVIDIA's done that since long before a multicore CPU was on the market). It's still not the same thing as if you took a pair of G80's, die shrunk them, and put them on the same piece of silicon though.

MUYA
06-04-07, 01:02 AM
GPU's aren't really multicore in the same sense as CPU's, and I don't think it makes sense to do it that way either (completely independent processors on the same die). It does make a lot of sense to have multiple functional blocks that can be enabled/disabled if that section has a defect (and NVIDIA's done that since long before a multicore CPU was on the market). It's still not the same thing as if you took a pair of G80's, die shrunk them, and put them on the same piece of silicon though.
I didn't say they were multicored...just in terms of blocks, basically parralelism. Almost akin...but not exactly and as you stated the reason why it is easy to have derivatives. I didn't say that parralelism is the same as having two distinctive cores on one die. I just said if talking in terms of CPU multicoring, then if u did slap on two distintictive cores on one die, they would have to be connected somehow, was thinking hmm SLI or crossfire type connections.

I think you need to re-read what I said ;)

rhink
06-04-07, 10:01 AM
Right. What I'm saying is I don't think it makes sense to "multicore" in the sense of a CPU (two distinct processors on the same chip) b/c graphics already lends itself so well to parallelism within the same "core", there's really no need- instead of multicore, you just increase the number of pipelines/shaders on the same chip. And you lose some efficiency (not to mention compatibility) with xfire/SLI, so I'm not sure what you'd gain by that approach.

ephmrl
06-04-07, 10:48 AM
What I'm saying is I don't think it makes sense to "multicore" in the sense of a CPU (two distinct processors on the same chip) b/c graphics already lends itself so well to parallelism within the same "core"

Yeah it does, that's why sli and cf exist today. Whether they are on different PCBs or crammed into the same bga or pcb, the intent is to increase parallelism at a courser granularity (an entire system/chip/core) even though each chip is already highly parallelized at a finer level (functional units / alu's / etc).

If you are more arguing against the likelihood of marrying cores within packages, or producing silicon joined multicores, then that makes more sense since there are no standard sockets for gpu's at this time, and defect density issues would get worse with bigger die (i.e. native multi-core).

However, as either of those changes, say with advances in "streaming" processors such that they get their own standardized sockets (a possible outcome for graphics solutions), and they are produced on mature processes with very high yields, it's likely cpu-like multicore will be used for these processors for the same reasons they are pursued today (easy way for tiering up product offerings, crudely managing thermal constraints, blah blah blah)...

The main point is that already being highly parallelized will not be the deciding factor in making a multi-core solution for any "chip". Market factors will continue to dominate, followed by ease/cost of production. Since this is the current trend in the CPU landscape, it seems a bit premature to dismiss the possibility wholesale that this is being researched for future GPU products in development (especially GPGPU)...

Remi
06-06-07, 12:56 PM
While we're speaking of parallelism and multicores, I think there's an important thing to note.

We enjoyed for a few years a stable memory slot, with sdram ddr. We now have multicore cpus, and have said bye-bye to DDR, welcome to DDR2. Oh, wait, no, I meant welcome to DDR3. By the way, have someone heard of DDR4?

I think you can see where I'm going with that. Yep, an important side of the multicores is: how do you feed them on data? Ideally we just would multiply the ram bandwidth as we mutliply cores, but that's not feasible in the cost-sensitive way that's compatible with products for the general public.

Taking a pair of G80s and packaging them in the same chip, or on the same card, won't double the perf. unless the ram bandwidth doubles too.

That's where the SLI concept enters: by using two cards, the system do see its memory bandwidth doubled.

So in fact, that idea of multicoring GPUs isn't new at all and it even already exists! It's just that we tend not necessarily to think of SLI as the multi-core solution which it is. :)

walterman
06-06-07, 03:32 PM
Agree, memory bandwidth is god for multimedia apps.

While we're speaking of parallelism and multicores, I think there's an important thing to note.

We enjoyed for a few years a stable memory slot, with sdram ddr. We now have multicore cpus, and have said bye-bye to DDR, welcome to DDR2. Oh, wait, no, I meant welcome to DDR3. By the way, have someone heard of DDR4?

I think you can see where I'm going with that. Yep, an important side of the multicores is: how do you feed them on data? Ideally we just would multiply the ram bandwidth as we mutliply cores, but that's not feasible in the cost-sensitive way that's compatible with products for the general public.

Taking a pair of G80s and packaging them in the same chip, or on the same card, won't double the perf. unless the ram bandwidth doubles too.

That's where the SLI concept enters: by using two cards, the system do see its memory bandwidth doubled.

So in fact, that idea of multicoring GPUs isn't new at all and it even already exists! It's just that we tend not necessarily to think of SLI as the multi-core solution which it is. :)

rhink
06-06-07, 08:01 PM
Yeah it does, that's why sli and cf exist today. Whether they are on different PCBs or crammed into the same bga or pcb, the intent is to increase parallelism at a courser granularity (an entire system/chip/core) even though each chip is already highly parallelized at a finer level (functional units / alu's / etc).

Multicore CPU's/GPU's == multiple discrete processors per package/socket. An 8800 is no more multicore a multicore processor than a Pentium 2 is.

Sazar
06-06-07, 08:19 PM
I wonder if it would be feasible to have a proc on either side of a pcb (with more layers to compensate for noise) in an off-set position (allowing for better heat dissipation)

Or, if there was a way to eliminate heat as primary concern, perhaps even run parallel traces.

It would dramatically reduce the sheer size of the board but it would certainly add many layers to th substrate. The marchitecture would probably be a work of art initially :D

Drawback == the cooler would be cooling front and back so board designs may have to change and it might take a stackable cooler like the one being demo'd for the 2900's to make it work for sli.

ephmrl
06-07-07, 04:36 PM
An 8800 is no more multicore a multicore processor than a Pentium 2 is.

Did I say they were the same? Answer: NO

What I said is it makes perfect sense to multi-core GPU's. Furthermore I'll assert that's all that SLI/CF are, quick and dirty ways to achieve what multi-core is aimed at. Read my post again, or at least this last sentence...

The main point is that already being highly parallelized will not be the deciding factor in making a multi-core solution for any "chip".