Announcement

Collapse
No announcement yet.

NVIDIA Announces The GeForce GTX 1060, Linux Tests Happening

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

  • #91
    Originally posted by dungeon View Post
    I guess because availbility and prices, RX 480 sells like hot cakes there
    It sold just as well as GTX 1080 did.
    Which is even more impressive for GTX 1080 considering it's relatively small market share compared to ~$250 GPUs.

    Comment


    • #92
      Originally posted by Slartifartblast View Post
      To quote Jean-Claude Juncker, "Why are you still here ?". This is about Nvidia.
      Sorry, perhaps I misread Kano's comment. It appeared to be talking about AMD drivers. Are you saying his comment was really about NVidia drivers ?
      Test signature

      Comment


      • #93
        Originally posted by Kano View Post
        And with your Mesa example: it won't work out of the box until a new mesa/kernel is officially released, not sure if kernel 4.7 is enough and a distro ships it (for AMD you need new LLVM too which is a bit problematic for backports). Maybe next year AMDGPU can be used for GCN 1.0 parts too then AMDGPU-PRO drivers can be used for those too if needed. If you are no gamer why would you buy a 200+ $/€ card? If you are why should you pay more for a less compatible/slower card? Do you think game devs switch over to AMD soon as first target? Don't forget you could certainly get cheaper used GTX 9xx cards too for upgrades.
        I use Gentoo. I've run bleeding edge kernel/libdrm/llvm/mesa for a long time. Just got done playing "Middle-Earth: Shadow of Mordor" on open source AMDGPU and my 390X on a 4k display (though I played it at 1440p).

        I'm paying for good cards that support open source. If your morals don't align with that, I'm sorry.

        Comment


        • #94
          Originally posted by atomsymbol
          I have a similar config on Gentoo, but it has issues playing accelerated videos. Could you please test the following steps on your machine and tell me whether you can replicate the issue?

          1. Open a youtube.com video in Chrome.
          2. Set playback speed to >= 1.25.
          3. Check for synchronization between the video and the audio.
          4. After playing an accelerated video for a while, the audio-video synchronization gets lost.
          I'm unable to replicate your issue. I tried a few different videos (especially some of those GoPro videos provide good audio-video synchronization content in 4k). I used Chrome, but I can try chromium too. In my experience firefox runs smoothly while chromium tears and stutters, even with Netflix.

          The kernel I'm running is agd5f's drm-next-4.8 branch.

          Mesa 12.1.0-devel (git-b479c47)
          OpenGL renderer string: Gallium 0.4 on AMD HAWAII (DRM 3.2.0 / 4.7.0-rc5+, LLVM 3.9.0)

          =media-libs/mesa-9999
          =sys-devel/clang-9999
          =sys-devel/llvm-9999
          =x11-drivers/xf86-video-amdgpu-9999
          =x11-libs/libdrm-9999

          Comment


          • #95
            Originally posted by atomsymbol

            Thanks for the test.

            How about this: mplayer -vo gl video-h264.mkv
            Installed mplayer just for you (I usually use mpv). Seems fine!


            Originally posted by atomsymbol
            Is there an advantage to running agd5f kernel compared to 4.7-git on R9 390?
            Yep, see this quote:
            Originally posted by bridgman View Post
            The pull request also contains patches which pick up new SMC microcode (with a _k suffix) for some SI/CI boards, which may improve stability for 390/390X users.
            The performance in this kernel is much, much better than it was for me on 4.7. I wasn't able to do much beyond basic desktop usage. I also no longer have to set performance/high dpm manually to avoid the machine freezing up.

            Comment


            • #96
              Originally posted by atomsymbol

              I think that in the general stuttering will be solved when the market moves to >= 144Hz monitors. I currently have a 60Hz display, the next one I buy to replace it (don't know when) will run at more than 60Hz.

              I don't know why they chose 144Hz to be the next standard refresh frequency.

              Edit: 60*24 = 1440, so it makes sense to me now.
              I agree. I decided to go with 4k over moar hertz for now, but when I can get a 4k monitor with 144 Hz for a reasonable price I will be happy.

              +1 to the multiple of 24 thing... the industry is weird

              Comment


              • #97
                Originally posted by atomsymbol

                I just tried agd5f's drm-next-4.8 branch. I measured no performance advantage over normal linux-git (Shadow of Mordor, Tomb Raider, glxgears).



                I have the _k patch as well (in normal linux-git). It lowers power consumption and keeps fan noise down.

                I additionally have a non-public patch to lower the memory clock on R9 390. This reduces desktop power consumption by about 40 watts compared to running memory at the default highest clock. Automatic mclk adjustment has some issues unfortunately, so I am adjusting mclk manually for now.
                Perhaps the _k patch alone solved a lot of problems for me.... I haven't tried it outside of the drm-next-4.8 branch. Everyone I've seen has claimed slightly different issues and kernel versions with the 390/390X.

                Comment


                • #98
                  There may be multiple issues being discussed here:

                  - reported performance regression on 290 (and 390 ?) which (AFAIK) affects the open source drivers in the 4.7 kernel but which has not made it into the AMDGPU-PRO kernel driver.

                  - stability issues, supposedly on 390 only, which the _k microcode has been reported to help with
                  Test signature

                  Comment


                  • #99
                    Originally posted by bridgman View Post
                    There may be multiple issues being discussed here:

                    - reported performance regression on 290 (and 390 ?) which (AFAIK) affects the open source drivers in the 4.7 kernel but which has not made it into the AMDGPU-PRO kernel driver.

                    - stability issues, supposedly on 390 only, which the _k microcode has been reported to help with
                    Yes, I think the performance regression hit most (all?) 290 owners and only some 390 owners (myself being unlucky).

                    Comment


                    • Originally posted by Passso View Post
                      So this will be 480 VS 1060. At last a real battle, the winner will get my money.

                      Fight!

                      Let Them Fight.Update Sept 2018: Okay, I uploaded this clip 5 years ago on a bit of a whim I'm my amateurish attempts at minor video editing and i can't quit...

                      Comment

                      Working...
                      X