On 12/11/2013 12:35 PM, Lauri Kasanen wrote:
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.
Yes, but these are two different things. Letting user-space pin buffers
by design is building in a software DOS in the kernel.
I don't think even Microsoft is allowing this, and AFAICT we've avoided
that since the very dawn of kernel buffer management.
Not having a perfect command stream parser or proper GPU hang recovery
mechanism is something else, and something we wish
to have but don't at the moment.
Allowing a new type of DOS just because we have other flaws isn't moving
things forward, but i guess in the end it's your choice.
Thanks,
Thomas
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
