Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On Fri, Apr 21, 2017 at 12:59 PM, Ville Syrjälä wrote: > On Fri, Apr 21, 2017 at 10:49:49AM -0400, Ilia Mirkin wrote: >> On Fri, Apr 21, 2017 at 3:58 AM, Gerd Hoffmann wrote: >> > While working on graphics support for virtual machines on ppc64

[PATCH 5/6] drm/amdgpu: guarantee bijective mapping of ring ids for LRU v3

Depending on usage patterns, the current LRU policy may create a non-injective mapping between userspace ring ids and kernel rings. This behaviour is undesired as apps that attempt to fill all HW blocks would be unable to reach some of them. This change forces the LRU policy to create bijective

[PATCH] LRU map compute/SDMA user ring ids to kernel ring ids v2

V2 updates: * Rebased * All patches now have r-b Second part of the split of the series: Add support for high priority scheduling in amdgpu v8 These patches should be close to being good enough to land. The first two patches are simple fixes I've ported from the ROCm branch. These still need

[PATCH 1/6] drm/amdgpu: condense mqd programming sequence

The MQD structure matches the reg layout. Take advantage of this to simplify HQD programming. Note that the ACTIVE field still needs to be programmed last. Suggested-by: Felix Kuehling Reviewed-by: Felix Kuehling Signed-off-by: Andres Rodriguez

[PATCH 3/6] drm/amdgpu: untie user ring ids from kernel ring ids v4

