Kristian Høgsberg <k...@bitplanet.net> writes: > On Sun, Jan 17, 2010 at 11:18 PM, Francisco Jerez <curroje...@riseup.net> > wrote: >> Kristian Høgsberg <k...@bitplanet.net> writes: >>> No, it sounds good, I'm happy that you're looking into this. I'll >>> have a closer look tomorrow, but what I've had in mind for this kind >>> of thing was that we could just allocate the new buffers up front in >>> the X server. Then, instead of an invalidate event and a subsequent >>> DRI2GetBuffers, we'll just have a "here are your new buffers event", >>> so we avoid the round trip. >> >> Yeah that's sensible, the only problem I see with doing things that way >> is that it doesn't give the driver an opportunity to flush its rendering >> queues before swapping buffers, so some of it could be lost buried in >> the old buffers. > > Right. Another option is to tell the client about new buffers in the > DRI2SwapBuffer/DRI2CopyRegion reply instead - or to kill two birds > with one stone, make DRI2SwapBuffers/DRI2CopyRegion one-way requests > (that is, requests without a reply) and then send an event instead. > This lets the client do other things while waiting for the server to > reply, and we'll wait for the event to arrive in the GetBuffers > callback from the driver if it hasn't already. The event will always > be sent in response to either DRI2SwapBuffer or DRI2CopyRegion, which > addresses your concern about sending the event to everybody. The > client must wait for the event before it starts rendering the next > frame since it could receive new buffers and in any case the server > needs to submit the back->front blit first (which is the reason > DRI2CopyRegion is a round-trip). >
That last proposal has a clear advantage: it needs *zero* protocol
changes: It could be implemented sending SwapBuffers and GetBuffers in
one go, without waiting for the responses. Instead we handle them
asynchronously with some "async handlers". If it hasn't arrived yet by
the time we start drawing again, we XSync().
However, IMHO, we still want a DRI2InvalidateBuffers-like event,
because:
* That solution wouldn't make event-driven GL applications very
happy, the succession of events could be something like:
1/ A frame is drawn, the app flushes and then it waits for events.
2/ We get the GetBuffers reply and install our new buffers.
3/ The user attempts a resize and the application reacts redrawing the
exposed areas... Helplessly, because we're still on the pre-resize
buffers, and they aren't big enough to hold it.
* It breaks up when there are several contexts bound to the same
drawable, because only the one calling SwapBuffers gets buffer
updates.
As I see it, forcing a buffer update on each flush or not,
asynchronously or not, is somewhat orthogonal with having the server
send buffer invalidation events to clients, and we probably want both
eventually.
> That would be the ideal solution as far as I know, and if we're
> changing things, this is what we should go for.
>
> cheers,
> Kristian
pgpDvgpvNYBtf.pgp
Description: PGP signature
------------------------------------------------------------------------------ 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
