On Fri, 2007-12-07 at 11:15 +0000, Keith Whitwell wrote: > Keith, > > Thomas has just left for two weeks of (well deserved!) holiday, so he > may be slow to respond. > > In the meantime, have you considered how this will interact with > userspace buffer pools? I know you guys aren't using them at this > point, but I'm of the opinion that they are an important facility which > needs to be preserved. At worst it may be that some additional flag is > needed to control this behaviour. > > Secondly I wonder whether this isn't already caught by other aspects of > the buffer manager behaviour? > > ie, if the buffer to which the relocation points to is being moved, > doesn't that imply all hardware activity related to that buffer must > have concluded? IE, if the buffer itself is free to move, surely all > commands containing relocations (or chains of relocations) which point > to the buffer must themselves have completed??
No, I may be emitting a relocation in a state buffer pointing at a new (not moved) state buffer, without changing any other state in my buffer. Think of the SF viewport, which can change without anything in SF state changing other than the SF VP offset. You can also imagine once the kernel's entirely in control of ring operations, it doing accelerated moves of buffers for memory management purposes, which means that you don't have to sync to move buffers. (though this may not be a win, as estimates I did for EXA based on simulation a long time ago didn't look promising). It would be nice if we could use MI_WRITE_DATA_IMM (sp?) for relocations in that case to avoid syncing. However, you don't get any guarantees about the flushing of it, so it's unreliable, along with not being an obvious performance win in tests done in the 2d driver as I recall. -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php
-- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
