E-450 graphics performance issues

[Kano]

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

[brent]

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?

[agd5f]

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.

[brent]

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?

[brent]

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.

[brent]

The power states look rather strange to me altogether:

[    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.

[brent]

...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...

[curaga]

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.

[brent]

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.

[bridgman]

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 ?

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