[webkit-changes] [WebKit/WebKit] 5c473b: [GStreamer] Establish locking when mapping gbm_bo ...

[Žan Doberšek]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 5c473b4124bf9486701c9e3277399a211de530a5
      https://github.com/WebKit/WebKit/commit/5c473b4124bf9486701c9e3277399a211de530a5
  Author: Žan Doberšek <zdobersek at igalia.com>
  Date:   2023-03-02 (Thu, 02 Mar 2023)

  Changed paths:
    M Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp

  Log Message:
  -----------
  [GStreamer] Establish locking when mapping gbm_bo objects for software-decoded data upload
https://bugs.webkit.org/show_bug.cgi?id=253244

Reviewed by Philippe Normand.

When separate GStreamer pipelines are established for different video elements,
mapping the gbm_bo objects in parallel across different threads can lead to
crashes and GPU memory corruption.

The different gbm_bo objects originate from a single gbm_device, which is fine.
Spawning gbm_bo objects and retrieving different attributes from them isn't
showing as problematic, but libgbm thread safety guarantees still need research.

Mapping gbm_bo objects in parallel is proving as problematic, and the length of
the upload of software-decoded data into the mapped memory regions takes long
enough for these problems to inhibit stability. To avoid that, a global lock is
provided on the gbm_bo-mapping Destination class inside the
MediaPlayerPrivateGStreamer::pushDMABufToCompositor() method. This lock is
activated whenever data for a given plane is moved over from the GStreamer-based
software decoder into the gbm_bo object.

* Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp:
(WebCore::MediaPlayerPrivateGStreamer::pushDMABufToCompositor):

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