Announcement

Collapse
No announcement yet.

AMD Has Open-Source Driver For HD 8000 Series

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Originally posted by Hamish Wilson View Post
    Well, as the article says, you could use a Radeon 7x50 card on Linux from day one thanks to Catalyst (just pointing this out as your wording did call for it). As for the free driver support, I am not sure. I doubt it would work properly with Ubuntu 12.04 though.
    My question was about the OSS driver of course. No need to update mesa for Catalyst from git, I think.

    Comment


    • #17
      Originally posted by Asariati View Post
      My question was about the OSS driver of course. No need to update mesa for Catalyst from git, I think.
      You could probably get the latest mesa etc from git(or PPA) on Ubuntu 12.04 was well, if you are to go down that path.

      Comment


      • #18
        From the article:

        [...] with the new "RadeonSI" Gallium3D driver it's been very slow to develop. Basic OpenGL demos will run on the HD 7000 series hardware, but not much more [...]
        Michael, will you please stop repeating this lie?

        OpenGL 2.1 functionality is shaping up pretty nicely in radeonsi for the Mesa 9.1 release. Over the last couple of days, I've tested games such as Open Arena, Red Eclipse, Tremulous, Nexuiz (with a pending LLVM R600 backend fix) and many more, and we're approaching 95% pass rate for piglit.

        If you have trouble reproducing these results, please ask on the mailing lists or on IRC. The normal support channels are open to you just like anyone else, you know.

        Comment


        • #19
          Originally posted by MrCooper View Post
          From the article:



          Michael, will you please stop repeating this lie?

          OpenGL 2.1 functionality is shaping up pretty nicely in radeonsi for the Mesa 9.1 release. Over the last couple of days, I've tested games such as Open Arena, Red Eclipse, Tremulous, Nexuiz (with a pending LLVM R600 backend fix) and many more, and we're approaching 95% pass rate for piglit.

          If you have trouble reproducing these results, please ask on the mailing lists or on IRC. The normal support channels are open to you just like anyone else, you know.
          How do you estimate performance levels? Is LLVM shader compiler enables you to approach performance of fgrlx?

          Comment


          • #20
            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.

            Comment


            • #21
              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?

              Comment


              • #22
                Originally posted by Veerappan View Post
                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

                Comment


                • #23
                  Originally posted by archibald View Post
                  how can we (the community) ask for more?
                  http://en.wikipedia.org/wiki/AK-47

                  Comment


                  • #24
                    Originally posted by ChrisXY View Post
                    No, it's not in git master of git://anongit.freedesktop.org/mesa/demos
                    *could have been an edit:
                    Even better
                    Code:
                    $ 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:

                    Comment


                    • #25
                      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.

                      Comment


                      • #26
                        Originally posted by enrico.tagliavini View Post
                        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.

                        Comment


                        • #27
                          Originally posted by enrico.tagliavini View Post
                          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.

                          Originally posted by enrico.tagliavini View Post
                          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.

                          Comment


                          • #28
                            Originally posted by fa5hion View Post
                            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.
                            Last edited by bridgman; 02-06-2013, 12:40 PM.

                            Comment


                            • #29
                              Originally posted by TemplarGR View Post
                              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.
                              Last edited by bridgman; 02-06-2013, 01:15 PM.

                              Comment


                              • #30
                                Originally posted by enrico.tagliavini View Post
                                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.
                                I must be dreaming then - I game on R600g all the time. And run composted desktops on it. Have you ever actually used it for these purposes or are you just going on accusations or here-say? It may not have the most performant 3D, but it works and it is stable, even on RadeonSI it now appears. And I do not think I am abusing the local power grid by using it, although I do admit the manual power-save modes are working really well for me for whatever reason.

                                I would say the main reason for the free radeon drivers, if you want to give them some specific technical objective, is to have a mainline kernel driver for the cards that offer out of the box support and better legacy compatibility. Mode setting and 2D are of course a part of this, but that does not minimize the other work.
                                Last edited by Hamish Wilson; 02-06-2013, 01:07 PM.

                                Comment

                                Working...
                                X