Revert "Reuse pixmap across VFPool/MailboxVFConverter."
This reverts commit f204c589. Reason for revert: crbug.com/1097755 Bug: 1097755 Original change's description: > Reuse pixmap across VFPool/MailboxVFConverter. > > In the newly introduced VideoDecoder, we create a native buffer for > video decoding on demand in the PlatformVideoFramePool. This buffer > eventually makes it to the MailboxVideoFrameConverter in order to > produce a SharedImage for the client. > > This CL ensures that the NativePixmap created in the > PlatformVideoFramePool can be re-used in the MailboxVideoFrameConverter. > Before this CL, we would call CreateNativePixmapFromHandle() > unnecessarily when creating the SharedImage for a buffer. That's because > we didn't propagate the GpuMemoryBufferId correctly from the > PlatformVideoFramePool to the MailboxVideoFrameConverter and the check > in [1] would fail. As a result, we would end up creating an additional > DRM framebuffer which is unnecessary because the allocation in the > PlatformVideoFramePool would have already created one. Thus, the > video.MemCheck.h264_hw test would fail because of having created too > many objects. > > To propagate the GpuMemoryBufferId correctly, we create a > GpuMemoryBuffer VideoFrame in the PlatformVideoFramePool (instead of a > dma-buf VideoFrame). That way, when MailboxVideoFrameConverter calls > CreateGpuMemoryBufferHandle(), it gets a GpuMemoryBufferHandle with the > same ID that PlatformVideoFramePool gets. Additionally, we make > MailboxVideoFrameConverter use kPlatformVideoFramePoolClientId since > that identifies the namespace of the GpuMemoryBufferIds in question. > > Note that for SCANOUT_VDA_WRITE buffers (which we use for video > decoding), we end up creating a ClientNativePixmapOpaque when creating a > GpuMemoryBufferImplNativePixmap. This is problematic because a > ClientNativePixmapOpaque doesn't let us query the stride and we need to > know it in order to create a GpuMemoryBuffer VideoFrame. Therefore, > GpuMemoryBufferImplNativePixmap::stride() is changed so that it's not > necessary to have a gfx::ClientNativePixmap to query the stride. > Instead, we query the underlying NativePixmapHandle directly. > > For that same reason, we must introduce a workaround in the > VideoFrameValidator: when we get a GMB VideoFrame, we cannot map it > directly because ClientNativePixmapOpaque doesn't allow us to. > Therefore, we extract the dma-buf FDs and use the regular dma-buf > mapping path. > > [1] https://cs.chromium.org/chromium/src/gpu/ipc/service/gpu_memory_buffer_factory_native_pixmap.cc?l=152&rcl=d96e9f16ae852ec9dbd15bf17df3d440402413bb > > Bug: 1091450, 1093644 > Test: video.MemCheck.h264_hw_switch, video.DecodeAccelVD.h264 on eve > Change-Id: I3d60efa362b66bd2f01139296d4ed756c8777ef8 > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2233534 > Commit-Queue: Andres Calderon Jaramillo <andrescj@chromium.org> > Reviewed-by: Daniel Cheng <dcheng@chromium.org> > Reviewed-by: Daniele Castagna <dcastagna@chromium.org> > Reviewed-by: Hirokazu Honda <hiroh@chromium.org> > Reviewed-by: Chih-Yu Huang <akahuang@chromium.org> > Cr-Commit-Position: refs/heads/master@{#780504} TBR=dcheng@chromium.org,akahuang@chromium.org,dcastagna@chromium.org,hiroh@chromium.org,andrescj@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: 1091450, 1093644 Change-Id: Iace25eb12b50b030327568ae75ebef0f7691934d Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2257418Reviewed-by:Corentin Wallez <cwallez@chromium.org> Commit-Queue: Corentin Wallez <cwallez@chromium.org> Cr-Commit-Position: refs/heads/master@{#780775}
Showing
Please register or sign in to comment