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=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 AF4E2C282CE for ; Tue, 4 Jun 2019 09:05:32 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 82C3F24A11 for ; Tue, 4 Jun 2019 09:05:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726982AbfFDJFc (ORCPT ); Tue, 4 Jun 2019 05:05:32 -0400 Received: from bhuna.collabora.co.uk ([46.235.227.227]:40888 "EHLO bhuna.collabora.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726965AbfFDJFb (ORCPT ); Tue, 4 Jun 2019 05:05:31 -0400 Received: from localhost (unknown [IPv6:2a01:e0a:2c:6930:5cf4:84a1:2763:fe0d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: bbrezillon) by bhuna.collabora.co.uk (Postfix) with ESMTPSA id 839D9260D64; Tue, 4 Jun 2019 10:05:30 +0100 (BST) Date: Tue, 4 Jun 2019 11:05:27 +0200 From: Boris Brezillon To: Thierry Reding Cc: Nicolas Dufresne , Paul Kocialkowski , Linux Media Mailing List , Hans Verkuil , Tomasz Figa , Alexandre Courbot , Maxime Ripard , Jernej Skrabec , Ezequiel Garcia , Jonas Karlman Subject: Re: Proposed updates and guidelines for MPEG-2, H.264 and H.265 stateless support Message-ID: <20190604110527.48d16907@collabora.com> In-Reply-To: <20190604085503.GE9048@ulmo> References: <0be542fabc57c38596bdb1db44aead7054a89158.camel@bootlin.com> <20190603112449.GA30132@ulmo> <20190604085503.GE9048@ulmo> Organization: Collabora X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org On Tue, 4 Jun 2019 10:55:03 +0200 Thierry Reding wrote: > On Mon, Jun 03, 2019 at 02:52:44PM -0400, Nicolas Dufresne wrote: > [...] > > There is one thing that come up though, if we enable per-frame decoding > > on top of per-slice decoder (like Cedrus), won't we force userspace to > > always compute l0/l1 even though the HW might be handling that ? Shall > > we instead pass the modification list and implement the non-parsing > > bits of applying the modifications in the kernel ? > > Applying the modifications is a standard procedure, right? If it's > completely driver-agnostic, it sounds to me like the right place to > perform the operation is in userspace. Well, the counter argument to that is "drivers know better what's needed by the HW", and if we want to avoid doing useless work without having complex caps checking done in userspace, doing this task kenel-side makes sense.