commit 52935286e62f786ad52cc3dd2e1813f7911ef99f
author Michael Tang <tangm@microsoft.com> Sat Jul 27 01:03:09 2024
committer Chromium LUCI CQ <chromium-scoped@luci-project-accounts.iam.gserviceaccount.com> Sat Jul 27 01:03:09 2024
tree a6c4b1eb22b04faee1e0a83277d71a57dd1327d4
parent 2aad7b33473199ecc61ffd35a014c747be21f333

Reland "gpu: win: Implement IDCompositionTexture for SCANOUT D3DImageBackings"

This is a reland of commit ed42105df5e6d41b3c8ce9b1d44791fb8a66c91f

The issue was that the original change returned true for
`D3DImageBackingFactory::IsSupported`, because we would hit the new
DComp texture check if `is_scanout && !is_video_decode && gmb_type !=
DXGI_SHARED_HANDLE`. However, in some video  cases, `gmb_type` can be
`SHARED_MEMORY_BUFFER`, which we want to always return false for, but
would return true in the original change if we supported DComp
textures.

Original change's description:
> gpu: win: Implement IDCompositionTexture for SCANOUT D3DImageBackings
>
> This change adds support for the SCANOUT usage for D3DImageBacking. It
> uses IDCompositionTexture, which is a new API introduced in Windows 11,
> version 10.0.22621.2428. IDCompositionTexture can be placed directly in
> a DComp tree, enabling delegated compositing of renderer quads.
>
> D3DImageBacking already has multiple "SCANOUT" usage implementations:
> swap chain and video frame textures. These should not conflict with the
> IDCompositionTexture backings, since both swap chains and video frame
> textures directly create D3DImageBackings (bypassing the
> SharedImageFactory) or use the GMB CreateSharedImage overloads.
> IDCompositionTextures are only created for compatible textures created
> through the normal, non-GMB CreateSharedImage overloads.
>
> For the purpose of delegated compositing, SCANOUT textures overlay read
> accesses are required to be held by the output device for potentially
> multiple frames (while the image is being used by the OS compositor).
> Due to this, these textures are incompatible with textures needing a
> keyed mutex, since the expectation for those textures is minimal read
> access scope. This shouldn't be an issue, but I've added a CHECK to
> ensure it's the case.
>
> This API was added in a patch version of build 22621, which causes some
> complications for detecting the SDK version. The SDK installs to a
> folder that does not include the patch version, so this change modifies
> the vs_toolchain.py to emit a custom error message if we're on build
> 22621 but do not have the new APIs.
>
> Bug: 1132392
> Change-Id: I2a99ed4bcd8790dd77e8011debde92db86c23e14
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5341660
> Commit-Queue: Michael Tang <tangm@microsoft.com>
> Reviewed-by: Sunny Sachanandani <sunnyps@chromium.org>
> Reviewed-by: Rafael Cintron <rafael.cintron@microsoft.com>
> Reviewed-by: Dirk Pranke <dpranke@google.com>
> Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#1331926}

Cq-Include-Trybots: luci.chromium.try:gpu-fyi-try-win11-qualcomm-rel-64
Bug: 1132392
Change-Id: I5f923474df039f1724e85bf5f4ef37211200968a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5738088
Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
Reviewed-by: Sunny Sachanandani <sunnyps@chromium.org>
Reviewed-by: Rafael Cintron <rafael.cintron@microsoft.com>
Commit-Queue: Michael Tang <tangm@microsoft.com>
Reviewed-by: Dirk Pranke <dpranke@google.com>
Cr-Commit-Position: refs/heads/main@{#1333853}