With 185.18.14 driver, Xserver 100% pegged with a XCopyPlane call

[ocelot09]

We have to call XCopyPlane once a second through a Xt timeout proc. Whenever
this X function is called, the Xserver will be pegged @100%. Keyboard and mouse
hardly response unless we kill the process.

But if I run the same program without using the timeout proc, calling XCopyPlane
is just fine.

I saw this problem since 180.xx.xx released. So we have to stay with 177.70.33
driver. We have a 64bit Linux 2.6.9-67 with Quadro NVS 290 card.

[zander]

@ocelot09: please see http://www.nvnews.net/vbulletin/showthread.php?t=46678 for instructions on how to report a bug. If you can, please provide a test case that reproduces the problem you're seeing.

[ocelot09]

@zander: I cannot reproduce the problem with a small testcase. But it does happen
when running our programs. Many our customers reported the same issue after
they moved to the 180 driver. So we have to tell them to stay with older releases.

So I wonder if we can send you the whole application system to nVidia to trace the
bug?

Right now we workaround the problematic XCopyPlane call by using the XGetImage
to manually extract a bitmap mask. That worked. This indicates that there is a bug
there indeed. Can you check what the code behind XCopyPlane changed between
170 and 180? This X function is basically used to extract a 1-bit bitmap from a full
depth (e.g. 24bit) pixmap. I guess there is something wrong around this operation.

[AaronP]

Does performance improve if you run "nvidia-settings -a InitialPixmapPlacement=1"?

[ocelot09]

@AaronP: Finally it works by setting the InitialPixmapPlacement=0. I first tried the value 1
as you suggested. It's kind working, but it takes 3+ seconds to execute XCopyPlane for the
first time. After that it just takes 10ms. But that happens again when I enlarge canvas, which means I will free the old pixmaps and create new pixmaps with the same size as the
resized canvas.

So 0 for InitialPixmapPlacement works for me so far, i.e. force pixmaps stay in system memory. I checked its default value on my Linux box. It's 2, i.e. create pixmaps in video memory. Our code is calling the following X functions:

XCopyPlane(... pix24, pix1); // extract a bitmap from pix24 to pix1
XSetClipMask(... gc, pix1); // use the extracted pix1 as clipping mask
XCopyArea(... another_pix24, pix24, gc ...) // copy another pixmap to the pix24 where
// the pix1 mask was extracted from

Does the above calling sequence mess up your driver in the configuration 2?

Another issue: I just tried to put "InitialPixmapPlacement" "0" in the Device session of
the xorg.conf. I got the message in Xorg.0.log:

(WW) NVIDIA(0): Option "InitialPixmapPlacement" is not used.

Anything wrong here? I attached xorg.conf and Xorg.0.log files.