Re: [PATCH] drm/i915: Only move to the CPU write domain if keeping the GTT pages

["Goel, Akash" <akash.goel@intel.com>]

On 8/9/2015 6:19 PM, Chris Wilson wrote:
> On Sun, Aug 09, 2015 at 05:11:52PM +0530, Goel, Akash wrote:
>>
>>
>> On 8/9/2015 4:25 PM, Chris Wilson wrote:
>>> On Sun, Aug 09, 2015 at 04:23:01PM +0530, Goel, Akash wrote:
>>>> On 8/7/2015 1:37 PM, Daniel Vetter wrote:
>>>>> I presume though you only want to avoid clflush when actually purging an
>>>>> object, so maybe we can keep this by purging the shmem backing node first
>>>>> and checking here for __I915_MADV_PURGED instead?
>>>>
>>>> An object marked as MADV_DONT_NEED, implies that it will be
>>>> purged/truncated right away after the call to put_pages_gtt
>>>> function.
>>>> So doing the other way round by purging first and then checking for
>>>> __I915_MADV_PURGED, might be equivalent.
>>>
>>> But disregards a few nice sanity checks, which I would like to keep.
>>> -Chris
>> Fine, just wanted to convey that doing the other way round may not
>> be really beneficial.
>>
>> About the other point of virtually indexed/physically tagged cache,
>> would it be safe just rely on the MADV_DONT_NEED state of the object
>> (which indicates that there are no active CPU mmappings) ?
>> Due to an earlier CPU mmappings, there could be cachelines holding
>> the stale data ?
>
> If the conflicts survive munmap(), I don't have a clever idea on how to
> avoid the clflush before we hand back the pages to the system.
One case could be, as you suggested, check if ever there was a CPU 
mapping created for the object & so avoid the clflush for GPU (GPU + 
GTT) only objects.

Best regards
Akash
> -Chris
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx