Announcement

Collapse
No announcement yet.

AMD Has Open-Source Driver For HD 8000 Series

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

  • #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; 06 February 2013, 01:40 PM.
                  Test signature

                  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; 06 February 2013, 02:15 PM.
                    Test signature

                    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; 06 February 2013, 02:07 PM.

                      Comment

                      Working...
                      X