| 34,8 → 34,8 |
|---|
| * set of these objects. |
| * |
| * Fences are used to detile GTT memory mappings. They're also connected to the |
| * hardware frontbuffer render tracking and hence interract with frontbuffer |
| * conmpression. Furthermore on older platforms fences are required for tiled |
| * hardware frontbuffer render tracking and hence interact with frontbuffer |
| * compression. Furthermore on older platforms fences are required for tiled |
| * objects used by the display engine. They can also be used by the render |
| * engine - they're required for blitter commands and are optional for render |
| * commands. But on gen4+ both display (with the exception of fbc) and rendering |
| 46,8 → 46,8 |
|---|
| * |
| * Finally note that because fences are such a restricted resource they're |
| * dynamically associated with objects. Furthermore fence state is committed to |
| * the hardware lazily to avoid unecessary stalls on gen2/3. Therefore code must |
| * explictly call i915_gem_object_get_fence() to synchronize fencing status |
| * the hardware lazily to avoid unnecessary stalls on gen2/3. Therefore code must |
| * explicitly call i915_gem_object_get_fence() to synchronize fencing status |
| * for cpu access. Also note that some code wants an unfenced view, for those |
| * cases the fence can be removed forcefully with i915_gem_object_put_fence(). |
| * |
| 527,7 → 527,7 |
|---|
| * required. |
| * |
| * When bit 17 is XORed in, we simply refuse to tile at all. Bit |
| * 17 is not just a page offset, so as we page an objet out and back in, |
| * 17 is not just a page offset, so as we page an object out and back in, |
| * individual pages in it will have different bit 17 addresses, resulting in |
| * each 64 bytes being swapped with its neighbor! |
| * |