Wait on fence before reusing DXVA picture buffer

Wait on fence before reusing DXVA picture buffer

This ensures that the decoder won't write a new frame into the picture buffer before the compositor reads the previous frame.

BUG=585685
Committed: https://crrev.com/27c9c30a074e9cf45babd66c22d336703797edea
Cr-Commit-Position: refs/heads/master@{#378636}

[jbauman, 2016-02-11 21:22:09]

jbauman@chromium.org changed reviewers:
+ ananta@chromium.org

[jbauman, 2016-02-18 22:53:51]

I just checked and this seems to remove some jitteriness that I saw when mousing
over the video timeline slider with Flash video with keyed mutexes disabled.

[jbauman, 2016-02-25 23:22:04]

ananta@: ping

[ananta, 2016-02-26 23:30:13]

On 2016/02/25 23:22:04, jbauman wrote:
> ananta@: ping

Why does the decoder have to do this?. Shouldn't this be handled on the side
which sends in the reuse IPC?

[jbauman, 2016-02-26 23:40:36]

On 2016/02/26 23:30:13, ananta wrote:
> On 2016/02/25 23:22:04, jbauman wrote:
> > ananta@: ping
> 
> Why does the decoder have to do this?. Shouldn't this be handled on the side
> which sends in the reuse IPC?

Well, it depends on the decoder exactly how it synchronizes with the GL context.
For example, waiting for the GPU to finish using the texture isn't necessary
with use_keyed_mutex_ or using_angle_device_, on VideoToolbox on mac, or on
android (I think). Also, this matches other decoders like V4L2 where it is
necessary.

[jbauman, 2016-03-01 22:56:11]

On 2016/02/26 23:40:36, jbauman wrote:
> On 2016/02/26 23:30:13, ananta wrote:
> > On 2016/02/25 23:22:04, jbauman wrote:
> > > ananta@: ping
> > 
> > Why does the decoder have to do this?. Shouldn't this be handled on the side
> > which sends in the reuse IPC?
> 
> Well, it depends on the decoder exactly how it synchronizes with the GL
context.
> For example, waiting for the GPU to finish using the texture isn't necessary
> with use_keyed_mutex_ or using_angle_device_, on VideoToolbox on mac, or on
> android (I think). Also, this matches other decoders like V4L2 where it is
> necessary.

Also, in general we rely on IPC ordering for synchronization. So if the IPC that
causes the GPU to draw from the texture reaches the GPU process before the reuse
IPC does, then it should work.

[ananta, 2016-03-01 23:10:58]

lgtm

[jbauman, 2016-03-01 23:59:49]

The CQ bit was checked by jbauman@chromium.org

[commit-bot: I haz the power, 2016-03-02 00:00:43]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1688993002/20001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1688993002/20001

[commit-bot: I haz the power, 2016-03-02 00:56:13]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2016-03-02 00:58:05]

Description was changed from

==========
Wait on fence before reusing DXVA picture buffer

This ensures that the decoder won't write a new frame into the picture buffer
before the compositor reads the previous frame.

BUG=585685
==========

to

==========
Wait on fence before reusing DXVA picture buffer

This ensures that the decoder won't write a new frame into the picture buffer
before the compositor reads the previous frame.

BUG=585685

Committed: https://crrev.com/27c9c30a074e9cf45babd66c22d336703797edea
Cr-Commit-Position: refs/heads/master@{#378636}
==========

[commit-bot: I haz the power, 2016-03-02 00:58:06]

Patchset 2 (id:??) landed as
https://crrev.com/27c9c30a074e9cf45babd66c22d336703797edea
Cr-Commit-Position: refs/heads/master@{#378636}