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. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
