Announcement

**Ali** · 1 December 2001, 15:20

Superflys post is quite good, explains a lot about why 256bit busses arnt already in use. I didnt realise about the extra pins needed for the cross bar controller. I thought they were there in case ATI bet Nvidia, so nvidia could release a 256bit version of the Geforce3 to get back on top (thats what I thought the Ti series was going to be).

Anyway, if Matrox adds some embedded RAM, that would make the chip bigger, therefore there wouldnt be that much of a problem fitting more pins on the bottom for the 256bit bus.

It would cost more of course, but most of us Matrox users tend to have nice big monitors that cost a lot anyway, and dont mind spending more money on a nice grapics cards (well, thats my feeling anyway).

If the next Matrox card is good enough, I might consider getting rid of my old 17inch secondary screen, moving my 21inch over to secondary, and get one of those 20 inch Dell flat panels for my primary. I dont play games as much as I use to, so any slight delay probems in the flat panel wouldnt matter.

Ali

**superfly** · 1 December 2001, 17:17

Embeded ram could be made to be very fast since the memory could be made to run as fast as the graphics processor itself and the bus could be made as wide as needed,256 bit wide or even 512 bit woudn't out out of the question since it's all integrated in the same die.

But there's disavantages as well..for one there's the extra die space it would take up to put a meaningfull amount of it,even if the memory itself can be packaged much "tighter" than logic circuits..most high performance cards out here can already run certain games at 1600*1200 32 bit at pretty decent frame rates which by themselves take up 30 megs of frame buffer(1600*1200 32bit,triple buffered).

The only way out of that situation is if the chip maker somehow managed to implement frame buffer,texture compression and vertex compression routines so that the max amount of data could be stored in the embeded memory and have extremely efficient prefetch circuitry that would minimize the performance hit when the chip would have to get it's data from the card's main memory.

Texture and vertex compression routines already exist in the DX8 spec,but i'm not sure about frame buffer compression routines,so those would most likely have to be implemented in hardware in such a way that the card would do it on it's own without intervention from game developers and would be API imdependent(either opengl or direct 3d would work).

Then there's the fact that by having that extra memory,the chip's feature set or it's implementation is sacrificed in order to make the chip at a reasonable size and cost as well.For instance any given chips maker can either have a vertex shader with let's say,5 million transistors if some of the die space is already used for embeded memory or a vertex shader that could have potentially 10 million of there wasn't any embeded memory on the chip,so it's a difficult decision to make since you could either use the "weaker" vertex unit with embeded memory and potentially use all of it's performance or have a stronger one without using embeded memory and rely on other optimizations to acheive the best possible performance from it,it's a tough call.

But as it is DX9 already brings improvements over DX8 in terms of vextex and pixel shader flexibility and adding displacement mapping will likely cost extra transistors as well so making a full blown DX9 card and adding a meaningfull amount of embeded memory to it would likely be a little too much to ask.IMHO.

I do believe that at some point in time,at least some chip makers will move the main bus to 192 bits,wich woudn't be nearly as bad as going to the trouble of a full 256 bit one,and provide quite a nice boost in bandwith as well since ould provide about 15 gig/sec of bandwith,use that with a system similar to what nvidia has done with their GF3 but implement it with six 32 memory controlers,one for each rendering pipeline which would require that 192 bit bus in the first place and those 15 gb/sec would look like 20+ in terms of real world performance.

One can only dream....

.

**2Whyzzi** · 1 December 2001, 19:44

Watch our luck

and have Synchronous RDRAM or something similar with a highly optimized/pipelined core.

**mute** · 1 December 2001, 23:32

RDRAM now , that would make the price go up ...

believe me

**Novdid** · 2 December 2001, 04:54

The high latency of RDRAM should make DDR a much better choice.

**Maggi** · 2 December 2001, 05:25

Wasn't there mentioning of FCRAM in one of the older rumours ?

Just for comparison's sake, I'd love to see that one used ...

**Maggi** · 2 December 2001, 05:37

