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

  • #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; 15 October 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; 15 October 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; 15 October 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