On Tue, Oct 4, 2011 at 1:48 PM, Thomas Hellstrom <thomas@xxxxxxxxxxxx> 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. > > 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 > 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
