ATi Support on infinityOS

[Armin]

I think Ubuntu and its derivatives have at least 50% market share for Linux distributions at this point. So putting up a Launchpad PPA would allow you to reach 50% of your market .

No offence, but it seams like you are somewhat new in this linux buisness. Ubuntu is right now a huge hype, there are a whole lot of other distributions, some of them with a kind of a big market share (i.e. Fedora, Debian, Slackware, OpenSUSE). And anyhow, if you want to talk about "market share" you should start with RedHat and SLED, these are the two BIG players! Btw, I don't want to mention Archlinux in this list, because it's rather small, but yeah if you want to get to know your operating system better ... Arch.

I don't think that the needs of workstation and desktop users are that different, both want a stable and working system, some with 3D some without. In both cases things like this resizing-issue are unacceptable and you will hear from both groups complains about it. It's just that one group pays a lot of money to fix their problems fast(RedHat and SLED charge a lot for their support and you can spend easily 1500$ for a FireGL/ FirePro card -- compared to maybe 300$ for the same chip on a Radeon HD 5xxx quite a lot).

[bridgman]

AFAIK the resizing issue only shows up with a compositor running, and most of the workstation market does not use compositors at all.

[RealNC]

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

DRI2 is not only RDR, it's also vsync'ed compositing.

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.

As said above, vsync doesn't work with compositing, it works only with DRI2. I've no idea about Compiz though. In KDE DRI2 vsync works as intended.

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

Please don't fall back to marketing speak :P Prioritizing X over Y is just a customer-friendly way of saying what I said: Y is not a priority.

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.

OK, you know this stuff much better than anyone else here, probably. Can't comment on that, since I've no idea about driver programming so I'll take your word on it.

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 don't get it. You would need to freeze everything else in order to put vsync into Xv?

Your company must use a really weird management system.

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.

So you chose the exact opposite of a perfect world, namely the most ugly, broken world imaginable?

The "perfect world" argument has been done to death, and it's getting annoying. It's always the last excuse when all else fails. You can't have a perfect world. Ever. So stop waiting for it to happen before trying to improve something because it will never happen.

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.

In other words, you don't intent to improve Xv in fglrx. Could have said so right away. The rest is just a wrapper for that fact to make it look less ugly.

[val-gaav]

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).

Last time I checked real FSF purists do not use 3d at all, because there were some patent/license issues with Mesa or some firmware in kernel ... Well something along the lines.

Anyway I do not want a closed blob, be it hybrid or not. I just don't like it because of pragmatism not ideology.

Current radeon driver is fine for me as it is... Well some 3d performance gain would be nice I guess ...

[darkphoenix22]

No offence, but it seams like you are somewhat new in this linux buisness. Ubuntu is right now a huge hype, there are a whole lot of other distributions, some of them with a kind of a big market share (i.e. Fedora, Debian, Slackware, OpenSUSE). And anyhow, if you want to talk about "market share" you should start with RedHat and SLED, these are the two BIG players! Btw, I don't want to mention Archlinux in this list, because it's rather small, but yeah if you want to get to know your operating system better ... Arch.

I don't think that the needs of workstation and desktop users are that different, both want a stable and working system, some with 3D some without. In both cases things like this resizing-issue are unacceptable and you will hear from both groups complains about it. It's just that one group pays a lot of money to fix their problems fast(RedHat and SLED charge a lot for their support and you can spend easily 1500$ for a FireGL/ FirePro card -- compared to maybe 300$ for the same chip on a Radeon HD 5xxx quite a lot).

All the new users are going towards Ubuntu/Debian based distributions, not the others. Almost every new distro made in the last couple of years has been made from Ubuntu/Debian. The RPM based distros are slowly but surely dying off (and good riddence the RPM package system is awful. The first thing I did on a SuSe back in the day was install apt-rpm). Arch and Gentoo are effectively marginalized and will see the same market share and penetration as the BSDs, for really the same reason as end user doesn't EVER want to have to compile.

I may come under criticism for saying this (and I fully admit my biases as the maintainer of a Ubuntu-based distribution), but Debian is developing into being the standard Linux distribution. It is the GNU operating system.

[darkphoenix22]

Note: The above is in terms of "desktop" Linux not server and corporate Linux. The Debian community has a long way to go in terms of professional and enterprise-class support.

[RealNC]

lol. You might want to re-evaluate Debian's market share. It's not that great. And just because Ubuntu is popular doesn't mean Debian is. Also, which other Debian-based distros are popular? Name them. And them compare them to openSUSE (please STOP still calling "SuSe", which would be wrong any way too since it was "SuSE") and Fedora.

So, yeah, right. Sorry, you have no clue.

[bridgman]

DRI2 is not only RDR, it's also vsync'ed compositing. As said above, vsync doesn't work with compositing, it works only with DRI2. I've no idea about Compiz though. In KDE DRI2 vsync works as intended.

I don't think DRI2 has anything to do with vsync'ed compositing, other than vsync'ed compositing being broken by DRI2 and now working again. Will check though. NVidia doesn't use DRI2 as far as I know, btw.

Please don't fall back to marketing speak :P Prioritizing X over Y is just a customer-friendly way of saying what I said: Y is not a priority.

No, you said *features* are not a priority. If you meant that I said *video* is not as high a priority as other stuff right now then I agree.

I don't get it. You would need to freeze everything else in order to put vsync into Xv?

Your company must use a really weird management system.

That's not what I said. There are only so many hours in a day. If developers are working on one thing that means less time available to work on other things, and all of the things that *are* being worked on are higher priority and need to get done first. Is that a wierd management system ?

I know it's nice to think that everything you want is trivial to implement and that only our stupidity and pettiness stops you from having it all today, but if it were a trivial change or a *real* bug fix we would have done it already.

So you chose the exact opposite of a perfect world, namely the most ugly, broken world imaginable?

The "perfect world" argument has been done to death, and it's getting annoying. It's always the last excuse when all else fails. You can't have a perfect world. Ever. So stop waiting for it to happen before trying to improve something because it will never happen.

Oh come on now. Do you really think I was serious about the tank of frozen developers ? If there is such a thing then I really want to know

In other words, you don't intent to improve Xv in fglrx. Could have said so right away. The rest is just a wrapper for that fact to make it look less ugly.

No, that's not what I said at all. What I said was that in the recent months other things have been more important than improving Xv in fglrx. If I had meant that we didn't intend to improve Xv in fglrx I would have said just that.

Past vs future.

[darkphoenix22]

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.

I just think it will be easier in terms of time and resources to port the fglrx features into the Radeon driverbase, rather than coding in proper Xv support among other things into fglrx.

The Radeon drivers are flexible and extensible. It honestly doesn't sound to me like the fglrx codebase is nearly as flexible or extensible, at least not at this point in time.

[Armin]

AFAIK the resizing issue only shows up with a compositor running, and most of the workstation market does not use compositors at all.

Right, that's what I meant ... more or less. In Linux distributions for the workstation market it's taken care of that such a problem doesn't occurre, one way or another.

@bridgman: I'm sorry that I brought up this hybrid thing, I know that the structure of the 2 drivers (radeon and fglrx) are totally different and that this solution would anyhow only be a long term solution. Now you have to fight against windmills to convince everybody that this isn't something happening tomorrow, if at all. I was just curious if there are such long term plan at AMD/ATI.