[mythtv-users] Vaapi use on Sandy Bridge

william otten williammotten at gmail.com
Thu Feb 9 12:12:38 UTC 2012

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 listmythtv-users at mythtv.orghttp://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 listmythtv-users at mythtv.orghttp://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 listmythtv-users at mythtv.orghttp://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 listmythtv-users at mythtv.orghttp://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.





terminal capture

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.mythtv.org/pipermail/mythtv-users/attachments/20120209/54a3087c/attachment.html 

More information about the mythtv-users mailing list