TwinView incorrectly indicates Xinerama as off when using two cards

[JaXXoN]

Originally Posted by ebf

as far as I know it is not currently possible to have both Xinerama and XRandR enabled.

Right, but you don't need XRandR to rotate the screens! The nvidia driver
can do that for you internaly i.e. by applying the option "Rotate" "Left"

Please find attached an example xorg.conf file that uses three 1600x1200
LCDs rotated for a 3600x1200 setup. It uses separate screens, so the
xinerama information will be fine. However, i have noticed that there
is quite some 3D performance drop (only 1/3 of the FPS for UT2K4).

There is basically nothing wrong about having three separate screens,
but dragging windows from one screen to another causes redraw-event,
which can be pretty annoying. This is why i created the beforementioned
patch so that you can avoid the redraw events by using twinview but
still get the desired XineramaInfo.

I think it should be possible to have a triple head setup with a rotated
twinview screen by i.e. adding both options "TwinViewOrientation" "Above"
and "Rotation" "Left", but i never tried that out.

regards

Bernhard


regards

Bernhard

[ebf]

Thank you both, Bernhard and Aaron.

I had actually tried using the Rotate option some time in the past. However, even the 2D performance was prohibitively slow. In particular, it seemed the rotation was being executed in software (i.e., by my CPU) rather than by the GPU. By contrast, when I use TwinView+XRandR, the speed is normal.

I should try it again, of course, since you are both suggesting it. But any idea as to why the Rotate option is apparently not performed by the graphics card?

Eric

[AaronP]

The rotation is performed by the GPU. While there's some slowdown because the GPU is doing more work, it shouldn't be as slow as you're saying it was.

[ebf]

I tried the Rotate option again. I'm not sure what's different from last time, but it works perfectly, including Xinerama support. Thanks!

[ebf]

Originally Posted by AaronP

The rotation is performed by the GPU. While there's some slowdown because the GPU is doing more work, it shouldn't be as slow as you're saying it was.

Aaron,

Though I reported success earlier today, I think there is actually still the problem I experienced a year ago last time I tried the Rotate option. The difference now, I think, is that I am using a dual-core processor, so I didn't notice the slowdown right away.

In particular, even just sitting with top(1) running but otherwise idle, I observe that X consumes about 7% of one of my cores. By contrast, when I run without the Rotate option, this is under 1%. To me, this suggests my CPU is doing work for the rotation that is normally performed by the GPU.

The reason I checked my CPU usage is that I noticed slowdown while performing compilation, which nearly fully-utilizes both cores. When both cores are utilized, my UI experience starts to become noticeably slower. This happens with the Rotate option, but it would never happen when rotating via RandR.

So, is this a bug in (my version of) X, or in the nvidia drivers?

Thanks,

Eric

[AaronP]

I don't think this is a bug. Both the CPU and the GPU have to do more work when rotation is enabled.

[ebf]

Aaron,

Why such a noticeable difference between TwinView+RandR versus Xinerama+Rotate, then? The issue I reported with CPU usage for the Rotate option is not a problem at all when using TwinView+RandR, even though I am rotating in that case as well.

Eric

[AaronP]

Xinerama also creates more work for the CPU and GPU.