[Intel-gfx] [PATCH 1/4] introduce intel_ring_buffer structure
Simon Farnsworth
simon.farnsworth at onelan.com
Tue May 18 18:19:32 CEST 2010
On Tuesday 18 May 2010, "Zou, Nanhai" <nanhai.zou at intel.com> wrote:
> >>-----Original Message-----
> >>From: Daniel Vetter [mailto:daniel at ffwll.ch]
> >>Sent: 2010年5月18日 1:43
> >>Well, that's exactly the problem. You simply can't optimize a kernel
> >>interface once it's in use. And if you try to, your users will get the
> >>pitchforks and scream bloody murder trying to get you ;) So we need to
> >>get these patches right (at least the semantics of the interface)
> >>beforehand.
> >>
> Hi,
> Since VAAPI will be the only client for this multi ring buffer for a period
> of time. We may not have so much pain to optimize both kernel and user
> space. This approach touches little user space interface, only 1 new flag
> is added to IOCTL. We have new kinds of ring buffer to come in
> SandyBridge and later chips. Since we are still enabling SandyBridge. I
> can not for cast how those rings would be synchronized to each other. We
> may use minimum API to work first.
>
Be aware that you cannot expect users to bump both their userspace VAAPI
library and their kernel at the same time; there are good reasons for this.
If you do tie the VAAPI library version and the kernel version too tightly
together, you get into a position where users get upset - if I bump my kernel
from 2.6.32 to 2.6.36 to get support for a new WiFi chipset and a new TV
capture card, I'm likely to get quite upset if I then have to also respin my
userspace.
There are also issues around bisection as a tool for isolating regressions -
if I have to carefully bump userspace and kernel in lock-step, it's very
difficult for me to bisect down until I find the changeset that broke things. As
most of the bugs you'll get reported from users like me won't reproduce in
your lab, making it harder for me to give you helpful information is not in
your interests.
In conclusion, as Daniel's been saying, you must get the kernel interface
mostly right first time. If it's too slow, a new interface to improve
performance isn't hard to add in parallel to the old interface; if the old
interface is a DoS vector or worse, you're going to get stuck in a very bad
place.
--
Simon Farnsworth
Software Engineer
ONELAN Limited
http://www.onelan.com/
More information about the Intel-gfx
mailing list