On Fri, 2010-01-15 at 10:48 +0800, Chia-I Wu wrote: 
> On Fri, Jan 15, 2010 at 9:35 AM, Jakob Bornecrantz <ja...@vmware.com> wrote:
> 
> > Some things that needs to worked out about this interface is how to handle
> > glViewport vs DRI2, since the code in glViewport needs to force a update of
> > the buffers in DRI2 but not for other state trackers. If we can some how
> > work around the need to force a update in a way that works on old servers
> > that would be great, but I doubt that can be done.
> With the mesa/st having access to the new st_framebuffer/sm_surface, it can
> call validate upon glViewport.  Does that suffice?
> 
> I am curious about this part too.  How often does DRI2GetBuffers be called in
> DRI2 drivers?

Currently, it's basically called on every glXMake*Current or glViewport
call, as there's no other reliable way to know when the buffer size
might have changed. Maybe at some point there will be a DRI2 event to
help with this.

Something I keep pointing out though is that ideally we want to avoid
calling DRI2GetBuffers() 'in the middle of a frame'. Once we've started
emitting drawing commands for a given set of DRI2 buffers, we should
stick to them until a buffer swap / frontbuffer flush. DRI2GetBuffers()
should only be called on a glXMake*Current or glViewport call if there's
been no drawing since the last buffer swap / frontbuffer flush (and in
the future maybe only if there's been no DRI2 event to signal it needs
to be called).


> In egl_g3d, it is indirectly called in every eglSwapBuffers and
> flush_frontbuffer.

That probably won't be enough for apps which don't render frames
continuously but only on demand:

buffer swap / frontbuffer flush -- DRI2GetBuffers -- window resize --
render frame: whoops, stale DRI2 buffer size


-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer

------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Reply via email to