On Wed, 19 May 2010 10:00:10 +0100, Simon Farnsworth <simon.farnswo...@onelan.com> wrote: > On Wednesday 19 May 2010, "Zou, Nanhai" <nanhai....@intel.com> wrote: > > Currently we do not find any regression or slowness. We have been > > testing > > full HD video test along with regression tests for more than 1 month. The > > only slowness we find now is with playing 2 1080p H.264 video. That was > > caused by too much GPU memory usage which is not related to the interface. > > > And are you utterly confident that if anyone finds a way to use your new > ioctl > to (e.g.) hang the GPU, stall rendering indefinitely waiting for media engine > events that will never happen, or perhaps bypass system security, you can fix > it without changing the ioctl interface to userspace? If not, you have a > problem, and need to redesign the ioctl. > > Bear in mind that I don't have to use VAAPI to call your ioctl; I can write > evil code that calls it directly. On the other hand, you can't remove the > ioctl later - users will want to use older VAAPI versions with new kernels, > so > that they can upgrade without too much fear of regression.
OK, now you're going over the top. The GPU can't schedule[1], is turing complete, and you hand it programs. You can hang it with or without his interface. If you don't want to be able to do that, then don't let non-root use the DRI. Our goal in designing kernel interfaces is to make sure that we get the best behavior we can. After clarifying the cache behavior of the BSD rendering (it all goes into the render cache, so if we're tracking which ring is producing the results, having objects only on one ring, and then tracking them in the one flushing list once they fall off a ring's active list), we can safely handle normal operation with a client dying in the middle. Also, userland is not having to manage caching differently from how userland already does in GEM. That was the part that was unclear before, so I think we're good to go. [1] OK, there's support for scheduling of operations between rings at batch or packet boundaries. Not helping.
pgp2YwuMtfuWo.pgp
Description: PGP signature
_______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
