On Wed, 2008-02-27 at 20:41 +0100, Thomas Hellström wrote: > Eric Anholt wrote: > > On Wed, 2008-02-27 at 10:49 -0800, Thomas Hellstrom wrote: > > > >> shared-core/i915_dma.c | 13 +++++++++---- > >> 1 file changed, 9 insertions(+), 4 deletions(-) > >> > >> New commits: > >> commit 72983ff30183745cd96760aa07b857c44daebde7 > >> Author: Thomas Hellstrom <thomas-at-tungstengraphics-dot-com> > >> Date: Wed Feb 27 19:46:28 2008 +0100 > >> > >> Don't wait for buffer idle before applying relocations. > >> > >> diff --git a/shared-core/i915_dma.c b/shared-core/i915_dma.c > >> index b916441..2d26fcc 100644 > >> --- a/shared-core/i915_dma.c > >> +++ b/shared-core/i915_dma.c > >> @@ -860,6 +860,15 @@ int i915_apply_reloc(struct drm_file *file_priv, int > >> num_buffers, > >> drm_bo_kunmap(&relocatee->kmap); > >> relocatee->data_page = NULL; > >> relocatee->offset = new_cmd_offset; > >> + > >> + /* > >> + * Note on buffer idle: > >> + * Since we're applying relocations, this part of the > >> + * buffer is obviously not used by the GPU and we don't > >> + * need to wait for buffer idle. This is an important > >> + * consideration for user-space buffer pools. > >> + */ > >> + > >> > > > > I don't understand this comment. What would have ensured that this part > > of the buffer is not used by the GPU if you've removed the syncing that > > the DRM does when applying relocations? > > > Hmm, > I'd say user-space would've idled the buffers when they were written to > and the relocations were created. > But I guess you can use relocations to just patch state buffers up > without mapping them from user-space. Are you doing that for i965? In > that case I'll immediately revert to the original code.
User space *can't* idle the buffers, because it doesn't know if the kernel will need to write an updated relocation for buffer location moving or not. Only the kernel has that knowledge, unless you want to just fail out to userland when any buffer has moved. That sounds like minimal fun. -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
-- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
