[mythtv-users] Vaapi use on Sandy Bridge
Mark Kendall
mark.kendall at gmail.com
Thu Feb 9 16:24:03 UTC 2012
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> 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> 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> 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> 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
>>>>> 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/~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
>>>>> 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
>>>>
>>>> myth.log
>>>>
>>>> http://dl.dropbox.com/u/17574275/myth%202-6-12.log
>>>>
>>>> terminal capture
>>>>
>>>> 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
>>>> 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
>>> 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
>> 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
>
> myth.log
>
> http://dl.dropbox.com/u/17574275/myth%202-9-12.log
>
> terminal capture
>
> http://dl.dropbox.com/u/17574275/MythtvBacktrace%202-9-12
> _______________________________________________
>
William
A couple of things:-
Can you add -v playback to your log output.
Can you check whether you have any deinterlacers selected in your playback profile. If you have, try removing them.
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)
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).
Regards
Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.mythtv.org/pipermail/mythtv-users/attachments/20120209/964656b7/attachment-0001.html
More information about the mythtv-users
mailing list