Announcement

Collapse
No announcement yet.

Valve Developed An Intel Linux Vulkan GPU Driver

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

  • phoronix
    started a topic Valve Developed An Intel Linux Vulkan GPU Driver

    Valve Developed An Intel Linux Vulkan GPU Driver

    Phoronix: Valve Developed An Intel Linux Vulkan GPU Driver

    For helping out ISVs and game developers test out their initial Vulkan code, they developed their own Intel Vulkan GPU graphics driver for Linux that they intend to open-source...

    http://www.phoronix.com/scan.php?pag...-Vulkan-Driver

  • ElectricPrism
    replied
    █▀▀░█░█░█▀█░█▀▀░█▀█
    ▀▀█░█░█░█▀▀░█▀░░█▀▄
    ▀▀▀░▀▀▀░▀░░░▀▀▀░▀░▀
    █▄░▄█░█▀▀░█▀▀▀░ █▀█
    █░█░█░█▀░░█░▀█░█▀▀█
    ▀░▀░▀░▀▀▀░▀▀▀▀░▀░░▀
    █░░█░█░▀▀█▀▀░█▀█░ █▀█
    █░░█░█░░░█░░░█▀▄░█▀▀█
    ▀▀▀▀░▀▀▀░▀░░░▀░▀░▀░░▀
    █▀▀░█▀█░█░█▀▀
    █▀░░█▀▀░█░█
    ▀▀▀░▀░░░▀░▀▀▀
    ░░░░░░██▄
    ░░░░░░█░█
    ░░░░░█░░█
    █▄▄▄█░░░██
    █░░ Valve ░░░█
    █ THANK YOU░█
    █░░░░░░░░░░█
    █░ And Give ░░█
    █░ me one ! ░░█
    ████████████
    Last edited by ElectricPrism; 03-23-2015, 05:05 AM.

    Leave a comment:


  • Prescience500
    replied
    I can't wait to actually see what the open source graphics driver developers have to say about how they will proceed.

    Leave a comment:


  • ahlaht
    replied
    Originally posted by Ancurio View Post
    You misunderstood what the person in the reddit thread you linked was explaining. Compiling your shaders outside the driver and then passing it into Vulkan instead of SPIR-V via a vendor extension means that all guarantees are not governed by the Khronos standard anymore but by the vendor writing the extension instead. What a driver does inside the driver after you passed in standard SPIR-V is completely unrelated to that. It could translate it to TGSI, then to NIR, then to Arabic poems and back to LLVM before emitting the hardware specific machine code. The driver would still have to pass all SPIR-V conformance testing.
    Thank you. I was just about to ask.

    Since GPUs do not run SPIR-V natively some kind of translation layer must always exist in between.

    Leave a comment:


  • Ancurio
    replied
    Originally posted by blackout23 View Post
    The driver that Valve/LunarG created is 100% from scratch in terms of userland implementation and uses the DRM interfaces with some modifications.
    http://www.reddit.com/r/linux/commen...driver/cp6mexg

    Translating from SPIR-V to whatever format is most useful for the driver doesn't sound like a good idea, since that means you throw conformance out the window.
    http://www.reddit.com/r/linux/commen...driver/cp6opom
    You misunderstood what the person in the reddit thread you linked was explaining. Compiling your shaders outside the driver and then passing it into Vulkan instead of SPIR-V via a vendor extension means that all guarantees are not governed by the Khronos standard anymore but by the vendor writing the extension instead. What a driver does inside the driver after you passed in standard SPIR-V is completely unrelated to that. It could translate it to TGSI, then to NIR, then to Arabic poems and back to LLVM before emitting the hardware specific machine code. The driver would still have to pass all SPIR-V conformance testing.

    Leave a comment:


  • blackout23
    replied
    Originally posted by smitty3268 View Post
    That's exactly the position that TGSI takes in the current Gallium drivers, though. The LLVM IR portion is inside the driver stack, not directly above it like TGSI is.

    SPIR-V is the compile target for tools and high-level languages. There's an assumption there that the drivers will be free to translate it into whatever format is most useful for them internally to get it going on their hardware.
    The driver that Valve/LunarG created is 100% from scratch in terms of userland implementation and uses the DRM interfaces with some modifications.
    http://www.reddit.com/r/linux/commen...driver/cp6mexg

    Translating from SPIR-V to whatever format is most useful for the driver doesn't sound like a good idea, since that means you throw conformance out the window.
    http://www.reddit.com/r/linux/commen...driver/cp6opom

    Leave a comment:


  • smitty3268
    replied
    Originally posted by dragorth View Post
    Then the message received by the slides being presented is kinda messed up. And in the video presentations that are online. All of them talk about SPIR-V being the compile target. It always positions SPIR-V directly above the driver stack, as the thing the driver consumes. And then everything else is above it, with some interesting projects being able to convert to other things, such as LLVM.

    http://youtu.be/EUNMrU8uU5M?t=45m3s

    This is an example of how it is presented.
    That's exactly the position that TGSI takes in the current Gallium drivers, though. The LLVM IR portion is inside the driver stack, not directly above it like TGSI is.

    SPIR-V is the compile target for tools and high-level languages. There's an assumption there that the drivers will be free to translate it into whatever format is most useful for them internally to get it going on their hardware.

    Leave a comment:


  • bridgman
    replied
    Originally posted by dragorth View Post
    Then the message received by the slides being presented is kinda messed up. And in the video presentations that are online. All of them talk about SPIR-V being the compile target. It always positions SPIR-V directly above the driver stack, as the thing the driver consumes.
    Not sure if it's messed up, or just not doing a good job of differentiating between the Vulkan driver itself (which accepts SPIR-V) and a pre-existing HW driver layer such as Gallium3D on which the Vulkan driver might be built and which already has an internal shader compiler IR which is neither SPIR-V nor LLVM IR.

    Leave a comment:


  • duby229
    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).
    Option 2 is the one I personally hope will happen.

    Leave a comment:


  • dragorth
    replied
    Originally posted by bridgman View Post
    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 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.
    Then the message received by the slides being presented is kinda messed up. And in the video presentations that are online. All of them talk about SPIR-V being the compile target. It always positions SPIR-V directly above the driver stack, as the thing the driver consumes. And then everything else is above it, with some interesting projects being able to convert to other things, such as LLVM.

    http://youtu.be/EUNMrU8uU5M?t=45m3s

    This is an example of how it is presented.

    Leave a comment:

Working...
X