Matrox Releases G400 Specs

Anonymous Coward writes "Matrox just released the hardware specs for the highly rated G400 here (must register). According to the guys working on the G200 driver (including John Carmack) from a driver perspective it is very similiar to the G200, so XFree86 and 3D support should be coming very soon. 1999 is going to be good year for Linux and high performance graphics. " With XFree86 4.0 out by the end of the year (hopefully), the Precision Insight news, and mandrake's work on xinerama, I'm inclined to agree. Now, if only I could get my hands on one of those babies...

Comments

Damage control, part dieux

[Anderson]

Hang on a sec. I think calling this a "marketing ploy" is going a little over the line. Two points about the triangle setup engine: it's not necessary to have the WARP triangle setup specs in order to get good 3d acceleration. You still get the rendering engine, after all, and it ain't half bad. But regardless, the WARP gives you about a 25% performance boost (J. Carmack's estimate, not mine), and Matrox has committed to helping the open-source driver developers use it. Considering their track record on promises to open-source folks, I'd say they're serious. On this one, let's wait a month or two and see what happens with the WARP -- my feeling (and the attitude on the GLX development list) is that Matrox will probably do what they say.

Sure, Nvidia released "already-written GPLed drivers", but a) they aren't fully finished, b) they didn't send the specs along with the drivers, and c) the Nvidia drivers were based on ... the same GLX source base as the G200 drivers. Surprise.

As to your note on Matrox needing to have a faster card *and* releasing full specs ... well, I don't want to get into a pissing contest here. But the result of having the card specs is that the *G200* is faster than any TNT(2)(Ultra) card under Linux right now -- the drivers are just better. So, if your only metric is Linux 3d (OpenGL) speed, then I would guess Matrox is a-okay: they've opened the specs on everything we could have asked for (as a public company, they would likely be liable and be sued for releasing specs on something as proprietary as the WARP ... I'm amazed they were able to release the G2/400 specs, personally), and have committed to help us (which, notably, is the same response we have from Nvidia -- code and a committment to continue helping) on the small remaining parts. Furthermore, their G200 (not to mention the forthcoming G400) is arguably the fastest Linux 2d/3d combo accelerator at present. (The Voodoo2's still beat up on it in pure 3d performance.) I'm not running off to buy Matrox stock or anything, but in regards to their open-source community standings, I would say they're doing all the right things.

Seeing this message and your other anti-Matrox message, it looks like you've made the full transition from Matrox fan/Nvidia hater to Matrox hater/Nvidia fan. Might I suggest reserving religious commentary for something other than graphics cards? :) There are better things to get worked up about -- both of these companies have helped out 3D under Linux *tremendously*. Bashing Matrox here doesn't do anyone any good.

technical hurdles

[Stickerboy]

The biggest hurdle to implementing bump mapping is artistic. To get the best effect from textures in hardware that doesn't support bump mapping, the light effects must be drawn in by hand in the texture (i.e. drawing the shadows on a brick wall). In a bump mapping-capable system, you want the hardware to do that, so the textures are drawn differently. Supporting both types of systems effectively doubles the workload of the texture artists, which is one of the main reasons why bump mapping isn't in q3a.

Another reason is the non-negligible 20%+ performance hit from enabling env. map bump mapping, as displayed by the Matrox G400. When a Ultra TNT2 is having trouble reaching 60 fps on "Highest Quality" in q3a, it doesn't make sense to devote the extra effort for a feature very few will use. As it is, q3a engine licensees are supposed to be able to easily enable bump mapping in the engine itself, for future games. (I can't remember which id .plan that was in)