[mythtv-users] Vaapi use on Sandy Bridge

[william otten]

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<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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.mythtv.org/pipermail/mythtv-users/attachments/20120203/1d504fb1/attachment.html