AMD Has Open-Source Driver For HD 8000 Series

[enrico.tagliavini]

AMD really has to review its release process. Let's start with a fact: the main uses of the open source radeon driver are modesetting and 2D (and I mean display the desktop with better performance then a cirrus card). 3D is not really an option and you can also live without compositing. Gaming is not even allowed in dreams. This will not change anytime soon.

With this release process AMD is missing even those 2 basic use: they missed linux 3.8 and it is up to distribution now to backport the work. Ok it should not be a very hard process, but still I think it is silly. That's why I think it is fine to have the 3D driver missing (I said missing, not present but a mess for the user), but with KMS, at least, working. This way a user can install his/her distro of choice and, if needed, migrate to fglrx. If basic KMS is not working the user is left more or less in the dark and the installation can be a russian roulette. And don't say you can use the alternate installation method, Joe User doesn't really know about it and I don't think he should use it anyway.

Also let's not talk about the fact you need a nuclear plant to run your AMD card if you run the radeon driver, cause powersave is a mess... and not even automatic! Joe User doesn't know about /sys fs.

And be sure to understand: the problem is the open source radeon team is only 5 full time developers. If AMD is not going to change this, AMD hardware will keep being a mess. And the legal team is not really helping either.

[archibald]

The people doing the technical review are required - they're not blocking release of source code just to be mean, they're doing it because of potential legal ramifications. I expect that they really do want to release the code, but aren't able/willing to sign off on something that could cause problems for AMD.

AMD has kept every promise that they have made, they are even hitting the targets that Mr. Bridgman hoped for (namely, releasing HD8000 code prior to release of the cards themselves). They've brought up the r300g driver and r600g is doing well (OpenGL 3.1 going on 3.3), and radeonsi is getting very close. Power management would be very useful, but they're doing the best they can - how can we (the community) ask for more?

[ChrisXY]

r600g reports OpenGL 3.1 if you invoke glxinfo with the -c argument. I believe that this requires a fairly recent copy of mesa-utils.

No, it's not in git master of git://anongit.freedesktop.org/mesa/demos

[necro-lover]

how can we (the community) ask for more?

http://en.wikipedia.org/wiki/AK-47

[ChrisXY]

No, it's not in git master of git://anongit.freedesktop.org/mesa/demos

*could have been an edit:
Even better

$ glxinfo | grep OpenGL
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Ivybridge Mobile 
OpenGL core profile version string: 3.1 (Core Profile) Mesa 9.2-devel (git-e062a41)
OpenGL core profile shading language version string: 1.40
OpenGL core profile context flags: (none)
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 9.2-devel (git-e062a41)
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:

[TemplarGR]

It seems to me AMD's intend for the opensource driver is to provide support for its APUs primarily. The next APU from AMD will be RadeonSI (HD7000 or HD8000 i don't know which) and by the time this will reach general availability most distros will be on MESA 10.0 or at least 9.1 .

Another reason i think this applies is because performance doesn't scale well to high end GPU's. The best Open-to-fglrx ratio is on lower end GPUs, so it seems to me AMD doesn't care to improve the higher versions.

So AMD's goal is probably to provide the same level of opensource support Intel provides for APUs, and leave the high end to Catalyst.

It is nice to know that the Opensource support for the next APU will be there on day one. I am planning to get one.

[fa5hion]

AMD really has to review its release process. Let's start with a fact: the main uses of the open source radeon driver are modesetting and 2D (and I mean display the desktop with better performance then a cirrus card). 3D is not really an option and you can also live without compositing.

3D engine is used for 2D acceleration in radeonsi (Radeon HD7000 series and newer). So, it's not that straightforward.

[glisse]

AMD really has to review its release process. Let's start with a fact: the main uses of the open source radeon driver are modesetting and 2D (and I mean display the desktop with better performance then a cirrus card). 3D is not really an option and you can also live without compositing. Gaming is not even allowed in dreams. This will not change anytime soon.

As of right now i know a lot of people that use the open source driver to play 3D games. They might not be the game released this year but many not so old game run (wow, various fps, ...) and have strong community.

And be sure to understand: the problem is the open source radeon team is only 5 full time developers. If AMD is not going to change this, AMD hardware will keep being a mess. And the legal team is not really helping either.

There is lot contribution from the community on the AMD driver. The sad thing is that the community is not bigger. It seems that GPU driver development is not as sexy as other open source project.

[bridgman]

3D engine is used for 2D acceleration in radeonsi (Radeon HD7000 series and newer). So, it's not that straightforward.

Right... that has actually been the case since r600 -- r5xx and rs690/740 were the last parts with 2D acceleration hardware.

We need to write "most of a 3D driver" in order to get anything more than the most trivial 2D acceleration on the newer parts. What we did from r600 through NI was write code to accelerate 2D operations on the 3D engine in the X driver, and "similar but different" code to accelerate 3D operations on the 3D engine in the Mesa driver.

For SI, we started using glamor to perform 2D operations on the 3D engine using the 3D driver, rather than a separate "2D on 3D HW" driver.

[bridgman]

It seems to me AMD's intend for the opensource driver is to provide support for its APUs primarily. The next APU from AMD will be RadeonSI (HD7000 or HD8000 i don't know which) and by the time this will reach general availability most distros will be on MESA 10.0 or at least 9.1 .

Another reason i think this applies is because performance doesn't scale well to high end GPU's. The best Open-to-fglrx ratio is on lower end GPUs, so it seems to me AMD doesn't care to improve the higher versions.

It's probably fair to say that the normal course of open source driver development initially favours the mid-range GPUs (and I have made recommendations along those lines to people thinking about new HW), but I don't think we are favouring any particular hardware other than shuffling priorities as needed to make sure we have launch-time support for APUs.

What is really happening IMO is :

- without a lot of performance work to optimize drawing paths, the overhead to prepare and pin memory buffers (eg vertex buffers and textures), submit commands to the GPU and get the results back to the application limits the potential framerate no matter how powerful the GPU is (this is why high end parts don't seem to be loved as much)

- without a lot of performance work to optimize use of memory bandwidth, the entry level cards with narrow/slow memory buses are most affected by memory bottlenecks (this is why low end parts don't seem to be loved as much)

- midrange parts have a smaller gfx core so the gfx engine comes closer to maxing out before the drawing path delays become the bottleneck, and enough memory bandwidth to keep the gfx engine running at decent speed without insane memory optimizations

BTW it's probably obvious from the comments above, but a fair amount of the optimization work in the proprietary drivers is in two areas :

1. Feeding a massive stream of data into the GPU in order to keep the drawing engines of high end GPUs running at full speed
2. Optimizing the heck out of narrow/slow memory buses in order to get decent performance from entry level cards

The third one used to be shader compiler optimizations to make best use of VLIW hardware, but with the transition to GCN architecture that requirement is much reduced although there is still a need to efficiently interleave scalar and SIMD operations.