[NvidiaLinux] Use BufferUsage::SCANOUT for GMB video frames to support NVIDIA drivers

On Linux, GpuMemoryBuffer video frames created with
BufferUsage::SCANOUT_CPU_READ_WRITE implicitly request
GBM_BO_USE_LINEAR, which is incompatible with rendering on certain
NVIDIA drivers.

This incompatibility prevents rendering in CEF shared texture and video
capture pipelines.

Switching to BufferUsage::SCANOUT avoids GBM_BO_USE_LINEAR while
retaining GBM_BO_USE_RENDERING, GBM_BO_USE_SCANOUT, and
GBM_BO_USE_TEXTURING, enabling Skia-based rendering and texture interop
to work correctly with NVIDIA drivers.

To support this a new value kPreferSharedImageWithNativeHandle, was
added to the BufferFormatPreference enum, which indicates that the
consumer prefers buffers with exportable GPU native handles (e.g.,
DMABUF FDs on Linux). These buffers may not be CPU mappable, but are
better suited for GPU interop scenarios such as Vulkan, Skia, or
offscreen rendering with shared textures.

The preference is propagated through the capture pipeline:

Start() receives the BufferFormatPreference from the client.

This preference is passed to VideoFramePool, then to
RenderableGpuMemoryBufferVideoFramePool.

FrameResources::Initialize() uses this to choose between
SCANOUT_CPU_READ_WRITE (default) and SCANOUT, depending on whether CPU
access is required.

The default behavior remains unchanged (i.e. CPU access is assumed
unless otherwise specified). Clients like Chromium Embedded Framework
(CEF) or GPU only consumers can now specify
kPreferSharedImageWithNativeHandle to request buffers that are not CPU
accessible but support efficient GPU interop.

Bug: 428022619
Test:
FrameSinkVideoCapturerTest.BufferFormatPreferencePassedToGpuFramePool,
RenderableGpuMemoryBufferVideoFramePoolTest.RequiresCpuAccessAffectsBufferUsage

Change-Id: I7975173ed38300ce6fa995b530ada2c85a2cea27
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6681354
Reviewed-by: Ted (Chromium) Meyer <tmathmeyer@chromium.org>
Commit-Queue: Anantanarayanan Iyengar US <aiyengar@nvidia.com>
Reviewed-by: Vasiliy Telezhnikov <vasilyt@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1497315}
9 files changed
tree: a8e7da70100c00e37f8222eaaefd76213b3ad129
  1. .github/
  2. agents/
  3. android_webview/
  4. apps/
  5. ash/
  6. base/
  7. build/
  8. build_overrides/
  9. buildtools/
  10. cc/
  11. chrome/
  12. chromecast/
  13. chromeos/
  14. codelabs/
  15. components/
  16. content/
  17. crypto/
  18. dbus/
  19. device/
  20. docs/
  21. extensions/
  22. fuchsia_web/
  23. gin/
  24. google_apis/
  25. gpu/
  26. headless/
  27. infra/
  28. ios/
  29. ipc/
  30. media/
  31. mojo/
  32. net/
  33. pdf/
  34. printing/
  35. remoting/
  36. rlz/
  37. sandbox/
  38. services/
  39. skia/
  40. sql/
  41. storage/
  42. styleguide/
  43. testing/
  44. third_party/
  45. tools/
  46. ui/
  47. url/
  48. webkit/
  49. .clang-format
  50. .clang-tidy
  51. .clangd
  52. .cursorignore
  53. .geminiignore
  54. .git-blame-ignore-revs
  55. .gitallowed
  56. .gitattributes
  57. .gitignore
  58. .gitmodules
  59. .gn
  60. .mailmap
  61. .rustfmt.toml
  62. .vpython3
  63. .yapfignore
  64. ATL_OWNERS
  65. AUTHORS
  66. BUILD.gn
  67. CODE_OF_CONDUCT.md
  68. codereview.settings
  69. CPPLINT.cfg
  70. CRYPTO_OWNERS
  71. DEPS
  72. DIR_METADATA
  73. LICENSE
  74. LICENSE.chromium_os
  75. OWNERS
  76. PRESUBMIT.py
  77. PRESUBMIT_test.py
  78. PRESUBMIT_test_mocks.py
  79. README.md
  80. SECURITY_OWNERS
  81. WATCHLISTS
README.md

Logo Chromium

Chromium is an open-source browser project that aims to build a safer, faster, and more stable way for all users to experience the web.

The project's web site is https://www.chromium.org.

To check out the source code locally, don't use git clone! Instead, follow the instructions on how to get the code.

Documentation in the source is rooted in docs/README.md.

Learn how to Get Around the Chromium Source Code Directory Structure.

For historical reasons, there are some small top level directories. Now the guidance is that new top level directories are for product (e.g. Chrome, Android WebView, Ash). Even if these products have multiple executables, the code should be in subdirectories of the product.

If you found a bug, please file it at https://crbug.com/new.