MTRR and 71.67

famhaugland · 04-01-05, 12:25 PM

Hi,
We upgraded the linux nvidia driver to 71.67. (kernel is 2.6.5). Before the /proc/mtrr file reported
reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1
reg01: base=0x7ff80000 (2047MB), size= 512KB: uncachable, count=1
reg02: base=0xd0000000 (3328MB), size= 256MB: write-combining, count=1
reg03: base=0xe0000000 (3584MB), size= 256MB: write-combining, count=1

As I understand reg02 is for the agp driver and reg03 is for the xserver. After upgrade to 71.67 both reg02 and reg03 are gone. (I suppose it has something to do with the release info: "PAT (Page Attribute Table) is used where possible instead of MTRRs")

We have students developing visualisation software , and this software is now several times slower (frames/sec) with the release 7.0 driver than with the release 6.0 drivers. The software is transferring lots of triangels from memory to agp card for each frame, so the software is depended on a fast AGP bus.

We got the same result earlier when we tried to upgrade from 2GB to 4GB RAM (using release 6.0 driver). Then the two write-combining regions could not be created because of an uncachable region from 3 to 4 GB in the /proc/mtrr file. The framerate also then dropped and the software became several times slower. We then had to go back to 2GB RAM.

We are using motherboard Intel 7505vb2, two Intel Xeon processors 3GHz and NVIDIA QUADRO FX 3000 graphics board.

Regards
John Ivar

**zander** · 04-01-05, 01:18 PM

Beginning with the 1.0-7167 driver release, the NVIDIA Linux graphics driver no longer uses MTRR's to specify cache attributes; instead, it uses the PAT and per-page attributes, if available (if PAT support is unavailable, the driver falls backs to MTRR's). Your problem is likely caused by a known performance problem with 1.0-7167 in combination with AGPGART; please upgrade to 1.0-7174.

famhaugland · 04-01-05, 03:32 PM

We will try the new version (Tuesday next week). However we have defined NvAGP=1 under the graphics device in xorg.conf file when trying 71.67, so I suppose we did not have problems related to agpgart.

With current 6.0 series driver and NvAGP=1 :
$lsmod | grep nvidia reports

nvidia 3474172 36
agpgart 36912 1 nvidia

What does this mean ? Why is agpgart module there ?

John Ivar

LubosD · 04-01-05, 03:50 PM

The best and really 100% working way to get rid of agpgart is to remove it from kernel.

