Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 18 May 2007 16:43:37 -0500
From:      Craig Boston <craig@yekse.gank.org>
To:        James Snyder <jbsnyder@fanplastic.org>
Cc:        freebsd-ports@freebsd.org
Subject:   Re: HEADS UP: xorg upgrade plans
Message-ID:  <20070518214337.GA52635@nowhere>
In-Reply-To: <464E0B62.8060505@fanplastic.org>
References:  <464E0B62.8060505@fanplastic.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, May 18, 2007 at 03:24:02PM -0500, James Snyder wrote:
> Window decorations died once while switching back and forth to another
> virtual terminal and GL screensavers hang up (first frame rendered,
> subsequent ones do not).

I've been meaning to post on this subject, though have been looking for
an appropriate nvidia forum or list to have a better chance of making
them aware of the problem.  So far I'm 0 for 2 on FreeBSD machines
using the nvidia driver with GL and Composite.

For clients using direct rendering, it behaves as you said -- rendering
one frame at most and then hanging.

For clients using _indirect_ rendering, it's slightly better.  They will
render but just be choppy.  The weird thing is that the client _thinks_
it's rendering normally (they report normal FPS), but only every 4th or
5th frame actually gets displayed on the screen.

If you do something that causes the screen to refresh, such as moving a
window or rotating the cube in compiz, then it displays the missing
frames and renders pretty much normally -- until you stop the action
that's causing it to refresh :)

It doesn't seem to make any difference whether the composite manager is
using GL or not -- I tried both beryl and xcompmgr.

You can force the NVidia libGL to use indirect rendering by setting
__GL_FORCE_INDIRECT=1 in the environment.  I'm using that as a
workaround, though GL clients still look pretty terrible even with it.

Craig



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070518214337.GA52635>