From patchwork Wed Nov 19 05:41:43 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alexandre Courbot X-Patchwork-Id: 412262 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id E4CFE1400EA for ; Wed, 19 Nov 2014 16:42:17 +1100 (AEDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751265AbaKSFmQ (ORCPT ); Wed, 19 Nov 2014 00:42:16 -0500 Received: from hqemgate15.nvidia.com ([216.228.121.64]:18616 "EHLO hqemgate15.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750757AbaKSFmQ (ORCPT ); Wed, 19 Nov 2014 00:42:16 -0500 Received: from hqnvupgp08.nvidia.com (Not Verified[216.228.121.13]) by hqemgate15.nvidia.com id ; Tue, 18 Nov 2014 21:41:59 -0800 Received: from hqemhub01.nvidia.com ([172.20.12.94]) by hqnvupgp08.nvidia.com (PGP Universal service); Tue, 18 Nov 2014 21:40:35 -0800 X-PGP-Universal: processed; by hqnvupgp08.nvidia.com on Tue, 18 Nov 2014 21:40:35 -0800 Received: from percival.nvidia.com (172.20.144.16) by hqemhub01.nvidia.com (172.20.150.30) with Microsoft SMTP Server (TLS) id 8.3.342.0; Tue, 18 Nov 2014 21:42:15 -0800 From: Alexandre Courbot To: Ilia Mirkin CC: , , , , Alexandre Courbot Subject: [PATCH v2 1/3] nouveau: support for custom VRAM domains Date: Wed, 19 Nov 2014 14:41:43 +0900 Message-ID: <1416375705-14068-2-git-send-email-acourbot@nvidia.com> X-Mailer: git-send-email 2.1.3 In-Reply-To: <1416375705-14068-1-git-send-email-acourbot@nvidia.com> References: <1416375705-14068-1-git-send-email-acourbot@nvidia.com> X-NVConfidentiality: public MIME-Version: 1.0 Sender: linux-tegra-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-tegra@vger.kernel.org Some NVIDIA chips (e.g. GK20A) do not embed VRAM of their own and have complete shared access to system memory. For these systems, allocating objects in VRAM might lead to unneeded copies and sub-optimal memory management. It will also lead to errors if the kernel does not allow VRAM objects allocations. This patch adds a vram_domain member to struct nouveau_screen that can optionally be initialized to an alternative domain to use for VRAM allocations (most likely, NOUVEAU_BO_GART to allocate everything in system memory). If not initialized, the default NOUVEAU_BO_VRAM domain is used. Code that allocates GPU objects is then expected to use the NV_VRAM_DOMAIN() macro in place of NOUVEAU_BO_VRAM to ensure correct behavior on VRAM-less chips. Signed-off-by: Alexandre Courbot --- src/gallium/drivers/nouveau/nouveau_screen.c | 6 ++++++ src/gallium/drivers/nouveau/nouveau_screen.h | 4 ++++ 2 files changed, 10 insertions(+) diff --git a/src/gallium/drivers/nouveau/nouveau_screen.c b/src/gallium/drivers/nouveau/nouveau_screen.c index 517978d88588..e4598c3fd24f 100644 --- a/src/gallium/drivers/nouveau/nouveau_screen.c +++ b/src/gallium/drivers/nouveau/nouveau_screen.c @@ -158,6 +158,12 @@ nouveau_screen_init(struct nouveau_screen *screen, struct nouveau_device *dev) size = sizeof(nvc0_data); } + /* + * Set default VRAM domain if not overridden + */ + if (!screen->vram_domain) + screen->vram_domain = NOUVEAU_BO_VRAM; + ret = nouveau_object_new(&dev->object, 0, NOUVEAU_FIFO_CHANNEL_CLASS, data, size, &screen->channel); if (ret) diff --git a/src/gallium/drivers/nouveau/nouveau_screen.h b/src/gallium/drivers/nouveau/nouveau_screen.h index cf06f7e88aa0..30041b271c94 100644 --- a/src/gallium/drivers/nouveau/nouveau_screen.h +++ b/src/gallium/drivers/nouveau/nouveau_screen.h @@ -51,6 +51,8 @@ struct nouveau_screen { boolean hint_buf_keep_sysmem_copy; + unsigned vram_domain; + struct { unsigned profiles_checked; unsigned profiles_present; @@ -94,6 +96,8 @@ struct nouveau_screen { #endif }; +#define NV_VRAM_DOMAIN(screen) ((screen)->vram_domain) + #ifdef NOUVEAU_ENABLE_DRIVER_STATISTICS # define NOUVEAU_DRV_STAT(s, n, v) do { \ (s)->stats.named.n += (v); \