Announcement

Collapse
No announcement yet.

GNOME Shell Now Works With Software Rendering!

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

  • GNOME Shell Now Works With Software Rendering!

    Phoronix: GNOME Shell Now Works With Software Rendering!

    There's some great news today: it's now possible to run the GNOME Shell with Mutter but not having to rely upon any GPU hardware driver! Software rendering is now working with GNOME Shell rather than any fall-back thanks to improvements with Gallium3D's LLVMpipe...

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

  • #2
    Just in case anyone is wondering (or worrying) about the future of the traditional Fallback:

    Fallback mode will still be around for a while, and if software rendering does not work out, or only works under certain circumstances, we will adapt the blacklisting mechanism that is currently used for fallback mode to only try the full experience when it has a chance of success, and continue to fall back to fallback mode in problematic cases.
    https://fedoraproject.org/wiki/Featu...ntingency_Plan

    Comment


    • #3
      I wonder if there is anything that could be done at the network level (such as with NoMachine's NX protocol) to further improve the performance when trying to use gnome shell over the public internet?

      I think the most efficient thing to do would be to have the 3d rendering with llvmpipe done on the server with an up-to-date CPU (first-gen Nehalem or newer) and then have the NX protocol figure out an efficient way to send the rendered objects to the proxy X server on the client side.

      This could really get rather complicated; the X proxy on the client-side may end up implementing more parts of the X.org wire protocols in order to robustly support compositing. The key will be to "intelligently" inform the client of what the data is and what transformations are made, so that the *client* can do some of the transformations itself. That's what makes the NX protocol so efficient as it is: you can drag around a window on a 2D desktop with NX at near-native speed over the public Internet, because your *client* is doing much of the calculation for the rendering itself, because it knows about the X protocol, and it caches pixmaps and such. It's not just another remote framebuffer.

      Then again, if we can have 3d rendering done server-side and somehow efficiently transfer the results to the client, then it would be possible (eventually, with innovations in NX) to have dedicated GPU hardware do GPU-intensive tasks on a mainframe-like server, and transmit the results over a network (say, a WiFi LAN) to a much less beefy, more mobile device, such as a tablet.

      So you'd have your tablet on your desk in a meeting doing apparently amazing, computationally-intensive real-time 3d rendering, but the actual legwork would be done on the server.

      I'm sure projects like these are all over the place in academia and industry now that tablets are becoming mainstream, and general-purpose GPUs are becoming popular workhorses in business.

      I'm just waiting for the likes of Red Hat or GNOME to come up with something similar for general purpose free desktop usage, rather than settling with the first proprietary vendor to actually market something like this and make it easy to use.

      Anyway, I'm way off the topic of llvmpipe doing software gnome-shell, so yay for that. I'm sure that people running high-end servers with no GPU will appreciate being able to run g-s on the local console (or in the KVM-over-IP framebuffer, or whatever) for those times when you just have to use a graphical program.

      Comment


      • #4
        LLVMpipe still isn't fast enough for many OpenGL games..
        Nor should it be.

        Comment


        • #5
          Originally posted by allquixotic View Post
          I wonder if there is anything that could be done at the network level (such as with NoMachine's NX protocol) to further improve the performance when trying to use gnome shell over the public internet?

          I think the most efficient thing to do would be to have the 3d rendering with llvmpipe done on the server with an up-to-date CPU (first-gen Nehalem or newer) and then have the NX protocol figure out an efficient way to send the rendered objects to the proxy X server on the client side.

          This could really get rather complicated; the X proxy on the client-side may end up implementing more parts of the X.org wire protocols in order to robustly support compositing. The key will be to "intelligently" inform the client of what the data is and what transformations are made, so that the *client* can do some of the transformations itself. That's what makes the NX protocol so efficient as it is: you can drag around a window on a 2D desktop with NX at near-native speed over the public Internet, because your *client* is doing much of the calculation for the rendering itself, because it knows about the X protocol, and it caches pixmaps and such. It's not just another remote framebuffer.

          Then again, if we can have 3d rendering done server-side and somehow efficiently transfer the results to the client, then it would be possible (eventually, with innovations in NX) to have dedicated GPU hardware do GPU-intensive tasks on a mainframe-like server, and transmit the results over a network (say, a WiFi LAN) to a much less beefy, more mobile device, such as a tablet.

          So you'd have your tablet on your desk in a meeting doing apparently amazing, computationally-intensive real-time 3d rendering, but the actual legwork would be done on the server.

          I'm sure projects like these are all over the place in academia and industry now that tablets are becoming mainstream, and general-purpose GPUs are becoming popular workhorses in business.

          I'm just waiting for the likes of Red Hat or GNOME to come up with something similar for general purpose free desktop usage, rather than settling with the first proprietary vendor to actually market something like this and make it easy to use.

          Anyway, I'm way off the topic of llvmpipe doing software gnome-shell, so yay for that. I'm sure that people running high-end servers with no GPU will appreciate being able to run g-s on the local console (or in the KVM-over-IP framebuffer, or whatever) for those times when you just have to use a graphical program.
          http://www.spice-space.org/
          While it isn't finished yet, this might be a viable option since it allows command submission and also uses efficient compression.
          http://tools.ietf.org/html/draft-ma-...vey-00#page-26
          That provides a concise explanation of the major protocols (though it does exclude NX).

          Comment


          • #6
            Michael, you mention "While most have open or closed-source 3D drivers available for their GPU, this will be of use to those with QEMU guests where hardware acceleration is lacking, those using Intel Poulsbo on open-source, etc."

            I'm wondering, what is the state of "true" hardware acceleration on the different virtual machines/environments? QEMU, KVM, vmware, Citrix, VirtualBox etc? It seems to me that vmware does have true hardware acceleration, but only up to OpenGL2.1. What goes for the other ones?

            It would be very interesting to see a comparison of the different virtual machines, including performance tests etc! If there already are tests like that, I'd really appreciate a link.

            Comment


            • #7
              For virtualbox, see this for example: https://www.virtualbox.org/attachmen...35/glxinfo.txt

              Comment


              • #8
                Originally posted by DanL View Post
                For virtualbox, see this for example: https://www.virtualbox.org/attachmen...35/glxinfo.txt
                Thanks! Is that real OpenGL GPU hardware acceleration, or OpenGL in software? Since it says Direct Rendering: Yes, it's in hardware, right?

                Comment


                • #9
                  Originally posted by Hamish Wilson View Post
                  Just in case anyone is wondering (or worrying) about the future of the traditional Fallback:

                  https://fedoraproject.org/wiki/Featu...ntingency_Plan
                  These are good news for anybody else, but horrible news for Ubuntu. AFAIK their Unity shell depends on GNOME fallback mode, so, if GNOME fallback mode itself falls into irrelevance, so does Ubuntu and their non-Unity-bar UI parts. Ubuntu would have to choose between non-maintained software (GNOME 2.24), abandoned software (GNOME 3 fallback mode) or GNOME Shell.

                  Comment


                  • #10
                    Originally posted by Hamish Wilson View Post
                    Just in case anyone is wondering (or worrying) about the future of the traditional Fallback:



                    https://fedoraproject.org/wiki/Featu...ntingency_Plan
                    FYI: That just means that FEDORA won't blow it out of the water. Unfortunately, they don't speak for GNOME. This is just the excuse that GNOME needs to screw everybody over.

                    Comment


                    • #11
                      Originally posted by Alejandro Nova View Post
                      AFAIK their Unity shell depends on GNOME fallback mode
                      Wondering where you heard such a ridiculous thing.

                      Comment


                      • #12
                        Originally posted by Awesomeness View Post
                        Wondering where you heard such a ridiculous thing.
                        I am guessing because Unity uses Compiz, and the only way you can use Compiz with GNOME 3 is through the Fallback mode?

                        Originally posted by droidhacker View Post
                        FYI: That just means that FEDORA won't blow it out of the water. Unfortunately, they don't speak for GNOME. This is just the excuse that GNOME needs to screw everybody over.
                        You do realize that many of the Fedora developers wear many hats, right? That many people involved in Fedora also work on GNOME? That Red Hat and Novel are the main contributors and backers to the GNOME project?

                        You do realize that William Jon McCann is a Red Hat employee right? So I think it is a fairly safe assumption that if Fedora says it will still be around, GNOME says it will still be around.

                        And I highly doubt that the Fallback was under any real threat anyway, as it is not that hard to maintain, and will still be the only option for older hardware like my brother's Dell Latitude D600. Do you really think his 1.6 GHz Intel CPU is going to be capable of running the Shell? They would have better luck getting it running on his Radeon 9000 IGP first, even though it is using an older Classic Mesa driver...

                        This belief that the Gnome developers have this kind of disdain for the Fallback is also miss-founded, a lot of work was put into it, and while they may be excited about their new Shell, and want it to run on as many systems as possible, that does not mean they want to kill the Fallback. The need for a Fallback that does not require Mutter has been a part of the Gnome 3 design doc for a long time, with them originally thinking of integrating Gnome 2 itself for this purpose, until getting the more sensible idea of porting the Panel to Gnome 3 infrastructure.

                        It is simply not going to go away overnight...

                        Comment


                        • #13
                          Originally posted by Hamish Wilson View Post
                          I am guessing because Unity uses Compiz, and the only way you can use Compiz with GNOME 3 is through the Fallback mode?



                          You do realize that many of the Fedora developers wear many hats, right? That many people involved in Fedora also work on GNOME? That Red Hat and Novel are the main contributors and backers to the GNOME project?

                          You do realize that William Jon McCann is a Red Hat employee right? So I think it is a fairly safe assumption that if Fedora says it will still be around, GNOME says it will still be around.

                          And I highly doubt that the Fallback was under any real threat anyway, as it is not that hard to maintain, and will still be the only option for older hardware like my brother's Dell Latitude D600. Do you really think his 1.6 GHz Intel CPU is going to be capable of running the Shell? They would have better luck getting it running on his Radeon 9000 IGP first, even though it is using an older Classic Mesa driver...

                          This belief that the Gnome developers have this kind of disdain for the Fallback is also miss-founded, a lot of work was put into it, and while they may be excited about their new Shell, and want it to run on as many systems as possible, that does not mean they want to kill the Fallback. The need for a Fallback that does not require Mutter has been a part of the Gnome 3 design doc for a long time, with them originally thinking of integrating Gnome 2 itself for this purpose, until getting the more sensible idea of porting the Panel to Gnome 3 infrastructure.

                          It is simply not going to go away overnight...
                          They've crippled it in gnome3, and have publicly stated (I'm too lazy to look it up and link to it) that they will be crippling it more and chopping it off at earliest opportunity.

                          And just because there are people from RH working on it doesn't mean that ONLY people from RH are responsible for it.

                          Comment


                          • #14
                            Originally posted by droidhacker View Post
                            They've crippled it in gnome3, and have publicly stated (I'm too lazy to look it up and link to it) that they will be crippling it more and chopping it off at earliest opportunity.
                            What do you mean by crippled? What more do you want from it? Bonobo support? Because that is the only thing that is really missing from the old Gnome Panel. And even then, that was handled by a compatibly layer in later versions of Gnome 2.x as it was considered archaic and obsolete even then. Gnome 3, as a major architectural change, was the right time to cut off support for it. You can not carry obsolete technologies on forever.

                            And unless you provide a link I simply can not believe your claims as it goes against everything that I have read and everything they seem to have done already to the Fallback mode. Over the past year they have put MORE features into it, fixed bugs in the Gnome Panel, done some theme tweaks, ported all of the official Gnome applets, and have kept it in sync with changes in other parts of the Gnome stack.

                            Originally posted by droidhacker View Post
                            And just because there are people from RH working on it doesn't mean that ONLY people from RH are responsible for it.
                            That was not what I actually said, but there are enough Red Hat employees behind GNOME that one can assume that they know what they are talking about with regards to the project. And there are other vested interests in keeping the Fallback mode around, so it would still be impractical to remove it, and I think the Gnome developers realize this.

                            Seriously, this is going from having a personal dislike for the modern DE (which is fair enough) to absolute paranoia, which is making me begin to understand why some Gnome developers might just feel somewhat attacked by some of their user community. You can not expect them to be fully reasonable unless the detractors act reasonable to to them in return.
                            Last edited by Hamish Wilson; 11-04-2011, 02:21 PM.

                            Comment


                            • #15
                              Originally posted by Alejandro Nova View Post
                              These are good news for anybody else, but horrible news for Ubuntu. AFAIK their Unity shell depends on GNOME fallback mode, so, if GNOME fallback mode itself falls into irrelevance, so does Ubuntu and their non-Unity-bar UI parts. Ubuntu would have to choose between non-maintained software (GNOME 2.24), abandoned software (GNOME 3 fallback mode) or GNOME Shell.
                              I don't believe that's true. GNOME's 'fallback mode' really consists of metacity and gnome-panel, neither of which is part of Unity. Unity builds on the non-shell parts of GNOME.

                              Comment

                              Working...
                              X