On Tue, Oct 4, 2011 at 1:48 PM, Thomas Hellstrom thomas@shipmail.org wrote:
Bah, I totally missed this patch and thus never reviewed it :( Probably on vacation.
There are a couple of things I'd like to point out.
- 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.
- 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 member.
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.
Marek