(Even when I didn't have agpgart in my startup scripts - and anything related to it - it has always loaded).

**zander** · 04-01-05, 03:55 PM

@famhaugland: on systems with kernels configured with AGPGART support, nvidia.ko relies on agpgart.ko to determine if a backend driver is present, in which case NvAGP is disabled. The AGPGART performance problem doesn't affect you if you're using NvAGP. Can you provide more specific information about the performance loss you're seeing.

famhaugland · 04-01-05, 05:02 PM

Using the 71.67 driver the performes is perhaps only 3 frames pr second. With the old driver it was good (in my opinion at least 20 frames pr second or more). I have not measured the performance in detail.

The software has been developed by students. It is visualizing a terrain. With the 71.67 driver, the terrain updates very slowly and it has also holes in it.

The software is using triangle fans. Number of triangels is around 100 000. The number of triangels,coordinates and normals are beeing continuously updated using a render callback from a CLOD algorithm.

The terrain is implemented as a node in a SGI Performer scenegraph and is using pfGeoSet and PFGS_TRIFANS as primitives.

I can give more details if you want.

**zander** · 04-03-05, 08:48 AM

@famhaugland: please send a bug report to linux-bugs@nvidia.com and include a detailed description of the problem, as well as the log file generated by `nvidia-bug-report.sh`; a sample application would also be very helpful.

04-01-05, 12:25 PM	#1
famhaugland Registered User Join Date: Feb 2004 Posts: 3	MTRR and 71.67 Hi, We upgraded the linux nvidia driver to 71.67. (kernel is 2.6.5). Before the /proc/mtrr file reported reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1 reg01: base=0x7ff80000 (2047MB), size= 512KB: uncachable, count=1 reg02: base=0xd0000000 (3328MB), size= 256MB: write-combining, count=1 reg03: base=0xe0000000 (3584MB), size= 256MB: write-combining, count=1 As I understand reg02 is for the agp driver and reg03 is for the xserver. After upgrade to 71.67 both reg02 and reg03 are gone. (I suppose it has something to do with the release info: "PAT (Page Attribute Table) is used where possible instead of MTRRs") We have students developing visualisation software , and this software is now several times slower (frames/sec) with the release 7.0 driver than with the release 6.0 drivers. The software is transferring lots of triangels from memory to agp card for each frame, so the software is depended on a fast AGP bus. We got the same result earlier when we tried to upgrade from 2GB to 4GB RAM (using release 6.0 driver). Then the two write-combining regions could not be created because of an uncachable region from 3 to 4 GB in the /proc/mtrr file. The framerate also then dropped and the software became several times slower. We then had to go back to 2GB RAM. We are using motherboard Intel 7505vb2, two Intel Xeon processors 3GHz and NVIDIA QUADRO FX 3000 graphics board. Regards John Ivar

04-01-05, 01:18 PM	#2
zander NVIDIA Corporation Join Date: Aug 2002 Posts: 3,740	Re: MTRR and 71.67 Beginning with the 1.0-7167 driver release, the NVIDIA Linux graphics driver no longer uses MTRR's to specify cache attributes; instead, it uses the PAT and per-page attributes, if available (if PAT support is unavailable, the driver falls backs to MTRR's). Your problem is likely caused by a known performance problem with 1.0-7167 in combination with AGPGART; please upgrade to 1.0-7174.

04-01-05, 03:32 PM	#3
famhaugland Registered User Join Date: Feb 2004 Posts: 3	Re: MTRR and 71.67 We will try the new version (Tuesday next week). However we have defined NvAGP=1 under the graphics device in xorg.conf file when trying 71.67, so I suppose we did not have problems related to agpgart. With current 6.0 series driver and NvAGP=1 : $lsmod \| grep nvidia reports nvidia 3474172 36 agpgart 36912 1 nvidia What does this mean ? Why is agpgart module there ? John Ivar

04-01-05, 03:50 PM	#4
LubosD Registered User Join Date: Jan 2005 Location: Czech Republic Posts: 451	Re: MTRR and 71.67 The best and really 100% working way to get rid of agpgart is to remove it from kernel. (Even when I didn't have agpgart in my startup scripts - and anything related to it - it has always loaded).

04-01-05, 03:55 PM	#5
zander NVIDIA Corporation Join Date: Aug 2002 Posts: 3,740	Re: MTRR and 71.67 @famhaugland: on systems with kernels configured with AGPGART support, nvidia.ko relies on agpgart.ko to determine if a backend driver is present, in which case NvAGP is disabled. The AGPGART performance problem doesn't affect you if you're using NvAGP. Can you provide more specific information about the performance loss you're seeing.

04-01-05, 05:02 PM	#6
famhaugland Registered User Join Date: Feb 2004 Posts: 3	Re: MTRR and 71.67 Using the 71.67 driver the performes is perhaps only 3 frames pr second. With the old driver it was good (in my opinion at least 20 frames pr second or more). I have not measured the performance in detail. The software has been developed by students. It is visualizing a terrain. With the 71.67 driver, the terrain updates very slowly and it has also holes in it. The software is using triangle fans. Number of triangels is around 100 000. The number of triangels,coordinates and normals are beeing continuously updated using a render callback from a CLOD algorithm. The terrain is implemented as a node in a SGI Performer scenegraph and is using pfGeoSet and PFGS_TRIFANS as primitives. I can give more details if you want.

04-03-05, 08:48 AM	#7
zander NVIDIA Corporation Join Date: Aug 2002 Posts: 3,740	Re: MTRR and 71.67 @famhaugland: please send a bug report to linux-bugs@nvidia.com and include a detailed description of the problem, as well as the log file generated by `nvidia-bug-report.sh`; a sample application would also be very helpful.