The Radeon HD 4850 & 4870: AMD Wins at $199 and $299
by Anand Lal Shimpi & Derek Wilson on June 25, 2008 12:00 AM EST- Posted in
- GPUs
Fixing AMD's Poor AA Performance
Now that we have a new architecture from AMD with improved AA performance, it's time again to look at a comparison of all the different AA modes these cards offer. No new modes have been introduced since the R600 and G80 reviews, but AMD has completely rebuilt their ROPs with special attention to hardware based AA resolve. In R600, hardware resolve wasn't much faster than shader based resolve, but this time around, AA runs blazingly fast whether its on the dedicated resolve hardware or on the shader hardware (since their is so much more shader hardware now even shader based resolve gets a giant boost).
The first thing we will want to look at are the MSAA modes. These are the modes we absolutely recommend for use with AMD hardware as all their other filters essentially low-pass filter the entire image by blending in neighboring subpixels. In any case, the results are very impressive for RV770.
The RV670 at 19x12 was limited in some way other than AA (it really couldn't keep up), but at 16x10 we can get a better idea of relative impact of AA. And clearly the RV770 quite improves fall off with increasing AA levels over the previous generation. One special thing to note is that the RV770 does fall off very gracefully to 8xAA. Since the RV670, G80 and GT200 all have sharp drops in performance when moving up from 4xAA to 8xAA, the RV770 really shines here. In fact, the few tests we did with 8xAA paints the 4870 in a much better light relative to the GTX 280. Remember from our earlier architecture discussion that Oblivion is the game where the GT200 had the largest performance advantage over RV770.
While 8xAA performance is all well and good, the image quality difference is just not enough for us to recommend enabling it over increasing resolution (or better yet, pixel density on LCD panels -- hello display makers). For those with panels that don't go over 1280x1024, it would be better to spend the extra money on a large panel than a $300 graphics card. The application where we see 8xAA making the most sense is on 50+ HDTVs used as computer monitors where the pixels are just plain huge. For the majority of desktop users though 4xAA is where it's at.
We did test the performance of all the other modes as well. NVIDIA's CSAA modes are quite good (they actually improve image quality rather than degrade it), but again, stay away from anything but AMD's "box" filtered AA.
The RV770 actually shows a bigger performance hit from enabling their tent filters than RV670. This is likely because the filters are run on shader hardware in both cases while RV770 has faster hardware resolve that can be used for normal AA resolve. If RV670 resolves "box" filtered AA on the shader as well this would explain the flatter performance in that case. Even more so than the image quality question, the fact that they perform lower really should be the nail in the coffin for AMD's tent filter garbage.
Facebook
Twitter
RSS
215 Comments
View All Comments
araczynski - Wednesday, June 25, 2008 - link
...as more and more people are hooking up their graphics cards to big HDTVs instead of wasting time with little monitors, i keep hoping to find out whether the 9800gx2/4800 lines have proper 1080p scaling/synching with the tvs? for example the 8800 line from nvidia seems to butcher 1080p with tv's.anyone care to speak from experience?
DerekWilson - Wednesday, June 25, 2008 - link
i havent had any problem with any modern graphics card (dvi or hdmi) and digital hdtvsi haven't really played with analog for a long time and i'm not sure how either amd or nvidia handle analog issues like overscan and timing.
araczynski - Wednesday, June 25, 2008 - link
interesting, what cards have you worked with? i have the 8800gts512 right now and have the same problem as with the 7900gtx previously. when i select 1080p for the resolution (which the drivers recognize the tv being capable of as it lists it as the native resolution) i get a washed out messy result where the contrast/brightness is completely maxed (sliders do little to help) as well as the whole overscan thing that forces me to shrink the displayed image down to fit the actual tv (with the nvidia driver utility). 1600x900 can usually be tolerable in XP (not in vista for some reason) and 1080p is just downright painful.i suppose it could by my dvi to hdmi cable? its a short run, but who knows... i just remember reading a bit on the nvidia forums that this is a known issue with the 8800 line, so was curious as to how the 9800 line or even the 4800 line handle it.
but as the previous guy mentioned, ATI does tend to do the TV stuff much better than nvidia ever did... maybe 4850 crossfire will be in my rig soon... unless i hear more about the 4870x2 soon...
ChronoReverse - Wednesday, June 25, 2008 - link
ATI cards tend to do the TV stuff properlyFXi - Wednesday, June 25, 2008 - link
If Nvidia doesn't release SLI to Intel chipsets (and on a $/perf ratio it might not even help if it does), the 4870 in CF is going to stop sales of the 260's into the ground.Releasing SLI on Intel and easing the price might help ease that problem, but of course they won't do it. Looks like ATI hasn't just come back, they've got a very, very good chip on their hands.
Powervano - Wednesday, June 25, 2008 - link
Anand and DerekWhat about temperatures of HD4870 under IDLE and LOAD? page 21 only shows power comsumption.
iwodo - Wednesday, June 25, 2008 - link
Given how ATI architecture greatly rely on maximizing its Shader use, wouldn't driver optimization be much more important then Nvidia in this regard?And is ATI going about Nvidia CUDA? Given CUDA now have a much bigger exposure then how ever ATI is offering.. CAL or CTM.. i dont even know now.
DerekWilson - Wednesday, June 25, 2008 - link
getting exposure for AMD's own GPGPU solutions and tools is going to be though, especially in light of Tesla and the momentum NVIDIA is building in the higher performance areas.they've just got to keep at it.
but i think their best hope is in Apple right now with OpenCL (as has been mentioned above) ...
certainly AMD need to keep pushing their GPU compute solutions, and trying to get people to build real apps that they can point to (like folding) and say "hey look we do this well too" ...
but in the long term i think NVIDIA's got the better marketing there (both to consumers and developers) and it's not likely going to be until a single compute language emerges as the dominant one that we see level competition.
Amiga500 - Wednesday, June 25, 2008 - link
AMD are going to continue to use the open source alternative - Open CL.In a relatively fledgling program environment, it makes all the sense in the world for developers to use the open source option, as compatibility and interoperability can be assured, unlike older environments like graphics APIs.
OSX v10.6 (snow lepoard) will use Open CL.
DerekWilson - Wednesday, June 25, 2008 - link
OpenCL isn't "open source" ...Apple is trying to create an industry standard heterogeneous compute language.
What we need is a compute language that isn't "owned" by a specific hardware maker. The problem is that NVIDIA has the power to redefine the CUDA language as it moves forward to better fit their architecture. Whether they would do this or not is irrelevant in light of the fact that it makes no sense for a competitor to adopt the solution if the possibility exists.
If NVIDIA wants to advance the industry, eventually they'll try and get CUDA ANSI / ISO certified or try to form an industry working group to refine and standardize it. While they have the exposure and power in CUDA and Tesla they won't really be interested in doing this (at least that's our prediction).
Apple is starting from a standards centric view and I hope they will help build a heterogeneous computing language that combines the high points of all the different solutions out there now into something that's easy to develop or and that can generate code to run well on all architectures.
but we'll have to wait and see.