Announcement

Collapse
No announcement yet.

1080p Linux Gaming Performance - NVIDIA 415.22 vs. Mesa 19.0-devel RADV/RadeonSI

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

  • #51
    Originally posted by bridgman View Post

    This does sound like shaders being uncached at first (so you get compilation delay) and then cached after a while.

    How often were you updating the open source drivers ?
    I think it sound like sound related stutter , when it loads some sound it stutter a bit

    Torchlight uses FMOD Ex, that offloads/plays the best on Sound Blaster's hardware acceleration or your's AMD True Audio

    There are sound related stutter particulary more when using WINE
    Last edited by dungeon; 12-17-2018, 12:32 PM.

    Comment


    • #52
      Interesting, hadn't thought about that. Is there a good way to check, eg disabling sounds somehow ?

      Comment


      • #53
        Yes, it have config setting NO SOUNDS. The best is also to boot without sound driver, to be absolutely sure

        I guess it have some effects enabled with that FMOD Ex and that is a bit more CPU intensive, thus it stutter.

        It even have SOUND VARIATION set to 3, whatever that is Even have LOW_RESOURCE_AUDIO option, SOUND DEBUG, guys like to play with sound Anyway, games are not just about graphics, but beautuful CPU intensive sound too

        And of course if all that happens on single thread shit will happen

        When you use default WINE using with GL translation then video skip sound too consistently, that is a sign that sound is CPU intensive really

        Graphics related so Mesa related is only HW skinning feature, that even missrender, instead to accelerate it there... probably Marek should look at that, SW Mesa seems have no idea about that too

        It have all shaders in folder, very readable and commented
        Last edited by dungeon; 12-17-2018, 01:58 PM.

        Comment


        • #54
          Originally posted by TemplarGR View Post

          Nice Anti-AMD FUD, i doubt you have ever bought an AMD product in your life. Also if you "fuck the open drivers", then why are you on Linux? Use Windows. AMD has far superior Windows driver to Nvidia, try them.
          ~ >>> inxi -bM
          System: Host: mjb Kernel: 4.19.8-16-tkg-cfs x86_64 bits: 64 Desktop: KDE Plasma 5.14.4 Distro: Manjaro Linux
          Machine: Type: Desktop Mobo: ASUSTeK model: TUF B450M-PLUS GAMING v: Rev X.0x serial: <root required>
          UEFI: American Megatrends v: 0601 date: 10/29/2018
          CPU: 6-Core: AMD Ryzen 5 2600 type: MT MCP speed: 3990 MHz min/max: 1550/4000 MHz
          Graphics: Device-1: Advanced Micro Devices [AMD/ATI] Ellesmere [Radeon RX 470/480/570/570X/580/580X] driver: amdgpu v: kernel
          Display: x11 server: X.Org 1.20.3 driver: amdgpu resolution: 1920x1080~60Hz
          OpenGL: renderer: Radeon RX 580 Series (POLARIS10 DRM 3.27.0 4.19.8-16-tkg-cfs LLVM 7.0.0)
          v: 4.5 Mesa 19.0.0-devel (git-2c5904f048)
          Network: Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet driver: r8169
          Drives: Local Storage: total: 700.51 GiB used: 228.49 GiB (32.6%)
          Info: Processes: 268 Uptime: 1d 7m Memory: 15.66 GiB used: 3.89 GiB (24.8%) Shell: zsh inxi: 3.0.28

          no AMD products ?

          About the f word, I'm sorry for having said that, that was totally out of line and unneeded.


          Originally posted by bridgman View Post

          This does sound like shaders being uncached at first (so you get compilation delay) and then cached after a while.

          How often were you updating the open source drivers ?
          Almost daily, I also test wip kernels to check improvements.

          The sound thing is interesting, I know disabling it in game made no difference but I've never tried disabling it at lower levels.

          I suspected I/O issues also, but my SSD is pretty fast. I've tried switching cpu and i/o schedulers without luck. Something I've got yet to try is putting the game in a ramdisk and running from it.

          Comment


          • #55
            Originally posted by clapbr View Post
            ~ >>> inxi -bM
            System: Host: mjb Kernel: 4.19.8-16-tkg-cfs x86_64 bits: 64 Desktop: KDE Plasma 5.14.4 Distro: Manjaro Linux
            Machine: Type: Desktop Mobo: ASUSTeK model: TUF B450M-PLUS GAMING v: Rev X.0x serial: <root required>
            UEFI: American Megatrends v: 0601 date: 10/29/2018
            CPU: 6-Core: AMD Ryzen 5 2600 type: MT MCP speed: 3990 MHz min/max: 1550/4000 MHz
            Graphics: Device-1: Advanced Micro Devices [AMD/ATI] Ellesmere [Radeon RX 470/480/570/570X/580/580X] driver: amdgpu v: kernel
            Display: x11 server: X.Org 1.20.3 driver: amdgpu resolution: 1920x1080~60Hz
            OpenGL: renderer: Radeon RX 580 Series (POLARIS10 DRM 3.27.0 4.19.8-16-tkg-cfs LLVM 7.0.0)
            v: 4.5 Mesa 19.0.0-devel (git-2c5904f048)
            Network: Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet driver: r8169
            Drives: Local Storage: total: 700.51 GiB used: 228.49 GiB (32.6%)
            Info: Processes: 268 Uptime: 1d 7m Memory: 15.66 GiB used: 3.89 GiB (24.8%) Shell: zsh inxi: 3.0.28

            no AMD products ?

            About the f word, I'm sorry for having said that, that was totally out of line and unneeded.



            Almost daily, I also test wip kernels to check improvements.

            The sound thing is interesting, I know disabling it in game made no difference but I've never tried disabling it at lower levels.

            I suspected I/O issues also, but my SSD is pretty fast. I've tried switching cpu and i/o schedulers without luck. Something I've got yet to try is putting the game in a ramdisk and running from it.
            I've already told you bro, it's almost certainly a tearing issue you described. Take a visit to your distro's wiki and learn how to enable tearfree in your xorg.conf. That almost certainly will olve it.

            Comment


            • #56
              Originally posted by duby229 View Post

              I've already told you bro, it's almost certainly a tearing issue you described. Take a visit to your distro's wiki and learn how to enable tearfree in your xorg.conf. That almost certainly will olve it.
              it is not tearing, and of course I've already tried every possible config for refresh sync including forcing pageflip on/off, no sync, tearfree, game's vsync, all vblank_mode(s), disabling specific sync extensions, turning compositor on/off, compositor's vsync windowed.

              edit: forgot to mention I already tried playing with nice levels and limits and also Feral's gamemode.

              edit2: also forgot to mention the most important info: the stutters doesn't happen with amdgpu.dc=0 but I have worse issues with old DC.
              Last edited by clapbr; 12-17-2018, 07:06 PM.

              Comment


              • #57
                Originally posted by clapbr View Post

                it is not tearing, and of course I've already tried every possible config for refresh sync including forcing pageflip on/off, no sync, tearfree, game's vsync, all vblank_mode(s), disabling specific sync extensions, turning compositor on/off, compositor's vsync windowed.
                The only time I ever saw tearfree not work was on a old 72hz monitor with a weird modeline. You might want to look into generating a custom modeline for the mode you use and see if that makes any difference.

                EDIT: I will say that AMD's drivers -do not- handle the modelines for TV's and other odd displays very well at all. For many displays you just have to make custom modelines for it.
                Last edited by duby229; 12-17-2018, 07:05 PM.

                Comment


                • #58
                  Originally posted by duby229 View Post

                  The only time I ever saw tearfree not work was on a old 72hz monitor with a weird modeline. You might want to look into generating a custom modeline for the mode you use and see if that makes any difference.

                  EDIT: I will say that AMD's drivers -do not- handle the modelines for TV's and other odd displays very well at all. For many displays you just have to make custom modelines for it.
                  I tried custom modelines and dumped edids from both linux and windows with a updated AOC driver. You didnt understood, TearFree does what is supposed to and works well (with the fast cursor plane patch for the new DC, without it you get stutters when moving the mouse around https://bugs.freedesktop.org/show_bug.cgi?id=106175 )
                  This is the monitor http://us.aoc.com/en/gaming/products/g2460vq6

                  edit: thanks for all suggestions but most likely I've already anything easily googlable. I suspect other people have similar issues but for various reasons won't notice, maybe people already have pretty lowbar expectations for linux gaming but thats just a guess.

                  now I'm curious, how many of you noticed the cursor path issue?
                  Last edited by clapbr; 12-17-2018, 07:29 PM.

                  Comment


                  • #59
                    Originally posted by clapbr View Post
                    edit2: also forgot to mention the most important info: the stutters doesn't happen with amdgpu.dc=0 but I have worse issues with old DC.
                    OK, that's interesting (and not what I expected). Any suspicious log errors ?

                    Are the "worse issues with old DC" (do you mean the pre-DC display code or early DC ?) related to stuttering as well ? Guessing no...

                    Comment


                    • #60
                      Originally posted by bridgman View Post

                      OK, that's interesting (and not what I expected). Any suspicious log errors ?

                      Are the "worse issues with old DC" (do you mean the pre-DC display code or early DC ?) related to stuttering as well ? Guessing no...
                      Nothing suspicious in dmesg and xorg log.

                      The bad issue with amdgpu.dc=0 is not waking up after sleeping for a long time. It doesn't happen with the default dc=1.

                      Comment

                      Working...
                      X