Announcement

Collapse
No announcement yet.

NVIDIA 367.18 Beta Linux Driver Released With Many Fixes

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

  • #11
    I tried this driver version. Got XIDs and lockups. Going back to 364.19 fixed them. I have no idea what nonsense is going through NVIDIA's minds these days.

    Comment


    • #12
      In this drivers nvenc is used more compared before drivers version


      367.18




      364.19




      Normally at 48fps recording nvenc stay around 24% of use but in 368.17 use up to 36 to 40% of use

      Also nvenc stay using more bitrate compared before versions: normally use around 6000 to 8000kb/s but in this driver use now around 11000 to 15000kbs in some cases like samurai warriors 4 II (quality improve in 367.18)

      And cpu use seems a bit lower compared with same test on 364.19

      However in race games nvenc use more bitrate, maybe with more race game type test can see more deeper this behavior

      Last edited by pinguinpc; 20 May 2016, 08:33 AM.

      Comment


      • #13
        Originally posted by magika View Post
        That is not the same issue. KWin corruption was happening due to driver invalidation of vertex buffers, which is afaik legit driver behaviour. KWin guys introduced a hack where if nvidia driver is detected VBO would be recreated after a second in some situations.
        Nobody in the OpenGL spec does it say that buffer object contents may randomly get discarded; heck, there's not even a mechanism in GL for the driver to report texture/buffer losses to the app (not counting this NV extension).

        It's crazy though; can you imagine getting a notification from the OS saying "sorry, all your heap allocations are now invalid, please reinitialize them?". The program may as well crash at that point.

        Comment


        • #14
          @pinguinpc

          The change in nvenc might show a different code due to addons of Pascal, but could be just different defaults by accident.

          The next readme will be much more interesting as a new VDPAU class must be there for Pascal with hardware HEVC 10/12 bit support. It seems the GTX 960 can decode that with a hybrid approach on Windows just like Broadwell/Skylake but Linux did not get the hybrid driver. The only hybrid decode is VC1 with some old chips that could not decode it correctly in hardware only. Btw. i expect series 368+ for Pascal because Windows drivers for Pascal are already at this series for the press drivers. A bit sad for existing GTX 950/960 owners however, the GM206 chip was pretty nice but without HEVC 10 bit decode you have to replace it if you want to watch 4k tv stations with Linux. Hopefully GP106 cards (logically GTX 1050/1060) will not take too much time - as the first samples have been already shipped my guess is 4 months from now, in time for Xmas...

          Comment


          • #15
            Originally posted by SaucyJack View Post
            Obviously. And no, they shouldnt.
            except they really should if they care about cross platform and performance.

            Comment


            • #16
              Originally posted by cj.wijtmans View Post
              except they really should if they care about cross platform and performance.
              Cross platform? Wayland and current wayland compositors are tied to Linux, so I don't see them caring much about that. Also, do you have any numbers regarding "performance"?

              Comment


              • #17
                https://devtalk.nvidia.com/default/t...x-950-361-28-/

                Today, the driver doesn't support MAIN 10, although the hardware does (hence why MAIN 10 works on windows). It will require major vdpau changes to fully support as vdpau assumes 8bit surfaces throughout its pipeline and that will need to change.
                GM206(Feature Set F hardware decoder) fully supports HEVC Main10 hardware decoding & it's fully working on Windows, it's not available on Linux because VDPAU doesn't support 10bit/12bit surfaces yet. Hopefully Nvidia can update VDPAU to support 10bit & 12bit surfaces for Main10(GM206) & Main12(GP10x).

                Pascal GP10x family has more advanced Main12 hardware decoding(Feature Set G hardware decoder) & Main10 10bit hardware encoding(NVENC).
                Last edited by GT220; 20 May 2016, 09:05 AM.

                Comment


                • #18
                  Originally posted by cj.wijtmans View Post
                  except they really should if they care about cross platform and performance.
                  Waving a big flag around that says 'I'm a Nvidia shill'. Wayland is already cross platform if you include mobile and embedded. I know how badly Nvidia wants a Nvidia platform they have absolute control over, but that's not reality. And performance? That's been debunked by the Wayland guys unless you're sitting on some unreleased benchmarks you'd care to share?

                  Comment


                  • #19
                    Originally posted by SaucyJack View Post
                    Wayland is already cross platform if you include mobile and embedded.
                    And yet it hasn't figured out how to handle pointer locking properly. But hey, it's only at it's tenth release.

                    Comment


                    • #20
                      Originally posted by bug77 View Post

                      And yet it hasn't figured out how to handle pointer locking properly. But hey, it's only at it's tenth release.
                      Never said it didn't have issues and that they don't need to get the lead out of their ass and get the Wayland stack working properly preferably sometime last year, but that's not relevant to EGLstreams.

                      Comment

                      Working...
                      X