Keith Packard wrote: >On Sat, 2007-12-22 at 07:59 +0100, Thomas Hellström wrote: > > > >>The way I would do this with a small extension to the current >>implementation is to >>implement a DRM_I915_FENCE_TYPE_READ fence type and a >>DRM_I915_FENCE_TYPE_WRITE fence type, which are triggered by the >>corresponding buffer object proposed_flags. >> >> > >Every fence would be READ|WRITE -- some of the buffers are read and some >are written. The access mode is not specific to the fence, rather it is >specific to the combination of the fence and each associated buffer. > > Yes, but all buffers carries with them the required fence_type, (bo->new_fence_type) which corresponds to the access mode of the buffer object. When the fence is created, the required fence type of *all* buffer objects on the unfenced list are ore'd together to create the cumulative fence_type used for the fence. So the fence may well end up with the type
DRM_I915_FENCE_TYPE_READ | DRM_I915_FENCE_TYPE_WRITE | DRM_FENCE_TYPE_EXE when the buffer object is fenced, the member bo->fence_type is set to the value of bo->new_fence_type and the next time the buffer object is validated and it's fence has not yet signaled, bo->fence_type is checked against the new required fence type and if they are incompatible, action needs to be taken for that buffer only. The simplest way is to wait for buffer idle. Note that the actual fence type of the fence itself is never used in this scheme. Only the required fence types computed from the access modes of the buffer object. > > >>This scheme would not work is a buffer is validated for READ and WRITE >>at the same time, and there might be better solutions. The needed >>changes to the current implementation are minimal, though. >> >> > >In a given command stream, it's certainly possible to mix read and write >operations, although under GL that's less likely. For an X server >though, it's extremely likely, so requiring any kind of synchronization >to switch from write to read would be bad. > > It's will not require any synchronization with the extension mentioned. Rather it's a restriction that a single buffer cannot be accessed in both read and write mode by the same superioctl command submission. There must be a call to drm_bo_do_validate() in between to switch access mode on the buffer object and emit the MI_FLUSH operation, and that call needs to be made using a new superioctl call. I'm not sure how else you would tell the kernel that we are switching buffer access modes? /Thomas ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
