- Jan 23, 2002
- 236
- 0
- 0
Originally posted by: Detselom
now what would this "16MB DRAM " do?
Originally posted by: Wurrmm
Why is it always the Nvidia chips that people like to buzz about. Granted I am not a fanboy, and though I myself do enjoying seeing potential specs for future Nvidia cards, it would be nice to see some for other chip manufactures, like ATI, Matrox, or even S3.
Originally posted by: Wurrmm
Why is it always the Nvidia chips that people like to buzz about. Granted I am not a fanboy, and though I myself do enjoying seeing potential specs for future Nvidia cards, it would be nice to see some for other chip manufactures, like ATI, Matrox, or even S3.
Close, it's a logical enhancement because then you could store the framebuffer into this ondie cache which would make accesses to it much faster. Since the textures don't required this kind of access latency (mostly just bandwidth I think), we could keep the local off-die memory for textures and it would work just fine.Originally posted by: keysplayr2003
Originally posted by: Detselom
now what would this "16MB DRAM " do?
Could it be that GPU's are evolving into CPU's? Do they need some sort of prefetch cache? Like 16MB L3 off die cache?
Interesting. Those are some hefty specs. I wonder if they will be adhered to.
Keys
Unlikely as you're not going to store much in a 16 MB framebuffer. It'll probably simply be a much larger extension of current caches which often store geometry and pixel/vertex instructions.Close, it's a logical enhancement because then you could store the framebuffer into this ondie cache which would make accesses to it much faster.
Why not? A 1600x1200 front buffer at 32-bit color requires <8 MB of storage. There's plenty of space for a front + z buffer.Originally posted by: BFG10K
Unlikely as you're not going to store much in a 16 MB framebuffer. It'll probably simply be a much larger extension of current caches which often store geometry and pixel/vertex instructions.Close, it's a logical enhancement because then you could store the framebuffer into this ondie cache which would make accesses to it much faster.
You're quite right, if you continue to keep the front and back buffers separate you can store 1600 x 1200 in slightly less than 16 MB. Obviously you'd want the flip to happen as early as possible so that you were rendering to the DRAM as much as possible.There's plenty of space for a front + z buffer.
The rest of the data is just fine to sit in the VRAM.I think he means texture wise.
I could be, but to save costs, i would think that S1-SRAM would be used. Its cheap, and fast.Originally posted by: Goi
Could the 16MB DRAM be embedded ram(EDRAM) aal Bitboys Glaze3D?![]()