[webkit-changes] [WebKit/WebKit] ea7c20: Cherry-pick 261072 at main (5c473b4124bf). https://bu...

[Žan Doberšek]

  Branch: refs/heads/webkitglib/2.40
  Home:   https://github.com/WebKit/WebKit
  Commit: ea7c20dfa5aa52dff6d8f740f37e7872177dc835
      https://github.com/WebKit/WebKit/commit/ea7c20dfa5aa52dff6d8f740f37e7872177dc835
  Author: Žan Doberšek <zdobersek at igalia.com>
  Date:   2023-03-03 (Fri, 03 Mar 2023)

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

  Log Message:
  -----------
  Cherry-pick 261072 at main (5c473b4124bf). https://bugs.webkit.org/show_bug.cgi?id=253244

    [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


  Commit: 49971be69094bede8d25c2129b98eaf33dcb85c4
      https://github.com/WebKit/WebKit/commit/49971be69094bede8d25c2129b98eaf33dcb85c4
  Author: Žan Doberšek <zdobersek at igalia.com>
  Date:   2023-03-03 (Fri, 03 Mar 2023)

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

  Log Message:
  -----------
  Cherry-pick 261077 at main (9b1c8b87c0a4). https://bugs.webkit.org/show_bug.cgi?id=253245

    [GStreamer] Improve GBM swapchain buffer handling
    https://bugs.webkit.org/show_bug.cgi?id=253245

    Reviewed by Philippe Normand.

    In MediaPlayerPrivateGStreamer::pushDMABufToCompositor(), when allocating
    buffer objects from the GBMBufferSwapchain to upload the software-decoded
    video data, do a null check on the retrieved buffer. This avoids proceeding with
    a null object that would be returned when for whatever perverse reason the
    swapchain is drained of available buffers.

    One such reason is when allocating, retrieving and locking buffers from the
    swapchain under an inactive proxy. In that case, the buffer doesn't end up
    being pushed into the composition, and it's then also never released and made
    available for reuse, effectively draining the swapchain.

    This case is avoidable through earlier detection of an inactive proxy. The proxy
    lock and is-active check are unified between different codepaths and done before
    deciding which codepath is taken.

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

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


Compare: https://github.com/WebKit/WebKit/compare/90e92d2420f1...49971be69094