Announcement

Collapse
No announcement yet.

Luc Calls For A Dead Linux Desktop If Keith Gets His Way

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

  • #31
    *rant* *rant* Can somebody of phonorix please change the title from 'Luc Calls For' to 'Luc Warns For'. Please don't put up such nonsense titles again phonorix.

    Comment


    • #32
      noob question (you have been warned )

      does moving the drivers in X affects projects like wayland??

      Comment


      • #33
        Originally posted by Xanbreon View Post
        What I don't understand is why everything gets pushed into the mainline kernel. This leaves you having to update the kernel to update the graphics bits. Wouldn't it be easier just to build everything as Kernel Modules?

        Thats one of the things I like about using the nVidia blob, I don't have to worry that if i upgrade my kernel im going to have to rebuild half my x server to keep the userspace bites in lockstep with the kernel stuff.

        Does KMS *need* to be in the kernel, would it not work if it was a loadable module? Eg, you could have a package called KMS that had the bits needed for KMS built into a loadable module. Or do i really not understand the problem?
        You understand fine; the distinction is between "what is possible" and "what most people do these days". The kernel graphics driver can still be built as a separate module... it's just that since the source code was merged into the kernel tree relatively more people pick up an entire new kernel.

        That behaviour is arguably part of the whole discussion here - the X developers are hoping that relatively more people will pick up the entire X+drivers stack and thereby test all the bits rather than just the one they wanted (that's the upside) but the downside is the risk that fewer people will pick up the newer drivers until the entire X+driver set is released (and it becomes too late to fix bugs in that release), which would arguably be worse from a testing perspective than the current situation.

        I guess there are really three options, and I'm not sure what is currently being proposed :

        - current state (drivers and X in separate projects, changed separately and built separately)
        - intermediate state (drivers and X in one tree, can be changed together, retain ability to build & use separately)
        - full integration (drivers and X in one tree, can be changed together, can only be built together)

        My recollection is that the proposed change is actually the intermediate state where individual drivers can be built independently, and so can be updated independently as long as API/ABI changes don't render the new driver incompatible with the current X. The "definite" downside of the intermediate state relative to today is that you need to download source for the entire X+driver stack even if you only want to build one driver; the "feared" downside is that developers will make so many API/ABI changes that the ability to build and use a single driver will practically disappear because the new driver would only rarely be compatible with the current X.

        Comment


        • #34
          Originally posted by Xanbreon View Post
          Does KMS *need* to be in the kernel, would it not work if it was a loadable module?
          This isn't about that. I had to read this quite a few times to figure out what this is about exactly. I'm still not quite sure.
          If I'm right, there's two things here
          1) Moving DRM development out of DRM branch into kernel tree. Luc opposed this but it's more of a historical thing, doing anything about it anymore would be painful even if anyone would want to. It has arguments for it and against it anyhow.
          2) Moving modular X.org video drivers (in KMS world we're talking about dumb drivers that just rely on DRM for modesetting and acceleration) into the actual X server. As far as I can see, this would mean that
          X-server<->ddx<->libdrm<->DRM would be simplified into X-server<->libdrm<->DRM. This would mean one less place where API/ABI can break, however, it would also mean X-server and libdrm would be tightly bound into each other. Personally I'd prefer concentrating work on getting the generic ddx in Gallium to work and moving thus moving into
          X-server<->Gallium<->libdrm<->DRM for everything. I think it might lead to significant wins in terms of removed duplicate code as well. This would also allow nVidia and fglrx to use whatever interface there is between X-server and Gallium for the generic ddx (note, I'm not saying they should use Gallium) so we wouldn't lose functionality. Of course, Intel wouldn't agree because they don't want to use Gallium.

          Comment


          • #35
            In a nutshell, my alternative approach would simplify things for those who want to play this together and allow everyone else to keep doing things just like they've been doing them before.

            Comment


            • #36
              Originally posted by bridgman View Post
              You understand fine; the distinction is between "what is possible" and "what most people do these days". The kernel graphics driver can still be built as a separate module... it's just that since the source code was merged into the kernel tree relatively more people pick up an entire new kernel.

              That behaviour is arguably part of the whole discussion here - the X developers are hoping that relatively more people will pick up the entire X+drivers stack and thereby test all the bits rather than just the one they wanted (that's the upside) but the downside is the risk that fewer people will pick up the newer drivers until the entire X+driver set is released (and it becomes too late to fix bugs in that release), which would arguably be worse from a testing perspective than the current situation.

              I guess there are really three options, and I'm not sure what is currently being proposed :

              - current state (drivers and X in separate projects, changed separately and built separately)
              - intermediate state (drivers and X in one tree, can be changed together, retain ability to build & use separately)
              - full integration (drivers and X in one tree, can be changed together, can only be built together)

              My recollection is that the proposed change is actually the intermediate state where individual drivers can be built independently, and so can be updated independently as long as API/ABI changes don't render the new driver incompatible with the current X. The "definite" downside of the intermediate state relative to today is that you need to download source for the entire X+driver stack even if you only want to build one driver; the "feared" downside is that developers will make so many API/ABI changes that the ability to build and use a single driver will practically disappear because the new driver would only rarely be compatible with the current X.
              Thanks for that! If and when I can use the OSS drivers (I need high performance OpenGL for many reasons) I dont think I would want to have to rebuild the whole graphics stack just to pick up an updated driver.

              I suppose xorg is the part of linux I am most afraid of breaking, if the worst comes to the worst and i build a new kernel that doesnt boot, no harm no foul, I reboot with one of the other i have installed, with xorg I might have to spend god knows how long purging configs and removing/reinstalling bits.

              If the drivers where they own, upgrading one wouldn't be as scary, you just remove/reinstall one part without to much fuss.

              Wouldn't it be more sain to have a stable API, where only new API calls where added, and only ones where depreciated after being marked as such for a long time.

              Im not a dev, but out of all things linux, the graphics stack seems to be the part in most need of some love (if you ignore PA, but thats a rant for another time).

              Comment


              • #37
                Originally posted by bridgman View Post
                You understand fine; the distinction is between "what is possible" and "what most people do these days". The kernel graphics driver can still be built as a separate module... it's just that since the source code was merged into the kernel tree relatively more people pick up an entire new kernel.
                Nope. The kernel graphics driver can not be built as a separate out-of-tree module anymore. It could in the past, but after moving in-kernel, the out-of-tree version was dropped.

                Comment


                • #38
                  Originally posted by RealNC View Post
                  AFAIK, it does not replace large parts of X (or any parts of anything.)
                  It replaces all of Mesa (much of which is shared now), all of kernel drm (much of it is shared now) and the bottom half of the X stack, and everything related to direct rendering, all of which is shared now. Also it replaces all of Gallium3d, which also has lots of shared code.

                  A binary blob is a drop-in replacement for Kernel DRM, bottom part of X, DRI, Mesa, Gallium3d and DDX. All of it closed source and working only on one certain manufacturer's hardware.

                  The Nvidia binary blob, for example, has more source code than the Linux kernel, and is several times larger when compiled.

                  Comment


                  • #39
                    EDIT: Obviously, the open-source way, and the goal of all open source developers is to share code where possible, and not reinvent the wheel.

                    The only question is whether it's easier to do bundled with X or not.

                    Comment


                    • #40
                      Originally posted by RealNC View Post
                      Nope. The kernel graphics driver can not be built as a separate out-of-tree module anymore. It could in the past, but after moving in-kernel, the out-of-tree version was dropped.
                      I believe that it's still possible to check out the drm part of the kernel and compile it as a module to run with your kernel.

                      The problem is that the binary compatibility breaks more often nowadays, so there's not guarantee that it will work.

                      Comment


                      • #41
                        Even in the past it relied on a macro Hell to work.

                        Comment


                        • #42
                          Originally posted by Xanbreon View Post
                          I suppose xorg is the part of linux I am most afraid of breaking, if the worst comes to the worst and i build a new kernel that doesnt boot, no harm no foul, I reboot with one of the other i have installed, with xorg I might have to spend god knows how long purging configs and removing/reinstalling bits.

                          If the drivers where they own, upgrading one wouldn't be as scary, you just remove/reinstall one part without to much fuss.
                          I don't quite understand the implications of what's being discussed, and reading Luc's blog post leaves me scratching my head. But if this is about having a fat X server that includes everything and users (regular mortals as well as distributions) are forced to rebuild the whole lot to pick up some changes, it doesn't sound very appealing.

                          As it is now, anybody with half a clue can try new drivers easily, relying on the compatibility with the X server provided by the distribution. Asking users/testers to go through the complications of building the server will lower the number of people willing to play around. And I agree with you, X looks really ugly and hairy, and it contains 2 of the last things you'd like to see broken: input and display. It is bad enough that at times you have to update to a new kernel on top of building mesa, drm and 2d drivers. As a mere user, I know I wouldn't go the extra mile of compiling X.

                          Also, would this have a negative effect on the way distributions are currently able to cherry pick fixes or improvements without updating the whole stuff (and thus avoiding hardly tested code)?

                          Comment


                          • #43
                            Originally posted by pingufunkybeat View Post
                            I believe that it's still possible to check out the drm part of the kernel and compile it as a module to run with your kernel.

                            The problem is that the binary compatibility breaks more often nowadays, so there's not guarantee that it will work.
                            Which is what I'm talking about. The out-of-tree version could be build with several kernels. The in-kernel version is really only for the kernel it's embedded in.

                            Comment


                            • #44
                              Originally posted by pingufunkybeat View Post
                              It replaces all of Mesa (much of which is shared now)
                              Mesa is not part of X actually; It's an OpenGL implementation, and as such it's only one among several. There's nothing wrong with offering your own GL implementation.


                              all of kernel drm (much of it is shared now)
                              It's a driver, what did you expect :P It's like saying the ATI DRM replaces the Intel DRM...


                              and the bottom half of the X stack, and everything related to direct rendering, all of which is shared now.
                              Dunno about that. By reading Phoronix through the years I was under the impression that fglrx does not do that, only the NVidia blob does.

                              Also it replaces all of Gallium3d, which also has lots of shared code.
                              Now you lost me completely. How does it replace Gallium3D if it doesn't even need it? (Btw, I don't even have Gallium3D installed and am using the open drivers currently, so what's there to replace anyway?)

                              Comment


                              • #45
                                Originally posted by RealNC View Post
                                Mesa is not part of X actually; It's an OpenGL implementation, and as such it's only one among several. There's nothing wrong with offering your own GL implementation.
                                Sure.

                                But this is clearly not what an open source driver should do, as long as there is an existing implementation in Mesa. Open drivers should use Mesa, and not bundle their own GL implementation.

                                It's a driver, what did you expect :P It's like saying the ATI DRM replaces the Intel DRM...
                                Parts of it are shared, part card-specific, as far as I understand. All the drivers use a standard interface (based on GEM) to communicate with the kernel. Binary blobs bypass all of that.

                                Now you lost me completely. How does it replace Gallium3D if it doesn't even need it? (Btw, I don't even have Gallium3D installed and am using the open drivers currently, so what's there to replace anyway?)
                                You don't need Gallium3d if you use classic Mesa drivers (I don't ATM), but this is what all the drivers are migrating towards.

                                And the nvidia and ati binary drivers do pretty much exactly the same thing Gallium3d does internally. An intermediate representation which allows them to share large parts of the OpenGL code and acceleration infrastructure etc. etc.

                                Comment

                                Working...
                                X