Bug 31682 - Radeon console output very slow with kms
Summary: Radeon console output very slow with kms
Status: RESOLVED OBSOLETE
Alias: None
Product: Drivers
Classification: Unclassified
Component: Video(DRI - non Intel) (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: drivers_video-dri
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-03-22 18:30 UTC by Kurt Roeckx
Modified: 2013-11-15 16:18 UTC (History)
4 users (show)

See Also:
Kernel Version: 2.6.38
Subsystem:
Regression: No
Bisected commit-id:


Attachments

Description Kurt Roeckx 2011-03-22 18:30:09 UTC
Hi,

When I try to use KMS, the console output is very slow.  I've seen a lot of people complain about this, but I can't find any bug about this.  It's not really usable when KMS is enabled.

If I disable KMS (and use radeonfb), things work normally.

It takes for instance about 1 second for me to just redraw the screen, while the same thing is _at least_ 10 times faster, probably more like 100, when KMS is disabled.

When booting with KMS enabled I get this in dmesg:
Mar 21 19:07:50 intrepid kernel: [    8.735138] [drm] Initialized drm 1.1.0 20060810
Mar 21 19:07:50 intrepid kernel: [    8.887517] [drm] radeon kernel modesetting enabled.
Mar 21 19:07:50 intrepid kernel: [    8.887709] radeon 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
Mar 21 19:07:50 intrepid kernel: [    8.891920] [drm] initializing kernel modesetting (RV280 0x1002:0x5964).
Mar 21 19:07:50 intrepid kernel: [    8.892029] [drm] register mmio base: 0xFD400000
Mar 21 19:07:50 intrepid kernel: [    8.892084] [drm] register mmio size: 65536
Mar 21 19:07:50 intrepid kernel: [    8.896084] agpgart-amd64 0000:00:00.0: AGP 3.5 bridge
Mar 21 19:07:50 intrepid kernel: [    8.896339] agpgart-amd64 0000:00:00.0: putting AGP V3 device into 8x mode
Mar 21 19:07:50 intrepid kernel: [    8.896458] radeon 0000:01:00.0: putting AGP V3 device into 8x mode
Mar 21 19:07:50 intrepid kernel: [    8.896519] radeon 0000:01:00.0: GTT: 64M 0xF8000000 - 0xFBFFFFFF
Mar 21 19:07:50 intrepid kernel: [    8.896578] [drm] Generation 2 PCI interface, using max accessible memory
Mar 21 19:07:50 intrepid kernel: [    8.896638] radeon 0000:01:00.0: VRAM: 128M 0x00000000E8000000 - 0x00000000EFFFFFFF (128M used)
Mar 21 19:07:50 intrepid kernel: [    8.896714] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
Mar 21 19:07:50 intrepid kernel: [    8.896772] [drm] Driver supports precise vblank timestamp query.
Mar 21 19:07:50 intrepid kernel: [    8.896866] [drm] radeon: irq initialized.
Mar 21 19:07:50 intrepid kernel: [    8.897063] [drm] Detected VRAM RAM=128M, BAR=128M
Mar 21 19:07:50 intrepid kernel: [    8.897123] [drm] RAM width 64bits DDR
Mar 21 19:07:50 intrepid kernel: [    8.897256] [TTM] Zone  kernel: Available graphics memory: 1030408 kiB.
Mar 21 19:07:50 intrepid kernel: [    8.897314] [TTM] Initializing pool allocator.
Mar 21 19:07:50 intrepid kernel: [    8.897392] [drm] radeon: 128M of VRAM memory ready
Mar 21 19:07:50 intrepid kernel: [    8.897447] [drm] radeon: 64M of GTT memory ready.
Mar 21 19:07:50 intrepid kernel: [    8.899585] radeon 0000:01:00.0: WB disabled
Mar 21 19:07:50 intrepid kernel: [    8.900265] [drm] Loading R200 Microcode
Mar 21 19:07:50 intrepid kernel: [    9.381958] [drm] radeon: ring at 0x00000000F8001000
Mar 21 19:07:50 intrepid kernel: [    9.382034] [drm] ring test succeeded in 1 usecs
Mar 21 19:07:50 intrepid kernel: [    9.384821] [drm] radeon: ib pool ready.
Mar 21 19:07:50 intrepid kernel: [    9.384959] [drm] ib test succeeded in 0 usecs
Mar 21 19:07:50 intrepid kernel: [    9.386362] [drm] Radeon Display Connectors
Mar 21 19:07:50 intrepid kernel: [    9.386417] [drm] Connector 0:
Mar 21 19:07:50 intrepid kernel: [    9.386469] [drm]   VGA
Mar 21 19:07:50 intrepid kernel: [    9.386522] [drm]   DDC: 0x60 0x60 0x60 0x60 0x60 0x60 0x60 0x60
Mar 21 19:07:50 intrepid kernel: [    9.386578] [drm]   Encoders:
Mar 21 19:07:50 intrepid kernel: [    9.386630] [drm]     CRT1: INTERNAL_DAC1
Mar 21 19:07:50 intrepid kernel: [    9.386684] [drm] Connector 1:
Mar 21 19:07:50 intrepid kernel: [    9.386736] [drm]   DVI-D
Mar 21 19:07:50 intrepid kernel: [    9.386787] [drm]   HPD1
Mar 21 19:07:50 intrepid kernel: [    9.386839] [drm]   DDC: 0x64 0x64 0x64 0x64 0x64 0x64 0x64 0x64
Mar 21 19:07:50 intrepid kernel: [    9.386895] [drm]   Encoders:
Mar 21 19:07:50 intrepid kernel: [    9.386947] [drm]     DFP1: INTERNAL_TMDS1
Mar 21 19:07:50 intrepid kernel: [    9.387001] [drm] Connector 2:
Mar 21 19:07:50 intrepid kernel: [    9.387053] [drm]   S-video
Mar 21 19:07:50 intrepid kernel: [    9.387105] [drm]   Encoders:
Mar 21 19:07:50 intrepid kernel: [    9.387157] [drm]     TV1: INTERNAL_DAC2
Mar 21 19:07:50 intrepid kernel: [    9.800245] [drm] fb mappable at 0xE8040000
Mar 21 19:07:50 intrepid kernel: [    9.800303] [drm] vram apper at 0xE8000000
Mar 21 19:07:50 intrepid kernel: [    9.802396] [drm] size 7680000
Mar 21 19:07:50 intrepid kernel: [    9.802448] [drm] fb depth is 24
Mar 21 19:07:50 intrepid kernel: [    9.802500] [drm]    pitch is 6400
Mar 21 19:07:50 intrepid kernel: [   10.023003] Console: switching to colour frame buffer device 200x75
Mar 21 19:07:50 intrepid kernel: [   10.139398] fb0: radeondrmfb frame buffer device
Mar 21 19:07:50 intrepid kernel: [   10.139400] drm: registered panic notifier
Mar 21 19:07:50 intrepid kernel: [   10.140945] [drm] Initialized radeon 2.8.0 20080528 for 0000:01:00.0 on minor 0


When KMS is disabled I see this instead:
Mar 21 19:10:55 intrepid kernel: [    9.011140] [drm] Initialized radeon 1.33.0 20080528 for 0000:01:00.0 on minor 0
[...]
Mar 21 19:10:55 intrepid kernel: [   13.332368] radeonfb: Found Intel x86 BIOS ROM Image
Mar 21 19:10:55 intrepid kernel: [   13.332430] radeonfb: Retrieved PLL infos from BIOS
Mar 21 19:10:55 intrepid kernel: [   13.332487] radeonfb: Reference=27.00 MHz (RefDiv=12) Memory=200.00 Mhz, System=166.00 MHz
Mar 21 19:10:55 intrepid kernel: [   13.332556] radeonfb: PLL min 20000 max 40000
Mar 21 19:10:55 intrepid kernel: [   13.684011] radeonfb: Monitor 1 type DFP found
Mar 21 19:10:55 intrepid kernel: [   13.684072] radeonfb: EDID probed
Mar 21 19:10:55 intrepid kernel: [   13.684124] radeonfb: Monitor 2 type CRT found
Mar 21 19:10:55 intrepid kernel: [   13.684178] radeonfb: EDID probed
Mar 21 19:10:55 intrepid kernel: [   13.747450] Console: switching to colour frame buffer device 200x75
Mar 21 19:10:55 intrepid kernel: [   13.799573] radeonfb (0000:01:00.0): ATI Radeon 5964 "Yd"


Kurt
Comment 1 Alex Deucher 2011-03-22 18:40:04 UTC
This is not exactly a bug.  KMS does not provide any acceleration for console operations while radeonfb does.
Comment 2 Kurt Roeckx 2011-03-22 19:14:36 UTC
So then see this as a feature request or something.
Comment 3 Arno Schuring 2011-08-19 14:26:06 UTC
@alex: by saying "not a bug", are you implying that this is by design and will not be fixed? Or do you simply mean that there are no clear, simple ways to improve the situation?

TBH, I could just as easily classify this as a performance regression since 2.6.32 (or whenever KMS was made the default). What is the recommended solution for no-X servers with AMD IGPs? Blacklist the radeon module, or will the modeset=0 option be supported indefinitely?
Comment 4 Alex Deucher 2011-08-19 14:45:22 UTC
Someone could implement support for accelerated fb operations, I just don't have any plans to.  The problem is, the drawing engine is usually the part of the GPU that hangs if there is a problem so if we use the drawing engine to accelerate fb operations and it hangs, you may end up with a hosed console whereas.  The other issue is that on newer asics, there is no 2D engine, so you'd have to implement fb acceleration with the 3D engine which is substantially more complex.
Comment 5 Alan 2012-08-20 15:13:08 UTC
(or use the GART like GMA50 ...)
Comment 6 Jérôme Glisse 2013-11-15 16:06:16 UTC
We can not do the GART trick on radeon, radeon is using dedicated VRAM and not scaning out from system memory mapped through a gart.

(Well we could do GART trick on newer GPU that has virtual address space where we can remap the VRAM with a GART but anybody with such a GPU that is using fbdev as others more serious personal issues)
Comment 7 Alan 2013-11-15 16:18:14 UTC
You only need to use the GART trick if you might not have enough memory to allocate twice the memory needed for the framebuffer. If you can afford the memory then allocate two copies and write each text blit into both. Then just change the start of the scan out as needed. It's even faster than the GMA500 GART trick!

Alan

Note You need to log in before you can comment on or make changes to this bug.