From patchwork Wed Apr 5 19:52:05 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: "Vivi, Rodrigo" X-Patchwork-Id: 13202393 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org 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 smtp.lore.kernel.org (Postfix) with ESMTPS id B21A9C76188 for ; Wed, 5 Apr 2023 19:52:41 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 0C77610E09B; Wed, 5 Apr 2023 19:52:41 +0000 (UTC) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by gabe.freedesktop.org (Postfix) with ESMTPS id 7D7EA10E09B for ; Wed, 5 Apr 2023 19:52:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1680724359; x=1712260359; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=hKpMugnT5uVzfbJUAjrYfWd+lsdG3X180eUjeVjgHhA=; b=L6Owq5xqGfKGstRs9HQ+Mg221LfHEUmtwrll6BNg5s/9Dsk6y6z3acZg 0yuD4OM7JVplA0rCN2Ccv5adOthiGxr1bDG49CMp+l6lIRyh6Ujwpzrct 5ao96etojGGvc7dr+Ba8RkQqrMT+XnHIAGp2IOdSIIGlyRAehRP1nOxQU UQ8+lynk5Kgm1WDlM5Bm2nZbJV4jwi1db1dZcLd4aW+9T417z3bVXt2RN Qzb5XipGYJk3tVsmsrTw5aCuar9/UZ6DFnydFmhSsO5fC3a6BaL84wLlA 9gPkVQ987j9ILS8vVHh3iUUHVLdn6O09DHu8g82hwsroPybtwSqEfymyS A==; X-IronPort-AV: E=McAfee;i="6600,9927,10671"; a="370382683" X-IronPort-AV: E=Sophos;i="5.98,321,1673942400"; d="scan'208";a="370382683" Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Apr 2023 12:52:38 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10671"; a="932946952" X-IronPort-AV: E=Sophos;i="5.98,321,1673942400"; d="scan'208";a="932946952" Received: from orsmsx603.amr.corp.intel.com ([10.22.229.16]) by fmsmga006.fm.intel.com with ESMTP; 05 Apr 2023 12:52:38 -0700 Received: from orsmsx610.amr.corp.intel.com (10.22.229.23) by ORSMSX603.amr.corp.intel.com (10.22.229.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.21; Wed, 5 Apr 2023 12:52:38 -0700 Received: from ORSEDG602.ED.cps.intel.com (10.7.248.7) by orsmsx610.amr.corp.intel.com (10.22.229.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.21 via Frontend Transport; Wed, 5 Apr 2023 12:52:38 -0700 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (104.47.57.176) by edgegateway.intel.com (134.134.137.103) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.21; Wed, 5 Apr 2023 12:52:36 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ha9YijR08xvghXHY5T53Z8IVpdj+03GU5u2F+fNyxEix8gVSHnXjD5cJAFjv3uNSKJOGvNK4s4ghrYqKdbtNnMnrlUajuPAPZcHNCAtqDGj5ME9kJTN+mrQHKF1bTFgBoKZQFxQ4NRdyE21a0iszJPuoqUuobOciXYCCOwS31pC6CXcMZsBthhkrKy58M71aWsqldFAACyKbrmQJCngV9v5nyABQN4bPRPCUY+BrWMi8fAt+SeNPGGW+5FYCAjtBakP81bMjtZU4BcLgp0jI/DkggYs7nuDow3+EbZsVfOyXpqujj0A6pTula62blOX4fReUPzcTjaG2vjGMyjSkZA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=YxNwj+kBue1tvc/WZpc8JCjE8iWBEqprQ7vbvD0DZzk=; b=D+Xs5bDLGJGGtXLyUJmkDpaS5eKoknC0UUWvbuD/jDJeXfHVLdL/od2b88xemh4TF/b4kE4ED2eNZgNh4TvYcEy5qMuDcSZGEUXHoSgc55K9bz1/yIkO3Ff4eS1LdcmGt5UsjCJeJWgi0sASwXLfKt+PT1pMaxEYrSsFZ0OiT5E8UOusUvRDCr1Gden3n0C2srXCY/V/QZ8KVuEcEN1GCrAIU619XK1ZTKTTcHdFbjEYAYY9XdSKN8ecfRWd7/m6DPWTmxGKHeEj/xRZKwcD4anoSDTp8UvUVP0m/1v1ZLKwP8OfmIg35rX3spOrGEy7psRlnwmwsJel63u5Y5Hs3g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; Received: from MN0PR11MB6059.namprd11.prod.outlook.com (2603:10b6:208:377::9) by SA0PR11MB4621.namprd11.prod.outlook.com (2603:10b6:806:72::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6254.35; Wed, 5 Apr 2023 19:52:29 +0000 Received: from MN0PR11MB6059.namprd11.prod.outlook.com ([fe80::2b57:646c:1b01:cd18]) by MN0PR11MB6059.namprd11.prod.outlook.com ([fe80::2b57:646c:1b01:cd18%9]) with mapi id 15.20.6254.033; Wed, 5 Apr 2023 19:52:29 +0000 From: Rodrigo Vivi To: Subject: [PATCH] drm/doc/rfc: Introduce the merge plan for the Xe driver. Date: Wed, 5 Apr 2023 15:52:05 -0400 Message-ID: <20230405195205.1674844-1-rodrigo.vivi@intel.com> X-Mailer: git-send-email 2.39.2 X-ClientProxiedBy: SJ0PR03CA0246.namprd03.prod.outlook.com (2603:10b6:a03:3a0::11) To MN0PR11MB6059.namprd11.prod.outlook.com (2603:10b6:208:377::9) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MN0PR11MB6059:EE_|SA0PR11MB4621:EE_ X-MS-Office365-Filtering-Correlation-Id: 8b87838d-b43e-40f1-26ad-08db360f49ca X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: ni21Gxt5WWzRCgR55wz78vjAdYy98pOB1hldbzCPeB0pqEWoKuZaIm5t7E/5hXZGpzJikv089bJoR4r3hXSV/EoEYzeTonuOt2Ajn9b7m/kxY3agULKIQ6GGWNZ1TP7i8o+D8R0hix0fy04eW6mVQ2hTu1VxGwGutjilBtTPKvDQPTE4f7rR4in7YNQW2XFbickBmIFiJtbENcAA0cg/XmC4+/95VnumKV2OZRF26vApq5UBbaWN0B1iDo0uhJixuE9/w5BUh9z/LclNsGZRZCJ78n9FXT9wYPSeacNzRewvOPDB3N3O5sE3zZVCgev8yqm3QGH+NqjCdMY8d9gEhE+CAsO8abMe4+T4W6CiPXy0ZRIeJkrMPyCzUaaHdrjwI2VXyNjIIlgEg8XQxpOkqaME+MtdKyoI293iWG6P0swZYuazjmhsfUlX6JxNjGRBNtGft9iKnzF9v3iJmncSe0s2vLsjlfTLeFPBpiOJHkpjCdbKPi9tqk/lBR1hGgrD X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN0PR11MB6059.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230028)(366004)(39860400002)(376002)(346002)(396003)(136003)(451199021)(6666004)(66574015)(2616005)(83380400001)(66899021)(186003)(26005)(6506007)(1076003)(6512007)(4326008)(66556008)(66476007)(8676002)(6916009)(38100700002)(66946007)(2906002)(44832011)(82960400001)(41300700001)(86362001)(316002)(54906003)(478600001)(5660300002)(8936002)(30864003)(966005)(6486002)(36756003); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?q?1K5S4Ne81zS0Tb7/7bhost6PZ7K4?= =?utf-8?q?06nBpg+0mDl3KY8mTKq6+hNzPfWU/Rn+/56NztM2RBZrCS89PyBoYTfqb6G2QgSxy?= =?utf-8?q?GfgTjxrMbWLezJfpq82Exs5FbWBcbqiWHftwRG6OIHAklLbdhFDTYay1irciV2VST?= =?utf-8?q?Ce1frR94Z3YGtTXGPkDLuGOelcxDSNn8wfqgqelMDBgT1XtWpPqNkCSPLDAhyIH1M?= =?utf-8?q?ZfWr3dePtZktIIRwt0vc6+lKcYiGMN8XWvfFYsKjBciTYHWxD4EKpPg71DTNGXN/5?= =?utf-8?q?xuYhzscs0YUJivcDRlUhPwn+0ut5jqpn6wSacrXeX/J1e/OEMj1INCmaWH31xs4Pe?= =?utf-8?q?AFSgyIS2eOnYddklg1E4bv4TpW+u0jxDyb6lLNsNrNi3m2XgDsxa/pELsVtOtm665?= =?utf-8?q?G/lbJDmlnMmgKHKZIxFlzyFSH4IOKyTSbg1vy6kMZYjwLqIoymypVaWwjlikkQ0Xs?= =?utf-8?q?oFjgJ0dv4CDdg6Ne2UD5/97VoPz73Smv5WYTYc6VBDJDQEeGpb94pPZik6La3DstJ?= =?utf-8?q?czno8dI0JU37RkWiVnSYVQKAx8so6UcN8vjJ4I5H6phTs41URt4YuDYPYhHG7TpYq?= =?utf-8?q?kCGNDd+0YmlpAOCcBZ2A6JxQltfG++L/nJ22leM1iYSJ51IOsiJOFn7aKEeQm+UGj?= =?utf-8?q?ZZJzXTbSHjtYfKs5JaTsSLakbyEMjUNdU8GrtKB0AwniejRo4BCxstRjFA61dfJaQ?= =?utf-8?q?/EJiFylbNN/sYSml0+uJ4mzfc0f7egWwnjhaKLiLeChUE8e8mvtQqJQ6qDa9LIBwA?= =?utf-8?q?OS1Pr9zk6j6hj3aCbpV+55QqIIv7aLKxVU6jKhpjKz4Rn4bYNd5gRblM7B4GJDRkO?= =?utf-8?q?mK/qF5AzNmMUzbNeGKCC2BFMEXNToe9Ny3xbOca+6pHEHB9UzMsDgVn/JhjaZaSVq?= =?utf-8?q?v2i42TFl1M32A9zBTPHZsn09jUiXvS4wuDePgfkJYv9WmROVbaJo5Vutkk4yto4rz?= =?utf-8?q?iLKhwdiB0kCED81sAfYaOyyWu2bpt2DwwJHMos1RuIZjda2b6JElIYvoh96WnBTXE?= =?utf-8?q?CubOuYYi4umDQ4ZUBsVFiBoffKO8o2u4iqh3UHxuykrFIwup4x69PL/0v0SbDycbg?= =?utf-8?q?Jh3vjXer9m+kZ0lbrmgpPUXvKotdAlO6AYwusdLg5mXHxU0moNBw966Sh9vZz45O6?= =?utf-8?q?qxbikXAO2oY1XhsJj2X+Cpan/gKkL2LBw/hHobIgO9VDrIS9P5Zmo9vXZ0IPU9EZ7?= =?utf-8?q?pQOU1UBvK0nHvc2GJFTaDyEP3h6jICiYdd4azj5m0P2cM1h3lqADsie261gKJrV3F?= =?utf-8?q?ln2lVb9QBo/0jRfgzfaVPJaVQL9FJKk3y4w8V2Mxgi0Mkn7F8t9QUxGR7B/wDFeUS?= =?utf-8?q?zhnbOz+hSC+00oifZyahItbF7li6sdBySZosSExDmLzbfHEhApb2AJogdrh02kkHj?= =?utf-8?q?PASc75KIyaZCWdZyXnZfuaO8k/3C+hCG58l4C90bbzrCRHKjgMjXV5tAVaQniC0e1?= =?utf-8?q?haMwSr2ZkEx0adCBUNJDGyL21qQ3Ml8O0m9GAu4L2OF0txyKAXEylwqCLMaFuamvS?= =?utf-8?q?Yad9iCnld4Wg?= X-MS-Exchange-CrossTenant-Network-Message-Id: 8b87838d-b43e-40f1-26ad-08db360f49ca X-MS-Exchange-CrossTenant-AuthSource: MN0PR11MB6059.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Apr 2023 19:52:29.6052 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 5MDreBLEQy8h5wX42Tgruh93RJg2FKB7YQEhLyAVhrt5w1QBzgmM5biu9svR0+/L8pXwlNMbWGb4fUFkLJ+i5g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR11MB4621 X-OriginatorOrg: intel.com 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: Matthew Brost , =?utf-8?q?Thomas_Hellstr=C3=B6m?= , Daniel Vetter , Oded Gabbay , Francois Dugast , Rodrigo Vivi , Dave Airlie , Luis Strano Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" Let’s establish a merge plan for Xe, by writing down clear pre-merge goals, in order to avoid unnecessary delays. This initial document starts with a TODO list containing items with clear and measurable key results. Xe’s initial pull request should only be sent to dri-devel after all the items are clearly resolved. Since many of them involve some level of a community consensus, in many cases, the consensus will be reached in follow-up patches to this document with more details of the API or helpers that will be developed or modified. Cc: Dave Airlie Cc: Daniel Vetter Cc: Oded Gabbay Signed-off-by: Rodrigo Vivi Signed-off-by: Francois Dugast Signed-off-by: Luis Strano Signed-off-by: Matthew Brost Signed-off-by: Thomas Hellström Signed-off-by: Maarten Lankhorst --- Documentation/gpu/rfc/index.rst | 4 + Documentation/gpu/rfc/xe.rst | 216 ++++++++++++++++++++++++++++++++ 2 files changed, 220 insertions(+) create mode 100644 Documentation/gpu/rfc/xe.rst diff --git a/Documentation/gpu/rfc/index.rst b/Documentation/gpu/rfc/index.rst index 476719771eef..e4f7b005138d 100644 --- a/Documentation/gpu/rfc/index.rst +++ b/Documentation/gpu/rfc/index.rst @@ -31,3 +31,7 @@ host such documentation: .. toctree:: i915_vm_bind.rst + +.. toctree:: + + xe.rst diff --git a/Documentation/gpu/rfc/xe.rst b/Documentation/gpu/rfc/xe.rst new file mode 100644 index 000000000000..1e3e7e9c67c3 --- /dev/null +++ b/Documentation/gpu/rfc/xe.rst @@ -0,0 +1,216 @@ +========================== +Xe – Merge Acceptance Plan +========================== +Xe is a new driver for Intel GPUs that supports both integrated and +discrete platforms starting with Tiger Lake (first Intel Xe Architecture). + +This document aims to establish a merge plan for the Xe, by writing down clear +pre-merge goals, in order to avoid unnecessary delays. + +Xe – Overview +============= +The main motivation of Xe is to have a fresh base to work from that is +unencumbered by older platforms, whilst also taking the opportunity to +rearchitect our driver to increase sharing across the drm subsystem, both +leveraging and allowing us to contribute more towards other shared components +like TTM and drm/scheduler. + +This is also an opportunity to start from the beginning with a clean uAPI that is +extensible by design and already aligned with the modern userspace needs. For +this reason, the memory model is solely based on GPU Virtual Address space +bind/unbind (‘VM_BIND’) of GEM buffer objects (BOs) and execution only supporting +explicit synchronization. With persistent mapping across the execution, the +userspace does not need to provide a list of all required mappings during each +submission. + +The new driver leverages a lot from i915. As for display, the intent is to share +the display code with the i915 driver so that there is maximum reuse there. + +As for the power management area, the goal is to have a much-simplified support +for the system suspend states (S-states), PCI device suspend states (D-states), +GPU/Render suspend states (R-states) and frequency management. It should leverage +as much as possible all the existent PCI-subsystem infrastructure (pm and +runtime_pm) and underlying firmware components such PCODE and GuC for the power +states and frequency decisions. + +Repository: + +https://gitlab.freedesktop.org/drm/xe/kernel (branch drm-xe-next) + +Xe – Platforms +============== +Currently, Xe is already functional and has experimental support for multiple +platforms starting from Tiger Lake, with initial support in userspace implemented +in Mesa (for Iris and Anv, our OpenGL and Vulkan drivers), as well as in NEO +(for OpenCL and Level0). + +During a transition period, platforms will be supported by both Xe and i915. +However, the force_probe mechanism existent in both drivers will allow only one +official and by-default probe at a given time. + +For instance, in order to probe a DG2 which PCI ID is 0x5690 by Xe instead of +i915, the following set of parameters need to be used: + +``` +i915.force_probe=!5690 xe.force_probe=5690 +``` + +In both drivers, the ‘.require_force_probe’ protection forces the user to use the +force_probe parameter while the driver is under development. This protection is +only removed when the support for the platform and the uAPI are stable. Stability +which needs to be demonstrated by CI results. + +In order to avoid user space regressions, i915 will continue to support all the +current platforms that are already out of this protection. Xe support will be +forever experimental and dependent on the usage of force_probe for these +platforms. + +When the time comes for Xe, the protection will be lifted on Xe and kept in i915. + +Xe driver will be protected with both STAGING Kconfig and force_probe. Changes in +the uAPI are expected while the driver is behind these protections. STAGING will +be removed when the driver uAPI gets to a mature state where we can guarantee the +‘no regression’ rule. Then force_probe will be lifted only for future platforms +that will be productized with Xe driver, but not with i915. + +Xe – Pre-Merge Goals +==================== + +Drm_scheduler +------------- +Xe primarily uses Firmware based scheduling (GuC FW). However, it will use +drm_scheduler as the scheduler ‘frontend’ for userspace submission in order to +resolve syncobj and dma-buf implicit sync dependencies. However, drm_scheduler is +not yet prepared to handle the 1-to-1 relationship between drm_gpu_scheduler and +drm_sched_entity. + +Deeper changes to drm_scheduler should *not* be required to get Xe accepted, but +some consensus needs to be reached between Xe and other community drivers that +could also benefit from this work, for coupling FW based/assisted submission such +as the ARM’s new Mali GPU driver, and others. + +As a key measurable result, the patch series introducing Xe itself shall not +depend on any other patch touching drm_scheduler itself that was not yet merged +through drm-misc. This, by itself, already includes the reach of an agreement for +uniform 1 to 1 relationship implementation / usage across drivers. + +GPU VA +------ +Two main goals of Xe are meeting together here: + +1) Have an uAPI that aligns with modern UMD needs. + +2) Early upstream engagement. + +RedHat engineers working on Nouveau proposed a new DRM feature to handle keeping +track of GPU virtual address mappings. This is still not merged upstream, but +this aligns very well with our goals and with our VM_BIND. The engagement with +upstream and the port of Xe towards GPUVA is already ongoing. + +As a key measurable result, Xe needs to be aligned with the GPU VA and working in +our tree. Missing Nouveau patches should *not* block Xe and any needed GPUVA +related patch should be independent and present on dri-devel or acked by +maintainers to go along with the first Xe pull request towards drm-next. + +DRM_VM_BIND +----------- +Nouveau, and Xe are all implementing ‘VM_BIND’ and new ‘Exec’ uAPIs in order to +fulfill the needs of the modern uAPI. Xe merge should *not* be blocked on the +development of a common new drm_infrastructure. However, the Xe team needs to +engage with the community to explore the options of a common API. + +As a key measurable result, the DRM_VM_BIND needs to be documented in this file +below, or this entire block deleted if the consensus is for independent drivers +vm_bind ioctls. + +Although having a common DRM level IOCTL for VM_BIND is not a requirement to get +Xe merged, it is mandatory to enforce the overall locking scheme for all major +structs and list (so vm and vma). So, a consensus is needed, and possibly some +common helpers. If helpers are needed, they should be also documented in this +document. + +ASYNC VM_BIND +------------- +Although having a common DRM level IOCTL for VM_BIND is not a requirement to get +Xe merged, it is mandatory to have a cross-driver consensus and understanding how +to handle async VM_BIND and interactions with userspace memory fences. Ideally +with helper support so people don't get it wrong in all possible ways. + +As a key measurable result, the benefits of ASYNC VM_BIND and a discussion of +various flavors, error handling and a sample API should be documented here or in +a separate document pointed to by this document. + +Userptr integration and vm_bind +------------------------------- +Different drivers implement different ways of dealing with execution of userptr. +With multiple drivers currently introducing support to VM_BIND, the goal is to +aim for a DRM consensus on what’s the best way to have that support. To some +extent this is already getting addressed itself with the GPUVA where likely the +userptr will be a GPUVA with a NULL GEM call VM bind directly on the userptr. +However, there are more aspects around the rules for that and the usage of +mmu_notifiers, locking and other aspects. + +This task here has the goal of introducing a documentation of the basic rules. + +The documentation *needs* to first live in this document (API session below) and +then moved to another more specific document or at Xe level or at DRM level. + +Documentation should include: + + * The userptr part of the VM_BIND api. + + * Locking, including the page-faulting case. + + * O(1) complexity under VM_BIND. + +Some parts of userptr like mmu_notifiers should become GPUVA or DRM helpers when +the second driver supporting VM_BIND+userptr appears. Details to be defined when +the time comes. + +Long running compute: minimal data structure/scaffolding +-------------------------------------------------------- +The generic scheduler code needs to include the handling of endless compute +contexts, with the minimal scaffolding for preempt-ctx fences (probably on the +drm_sched_entity) and making sure drm_scheduler can cope with the lack of job +completion fence. + +The goal is to achieve a consensus ahead of Xe initial pull-request, ideally with +this minimal drm/scheduler work, if needed, merged to drm-misc in a way that any +drm driver, including Xe, could re-use and add their own individual needs on top +in a next stage. However, this should not block the initial merge. + +As a key measurable result, the handling of the long running jobs and the minimal +scaffolding should be documented here or in a separate document pointed to by +this document. + +Display integration with i915 +----------------------------- +In order to share the display code with the i915 driver so that there is maximum +reuse, the i915/display/ code is built twice, once for i915.ko and then for +xe.ko. Currently, the i915/display code in Xe tree is polluted with many 'ifdefs' +depending on the build target. The goal is to refactor both Xe and i915/display +code simultaneously in order to get a clean result before they land upstream, so +that display can already be part of the initial pull request towards drm-next. + +However, display code should not gate the acceptance of Xe in upstream. Xe +patches will be refactored in a way that display code can be removed, if needed, +from the first pull request of Xe towards drm-next. The expectation is that when +both drivers are part of the drm-tip, the introduction of cleaner patches will be +easier and speed up. + +Drm_exec +-------- +Helper to make dma_resv locking for a big number of buffers is getting removed in +the drm_exec series proposed in https://patchwork.freedesktop.org/patch/524376/ +If that happens, Xe needs to change and incorporate the changes in the driver. +The goal is to engage with the Community to understand if the best approach is to +move that to the drivers that are using it or if we should keep the helpers in +place waiting for Xe to get merged. + +As a key measurable result, we need to have a community consensus documented in +this document and the Xe driver prepared for the changes, if necessary. + +Xe – uAPI high level overview +============================= + +...Warning: To be done in follow up patches after/when/where the main consensus in various items are individually reached.