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.
/Thomas ------------------------------------------------------------------------- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
