[mythtv-users] Vaapi use on Sandy Bridge
william otten
williammotten at gmail.com
Thu Feb 9 17:25:33 UTC 2012
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.mythtv.org/pipermail/mythtv-users/attachments/20120209/b83fbf54/attachment.html
More information about the mythtv-users
mailing list