Now I use kernel 2.6.36 and r300g driver + Mesa 7.11-git on xserver 1.9.0 and vblank_mode=0 does make difference just for glxgears, not for fullscreen FPS games.
One thing in AMD's favour though is they seem to have at lest gotten the hairy moths out of the soup at last.
The Direct2D accel is still broken for me, and now the
won't turn it off. It seems, that XAA was removed from this driver.Code:aticonfig --set-pcs-str=DDX,ForceXAA,TRUE
And yes, in fact, early cars did not necessarily come with wipers. Early restaurants likely did not come with napkins (or utensils, for that matter). Early airplanes did not come with cabin pressure.
People are too complacent and used to our everything's-perfect, homogenized lifestyle in the 21st century. People don't realize that things are only well-suited to our desires and our tastes because other people have developed methods, procedures, and technologies, and then set other people to work performing those methods and procedures, and creating instances of those technologies, to make it happen. There is a road to travel in order to get to the ideal level of service.
If you would prefer that all 3d graphics drivers remain in-house, unreleased research projects until they are 99.99999% perfect, then please delete all instances of Catalyst, the NVIDIA binary driver, and all open source graphics drivers from your PC right now, and do not install them until, oh, 2025 or so at the earliest. For the open source drivers, I'd say 2050. And even then, there will be the occasional engine built with a flaw that leads to a head gasket breach after 50,000 miles, or the occasional hair or fly in your soup.
Maybe AMD should call the Catalyst Linux driver a "public beta". Would that make you happy? Because that's more or less what it is, or at least, what it had been in 2010. Maybe 2011 will be the year of Catalyst actually crystallizing into a nice driver, but I think it'd be fair to call it beta in 2010, with the lack of tear-free support and a host of OpenGL bugs. A beta driver is like a "soup" scraped up from random kitchen scraps that were slated for the trash, called "chef's experiment" or something on the menu. By setting your expectations right, you don't get a sour attitude when something's in there that you don't find appealing.
In fact, this whole issue with you seems to be about expectations. While I, too, believe that someday Catalyst (and the open source drivers too, I hope!) will enjoy asymptotic perfection, that day is not today. Should we hold AMD to blame for putting out a driver before it's ready? It's hard to say, "Well, you should have done better than you have, in less time, and delivered everything I want yesterday!" in an industry that is barely a decade old, to a team of at least 50 people (in the Catalyst case).
Personally, my expectations in the 3d graphics drivers space have been relativistic, rather than based upon an idea of perfection. Take the best driver out there, account for its features and stability, and rank the remaining drivers in terms of the defects they have that are absent in the best driver, or features that the best driver has that the others don't.
Now, I share the experience of others that the NVIDIA binary driver does not provide full desktop tear-free experience, especially on the 2d side, but also with 3d games. But, freedom aside, many would agree that the NVIDIA binary is currently the best graphics driver for Linux in terms of features, stability, and performance. So how does Catalyst stack up?
1. They both support the same level of the OpenGL API. Damn vague Khronos specifications and interpretation mismatches aside, it seems that the few users of the latest OpenGL specs (ahem, Unigine) can run fairly well on Catalyst. And if you go back to, say, OpenGL 2.1, Catalyst does about as well as it possibly can; it's hard to expect more.
2. Catalyst supports cross-API, full-screen tear-free, while NVIDIA doesn't (they only support tear-free within an individual API, e.g. OpenGL or composited desktop or a video, but not sync between all three at once). Looks like Catalyst actually wins this battle, now doesn't it?
3. Multi-monitor is well-supported in Catalyst these days, and I know NVIDIA has their own proprietary solution that is supposed to work well.
4. Perhaps there are video decoding issues with Catalyst under Xv and XvBA, whereas NVIDIA's VDPAU is supposed to be awesome. This is a fair point; Catalyst video playback could use some work. To me, this isn't an indispensable feature, because using OpenGL for video keeps the hardware acceleration aspect, while basically guaranteeing that a conforming OpenGL implementation will render a pixel-correct result. Since the performance (i.e., the smoothness of the framerate) is acceptable for me even at 1080p, I am satisfied.
So on point 2, Catalyst "wins", and on point 4, there exists some ancient video API that Catalyst incorrectly implements while it correctly plays back video with another API instead. Boo hoo. From my perspective, Catalyst is actually better than the NVIDIA binary driver as of the 11.1 release. If you care about HW video decoding even when using OpenGL results in acceptable performance, that's like caring that your car (damn bad analogies) is a SOHC engine instead of DOHC. For all practical purposes, it's basically an academic point.
Since you said "bollocks" to my attempt to dissuade you from car analogies, here's one more while we're at it: Catalyst is like a car that gets you from point A to point B. Earlier models lacked windshield wipers, but the 2011 model has those as well as XM radio, GPS, and improved airbags. It's gotten you from point A to point B since about 2007, but now it has all the features most ordinary users expect. But the difference is that, to make a proper car analogy, the year it started to get you from point A to point B was actually 1907, not 2007. (OK, the Model T wasn't available until late 1908, but taking it back exactly 100 years was fun for illustration purposes). And it's just "1911" now, and it already has GPS, wipers and XM radio? Holy crap, those Ford engineers move fast! :P
in the past there were more hairy moths than soup
next step will be slim a bit and support webGL without crashes and final support video acceleration in flash.
maybe we got an catalyst 11.3 with all that stuff.
In response to the question "Has AMD Finally Fixed Tearing With Its Linux Driver?" asked by the thread title, I can give an answer for my system.
This is with 3 x 24" LCDs, each @ their native resolutions of 1920x1200 with no rotation or anything fancy.
Looks like I'll have to dump this adaptor after all. Seems 1 GB isn't enough.
It gets better.
When I was running the FirePro pre-release driver at least I could get GL video output frame locked if not the whole desktop.
Now, each monitor has its own idea of where the V-Blank is so on each screen the tearing occurs at a different place. At lease the tear position doesn't roll up or down though like it used to