Announcement

Collapse
No announcement yet.

AMD APUs Don't Appear Affected By Linux 3.12 Change

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

  • #16
    Bus Improvements?

    Well since we tested an APU, of course a low end one maybe some A10 non GCN would give more accurate results, lets examine our guesses!

    - Intel CPU governor improvements:
    To check this we should run the test with the radeon cards on an AMD CPU system. Also if this is the case there should be improvements to the Catalyst driver's performance also, so running the test with 3.12 and Catalyst should answer this question!(if this can be done now)

    -PCI Express Bus or RAM Access
    This is my wild guess considering Alex words about GART size and thinking that it is not affecting the APUs so it maybe a BUS enhancement in the 3.12 kernel like it was when PCI Express 2.0 was enabled by default.

    Comment


    • #17
      Originally posted by djdoo View Post
      Well since we tested an APU, of course a low end one maybe some A10 non GCN would give more accurate results....
      I think they might benefit more than the e350s did. When I was running 3.11-git while it was in rc, setting the CPU to performance manually, did produce a noticable speedup. Once 3.11 hit release, I stopped doing that because the performance has been good enough since then. It does seem to imply that the new CPU governor implementation would have an effect as well.

      I have an e450 myself in my HTPC, and the thing pretty much always runs at maximum clock when you do anything heavy on it. I think because they're weaker APUs, they might just be running at max frequency all the time already. The "big" a10 APUs might have different results.

      If I can find time I'll run these tests myself.

      Comment


      • #18
        The title of this article is misleading and raises expectations it does not come true.

        Comment


        • #19
          The likely reason AMD APUs (and also Intel GPUs) are not affected much by the cpufreq change is that they are most likely already GPU bound even at lower frequencies. The higher end dGPUs still have a good bit of GPU capacity left so higher CPU clocks help take advantage of that. That's why you see the largest performance increases with the larger dGPUs.

          Comment


          • #20
            Originally posted by Ericg View Post
            Now, if you DID enable DPM, then okay, great, this is more data to figure out what exactly is going on.
            You were already answered, but I think it needs mentioning: my E-350 units only have one power state, and so DPM would not affect them at all. It's reasonable to assume all E-350 are like that.

            Comment


            • #21
              Originally posted by agd5f View Post
              The likely reason AMD APUs (and also Intel GPUs) are not affected much by the cpufreq change is that they are most likely already GPU bound even at lower frequencies. The higher end dGPUs still have a good bit of GPU capacity left so higher CPU clocks help take advantage of that. That's why you see the largest performance increases with the larger dGPUs.
              Is a broad characterization really fair? Specifically, your use of the plural (i.e. APUs). AFAIK (or have seen from the various threads), the generalization that the APUs are unaffected is currently based upon the results of a sample size of one. Would the performance results for an A10 truly be unaffected as they were for a lowly e-350? The A10 will have ~3.5x the mem bandwidth alone (without looking at any other consideration) which may (or may not) impact the condition of being GPU bound within the benchmark tests.

              In Michaels tests, the HD6450 he used stands out as a candidate for being gpu bound. Yet, despite that its results were pretty much dismissed, it too showed a range of roughly a 1.5-9% improvement. There have been numerous articles over the years which highlight small 2% type of performance gains brought about by newly enabled feature xyz. Alone, their not much (and especially when they may pale in comparison to 60% type gains seen on other devices, in such a case like this), but they compound well enough. But I digress. The point is, I'd suspect that there are some gains to be seen on some of the higher end APUs. Similarly, I'd suspect that a Iris Pro would see some improvement too (did Michael look at that one? I can't remember such mention).

              Though, at this point, I not clear if the cpu governor change is only impacting Intel platforms or if it extends to AMD too ... someone pointed out a commit related to p-state and Haswell in one of the threads.
              Last edited by Tyler_K; 10-15-2013, 01:01 PM.

              Comment


              • #22
                Originally posted by curaga View Post
                You were already answered, but I think it needs mentioning: my E-350 units only have one power state, and so DPM would not affect them at all. It's reasonable to assume all E-350 are like that.
                okay, but wouldn't the performance levels available within that state not impact ? www.botchco.com/agd5f/?p=57

                Comment


                • #23
                  Originally posted by Tyler_K View Post
                  Though, at this point, I not clear if the cpu governor change is only impacting Intel platforms or if it extends to AMD too ... someone pointed out a commit related to p-state and Haswell in one of the threads.
                  From how I understand the commit, it should only affect AMD CPUs (and old Intel CPUs). Current-day Intel CPUs use a completely different frequency driver (it doesn't even have an ondemand governor to begin with). It's just that Ubuntu hasn't sorted itself out yet and disabled it, although it's fully functional.

                  Comment


                  • #24
                    Originally posted by GreatEmerald View Post
                    From how I understand the commit, it should only affect AMD CPUs (and old Intel CPUs).
                    right, thanks. Upon reflection, that is what I'd expect too.
                    Current-day Intel CPUs use a completely different frequency driver (it doesn't even have an ondemand governor to begin with).
                    right, p-state driver
                    It's just that Ubuntu hasn't sorted itself out yet and disabled it, although it's fully functional.
                    To be clear to anyone else, when I said commit above, I didn't mean the kernel cpufreq ondemand one, but rather the one related to ubuntu (which is the platform Michael tested from)). As GE has alluded too, effectively under ubuntu, the intel platform is behaving under the old scheme, and not per conditions that would be found with the new p-state (though, I suspect that the two would likely be similar now with this new new cpufreq commit).

                    So, we should expect the cpufreq commit to impact AMD platforms too ... only, at this point, we (or, at the very least "I" don't; as I certainly haven't done any testing) still don't know for sure whether the impact is to the same extent as seen when the Intel platform is driven like such

                    Comment


                    • #25
                      Originally posted by Tyler_K View Post
                      Is a broad characterization really fair? Specifically, your use of the plural (i.e. APUs). AFAIK (or have seen from the various threads), the generalization that the APUs are unaffected is currently based upon the results of a sample size of one. Would the performance results for an A10 truly be unaffected as they were for a lowly e-350? The A10 will have ~3.5x the mem bandwidth alone (without looking at any other consideration) which may (or may not) impact the condition of being GPU bound within the benchmark tests.

                      In Michaels tests, the HD6450 he used stands out as a candidate for being gpu bound. Yet, despite that its results were pretty much dismissed, it too showed a range of roughly a 1.5-9% improvement. There have been numerous articles over the years which highlight small 2% type of performance gains brought about by newly enabled feature xyz. Alone, their not much (and especially when they may pale in comparison to 60% type gains seen on other devices, in such a case like this), but they compound well enough. But I digress. The point is, I'd suspect that there are some gains to be seen on some of the higher end APUs. Similarly, I'd suspect that a Iris Pro would see some improvement too (did Michael look at that one? I can't remember such mention).

                      Though, at this point, I not clear if the cpu governor change is only impacting Intel platforms or if it extends to AMD too ... someone pointed out a commit related to p-state and Haswell in one of the threads.
                      I was speaking in general terms; there will always be exceptions. Overall, the performance impact on low end cards like the 6450 is much less than it is on larger dGPUs. Also, GDDR5 provides substantially more memory bandwidth than regular DDR3 system memory, so even though APUs have a fast channel to memory, you still can't beat dGPUs with vram. That only covers memory bandwith. The number of compute units on the GPU is the other factor. The workload will determine which of those is more important. Intel chips with dedicated memory may see some improvements depending on the work load. In general integrated GPUs are sized (from a compute unit perspective) to be commensurate with the CPU speed and memory bandwidth of the chip. There's no reason to add lots of compute units if the CPU can't keep them fed. That said, there may be some gains for intergrated GPUs, but I doubt they will be as substantial as you see with dGPUs.

                      Comment


                      • #26
                        Originally posted by GreatEmerald View Post
                        From how I understand the commit, it should only affect AMD CPUs (and old Intel CPUs). Current-day Intel CPUs use a completely different frequency driver (it doesn't even have an ondemand governor to begin with). It's just that Ubuntu hasn't sorted itself out yet and disabled it, although it's fully functional.
                        Obviously now we need benchmarks of the p-state driver vs. ondemand.

                        Comment


                        • #27
                          Originally posted by agd5f View Post
                          I was speaking in general terms; there will always be exceptions.
                          okay.

                          Overall, the performance impact on low end cards like the 6450 is much less than it is on larger dGPUs. Also, GDDR5 provides substantially more memory bandwidth than regular DDR3 system memory, so even though APUs have a fast channel to memory, you still can't beat dGPUs with vram.
                          true, but I don't recall what the characteristics of the card Michael is using. Most of the 6450's I believe are using DDR3, with the ones using GDDR5 being more of the exception to the case (though, I could be wrong), and, anyway, IIRC, they all use a narrow 64bit mem pipe.

                          That only covers memory bandwith. The number of compute units on the GPU is the other factor.
                          Right. And this is why I drew attention to the bandwidth alone, as the other defining points (cores, core clock, texture units, blah blah blah) on some of the APUs bring them well into the territory of lower end dGPUs . And, given even highly constrained gpu bound adapter like the 6450 showed improvement, I'd expect that a measurable difference would be observed with the top APUs, even if it wasn't really seen with the "low end" e-350 (though, still Michael's e-350 numbers do actually show marginal ~1% differences ... but I suppose its debatable whether its just noise), which has much lower core characteristics (as well as memory ones too)

                          The workload will determine which of those is more important. Intel chips with dedicated memory may see some improvements depending on the work load. In general integrated GPUs are sized (from a compute unit perspective) to be commensurate with the CPU speed and memory bandwidth of the chip. There's no reason to add lots of compute units if the CPU can't keep them fed. That said, there may be some gains for intergrated GPUs, but I doubt they will be as substantial as you see with dGPUs.
                          Not expecting substantial 60% gains like seen with the dGPUs, but I'd suspect a healthy gain nonetheless ... and I'm sure that those APU owners concerned about performance won't be unhappy about seeing more compounding
                          Last edited by Tyler_K; 10-15-2013, 03:21 PM.

                          Comment


                          • #28
                            Originally posted by Tyler_K View Post
                            Not expecting substantial 60% gains like seen with the dGPUs, but I'd suspect a healthy gain nonetheless ... and I'm sure that those APU owners concerned about performance won't be unhappy about seeing more compounding
                            Actually, in hindsight, I recognize that I'd lost sight of something -- there isn't any new performance being realized ... and those really concerned about performance would likely have already maximized their experience by utilizing the performance gov.
                            Last edited by Tyler_K; 10-15-2013, 04:01 PM.

                            Comment


                            • #29
                              Originally posted by AnonymousCoward View Post
                              Obviously now we need benchmarks of the p-state driver vs. ondemand.
                              The intel_pstate driver has two governors, powersave and performance. The default is powersave. So which one would you benchmark?

                              Comment

                              Working...
                              X