Re: [PATCH] drm/amdgpu: add VCN to firmware query interface

On Fri, Mar 16, 2018 at 11:07:08AM -0500, Alex Deucher wrote: > Need to be able to query the VCN firmware version from > userspace to determine supported features, etc. > Reviewed-by: Huang Rui > Signed-off-by: Alex Deucher > --- >

Re: [PATCH 1/2] drm/amdgpu: Don't change preferred domian when fallback GTT v3

On 2018年03月19日 18:03, Christian König wrote: Am 19.03.2018 um 11:00 schrieb Chunming Zhou: v2: add sanity checking v3: make code open Change-Id: I2cf672ad36b8b4cc1a6b2e704f786bf6a155d9ce Signed-off-by: Chunming Zhou Reviewed-by: Christian König

RE: [PATCH] drm/amdgpu: disable job timeout on GPU reset disabled

Hi Christian, The messages prompted on timeout are Errors not just Warnings although we did not see any real problem(for the dgemm special case). That's why we say it confusing. And i suppose you want a fix like my previous patch(see attachment). Regards, Evan > -Original Message- >

Re: Documentation about AMD's HSA implementation?

Thanks, John! On Sat, Mar 17, 2018 at 4:17 PM, Bridgman, John wrote: > >>-Original Message- >>From: Ming Yang [mailto:minos.fut...@gmail.com] >>Sent: Saturday, March 17, 2018 12:35 PM >>To: Kuehling, Felix; Bridgman, John >>Cc: amd-gfx@lists.freedesktop.org

Re: [PATCH 1/2] drm/amdgpu: Enable scatter gather display support

In theory, Mesa doesn't have to do anything. It can continue setting VRAM and if the kernel has to put a display buffer into GTT, it doesn't matter (for Mesa). Whether the VRAM placement is really used is largely determined by BO priorities. The way I understand scather/gather is that it only

Re: [PATCH] drm/amd/powerplay: Fix NULL pointer deref on driver unbind.

Reviewed-by: Alex Deucher From: amd-gfx on behalf of Andrey Grodzovsky Sent: Monday, March 19, 2018 4:55 PM To: amd-gfx@lists.freedesktop.org Cc: Grodzovsky, Andrey;

Re: [PATCH 1/2] drm/amdgpu: Enable scatter gather display support

On Mon, Mar 19, 2018 at 4:29 PM, Li, Samuel wrote: >>to my earlier point, there may be cases where it is advantageous to put >> display buffers in vram even if s/g display is supported > > Agreed. That is also why the patch has the options to let user select where > to put

[PATCH] drm/amd/powerplay: Fix NULL pointer deref on driver unbind.

Signed-off-by: Andrey Grodzovsky --- drivers/gpu/drm/amd/powerplay/amd_powerplay.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/powerplay/amd_powerplay.c b/drivers/gpu/drm/amd/powerplay/amd_powerplay.c index

Re: [PATCH 1/2] drm/amdgpu: Enable scatter gather display support

On Mon, Mar 19, 2018 at 4:53 PM, Alex Deucher wrote: > On Mon, Mar 19, 2018 at 4:26 PM, Marek Olšák wrote: > > When Mesa wants a buffer in VRAM, it always sets VRAM. It relies on BO > move > > throttling to prevent unnecessary BO moves. > > > > My

Re: [PATCH 1/2] drm/amdgpu: Enable scatter gather display support

On Mon, Mar 19, 2018 at 4:26 PM, Marek Olšák wrote: > When Mesa wants a buffer in VRAM, it always sets VRAM. It relies on BO move > throttling to prevent unnecessary BO moves. > > My questions are: > - what should Mesa do differently for tiny VRAM? > - what is a tiny VRAM? > -

RE: [PATCH 1/2] drm/amdgpu: Enable scatter gather display support

>to my earlier point, there may be cases where it is advantageous to put >display buffers in vram even if s/g display is supported Agreed. That is also why the patch has the options to let user select where to put display buffers. As whether to put the option in Mesa or kernel, it seems the

Re: [PATCH 1/2] drm/amdgpu: Enable scatter gather display support

When Mesa wants a buffer in VRAM, it always sets VRAM. It relies on BO move throttling to prevent unnecessary BO moves. My questions are: - what should Mesa do differently for tiny VRAM? - what is a tiny VRAM? - if VRAM is tiny, which allocations should we put there? Marek On Mon, Mar 19, 2018

RE: [PATCH 1/2] drm/amdgpu: Enable scatter gather display support

s/not/now/. I meant to say, "we have NOW excluded the possibility of ever setting displays anywhere else without a kernel update". Alex From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of Deucher, Alexander Sent: Monday, March 19, 2018 4:13 PM To: Li, Samuel

Re: [PATCH 1/2] drm/amdgpu: Enable scatter gather display support

I'm not sure what you mean by the 3 scenarios. Generally userspace selects what domains it wants a buffer to be in, vram, gtt, or both (don't care). I'd rather not have the kernel second guess the UMDs if we can help it. I'd rather leave the kernel for cases where we have to force things due

Re: [PATCH 1/2] drm/amdgpu: Enable scatter gather display support

Hi Sam, no that is seriously a no-go. The placement decision is done my userspace, not the kernel. The only time the kernel overrides that decision is a) hardware requirements (for example old UVD on AGP systems) and b) memory pressure. We are have actually pushed quite hard on avoiding

RE: [PATCH 1/2] drm/amdgpu: Enable scatter gather display support

Alex, I assume you are talking the three scenarios here, 1)VRAM, 2)GTT, 3)VRAM/GTT. But kernel will need the decision too(amdgpufb). I think it shall be better to do it in kernel, instead of different clients(mesa, ddx, kernel ...) Regards, Samuel Li From: Deucher, Alexander Sent: Monday,

Re: [PATCH 1/2] drm/amdgpu: Enable scatter gather display support

My personal preference is still to plumb this through to mesa rather than forcing it in the kernel. Alex From: amd-gfx on behalf of Li, Samuel Sent: Monday, March 19, 2018 3:50:34 PM To: Koenig,

RE: [PATCH 1/2] drm/amdgpu: Enable scatter gather display support

Christian, You misunderstood Alex’s comments, >Regardless of which scenarios we need to support, I think we also need >to really plumb this through to mesa however since user space is who >ultimately requests the location. Overriding it in the kernel gets >tricky and can lead to

Re: [PATCH 1/2] drm/amdgpu: Enable scatter gather display support

Quoting Alex: Regardless of which scenarios we need to support, I think we also need to really plumb this through to mesa however since user space is who ultimately requests the location. Overriding it in the kernel gets tricky and can lead to ping-ponging as others have noted. Better to have

Re: [PATCH 1/2] drm/amdgpu: Enable scatter gather display support

Am 19.03.2018 um 20:39 schrieb Marek Olšák: On Mon, Mar 19, 2018 at 3:27 PM, Christian König > wrote: I think that the consensus with Alex and me is that we should avoid exactly that. Overriding the preferred domain in the

RE: [PATCH 1/2] drm/amdgpu: Enable scatter gather display support

Agreed. >I think that the consensus with Alex and me is that we should avoid exactly >that. Christian, Alex’s concern is about ping-pong, not about the preferred domain. Regards, Samuel Li From: Marek Olšák [mailto:mar...@gmail.com] Sent: Monday, March 19, 2018 3:39 PM To: Koenig, Christian

Re: [PATCH 1/2] drm/amdgpu: Enable scatter gather display support

On Mon, Mar 19, 2018 at 3:27 PM, Christian König wrote: > I think that the consensus with Alex and me is that we should avoid > exactly that. > > Overriding the preferred domain in the kernel is a no-go for that patch > set, so please implement the discussed changes in

Re: [PATCH 1/2] drm/amdgpu: Enable scatter gather display support

I think that the consensus with Alex and me is that we should avoid exactly that. Overriding the preferred domain in the kernel is a no-go for that patch set, so please implement the discussed changes in Mesa. Regards, Christian. Am 19.03.2018 um 20:22 schrieb Li, Samuel: I agree with

Re: [PATCH] drm/amdgpu: add documentation for amdgpu_device.c

