ATi Support on infinityOS

[darkphoenix22]

I don't get your point with the documentation as it is there and ati/redhat devs work with it. xv was usually the first that works after modesetting - it just does not work with hd 5 series yet. xv was ok for long time with radeon oss driver (radeonhd has the same issues as fglrx). What's the big problem with your distro using opengl for video output? I know that some apps do not allow that, but xbmc, mplayer, vlc can all use it - just that the speed of a lowend card can be too slow...

OpenGL is much slower than XV. In addition, every other video card driver I used has full support for XV V-sync, including the open source Radeon drivers. There is no why a the driver for a major video card should not support XV V-sync. It makes the drivers appear incomplete.

I am happy that ATi has people working on the open source drivers. It is probably the very reason why the those drivers are so complete compared to the nouveau drivers in terms of usability and functionally. I just feel that because of the progress made on the Radeon drivers, ATi should shift their developer focus to them instead of the fglrx drivers. It frankly would be a much better use of time and resources, in addition to giving ATi a huge advantage over Nvidia in the Linux community.

I know I would buy ATi over Nvidia no questions asked if I knew that ATi's primary Linux driver was completely open source. Presently, I am forced to chose Nvidia as their official drivers just plain work better at the present time.

[bridgman]

Remember why proprietary Linux drivers exist in the first place - they allow code sharing across 100% of the PC market in the areas where APIs are common, such as OpenGL, which in turn makes it possible to provide more features and performance to Linux users than any vendor could provide with a *nix-specific open source code base.

Opening up the proprietary stack isn't practical because the other 98% of the PC market requires robust DRM all through the stack, and opening up the proprietary code base would put the DRM implementations at risk (which in turn puts the other 98% of our market at risk).

Bottom line is that some markets (3D workstation, high end gaming, possibly compute) are going to require the features and performance which are only practical with code-shared proprietary drivers. Code sharing is what gives you the benefits, and proprietary/binary delivery is just the cost of code sharing.

For your application you may find that staying with the open source drivers is the best solution right now, if you require Xv or need to operate on sufficiently slow CPUs that the extra overhead of GL (which is pretty small with the right options) can not be tolerated.

[darkphoenix22]

Bottom line is that some markets (3D workstation, high end gaming, possibly compute) are going to require the features and performance which are only practical with code-shared proprietary drivers. Code sharing is what gives you the benefits, and proprietary/binary delivery is just the cost of code sharing..

Intel has fully open source drivers on LInux and they work beautifully. As they are integrated with the X server, they work out of the box, no need to install on any Linux distribution. They are better in quality than the Windows drivers and support more features. Hell they work on Live CDs, something I have never been able to do with the binary Nvidia or ATi drivers.

My question is, if users of Intel video hardware can have fully open source drivers (with full support of 3D acceleration) and be able to take advantage of the many of benefits such a solution offers, why can't users of ATi hardware? Why must users of ATi on Linux deal with half-working and half-implemented drivers when users of the competition's products have no such problems and restrictions?

[jrch2k8]

Remember why proprietary Linux drivers exist in the first place - they allow code sharing across 100% of the PC market in the areas where APIs are common, such as OpenGL, which in turn makes it possible to provide more features and performance to Linux users than any vendor could provide with a *nix-specific open source code base.

Opening up the proprietary stack isn't practical because the other 98% of the PC market requires robust DRM all through the stack, and opening up the proprietary code base would put the DRM implementations at risk (which in turn puts the other 98% of our market at risk).

Bottom line is that some markets (3D workstation, high end gaming, possibly compute) are going to require the features and performance which are only practical with code-shared proprietary drivers. Code sharing is what gives you the benefits, and proprietary/binary delivery is just the cost of code sharing.

For your application you may find that staying with the open source drivers is the best solution right now, if you require Xv or need to operate on sufficiently slow CPUs that the extra overhead of GL (which is pretty small with the right options) can not be tolerated.

well i have to admit that fglrx have improved over 9 series but well i see the point of darkphoenix too, for example my rig is

