Announcement

Collapse
No announcement yet.

NVIDIA Releases 381.26.08 Vulkan Beta Driver With New Extensions

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

  • NVIDIA Releases 381.26.08 Vulkan Beta Driver With New Extensions

    Phoronix: NVIDIA Releases 381.26.08 Vulkan Beta Driver With New Extensions

    NVIDIA has once again managed a same-day driver update for matching a new Vulkan release...

    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
    Why AMD not update Vulkan ?
    Still version 1.0.39 (in Windows, 17.7.1)

    Comment


    • #3
      This driver dont support GT 1030 ?

      But support more older gpus case GT 710

      Comment


      • #4
        Originally posted by mphuZ View Post
        Why AMD not update Vulkan ?
        Still version 1.0.39 (in Windows, 17.7.1)
        The windows team is probably too busy with the Vega drivers (which are apparently right now a shambles) while the Linux team is too busy with getting DC/DAL ready for being mainlined.

        Comment


        • #5
          Originally posted by L_A_G View Post
          DC/DAL
          And why only the Linux command them busy ?
          DAL is not common to Linux and Windows ?

          Comment


          • #6
            Originally posted by mphuZ View Post
            And why only the Linux command them busy ?
            DAL is not common to Linux and Windows ?
            From what I've understood DAL/DC is code is for the most part adapted from the pre-existing Windows driver code base. The reason why Linux DAL/DC hasn't been merged yet is because it's in the process of being cleaned up and restructured. When they first showed the code David Airlie, the lead DRM maintainer, complained that they needed to do a lot of re-structuring and cleanups to get rid of clutter and unnecessary abstraction layers (most probably stemming from it being adapted Windows code).

            Comment


            • #7
              Originally posted by L_A_G View Post
              From what I've understood DAL/DC is code is for the most part adapted from the pre-existing Windows driver code base. The reason why Linux DAL/DC hasn't been merged yet is because it's in the process of being cleaned up and restructured.
              Nope - the code was written from scratch in order to comply with kernel coding standards among other things, and was only being used by the Linux driver when we first published it for review. It is still going to be shared across multiple OSes (more than just Windows) and that's where the main abstraction layer comes in, since that's how all of the other drivers interface with it.

              Originally posted by L_A_G View Post
              When they first showed the code David Airlie, the lead DRM maintainer, complained that they needed to do a lot of re-structuring and cleanups to get rid of clutter and unnecessary abstraction layers (most probably stemming from it being adapted Windows code).
              Sort of... between the time the code was written and the time we were able to first make it public a lot of things changed in the Linux kernel (like atomic modesetting) so we focused first on those. We were hoping we could replace the abstraction layer with Linux-specific calls into lower level functions after the code was upstream so we wouldn't be stuck in a constant tail-chase trying to keep up with the kernel and restructure the code at the same time, which in turn would give us a chance to get the code restructured while it was still only being used in the Linux drivers.

              That didn't happen, so now we are unfortunately trying to (a) keep up with the kernel (not bad so far), (b) restructure the code to interface at a lower level for Linux while maintaining the high level interface for other OSes, (c) integrate the code into all of the other platforms that our shared display logic needs to support and (d) continue adding support for new HW, all at the same time.

              BTW it's the display team working on re-architecting the display code, not the Linux-specific teams.
              Last edited by bridgman; 14 July 2017, 08:39 AM.
              Test signature

              Comment


              • #8
                Originally posted by bridgman View Post
                Nope - the code was written from scratch in order to comply with kernel coding standards among other things, and was only being used by the Linux driver when we first published it for review. It is still going to be shared across multiple OSes (more than just Windows) and that's where the main abstraction layer comes in, since that's how all of the other drivers interface with it.
                I wonder how I got the impression that it was adapted Windows code? Probably went too far with my assumptions when I read about the code sharing and just assumed that you were re-purposing Windows code the same way Nvidia is (from what I've understood, thou I could be wrong again).

                Sort of... between the time the code was written and the time we were able to first make it public a lot of things changed in the Linux kernel (like atomic modesetting) so we focused first on those. We were hoping we could replace the abstraction layer with Linux-specific calls into lower level functions after the code was upstream so we wouldn't be stuck in a constant tail-chase trying to keep up with the kernel and restructure the code at the same time, which in turn would give us a chance to get the code restructured while it was still only being used in the Linux drivers.

                That didn't happen, so now we are unfortunately trying to (a) keep up with the kernel (not bad so far), (b) restructure the code to interface at a lower level for Linux while maintaining the high level interface for other OSes, (c) integrate the code into all of the other platforms that our shared display logic needs to support and (d) continue adding support for new HW, all at the same time.
                Well I guess that explains a lot about the constant delays in getting DC/DAL merged into the mainline. Not being totally in tune with the driver-OS interface world (more of an application and tools person) I didn't fully realize how much additional work changes like atomic mode setting were for driver devs. Instead I assumed most of the issues were related to creating more standard interfaces between the kernel and your own internal driver structure, which is obviously a massive amount of work requiring some very tight coordination (I've once or twice had to do something similar except on a much smaller scale so I understand the challenge).

                BTW it's the display team working on re-architecting the display code, not the Linux-specific teams.
                Well that's interesting... Thought that you wouldn't have platform independent teams like that just yet, but moving to have much heavier code sharing between OSs I guess it was to be expected that teams would become independent or new independent teams would be created sooner or later.

                Comment


                • #9
                  Yep, I think we set up the first platform-independent teams around 1999 or so - DAL/display and CMM (common memory manager) were the first IIRC, although most of the userspace teams were writing platform-independent code by ~2003 or so. This wasn't just for "Windows and something else" sharing though - at the time different Windows generations were sufficiently different internally that they might as well have been separate OSes too.
                  Test signature

                  Comment

                  Working...
                  X