Hi Christian,
I also checked move uvd fence memory into GTT bo as same as other IPs', but it
has ib test fail on Bonaire. so the patch uses
amdgpu_fence_driver_force_completion() to update fence seq as you suggestion.
Please review.
Thanks
JimQu
发件人:
otherwise, uvd block will be never powered up in ring begin_use()
callback. uvd ring test will be fail in resume in rumtime pm.
Change-Id: Ic623e789cc682ea07af228898f9aaf22511bbe20
Signed-off-by: Jim Qu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 2 ++
1 file changed, 2 insertions(+)
diff --g
Change-Id: I62720a2df92005c8838f2e6a505f7d4840903ebb
Signed-off-by: Jim Qu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
index 916e516..89d59fd
On 2017年12月15日 02:04, Alex Deucher wrote:
On Thu, Dec 14, 2017 at 7:03 AM, Christian König
wrote:
Instead of falling back to 2 level and very limited address space use
2+1 PD support and 128TB + 512GB of virtual address space.
v2: cleanup defines, rebase on top of level enum
Signed-off-by:
Roger and Chrisitian,
Correct me if I'm wrong, but It seems to me like a lot of the recent
changes to ttm_bo.c are to allow recursive reservation object locking in
the case of shared reservation objects, but only in certain functions
and with special arguments so it doesn't look like recursive
Hi.
On 12/14/2017 09:10 AM, Roger He wrote:
Change-Id: I0c6ece0decd18d30ccc94e5c7ca106d351941c62
Signed-off-by: Roger He
---
drivers/gpu/drm/ttm/ttm_bo.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.
Hi Dave,
Nothing too major here. A couple more ttm fixes for huge page and a kiq
fix for amdgpu.
The following changes since commit 90eeb3aa34831ff3d031589c0c24892eb8a07e51:
Merge tag 'drm-misc-fixes-2017-12-07' of
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes (2017-12-08 08:17:5
On Thu, Dec 14, 2017 at 7:03 AM, Christian König
wrote:
> Instead of falling back to 2 level and very limited address space use
> 2+1 PD support and 128TB + 512GB of virtual address space.
>
> v2: cleanup defines, rebase on top of level enum
>
> Signed-off-by: Christian König
> ---
> drivers/gpu
> This is for the DMA-buf mapping function, not the normal driver mmap
> implementation. So we can be pretty sure that the memory will be CPU accessed.
>
> The question in my mind is if it really is such a good idea to ping/pong the
> page when the GPU/CPU is accessing them. Not that I want to b
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Harry Wentland
> Sent: Wednesday, December 13, 2017 5:35 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Zuo, Jerry
> Subject: [PATCH 09/30] drm/amd/display: Fix rehook MST display not light
>
Am 14.12.2017 um 17:16 schrieb Michel Dänzer:
On 2017-12-14 09:07 AM, Christian König wrote:
Please CC Michel as well,
No need, I read the lists (just sometimes get a little swamped and take
time to catch up).
he originally commented that we should try to solve this in the DDX instead.
I do
Hi Yong,
How should deal with that or can you come up with a fix?
well that is the expected effect. So I don't see much we can do here.
Support for the parameter was added to be able to intentionally break
support for HMM/SVM for testing the fall back paths.
Didn't thought about ATC while e
Change-Id: Id522c1cbadb8c069720f4e64a31cff42cd014733
Signed-off-by: Yong Zhao
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index 709587d..93500e6 1006
On 2017-12-14 09:00 AM, Lvzhihong (ReJohn) wrote:
>
> By the way, I set "AccelMethod" to ”none”instead of “glamor”also makes
> the screen became normal.
Same reason as with ShadowPrimary.
> but OpenGL app run with Error:
AccelMethod none is only intended for bringing up new GPU hardware, not
On 2017-12-14 09:07 AM, Christian König wrote:
> Please CC Michel as well,
No need, I read the lists (just sometimes get a little swamped and take
time to catch up).
> he originally commented that we should try to solve this in the DDX instead.
I don't think a DDX driver is even involved in the
I tried the latest drm-next as of this morning and still had gfx corruption.
I added you to the watchers list for a JIRA ticket I opened about this.
Cheers,
Tom
From: Wentland, Harry
Sent: Thursday, December 14, 2017 10:41
To: StDenis, Tom; amd-gfx@lists.
On 2017-12-14 09:12 AM, Roger He wrote:
> Change-Id: I0c6571c2a64e6c5bdad80ccbcccb40eba1c20b4e
> Signed-off-by: Roger He
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 6 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 7 ++-
> 2 files changed, 11 insertions(+), 2 deletions(-)
>
Hi Christian,
I don't know much about the background. But according to my experiments,
as long as we change the vm size to 64G, ATC memory access on Raven will
fall apart. How should deal with that or can you come up with a fix?
Regards,
Yong
On 2017-12-14 03:47 AM, Christian König wrote:
On 2017-12-13 05:39 PM, Tom St Denis wrote:
> Would this fix the regression I found on Carrizo after the drm-next rebase?
>
This shouldn't have any functional impact. It was just a bit of unused code
that we missed cleaning up in a previous change.
Regarding the regression you found, the fallou
Hi
I am trying to use amdgpupro opencl on top of amdgpu and everything
seems to run fine except this OOPS that I get once per execution:
[ 120.180229] BUG: sleeping function called from invalid context at
/var/lib/jenkins/workspace/qt5122-dyspro/build/tmp/work-shared/qt5122/kernel-source/mm/slab
On Fri, Dec 8, 2017 at 3:10 PM, Alex Deucher wrote:
> Same as previous asics. This was not yet set for gfx9.
Ping?
>
> Signed-off-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 17 -
> drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 8
> 2 files changed, 20
Hi Christian,
Correctly, the problem really is that uvd fence memory is behind uvd firmware.
In generic case, uvd firmware and fence will be saved in adev->uvd.saved_bo. In
this issue, because of there is no uvd handles, so uvd firmware and fence
memory are not saved in amdgpu_uvd_suspend(). In
Hi Jim,
ah yes, we dropped that because it shouldn't be necessary any more on
amdgpu. The fences are written into a GTT BO and the content of that
should be preserved even over a suspend & resume cycle.
But there is an issue with that. Taking a look at
amdgpu_fence_driver_start_ring() we sti
On 12/14/2017 02:17 PM, Christian König wrote:
Am 14.12.2017 um 08:24 schrieb Thomas Hellstrom:
On 12/13/2017 09:55 PM, Thomas Hellstrom wrote:
Hi, Christian,
While this has probably already been committed, and looks like a
nice cleanup there are two things below I think needs fixing.
On 11
Hi Christian,
I remember the amdgpu_fence_driver_start_ring() function is called by
amdgpu_ring_init (), so the function should never be called in
amdgpu_device_resume().
Thanks
JimQu
-邮件原件-
发件人: Christian König [mailto:ckoenig.leichtzumer...@gmail.com]
发送时间: 2017年12月14日 20:57
收件人: Qu,
Am 14.12.2017 um 08:24 schrieb Thomas Hellstrom:
On 12/13/2017 09:55 PM, Thomas Hellstrom wrote:
Hi, Christian,
While this has probably already been committed, and looks like a nice
cleanup there are two things below I think needs fixing.
On 11/15/2017 01:31 PM, Christian König wrote:
There
Am 14.12.2017 um 12:38 schrieb Jim Qu:
otherwise, uvd block will be never powered up in ring begin_use()
callback. uvd ring test will be fail in resume in rumtime pm.
NAK, that should already be done by amdgpu_fence_driver_start_ring().
If this doesn't work please try to figure out why
amdgpu
otherwise, uvd block will be never powered up in ring begin_use()
callback. uvd ring test will be fail in resume in rumtime pm.
Change-Id: I71b6c00bad174c90e12628e6037dc04a4ff9d9f2
Signed-off-by: Jim Qu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 10 --
drivers/gpu/drm/amd/amdgpu/amdgp
Instead of falling back to 2 level and very limited address space use
2+1 PD support and 128TB + 512GB of virtual address space.
v2: cleanup defines, rebase on top of level enum
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu
Am 14.12.2017 um 12:38 schrieb Jim Qu:
Change-Id: I06e5460ece91e812cda28fb02a6b78676d921e18
Signed-off-by: Jim Qu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
b/drivers/gpu/drm/amd/
Change-Id: I06e5460ece91e812cda28fb02a6b78676d921e18
Signed-off-by: Jim Qu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
index 916e516..343b682
On 12/14/2017 02:16 AM, Liu, Monk wrote:
Andrey
You patch looks breaks the logic for SRIOV, please check function
"xgpu_ai_mailbox_flr_work"
This function manually triggers GPU_RECOVER by the will of hypervisor.
Your check of :
+ if (!amdgpu_gpu_recovery) {
+ DRM_INFO("GP
On 2017年12月14日 17:35, Christian König wrote:
Am 14.12.2017 um 10:22 schrieb Chunming Zhou:
v2:
remove SUBPTB member
v3:
remove last_level, use AMDGPU_VM_PTB directly instead.
Change-Id: Ic1f39d3bc853e9e4259d3e03a22920eda822eec5
Signed-off-by: Chunming Zhou
Reviewed-by: Christian Köni
Am 14.12.2017 um 10:22 schrieb Chunming Zhou:
v2:
remove SUBPTB member
v3:
remove last_level, use AMDGPU_VM_PTB directly instead.
Change-Id: Ic1f39d3bc853e9e4259d3e03a22920eda822eec5
Signed-off-by: Chunming Zhou
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.
Hi Thomas:
Really sorry for that and will keep that in mind.
If necessary, next time I will send cover letter to provide more background and
details.
Thanks
Roger(Hongbo.He)
-Original Message-
From: Thomas Hellstrom [mailto:tho...@shipmail.org]
Sent: Thursday, December 14, 201
v2:
remove SUBPTB member
v3:
remove last_level, use AMDGPU_VM_PTB directly instead.
Change-Id: Ic1f39d3bc853e9e4259d3e03a22920eda822eec5
Signed-off-by: Chunming Zhou
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 69 --
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 1
Am 14.12.2017 um 06:32 schrieb Chunming Zhou:
v2:
remove SUBPTB member
Change-Id: Ic1f39d3bc853e9e4259d3e03a22920eda822eec5
Signed-off-by: Chunming Zhou
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 70 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 12 ++
Am 14.12.2017 um 09:55 schrieb Thomas Hellstrom:
Hi, Christian,
On 12/14/2017 09:40 AM, Christian König wrote:
Hi Thomas,
sorry for that. Noted on the rest of that series as well that we need
to improve the commit messages. But this one somehow slipped through
because I discussed this change
Hi, Christian,
On 12/14/2017 09:40 AM, Christian König wrote:
Hi Thomas,
sorry for that. Noted on the rest of that series as well that we need
to improve the commit messages. But this one somehow slipped through
because I discussed this change previously internally with Roger.
That made the
Am 14.12.2017 um 08:19 schrieb Liu, Monk:
Problem with this is that amdgpu_check_soft_reset will not be called, this
function which prints which IP block was hung even when later we opt not to
recover.
I suggest instead to add a bool force_reset parameter to amdgpu_gpu_recover
which will over
NAK, that really circumvents the intention of the patch to adjust the
number of levels based on the vm_size.
Christian.
Am 14.12.2017 um 03:25 schrieb Yong Zhao:
Change-Id: Id522c1cbadb8c069720f4e64a31cff42cd014733
Signed-off-by: Yong Zhao
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 2 +-
Am 13.12.2017 um 20:44 schrieb Andrey Grodzovsky:
With introduction of amdgpu_gpu_recovery we don't need any more
to rely on amdgpu_lockup_timeout == 0 for disabling GPU reset.
Signed-off-by: Andrey Grodzovsky
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |
Hi Thomas,
sorry for that. Noted on the rest of that series as well that we need to
improve the commit messages. But this one somehow slipped through
because I discussed this change previously internally with Roger.
That made the change completely logical for me, but without this context
eve
Reviewed-by: Chunming Zhou as well.
On 2017年12月14日 16:20, Christian König wrote:
Here again a better commit message is needed. Just something like the
following:
This enables eviction of other per VM BOs during allocation and allows
reaping of deleted per VM BOs during CS again.
With that
Here again a better commit message is needed. Just something like the
following:
This enables eviction of other per VM BOs during allocation and allows
reaping of deleted per VM BOs during CS again.
With that fixed the patch is Reviewed-by: Christian König
.
Regards,
Christian.
Am 14.12.2
We need some commit message here. Something like this:
Allow eviction of BOs reserved by the caller when they are not part of
the current working set.
with that fixed the patch is Reviewed-by: Christian König
.
Thanks,
Christian.
Am 14.12.2017 um 09:10 schrieb Roger He:
Change-Id: I0c6ece
Change-Id: I0c6571c2a64e6c5bdad80ccbcccb40eba1c20b4e
Signed-off-by: Roger He
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 6 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 7 ++-
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b
Change-Id: I0c6ece0decd18d30ccc94e5c7ca106d351941c62
Signed-off-by: Roger He
---
drivers/gpu/drm/ttm/ttm_bo.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 098b22e..ba5b486 100644
--- a/drivers/gpu
Please CC Michel as well, he originally commented that we should try to
solve this in the DDX instead.
And BTW: Why don't we just do the migration during the mmap call?
Christian.
Am 13.12.2017 um 22:28 schrieb Li, Samuel:
Will do after some basic testing.
Sam
*From:*Deucher, Alexander
*Se
>With ShadowPrimary enabled, all normal X11 drawing is performed by the CPU,
>not the GPU.
>Does enabling ShadowPrimary also make OpenGL applications look correct?
>If not, it's most likely a Mesa or maybe LLVM issue.
Enableing ShadowPrimary, some OpenGL applications looks better. But som
50 matches
Mail list logo
