[Intel-gfx] [PATCH 1/4] introduce intel_ring_buffer structure

[Eric Anholt]

On Wed, 19 May 2010 10:00:10 +0100, Simon Farnsworth <simon.farnsworth at onelan.com> wrote:
> On Wednesday 19 May 2010, "Zou, Nanhai" <nanhai.zou at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20100519/c67cd01f/attachment.sig>