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=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 607F6C48BE8 for ; Wed, 16 Jun 2021 20:39:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 3F0C6613C1 for ; Wed, 16 Jun 2021 20:39:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233606AbhFPUl5 (ORCPT ); Wed, 16 Jun 2021 16:41:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52118 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233560AbhFPUl4 (ORCPT ); Wed, 16 Jun 2021 16:41:56 -0400 Received: from mail-oo1-xc33.google.com (mail-oo1-xc33.google.com [IPv6:2607:f8b0:4864:20::c33]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 38C8DC061574 for ; Wed, 16 Jun 2021 13:39:50 -0700 (PDT) Received: by mail-oo1-xc33.google.com with SMTP id b24-20020a4a34180000b029024b199e7d4dso694506ooa.4 for ; Wed, 16 Jun 2021 13:39:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lMcYalmCAHylGdhbg1IVp3Bs2x8m0iHlc/lzRXUM0HU=; b=htoR91a3QnMRSu6n34Lez7gNPl5jTDFDopua7XbvonDZMTt0D1/rpVqdZZ3esJ2kLC FALEJvTCoI49RoBJFWwAjdVho4tEu59KBmWww0r39Mi42xLCdXCd4i6bU00GeTaMFl0L N/TxuTnsj+lK1DJR61Lm8nkI0DHDruodZ/qA4= 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=lMcYalmCAHylGdhbg1IVp3Bs2x8m0iHlc/lzRXUM0HU=; b=OWmNX3WjVA07iW+jnu5BakYE/D5dKixtln/dsgr7RX+Af/WAo/oRgxeWqrM2RKu7te gtGYREYdnk4RWFOXyMnGktjt597BO3TU6vkM/2JQaALFyTF7GpM58GU4n8hXgNjcxKcG ooBCbIiSKkzwLvpEYUrM84V107mHSg45Otim/laTPohGZT2jFUeBuxrOPvHg+kZdBVdC bZbxLaj+SaGntn0i5Wdg52BKxSMXQNVrWwrESUudfY4SpDwUD5MT0VLU8ynbD7+hDOCJ Qhz2scKbt2s9MDS4Lw2059GGTucyN+PGY5v9WtoR9LjY2wUt5jL2f14gh0yOrnzzdywm PgYw== X-Gm-Message-State: AOAM530iODHmr62rmZxBnlcriqzCj8vV1SCQ0gyUNV3Kzy4asSfFYGfp QLQX4rCCgzptR1ZGvbiSrqMEyMgoqhq9gsKFmpwSHg== X-Google-Smtp-Source: ABdhPJwDD/zT6kJIKvO4ayePA1R6nD7IZD+SzvyTh12qM5egyqQSXfFOwPMoWgmByXCoF0ISXyZzGIwha/OsCv8QQh4= X-Received: by 2002:a4a:8802:: with SMTP id d2mr1538686ooi.28.1623875989469; Wed, 16 Jun 2021 13:39:49 -0700 (PDT) MIME-Version: 1.0 References: <20210610174731.1209188-1-maxime@cerno.tech> <20210611120309.2b5eb4htupv5ss32@e110455-lin.cambridge.arm.com> <20210614174912.15a49336@eldfell> <20210614152413.nguqia3s4tlowio4@e110455-lin.cambridge.arm.com> <20210615100335.0b8f96d5@eldfell> <20210615131656.2ecefdc4@eldfell> In-Reply-To: From: Daniel Vetter Date: Wed, 16 Jun 2021 22:39:36 +0200 Message-ID: Subject: Re: [PATCH v3] Documentation: gpu: Mention the requirements for new properties To: Simon Ser Cc: Pekka Paalanen , Laurent Pinchart , Liviu Dudau , Haneen Mohammed , Alexandre Belloni , Linux Doc Mailing List , Xinliang Liu , Edmund Dea , Alexandre Torgue , dri-devel , Russell King , Melissa Wen , Tomi Valkeinen , Thierry Reding , Benjamin Gaignard , Anitha Chrisanthus , Daniel Vetter , Steven Price , Sam Ravnborg , Jyri Sarha , Jerome Brunet , Marek Vasut , Joonyoung Shim , Qiang Yu , Krzysztof Kozlowski , Kevin Hilman , Neil Armstrong , Alyssa Rosenzweig , Xinwei Kong , Jonathan Hunter , David Airlie , Ludovic Desroches , Kieran Bingham , VMware Graphics , NXP Linux Team , Ben Skeggs , Chun-Kuang Hu , Maxime Coquelin , Jonas Karlman , Martin Blumenstingl , Chen Feng , Sascha Hauer , Alison Wang , Roland Scheidegger , Andrzej Hajda , Hans de Goede , Maxime Ripard , Rodrigo Vivi , Matthias Brugger , Nicolas Ferre , Chen-Yu Tsai , Sean Paul , Thomas Zimmermann , Paul Cercueil , Jernej Skrabec , Rodrigo Siqueira , Hyun Kwon , Boris Brezillon , Andrew Jeffery , Huang Rui , Yannick Fertr e , Jonathan Corbet , Seung-Woo Kim , Sandy Huang , Robert Foss , Joel Stanley , Tomeu Vizoso , Kyungmin Park , =?UTF-8?Q?Noralf_Tr=C3=B8nnes?= , Philippe Cornu , Pengutronix Kernel Team , Alex Deucher , Tian Tao , Oleksandr Andrushchenko , Shawn Guo , =?UTF-8?Q?Christian_K=C3=B6nig?= , Gerd Hoffmann Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org On Tue, Jun 15, 2021 at 2:09 PM Simon Ser wrote: > > On Tuesday, June 15th, 2021 at 12:16, Pekka Paalanen wrote: > > > Good reminder about CRCs. CRCs have zero tolerance, so they are not > > useful for testing properties that have any leeway, are they? > > IIRC, IGT's alpha blending test currently computes the CRC for all > possible roundings, then checks that the hw returns one of the > acceptable CRCs. > > With more complex color management properties, this approach might not > be possible and write-back support in hw drivers would really help. Yeah CRC based tests have severe limits, and even if you only try to test the extreme stuff there's enough busted hw out there that they will fail. E.g. when scaling I'm sure there's hw that bleeds in pixels from outside the bounding box and can't be fixed, or there's some intel hw where the alpha blending gets the mapping between [0, 0xff] <-> [0.0, 1.0] and you get a nice faint ghost instead of full transparency or opaqueness. I think for those broken hw is just broken, nothing we can do. Also writeback isn't supported by enough display hw, and not everyone has access to chamelium or similar. I think best we can do is that relevant igt have an interactive mode (built-in for crc tests, so you can pause and look at the screen) and then perhaps compare with the vkms reference implementation manually. That's not great, and vkms is also not anywhere near close enough for this either (and like currently you can't even look at it, we'd first need a v4l output mode). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch 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=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED 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 C967FC48BE6 for ; Wed, 16 Jun 2021 20:39:51 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (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 2EE6961076 for ; Wed, 16 Jun 2021 20:39:51 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2EE6961076 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ffwll.ch Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id AEF286E05D; Wed, 16 Jun 2021 20:39:50 +0000 (UTC) Received: from mail-oo1-xc36.google.com (mail-oo1-xc36.google.com [IPv6:2607:f8b0:4864:20::c36]) by gabe.freedesktop.org (Postfix) with ESMTPS id 311F46E05D for ; Wed, 16 Jun 2021 20:39:50 +0000 (UTC) Received: by mail-oo1-xc36.google.com with SMTP id i8-20020a4aa1080000b0290201edd785e7so1033877ool.1 for ; Wed, 16 Jun 2021 13:39:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lMcYalmCAHylGdhbg1IVp3Bs2x8m0iHlc/lzRXUM0HU=; b=htoR91a3QnMRSu6n34Lez7gNPl5jTDFDopua7XbvonDZMTt0D1/rpVqdZZ3esJ2kLC FALEJvTCoI49RoBJFWwAjdVho4tEu59KBmWww0r39Mi42xLCdXCd4i6bU00GeTaMFl0L N/TxuTnsj+lK1DJR61Lm8nkI0DHDruodZ/qA4= 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=lMcYalmCAHylGdhbg1IVp3Bs2x8m0iHlc/lzRXUM0HU=; b=jREpX4oKoHl720DW6lO2Hb4oEW6inXDjk5DQfy8ydxswXcm+j0EUOzVK2Uks1ITMIY O9O9PYREuCjqatNQvr83AfEXwCX07+rO3B/XmfufSIqA9b2Ydpo0vn4Skr/wPiOCNTPc mz/Qjc1fnJxVzhQTZ2sBDpCTTAUv7cUjWDXQMJ246knWkwkXOcxxbvwPqYX1btBUIzBp FkOxRskso4J6YnbbKwLtpeIIqc/oqugsaWOF6kSYWO4idD9p8b/ltcQGRfcFBuVrNNQH Gn6PwlKLJn4fAn2R+5itihSBslZMbIS2GabeBF8Ec6bAkmfRvBDLDBa7QpAK0GWY6gAw C5zA== X-Gm-Message-State: AOAM532iFDlVr+fR+fdi5RjIRyLinU6LFE5TKhsbY1/cfQR6dlxB2Ot2 c9hu/T1DnR+HsrIOLDPPTy+ubk2zIrTTlEmXXTd9uw== X-Google-Smtp-Source: ABdhPJwDD/zT6kJIKvO4ayePA1R6nD7IZD+SzvyTh12qM5egyqQSXfFOwPMoWgmByXCoF0ISXyZzGIwha/OsCv8QQh4= X-Received: by 2002:a4a:8802:: with SMTP id d2mr1538686ooi.28.1623875989469; Wed, 16 Jun 2021 13:39:49 -0700 (PDT) MIME-Version: 1.0 References: <20210610174731.1209188-1-maxime@cerno.tech> <20210611120309.2b5eb4htupv5ss32@e110455-lin.cambridge.arm.com> <20210614174912.15a49336@eldfell> <20210614152413.nguqia3s4tlowio4@e110455-lin.cambridge.arm.com> <20210615100335.0b8f96d5@eldfell> <20210615131656.2ecefdc4@eldfell> In-Reply-To: From: Daniel Vetter Date: Wed, 16 Jun 2021 22:39:36 +0200 Message-ID: Subject: Re: [PATCH v3] Documentation: gpu: Mention the requirements for new properties To: Simon Ser Content-Type: text/plain; charset="UTF-8" X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Ludovic Desroches , Haneen Mohammed , Alexandre Belloni , Linux Doc Mailing List , Xinliang Liu , Edmund Dea , Alexandre Torgue , dri-devel , Sandy Huang , Melissa Wen , Andrzej Hajda , Thierry Reding , Laurent Pinchart , Benjamin Gaignard , Anitha Chrisanthus , Daniel Vetter , Jonathan Hunter , Sam Ravnborg , Jerome Brunet , Marek Vasut , Jonathan Corbet , Joonyoung Shim , Krzysztof Kozlowski , Kevin Hilman , Neil Armstrong , Russell King , Steven Price , David Airlie , Xinwei Kong , =?UTF-8?Q?Noralf_Tr=C3=B8nnes?= , VMware Graphics , Alyssa Rosenzweig , Chen Feng , Hyun Kwon , NXP Linux Team , Chun-Kuang Hu , Thomas Zimmermann , Jonas Karlman , Martin Blumenstingl , Liviu Dudau , Sascha Hauer , Alison Wang , Roland Scheidegger , Shawn Guo , Ben Skeggs , Maxime Ripard , Rodrigo Vivi , Matthias Brugger , Chen-Yu Tsai , Sean Paul , Pengutronix Kernel Team , Paul Cercueil , Jernej Skrabec , Rodrigo Siqueira , Tomi Valkeinen , Hans de Goede , Andrew Jeffery , Huang Rui , Yannick Fertr e , Boris Brezillon , Seung-Woo Kim , Nicolas Ferre , Robert Foss , Joel Stanley , Tomeu Vizoso , Kyungmin Park , Kieran Bingham , Qiang Yu , Maxime Coquelin , Alex Deucher , Tian Tao , Oleksandr Andrushchenko , Philippe Cornu , Jyri Sarha , =?UTF-8?Q?Christian_K=C3=B6nig?= , Gerd Hoffmann Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Tue, Jun 15, 2021 at 2:09 PM Simon Ser wrote: > > On Tuesday, June 15th, 2021 at 12:16, Pekka Paalanen wrote: > > > Good reminder about CRCs. CRCs have zero tolerance, so they are not > > useful for testing properties that have any leeway, are they? > > IIRC, IGT's alpha blending test currently computes the CRC for all > possible roundings, then checks that the hw returns one of the > acceptable CRCs. > > With more complex color management properties, this approach might not > be possible and write-back support in hw drivers would really help. Yeah CRC based tests have severe limits, and even if you only try to test the extreme stuff there's enough busted hw out there that they will fail. E.g. when scaling I'm sure there's hw that bleeds in pixels from outside the bounding box and can't be fixed, or there's some intel hw where the alpha blending gets the mapping between [0, 0xff] <-> [0.0, 1.0] and you get a nice faint ghost instead of full transparency or opaqueness. I think for those broken hw is just broken, nothing we can do. Also writeback isn't supported by enough display hw, and not everyone has access to chamelium or similar. I think best we can do is that relevant igt have an interactive mode (built-in for crc tests, so you can pause and look at the screen) and then perhaps compare with the vkms reference implementation manually. That's not great, and vkms is also not anywhere near close enough for this either (and like currently you can't even look at it, we'd first need a v4l output mode). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch