Re: [PATCH 21/26] drm/amdgpu: convert srbm lock to a spinlock v2

Am 12.04.2017 um 00:19 schrieb Alex Deucher: On Thu, Apr 6, 2017 at 2:21 AM, Andres Rodriguez wrote: Replace adev->srbm_mutex with a spinlock adev->srbm_lock v2: rebased on 4.12 and included gfx9 Signed-off-by: Andres Rodriguez Maybe move this one up

Re: [PATCH 8/8] amdgpu: use sync file for shared semaphores (v2.1)

Am 12.04.2017 um 05:58 schrieb Dave Airlie: On 12 April 2017 at 13:34, Mao, David wrote: My point is it is reasonable to split the semaphore signal/wait with the command submission. For the signal ioctl, we could just pick the last fence in the same schedule context, and

Re: [PATCH 8/8] amdgpu: use sync file for shared semaphores (v3)

Am 12.04.2017 um 06:57 schrieb Dave Airlie: From: Dave Airlie This creates a new command submission chunk for amdgpu to add wait and signal sync objects around the submission. Sync objects are managed via the drm syncobj ioctls. The command submission interface is

Re: [PATCH 8/8] amdgpu: use sync file for shared semaphores (v3)

On Wed, Apr 12, 2017 at 11:55:24AM +0200, Christian König wrote: > Am 12.04.2017 um 06:57 schrieb Dave Airlie: > >+static int amdgpu_sem_lookup_and_remove(struct amdgpu_cs_parser *p, > >+ uint32_t handle) > >+{ > >+int r; > >+struct dma_fence *old_fence; >

Re: [PATCH 5/8] sync_file: add support for a semaphore object

On Wed, Apr 12, 2017 at 12:36:37PM +1000, Dave Airlie wrote: > On 11 April 2017 at 17:50, Chris Wilson wrote: > > On Tue, Apr 11, 2017 at 01:22:17PM +1000, Dave Airlie wrote: > >> From: Dave Airlie > >> > >> This object can be used to implement the

Re: [PATCH 8/8] amdgpu: use sync file for shared semaphores (v3)

Am 12.04.2017 um 12:18 schrieb Chris Wilson: On Wed, Apr 12, 2017 at 11:55:24AM +0200, Christian König wrote: Am 12.04.2017 um 06:57 schrieb Dave Airlie: +static int amdgpu_sem_lookup_and_remove(struct amdgpu_cs_parser *p, + uint32_t handle) +{ + int

RE: [PATCH 2/3] drm/radeon: Make SI support in Radeon conditional

My understanding is that SI support in AMDGPU is limited. So maybe here it can be the other way around, that by default SI support in AMDGPU shall be disabled. Sam -Original Message- From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of Felix Kuehling Sent:

Re: [PATCH umr] Prevent reading sensors far too quickly.

Reviewed-by: Edward O'Callaghan On 04/12/2017 11:10 PM, Tom St Denis wrote: > On platforms without GPU_POWER sensors the thread reading sensors would > proceed > far too quickly. So it is now rate limited to 50Hz to be consistent. > > Signed-off-by: Tom St Denis

Re: [PATCH 8/8] amdgpu: use sync file for shared semaphores (v3)

On Wed, Apr 12, 2017 at 12:57 AM, Dave Airlie wrote: > From: Dave Airlie > > This creates a new command submission chunk for amdgpu > to add wait and signal sync objects around the submission. > > Sync objects are managed via the drm syncobj ioctls. > > The

[PATCH 2/2] drm/amdgpu: drop support for per ASIC read registers

From: Christian König Only per family registers are still used. Signed-off-by: Christian König --- drivers/gpu/drm/amd/amdgpu/soc15.c | 29 +- drivers/gpu/drm/amd/amdgpu/vi.c| 42

[PATCH 1/2] drm/amdgpu: drop support for untouched registers

From: Christian König I couldn't figure out what this was original good for, but we don't use it any more. Signed-off-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 - drivers/gpu/drm/amd/amdgpu/cik.c| 121

Re: [PATCH 5/8] sync_file: add support for a semaphore object

>> >> Not sure what the best semantics are there, any opinions on barring >> wakeups/polling on semaphore sync_files, and just punting this >> until we need it. > > I think getting it right now will make writing sw_sync-esque (i.e. cpu) > tests easier and more complete. I just don't have any use

Re: [PATCH 16/26] drm/amdgpu: new queue policy, take first 2 queues of each pipe

On 2017-04-11 06:30 PM, Felix Kuehling wrote: What about GFX9? I don't have a gfx9 card to test with yet. When changing the queue policy for gfx7/8 I found a lot of places in the code that had the assumption that amdgpu would only be using the same pipe. I'm pretty sure there is probably

RE: [PATCH] drm/amdgpu: Add kernel parameter to manage memory error handling.

> -Original Message- > From: Michel Dänzer [mailto:mic...@daenzer.net] > Sent: Tuesday, April 11, 2017 10:12 PM > To: Panariti, David > Cc: amd-gfx@lists.freedesktop.org > Subject: Re: [PATCH] drm/amdgpu: Add kernel parameter to manage > memory error handling. >

Re: [PATCH 25/26] drm/amdgpu: guarantee bijective mapping of ring ids for LRU v3

I haven't reviewed this in detail. But would it make sense to squash that into the commit that introduced the LRU policy for the queue manager (patch 18 in this series)? Regards, Felix On 17-04-06 02:21 AM, Andres Rodriguez wrote: > Depending on usage patterns, the current LRU policy may

Re: [PATCH] Add support for high priority scheduling in amdgpu v8

Thanks for the comments. I'll get these and Alex's comments addressed and re-send the series out. Regards, Andres On 2017-04-11 06:31 PM, Felix Kuehling wrote: I replied to patch 5 with an observation. But I think that code was broken before your change. The order of patches 7 and 8 should

Re: [PATCH 5/8] sync_file: add support for a semaphore object

On Thu, Apr 13, 2017 at 05:05:27AM +1000, Dave Airlie wrote: > >> > >> Not sure what the best semantics are there, any opinions on barring > >> wakeups/polling on semaphore sync_files, and just punting this > >> until we need it. > > > > I think getting it right now will make writing sw_sync-esque

Re: [PATCH 5/8] sync_file: add support for a semaphore object

On 13 April 2017 at 08:34, Chris Wilson wrote: > On Thu, Apr 13, 2017 at 07:41:28AM +1000, Dave Airlie wrote: >> > >> > The problem, as I see it, is that you are taking functionality away from >> > sync_file. If you are wrapping them up inside a sync_file, we have a >> >

Re: [PATCH 5/8] sync_file: add support for a semaphore object

> > The problem, as I see it, is that you are taking functionality away from > sync_file. If you are wrapping them up inside a sync_file, we have a > fair expectation that our code to handle sync_files will continue to > work. What code? there is no code existing that should be sharing sync

Re: [PATCH 01/26] drm/amdgpu: refactor MQD/HQD initialization v2

On 2017-04-11 06:08 PM, Alex Deucher wrote: On Thu, Apr 6, 2017 at 2:21 AM, Andres Rodriguez wrote: 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

Re: [PATCH 5/8] sync_file: add support for a semaphore object

On Wed, Apr 12, 2017 at 09:01:32PM +0100, Chris Wilson wrote: > On Thu, Apr 13, 2017 at 05:05:27AM +1000, Dave Airlie wrote: > > >> > > >> Not sure what the best semantics are there, any opinions on barring > > >> wakeups/polling on semaphore sync_files, and just punting this > > >> until we need

Re: [PATCH 5/8] sync_file: add support for a semaphore object

On Thu, Apr 13, 2017 at 06:51:17AM +1000, Dave Airlie wrote: > On 13 April 2017 at 06:39, Chris Wilson wrote: > > On Wed, Apr 12, 2017 at 09:01:32PM +0100, Chris Wilson wrote: > >> On Thu, Apr 13, 2017 at 05:05:27AM +1000, Dave Airlie wrote: > >> > >> > >> > >> Not sure

Re: [PATCH 01/26] drm/amdgpu: refactor MQD/HQD initialization v2

On 2017-04-11 06:18 PM, Alex Deucher wrote: On Thu, Apr 6, 2017 at 2:21 AM, Andres Rodriguez wrote: 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

Re: [PATCH 5/8] sync_file: add support for a semaphore object

On Thu, Apr 13, 2017 at 07:41:28AM +1000, Dave Airlie wrote: > > > > The problem, as I see it, is that you are taking functionality away from > > sync_file. If you are wrapping them up inside a sync_file, we have a > > fair expectation that our code to handle sync_files will continue to > > work.

[PATCH 7/7] amdgpu: use sync file for shared semaphores (v3)

From: Dave Airlie This creates a new command submission chunk for amdgpu to add wait and signal sync objects around the submission. Sync objects are managed via the drm syncobj ioctls. The command submission interface is enhanced with two new chunks, one for semaphore

RE: [PATCH] drm/amdgpu: Add kernel parameter to manage memory error handling.

> -Original Message- > From: Michel Dänzer [mailto:mic...@daenzer.net] > Sent: Wednesday, April 12, 2017 9:17 PM > To: Panariti, David > Cc: Deucher, Alexander; amd-gfx@lists.freedesktop.org > Subject: Re: [PATCH] drm/amdgpu: Add kernel parameter to manage > memory error handling. > > On

Re: [PATCH] drm/amdgpu: Add kernel parameter to manage memory error handling.

On 13/04/17 02:38 AM, Panariti, David wrote: >> From: Michel Dänzer [mailto:mic...@daenzer.net] >> >>> @@ -212,6 +213,9 @@ module_param_named(cg_mask, >> amdgpu_cg_mask, uint, >>> 0444); MODULE_PARM_DESC(pg_mask, "Powergating flags mask (0 = >> disable >>> power gating)");

Re: [PATCH 4/7] sync_file: add support for sem_file

On Thu, Apr 13, 2017 at 11:41:41AM +1000, Dave Airlie wrote: > From: Dave Airlie > > This adds support for a file that has semaphore semantics > (for Vulkan shared semaphores). > > These objects are persistent objects that can have a > fence that changes. When the object is

[PATCH 2/7] sync_file: mark the fence pointer as rcu.

From: Dave Airlie The current code never updates this pointer after init, and it should always be initialised with a valid value. However in the future we want to share some code with semaphore files, and those will want to use rcu to update this pointer. However none of the

[PATCH 1/7] sync_file: get rid of internal reference count.

From: Dave Airlie sync_file uses the reference count of the file, the internal kref was never getting moved past 1. We can reintroduce this if we decide we need it later. [airlied: fix buildbot warnings] Reviewed-by: Chris Wilson Signed-off-by:

[PATCH 3/7] sync_file: split out fence_file base class from sync_file.

From: Dave Airlie This just splits out a common base object to be shared between sync_file and sem_files. Signed-off-by: Dave Airlie --- drivers/dma-buf/sync_file.c | 49 +++- drivers/gpu/drm/drm_atomic.c | 4

[rfc repost] drm sync objects - a new beginning (make ickle happier?)

Okay I've taken Chris's suggestions to heart and reworked things around a sem_file to see how they might look. This means the drm_syncobj are currently only useful for semaphores, the flags field could be used in future to use it for other things, and we can reintroduce some of the API then if

[PATCH 6/7] amdgpu/cs: split out fence dependency checking

From: Dave Airlie This just splits out the fence depenency checking into it's own function to make it easier to add semaphore dependencies. Reviewed-by: Christian König Signed-off-by: Dave Airlie ---

[PATCH 4/7] sync_file: add support for sem_file

From: Dave Airlie This adds support for a file that has semaphore semantics (for Vulkan shared semaphores). These objects are persistent objects that can have a fence that changes. When the object is signaled, a fence is attached to it, and when an object is waited on, the

[PATCH 5/7] drm: introduce sync objects as wrappers for sem files

From: Dave Airlie Sync objects are new toplevel drm object, that have the same semantics as sem_file objects, but without requiring an fd to be consumed to support them. This patch just enables the DRM interface to create these objects, it doesn't actually provide any

Re: [PATCH 2/4] PCI: add functionality for resizing resources v2

On Tue, Apr 11, 2017 at 05:37:04PM +0200, Christian König wrote: > >>+int pci_resize_resource(struct pci_dev *dev, int resno, int size) > >>+{ > >>+ struct resource *res = dev->resource + resno; > >>+ u32 sizes = pci_rbar_get_possible_sizes(dev, resno); > >>+ int old =

Re: [PATCH 3/4] x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 30h-3fh) Processors

On Tue, Apr 11, 2017 at 05:48:25PM +0200, Christian König wrote: > Am 24.03.2017 um 16:47 schrieb Bjorn Helgaas: > >On Mon, Mar 13, 2017 at 01:41:35PM +0100, Christian König wrote: > >>From: Christian König > >> > >>Most BIOS don't enable this because of compatibility

Re: [PATCH 01/26] drm/amdgpu: refactor MQD/HQD initialization v2

Your proposed patch looks good to me. You can add a: Reviewed-by: Andres Rodriguez On 2017-04-11 06:18 PM, Alex Deucher wrote: On Thu, Apr 6, 2017 at 2:21 AM, Andres Rodriguez wrote: The MQD programming sequence currently exists in 3 different places.

Re: [PATCH 2/2] drm/amdgpu: drop support for per ASIC read registers

On Wed, Apr 12, 2017 at 8:13 AM, Christian König wrote: > From: Christian König > > Only per family registers are still used. > > Signed-off-by: Christian König Series is: Reviewed-by: Alex Deucher