Announcement

Collapse
No announcement yet.

LLVMpipe Gallium3D Driver Now Exposes OpenGL 4.3

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

  • LLVMpipe Gallium3D Driver Now Exposes OpenGL 4.3

    Phoronix: LLVMpipe Gallium3D Driver Now Exposes OpenGL 4.3

    It was just at the start of July that the LLVMpipe software driver gained OpenGL 4.0 support at long last. Days after that milestone OpenGL 4.2 support was reached for this driver that offers OpenGL acceleration atop CPUs either for fallback purposes or a vendor-neutral debug path. Now just days before the Mesa 20.2 branching, OpenGL 4.3 support has been cleared!..

    http://www.phoronix.com/scan.php?pag...L-4.3-LLVMpipe

  • #2
    Any ideas of what their plans are regarding this? Why spend time and money on LLVMPipe now?

    Comment


    • #3
      Mesamatrix lists llvmpipe as OpenGL 4.4, with 4.5 and 4.6 almost done too.

      Originally posted by Azpegath View Post
      Any ideas of what their plans are regarding this? Why spend time and money on LLVMPipe now?
      It can be used as a fallback when no native hardware driver is available.
      It can be used to have an alternative implementation to compare against for developers of device drivers so they know that their driver is behaving the same and produces the same result.
      I guess it can be used under virtual machines.

      Comment


      • #4
        Originally posted by Azpegath View Post
        Any ideas of what their plans are regarding this? Why spend time and money on LLVMPipe now?
        CI coverage for core mesa, CI coverage for virgl
        Eventual vulkan swrast fallback path for VM and server fallbacks and testing.

        Comment


        • #5
          Sweet, 4.5 compatibility appears to be only a stone throw away with ES2 support in place already, at it also requires GL_KHR_rebustness.

          Comment


          • #6
            Could this eventually help in developing "hybrid" drivers for older GPUs that "fill in the gaps" of certain hardware support in older GPUs, utilizing any hardware acceleration features those already have and augmenting them with partially processing stuff on the CPU w.r.t. unsupported hardware features, in effect making them support later OpenGL versions than they would otherwise be able to support completely in hardware?

            One obvious example would be software-based FP64 support, but there might also be others? I understand that certain acceleration features can't be handled jointly by the CPU and GPU in a cooperative matter, but for some stuff it might be feasible, right? Partial hardware acceleration would still be better than no hardware acceleration at all.

            Comment


            • #7
              Originally posted by phoronix View Post
              Phoronix: LLVMpipe Gallium3D Driver Now Exposes OpenGL 4.3

              It was just at the start of July that the LLVMpipe software driver gained OpenGL 4.0 support at long last. Days after that milestone OpenGL 4.2 support was reached for this driver that offers OpenGL acceleration atop CPUs either for fallback purposes or a vendor-neutral debug path. Now just days before the Mesa 20.2 branching, OpenGL 4.3 support has been cleared!..

              http://www.phoronix.com/scan.php?pag...L-4.3-LLVMpipe
              On an 8-core CPU that has AVX2 and 256-bit-wide data paths:
              • Metro 2033 Redux, 1080p, lowest quality: 5 frames per second
              • Tomb Raider: crashes

              Comment


              • #8
                Originally posted by SteamPunker View Post
                One obvious example would be software-based FP64 support, but there might also be others? I understand that certain acceleration features can't be handled jointly by the CPU and GPU in a cooperative matter, but for some stuff it might be feasible, right? Partial hardware acceleration would still be better than no hardware acceleration at all.
                The software-based FP64 emulation already landed in mesa. So if I understand correctly, drivers that have a NIR and Gallium3D based architecture should be able to wire that up relatively easy - like the R600g NIR driver. Or do I miss something there?

                About the partial hardware acceleration: I'm not sure if I'd agree - a higher GL support level could trick applications into using different code path, ending up in a situation where things get slower because emulated features are used instead of older but accelerated ones. That happened in the past for the i915 mesa driver, see https://www.phoronix.com/scan.php?pa...-OpenGL-2-Drop

                Comment


                • #9
                  All I know is thanks to LLVMpipe, I can boot to a modern Linux desktop with full quality regardless of a working GPU driver, while on Windows I am stuck with 4:3 resolutions or no video output at all.

                  Comment


                  • #10
                    Originally posted by [email protected] View Post
                    All I know is thanks to LLVMpipe, I can boot to a modern Linux desktop with full quality regardless of a working GPU driver, while on Windows I am stuck with 4:3 resolutions or no video output at all.
                    Exactly. And 30 years from now when we try to play our "retro" games. We will very likely not have a working accelerated GPU driver in the emulator. LLVMpipe will be priceless!

                    As far as I know though, the vesa driver still only supports 4:3 resolutions. Modesetting driver is better but again, the emulators of the future will unlikely support that either. Luckily a remote X11 or Xvnc session allows for any resolution so there is still hope. For digital preservation, BSD and Linux is currently in pretty good shape.

                    Comment

                    Working...
                    X