* Athlon II X4 620 cache unlocked @ 3.6 ghz standard voltage (this is one hell of a processor +1billion to AMD here)
* 2x Radeon HD 4850 X2 in crossfire since 10.4 in ubnutu
* 2 1tb black series WD HDD in RAID 1
* mobo MSI GD-70 (i think the is the best mobo for AMD cpu rigth now)
* 8gb 2133 ddr3

i consider this a very powerful rig, ok is not a Power7 cpu but you get the point, and even with this setup watch a 720p/1080p using opengl or Xv are really crappy using fglrx, aka

* teared as hell
* weird fast motion defect, you can see some weird diagonal lines is fast action scenes
* sometimes it takes a real nasty bunch of memory and the video begin the slower and slower until mplayer or vlc crash and i have to restart the Xorg to release some memory
* in some cases in the middle of a movie frames freeze and i have to restart the video

now on the other hand OSS drivers with XV is stable like a rock, so far since latest december git the video is 100% glitch free for me, the frame rate is always persistent across the movies, is like a dream come true. so since his distro is focused for video professional i think the OSS is best of the best for that, specially since va-api and xvba are mostly alpha quality software (not very stable btw) at least for now.

now is true that the OSS is not yet there if you are interested in 3D art or heavy wine gaming, so for now fglrx is your only choice (with a truckload of patches especially for wine)

now about you commentaries about the drm issues, well from my point of view i think for Linux is by far better have a clean unix implementation than code sharing. most of those code sharing feature are useless for linux anyway, and the rest of drm needed for X or Y opengl function needed in games, ermmm well we can hack it and putting in a legal limbo as an external package as always so not a big deal, what linux needs is only these:

* up to date standard opengl 3.X/4.X implementation in mesa/gallium
* standard up to date Opencl tracker
* the uber DDX we already have
* a better Xorg this monster need a lot of love in the next years

with this we can recreate all the code sharing stuff properly, for example:

* UVD? = no, OpenCL accelerated codec in libavcodec/libavformat/libpostproc + opencl accelerated convertion in XV
* Xrender/Direct2d? = have some sort of plugin architecture in the lower core of Xorg could allow ppl to write and OpenGL/CL accelerated rendering
* Eyefinity? = get rid of xinerama and implement a better multi monitor solution maybe and some help with the hardware speficics in the 5000 series
* stream? = just opencl a million times better
* overlay? = well im just not sure anymore if this still have any major use beside some poor ported 3d/cad apps.
* opengl IP protected extension = well i think that having an idea of how it works it can be coded with C or Opencl for example, or just the always old good hack.
* 3d performance/optimization? = well at first im sure it will be at least 20% slower but with time will get better maybe close enough to stop caring.
* multigpu = well i heard that airlied and gsoc ppl are thinking in something, maybe mesa 8 or 8.X could bring a surprise here too

all this plus ports to BSD/Opensolaris/etc/etc, of course all this could take a couple of years or a bit more but when the tools get here and get stable enough the need for fglrx outside any enterprise stuff will be very close to 0

[jrch2k8]

Intel has fully open source drivers on LInux and they work beautifully. As they are integrated with the X server, they work out of the box, no need to install on any Linux distribution. They are better in quality than the Windows drivers and support more features. Hell they work on Live CDs, something I have never been able to do with the binary Nvidia or ATi drivers.

My question is, if users of Intel video hardware can have fully open source drivers (with full support of 3D acceleration) and be able to take advantage of the many of benefits such a solution offers, why can't users of ATi hardware? Why must users of ATi on Linux deal with half-working and half-implemented drivers when users of the competition's products have no such problems and restrictions?

My advise is support the OSS driver you wont regret it, like im really impressed of how good is becoming everyday

[bridgman]

My question is, if users of Intel video hardware can have fully open source drivers (with full support of 3D acceleration) and be able to take advantage of the many of benefits such a solution offers, why can't users of ATi hardware? Why must users of ATi on Linux deal with half-working and half-implemented drivers when users of the competition's products have no such problems and restrictions?

The quick answer is that Intel doesn't offer products in the areas (workstation, high end gaming, compute) where a proprietary driver is needed. From my earlier post :

Bottom line is that some markets (3D workstation, high end gaming, possibly compute) are going to require the features and performance which are only practical with code-shared proprietary drivers.

