Keith Packard wrote: >Right now, the GPU access mode on a buffer is stored in the buffer >object itself, which means buffers must always be used in the same way >with the GPU. However, buffers may be read sometimes (textures) and >written others (render to texture). It seems like the GPU access mode of >the buffer should be specified in the operation and left out of the >buffer object itself. > > Keith, As you mention, the intended operation is stored in the buffer flags. Device specific operations are intended to be stored in the device specific part of the 64-bit buffer flag members.
This doesn't really restrict buffer operations in the way you suggest. However, a buffer is restricted to the same operation "mode" between validates. A typical render-to texture operation would look like this, (assuming flags, change_mask validate arguments) // Change only the RW flags, and set them to "Write" validate(bo, DRM_BO_FLAG_WRITE , DRM_BO_FLAG_READ | DRM_BO_FLAG_WRITE) Render to buffer object. // Change only the RW flags, and set them to "READ" validate(bo, DRM_BO_FLAG_READ , DRM_BO_FLAG_READ | DRM_BO_FLAG_WRITE) Use as a texture. Is this sufficient to do what you're after? Some operation modes are perhaps only used to set the correct fence type, and they may not need to be stored with the buffer object itself. This is the case for Intel i9xx hardware and the read-write operations, however other hardware may have read-write protection flags in the page-table entries, and for these type of hardware, the operation mode may become a buffer state. Hence I'm not entirely convinced that the distinction between operation mode and buffer state is clear enough to warrant a big change here? /Thomas > > >------------------------------------------------------------------------ > >------------------------------------------------------------------------- >SF.Net email is sponsored by: >Check out the new SourceForge.net Marketplace. >It's the best place to buy or sell services >for just about anything Open Source. >http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > >------------------------------------------------------------------------ > >-- >_______________________________________________ >Dri-devel mailing list >Dri-devel@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/dri-devel > > ------------------------------------------------------------------------- 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
