TTMBoF
Discussion list for TTM BoF at XDS 2007.
Please just add your name and a list of things you would like to raise...
removal of any unused interfaces to avoid long term support in upstream kernels
Mandatory super ioctl in the driver.
Relocation types.
fake buffer type (do we need to pass in the type at all, really userspace dc or user can be worked out from the pointer - krh) - agreed to remove this from interface.
- JeromeGlisse: There was a discussion on irc about handling of cliprect i am not sure this truely fit this topic and likely could be worked before TTM. The things is that if we want multiple consumer of DRM (could be two X server running at the same time using the same hw but each one having its head or one visible while the other in background, whatever) for that i think it would be better to move all sarea and other DRI initialization bit out from DDX to libdrm for instance, also providing API to handle cliprect in libdrm (this was proposed by KristianHøgsberg). So libdrm handle remaining initialization of DRI that were done in DDX. In such scheme we might need to have some notion of master/slave or parent/child in libdrm so parent|master own the framebuffer and authorize who can have a dri context for this framebuffer|scanoutbuffer and also is the only one who can update cliprect of its child|slave. This is just my feeling and wish (i tend to always ask too much to Santa :-)) and i could also be totaly wrong about all this as i never truely looked deep into this part of the code )
- KristianHøgsberg: I'm no longer convinced that we need to push this into libdrm and the kernel modules. Optimizing the way the server communicates cliprects will probably go a long way. I've been working on a system BO based 'journal' idea, where the xserver writes changes to cliprects, window positions and drm_drawable_t -> ancillary buffer objects mappings. DRI clients read from this journal and keep their own tail pointer. This way,clients can quickly see if they're behind, and can catch up without doing protocol do the server (ie while holding the lock).
- KeithWhitwell: Cliprects are just evil anyway. Switching to a private-backbuffer arrangement leads to drivers which are vastly easier to understand and deal with, and then you only have to examine cliprects once per frame which is not a significant cost with the existing DRI facilities. In any case they certainly have nothing to do with the buffer manager - if you care about cliprects it is because of choices you have made in the window-system integration layer, in my opinion the buffer manager shouldn't care about this at all.
- JesseBarnes:
- per-process GTT entries
- page fault support I can look into what Intel hardware supports in this regard; hopefully we can fit this stuff into the current design without too much trouble.
KeithWhitwell:
- Relocations are great, but sometimes you really need to know where a buffer is going to be.
* Software zone/tiled rendering - can generate 10,000's of relocations. The CPU overhead of this would otherwise defeat the technique.
* Reusing buffers containing relocations over multiple scenes -- eg. caching generated programs/state which themselves contain relocations.
* Approaches for dealing with this -- 'prevalidation', investigating NO_MOVE buffers.
- Differences between NO_MOVE and NO_EVICT. Both are important but for different reasons.
- Private backbuffers --> We need to be able to allocate tiled buffers on Intel IGPs.
Private backbuffers and pageflipping. How will this work?
KristianHøgsberg:
- Can we drop drmBODestroy and only use drmBOUnreference? Sometimes the X server creates a BO and the DRI driver running in a DRI client may end up being the last user. The X server can't just call drmBODestroy, since others may be using it, at the same time, the DRI client can't destroy it because it didn't create it.
- We need to talk about how the private back buffer work overlaps with redirected direct rendering.