If we only offered IGP graphics I expect we would focus entirely on open source drivers as well, but the reality is that for the high performance market segments a proprietary code-shared driver is the only competitive solution today.

If you get the opportunity to install Lucid on one of our IGP products you might be pleasantly surprised by the out-of-box open source drivers. Give it a try if you get a chance.

[darkphoenix22]

Due to the exceptionally strong video performance, I have decided to concretely provide support for the Radeon drivers. I am still truly, even after a day, blow away at how well they work. I have even decided to replace (at least temporarily) my Nvidia 9600 with the card I tested last night, running on the Radeon drivers, as it runs much cooler and quieter.

Due to the unimpressive support for video in the fglrx drivers, I have decided to not support them in infinityOS, at least for the forseeable feature. The many problems with them, especially in regards to video playback, would likely be thought to have been caused by my distro, instead of the fglrx drivers and ATi. This is not a risk I can take.

I have posted up a FAQ on my Launchpad detailing this stance and the reasons behind it for my users to read.

I still encourage ATi to adopt the Radeon driver codebase as the basis of their Linux drivers, but I recognize that you have corporate interests in mind. I can only appeal and ask that you keep the needs of your users in mind, as it is us who will be buying your products and recommending them to others. It is never a good idea to put the needs of your corporation ahead of the needs of your consumers.

[Kano]

Basically you can not recommend using radeon oss driver to hd 5 card users. And that's something you often get when you buy now a new laptop - there you can not exchange the gfx card. I know that fglrx is far from optimal, but it is unlogical not to support it. Also you should test vaapi.

[darkphoenix22]

Basically you can not recommend using radeon oss driver to hd 5 card users. And that's something you often get when you buy now a new laptop - there you can not exchange the gfx card. I know that fglrx is far from optimal, but it is unlogical not to support it. Also you should test vaapi.

My goal with infinityOS is to provide a complete solution of 100% working software. I want my users to know that when they use infinityOS, everything will work from head to toe, end of story.

I would rather turn away potential users because their hardware is not supported then frustrate users because their hardware is half supported. The former user could later try infinityOS again at a later time. The latter user would be discouraged from ever using infinityOS (or even Linux, due to the user group I am targetting) again and would be forever lost as a customer. As I feel my distro is geared towards end users, I can not ask my users to configure text files or compile software to get their hardware working as they would like not have the skill set needed for this undertaking.

fglrx is not the only software I have excluded from infinityOS for these reasons. PulseAudio, an audio daemon included in many modern Linux distros, has been excluded as well as it never seems to work and just causes frustrations for my users as it breaks many common programs, such as games and Adobe Flash. This has cost me support for bluetooth headphones and heasets, but I feel that the gain to my users in common usage scenerios is worth it.

In terms of hardware support, a hard "no" is infinity better than a "maybe".

PS Kano, I would be more than a happy to include your builds (or the builds you recommended) of the fglrx and mplayer in my repositories. I would have to ask though that you upload them to Launchpad. When I copy them over, they will likely be placed in my "unstable" repo due to the beta status of some of their components.

[Panix]

If I'm not mistaken, the OSS drivers doesn't support/cover enough features to just say, mostly support that.

What about the Wine users? What if you want 3D and video features/support?

I don't understand the fglrx 'bashers' at all. I can understand frustrations with it and encouragement/insistence that they improve and/or that the support effort/investment be increased or more dedication thereof but to say 'replace' or 'neglect' in favor of the OSS?!?

The OSS drivers are obviously ideal but to concentrate on seems unrealistic. I realize the ATI ppl state the development is separate and done independently but the fact is the 3D/'extra features' (e.g. Wine, 3D, video acceleration etc etc.) is only available or more optimized with the fglrx driver.

Nvidia is only having a binary driver and you get VDPAU and other features so if you want more choices and a viable alternative to that, you need an improved and optimized fglrx driver, bottom line. Imho...

I hope it steadily improves because I still would like a Radeon 5xxx card. But, the lack of features compared to Nvidia cards does concern me. 'Doubt I'd want a Fermi card, though. Only if the 45x or if there is a 46x card but they will probably be more expensive than comparable ATI cards so... waiting for ATI's improvement/development of the binary driver.