Carmack on Parhelia

[Nagorak]

With eye candy on it does, and I thought that is what we bought $400 dollar video cards for. Yes its not blowing a Ti4600 out of the water(yet beats it) but impressive FSAA numbers for a debut. Not to Mention Matrox has been out of the high end game for a long time, I will wait for a few driver releases to say its a failure.
I think HYPE has killed this card (Nappe ) being the 1st 256 bit card the expectations were too high...like a movie...hype..hype and you see it and say "that wasn't that great".
I look at this way, if you bought a Ti4600 for FSAA performance whats stopping someone for doing the same with a Parhelia.

The problem is it's too sloooooooow. I don't care if it has a 0% performance hit for AA (which it doesn't), if in the end it's running at 30 fps it is still unplayable.

And the Radeon 8500 has better looking anisotropic, takes a smaller performance hit, and costs 1/4 as much! I'd take anisotropic over AA any day, even if both cards were equally priced.

 

[Nagorak]

Another possibility is hardware bugs which are causing stalls/increased latency in their pipeline. Management could of decided they could not afford another cycle/delay and had to go with the broken hardware to get it out before the next gen from ATI and nVIDIA. If true, the next revision or "spring refresh" could perform better then what can be attributed to clock speed increases alone (assuming a process improvement).

The point is: so what? It's obvious why Matrox rushed the card out, because the R300 is coming. Even if Matrox improves the core/drivers so they get a 100% improvement (which incredibly unlikely), it will still get raped by the R300.

So let's say they increase performance by a more reasonable amount like 40%... by the time they do R300 will be out and then what? The card isn't going to "get better over time", it's just going to get worse.

As bad as all those benchmark graphs looked with the Ti4600, imagine how much worse it would have looked with the R300 to compare against. Matrox had a limited window to get this card out the door, and they basically blew it.

Now, even if the drivers improve and the card performs a little better, relatively speaking it's just going to get worse!

 

[SvP]

Carmack:

Displacement mapping. Sigh. I am disappointed that the industry is still pursuing any quad based approaches. Haven't we learned from the stellar success of 3DO, Saturn, and NV1 that quads really suck?

Could somebody explain me what the above meant? What's so bad about displacement mapping?

 

[Doomtrooper]

Just trying help with damage control for Nappe1

 

[Moloch]

I think the core speed is whats making it slow in games that don't use 4 TMUs.

 

[Nappe1]

Just trying help with damage control for Nappe1

hehe
but, why bother? Really, this has been self caused Supertanker load of poo coming and only one who I point of causing it is myself

Too bad but after these three flopping (well Parhelia actually at least came out, but otherwise G800, Avalanche and Parhelia has practically flopped) this makes me even more cautious and I am already practically on the path of "I know, but can't tell"

I hope Dsuiko does understand me (he was ones who were thankful sharing information...), why I have decided to take this route for now on.

I'll be at The Assembly, but I doubt that I could be seing something so amazing that it couldn't be turned against me in a way or the other, so most likely, I am not willing to take this sh!t anymore and you will hear pretty much nothing about that at least from me.

 

[KimB]

Carmack:

Displacement mapping. Sigh. I am disappointed that the industry is still pursuing any quad based approaches. Haven't we learned from the stellar success of 3DO, Saturn, and NV1 that quads really suck?

Could somebody explain me what the above meant? What's so bad about displacement mapping?

Quad-based=bad. I didn't realize that Matrox' displacement mapping was quad-based...and it doesn't bode well.

You see, nearly all geometry today is triangle-based, so it's pretty much impossible for game developers to just apply a displacement map just like they would a bump map. It requires a full redesign of all game models, which means that we'll see little to no displacement mapping use, at least for the Parhelia.

Additionally, previous quad-based HOS designs all had problems with edge alignment (preventing cracks between edges of a surface...Quake3 level designers can probably attest to this), and some had texture alignment problems (NV1).

In short, quad based=hard to program for, hard to design art for.

As a quick note, this is one of the things that nVidia really stressed about their NV_Evaluators extension (RT Patches in D3D), that they were triangle-based.

 

[MfA]

A triangle of course is just a degenerate quad NVIDIA's hardware is quad based for instance ...

 

[LeStoffer]

Can we finally put the nail into the coffin on these "bandwidth is king" arguments that have been going on over the past 4 years on B3D? You know, you take the specs of 3D card X, and 3D card Y, compare bandwidth, # pipelines, texture units, and clock, and pronounce the winner?

Yes, please! Besides I don't think that we had any really unbalanced card except the original GeForce with SDR-mem and the GeForce2. Goodbye, Bitboys and XBA...

Regarding Parhelias less than stellar performance on DoomIII: Remember that those stencil shadows eats simple pixel fillrate which is exactly the weak spot for Parhelia (no fancy multipass is going to change that shortcoming).

 

[OpenGL guy]

A triangle of course is just a degenerate quad NVIDIA's hardware is quad based for instance ...

You sure about that? I think when people talk about "nvidia renders in quads", they are talking about the 2x2 pixel quads that depicts the arrangement of the pixel pipes.

 

[Sharkfood]

I seem to recall saying months ago (in a B3D thread) that efficiency problems could kill this card, but other fans were saying "even if 30% less efficient, it has 2x the bandwidth, so it will still be way faster!"

It really depends what one categorizes as "efficiency" versus plain out reductions in rendering quality to gain some performance. If two different IHVs take totally different approaches, obviously you'll see largish differences in performance.

I'm not all together convinced this theory of "forget the bandwidth, it's efficiency that counts" truly holds any water, especially in the case of the GF4. The more road signs I see missing their wooden posts, the more complete shrubbery I see totally missing in FS2002.. and the more saw-bladed water edges I see around water bodies in Tribes2.. the more I wonder how much slower this card would perform if such driver "cheats" were all but removed.

This theory is also prematurely digging a hole for the Parhelia since nobody here has seen the card in person to verify what differences it yields. Obviously, nothing is free in 3D and whether or not the seemingly lackluster performance figures are due to valid, visible improvements in IQ (from a different product design ethic) or from poor driver quality is still a complete mystery... the jump at a conclusion that such architecture is just poor is premature IMO.

I still look at the first month of the GF3 where it couldnt topple an Ultra, and game benches like NFS-PU were a lowly 19.2 fps versus 38 fps on the Ultra. I didn't see droves of people coming here to condemn the new architecture, but instead an agreement to wait for newer drivers- which within 6 months were delivered and finally toppled the Ultras. Given the Parhelia is from Matrox, I'd have guessed it having poor launch drivers would be almost expected.

In all, not to say the board is the next best thing since sliced bread, but instead simply maintain there is insufficient data at this time to make any kind of determination. All these cookie-cutter reviews are in conflict with each other, none actually measure delivery from either product (or the glaring z issues with the GF4 might actually be discussed!) and none actually go into detail or pursue reasoning for the seemingly less-than-stellar performance delivered. This all really makes for an obfuscated collection of data from which I dont see why so many are so quick to want to start digging holes.

 

[ConeK]

Another possibility is hardware bugs which are causing stalls/increased latency in their pipeline. Management could of decided they could not afford another cycle/delay and had to go with the broken hardware to get it out before the next gen from ATI and nVIDIA. If true, the next revision or "spring refresh" could perform better then what can be attributed to clock speed increases alone (assuming a process improvement).

I don't think that there is bugs (atleast big bugs) in the pipeline stucture of parhelia. When you look at the synthetic tests, like fill rate, vertex shader or pixel shader. Fill rate is what it should be, vertex shader speed seemes to be low in 3dmark, but Matrox´s own test gives good results. Pixel shader speed is not in par with 8500 or GF4, but why should it be. Pixel shaders are just parts of pixel pipelines and with 4 pixel pipelines and 220 MHz clock, Pixel shader speed should be weaker than 8500/GF4´s or even weeker than GF3 Ti500´s.

I still think that the memory bandwith is the king. But if we look at the Ti4600 results, it is pretty clear that the overall design of the memory subsystem and the chips internal structure (caches etc.) are highly efficient. Parhelia is lacking in memory speed even though it has 256b wide path to the memory. NVIDIA and ATI has put a lot of thought into the design of their chips and developed very efficient HSR techniques. So there is no "one big reason" lurking behind the "Great flop of the Parhelia". It is usually the overall balance of different techniques that makes the card fast or not.

Im not entirely sure about Matrox´s capability of making drivers that would pring a lot more performance (not the mysteriously missing 50%) to the table in short period of time. We have to remember that the first working samples have been here for a while. Im sure that there will be speed improvements in the new drivers, maybe even 20%.

 

[Kristof]

I think the core speed is whats making it slow in games that don't use 4 TMUs.

While I don't disagree, the card is not exactly fast in SSam which uses all 4 TMUs where possible (at least does so on KYRO).

K~

 

[Simon F]

A triangle of course is just a degenerate quad .

Hee hee. Perhaps we should send someone a copy of graphics gems to see how triangular patches can be converted to quads ....

 

[pascal]

There are two Parhelia models and IIRC someone said that there are some 700Mhz GF4 available. Maybe he had an slower reference card and a very fast GF4.

Not only is this pretty far-fetched, I fail to see what does it have to do with your calculations. Is it so hard to admit that you made a couple of simple mistakes??

What I was trying to explain was the reasoning behind the 16GB/11.5GB.
Thank you Geeforcer to show me my "mistakes"

 

[MfA]

Pretty sure, OpenGL guy If you want all the technical info dig up their siggraph paper on the tesselator, this quote from the OpenGL specs says it all though :

Should we support triangular patches?
RESOLVED: Yes. Otherwise, applications will have to convert
them to rectangular patches themselves. We can do this more
efficiently.

NVIDIA uses a simple degenerate quad for a tri, which is ok but does not give the most uniform tesselation possible ... with 4 quads per tri you can get very close to the ideal though.

 

[jb]

DemoCoder,

how about we say effective bandwidth is still king

And with no real forms of bandwidth saving tech you have to realise that some of the bandwidth is just not used well. Pitty too.

However what about the 16FAA? I think when it works it looks very nice.

I never expected this card to be uber fast. But I do think it still has a place for those highend devleopers that want the higher IQ and 3 monitor support.

Kristof,
we know that SS looks for cards and then can use tweaks to get them to run faster. Any chance that SS:SE does not do this yet for the Parhelia? I doubt Croteam would have a working sample back when they were working on SS:SE as that was almost ready last year. Just a thought. Maybe in the next patch? Ok I will stop guessing...

 

[JF_Aidan_Pryde]

how about we say effective bandwidth is still king

How about Effective Fillrate is king? That has pretty much always being the case in consumer 3D graphcis. The whole Bandwidth is King slogan is derived from the need for fillrate, effective fillrate.

First : Fillrate is King

Then: Fillrate/Bandwidth became unbalanced, bandwidth holding back fillrate

Impression: Bandwidth is King!

Now: Bandwidth is here but it's not giving us the effective fillrate.

Fact is, until we become poly limited, effective, real world fillrate will always be king.

 

[KimB]

Just don't forget that now we have other image quality-enhancing techniques that eat into fillrate, so it is often more important to benchmark with those enabled (anisotropic filering, anti-aliasing).

 

[MfA]

Slip of the mind there, that should be subdivision into 3 quads ... was thinking of a paper I read called "Conversion of a triangular Bezier patch into three rectangular Bezier patches" by Shi-Min Hu ... NVIDIA mentions a different paper for this kind of conversion "An Optimal Algorithm for Expanding the Composition of Polynomials" which might be equivalent, but I really couldnt say since Im just not interested enough in it to suffer through reading it (The first paper I mentioned is nice and straightforward, you could write an efficient implementation from it with comparitively little effort whereas with the second you would first have to dig your way through a ton of math.)