Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
2938543005:
media: Add GLES2DecoderHelper (Closed)
|
Created:
3 years, 6 months ago by sandersd (OOO until July 31) Modified:
3 years, 5 months ago CC:
chromium-reviews, posciak+watch_chromium.org, piman+watch_chromium.org, feature-media-reviews_chromium.org, Geoff Lang Target Ref:
refs/heads/master Project:
chromium Visibility:
Public. |
Descriptionmedia: Add GLES2DecoderHelper
This class wraps a gpu::gles2::GLES2Decoder* to provide utility
functions for VDAs.
BUG=522298
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Review-Url: https://codereview.chromium.org/2938543005
Cr-Commit-Position: refs/heads/master@{#485091}
Committed: https://chromium.googlesource.com/chromium/src/+/0ea82f3864289d9103d288edc822f264e62ca9a4
Patch Set 1 #
Total comments: 6
Patch Set 2 : Mark SyncTokens as verified. #Patch Set 3 : Nits. #
Total comments: 2
Patch Set 4 : Use GLES2Decoder directly. #Patch Set 5 : decoder -> decoder_ #
Total comments: 4
Patch Set 6 : Remove unneeded #includes. #
Total comments: 9
Patch Set 7 : DCHECK that the context is current. #Patch Set 8 : Don't check for guaranteed non-nulls. #
Messages
Total messages: 39 (15 generated)
Description was changed from ========== media: Add CommandBufferHelper. This class wraps a gpu::GpuCommandBuffer and provides utility functions for VDAs. BUG=522298 ========== to ========== media: Add CommandBufferHelper. This class wraps a gpu::GpuCommandBuffer and provides utility functions for VDAs. BUG=522298 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel ==========
sandersd@chromium.org changed reviewers: + watk@chromium.org
Patchset #1 (id:1) has been deleted
Patchset #1 (id:20001) has been deleted
Description was changed from ========== media: Add CommandBufferHelper. This class wraps a gpu::GpuCommandBuffer and provides utility functions for VDAs. BUG=522298 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel ========== to ========== media: Add CommandBufferHelper. This class wraps a gpu::GpuCommandBufferStub to provide utility functions for VDAs. BUG=522298 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel ==========
posciak@chromium.org changed reviewers: + posciak@chromium.org
Is this intended to be used by all VDAs? Thanks!
On 2017/06/13 23:36:35, Pawel Osciak wrote: > Is this intended to be used by all VDAs? Thanks! No, just by VdaVideoDecoder and MediaCodecVideoDecoder. VdaVideoDecoder (which wraps VDAs for use by MojoVideoDecoder) will use this to implement the current VDA interface, and in the future to implement the new VDA interfaces we designed as well. But the actual VDA implementations won't see it. This does provide a solid foundation for the work we outlined in December. I am working on that design doc now, you can expect it sometime this week.
https://codereview.chromium.org/2938543005/diff/40001/media/gpu/command_buffe... File media/gpu/command_buffer_helper.cc (right): https://codereview.chromium.org/2938543005/diff/40001/media/gpu/command_buffe... media/gpu/command_buffer_helper.cc:133: stub_->stream_id(), stub_->command_buffer_id(), 0); Are you intending this TODO to be of the kind "lets leave this and if something breaks we'll come back to it", or "I'll actively address this soon". I feel like we should make it the latter. Because the failure modes might be subtle. https://codereview.chromium.org/2938543005/diff/40001/media/gpu/command_buffe... media/gpu/command_buffer_helper.cc:162: gpu::GpuCommandBufferStub* stub_ = nullptr; Unconventional to have an initializer here and in the constructor. https://codereview.chromium.org/2938543005/diff/40001/media/gpu/command_buffe... File media/gpu/command_buffer_helper.h (right): https://codereview.chromium.org/2938543005/diff/40001/media/gpu/command_buffe... media/gpu/command_buffer_helper.h:57: // Creates a malbox for a texture. mailbox
https://codereview.chromium.org/2938543005/diff/40001/media/gpu/command_buffe... File media/gpu/command_buffer_helper.cc (right): https://codereview.chromium.org/2938543005/diff/40001/media/gpu/command_buffe... media/gpu/command_buffer_helper.cc:133: stub_->stream_id(), stub_->command_buffer_id(), 0); On 2017/06/14 00:01:38, watk wrote: > Are you intending this TODO to be of the kind "lets leave this and if something > breaks we'll come back to it", or "I'll actively address this soon". I feel like > we should make it the latter. Because the failure modes might be subtle. This is in the category of 'I don't understand this enough to write correct code, I need help with this CL'.
https://codereview.chromium.org/2938543005/diff/40001/media/gpu/command_buffe... File media/gpu/command_buffer_helper.cc (right): https://codereview.chromium.org/2938543005/diff/40001/media/gpu/command_buffe... media/gpu/command_buffer_helper.cc:162: gpu::GpuCommandBufferStub* stub_ = nullptr; On 2017/06/14 00:01:38, watk wrote: > Unconventional to have an initializer here and in the constructor. Done. https://codereview.chromium.org/2938543005/diff/40001/media/gpu/command_buffe... File media/gpu/command_buffer_helper.h (right): https://codereview.chromium.org/2938543005/diff/40001/media/gpu/command_buffe... media/gpu/command_buffer_helper.h:57: // Creates a malbox for a texture. On 2017/06/14 00:01:38, watk wrote: > mailbox Done.
lgtm lgtm
sandersd@chromium.org changed reviewers: + sunnyps@chromium.org
sunnyps@: Please review command buffer usage.
I'm a bit worried about creating TextureRefs outside of TextureManager and without client-side ids because we don't do that anywhere else. There may also be weird interactions with ServiceDiscardableManager which uses client-side ids for tracking. Can you describe how the new VDA will use this helper? Will it be necessary to synchronize with other command buffers e.g. reuse a texture after it's drawn by compositor? Will the VDA/media context be used on the client? If not, have you considered using an InProcessCommandBuffer in the VDA service? https://codereview.chromium.org/2938543005/diff/80001/media/gpu/command_buffe... File media/gpu/command_buffer_helper.cc (right): https://codereview.chromium.org/2938543005/diff/80001/media/gpu/command_buffe... media/gpu/command_buffer_helper.cc:23: explicit CommandBufferHelperImpl(gpu::GpuCommandBufferStub* stub) nit: Make the helper take a decoder instead of the stub. This will help in porting to other command buffers too. Instead of being the stub's destruction observer, the helper should have a Destroy method and the helper's client should handle the stub specific logic.
sunnyps@chromium.org changed reviewers: + ericrk@chromium.org
+ericrk for ServiceDiscardableManager questions
> I'm a bit worried about creating TextureRefs outside of TextureManager and > without client-side ids because we don't do that anywhere else. Note that this implementation is actually a clone of that in BackTexture, which is used by by not exposed from GLES2DecoderImpl: https://chromium.googlesource.com/chromium/src/+/93ace63c2d974e16c2f79500d709... > There may also be weird interactions with ServiceDiscardableManager which uses > client-side ids for tracking. Interesting. I don't think this should be important, because VDA textures are never discardable, but I don't fully understand the mechanism either. If it's the renderer that opts in, it can do so after opening the mailbox. > Can you describe how the new VDA will use this helper? Will it be necessary to > synchronize with other command buffers e.g. reuse a texture after it's drawn by > compositor? Will the VDA/media context be used on the client? If not, have you > considered using an InProcessCommandBuffer in the VDA service? VDAs are initialized with an UnguessableToken that identifies the associated renderer's media command buffer, which they look up via the MediaGpuService. We will need to synchronize with the compositor before reusing textures. Currently the only VDA implementation using this path does not rely on this synchronization, it creates a new texture for each frame and only uses the reuse path to drop its TextureRefs. We already wait for the compositor sync point as part of hopping to the media thread in the renderer, so I expect the implementation to just be verifying the release. I have not determined exactly what will be required if for some reason we actually need to wait for the sync point. (It does look like there is a sync point callback mechanism we can use though.) An InProcessCommandBuffer would be a reasonable solution, but it has a complexity cost and (as I understand it) a non-trivial memory cost. We would have to more significantly change the VDA model and answer more difficult lifetime questions. I would rather avoid that for now if possible. https://codereview.chromium.org/2938543005/diff/80001/media/gpu/command_buffe... File media/gpu/command_buffer_helper.cc (right): https://codereview.chromium.org/2938543005/diff/80001/media/gpu/command_buffe... media/gpu/command_buffer_helper.cc:23: explicit CommandBufferHelperImpl(gpu::GpuCommandBufferStub* stub) On 2017/06/23 00:57:59, sunnyps wrote: > nit: Make the helper take a decoder instead of the stub. This will help in > porting to other command buffers too. Instead of being the stub's destruction > observer, the helper should have a Destroy method and the helper's client should > handle the stub specific logic. I'm not sure about this, because it means that CreateSyncToken() can't be here (at least not with its current implementation). Possibly this means that CreateSyncToken() should be in a separate class. I'll add a TODO to explain why that would be useful.
On 2017/06/26 21:00:28, sandersd wrote: > > I'm a bit worried about creating TextureRefs outside of TextureManager and > > without client-side ids because we don't do that anywhere else. > > Note that this implementation is actually a clone of that in BackTexture, which > is used by by not exposed from GLES2DecoderImpl: > https://chromium.googlesource.com/chromium/src/+/93ace63c2d974e16c2f79500d709... > > > There may also be weird interactions with ServiceDiscardableManager which uses > > client-side ids for tracking. > > Interesting. I don't think this should be important, because VDA textures are > never discardable, but I don't fully understand the mechanism either. If it's > the renderer that opts in, it can do so after opening the mailbox. I think we're OK here (I wrote the ServiceDiscardableManager code :D) - it's purely opt-in, and the opt-in is done via the "glInitializeDiscardableTextureCHROMIUM" call, which takes a client ID. So, as is described, it should be impossible to add these textures to the discardable manager without first sending them via mailbox to a new client (which will generate the client ID). At that point, they can be used normally with discardable manager. > > > Can you describe how the new VDA will use this helper? Will it be necessary to > > synchronize with other command buffers e.g. reuse a texture after it's drawn > by > > compositor? Will the VDA/media context be used on the client? If not, have you > > considered using an InProcessCommandBuffer in the VDA service? > > VDAs are initialized with an UnguessableToken that identifies the associated > renderer's media command buffer, which they look up via the MediaGpuService. > > We will need to synchronize with the compositor before reusing textures. > Currently the only VDA implementation using this path does not rely on this > synchronization, it creates a new texture for each frame and only uses the reuse > path to drop its TextureRefs. > > We already wait for the compositor sync point as part of hopping to the media > thread in the renderer, so I expect the implementation to just be verifying the > release. I have not determined exactly what will be required if for some reason > we actually need to wait for the sync point. (It does look like there is a sync > point callback mechanism we can use though.) > > An InProcessCommandBuffer would be a reasonable solution, but it has a > complexity cost and (as I understand it) a non-trivial memory cost. We would > have to more significantly change the VDA model and answer more difficult > lifetime questions. I would rather avoid that for now if possible. > > https://codereview.chromium.org/2938543005/diff/80001/media/gpu/command_buffe... > File media/gpu/command_buffer_helper.cc (right): > > https://codereview.chromium.org/2938543005/diff/80001/media/gpu/command_buffe... > media/gpu/command_buffer_helper.cc:23: explicit > CommandBufferHelperImpl(gpu::GpuCommandBufferStub* stub) > On 2017/06/23 00:57:59, sunnyps wrote: > > nit: Make the helper take a decoder instead of the stub. This will help in > > porting to other command buffers too. Instead of being the stub's destruction > > observer, the helper should have a Destroy method and the helper's client > should > > handle the stub specific logic. > > I'm not sure about this, because it means that CreateSyncToken() can't be here > (at least not with its current implementation). > > Possibly this means that CreateSyncToken() should be in a separate class. I'll > add a TODO to explain why that would be useful.
On 2017/06/26 21:00:28, sandersd wrote: > > I'm a bit worried about creating TextureRefs outside of TextureManager and > > without client-side ids because we don't do that anywhere else. > > Note that this implementation is actually a clone of that in BackTexture, which > is used by by not exposed from GLES2DecoderImpl: > https://chromium.googlesource.com/chromium/src/+/93ace63c2d974e16c2f79500d709... Ok. > > > There may also be weird interactions with ServiceDiscardableManager which uses > > client-side ids for tracking. > > Interesting. I don't think this should be important, because VDA textures are > never discardable, but I don't fully understand the mechanism either. If it's > the renderer that opts in, it can do so after opening the mailbox. > > > Can you describe how the new VDA will use this helper? Will it be necessary to > > synchronize with other command buffers e.g. reuse a texture after it's drawn > by > > compositor? Will the VDA/media context be used on the client? If not, have you > > considered using an InProcessCommandBuffer in the VDA service? > > VDAs are initialized with an UnguessableToken that identifies the associated > renderer's media command buffer, which they look up via the MediaGpuService. > > We will need to synchronize with the compositor before reusing textures. > Currently the only VDA implementation using this path does not rely on this > synchronization, it creates a new texture for each frame and only uses the reuse > path to drop its TextureRefs. Right, but we still have to wait for the sync token before dropping the TextureRef. > > We already wait for the compositor sync point as part of hopping to the media > thread in the renderer, so I expect the implementation to just be verifying the > release. I have not determined exactly what will be required if for some reason > we actually need to wait for the sync point. (It does look like there is a sync > point callback mechanism we can use though.) I don't think we wait for the compositor sync token in the renderer today. That sync token is passed via callbacks and then a wait is inserted into the command buffer before reusing/destroying the corresponding resource. Are you referring to the SignalSyncToken IPC? That will run a callback on the client when the fence is released on the service. After that you'll be able to make your mojo call to reuse/destroy the texture. > > An InProcessCommandBuffer would be a reasonable solution, but it has a > complexity cost and (as I understand it) a non-trivial memory cost. We would > have to more significantly change the VDA model and answer more difficult > lifetime questions. I would rather avoid that for now if possible. > > https://codereview.chromium.org/2938543005/diff/80001/media/gpu/command_buffe... > File media/gpu/command_buffer_helper.cc (right): > > https://codereview.chromium.org/2938543005/diff/80001/media/gpu/command_buffe... > media/gpu/command_buffer_helper.cc:23: explicit > CommandBufferHelperImpl(gpu::GpuCommandBufferStub* stub) > On 2017/06/23 00:57:59, sunnyps wrote: > > nit: Make the helper take a decoder instead of the stub. This will help in > > porting to other command buffers too. Instead of being the stub's destruction > > observer, the helper should have a Destroy method and the helper's client > should > > handle the stub specific logic. > > I'm not sure about this, because it means that CreateSyncToken() can't be here > (at least not with its current implementation). > > Possibly this means that CreateSyncToken() should be in a separate class. I'll > add a TODO to explain why that would be useful.
> I don't think we wait for the compositor sync token in the renderer today. That > sync token is passed via callbacks and then a wait is inserted into the command > buffer before reusing/destroying the corresponding resource. Upon re-reading the code, you are correct. My assertion was accurate when I was still planning to pass the reuse call via the command buffer, but now that it's just mojo that's not correct. > Are you referring to the SignalSyncToken IPC? That will run a callback on the > client when the fence is released on the service. After that you'll be able to > make your mojo call to reuse/destroy the texture. I was imagining using SyncPointManager::Wait() (or one of the related functions) directly.
Description was changed from ========== media: Add CommandBufferHelper. This class wraps a gpu::GpuCommandBufferStub to provide utility functions for VDAs. BUG=522298 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel ========== to ========== media: Add GLES2DecoderHelper This class wraps a gpu::gles2::GLES2Decoder* to provide utility functions for VDAs. BUG=522298 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel ==========
Patchset #4 (id:100001) has been deleted
Now that SyncTokens are not being generated, I have changed the implementation to use a GLES2Decoder directly, rather than a CommandBufferStub. PTAL.
lgtm https://codereview.chromium.org/2938543005/diff/140001/media/gpu/gles2_decode... File media/gpu/gles2_decoder_helper.cc (right): https://codereview.chromium.org/2938543005/diff/140001/media/gpu/gles2_decode... media/gpu/gles2_decoder_helper.cc:11: #include "gpu/command_buffer/common/sync_token.h" potentially unneeded now https://codereview.chromium.org/2938543005/diff/140001/media/gpu/gles2_decode... media/gpu/gles2_decoder_helper.cc:15: #include "gpu/ipc/service/gpu_command_buffer_stub.h" potentially unneeded
https://codereview.chromium.org/2938543005/diff/140001/media/gpu/gles2_decode... File media/gpu/gles2_decoder_helper.cc (right): https://codereview.chromium.org/2938543005/diff/140001/media/gpu/gles2_decode... media/gpu/gles2_decoder_helper.cc:11: #include "gpu/command_buffer/common/sync_token.h" On 2017/06/29 18:39:07, watk wrote: > potentially unneeded now Done. https://codereview.chromium.org/2938543005/diff/140001/media/gpu/gles2_decode... media/gpu/gles2_decoder_helper.cc:15: #include "gpu/ipc/service/gpu_command_buffer_stub.h" On 2017/06/29 18:39:07, watk wrote: > potentially unneeded Done.
sunnyps@chromium.org changed reviewers: + piman@chromium.org
lgtm % nit I'll defer to piman@ for high level design, in particular, if this should live in gpu/command_buffer/service and exposed only via an interface. https://codereview.chromium.org/2938543005/diff/160001/media/gpu/gles2_decode... File media/gpu/gles2_decoder_helper.cc (right): https://codereview.chromium.org/2938543005/diff/160001/media/gpu/gles2_decode... media/gpu/gles2_decoder_helper.cc:33: DCHECK_CALLED_ON_VALID_THREAD(thread_checker_); nit: dcheck if context is current
On 2017/06/30 01:01:07, sunnyps wrote: > lgtm % nit > > I'll defer to piman@ for high level design, in particular, if this should live > in gpu/command_buffer/service and exposed only via an interface. > > https://codereview.chromium.org/2938543005/diff/160001/media/gpu/gles2_decode... > File media/gpu/gles2_decoder_helper.cc (right): > > https://codereview.chromium.org/2938543005/diff/160001/media/gpu/gles2_decode... > media/gpu/gles2_decoder_helper.cc:33: > DCHECK_CALLED_ON_VALID_THREAD(thread_checker_); > nit: dcheck if context is current piman@: ping. (see message from sunnyps@ for scope)
https://codereview.chromium.org/2938543005/diff/160001/media/gpu/gles2_decode... File media/gpu/gles2_decoder_helper.cc (right): https://codereview.chromium.org/2938543005/diff/160001/media/gpu/gles2_decode... media/gpu/gles2_decoder_helper.cc:33: DCHECK_CALLED_ON_VALID_THREAD(thread_checker_); On 2017/06/30 01:01:07, sunnyps wrote: > nit: dcheck if context is current Done.
This LGTM for now. There's a few nits (some things can't be null), which can simplify the API a bit. There is a larger concern of how this (but also GVDA more generally) will work with the GLES2DecoderPassthroughImpl. Looping in Geoff who's working on that. https://codereview.chromium.org/2938543005/diff/160001/media/gpu/gles2_decode... File media/gpu/gles2_decoder_helper.cc (right): https://codereview.chromium.org/2938543005/diff/160001/media/gpu/gles2_decode... media/gpu/gles2_decoder_helper.cc:35: if (!group) nit: This will always be non-null https://codereview.chromium.org/2938543005/diff/160001/media/gpu/gles2_decode... media/gpu/gles2_decoder_helper.cc:38: if (!texture_manager) So, today this would never be null in production. However we have a new decoder back-end (GLES2DecoderPassthroughImpl) that exclusively works with ANGLE which doesn't use TextureManager, but instead uses the group's PassthroughResources. At the same time, it doesn't use TextureRef either (it just has a client id -> service id map)... Either way, I think GVDA and friends will need some changes to work with it, somewhat orthogonal to this CL. Given that this function wouldn't even make sense with that other back-end, I think I would DCHECK(texture_manager) instead, with a TODO. We may want to revisit this API at a higher level later on, to see how we can make it work with both types of decoder. It could make sense to move some of the logic onto the decoder themselves. https://codereview.chromium.org/2938543005/diff/160001/media/gpu/gles2_decode... media/gpu/gles2_decoder_helper.cc:103: if (!group) nit: ditto https://codereview.chromium.org/2938543005/diff/160001/media/gpu/gles2_decode... media/gpu/gles2_decoder_helper.cc:106: if (!mailbox_manager) nit: also never null Which means, you don't need to provide a failure path.
https://codereview.chromium.org/2938543005/diff/160001/media/gpu/gles2_decode... File media/gpu/gles2_decoder_helper.cc (right): https://codereview.chromium.org/2938543005/diff/160001/media/gpu/gles2_decode... media/gpu/gles2_decoder_helper.cc:38: if (!texture_manager) On 2017/07/06 22:30:50, piman wrote: > So, today this would never be null in production. However we have a new decoder > back-end (GLES2DecoderPassthroughImpl) that exclusively works with ANGLE which > doesn't use TextureManager, but instead uses the group's PassthroughResources. > At the same time, it doesn't use TextureRef either (it just has a client id -> > service id map)... Either way, I think GVDA and friends will need some changes > to work with it, somewhat orthogonal to this CL. Given that this function > wouldn't even make sense with that other back-end, I think I would > DCHECK(texture_manager) instead, with a TODO. > > We may want to revisit this API at a higher level later on, to see how we can > make it work with both types of decoder. It could make sense to move some of the > logic onto the decoder themselves. Done. In general, the purpose of VDAs is not just to be in the GPU process, but also to have access to the platform primitives for graphics operations. Perhaps the real answer is that we'll eventually want to move to the other side of ANGLE? https://codereview.chromium.org/2938543005/diff/160001/media/gpu/gles2_decode... media/gpu/gles2_decoder_helper.cc:103: if (!group) On 2017/07/06 22:30:50, piman wrote: > nit: ditto Done. https://codereview.chromium.org/2938543005/diff/160001/media/gpu/gles2_decode... media/gpu/gles2_decoder_helper.cc:106: if (!mailbox_manager) On 2017/07/06 22:30:50, piman wrote: > nit: also never null > > Which means, you don't need to provide a failure path. Done.
The CQ bit was checked by sandersd@chromium.org
The patchset sent to the CQ was uploaded after l-g-t-m from watk@chromium.org, sunnyps@chromium.org, piman@chromium.org Link to the patchset: https://codereview.chromium.org/2938543005/#ps200001 (title: "Don't check for guaranteed non-nulls.")
CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
CQ is committing da patch.
Bot data: {"patchset_id": 200001, "attempt_start_ts": 1499462210233150,
"parent_rev": "8d85c9d73b81179c68dd4977e1cad46eeb8bf1cf", "commit_rev":
"0ea82f3864289d9103d288edc822f264e62ca9a4"}
Message was sent while issue was closed.
Description was changed from ========== media: Add GLES2DecoderHelper This class wraps a gpu::gles2::GLES2Decoder* to provide utility functions for VDAs. BUG=522298 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel ========== to ========== media: Add GLES2DecoderHelper This class wraps a gpu::gles2::GLES2Decoder* to provide utility functions for VDAs. BUG=522298 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel Review-Url: https://codereview.chromium.org/2938543005 Cr-Commit-Position: refs/heads/master@{#485091} Committed: https://chromium.googlesource.com/chromium/src/+/0ea82f3864289d9103d288edc822... ==========
Message was sent while issue was closed.
Committed patchset #8 (id:200001) as https://chromium.googlesource.com/chromium/src/+/0ea82f3864289d9103d288edc822... |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
