Announcement

Collapse
No announcement yet.

LLVMpipe Gallium3D Driver Now Exposes OpenGL 4.0

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

  • LLVMpipe Gallium3D Driver Now Exposes OpenGL 4.0

    Phoronix: LLVMpipe Gallium3D Driver Now Exposes OpenGL 4.0

    The LLVMpipe Gallium3D driver that provides a software/CPU-based OpenGL implementation for running on systems as a fallback path when no GPU / hardware OpenGL driver is available, a vendor-neutral path for debug purposes, and similar use-cases, now has OpenGL 4.0 support...

    http://www.phoronix.com/scan.php?pag...ipe-OpenGL-4.0

  • #2
    LLVMpipe is looking good, not much until OpenGL 4.4 support.
    softpipe is looking good, not much until OpenGL 4.0 support.
    virgl is looking good, only 1 feature left for OpenGL 4.5 support.
    Show Mesa progress for the OpenGL implementation into an easy to read HTML page.

    Comment


    • #3
      Nice progress. I'm quite interested in seeing Vallium evolve.

      Comment


      • #4
        Originally posted by uid313 View Post
        virgl is looking good, only 1 feature left for OpenGL 4.5 support.
        The progress is cool. Isn't virgl "just" a wrapper for use from within qemu to send commands to the virglrenderer library?
        Last edited by atomsymbol; 07-02-2020, 08:59 AM. Reason: Fix grammar

        Comment


        • #5
          Although I understand this is mostly meant to be a failsafe/fallback option, I think these software rasterizers need stuff like OGL4.x the most, since it allows GPUs without support (either because they're physically incapable or don't have enough driver development) to use those features. At least to my understanding, it can work that way. I'm actually not totally sure if you can mix up drivers like that.

          Comment


          • #6
            Originally posted by schmidtbag View Post
            Although I understand this is mostly meant to be a failsafe/fallback option, I think these software rasterizers need stuff like OGL4.x the most, since it allows GPUs without support (either because they're physically incapable or don't have enough driver development) to use those features. At least to my understanding, it can work that way. I'm actually not totally sure if you can mix up drivers like that.
            No there is currently not such support and even still hitting those code paths and the added CPU <-> GPU latency would still be a mess for performance.
            Michael Larabel
            http://www.michaellarabel.com/

            Comment


            • #7
              Originally posted by Michael View Post
              No there is currently not such support and even still hitting those code paths and the added CPU <-> GPU latency would still be a mess for performance.
              I guess there was a reason for my uncertainty. But, isn't a software solution used to assist the r600 drivers in OpenGL features it doesn't have/support? That might be where my confusion came in that you could mix drivers.

              Comment


              • #8
                Originally posted by schmidtbag View Post
                I guess there was a reason for my uncertainty. But, isn't a software solution used to assist the r600 drivers in OpenGL features it doesn't have/support? That might be where my confusion came in that you could mix drivers.
                There is the "soft FP64" support specifically, but that isn't just magically re-using LLVMpipe or the like. Way back in the day was also some i915 work for using LLVM for handling some unsupported features, but again was all work done specifically for that within the driver and just not getting any advancements from LLVMpipe.
                Michael Larabel
                http://www.michaellarabel.com/

                Comment


                • #9
                  Originally posted by schmidtbag View Post
                  Although I understand this is mostly meant to be a failsafe/fallback option.
                  For many virtualization packages, LLVMpipe is the only option. It is also very useful for things like containers / jails to retain security and not need to provide access to the raw device.

                  And finally it is also very useful to make sure badly written software works on older hardware. For example badly written software overly consumes the latest features and LLVMpipe can mitigate against this. Gnome 3 for example would not be able to run without LLVMpipe.

                  Comment


                  • #10
                    Originally posted by schmidtbag View Post
                    That might be where my confusion came in that you could mix drivers.
                    schmidtbag
                    Posts: 5058
                    This is your brain on Phoronix.

                    Comment

                    Working...
                    X