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?
> 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
Eric Anholt anholt@...
Get latest updates about Open Source Projects, Conferences and News.