Page 2 of 5 FirstFirst 1234 ... LastLast
Results 11 to 20 of 46

Thread: AMD Kaveri: Gallium3D vs. Catalyst Drivers

  1. #11
    Join Date
    Dec 2010
    Location
    MA, USA
    Posts
    1,272

    Default

    Quote Originally Posted by bridgman View Post
    Interesting... the performance looks more like the "before" numbers in Michael's 3.12 vs 3.13 radeonsi article.

    Trinity and Richland use r600g instead of radeonsi so there are more performance optimizations in place for those parts. That said, radeonsi was putting out some much improved numbers in yesterday's article as well (albeit on Pitcairn & Tahiti dGPUs with ~3x and ~4x the shader power respectively) so there might be something else going on here.

    Based on limited experience with my half-a-Kaveri dev box I was expecting about 2x this performance, ie roughly 1/2 of Catalyst performance rather than 1/4. Anyways, thanks Michael for running the tests.
    I was thinking the same thing. There must be some DPM issue, these numbers just don't seem right. They're pretty poor even for the 3.12 kernel.

  2. #12
    Join Date
    Jan 2008
    Posts
    105

    Default

    I'll have A10-7850K in next week, so I'll be able to push some benchmarks with 2400MHz RAM.

  3. #13
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,440

    Default

    Quote Originally Posted by schmidtbag View Post
    I was thinking the same thing. There must be some DPM issue, these numbers just don't seem right. They're pretty poor even for the 3.12 kernel.
    D'oh !! (unless agd5f tells me I'm wrong). Just checked the code in radeon.pm -- looks like DPM is off by default for Kaveri in 3.13, enabled by default in 3.14.

    EDIT -- after re-reading Michael's article I didn't see any mention of DPM being forced on (the "enable DPM on CI APUs" patch was Dec 24 and was at the front of 3.14-next rather than the end of 3.13-fixes, which makes sense in hindsight) so that's probably the reason for the slower-than-expected performance.

    Hopefully Michael hasn't taken the benchmark setup apart yet
    Last edited by bridgman; 01-19-2014 at 11:59 AM.

  4. #14
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,440

    Default

    Just a quick caution -- agd5f's drm-next-3.14 branch contains the "make it work well enough that it's safe to enable by default" patches, not just the "enable by default" patch.

    Good news is that the benchmark numbers don't seem out of line considering that the Kaveri was probably running without DPM.
    Last edited by bridgman; 01-19-2014 at 12:08 PM.

  5. #15
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,440

    Default

    One last point -- the patches I mentioned in the previous post were for CI in general. I don't think we have explicitly tested DPM on Kaveri yet, although we'll certainly do that next week.

  6. #16
    Join Date
    Dec 2009
    Posts
    338

    Default

    Quote Originally Posted by bridgman View Post
    One last point -- the patches I mentioned in the previous post were for CI in general. I don't think we have explicitly tested DPM on Kaveri yet, although we'll certainly do that next week.
    I understand that Tim is the one to ask but since you're here.
    So to me it seems like development slowed done since the dpm and uvd push. More precisely:
    - No news about what Christian is working on, his latest state tracker was never merged, I think.
    - Marek has almost fewer mesa commits than in his worst exam period.
    - No real news regarding Tom ever since bgfminer started working.

    I'm not saying they are lazy, quite the contrary. I wonder how restricted they are by AMD legal and other internal stuff (writing reports, god knows)?
    Just to give you an example: I've thought that by now r600g will have at least RFC patches to enable GL 3.3 but it appears nobody is working on it.

    Yes, I am aware that it wasn't part of your original commitment but if you hire the guys who would do it anyways then I would assume they have more time to work on it.

    Can't blame HSA either, there's no news about it coming to Linux any time soon.

    Would you be kind enough to enlighten me? Thanks a lot in advance!

  7. #17
    Join Date
    Mar 2012
    Posts
    65

    Default

    Quote Originally Posted by HokTar View Post
    I understand that Tim is the one to ask but since you're here.
    So to me it seems like development slowed done since the dpm and uvd push. More precisely:
    - No news about what Christian is working on, his latest state tracker was never merged, I think.
    - Marek has almost fewer mesa commits than in his worst exam period.
    - No real news regarding Tom ever since bgfminer started working.

    I'm not saying they are lazy, quite the contrary. I wonder how restricted they are by AMD legal and other internal stuff (writing reports, god knows)?
    Just to give you an example: I've thought that by now r600g will have at least RFC patches to enable GL 3.3 but it appears nobody is working on it.

    Yes, I am aware that it wasn't part of your original commitment but if you hire the guys who would do it anyways then I would assume they have more time to work on it.

    Can't blame HSA either, there's no news about it coming to Linux any time soon.

    Would you be kind enough to enlighten me? Thanks a lot in advance!
    I'm not from AMD but I have an answer for one of your questions.
    As for geometry shaders which is the missing part for OpenGL 3.3, Vadim had started working on them for r600g. Then Dave made a couple of new patches to it. You can find it in one of his branches. As for geometry shaders work for radeonsi AMD is working internally (Alex mentioned somewhere on phoronix). According to RadeonsiToDo, Michel Dänzer is working on it.

  8. #18
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,440

    Default

    Quote Originally Posted by HokTar View Post
    I understand that Tim is the one to ask but since you're here.
    So to me it seems like development slowed done since the dpm and uvd push.
    The public view of what we're doing has always been a bit "lumpy" -- nothing seems to be happening, then something surprisingly good gets released, then there's a flurry of tweaks and bug fixes for a while, then things die down and nothing seems to be happening...

    It's probably safe to say that everyone is working on what you would like them to be working on, including a few things you haven't thought to ask for yet

    Quote Originally Posted by HokTar View Post
    I wonder how restricted they are by AMD legal and other internal stuff (writing reports, god knows)?
    There's the usual IP gates for new programming info which are both legal and technical -- we're trying to push that earlier in the development effort but in the short term (like all improvements) it means more work with less visible result for a while. Other than that I think the only "internal stuff" is maintaining a task list so the devs don't duplicate each other's work or work being done in the community.

    Quote Originally Posted by HokTar View Post
    Can't blame HSA either, there's no news about it coming to Linux any time soon.
    Actually there's a lot of Linux HSA work going on now, it's just being going through the "nothing seems to be happening" phase as well but that won't last much longer.

  9. #19
    Join Date
    Apr 2013
    Posts
    221

    Default dpm not works yet

    what i read is dpm not works yet for new apu

  10. #20
    Join Date
    Dec 2007
    Posts
    2,360

    Default

    Quote Originally Posted by zanny View Post
    DPM is defaulted on in 3.13, so the huge performance gap is with all the gpu cores in use and at their rated frequencies. I think. They may not have DPM code for Kaveri in yet.
    Not exactly. It was enabled by default for certain GPU families, but not all. DPM support for CI parts is still disabled by default. I hope to enable by default for CI for 3.14.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •