Announcement

Collapse
No announcement yet.

Radeon RX Vega OpenGL Linux Performance For September 2017

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

  • #31
    Originally posted by debianxfce View Post
    We all know that you have latest and greatest hardware like 4k monitors. Majority of people do not waste money to 4k gaming, so this article is not useful.
    Your comment makes no sense.

    If you are doing 4k only for productivity tasks, you don't need to spend anything near the money for Vega.

    For anyone debating upgrading to a 4k monitor vs spending the money on Vega the monitor will be a much more beneficial upgrade.

    If you're gaming at 1080p a 480/580 will be more than enough, and has been for some time.

    You don't have to read every single article on the site. The title gives you a pretty good idea of the contents if you just want to skip it.

    Comment


    • #32
      Originally posted by Geopirate View Post
      If you're gaming at 1080p a 480/580 will be more than enough, and has been for some time.
      Yep.
      My R9 290 which I bought almost 4 years ago does great at 1080p.
      GPUs like Vega and GTX 1080 are meant for higher resolutions.

      Comment


      • #33
        Originally posted by oleyska View Post

        only the deus ex logo gets artifacts, this happens elsewhere but it's an easy test..


        There are also a number of other artifacts.

        Currently:
        4K res.
        Vega 64
        Ryzen 1700
        ubuntu 17.10
        Wayland and X does it.

        oleyska@oleUbuntu:~$ glxinfo | grep render
        direct rendering: Yes
        GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer,
        GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer,
        Extended renderer info (GLX_MESA_query_renderer):
        OpenGL renderer string: AMD VEGA10 (DRM 3.20.0 / 4.13.0-rc5-phx-amdgpudc, LLVM 5.0.0)
        GL_ARB_compute_variable_group_size, GL_ARB_conditional_render_inverted,
        GL_NV_conditional_render, GL_NV_depth_clamp, GL_NV_packed_depth_stencil,
        GL_ARB_conditional_render_inverted, GL_ARB_conservative_depth,
        GL_NV_blend_square, GL_NV_conditional_render, GL_NV_depth_clamp,
        GL_OES_element_index_uint, GL_OES_fbo_render_mipmap,
        oleyska@oleUbuntu:~$ uname -r
        4.13.0-rc5-phx-amdgpudc
        One more test: If the human character models in the benchmark suddenly have blue skin, then this is the same artifacting issue that I had on my system a while ago. It's a mesa bug. Make sure you only have one version of mesa installed (instead of say, one installed to /usr and another to /usr/local), and update to the latest version. If you're already on the latest version of mesa, it can be good idea to delete the shader cache, and see if the issue is still there. If it's still present in the latest mesa commit, you would do well submit a bug report to the tracker.

        Comment


        • #34
          Originally posted by randomsalad View Post

          One more test: If the human character models in the benchmark suddenly have blue skin, then this is the same artifacting issue that I had on my system a while ago. It's a mesa bug. Make sure you only have one version of mesa installed (instead of say, one installed to /usr and another to /usr/local), and update to the latest version. If you're already on the latest version of mesa, it can be good idea to delete the shader cache, and see if the issue is still there. If it's still present in the latest mesa commit, you would do well submit a bug report to the tracker.
          I can only find mesautils being in an older version as required by playonlinux
          but yeah they're smurfs...

          Comment


          • #35
            If on a debian-like system, the system packages to look for are called libgl1-mesa-dri, libgl1-mesa-glx, so on and so forth. mesautils is just a package with some version independent tools, such as glxinfo and glxgears. You can do
            Code:
            find /usr -name *radeonsi* 2>&1 | grep -v "Permission denied"
            to look for versions of mesa installed under /usr. On a debian-like system, there should only be stuff under /usr/lib/x86_64-linux-gnu and /usr/lib/i386-linux-gnu, but none under /usr/local (the default install path if you ever compiled mesa yourself).

            But before doing any of that, a few other things to try doing: deleting the local shader cache and letting the game rebuild them from scratch. The cache is either stored in .cache/mesa, .cache/mesa_shader_cache, or in the case of steam applications, under .steam/steamapps/shadercache/<steam_appid> (When did steam start doing this?).

            Comment


            • #36
              Originally posted by LeJimster View Post

              I was thinking the extra threads might come in handy when it comes to compiling stuff. The prices seem to be slowly dropping aswell. Will have to see. Maybe the 1600 is better value.
              Depends on what you are compiling and how well it can be parallelized. IMO, the real advantage for Ryzen 7 is sending -j12 and still having 4 threads to use for other tasks.

              Comment

              Working...
              X