Am 12.03.19 um 22:20 schrieb Kuehling, Felix:
> When page table are updated by the CPU, synchronize with the
> allocation and initialization of newly allocated page tables.
Really good catch, didn't thought about that fully when writing the
original patch.
Would you mind if instead of this patch
Acked-by: Christian König
But I have the strong feeling that we sooner or later need to rewrite
the whole stuff from scratch.
Especially the struct amdgpu_ttm_tt structure now has a lot of
superfluous stuff left.
Christian.
Am 13.03.19 um 02:47 schrieb Kuehling, Felix:
This patch is Revi
Am 12.03.19 um 17:57 schrieb Andrey Grodzovsky:
Also stop calling drm_sched_increase_karma multiple times.
Signed-off-by: Andrey Grodzovsky
Acked-by: Christian König
---
drivers/gpu/drm/v3d/v3d_sched.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/dri
All commands updating the page tables are pushed through the same
scheduler entity.
And that one makes sure that they are all executed on the same SDMA engine.
Switching of entities between engines happens only when the entities are
idle.
Regards,
Christian.
Am 13.03.19 um 00:36 schrieb Kue
This reverts commit 4ef27005fefd4be102010b7d8552fec1ee13435a.
It can trigger a reference counter bug in TTM. Need to investigate further, but
for now revert the offending change.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 2 ++
1 file changed, 2 insertions(+)
d
On 2019-03-13 9:38 a.m., Christian König wrote:
> This reverts commit 4ef27005fefd4be102010b7d8552fec1ee13435a.
>
> It can trigger a reference counter bug in TTM. Need to investigate further,
> but
> for now revert the offending change.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/dr
add amdgpu_amdkfd_pre_reset and amdgpu_amdkfd_post_reset inside
amdgpu_device_reset_sriov.
Change-Id: Icf2839f0b620ce9d47d6414b6c32b9d06672f2ac
Signed-off-by: Wentao Lou
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/amd/amd
Fantastic, I'm integrating it now. Fingers crossed!
Kent
> -Original Message-
> From: Kuehling, Felix
> Sent: Tuesday, March 12, 2019 7:31 PM
> To: Yang, Philip ; Russell, Kent
> ; Koenig, Christian ;
> amd-gfx@lists.freedesktop.org
> Subject: Re: [PATCH 3/6] drm/amdgpu: allocate VM PDs/
/commits/Chunming-Zhou/dma-buf-add-new-dma_fence_chain-container-v5/20190313-080623
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'
All warnings (new ones prefixed by >>):
>> dri
What I observe is that moving the mouse made the memory speed go up and
also it made mclk=1200Mhz in rocm-smi output.
However if I force mclk to 1200Mhz myself then memory speed is still slow.
So rocm-smi output when memory speed went fast due to mouse movement:
rocm-smi
This patch enables gfxoff and stutter mode again, since we take more testing on
raven series. For raven2 and picasso, we can enable it directly. And for raven,
we need check the RLC ucode version cannot be less than #531.
Signed-off-by: Huang Rui
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
Tested-by: Likun Gao
Regards,
Likun
-Original Message-
From: amd-gfx On Behalf Of Huang Rui
Sent: Wednesday, March 13, 2019 8:28 PM
To: amd-gfx@lists.freedesktop.org
Cc: Huang, Ray
Subject: [PATCH] drm/amdgpu: enable gfxoff again on raven series
This patch enables gfxoff and stutter m
To be on the safe side I've adjusted the code to work with any number of
SDMA instances.
Christian.
Am 12.03.19 um 16:33 schrieb Deucher, Alexander:
I don't think Raven has a paging queue in the first place.
Alex
*From:*
Now that we have re-reoute faults to the other IH
ring we can enable retries again.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/gfxhub_v1_0.c | 2 +-
drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/
We need the first paging queue to handle page faults.
v2: handle any number of SDMA instances gracefully
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c | 22 ++
1 file changed, 14 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdg
To aid recoverable page faults.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c
index 335a0edf114b..8f5026c123ef 100644
--- a/dri
Reviewed-by: Alex Deucher
From: amd-gfx on behalf of Huang Rui
Sent: Wednesday, March 13, 2019 8:27 AM
To: amd-gfx@lists.freedesktop.org
Cc: Huang, Ray
Subject: [PATCH] drm/amdgpu: enable gfxoff again on raven series
This patch enables gfxoff and stutter mode a
I just put a Radeon 9600XT into an Athlon XP machine. I do not know if the card
is good or not, but 2D dumb framebufer works fine with radeon module. However,
init of the acceleration engine fails. I compiled my own kernel (v5.0 from git)
with UBSAN (no other debug yet) and got a cascade of UBSAN
"Grodzovsky, Andrey" writes:
> They are not the same, but the guilty job belongs to only one {entity,
> scheduler} pair and so we mark as guilty only for that particular
> entity in the context of that scheduler only once.
I get it now, sorry. I'll merge this through drm-misc-next.
signature.
[Why]
Incorrect hardcoded assumptions are made regarding luma and chroma
alignment. The actual values set for the DRM framebuffer should be used
when programming the address.
[How]
Respect the given pitch for both luma and chroma planes - it's not like
we can force the alignment to anything else a
On 3/13/19 12:13 PM, Eric Anholt wrote:
> "Grodzovsky, Andrey" writes:
>
>> They are not the same, but the guilty job belongs to only one {entity,
>> scheduler} pair and so we mark as guilty only for that particular
>> entity in the context of that scheduler only once.
> I get it now, sorry. I'l
The series is Reviewed-by: Felix Kuehling
On 2019-03-13 9:44 a.m., Christian König wrote:
> Now that we have re-reoute faults to the other IH
> ring we can enable retries again.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/amd/amdgpu/gfxhub_v1_0.c | 2 +-
> drivers/gpu/drm/amd/a
On Wed, Mar 13, 2019 at 6:04 AM wentalou wrote:
>
> add amdgpu_amdkfd_pre_reset and amdgpu_amdkfd_post_reset inside
> amdgpu_device_reset_sriov.
>
> Change-Id: Icf2839f0b620ce9d47d6414b6c32b9d06672f2ac
> Signed-off-by: Wentao Lou
Acked-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdgpu/amdg
"Grodzovsky, Andrey" writes:
> On 3/13/19 12:13 PM, Eric Anholt wrote:
>> "Grodzovsky, Andrey" writes:
>>
>>> They are not the same, but the guilty job belongs to only one {entity,
>>> scheduler} pair and so we mark as guilty only for that particular
>>> entity in the context of that scheduler o
On 2019-03-13 12:35 p.m., Nicholas Kazlauskas wrote:
> [Why]
> Incorrect hardcoded assumptions are made regarding luma and chroma
> alignment. The actual values set for the DRM framebuffer should be used
> when programming the address.
>
> [How]
> Respect the given pitch for both luma and chroma p
np
Andrey
On 3/13/19 1:53 PM, Eric Anholt wrote:
> "Grodzovsky, Andrey" writes:
>
>> On 3/13/19 12:13 PM, Eric Anholt wrote:
>>> "Grodzovsky, Andrey" writes:
>>>
They are not the same, but the guilty job belongs to only one {entity,
scheduler} pair and so we mark as guilty only for th
Hi Lauri,
I still think the SMU is doing something funny, but rocm-smi isn't
showing enough information to really see what's going on.
On APUs the SMU firmware is embedded in the system BIOS. Unlike discrete
GPUs, the SMU firmware is not loaded by the driver. You could try
updating your system
From: Nicholas Kazlauskas
[ Upstream commit 0921c41e19028314830b33daa681e46b46477c5e ]
[Why]
If the cursor pos passed from DM is less than the plane_state->dst_rect
top left corner then the unsigned cursor pos wraps around to a large
positive number since cursor pos is a u32.
There was an attem
Hi Dave, Daniel,
A few fixes for 5.1:
- Update golden regs for gfx9
- Powerplay fixes
The following changes since commit 59d3191f14dc18881fec1172c7096b7863622803:
drm/amd/display: don't call dm_pp_ function from an fpu block (2019-03-06
15:31:20 -0500)
are available in the Git repository at:
For reproduction only the tiny cl_slow_test.cpp is needed which is attached
to first e-mail.
System information is following:
CPU: Ryzen5 2400G
Main board: Gigabyte AMD B450 AORUS mini itx:
https://www.gigabyte.com/Motherboard/B450-I-AORUS-PRO-WIFI-rev-10#kf
BIOS: F5 8.47 MB 2019/01/25 (latest)
Ke
Hello,
This series fixes the slow down in performance introduced by
"[PATCH v2] drm: Block fb changes for async plane updates" where async update
falls back to a sync update, causing igt failures of type:
"CRITICAL: completed 97 cursor updated in a period of 30 flips, we
expect to complet
Async update callbacks are expected to set the old_fb in the new_state
so prepare/cleanup framebuffers are balanced.
Calling drm_atomic_set_fb_for_plane() (which gets a reference of the new
fb and put the old fb) is not required, as it's taken care by
drm_mode_cursor_universal() when calling drm_a
In the case of a normal sync update, the preparation of framebuffers (be
it calling drm_atomic_helper_prepare_planes() or doing setups with
drm_framebuffer_get()) are performed in the new_state and the respective
cleanups are performed in the old_state.
In the case of async updates, the preparatio
This patch enables gfxoff and stutter mode again, since we take more testing on
raven series. For raven2 and picasso, we can enable it directly. And for raven,
we need check the RLC/SMC ucode version cannot be less than #531/0x1e45.
v2: add smc version checking for raven.
Signed-off-by: Huang Rui
Tested-by: Likun Gao
Regards,
Likun
-Original Message-
From: amd-gfx On Behalf Of Huang Rui
Sent: Thursday, March 14, 2019 1:56 PM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Gao, Likun
; Huang, Ray
Subject: [PATCH v2] drm/amdgpu: enable gfxoff again on raven series (v2
35 matches
Mail list logo
