Announcement

Collapse
No announcement yet.

Open-Source Radeon Performance Boosted By Linux 3.16

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

  • #51
    Originally posted by Azpegath View Post
    Isn't it time to enable hyperz by default, and just deal with the bugs that will come in, and fix them? I know the developers have a lot to do, but leaving half-finished features in, and never enabling them for most users is really sad.
    People who know what HyperZ is can easily enable it if. But most people probably don't know what it is and probably prefer a little performance hit by default over being exposed to a number of known GPU hang bugs. That's why we can't enable it by default as long as there are such bugs.

    Of course, patches enabling it via drirc for games where it's known to be reliable and provide a big boost are welcome.

    Comment


    • #52
      I heard than DPM was disabled by default, that could help to better performance, in my case 3d performance its worst with it activated, when I want to play I have to activate dpm in the kernel boot line and then set the performance variable.
      But still with hyperz activated, in my hd 4200 it has problems running TF2 properly. Does the desktop environment influence the performance? Do I will get more fps if I use openbox instead cinnamon? Im just wondering.

      Comment


      • #53
        Originally posted by blackiwid View Post
        The only argument for free drivers is updateabiltiy but what does that bring on a pure gaming machine? And that maybe the proprietary games have only user privileges so they cant as easily root-kit your system, but especialy if you would use steamos which every system is exactly the same the security holes would be easy and can be used to install from a vendors game or from valves steam itself a rootkit.

        And is that totaly cracy idea, google sony rootkit and you you see no, its totaly reasonable to think that its not to unlikly to happen.
        Ability to skipp glGetError, and just break at ANY mesa function (including _mesa_error and really, any _mesa_OpenGP-function-name), are great benefits to the game devs.
        Also Intel/AMD/Nouveau folks can talk about their work openly, no NDA (which help spread good practicies, which help build better code, which helps build better drivers, which helps us gamers, users of GPU).
        Lets not forget about game devs being able to send patches directly if during debugging they would found any bugs.
        And most importantly all of above is accessible to SMALLEST ONE-MAN-ARMY NOBODY-KNOW-ABOUT indie dev, instantly. We do not need to wait for big 3 to kindly recognize anybody (Dolphin crew comes to mind).
        On top of that there is long term benefit of better GPU driver engineers, who can start familiarizing themselfs with GPUs, even before they start working for given company.


        So there are tons of advantages to FLOSS drivers.

        Some of them solve big issues, that OpenGL/DX currently have sticked onto in debate about what should be next gen API.

        Comment


        • #54
          Originally posted by stqn View Post
          I?m having a hard time finding information about an HD7580? Did you mean 7850? Or 7580D?
          Oh, sorry, I meant 7850

          Comment


          • #55
            Originally posted by geearf View Post
            Tom fixed that bug last week, unfortunately my game (DIII) now freezes within a minute... so not much better, but at least I get a minute of gaming instead of 0...
            *ROFL*

            Comment


            • #56
              It's not really fixed:

              Originally posted by https://bugs.freedesktop.org/show_bug.cgi?id=75276#c26
              I've pushed a work-arond for the crash to LLVM trunk, so if you use the latest version of LLVM from svn/git these games should not crash, but there may be some mis-rendering.

              When I come up with a proper fix, I will post it to this bug (this could be a while).

              Comment


              • #57
                Originally posted by liam View Post
                So VM is referring to virtual memory. So, how was memory handled prior to SI (excluding, iirc, trinity/richland)? It just used an unprotected flat memory space? So the driver was then responsible for making sure the process (context) addressed the proper segment of memory?
                Yeah, the kernel driver was passed a list of buffer handles and a list of "relocs", ie places in the command stream where buffers were referenced. After making sure that each buffer was owned by the right process and pinning the buffers down into physical memory, the kernel driver patched the command stream to insert the physical addresses in the right spots.

                With VM the kernel driver just has to set up page tables so that the virtual addresses used by the GPU get translated to the right physical addresses and all other accesses go to a dummy page or fail.
                Test signature

                Comment


                • #58
                  Originally posted by bridgman View Post
                  Yeah, the kernel driver was passed a list of buffer handles and a list of "relocs", ie places in the command stream where buffers were referenced. After making sure that each buffer was owned by the right process and pinning the buffers down into physical memory, the kernel driver patched the command stream to insert the physical addresses in the right spots.

                  With VM the kernel driver just has to set up page tables so that the virtual addresses used by the GPU get translated to the right physical addresses and all other accesses go to a dummy page or fail.
                  Thanks Bridgman!
                  I'd imagine that alone should make the SI drivers a good deal simpler.
                  I'd no idea how much SI modernized the GPU situation for AMD...

                  Comment


                  • #59
                    With 3.16rc3 and today's daily kernel, I get very slight suttering on my 7850 when moving windows around on Ubuntu + Unity. Xorg's log also mentioned something along the lines of pageflipping being impossible to meet a time deadline a good bit. Disabling page flipping stops the errors, but doesn't stop the slight random stutter.

                    Don't notice such errors or stuttering on my 7660G + 7670M muxless laptop.

                    Comment


                    • #60
                      Originally posted by Espionage724 View Post
                      With 3.16rc3 and today's daily kernel, I get very slight suttering on my 7850 when moving windows around on Ubuntu + Unity. Xorg's log also mentioned something along the lines of pageflipping being impossible to meet a time deadline a good bit. Disabling page flipping stops the errors, but doesn't stop the slight random stutter.

                      Don't notice such errors or stuttering on my 7660G + 7670M muxless laptop.
                      As i see now running 3.16-rc4 pagefliping seems fixed, does not see those messages in Xorg.log . But i don't run Ubuntu nor Unity, so can't know for that stutter matter... maybe it is fixed maybe not .

                      Kabini running never better with 3.16-rc4 . Playing with vm_block_size parameter increasing that to 12 (default is 9) also gives more performance in games something like +2-3% .
                      Last edited by dungeon; 06 July 2014, 06:04 PM.

                      Comment

                      Working...
                      X