throw your ndas away

[Geeforcer]

Sigh... not this crap again. That image is a hoax.

 

[ben6]

Edited: For clarity.

 

[Nappe1]

btw, what's the correct hour offset for EST from GMT?
is it GMT -5 or GMT -6?

there is some confusion because europe changed to summer time some time ago...

 

[Hellbinder]

bet this card will play tribes 2 really really fast... LOL

Also, my feelings on the on chip cache, are related to an address that one of the matrox guys gave a few months ago. He hinted more than a little that Bitboys was not the "only" company working With emmbeded cahe...

i got the feeling then that they intended to include it on whateve their next prodject was.....

As Type said... No one will know any of this for sure until tuesday. Its just fun to talk about in the meantime.

 

[Daemon_UK]

You all are going to hate me. But one number I am hearing from a undisclosed source (sorry I'm not going to even hint as to who it is.) says the Parhelia 512 will be doing 50fps when looking at the water in Morrowind with 1024x1024 textures enabled. By way of comparison, my 128MB AIW Radeon 8500 does 13 fps with those settings when rain is going down, and around 18 fps with no rain... Even accounting for variances in where the scene is it's still around 2x 8500 speed...

Can you confirm if that was using triple head as well??

Don't say it is, cause Im seriously looking into triple head, JUST for Morrowind!

 

[Randell]

if it's pixel shaders 1.3 how can it be DX9 compliant?

 

[Daemon_UK]

if it's pixel shaders 13.3 how can it be DX9 compliant?

Its partially DX9 compliant

 

[Nappe1]

if it's pixel shaders 13.3 how can it be DX9 compliant?

no one here has said it would be fully DX9 compliant.

Few rules to everyone:
- every paper stating Parhelia as fully DX9 compliant is a HOAX!
- every paper talking about G1000 is HOAX!
- about "leaked" information always look for www.soontm.com before waving "Matrox 0wnz j00, because of this paper/info/screenshot/etc."

 

[Randell]

if it's pixel shaders 13.3 how can it be DX9 compliant?

no one here has said it would be fully DX9 compliant."

I was referring to the link, and you're following points were what I meant.

 

[mboeller]

The picture with the dragon and their stats numbers are misleading, they show an edge detect image and numbers but reality is that they do this "per triangle edge" as indicated in the text and you have way more triangle edges than indicated in their dragon image. They make it sound like they only do extra work and processing on 3.2% of the pixels, that number is probably much higher in reality assuming they do this per triangle edge (both visible and hidden). Sounds like a marketing twist.

I'm not sure but an edge detection ( for FSAA ) could work like the one mentioned
in the Powerpoint Presentation "Image-Space Rendering Techniques"
Page 25ff. Link : http://www.microsoft.com/corpevents/gdc2002/

Maybe Matrox does it that way???

 

[Kristof]

No, that would not work. The shaders listed there are post processing image filters, like you would do in photoshop. You can render the scene to texture and then filter that image into the framebuffer using an edge detection filter but thats no use for edge AA... unless you want to do another pixel shader post process based on the edge detection result and a blur kernel... eeeuw... it would work but be very slow and bw intensive.

Btw doing some more thinking abou FAA it seems like :

- Intersection edges (Z fail edges) will not get any AA
- Connected triangles might have area numbers not adding up to 100% along the edge due to maths inaccuracies resulting in ugly extra aliased artefacts along inter-object triangle edges. For an example of this see :

(http://www.chip.de/artikelbilder/bilder_galerie_8725856.html?show=28)

Notice the bleed of the teeth color into the yaw (background comes through the fragments). Also notice the weird stripy pattern in the sky in that image ? How can they use that image in marketing material and HOW on earth do editors not notice this ?!

K-

 

[ushac]

How do you think FAA will cope with increased polycount? I bet there'll be more than 3% pixels to AA in this picture for instace...

(From the nVidia "Squid" demo)

Regards / ushac

 

[Kristof]

The "3% pixels" number is, excuse the language, marketing BS !

The image they show is an image they pushed though an edge detecting filter, from say Photoshop. This number is considerably lower that the number of triangle edges (the text clearly says they process the triangle edges, not just the real visible edges that the edge detected image reveals). Due to increasing numbers of triangles the number of triangle edges is also going up quite considerably, but this does not take away the bw and storage advantages this tech has... it just makes it easier for things to go wrong when there are multiple overlapping edges and they run out of storage space for the fragments per pixel.

K-

 

[Nappe1]

Kristof: without any doubts your professional abilities to look this subject, I would remind that Officially Matrox has not released anything.

afaik, Digit-Life/iXBT articles mixed up some Matrox press document (which is under NDA until 14th may.) and latest rumours. So take it as grain of salt until we hear same (and maybe even more) from Matrox themselves.

There is some un-explained things and one is what you are stating. Another thing is that "no memory saving tech." (though there is Depth cache and Depth Acceleration in the chip, no one knows what they do.)

and what is my own opinion on this FSAA?? well, I don't care how it's done as long as it looks good with minimal performance hit.

I still wonder why they did the pipeline coupling like that flow chart show it? If I read it right, when coupled, 8 TMUs (in pipelines 3 and 4 which are coupled to pipelines 1 and 2) are left to useless. am I right?

 

[Kristof]

Oh I agree that things are in a limbo until we receive official press documents, but the info I based this on is from the images that are posted by several websites (russian and german chip.de) so I assume these are extracts from the NDAed press info. Also did some reasoning on how they could implement this (the more I think of it the more possible pitfalls this AA technique has).

I am expecially worried about the screenshot above (Marketing should never release a screenshot like that, so I hope its a fake or an image created by members from the press - in which case its a GOOD image), it has quite a few artifacts and some might be caused by the FAA technique. I am looking forward to testing some special cases on their AA implementation though.

I have written up some text on how I think FAA might work, possibly will post it later. It seems to have interesting BW and storage advantages but a high risk of not AA-ing certain edges and lots of risk for possible additional artefacts in "special" situations.

At this point in time I am lost in their pixel shader structure (then again not much info to go by, I prefer looking at the pictures of slides rather than reading the text), but it currently makes no sense to me.

There is a block inside the chip diagram that suggests possible BW savings techniques, and the FAA system is in essence a BW saving technique.

K-

 

[Bambers]

I must say I found the following slide strange:

Yea, i think they must of used quicnux or 4x 9 tap for the MSAA screen. Bit of cheap marketing PR

 

[mboeller]

Due to increasing numbers of triangles the number of triangle edges is also going up quite considerably, but this does not take away the bw and storage advantages this tech has... it just makes it easier for things to go wrong when there are multiple overlapping edges and they run out of storage space for the fragments per pixel.
K-

How about Z3? This form of FSAA stores only up to 3 Z-values per fragment and has an very high quality despite this "loosy" form of fragmant handling (if memory serves me well here).

Although I'm not sure if the Z3-algorithm even works with an IMR renderer?

 

[muted]

Haig , hinted there would be a whole lot more for us to read , and download tomorrow ..

and if those pictures, are really in the final press presentation , i would fire the people that came up with those shots ..

as kristof pointed - the artifacts in the dragon shot

and as many others have pointed - the fps count , to the general nvidia hugging speed fiend , that card will sux0r

i'm sure to get that fishy tech demo ..

 

[Kristof]

True, but Z3 still falls over (well has to hack things) when you have more than 3 Z values per pixel. Also given some comments about memory use I am led to believe that Matrox FAA might only have 1 fragment buffer entry, not 3. I believe that Z3 forces a combine with the background if they run out of storgae space. Note that if you store 3 fragment Z values and colors and one base color and Z value that your storage requirements are the same as 4x MSAA.

We'll have to wait and see and create some tests scenes to know when their technique starts to fail. Then again it might work in a completely different manner than I am thinking...

K-

 

[muted]

I've been thinking , and about the comment posted earlier regarding the increased polygon number , and the squid nvidia shot

my opinion is if the general geometry stays relativly flat

take a cube , other techniques would try and AA the face you are looking at directly ..


and i think game developers could implement and "edge detection" mechanism to their code .. ( tell me if that's just stupid )