> Dave, I'd like to see the flag DRM_BO_FLAG_CACHED really mean cache-coherent > memory, that is cache coherent also while visible to the GPU. There are HW > implementations out there (Poulsbo at least) where this option actually seems > to work, althought it's considerably slower for things like texturing. It's > also a requirement for user bo's since they will have VMAs that we cant kill > and remap.
Most PCIE cards will be cache coherent, however AGP cards not so much, so need to think if a generic _CACHED makes sense especially for something like radeon, will I have to pass different flags depending on the GART type.... this seems like uggh.. so maybe a separate flag makes more sense.. > > Could we perhaps change the flag DRM_BO_FLAG_READ_CACHED to mean > DRM_BO_FLAG_MAPPED_CACHED to implement the behaviour you describe. This will > also indicate that the buffer cannot be used for user-space sub-allocators, as > we in that case must be able to guarantee that the CPU can access parts of the > buffer while other parts are validated for the GPU. Yes, to be honest sub-allocators for most use-cases should be avoided if possible, we should be able to make the kernel interface fast enough for most things if we don't have to switching caching flags on the fly at map/destroy etc.. > Does this mean that clflush() on one processor flushes the cache line on all > processors in an SMP system? No need for preemption guarding and IPIs? Yes this is specified to do this, tlb flushing would require ipi but we should mostly be able to avoid doing tlb flushes from what I can see, the problem I was seeing on i9xx was the chipset had its own Global Write Buffer which wasn't that well documented.. so stuff could hide in it.. > > So comments please on whether a comeback for linux-agp-compat is a good or > > bad thing.. > > > > > Perhaps an intel-specific TTM backend? Actually I did a backport into a i915_compat.c and it seems like I can make that work, However something in the changes you made in your branch, broke something on me, so I'll have to spend tomorrow rebasing my tree with your patches to see what went wrong, something doesn't appear to be getting flushed at the right time. Dave. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
