Matrox G1000 Info???
- Thread starter Mary_Poppins
- Start date
Ante P said:rofl, for f's sake
maybe the announcment of the G1000 would have been a credible prank
but the specs are just too funny, no way, no how
can't belive people fall for this kind of stuff
Yeah, there's a bit to much wish list on this one. Maybe that's why I initially had this "I want one too!"
But "Matrox Deferred Rendering Engine" and 2 MB of on chip cache?
support for both 64, 96 and 128-bit color depths?
105 million transitors and a price start at $229?
375 MHz with 8 DX9 pixel pipes?
And the Truview-trademark for jitterede AA?
Oh, and I remember something about Matrox not going to call the chip a G1000-or-something...
Looks nice though
It just looks too much like their current products pages - why would they have those more info links on the right? Why wouldn't it be in their "what's new" section instead? The Windows NT support would be a surprise - the G550 doesn't even indicate support for that OS. And stuff like 128-bit color and quad monitor support just make no sense to me, and DX9 support now? The language used at the bottom just doesn't read like professional promotion-speak to me, either.
Definitely a 4/1 deal...
Definitely a 4/1 deal...
It just looks too much like their current products pages - why would they have those more info links on the right? Why wouldn't it be in their "what's new" section instead? The Windows NT support would be a surprise - the G550 doesn't even indicate support for that OS. And stuff like 128-bit color and quad monitor support just make no sense to me, and DX9 support now? The language used at the bottom just doesn't read like professional promotion-speak to me, either.
Definitely a 4/1 deal...
Definitely a 4/1 deal...
It looks fake, but:
- 2MBytes cache means 40 millions transistors with high density (small size) die usage, it means "only" 65millions transistors for the rest (logic), which is not much for a .13 micron process. Who has a .13 micron process available by june??? TSMC?
- The fact it support 128bits doesnt mean a high performance with 128bits.
- Maybe it is a page under study by marketing people. Then many mistakes are possible.
- Four monitors could be good for some small niche market and braging reasons.
- With all this big 2MB cache, some small and cheap 64MB DDR (250MHz ???) could be possible with low cost.
- G1000 name looks good for a radically new chip from Matrox.
- 2MBytes cache means 40 millions transistors with high density (small size) die usage, it means "only" 65millions transistors for the rest (logic), which is not much for a .13 micron process. Who has a .13 micron process available by june??? TSMC?
- The fact it support 128bits doesnt mean a high performance with 128bits.
- Maybe it is a page under study by marketing people. Then many mistakes are possible.
- Four monitors could be good for some small niche market and braging reasons.
- With all this big 2MB cache, some small and cheap 64MB DDR (250MHz ???) could be possible with low cost.
- G1000 name looks good for a radically new chip from Matrox.
Most unbelievable bit
Would be the WHQL & Platform support bit.
"Extensive", of course, is such a nice marketing word.
Adding everything together would indicate that the entry level cards would not include 4 monitor support. (eh, pascal)
One has to wonder why Mary Poppins didn't hit the "Pre-order today" button.
Would be the WHQL & Platform support bit.
"Extensive", of course, is such a nice marketing word.
Adding everything together would indicate that the entry level cards would not include 4 monitor support. (eh, pascal)
One has to wonder why Mary Poppins didn't hit the "Pre-order today" button.
Yep I agree it's prolly a fake, but anyway.
About the 128-bit bit. Is there any practical use for a 128-bit accumulation buffer if you are using 64-bit color -- or is all-64-bit accurate enough to keep the end result, um, well, accurate enough?
(I think SGI brags a 96-bit hardware accu buffer, for 48-bit color I presume, so I thought maybe 128-bit is useful in some non-realtime professional work.)
Or, alternatively, is there some use for a 128-bit "color" format, for just 128-bit data really, written to or read from data "texture" maps and used in some funky pixel shader operations? Maybe for 128-bit vector data? And should we call them bitmaps, bytemaps, or VLIWmaps?
About the 128-bit bit. Is there any practical use for a 128-bit accumulation buffer if you are using 64-bit color -- or is all-64-bit accurate enough to keep the end result, um, well, accurate enough?
(I think SGI brags a 96-bit hardware accu buffer, for 48-bit color I presume, so I thought maybe 128-bit is useful in some non-realtime professional work.)
Or, alternatively, is there some use for a 128-bit "color" format, for just 128-bit data really, written to or read from data "texture" maps and used in some funky pixel shader operations? Maybe for 128-bit vector data? And should we call them bitmaps, bytemaps, or VLIWmaps?
IIRC sometime ago Carmack asked the chip manufacturers to add 64bits color (probably internally). He probably wanted this for Doom3.
Also he said he is looking forward for more than 100 passes in future engine (after Doom3).
Maybe this 128bits could be done combining more than one pipeline or with two 64bits passes.
IIRC the Unreal 2 flamethrower use up to 50 passes. Dont ask me how/why.
Some nvnews news: http://www.nvnews.net/#1017524598
Also he said he is looking forward for more than 100 passes in future engine (after Doom3).
Maybe this 128bits could be done combining more than one pipeline or with two 64bits passes.
IIRC the Unreal 2 flamethrower use up to 50 passes. Dont ask me how/why.
Off course nobody will do a 4 monitor support with entry levels card
Some nvnews news: http://www.nvnews.net/#1017524598
Thanks, Pascal. I seem to recall Carmack was asking for 64-bit already back when he was counseling 3dfx... I guess you could jerry-rig a 128-bit pass by using parallel/consecutive 64-bit passes, an interesting idea in itself, but what I was really asking is, what do you need a 128-bit pass for? What do you do with 128-bit color?
Well, maybe with 50 or 100 passes even 64-bit can get limited, I don't really know (at all, I'm making this up as I go along). Could be that in such a situation one color component (say with a mainly yellowish flamethrower flame) needs blending finesse beyond the 16-bit floating point, and it doesn't help to have the other 48 of the 64 bits available, but instead you have to expand all components to 32-bit, so you get a memory-friendly 128-bit color format... (In a situation like this, of course you wouldn't need 128-bit for the entire framebuffer, rather just for rendering the color-problematic part. But you couldn't expand just one color component to 32-bit precision, you'd need the full 128-bit monty. I imagine.)
Dave, okay, I believe it's a fake, I'm just off-topicing because I miraculously found myself a 1992 vintage IBM keyboard in mint condition and am enjoying the unbeatable typing feel
Well, maybe with 50 or 100 passes even 64-bit can get limited, I don't really know (at all, I'm making this up as I go along). Could be that in such a situation one color component (say with a mainly yellowish flamethrower flame) needs blending finesse beyond the 16-bit floating point, and it doesn't help to have the other 48 of the 64 bits available, but instead you have to expand all components to 32-bit, so you get a memory-friendly 128-bit color format... (In a situation like this, of course you wouldn't need 128-bit for the entire framebuffer, rather just for rendering the color-problematic part. But you couldn't expand just one color component to 32-bit precision, you'd need the full 128-bit monty. I imagine.)
Dave, okay, I believe it's a fake, I'm just off-topicing because I miraculously found myself a 1992 vintage IBM keyboard in mint condition and am enjoying the unbeatable typing feel
Similar threads
