Originally posted by -MacNuke-
View Post
Announcement
Collapse
No announcement yet.
Valve Developed An Intel Linux Vulkan GPU Driver
Collapse
X
-
-
Originally posted by duby229 View PostThe 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.
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.
Comment
-
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
Comment
-
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.
Comment
-
Originally posted by robclark View Postdifferent 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.
Originally posted by robclark View PostOne 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 ;-)
Comment
-
Originally posted by duby229 View PostAbout the "stateless gallium state tracker ;-)", that means using SPIR-V that the driver provides instead of TGSI right?
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; 06 March 2015, 09:50 PM.Test signature
Comment
-
Originally posted by bridgman View PostI 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).
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.
Comment
-
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; 06 March 2015, 11:02 PM.Test signature
Comment
-
Originally posted by bridgman View PostThe 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 today, which more or less negates the benefits of 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.
http://youtu.be/EUNMrU8uU5M?t=45m3s
This is an example of how it is presented.
Comment
-
Originally posted by bridgman View PostI 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).
Comment
Comment