On some systems (real hardware) any direct drawing to framebuffer is really slow

[stippi]

I have a system with supported graphics board (X300) which performs great under ZETA with our Radeon driver. For some weird reason, directly rendering to the screen is painfully slow in Haiku, while hw accelerated calls work fine. For example, I can literally watch the text being rendered in any app. I have seen the app_server perform much better on much slower systems, so it cannot be a problem with slow drawing itself. Maybe it is something with the MTRR setup, or maybe with the AGP setup (it's a PCIe system btw). Maybe it has to do with the screen being in a weird mode (1600x1200 while it should be 1920x1200). I have no idea, but it should be fixed, maybe there are more systems out there with this problem. I am filing this under System/Kernel since either of the three things I am suspecting are living there (MTRR/AGP/EDID).

[korli]

Please provide a syslog, and possibly a dump of 'cat /proc/mtrr' on Linux.

[stippi]

Syslog from hrev25871 (booted fine (using new ATA), but shows symptoms described in this ticket)

[stippi]

output of cat /proc/mtrr on Ubuntu 7.10

[stippi]

Ok, added both files. Hope it helps, Since Michael's fix last night, this system boots Haiku again, so I can do further tests as necessary.

[korli]

the syslog seems corrupted. Do you have a serial log by chance ?

[stippi]

No serial port on this computer, sorry. How is it corrupted? Is there a part missing from the middle?

[stippi]

Oh, I see the place where it says <DROP>. Can I enlarge a buffer or something to capture the entire syslog?

[mmlr]

The first part of the output is truncated too it seems. The early debug output is put into a buffer until the syslog is ready, but this buffer is likely to small. The direct syslog output starts with the "Welcome to syslog debug output" line and it seems it cuts the early output. I added the welcome message recently to at least get the revision number in syslogs that is usually written to the early debug output too. Axel mentioned increasing the buffer size might be enough to solve this. That would be somewhere in the early boot process likely in the bootloader already.

[korli]

Replying to stippi:

Oh, I see the place where it says <DROP>. Can I enlarge a buffer or something to capture the entire syslog?

<TRUNC> is the point where the syslog is truncated.

[korli]

Replying to stippi:

Oh, I see the place where it says <DROP>. Can I enlarge a buffer or something to capture the entire syslog?

Could you try to double the SYSLOG_BUFFER_SIZE in src/system/kernel/debug/debug.cpp ?

[stippi]

This seemed to have helped, I got a new syslog. However, I am getting Internal Server Errors when I try to attach it. Therefor I am pasting what seems to me to be the relevant output:

2008-07-03 15:05:29 KERN: allocate_commpage_entry(4, 34) -> 0xffff0118
2008-07-03 15:05:29 KERN: set_memory_write_back base 0 length 3ff80000
2008-07-03 15:05:29 KERN: find_nearest 3ff80000 0
2008-07-03 15:05:29 KERN: find_nearest 1ff80000 1
2008-07-03 15:05:29 KERN: find_nearest ff80000 2
2008-07-03 15:05:29 KERN: find_nearest 7f80000 3
2008-07-03 15:05:29 KERN: find_nearest 3f80000 4
2008-07-03 15:05:29 KERN: find_nearest 1f80000 5
2008-07-03 15:05:29 KERN: find_nearest 80000 5
2008-07-03 15:05:29 KERN: find_nearest 80000 4
2008-07-03 15:05:29 KERN: find_nearest 80000 3
2008-07-03 15:05:29 KERN: find_nearest 80000 2
2008-07-03 15:05:29 KERN: find_nearest 80000 1
2008-07-03 15:05:29 KERN: solutions: 0x40000000 0x80000 
2008-07-03 15:05:29 KERN: allocate MTRR slot 0, base = 0, length = 40000000, type=0x6
2008-07-03 15:05:29 KERN: allocate MTRR slot 1, base = 3ff80000, length = 80000, type=0x0
2008-07-03 15:05:29 KERN: allocate MTRR slot 2, base = f0000000, length = 400000, type=0x1

[...]

2008-07-03 15:05:29 KERN: Radeon - init_hardware: Version: 5.1.6.0
2008-07-03 15:05:29 KERN: Radeon - Radeon_FindRom: found ROM @0xc0000
2008-07-03 15:05:29 KERN: Radeon - Radeon_CardDetect: found supported device pci index 2, device 0x1002/0x5b60
2008-07-03 15:05:29 KERN: Radeon - init_driver: 
2008-07-03 15:05:29 KERN: [36mAGP:[0m bus manager init
2008-07-03 15:05:29 KERN: [36mAGP:[0m found 0 AGP devices
2008-07-03 15:05:29 KERN: Radeon - GetDriverSettings: 
2008-07-03 15:05:29 KERN: Radeon - Radeon_FindRom: found ROM @0xc0000
2008-07-03 15:05:29 KERN: Radeon - Radeon_MapDevice: device: 010000
2008-07-03 15:05:29 KERN: Radeon - Radeon_MapDevice: old PCI command state: 0x00000007
2008-07-03 15:05:29 KERN: Radeon - Radeon_MapDevice: physical address of memory-mapped I/O: 0xfe9e0000-0xfe9effff
2008-07-03 15:05:29 KERN: Radeon - Radeon_GetPLLInfo: ref_clk=2700, ref_div=12, xclk=20000, min_freq=20000, max_freq=40000 from Legacy BIOS
2008-07-03 15:05:29 KERN: Radeon - Radeon_GetConnectorInfoFromBIOS: Port0: DDCType-2, DACType-1, TMDSType-0, ConnectorType-3
2008-07-03 15:05:29 KERN: Radeon - Radeon_GetConnectorInfoFromBIOS: Port1: DDCType-3, DACType-0, TMDSType-1, ConnectorType-3
2008-07-03 15:05:29 KERN: Radeon - Radeon_GetTMDSInfoFromBios: DFP table revision: 4
2008-07-03 15:05:29 KERN: Radeon - RADEON_GetAccessibleVRAM: Generation 2 PCI interface, using max accessible memory
2008-07-03 15:05:29 KERN: Radeon - Radeon_DetectRAM: Detected total video RAM=131072K, accessible=131072K (PCI BAR=131072K)
2008-07-03 15:05:29 KERN: Radeon - Radeon_DetectRAM: 128 MB SDR SGRAM found on 64 wide bus
2008-07-03 15:05:29 KERN: Radeon - Radeon_UnmapDevice: 
2008-07-03 15:05:29 KERN: Radeon - probeDevice: found Radeon X300 (RV370) 5B60; ASIC: rv380
2008-07-03 15:05:29 KERN: Radeon - probeDevice: making /dev/graphics/1002_5B60_010000
2008-07-03 15:05:29 KERN: Radeon - Radeon_ProbeDevices: 1 supported devices
2008-07-03 15:05:29 KERN: loaded driver /boot/beos/system/add-ons/kernel/drivers/dev/graphics/radeon
2008-07-03 15:05:29 KERN: S3: init_hardware() - no supported devices
2008-07-03 15:05:29 KERN: savage: init_hardware - no supported devices
2008-07-03 15:05:29 KERN: vesa: init_hardware()
2008-07-03 15:05:29 KERN: vesa: init_driver()
2008-07-03 15:05:29 KERN: vesa: publish_devices()
2008-07-03 15:05:29 KERN: vesa: find_device()
2008-07-03 15:05:29 KERN: loaded driver /boot/beos/system/add-ons/kernel/drivers/dev/graphics/vesa
2008-07-03 15:05:29 KERN: Radeon - open_hook: name=graphics/1002_5B60_010000, flags=2, cookie=0x90c5e720
2008-07-03 15:05:29 KERN: Radeon - Radeon_MapDevice: device: 010000
2008-07-03 15:05:29 KERN: Radeon - Radeon_MapDevice: old PCI command state: 0x00000006
2008-07-03 15:05:29 KERN: Radeon - Radeon_MapDevice: physical address of memory-mapped I/O: 0xfe9e0000-0xfe9effff
2008-07-03 15:05:29 KERN: Radeon - Radeon_MapDevice: physical address of framebuffer: 0xf0000000-0xf7ffffff
2008-07-03 15:05:29 KERN: allocate MTRR slot 3, base = f0000000, length = 8000000, type=0x1
2008-07-03 15:05:29 KERN: Radeon - Radeon_MapDevice: mapped frame buffer @0x98000000
2008-07-03 15:05:29 KERN: Radeon - Radeon_FirstOpen: Copy of Laptop Display Regs for Reference:
2008-07-03 15:05:29 KERN: Radeon - Radeon_FirstOpen: LVDS GEN =  804008a
2008-07-03 15:05:29 KERN: Radeon - Radeon_FirstOpen: LVDS PLL =     128c
2008-07-03 15:05:29 KERN: Radeon - Radeon_FirstOpen: TMDS PLL = 1fb800cd
2008-07-03 15:05:29 KERN: Radeon - Radeon_FirstOpen: TMDS TRANS = 10000040
2008-07-03 15:05:29 KERN: Radeon - Radeon_FirstOpen: FP1 GEN =  bc2c000
2008-07-03 15:05:29 KERN: Radeon - Radeon_FirstOpen: FP2 GEN = 1240080c
2008-07-03 15:05:29 KERN: Radeon - Radeon_FirstOpen: TV DAC =  7660142
2008-07-03 15:05:29 KERN: Radeon - createGARTBuffer: 
2008-07-03 15:05:29 KERN: Radeon - initGATT: 
2008-07-03 15:05:29 KERN: Radeon - initGATT: GATT_ptr=0x93800000, GATT_phys=0x02a61000
2008-07-03 15:05:29 KERN: pci_gart_map_area: 2457
2008-07-03 15:05:29 KERN: Radeon - Radeon_InitMemController: Graphics card address mapping:
2008-07-03 15:05:29 KERN: Radeon - Radeon_InitMemController:  local memory 0x8000000@0xf0000000
2008-07-03 15:05:29 KERN: Radeon - Radeon_InitMemController:  PCI GART 0x2000000@0x3ff80000
2008-07-03 15:05:29 KERN: Radeon - Radeon_InitMemController:  disabled AGP GART 0x400000@0x42000000
2008-07-03 15:05:29 KERN: Radeon - Radeon_SetupIRQ: installed IRQ @ 11
2008-07-03 15:05:29 KERN: [36mAGP:[0m get_nth_agp_info(index 0)
2008-07-03 15:05:29 KERN: Radeon - Radeon_Set_AGP: No AGP capable devices found.
2008-07-03 15:05:29 KERN: Radeon - Radeon_FirstOpen: DMA is diabled using PIO mode
2008-07-03 15:05:29 KERN: Radeon - open_hook: returning 0x00000000
2008-07-03 15:05:29 KERN: Radeon - Radeon_DetectTVOut: 
2008-07-03 15:05:29 KERN: DDC: ddc2_read(): DDC information read failure
2008-07-03 15:05:29 KERN: Last message repeated 3 times.
2008-07-03 15:05:29 KERN: Radeon - Radeon_ReadEDID: Found DDC-capable monitor @0x0060
2008-07-03 15:05:29 KERN: Radeon - Radeon_DetectDisplays: Edid Data for CRTC 1 on line 3

Hope this is useful.

[korli]

Hey Stephan,

as I see them, MTRR seem like in my setup. Maybe you noticed there is an overlapping of MTRR 2 et 3.

Could you try to disable the setup of MTTR 2 in src/system/kernel/debug/frame_buffer_console.cpp (function frame_buffer_console_init_post_modules) ?

HTH Jérôme

[korli]

Stephan, any news on this one ?

[stippi]

No, sorry. Have not looked into it again. At one time, I tried to mess with MTRR setup, but it didn't have any effect.

[stippi]

I am using a different graphics card now in the system that this was a problem on (ATI X300 -> nVidia 7300) and with the nVidia driver it works fine. The fix to the semaphore init in the Radeon driver was after I switched the board, so I have not yet checked if that changed anything. In any case, the issue can also be worked around by using the VESA driver too. So I don't believe this should be in the Alpha milestone anymore.

[bonefish]

Regarding overlapping of the MTRR 2 and 3, according to the precedence rules defined in the IA32 specification overlapping of identically typed memory range is well-defined: "If two or more variable memory ranges match and the memory types are identical, then that memory type is used." So in theory that shouldn't be a problem. Of course, a model-specific bug cannot be ruled out.

Somewhat related: On my new system with 4 GB RAM the VESA graphics is slow, too. In my case the MTRR algorithm computes a subtractive setup for the RAM (0 - 4G write-back, 3.x GB - 4 GB uncachable), which leads to the frame buffer being uncachable, too, since according to the precedence rules an uncachable range always wins. Since that is not the only problem of the current algorithm -- it also computes an incorrect (slightly too large) setup for the RAM and has exponential (!) complexity by design -- I'm rewriting the whole MTRR handling.

[michael.weirauch]

Replying to bonefish:

[...] Since that is not the only problem of the current algorithm -- it also computes an incorrect (slightly too large) setup for the RAM and has exponential (!) complexity by design -- I'm rewriting the whole MTRR handling.

That sentence makes me whonder if that "slightly too large" might be a reason for me having to limit the availbale memory to 3067 MB in order to not having the system freeze? c.f. #3772 (also includes MTRR setup listings)

[bonefish]

Replying to michael.weirauch:

Replying to bonefish:

[...] Since that is not the only problem of the current algorithm -- it also computes an incorrect (slightly too large) setup for the RAM and has exponential (!) complexity by design -- I'm rewriting the whole MTRR handling.

That sentence makes me whonder if that "slightly too large" might be a reason for me having to limit the availbale memory to 3067 MB in order to not having the system freeze? c.f. #3772 (also includes MTRR setup listings)

If a memory range containing hardware registers is accidentally set to write-back, that might indeed not be healthy. Would be interesting to see the RAM ranges and the MTRR setup.

[bonefish]

hrev34197 reimplements the MTRR handling, among other things avoiding equally typed overlapping MTRRs. If that was indeed the problem, it should be gone now. Stippi, please test, or if you're not going to, close this ticket.

[stippi]

I should be able to test this when I find my Radeon graphics board. I did switch motherboards as well in the meantime, but I don't know if that is relevant. We will see, I guess.

[jackburton]

Should we close this ? Stephan ?

[stippi]

Yeah, I guess so. I probably still have the Radeon, but I wouldn't know where to start looking even... also, the difference was so noticeable, IIRC, that we would hear some complaints.