Announcement

Collapse
No announcement yet.

RADV Vulkan Driver Has Geometry Shader Support For Testing

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

  • RADV Vulkan Driver Has Geometry Shader Support For Testing

    Phoronix: RADV Vulkan Driver Has Geometry Shader Support For Testing

    David Airlie has published a set of 31 patches for testing that provide initial support for geometry shaders within the RADV Radeon Vulkan driver...

    http://www.phoronix.com/scan.php?pag...Shader-Patches

  • #2
    I'd love to try out RADV, but despite my fiddling, I cannot get it to work. Michael, what did you have to do other than add Padoka's PPA and run sudo apt-get dist-upgrade? (Ubuntu 16.10 w/ RX 480 here)

    Comment


    • #3
      Seems like RADV is improving very fast and lots of people are committed to improving it.

      Comment


      • #4
        "lots" being 2 people...

        Comment


        • #5
          If this functionality wasn't previously in the driver how does this change affect the performance?

          Did the driver previously simply skip geometry shader calls meaning the screen wasn't rendered properly and the results were faster than they should have been? Or was rendered previously offloaded to the CPU so this change will result in an improvement to performance?

          Comment


          • #6
            TYVM David. I just came here to check the status of RADV geometry like 10 mins ago and to ask whether I should use radv-wip-geom-shaders, so this is perfect timing


            Originally posted by Herem View Post
            If this functionality wasn't previously in the driver how does this change affect the performance?

            Did the driver previously simply skip geometry shader calls meaning the screen wasn't rendered properly and the results were faster than they should have been? Or was rendered previously offloaded to the CPU so this change will result in an improvement to performance?
            Previously, the driver didn't have the geometry feature available, so you couldn't create the device if you requested the geometry feature (via VkPhysicalDeviceFeatures). The validation layer would error if you tried to create a pipeline with a geometry shader module if that feature wasn't requested when the device was created. Not sure what would happen if you turned that layer off - undefined behavior probably.

            EDIT: Feature, not Extension.
            Last edited by xaxazak; 20 January 2017, 06:35 AM. Reason: Extension => Feature

            Comment


            • #7
              Originally posted by fhuberts View Post
              "lots" being 2 people...
              Seems to be enough...
              The progress is very fast IMO...

              Comment


              • #8
                Originally posted by nomadewolf View Post

                Seems to be enough...
                The progress is very fast IMO...
                They benefit from Intel's Vulkan work, LLVM amdgpu backend and shared Mesa utility work so they can move very fast.

                Comment


                • #9
                  Originally posted by Xicronic View Post
                  I'd love to try out RADV, but despite my fiddling, I cannot get it to work. Michael, what did you have to do other than add Padoka's PPA and run sudo apt-get dist-upgrade? (Ubuntu 16.10 w/ RX 480 here)
                  Try with the latest Steam update that fixes the libxcb issue. Stopped me from using RADV anyway...

                  Comment


                  • #10
                    Originally posted by xaxazak View Post
                    The validation layer would error if you tried to create a pipeline with a geometry shader module if that feature wasn't requested when the device was created. Not sure what would happen if you turned that layer off - undefined behavior probably.
                    The feature/extension system of vulkan requires you to name all the features you want to use up front, so AFAICS everything else leads to UB. This requirement is so that implementations can avoid doing initialization work that will not benefit apps that do not use certain features. This is similar to how setting the wrong load/store modes on a renderpass will lead to undefined content in the render buffers attachments (and maybe even UB, I'm not sure) but can lead to efficiency improvements if used well.

                    Comment

                    Working...
                    X