Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#5085 closed bug (invalid)

Poor vesa performance on NVidia Quadro FX770M

Reported by: PieterPanman Owned by: bonefish
Priority: normal Milestone: R1
Component: System/Kernel Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

My previous laptop with a Geforce 8600m GT has broken down, so I have replaced it with a new one, which has a NVidia Quadro FX770M laptop, (like the GeForce 9600M GT).

Though neither of them is supported by Rudolf's driver, I had very good vesa performance with the Geforce 8600m. I could play high res movies at full screen 1680x1050, without really maxing the cpu.

On my new laptop, with slightly better specs, (also 1680x1050) I can barely fullscreen ActivityMonitor without using the cpu fully. Fullscreening a simple divx movie maxes out the cpu for the app server, making it very stuttery.

This laptop has 4 gigs of ram compared to the old one, which had 2. hrev34494.

Attachments (6)

syslog (111.2 KB ) - added by PieterPanman 10 years ago.
listdev.txt (3.9 KB ) - added by PieterPanman 10 years ago.
listdev
listdevd.txt (16.0 KB ) - added by PieterPanman 10 years ago.
listdev -d
syslog.2 (129.6 KB ) - added by PieterPanman 10 years ago.
New syslog with larger ringbuffer. No more truncs and drops
dmessages.txt (63.2 KB ) - added by PieterPanman 10 years ago.
linux dmesg
lspci.txt (12.1 KB ) - added by PieterPanman 10 years ago.
lspci -v

Download all attachments as: .zip

Change History (17)

by PieterPanman, 10 years ago

Attachment: syslog added

by PieterPanman, 10 years ago

Attachment: listdev.txt added

listdev

by PieterPanman, 10 years ago

Attachment: listdevd.txt added

listdev -d

comment:1 by bonefish, 10 years ago

If only graphics are slow, it's probably an MTRR issue. Unfortunately your syslog is truncated. Please increase the syslog buffer size (the setting "syslog_buffer_size" in /boot/home/config/settings/kernel/drivers/kernel).

by PieterPanman, 10 years ago

Attachment: syslog.2 added

New syslog with larger ringbuffer. No more truncs and drops

comment:2 by PieterPanman, 10 years ago

The rest feels ok. mtrr setup lists some failures, so I'll let you guys work your magic :)

comment:3 by axeld, 10 years ago

Component: Drivers/GraphicsSystem/Kernel
Owner: changed from nobody to bonefish

comment:4 by bonefish, 10 years ago

The RAM ranges are way too complicated:

KERN: add_memory_type_range(-1, 0x0, 0xbc4e2000, 6)
KERN: add_memory_type_range(-1, 0xbc6e2000, 0x17dd000, 6)
KERN: add_memory_type_range(-1, 0xbdfff000, 0x1000, 6)

The algorithm runs out of registers already with the first range. No idea what a good strategy would be. We could reserve a register or two when processing the RAM regions, so they would be available for the frame buffer, but in this case the frame buffer range isn't particularly friendly either:

KERN: add_memory_type_range(76, 0xd1000000, 0x6bb000, 1)

Besides, ATM the less of the RAM range is covered, the slower the whole system will eventually be -- we probably should at least allocate the affected pages, so that they won't be used later on.

For some reason Linux normally uses much simpler ranges. Would be interesting to know how they get the information.

comment:5 by PieterPanman, 10 years ago

Well, just let me know if you have a change for this, I can retry it and provide feedback. If you need any other information, just let me know.

comment:6 by PieterPanman, 10 years ago

Is there something I can hack in the kernel to get this to work for my case specifically?

in reply to:  6 comment:7 by bonefish, 10 years ago

Replying to PieterPanman:

Is there something I can hack in the kernel to get this to work for my case specifically?

In src/system/kernel/arch/x86/arch_vm.cpp:arch_vm_init_post_modules() you could comment out the loop calling add_memory_type_range() and add a single call to add_memory_type_range() instead. I would first try the following:

	add_memory_type_range(-1, 0, 0xbe000000, B_MTR_WB);

If the holes in the RAM memory ranges are locations where device registers are mapped, this could cause problems, though. Then I would try a smaller range -- replace the 0xbe000000 e.g. by 0xbc000000 -- and also limit the used RAM size to that amount (LIMIT_AVAILABLE_MEMORY in the kernel_debug_config.h header).

Your frame buffer range will still be too complex to be fully covered, but that should only concern the last 12 KB, i.e. only the last few rows.

comment:8 by PieterPanman, 10 years ago

Nice, that solved it for my system (the first option you quoted). Not sure if it is of any help, but I'll attach the linux kernel messages and lspci -v output.

by PieterPanman, 10 years ago

Attachment: dmessages.txt added

linux dmesg

by PieterPanman, 10 years ago

Attachment: lspci.txt added

lspci -v

comment:9 by PieterPanman, 10 years ago

This bug can probably be closed, as it is not a VESA problem. Should I create a new bug to improve MTRR setup?

in reply to:  9 comment:10 by bonefish, 10 years ago

Resolution: invalid
Status: newclosed

Replying to PieterPanman:

This bug can probably be closed, as it is not a VESA problem. Should I create a new bug to improve MTRR setup?

Sure, why not.

comment:11 by PieterPanman, 10 years ago

Done, see #5353. Thanks.

Note: See TracTickets for help on using tickets.