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 3EDFAC43603 for ; Tue, 17 Dec 2019 13:16:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 042CC20716 for ; Tue, 17 Dec 2019 13:16:14 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="bzctSbhh" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727941AbfLQNQN (ORCPT ); Tue, 17 Dec 2019 08:16:13 -0500 Received: from mail-ed1-f65.google.com ([209.85.208.65]:46092 "EHLO mail-ed1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727736AbfLQNQN (ORCPT ); Tue, 17 Dec 2019 08:16:13 -0500 Received: by mail-ed1-f65.google.com with SMTP id m8so7960947edi.13 for ; Tue, 17 Dec 2019 05:16:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6WQl0PRUEhaXlPsBOZs45R+KlV8M2VaJbDwobeEyETI=; b=bzctSbhhGOS6SX7VGZzvSGQLQIEgw4gBRD6xeLcwEah6Jl3IJBpN55Po+kUoDtPSIK q1j/7QvVDRyPX9pq4yJb8ar1XvGf1WZ3Ibf/JBLc8QwVjlrzey9MH7uYETQNS5G/nOkD BRUSh9skWEn9btuHy/SGuxpVXgu7h0feM9wHg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6WQl0PRUEhaXlPsBOZs45R+KlV8M2VaJbDwobeEyETI=; b=DCMOw3r/4FgjsTyyXIs7ecbJi8XAInuJhx+uZq+LUYDjkzPVRrnc3NhYw6cBYZ7tmz 8DuWmgSHByVQlXfL4q1b6a8RpcAJTaCe5s/0R5dUzuHAG5SnDZyXSk7fWq7S7+omMbo5 v5hifC1/Kp6/DZHfh9AYzB8jjPPZaZG4rAU9dbndpdvSwPkN54/gqElG9yfe7NhpDN7U QJsX/eMH4G+1lZZIbLGih5S8Ex98Dy+YdoFB5aDiDaNgDKsGn5IvUF00KhdN4CdJ7cgG CuAG8jKRJ6Ai2RDvb2+RuEUKnST1uDAqEZ3DF2BU7YDdpUgD7WLYYRlYqvRHoVxPn6fs +b+w== X-Gm-Message-State: APjAAAVMvX2D9d7FRb1SVuMaFlAxko/OfqXRvk6UOm7aZFEtGvpRweFU 7+9uJ32qiKLsNbzvDnDd2HTZ55iI4AG0SA== X-Google-Smtp-Source: APXvYqwLgsO8iDf3IVIL9Dze6wTQBDsAPgmeQW1N8hsEYvx78BoOXwwXVrFflRxD/b1C1HswBRJGfQ== X-Received: by 2002:a17:906:2e46:: with SMTP id r6mr5136348eji.310.1576588570291; Tue, 17 Dec 2019 05:16:10 -0800 (PST) Received: from mail-wm1-f47.google.com (mail-wm1-f47.google.com. [209.85.128.47]) by smtp.gmail.com with ESMTPSA id h61sm719645edd.49.2019.12.17.05.16.08 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 17 Dec 2019 05:16:09 -0800 (PST) Received: by mail-wm1-f47.google.com with SMTP id b72so3114404wme.4 for ; Tue, 17 Dec 2019 05:16:08 -0800 (PST) X-Received: by 2002:a1c:e916:: with SMTP id q22mr5423008wmc.92.1576588567759; Tue, 17 Dec 2019 05:16:07 -0800 (PST) MIME-Version: 1.0 References: <20191105191919.167345-1-dmitry.sepp@opensynergy.com> <20191120112929.gvsne7ykvcyw65lu@sirius.home.kraxel.org> <7736193.Whgddqjo8n@os-lin-dmo> <20191204091620.zpnd7jttkpkduort@sirius.home.kraxel.org> <20191216103236.ugjorzq5pntc7gtt@sirius.home.kraxel.org> In-Reply-To: <20191216103236.ugjorzq5pntc7gtt@sirius.home.kraxel.org> From: Tomasz Figa Date: Tue, 17 Dec 2019 22:15:56 +0900 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [virtio-dev] [RFC RESEND] virtio-video: Add virtio video device specification To: Gerd Hoffmann Cc: Keiichi Watanabe , Dmitry Sepp , virtio-dev@lists.oasis-open.org, Linux Media Mailing List , Alexandre Courbot , Alex Lau , Dylan Reid , =?UTF-8?Q?St=C3=A9phane_Marchesin?= , Pawel Osciak , David Stevens , Hans Verkuil , Daniel Vetter Content-Type: text/plain; charset="UTF-8" Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org On Mon, Dec 16, 2019 at 7:32 PM Gerd Hoffmann wrote: > > Hi, > > > > Hmm, modern GPUs support both encoding and decoding ... > > > > Many SoC architectures have completely separate IP blocks for encoding > > and decoding. Similarly, in GPUs those are usually completely separate > > parts of the pipeline. > > In the OS there is one driver per GPU handling both ... > That's usually only the case for the desktop PC-style GPUs. That said, it probably doesn't matter from the protocol point of view how it's handled in the host. At least it is definitely safe to assume that the host provides functionality for independently decoding and encoding things from different processes, which is enough to implement virtio decoder and encoder as separate devices. > > > I don't think we should bake that restriction into the specification. > > > It probably makes sense to use one virtqueue per function though, that > > > will simplify dispatching in both host and guest. > > > > > > > Wouldn't it make the handling easier if we had one virtio device per function? > > I don't think there is much of a difference between one device per > function and one virtqueue per function. You'll probably have a single > driver for both anyway, to share common code for buffer management etc. > The semantics of the encoder and decoder on the driver side, at least on Linux where V4L2 is used, are different enough for much of the code to be separated. That said, even with separate devices, the same driver can be instantiated multiple times, which is a common case in Linux, handled by the driver core. That basically gives us the ability to have as many instances of whatever function we want for free, without the need to explicitly handle multiple functions in one device in the driver. So that clearly equals simpler driver code. On the host side, the encode and decode APIs are different as well, so having separate implementation decoder and encoder, possibly just sharing some helper code, would make much more sense. > > > Use separate pixel_format (fourcc) and stream_format (H.264 etc.) enums? > > > > I'd specifically avoid FourCC here, as it's very loosely defined and > > could introduce confusion. > > I don't think using fourcc is a problem, and given that both drm and > v4l2 use fourcc already this would be a good choice I think. Both DRM and V4L2 use two mutually incompatible sets of FourCCs, so I'm not sure how it could be a good choice. At least unless we decide to pick a specific set of FourCC. It doesn't help that Windows/DirectX has its own set of FourCCs that's again slightly different than the two mentioned before. > > But the definition should be more specific than just "fourcc". Best > would be to explicitly list and define each format supported by the > spec. Why not be consistent with virtio-gpu and just define new formats as we add support for them as sequential integers? Best regards, Tomasz From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: virtio-dev-return-6522-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 342AF985ED9 for ; Tue, 17 Dec 2019 13:16:13 +0000 (UTC) MIME-Version: 1.0 References: <20191105191919.167345-1-dmitry.sepp@opensynergy.com> <20191120112929.gvsne7ykvcyw65lu@sirius.home.kraxel.org> <7736193.Whgddqjo8n@os-lin-dmo> <20191204091620.zpnd7jttkpkduort@sirius.home.kraxel.org> <20191216103236.ugjorzq5pntc7gtt@sirius.home.kraxel.org> In-Reply-To: <20191216103236.ugjorzq5pntc7gtt@sirius.home.kraxel.org> From: Tomasz Figa Date: Tue, 17 Dec 2019 22:15:56 +0900 Message-ID: Subject: Re: [virtio-dev] [RFC RESEND] virtio-video: Add virtio video device specification Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable To: Gerd Hoffmann Cc: Keiichi Watanabe , Dmitry Sepp , virtio-dev@lists.oasis-open.org, Linux Media Mailing List , Alexandre Courbot , Alex Lau , Dylan Reid , =?UTF-8?Q?St=C3=A9phane_Marchesin?= , Pawel Osciak , David Stevens , Hans Verkuil , Daniel Vetter List-ID: On Mon, Dec 16, 2019 at 7:32 PM Gerd Hoffmann wrote: > > Hi, > > > > Hmm, modern GPUs support both encoding and decoding ... > > > > Many SoC architectures have completely separate IP blocks for encoding > > and decoding. Similarly, in GPUs those are usually completely separate > > parts of the pipeline. > > In the OS there is one driver per GPU handling both ... > That's usually only the case for the desktop PC-style GPUs. That said, it probably doesn't matter from the protocol point of view how it's handled in the host. At least it is definitely safe to assume that the host provides functionality for independently decoding and encoding things from different processes, which is enough to implement virtio decoder and encoder as separate devices. > > > I don't think we should bake that restriction into the specification. > > > It probably makes sense to use one virtqueue per function though, tha= t > > > will simplify dispatching in both host and guest. > > > > > > > Wouldn't it make the handling easier if we had one virtio device per fu= nction? > > I don't think there is much of a difference between one device per > function and one virtqueue per function. You'll probably have a single > driver for both anyway, to share common code for buffer management etc. > The semantics of the encoder and decoder on the driver side, at least on Linux where V4L2 is used, are different enough for much of the code to be separated. That said, even with separate devices, the same driver can be instantiated multiple times, which is a common case in Linux, handled by the driver core. That basically gives us the ability to have as many instances of whatever function we want for free, without the need to explicitly handle multiple functions in one device in the driver. So that clearly equals simpler driver code. On the host side, the encode and decode APIs are different as well, so having separate implementation decoder and encoder, possibly just sharing some helper code, would make much more sense. > > > Use separate pixel_format (fourcc) and stream_format (H.264 etc.) enu= ms? > > > > I'd specifically avoid FourCC here, as it's very loosely defined and > > could introduce confusion. > > I don't think using fourcc is a problem, and given that both drm and > v4l2 use fourcc already this would be a good choice I think. Both DRM and V4L2 use two mutually incompatible sets of FourCCs, so I'm not sure how it could be a good choice. At least unless we decide to pick a specific set of FourCC. It doesn't help that Windows/DirectX has its own set of FourCCs that's again slightly different than the two mentioned before. > > But the definition should be more specific than just "fourcc". Best > would be to explicitly list and define each format supported by the > spec. Why not be consistent with virtio-gpu and just define new formats as we add support for them as sequential integers? Best regards, Tomasz --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org