Keith Whitwell wrote:
Thomas Hellstr�m wrote:
Hi!
Keith Whitwell wrote:
get lock while (timestamp mismatch) { release lock request new cliprects and timestamp get lock }
Note that is the contended case only. What's the worst that could happen - somebody's wizzing windows around and our 3d client sits in this loop for the duration. Note that the loop includes X server communication so it's not going to suck up the cpu or anything drastic.
This is basically what I'm doing right now. The problem is as the code continues:
get lock while (timestamp mismatch) { release lock request new cliprects and timestamp get lock } wait_for_device() render_to_scale_buffer() wait_for_device() render_to_back_buffer() wiat_for_device() blit_to_screen() release_lock()
And, to avoid holding the lock while waiting for the device, since that blocks use of the decoder while I'm doing scaling operations, I'd like to
mark_scaling_device_busy() get_drawable_lock() get lock while (timestamp mismatch) { release lock release_drawable_lock() request new cliprects and timestamp get_drawable_lock get lock } release_lock() wait_for_device() get_lock() render_to_scale_buffer() release_lock() wait_for_device() get_lock() render_to_back_buffer() release_lock() wait_for_device() get_lock() blit_to_screen() release_lock() mark_scaling_device_free()
And then release_drawable_lock()?
What semantics are you hoping for from the drawable lock in your scenario above? Just that the cliprects won't change while it is held?
Exactly on both points, except the drawable_lock would have to be released before mark_scaling_device_free() to avoid deadlocks.
So a few more questions:
1) Why (exactly) is keeping the cliprects from changing a concern? What happens if they change between steps above?
2) Could the DDX driver blit the contents of these additional buffers (scale, back) at the same time it blits the frontbuffer so that the window change "just works"?
3) I don't think that the drawable lock is a pretty thing, is it worth keeping it around for this? Would some black areas or incomplete video frames during window moves be so bad? Note that the next version of this hardware might have a proper command stream that just allows you to submit all those operations to hardware in a single go, and not have to do the waiting in the driver...
Keith
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=click -- _______________________________________________ Dri-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
