Tear-Free Acceleration For ATI EXA, Xv

[MrCooper]

No tearing please, we're British

The sync-to-vblank technique used by compiz can't work reliably with indirect rendering. Until we can use compiz with direct rendering with DRI2, the only hope there is to set the vblank_mode option to 2 or 3 in /etc/drirc. Unfortunately, that doesn't help in the non-fullscreen case either, as compiz uses the GLX_MESA_copy_sub_buffer extension instead of buffer swaps for incremental screen updates. And in the fullscreen case, compiz can unredirect the window anyway, in which case the following applies:

It should be relatively straightforward to integrate the XVideo part of Alex's patch into mainline xf86-video-ati Git. Only the normal 2D rendering part isn't ready.

[some-guy]

Saying fglrx needs to go away is rather impractical. The mesa 3d driver will never equal the 3d performance of fglrx, simply because ATI spends the time and money to optimize their driver for specific games and has more resources at their desposal. The mesa driver may get withing 10-20 percent of fglrx, but probably no closer.

While it may have features that OSS doesn't(because of drm, etc), OSS will imo get ahead. Many games use OpenGL 2 and GLSL, this is where mesa is behind, once gallium comes, GL2 and 3 as well as the GLSL's should be implemented, then it should be very close

[duby229]

Duby, you're being a bit abrasive and also unrealisitc. Radeon and radeonhd are *very* similar drivers. Very little effort is being duplicated at this poing and a lot of code is being shared. RadeonHD is arguably the better driver since the inclusion of ATOMBios, which enables it to do modesetting natively for cards that it knows about, and with ATOMBios for everything else. Also, the acceleration code for r600+ is totally different from anything prior, so including in radeon would be rather impractical.

Saying fglrx needs to go away is rather impractical. The mesa 3d driver will never equal the 3d performance of fglrx, simply because ATI spends the time and money to optimize their driver for specific games and has more resources at their desposal. The mesa driver may get withing 10-20 percent of fglrx, but probably no closer. ATI can't very well release code that contains IP that isn't theirs, so open-sourcing fglrx isn't practical either. Fglrx will always have a place, but hopefully a more marginal one as the open-source driver improves.

I simply cant agree with you... I've taken the liberty of bolding one thing that you've said... So with that bolded statement in ming, again what was the point in radeonhd? You keep bringing up native modesetting as it's only saving grace except that you've already admitted that it was a watse of time due to KMS. I'm sorry but I just cant find anything redeeming. Nothing.

I think your totally mistaken about fglrx... It's linux performance --sucks-- compared to it's windows performance. I dont ever expect the open source driver to ever get the same level of performance that the windows driver has, but I'd be happy with 75%...fglrx doesnt even come close to offering that and I'm 100% convinced that the open source driver will surpass it....

So far the only benefits that the closed driver has over the open driver is artificially imposed by ATi. Personally I think they should be ashamed of themselves, especially in the face of Intels open source driver running on Larrabee... Like I said the window of opportunity is closing and ATi needs to get on the ball while they still can...

[bridgman]

So with that bolded statement in ming, again what was the point in radeonhd? You keep bringing up native modesetting as it's only saving grace except that you've already admitted that it was a watse of time due to KMS. I'm sorry but I just cant find anything redeeming. Nothing.

There are some things about radeonhd which are more important to Novell than to Red Hat, at least for a while. One example is that the radeon modesetting code is built natively around randr1.2, which makes the code nice and simple but means that xservers without randr1.2 are not directly supported. A lot of Novell enterprise distros in use today are running pre-Randr1.2 x servers while the corresponding Red Hat distros are running slightly newer X servers and are happy with only RandR1.2-based modesetting. My understanding is that it should be possible to pick up the RandR1.2 code from the server and patch it into the driver but the Novell devs had a strong preference for supporting the pre-RandR1.2 API directly.

There are a number of similar issues. None of them are showstoppers but it will take time to work through them all. Once we have a combination of feature set and implementation style that all the major distros and devs can agree on we should be able to get to a single driver. The "duplicated effort" is mostly in the past, since the bulk of ongoing work will either be in the drm or mesa components, which were never duplicated.

