Re: [PATCH libdrm] libdrm_amdgpu: add kernel semaphore support

On 7 July 2017 at 19:07, Christian König wrote: > Hi Dave, > > on first glance that looks rather good to me, but there is one things I > don't really like and I strongly think Marek will absolutely agree on that: > When we add a new CS function then let's get ride of all this abstraction! > > The

Re: [PATCH umr] top vram add visible vram usage info

Hi Tom, Any feedback on this patch? Regards, Qiang From: Qiang Yu Sent: Thursday, July 6, 2017 2:32:20 PM To: amd-gfx@lists.freedesktop.org Cc: Yu, Qiang Subject: [PATCH umr] top vram add visible vram usage info Signed-off-by: Qiang Yu --- src/app/top.

Re: [PATCH] drm/syncobj: add sync obj wait interface. (v6)

On 11/07/17 06:09 AM, Jason Ekstrand wrote: > On Mon, Jul 10, 2017 at 9:15 AM, Christian König > mailto:deathsim...@vodafone.de>> wrote: > > Am 10.07.2017 um 17:52 schrieb Jason Ekstrand: >> On Mon, Jul 10, 2017 at 8:45 AM, Christian König >> mailto:deathsim...@vodafone.de>> wrote: >>

Re: [PATCH umr] top vram add visible vram usage info

Hi Qiang, Sorry I must have missed that. I'll try it out first thing in the morning (Markham time). If it's all good I'll add a Rb and push it out. Cheers, Tom From: Yu, Qiang Sent: Monday, July 10, 2017 22:07 To: amd-gfx@lists.freedesktop.org; StDenis,

Re: Regression in amd-staging-4.11

On 10/07/17 08:00 PM, Martin Babutzka wrote: > Dear AMD graphics developers, > > I am one of the guys that regularly builds your amd-staging kernels and > makes them available for the lazier people. By this we get a nice > preview of DAL/DC and you get some free beta-testers. > > One of the users

Re: [PATCH v8 6/6] drm/amdgpu: resize VRAM BAR for CPU access v4

On Mon, Jul 10, 2017 at 04:59:54PM +0200, Christian König wrote: > From: Christian König > > Try to resize BAR0 to let CPU access all of VRAM. > > v2: rebased, style cleanups, disable mem decode before resize, > handle gmc_v9 as well, round size up to power of two. > v3: handle gmc_v6 as wel

Re: [PATCH v8 1/6] PCI: add a define for the PCI resource type mask v2

If you post this again, you can drop the "v2", "v5", etc at the end of the subject lines. I don't think it's useful to merge those. On Mon, Jul 10, 2017 at 04:59:49PM +0200, Christian König wrote: > From: Christian König > > We use this mask multiple times in the bus setup. > > v2: fix some st

Re: [PATCH] drm/syncobj: add sync obj wait interface. (v6)

On Mon, Jul 10, 2017 at 9:13 AM, Christian König wrote: > Am 10.07.2017 um 17:58 schrieb Xie, AlexBin: > > I understand this discussion from closes source driver terminology. > > > > If a process is killed before it sends out the signaling command, will > some part of the GPU be in a waiting situ

RE: [PATCH 1/3] drm/amdgpu/atom: fix atom_fw check

I just sent patches to fix it. Sorry my internet service has been out all day. I'm just catching up now. Alex From: Marek Olšák [mailto:mar...@gmail.com] Sent: Monday, July 10, 2017 10:08 AM To: Deucher, Alexander Cc: Alex Deucher; amd-gfx mailing list Subject: Re: [PATCH 1/3] drm/amdgpu/atom:

[PATCH 2/2] drm/amdgpu: call atomfirmware get_clock_info for atomfirmware systems

Rather than the legacy atombios version. Signed-off-by: Alex Deucher --- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c index d17e54b

[PATCH 1/2] drm/amdgpu: add get_clock_info for atomfirmware

The information has moved to different tables, notably smu_info for core refclk and umc_info for mem refclk. Signed-off-by: Alex Deucher --- drivers/gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c | 93 drivers/gpu/drm/amd/amdgpu/amdgpu_atomfirmware.h | 1 + 2 files changed, 9

Re: [PATCH] drm/syncobj: add sync obj wait interface. (v6)

On Mon, Jul 10, 2017 at 9:15 AM, Christian König wrote: > Am 10.07.2017 um 17:52 schrieb Jason Ekstrand: > > On Mon, Jul 10, 2017 at 8:45 AM, Christian König > wrote: > >> Am 10.07.2017 um 17:28 schrieb Jason Ekstrand: >> >> On Wed, Jul 5, 2017 at 6:04 PM, Dave Airlie wrote: >> [SNIP] >> So, re

Re: [PATCH] drm/syncobj: add sync obj wait interface. (v6)

Am 10.07.2017 um 17:52 schrieb Jason Ekstrand: On Mon, Jul 10, 2017 at 8:45 AM, Christian König mailto:deathsim...@vodafone.de>> wrote: Am 10.07.2017 um 17:28 schrieb Jason Ekstrand: On Wed, Jul 5, 2017 at 6:04 PM, Dave Airlie mailto:airl...@gmail.com>> wrote: [SNIP] So, readin

Re: [PATCH] drm/syncobj: add sync obj wait interface. (v6)

Am 10.07.2017 um 17:58 schrieb Xie, AlexBin: I understand this discussion from closes source driver terminology. If a process is killed before it sends out the signaling command, will some part of the GPU be in a waiting situation forever? Yes, exactly that's the problem here and the reaso

