Announcement

Collapse
No announcement yet.

AMD's Vulkan Driver Will Only Work With The AMDGPU Kernel Driver

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

  • MaxToTheMax
    replied
    Originally posted by bridgman View Post
    *bridgman bangs head on screen since EVERY SINGLE STINKIN' LONG-ENOUGH-TO-BE-USEFUL POST GETS MODERATED !!!!!

    Guess I do need to start saving before I post... if nothing else it would be interesting to see if the same text posted multiple times gets moderated every time...
    I never type extensive posts directly into the browser. Once I get past a couple paragraphs, I switch to a real text editor and paste it back to the browser when I'm done. There's also a browser extension called "it's all text" that does this automatically, but it doesn't work for websites that use customized javascript-infested text entry fields.

    Leave a comment:


  • bridgman
    replied
    *bridgman bangs head on screen since EVERY SINGLE STINKIN' LONG-ENOUGH-TO-BE-USEFUL POST GETS MODERATED !!!!!

    Guess I do need to start saving before I post... if nothing else it would be interesting to see if the same text posted multiple times gets moderated every time...
    Last edited by bridgman; 21 January 2016, 06:56 PM.

    Leave a comment:


  • bridgman
    replied
    Originally posted by duby229 View Post
    Well, after reading this thread, I'm personally convinced that if AMD doesn't support Vulkan on -all- GCN cards, there will be an explosive backfire. And I think bridgmans excuse of blaming it on linus is asinine.
    With respect, perhaps you don't understand what I'm saying. The *only* thing I am associating with Linus's policies is the *current* upstream default driver for SI and CI hardware. I have never said *anything* which ties Vulkan support to upstream default support, other than saying multiple times that Michael was drawing a connection where none actually existed. Can you please be a bit more specific about why you think I am blaming (or even hinting) that Vulkan support has anything to do with which driver is enabled upstream by default today ? Thanks.

    Originally posted by duby229 View Post
    EDIT: The exists a politically correct method and a different technically correct method. The chosen path is the politically correct one, but which is definitely not technically correct.
    Can you use different words here ? I have no idea what you are trying to say.

    Originally posted by duby229 View Post
    EDIT: So we've got multiple AMD employees saying multiple incompatible things. One says Vulkan will only work on amdgpu, another says only GCN 1.2 and up will be supported on amdgpu (and blames that on linus torvalds), another says amdgpu will support older GCN revisions out of tree eventually.....
    No, we're all saying pretty much the same thing, but you (and others) are mixing comments about libdrm level interfaces with comments about kernel drivers (and yes if I were king they would either have different names or fully qualified hierarchical names ).

    Vulkan is definitely only going to be supported on the libdrm-amdgpu userspace interface, not libdrm-radeon or the Catalyst equivalent. The libdrm-amdgpu interface library currently only runs over the amdgpu kernel driver, but we could also run it over the radeon kernel driver if that made more sense (or gave us a better short term solution) than adding SI support to amdgpu. We have been looking at both options in parallel with development of the Vulkan driver.

    Originally posted by duby229 View Post
    Come on AMD. You can do better. (Fuck the out of tree bullshit. Fuck the blame game on linus bullshit.) Put -ALL- GCN support in amdgpu and get it upstreamed. If that requires removing GCN support from radeon, then that is exactly what it requires.
    You are missing the point again. We can't just remove support from radeon and break every user out there when they upgrade their kernel. First we have to get userspace code which can seamlessly run over either driver on SI/CI hardware, then wait until that code gets out to most users and have a transition/messaging plan for the rest, and *then* we can start looking at switching. I have said this many many times in the last week.

    We have CI code in amdgpu kernel driver today, which makes sense because CI and VI chips are relatively similar from a programming perspective. We do not have SI code in amdgpu kernel driver today, because NI and SI chips are relatively similar from a programming perspective and so it makes most sense to keep them on radeon.

    Using radeon gives us the ability to run immediately on upstream and in-distro kernels, and gives us a known-quality driver stack for all of the other functionality. Using amdgpu on SI/CI means (apart from the porting effort) that to some extent we are starting from scratch in terms of dealing with individual board/system gotchas (you can port quirk code but you can't port "writing the code the way we did just happened to work for those SKUs") and forces us to deploy the kernel drivers out-of-tree for probably 6 months, but also means we get to deal with a single interface for the usermode drivers.

    The big breaking news here is not "AMD isn't supporting XYZ", it's "AMD chose not to answer all of Michael's questions immediately so he made some guesses and people misinterpreted what he wrote".

    Leave a comment:


  • artivision
    replied
    Most Devs will not support Vulkan or DX12 if it works only on GCN and Kepler+ GPUs, they need support for HD5-6 series and Fermi. Even today, most of them have D3D9 legacy support, eventually legacy will be replaced with D3D10. They all say that they need Vulkan and D3D12 for all SM5 GPUs. So the best will be an extension to Amdgpu to support Radeon IOCTLs (HD5-6 series not excluded).

    Leave a comment:


  • duby229
    replied
    Well, after reading this thread, I'm personally convinced that if AMD doesn't support Vulkan on -all- GCN cards, there will be an explosive backfire. And I think bridgmans excuse of blaming it on linus is asinine.

    EDIT: The exists a politically correct method and a different technically correct method. The chosen path is the politically correct one, but which is definitely not technically correct.

    EDIT: So we've got multiple AMD employees saying multiple incompatible things. One says Vulkan will only work on amdgpu, another says only GCN 1.2 and up will be supported on amdgpu (and blames that on linus torvalds), another says amdgpu will support older GCN revisions out of tree eventually.....

    Come on AMD. You can do better. (Fuck the out of tree bullshit. Fuck the blame game on linus bullshit.) Put -ALL- GCN support in amdgpu and get it upstreamed. If that requires removing GCN support from radeon, then that is exactly what it requires.
    Last edited by duby229; 21 January 2016, 01:01 PM.

    Leave a comment:


  • Kano
    replied
    No, there is a GLSL -> SPIR-V sample implementation but Vulkan can only use SPIR-V.

    Leave a comment:


  • artivision
    replied
    Originally posted by Kano View Post
    DX12 uses HLSL not SPIR-V - HLSL is the same as before. But maybe it is faster to do HLSL -> SPIR-V than HLSL -> GLSL. At least writing an optimizier for SPIR-V would be more generic after that step.
    D3D12 uses HLSL and Vuckan GLSL and every API will be ever created will use an SL for Devs to write graphics and never an Assembly. The only difference is that with low level APIs, graphics will be distributed pre-compiled in Assembly(SpirV or D3D12_asm) with many optimizations already done. So it will be asm_to_SpirV (assembly to equal level assembly with just typos conversion), or directly asm_to_hw, or to virtual machine assembly (LLVM-IR) and then HW.

    Leave a comment:


  • Kano
    replied
    DX12 uses HLSL not SPIR-V - HLSL is the same as before. But maybe it is faster to do HLSL -> SPIR-V than HLSL -> GLSL. At least writing an optimizier for SPIR-V would be more generic after that step.

    Leave a comment:


  • artivision
    replied
    I think the community must think Vulkan also for Radeon HD 5000-6000 series. With an extra D3D12 to Vulkan compatibility layer with low overhead, we can take a very important portion of the gamers from MS (D3D12 on HD5-6 series). This is a golden and rare change to upgrade Linux usage on PC and gain more native support after.

    Leave a comment:


  • MaxToTheMax
    replied
    Originally posted by bridgman View Post
    <SNIP>
    People sometimes forget that GCN is short for Graphics Core Next, not Graphics Chip Next
    Very informative, thanks.

    Leave a comment:

Working...
X