On Thursday 24 August 2006 17:46, Timothy Miller wrote: > On 8/23/06, Lourens Veen <[EMAIL PROTECTED]> wrote: > > Okay, let me rephrase that again. The abstraction contains > > operations. What guarantees does the system give with respect to > > each of these operations, and to the sequence of operations as a > > whole? A real-time system would guarantee that each operation > > completes within a certain amount of time for example, whereas a > > non-realtime one wouldn't. Perhaps the system guarantees that the > > operations are executed serially, in the order in which they were > > submitted. Or maybe it only guarantees a weaker constraint: that > > all the operations on a certain grid are executed in the order in > > which they were submitted. > > Or all the operations from a particular client application are > executed serially. I have some ideas about how to handle context > switches well on the GPU well, although they may apply better to OGA > than other chips. > > > Note that this latter abstraction will still work as you would > > expect. > > Yes. We only need to have things complete in an order that is, as > they say in distributed system semantics, "serializable". That is, > there is a directed graph of dependencies, and the order in which > things are executed does not violate the ordering of that graph.
The way it's defined in databases (my current field) is that if parallel transactions are executed in a serialisable manner, then the final result is the same as when they were executed serially, in some unspecified but possible order. With this definition, serialisable implies out-of-order execution. We might specify this kind of serialisability between the commands sent by different processes, while specifying strict in-order execution for the commands in a single stream. Or something equivalent, of course. As an example, let's say that we have processes A, B and C, which are sending commands A1, A2, ... ; B1, B2, ...; C1, C2, ... and so on. Let's say commands arrive as follows: A1 A2 B1 C1 B2 A3 B3 C2 The only guarantee with respect to order of execution is that at any point during execution the result is equivalent to that obtained when the commands submitted thus far were executed in some order satisfying A1 < A2 < A3 < ...; B1 < B2 < B3 < ...; C1 < C2 < C3 < ... Incidentally, note that the primary grid would need special consideration from the command scheduler, because any commands changing it need to be executed serially, not just serialisably, since intermediate results may be visible. > BTW, I was thinking about the "submit" or "update" command. There > should be two of them or one with a flag. > > In one case, the submit is immediate. The commands are immediately > issued to the GPU or queued up behind other commands being executed > already. > > In the other case, an anticipatory delay is added. If you submit no > new commands within the delay period, they get sent. If you submit > more commands within that time delay, the old submit is canceled, and > the delay is reset. [If your command queue is full, then send it > regardless.] > > I've messed around with this before, and I can tell you that the > reduction in overhead from bulking things up in an anticipatory way > can be immense. Performance goes way up, because you're not doing > the work of submitting packets to the GPU until you either have a > large number of them to send in bulk or you don't have any more to > send. Unless we add real-time guarantees to the model, there is no semantical difference. Without any guarantees as to execution speed, we could just queue up everything as long as it's for a finite amount of time. It does raise a very good point: the model is constrained by two kinds of guarantees. First, there are transformational guarantees about the output that will be produced for a given input. Second, there are temporal guarantees about when that output will appear. I've made some suggestions for the first kind of guarantees. I think designing a useful set of guarantees of the second kind is much harder. It is at least related to Hamish' recent post on command scheduling and delaying commands until some event occurs, to the vretrace discussion, _and_, via the ordering constraints, to the guarantees of the first kind. Sounds like a great subject for a PhD thesis :-). Or at least for some more thought. > > Furthermore, if we delay any operations on the primary (visible) > > grid until the vertical retrace occurs, then you can do double > > buffering by simply drawing to the backbuffer, doing a flip (which > > would be treated as an operation on both buffers), and waiting for > > it to complete. Triple buffering? Perform operation on one of the > > backbuffers, flip it with the primary, continue sending operations > > on the other backbuffer. They'll bypass the flip, so there's no > > time wasted. > > Well, the only thing wasted is any frame you draw that never gets > shown. Say you're getting 200FPS on the backbuffer. What you do is > keep switching back and forth between the two backbuffers. Then at > your real framerate, during vertical blank, you swap the front buffer > for the back buffer that is currently not being drawn to. You'll end > up wasting loads of CPU and GPU time on frames that are never seen. That was the point of the wait-for-completion operation: you can flip, draw another frame, do another flip, and wait for the first flip to finish before drawing a third frame. Lourens
pgpJihxw7tS9J.pgp
Description: PGP signature
_______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
