Hi,
I try to use the function glXSwapBuffers, but with this function, the demo
doesn't run correctly, I have no vertical sync. So i try to follow the
differents function called to see where is my problem.
The function glXSwapBuffers (file : glxcmds.c) calls the function glFlush (file
: ???) and the function swapBuffers ( = dri2SwapBuffers, file : dri2_glx.c).
The function dri2SwapBuffers (file : dri2_glx.c) calls the function
dri2CopySubBuffer (file : dri2_glx.c).
The function dri2CopySubBuffer (file : dri2_glx.c) calls flush (
(*pdraw->psc->f->flush)(pdraw->driDrawable) , file : ???) and the function
DRI2CopyRegion (file : ???)
Moreover, i know that my kernel use the function drm_wait_vblank (file
drm_irq.c) by the driver drm.ko.
So I would like to know where are the functions glFlush, flush and
DRI2CopyRegion, and how runs this functions with the driver drm.ko.
Thanks
________________________________
Nicolas Cadio
ENSSAT, EII3
nca...@enssat.fr
cadio_nico...@yahoo.fr
________________________________
________________________________
De : Jesse Barnes <jbar...@virtuousgeek.org>
À : Owen Taylor <otay...@redhat.com>
Cc : Nicolas Cadio <nicolas.ca...@ymail.com>;
"mesa3d-dev@lists.sourceforge.net" <mesa3d-dev@lists.sourceforge.net>
Envoyé le : Mercredi, 1 Juillet 2009, 19h35mn 21s
Objet : Re: [Mesa3d-dev] Re : Re : Problem with the xdemo glsync
On Wed, 01 Jul 2009 11:53:14 -0400
Owen Taylor <otay...@redhat.com> wrote:
> On Tue, 2009-06-30 at 09:18 -0700, Jesse Barnes wrote:
> > That depends... If you're getting hit by scheduling latency (i.e.
> > your app doesn't actually get scheduled on the CPU until several ms
> > after the vblank interrupt fires), then there's no easy way to fix
> > it. You could try realtime scheduling and configuring things just
> > right so that your waiting apps always get scheduled in time, but
> > that's going to be difficult in a general purpose environment.
> >
> > If the interrupt is arriving too late, you could try one of the
> > other hardware mechanisms (fire an interrupt at a scanline near the
> > bottom of the screen instead, to give you some extra time or
> > something).
>
> Without looking at the demo source code, I suspect the problem might
> be something else. The implementation of sgi_video_sync in Mesa simply
> waits for the vblank interval and does nothing else.
>
> So, if I:
>
> - Do a bunch of rendering
> - Wait for vblank
> - glXSwapBuffers
>
> Then my command buffers will not be flushed to the video card until
> after vblank. If the command buffers take time to execute, then the
> swap buffers is delayed and you get a tear. So, you need to glFlush()
> before waiting for vblank.
Yeah, that's a good point. In the case of this demo we're just doing a
clear, so there shouldn't be much latency involved in buffer submission
for the swapbuffers (though there surely is some, sending a request to
the server for the copyregion isn't free).
>
> There's a more subtle reason why you want to actually glFinish()
> rather than glFlush() - if your rendering takes long enough so that
> you can't keep up with the refresh rate:
>
> - Do a bunch of rendering
> - glFlush
> - Wait for vblank
> - glXSwapBuffers
>
> Will cause the glXSwapBuffers to happen in the middle of a frame,
> while
>
> - Do a bunch of rendering
> - glFinish
> - Wait for vblank
> - glXSwapBuffers
>
> Will cause it to properly happen at the *second* vblank.
Of course glXSwapBuffers *should* just do the right thing and not tear
by default (this happens with current radeon & intel drivers afaik).
So I'd discourage people from using SGI_video_sync for tear-avoidance
in general. If you get tearing with glXSwapBuffers, file a bug.
--
Jesse Barnes, Intel Open Source Technology Center
------------------------------------------------------------------------------
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
