Re: i915: wait for buffer idle before writing relocations

[Keith P. <ke...@ke...>]

On Mon, 2007-12-10 at 13:27 +0000, Keith Whitwell wrote:

> OK, it sounds like you're talking about situations where the driver is=20
> modifying state in buffers *only* through changes to the relocations?

Yes, although I also don't expect this to be common.

> It's probably not surprising the fence is not implemented as I'd=20
> normally think that those relocation changes would be associated with=20
> some changes to the other data, and that would imply mapping the buffer=20
> (and hence the wait).

If the buffer was mapped (and waited for) by the client, then the kernel
'wait' will be free.

>   I do understand the examples though and can see=20
> where you're trying to take this.

Ok, thanks for thinking it through.

> Anyway, I'm hopeful that this won't break other usages...

I think the interesting usage that you point out is where the
application "knows" that a wait isn't necessary as the previously
referenced data will not be re-used, and only new portions of the buffer
need relocations.=20

Given the choice between avoiding waits for cases we have today vs
avoiding waits for cases we may try in the future, it seems reasonable
to solve what we're using now.

--=20
kei...@in...