View Full Version : Interesting Cebit Report...
Here we go: http://www.aceshardware.com/read.jsp?id=45000320
Any thought?
Marco
LeStoffer
01-Apr-2002, 11:29
multi-die BGA configurations?
Ahhh, the fond remembrance of the Pentium Pro! While that turned out to be too expensive, this could be pretty cool. But you still need very fast DDR - or could you cram a 256 bit path onto a BGA? Hmmm, thank God I don't have to lay out all those traces! :o
By Johan De Gelas
Monday, April 1, 2002 12:28 AM EST
i dont trust anything today...
Joe DeFuria
02-Apr-2002, 17:34
Well, it doesn't appear to be any type of April Fools content.
The Multi-Die BGA set-up looks like a very good way to me to significantly increase bandwidth without having to go 256 bit wide external path.
Why not have the following?
GPU Core, plus 32 MB, 128 bit DDR "on package", plus 64 MB, 128 bit DDR "external" memory? What type of physical limitations would this have vs a traditional 96 MB of 256 bit DDR Ram, all "external" to the chip package? (Would this impose a synchronous core/memory clock? Or can the on-chip and off-chip ram be asynchronous with the core, or even each other?)
That gives you 256 MB DDR data path, without having the need for the so-called "prohibitively expensive" 256 bit chip packaging. Of course, there is an increased expense for putting the 32 MB DDR "on pacakge", but I assume that's much less costly than the alternative.
Why cant they call them MCM's anymore?
Cause the new name is cool :-?
Joe:
GPU Core, plus 32 MB, 128 bit DDR "on die", plus 64 MB, 128 bit DDR "external" memory? What type of physical limitations would this have vs a traditional 96 MB of 256 bit DDR Ram, all "external" to the chip p? (Would this impose a synchronous core/memory clock? Or can the on-die and off-die be asynchronous with the core, or even each other?)
My view points:
-the "on package" idea looks very good.
-Probably the memory chips will be custom chips with large bus width
-Depending on what you use it for maybe 16MB or less could be enough (less expensive chips, smaller, cooler). XBA design have a 12MB for framebuffer. IIRC Gamecube has some 1T-SRAM for framebuffer.
-The external memory and the "internal" memory dont need to be syncronous or have the same frequency. The internal could be faster.
That gives you 256 MB DDR data path, without having the need for the so-called "prohibitively expensive" 256 bit chip packaging. Of course, there is an increased expense for putting the 32 MB DDR "on die", but I assume that's much less costly than the alternative.Probably yes.
Mfa:
Why cant they call them MCM's anymore?Maybe there are different packaging technology capable to have more than one chip, and multi-die BGA is an specific kind of MCM.
mboeller
02-Apr-2002, 19:30
Joe DeFuria;
IMHO You miss the most important part of the article :
very high bandwidth due to high speed and wide busses !
So; how about 512bit x 400MHz x 32 - 64MB onchip + 128bit x 300MHz off-chip for an highend solution.
This MCM's could mean the best of both worlds. High bandwidth like an eDRAM-solution
but only marginally higher cost than an normal design due to the usage
of "normal" DDR-RAM.
For me it seem's that both, Nvidia and ATi will go in this direction. ATi already uses it for it's mobile chips/cards and Nvidia will use it in the near future with the mobile version of the NV17. So why not use it in the desktop area as well. Maybe it is even cheaper than going 256bit externally.
That would have to be a big chip, to avoid getting pad limited.
Looks like that the "multi-die BGA could be better than edram for short term" is not new: http://www.theinquirer.net/30070101.htm. Please introduce yourself and your position at ATI?
A. My name is Ed Knight and I am a Technical Marketing Manager for ATI Technologies, Europe.
........
Q. Are we going to see "on die" memory in future chips from ATI?
A. I'm not aware of any plans to integrate memory onto a graphics die for an ATI chip in the near future. ATI has been offering integrated memory in the multi-die-BGA-packaged Mobility chips for some time. However, combining memory and logic technologies on a single die whilst maintaining good performance and yields is more difficult, so I doubt we'll see this in the short term.
MBoeller:
very high bandwidth due to high speed and wide busses !
So; how about 512bit x 400MHz x 32 - 64MB onchip + 128bit x 300MHz off-chip for an highend solution.
Maybe 512bits is too much, but what about the configuration below?
256MB 128bits 400MHz DDR-II external (12.8GB/s) (large .13micron chips :) )
32MB 128bits 600MHz DDR-II internal ( 19.2GB/s) (edram level performance)
edited: The Rage Mobility 128 was priced $55 in 10.000 quantities (1999 prices), then it is not an expensive technology :)
Joe DeFuria
02-Apr-2002, 21:35
Hmmm...I seem to be on a slightly different page here.
-Probably the memory chips will be custom chips with large bus width
I disagree. The point, IMO, would be to use relatively "standard" DRAMS(to reduce cost), and "standard" bus widths / implementation to minimize custom memory controller design. I don't think ATI or anyone else would want (initially) to have the on-package ram running async. with the board memory. That would require a completely different memory management scheme than the current GPUs use. Such a scheme could eventually be beneficial and certainly more flexible, but to keep initial costs down, I think the point would be to have the GPU to basically not be aware of "where" the memory is. It should just see a pool DDR ram, with a total width of 256 bits of access.
Then they could re-use the same GPU core in multiple configurations (as they did with the Mobility Radeon), both with and without the "on-package" ram.
Maybe 512bits is too much, but what about the configuration below?
256MB 128bits 400MHz DDR-II external (12.8GB/s) (large .13micron chips )
32MB 128bits 600MHz DDR-II internal ( 19.2GB/s) (edram level performance)
I also believe (contrary to what most seem to be posting here), that the "on-package" ram speed will be more difficult to ramp up vs. the off-package ram. I don't see the on-package ram as being some "high-speed" memory component like edram, but quite simply just "more of the same" DDR memory. I would think that having multiple components lumped together in a relatively small space should make it more difficult to get high clock rates. (Both for the GPU and the memory.)
I would hope that a reasonable configuration would be something like the following:
* 8 Pixel Pipes, 300 Mhz Core
* 32 MB 128 bit DDR Ram @ 300 Mhz "on package"
* 64 MB 128 bit DDR Ram @ 300 Mhz "off-package"
In theory you could use a more efficient pipelined application specific interface for the memory, with a higher bandwith per pin and/or lower power requirements per bps because signal integrity is easier to guarantuee. They could use a eDRAM process to roll their own memory chips but still retain the advantages of being able to do their own interfacing and the modular approach, without having to design the memory from the ground up.
As you say though, if you dont use standard chips you get a cost disadvantage ... and MCM's are probably still not a cheap way of manufacturing a chip on top of that.
I dont think power requirements will prevent speed ramping of the internal memory chips since external one's usually still dont have their own heatsinks, let alone active cooling ...
The memory should not look like a single memory pool IMO, not managing them seperately would be unacceptable unless they were approximately the same size and bandwith (then loadbalancing breaks down to just equally dividing everything).
Marco
mboeller
03-Apr-2002, 07:47
Hmmm...I seem to be on a slightly different page here.
I disagree. The point, IMO, would be to use relatively "standard" DRAMS(to reduce cost), and "standard" bus widths / implementation to minimize custom memory controller design. I don't think ATI or anyone else would want (initially) to have the on-package ram running async. with the board memory. That would require a completely different memory management scheme than the current GPUs use. Such a scheme could eventually be beneficial and certainly more flexible, but to keep initial costs down, I think the point would be to have the GPU to basically not be aware of "where" the memory is. It should just see a pool DDR ram, with a total width of 256 bits of access.
I also believe (contrary to what most seem to be posting here), that the "on-package" ram speed will be more difficult to ramp up vs. the off-package ram. I don't see the on-package ram as being some "high-speed" memory component like edram, but quite simply just "more of the same" DDR memory. I would think that having multiple components lumped together in a relatively small space should make it more difficult to get high clock rates. (Both for the GPU and the memory.)
I disagree here :)
How about an 400MHz GPU with at least 32MB onchip-RAM @ 400 MHz and 128MB off-chip RAM @ 200MHz + virtual texturing (to save bandwidth)
( with 400MHz onchip and 200MHz offchip it should be possible to access both memories with one memory controller ).
IMHO 32MB are the absolute minimum for onchip RAM, cause you need this amount of memory even when using no AA at all ( 1600x1200x2x48bit + 1600x1200x32 = ~ 30 MB ). When you use MSAA then the memory requirement is even higher. Otherwise you could only store the Z-buffer onchip ( and hopefully use an nearly 100% efficient early Z-check to lower the overall bandwidth requirements )
An 512bit would be tough I agree, because you would need 16 small 16Mbit - 32Mbit memory chips. IMO the speed should be no problem, cause you can cool them more efficiently together with the GPU, then off-chip. The chip would be hugh but this would only help to cool the die's inside.
MCM's should be cheap, otherwise I cannot see why Sony used this in the PS1.
Joe:
I disagree. The point, IMO, would be to use relatively "standard" DRAMS(to reduce cost), and "standard" bus widths / implementation to minimize custom memory controller design. I don't think ATI or anyone else would want (initially) to have the on-package ram running async. with the board memory.
I agree that standard dram probably would simplify and reduce cost of the design/test of the GPU and will cost nothing with design drams.
That would require a completely different memory management scheme than the current GPUs use.
The 256bits memory (128 int + 128 ext) will require memory management (and cache and the entire GPU Datapath) redesign anyway to prevent the potential bottlenecks.
Such a scheme could eventually be beneficial and certainly more flexible, but to keep initial costs down, I think the point would be to have the GPU to basically not be aware of "where" the memory is. It should just see a pool DDR ram, with a total width of 256 bits of access.
Generally I agree that twice the bandwith with keeping the cost down is a good police :wink:
Probably you are talking about a single address space (UMA) right? See the comment below.
Now I need some help here. AFAIK the 300MHz DDR memories are new and probably there is not much different designs available. Probably most designs are 4Megaaddress x 16bits x 2 (DDR), it means 4 mega address and each address with one 16 bits (width) word times 2 (DDR).
Probably the idea is to use the multi die BGA with one GPU chip and one or two dram chips. Lets say we will use two then it means 64bits width.
Question: are there any 300MHz DDR dram chip with 64bits width?
Then they could re-use the same GPU core in multiple configurations (as they did with the Mobility Radeon), both with and without the "on-package" ram.
Sounds good to me.
also believe (contrary to what most seem to be posting here), that the "on-package" ram speed will be more difficult to ramp up vs. the off-package ram. I don't see the on-package ram as being some "high-speed" memory component like edram, but quite simply just "more of the same" DDR memory.
If possible then lets have more of the same dram. Also the Amdhals´s law will put a limit (better a curve, I think you call it diminishing returns) with the maximum contribution the internal memory can have. The external dram will be the bottleneck in some situations.
I would think that having multiple components lumped together in a relatively small space should make it more difficult to get high clock rates. (Both for the GPU and the memory.)
Usually it is the oposite. The PCB capacitance usually is a problem.
Joe:
8 Pixel Pipes, 300 Mhz Core
* 32 MB 128 bit DDR Ram @ 300 Mhz "on package"
* 64 MB 128 bit DDR Ram @ 300 Mhz "off-package"
Lets have it now 8)
Comment: But see that load balance is dificult for textures because it requires a lot of memory.
Mfa:
In theory you could use a more efficient pipelined application specific interface for the memory, with a higher bandwith per pin and/or lower power requirements per bps because signal integrity is easier to guarantuee. ...
That is true.
Mboeller:
IMHO 32MB are the absolute minimum for onchip RAM, cause you need this amount of memory even when using no AA at all ( 1600x1200x2x48bit + 1600x1200x32 = ~ 30 MB ). When you use MSAA then the memory requirement is even higher. Otherwise you could only store the Z-buffer onchip ( and hopefully use an nearly 100% efficient early Z-check to lower the overall bandwidth requirements )
Most people play at 1024x768x32 or lower (77%) then if you offer people a great gameplay experience at 1024x768x32 with FSAA my guess the other people (23%) will accept lower the resolution to 1024x768x32.
An 512bit would be tough I agree, because you would need 16 small 16Mbit - 32Mbit memory chips. IMO the speed should be no problem, cause you can cool them more efficiently together with the GPU, then off-chip. The chip would be hugh but this would only help to cool the die's inside.
Maybe it is too much chips for multi die BGA.
MCM's should be cheap, otherwise I cannot see why Sony used this in the PS1.Those people (Nvidia, ATI and others) are saving few dollars and losing a lot of market.
BTW why the hell would you bother with external memory at all? I know Ace's suggested it, and as such they were probably quoting ATI ... but still I dont see the point. The number of chips is not a real problem AFAICS, with flip chip bonding there is plenty of room on the substrate.
You can still not grow the busses as wide as you would want, since as I said before you would get pad limited (pad's on the die only occur on the edges, and their size is large enough to make them a bottleneck in some cases ... area interconnects are the future, but that will take a while). But all in all I dont really see the advantage of keeping external memory.
Joe DeFuria
03-Apr-2002, 14:50
Usually it is the oposite. The PCB capacitance usually is a problem.
Heh...good thing I don't design hardware. ;)
BTW why the hell would you bother with external memory at all?
Well, I wouldn't want too, but based on little mroe than speculation at this point, I was thinking that 64-128 MB of 256 bit DDRAM would not be physically implementable (real estate wise) on one of these multi-BGA packages at a reasonable cost. So simplistically, I was thinking keep today's 128 bit external interface to ram, and use an "internal" 128 bit bus for the on package ram.
If I'm wrong, then I'd agree....just put all of the DDRAM in the package!
Does anyone know the specifics of ATI's mobility chips, in terms of what configurations they offer (RAM wise). I haven't been able to find much detail from ATI's stie...
mboeller
03-Apr-2002, 16:26
Does anyone know the specifics of ATI's mobility chips, in terms of what configurations they offer (RAM wise). I haven't been able to find much detail from ATI's stie...
Maybe the report helps :
http://maccentral.macworld.com/news/0108/27.mobilitydetail.shtml
The chip has up to 32MB onchip memory.
The info I found: http://www.google.com.br/search?q=cache:x5s8CbI8Md4C:www.atinfo.ru/Chips/RAGE_mobility_128.pdf+mobility+bga++memory+ati&hl= pt
Mfa:
BTW why the hell would you bother with external memory at all? Joe:
If I'm wrong, then I'd agree....just put all of the DDRAM in the package!
Yeah, put everything in the package with a big 256bits UMA 8)
Mfa,
Do you know were can we have some price information about the different packages? Thanks
Joe DeFuria
03-Apr-2002, 18:10
Thanks for the links!
Here's the juicy bit for the Radeon 7500 Mobility:
ATI has developed three different variants of the Mobility Radeon 7500. The first configuration is a graphics-only variant, which leaves it up to the laptop maker to install graphics memory on the motherboard to support the chip. ATI also has versions with an integrated 16MB frame buffer and a 32MB frame buffer as well -- and up to 32MB of additional graphics memory can be supported on the laptop, for a total of up to 64MB.
So, ATI already has a design where they can implement 32 MB "on package", plus accept up to 32 MB "off package". Tom's hardware has a review of the 64 MB Variant of the Mobility 7500.
http://www4.tomshardware.com/mobile/02q1/020220/radeon7500-02.html
They list the specs as 64 MB, 128 bit DDR. So I assume each memory interface is 64 bit DDR, to give a total of 128 bit DDR interface for the implementations with both on-package and off-package ram. I don't think you can get the Radeon 7500 mobility with 128 bit DDR, UNLESS you supply external ram. That is, the "on-package" RAM is limited to 64 bit DDR only. Presumably because of cost / power consumption / or physical limitations of the current tech.
Also interesting is that the RAM does indeed operate asynchronously with the core. (But I assume the on-package and off-package ram operates at the same frequency.)
Theoretically, this part should be on par with a "standard" Radeon 7500 running at the same clock speed. Would be interesting to see if this "split" ram set-up is equally effective as a single pool of "external" memory. Unfortunatley, Tom doesn't benchmark against the desk-top counterparts, only the GeForce2 go. Maybe I can find another review...
In any case, I can see ATI logically extending this technology to support dual 128 bit DDR interfaces instead of dual 64 bit interfaces. (Plus increase ram density, for a 64+64 config.) Based on ATI's current experience and apparent success with the tech, I presume this would be more cost effective than going with a fully fledged 256 bit external interface. I still also believe (just a hunch) that putting the full 256 bit footprint of ram "on package" is likely not doable at this point.
More speculation.
What about a "small" edram chip using a high frequency 64bits interface to the GPU.
Something like a:
-128bits 400MHz DDR (12.8GB/s) from external UMA to the GPU
-64bits 800MHz DDR (12.8GB/s) from 16MB edram to the GPU
Pros
-Only 64 more data pads in the GPU
-Only 64 more lines in the multi-die BGA
-relativally cheap edram
-modularity
Note that only the interface need to be high frequency and will use multiplexing to connect to lower frequency GPU and edram cores.
-64bits 800MHz DDR (12.8GB/s) from 16MB edram to the GPU
On what process does a so fast dram commodity exist?
My guess nobody has such a high frequency (800MHz) core sdram.
edited: The high frequency is only for interface, internally use some 256bits or 512bits at lower frequency and multiplex it to the 64bits.
It means only 400 or 200MHz internaly.
The idea is get some advantage of the multi-die BGA high frequency potential. Anyway, it is just speculation :)
They list the specs as 64 MB, 128 bit DDR. So I assume each memory interface is 64 bit DDR, to give a total of 128 bit DDR interface for the implementations with both on-package and off-package ram. I don't think you can get the Radeon 7500 mobility with 128 bit DDR, UNLESS you supply external ram. That is, the "on-package" RAM is limited to 64 bit DDR only. Presumably because of cost / power consumption / or physical limitations of the current tech.
I don't believe this is the case, IIRC from the information I read on the chip, the memory included in the package is connected with a true 128bit interface. I believe this was at inquest, ATi or Rage3d's site. I can't remember it was a while back. I'm pretty sure it was a true 128bit bus. The external bus on the other hand is limited to 64bits.
Joe DeFuria
04-Apr-2002, 19:40
I'm pretty sure it was a true 128bit bus. The external bus on the other hand is limited to 64bits.
Hmmmm...interesting if true. I would assume then, that if external memory is used, the internal bus is also only implementable at 64 bits. It would only be in implementations without external memory, you'd have the option of going with 64 or 128 bit DDR internal bus.
Maybe someone from B3D could ask ATI to clear this up. If what you're saying is true, then I'd say ATI is closer to being able to produce a "dual" 128 bit bus than I had thought.
Maybe ATI-ISV could clarify it :)
Joe DeFuria
04-Apr-2002, 19:52
Hmmmm...interesting if true.
It seems that it isn't true. ;)
http://www.inqst.com/articles/radeon/0826main.htm
The chip can support a 16MB or 32MB 64-bit DDR configuration for the mainstream, and a 32MB or 64MB 128-bit DDR configuration for the high end. From an integration standpoint, ATI offers a small MCM package option that integrates 32MB in a 64-bit configuration to optimize the footprint for tighter design requirements. Interestingly, this package also allows the addition of the second channel of 32MB externally, delivering 128-bit performance in a footprint comparable to other 64-bit 32MB designs.
This quote is a little ambiguous, but I would say it indicates that the internal bus is limited to 64 bits.
It is 128bits (64bits internal+ 64bits external): http://www.rage3d.com/reviews/mobility7500/m7500-3.shtml
Anyway ATI, if 256bits is not possible then just give us 192bits :wink:
Joe DeFuria
04-Apr-2002, 20:19
Thanks for the link!
Anyway ATI, if 256bits is not possible then just give us 192bits
Exactly...why not have a 32 MB, 64 bit, internal + 64 MB, 128 bit External, configuration, giving a 96 MB Card with a 192 bit interface? (Maintaining a constant ram density per bandwidth).
Seems like that would be the sweet spot!
It is 128bits (64bits internal+ 64bits external): http://www.rage3d.com/reviews/mobility7500/m7500-3.shtml
Anyway ATI, if 256bits is not possible then just give us 192bits :wink:
256 Bits is possible and it looks like to be closer than most of you think...
RussSchultz
05-Apr-2002, 02:44
It is 128bits (64bits internal+ 64bits external): http://www.rage3d.com/reviews/mobility7500/m7500-3.shtml
Anyway ATI, if 256bits is not possible then just give us 192bits :wink:
256 Bits is possible and it looks like to be closer than most of you think...
And the prophetic Nappe1 speaks again! (one of these days you'll be right! :D )
256 Bits is possible and it looks like to be closer than most of you think...
But how close is it really? E3, 22th May maybe?
And it is interesting how many people would like to say something about Matrox's next gen but can't:
http://www.aceshardware.com/forum?read=65040995
256 Bits is possible and it looks like to be closer than most of you think...
But how close is it really? E3, 22th May maybe?
And it is interesting how many people would like to say something about Matrox's next gen but can't:
http://www.aceshardware.com/forum?read=65040995
well, I am not suprised. if even half of things that I have heard are true, they have small revolution coming... and if all is true, they will cause hard time even to the R300 ( in a light of rumoured specs.)
and it's not going to be a cheap, but still I am sold and want one of those cards though I haven't seen any benches yet. (I have only idea about theorical performance.)
Joe:
Exactly...why not have a 32 MB, 64 bit, internal + 64 MB, 128 bit External, configuration, giving a 96 MB Card with a 192 bit interface? (Maintaining a constant ram density per bandwidth).
Seems like that would be the sweet spot!
Sounds good. It means a 384 bits memory access (192bits DDR) or three 128bits words.
Two 128bits words could go for textures cache (like nvidia do) and one 128bits could go for vertex or framebuffer cache.
It will have a lower latency and higher bandwith than the LMA (Lightspeed Memory Architecture) when trying to access the framebuffer and textures simultaneouslly. And could be relativally cheap too http://www.plauder-smilies.de/smokin.gif
well, I am not suprised. if even half of things that I have heard are true, they have small revolution coming... and if all is true, they will cause hard time even to the R300 ( in a light of rumoured specs.)
and it's not going to be a cheap, but still I am sold and want one of those cards though I haven't seen any benches yet. (I have only idea about theorical performance.)
Nappe1, I (and many like me) wish you are right. http://www.plauder-smilies.de/jump.gif
I was thinking about the nforce IGP (northbridge) . It has:
- 2 64 bits DDR memory channels
- 1 64 bits DDR CPU channel
- 1 AGP interface
- 1 Hypertransport interface
- 1 RAMDAC
- other functions.
http://www.socketa.com/reviews/chipsets/nvidia/nforce/NewArchitecture.jpg
It has a lot of pins ("320 pins in a BGA"). IIRC someone (pcchen ?) said that GF4 has almost 1 thousand balls. Then tell me again why we can not have 192 or 256 bits data bus for graphics.
I wouldn't worry too much about memory bandwidth. Each chip coming out in the DX9.x time frame should have sufficient memory bandwidth for their needs, though they will not necessarily use the same techniques.
Something interesting to note is that since the different technologies are available to all the competitors, what distinguishes one from the other.
For one thing, larger companies can afford less risk since they have higher fixed expenses. Therefore the newest (and the riskest) technologies are often adopted by the smaller firms first. However, larger firms bring more stablity and consistency. In addition, larger firms have the resources to devote to very thorough driver development and QA. Finally, they also have larger budgets to do more R&D and to buy outside technologies to move quickly when they need to.
One major competitive difference in the 3d chip business, however, is when some firm manages to step outside the box to significantly increase the transistor count over their competitors in a cost effective fashion. This would probably have more immediate impact than anything mentioned above.
Dave Baumann
16-Apr-2002, 10:19
One major competitive difference in the 3d chip business, however, is when some firm manages to step outside the box to significantly increase the transistor count over their competitors in a cost effective fashion.
Such as, errrr, moving a large chunk of silicon outside of the main 3D core and having it as a separate co-processor?
Such as, errrr, moving a large chunk of silicon outside of the main 3D core and having it as a separate co-processor?
Is it cost effective?
I wouldn't worry too much about memory bandwidth. Each chip coming out in the DX9.x time frame should have sufficient memory bandwidth for their needs, though they will not necessarily use the same techniques.
An optimistic point of view?
What if are they (ATI and nVIDIA) really going to double pixel pipelines?
Maybe just going with faster memory and improving current occlusion culling schemes wouldn't be enough...but it could be just a future proof move..
ciao,
Marco
LeStoffer
16-Apr-2002, 10:43
I wouldn't worry too much about memory bandwidth. Each chip coming out in the DX9.x time frame should have sufficient memory bandwidth for their needs, though they will not necessarily use the same techniques.
Would you care to elaborate on this, SA? Are you talking about DX9 features like the ability to address several ( 8 ) textures in one pass etc.?
Memory bandwidth is a bit like money. While it is possible to have enough for your current needs it seems you can never have as much as you want.
I think I am starting to understand, but I am still confused.
More bits requires:
- More pads
- More package pins
- Better PCB
- More memory chips ???? (twice more chips when going from 128bits to 256bits UMA because of the memory chip bus width )
Then the large companies decide that is better have more transistors doing data compression, larger caches, multisampling, more textures per pass, better memory architecture, some occlusion culling, etc... and we still have some tricks to do or improve.
Also large companies will not take the risk. Then I speculate we can expect a NV30 with 128bits 800Mhz (12.8G B/s) with +8 textures in an single pass, much better occlusion culling and very large caches. The same from ATI.
Some smaller companies will take the risk with exotic technology.
One major competitive difference in the 3d chip business, however, is when some firm manages to step outside the box to significantly increase the transistor count over their competitors in a cost effective fashion.
Such as, errrr, moving a large chunk of silicon outside of the main 3D core and having it as a separate co-processor?
And maybe simultaneouslly using a new fabrication process like .13 micron? Is anyone doing it?
vBulletin® v3.8.6, Copyright ©2000-2013, Jelsoft Enterprises Ltd.