From patchwork Thu Jun 10 22:48:29 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Kasireddy, Vivek" X-Patchwork-Id: 12314241 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-11.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C8144C48BDF for ; Thu, 10 Jun 2021 23:02:39 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 6E98661287 for ; Thu, 10 Jun 2021 23:02:39 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6E98661287 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:51550 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lrTh8-0001HJ-C8 for qemu-devel@archiver.kernel.org; Thu, 10 Jun 2021 19:02:38 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:51040) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lrTfy-0007H8-Ke for qemu-devel@nongnu.org; Thu, 10 Jun 2021 19:01:26 -0400 Received: from mga17.intel.com ([192.55.52.151]:52951) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lrTft-0006zL-Pr for qemu-devel@nongnu.org; Thu, 10 Jun 2021 19:01:26 -0400 IronPort-SDR: FOdWRLYC0MDILhWs5rxo92H7vezPuEPWTIj25tafadkHQE7N5GvPM7Ahw3gAiiShNTvaOLmpUI r1CGkNMrlnZw== X-IronPort-AV: E=McAfee;i="6200,9189,10011"; a="185796179" X-IronPort-AV: E=Sophos;i="5.83,264,1616482800"; d="scan'208";a="185796179" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Jun 2021 16:01:08 -0700 IronPort-SDR: KPjHMlEnvPd1ZQLNEZ/5VLz+6GaDcsbpTetBg4YPTuynglOZHkMPXRuHqlrJaseWtqMvHDOpfc Jelneh0xabFw== X-IronPort-AV: E=Sophos;i="5.83,264,1616482800"; d="scan'208";a="419888349" Received: from vkasired-desk2.fm.intel.com ([10.105.128.127]) by orsmga002-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Jun 2021 16:01:07 -0700 From: Vivek Kasireddy To: qemu-devel@nongnu.org Subject: [PATCH v2 0/8] virtio-gpu: Add a default synchronization mechanism for blobs Date: Thu, 10 Jun 2021 15:48:29 -0700 Message-Id: <20210610224837.670192-1-vivek.kasireddy@intel.com> X-Mailer: git-send-email 2.30.2 MIME-Version: 1.0 Received-SPF: pass client-ip=192.55.52.151; envelope-from=vivek.kasireddy@intel.com; helo=mga17.intel.com X-Spam_score_int: -41 X-Spam_score: -4.2 X-Spam_bar: ---- X-Spam_report: (-4.2 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Dongwon Kim , Tina Zhang , Vivek Kasireddy , Gerd Hoffmann Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" When the Guest and Host are using Blob resources, there is a chance that they may use the underlying storage associated with a Blob at the same time leading to glitches such as flickering or tearing. To prevent these from happening, the Host needs to ensure that it waits until its Blit is completed by the Host GPU before letting the Guest reuse the Blob. This should be the default behavior regardless of the type of Guest that is using Blob resources but would be particularly useful for Guests that are using frontbuffer rendering such as Linux with X or Windows 10, etc. The way it works is the Guest includes a fence as part of resource_flush and waits for it to be signalled. The Host will queue a repaint request and signal the fence after it completes waiting on the sync object associated with the Blit. v2: - Added more description in the cover letter - Removed the wait from resource_flush and included it in a gl_flushed() callback Cc: Gerd Hoffmann Cc: Dongwon Kim Cc: Tina Zhang Vivek Kasireddy (8): ui/gtk: Create a common release_dmabuf helper ui/egl: Add egl helpers to help with synchronization ui: Add a helper to wait on a dmabuf sync object ui/gtk: Implement wait_dmabuf function ui: Create sync objects only for blobs ui/gtk-egl: Wait for the draw signal for dmabuf blobs virtio-gpu: Add dmabuf helpers for synchronization virtio-gpu: Add gl_flushed callback hw/display/virtio-gpu-udmabuf.c | 30 ++++++++++++++++++++++ hw/display/virtio-gpu.c | 44 ++++++++++++++++++++++++++++++++- include/hw/virtio/virtio-gpu.h | 2 ++ include/ui/console.h | 8 ++++++ include/ui/egl-helpers.h | 4 +++ include/ui/gtk.h | 4 +-- stubs/virtio-gpu-udmabuf.c | 6 +++++ ui/console.c | 10 ++++++++ ui/egl-helpers.c | 44 +++++++++++++++++++++++++++++++++ ui/gtk-egl.c | 32 ++++++++++++++++++------ ui/gtk-gl-area.c | 8 ++++++ ui/gtk.c | 28 +++++++++++++++++++-- 12 files changed, 207 insertions(+), 13 deletions(-)