Announcement

Collapse
No announcement yet.

AMD's Latest Open-Source Driver On Linux Is Getting Competitive With Catalyst 15.7

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

  • #21
    Originally posted by eydee View Post
    Problem is these benchmarks are all about fps, nothing more. However, Catalyst has some serious microstuttering. 40 fps on OSS drivers feels smooth, 60 fps on Catalyst feels like as if it was 25. Catalyst also doubles loading times for some games, especially for source games. The upside is ease of use, GPU scaling and having the ability to have application controlled vsync.
    You aren't alone, I have the same issues. It seems like the solution is having FPS so high that only once every few minutes do you notice one.

    Comment


    • #22
      Nobody got that CS:GO has no CAP, that's why OSS is relatively fast for some cards...

      Comment


      • #23
        Originally posted by zanny View Post

        Oh god please don't ask the scant few Radeon devs to put more work into GLAMOR when it is already perfectly good at what it does. Many desktops aren't using xrender anymore in the first place, Wayland will never use 2d, and any desktops still using it have GLAMOR performing more than sufficient for the job. Make the 3d engine faster / implement the rest of OGL. My 290 is smooth as butter in either OGL or Xrender mode on Kwin, but I would really like to see it start beating integrated GPUs by more than the margin of error at some point.
        GLAMOR performance is good enough for the desktop but the glyph corruption bug with Firefox and Thunderbird is still there, at least in Debian. I found this on IRC but it's from well over a year ago:
        07:52 #radeon: < zgreg> MrCooper: the copyarea optimization patchset actually seems to fix the glyph corruption, maybe it was something different than I thought, or it's a side effect of the change. I haven't looked any further into this.

        Comment


        • #24
          Hi Michael,

          Would it be possible to include a cpu overlay with the fps results?
          It's be nice to know when we're cpu-limited and how much overhead the gallium framework imposes.

          Best/liam

          Comment


          • #25
            Originally posted by humbug View Post
            The only thing the CS:GO tests prove is that the driver overhead is so bad that it has become the dominating factor in determining performance. Not the actual capabilities of the hardware. How else can you explain a 6950 beating a 370 and 290. We almost never see things like this happening in DirectX.

            6950 is using r600 while the others are using the newer architecture and less mature si driver.
            NOTHING to do with ogl.

            Comment


            • #26
              Originally posted by rrohbeck View Post

              GLAMOR performance is good enough for the desktop but the glyph corruption bug with Firefox and Thunderbird is still there, at least in Debian. I found this on IRC but it's from well over a year ago:
              07:52 #radeon: < zgreg> MrCooper: the copyarea optimization patchset actually seems to fix the glyph corruption, maybe it was something different than I thought, or it's a side effect of the change. I haven't looked any further into this.
              Yup that was xserver 1.16 bug, comment was for 1.17 early development where it should be fixed... AFAIR it affect only mozzila software, and only xrender because 'gfx.xrender.enabled false' does not show the issue... so if not upgrading xserver using cairo/pixman can be sort of workaround.

              Comment


              • #27
                Originally posted by liam View Post
                6950 is using r600 while the others are using the newer architecture and less mature si driver.
                NOTHING to do with ogl.
                There also huge issue that a lot of improvements for SI depend on newer LLVM.

                Comment


                • #28
                  Originally posted by SXX⁣ View Post
                  There also huge issue that a lot of improvements for SI depend on newer LLVM.
                  That might be issue for some packagers i guess, while radeon/amdgpu driver developers use current llvm all the time

                  For OpenGL look at it just as shader compiler, 6 months old shader compiler... Virtually spoken compare that like current intel driver which uses mesa 10.7-dev but with shader compiler from 10.4

                  edit: btw from few hours ago llvm trunk is now at 3.8
                  Last edited by dungeon; 14 July 2015, 08:49 PM.

                  Comment

                  Working...
                  X