On Tue, 2008-08-19 at 16:31 -0400, Kristian Høgsberg wrote: > We can just submit the swap buffer commands, wait for them to fire and > then send the reply. What we do now is to wait for vblank and then > submit the swap commands, what I'm suggesting is to submit the > commands and wait for vblank. Same thing.
We tried this briefly with Xv and the effect on interactivity was fairly horrible -- the whole system shut down for long periods if the commands were submitted a long time before vblank. I'd prefer to avoid this. > We cound conceivably do better if we could let software queue up > commands for the next frame, either in a blocked command ring (sw or > hw) and then unblock it once the swap commands have been executed. > This increases the parallelism, but relieson synchronization between > multiple command queues. Some hardware may be able to manage this; one concern is that if you cannot interrupt command execution, you may miss the vblank window and end up with occasional tearing on the screen. This does seem better than blocking the ring though. > I doubt it will be really wasteful - we have to do the reply for > synchronization purposes, adding ~100 bytes of data to the reply > doesn't seem significant. My concern isn't that the reply data will be significant, but that somehow computing what needs to be in that reply will constrain our implementation in the future. If it turns out that this reply data isn't actually useful, but has adverse effects on future implementations, it would be better that we not provide it. What we can do is allow the reply to have additional data and carefully version the protocol so that we can add useful data in a future minor release of the protocol; it's not hard to make sure existing versions of the library can skip over unexpected data. > Doing it as two requests lets you do other requests between them > though and the overhead of an extra async request before the > synchronous second half is negligible. Yeah, if you want to allow the client to continue executing requests without blocking, then we'll either want a separate reply or an event. Of the two, I agree that the reply is probably a better plan given the complexity of insisting on sensible X event processing by all GL clients. -- [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
-- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
