MatrixAA

Nappe1

lp0 On Fire!
Veteran
you propably know already who's method this is, but I would like to hear some comments based on the knowledge that "it is basically free" and it looks like this:
MatrixAA.jpg


more information:
http://www.bitboys.com/graphicstechnology_professional_services.htm
 
I'm sure if they released the details on how MatrixAA functions more people could respond. A better picture would be nice. Anyway, from what's there, MatrixAA looks like a fairly decent solution. It would seem to be similarish to Matrox's 16FAA.
 
Dave (Barron) sent me the draft whitepaper on this back when he was with the BB, for me to check. I've lost the damn thing though! :LOL:

I think it was "plain ole" supersampling but with the embedded memory it can be "free" (lord knows up what rez though). I could be wrong though (it was so long ago!).
 
I'm looking at Dave's doc at the moment. I'll probably incorporate it into a larger FSAA article.
 
Nappe1 said:
you propably know already who's method this is...

Huh? Nope, I don't think BitBoys (Yo!) ever told us what kind of method they used for AA... Supersampling wouldn't make any sense unless BB was using a tile-architecture as you cannot fit 4 x FSAA into the on-die memory at high res. Was I guess MSAA or Matrox-like edge-AA. Dunno really...
 
Galilee said:
Does it blur a little?
No, it doesn't. The difference in textures, though it is there, is very small. I'm quite sure it comes from a slight difference in texture sample position. It's not more or less sharp. Only the edges seem to really be affected.
 
LeStoffer: sorry, my bad...
I ment that you know who has designed MatrixAA...

and another thing... time to dig up old Glaze3D slideshow from SIGGRAPH ´98 how it renders things. afaik Axe does it pretty much same.

When you look at the Axe diagram, you see a component called Host Interface... that should make you wonder if they took something else from Glaze3D to Axe too...

on the one secret IRCNet channel, that feature is/was known as BB's Secret Weapon. ;)

too bad that shutting down Infineon lines killed both card models.
 
Ehmmm Dave, dont get Dave into trouble ... just cause it's been a while doesnt mean the NDAs have passed.
 
If I remember correctly, I think their method was based on Super-Sampling. There was a wrinkle or 2 about it, but I do believe it was based on SS.
 
Nappe1 said:
LeStoffer: sorry, my bad...
and another thing... time to dig up old Glaze3D slideshow from SIGGRAPH ´98 how it renders things. afaik Axe does it pretty much same.
So you mean:

- Full linear framebuffer in video memory but primitives rendered as tiles instead of scanlines
- Framebuffer is divided into tiles (16x16, 32x32, 64x64)

;)

I don't think it's supersampling because the textures don't look any better.
 
Nappe1 said:
too bad that shutting down Infineon lines killed both card models.

Now this is a bit of bull... IF a card was that good, it would've survived the factory problems. Someone else would've bought the rights or something like that.

My guess is that: quality was good, but speed horrible. No-one needs another Voodoo5, not anymore.
 
TKorho said:
Nappe1 said:
too bad that shutting down Infineon lines killed both card models.

Now this is a bit of bull... IF a card was that good, it would've survived the factory problems. Someone else would've bought the rights or something like that.

My guess is that: quality was good, but speed horrible. No-one needs another Voodoo5, not anymore.

someone still doesn't know what's so different in eDRAM manufacturing and why eDRAM based solutions cannot be transformed from the one fab to the another one in acceptable time...

please someone help TKorho with this subject... I am so tired to post all this stuff every time when we start talking about eDRAM chips...
 
Umm, the only thing you'd have to worry about is the backend.

The logic design wouldn't have to change much at all.

I'd say to switch from one fab to the other EVEN WITH EDRAM, you'd have about 2-3 months of work prior to tapeout.
 
Xmas said:
Nappe1 said:
LeStoffer: sorry, my bad...
and another thing... time to dig up old Glaze3D slideshow from SIGGRAPH ´98 how it renders things. afaik Axe does it pretty much same.
So you mean:

- Full linear framebuffer in video memory but primitives rendered as tiles instead of scanlines
- Framebuffer is divided into tiles (16x16, 32x32, 64x64)

;)
yep.
I am not sure if they changed tile size or made it dynamic...
(dynamic corresponding rendering parameters (AA, resolution, Z-buffer depth, color depth...) would be most efficient.)

In Dual Chip mode another chip just helps "tile" -rendering speed. (theorically could double it. practically not.)

IMO,
With this implementation, they can always render tile on eDRAM, and never run out of bandwidth. Of course on extremely high resolutions, amount of tiles gets so high that copying tiles from eDRAM to the back buffer (in case when back buffer & Z-Buffer takes more than 12MB) starts slowing things down.
 
RussSchultz said:
Umm, the only thing you'd have to worry about is the backend.

The logic design wouldn't have to change much at all.

I'd say to switch from one fab to the other EVEN WITH EDRAM, you'd have about 2-3 months of work prior to tapeout.

wow, that was new info for me...

well, it's time to update my facts too.

No one knows outside what were the reasons not changing the fab for Axe instead of developing something new again. (and who knows how much their next design for PC has new... too bad that I can't comment more about axe as good base for DX9... and reason is that even if I would have permission to do that, I wouldn't have anything to proof that I am not BS'ing everyone.)
 
Hmm, i really wouldn't have mentioned Dave's doc. He told me not to mention it to anyone. :)

So, who *didn't* Dave give the doc too :)

-Colourless
 
Back
Top