Announcement

Collapse
No announcement yet.

Valve Developed An Intel Linux Vulkan GPU Driver

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

  • bridgman
    replied
    The big difference beween LLVM IR and SPIR-V as far as I know is that LLVM tools can work on LLVM IR but not on SPIR-V. Tom can comment more on how things worked out, but we picked LLVM IR because of the tools (optimizing passes etc..) that it came with not because we thought it was the ideal IR for our shader compiler in an absolute sense.

    Unless I'm missing something, replacing LLVM IR with SPIR-V as the driver-internal IR would require that we re-implement (or at least fork and modify) all of the LLVM tools we use in the shader compiler, which would largely eliminate the benefits from using LLVM in the first place.

    It seems more likely that SPIR-V would replace TGSI, although there's been less discussion of that than I expected.
    Last edited by bridgman; 03-06-2015, 11:02 PM.

    Leave a comment:


  • dragorth
    replied
    Originally posted by bridgman View Post
    I guess there are two main options :

    1. Have the Vulkan state tracker translate SPIR-V into TGSI before passing it to the Gallium3D driver

    2. Extend the Gallium3D API definition so that SPIR-V shader code can be accepted in addition to TGSI, allowing the Vulkan state tracker to pass SPIR-V directly to the driver. This could use a SPIR-V to TGSI translator inside the driver, or could convert SPIR-V directly to an IR already being used internally to the driver, eg LLVM IR for radeonsi.

    Option 2 has more flexibility in the sense that it would also be convenient for adding SPIR-V support to the clover OpenCL state tracker.

    In addition to this, Vulkan API calls would need to be mapped onto Gallium3D API calls, which might require a tweak to the Gallium3D API for best efficiency (don't know if anyone has looked at things like granularity of state object definitions to see how well they align).
    My understanding of the intent of SPIR-V has been for it to BE LLVM-IR, only for all GPUs. Keep in mind, the idea is to get rid of the driver overhead, including converting into an intermediate language during execution. I am not saying it can't be done, I am saying it is not ideal for graphics or compute use cases.

    The Unix philosophy is for each thing to do one thing well, then SPIR-R which is a direct GPU mapping going into LLVM IR to then go into the GPU seems to defeat both that philosophy and its purpose.

    Keep in mind, Khronos originally wanted to use LLVM-IL for SPIR then decided against it for two reasons, the IL was always in flux and could go in a completely counter direction without them having a say, and LLVM-IL didn't map neatly into the GPU use case. So SPIR-V was design to counter those issues, meaning it is the better match to go directly to the GPU.

    Leave a comment:


  • bridgman
    replied
    Originally posted by duby229 View Post
    About the "stateless gallium state tracker ;-)", that means using SPIR-V that the driver provides instead of TGSI right?
    I guess there are two main options :

    1. Have the Vulkan state tracker translate SPIR-V into TGSI before passing it to the Gallium3D driver

    2. Extend the Gallium3D API definition so that SPIR-V shader code can be accepted in addition to TGSI, allowing the Vulkan state tracker to pass SPIR-V directly to the driver. This could use a SPIR-V to TGSI translator inside the driver, or could convert SPIR-V directly to an IR already being used internally to the driver, eg LLVM IR for radeonsi.

    Option 2 has more flexibility in the sense that it would also be convenient for adding SPIR-V support to the clover OpenCL state tracker.

    In addition to this, Vulkan API calls would need to be mapped onto Gallium3D API calls, which might require a tweak to the Gallium3D API for best efficiency (don't know if anyone has looked at things like granularity of state object definitions to see how well they align).
    Last edited by bridgman; 03-06-2015, 09:50 PM.

    Leave a comment:


  • duby229
    replied
    Originally posted by robclark View Post
    different definition of state..

    in this context, "state" means "stateful API", ie. w/ opengl the driver is tracking state behind the scenes rather than application passing objects that describe the state.
    I guess I took something I know about and applied in the wrong context during this thread. I apologize for that.

    Originally posted by robclark View Post
    One way or another, I don't think supporting both a gallium pipe driver for opengl, and a vulkan driver, is a reasonable option. It's not like opengl is going away tomorrow. Unless someone steps up with an open source opengl on top of vulkan, then I think we will have to somehow implement vulkan as a stateless gallium state tracker ;-)
    About the "stateless gallium state tracker ;-)", that means using SPIR-V that the driver provides instead of TGSI right?

    Leave a comment:


  • Ancurio
    replied
    It seems like two people are constantly talking past each other regarding the semantics of "state". In OpenGL, you would for example set a scissor state, which is global and affects all calls thereafter until changed (so any code requiring a specific scissor setup needs to first save the old state before clobbering it), whereas in Vulkan absolutely everything is packaged into neat objects which don't affect each other. That's all the difference. It's analogous to passing the desired scissor state directly into glDrawWhatever (if that was possible in OpenGL, which of course it's not).

    SPIR-V is not some magic bullet that will somehow automatically give you support for an entire API (which I feel some people are mistaking it for). It's just compiled GLSL (very simply put, of course you could write a compiler for any imaginary shader language, and I didn't mention compute kernels either), nothing more. You're not going to compile arbitrary C programs to SPIR-V and somehow have them run on the GPU. If you were to implement Vulkan on top of Gallium, you would write one generic SPIR-V -> TGSI pass since all Gallium drivers consume TGSI (I believe, or are there OpenCL exceptions?).

    The presentation mentioned further clarified that you shouldn't think of Vulkan as "low level"; rather, it is a graphics API that first the design of current hardware much more closely.

    Leave a comment:


  • LEW21
    replied
    I guess some people assume Gallium3D = state tracker, and that is simply not true. Gallium3D = state trackers PLUS hw drivers PLUS winsys implementations. And, as the interface between state trackers and hw drivers is AFAIK quite similar in spirit to Vulkan, it will be probably quite easy to:
    1) provide Vulkan implementation over Gallium3D drivers
    2) provide Mesa's OGL API over Vulkan drivers

    Leave a comment:


  • robclark
    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.
    different definition of state..

    in this context, "state" means "stateful API", ie. w/ opengl the driver is tracking state behind the scenes rather than application passing objects that describe the state.

    Leave a comment:


  • robclark
    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.
    One way or another, I don't think supporting both a gallium pipe driver for opengl, and a vulkan driver, is a reasonable option. It's not like opengl is going away tomorrow. Unless someone steps up with an open source opengl on top of vulkan, then I think we will have to somehow implement vulkan as a stateless gallium state tracker ;-)

    Leave a comment:


  • carewolf
    replied
    Originally posted by duby229 View Post
    If it's in some kind of memory, then it's in some kind of state. That's a fact.
    Yes, but the states we talk about in OpenGL and Direct3D in Gallium3D are global variables. When they say Vulkan is stateless what is meant is that it doesn't rely on global variables the same way as the old APIs did.

    Leave a comment:


  • mr_tawan
    replied
    Originally posted by dungeon View Post
    That "kiss" is not metter of love



    Yes you are counted, everybody in the world should be
    I must say that I didn't really mean that when I posted the reply, though I cannot remember what exactly I was thinking at that time. My memory is pretty much short-live .

    Leave a comment:

Working...
X