On Wed, 29 Oct 2003 10:19:20 -0800 Ian Romanick <[EMAIL PROTECTED]> wrote:
> Felix K�hling wrote: > > > On Wed, 29 Oct 2003 08:56:09 -0800 > > Ian Romanick <[EMAIL PROTECTED]> wrote: > > > > > >>I also believe the #1 and #3 will require a bit of work in the > >>client-side driver. It would need to batch up commands and wait to > >>issue them. The problem is state changes. The driver usually knows the > >>current hardware state before issuing a command. Since commands are > >>just being queued, there's know way to know what the state will be when > >>they are actually issued. The queuing is done per-drawable, but state > >>is tracked per-context. I think that's solvable, but it will take some > >>work. > > > > So you want to do the queueing in user space? The scheduler that Keith > > and I were talking about would be in the kernel. I guess the user space > > approach would be easier to implement. The question is how you resume > > Buffering the commands in user space avoids having to do state switching > in the kernel, which is nice. It should also be faster in the common case. > > > submitting commands. You can't do it asynchronously while the > > application is computing physics or AI. But the next GL function call > > could trigger flushing queued commands. > > Right. That shouldn't be a problem, though. If the application is > computing physics or AI there won't be any commands to queue. :) I did > think of another "problem" case. What happens when the application > calls glXSwapBuffers while the previous swap is still pending? I'm > guessing that we'd sleep, flush out all the commands (for the whole > frame!), then issue the new swap. Queuing texture uploads would be > interesting... > > Basically, queuing commands while we wait for a swap to complete is like > building a display list. Maybe it would be easier to tackle the problem > from that point of view? When a swap is pending we'd "somehow" switch > to build-display list mode. When the swap completed we'd execute the > currently built display list and switch back to immediate mode. Dunno... Could we avoid queuing of commands with tripple buffering? Buffer 1 would be displayed. Buffer 2 has completed rendering and is waiting for its buffer swap. Now the application can continue rendering to buffer 3. When buffer 3 is finished before the swap for buffer 2 has happened then we can just throw away buffer 2 and continue rendering to buffer 2 while 3 is waiting. ... and so on. Cheers, Felix ------------ __\|/__ ___ ___ ------------------------- Felix ___\_e -_/___/ __\___/ __\_____ You can do anything, K�hling (_____\�/____/ /_____/ /________) just not everything [EMAIL PROTECTED] \___/ \___/ U at the same time. ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
