Dave Airlie wrote: > I'm just wondering if rather than specify all the CACHED and MAPPABLE and > SHAREABLE flags we make the BO interface in terms of CPU and GPU > operations.. > > So we define > CPU_READ - cpu needs to read from this buffer > CPU_WRITE - cpu need to write to the buffer > CPU_POOL - cpu wants to use the buffer for suballocs > > GPU_READ - gpu reads > GPU_WRITE - gpu writes > (GPU_EXEC??) - batchbuffers? (maybe buffers that need relocs.. not sure) > > We can then let the drivers internally decide what types of buffer to use > and not expose the flags mess to userspace. > > Dave. > This might be a good idea for most situations. However, there are situations where the user-space drivers need to provide more info as to what the buffers are used for.
Cache coherent buffers is an excellent way to transfer data from GPU to CPU, but they are usually very slow to render from. How would you tell DRM that you want a cache-coherent buffer for download-from-screen type of operations? Please take a look at i915tex (mesa i915tex_branch) intel_buffer_objects.c, the function intel_bufferobj_select() that translates the GL target + usage hints to a subset of the flags available. My opinion is that we need to be able to keep this functionality. Either we need to push similar usage hints down to drm, or provide an interface that allows the user-space driver to select different memory types and properties. The third option is to make the flags driver-specific and have a translation function in DRM. EXE buffers are intended for batch buffers. DRM needs to know so it can idle those buffers for reuse as early as possible, while the GPU is still working on the textures and destination buffers the EXE buffer referenced. Having said that, some flags are probably unnecessary and can be removed from the user-space interface. Like mappable and force_mappable. But leaving to DRM to decide with a very limited interface will probably end up in bad decisions and low-perfomance drivers. /Thomas ------------------------------------------------------------------------- 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
