[mythtv-users] Vaapi use on Sandy Bridge
William Otten
williammotten at gmail.com
Tue Feb 7 11:53:34 UTC 2012
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 <mailto: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 <mailto: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 <mailto: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 <mailto: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
>>> <http://bazaar.launchpad.net/%7Evcs-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 <mailto: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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.mythtv.org/pipermail/mythtv-users/attachments/20120207/e576c310/attachment.html
More information about the mythtv-users
mailing list