Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: be6e7f710fee95e06cd97e7ae5059aa2ee3ba861
      
https://github.com/WebKit/WebKit/commit/be6e7f710fee95e06cd97e7ae5059aa2ee3ba861
  Author: Nikolas Zimmermann <[email protected]>
  Date:   2026-04-28 (Tue, 28 Apr 2026)

  Changed paths:
    M Source/WebCore/PlatformGTK.cmake
    M Source/WebCore/PlatformWPE.cmake
    M Source/WebCore/platform/graphics/gbm/DMABufBuffer.cpp
    R Source/WebCore/platform/graphics/gbm/GBMUtilities.h
    M Source/WebCore/platform/graphics/gbm/MemoryMappedGPUBuffer.cpp
    M Source/WebCore/platform/graphics/gbm/MemoryMappedGPUBuffer.h

  Log Message:
  -----------
  [Skia][GBM] Use gbm_bo_map() fallback when gbm_bo_get_fd_for_plane() returns 
a non-RDWR FD
https://bugs.webkit.org/show_bug.cgi?id=313488

Reviewed by Carlos Garcia Campos.

Replaces the DRMSystemCall mapping strategy (drmPrimeHandleToFD(DRM_RDWR))
with a gbm_bo_map() fallback. The DRMSystemCall path could not satisfy two
mutually exclusive constraints on the same gem handle: (a) the GPU-sampling
prime export must go through gbm_bo_get_fd_for_plane() so Mesa observes it
and attaches its implicit-sync dma_resv fence (otherwise V3D Gallium's
pre-draw fence wait returns EINVAL or hangs in the v3d_dri ioctl, as seen
on RPi4); (b) the CPU-mapping FD must be RDWR-capable, but on Mesa builds
that don't pass DRM_RDWR through gbm_bo_get_fd_for_plane() the kernel locks
the dma-buf mode flags on first export, so any subsequent FD aliasing the
cached entry SIGBUSes on mmap(PROT_WRITE).

Both ordering attempts (gbm-first / drm-first) broke one of the two
constraints on at least one Mesa version. gbm_bo_map() side-steps the
problem entirely: it uses the driver-native BO mmap path and never touches
the kernel dma-buf cache, so the GPU-sampling export's mode flags don't
constrain it.

The capability probe still runs once per session: it tries the dma-buf-FD
mmap path first and falls back to gbm_bo_map() only if the FD isn't
PROT_WRITE-mappable. Systems where gbm_bo_get_fd_for_plane() already
returns RDWR FDs keep the existing fast path. The originating gbm_bo* is
retained for the lifetime of the buffer regardless of strategy. A
RELEASE_ASSERT enforces that ForceVivanteSuperTiled only uses the
dma-buf-mmap strategy, since gbm_bo_map() is allowed to linearize tiled
BOs and would silently corrupt VivanteSuperTiledTexture's stride
assumption.

* Source/WebCore/PlatformGTK.cmake:
* Source/WebCore/PlatformWPE.cmake: Drop GBMUtilities.h.
* Source/WebCore/platform/graphics/gbm/DMABufBuffer.cpp:
(WebCore::DMABufBufferAttributes::fromGBMBufferObject): Call
gbm_bo_get_fd_for_plane() directly; the GPU-sampling purpose is the only
one served here now.
* Source/WebCore/platform/graphics/gbm/GBMUtilities.h: Removed.
* Source/WebCore/platform/graphics/gbm/MemoryMappedGPUBuffer.cpp:
(WebCore::strategyName):
(WebCore::runCapabilityProbe):
(WebCore::cachedCPUMappingStrategy):
(WebCore::MemoryMappedGPUBuffer::isSupported):
(WebCore::MemoryMappedGPUBuffer::exportStrategyDescription):
(WebCore::MemoryMappedGPUBuffer::create):
(WebCore::MemoryMappedGPUBuffer::~MemoryMappedGPUBuffer):
(WebCore::MemoryMappedGPUBuffer::primaryPlaneDmaBufFD):
(WebCore::MemoryMappedGPUBuffer::mapIfNeeded):
(WebCore::MemoryMappedGPUBuffer::unmapIfNeeded):
(WebCore::MemoryMappedGPUBuffer::performDMABufSyncSystemCall):
* Source/WebCore/platform/graphics/gbm/MemoryMappedGPUBuffer.h:

Canonical link: https://commits.webkit.org/312182@main



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications

Reply via email to