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 -MacNuke- View Post
    Vulkan has nothing of it. The driver only has to manage the memory of your GPU (following the application requests) and execute the SPIR-V code. No state.
    It might be worth reading through the Vulkan slides again, doing a Find on the word "state". The driver has to do a lot more than just manage memory and execute SPIR-V.
    Test signature

    Comment


    • Why do you think everyone should have to re-invent the wheel everytime a new API is developed? If it's in RAM, then it's in some kind of state and it doesn't matter what some marketing department says.
      Last edited by duby229; 06 March 2015, 01:45 PM.

      Comment


      • Originally posted by -MacNuke- View Post
        But why should one put the SPIR-V code through the Gallium3D Stack when you can send the SPIR-V code directly to the driver?
        Maybe a Vulkan-compatibility layer made in Gallium3D ?

        Comment


        • Originally posted by mr_tawan View Post
          Maybe a Vulkan-compatibility layer made in Gallium3D ?
          The SPIR-V code won't even need to know anything about gallium because the hardware driver will directly support SPIR-V and gallium independently. It's the hardware driver that will end up executing the SPIR-V code.

          Comment


          • Originally posted by duby229 View Post
            Why do you think everyone should have to re-invent the wheel everytime a new API is developed? If it's in RAM, then it's in some kind of state and it doesn't matter what some marketing department says.
            Well eh, with Vulkan you can choose not to track the state, or even not to create the state at all (afterall you have to create the state-tracking mechnism yourself so you can use whatever to implement that, or just don't create it). While in OpenGL the state is always there and create overheads in CPU.

            Comment


            • Originally posted by duby229 View Post
              The SPIR-V code won't even need to know anything about gallium because the hardware driver will directly support SPIR-V and gallium independently. It's the hardware driver that will end up executing the SPIR-V code.
              That is based on the fact that driver already support Vulkan and SPIR-V. So if the driver does not support it, it would be nice to have a compatibility layer just before that right ?

              It's the only use case I can think of right now anyway :P.

              Comment


              • Originally posted by bridgman View Post
                It might be worth reading through the Vulkan slides again, doing a Find on the word "state". The driver has to do a lot more than just manage memory and execute SPIR-V.
                Any links on that?

                I do not find anything useful in terms of state in combination with the API calls.

                Comment


                • Originally posted by mr_tawan View Post
                  That is based on the fact that driver already support Vulkan and SPIR-V. So if the driver does not support it, it would be nice to have a compatibility layer just before that right ?

                  It's the only use case I can think of right now anyway :P.
                  I assume it's being worked on already. AMD has known about Vulkan from the beginning, so I have to assume they are already working on it. It's one of thos things, when it's done is when it'll be done.

                  Comment


                  • Originally posted by duby229 View Post
                    Why do you think everyone should have to re-invent the wheel everytime a new API is developed? If it's in RAM, then it's in some kind of state and it doesn't matter what some marketing department says.
                    Nobody is re-inventing the wheel.

                    Gallium3D was created, because every driver implemented a state-tracker, a shader-compiler and an internal representation of things going on.

                    Vulkan is simply the last step to the hardware itself. When the driver implements SPIR-V directly, than Gallium3D on itself is useless for that task. The Vulkan-Library will send the code to the driver and not to another library (like libGL).

                    Sure you need Gallium3D to execute applications which are using OpenGL, but not for Vulkan.

                    Or in short. Vulkan is some kind of Gallium3D.

                    Comment


                    • Originally posted by mr_tawan View Post
                      Well eh, with Vulkan you can choose not to track the state, or even not to create the state at all (afterall you have to create the state-tracking mechnism yourself so you can use whatever to implement that, or just don't create it). While in OpenGL the state is always there and create overheads in CPU.
                      The only way to not create a state is execute directly from binary form off of the storage medium. Otherwise if it's in RAM, then it is in some state.

                      Comment

                      Working...
                      X