[AMD Official Use Only - General]
> -Original Message-
> From: Kuehling, Felix
> Sent: Friday, February 2, 2024 10:21 AM
> To: Bhardwaj, Rajneesh ;
> amd-gfx@lists.freedesktop.org
> Cc: Greathouse, Joseph
> Subject: Re: [PATCH] drm/amdkfd: update SIMD distri
[AMD Official Use Only - General]
> -Original Message-
> From: Kuehling, Felix
> Sent: Monday, January 22, 2024 2:02 PM
> To: amd-gfx@lists.freedesktop.org; Greathouse, Joseph
>
> Subject: Re: [PATCH] drm/amdkfd: Add cache line sizes to KFD topology
>
> On
[Public]
> -Original Message-
> From: Zhu, James
> Sent: Thursday, November 23, 2023 1:49 PM
>
> On 2023-11-23 14:02, Felix Kuehling wrote:
> > On 2023-11-23 11:25, James Zhu wrote:
> >>
> >> On 2023-11-22 17:35, Felix Kuehling wrote:
> >>>
> >>> On 2023-11-03 09:11, James Zhu wrote:
>
> -Original Message-
> From: Lazar, Lijo
> Sent: Tuesday, August 24, 2021 2:24 AM
> To: Greathouse, Joseph ; Kuehling, Felix
> ; amd-
> g...@lists.freedesktop.org
> Subject: Re: [PATCH 1/3] drm/amdkfd: Allocate SDMA engines more fairly
>
>
>
> On 8/24/
> -Original Message-
> From: Lazar, Lijo
> Sent: Monday, August 23, 2021 11:37 PM
> To: Kuehling, Felix ; Greathouse, Joseph
> ; amd-
> g...@lists.freedesktop.org
> Subject: Re: [PATCH 1/3] drm/amdkfd: Allocate SDMA engines more fairly
>
> On 8/23/2021 10:
> -Original Message-
> From: Christian König
> Sent: Friday, August 20, 2021 2:00 AM
> To: Greathouse, Joseph ;
> amd-gfx@lists.freedesktop.org
> Subject: Re: [PATCH 2/3] drm/amdgpu: Use SDMA1 for buffer movement on
> Aldebaran
>
> Am 20.08.21 um 07:3
> -Original Message-
> From: Kasiviswanathan, Harish
> Sent: Tuesday, April 27, 2021 2:57 PM
> To: amd-gfx@lists.freedesktop.org; Greathouse, Joseph
>
> Cc: Kasiviswanathan, Harish
> Subject: [PATCH] drm/amdkfd: Add Aldebaran gws support
>
> v2: updated MEC
[AMD Public Use]
Response inline.
Thanks,
-Joe
-Original Message-
From: Russell, Kent
Sent: Tuesday, June 30, 2020 7:00 AM
To: Greathouse, Joseph ;
amd-gfx@lists.freedesktop.org
Cc: Greathouse, Joseph
Subject: RE: [PATCH] drm/amdkfd: Add Arcturus GWS support and fix VG10
[AMD
> -Original Message-
> From: Kenny Ho
> Sent: Friday, November 29, 2019 12:00 AM
>
> Reducing audience since this is AMD specific.
>
> On Tue, Oct 8, 2019 at 3:11 PM Kuehling, Felix wrote:
> >
> > On 2019-08-29 2:05 a.m., Kenny Ho wrote:
> > > The number of logical gpu (lgpu) is
> From: Daniel Vetter On Behalf Of Daniel Vetter
> Sent: Wednesday, October 9, 2019 11:07 AM
> On Wed, Oct 09, 2019 at 03:53:42PM +, Kuehling, Felix wrote:
> > On 2019-10-09 11:34, Daniel Vetter wrote:
> > > On Wed, Oct 09, 2019 at 03:25:22PM +, Kuehling, Felix wrote:
> > >> On 2019-10-09
The gpu_id argument is not needed when enabling GWS on a queue.
The queue can only be associated with one device, so the only
possible situations for the call as previously defined were:
1) the gpu_id was for the device associated with the target queue
and things worked as expected, or 2) the
The gpu_id argument is not needed when enabling GWS on a queue.
The queue can only be associated with one device, so the only
possible situations for the call as previously defined were:
1) the gpu_id was for the device associated with the target queue
and things worked as expected, or 2) the
Units in the GDS block default to allowing all VMIDs access to all
entries. Disable shader access to the GDS, GWS, and OA blocks from all
compute and gfx VMIDs by default. For compute, HWS firmware will set
up the access bits for the appropriate VMID when a compute queue
requires access to these
Units in the GDS block default to allowing all VMIDs access
to all entries. Disable shader access to the GDS, GWS, and OA
blocks from all compute and gfx VMIDs by default. For compute,
HWS firmware will set up the access bits for the appropriate
VMID when a compute queue requires access to these
> -Original Message-
> From: Christian König
> Sent: Thursday, July 18, 2019 3:14 AM
> To: Kuehling, Felix ; Greathouse, Joseph
> ; amd-gfx@lists.freedesktop.org
> Subject: Re: [PATCH v2] drm/amdgpu: Default disable GDS for compute
> VMIDs
>
> Am 17.07.19 um 22
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
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
If we shut down a process without having destroyed its GWS-using
queues, it is possible that GWS BO will still be in the process
BO list during the gpuvm destruction. This list should be empty
at that time, so we should remove the GWS allocation at the
process uninit point if it is still around.
Reading the sysfs files pp_sclk_od and pp_mclk_od return the
percentage difference between the VBIOS-provided default
frequency and the current (possibly user-set) frequency in
the highest SCLK and MCLK DPM states, respectively.
Writing to these files provides an easy mechanism for
setting a
OverDrive mode allows users to increase the maximum SCLK and MCLK
frequencies beyond the default on the GPU. However, this may not
results in large performance gains if the GPU then runs into its TDP
power limit. This patch adds the capability to increase the power
limit of a GPU above its default
OverDrive mode allows users to increase the maximum SCLK and MCLK
frequencies beyond the default on the GPU. However, this may not
results in large performance gains if the GPU then runs into its TDP
power limit. This patch adds the capability to increase the power
limit of a GPU above its default
21 matches
Mail list logo
