R700 has LDS too. I guess that MLAA is only using LDS for shared reads (owner-writes model) - on that basis R700 performance would be comparably accelerated.
R700's LDS problem is lack of support for generic write, i.e. any work item writing to any location in the work group's allocation of memory (only the "owner" of each distinct range of memory can write to it). It's my guess that this algorithm doesn't require generic write.Hmm. I remembered RV770 having LDS problems... Guess my memory was off.
R700's LDS problem is lack of support for generic write, i.e. any work item writing to any location in the work group's allocation of memory (only the "owner" of each distinct range of memory can write to it). It's my guess that this algorithm doesn't require generic write.
There's a subtler problem to do with the shape and size of work groups in R700 (1D, 64 work items) but I can't remember the details. OpenCL and Direct Compute 4.0/4.1 handle this differently I think and the underlying architecture is slightly more generic but still restricted. Stuff I ignore these days, frankly.
There is another factor in play: LDS reads are at the same bandwidth as TEX reads in R700. This is ~half the relative speed seen in Evergreen's LDS. This might mean the algorithm doesn't appreciably benefit from LDS on R700 and it would be best simply to optimise for L1 cache coherency instead.
I share your disappointment IST...as was mentioned earlier...HD6800 are just binned chips...being cynical...one can call HD6870 as nothing more than a hacked down 5850, overvolted and overclocked to 900mhz...i expect 5850 overclock to 900mhz would provide better results...as the two are arch similar..im very curious what "real" arch improvement cayman will have to justify the HD69xx renaming...strangely...i maybe even just get the 5850 for cheap to replace the heaty 4870....one year late...i am...
I don't think they are really much more efficient. Earlier results showed Cypress scaled a lot better with clocks than additional shader units. And that's exactly what the HD68xx are - less shader units but higher clock. The tweaks for tesselation are definitely helping too but that's about it imho. A bit more efficient per area too because of the cut-down MC PHY, lack of DP etc. but in the grand scheme of things nothing drastic (not that this is necessarily a bad thing).I would say the HD 6xxx series is much more efficient than the HD 5xxx series. In many cases, it nearly beats or beats the cards they're replacing with much lower specs.
I don't think they are really much more efficient. Earlier results showed Cypress scaled a lot better with clocks than additional shader units. And that's exactly what the HD68xx are - less shader units but higher clock. The tweaks for tesselation are definitely helping too but that's about it imho. A bit more efficient per area too because of the cut-down MC PHY, lack of DP etc. but in the grand scheme of things nothing drastic (not that this is necessarily a bad thing).
Optimizations will apply to both Barts and Cypress, so at a generical level both benefit equally, other than tessellation differences.1. They optimized the hell out of the drivers, and there's not much performance left in the chip.
Agreed...you are comparing a 725mhz to 900mhz...and even that beats it out by less than 8fps on average (with lowered AF defaults!)....the disappointing thing ....the tessellation improvements...seem more like very small hardware tweaks...very small...in the grand scheme...the move to HD6870 now all seemed smaller than moving to HD4890..at least that one AMD moved up the clock without removing sp...even added some more trannies to help overclocking!
I get that MLAA also works on alpha textures, but does it also work on shader/spatial aliasing and texture aliasing?
So will it be possible for devs to exclude certain parts of the image in the future? The funky looking health squares in SC2 and other UI elements come to mind.
So why is the cursor not affected?How shall we put it?
http://forum.beyond3d.com/showpost.php?p=1486838&postcount=4165
I wonder why people have a hard time understanding that currently, MLAA is not upto devs, it's a post-process filter for crying out loud, POST!