Announcement

Collapse
No announcement yet.

AMDVLK Vulkan Driver Now Supports Direct Display Mode For VR HMDs

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

  • AMDVLK Vulkan Driver Now Supports Direct Display Mode For VR HMDs

    Phoronix: AMDVLK Vulkan Driver Now Supports Direct Display Mode For VR HMDs

    The AMDVLK open-source Radeon Vulkan Linux driver has seen its latest weekly code drop that brings with it some of the extensions needed for supporting the Steam VR experience...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Question is still why someone should use it over RadV in the first place with it being still mostly slower and less compatible.

    RadV btw. shows lower input latency in SS: Fusion and some other titles. Nvidia's Vulkan driver also has higher input latency. I suppose RadV limits the frame buffer queue to 1, while other drivers buffer 2 or 3 frames unless told otherwise by the game (imho RotTR feels like 1 also with Nvidia).

    Comment


    • #3
      wait so, will new oss like fuchsia , menuet or redox be forced to emulate x11 , and wayland to use xwayland , to use vr ? will this be fixed with openxr ( khronos vr) ?

      Comment


      • #4
        bridgman agd5f davidmaoAMD airlied

        This is a bit offtopic,, but Vulkan related

        My personal petition/question/proposal...

        Is it possible to merge both AMDVLK and RADV? I see the current situation a waste of resources and lack of community collaboration.

        If that's not entirely possible: What about merge as much code as possible into RADV and put the platform agnostic code on top of it? It seems this happens in some way in the DC/DAL code and such.

        This would benefit into having a common codebase and ONE community working together. Maybe the Windows bits need to be proprietary, but I would like them to be Open Source too (I think about ReactOS, for example).

        Niche/Windows/videoconsole platforms could use MESA or the "AMDVLK" (non-MESA dependent code part) way.

        My personal ideal solution would be to "kill two birds with one shot": Share as much as code as possible to avoid NIH syndrome

        Please consider it and try to discuss it with your AMD bosses, please.

        nhaehnle marek

        What do you think?

        PS: I have been trying different VR glasses and the feeling is amazing! I still miss some more resolution in them, becoming comfortable. But the most important is the HID interface in the hands like some kind of advanced haptic gloves such as VRgluv, HaptX the upcoming Occulus haptic gloves and such.

        Meanwhile we can do DIY stuff like this...

        Comment


        • #5
          Originally posted by timofonic View Post
          Is it possible to merge both AMDVLK and RADV? I see the current situation a waste of resources and lack of community collaboration.

          If that's not entirely possible: What about merge as much code as possible into RADV and put the platform agnostic code on top of it? It seems this happens in some way in the DC/DAL code and such.
          If you are talking about replacing radv code with the (considerably larger because of code sharing abstractions) AMDVLK code then yes, I think that would be do-able although it would be a tough sell to upstream even once we get to the point where we can replace the "weekly drop" update model with a more finely grained one that maintains a more useable commit history.

          If you are talking about going the other way, then you would basically be asking AMD to replace our (quite successful) Windows Vulkan driver with radv and essentially giving up control of architectural direction. It would also mean losing our ability to share Vulkan code across multiple OSes so significantly increase the cost of supporting new GPUs since we would no longer be sharing the PAL code we still have to develop for other APIs on each new GPU. Tough sell.

          DAL/DC was more like the first approach, in the sense that we were able to make the code upstreamable without having to break our ability to actively share it across OSes and platforms.
          Last edited by bridgman; 14 July 2018, 10:35 AM.
          Test signature

          Comment

          Working...
          X