I think your totally mistaken about fglrx... It's linux performance --sucks-- compared to it's windows performance. I dont ever expect the open source driver to ever get the same level of performance that the windows driver has, but I'd be happy with 75%...fglrx doesnt even come close to offering that and I'm 100% convinced that the open source driver will surpass it....

Depends on whether you are talking about 2D or 3D. On the 3D side the performance is pretty close already, and fglrx will probably continue to be faster than the open source driver because the API is common with other OSes and we can take advantage of a common code base across OSes.

On the 2D side the performance is probably slower but it's tough to compare apples-to-apples because the acceleration framework is different and a number of the apps use different rendering approaches on Linux vs. Windows. If you run EXA on the open source driver with 1.5 server you should get an idea of what is possible with the current accel framework, and I expect that fglrx will approximate that over time. Performance in 2D is more driven by framework improvements and application changes than by driver sophistication, so fglrx will not have the same kind of inherent performance edge that it does in 3D.

So far the only benefits that the closed driver has over the open driver is artificially imposed by ATi. Personally I think they should be ashamed of themselves, especially in the face of Intels open source driver running on Larrabee...

I don't understand this - can you fill me in ? Our open source drivers run on our high end workstation cards, and once the memory management work catches up with the recent change from TTM to GEM I expect the new framework features will arrive more or less simultaneously on Radeon parts. Most of the performance difference between fglrx and open source drivers today is a function of framework features and driver architecture, but those are all being addressed.

Are you saying that we are artificially holding back the open source drivers somehow, or are you just saying that by providing a closed source driver for the Linux workstation business we are somehow stealing resources from the open source drivers ?

The fglrx driver will probably continue to be faster in 3D because of the cross-OS $$ we invest in things like a proprietary shader compiler and performance optimizations, but that investment is only available to the Linux driver *because* we share closed-source code with other OSes. If we had a dedicated Linux open source driver then it would *not* benefit from the work done for other OSes in common code and would perform more like the open source drivers we have today.

That said, all this discussion is fairly pointless, since the performance of the open source driver stack today is not representative of how it will perform once the next round of framework improvements (primarily gated by memory management today) arrive and allow corresponding improvements to be made in the driver. I think the driver world will look quite different six months from now.

[duby229]

Hi Bridgeman,

Sorry for the late response. After the weekend I came to work only to discover a massive outbreak of Antivirus 2008 XP... Oy...

Anyhoo....

There are some things about radeonhd which are more important to Novell than to Red Hat, at least for a while. One example is that the radeon modesetting code is built natively around randr1.2, which makes the code nice and simple but means that xservers without randr1.2 are not directly supported. A lot of Novell enterprise distros in use today are running pre-Randr1.2 x servers while the corresponding Red Hat distros are running slightly newer X servers and are happy with only RandR1.2-based modesetting. My understanding is that it should be possible to pick up the RandR1.2 code from the server and patch it into the driver but the Novell devs had a strong preference for supporting the pre-RandR1.2 API directly.

There are a number of similar issues. None of them are showstoppers but it will take time to work through them all. Once we have a combination of feature set and implementation style that all the major distros and devs can agree on we should be able to get to a single driver. The "duplicated effort" is mostly in the past, since the bulk of ongoing work will either be in the drm or mesa components, which were never duplicated.

Which is --exactly-- why ATi needs to tell Novell to suck on an orange. Time and time again Novel does something totally retarded specifically for the sole reason of holding our industry back. This is just one more example in a massive string of others. I could go on and on about just how corrupted Novell really is, and show where most of there money comes from, but I'll choose to keep this short and sweet. I'll just say this... Novells earnings reports are damn near illegal.


They definitely have a financial bias against the linux community, and it is because of this that it is no coincidence that they chose to buy Suse, and has since then proceeded to obfuscate, and divert resources industry wide across a huge range of projects..

Depends on whether you are talking about 2D or 3D. On the 3D side the performance is pretty close already, and fglrx will probably continue to be faster than the open source driver because the API is common with other OSes and we can take advantage of a common code base across OSes.

On the 2D side the performance is probably slower but it's tough to compare apples-to-apples because the acceleration framework is different and a number of the apps use different rendering approaches on Linux vs. Windows. If you run EXA on the open source driver with 1.5 server you should get an idea of what is possible with the current accel framework, and I expect that fglrx will approximate that over time. Performance in 2D is more driven by framework improvements and application changes than by driver sophistication, so fglrx will not have the same kind of inherent performance edge that it does in 3D.

