[PATCH 2/2] drm/amdgpu:256dw is enough for one ib_schedule

Change-Id: I1ee3258276868a753e536ae2d9ae1b12e7eaf791 Signed-off-by: Monk Liu --- drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c index

[PATCH 1/2] drm/amdgpu:fix gfx ib schedule

for GFX 8, originally we use double switch_buffer to prevents CE go ahead of DE, thus it can avoid VM fault in case of VM_flush not finish. but double SWITCH_BUFFER drops performance, and world switch preemption requires that only one SWITCH_BUFFER is needed at the end of DMAframe. to Pevent CE

Re: [PATCH 0/6] make ctx mgr global

Yeah, I wouldn't mind a patch renaming ctx to fence_context in the job and rign structure. This way we make it clear what is used here. Christian. Am 25.08.2016 um 05:38 schrieb Liu, Monk: Sorry, I don't mean ctx-id, I'm talking about "job->ctx", which is a atomic_64t value, and it is

Re: [PATCH 2/2] drm/amdgpu:256dw is enough for one ib_schedule

Well userspace is allowed to send any number of IBs down to this if I remember correctly. So we clearly need something depending on the number of IBs or reject submissions with to many IBs earlier in the CS. Otherwise we clearly open up a possible problem where userspace can trigger a ring

RE: [PATCH 2/2] drm/amdgpu:256dw is enough for one ib_schedule

But even user space will submit 10 ibs this submission, the calculate of 256*ibs is totally overflow, remember that ring buffer is only 4kb size -Original Message- From: Christian König [mailto:deathsim...@vodafone.de] Sent: Thursday, August 25, 2016 4:12 PM To: Liu, Monk

RE: [PATCH 0/6] make ctx mgr global

Yeah, I was already doing that -Original Message- From: Christian König [mailto:deathsim...@vodafone.de] Sent: Thursday, August 25, 2016 4:08 PM To: Liu, Monk ; Zhou, David(ChunMing) ; amd-gfx@lists.freedesktop.org Cc: Mao, David

Re: [PATCH 2/2] drm/amdgpu:256dw is enough for one ib_schedule

True indeed. Something like 256 + 32 * num_ibs (or even 16 * num_ibs??? Need to double check) should do as well. Christian. Am 25.08.2016 um 10:28 schrieb Liu, Monk: But even user space will submit 10 ibs this submission, the calculate of 256*ibs is totally overflow, remember that ring

Re: 答复: [PATCH 2/2] drm/amdgpu/vce3: add support for third vce ring

Reviewed-by: Christian König as well. Do we have any requirement to support ring 2 and 3 in the near future or was this set just for cleanup? Regards, Christian. Am 25.08.2016 um 02:03 schrieb Qu, Jim: These series Reivewed-by: JimQu Thanks JimQu

[PATCH xf86-video-ati 2/2] Don't override crtc parameter value in drmmode_flip_handler/abort

From: Michel Dänzer When overriding the crtc parameter value of the last pending CRTC, drmmode_clear_pending_flip would work on the wrong CRTC, and the last pending CRTC's flip_pending flag might never get cleared. This would prevent that CRTC from properly turning off

[PATCH xf86-video-ati 1/2] Also call drmmode_clear_pending_flip from radeon_scanout_flip_abort

From: Michel Dänzer Not doing so could break DPMS with TearFree. Reported-and-Tested-by: furkan on IRC Fixes: 9090309e057d ("Wait for pending flips to complete before turning off an output or CRTC") Signed-off-by: Michel Dänzer ---

Re: SDMA out-of-bounds write access of tiled surface

FYI, I've disabled SDMA texture copying for Carrizo in Mesa. The VM faults should no longer occur. Marek On Fri, Aug 5, 2016 at 3:22 PM, Mads wrote: > Just to update, R600_DEBUG=nodma is still needed when updating to > xorg-server 1.18.4, plasma 5.7.3 and linux 4.7.0, and libdrm,

RE: [PATCH 1/2] drm/amdgpu:fix gfx ib schedule

> -Original Message- > From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf > Of Monk Liu > Sent: Thursday, August 25, 2016 1:58 AM > To: amd-gfx@lists.freedesktop.org > Cc: Liu, Monk > Subject: [PATCH 1/2] drm/amdgpu:fix gfx ib schedule > > for GFX 8, originally we use

RE: [PATCH xf86-video-ati 1/2] Also call drmmode_clear_pending_flip from radeon_scanout_flip_abort

> -Original Message- > From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf > Of Michel Dänzer > Sent: Thursday, August 25, 2016 5:58 AM > To: amd-gfx@lists.freedesktop.org > Subject: [PATCH xf86-video-ati 1/2] Also call drmmode_clear_pending_flip > from

Re: SDMA out-of-bounds write access of tiled surface

Thank you for notifying :) Just curious, is there a way to enable them in the same way as disabling them is done with R600_DEBUG=nodma? Because, while desktop applications gets buggy, games and such does not trigger any artifacts, so normally I disable R600_DEBUG=nodma when gaming (as I've

Bind amdgpu to SR-IOV virtual function

Hello! I investigating the virtualisation abilities of current AMD FirePro hardware; specifically how to securely pass a share of a GPU to one application (a Rkt/ Docker container). I already read vfio.txt and pci-iov-howto.txt, but they do not answer my questions. I was unable to find

RE: [PATCH 3/3] drm/amd/amdgpu: Tidy up cz_dpm.c

> -Original Message- > From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf > Of Tom St Denis > Sent: Thursday, August 25, 2016 1:10 PM > To: amd-gfx@lists.freedesktop.org > Cc: StDenis, Tom > Subject: [PATCH 3/3] drm/amd/amdgpu: Tidy up cz_dpm.c > > Various minor

Re: Bind amdgpu to SR-IOV virtual function

On Thursday, 25 August 2016 11:44:08 CEST Alex Deucher wrote: > SR-IOV support is not yet upstream for Linux. Where do I ask about the abilities of the binary driver? Is there another mailinglist? --Dennis signature.asc Description: This is a digitally signed message part.

[PATCH 1/3] drm/amd/amdgpu: Fix memleak in cz_parse_power_table()

If one of the entries fails to be allocated then free all of the previous entries before freeing the array which holds their pointers. Signed-off-by: Tom St Denis --- drivers/gpu/drm/amd/amdgpu/cz_dpm.c | 2 ++ 1 file changed, 2 insertions(+) diff --git

[PATCH 2/3] drm/amd/amdgpu: Clean up memory leak in cz_dpm_init().

If init fails free up any allocated memory. Signed-off-by: Tom St Denis --- drivers/gpu/drm/amd/amdgpu/cz_dpm.c | 14 +- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/cz_dpm.c b/drivers/gpu/drm/amd/amdgpu/cz_dpm.c

Small fixes for cz_dpm.c

Various small fixes for cz_dpm.c. Patches #1/#2 deal with cleaning up the memory allocations if init fails. Patch #3 addresses various style/indenation issues. ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org

[PATCH 3/3] drm/amd/amdgpu: Tidy up cz_dpm.c

Various minor formatting changes. Signed-off-by: Tom St Denis --- drivers/gpu/drm/amd/amdgpu/cz_dpm.c | 31 +++ 1 file changed, 11 insertions(+), 20 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/cz_dpm.c

Re: Bind amdgpu to SR-IOV virtual function

On Thu, Aug 25, 2016 at 11:51 AM, Dennis Schridde wrote: > On Thursday, 25 August 2016 11:44:08 CEST Alex Deucher wrote: >> SR-IOV support is not yet upstream for Linux. > > Where do I ask about the abilities of the binary driver? Is there another > mailinglist?

Re: SDMA out-of-bounds write access of tiled surface

On 2016-08-25 20:43, Marek Olšák wrote: On Thu, Aug 25, 2016 at 3:36 PM, Mads wrote: Thank you for notifying :) Just curious, is there a way to enable them in the same way as disabling them is done with R600_DEBUG=nodma? Because, while desktop applications gets buggy, games

[PATCH xf86-video-ati] Also handle disabled CRTCs in drmmode_clear_pending_flip

From: Michel Dänzer If disabling a CRTC had to be deferred due to a pending flip in drmmode_crtc_dpms, there may no longer be any outputs associated with the CRTC when we get here. So we have to check for !crtc->enabled and call drmmode_crtc_dpms in that case as well.

RE: [PATCH 1/2] drm/amdgpu:fix gfx ib schedule

But for VI. My patch will reduce those 5 redundant SB and one SB can always use ping-pong buffer, so the performance looks raised around 5%. BR Monk -Original Message- From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of Liu, Monk Sent: Friday, August 26, 2016

RE: [PATCH 1/2] drm/amdgpu:fix gfx ib schedule

Not needed at least in windows kmd, I don't know if it is out of what reason, with my guess: 1, CI doesn’t support world switch, so no need for the SWITCH_BUFFER at end (only one SB at end is for world switch). 2, I don’t know if that limit can also applied on CI (limit is CE can at most ahead