Add amdgpu_queue_mgr, a mechanism that allows disjointing usermode's ring ids from the kernel's ring ids. The queue manager maintains a per-file descriptor map of user ring ids to amdgpu_ring pointers. Once a map is created it is permanent (this is required to maintain FIFO execution guarantees

[PATCH 4/6] drm/amdgpu: implement lru amdgpu_queue_mgr policy for compute v4

Use an LRU policy to map usermode rings to HW compute queues. Most compute clients use one queue, and usually the first queue available. This results in poor pipe/queue work distribution when multiple compute apps are running. In most cases pipe 0 queue 0 is the only queue that gets used. In

Re: [PATCH 05/17] drm/amdgpu: unify MQD programming sequence for kfd and amdgpu v2

On 17-04-21 05:21 PM, Andres Rodriguez wrote: > Hey Felix, > > I wanted to confirm my understanding of your email. > > > Reading the updated shadow_wptr > > You are referring to the copy_from_user() call, correct? Just wanted > to make sure I didn't misunderstand and you meant the write to >

Re: [PATCH 05/17] drm/amdgpu: unify MQD programming sequence for kfd and amdgpu v2

Hey Felix, I wanted to confirm my understanding of your email. > Reading the updated shadow_wptr You are referring to the copy_from_user() call, correct? Just wanted to make sure I didn't misunderstand and you meant the write to mmCP_HQD_PQ_WPTR. > after the doorbell has been enabled in

Re: [PATCH 05/17] drm/amdgpu: unify MQD programming sequence for kfd and amdgpu v2

I spotted a potential race condition in this change: Reading the updated shadow_wptr must happen after the doorbell has been enabled in the HQD. Once the doorbell is enabled, the CP will capture any further submissions to the queue. If you activate the doorbell later (in mqd_commit), the CP would

Re: [PATCH split 2/3] LRU map compute/SDMA user ring ids to kernel ring ids

Patches 1 and 2 are Reviewed-by: Felix Kuehling Note that we're making another change to this programming sequence in the upcoming release. Conceptually the MQD represents the state of an inactive queue. So the CP_HQD_ACTIVE and DOORBELL_EN bits should be 0 in the MQD.

[PATCH 14/17] drm/amdgpu: allocate queues horizontally across pipes

Pipes provide better concurrency than queues, therefore we want to make sure that apps use queues from different pipes whenever possible. Optimize for the trivial case where an app will consume rings in order, therefore we don't want adjacent rings to belong to the same pipe. Reviewed-by: Edward

[PATCH 16/17] drm/amdgpu: avoid KIQ clashing with compute or KFD queues v2

Instead of picking an arbitrary queue for KIQ, search for one according to policy. The queue must be unused. Also report the KIQ as an unavailable resource to KFD. In testing I ran into KCQ initialization issues when using pipes 2/3 of MEC2 for the KIQ. Therefore the policy disallows grabbing

[PATCH 17/17] drm/amdgpu: new queue policy, take first 2 queues of each pipe v2

Instead of taking the first pipe and giving the rest to kfd, take the first 2 queues of each pipe. Effectively, amdgpu and amdkfd own the same number of queues. But because the queues are spread over multiple pipes the hardware will be able to better handle concurrent compute workloads. amdgpu

[PATCH 15/17] drm/amdgpu: remove hardcoded queue_mask in PACKET3_SET_RESOURCES

The assumption that we are only using the first pipe no longer holds. Instead, calculate the queue_mask from the queue_bitmap. Acked-by: Felix Kuehling Signed-off-by: Andres Rodriguez --- drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 20

[PATCH 08/17] drm/radeon: take ownership of pipe initialization

Take ownership of pipe initialization away from KFD. Note that hpd_eop_gpu_addr was already large enough to accomodate all pipes. Reviewed-by: Edward O'Callaghan Reviewed-by: Felix Kuehling Acked-by: Christian König

[PATCH 11/17] drm/amdgpu: teach amdgpu how to enable interrupts for any pipe v3

The current implementation is hardcoded to enable ME1/PIPE0 interrupts only. This patch allows amdgpu to enable interrupts for any pipe of ME1. v2: added gfx9 support v3: use soc15_grbm_select for gfx9 Acked-by: Felix Kuehling Signed-off-by: Andres Rodriguez

[PATCH 12/17] drm/amdkfd: allow split HQD on per-queue granularity v5

Update the KGD to KFD interface to allow sharing pipes with queue granularity instead of pipe granularity. This allows for more interesting pipe/queue splits. v2: fix overflow check for res.queue_mask v3: fix shift overflow when setting res.queue_mask v4: fix comment in is_pipeline_enabled() v5:

[PATCH] Improve pipe split between amdgpu and amdkfd v4

V4 updates: * Rebased onto latest 4.12-wip (ba16d6c), since I got test reports that the patch series failed to apply V3 updates: * Fixed kfd set resources grabbing MEC1 queues * kfdtest now passes on Kaveri with the amdgpu or radeon driver V2 updates: * Fixed wrong HPD offset in

[PATCH 13/17] drm/amdgpu: remove duplicate magic constants from amdgpu_amdkfd_gfx*.c

This information is already available in adev. Reviewed-by: Edward O'Callaghan Reviewed-by: Felix Kuehling Acked-by: Christian König Signed-off-by: Andres Rodriguez ---

[PATCH 09/17] drm/amdgpu: take ownership of per-pipe configuration v3

Make amdgpu the owner of all per-pipe state of the HQDs. This change will allow us to split the queues between kfd and amdgpu with a queue granularity instead of pipe granularity. This patch fixes kfd allocating an HDP_EOP region for its 3 pipes which goes unused. v2: support for gfx9 v3: fix

[PATCH 10/17] drm/amdgpu: allow split of queues with kfd at queue granularity v4

Previously the queue/pipe split with kfd operated with pipe granularity. This patch allows amdgpu to take ownership of an arbitrary set of queues. It also consolidates the last few magic numbers in the compute initialization process into mec_init. v2: support for gfx9 v3: renamed

[PATCH 06/17] drm/amdgpu: fix kgd_hqd_load failing to update shadow_wptr

The return value from copy_form_user is 0 for the success case. Reviewed-by: Felix Kuehling Signed-off-by: Andres Rodriguez --- drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v8.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH 07/17] drm/amdgpu: rename rdev to adev

Rename straggler instances of r(adeon)dev to a(mdgpu)dev Reviewed-by: Edward O'Callaghan Reviewed-by: Felix Kuehling Acked-by: Christian König Signed-off-by: Andres Rodriguez ---

[PATCH 03/17] drm/amdgpu: detect timeout error when deactivating hqd

Handle HQD deactivation timeouts instead of ignoring them. Reviewed-by: Edward O'Callaghan Acked-by: Christian König Acked-by: Felix Kuehling Signed-off-by: Andres Rodriguez ---

