> Ummm... which other models are you refering to? I'm told that >Windows does it globally.
Windows Direct Draw does per surface "Locking" which is a similar thing to what we are discussing, and yes, many drivers DO checkpoint very often. Direct Draw isn't a perfect analogy because it is the application that often wants to render to the surface with the CPU so there are many clients running in parallel. That compounds the impact of waiting too long for your sync. >Having per-surface syncing may mean >you end up syncing more often. Eg. Render with HW to one surface >then to another, then if you render to SW to both of those surfaces, >two syncs happen. Doing it globally would have resulted in only >one sync call. The driver has to take a little responsibility for knowing when it is out of sync. A global syncing driver would need to handle that second sync without any hardware interaction. The penalty is just the added indirect function call. This common scenario would be improved with per-surface sync: Put Image -> offscreen_surface1 ... offscreen_surface1 -> FB ... Put Image -> offscreen_surface1 The offscreen surface cannot be written until after the blit is finished so a sync is needed. However on a busy system there are lots of other blits going on during the "..." so global syncing before the 2nd Put is bad on 2 accounts. 1) You waited longer than you needed to, you only needed to wait for the blit that referenced offscreen1. 2) You idled the hardware while the 2nd put is happening. Now the graphics engine is idle instead of crunching data in parallel. Does the possible improved concurrency outweigh the additional overhead of making an indirect call to check the sync status everytime? It is Hard to tell. _______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
