Have any G800 rumors or "inside info?"

[Joel]

Of course the above is pure speculation being that Matrox has not even announced a G800 card.

Joel

[Scooter]

Man, it took 30 posts to get the answer I was looking for. Thanks tuco!

[Brian R.]

Scooter - You going to believe anything you don't hear from Matrox? When I see it on the Matrox site, I'll believe it.

[Humus]

Originally posted by Barbarella:

"It might make it impossible to use with DX9 when it comes".

only the new function and they will not be a lot. so you can use the traditionnal way. using driver. DW8 will be a big dirextX, i don't think Microsoft will change a lot of DX8 when launching DX9. Adding the fact that DX9 will not appear soon this will give time to make a new G800, G900


"Furthermore, function calling overhead isn't the bottleneck."

Not true. We can see big difference between beta driver and optimised driver. This solution (or something like that) is used in console game.

DX8 to DX9 will probably be just large as DX7 to DX8 or DX6 to DX7. Most DX versions have completely new graphics API, hardlocking to a certain API will probably make it impossible to use with the next API.
All vendors are trying to make their cards more flexible, and that's not without a reason, hardlocking is certainly not gonna appear on G800 or any other card. Flexible hardware can make the card go much faster if smartly used by the driver or the application. The register combiners of GF cards proves that.

Hardlocking will also make all kinds of on the fly optimization by instruction inspection impossible (like converting two consecutive single textured passes into a multitextured pass).

And I don't understand what you mean by this "beta driver" and "optimized driver" thing. What was this supposed to prove? The function calling is done by the application, it doesn't change with different driver versions.

[Barbarella]

"Most DX versions have completely new graphics API, hardlocking to a certain API will probably make it impossible to use with the next API"

should i understand that a game made for DX6 won't works with DX7 ? i don't think so.

"Flexible hardware can make the card go much faster if smartly used by the driver or the application."

Sorry but less work have to do druver faster will be a game or a 2D/3D application. About flexible hardware this is an another story. It's truth that i not imagine a card makers not thinking about flexibilities, but this doesn't mean that you can't make an optimised processor for one or two API




[This message has been edited by Barbarella (edited 03 October 2000).]

[Scooter]

Brian R. this was my original question:

I wanna know what rumours have been floating around concerning the G800.

[pchoi]

should i understand that a game made for DX6 won't works with DX7 ? i don't think so.

Two words: Deprecated functions.

The old functionality will still be there (why do you think each release of DX gets bigger and bigger? So much redundant code) for old games. DX8 is simply more functions and it doesn't make a difference whether you have DX9, DX10 etc. etc.

MS will keep all the redundant code in for several releases (maybe 2-3) then by that time (2-3 years) no one will play the old games anymore and they can strip most of the redudant functions. For example, a 2D DirectDraw game called SubSpace was released at the time of DX2, and matured with DX3. To this date, it still works under DX7, however some behaviour in the game is strange. The only way to explain why this game still works is if 1. MS still has those functions in there or 2. The functions used by the game are re-routed to newer functions. You really don't have to worry about backwards compatibility.

Optimized (from the hardware vendor's POV) simply means it runs faster with less redundant operations or function calls. Beta means it hasn't been fully tested yet, that's all. It's entirely possible that a beta driver could be ridiculously fast because of optimizations. Therefore you could have optimized beta drivers Man this could get confusing...

[Targon]

Of course, the API interface, if it's in the BIOS, COULD be easily flashed for the new API. That is if there's nothing else that's currently dealing with the translation. I love that we are now at a point where just about every card comes with a flash BIOS. Five years ago, you buy a card with a BIOS bug, you need to ship the card back, and wait for a replacement card to get an updated BIOS. Now, you just download a flash BIOS program and BIOS image, and reboot. Instant updated card.

Now, for any company that wanted to center around DirectX/Direct3D, they could do that, but they would need to keep enough room for at least 2 or 3 DX revisions if Matrox or others wanted to try supporting their customers properly. It's a definate possibility, but I don't see it happening.

[Brian R.]

OK, but they aren't very valuable. (unless from a very select group of people)

[Scooter]

Who might this very select group be? Again,

I want to say that I just started following Matrox again. So I've been out of the loop for a while....

It's easy to say that somebody know the answer, but who? It's pretty safe to say Matrox isn't gonna say anything.

[Brian R.]

The select group ain't talking either. They are working for Matrox as beta/alpha testers of new products.

[Humus]

Originally posted by Barbarella:
"Most DX versions have completely new graphics API, hardlocking to a certain API will probably make it impossible to use with the next API"

should i understand that a game made for DX6 won't works with DX7 ? i don't think so.

pchoi explained this rather good. I can add that each DX version have a new D3D interface, the old one is still there and programs requesting the old interface will get that interface. Newer programs will request the new interface. I'm not a DX programmer (I'm a OpenGL programmer) but I have some insight in how DX is built. The oldest DirectDraw object is called iDirectDraw (if I remember it right), the next interface was called iDirectDraw2 and then iDirectDraw3 etc. The old objects are still available, M$ just adds new interfaces.

Originally posted by Barbarella:
"Flexible hardware can make the card go much faster if smartly used by the driver or the application."

Sorry but less work have to do druver faster will be a game or a 2D/3D application. About flexible hardware this is an another story. It's truth that i not imagine a card makers not thinking about flexibilities, but this doesn't mean an optimised processor for one or two API

We are talking about perhaps 2 or 3 writes instead of a single write when doing a state change. How much of a difference is that? When going from AGP2x to AGP4x you mostly see no significant speed improvements, so why would you see a difference when saving a few AGP writes in DX function calls?
Furthermore, the state changes are very few in comparison to data writes which has to be done regardless of wheater it's hardlocked or not.

[Barbarella]

well,

you're right on that but you forgot something. Things change ! MS will have DX8 on the X-box. this is a big investissement even for MS, so i think they will manage the upgrade of DX8 in a different way.

"We are talking about perhaps 2 or 3 writes instead of a single write when doing a state change. How much of a difference is that? When going from AGP2x to AGP4x you mostly see no significant speed improvements, "

We are talking about communication between the main processor and the graphic processor. not between memories and graphic processor. But i believe i understand what you trying to said.

In fact nobody know the real cost of a driver work. But console game are working in this way and it's works fine.

About AGPx2 and x4 this not a good example. Because even pc133 memories can afford the bandwidth of AGPx4. In reality they did not even afford AGPx2.

[Cybermind]

Have faith in Matrox' talent and direction. Be patient. The G800 Techdemo is almost done, and -is- going to blow your minds, no doubt about that.

Alex 'Cybermind' Redman
Zen Tao Interactive, Inc.

[Nuno]

If MS continues doing so (who is using a DX1 app anymore?) I bet DX15 will install 150Mb of crap... But by that time, Win Me&You II Third Edition (the anounced last one with Win9x kernel) will be around 5 Gig, so who cares...