3D, 2D, Video. It's all the same.... Buggy, slow, incompatable, unstable, incomplete, not standards compliant, etc, etc, etc. The list goes on and on and on.. I'll just put it like this, Play Doom3 on Windows, and then on Linux using fglrx on the same hardware, nuff said...... This is not a suggestion, you should actually do it. See for yourself.

I don't understand this - can you fill me in ? Our open source drivers run on our high end workstation cards, and once the memory management work catches up with the recent change from TTM to GEM I expect the new framework features will arrive more or less simultaneously on Radeon parts. Most of the performance difference between fglrx and open source drivers today is a function of framework features and driver architecture, but those are all being addressed.

Are you saying that we are artificially holding back the open source drivers somehow, or are you just saying that by providing a closed source driver for the Linux workstation business we are somehow stealing resources from the open source drivers ?

Absolutely yes. Beyond the shadow of any doubt. 100% Clearly and obviously. The problem is that while the radeonhd devs were busy accomplishing -nothing- the memory management code could have been worked on by more people. While ATi was busy writing a buggy, incomplete, unstable, non-compliant, propriatary driver they could have been working on releasing documentation faster, or helping the xserver devs, or helping the mesa devs... Hell any one of a 100 other things far more productive.

And then there are ATi's excuses for why they cant support crossfire on the open drivers, or proper video decode on the open drivers, or etc, etc, etc... The list again goes on and on and on again. Tell me why ATi couldnt use an industry standards interconnect? And becouse they chose to implement a proprietary interconnect shouldnt they be obligated to document it?

The fglrx driver will probably continue to be faster in 3D because of the cross-OS $$ we invest in things like a proprietary shader compiler and performance optimizations, but that investment is only available to the Linux driver *because* we share closed-source code with other OSes. If we had a dedicated Linux open source driver then it would *not* benefit from the work done for other OSes in common code and would perform more like the open source drivers we have today.

That said, all this discussion is fairly pointless, since the performance of the open source driver stack today is not representative of how it will perform once the next round of framework improvements (primarily gated by memory management today) arrive and allow corresponding improvements to be made in the driver. I think the driver world will look quite different six months from now.

No this is exactly what the point is. fglrx performance sucks, radeonhd is a waste, and radeon isnt anywhere near what it could be, and should be by now. ATi has spread itself too thin and --must-- consolidate.

Once Intel gets a top end competitor out on a stable feature complete open source driver, ATi is done. It has no future from that point forward.

[TechMage89]

uhm, let me remind you that neither radeon nor radeonhd have anything to do with 3d acceleration. That's handled entirely in mesa, where the limitations that exist do so primarily because the whole stack needs a major update, which it's getting with gem, dri2, and gallium3d.

It's really not helpful to say that ATI is holding things back deliberately. They're making the best effort to open the docs without NDA, but unfortunately, the IP situation is a lot messier than was thought initially. The docs for r500 are already pretty much all public (except for AVIVO, which is pretty low priority anyway.)

flgrx may have crummy 2d acceleration and be buggy, but it is as fast for OpenGL as the Windows driver.

[mityukov]

flgrx may have crummy 2d acceleration and be buggy, but it is as fast for OpenGL as the Windows driver.

It's very interesting point... "With all the $$ spent for hacking of Games' not-driver-friendly code", someone said..

But those games were all for Windows, isn't it? Or, there were some $$ spent for "hacking" Linux games?


Also, from what I heard, the closed driver is full of "Win blobs", adjusted via some hacking/work-arounds for working in X environment. While the OSS drivers were originally designed for X.

Yes, it supports more visuals, higher versions of OGL, etc, where OSS drivers fall back to software rendering. But I would doubt this is close to Windows version even in 3D...

[duby229]

uhm, let me remind you that neither radeon nor radeonhd have anything to do with 3d acceleration. That's handled entirely in mesa, where the limitations that exist do so primarily because the whole stack needs a major update, which it's getting with gem, dri2, and gallium3d.

It's really not helpful to say that ATI is holding things back deliberately. They're making the best effort to open the docs without NDA, but unfortunately, the IP situation is a lot messier than was thought initially. The docs for r500 are already pretty much all public (except for AVIVO, which is pretty low priority anyway.)

