Page 2 of 9 FirstFirst 1234 ... LastLast
Results 11 to 20 of 87

Thread: E-450 graphics performance issues

  1. #11
    Join Date
    Aug 2007
    Posts
    6,641

    Default

    Why do you need a xorg.conf file these days for oss drivers? Wouldnt it be more logical when those options are default?

  2. #12
    Join Date
    Jan 2010
    Posts
    365

    Default

    I already enabled 2D color tiling earlier, and it seems to help a little bit, but not much. Performance still is largely pathologically bad. For instance, a simple GLSL-based plasma effect I made a while ago runs with approximately similar performance to GMA950, again. It's a very simple fragment shader, yet a fullscreen window of it runs at just ~20 fps.

    Is this really the current state of Mesa's APU support? What's holding back performance?

  3. #13
    Join Date
    Dec 2007
    Posts
    2,395

    Default

    Quote Originally Posted by brent View Post
    Is this really the current state of Mesa's APU support? What's holding back performance?
    Performance is fluid on my APU systems. Try profiling that apps you are having problems with and see where the bottlenecks are. The open source driver is not as fast as the closed driver at the moment. If maximum 3D performance is what you need, you may want to use the closed source driver in the interim.

  4. #14
    Join Date
    Jan 2010
    Posts
    365

    Default

    fglrx offers great OpenGL support and performance, and power management is also much better (~1W less at idle!), but literally everything else is worse or completely broken. I don't care that much for the driver being closed-source, but features like suspend to ram simply must work reliably. OTOH, I don't need superb OpenGL support/performance, but it should be *acceptable* at least.

    Performance is fluid on my APU systems.
    Can you be more specific?

    agd5f, by the way, do you know if power management works correctly on Brazos APUs? As I said before, radeon_pm_info spits out some rather nonsensical values. Is the GPU actually clocked correctly up to its full frequency? I did some simple tests and observed no difference between low/mid/high profiles or dynpm. What power management features are missing to make power consumption as low as with fgrlx?
    Last edited by brent; 07-07-2012 at 11:21 AM.

  5. #15
    Join Date
    Jan 2010
    Posts
    365

    Default

    I enabled some DRM debugging, and this is what I see for *every* call to r600_get_dynpm_state:

    [25233.444967] [drm:r600_pm_get_dynpm_state], Requested: e: 17369 m: 0 p: 1
    The clock unit is 10 KHz. Does that mean the engine clock is essentially fixed to ~173 MHz for some reason? I'll try to find out what's in the power state tables. If the debug output is right, the GPU is always running at basically 1/3 of the specified clock, not even taking the "turbo" mode into consideration.

  6. #16
    Join Date
    Jan 2010
    Posts
    365

    Default

    The power states look rather strange to me altogether:

    Code:
    [    7.630610] [drm:radeon_pm_print_states], 6 Power State(s)
    [    7.630615] [drm:radeon_pm_print_states], State 0: Default
    [    7.630618] [drm:radeon_pm_print_states],    1 Clock Mode(s)
    [    7.630621] [drm:radeon_pm_print_states],            0 e: 275000
    [    7.630625] [drm:radeon_pm_print_states], State 1: Default
    [    7.630628] [drm:radeon_pm_print_states],    1 Clock Mode(s)
    [    7.630631] [drm:radeon_pm_print_states],            0 e: 507700
    [    7.630634] [drm:radeon_pm_print_states], State 2: Battery
    [    7.630637] [drm:radeon_pm_print_states],    1 Clock Mode(s)
    [    7.630639] [drm:radeon_pm_print_states],            0 e: 275000
    [    7.630642] [drm:radeon_pm_print_states], State 3: Performance
    [    7.630645] [drm:radeon_pm_print_states],    2 Clock Mode(s)
    [    7.630648] [drm:radeon_pm_print_states],            0 e: 275000     No display only
    [    7.630651] [drm:radeon_pm_print_states],            1 e: 507700
    [    7.630654] [drm:radeon_pm_print_states], State 4: Default
    [    7.630657] [drm:radeon_pm_print_states],    Default
    [    7.630660] [drm:radeon_pm_print_states], 
    [    7.630664] [drm:radeon_pm_print_states],            0 e: 200000     No display only
    [    7.630667] [drm:radeon_pm_print_states],            1 e: 200000
    [    7.630670] [drm:radeon_pm_print_states], State 5: Default
    [    7.630673] [drm:radeon_pm_print_states],    1 Clock Mode(s)
    [    7.630676] [drm:radeon_pm_print_states],            0 e: 173690
    Maybe this confuses the driver and tricks into selecting only the last two states.

  7. #17
    Join Date
    Jan 2010
    Posts
    365

    Default

    ...and that is indeed what is happening. I made some crude hacks to get profiles with 275 and 507 MHz clocks working, and they work fine. It's definitely a night-and-day difference, especially at the full clock.

    Now, what's up with those tables? Does the driver actually parse them correctly? The E-450 introduces a new turbo mode for the GPU, maybe that's handled with a new format in the powerplay tables. Or is it just Lenovo screwing up? fglrx seems to handle it correctly.

    Overall, from what I've seen the power management code seems to need a lot of work...
    Last edited by brent; 07-07-2012 at 10:27 PM.

  8. #18
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,182

    Default

    Overall, from what I've seen the power management code seems to need a lot of work...
    True, and I believe the response has been "patches welcome, we'll work on it later if we have time"

    One tweak I guess would be fairly easy would be to make the "high" profile really pick the highest mode.

  9. #19
    Join Date
    Jan 2010
    Posts
    365

    Default

    I'm willing to work on it, but it appears that power management features are entirely missing in the available documentation. In fact, Evergreen hardware is not documented at all. Shame on you, AMD.
    Last edited by brent; 07-08-2012 at 02:16 PM.

  10. #20
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,514

    Default

    Quote Originally Posted by brent View Post
    but it appears that power management features are entirely missing in the available documentation.... Shame on you, AMD.
    Just to be clear, are you saying "shame on us" for :

    - not documenting what we don't know yet or can't release yet ? (remember we have to figure out the hardware by getting code working first before we can *write* documentation)
    - not doing enough documentation about the parts we do know and the code we have released ?
    - working on higher priority things like fixing corruption/hangs or implementing initial support for new hardware instead of improving power management ?
    - something else ?

    Between the existing code, comments in the code, and agd5f's blog posts (eg http://www.botchco.com/agd5f/?p=45) what do you think is missing ?

    Quote Originally Posted by brent View Post
    In fact, Evergreen hardware is not documented at all.
    The biggest changes between generations are in the shader core, and we release ISA guides for each new shader core. Please take a read through the Evergreen ISA guide at your convenience (especially section 8) and let me know what you think is missing :

    http://developer.amd.com/sdks/AMDAPP...chitecture.pdf

    Other than a few things like attribute interpolation (covered by the ISA guide, highlights at front + details in section 8) and compute support (ISA guide again, plus Tom and others in the community are writing and publishing code) the Evergreen and NI generations is programmed in the same way described in the 6xx/7xx documentation... it's really SI (GCN) hardware where we need another slug of documentation and that's one of the things being worked on now.

    There are gaps in areas where the devs are still trying to find correct info (eg DP-to-analog bridge chips) but unfortunately that falls into the "documenting things we don't know yet" bucket ;(

    In case you didn't know about the ISA guides, please check out the bottom of the RadeonFeature page : http://www.x.org/wiki/RadeonFeature
    Last edited by bridgman; 07-08-2012 at 03:04 PM.

Posting Permissions

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