All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Greathouse, Joseph" <Joseph.Greathouse-5C7GfCeVMHo@public.gmane.org>
To: "Koenig,
	Christian" <Christian.Koenig-5C7GfCeVMHo@public.gmane.org>,
	"Kuehling, Felix" <Felix.Kuehling-5C7GfCeVMHo@public.gmane.org>,
	"amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org"
	<amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>
Subject: RE: [PATCH v2] drm/amdgpu: Default disable GDS for compute VMIDs
Date: Thu, 18 Jul 2019 20:46:00 +0000	[thread overview]
Message-ID: <CY4PR12MB17679E12D3513F612E48AB55F9C80@CY4PR12MB1767.namprd12.prod.outlook.com> (raw)
In-Reply-To: <42627d7f-2431-6b17-72aa-e448b4937c53-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

> -----Original Message-----
> From: Christian König <ckoenig.leichtzumerken@gmail.com>
> Sent: Thursday, July 18, 2019 3:14 AM
> To: Kuehling, Felix <Felix.Kuehling@amd.com>; Greathouse, Joseph
> <Joseph.Greathouse@amd.com>; amd-gfx@lists.freedesktop.org
> Subject: Re: [PATCH v2] drm/amdgpu: Default disable GDS for compute
> VMIDs
> 
> Am 17.07.19 um 22:09 schrieb Kuehling, Felix:
> > On 2019-07-17 14:23, Greathouse, Joseph wrote:
> >> The GDS and GWS blocks default to allowing all VMIDs to
> >> access all entries. Graphics VMIDs can handle setting
> >> these limits when the driver launches work. However,
> >> compute workloads under HWS control don't go through the
> >> kernel driver. Instead, HWS firmware should set these
> >> limits when a process is put into a VMID slot.
> >>
> >> Disable access to these devices by default by turning off
> >> all mask bits (for OA) and setting BASE=SIZE=0 (for GDS
> >> and GWS) for all compute VMIDs. If a process wants to use
> >> these resources, they can request this from the HWS
> >> firmware (when such capabilities are enabled). HWS will
> >> then handle setting the base and limit for the process when
> >> it is assigned to a VMID.
> >>
> >> This will also prevent user kernels from getting 'stuck' in
> >> GWS by accident if they write GWS-using code but HWS
> >> firmware is not set up to handle GWS reset. Until HWS is
> >> enabled to handle GWS properly, all GWS accesses will
> >> MEM_VIOL fault the kernel.
> >>
> >> v2: Move initialization outside of SRBM mutex
> >>
> >> Change-Id: I8edcea9d0b14d16a7444bcf9fbf9451aef8b707d
> >> Signed-off-by: Joseph Greathouse <Joseph.Greathouse@amd.com>
> > Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
> 
> Might be a good idea to do this for all VMIDs during initialization and
> not just for the ones used for compute.
> 
> But anyway patch is Reviewed-by: Christian König
> <christian.koenig@amd.com>.

Hmm, good point. It looks like graphics jobs will eventually call through to emit_gds_switch() to set these when launching a job, but it may be worthwhile to set these to zero as a default. I didn't want to step on any toes on the graphics side without checking first.

Do you have opinions on the most reasonable location to do this? early_init(), late_init()? The various gfx_v*_set_gds_init() might be a good place -- a quick test of setting all 16 VMIDs in gfx_v9_0_set_gds_init() appears to work fine on my Vega 20.

-Joe
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

      parent reply	other threads:[~2019-07-18 20:46 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-17 17:11 [PATCH] drm/amdgpu: Default disable GDS for compute VMIDs Greathouse, Joseph
     [not found] ` <20190717171112.4962-1-Joseph.Greathouse-5C7GfCeVMHo@public.gmane.org>
2019-07-17 17:23   ` Kuehling, Felix
     [not found]     ` <28783441-080b-1696-b4ea-f6ec24901fb1-5C7GfCeVMHo@public.gmane.org>
2019-07-17 18:23       ` [PATCH v2] " Greathouse, Joseph
     [not found]         ` <20190717182233.93031-1-Joseph.Greathouse-5C7GfCeVMHo@public.gmane.org>
2019-07-17 20:09           ` Kuehling, Felix
     [not found]             ` <268d3673-da7f-8e75-6131-3de9291d77d4-5C7GfCeVMHo@public.gmane.org>
2019-07-18  8:14               ` Christian König
     [not found]                 ` <42627d7f-2431-6b17-72aa-e448b4937c53-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2019-07-18 20:46                   ` Greathouse, Joseph [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CY4PR12MB17679E12D3513F612E48AB55F9C80@CY4PR12MB1767.namprd12.prod.outlook.com \
    --to=joseph.greathouse-5c7gfcevmho@public.gmane.org \
    --cc=Christian.Koenig-5C7GfCeVMHo@public.gmane.org \
    --cc=Felix.Kuehling-5C7GfCeVMHo@public.gmane.org \
    --cc=amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.