[mythtv-users] Vaapi use on Sandy Bridge
william otten
williammotten at gmail.com
Thu Feb 9 22:13:35 UTC 2012
On Thu, Feb 9, 2012 at 11:25 AM, william otten <williammotten at gmail.com>wrote:
>
>
> On Thu, Feb 9, 2012 at 10:24 AM, Mark Kendall <mark.kendall at gmail.com>wrote:
>
>>
>> On 9 Feb 2012, at 12:12, william otten <williammotten at gmail.com> wrote:
>>
>>
>>
>> On Wed, Feb 8, 2012 at 8:17 AM, William Otten < <williammotten at gmail.com>
>> williammotten at gmail.com> wrote:
>>
>>> On 2/7/2012 5:53 AM, William Otten wrote:
>>>
>>> On 2/6/2012 2:23 PM, William Otten wrote:
>>>
>>> On 2/6/2012 10:56 AM, william otten wrote:
>>>
>>>
>>>
>>> On Sat, Feb 4, 2012 at 8:58 AM, William Otten <<williammotten at gmail.com>
>>> williammotten at gmail.com> wrote:
>>>
>>>> On 2/3/2012 9:59 PM, william otten wrote:
>>>>
>>>>
>>>>
>>>> On Fri, Feb 3, 2012 at 4:01 PM, Matt Garman <<matthew.garman at gmail.com>
>>>> matthew.garman at gmail.com> wrote:
>>>>
>>>>> Hi William,
>>>>>
>>>>> The only way I know to verify the patch is in place (other than by
>>>>> testing in myth using opengl) is to look at the source. Look at that
>>>>> function I mentioned in the earlier post, and see if it includes the
>>>>> additional null pointer check. Or, I suppose if you are already in contact
>>>>> with the xorg devs, just ask them directly.
>>>>>
>>>>> I'm afraid I can't think of any other way to check. Hope that helps!
>>>>> Matt
>>>>> On Feb 3, 2012 6:47 AM, "William Otten" < <williammotten at gmail.com>
>>>>> williammotten at gmail.com> wrote:
>>>>>
>>>>>> On 1/29/2012 7:34 PM, Matt Garman wrote:
>>>>>>
>>>>>>> On Sat, Jan 28, 2012 at 01:55:31PM -0600, william otten wrote:
>>>>>>>
>>>>>>>> The patch is quite simple and involves one function in
>>>>>>>> mesa/drivers/dri/intel/intel_screen.c
>>>>>>>> Another person on this list
>>>>>>>> reported that the patch solved an identical crash for him. Before
>>>>>>>> diving into much debugging, I suggest you apply this patch to the
>>>>>>>> mesa
>>>>>>>> 7.11.2 code, recompile it, and give it a test.
>>>>>>>>
>>>>>>> I may be the "other person" who has been referred to several times
>>>>>>> in this thread, as I did exactly that: I patched the intel_screen.c
>>>>>>> file and rebuilt mesa, and now have a nicely working OpenGL-based
>>>>>>> SNB frontend (which I'm proud to say is also quite small and
>>>>>>> low-power :).
>>>>>>>
>>>>>>> > From my skimming of this thread, it looks like the individual with
>>>>>>> the patching issues is running Ubuntu. I'm running CentOS plus
>>>>>>> ATrpms (for MythTV) and elrepo for newer Intel video drivers and
>>>>>>> supporting packages (in particular, mesa).
>>>>>>>
>>>>>>> What I did was simply download the source RPM for mesa from elrepo,
>>>>>>> manually hack the intel_screen.c file according to the patch, and
>>>>>>> rebuild. I don't know how to do this with Ubuntu/debian packages,
>>>>>>> but I can't imagine the process is dramatically different from an
>>>>>>> RPM-based distro.
>>>>>>>
>>>>>>> FWIW, the patch that has been mentioned doesn't apply cleanly to the
>>>>>>> mesa source from elrepo, because it's a slightly older version:
>>>>>>> looks like the mesa-20111103 snapshot.
>>>>>>>
>>>>>>> But the patch is super simple. Just look for the function
>>>>>>> "intelDRI2Flush()" in the file mentioned above. It should be near
>>>>>>> the top of the file. Just replace that function definition with
>>>>>>> this one:
>>>>>>>
>>>>>>> static void
>>>>>>> intelDRI2Flush(__DRIdrawable *drawable)
>>>>>>> {
>>>>>>> GET_CURRENT_CONTEXT(ctx);
>>>>>>> struct intel_context *intel = intel_context(ctx);
>>>>>>>
>>>>>>> if (intel != NULL) { /* add this... */
>>>>>>> if (intel->gen< 4)
>>>>>>> INTEL_FIREVERTICES(intel);
>>>>>>>
>>>>>>> intel->need_throttle = GL_TRUE;
>>>>>>>
>>>>>>> if (intel->batch.used)
>>>>>>> intel_batchbuffer_flush(intel);
>>>>>>> } /* ...and this */
>>>>>>> }
>>>>>>>
>>>>>>> As I commented above, the patch just adds two lines, which just do a
>>>>>>> NULL pointer safety check.
>>>>>>>
>>>>>>> So, generic instructions would be:
>>>>>>>
>>>>>>> - get your distro's newest mesa source package
>>>>>>> - unpack it (e.g. RPMs are really cpio archives)
>>>>>>> - track down the intel_screen.c file and patch (or manually
>>>>>>> edit) it as described above
>>>>>>> - re-package the mesa source package
>>>>>>> - use your distro's source package build tool to build a binary
>>>>>>> package (e.g. rpmrebuild for RPM-based distros)
>>>>>>>
>>>>>>> Working with your distro's source packages should be well-documented
>>>>>>> (at least for major distros like Ubuntu and Fedora).
>>>>>>>
>>>>>>> The other option is to wait: I also reported my success with this on
>>>>>>> the elrepo mailing list. The elrepo mesa maintainer said he didn't
>>>>>>> want to update the package with a patch that wasn't committed
>>>>>>> (according to this thread, it is now, but wasn't when I made the
>>>>>>> comment). So I would imagine that package maintainers will probably
>>>>>>> be open to incorporating this patch into their builds now that it's
>>>>>>> officially committed... I might request it for elrepo if I get
>>>>>>> around to it.
>>>>>>>
>>>>>>> In other words, with this patch officially committed, it will
>>>>>>> eventually make its way into different distro's mesa builds.
>>>>>>>
>>>>>>> HTH,
>>>>>>> Matt
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> mythtv-users mailing list
>>>>>>> <mythtv-users at mythtv.org>mythtv-users at mythtv.org
>>>>>>> <http://www.mythtv.org/mailman/listinfo/mythtv-users>
>>>>>>> http://www.mythtv.org/mailman/listinfo/mythtv-users
>>>>>>>
>>>>>> Matt
>>>>>> I appreciate your input on this issue. Not being a programmer, I
>>>>>> can't get my brain wrapped around all that needs to be considered or done
>>>>>> to test this patch. With that said, I have setup with xorg-edgers in
>>>>>> anticipation that the patch will work it's way down stream. I contacted one
>>>>>> of the dev's at xorg-edgers and he replied that the patch should be
>>>>>> available within a week or two ( that was about a week ago). I have since
>>>>>> received a couple of updates from them but I'm not sure if the patch was
>>>>>> included. Is there a way to check (other than just trying vaapi with
>>>>>> mythtv) to see if the patch is included or has been received by me?
>>>>>> Thanks
>>>>>> William
>>>>>>
>>>>> I'm a fish out of water here. I tried to find the source on the
>>>> xorg-edgers site for over an hour but no luck. The only thing I found was
>>>> this:
>>>>
>>>> <http://bazaar.launchpad.net/%7Evcs-imports/mesa/master/revision/26908>
>>>> http://bazaar.launchpad.net/~vcs-imports/mesa/master/revision/26908
>>>>
>>>> The other url doesn't work anymore. Also I sent an email to one of the
>>>> dev's.
>>>>
>>>> _______________________________________________
>>>> mythtv-users mailing list <mythtv-users at mythtv.org>mythtv-users at mythtv.org <http://www.mythtv.org/mailman/listinfo/mythtv-users>http://www.mythtv.org/mailman/listinfo/mythtv-users
>>>>
>>>> I tried the opengl option for render and osd render and it works
>>>> with ffmpeg. So the patch must be working. I will try to use debug again
>>>> with vaapi and see if i can get errors to post since the vaapi decoder
>>>> option still isn't working.
>>>>
>>> This the latest debug using the latest master:
>>>
>>> gdb.txt
>>>
>>> <http://dl.dropbox.com/u/17574275/gdb%202-6-12.txt>
>>> http://dl.dropbox.com/u/17574275/gdb%202-6-12.txt
>>>
>>> myth.log
>>>
>>> <http://dl.dropbox.com/u/17574275/myth%202-6-12.log>
>>> http://dl.dropbox.com/u/17574275/myth%202-6-12.log
>>>
>>> terminal capture
>>>
>>> <http://dl.dropbox.com/u/17574275/MythtvBacktrace%202-6-12>
>>> http://dl.dropbox.com/u/17574275/MythtvBacktrace%202-6-12
>>>
>>> I also changed from ubuntu 11.10 to 12.4. A side note, mythtv plays
>>> without tearing using ffmpeg and opengl with unity.
>>>
>>>
>>> _______________________________________________
>>> mythtv-users mailing list <mythtv-users at mythtv.org>mythtv-users at mythtv.org <http://www.mythtv.org/mailman/listinfo/mythtv-users>http://www.mythtv.org/mailman/listinfo/mythtv-users
>>>
>>> This statement keeps repeating in the command line but not showing up
>>> in
>>> gdb.txt or myth.log:
>>> intel_do_flush_locked failed: Input/output error
>>>
>>>
>>> _______________________________________________
>>> mythtv-users mailing list <mythtv-users at mythtv.org>mythtv-users at mythtv.org <http://www.mythtv.org/mailman/listinfo/mythtv-users>http://www.mythtv.org/mailman/listinfo/mythtv-users
>>>
>>> I ran debug on the latest master v0.25pre-4398-g7090d59 and got the
>>> same result:
>>> intel_do_flush_locked failed: Input/output error
>>> The logs look the same so I'm not posting them.
>>>
>>>
>>> _______________________________________________
>>> mythtv-users mailing list <mythtv-users at mythtv.org>mythtv-users at mythtv.org <http://www.mythtv.org/mailman/listinfo/mythtv-users>http://www.mythtv.org/mailman/listinfo/mythtv-users
>>>
>>> I ran debug on the latest master v0.25pre-4422-g334f61f and ubuntu 12.4.
>>> I basically got the same result except when the process was finished
>>> this time, it ended in mythtv and not the desktop but the keyboard seemed
>>> to work one time (ctrl-alt-backspace and then ctrl-alt-F1 to reboot) but
>>> not the last time. The gdb.txt and myth.log didn't show any different info.
>>> I'm allowing the debug to resolve itself the first time and using control-c
>>> the second time.
>>>
>> The latest debug with the latest master with basically the same result:
>> intel_do_flush_locked failed: Input/output error
>> Is there anything else I need to do? Do I keep posting? I haven't had any
>> replies in a while. Is anyone else having the same or related issue? I need
>> some guidance to move forward.
>>
>> gdb,txt
>>
>> <http://dl.dropbox.com/u/17574275/gdb%202-9-12.txt>
>> http://dl.dropbox.com/u/17574275/gdb%202-9-12.txt
>>
>> myth.log
>>
>> <http://dl.dropbox.com/u/17574275/myth%202-9-12.log>
>> http://dl.dropbox.com/u/17574275/myth%202-9-12.log
>>
>> terminal capture
>>
>> <http://dl.dropbox.com/u/17574275/MythtvBacktrace%202-9-12>
>> http://dl.dropbox.com/u/17574275/MythtvBacktrace%202-9-12
>>
>> _______________________________________________
>>
>>
>> William
>>
>> A couple of things:-
>>
>> Can you add -v playback to your log output.
>>
>
> Please be more specific on how I would do this.
>
> Can you check whether you have any deinterlacers selected in your playback
>> profile. If you have, try removing them.
>>
>
> No deinterlacers have been used.
>
>
>> Can you try playing back some h264 and vc1 material. (according to your
>> logs h264 won't work, which is slightly worrying, although it probably
>> isn't relevant here)
>>
>
> Not sure what vc1 is and I think h264 is a mpg4 file?
>
>>
>> And most importantly, you're not actually capturing the backtrace. If
>> you're running directly within gdb, once mythfrontend crashes, you'll need
>> to type in something like 'thread apply all bt' (from memory, the correct
>> command is in the debugging section of the docs).
>>
>
> Here is my gdbcommands file:
>
> handle SIGPIPE nostop noprint
> handle SIG33 nostop noprint
> set logging on
> set pagination off
> set breakpoint pending on
> break qFatal
> set args -l myth.log -v important,general
> run
> thread apply all bt full
> set logging off
>
>
>> Regards
>> Mark
>>
>> _______________________________________________
>> mythtv-users mailing list
>> mythtv-users at mythtv.org
>> http://www.mythtv.org/mailman/listinfo/mythtv-users
>>
>>
> Concerning the backtrace, I stated in the previous posts that I am
> allowing gdb to resolve itself the 1st time then I try using control-c the
> second time. I apply control-c right after I select the enter key to start
> the recording and then I keep pressing control-c many times.
>
I decided to try different recordings / videos due to Mark's comment,
lately I have been using one recording - cnbchd 1080 which never worked. I
liked this for a test due to the scrolling ticker. The results:
TV recordings 720P
I tried several recordings and got mixed results:
1. The recordings didn't work repeatably - If I successfully viewed a
recording the next time I tried after a reboot it may or may not work.
2. The startup for recordings was delayed up to 25 seconds. The usual
routine was for the "Please wait" screen then 2 seconds later there was
audio for a second then after 5 more seconds the screen would turn black
and then the video and audio would start. The total time here was about 7 -
8 seconds. The other extreme was the same up to the black screen but this
would happens after 25 seconds.
3. Exiting a successful recording could result in a freeze. The screen
would have frame of video and the keyboard was non-responsive. I would have
to use a hard reset at this point.
Videos - AVI and MKV
1. MKV videos would not work but the AVI videos did and they could be
re-played again unlike the tv recordings.
2. The AVI videos weren't as good a quality as the tv recordings.
3. The startup was normal for the AVI videos.
4. Exiting a successful video could result in a freeze. The screen would
have frame of video and the keyboard was non-responsive. I would have to
use a hard reset at this point.
Here are the log files. There is something different in the gdb.txt. I
can't state when or why it happened due the numerous attempts.
gdb.txt
http://dl.dropbox.com/u/17574275/gdb%202-9-12%20A.txt
myth.log
http://dl.dropbox.com/u/17574275/myth%202-9-12%20A.log
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.mythtv.org/pipermail/mythtv-users/attachments/20120209/9aec33dd/attachment.html
More information about the mythtv-users
mailing list