MatrixAA

It's not AA.
It's blur.

There are various edges that are not improved at all, but they are blurred to hell.

I'd need some cleaner model to see it better though.
(I wonder why they chose a picture with nearly no close vertical or close horizontal edges.)
 
That i have to agree to. MatrixAA would be best described as a selective blur. I would be most interested in the actual results when a high polygon model has MatrixAA applied. In low res cases, things shouldn't get blurred too much since there aren't many edges, but in high polygon counts there are edges everywhere.
 
LeStoffer said:
Nappe1 said:
... too bad that shutting down Infineon lines killed both card models.

Ack, indeed! Do you by chance know when they should have hit the market if Infineon didn't bail out? :(

well, at first, I am not sure when BB got a news that Infineon is pulling out.
first rumours hitted on late August 2001, but they were denied at from Bitboys. Next time it was true (26th of November) and they confirmed it. (29th of November)

I know surely, that there was something wrong in the Assembly 2001, because in the seminar they didn't even mentioned Infineon. (it was on the slides for the Axe's design, but they didn't mentioned it. Other partners they mentioned at least twice.)

Month after that I got a leak of another codename that was suppossed to be at the works too. at first I didn't believe it, but 2 months after that, another source also confirmed existance. And since Mobile chip came reality now, it will be seen if we see this Next Gen (still I don't want to use internal names until BB themselves decides use it, like in case of Axe.) to materialize.
 
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.

ONLY thing? A design that is carefully taking advantage of the EDRAM does not just port to a new ASIC library. It is a redesign, not just backend work. But there is always a lot you can take with you to a new process and a new design, only not in just 2-3 months. Read the info right. They have this product on hardware, but it is not going commercial. Clearly there is no deal on the revision and the attention seems to be in the mobile product. But what I know of MatrixAA it is a new way of getting the AA result and not limited to EDRAM design, although clearly easiest to implement there.
 
Colourless said:
That i have to agree to. MatrixAA would be best described as a selective blur. I would be most interested in the actual results when a high polygon model has MatrixAA applied. In low res cases, things shouldn't get blurred too much since there aren't many edges, but in high polygon counts there are edges everywhere.

Do you mean edge adaptive blur or intensity change (edge detect) adaptive?
I think if it's selective it's a latter.

You can do it in an image editor: copy layer, edge detect, copy intensity to selection (it may be a few steps depending on the app), apply blur to the original layer as per selection.

Smart blur works the same, except the selection is inverted.

If the algorithm is the first (the card remembers the edges), than I do not understand why it blurs the textures too?
 
finsider said:
ONLY thing? A design that is carefully taking advantage of the EDRAM does not just port to a new ASIC library. It is a redesign, not just backend work.

I don't see why. They'd just resynthesize and do all their timing analysis with the new libraries, and then lay it out. Maybe you'd have new test and repair engine for the RAMs or some glue logic that would require a little new RTL work, but the eDRAM is logically a memory array and there's likely nothing terribly different between libraries that would make it a redesign.
 
It remembers where the edges are. Of course it's possible that it will be able to compensate for cases where triangles share an edge.
 
RussSchultz said:
finsider said:
ONLY thing? A design that is carefully taking advantage of the EDRAM does not just port to a new ASIC library. It is a redesign, not just backend work.

I don't see why. They'd just resynthesize and do all their timing analysis with the new libraries, and then lay it out. Maybe you'd have new test and repair engine for the RAMs or some glue logic that would require a little new RTL work, but the eDRAM is logically a memory array and there's likely nothing terribly different between libraries that would make it a redesign.

So, what would you do with a memory manager that has been designed to be capable of handling internal EDRAM memory plus external memory in an efficient and effective way? Plus all the fab-specific components on the chip?

Surely most of the pipeline would remain just subject to resynthesis and backend work, but these GPU's are made to take full advantage of the process and therefore, very unlikely that a straighforward conversion would be the best option anyway, even if it would be possible. However, if you know anything about the EDRAM process, you would also know that for logic gates it is an extremely challenging process. Advantage is the tiny size of the memory.

It is an achievement as such that BB has been able to squeeze the required logic and 12 megs of memory on a same die. Shift to a logic process would be an opportunity to either make a future chip really small or add features. I hope that someone picks the idea up, alternative designs are always welcome!

So in real life the decisions on process and redesigns is never as simple as it can be made sound on a forum like this...
 
What I was suggesting was moving to another fab that offers eDRAM.

TSMC and UMC both offer eDRAM libraries/processes, either through their own libraries or 3rd party vendors like Artisan. Most products made by fabless semiconductor companies these days are not custom logic, but either standard cells, or black boxes that have been ported by the IP vendors. (By the way, eDRAM, at least at TSMC, is built on the standard logic process, though they do have a slightly modified process that increases density by a certain percentage)

I'm not suggesting removing the eDRAM, just moving to another fab. Surely, they might need to drop some memory or maybe add some (or make the die larger or smaller). But it isn't like changing the fab is some catastrophic event (unless 2-3 months is a catastrophic event for your company) Infineon wasn't the only company with eDRAM out there.
 
I don't know if MatrixAA is bluring the image, but the colors are definitely not as vibrant. The truck is an entirely different shade of red.
 
RussSchultz said:
What I was suggesting was moving to another fab that offers eDRAM.

TSMC and UMC both offer eDRAM libraries/processes, either through their own libraries or 3rd party vendors like Artisan. Most products made by fabless semiconductor companies these days are not custom logic, but either standard cells, or black boxes that have been ported by the IP vendors. (By the way, eDRAM, at least at TSMC, is built on the standard logic process, though they do have a slightly modified process that increases density by a certain percentage)

I'm not suggesting removing the eDRAM, just moving to another fab. Surely, they might need to drop some memory or maybe add some (or make the die larger or smaller). But it isn't like changing the fab is some catastrophic event (unless 2-3 months is a catastrophic event for your company) Infineon wasn't the only company with eDRAM out there.

Logic processes are far more similar to one another than any two eDRAM processes. What you argue, might work for a relatively small design, being then mostly a cost and time issue. For any high-end design, so many other constraints come to play a role, that 2-3 months to change fabs is a theory that does not hold in practice.
 
Hyp-X said:
Do you mean edge adaptive blur or intensity change (edge detect) adaptive?
I think if it's selective it's a latter.
[\quote]

It is adaptive, so to speak. It doesn't just run up to an edge and blur it. It detects a value and uses that value to calculate a color value based on a %. That value is then uses with surrounding pixels to achieve the final pixel color value. Hope that helps. I have to watch what I say. :)

And Colorless, I already got in trouble... not really, but my former co-workers do read this board.
 
Back
Top