When'll AMD Opensource Drivers be feature-complete for Evergreen chips

[Figueiredo]

I believe AMD invests more in Linux relative to the size of the company than Intel does.

What "position" you are talking about -- being smaller ?

bridgman,

First of all, thank you very much for your hard work and great support you give to the community. Please note that I very much appreciate the work you and the whole AMD team at AMD do.

That being said, the position I'm refering to is this.

There is no AMD system that I know of that ships with linux installed. AMD is not confident enough to provide linux support for OEMs or consumers. Intel is. There are several intel laptops shipping right now with linux. There are also a few smartphones. Even nvidia is shipping products with linux right now, and a lot by the way (see nexus 7).

What products ship with AMD chips? windows PCs, XBox 360, and if the rumors are true, the next gen xbox and playstation. Where's linux in this mix? Nowhere to be seen...

I really hope that valve is able to persuade some high execs over there into supporting linux. AMD already lost OYUA to nvidia, and every rumor i've seems hints toward nvidia on the steambox. So in my mind, we're a living the gaming revolution on linux right now, and AMD is missing the boat as we speak.

AMD may invest more on linux relative to its size than intel, but that changes nothing for the consumer. The same way that relative to the size of the company, FX processors are probably blazing fast, but it doesn't sell any more chips because of that.

It's just a shame really, because I would love to have an APU based steambox...

Anyway, keep up the good work. I sincerely hope you guys manage to achieve your objectives.

[bridgman]

AFAIK there are a number of AMD-based systems shipping with Linux preloaded. I know there were last year, but haven't been involved for a while so not sure of current status. The preloads are generally using fglrx, however, not the open source drivers. Will take a quick look and see what I find...

EDIT -- wow, I'm not seeing many Linux preloads this year on *anyone's* hardware, even in the workstation corner. Lots of Win8 and Win7 on clients, RHEL and SLES on servers and the occasional Ubuntu client, but a *lot* less than last year.

... so you might be right. Hopefully that will change once everyone recovers from the Win8 transition.

BTW you mentioned "NVidia shipping with Linux on Nexus7" -- while it's true that Android uses a kernel so it is absolutely correct to call an Android product "Linux", but since the graphics driver stacks are so different between Android Linux and typical PC Linux/Gnu/X/Mesa/DRI that they really need to be kept separate from a practical perspective. You can share a KMS kernel driver and 3D driver between the two stacks (so Android-x86 works with both intel and radeon), but that's pretty much where it ends.

[crazycheese]

EDIT -- wow, I'm not seeing many Linux preloads this year on *anyone's* hardware, even in the workstation corner. Lots of Win8 and Win7 on clients, RHEL and SLES on servers and the occasional Ubuntu client, but a *lot* less than last year.

... so you might be right. Hopefully that will change once everyone recovers from the Win8 transition.

How should I read this?
- we will hold every platform support, until our windows 8 driver is polished so that people are forced on windows 8 - We compensate ugly interface with stable driver - crashing/underdeveloped driver for other platforms.
or
- we put every effort into windows 8 right now, so others are not important, regardless of what crowd and Gaben says?

Also, *source* on *a lot less Linux preloads* please..?
Fact is, mobile non-x86 processors are dominating this year, with a LOT of Linux Android/or full-blown hatching, incl. gaming. These are not powered by AMD GPUs/APUs, so thats obvious.
However, why should relative preload marketshare of x86 change due to this?

[lucx]

I guess the most important part of the answer is that the addition of a feature to the list doesn't necessarily mean that anyone expects to ever work on it -- sometimes features are added just to make it clear what is and is not included.

Most of the features you mentioned are discussed here on a regular basis, but here's a quick summary off the top of my head :

* Video Decode (XvMC/VDPAU/VA-API) on the 3D engine -- Christian and others put a lot of work into this and concluded that it wasn't likely to work particularly well for H.264 using the graphics pipeline. Christian thought that compute shaders (with their lower overhead) might be a sufficient improvement but at the time the compute infrastructure wasn't in place. Short term focus is on investigating whether we can expose UVD support (internal), and building up compute infrastructure via OpenCL efforts below.

* Video Decode (XvMC/VDPAU/VA-API) on UVD - see above

* Hybrid Graphics - lots of work on this over the last year, mostly by airlied

* Stippled Primitives - don't think anyone is looking at this, or if there is much use outside of a few workstation apps

