On Fri, Jun 02, 2017 at 04:33:31PM -0400, Alex Deucher wrote:
> This was missing for gfx6.
>
> Signed-off-by: Alex Deucher
> Cc: sta...@vger.kernel.org
Acked-by: Huang Rui
> ---
> drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a
Hi all,
Just back after a week off ... first thing I see on my vega10 system is
this patch:
83866f0fc72017d55f40cbd4160cd1e42a2cc3a8 is the first bad commit
commit 83866f0fc72017d55f40cbd4160cd1e42a2cc3a8
Author: Andres Rodriguez
Date: Thu Feb 2 00:38:22 2017 -0500
drm/amdgpu: allow sp
The commit 83866f0fc72017d55f40cbd4160cd1e42a2cc3a8 erroneously included the
old ring init sequence along with the new one which uses shared header
definitions.
The fix which works on my vega10 seems to be to drop the old init sequence.
Signed-off-by: Tom St Denis
---
drivers/gpu/drm/amd/amdgp
Hi, Tom,
You have found a bug.
Your patch looks fine for me.
Have you confirmed the deleted part is older version? Perhaps search email list
or git history to confirm?
Alex Bin Xie
-Original Message-
From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of
amd-gfx-r
Hi Tom,
I have found the original patch which introduce the duplicate code.
The patch is in:
amd-gfx Digest, Vol 11, Issue 301
Alex Bin Xie
-Original Message-
From: Xie, AlexBin
Sent: Monday, June 5, 2017 10:25 AM
To: amd-gfx@lists.freedesktop.org
Subject: RE: amd-gfx Digest, Vol 13, I
Instead of taking the first pipe and giving the rest to kfd, take the
first 2 queues of each pipe.
Effectively, amdgpu and amdkfd own the same number of queues. But
because the queues are spread over multiple pipes the hardware will be
able to better handle concurrent compute workloads.
amdgpu go
Pipes provide better concurrency than queues, therefore we want to make
sure that apps use queues from different pipes whenever possible.
Optimize for the trivial case where an app will consume rings in order,
therefore we don't want adjacent rings to belong to the same pipe.
gfx9 was missed when
On 05/06/17 10:24 AM, Xie, AlexBin wrote:
Hi, Tom,
You have found a bug.
Your patch looks fine for me.
Have you confirmed the deleted part is older version? Perhaps search email list
or git history to confirm?
It looks like the edits to the older GFX files (7/8) simply changed that
block o
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Xiangliang Yu
> Sent: Saturday, June 03, 2017 5:45 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Yu, Xiangliang
> Subject: [PATCH] drm/amdgpu: correct clock info for SRIOV
>
> Currently, get c
On Mon, Jun 5, 2017 at 7:34 AM, Tom St Denis wrote:
> Hi all,
>
> Just back after a week off ... first thing I see on my vega10 system is this
> patch:
>
> 83866f0fc72017d55f40cbd4160cd1e42a2cc3a8 is the first bad commit
> commit 83866f0fc72017d55f40cbd4160cd1e42a2cc3a8
> Author: Andres Rodriguez
On 05/06/17 11:32 AM, Alex Deucher wrote:
On Mon, Jun 5, 2017 at 7:34 AM, Tom St Denis wrote:
Hi all,
Just back after a week off ... first thing I see on my vega10 system is this
patch:
83866f0fc72017d55f40cbd4160cd1e42a2cc3a8 is the first bad commit
commit 83866f0fc72017d55f40cbd4160cd1e42a2
> what is the purpose of the file version
The initial purpose is to act like a version tag, not necessarily format
related.
Sam
-Original Message-
From: Michel Dänzer [mailto:mic...@daenzer.net]
Sent: Sunday, June 04, 2017 10:10 PM
To: Li, Samuel
Cc: amd-gfx@lists.freedesktop.org; Yua
Thanks for the gfx9 fixes, and sorry for the trouble. Hopefully a gfx9
card will be out soon so that I can start testing on it :)
Reviewed-by: Andres Rodriguez
-Andres
On 2017-06-05 11:06 AM, Alex Deucher wrote:
Pipes provide better concurrency than queues, therefore we want to make
sure tha
Reviewed-by: Andres Rodriguez
-Andres
On 2017-06-05 11:06 AM, Alex Deucher wrote:
Instead of taking the first pipe and giving the rest to kfd, take the
first 2 queues of each pipe.
Effectively, amdgpu and amdkfd own the same number of queues. But
because the queues are spread over multiple pi
The device_id option [-d] was badly broken. This commit fixes
the width (was 8 is now 16 bits) as well as enables searches
without specifying a bus id. It was also comparing "dev" from
the bus field which is not the PCI device id.
Signed-off-by: Tom St Denis
---
tests/amdgpu/amdgpu_test.c | 18
Hi Luke,
the first things to check would be the saved kern.log and Xorg.0.log
from before the crash occured. Both should be in /var/log. These logs
will keep a long record but you should be able to find the bad run as
kern.log is timestamped and with Xorg.0.log you should be able to scroll
ba
Create crtc/connector combinations based on actual adapter
information obtained from drmModeRes.
Also set MAX_CRTCs to 6 for AMD GPUs.
Signed-off-by: Harry Wentland
---
tests/kms_setmode.c | 24 ++--
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git a/tests/kms_se
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Tom St Denis
> Sent: Monday, June 05, 2017 2:04 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: StDenis, Tom
> Subject: [PATCH drm] tests/amdgpu: Fix device_id option
>
> The device_id option [-
On Mon, Jun 5, 2017 at 2:36 PM, Harry Wentland wrote:
> Hi Luke,
>
> the first things to check would be the saved kern.log and Xorg.0.log from
> before the crash occured. Both should be in /var/log. These logs will keep a
> long record but you should be able to find the bad run as kern.log is
> ti
On Mon, Jun 5, 2017 at 2:43 PM, Harry Wentland wrote:
> Create crtc/connector combinations based on actual adapter
> information obtained from drmModeRes.
>
> Also set MAX_CRTCs to 6 for AMD GPUs.
>
> Signed-off-by: Harry Wentland
The code is kind of hard to follow, but it looks good to me:
Acke
On 2017-06-05 03:50 PM, Alex Deucher wrote:
On Mon, Jun 5, 2017 at 2:43 PM, Harry Wentland wrote:
Create crtc/connector combinations based on actual adapter
information obtained from drmModeRes.
Also set MAX_CRTCs to 6 for AMD GPUs.
Signed-off-by: Harry Wentland
The code is kind of hard to
Hi Andres,
I think the original patch was written by you. Would you comment? Is it a bug
or intentional?
Thank you.
Alex Bin Xie
Message: 1
Date: Mon, 5 Jun 2017 10:36:59 -0400
From: Tom St Denis
To: amd-gfx@lists.freedesktop.org
Subject: Re: amd-gfx Digest, Vol 13, Issue 29
Message-ID: <587
On 2017-06-05 03:48 PM, Xie, AlexBin wrote:
Hi Andres,
I think the original patch was written by you. Would you comment? Is it a bug
or intentional?
Thank you.
Alex Bin Xie
Message: 1
Date: Mon, 5 Jun 2017 10:36:59 -0400
From: Tom St Denis
To: amd-gfx@lists.freedesktop.org
Subject: Re: a
On 05/06/17 11:42 PM, Xie, AlexBin wrote:
>
> I have found the original patch which introduce the duplicate code.
>
> The patch is in:
> amd-gfx Digest, Vol 11, Issue 301
FYI, such a reference is useless for people who aren't subscribed to the
list in digest mode (which is presumably the majorit
On 03/06/17 07:46 AM, Luke Miller wrote:
>
> I have a recurring problem with one 3D program (UE4editor) crashing my
> computer during a particular operation.
>
> I believe the problem is at the DRM layer.
It's actually more likely in Mesa. If you set either or both of the
following environment v
> > Currently, get clock info from default clk of pm if dpm is disable.
> > Buf SRIOV doesn't support dpm and pm, can't get anything from pm.
> > Only get clock info only from default clk of amdgpu for SRIOV.
> >
> > And driver get pm default clk also from amdgpu default clk and never
> > be change
gpu_info firmware is released after data is used. But when system enters into
suspend, upper class driver will cache all firmware names. At that time,
gpu_info will be failing to load. It seems an upper class issue, that we should
not release gpu_info firmware until device finished.
[ 903.236589]
27 matches
Mail list logo