RE: [PATCH] drm/syncobj: add sync obj wait interface. (v6)

I understand this discussion from closes source driver terminology. If a process is killed before it sends out the signaling command, will some part of the GPU be in a waiting situation forever? Alex Bin Xie From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of Jason Ekstran

Re: [PATCH] drm/syncobj: add sync obj wait interface. (v6)

On Mon, Jul 10, 2017 at 8:45 AM, Christian König wrote: > Am 10.07.2017 um 17:28 schrieb Jason Ekstrand: > > On Wed, Jul 5, 2017 at 6:04 PM, Dave Airlie wrote: > >> From: Dave Airlie >> >> This interface will allow sync object to be used to back >> Vulkan fences. This API is pretty much the vul

Re: [PATCH] drm/syncobj: add sync obj wait interface. (v6)

Am 10.07.2017 um 17:28 schrieb Jason Ekstrand: On Wed, Jul 5, 2017 at 6:04 PM, Dave Airlie > wrote: From: Dave Airlie mailto:airl...@redhat.com>> This interface will allow sync object to be used to back Vulkan fences. This API is pretty much the vulkan fenc

Re: [PATCH] drm/syncobj: add sync obj wait interface. (v6)

On Wed, Jul 5, 2017 at 6:04 PM, Dave Airlie wrote: > From: Dave Airlie > > This interface will allow sync object to be used to back > Vulkan fences. This API is pretty much the vulkan fence waiting > API, and I've ported the code from amdgpu. > > v2: accept relative timeout, pass remaining time

[PATCH v8 6/6] drm/amdgpu: resize VRAM BAR for CPU access v4

From: Christian König Try to resize BAR0 to let CPU access all of VRAM. v2: rebased, style cleanups, disable mem decode before resize, handle gmc_v9 as well, round size up to power of two. v3: handle gmc_v6 as well, release and reassign all BARs in the driver. v4: rename new function to amdg

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

From: Christian König Most BIOS don't enable this because of compatibility reasons. Manually enable a 64bit BAR of 64GB size so that we have enough room for PCI devices. v2: style cleanups, increase size, add resource name, set correct flags, print message that windows was added v3: add def

[PATCH v8 5/6] drm/amdgpu: move hw generation check into amdgpu_doorbell_init v2

From: Christian König This way we can safely call it on SI as well. v2: fix type in commit message Signed-off-by: Christian König Reviewed-by: Andy Shevchenko --- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 17 - 1 file changed, 12 insertions(+), 5 deletions(-) diff --git a

[PATCH v8 2/6] PCI: add resizeable BAR infrastructure v5

From: Christian König Just the defines and helper functions to read the possible sizes of a BAR and update it's size. See https://pcisig.com/sites/default/files/specification_documents/ECN_Resizable-BAR_24Apr2008.pdf and PCIe r3.1, sec 7.22. This is useful for hardware with large local storage

[PATCH v8 3/6] PCI: add functionality for resizing resources v7

From: Christian König This allows device drivers to request resizing their BARs. The function only tries to reprogram the windows of the bridge directly above the requesting device and only the BAR of the same type (usually mem, 64bit, prefetchable). This is done to make sure not to disturb othe

Resizeable PCI BAR support V8

Hi everyone, This is the eighth incarnation of this set of patches. It enables device drivers to resize and most likely also relocate the PCI BAR of devices they manage to allow the CPU to access all of the device local memory at once. This is very useful for GFX device drivers where the default

[PATCH v8 1/6] PCI: add a define for the PCI resource type mask v2

From: Christian König We use this mask multiple times in the bus setup. v2: fix some style nit picks Signed-off-by: Christian König Reviewed-by: Andy Shevchenko --- drivers/pci/pci.h | 3 +++ drivers/pci/setup-bus.c | 12 +++- 2 files changed, 6 insertions(+), 9 deletions(-)

Re: Regression in amd-staging-4.11

Thanks for the info, is it possible to provide dmesg log for this issue ? On 07/10/2017 07:00 AM, Martin Babutzka wrote: Dear AMD graphics developers, I am one of the guys that regularly builds your amd-staging kernels and makes them available for the lazier people. By this we get a nice prev

Re: [PATCH 1/3] drm/amdgpu/atom: fix atom_fw check

On Mon, Jul 10, 2017 at 3:49 PM, Deucher, Alexander < alexander.deuc...@amd.com> wrote: > > -Original Message- > > From: Marek Olšák [mailto:mar...@gmail.com] > > Sent: Saturday, July 08, 2017 7:08 PM > > To: Alex Deucher > > Cc: amd-gfx mailing list; Deucher, Alexander > > Subject: Re: [P

RE: [PATCH 1/3] drm/amdgpu/atom: fix atom_fw check

> -Original Message- > From: Marek Olšák [mailto:mar...@gmail.com] > Sent: Saturday, July 08, 2017 7:08 PM > To: Alex Deucher > Cc: amd-gfx mailing list; Deucher, Alexander > Subject: Re: [PATCH 1/3] drm/amdgpu/atom: fix atom_fw check > > Hi Alex, > > This commit causes that clock_crystal

Regression in amd-staging-4.11

Dear AMD graphics developers,I am one of the guys that regularly builds your amd-staging kernels andmakes them available for the lazier people. By this we get a nicepreview of DAL/DC and you get some free beta-testers.One of the users describe a regression here:https://github.com/M-Bab/linux-kerne