ATi Support on infinityOS

[bridgman]

So has XAA (for 2D) and look at all the crap we get for using it

(slow unminimize after the no-backfill X server patch was yanked from distros)

[RealNC]

Yep, understood. I don't think it was well understood at the beginning that some players were not capable of working with a GL output yet.

GL only solves the wrong color problem, not the vsync one. To go back to what we said earlier, what we really would wish for is DRI2 support in fglrx. Since, as you said, features are not a priority for you, then GL is not a real solution for video. You really need to fix Xv in fglrx. Since the way the open driver does vsync in Xv with DRI1 doesn't seem that complicated, why can't you do the same in fglrx? It's been ages since people were complaining about this. Is the cost of fixing this really that high for such a large, milti-million, world-class corporation like AMD?

You can also start a donation effort where people can contribute a few bucks if you're really that poor.

[monraaf]

But Xv works quite well even nowadays with content up to 720p. The radeon driver surely has no problems with it. Maybe the fglrx devs should take a look at the code, the license is permissive enough to take bits of the code and use it in the proprietary drivers. At least the washed out colors problem should be easy enough to fix in a day.

[darkphoenix22]

GL only solves the wrong color problem, not the vsync one. To go back to what we said earlier, what we really would wish for is DRI2 support in fglrx. Since, as you said, features are not a priority for you, then GL is not a real solution for video. You really need to fix Xv in fglrx. Since the way the open driver does vsync in Xv with DRI1 doesn't seem that complicated, why can't you do the same in fglrx? It's been ages since people were complaining about this. Is the cost of fixing this really that high for such a large, milti-million, world-class corporation like AMD?

You can also start a donation effort where people can contribute a few bucks if you're really that poor.

Perhaps, as per the suggestion earlier in this thread, ATi should make the OSS Radeon drivers the offical "desktop Linux" drivers and gradually add proper OpenGL support (using code from fglrx) via a closed source library. This compromise seems to solve everyone's issues and would make everyone happy.

[bridgman]

GL only solves the wrong color problem, not the vsync one. To go back to what we said earlier, what we really would wish for is DRI2 support in fglrx.

Why ? You have redirected direct rendering already. DRI2 was a way to get to RDR, albeit with a non-trivial performance hit right now.

Seriously, my understanding is that vsync *does* work with GL. If it doesn't then please give me some moer details. I don't think Compiz understands vsync properly yet but that's a separate issue.

Since, as you said, features are not a priority for you...

When did I say that ? I said that we were prioritizing some features over others...

... then GL is not a real solution for video. You really need to fix Xv in fglrx. Since the way the open driver does vsync in Xv with DRI1 doesn't seem that complicated, why can't you do the same in fglrx?

Because all the internal APIs and partitioning of functionality are different, and banging on registers directly in the video stack would cause all kinds of bad things to happen.

It's been ages since people were complaining about this. Is the cost of fixing this really that high for such a large, milti-million, world-class corporation like AMD?

You can also start a donation effort where people can contribute a few bucks if you're really that poor.

The cost is what we *don't* do as a result of spending time rewriting the video stack. If we don't do the things that we *are* working on that costs us large orders and millions of dollars in lost sales. Contributions welcome.

I know that in a perfect world we would have a tank of frozen, pre-trained developer clones so we could pull out a few dozen, thaw them out and use them whenever we needed them and throw them back in the tank before the budget runs out, but I've looked all over and haven't found it yet.

Seriously, if you want to contribute then help push the open source 3D effort ahead or get Compiz vsync working on a wider range of drivers.

[darkphoenix22]

Looking at the license of the Radeon code, it is licensed under MIT, meaning linking to proprietary code is completely allowed. I believe most of not all of X.org is licensed under MIT as well, making the hybrid driver completely possible in terms of legality.

This solution would be more than satisfactory to much of the opern source community (except for the Free Software Foundation, but who the hell cares what they think anymore).

The open source community would just prefer if the backend of the drivers is free and open. I know I personally couldn't care less about the 3D libraries, especially if we could easily compile it to use Mesa instead.

[bridgman]

Perhaps, as per the suggestion earlier in this thread, ATi should make the OSS Radeon drivers the offical "desktop Linux" drivers and gradually add proper OpenGL support (using code from fglrx) via a closed source library. This compromise seems to solve everyone's issues and would make everyone happy.

Sure, except the internal APIs are totally different. If we grafted the closed source 3D driver onto the open source driver's lower level stack you wouldn't *get* the performance and functionality you want.

If we grafted the open source X driver onto the proprietary lower level stack (which is what you need for the 3D features and performance) then you lose the simplicity that everyone finds so attractive about the open source driver.

Seriously folks, we're talking about a 15 million line code base vs a 150,000 line code base. There's a reason you get more features and performance from the proprietary driver.

What I do think *can* work is opening up more of the interface code between proprietary common modules and the rest of the Linux system, like we do with the kernel compatibility layer today.

[bridgman]

I will not use car analogies
I will not use car analogies
I will not use car analogies
...

[darkphoenix22]

Sure, except the internal APIs are totally different. If we grafted the closed source 3D driver onto the open source driver's lower level stack you wouldn't *get* the performance and functionality you want.

If we grafted the open source X driver onto the proprietary lower level stack (which is what you need for the 3D features and performance) then you lose the simplicity that everyone finds so attractive about the open source driver.

Seriously folks, we're talking about a 15 million line code base vs a 150,000 line code base. There's a reason you get more features and performance from the proprietary driver.

What I do think *can* work is opening up more of the interface code between proprietary common modules and the rest of the Linux system, like we do with the kernel compatibility layer today.

Performance can come with time. We just want something that works. A hybrid driver will provide that in the short term as well as in the long term.

[bridgman]

Seriously, a hybrid of the fglrx 3D userspace driver over the open source kernel and X drivers is *not* a short term solution. The internal APIs are totally different and the low level APIs in the fglrx stack explicitly support the upper level functionality. You can't map one on to the other.

Getting the last few 3D issues worked out on the open source stack is a short term solution. A hybrid open/closed driver is a possible long term solution but not until the open source stack starts to approach fglrx in functionality.

I guess I don't understand why you think it would be easy.