On Wed, 11 Dec 2013 12:04:05 +0900 Michel Dänzer <michel@xxxxxxxxxxx> wrote: > > 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. We don't have that in the kernel. Only userspace has the accurate stats on usage. If we instead modified userspace to pass these stats, it would have the exact same issue of "what if somebody passes false data"? Maarten: > 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. No, this would be the exact opposite: it would pin the old-userspace buffers, at the cost of possibly not letting proper-scored buffers in VRAM. Thomas: > 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. I think the kernel just has to trust userspace on this. I can't think of any way of not involving userspace, so if somebody really wants to hack mesa to gain some fps advantage on a multiseat system, let them ;) Basically, they already can hack mesa to pass invalid buffers to cause a hang/crash the kernel. So we already trust userspace more than this new functionality would. > 2) If score is calculated in user-space, how are shared buffers handled? Good question, I don't know yet. - Lauri _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
