[Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal
daniel at fooishbar.org
Fri Apr 30 10:17:43 UTC 2021
On Fri, 30 Apr 2021 at 10:35, Daniel Vetter <daniel at ffwll.ch> wrote:
> On Fri, Apr 30, 2021 at 11:08 AM Christian König
> <ckoenig.leichtzumerken at gmail.com> wrote:
> > This doesn't work in hardware. We at least need to setup a few registers
> > and memory locations from inside the VM which userspace shouldn't have
> > access to when we want the end of batch fence and ring buffer start to
> > be reliable.
> The thing is, we don't care whether it's reliable or not. Userspace is
> allowed to lie, not signal, signal the wrong thing, out of order,
> The design assumes all this is possible.
> So unless you can't signal at all from userspace, this works. And for
> the "can't signal at all" it just means something needs to do a cpu
> busy wait and burn down lots of cpu time. I hope that's not your hw
> design :-)
I've been sitting this one out so far because what other-Dan's
proposed seems totally sensible and workable for me, so I'll let him
argue it rather than confuse it.
But - yes. Our threat model does not care about a malicious content
which deliberately submits garbage and then gets the compositor to
display garbage. If that's the attack then you could just emit noise
from your frag shader.
More information about the mesa-dev