Announcement

Collapse
No announcement yet.

Valve Developed An Intel Linux Vulkan GPU Driver

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
    -MacNuke-
    Senior Member

  • -MacNuke-
    replied
    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.

    Leave a comment:

  • mr_tawan
    Phoronix Member

  • mr_tawan
    replied
    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.

    Leave a comment:

  • mr_tawan
    Phoronix Member

  • mr_tawan
    replied
    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.

    Leave a comment:

  • duby229
    Senior Member

  • duby229
    replied
    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.

    Leave a comment:

  • mr_tawan
    Phoronix Member

  • mr_tawan
    replied
    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 ?

    Leave a comment:

  • duby229
    Senior Member

  • duby229
    replied
    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.
    duby229
    Senior Member
    Last edited by duby229; 06 March 2015, 01:45 PM.

    Leave a comment:

  • bridgman
    AMD Linux

  • bridgman
    replied
    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.

    Leave a comment:

  • -MacNuke-
    Senior Member

  • -MacNuke-
    replied
    Originally posted by duby229 View Post
    Unless you plan on making all of you API calls from a binary on the HD and only from that binary on that HD, then it's in some kind of state. If you can make a memory dump and read it, then it's in some kind of state.
    This has nothing to to with the work of a state tracker.

    Originally posted by duby229 View Post
    I don't think you understand how gallium works.
    And I think you do not understand how graphic APIs work.

    Leave a comment:

  • duby229
    Senior Member

  • duby229
    replied
    Originally posted by -MacNuke- View Post
    Your Application has a state, yes. But not the API...

    If you bind a texture in OpenGL, set a light, etc., all your following draw calls will use this texture and this light. There is your state... transparent for the application. Pure OpenGL state.

    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.



    And Gallium3D does what?

    Sending code to the driver is the work of the Vulkan-Library. Why should one send the code to the Gallium3D interface instead of directly to the driver?
    Unless you plan on making all of you API calls from a binary on the HD and only from that binary on that HD, then it's in some kind of state. If you can make a memory dump and read it, then it's in some kind of state.

    I don't think you understand how gallium works.

    Leave a comment:

  • -MacNuke-
    Senior Member

  • -MacNuke-
    replied
    Originally posted by duby229 View Post
    How can it not have a state? If it's in some kind of memory somewhere it's in some kind of state. It's the whole reason why the harvard architecture was invented. It's the whole reason for RAM.
    Your Application has a state, yes. But not the API...

    If you bind a texture in OpenGL, set a light, etc., all your following draw calls will use this texture and this light. There is your state... transparent for the application. Pure OpenGL state.

    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.

    Originally posted by duby229 View Post
    The SPIR-V code will be going directly to the hardware driver. It's the only thing that needs to care about it.
    And Gallium3D does what?

    Sending code to the driver is the work of the Vulkan-Library. Why should one send the code to the Gallium3D interface instead of directly to the driver?

    Leave a comment:

Working...
X