Hacks to make HW decode work on linux via libva.

Hacks to make HW decode work on linux via libva.

This still requires telling gyp chromeos=1 but with this (and a couple
of upstream vdpau-driver hacks) both chrome &
video_decode_accelerator_unittest work well on my lucid laptop (NVIDIA
graphics libva wrapping vdpau-driver).

BUG=137247
Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=156677

[Ami GONE FROM CHROMIUM, 2012-09-07 10:04:20]

Not sure if I want to land this, but thought I'd send it out.
Still need to test on lumpy & win to ensure no regressions.

https://chromiumcodereview.appspot.com/10909112/diff/1/content/common/gpu/med...
File content/common/gpu/media/rendering_helper_gl.cc (left):

https://chromiumcodereview.appspot.com/10909112/diff/1/content/common/gpu/med...
content/common/gpu/media/rendering_helper_gl.cc:200: GLX_ALPHA_SIZE, 1,
AFAICT we don't depend on these, and they break on my setup (no fbconfigs are
found).

https://chromiumcodereview.appspot.com/10909112/diff/1/content/common/gpu/med...
File content/common/gpu/media/vaapi_h264_decoder.cc (right):

https://chromiumcodereview.appspot.com/10909112/diff/1/content/common/gpu/med...
content/common/gpu/media/vaapi_h264_decoder.cc:277: XSync(x_display_, False);
Without this, rendering_thread.Stop() in vdatest triggers this:

X Error of failed request:  GLXBadPixmap
  Major opcode of failed request:  135 (GLX)
  Minor opcode of failed request:  23 (X_GLXDestroyPixmap)
  Serial number of failed request:  585
  Current serial number in output stream:  590

on thread shutdown.  I suspect a driver bug, but this method is called
sufficiently infrequently that I can live with this hack.  WDYT?

[Pawel Osciak, 2012-09-07 15:49:12]

https://chromiumcodereview.appspot.com/10909112/diff/1/content/common/gpu/med...
File content/common/gpu/media/rendering_helper_gl.cc (left):

https://chromiumcodereview.appspot.com/10909112/diff/1/content/common/gpu/med...
content/common/gpu/media/rendering_helper_gl.cc:200: GLX_ALPHA_SIZE, 1,
On 2012/09/07 10:04:21, Ami Fischman wrote:
> AFAICT we don't depend on these, and they break on my setup (no fbconfigs are
> found).

The inverted property didn't have any effect for me on CrOS, so probably yes.
The sizes should not be a problem in normal circumstances. Did you try looking
for fbconfigs with just inverted property removed?

https://chromiumcodereview.appspot.com/10909112/diff/1/content/common/gpu/med...
File content/common/gpu/media/vaapi_h264_decoder.cc (right):

https://chromiumcodereview.appspot.com/10909112/diff/1/content/common/gpu/med...
content/common/gpu/media/vaapi_h264_decoder.cc:277: XSync(x_display_, False);
On 2012/09/07 10:04:21, Ami Fischman wrote:
> Without this, rendering_thread.Stop() in vdatest triggers this:
> 
> X Error of failed request:  GLXBadPixmap
>   Major opcode of failed request:  135 (GLX)
>   Minor opcode of failed request:  23 (X_GLXDestroyPixmap)
>   Serial number of failed request:  585
>   Current serial number in output stream:  590
> 
> on thread shutdown.  I suspect a driver bug, but this method is called
> sufficiently infrequently that I can live with this hack.  WDYT?

Could be a driver bug and/or us not being in correct/valid GLX context at the
time of destroying the glx pixmap. Is make_context_current_ above at l.270
working for you?

I agree this XSync would not be a big deal being here only, although I'm more
worried about leaking memory with the above error (unless it's because of
double-freeing, here and somewhere in the driver perhaps).

[Ami GONE FROM CHROMIUM, 2012-09-12 00:53:10]

https://chromiumcodereview.appspot.com/10909112/diff/1/content/common/gpu/med...
File content/common/gpu/media/rendering_helper_gl.cc (left):

https://chromiumcodereview.appspot.com/10909112/diff/1/content/common/gpu/med...
content/common/gpu/media/rendering_helper_gl.cc:200: GLX_ALPHA_SIZE, 1,
On 2012/09/07 15:49:13, posciak wrote:
> On 2012/09/07 10:04:21, Ami Fischman wrote:
> > AFAICT we don't depend on these, and they break on my setup (no fbconfigs
are
> > found).
> 
> The inverted property didn't have any effect for me on CrOS, so probably yes.
> The sizes should not be a problem in normal circumstances. Did you try looking
> for fbconfigs with just inverted property removed?

Yes; no dice.

https://chromiumcodereview.appspot.com/10909112/diff/1/content/common/gpu/med...
File content/common/gpu/media/vaapi_h264_decoder.cc (right):

https://chromiumcodereview.appspot.com/10909112/diff/1/content/common/gpu/med...
content/common/gpu/media/vaapi_h264_decoder.cc:277: XSync(x_display_, False);
On 2012/09/07 15:49:13, posciak wrote:
> On 2012/09/07 10:04:21, Ami Fischman wrote:
> > Without this, rendering_thread.Stop() in vdatest triggers this:
> > 
> > X Error of failed request:  GLXBadPixmap
> >   Major opcode of failed request:  135 (GLX)
> >   Minor opcode of failed request:  23 (X_GLXDestroyPixmap)
> >   Serial number of failed request:  585
> >   Current serial number in output stream:  590
> > 
> > on thread shutdown.  I suspect a driver bug, but this method is called
> > sufficiently infrequently that I can live with this hack.  WDYT?
> 
> Could be a driver bug and/or us not being in correct/valid GLX context at the
> time of destroying the glx pixmap. Is make_context_current_ above at l.270
> working for you?

It must be, or else the failing opcode wouldn't be getting called :)

> I agree this XSync would not be a big deal being here only, although I'm more
> worried about leaking memory with the above error (unless it's because of
> double-freeing, here and somewhere in the driver perhaps).

yes, my suspicion is on the driver.

[Pawel Osciak, 2012-09-13 21:06:20]

lgtm

[commit-bot: I haz the power, 2012-09-13 21:08:11]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/fischman@chromium.org/10909112/4001

[commit-bot: I haz the power, 2012-09-13 23:38:51]

Change committed as 156677