On 12/11/2013 08:57 AM, Maarten Lankhorst wrote:
op 11-12-13 04:04, Michel Dänzer schreef:
On Die, 2013-12-10 at 12:03 +0100, Maarten Lankhorst wrote:
op 10-12-13 01:49, Michel Dänzer schreef:
On Mon, 2013-12-09 at 23:45 +0100, Marek Olšák wrote:
On Mon, Dec 9, 2013 at 9:30 PM, Lauri Kasanen <cand@xxxxxxx> wrote:
Note that the hotness calculation will be in userspace, as only there
are the necessary counters available. So the finished hotness score
will be passed to the kernel, instead of sending all the necessary data
there. Ought to be less context switches that way.
Sounds like this could be abused by userspace though...
Of all the worries that exist, this is a non-issue. Userspace can
simply queue a lot of draw calls that take 1 second each through the
normal command submission methods, why would it need to tweak some
obscure number to cause some eviction?
That's not what I'm concerned about.
Consider e.g. a multiseat environment: Some users could patch their
userspace drivers such that their buffers are more likely to stay in
VRAM than those of other users.
I agree it's not a huge issue, I'm just saying we should try to make the
score calculation as much as possible based on the actual usage of the
buffers instead of on meta data provided by userspace.
Well, the easiest solution is to make the score only count as penalty, and set buffers
that don't have the meta-data to maximum score. This preserves current behavior for
clients that aren't score aware.
I agree with Michel that some mechanism needs to be in place to stop
user-space clients from effectively
pinning buffers by giving them a certain score. Two other things:
1) A good memory manager should be able to guarantee a certain amount of
GPU visible memory to be available, so that user-space knows when to flush.
for an execbuf call (albeit not necessarily VRAM), if, due to
fragmentation or something else, this is hard to achieve during normal
(score based or LRU) eviction mechanism, a typical implementation would
lock out other execbuf processes, release all reservations, evict what's
necessary and restart execbuf. In this "panic" case, I think the
score-based eviction needs to be relaxed to allow new buffers in
regardless of score.
2) If score is calculated in user-space, how are shared buffers handled?
Thanks,
Thomas
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
