From: Shirish S
Add reverse iterator for_each_oldnew_plane_in_state_reverse to compliment the
for_each_oldnew_plane_in_state way or reading plane states.
The plane states are required to be read in reverse order for amd drivers,
cause the z order convention followed in linux is opposite to how
because this time SDMA may under GPU RESET so its ring->ready
can be false(e.g. IB test failed during GPU reset), just keep
going and GPU scheduler will reschedule this job once it failed.
v2:
consider error if ring not ready only finds gpu is not doing GPU reset
handle all places in amdgpu_ttm.c
> Please change the test to use ring->ring_obj instead, this way we still bail
> out if somebody tries to submit commands before the ring is even allocated.
I don't understand how could fill_buffer() get run under the case that
ring->ring_obj is not even allocated ... where is such case ?
/Mo
Anyone review this ?
-Original Message-
From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of Monk
Liu
Sent: 2018年2月28日 15:28
To: amd-gfx@lists.freedesktop.org
Cc: Liu, Monk
Subject: [PATCH] drm/amdgpu: try again kiq access if not in IRQ(v2)
sometimes GPU is switched
From: Shirish S
The below commit
"drm/atomic: Try to preserve the crtc enabled state in drm_atomic_remove_fb, v2"
introduces a slight behavioral change to rmfb. Instead of disabling a crtc when
the primary plane is disabled, it now preserves it.
This change leads to BUG hit while performing
Rather than querying it every time we need it.
Also fixes a crash in VM pass through if there is no
root bridge because the cached value fetch already checks
this properly.
v2: fix includes
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=105244
Signed-off-by: Alex Deucher
Cc: sta...@vger.ker
The util mkregtable includes a copy of the kernel API for linked lists,
only a small subset of it is used. Delete the unused functions and macros.
Signed-off-by: Matthias Kaehlcke
---
drivers/gpu/drm/radeon/mkregtable.c | 433
1 file changed, 433 deletions(-)
diff -
Hi Dave,
A few misc fixes for 4.16.
The following changes since commit 219b3b22df9d828367a4eeceed7600890e2ff4ef:
Merge branch 'drm-fixes-4.16' of git://people.freedesktop.org/~agd5f/linux
into drm-fixes (2018-02-28 11:39:52 +1000)
are available in the git repository at:
git://people.freed
On Wed, Feb 28, 2018 at 1:47 PM, Felix Kuehling wrote:
> On 2018-02-28 12:37 PM, Zhu, Rex wrote:
>>
>> Hi Felix,
>>
>>
>> First, thanks very much for taking so much time to review this interface.
>>
>> In fact, we just hope and want to support power profiling feature better.
>>
>>
>> Sclk level 7
On 2018-02-28 12:37 PM, Zhu, Rex wrote:
>
> Hi Felix,
>
>
> First, thanks very much for taking so much time to review this interface.
>
> In fact, we just hope and want to support power profiling feature better.
>
>
> Sclk level 7 i mean the highest sclk level, we get used to start from
> level 0.
After looking more
"Failed to initialize parser !" is expected since the reason is jobs
from guilty context (context causing the GPU hang) are canceled.
Locking imbalance is actually gone with Monk's patches.
Thanks,
Andrey
On 02/28/2018 11:40 AM, Andrey Grodzovsky wrote:
No new issues fou
Hi Rex,
The purpose of the compute power profile for us is to optimize
performance. Compute workloads tend to be "bursty". The default
heuristics of the SMU don't work well for such work loads. They aren't
able to raise clocks quickly enough to accelerate short bursts of
compute work.
We need to
No new issues found with those patches, testing GPU reset using libdrm
deadlock detection test on Ellsmire.
The patches are Tested-By: Andrey Grodzovsky
P.S
Noticed existing issues (before Monk's patches)
Multiple [drm:amdgpu_cs_ioctl [amdgpu]] *ERROR* Failed to initialize
parser !
And oc
Am 28.02.2018 um 16:40 schrieb Michel Dänzer:
On 2018-02-28 04:25 PM, Christian König wrote:
Am 28.02.2018 um 16:21 schrieb Michel Dänzer:
On 2018-02-28 03:41 PM, Christian König wrote:
The 32bit address range end is exclusive, not inclusive.
The other way around. :) Inclusive means [a,b], i.
On 2018-02-28 04:25 PM, Christian König wrote:
> Am 28.02.2018 um 16:21 schrieb Michel Dänzer:
>> On 2018-02-28 03:41 PM, Christian König wrote:
>>> The 32bit address range end is exclusive, not inclusive.
>> The other way around. :) Inclusive means [a,b], i.e. an interval
>> including the endpoint
Am 28.02.2018 um 16:21 schrieb Michel Dänzer:
On 2018-02-28 03:41 PM, Christian König wrote:
The 32bit address range end is exclusive, not inclusive.
The other way around. :) Inclusive means [a,b], i.e. an interval
including the endpoints, whereas exclusive means ]a,b[, i.e. an interval
not inc
On 2018-02-28 03:41 PM, Christian König wrote:
> The 32bit address range end is exclusive, not inclusive.
The other way around. :) Inclusive means [a,b], i.e. an interval
including the endpoints, whereas exclusive means ]a,b[, i.e. an interval
not including the endpoints. The patch changes the 32-
The 32bit address range end is exclusive, not inclusive. This fixes crashes
when 32bit addresses are in use.
Signed-off-by: Christian König
---
amdgpu/amdgpu_device.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/amdgpu/amdgpu_device.c b/amdgpu/amdgpu_device.c
index 9ff
+ dri-devel
On Wed, Feb 28, 2018 at 4:33 AM, S, Shirish wrote:
> From: Shirish S
>
> Add reverse iterator "for_each_oldnew_plane_in_state_reverse" to
> complement "for_each_oldnew_plane_in_state" way of reading plane
> states.
>
> The plane states are required to be read in reverse order for
>
On Wed, Feb 28, 2018 at 2:21 AM, Monk Liu wrote:
> 1)create a routine "handle_vram_lost" to do the vram
> recovery, and put it into amdgpu_device_reset/reset_sriov,
> this way no need of the extra paramter to hold the
> VRAM LOST information and the related macros can be removed.
>
> 3)show vram_r
Any DRM related changes needs to be sent to dri-de...@lists.freedesktop.org
Andrey
On 02/28/2018 04:33 AM, S, Shirish wrote:
From: Shirish S
Add reverse iterator "for_each_oldnew_plane_in_state_reverse" to
complement "for_each_oldnew_plane_in_state" way of reading plane
states.
The plane st
Found it.
Thanks.
On 02/28/2018 08:31 AM, Liu, Monk wrote:
Already sent
-Original Message-
From: Grodzovsky, Andrey
Sent: 2018年2月28日 21:31
To: Koenig, Christian ; Liu, Monk ;
amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH 1/4] drm/amdgpu: stop all rings before doing gpu recover
W
Patch look good to me then.
Acked-by: Andrey Grodzovsky
Andrey
On 02/28/2018 08:36 AM, Liu, Monk wrote:
goto error;
amdgpu_irq_gpu_reset_resume_helper(adev);
r = amdgpu_ib_ring_tests(adev);
- if (r)
- dev_err(adev->dev, "[GPU_RESET] ib ri
> goto error;
>
> amdgpu_irq_gpu_reset_resume_helper(adev);
> r = amdgpu_ib_ring_tests(adev);
> - if (r)
> - dev_err(adev->dev, "[GPU_RESET] ib ring test failed (%d).\n",
> r);
This 2 lines deletion seems unintentional
No, intentional, because if IB T
Already sent
-Original Message-
From: Grodzovsky, Andrey
Sent: 2018年2月28日 21:31
To: Koenig, Christian ; Liu, Monk ;
amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH 1/4] drm/amdgpu: stop all rings before doing gpu recover
Will do once Monk sends V2 for [PATCH 4/4] drm/amdgpu: try aga
Will do once Monk sends V2 for [PATCH 4/4] drm/amdgpu: try again kiq
access if not in IRQ
Andrey
On 02/28/2018 07:20 AM, Christian König wrote:
Andrey please give this set a good testing as well.
Am 28.02.2018 um 08:21 schrieb Monk Liu:
found recover_vram_from_shadow sometimes get executed
On 02/28/2018 02:21 AM, Monk Liu wrote:
1)create a routine "handle_vram_lost" to do the vram
recovery, and put it into amdgpu_device_reset/reset_sriov,
this way no need of the extra paramter to hold the
VRAM LOST information and the related macros can be removed.
3)show vram_recover failure if
Hi Christian
I'll try patch it and give a try on my branch, yeah my branch is old and not
have this patch
But I still feed odds, because by any reason I think it is safe that always
call reserve_shared() before amdgpu_bo_fence() right ?
The real problem troubles me is:
1) Under vulkan CTS tes
Good point, but in this case we need some other handling.
Please change the test to use ring->ring_obj instead, this way we still
bail out if somebody tries to submit commands before the ring is even
allocated.
And you also need to fix a couple of other places in amdgpu_ttm.c.
Regards,
Chris
What about this for fill_buffer():
if (ring->ready != true && !adev->in_gpu_reset) {
return -EINVAL;
}
/Monk
-Original Message-
From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of Liu,
Monk
Sent: 2018年2月28日 20:35
To: Koenig, Christian ; amd-gfx@lists.fre
Ok, I've figured out what is going on here. The problem was that we
tried to clear VM BOs with the standard background clear function.
Because of this you needed not only one, but two fence slots for newly
allocated page directories/tables.
But I've already fixed this bug quite a while ago, m
Because when SDMA was hang by like process A, and meanwhile another process B
is already running into the code of fill_buffer()
So just let process B continue, don't block it otherwise process B would fail
by software reason .
Let it run and finally process B's job would fail and GPU recover wil
Please try a newer kernel and/or branch amd-staging-drm-next and test of
the problem still exists.
If it is still around please open a bug report on bugs.freedesktop.org.
Regards,
Christian.
Am 27.02.2018 um 23:17 schrieb Anton Kashcheev:
Good day,
I have problems with graphics -- from time
Am 28.02.2018 um 08:21 schrieb Monk Liu:
because this time SDMA may under GPU RESET so its ring->ready
may not true, keep going and GPU scheduler will reschedule
this job if it failed.
give a warning on copy_buffer when go through direct_submit
while ring->ready is false
NAK, that test has alr
Am 28.02.2018 um 08:21 schrieb Monk Liu:
1)create a routine "handle_vram_lost" to do the vram
recovery, and put it into amdgpu_device_reset/reset_sriov,
this way no need of the extra paramter to hold the
VRAM LOST information and the related macros can be removed.
3)show vram_recover failure if
Andrey please give this set a good testing as well.
Am 28.02.2018 um 08:21 schrieb Monk Liu:
found recover_vram_from_shadow sometimes get executed
in paralle with SDMA scheduler, should stop all
schedulers before doing gpu reset/recover
Change-Id: Ibaef3e3c015f3cf88f84b2eaf95cda95ae1a64e3
Signe
I went through the power profiling feature in windows - Auto Wattman supported
on Polaris and Vega. Initially apply to Polaris.
The Goal is to maximize performance/watt without impacting performance and no
visual impact per system/use case
On smu7, 3 parameters control how SMU responds to sclk/
Hi Monk,
yeah thinking about those issue currently as well. It indeed looks like
we have some kind of race here.
When we call backoff_reservation the next iteration of the look will
reserve all BOs again, so that can't be the issue.
Regards,
Christian.
Am 28.02.2018 um 11:37 schrieb Liu, M
Hi Christian
In amdgpu_cs_parser_bos(), it calls ttm_eu_backoff_reservation() if @need_pages
not empty, is it safe ?
You see that if two threads in parallel running in cs_parser_bos(), if the
thread1 did call backoff_reservation and continue, that leaves
All following reservation functions on r
Am 28.02.2018 um 10:48 schrieb Lucas Stach:
Hi Christian,
Am Dienstag, den 27.02.2018, 12:49 +0100 schrieb Christian König:
Unpin the GEM object only after freeing the sg table.
What is the race that is being fixed here? The SG table is private to
the importer and the importer should hopefully
Hi Christian,
Am Dienstag, den 27.02.2018, 12:49 +0100 schrieb Christian König:
> Unpin the GEM object only after freeing the sg table.
What is the race that is being fixed here? The SG table is private to
the importer and the importer should hopefully only call map_detach if
it is done with all
From: Shirish S
Add reverse iterator "for_each_oldnew_plane_in_state_reverse" to
complement "for_each_oldnew_plane_in_state" way of reading plane
states.
The plane states are required to be read in reverse order for
amdgpu, as the z order convention followed in linux is
opposite to how the plane
42 matches
Mail list logo
