It's a noop on DG1, and in the future when need to support other devices which let us control the coherency, then it should be an immutable creation time property for the BO. This will likely be controlled through a new gem_create_ext extension. v2: add some kernel doc for the discrete changes, and document the implicit rules
Showing the changes to include/uapi (1 of 2 files). Show all
Unified · Split
| @@ -1395,6 +1395,35 @@ struct drm_i915_gem_busy { · 1394 unmodified lines | ||
| 1395 | 1395 | * ppGTT support, or if the object is used for scanout). Note that this might |
| 1396 | 1396 | * require unbinding the object from the GTT first, if its current caching value |
| 1397 | 1397 | * doesn't match. |
| 1398 | + * | |
| 1399 | + * Note that this all changes on discrete platforms, starting from DG1, the | |
| 1400 | + * set/get caching is no longer supported, and is now rejected. Instead the CPU | |
| 1401 | + * caching attributes(WB vs WC) will become an immutable creation time property | |
| 1402 | + * for the object, along with the GTT caching level. For now we don't expose any | |
| 1403 | + * new uAPI for this, instead on DG1 this is all implicit, although this largely | |
| 1404 | + * shouldn't matter since DG1 is coherent by default(without any way of | |
| 1405 | + * controlling it). | |
| 1406 | + * | |
| 1407 | + * Implicit caching rules, starting from DG1: | |
| 1408 | + * | |
| 1409 | + * - If any of the object placements (see &drm_i915_gem_create_ext_memory_regions) | |
| 1410 | + * contain I915_MEMORY_CLASS_DEVICE then the object will be allocated and | |
| 1411 | + * mapped as write-combined only. | |
| 1412 | + * | |
| 1413 | + * - Everything else is always allocated and mapped as write-back, with the | |
| 1414 | + * guarantee that everything is also coherent with the GPU. | |
| 1415 | + * | |
| 1416 | + * Note that this is likely to change in the future again, where we might need | |
| 1417 | + * more flexibility on future devices, so making this all explicit as part of a | |
| 1418 | + * new &drm_i915_gem_create_ext extension is probable. | |
| 1419 | + * | |
| 1420 | + * Side note: Part of the reason for this is that changing the at-allocation-time CPU | |
| 1421 | + * caching attributes for the pages might be required(and is expensive) if we | |
| 1422 | + * need to then CPU map the pages later with different caching attributes. This | |
| 1423 | + * inconsistent caching behaviour, while supported on x86, is not universally | |
| 1424 | + * supported on other architectures. So for simplicity we opt for setting | |
| 1425 | + * everything at creation time, whilst also making it immutable, on discrete | |
| 1426 | + * platforms. | |
| 1398 | 1427 | */ |
| 1399 | 1428 | struct drm_i915_gem_caching { |
| 1400 | 1429 | /** |