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

[Zou, Nanhai]

>>-----Original Message-----
>>From: Simon Farnsworth [mailto:simon.farnsworth at onelan.com]
>>Sent: 2010年5月19日 0:20
>>To: intel-gfx at lists.freedesktop.org
>>Cc: Zou, Nanhai; Daniel Vetter; Anholt, Eric
>>Subject: Re: [Intel-gfx] [PATCH 1/4] introduce intel_ring_buffer structure
>>
>>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.
>>--

Hi,
	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.

Thanks
Zou Nan hai

>>Simon Farnsworth
>>Software Engineer
>>ONELAN Limited
>>http://www.onelan.com/