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 Olk, 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...

    http://www.phoronix.com/vr.php?view=OTU2OQ

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

                    Comment


                    • #11
                      G3D is supposed to be a cross OS solution to the graphics problem. How come its so dependent on linux stuff that need to be ported on other OSes???






                      ps
                      someone must give marek a big lump of money

                      Comment


                      • #12
                        Originally posted by bridgman View Post
                        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.
                        Indeed, and I don't blame corporations for not wanting to invest engineers in doing the work. I won't deny that BSD has its adherents, and they might have a valid point when it comes to server-based work, but for clients with rich 3d and such, BSD wouldn't be my first choice, especially if you're looking for free drivers (nvidia blob is supported on FreeBSD afaik, so you've at least got that).

                        To change the situation, some company (or extremely motivated volunteer) would have to take the work upon themselves. I don't see it getting done otherwise. And with Linux's open source graphics stack shaping up so well, they have a free software competitor, making it even less likely that there will necessarily be a second (especially if their goal is to "play catchup" with Linux; if they plan to do something radically new and better, that might be a different story.)

                        Comment


                        • #13
                          Originally posted by 89c51 View Post
                          G3D is supposed to be a cross OS solution to the graphics problem. How come its so dependent on linux stuff that need to be ported on other OSes???

                          The state trackers in G3D are cross platform, the rest is not. There is a whole winsys layer defined in gallium that hooks into the native OS calls.

                          The (correct) way of accessing actual hardware is to do it in the kernel, and every kernel is different. You can come up with a big compatibility layer that your kernel driver sits in, like the nvidia and fglrx drivers do, but that's a fair amount of work to do which not many are really interested in. The main bits that have to be implemented within the kernel itself are the memory manager - the GEM and TTM APIs. Once they are provided, the rest of the kernel drivers should be pretty simple to port over.

                          Comment


                          • #14
                            Originally posted by smitty3268 View Post
                            The state trackers in G3D are cross platform, the rest is not. There is a whole winsys layer defined in gallium that hooks into the native OS calls.

                            The (correct) way of accessing actual hardware is to do it in the kernel, and every kernel is different. You can come up with a big compatibility layer that your kernel driver sits in, like the nvidia and fglrx drivers do, but that's a fair amount of work to do which not many are really interested in. The main bits that have to be implemented within the kernel itself are the memory manager - the GEM and TTM APIs. Once they are provided, the rest of the kernel drivers should be pretty simple to port over.
                            thanks

                            the question is more about why it can't use the OS native memory manager and requires GEM TTM or whatever linux tech. is it just easier to port those instead of adapting the native ones???

                            Comment


                            • #15
                              Originally posted by allquixotic
                              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.
                              Originally posted by plombo
                              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.
                              Originally posted by bridgman
                              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.
                              Originally posted by allquixotic View Post
                              Indeed, and I don't blame corpor
                              "Indeed"? Indeed what? Indeed your cheap shot at BSD was unfounded?

                              Comment

                              Working...
                              X