Am 19.03.2018 um 19:27 schrieb Alex Deucher: On Fri, Mar 16, 2018 at 4:19 PM, Alex Deucher wrote: Add kernel doc for the functions in amdgpu_device.c Signed-off-by: Alex Deucher Ping? Acked-by: Christian König

RE: [PATCH 1/2] drm/amdgpu: Enable scatter gather display support

I agree with Marek/Michel: since kernel sets the domain before scanning out, it shall update the preferred domain here too. Regards, Samuel Li > -Original Message- > From: Koenig, Christian > Sent: Thursday, March 08, 2018 4:07 AM > To: Michel Dänzer ; Li, Samuel >

Re: [PATCH 00/20] Add KFD GPUVM support for dGPUs v4

On 2018-03-19 12:39 PM, Christian König wrote: > So coming back to this series once more. > > Patch #1, #3 are Reviewed-by: Christian König . > > Patch #2, #4 - #13 and #18-#19 are Acked-by: Christian König > . > > Patch #14: What's the

Re: [PATCH] drm/amdgpu: add VCN to firmware query interface

Acked-by: Leo Liu On 03/19/2018 02:26 PM, Alex Deucher wrote: On Fri, Mar 16, 2018 at 12:07 PM, Alex Deucher wrote: Need to be able to query the VCN firmware version from userspace to determine supported features, etc. Signed-off-by: Alex Deucher

[PATCH 4.9 121/241] drm/radeon: Fail fb creation from imported dma-bufs.

4.9-stable review patch. If anyone has any objections, please let me know. -- From: Christopher James Halse Rogers [ Upstream commit a294043b2fbd8de69d161457ed0c7a4026bbfa5a ] Any use of the framebuffer will migrate it to VRAM, which

[PATCH 3.18 33/68] drm/radeon: Fail fb creation from imported dma-bufs.

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Christopher James Halse Rogers [ Upstream commit a294043b2fbd8de69d161457ed0c7a4026bbfa5a ] Any use of the framebuffer will migrate it to VRAM, which

[PATCH 4.9 122/241] drm/amdgpu: Fail fb creation from imported dma-bufs. (v2)

4.9-stable review patch. If anyone has any objections, please let me know. -- From: Christopher James Halse Rogers [ Upstream commit 1769152ac64b0b07583f696b621624df2ca4c840 ] Any use of the framebuffer will migrate it to VRAM, which

[PATCH 4.4 060/134] drm/amdgpu: Fail fb creation from imported dma-bufs. (v2)

4.4-stable review patch. If anyone has any objections, please let me know. -- From: Christopher James Halse Rogers [ Upstream commit 1769152ac64b0b07583f696b621624df2ca4c840 ] Any use of the framebuffer will migrate it to VRAM, which

Re: [PATCH] drm/amdgpu: add documentation for amdgpu_device.c

On Fri, Mar 16, 2018 at 4:19 PM, Alex Deucher wrote: > Add kernel doc for the functions in amdgpu_device.c > > Signed-off-by: Alex Deucher Ping? Alex > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 439 > - >

Re: [PATCH] drm/amdgpu: add VCN to firmware query interface

On Fri, Mar 16, 2018 at 12:07 PM, Alex Deucher wrote: > Need to be able to query the VCN firmware version from > userspace to determine supported features, etc. > > Signed-off-by: Alex Deucher Ping? Alex > --- >

Re: [PATCH] drm/amdgpu: Add CM_TEST_DEBUG regs for DCN

On 2018-03-19 01:45 PM, Harry Wentland wrote: > We'd like to use them for reading DCN debug status. > > Signed-off-by: Harry Wentland > --- > > See patch for where we use them http://git.amd.com:8080/#/c/137151/1 > > Tony can comment on details. > Whoops, didn't mean

Re: [PATCH 00/20] Add KFD GPUVM support for dGPUs v4

So coming back to this series once more. Patch #1, #3 are Reviewed-by: Christian König . Patch #2, #4 - #13 and #18-#19 are Acked-by: Christian König . Patch #14: What's the difference to setting vramlimit=$size_of_bar ? Patch #15 & #20:

Re: [PATCH 1/5] dma-buf: add optional invalidate_mappings callback v2

