Page 1 of 2 12 LastLast
Results 1 to 10 of 19

Thread: GNOME Shell Now Works With Software Rendering!

Hybrid View

  1. #1
    Join Date
    Jan 2007
    Posts
    14,613

    Default 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. #2
    Join Date
    Oct 2011
    Location
    Rural Alberta, Canada
    Posts
    1,030

    Default

    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

  3. #3
    Join Date
    Sep 2008
    Posts
    989

    Default

    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.

  4. #4
    Join Date
    Oct 2009
    Posts
    353

    Default

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

  5. #5
    Join Date
    Jan 2009
    Posts
    1,353

    Default

    Quote 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).

  6. #6
    Join Date
    Nov 2010
    Location
    Stockholm, Sweden
    Posts
    399

    Default

    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.

  7. #7
    Join Date
    Oct 2007
    Posts
    1,268

    Default

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

  8. #8
    Join Date
    Feb 2008
    Location
    Santiago, Chile
    Posts
    240

    Default

    Quote 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.

  9. #9
    Join Date
    Dec 2010
    Posts
    1,120

    Default

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

  10. #10
    Join Date
    Oct 2011
    Location
    Rural Alberta, Canada
    Posts
    1,030

    Default

    Quote 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?

    Quote 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...

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •