Announcement

Collapse
No announcement yet.

Valve Developed An Intel Linux Vulkan GPU Driver

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

  • -MacNuke-
    replied
    Originally posted by duby229 View Post
    And you obviously don't understand why RAM was invented.
    Another sentence from you that shows that you do not understand it xD

    Leave a comment:


  • bridgman
    replied
    Originally posted by -MacNuke- View Post
    Slide 29.

    "Drivers do not track state"
    Yep, although slide 29 is specifically talking about resource state rather than HW state.

    The statement about not *tracking* state does not mean the drivers are not involved in *executing* state commands from the application. In the case of Vulkan (and Gallium3D) state commands are given by (a) populating a state object structure and asking the driver to process it (thereby making one of the "immutable state objects" that the deck mentions, then (b) at command runtime specifying which pre-processed state objects should be used.
    Last edited by bridgman; 03-06-2015, 02:20 PM.

    Leave a comment:


  • duby229
    replied
    Originally posted by -MacNuke- View Post
    You simply do not understand the difference between a stateful API and a hardware state...
    And you obviously don't understand why RAM was invented.

    Leave a comment:


  • -MacNuke-
    replied
    Originally posted by duby229 View Post
    Why call it useless when it provides an API agnostic interface?
    I give up... you do not understand it.

    Leave a comment:


  • -MacNuke-
    replied
    Originally posted by bridgman View Post
    Slides 8, 21, 22 and 27 are the main ones. Slides 21 and 22 give examples of API calls for creating state objects. Slide 27 talks a bit about binding state objects (pipeline is basically a state object as well) to command buffers before submitting them.

    https://www.khronos.org/assets/uploa...-GDC-Mar15.pdf

    It's not that much of an oversimplification to say that a driver basically does two things -- translate state settings to HW settings, and translate shader IR instructions to HW instructions.
    Slide 29.

    "Drivers do not track state"

    Leave a comment:


  • duby229
    replied
    Originally posted by -MacNuke- View Post
    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.
    Why call it useless when it provides an API agnostic interface? There is absolutely nothing wrong with gallium drivers implementing SPIR-V support. Just like there is nothing wrong with them implementing TGSI or LLVMIR. Just because it's new and it hasn't been done yet doesn't mean that it can't be done or shouldn't be...

    The fact is that right now gallium is providing for OpenGL, OpenCL, and Direct3D9. And will be providing Vulkan and OpenCL2.

    Leave a comment:


  • -MacNuke-
    replied
    Originally posted by duby229 View Post
    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.
    You simply do not understand the difference between a stateful API and a hardware state...

    Leave a comment:


  • bridgman
    replied
    Originally posted by -MacNuke- View Post
    Any links on that? I do not find anything useful in terms of state in combination with the API calls.
    Slides 8, 21, 22 and 27 are the main ones. Slides 21 and 22 give examples of API calls for creating state objects. Slide 27 talks a bit about binding state objects (pipeline is basically a state object as well) to command buffers before submitting them.

    https://www.khronos.org/assets/uploa...-GDC-Mar15.pdf

    It's not that much of an oversimplification to say that a driver basically does three things :

    - translate state settings to HW settings
    - translate shader IR instructions to HW instructions
    - implement command submissions which combine geometry, state and shader code
    Last edited by bridgman; 03-06-2015, 02:13 PM.

    Leave a comment:


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

    Leave a comment:


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

    Leave a comment:

Working...
X