Announcement

Collapse
No announcement yet.

Radeon Memory Boost: Up To 50%+ Better Performance

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

  • Radeon Memory Boost: Up To 50%+ Better Performance

    Phoronix: Radeon Memory Boost: Up To 50%+ Better Performance

    Marek Olk published a set of Radeon memory management improvements today for the open-source AMD Linux graphics driver that can offer performance improvements...

    http://www.phoronix.com/vr.php?view=MTYxMzM

  • #2
    Would be nice to see some Benchmarks, especially Source based Games.

    Comment


    • #3
      But what about r300? My poor T42 feels left out

      Comment


      • #4
        Will this also benefit 2GB cards? I heard that the FOSS driver copies a lot of data back and forth between video RAM and system RAM, does this (or one of the future patches) reduce that or is it really only for limited cards?

        Comment


        • #5
          This definitely calls for a new set of benchmarks for a wide range of graphic cards.

          Comment


          • #6
            Code:
            /* This function is based on the current VRAM usage.
            	 *
            	 * - If all of VRAM is free, allow relocating the number of bytes that
            	 *   is equal to 1/4 of the size of VRAM for this IB.
            
            	 * - If more than one half of VRAM is occupied, only allow relocating
            	 *   1 MB of data for this IB.
            	 *
            	 * - From 0 to one half of used VRAM, the threshold decreases
            	 *   linearly.
            	 *         __________________
            	 * 1/4 of -|\               |
            	 * VRAM    | \              |
            	 *         |  \             |
            	 *         |   \            |
            	 *         |    \           |
            	 *         |     \          |
            	 *         |      \         |
            	 *         |       \________|1 MB
            	 *         |----------------|
            	 *    VRAM 0 %             100 %
            	 *         used            used
            	 *
            	 * Note: It's a threshold, not a limit. The threshold must be crossed
            	 * for buffer relocations to stop, so any buffer of an arbitrary size
            	 * can be moved as long as the threshold isn't crossed before
            	 * the relocation takes place. We don't want to disable buffer
            	 * relocations completely.
            	 *
            	 * The idea is that buffers should be placed in VRAM at creation time
            	 * and TTM should only do a minimum number of relocations during
            	 * command submission. In practice, you need to submit at least
            	 * a dozen IBs to move all buffers to VRAM if they are in GTT.
            	 *
            	 * Also, things can get pretty crazy under memory pressure and actual
            	 * VRAM usage can change a lot, so playing safe even at 50% does
            	 * consistently increase performance.
            	 */
            Wow marek's an artist too! :P

            Comment


            • #7
              Originally posted by kbios View Post
              Code:
              /* This function is based on the current VRAM usage.
              	 *
              	 * - If all of VRAM is free, allow relocating the number of bytes that
              	 *   is equal to 1/4 of the size of VRAM for this IB.
              
              	 * - If more than one half of VRAM is occupied, only allow relocating
              	 *   1 MB of data for this IB.
              	 *
              	 * - From 0 to one half of used VRAM, the threshold decreases
              	 *   linearly.
              	 *         __________________
              	 * 1/4 of -|\               |
              	 * VRAM    | \              |
              	 *         |  \             |
              	 *         |   \            |
              	 *         |    \           |
              	 *         |     \          |
              	 *         |      \         |
              	 *         |       \________|1 MB
              	 *         |----------------|
              	 *    VRAM 0 %             100 %
              	 *         used            used
              	 *
              	 * Note: It's a threshold, not a limit. The threshold must be crossed
              	 * for buffer relocations to stop, so any buffer of an arbitrary size
              	 * can be moved as long as the threshold isn't crossed before
              	 * the relocation takes place. We don't want to disable buffer
              	 * relocations completely.
              	 *
              	 * The idea is that buffers should be placed in VRAM at creation time
              	 * and TTM should only do a minimum number of relocations during
              	 * command submission. In practice, you need to submit at least
              	 * a dozen IBs to move all buffers to VRAM if they are in GTT.
              	 *
              	 * Also, things can get pretty crazy under memory pressure and actual
              	 * VRAM usage can change a lot, so playing safe even at 50% does
              	 * consistently increase performance.
              	 */
              Wow marek's an artist too! :P
              Not quite, but close:

              gnuplot> set term dumb

              Comment


              • #8
                Music to my ears

                Comment


                • #9
                  Originally posted by oliver View Post
                  But what about r300? My poor T42 feels left out
                  The most recent r300 chip is almost 10 years old now. Might be time for an upgrade.

                  Comment


                  • #10
                    Interesting, I wonder if this affects APUs as well. A super low-end AMD netbook I maintain might like these changes once I switch to the open drivers (which is as soon as Gentoo stabilises 3.13, which might be in a week or in a month).

                    Comment


                    • #11
                      I wished X-Plane would start with FOSS drivers. This is the only reason i have to use catalyst...

                      Comment


                      • #12
                        Originally posted by GreatEmerald View Post
                        Interesting, I wonder if this affects APUs as well. A super low-end AMD netbook I maintain might like these changes once I switch to the open drivers (which is as soon as Gentoo stabilises 3.13, which might be in a week or in a month).
                        Writing from AMD C-60 netbook running Fedora 20 and Gnome shell. It's pretty much on par with the blob...

                        BTW is this only for the r600 or does it affect radeonsi too?

                        Comment


                        • #13
                          Originally posted by Redi44 View Post
                          Writing from AMD C-60 netbook running Fedora 20 and Gnome shell. It's pretty much on par with the blob...

                          BTW is this only for the r600 or does it affect radeonsi too?
                          I think this kernel code is good for any radeon card, or at least r300+. It looks like it requires some changes in Mesa to take best advantage of it, so we'll see if Marek submits changes to r300g along with r600g and SI. I'm pretty certain he'll at least do the last 2.

                          I don't think it will affect APU's, though. It seems to mostly be changing how memory is evicted from the GPU memory and sent to system memory, which doesn't exist unless you have a discrete card.

                          *disclaimer - i'm not a kernel or graphics dev, and this is just my understanding of the code i read in the ML

                          Comment


                          • #14
                            Originally posted by GreatEmerald View Post
                            Interesting, I wonder if this affects APUs as well. A super low-end AMD netbook I maintain might like these changes once I switch to the open drivers (which is as soon as Gentoo stabilises 3.13, which might be in a week or in a month).
                            I think this would have a bigger effect on APUs than anything else. The major drawback to APUs is the memory bandwidth. If Marek's fix lowers memory activity, then that should have an immense impact on APUs.

                            Comment


                            • #15
                              Originally posted by schmidtbag View Post
                              I think this would have a bigger effect on APUs than anything else. The major drawback to APUs is the memory bandwidth. If Marek's fix lowers memory activity, then that should have an immense impact on APUs.
                              The changes deal with ram-vram transfers, apus (and igps) should not be affected afaiu.

                              Comment

                              Working...
                              X