On 06/03/2014 10:39, Gupta, Sourab wrote:
Hi Daniel,
We had also considered the two points where the stolen mem objs can be truncated -
a) at the point of a new bo allocation, if stolen mem space is exhausted.
b) at the point when the bo is marked as purgeable (madvise ioctl)
We decided upon the second case because:
1) For normal objects, there is a bo cacheing at libdrm level. So even after a bo is marked as purgeable,
it can still get reused by libdrm (if not truncated already), thereby reducing the effort in new object creation.
Currently for stolen objects we have not enabled this cacheing. So once a stolen bo is marked as purgeable by User,
Driver can immediately reclaim the stolen space and there will be no obvious benefit in deferring the object truncation to
a later stage (when there is a failure in allocation of a new bo).
Actually we thought that since Stolen mem is a relatively much smaller space and has a limited usage,
there may not be any additional benefit gained by enabling bo cacheing on libdrm side.
Also the effort in getting the backing space from stolen mem shall be much less than from shmem.
With the first approach, it would have required us to scan the entire list of bound & unbound objects to search for the
purgeable stolen objects and purge them. With the 2nd approach, we could avoid this & purge the objects we already have
in our hand.
Well, approach b) breaks the libdrm cache, since libdrm sets the madvise
flag to purgeable when insert an unused object into it's cache. So you
really can't truncate the object right away, since that completely
defeats the point of the cache.
-Daniel
Intel Semiconductor AG
Registered No. 020.30.913.786-7
Registered Office: World Trade Center, Leutschenbachstrasse 95, 8050 Zurich, Switzerland
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
