0x95C5:0x1043:0x01F4: Asus EAH3450

Juergen Buchmueller

8 May 2009 8 May '09

12:35

More info on the dramatic slowdown of my R6xx (R620) blits: With a 16bpp depth everything seems to be working fine using either XAA or EXA. It's just the 24bpp mode that shows the slowness in screen-to-screen blits. I'm looking into r600_exa.c and r6xx_accel.c to see if I can make out the difference in the code that handles the distinct depths... Juergen -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

Show replies by date

Alex Deucher

8 May 8 May

14:32

On Fri, May 8, 2009 at 8:35 AM, Juergen Buchmueller wrote:

...

More info on the dramatic slowdown of my R6xx (R620) blits: With a 16bpp depth everything seems to be working fine using either XAA or EXA. It's just the 24bpp mode that shows the slowness in screen-to-screen blits.

There is no XAA support for r6xx/r7xx. When you select XAA, it falls back to shadowfb or none I think.

...

I'm looking into r600_exa.c and r6xx_accel.c to see if I can make out the difference in the code that handles the distinct depths...

Most likely you don't have the drm installed correctly. If the drm is not available, the driver will fallback to direct framebuffer access rather than shadowfb for software rendering. Shadowfb is faster than rendering directly to the framebuffer because the framebuffer is shadowed in system ram. Alex -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

Juergen Buchmueller

15:07

On Fri, 8 May 2009 10:32:46 -0400 Alex Deucher wrote:

...

There is no XAA support for r6xx/r7xx. When you select XAA, it falls back to shadowfb or none I think.

Ok, so what I see then is shadowfb, which always has been reasonably fast.

...

Most likely you don't have the drm installed correctly. If the drm is not available, the driver will fallback to direct framebuffer access rather than shadowfb for software rendering.

Well, actually there is no such thing as drm in a NetBSD 5.0 kernel. So if you say I need a kernel direct rendering manager, then the following lines from Xorg.0.log are a little misleading: (**) RADEONHD(0): Depth 16, (--) framebuffer bpp 16 (**) RADEONHD(0): Option "AccelMethod" "EXA" (**) RADEONHD(0): Selected EXA 2D acceleration. (II) RADEONHD(0): Unknown card detected: 0x95C5:0x1043:0x01F4. If - and only if - your card does not work or does not work optimally please contact radeonhd@opensuse.org to help rectify this. Use the subject: 0x95C5:0x1043:0x01F4: <name of board> and *please* describe the problems you are seeing in your message. (--) RADEONHD(0): Detected an RV620 on an unidentified card There is no warning or even error telling me that EXA would not be working or that I'm missing something else.

...

Shadowfb is faster than rendering directly to the framebuffer because the framebuffer is shadowed in system ram.

Ok, I got that. So I think the radeonhd drivers before 1.2.5 were falling back to shadowfb (?), while 1.2.5 directly accesses the framebuffer in case it doesn't find (how?) DRM. Perhaps a warning or error message in the logfile would help stupid people like me to understand what goes wrong ;-)

...

Alex

Thanks for the explanations, Juergen -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

Alex Deucher

15:15

On Fri, May 8, 2009 at 11:07 AM, Juergen Buchmueller wrote:

...

On Fri, 8 May 2009 10:32:46 -0400 Alex Deucher wrote:

...
There is no XAA support for r6xx/r7xx. When you select XAA, it falls back to shadowfb or none I think.

Ok, so what I see then is shadowfb, which always has been reasonably fast.

...
Most likely you don't have the drm installed correctly. If the drm is not available, the driver will fallback to direct framebuffer access rather than shadowfb for software rendering.

Well, actually there is no such thing as drm in a NetBSD 5.0 kernel. So if you say I need a kernel direct rendering manager, then the following lines from Xorg.0.log are a little misleading:

(**) RADEONHD(0): Depth 16, (--) framebuffer bpp 16 (**) RADEONHD(0): Option "AccelMethod" "EXA" (**) RADEONHD(0): Selected EXA 2D acceleration. (II) RADEONHD(0): Unknown card detected: 0x95C5:0x1043:0x01F4. If - and only if - your card does not work or does not work optimally please contact radeonhd@opensuse.org to help rectify this. Use the subject: 0x95C5:0x1043:0x01F4: <name of board> and *please* describe the problems you are seeing in your message. (--) RADEONHD(0): Detected an RV620 on an unidentified card

There is no warning or even error telling me that EXA would not be working or that I'm missing something else.

Those messages are telling you that you've selected EXA, look further down the log to see if EXA initialized properly or not. if it did you'll see: (II) EXA(0): Offscreen pixmap area of 51871744 bytes (II) EXA(0): Driver registered support for the following operations: (II) Solid (II) Copy (II) Composite (RENDER acceleration) (II) UploadToScreen (II) DownloadFromScreen

...

...
Shadowfb is faster than rendering directly to the framebuffer because the framebuffer is shadowed in system ram.

Ok, I got that. So I think the radeonhd drivers before 1.2.5 were falling back to shadowfb (?), while 1.2.5 directly accesses the framebuffer in case it doesn't find (how?) DRM.

