Re: Nvidia 3000G Support

Sean Ahern <[email protected]>
Newsgroups gmane.comp.graphics.chromium.user,gmane.comp.graphics.chromium.devel
Message-ID <[email protected]>
Ricky Uy wrote:
> Hi, I remember that a little while ago there was talk that some people
> were implementing 3000G support in Chromium to handle frame synch
> using some of the API that is provided by Nvidia with the cards.  Has
> this been completed?  If not, what issues are left to resolve?

This has yet to be completed.  We are working with nVidia to resolve the
technical issues, but have yet to reach resolution.  Since we haven't
been able to fix the problem with test apps, there as of yet no reason
to fully integrate the API changes into Chromium or DMX, though there is
some support in the render SPU.  (see is_swap_master, num_swap_client,
nv_swap_clients, nv_swap_group, and swap_master_url)

I'm sure Brian has more comments about this.

> And what kind of support was this exactly?  Was this to make sure that
> the framebuffers in each of the render spu machines had the right
> frame in it, and that SwapBuffers() calls would be made at about the
> same time along with an Nvidia call to make sure they refreshed at the
> same time?

There are two types of synchronization that one might desire.  One is
swaplock, where windows are put in to a "swap group".  When one window
is told to swap, all of them are guaranteed to swap at the same time.
This can be accomplished to a large degree in user-space software.  In
fact, Chromium already support for this in the tilesort SPU (see
sync_on_swap, sync_on_finish).  In many cases, any tearing that might
happen is very minor and isn't even visible to most people.  GLXProxy in
DMX also has support for this if you pass "-glxsyncswap" to DMX.

The second type of synchronization is framelock, where the left and
right buffer swaps are synchronized between cards.  This type of swap
cannot be done in software.  It also requires a higher degree of
synchronization, as any tearing is easily visible to someone wearing
stereo glasses.  This is the one that we're having the most trouble
with.

> I am experiencing some frames getting ahead of others in my wall
> display and I am interested in pursuing this to fix the problem.  The
> other thing I was thinking might be causing the messed up frame synch
> is that I have a 25% overlap on each tile, causing the tilesort spu to
> perform more computations.  So yeah, any information on the Nvidia
> stuff would be greatly appreciated.  Thanks so much!

__
[email protected]
925-422-1648


-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.