when will 512bit memory bus come?
- Thread starter malcolm
- Start date
Voodoo Graphics is 64 bits IIRC. However it has segmented memory (frame buffer/texture), both has 64 bits memory bus. So it can be seen as a combined 128 bits bus if you want. The first 128 bits bus 3D chip I know is RIVA 128, but it is not really fully exploit the benefit of 128 bits bus (just lke the 256 bits P10 VPU or Parhelia).
Until the bandwidth limits of a 256bit bus start to bite I don't think we'll see a 512bit bus. It would be horrible to try and implement as well.
Malcom,
IANA Hardware Engineer but....
The problem with a very wide bus is the external pin connections. Each pin needs a reasonably large area on the chip (called a pad I think) and a relatively large power requirement to 'drive' it. Furthermore, you need a certain number of ground and power pins per 'communication' pin (I think I heard it was about 1 pair per every 5 pins) and so these also have to be factored in. This means that your chip may become excessively large just to accomodate the wider bus. You might be better off using that silicon area for, say, a bigger cache. <shrug>
IANA Hardware Engineer but....
The problem with a very wide bus is the external pin connections. Each pin needs a reasonably large area on the chip (called a pad I think) and a relatively large power requirement to 'drive' it. Furthermore, you need a certain number of ground and power pins per 'communication' pin (I think I heard it was about 1 pair per every 5 pins) and so these also have to be factored in. This means that your chip may become excessively large just to accomodate the wider bus. You might be better off using that silicon area for, say, a bigger cache. <shrug>
With shaders in its infancy and promises so much more than what is being currently implemented (and understandably so), GPU performance is more important than bandwidth since the latter will not be as big a performance-limiting issue as the former. Of course, as games become more and more texture-intensive (as it should be, based on current games), bandwidth may become as important an issue as GPU performance.
As I continue to refine my PS research by adding more and more new 512x512 textures to the "level", I have found more performance benefits (percentage-wise) from overclocking the core of a R300, NV31 and NV34 compared to overclocking the memory of each card.
Am I going OT?
As I continue to refine my PS research by adding more and more new 512x512 textures to the "level", I have found more performance benefits (percentage-wise) from overclocking the core of a R300, NV31 and NV34 compared to overclocking the memory of each card.
Am I going OT?
Simon F said:
Well the pads aren't going to be in the same metal layers as the processing parts of the die, so the problem isn't that they're competing for space with e.g. cache. In fact it's the opposite problem: in order to fit all the pads, you end up with a larger die than you know what to do with. Ok, so you know what to do with it; the problem is it costs too much to manufacture. (This problem is known as being "pad limited".)
As with (almost) everything, it will get better with time and Moore's Law. Another problem is the packaging cost of so many pins, and although this is much less a problem than it was several years ago, as packaging technologies have improved immensely, for 512 bits you're talking a whole lot of pins.
Next there's the issue of placing and routing a 512 bit wide very high speed bus. Finally there's the problem of getting 512 bits wide worth of DRAM to connect to it. At the moment, the widest DRAM comes is x32, which means you'd need 16 DRAMs to feed a 512 bit bus, which means more high costs. The solution is x64 DRAM, and it will come if there is demand for it, although making DRAM wider does tend to reduce the yields a bit.
I suppose Intels upcoming ball-less chip packaging tech where the package is sort of "grown" onto the chip using standard CMOS manufacturing techniques would help here, since one could most likely use smaller pads. However that still leaves the problem of fitting a 512-bit memory bus in a circuit board that's only like 2mm thick.
Also, with a very wide 512-bit bus, a four-way crossbar memory controller isn't going to be very fine-grained, which might lead to poor efficiency, thus defeating (some) of the original purpose to go with 512-bit bus in the first place! Going with 8-way crossbar will add even more pins to the package and complexity to the chip itself, so that might not be very attractive either. If the added costs and engineering headaches combined with not impressive enough end results means we'll never see such a setup.
The Gamecube way, where one back framebuffer and Z-buffer reside in on-chip memory and is then copied off-chip when finished seems a nice, clean approach to me. Saves bandwidth, since each pixel is for all purposes written to only once in off-chip memory, and you save some space too; triple buffering consumes no more off-chip memory than double buffering will.
*G*
Also, with a very wide 512-bit bus, a four-way crossbar memory controller isn't going to be very fine-grained, which might lead to poor efficiency, thus defeating (some) of the original purpose to go with 512-bit bus in the first place! Going with 8-way crossbar will add even more pins to the package and complexity to the chip itself, so that might not be very attractive either. If the added costs and engineering headaches combined with not impressive enough end results means we'll never see such a setup.
The Gamecube way, where one back framebuffer and Z-buffer reside in on-chip memory and is then copied off-chip when finished seems a nice, clean approach to me. Saves bandwidth, since each pixel is for all purposes written to only once in off-chip memory, and you save some space too; triple buffering consumes no more off-chip memory than double buffering will.
*G*
I too think that bandwidth will become less important in the future. That doesn't mean there won't be a need to increase bandwidth, but that improving RAM speeds will be sufficient, and there won't be a need to go with 512 bit bus.
You know how long 128bit did hold up, but why did it hold up? Because of the RAM speed increase. Compare the bandwidth of the Riva128 with the FX5800U!
In the future there'll be subdivision surfaces (calculated on the GPU), complex animations (calculated on the GPU), realistic lighting models (calculated on the GPU).
These will move the bottleneck from the memory bus to the GPU's computing capabilities.
Even with the traditional rendering model (no advanced computations), texture bandwidth is less than the framebuffer+Z-buffer bandwidth so increasing the number of texture layers alone puts the bottleneck to the GPU.
You know how long 128bit did hold up, but why did it hold up? Because of the RAM speed increase. Compare the bandwidth of the Riva128 with the FX5800U!
In the future there'll be subdivision surfaces (calculated on the GPU), complex animations (calculated on the GPU), realistic lighting models (calculated on the GPU).
These will move the bottleneck from the memory bus to the GPU's computing capabilities.
Even with the traditional rendering model (no advanced computations), texture bandwidth is less than the framebuffer+Z-buffer bandwidth so increasing the number of texture layers alone puts the bottleneck to the GPU.
Yes and no. If a 'complex' chip and a 'simple' chip both require the same silicon area (for a given process) then they are going to cost about the same to manufacture.K.I.L.E.R said:
Of course, there is a larger cost in designing the complex chip but that can be spread out over its lifetime.
Not for a while, but when it does, there's sure to be three arriving at the same time.
This only really works if you're prepeared to limit the maximum resolution and precision that you want to render at. Also, some render to texture usage patterns used in games today might result in a lot of swapping back and forth... Probably Ok for a console, not good for a PC...Grall said:
John.
Hyp-X said:
I cut a little out from the above to distill the gist of it.
Exactly the same argument was made as little as one year ago re:128 vs. 256 bit paths to memory.
I was critical of the "bandwidth will become less important..." argument then, and still am. Not because not more work won't be made internal on the GPU. It will. But because bandwidth is a fundamental gating parameter. It puts hard limits on just how much information you can get into and out of that GPU, and if history teaches us anything, it is that where ever you have those limits, the CPU/GPU/whatever will evolve to use every last whit of it and then more.
The issue rather, is one of cost.
Going to a 512-bit bus may not be cost effective, and by the time it is, it may have become an obsolete path to pursue due to higher levels of integration. However, graphics is unusual in that it's so amenable to parallell processing. While memory clocks scale, they do not scale as fast as logic, nor does such a comparison take into account parallellization. Thus it is very likely, if not certain that these two factors ensure that GPU "power" will grow much faster than memory clocks.
At what point, if ever, the competitive and market landscape will make a move to yet wider buses a reality is difficult to say. But I do not doubt for a second that there will be a continuing hard evolutionary pressure to increase bandwidth. It is too fundamental a limiting parameter.
Entropy
Entropy said:
And what does this show?
That it didn't happen as soon as some did expect.
Some might though that games would pop up using 10+ instruction shaders overnight, but it didn't happen.
I didn't say that rendering mode will be common in 2004, I'm sure it wont be, software tech doesn't move very fast. (For various reasons that are often discussed here, so I don't feel like repeating them.)
But think about it: 128bit arrived in 1998, 256bit arrived in 2002, 4 years later. By that trend 512 is due in 2006. And I do think that those techniques will be significant by then.
I think the curent BUS will stay until memory chips reach speeds like 1,6 Ghz (GDDR3) .
After GDDR3 ... I think BIG , MegaBytes measured , caches will be the next step .
A high speeds 2 MB cache for example would be huge .
Also , embeded memory could be some direction considering that we won;t need more than 256 MB for the next 3 years or so ...
After GDDR3 ... I think BIG , MegaBytes measured , caches will be the next step .
A high speeds 2 MB cache for example would be huge .
Also , embeded memory could be some direction considering that we won;t need more than 256 MB for the next 3 years or so ...
after the business moved to 256 bit bus, it is pretty hard try to estimate when 512 bit bus is needed. of course, it is pretty sure that technology goes some big leaps before we see 512 bit memory bus. IF eDRAM technology development continues as fast as it is now, it is possible that we see memory busses beyond 512 bits, but just as internal.
too many but(t)s to even guestestimate, but (again! ) eDRAM COULD be one of the possibilities. for example NEC has some very interesting eDRAM fab lineups running and going. It is up to chip designers and chip manufacturers to exploit it's possibilities.
Of course using eDRAM doesn't limit development of external memory bus width and eDRAM isn't magic key word turning everything bandwidth hungry to fluid 100 fps real time animation; you definately need a monster version of highly efficient memory controller with sophisticated amount of channels to control and use all that bandwidth eDRAM can offer efficiently.
too many but(t)s
to even guestestimate, but (again! ) eDRAM COULD be one of the possibilities. for example NEC has some very interesting eDRAM fab lineups running and going. It is up to chip designers and chip manufacturers to exploit it's possibilities. Of course using eDRAM doesn't limit development of external memory bus width and eDRAM isn't magic key word turning everything bandwidth hungry to fluid 100 fps real time animation; you definately need a monster version of highly efficient memory controller with sophisticated amount of channels to control and use all that bandwidth eDRAM can offer efficiently.
Similar threads
