From patchwork Thu Feb 14 09:00:17 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Daniel Vetter X-Patchwork-Id: 10816581 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 DEA7A17D5 for ; Sat, 16 Feb 2019 20:13:11 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id CF4962AB54 for ; Sat, 16 Feb 2019 20:13:11 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id C3CF62AB6F; Sat, 16 Feb 2019 20:13:11 +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 42E3F2AB54 for ; Sat, 16 Feb 2019 20:13:11 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 386716E460; Sat, 16 Feb 2019 20:11:34 +0000 (UTC) X-Original-To: dri-devel@lists.freedesktop.org Delivered-To: dri-devel@lists.freedesktop.org Received: from mail-ed1-x544.google.com (mail-ed1-x544.google.com [IPv6:2a00:1450:4864:20::544]) by gabe.freedesktop.org (Postfix) with ESMTPS id E32DD6E38E for ; Thu, 14 Feb 2019 09:00:35 +0000 (UTC) Received: by mail-ed1-x544.google.com with SMTP id 10so4353728eds.7 for ; Thu, 14 Feb 2019 01:00:35 -0800 (PST) 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=ri0/kHCI1A4RMTXnhThP7QQZbXjas4bvIfkS/cIgbg0=; b=dPw9pyg2k5gIRW9Hn20NiBm117eK72EomNbjvnPimCzuUZ3ru+R1BVocjqnoyzwjnw saLAub0O//kg7GGf2Kigs3dU0tJwdltMqLP39Aip/OBwt/f5MXpvSGyfsl6OVxTGSWG+ czsm1WBG1u1FIDCvTP50vU1fl8FKqQDSSHB2pvvICALWyel/Eb8/QxiiUCxwhPKOoAzC wuXBhkYW4CK0iCGWhlKwP9AtNZZWe/8sr738HI/F04jVXQqdl6S25s+pNTjbJ/lI+8eU 6W1eCbLIA3qTq7s+4ziQkyk2KMEW3ulu187oJ/J/mZvHv5tCGRhyYM2DTrQd5Wje39Fq PSYQ== X-Gm-Message-State: AHQUAubF8/8F3cYbx/fjBKpmugoTJ1SWNwy+Xh5ITCifzRyuxb6yUJDo XzlFAzeT2vj4cFT0F+5S9v2nu7SAbCLKfQ== X-Google-Smtp-Source: AHgI3Ia8+8aJAdGWyHm+7kLlRPTY05k1ANZSDCw6kRBetOyiPct7guisFTKLxX9rBEN1iVA4AR7fJg== X-Received: by 2002:a17:906:f90:: with SMTP id q16mr372652ejj.224.1550134833003; Thu, 14 Feb 2019 01:00:33 -0800 (PST) Received: from phenom.ffwll.local ([2a02:168:569e:0:3106:d637:d723:e855]) by smtp.gmail.com with ESMTPSA id p36sm517123edc.78.2019.02.14.01.00.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Feb 2019 01:00:26 -0800 (PST) From: Daniel Vetter To: DRI Development , Mesa Dev Subject: [RFC] gpu/docs: Clarify what userspace means for gl Date: Thu, 14 Feb 2019 10:00:17 +0100 Message-Id: <20190214090017.29348-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=ri0/kHCI1A4RMTXnhThP7QQZbXjas4bvIfkS/cIgbg0=; b=OmypYS98BwRFyPIGL84VN2spuu/dvmbaqZGt0m7QwkEKfd4cfowz5Z21pgnVh6e6by t1F8ztmWSESHlP0cNCF+MTLjae6FlI7mhNzpWCKpEHoczMIm5+1ZVPwa+WKYl+hrCgc1 Ma79wxn/G2k0lAJR8UcQ1SuEqqBUNj8brFkCA= 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: Daniel Vetter , Daniel Vetter Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" X-Virus-Scanned: ClamAV using ClamSMTP Clear rules avoid arguing. 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. Signed-off-by: Daniel Vetter --- Hi all, I discussed this a bit with a few people over the past few months (I think), to get a feel for where the consensus might be. Goal here isn't anything aspirational (like with the recent igt patch), but just documented current expectations, so that there's no confusion or companies with failed projects that had no reason to fail. Same reasons really like for the patch to document open source userspace requirements a few years ago, that one is still extremely useful. For obvious reasons needs solid support from both mesa and kernel people, or it won't land. Thoughts, hot takes, comments, also acks all very much welcome. Thanks, Daniel --- Documentation/gpu/drm-uapi.rst | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst index c9fd23efd957..79f78c3fa458 100644 --- a/Documentation/gpu/drm-uapi.rst +++ b/Documentation/gpu/drm-uapi.rst @@ -105,6 +105,29 @@ 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 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 +otherwise 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