[PATCH 02/17] drm/amdgpu: refactor MQD/HQD initialization v3

The MQD programming sequence currently exists in 3 different places. Refactor it to absorb all the duplicates. The success path remains mostly identical except for a slightly different order in the non-kiq case. This shouldn't matter if the HQD is disabled. The error handling paths have been

[PATCH 01/17] drm/amdgpu: clarify MEC_HPD_SIZE is specific to a gfx generation

Rename MEC_HPD_SIZE to GFXN_MEC_HPD_SIZE to clarify it is specific to a gfx generation. Signed-off-by: Andres Rodriguez --- drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c | 11 +-- drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 15 +++

[PATCH 04/17] drm/amdgpu: remove duplicate definition of cik_mqd

The gfxv7 contains a slightly different version of cik_mqd called bonaire_mqd. This can introduce subtle bugs if fixes are not applied in both places. Reviewed-by: Edward O'Callaghan Acked-by: Christian König Acked-by: Felix Kuehling

Re: Pageflip fixes for the amd dal/dc staging tree.

On 2017-04-21 12:23 PM, Mario Kleiner wrote: Hi These two patches were written and tested against Harry's hwentland amd-staging-dc-drm-next branch from a few days ago. Not sure if that is the right one to base dal/dc patches against, but it looks recent and active enough? Yes, I suggest you

Re: [PATCH] dmr/amdgpu: Fix wrongly unref of BO

On 17-04-21 01:01 PM, Christian König wrote: > Am 21.04.2017 um 17:43 schrieb Felix Kuehling: >> On 17-04-21 03:11 AM, Christian König wrote: >>> Hi Alex, >>> No. For the current source code, I think the premap and no-op is not working. >>> Indeed, we don't set bo->mem.bus.addr in

Re: [PATCH 5/5] drm/amdgpu: add limitation for dedicated vm number

Am 21.04.2017 um 12:05 schrieb Chunming Zhou: Change-Id: Ie5958cf6dbdc1c8278e61d9158483472d6f5c6e3 Signed-off-by: Chunming Zhou That patch should come earlier in the series. --- drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 +

Re: [PATCH 4/5] drm/amdgpu: implement grab dedicated vmid

Am 21.04.2017 um 12:05 schrieb Chunming Zhou: Change-Id: I64da2701c9fdcf986afb90ba1492a78d5bef1b6c Signed-off-by: Chunming Zhou --- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 60 ++ 1 file changed, 60 insertions(+) diff --git

Re: [PATCH 3/5] drm/amdgpu: add context flags for dedicated vmid reqest

Am 21.04.2017 um 12:05 schrieb Chunming Zhou: ctx_alloc will check dedicated flag for its process by this flag. Change-Id: I5f80dc39dc9d44660a96a2b710b0dbb4d3b9039d Signed-off-by: Chunming Zhou --- drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 9 --

Re: [PATCH 1/5] drm/amdgpu: handle flags when context alloc

Am 21.04.2017 um 12:05 schrieb Chunming Zhou: Change-Id: I652d89200c38a238ff50092107fa1ee31317728a Signed-off-by: Chunming Zhou Reviewed-by: Christian König for this one. --- drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 9 ++--- 1 file

Re: [PATCH 0/5] *** Dedicated vmid per process ***

Am 21.04.2017 um 18:27 schrieb Deucher, Alexander: -Original Message- From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of Chunming Zhou Sent: Friday, April 21, 2017 6:06 AM To: amd-gfx@lists.freedesktop.org Cc: Zhou, David(ChunMing) Subject: [PATCH 0/5] ***

Re: [PATCH] drm: Harmonize CIK ASIC support in radeon and amdgpu (v2)

__setup doesn't work in modules. s8250_options is only compiled if the driver is not a module. I came up with a different way to parse another module's options. But I can't get the commandline that I would parse in that way: @@ -787,12 +793,45 @@ long amdgpu_drm_ioctl(struct file *filp,

Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On Fri, Apr 21, 2017 at 10:49:49AM -0400, Ilia Mirkin wrote: > On Fri, Apr 21, 2017 at 3:58 AM, Gerd Hoffmann wrote: > > While working on graphics support for virtual machines on ppc64 (which > > exists in both little and big endian variants) I've figured the comments > > for

