Dave Airlie wrote: >> Dave, >> As mentioned previously to Eric, I think we should keep the single >> buffer validate interface with the exception that the hint >> DRM_BO_HINT_DONT_FENCE is implied, and use that instead of the set pin >> interface. We can perhaps rename it to drmBOSetStatus or something more >> suitable. >> >> This will get rid of the user-space unfenced list access (which I >> believe was the main motivation behind the set pin interface?) while >> keeping the currently heavily used (at least in Poulsbo) functionality >> to move out NO_EVICT scanout buffers to local memory before unpinning >> them, (to avoid VRAM and TT fragmentation, as DRI clients may still >> reference those buffers, so they won't get destroyed before a new one is >> allocated). >> >> It would also allow us to specify where we want to pin buffers. If we >> remove the memory flag specification from drmBOCreate there's no other >> way to do that, except running the buffer through a superioctl which >> isn't very nice. >> >> Also it would make it much easier to unbreak i915 zone rendering and >> derived work. >> >> If we can agree on this, I'll come up with a patch. > > I'm quite happy to have this type of interface I can definitely see its > uses.. we also need to investigate some sort of temporary NO_MOVE like > interface (the NO_MOVE until next fencing...) in order to avoid > relocations, but it might be possible to make this driver specific.. > > Keith P also had an idea for relocation avoidance in the simple case which > I've allowed for in my interface, we could use the 4th uint32_t in the > relocation to pass in the value we've already written and only relocate it > if the buffers location changes, so after doing one superioctl, the > validated offsets would be passed back to userspace and used by it and we > only have to relocate future buffers if the buffers move..
Theoretically the kernel could keep the relocation lists for each buffer hanging around after use and do this automatically if a buffer is reused, and the buffers that its relocations point to have been moved. That would be a good approach for one sort of buffer reuse, ie persistent state object buffers that are reused over multiple frames but contain references to other buffers. Note that it only makes sense to reuse relocations in situations where those relocations target a small number of buffers - probably other command buffers or buffers containing state objects which themselves make no further reference to other buffers. Trying to go beyond that, eg to reuse buffers of state objects that contain references to texture images, can lead to a major waste of resources. If you think about a situation with a buffer of 50 texture state objects, each referencing 4 texture images, and you just want to reuse one of those state objects -- you will emit a relocation to that state buffer, which will need to be validated and then should recursively require all 200 texture images to be validated, even if you only needed access to 4 of them... The pre-validate/no-move/whatever thing is a useful optimization, but it only makes sense up to a certain level - a handful of command, indirect state and/or vertex buffers is pretty much it. Keith ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
