Announcement

Collapse
No announcement yet.

Valve Developed An Intel Linux Vulkan GPU Driver

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

  • Originally posted by dragorth View Post
    Then the message received by the slides being presented is kinda messed up. And in the video presentations that are online. All of them talk about SPIR-V being the compile target. It always positions SPIR-V directly above the driver stack, as the thing the driver consumes.
    Not sure if it's messed up, or just not doing a good job of differentiating between the Vulkan driver itself (which accepts SPIR-V) and a pre-existing HW driver layer such as Gallium3D on which the Vulkan driver might be built and which already has an internal shader compiler IR which is neither SPIR-V nor LLVM IR.

    Comment


    • Originally posted by dragorth View Post
      Then the message received by the slides being presented is kinda messed up. And in the video presentations that are online. All of them talk about SPIR-V being the compile target. It always positions SPIR-V directly above the driver stack, as the thing the driver consumes. And then everything else is above it, with some interesting projects being able to convert to other things, such as LLVM.

      http://youtu.be/EUNMrU8uU5M?t=45m3s

      This is an example of how it is presented.
      That's exactly the position that TGSI takes in the current Gallium drivers, though. The LLVM IR portion is inside the driver stack, not directly above it like TGSI is.

      SPIR-V is the compile target for tools and high-level languages. There's an assumption there that the drivers will be free to translate it into whatever format is most useful for them internally to get it going on their hardware.

      Comment


      • Originally posted by smitty3268 View Post
        That's exactly the position that TGSI takes in the current Gallium drivers, though. The LLVM IR portion is inside the driver stack, not directly above it like TGSI is.

        SPIR-V is the compile target for tools and high-level languages. There's an assumption there that the drivers will be free to translate it into whatever format is most useful for them internally to get it going on their hardware.
        The driver that Valve/LunarG created is 100% from scratch in terms of userland implementation and uses the DRM interfaces with some modifications.
        http://www.reddit.com/r/linux/commen...driver/cp6mexg

        Translating from SPIR-V to whatever format is most useful for the driver doesn't sound like a good idea, since that means you throw conformance out the window.
        http://www.reddit.com/r/linux/commen...driver/cp6opom

        Comment


        • Originally posted by blackout23 View Post
          The driver that Valve/LunarG created is 100% from scratch in terms of userland implementation and uses the DRM interfaces with some modifications.
          http://www.reddit.com/r/linux/commen...driver/cp6mexg

          Translating from SPIR-V to whatever format is most useful for the driver doesn't sound like a good idea, since that means you throw conformance out the window.
          http://www.reddit.com/r/linux/commen...driver/cp6opom
          You misunderstood what the person in the reddit thread you linked was explaining. Compiling your shaders outside the driver and then passing it into Vulkan instead of SPIR-V via a vendor extension means that all guarantees are not governed by the Khronos standard anymore but by the vendor writing the extension instead. What a driver does inside the driver after you passed in standard SPIR-V is completely unrelated to that. It could translate it to TGSI, then to NIR, then to Arabic poems and back to LLVM before emitting the hardware specific machine code. The driver would still have to pass all SPIR-V conformance testing.

          Comment


          • Originally posted by Ancurio View Post
            You misunderstood what the person in the reddit thread you linked was explaining. Compiling your shaders outside the driver and then passing it into Vulkan instead of SPIR-V via a vendor extension means that all guarantees are not governed by the Khronos standard anymore but by the vendor writing the extension instead. What a driver does inside the driver after you passed in standard SPIR-V is completely unrelated to that. It could translate it to TGSI, then to NIR, then to Arabic poems and back to LLVM before emitting the hardware specific machine code. The driver would still have to pass all SPIR-V conformance testing.
            Thank you. I was just about to ask.

            Since GPUs do not run SPIR-V natively some kind of translation layer must always exist in between.

            Comment


            • I can't wait to actually see what the open source graphics driver developers have to say about how they will proceed.

              Comment


              • █▀▀░█░█░█▀█░█▀▀░█▀█
                ▀▀█░█░█░█▀▀░█▀░░█▀▄
                ▀▀▀░▀▀▀░▀░░░▀▀▀░▀░▀
                █▄░▄█░█▀▀░█▀▀▀░ █▀█
                █░█░█░█▀░░█░▀█░█▀▀█
                ▀░▀░▀░▀▀▀░▀▀▀▀░▀░░▀
                █░░█░█░▀▀█▀▀░█▀█░ █▀█
                █░░█░█░░░█░░░█▀▄░█▀▀█
                ▀▀▀▀░▀▀▀░▀░░░▀░▀░▀░░▀
                █▀▀░█▀█░█░█▀▀
                █▀░░█▀▀░█░█
                ▀▀▀░▀░░░▀░▀▀▀
                ░░░░░░██▄
                ░░░░░░█░█
                ░░░░░█░░█
                █▄▄▄█░░░██
                █░░ Valve ░░░█
                █ THANK YOU░█
                █░░░░░░░░░░█
                █░ And Give ░░█
                █░ me one ! ░░█
                ████████████
                Last edited by ElectricPrism; 03-23-2015, 05:05 AM.

                Comment

                Working...
                X