From mboxrd@z Thu Jan 1 00:00:00 1970 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=-0.9 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no 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 15690C43603 for ; Thu, 19 Dec 2019 13:12:46 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id DDD4020716 for ; Thu, 19 Dec 2019 13:12:45 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="MqUgKUbg" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726751AbfLSNMp (ORCPT ); Thu, 19 Dec 2019 08:12:45 -0500 Received: from us-smtp-delivery-1.mimecast.com ([207.211.31.120]:27256 "EHLO us-smtp-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726701AbfLSNMp (ORCPT ); Thu, 19 Dec 2019 08:12:45 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1576761164; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=3xWdptGiax0pdVbALf1KWnovXqWWxHEyt0r89yHID0w=; b=MqUgKUbgcMEya4gRnBjcqMVhlZnZ6jRUL/IuTMujMoSJ+LZqeAgCNTCgJxHSxqfSxqBzek vgBAfy0/bvfSzXraRFAHYuuvXTcDVq4DZY7+csa3lxsDk9/Ib/D22CslXdLXLkkoY0faNJ 3yxwRpSOKL4sbc3O4OHsf8/TenLLM7c= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-207-Nd4DKpusNceE6R0IkJcwBQ-1; Thu, 19 Dec 2019 08:12:41 -0500 X-MC-Unique: Nd4DKpusNceE6R0IkJcwBQ-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id A7776100550E; Thu, 19 Dec 2019 13:12:38 +0000 (UTC) Received: from sirius.home.kraxel.org (ovpn-116-98.ams2.redhat.com [10.36.116.98]) by smtp.corp.redhat.com (Postfix) with ESMTP id A12C1620C0; Thu, 19 Dec 2019 13:12:35 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id 8020A9DA3; Thu, 19 Dec 2019 14:12:34 +0100 (CET) Date: Thu, 19 Dec 2019 14:12:34 +0100 From: Gerd Hoffmann To: Dmitry Sepp Cc: Tomasz Figa , Keiichi Watanabe , virtio-dev@lists.oasis-open.org, Linux Media Mailing List , Alexandre Courbot , Alex Lau , Daniel Vetter , Dylan Reid , Enrico Granata , fziglio@redhat.com, Hans Verkuil , =?utf-8?B?U3TDqXBoYW5l?= Marchesin , Pawel Osciak , spice-devel@lists.freedesktop.org, David Stevens , uril@redhat.com Subject: Re: [virtio-dev] Re: [PATCH v2 1/1] virtio-video: Add virtio video device specification Message-ID: <20191219131234.wm24cazvc7zrnhpn@sirius.home.kraxel.org> References: <20191218130214.170703-1-keiichiw@chromium.org> <3550989.gzE5nMqd4t@os-lin-dmo> <3878267.TzG3DlCiay@os-lin-dmo> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3878267.TzG3DlCiay@os-lin-dmo> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org Hi, > > However that still doesn't let the driver know which buffers will be > > dequeued when. A simple example of this scenario is when the guest is > > done displaying a frame and requeues the buffer back to the decoder. > > Then the decoder will not choose it for decoding next frames into as > > long as the frame in that buffer is still used as a reference frame, > > even if one sends the drain request. > It might be that I'm getting your point wrong, but do you mean some hardware > can mark a buffer as ready to be displayed yet still using the underlying > memory to decode other frames? Yes, this is how I understand Tomasz Figa. > This means, if you occasionally/intentionally > write to the buffer you mess up the whole decoding pipeline. And to avoid this the buffer handling aspect must be clarified in the specification. Is the device allowed to continue using the buffer after finishing decoding and completing the queue request? If so, how do we hand over buffer ownership back to the driver so it can free the pages? drain request? How do we handle re-using buffers? Can the driver simply re-queue them and expect the device figures by itself whenever it can use the buffer or whenever it is still needed as reference frame? cheers, Gerd From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: virtio-dev-return-6548-cohuck=redhat.com@lists.oasis-open.org Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis-open.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id 3B500985F44 for ; Thu, 19 Dec 2019 13:12:45 +0000 (UTC) Date: Thu, 19 Dec 2019 14:12:34 +0100 From: Gerd Hoffmann Message-ID: <20191219131234.wm24cazvc7zrnhpn@sirius.home.kraxel.org> References: <20191218130214.170703-1-keiichiw@chromium.org> <3550989.gzE5nMqd4t@os-lin-dmo> <3878267.TzG3DlCiay@os-lin-dmo> MIME-Version: 1.0 In-Reply-To: <3878267.TzG3DlCiay@os-lin-dmo> Subject: Re: [virtio-dev] Re: [PATCH v2 1/1] virtio-video: Add virtio video device specification Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline To: Dmitry Sepp Cc: Tomasz Figa , Keiichi Watanabe , virtio-dev@lists.oasis-open.org, Linux Media Mailing List , Alexandre Courbot , Alex Lau , Daniel Vetter , Dylan Reid , Enrico Granata , fziglio@redhat.com, Hans Verkuil , =?utf-8?B?U3TDqXBoYW5l?= Marchesin , Pawel Osciak , spice-devel@lists.freedesktop.org, David Stevens , uril@redhat.com List-ID: Hi, > > However that still doesn't let the driver know which buffers will be > > dequeued when. A simple example of this scenario is when the guest is > > done displaying a frame and requeues the buffer back to the decoder. > > Then the decoder will not choose it for decoding next frames into as > > long as the frame in that buffer is still used as a reference frame, > > even if one sends the drain request. > It might be that I'm getting your point wrong, but do you mean some hardw= are=20 > can mark a buffer as ready to be displayed yet still using the underlying= =20 > memory to decode other frames? Yes, this is how I understand Tomasz Figa. > This means, if you occasionally/intentionally=20 > write to the buffer you mess up the whole decoding pipeline. And to avoid this the buffer handling aspect must be clarified in the specification. Is the device allowed to continue using the buffer after finishing decoding and completing the queue request? If so, how do we hand over buffer ownership back to the driver so it can free the pages? drain request? How do we handle re-using buffers? Can the driver simply re-queue them and expect the device figures by itself whenever it can use the buffer or whenever it is still needed as reference frame? cheers, Gerd --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org