flgrx may have crummy 2d acceleration and be buggy, but it is as fast for OpenGL as the Windows driver.

I fully understand and appreciate that, however fglrx's 3d performance is --not-- up to par with windows. Not even 75%. I fully expect that in the coming year or two mesa will at least hit 75% of the single GPU performance. On the other hand the open driver is responsible for 2d acceleration, and video acceleration, and in both cases the open driver is wholly inadequate and yet it still outperforms the closed driver...

Why is that? How is it that a handful of open source developers that are are working against each other, can produce an incomplete, underdeveloped driver on an infrastructure that was designed for Intels inferior hardware? And get this, even under these extreme limitations,they still annihilate ATi's closed driver in almost every metric.

And I never said that ATi is holding the market back, but I did say that Novell is...ATi on the other hand for some reason that only they seem to know, thinks that a closed driver on an otherwise completely open platform is somehow, someway a good idea.... It may not be deliberate sabotage on ATi's part, but it certainly is stupid to the extreme.

[bridgman]

In most of the benchmarks I have seen Linux performance is *much* higher than 75% of Windows - probably 95% is more like it. I'll see if I can get some internal numbers for Doom3.

re: 2D, the code is perhaps 1/100th the size of 3D and the open source developers (mostly Alex) were able to implement support for a newly useful API (EXA) and get it into users hands quickly. We do expect that "new things in the framework" will hit the open source driver before fglrx; that is just one example. Alex was not fighting with himself very much while working on the EXA code (or the Textured Video code) so don't think that was a factor.

On the Textured Video side, the fglrx implementation was there for a couple of years before Compiz over AIGLX became an issue, and it was implemented in a way that didn't fit with a compositor so well. The open source implementation had the advantage of coming much later (Alex wrote it in Jan/Feb 08) so he was able to design it around Compiz from day one while the fglrx implementation needs some significant changes to work the same way.

Not sure what you mean by "a framework designed for Intel's inferior hardware". The X framework predated Intel's involvement by maybe 15 years. Keith has been working on it for a long time but only recently at Intel.

The closed driver was primarily aimed at the workstation market, where most of the users come from the Unix world and so open source is really not a concern. NVidia doesn't seem to be having problems with a closed driver; I don't think that is the main issue here.

[duby229]

In most of the benchmarks I have seen Linux performance is *much* higher than 75% of Windows - probably 95% is more like it. I'll see if I can get some internal numbers for Doom3.

re: 2D, the code is perhaps 1/100th the size of 3D and the open source developers (mostly Alex) were able to implement support for a newly useful API (EXA) and get it into users hands quickly. We do expect that "new things in the framework" will hit the open source driver before fglrx; that is just one example. Alex was not fighting with himself very much while working on the EXA code (or the Textured Video code) so don't think that was a factor.

On the Textured Video side, the fglrx implementation was there for a couple of years before Compiz over AIGLX became an issue, and it was implemented in a way that didn't fit with a compositor so well. The open source implementation had the advantage of coming much later (Alex wrote it in Jan/Feb 08) so he was able to design it around Compiz from day one while the fglrx implementation needs some significant changes to work the same way.

Not sure what you mean by "a framework designed for Intel's inferior hardware". The X framework predated Intel's involvement by maybe 15 years. Keith has been working on it for a long time but only recently at Intel.

The closed driver was primarily aimed at the workstation market, where most of the users come from the Unix world and so open source is really not a concern. NVidia doesn't seem to be having problems with a closed driver; I don't think that is the main issue here.

I understand your position as a public face for ATi, and I appreciate it very much. We need more people like you in this industry for sure, but I really dont think that you are being at all realistic. I think your views are so far off base right now that they likely arent representative of the majority. I think you give ATi a much greater role in the open source community then they deserve. And you portray the closed driver as some sort of "requirement" I think your out of touch with reality, and are getting deeper and deeper in delusions that are driven by marketing.

Heres what I would like to see for once... I would like ATi to admit that they havent been allocating the resources that there products deserve. That the closed driver has no place in an open source environment. And to tell Novell just where they can shove it.

Stop defending your worthless closed driver, and get your open source developers on the same team.