RE: [PATCH 0/5] *** Dedicated vmid per process ***

> -Original Message- > From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf > Of Chunming Zhou > Sent: Friday, April 21, 2017 6:06 AM > To: amd-gfx@lists.freedesktop.org > Cc: Zhou, David(ChunMing) > Subject: [PATCH 0/5] *** Dedicated vmid per process *** > > The current

Pageflip fixes for the amd dal/dc staging tree.

Hi These two patches were written and tested against Harry's hwentland amd-staging-dc-drm-next branch from a few days ago. Not sure if that is the right one to base dal/dc patches against, but it looks recent and active enough? They fix pageflip scheduling to always flip at the right target

[PATCH 2/2] drm/amd/display: Prevent premature pageflip when comitting in vblank.

Make sure we do not program a hw pageflip inside vblank 'n' iff the atomic flip is comitted while inside the same vblank 'n'. We must defer such a flip by one refresh cycle to vblank 'n+1'. Without this, pageflips programmed via X11 GLX_OML_sync_control extensions glXSwapBuffersMscOML(...,

[PATCH 1/2] drm/amd/display: Fix race between vblank irq and pageflip irq.

Since DC now uses CRTC_VERTICAL_INTERRUPT0 as VBLANK irq trigger and vblank interrupts actually happen earliest at start of vblank, instead of a bit before vblank, we no longer need some of the fudging logic to deal with too early vblank irq handling (grep for lb_vblank_lead_lines). This itself

RE: [PATCH 1/3] drm/amdgpu: fix indent

> -Original Message- > From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf > Of Roger.He > Sent: Friday, April 21, 2017 3:07 AM > To: amd-gfx@lists.freedesktop.org > Cc: Zhou, David(ChunMing); He, Hongbo > Subject: [PATCH 1/3] drm/amdgpu: fix indent > > Change-Id:

Re: [PATCH] dmr/amdgpu: Fix wrongly unref of BO

On 17-04-21 03:11 AM, Christian König wrote: > Hi Alex, > >> No. For the current source code, I think the premap and no-op is not >> working. >> > Indeed, we don't set bo->mem.bus.addr in amdgpu_ttm_io_mem_reserve() > any more. Felix will probably want to fix that for the KFD branch. I vaguely

Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

Thanks, Christian for adding me. On 2017-04-21 09:27 AM, Christian König wrote: Adding Harry to this mail thread as well, cause is one of the people really affected by this. Christian. Am 21.04.2017 um 15:21 schrieb Christian König: Am 21.04.2017 um 15:12 schrieb Gerd Hoffmann: Hi,

Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On Fri, Apr 21, 2017 at 3:58 AM, Gerd Hoffmann wrote: > While working on graphics support for virtual machines on ppc64 (which > exists in both little and big endian variants) I've figured the comments > for various drm fourcc formats in the header file don't match reality. > >

Re: [PATCH] drm/amdgpu: increase gtt size to 3GB by default v2

On Fri, Apr 21, 2017 at 4:43 AM, Chunming Zhou wrote: > v2: address Alex's comment, add AMDGPU_DEFAULT_GTT_SIZE_MB. > > Change-Id: I0417651a8e6fd23b28f9b30a110a196c332e2d03 > Signed-off-by: Chunming Zhou Reviewed-by: Alex Deucher

Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

Adding Harry to this mail thread as well, cause is one of the people really affected by this. Christian. Am 21.04.2017 um 15:21 schrieb Christian König: Am 21.04.2017 um 15:12 schrieb Gerd Hoffmann: Hi, "native" to me feels more like "native to the GPU" since these things really are

Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

Am 21.04.2017 um 15:12 schrieb Gerd Hoffmann: Hi, "native" to me feels more like "native to the GPU" since these things really are tied to the GPU not the CPU. That's also why I went with the explicit endianness originally so that the driver could properly declare what the GPU supports.

Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

Hi, > > "native" to me feels more like "native to the GPU" since these things > > really are tied to the GPU not the CPU. That's also why I went with the > > explicit endianness originally so that the driver could properly declare > > what the GPU supports. > And to be honest I would really

Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

Am 21.04.2017 um 13:49 schrieb Ville Syrjälä: On Fri, Apr 21, 2017 at 02:40:18PM +0300, Pekka Paalanen wrote: On Fri, 21 Apr 2017 14:08:04 +0300 Ville Syrjälä wrote: On Fri, Apr 21, 2017 at 11:50:18AM +0200, Gerd Hoffmann wrote: On Fr, 2017-04-21 at 12:25

RE: [PATCH 3/3] drm/amdgpu: fix gpu reset issue

Thank you! -Original Message- From: Christian König [mailto:deathsim...@vodafone.de] Sent: Friday, April 21, 2017 7:47 PM To: He, Hongbo; amd-gfx@lists.freedesktop.org Cc: Zhou, David(ChunMing) Subject: Re: [PATCH 3/3] drm/amdgpu: fix gpu reset issue See amdgpu_gpu_reset(): >

Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On Fri, Apr 21, 2017 at 02:40:18PM +0300, Pekka Paalanen wrote: > On Fri, 21 Apr 2017 14:08:04 +0300 > Ville Syrjälä wrote: > > > On Fri, Apr 21, 2017 at 11:50:18AM +0200, Gerd Hoffmann wrote: > > > On Fr, 2017-04-21 at 12:25 +0300, Ville Syrjälä wrote: > > > >

Re: [PATCH] drm/amdgpu: fix no-vmid job

Am 21.04.2017 um 12:00 schrieb Chunming Zhou: [ 132.036658] amdgpu :22:00.0: VM IB without ID [ 132.036709] [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) [ 132.036755] [drm:amd_sched_main [amdgpu]] *ERROR* Failed to run job! root cause is fence is signaled during sync

Re: [PATCH 3/3] drm/amdgpu: fix gpu reset issue

See amdgpu_gpu_reset(): /* block scheduler */ for (i = 0; i < AMDGPU_MAX_RINGS; ++i) { struct amdgpu_ring *ring = adev->rings[i]; if (!ring) continue; kthread_park(ring->sched.thread);

Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On Fri, 21 Apr 2017 14:08:04 +0300 Ville Syrjälä wrote: > On Fri, Apr 21, 2017 at 11:50:18AM +0200, Gerd Hoffmann wrote: > > On Fr, 2017-04-21 at 12:25 +0300, Ville Syrjälä wrote: > > > On Fri, Apr 21, 2017 at 09:58:24AM +0200, Gerd Hoffmann wrote: > > > >

Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

Hi, > > I personally find "native" more intuitive, but at the end of the day I > > don't mind much. If people prefer "host" over "native" I'll change it. > > "native" to me feels more like "native to the GPU" since these things > really are tied to the GPU not the CPU. Ok, then maybe "host"

Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On Fri, Apr 21, 2017 at 11:50:18AM +0200, Gerd Hoffmann wrote: > On Fr, 2017-04-21 at 12:25 +0300, Ville Syrjälä wrote: > > On Fri, Apr 21, 2017 at 09:58:24AM +0200, Gerd Hoffmann wrote: > > > While working on graphics support for virtual machines on ppc64 (which > > > exists in both little and

Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On Fri, Apr 21, 2017 at 11:50:18AM +0200, Gerd Hoffmann wrote: > On Fr, 2017-04-21 at 12:25 +0300, Ville Syrjälä wrote: > > On Fri, Apr 21, 2017 at 09:58:24AM +0200, Gerd Hoffmann wrote: > > > While working on graphics support for virtual machines on ppc64 (which > > > exists in both little and

[PATCH 5/5] drm/amdgpu: add limitation for dedicated vm number

Change-Id: Ie5958cf6dbdc1c8278e61d9158483472d6f5c6e3 Signed-off-by: Chunming Zhou --- drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 10 ++ 3 files changed, 12

[PATCH 2/5] drm/amdgpu: add dedicated vmid field in vm struct

Change-Id: Id728e20366c8a1ae90d4e901dc80e136e2a613bb Signed-off-by: Chunming Zhou --- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 17 - drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 2 ++ 2 files changed, 18 insertions(+), 1 deletion(-) diff --git

[PATCH 3/5] drm/amdgpu: add context flags for dedicated vmid reqest

ctx_alloc will check dedicated flag for its process by this flag. Change-Id: I5f80dc39dc9d44660a96a2b710b0dbb4d3b9039d Signed-off-by: Chunming Zhou --- drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 9 -- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 50

[PATCH 0/5] *** Dedicated vmid per process ***

The current kernel implementation, which grabs the idle VMID from pool when emitting the job may: The back-to-back submission from one process could use different VMID. The submission to different queues from single process could use different VMID It works well in most case but cannot

[PATCH 4/5] drm/amdgpu: implement grab dedicated vmid

Change-Id: I64da2701c9fdcf986afb90ba1492a78d5bef1b6c Signed-off-by: Chunming Zhou --- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 60 ++ 1 file changed, 60 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c

[PATCH 1/5] drm/amdgpu: handle flags when context alloc

Change-Id: I652d89200c38a238ff50092107fa1ee31317728a Signed-off-by: Chunming Zhou --- drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c

[PATCH] drm/amdgpu: fix no-vmid job

[ 132.036658] amdgpu :22:00.0: VM IB without ID [ 132.036709] [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) [ 132.036755] [drm:amd_sched_main [amdgpu]] *ERROR* Failed to run job! root cause is fence is signaled during sync transfer. Change-Id:

RE: [PATCH 3/3] drm/amdgpu: fix gpu reset issue

> During GPU reset, IOCTL still submit command to GPU. No it won't. We disable the GPU scheduler during GPU reset, so that isn't an issue. Could you point out the related code? Thanks. Thanks Roger(Hongbo.He) -Original Message- From: Christian König

Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On Fr, 2017-04-21 at 12:25 +0300, Ville Syrjälä wrote: > On Fri, Apr 21, 2017 at 09:58:24AM +0200, Gerd Hoffmann wrote: > > While working on graphics support for virtual machines on ppc64 (which > > exists in both little and big endian variants) I've figured the comments > > for various drm fourcc

Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On Fri, Apr 21, 2017 at 11:38:28AM +0200, Gerd Hoffmann wrote: > Hi, > > > > Leaving the yuv formats as-is. I have no idea if and how those are used > > > on bigendian machines. > > > just an idea - since we are not sure how the remaining formats are being > > used, should those be marked

Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

Hi, > > Leaving the yuv formats as-is. I have no idea if and how those are used > > on bigendian machines. > just an idea - since we are not sure how the remaining formats are being > used, should those be marked somehow uncertain whether they are little > or native endian? ATM the yuv don't

Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On Fri, Apr 21, 2017 at 09:58:24AM +0200, Gerd Hoffmann wrote: > While working on graphics support for virtual machines on ppc64 (which > exists in both little and big endian variants) I've figured the comments > for various drm fourcc formats in the header file don't match reality. > > Comments

Re: [PATCH] drm/amdgpu: increase gtt size to 3GB by default v2

Am 21.04.2017 um 10:43 schrieb Chunming Zhou: v2: address Alex's comment, add AMDGPU_DEFAULT_GTT_SIZE_MB. Change-Id: I0417651a8e6fd23b28f9b30a110a196c332e2d03 Signed-off-by: Chunming Zhou Reviewed-by: Christian König ---

RE: [PATCH 3/3] drm/amdgpu: fix gpu reset issue

Hi Christian: During GPU reset, IOCTL still submit command to GPU. That will result in lots of strange problems when we test this feature. I have no better idea to handle this case. At that time, I have tried with return error directly rather than waiting GPU reset completion. But that

Re: [PATCH 3/3] drm/amdgpu: fix gpu reset issue

Hi Roger, Could you try to move 'id->current_gpu_reset_count = atomic_read(>gpu_reset_counter);' in amdgpu_vm_grab_id to no_flush_needed label. Regards, David Zhou On 2017年04月21日 16:27, Christian König wrote: NAK, that is exactly what we wanted to avoid. We used to have an exclusive lock

[PATCH] drm/amdgpu: increase gtt size to 3GB by default v2

v2: address Alex's comment, add AMDGPU_DEFAULT_GTT_SIZE_MB. Change-Id: I0417651a8e6fd23b28f9b30a110a196c332e2d03 Signed-off-by: Chunming Zhou --- drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 + drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c | 3 ++-

Re: [PATCH 2/2] drm/amdgpu: increase gtt size to 3GB by default

On 2017年04月20日 20:58, Christian König wrote: Am 20.04.2017 um 14:43 schrieb Alex Deucher: On Wed, Apr 19, 2017 at 11:47 PM, Chunming Zhou wrote: Change-Id: Icdf2486a2d1116e71dc8958cda679a4a83838489 Signed-off-by: Chunming Zhou ---

Re: [PATCH 3/3] drm/amdgpu: fix gpu reset issue

NAK, that is exactly what we wanted to avoid. We used to have an exclusive lock for this and it cause a whole bunch of problems. Please elaborate why that should be necessary. Regards, Christian. Am 21.04.2017 um 09:08 schrieb Roger.He: Change-Id: Ib77d33a09f348ebf2e3a9d7861411f4b951ebf7c

Re: [PATCH] drm/amdgpu: fix VM clearing in amdgpu_gem_object_close

On 21.04.2017 10:07, Christian König wrote: From: Christian König We need to check if the VM is swapped out before trying to update it. Signed-off-by: Christian König Oops. That makes a lot of sense... Fixes: 23e0563e48f7 ("drm/amdgpu:

[PATCH] drm/amdgpu: fix VM clearing in amdgpu_gem_object_close

From: Christian König We need to check if the VM is swapped out before trying to update it. Signed-off-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 68 ++--- 1 file changed, 37 insertions(+),

Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On Fri, 21 Apr 2017 09:58:24 +0200 Gerd Hoffmann wrote: > While working on graphics support for virtual machines on ppc64 (which > exists in both little and big endian variants) I've figured the comments > for various drm fourcc formats in the header file don't match reality.

[PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

While working on graphics support for virtual machines on ppc64 (which exists in both little and big endian variants) I've figured the comments for various drm fourcc formats in the header file don't match reality. Comments says the RGB formats are little endian, but in practice they are native

[PATCH 3/3] drm/amdgpu: fix gpu reset issue

Change-Id: Ib77d33a09f348ebf2e3a9d7861411f4b951ebf7c Signed-off-by: Roger.He --- drivers/gpu/drm/amd/amdgpu/amdgpu.h| 6 ++ drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 16 +++- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 4

[PATCH 1/3] drm/amdgpu: fix indent

Change-Id: I3a81680648fbaca74662c85709c864fa3a4a75bd Signed-off-by: Roger.He --- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 34 +++--- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c

[PATCH 2/3] drm/amdgpu: validate bo before restoring from shadow

Change-Id: Id925f4e241c4192127880d2017fbf2979aa09fc7 Signed-off-by: Roger.He --- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 46 ++ 1 file changed, 46 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c

Re: [PATCH 3/3] drm/amdgpu: fix gpu reset issue

On 2017年04月21日 15:08, Roger.He wrote: Change-Id: Ib77d33a09f348ebf2e3a9d7861411f4b951ebf7c Signed-off-by: Roger.He Please add more explaination in comment, like "prevent ioctl during gpu reset, otherwise many un-expected behaviour happen." Regards, David Zhou ---

Re: [PATCH 2/3] drm/amdgpu: validate bo before restoring from shadow

On 2017年04月21日 15:07, Roger.He wrote: Change-Id: Id925f4e241c4192127880d2017fbf2979aa09fc7 Signed-off-by: Roger.He --- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 46 ++ 1 file changed, 46 insertions(+) diff --git

Re: [PATCH] dmr/amdgpu: Fix wrongly unref of BO

Hi Alex, No. For the current source code, I think the premap and no-op is not working. Indeed, we don't set bo->mem.bus.addr in amdgpu_ttm_io_mem_reserve() any more. Felix will probably want to fix that for the KFD branch. Anyway, as I said not unmapping the page tables is harmless