Am 19.03.2018 um 16:53 schrieb Chris Wilson: Quoting Christian König (2018-03-16 14:22:32) [snip, probably lost too must context] This allows for full grown pipelining, e.g. the exporter can say I need to move the buffer for some operation. Then let the move operation wait for all existing

Re: [PATCH 1/5] dma-buf: add optional invalidate_mappings callback v2

Quoting Christian König (2018-03-16 14:22:32) [snip, probably lost too must context] > This allows for full grown pipelining, e.g. the exporter can say I need > to move the buffer for some operation. Then let the move operation wait > for all existing fences in the reservation object and install

RE: [PATCH] drm/amd/amdgpu: passing i2s instance value as platform data

> -Original Message- > From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf > Of Vijendar Mukunda > Sent: Monday, March 19, 2018 2:47 AM > To: amd-gfx@lists.freedesktop.org > Cc: Deucher, Alexander ; Mukunda, > Vijendar

Re: RFC: unpinned DMA-buf exporting v2

On Fri, Mar 16, 2018 at 02:20:44PM +0100, Christian König wrote: > Hi everybody, > > since I've got positive feedback from Daniel I continued working on this > approach. > > A few issues are still open: > 1. Daniel suggested that I make the invalidate_mappings callback a parameter > of

Re: [PATCH 1/5] dma-buf: add optional invalidate_mappings callback v2

On Fri, Mar 16, 2018 at 02:20:45PM +0100, Christian König wrote: > Each importer can now provide an invalidate_mappings callback. > > This allows the exporter to provide the mappings without the need to pin > the backing store. > > v2: don't try to invalidate mappings when the callback is NULL,

Re: [PATCH] drm/amdgpu/nbio6: Correct PCIE_INDEX/DATA pair used for smn register accessing

On Mon, Mar 19, 2018 at 5:32 AM, Hawking Zhang wrote: > PCIE_INDEX2/DATA2 pair will be used for smn register accessing since from > vega. > PCIE_INDEX/DATA pair should be reserved for smu > > Change-Id: Ie597d89001e706225521c94161d2b40443ec3c48 > Signed-off-by: Hawking

Re: After upgrading LLVM to 7.0.0-0.1.r326462 version and MESA to 18.1.0-0.4.git56dc9f9 the games which are used Vulkan driver have begun crashing at start

No one looked why Vulkan driver start crashing? Thread 1 "vulkandriverque" received signal SIGSEGV, Segmentation fault. 0x in ?? () (gdb) thread apply all bt Thread 3 (Thread 0x7fffef06c700 (LWP 15668)): #0 0x76e4f82d in futex_wait_cancelable (private=, expected=0,

Re: [Outreachy kernel] Re: [PATCH] gpu: drm: Use list_first_entry instead of list_entry

On Mon, 19 Mar 2018, Christian König wrote: > Mhm, actually that patch isn't correct. What we grab get here is the next > entry, not the first one. > > We don't have an alias list_next_entry for list_first_entry? As compared to the semantic patch I proposed earlier today, it would seem that

Re: [Outreachy kernel] Re: [PATCH] gpu: drm: Use list_first_entry instead of list_entry

Am 19.03.2018 um 12:06 schrieb Julia Lawall: On Mon, 19 Mar 2018, Christian König wrote: Mhm, actually that patch isn't correct. What we grab get here is the next entry, not the first one. We don't have an alias list_next_entry for list_first_entry? As compared to the semantic patch I

[PATCH] drm/amdgpu: re-validate per VM BOs if required

If a per VM BO ends up in a allowed domain it never moves back into the prefered domain. Signed-off-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 15 +-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git

Re: [PATCH 2/2] drm/amdgpu: validate fallback BOs

Am 19.03.2018 um 11:00 schrieb Chunming Zhou: issue: Game F1 performance drops 13% when per vm bo is enabled. root cause: if some BOs are fallback to allowed domain, they will never be validated if no eviction happens, that means they always exist in allowed domain. Fix: maintain a per vm

Re: [PATCH 1/2] drm/amdgpu: Don't change preferred domian when fallback GTT v3

