Announcement

Collapse
No announcement yet.

Luc Modularizes Mesa, DRI Drivers

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

  • #16
    Originally posted by mattst88 View Post
    Luc,

    For X server 1.9, the tentative plan is to merge the device-dependent drivers back into the X server.

    Your work here on Mesa seems to be doing the opposite.

    So, do you disagree with the move to merge the DDXs into the X server? If so, please explain.

    If not, how is the situation with DDX/X server sufficiently different from Mesa to warrant this move in the opposite direction?
    Moving drivers back into the X server is the single worst thing that people can do at this point.

    Ask yourself, what good does this move bring that isn't already fully provided for by the tinderbox?

    The graphics driver developers who want this just want to be lazy, and just want to be more free to break the APIs in a bad and untrackable way.

    People believe that the kernel model works for hardware as complicated and volatile as graphics hardware, but time will tell differently.

    Comment


    • #17
      SDK capable mesa tree now available!

      at http://cgit.freedesktop.org/~libv/mesa-dri-sdk/

      I am still working on a README, and will make more noise once i have had some shut-eye.

      For the adventurous, here is the quick summary:
      * pick versions that are very close to your current mesa version (libGL needs to match)
      > ./autogen.sh [maybe want to add --prefix=/usr/]
      > make dri-sdk
      > make dri-sdk-install

      Then you can build, install and run your dri driver.

      Comment


      • #18
        Originally posted by libv View Post
        at http://cgit.freedesktop.org/~libv/mesa-dri-sdk/

        I am still working on a README, and will make more noise once i have had some shut-eye.

        For the adventurous, here is the quick summary:
        * pick versions that are very close to your current mesa version (libGL needs to match)
        > ./autogen.sh [maybe want to add --prefix=/usr/]
        > make dri-sdk
        > make dri-sdk-install

        Then you can build, install and run your dri driver.
        README: http://people.freedesktop.org/~libv/dri-sdk.txt

        Comment


        • #19
          Originally posted by libv View Post
          Well, forking is not my style and something like that does not succeed on its own, especially not for technical reasons. Forks are mostly only about politics and people trying to protect or enlarge their power-base outside of technical advancement.

          About not liking something, and/or not liking the general direction of things, and then coding up how they should be... I have done that many times before. And several of those have turned out to be real winners, even though the people who get proven wrong in such a case, are usually not very sportive about it. This means that credit is then not given where credit is due, and this is where the whole meritocracy thing breaks down, as the next time round, the same story has to be played all over again, in pretty much the same way, with a sizable waste of resources as a consequence.
          Tell me the story of radeonhd again? :P

          Originally posted by libv View Post
          About ctrl-alt-bcksp... I miss that too (i know, it's only off per default). It's like the X stipple and the VGA text console. When you see the stipple, you know that your driver code is not horribly broken. When it is horribly broken, you might still have ctrl-alt-backspace, which then hopefully gives you the VGA console again. If you see the VGA console again, you get to play again... All 3 are happily tied together for a graphics driver developer
          We figured that graphics drivers were probably going to be able to work out -retro, or have an alias or something. I admit it's not ideal though; we could do something like display the root weave in everything but RC/stable tarballs?

          Comment


          • #20
            Originally posted by libv View Post
            Moving drivers back into the X server is the single worst thing that people can do at this point.

            Ask yourself, what good does this move bring that isn't already fully provided for by the tinderbox?

            The graphics driver developers who want this just want to be lazy, and just want to be more free to break the APIs in a bad and untrackable way.

            People believe that the kernel model works for hardware as complicated and volatile as graphics hardware, but time will tell differently.
            'API' implies some vague sort of design. $(includedir)/xorg is many things, but not designed. The idea is to basically incrementally create useful APIs that everyone can use without too much pain. You should know this, having written a Screen(Pre)Init before ...

            Comment


            • #21
              Great job Luc!! Everyone's making fantastic progress but I hope it gets further along to provide a nice soft warm place for windows converts to land. Everyone was trying to jump ship in the fedora 10/ubuntu 9.04 days. Let's just hope this gets done well on this next round of releases as it will mean millions of users. I'm already seeing large groups of linux users on the net which is unheard of 2 years ago.

              Comment


              • #22
                Originally posted by daniels View Post
                Tell me the story of radeonhd again? :P
                RadeonHD started afresh late july 2007. We were not at liberty to discuss anything with the outside world (while those who imposed that limitation on us happily did so all the time).

                We discussed basing our work on top of avivo, but avivo was GPL-ed, and we were unable to get that to change (and i am not sure whether, at the time, you would have at all been willing to change that when we came a-knocking). Avivo did relatively little as well, so we soon progressed to a point where we overshot avivo functionality (not hard when spending worktime on it and when the hardware is available).

                GPL was the main reason why avivo became just one of many levers that made AMD decide to open source things. But it was a more significant one than some other people thought they were (judging from the claims they made shortly after the announcements/releases from september 2007).

                Originally posted by daniels View Post
                We figured that graphics drivers were probably going to be able to work out -retro, or have an alias or something. I admit it's not ideal though; we could do something like display the root weave in everything but RC/stable tarballs?
                Yeah, that sounds like a plan. Although i still do not understand why the root weave had to go to begin with. It is all about delaying the unblanking of the displays, and it shouldn't be impossible to delay thsi unblanking a bit further than is/was the case.

                If nothing is running on top, you then get a rootweave. If anything is running on top, you get to see what it is, without seeing the rootweave or the crapped up/old framebuffer content in between.

                Comment


                • #23
                  Originally posted by daniels View Post
                  'API' implies some vague sort of design. $(includedir)/xorg is many things, but not designed. The idea is to basically incrementally create useful APIs that everyone can use without too much pain. You should know this, having written a Screen(Pre)Init before ...
                  Again, what does one gain from moving drivers back into the xserver that one doesn't gain from a tinderbox? I do not see it.

                  Current slightly more distributed model does not impede such things either, it just is a slight bit more hassle, and therefor (and only therefor) requires the developer to think a bit further about the changes he is about to make (although it hasn't stopped anyone from breaking things horribly in the past).

                  My analysis: people just do not want to do this tiny bit of extra thinking.

                  Comment


                  • #24
                    Originally posted by Hephasteus View Post
                    Great job Luc!! Everyone's making fantastic progress but I hope it gets further along to provide a nice soft warm place for windows converts to land. Everyone was trying to jump ship in the fedora 10/ubuntu 9.04 days. Let's just hope this gets done well on this next round of releases as it will mean millions of users. I'm already seeing large groups of linux users on the net which is unheard of 2 years ago.
                    Well, it is not just about windows users. It will also lure more people away from closed source drivers, as those closed source drivers are simply easier to procure and install. And, it will also make it easier for those who have used open source drivers before, who before were forced to update part of their installation or just dist-upgrade.

                    Imagine how many more people will be installing, testing and using the latest graphics driver bits when this process is made easy.

                    Comment


                    • #25
                      Originally posted by libv View Post
                      RadeonHD started afresh late july 2007. We were not at liberty to discuss anything with the outside world (while those who imposed that limitation on us happily did so all the time).

                      We discussed basing our work on top of avivo, but avivo was GPL-ed, and we were unable to get that to change (and i am not sure whether, at the time, you would have at all been willing to change that when we came a-knocking). Avivo did relatively little as well, so we soon progressed to a point where we overshot avivo functionality (not hard when spending worktime on it and when the hardware is available).

                      GPL was the main reason why avivo became just one of many levers that made AMD decide to open source things. But it was a more significant one than some other people thought they were (judging from the claims they made shortly after the announcements/releases from september 2007).
                      You never asked about the license. The -radeon guys did, and we agreed to license the bit of code they asked for under MIT/X11.

                      Comment


                      • #26
                        Originally posted by daniels View Post
                        You never asked about the license. The -radeon guys did, and we agreed to license the bit of code they asked for under MIT/X11.
                        As said, we were not allowed to talk to anyone about this. We even had a major incident where one of the SUSE guys posted a news item over ATIs plans in late august, and in the end that turned out to be a leak from inside AMD/ATI. Heck, if Michael hadn't posted his article ahead of the latest schedule change (as no-one informed him about the change in plans), we might still be waiting for that announcement.

                        And it has to be said, I am not too certain how you would have responded when asked in July 2007 by the SUSE people, before the big event, as opposed to afterwards, when asked by Redhat and ATI.

                        Comment


                        • #27
                          Thank you luc.

                          From the diagrams on your fosdem slides it's obvious -even for a non-programmer like myself- that the linux graphics stack can use some improvements, and it's great to see someone doing something about it.

                          Comment

                          Working...
                          X