* Smooth Primitives - ditto

* Tessellation Shader Stages - believe this is GL4 functionality so would probably get looked at after 3.3 is done

* Geometry Shaders - this is GL3.2 so "it's number just came up" -- article in the last few days about work on this by airlied

* Hyper-Z - lots of work on this over the last year but don't think it's ready to turn on by default yet

* CrossFire (multi-card) - don't think anyone is looking at this -- improving performance of single card 3D is generally felt to be better use of time

* Compute (OpenCL) - lots of work on this over the last year by tstellard and a some community developers

BTW I only counted 10 -- what did I miss ?

Hello, are you shure that you know what are you talking about???

support for vaapi was removed with this commit
http://cgit.freedesktop.org/mesa/mes...61cf0955c33072

and for vdpau acceleration is working only mpeg2 and for this codec not even all profiles, just simple I belive!!

[agd5f]

How should I read this?
- we will hold every platform support, until our windows 8 driver is polished so that people are forced on windows 8 - We compensate ugly interface with stable driver - crashing/underdeveloped driver for other platforms.
or
- we put every effort into windows 8 right now, so others are not important, regardless of what crowd and Gaben says?

or, OEMs are not asking for Linux pre-loads at the moment?

[bridgman]

How should I read this?
- we will hold every platform support, until our windows 8 driver is polished so that people are forced on windows 8 - We compensate ugly interface with stable driver - crashing/underdeveloped driver for other platforms.
or
- we put every effort into windows 8 right now, so others are not important, regardless of what crowd and Gaben says?

Read it as "there seem to be a lot fewer Linux preloads overall, and the ones that are there seem to be going for IGP-level graphics rather than dGPU so we don't seem to have as much of a share as in previous years. Our share is probably the same for dGPU ("traditional workstation") but right now those SKUs seem to be largely Windows-only no matter which GPU vendor you look at.

Also, *source* on *a lot less Linux preloads* please..?

I spent a few minutes looking at web sites for a few major OEMs and compared what I saw to my recollections from previous years.

[bridgman]

Hello, are you shure that you know what are you talking about???

support for vaapi was removed with this commit
http://cgit.freedesktop.org/mesa/mes...61cf0955c33072

and for vdpau acceleration is working only mpeg2 and for this codec not even all profiles, just simple I belive!!

Nope, but in this case I don't understand what point you are trying to make.

How is what you are saying inconsistent with what I said ?

[lucx]

Nope, but in this case I don't understand what point you are trying to make.

How is what you are saying inconsistent with what I said ?

sorry for that I just misunderstood your post!

[oliver]

What does this mean? Comes up in a mode you don't like? dualhead vs. clone? something else? The driver just generates an event when a monitor is plugged or unplugged. It's up to your desktop environment to decide what to do with that event.

I have the same issues on my 6650. I have 2 heads connected, one via DVI and one via Displayport with both a HPLP2475w. When I even hit the 'scan' button to scan for inputs, the system thinks the head got disconnected. I have to do an ctrl-alt-f2 ctrl-alt-f1 to switch out/in to graphical mode to re-activate the port.

[Adarion]

Thanks for the update John!

Can you (one of the devs) explain a bit more about the VBIOS tables?
Can that be compared to something like the ACPI tables (eg. DSDT) or is it just the several states like "video watching" (GPU on xxx MHz, VRAM on xxx MHz) and "gaming" (with GPU on yyy MHz etc.)? Why do these tables lack information?

I personally always used Sapphire cards which afaik are close to AMD's reference design and they normally work nicely - also in terms of power consumption. Actually I have with profile=low (free driver stack) same or even 1-2 W better overall (power plug wall measured) wattage like I have in Windows XP with Catalyst. It's like 83 W (Linux free) idle vs. 85 W idle (W32). (Didn't try fglrx/Linux for a long time )
So I personally am really fine with power side of the free stack (just sad that dynpm does not use low profile!). But I see complaints from others sometimes.

So do some vendors provide clean implementation of VBIOS tables (like some mainbaord people provide good DSDTs) and some do not? How many quirks are allowed for a vendor that sells a Radeon GPU somewhere in a solution?

edit: And yes please for any kind of video accel (your E-350 Mini-ITX style boards would be perfect HTPCs then!) (low power, passively cooled and so on)