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. 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. The anticipatory I/O scheduler in Linux also demonstrates the advantage.
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.
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.
There would probably have to be a way for the programme to sleep until a certain operation it issued has completed. Also note that there is now no concept of a vertical retrace. Displays that don't have to wait for a vertical retrace can simply have a driver that doesn't wait.
Definitely. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