Releases before 1.2.5 did not have acceleration support for r6xx/r7xx cards so they always used shadowfb. When EXA initialization fails the driver falls back to no accel rather than shadowfb.

...

Perhaps a warning or error message in the logfile would help stupid people like me to understand what goes wrong ;-)

...
Alex

Thanks for the explanations,

No problem. Alex

...

Juergen

-- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

Federico

15:38

2009/5/8 Alex Deucher :

...

Releases before 1.2.5 did not have acceleration support for r6xx/r7xx cards so they always used shadowfb. When EXA initialization fails the driver falls back to no accel rather than shadowfb.

This is a problem since DRM only works in the first X session. When you switch users (by using the fast user switch option or when the screen is locked by another user) you lose DRM and EXA. In my hardware (RS780) shadowfb was fast, but the current setup with no acceleration is almost like the vesa driver. Is there any chance the fallback is shadowfb? At least until DRM works with more than one X session. -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

Alex Deucher

15:44

On Fri, May 8, 2009 at 11:38 AM, Federico wrote:

...

2009/5/8 Alex Deucher :

...
Releases before 1.2.5 did not have acceleration support for r6xx/r7xx cards so they always used shadowfb. When EXA initialization fails the driver falls back to no accel rather than shadowfb.

This is a problem since DRM only works in the first X session. When you switch users (by using the fast user switch option or when the screen is locked by another user) you lose DRM and EXA.

In my hardware (RS780) shadowfb was fast, but the current setup with no acceleration is almost like the vesa driver.

Is there any chance the fallback is shadowfb? At least until DRM works with more than one X session.

It could be changed in the code if the fallback isn't shadowfb. Alex -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

Federico

16:29

2009/5/8 Alex Deucher :

...

...
Is there any chance the fallback is shadowfb? At least until DRM works with more than one X session.

It could be changed in the code if the fallback isn't shadowfb.

Should I file a bug requesting that change? -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

Alex Deucher

17:16

On Fri, May 8, 2009 at 12:29 PM, Federico wrote:

...

2009/5/8 Alex Deucher :

...
...
Is there any chance the fallback is shadowfb? At least until DRM works with more than one X session.

It could be changed in the code if the fallback isn't shadowfb.

Should I file a bug requesting that change?

Sure. -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

Matthias Hopf

11 May 11 May

16:10

On May 08, 09 11:15:05 -0400, Alex Deucher wrote:

...

Releases before 1.2.5 did not have acceleration support for r6xx/r7xx cards so they always used shadowfb. When EXA initialization fails the driver falls back to no accel rather than shadowfb.

Alex, do you think this can be reworked to use shadowfb if it fails? I know that the logic order is different, so this *might* be troublesome. OTOH it might just work, and it would be helpful for a lot of people. OTOH if the driver is slow after enabling acceleration you immediately notice that something is going wrong. That's actually good feedback :-] But given that HW acceleration wasn't available before, it looks like regression to the average user. Matthias -- Matthias Hopf __ __ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ mat@mshopf.de Phone +49-911-74053-715 __) |_| __) |__ R & D www.mshopf.de -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

Matthias Hopf

16:20

On May 11, 09 18:10:04 +0200, Matthias Hopf wrote:

...

On May 08, 09 11:15:05 -0400, Alex Deucher wrote:

...
Releases before 1.2.5 did not have acceleration support for r6xx/r7xx cards so they always used shadowfb. When EXA initialization fails the driver falls back to no accel rather than shadowfb.

Alex, do you think this can be reworked to use shadowfb if it fails? I know that the logic order is different, so this *might* be troublesome.

Reading the code again, it turns out that we would need a PreInit function to determine whether acceleration is available or not. So this needs some coding. The Init function is called after memory layout setup, which is influenced by ShadowFB. Matthias -- Matthias Hopf __ __ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ mat@mshopf.de Phone +49-911-74053-715 __) |_| __) |__ R & D www.mshopf.de -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

Alex Deucher

17:01

On Mon, May 11, 2009 at 12:20 PM, Matthias Hopf wrote:

...

On May 11, 09 18:10:04 +0200, Matthias Hopf wrote:

...
On May 08, 09 11:15:05 -0400, Alex Deucher wrote:

...
Releases before 1.2.5 did not have acceleration support for r6xx/r7xx cards so they always used shadowfb. When EXA initialization fails the driver falls back to no accel rather than shadowfb.

Alex, do you think this can be reworked to use shadowfb if it fails? I know that the logic order is different, so this *might* be troublesome.

Reading the code again, it turns out that we would need a PreInit function to determine whether acceleration is available or not. So this needs some coding. The Init function is called after memory layout setup, which is influenced by ShadowFB.

Yeah, I figured something like that would need to be done which is why it's not currently done even for older asics. Alex -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

5500

Age (days ago)

5503

Last active (days ago)

List overview

Download

10 comments

4 participants

participants (4)

Alex Deucher
Federico
Juergen Buchmueller
Matthias Hopf