On Mon, Nov 16, 2020 at 9:55 AM Jonathan Marek <jonathan@xxxxxxxx> wrote: > > On 11/16/20 12:50 PM, Rob Clark wrote: > > On Mon, Nov 16, 2020 at 9:33 AM Christoph Hellwig <hch@xxxxxx> wrote: > >> > >> On Sat, Nov 14, 2020 at 03:07:20PM -0500, Jonathan Marek wrote: > >>> qcom's vulkan driver has nonCoherentAtomSize=1, and it looks like > >>> dma_sync_single_for_cpu() does deal in some way with the partial cache line > >>> case, although I'm not sure that means we can have a nonCoherentAtomSize=1. > >> > >> No, it doesn't. You need to ensure ownership is managed at > >> dma_get_cache_alignment() granularity. > > > > my guess is nonCoherentAtomSize=1 only works in the case of cache > > coherent buffers > > > > nonCoherentAtomSize doesn't apply to coherent memory (as the name > implies), I guess qcom's driver is just wrong about having > nonCoherentAtomSize=1. > > Jordan just mentioned there is at least one conformance test for this, I > wonder if it just doesn't test it well enough, or just doesn't test the > non-coherent memory type? I was *assuming* (but could be wrong) that Jordan was referring to an opencl cts test? At any rate, it is sounding like you should add a `MSM_PARAM_CACHE_ALIGNMENT` type of param that returns dma_get_cache_alignment(), and then properly implement offset/end BR, -R _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