<table border cellpadding=7>
<tr>
<td valign="TOP">
DRAM Type
</td>
<td valign="TOP">
PC100
</td>
<td valign="TOP">
PC133
</td>
<td valign="TOP">
DDR
</td>
<td valign="TOP">
RDRAM
</td>
<td valign="TOP">
FCRAM
</td>
</tr>
<tr>
<td valign="TOP">
Clock speed (MHz)
</td>
<td valign="TOP">
100
</td>
<td valign="TOP">
133
</td>
<td valign="TOP">
133
</td>
<td valign="TOP">
400
</td>
<td valign="TOP">
133
</td>
</tr>
<tr>
<td valign="TOP">
Data rate (MHz)
</td>
<td valign="TOP">
100
</td>
<td valign="TOP">
133
</td>
<td valign="TOP">
266
</td>
<td valign="TOP">
800
</td>
<td valign="TOP">
266
</td>
</tr>
<tr>
<td valign="TOP">
System data bus width
</td>
<td valign="TOP">
64-bit
</td>
<td valign="TOP">
64-bit
</td>
<td valign="TOP">
64-bit
</td>
<td valign="TOP">
16-bit
</td>
<td valign="TOP">
64-bit
</td>
</tr>
<tr>
<td valign="TOP">
Peak Bandwidth (MB/sec)
</td>
<td valign="TOP">
800
</td>
<td valign="TOP">
1067
</td>
<td valign="TOP">
2133
</td>
<td valign="TOP">
1600
</td>
<td valign="TOP">
2133
</td>
</tr>
<tr>
<td valign="TOP">
Bus Utilization
</td>
<td valign="TOP">
62%
</td>
<td valign="TOP">
59%
</td>
<td valign="TOP">
42%
</td>
<td valign="TOP">
74%
</td>
<td valign="TOP">
55%
</td>
</tr>
<tr>
<td valign="TOP">
Max. Effective Bandwidth (MB/sec)
</td>
<td valign="TOP">
494
</td>
<td valign="TOP">
631
</td>
<td valign="TOP">
897
</td>
<td valign="TOP">
1190
</td>
<td valign="TOP">
1165
</td>
</tr>
</table>

found here

**mdhome** · 2 December 2001, 06:00

Maggi, silly question but what is the difference between the two.

regards md

**KeiFront** · 2 December 2001, 09:03

FCRAM has low latency and high bandwith.
RDRAM has a high latency and high bandwith.

FCRAM is ideal for graphical use, much lower latency than RDRAM.

**superfly** · 2 December 2001, 09:13

Rdram would be inadvisable since like others have mentioned it still has the high latency disadvatage going for it in it's current implementation,however since the rdram spec will undergo changes in the medium term,from 16 bit to 32 and even 64 bit versions are planned and even higher clocked mhz are in the pipeline are in the works,it could very well be used in graphics cards within the next 2 years.

A 2 channel 64 bit pc 1200(600 mhz effective) rdram solution would provide about 20 gigs/sec of bandwith.

**Novdid** · 2 December 2001, 09:16

Very interesting graph...FCRAM seems like the best choice not a doupt.

**Indiana** · 2 December 2001, 10:02

Besides Rambus is about to lose the DDR SDRAM court against Infineon as well and most probably will finally be dead for good.
Without Intels support I seriously doubt that there still will be any RDRAM in the market in two years...

**Maggi** · 2 December 2001, 12:39

Originally posted by mdhome
Maggi, silly question but what is the difference between the two.

regards md

not silly, but lazy ...

if you'd followed the link I posted above, you'd found:

FCRAM - A Faster Memory Core
All of the DRAM types commonly discussed in the industry today, such as EDO, SDRAM, DDR and RDRAM, have one major thing in common ñ their memory cores are the same. What is different about each type is the peripheral logic circuitry, not the memory cell array. What this complex new peripheral logic circuitry does is attempt to hide the inherently slow memory core.

FCRAM is a novel concept, which finally recognizes and fixes the slow memory core by segmenting it into smaller arrays such that the data can be accessed much faster and latency greatly improved. How this is done is beyond the scope of this paper. If the reader is interested, both Toshiba and Fujitsu can provide more detailed information on FCRAM functionality.

The key measure of how FCRAM improves latency and can improve system performance is the read/write cycle time (tRC), which measures how long the DRAM takes to complete a read or write cycle before it can start another one. In the case of conventional DRAM types, including SDRAM, DDR and RDRAM, tRC is typically on the order of 70ns. With FCRAM, tRC of 20 or 30ns is possible. For this reason, this new device is referred to as a fast cycle RAM.

Besides faster tRC, FCRAM also improves latency with several new features that will be discussed below.

like the others already said, it has improved latencies

**superfly** · 2 December 2001, 12:45

I doubt that Rambus will go down in 2 years time since if nothing else,the PS2 uses rambus memory and that alone will keep the company alive,considering the amount of PS2 consoles already sold and the fact that the PS2's replacement probably won't be released for another 2~3 years at least..

**KngtRider** · 2 December 2001, 15:00

Creative labs used 4 and 8mb RAMBUS on some of their 'early' cirrus logic cards (3d as in crapo virge 3d, 1997)

they flopped

you can look at the info in the tech info section on creative asia site

Announcement

What exactly is Matrox up to .... get the <facts>

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment