[compiz] Nvidia performance bug and vterm switching bug

[Vasek Potocek]

>> This has been a long problem with Compiz that NVIDIA never fixed,
>> intermittent performance problems such as hick ups; the problem is easily
>> reproducible moving the cursor while opening programs such as Firefox or
>> Evolution.
>> Until Compiz 0.3.4 this bug was fixed setting the __GL_YIELD environment
>> variable to "NOTHING" in Compiz environment.
> the only thing that this changes (and is supposed to change) is to make 
> compiz responsive under high cpu load.
>> Since Compiz 0.3.6 setting the __GL_YIELD environment variable to 
>> "NOTHING"
>> is not enough, but launching Compiz WITHOUT "--unredirect-rendering" 
>> is also
>> needed to fix this. So whats the problem using direct-rendering? using
>> direct-rendering triggers the NVIDIA vterm switching bug, that makes the
>> screen keep black on vterm switching. If one clicks at the black 
>> screen, a
>> hard reboot is needed; the only solution is to kill X and start it again.
> Turn of sync to vblank this might be causing this.
>> Also, for some people like me, using --indirect-rendering gives better
>> performance than using direct rendering.
> no its not!
> if you use indirect rendering on nvidia the _GL_YIELD env variable will 
> gets ignored and the system will be almost unuseable under high load.
I can confirm the problem, although it does not happen regularly for me --
-- sometimes compiz crashes with a SEGFAULT instead and sometimes all
continues to work normally after a few VT switches. For that reason, I'm
using --indirect-rendering by default and have few experience with the
opposite.
I have turned on the DEBUG macro and found my terminal is filled by a flood
of messages like this:
> X Error of failed request: BadValue (integer parameter out of range for operation)
>   Major opcode of failed request:  128
>   Minor opcode of failed request:  16
>   Resource id in failed request:  0x20de
every now and then when direct rendering is used. However, I can't tell
where such message comes from, because the minor opcode of 16 doesn't
mean anything useful: X_GLXVendorPrivate. I think this can very well cause
the slowdown, but the VT switching bug probably not.
Note: Turning off Sync to VBlank seems only to attenuate the latter.