From patchwork Wed Apr 24 13:46:47 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Daniel Vetter X-Patchwork-Id: 10914833 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 6CD1814DB for ; Wed, 24 Apr 2019 13:47:14 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 5C3FD288DC for ; Wed, 24 Apr 2019 13:47:14 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 4FFDB28A4B; Wed, 24 Apr 2019 13:47:14 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 977C8288DC for ; Wed, 24 Apr 2019 13:47:13 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 7F3E789100; Wed, 24 Apr 2019 13:47:11 +0000 (UTC) X-Original-To: dri-devel@lists.freedesktop.org Delivered-To: dri-devel@lists.freedesktop.org Received: from mail-ed1-x541.google.com (mail-ed1-x541.google.com [IPv6:2a00:1450:4864:20::541]) by gabe.freedesktop.org (Postfix) with ESMTPS id F2DD689100 for ; Wed, 24 Apr 2019 13:47:09 +0000 (UTC) Received: by mail-ed1-x541.google.com with SMTP id k45so15982350edb.6 for ; Wed, 24 Apr 2019 06:47:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=8WzxdHmeYM6gmEWNK99xAk/f0ttJexHC8q7eL1bCl9Q=; b=ovpXAwW7i4UfkiPVJ1Wd7dJInOH7j0IW9r7/7LeefjSji+DEOoxWrfiYoG2MBBxuT1 dnjB7DLIh2lqP5iDClGHeoxWlN/qCOwSOQwk7agXj8iMSzZiyARKGDuye8tOvGaGTQ/J yR8EL19TCekbqSVElb4aDYtX0EBLyFsLN0Nqe3H4+tap0Ed1Dilj2H+WuaiZgONepbmD 5l7i7rs6ndTcgMbSHmyEq2Clwu0h9fWLux7J4v4LlUybwyWko1rvByRkN/1A2h06l6f+ BII+pIAc+aGerxtcF58qx9+EQGF8lnT0b3at+3B39QYLCxFb7sMjbBYElDfZ5V5fAjN+ gI9w== X-Gm-Message-State: APjAAAUUsDfZym3wyq04q/Kqfzw9J+pBBSlG6yftm8sNmHKun0EdZEih Vx2erahm/Hs9clXwNLH+WkvH63qt2H0= X-Google-Smtp-Source: APXvYqz9g9hBCL5AC+aF1sGbbf3wcbYtXAcUfwcDv229xPZZu85Uj0G9OTSPL4ul4rR4wapQT/s/eQ== X-Received: by 2002:a50:9744:: with SMTP id d4mr19729913edb.125.1556113628360; Wed, 24 Apr 2019 06:47:08 -0700 (PDT) Received: from phenom.ffwll.local ([2a02:168:569e:0:3106:d637:d723:e855]) by smtp.gmail.com with ESMTPSA id i16sm132194ejh.79.2019.04.24.06.47.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Apr 2019 06:47:07 -0700 (PDT) From: Daniel Vetter To: DRI Development , Mesa Dev Subject: [PATCH] gpu/docs: Clarify what userspace means for gl Date: Wed, 24 Apr 2019 15:46:47 +0200 Message-Id: <20190424134647.9298-1-daniel.vetter@ffwll.ch> X-Mailer: git-send-email 2.20.1 MIME-Version: 1.0 X-Mailman-Original-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=8WzxdHmeYM6gmEWNK99xAk/f0ttJexHC8q7eL1bCl9Q=; b=f/FIDrBcW1jwLzbGmk8nStzItKuvOyWuvxJmVl1yjBiJiwQ8w/HUVMkO9X5d2ffhV8 v7JdSjx0NFJlRc5/MLIZ1TKIT/e5mrR2NEvhYrrns9OLR8PesbS7F38DSGS4jW6Cwwsp aOkna+oSF9JDm0OgMKhwsAPjUjBvLbSgNSLmA= X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: =?utf-8?b?SsOpcsO0bWUgR2xpc3Nl?= , Daniel Vetter , Karol Herbst , Kenneth Graunke , Ben Skeggs , Daniel Vetter , Sean Paul Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" X-Virus-Scanned: ClamAV using ClamSMTP Clear rules avoid arguing. Note that this just aims to document current expectations. If that shifts (e.g. because gl isn't the main api anymore, replaced by vk), then we need to update this text. I think it'd be good to have an equally solid list on the kms side. But kms is much more meant to be a standard, and the list of userspace projects we've accepted in the past is constantly shifting and adjusting. So I figured I'll leave that as an exercise for later on. v2: Try to clarify that we don't want a mesa driver just for mesa's sake, and more clearly exclude anything that just doesn't make sense technically. Example would be a compute driver that makes sense to be merged into drm (for kernel side code-sharing), but where the intended use is some single-source CUDA-style compute without ever bothering about any of the 3D/rendering side baggage that comes with gl/vk. v3: Drop vulkan for now, the situation there isn't as obviously clear-cut as on the gl side, and I don't want to tank this idea on a hot discussion about vk and mesa. Plus I think once we have 1-2 more vk drivers in mesa the situation on the vk side is clear-cut too, and we can do a follow-up patch to add vk to the list where we expect the userspace to be in upstream mesa. That's would give nice precedence to make it clear that this isn't cast in stone, but meant to reflect reality and should be adjusted as needed. v4: Fix typo. v5: Add a note to the commit message that this text needs to be updated when the situation changes. v6: Add a sentence why mesa will give the most meaningful review on gl stuff - it's a very active project with lots of developers. Acked-by: Dave Airlie (v4) Acked-by: Eric Anholt (v4) Acked-by: Alex Deucher (v5) Acked-by: Sean Paul (v5) Acked-by: Kenneth Graunke (v5) Acked-by: Karol Herbst (v5) Acked-by: Rob Clark Acked-by: Jérôme Glisse Acked-by: Bas Nieuwenhuizen Acked-by: Ben Skeggs Cc: Dave Airlie Cc: Eric Anholt Cc: Alex Deucher Cc: Sean Paul Cc: Kenneth Graunke Cc: Karol Herbst Cc: Rob Clark Cc: Jérôme Glisse Cc: Bas Nieuwenhuizen Cc: Ben Skeggs Signed-off-by: Daniel Vetter Acked-by: Dave Airlie (v4) Acked-by: Eric Anholt (v4) Acked-by: Alex Deucher (v5) Acked-by: Sean Paul (v5) Acked-by: Kenneth Graunke (v5) Acked-by: Karol Herbst (v5) Acked-by: Rob Clark Acked-by: Jérôme Glisse Acked-by: Bas Nieuwenhuizen Acked-by: Ben Skeggs Signed-off-by: Daniel Vetter --- I chatted with a pile of people in private, and there's clearly some solid support for this. But there's also some big concerns brought up by other people. The main one summed up is "what if everyone just ships vk, with a generic gl-on-vk like ANGLE?", but there's other concerns too. So all together I think this doesn't clear the bar of (almost) unanimous support which we need to make documentation actually help with clarifying what's expected. And if/when someone comes up with a more creative userspace approach for gl/vk we'll need to figure this all out with the time honored tradition of having a few massive threads on dri-devel :-) Hence this is more fyi as a guidance I guess, not a strict&hard rule. And I don't plan on merging this. Cheers, Daniel --- Documentation/gpu/drm-uapi.rst | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst index c9fd23efd957..0f767cfd5db6 100644 --- a/Documentation/gpu/drm-uapi.rst +++ b/Documentation/gpu/drm-uapi.rst @@ -105,6 +105,31 @@ is already rather painful for the DRM subsystem, with multiple different uAPIs for the same thing co-existing. If we add a few more complete mistakes into the mix every year it would be entirely unmanageable. +Below some clarifications what this means for specific areas in DRM. + +Compute&Rendering Userspace +--------------------------- + +Userspace API for enabling compute and rendering blocks which are capable of at +least supporting one of the OpenGL or OpenGL ES standards from Khronos need to +be enabled in the upstream `Mesa3D project`. + +Mesa3D is the canonical upstream for these areas because it is a fully +compliant, performant and cross-vendor implementation that supports all kernel +drivers in DRM. It is also an active project with plenty of developers who +can perform meaningful review. It is therefore the best platform to validate +userspace API and especially make sure that cross-vendor interoperation is +assured. + +Other userspace is only admissible if exposing a given feature through OpenGL or +OpenGL ES would result in a technically unsound design, incomplete driver or +an implementation which isn't useful in real world usage. + +Other areas, like media codec, which Mesa3D supports for just some drivers, but +isn't the clear universal choice, are excluded from this policy. Driver teams +are still encourage to aim for shared, cross-vendor infrastructure in userspace +as much as possible. + .. _drm_render_node: Render nodes