[mythtv-users] Vaapi use on Sandy Bridge
William Otten
williammotten at gmail.com
Sat Feb 4 14:58:38 UTC 2012
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
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.mythtv.org/pipermail/mythtv-users/attachments/20120204/36ee2d98/attachment.html
More information about the mythtv-users
mailing list