Poor vesa performance on NVidia Quadro FX770M

[PieterPanman]

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.

[PieterPanman]

listdev

[PieterPanman]

listdev -d

[bonefish]

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

[PieterPanman]

New syslog with larger ringbuffer. No more truncs and drops

[PieterPanman]

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

[bonefish]

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.

[PieterPanman]

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.

[PieterPanman]

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

[bonefish]

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.

[PieterPanman]

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.

[PieterPanman]

linux dmesg

[PieterPanman]

lspci -v

[PieterPanman]

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

[bonefish]

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.

[PieterPanman]

Done, see #5353. Thanks.