[Intel-gfx] [PATCH] [RFC] LLC and per-BO cache handling

[Eugeni Dodonov]

With base on comments and feedback on LLC handling from Daniel Vetter, Chris
Wilson and Ben Widawsky, I reworked my patch into a more useful approach for
detecting presence of different cache levels from userspace.

So, in this context, PATCH 1 adds the very same .has_llc flag and debugfs
entry for it. PATCH 2 does the initial job of preparing to export cache
levels to userspace, which can be queried via the DRM interface by means of
PATCH 3. And finally, PATCH 4 allows to get and set a specific cache level for each
bo.

The i915_gem_object_set_cache_level() routine does a good job of checking
whether the objects should be put into specific cache levels already. When
thinking about possible optimizations and tweaks for different cache levels,
this is what we thought:
 - The most usual case is for I915_MADV_WILLNEED object, where we can change
   its cache level as we want.
 - If we are trying to change cache level of I915_MADV_DONTNEED object, on
   first glance, it is pointless to do so. However, it could make sense for
   some sort of prefetching or quick change of mind (we certainly can mark
   an object as DONTNEED and get to reallocate and WILLNEED it again). So
   why not?
 - If we are trying to change cache level of a PURGED object, nothing will
   happen, as it has no GTT space anyway.

One possible optimization would be to remove an object from LLC on
gem_madvise_ioctl(..I915_MADV_DONTNEED). However, I don't think it is worth
the extra cycles - at some point, it will be removed eventually anyway, even
if we leave it at LLC.

So those are all the possible cases I could think of. Of course, I could
have missed something, so just yell if so :).