Announcement

Collapse
No announcement yet.

R600 Gallium3D Driver Is Now Built By Default

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

  • R600 Gallium3D Driver Is Now Built By Default

    Phoronix: R600 Gallium3D Driver Is Now Built By Default

    Marek Ol??k, the open-source community developer known for his contributions to Mesa / Gallium3D and to the Radeon driver in particular, has submitted a set of patches to the Mesa mailing list. This time around, these patches overhaul the Gallium3D configure/build-time options. These patches are meant to make it easier to configure Gallium3D with the Gallium3D EGL support and in automatically determining what state trackers to build. In addition, there is one prominent change in default behavior...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    It's high time to nuke r300c/r600c from the repositories altogether. All the effort put into them is appreciated, and they served their purpose, but they are just a maintenance burden now.

    They will stay in the git history regardless, so it's not like the code will go away. Nuking stuff in a version-controlled world is a pretty safe operation.

    Intel made a similar move when they pared down all the legacy support for UMS, EXA, XAA, etc. in the intel driver stack. If it hasn't been done, UMS and XAA support in radeon should also be removed. Just keep the path that's known to work and actively being worked on: KMS + GEM/TTM + DRI2 + EXA + r600g.

    Comment


    • #3
      Now we just need Intel to make the switch. Then we can ditch the classic architecture completely.

      Comment


      • #4
        Originally posted by allquixotic View Post
        It's high time to nuke r300c/r600c from the repositories altogether. All the effort put into them is appreciated, and they served their purpose, but they are just a maintenance burden now.

        They will stay in the git history regardless, so it's not like the code will go away. Nuking stuff in a version-controlled world is a pretty safe operation.

        Intel made a similar move when they pared down all the legacy support for UMS, EXA, XAA, etc. in the intel driver stack. If it hasn't been done, UMS and XAA support in radeon should also be removed. Just keep the path that's known to work and actively being worked on: KMS + GEM/TTM + DRI2 + EXA + r600g.
        I tend to agree, especially since the classic drivers aren't supported much anymore. r300c bugs, at least, have been closed with the response that the user should switch to the gallium driver. It sucks that the BSDs can't run them yet, but at some point you've just got to cut your losses and move on in order to make progress.

        Comment


        • #5
          Originally posted by smitty3268 View Post
          I tend to agree, especially since the classic drivers aren't supported much anymore. r300c bugs, at least, have been closed with the response that the user should switch to the gallium driver. It sucks that the BSDs can't run them yet, but at some point you've just got to cut your losses and move on in order to make progress.
          Any other non-Linux kernels wanting to use Mesa + Xorg should seriously consider implementing the kernel-side of the house that it depends on. I know there's work going on in some variants of BSD to do that, but obviously since their platform has considerably lower adoption in desktop circles than Linux, they have less interest and correspondingly fewer developers and testers.

          Mesa is user-space software that just so happens to depend on a fairly particular kernel-space implementation, but nothing's stopping anyone from implementing the KMS+GEM+TTM+DRM bits that it needs.

          Comment


          • #6
            Originally posted by allquixotic View Post
            Any other non-Linux kernels wanting to use Mesa + Xorg should seriously consider implementing the kernel-side of the house that it depends on. I know there's work going on in some variants of BSD to do that, but obviously since their platform has considerably lower adoption in desktop circles than Linux, they have less interest and correspondingly fewer developers and testers.

            Mesa is user-space software that just so happens to depend on a fairly particular kernel-space implementation, but nothing's stopping anyone from implementing the KMS+GEM+TTM+DRM bits that it needs.
            Implementing the kernel-side graphics stack in other kernels is so much work that no one wants to do it.

            Comment


            • #7
              Originally posted by Plombo View Post
              Implementing the kernel-side graphics stack in other kernels is so much work that no one wants to do it.
              Well, the alternative is implementing and maintaining the entire graphics stack. Or at least it will be when r300c and r600c get dropped.

              Comment


              • #8
                Originally posted by Plombo View Post
                Implementing the kernel-side graphics stack in other kernels is so much work that no one wants to do it.
                Well, if they'd just use a GPLv2-compatible license, they could use the Linux kernel sources as a reference, and maybe even copy and paste large swaths of code and just adapt the kernel API calls as appropriate to the local dogma.

                But aside from that, there are plenty of docs out there that you can use to work on a clean-room implementation of the kernel side. There should be a lot of motivation to do that, considering that as soon as you implement the kernel side of the DRI2 / DRM calls coming out of Mesa, you basically get an OpenGL 2.1 implementation for free.

                Comment


                • #9
                  Originally posted by allquixotic View Post
                  Well, if they'd just use a GPLv2-compatible license, they could use the Linux kernel sources as a reference, and maybe even copy and paste large swaths of code and just adapt the kernel API calls as appropriate to the local dogma.

                  But aside from that, there are plenty of docs out there that you can use to work on a clean-room implementation of the kernel side. There should be a lot of motivation to do that, considering that as soon as you implement the kernel side of the DRI2 / DRM calls coming out of Mesa, you basically get an OpenGL 2.1 implementation for free.
                  Unlike most of the Linux kernel, the kernel DRM sources are licensed under an MIT/X11 license, which is compatible with the BSD licenses. Even with that, porting all of it to BSD is a task that would take several months.

                  Comment


                  • #10
                    Originally posted by allquixotic View Post
                    Well, if they'd just use a GPLv2-compatible license, they could use the Linux kernel sources as a reference, and maybe even copy and paste large swaths of code and just adapt the kernel API calls as appropriate to the local dogma.

                    But aside from that, there are plenty of docs out there that you can use to work on a clean-room implementation of the kernel side. There should be a lot of motivation to do that, considering that as soon as you implement the kernel side of the DRI2 / DRM calls coming out of Mesa, you basically get an OpenGL 2.1 implementation for free.
                    As plombo said, the graphics driver stack is X11 licensed in order to be license-compatible with a wide range of OSes, so there are no license problems. The issue as I understand it is that the OS memory management mechanisms are significantly different between Linux and BSD, so porting the new (and more complex) GEM/TTM graphics memory manager to an OS with a different memory management model is a fair chunk of work.
                    Test signature

                    Comment

                    Working...
                    X