[PATCH 1/2] drm/ttm: add a way to bo_wait for either the last read or last write
maraeo at gmail.com
Tue Oct 4 19:08:43 PDT 2011
On Tue, Oct 4, 2011 at 1:48 PM, Thomas Hellstrom <thomas at shipmail.org> wrote:
> Bah, I totally missed this patch and thus never reviewed it :( Probably on
> There are a couple of things I'd like to point out.
> 1) The bo subsystem may never assume that fence objects are ordered, so that
> when we unref
> bo::sync_obj, we may never assume that previously attached fence objects are
> signaled and can be unref'd
> Think for example fence objects submitted to different command streams. This
> is a bug and must be fixed.
If what you say is true, then even the original sync_obj can't be
trusted. What if I overwrite sync_obj with a new one and the new one
is signalled sooner than the old one?
> We can detach fence objects from buffers in the driver validation code,
> because that code knows whether fences are implicitly ordered, or can order
> them either by inserting a barrier (semaphore in NV languange) or waiting
I am not sure I follow you here. ttm_bo_wait needs the fences...
unless we want to move the fences out of TTM into drivers.
> for the fence to expire. (For example if the new validation is READ and the
> fence currently attached is WRITE, we might need to schedule a gpu cache
> flush before detaching the write fence).
I am not sure what fences have to do with flushing. Write caches
should be flushed automatically when resources are unbound. When a
resource is used for write and read at the same time, it's not our
problem: the user is responsible for flushing (e.g. through memory and
texture barriers in OpenGL), not the driver.
> 2) Can't we say that a write_sync_obj is simply a sync_obj? What's the
> difference between those two? I think we should remove the write_sync_obj bo
Okay, but I think we should remove sync_obj instead, and keep write
and read sync objs. In the case of READWRITE usage, read_sync_obj
would be equal to write_sync_obj.
More information about the dri-devel