Am 19.03.2018 um 11:00 schrieb Chunming Zhou: v2: add sanity checking v3: make code open Change-Id: I2cf672ad36b8b4cc1a6b2e704f786bf6a155d9ce Signed-off-by: Chunming Zhou Reviewed-by: Christian König ---

[PATCH 2/2] drm/amdgpu: validate fallback BOs

issue: Game F1 performance drops 13% when per vm bo is enabled. root cause: if some BOs are fallback to allowed domain, they will never be validated if no eviction happens, that means they always exist in allowed domain. Fix: maintain a per vm allowed domain BOs list, then try to validated them

[PATCH 1/2] drm/amdgpu: Don't change preferred domian when fallback GTT v3

v2: add sanity checking v3: make code open Change-Id: I2cf672ad36b8b4cc1a6b2e704f786bf6a155d9ce Signed-off-by: Chunming Zhou --- drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c| 5 - drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 16 2 files changed, 12

Re: [PATCH 1/2] drm/amdgpu: Don't change preferred domian when fallback GTT v2

Am 19.03.2018 um 09:19 schrieb Chunming Zhou: v2: add sanity checking Change-Id: I2cf672ad36b8b4cc1a6b2e704f786bf6a155d9ce Signed-off-by: Chunming Zhou --- drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c| 5 - drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 15

Re: [PATCH] drm/amdgpu: disable job timeout on GPU reset disabled

Am 19.03.2018 um 07:08 schrieb Evan Quan: Since under some heavy computing environment(dgemm test), it takes the asic over 10+ seconds to finish the dispatched single job which will trigger the timeout. It's quite confusing although it does not seem to bring any real problems. As a quick

Re: [PATCH] gpu: drm: Use list_first_entry instead of list_entry

Mhm, actually that patch isn't correct. What we grab get here is the next entry, not the first one. We don't have an alias list_next_entry for list_first_entry? Regards, Christian. Am 18.03.2018 um 22:51 schrieb Arushi Singhal: This patch replaces list_entry with list_first_entry as it makes

[PATCH] drm/amdgpu/nbio6: Correct PCIE_INDEX/DATA pair used for smn register accessing

PCIE_INDEX2/DATA2 pair will be used for smn register accessing since from vega. PCIE_INDEX/DATA pair should be reserved for smu Change-Id: Ie597d89001e706225521c94161d2b40443ec3c48 Signed-off-by: Hawking Zhang --- drivers/gpu/drm/amd/amdgpu/nbio_v6_1.c | 4 ++-- 1 file

[PATCH 2/2] drm/amdgpu: validate fallback BOs

issue: Game F1 performance drops 13% when per vm bo is enabled. root cause: if some BOs are fallback to allowed domain, they will never be validated if no eviction happens, that means they always exist in allowed domain. Fix: maintain a per vm allowed domain BOs list, then try to validated them

[PATCH 1/2] drm/amdgpu: Don't change preferred domian when fallback GTT v2

v2: add sanity checking Change-Id: I2cf672ad36b8b4cc1a6b2e704f786bf6a155d9ce Signed-off-by: Chunming Zhou --- drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c| 5 - drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 15 +-- 2 files changed, 13 insertions(+), 7

[PATCH] drm/amd/amdgpu: passing i2s instance value as platform data

i2s instance value is passed as platform data to dwc driver. this parameter will be useful to distinguish current i2s instance value when multiple i2s controller instances are created. Signed-off-by: Vijendar Mukunda --- drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c | 5

RE: [PATCH] drm/amdgpu: disable job timeout on GPU reset disabled

Hi Alex, INT_MAX is used instead of MAX_SCHEDULE_TIMEOUT(which we discussed in another mail thread) since the amdgpu_lockup_timeout is with data type int. Using MAX_SCHEDULE_TIMEOUT(data type:long) will get compile warnings. Regards, Evan -Original Message- From: Evan Quan

[PATCH] drm/amdgpu: disable job timeout on GPU reset disabled

Since under some heavy computing environment(dgemm test), it takes the asic over 10+ seconds to finish the dispatched single job which will trigger the timeout. It's quite confusing although it does not seem to bring any real problems. As a quick workround, we choose to disable timeout when GPU