Announcement

Collapse
No announcement yet.

Valve Developed An Intel Linux Vulkan GPU Driver

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

  • 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:


  • dungeon
    replied
    Originally posted by mr_tawan View Post
    Lol I don't think we asians would love your kiss . Just pay us a visit sometime when you have free time.
    That "kiss" is not metter of love

    Anyway I don't really live in the place that exports electronics so myself is not counted in, am I ?
    Yes you are counted, everybody in the world should be

    Leave a comment:

Working...
X