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=-0.6 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 70448C38A24 for ; Thu, 7 May 2020 16:00:17 +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 43CEA2082E for ; Thu, 7 May 2020 16:00:17 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=jlekstrand-net.20150623.gappssmtp.com header.i=@jlekstrand-net.20150623.gappssmtp.com header.b="XneLJgt2" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 43CEA2082E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=jlekstrand.net 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 84C8B6EA2D; Thu, 7 May 2020 16:00:14 +0000 (UTC) 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 030AD6EA2D for ; Thu, 7 May 2020 16:00:12 +0000 (UTC) Received: by mail-ed1-x544.google.com with SMTP id g16so5971271eds.1 for ; Thu, 07 May 2020 09:00:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jlekstrand-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zKTFigpC2E8aDo3Jektb3FrHnIr1pcyu6F3QfmafSN8=; b=XneLJgt2Fzefze3cJkTlaQ3tYZam6ljoNTl7McBxUy/ky+bmmMIvIjIv6eyMQpGpsQ gpJOtGI4xK8kvH9+gKyKNs27YJ/KJNygjn3FE86E5m7VMJYH5KHqD3l+unyotqH+jQCB hK7uDu7is0F4GLmlwieI43A5uNsJTd6xVum1txMjRwfbtip9TAWanf72riKMJuu1aXUT PLZMof+9RSgOmBsA3K458+ZO4/zkJtYxhlw9lMvY/iOuHA1tprsux2lYk/xNq5nYSb+H 53pTuH8PsKaF+AyFCbgwzOQKGPZP8cvV6rTE665khVLgaVug+G+fhHMDbU828QbMJADz fIrA== 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=zKTFigpC2E8aDo3Jektb3FrHnIr1pcyu6F3QfmafSN8=; b=ashSKf8ZW5/H5K1Sy7K9jPH35KwhbCrEt3LnUBspV50Wfg+evA/7clf5mcenJTdSLw 0ZX+wan7/L39Ohu69AGm9b4y24W74FuyO6MSXo9+CQCHduprek3zJtGO683YHLodFqIF L0YF9s5PX+LKm4i737ooF5GLls3Vv4yaAUEn2XydSzigIHVVj0CIoWwl9qGhA7e3HqNw hrsDaDI4CWMht3aFjcS1nw2M5zcOd94ubu+stPshMUvxJXS2zs5VW+QHXH+31XFEwwM1 LQ7gqghGbRhXfJy6XjkvZZN/R6Ntcvaj+7B5gi1NrUl1QwEGyJRzIGPyZP5/r76Hu8yJ ma9Q== X-Gm-Message-State: AGi0PuaWDx08+ZcMiHwnzO4emAGooinlMdKwZhm5uyH3yCniTKShaPa+ aaJ3AEw0oZj75tKUGCjIH6eWsIdS0zvpFHgWkCoy+g== X-Google-Smtp-Source: APiQypKanG5unzKeCaUc2Vx9nZL9/DqKl8QPmySR1la1wpMuBECmw2jzIRuI/NrnkpIvk0cWYzmSG+N1ISKxqLT7KRU= X-Received: by 2002:a05:6402:30b4:: with SMTP id df20mr6637147edb.324.1588867211462; Thu, 07 May 2020 09:00:11 -0700 (PDT) MIME-Version: 1.0 References: <20200507153600.314454-1-jason@jlekstrand.net> <158886626795.20858.1870213936656066157@build.alporthouse.com> In-Reply-To: <158886626795.20858.1870213936656066157@build.alporthouse.com> From: Jason Ekstrand Date: Thu, 7 May 2020 11:00:00 -0500 Message-ID: Subject: Re: [PATCH] RFC: i915: Drop relocation support on Gen12+ To: Chris Wilson 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: Dave Airlie , Intel GFX , Maling list - DRI developers , Daniel Vetter Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Thu, May 7, 2020 at 10:44 AM Chris Wilson wrote: > > Quoting Jason Ekstrand (2020-05-07 16:36:00) > > The Vulkan driver in Mesa for Intel hardware never uses relocations if > > it's running on a version of i915 that supports at least softpin which > > all versions of i915 supporting Gen12 do. On the OpenGL side, Gen12 is > > only supported by iris which never uses relocations. The older i965 > > driver in Mesa does use relocations but it only supports Intel hardware > > through Gen11 and has been deprecated for all hardware Gen9+. The entire > > relocation UAPI and related infrastructure, therefore, doesn't have any > > open-source userspace consumer starting with Gen12. > > > > Rejecting relocations starting with Gen12 has the benefit that we don't > > have to bother supporting it on platforms with local memory. Given how > > much CPU touching of memory is required for relocations, not having to > > do so on platforms where not all memory is directly CPU-accessible > > carries significant advantages. > > You are not supplying them, the kernel is not checking them [as they > don't exist], so there is no material benefit. The only question is > maintainability. > > How confident are you that you will never use them Confident enough to send this patch. Especially in a Vulkan world where it's very hard to tell which bits of memory are actually in-use on the GPU, stalling to relocate is performance death. With a 48-bit GTT, there's no need to have the kernel involved in address space assignment so relocations don't really serve much purpose. We did potentially have one use for them with VK_KHR_performance_query but we're going out of our way to avoid them there. If we desperately need relocations, we can do them from userspace. > and rewrite the media-driver? I'm pretty sure they're working on getting rid of them. I'm checking on that right now. > The code exists, will be tested, and can just as easily > expire with the rest of execbuffer2. Sure. The question, again, is maintenance. If we're spending piles of time trying to figure out how to keep relocations going in a local memory world, that's likely a waste. Relocations can sit and rot on Gen11 and below until we finally make execbuffer3 a reality and then they can rot in the deprecated execbuffer2 ioct. There is a bit of a question here about what to do with IGT. I suspect it uses relocations for a lot of stuff and the fallout there could be significant. (I explicitly made this patch so it won't actually build because I don't hate our CI people.) --Jason _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel 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=-0.6 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 24A78C47247 for ; Thu, 7 May 2020 16:00:15 +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 EC7A820659 for ; Thu, 7 May 2020 16:00:14 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=jlekstrand-net.20150623.gappssmtp.com header.i=@jlekstrand-net.20150623.gappssmtp.com header.b="XneLJgt2" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EC7A820659 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=jlekstrand.net Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=intel-gfx-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 548826EA2B; Thu, 7 May 2020 16:00:14 +0000 (UTC) Received: from mail-ed1-x542.google.com (mail-ed1-x542.google.com [IPv6:2a00:1450:4864:20::542]) by gabe.freedesktop.org (Postfix) with ESMTPS id 0266C6EA2B for ; Thu, 7 May 2020 16:00:12 +0000 (UTC) Received: by mail-ed1-x542.google.com with SMTP id y24so5983381edo.0 for ; Thu, 07 May 2020 09:00:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jlekstrand-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zKTFigpC2E8aDo3Jektb3FrHnIr1pcyu6F3QfmafSN8=; b=XneLJgt2Fzefze3cJkTlaQ3tYZam6ljoNTl7McBxUy/ky+bmmMIvIjIv6eyMQpGpsQ gpJOtGI4xK8kvH9+gKyKNs27YJ/KJNygjn3FE86E5m7VMJYH5KHqD3l+unyotqH+jQCB hK7uDu7is0F4GLmlwieI43A5uNsJTd6xVum1txMjRwfbtip9TAWanf72riKMJuu1aXUT PLZMof+9RSgOmBsA3K458+ZO4/zkJtYxhlw9lMvY/iOuHA1tprsux2lYk/xNq5nYSb+H 53pTuH8PsKaF+AyFCbgwzOQKGPZP8cvV6rTE665khVLgaVug+G+fhHMDbU828QbMJADz fIrA== 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=zKTFigpC2E8aDo3Jektb3FrHnIr1pcyu6F3QfmafSN8=; b=GfZjP1F1TM1PFz9XR061MPnjurbKK+wmm2t3IdE0Ui3IFxv3azAud2WJovnMg6SDgD DeW/BZ0I3j5fHdEuB1drTHX9PhOGJv+7wly2ApbbDnDlSkfgT7e0sbpYedk23caGM06v AU3mWe4ZVQNfnTDqtYd5lruM1PmBbHLV0emXeGaxv6GkB9+GWGFOMMG7bKlV/mdw16c+ 3byrShu4ZEEgDaJL37Ga0DrCmDZgHwqlW1PZKlLT0/iJEwoAxXx1n2O72/4cqoWa75MV 2wlROswiLCu6rkrfmtkhhcl6gqKrUnyF2Gv/JHBoIGmL6Fjkz7ERmbiJmp4TKIMe/yiU 7Gtg== X-Gm-Message-State: AGi0PuYDvO8klZp+uN9bEyqmfZLC8b7m095DPwNUsH869ebyAkKm378R Di+B6zwb8z7JUW5KY+bL6LtEE3xnqcdyhe3h+9YdOQ== X-Google-Smtp-Source: APiQypKanG5unzKeCaUc2Vx9nZL9/DqKl8QPmySR1la1wpMuBECmw2jzIRuI/NrnkpIvk0cWYzmSG+N1ISKxqLT7KRU= X-Received: by 2002:a05:6402:30b4:: with SMTP id df20mr6637147edb.324.1588867211462; Thu, 07 May 2020 09:00:11 -0700 (PDT) MIME-Version: 1.0 References: <20200507153600.314454-1-jason@jlekstrand.net> <158886626795.20858.1870213936656066157@build.alporthouse.com> In-Reply-To: <158886626795.20858.1870213936656066157@build.alporthouse.com> From: Jason Ekstrand Date: Thu, 7 May 2020 11:00:00 -0500 Message-ID: To: Chris Wilson Subject: Re: [Intel-gfx] [PATCH] RFC: i915: Drop relocation support on Gen12+ X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Dave Airlie , Intel GFX , Maling list - DRI developers , Daniel Vetter Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" On Thu, May 7, 2020 at 10:44 AM Chris Wilson wrote: > > Quoting Jason Ekstrand (2020-05-07 16:36:00) > > The Vulkan driver in Mesa for Intel hardware never uses relocations if > > it's running on a version of i915 that supports at least softpin which > > all versions of i915 supporting Gen12 do. On the OpenGL side, Gen12 is > > only supported by iris which never uses relocations. The older i965 > > driver in Mesa does use relocations but it only supports Intel hardware > > through Gen11 and has been deprecated for all hardware Gen9+. The entire > > relocation UAPI and related infrastructure, therefore, doesn't have any > > open-source userspace consumer starting with Gen12. > > > > Rejecting relocations starting with Gen12 has the benefit that we don't > > have to bother supporting it on platforms with local memory. Given how > > much CPU touching of memory is required for relocations, not having to > > do so on platforms where not all memory is directly CPU-accessible > > carries significant advantages. > > You are not supplying them, the kernel is not checking them [as they > don't exist], so there is no material benefit. The only question is > maintainability. > > How confident are you that you will never use them Confident enough to send this patch. Especially in a Vulkan world where it's very hard to tell which bits of memory are actually in-use on the GPU, stalling to relocate is performance death. With a 48-bit GTT, there's no need to have the kernel involved in address space assignment so relocations don't really serve much purpose. We did potentially have one use for them with VK_KHR_performance_query but we're going out of our way to avoid them there. If we desperately need relocations, we can do them from userspace. > and rewrite the media-driver? I'm pretty sure they're working on getting rid of them. I'm checking on that right now. > The code exists, will be tested, and can just as easily > expire with the rest of execbuffer2. Sure. The question, again, is maintenance. If we're spending piles of time trying to figure out how to keep relocations going in a local memory world, that's likely a waste. Relocations can sit and rot on Gen11 and below until we finally make execbuffer3 a reality and then they can rot in the deprecated execbuffer2 ioct. There is a bit of a question here about what to do with IGT. I suspect it uses relocations for a lot of stuff and the fallout there could be significant. (I explicitly made this patch so it won't actually build because I don't hate our CI people.) --Jason _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx