RE: [PATCH] drm/amdgpu:fix DMAframe for GFX8

Christian, I'm not going to argue with you about policy or interface protocol , cuz those things would block us from implementing new features, instead they should be changed if they are not fit to new requirement, isn't it ? See my answers in lines, thanks ! -Original Message-

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

On 2016年08月24日 17:39, Christian König wrote: Am 24.08.2016 um 11:33 schrieb zhoucm1: On 2016年08月18日 16:15, Christian König wrote: NAK to the whole approach. If we want to share dependencies in the form of fences between devices and especially processes we must use android fences and the

Re: [PATCH] drm/amdgpu: throttle buffer migrations at CS using a fixed MBps limit

On Wed, Aug 24, 2016 at 4:49 AM, zhoucm1 wrote: > Looks very good to me, binding time and byte is good idea according free > vram. > Did you test more games for your algorithm? No, I only tested one game. Its behavior is that the game wants to use 50% more VRAM than I have.

[PATCH] drm/amdgpu: refine uvd gate logic for CI.

uvd dpm will be controlled by uvd. dpm just disable uvd dpm in case of suspend when play video. due to the new logic of uvd_begin_use/end_use, if disable uvd dpm in late init, will have no chance to enable uvd dpm after resume until play video again. Change-Id:

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

Am 24.08.2016 um 11:33 schrieb zhoucm1: On 2016年08月18日 16:15, Christian König wrote: NAK to the whole approach. If we want to share dependencies in the form of fences between devices and especially processes we must use android fences and the sync file framework. Then if we want to share

Re: Random short freezes due to TTM buffer migrations

On Wed, Aug 24, 2016 at 9:56 AM, Christian König wrote: > Am 23.08.2016 um 21:55 schrieb Marek Olšák: >> >> On Tue, Aug 23, 2016 at 8:01 PM, Marek Olšák wrote: >>> >>> On Thu, Aug 18, 2016 at 10:52 AM, Christian König >>>

RE: [PATCH] drm/amdgpu:fix DMAframe for GFX8

> “Checking if preamble CE ib could be skipped” itself is a classic > behavior of ring specific code, only gfx ring have preamble CE ib … > That isn't correct. The preamble IB feature can be used for Compute and DMA engines as well. [ML] I'm fuzzy preamble CE ib is only mean for gfx and

RE: [PATCH] drm/amdgpu:fix DMAframe for GFX8

Christian, 1,umd should insert always three IB each job, this is guaranteed in windows and catalyst driver, and this is a must for virtualization, Besides, how to implement virtualization is not lead by driver, instead we should follow CP logic, and you don't have any choice of how to impl it

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

On 2016年08月18日 16:15, Christian König wrote: NAK to the whole approach. If we want to share dependencies in the form of fences between devices and especially processes we must use android fences and the sync file framework. Then if we want to share semaphore between devices and processes,

Re: [PATCH] drm/amdgpu:fix DMAframe for GFX8

Am 24.08.2016 um 10:29 schrieb Liu, Monk: Christian, 1,umd should insert always three IB each job, this is guaranteed in windows and catalyst driver, and this is a must for virtualization, Besides, how to implement virtualization is not lead by driver, instead we should follow CP logic, and

RE: [PATCH] drm/amdgpu:fix DMAframe for GFX8

Some amends for why preamble CE ib is a must: Previous thread doesn’t explain the major reason of why CE preamble IB is a must: In Preamble CE IB, there will be many load_ce_ram package there, and they are responsible for restore the scenario, e.g. from a context switch When World Switch

Re: [PATCH] drm/amdgpu:fix DMAframe for GFX8

>>Briefly speaking: ring buffer should be fixed at some certain pattern so that CP hw can rely on this pattern to get/set data *in ring buffer directly* for the purpose of world switch! In this case the kernel driver must make sure that the requirements of the hardware are fulfilled for this.

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

Am 24.08.2016 um 12:01 schrieb zhoucm1: On 2016年08月24日 17:39, Christian König wrote: Am 24.08.2016 um 11:33 schrieb zhoucm1: On 2016年08月18日 16:15, Christian König wrote: NAK to the whole approach. If we want to share dependencies in the form of fences between devices and especially

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

David, No matter what's the initial purpose of this patch is, I think this patch is needed, otherwise context switch judgment will be incorrect , e.g. process1 and process2 can both have a context id 99, and that will Lead to incorrect skipping of PREAMBLE CE IB BR monk -Original

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

Not of much use at the moment (we don't really use the second ring either), but may be useful later. Signed-off-by: Alex Deucher --- drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c | 4 ++--

[PATCH 1/2] drm/amdgpu: track the number of vce rings

Rather than using a hardcoded value. This allows different versions to expose more or less rings. No functional change. Signed-off-by: Alex Deucher --- drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 2 +-

[pull] radeon and amdgpu drm-next-4.9

Hi Dave, First drm-next pull for radeon and amdgpu for 4.9. Highlights: - powerplay support for iceland asics - improved GPU reset (both full asic and per block) - UVD and VCE powergating for CZ and ST - VCE clockgating for CZ and ST - Support for pre-initialized (e.g., zeroed) vram buffers -

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

These series Reivewed-by: JimQu Thanks JimQu 发件人: amd-gfx 代表 Alex Deucher 发送时间: 2016年8月25日 6:31:34 收件人: amd-gfx@lists.freedesktop.org 抄送: Deucher, Alexander 主题: [PATCH 2/2]

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

Sorry, I don't mean ctx-id, I'm talking about "job->ctx", which is a atomic_64t value, and it is initiated from entity->fence_context, As long as fence_context is unique cross whole system, we are safe to use it to judge context switch, I checked again the code, this fence_context is already

Re: cannot send email to amd-gfx

On 24/08/16 03:05 PM, Michel Dänzer wrote: > On 24/08/16 01:11 PM, Liu, Monk wrote: >> Hi Alex >> >> >> >> I tried use git send-email to send patch to amd-gfx, but seems it failed, >> >> So I use git send-email to send patch to myself, it’s okay. >> >> >> >> And I forward the patch mail to

Re: [PATCH] drm/amdgpu: throttle buffer migrations at CS using a fixed MBps limit

+ struct mutexlock; I haven't completely checked the code, but it looked like you just made a bunch of calculations while holding the lock (e.g. no sleeping). So it might be more appropriate to use a spinlock here (less overhead). Apart from that this looks really

Re: [PATCH] drm/amdgpu:fix DMAframe for GFX8

Am 24.08.2016 um 05:42 schrieb Monk Liu: 1,drop inserting double SWITCH_BUFFERS scheme, which impacts performance, because double SWITCH_BUFFER actaully doesn't switch buffer, so the CE's ping-pong buffer is not used at all. Now only insert one SWITCH_BUFFERS at the bottom of each GFX dmaframe.

[PATCH] drm/amdgpu: avoid a possible array overflow

When looking up the connector type make sure the index is valid. Avoids a later crash if we read past the end of the array. Signed-off-by: Alex Deucher Cc: sta...@vger.kernel.org --- drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c | 6 ++ 1 file changed, 6

[PATCH] drm/amdgpu: skip TV/CV in display parsing

No asics supported by amdgpu support analog TV. Workaround for bug: https://bugs.freedesktop.org/show_bug.cgi?id=97460 Signed-off-by: Alex Deucher Cc: sta...@vger.kernel.org --- drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c | 7 +++ 1 file changed, 7 insertions(+)

Re: [PATCH] drm/amdgpu: avoid a possible array overflow

Am 24.08.2016 um 18:34 schrieb Alex Deucher: When looking up the connector type make sure the index is valid. Avoids a later crash if we read past the end of the array. Signed-off-by: Alex Deucher Reviewed-by: Christian König . Cc:

Re: [PATCH] drm/amdgpu: skip TV/CV in display parsing

Am 24.08.2016 um 19:06 schrieb Alex Deucher: No asics supported by amdgpu support analog TV. Workaround for bug: https://bugs.freedesktop.org/show_bug.cgi?id=97460 Signed-off-by: Alex Deucher Why in the world would any BIOS amdgpu has to deal with have such

[pull] radeon and amdgpu drm-fixes-4.8

Hi Dave, radeon and amdgpu fixes for 4.8. Nothing major: - fix a performance regression due to the LRU changes in 4.7 - 32 bit fixes - fix a PLL regression - misc bug fixes The following changes since commit 91d62d9f30206be6f7749a0e6f7fa58c6d70c702: Merge branch 'drm-fixes-4.8' of

Re: cannot send email to amd-gfx

On Wed, Aug 24, 2016 at 12:11 AM, Liu, Monk wrote: > Hi Alex > > > > I tried use git send-email to send patch to amd-gfx, but seems it failed, > > So I use git send-email to send patch to myself, it’s okay. > > > > And I forward the patch mail to amd-gfx@lists.freedesktop.org

[PATCH] drm/amdgpu: throttle buffer migrations at CS using a fixed MBps limit (v2)

From: Marek Olšák The old mechanism used a per-submission limit that didn't take previous submissions within the same time frame into account. It also filled VRAM slowly when VRAM usage dropped due to a big eviction or buffer deallocation. This new method establishes a