On 07/11/16 06:33 PM, Christian König wrote:
> Am 07.11.2016 um 10:29 schrieb Michel Dänzer:
>> On 07/11/16 06:21 PM, Christian König wrote:
>>> From: Christian König
>>>
>>> We don't need to use the PCI BAR on APUs. This allows us to access
>>> the full VRAM directly without being limited by the
On 08/11/16 05:31 AM, Dave Airlie wrote:
> On 7 November 2016 at 19:21, Christian König wrote:
>> From: Christian König
>>
>> We don't need to use the PCI BAR on APUs. This allows us to access
>> the full VRAM directly without being limited by the BAR size.
>
> I'm feeling coherency issues, has
2016-11-07 Alex Deucher :
> From: Christian König
>
> This reverts commit fb8b7d2b9d80e1e71f379e57355936bd2b024be9.
>
> Otherwise signaling might never be activated on the fences. This can
> result in infinite waiting with hardware which has unreliable interrupts.
>
> v2: still return one when
External clients which import our bo's wait only
for exclusive dmabuf-fences, not on shared ones,
ditto for bo's which we import from external
providers and write to.
Therefore attach exclusive fences on prime shared buffers
if our exported buffer gets imported by an external
client, or if we impo
2016-11-07 Christian König :
> Am 07.11.2016 um 02:10 schrieb Gustavo Padovan:
> > Hi Alex,
> >
> > 2016-11-04 Alex Deucher :
> >
> > > From: Junwei Zhang
> > >
> > > v2: agd: rebase and squash in all the previous optimizations and
> > > changes so everything compiles.
> > > v3: squash in Slav
As a next step, you could also remove HDP flushing on APUs.
Regards,
Felix
On 16-11-07 04:21 AM, Christian König wrote:
> From: Christian König
>
> We don't need to use the PCI BAR on APUs. This allows us to access
> the full VRAM directly without being limited by the BAR size.
>
> Signed-off
Hi Alex,
On 07-Nov-2016 11:14 PM, "Alex Deucher" wrote:
>
> On Fri, Nov 4, 2016 at 6:03 PM, Sumit Semwal
wrote:
> > Hi Alex,
> >
> > Thanks for the patches.
> >
> > On 4 November 2016 at 14:16, Alex Deucher wrote:
> >> From: "monk.liu"
> >>
> >> Return the index of the first signaled fence. T
Deucher, Alexander wrote:
-Original Message- From: amd-gfx
[mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of Andy
Furniss Sent: Sunday, November 06, 2016 3:31 PM To: Zhu, Rex;
Deucher, Alexander; amd-gfx@lists.freedesktop.org Subject: Re:
[PATCH] drm/amdgpu: set bypass mode when
From: Christian König
This reverts commit fb8b7d2b9d80e1e71f379e57355936bd2b024be9.
Otherwise signaling might never be activated on the fences. This can
result in infinite waiting with hardware which has unreliable interrupts.
v2: still return one when the timeout is zero and we don't have any
Kernel functions taking a timeout usually return 1 on success even
when they get a zero timeout.
v2: agd: rebase on drm-next
Reviewed-by: Alex Deucher
Signen-off-by: Christian König
Reviewed-by: Chunming Zhou
Signed-off-by: Alex Deucher
---
These are the same patches Christian sent out previ
From: Christian König
reservation_object_wait_timeout_rcu() should enable signaling even with a zero
timeout, but ttm_bo_wait() can also be called from atomic context and then it
is not a good idea to do this.
Reviewed-by: Alex Deucher
Signed-off-by: Christian König
Signed-off-by: Alex Deucher
This reverts commit 847b19a39e4c9b5e74c40f0842c48b41664cb43c.
When we don't call the wait function software signaling might never be
activated. This can cause infinite polling loops with unreliable interrupt
driven hardware.
v2: rebase on drm-next
Reviewed-by: Alex Deucher
Signed-off-by: Christ
On 7 November 2016 at 19:21, Christian König wrote:
> From: Christian König
>
> We don't need to use the PCI BAR on APUs. This allows us to access
> the full VRAM directly without being limited by the BAR size.
I'm feeling coherency issues, has this approach been validated with the hw team?
Dav
On 11/07/2016 08:55 AM, Christian König wrote:
Am 07.11.2016 um 04:29 schrieb Michel Dänzer:
On 07/11/16 11:47 AM, Mario Kleiner wrote:
External clients which import our bo's wait only
for exclusive dmabuf-fences, not on shared ones,
so attach fences on exported buffers as exclusive
ones, if th
Could we provide fault information through a ring buffer and a debugfs or drm
ioctl interface?
Tom
From: amd-gfx on behalf of Alex Deucher
Sent: Monday, November 7, 2016 13:35
To: Edward O'Callaghan; Nicolai Hähnle; Marek Olsak
Cc: Michel Dänzer; amd-gfx lis
On Sun, Nov 6, 2016 at 11:35 PM, Edward O'Callaghan
wrote:
> These are rather minor however should help stop some folks
> machines grinding to a halt when a userspace application somehow
> gets the GPU into some horrible state causing the console to fill
> very quickly. Applies on top of master.
On Fri, Nov 4, 2016 at 6:03 PM, Sumit Semwal wrote:
> Hi Alex,
>
> Thanks for the patches.
>
> On 4 November 2016 at 14:16, Alex Deucher wrote:
>> From: "monk.liu"
>>
>> Return the index of the first signaled fence. This information
>> is useful in some APIs like Vulkan.
>>
>> v2: rebase on drm
For the series:
Reviewed-by: Alex Deucher
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Tom St Denis
> Sent: Monday, November 07, 2016 10:36 AM
> To: amd-gfx@lists.freedesktop.org
> Subject: Clean up indirect SQ register accessors for g
> -Original Message-
> From: Zhu, Rex
> Sent: Monday, November 07, 2016 4:37 AM
> To: Deucher, Alexander; amd-gfx@lists.freedesktop.org
> Subject: RE: [PATCH] drm/amdgpu: set bypass mode when uvd is idle.
>
> Hi Alex,
>
> We don't need to set bypass mode for uvd.
> For the issue uvd clock
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Michel Dänzer
> Sent: Monday, November 07, 2016 4:09 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Zhang, Jerry
> Subject: [PATCH libdrm] amdgpu: add the function to get the marketing
> name (v
On 7 November 2016 at 11:43, Emil Velikov wrote:
> On 7 November 2016 at 09:09, Michel Dänzer wrote:
>
>> +static struct amdgpu_asic_id_table_t {
>> + uint32_t did;
>> + uint32_t rid;
>> + char marketing_name[64];
> Using a char * here might be a better. From a quick look [64] i
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Andy Furniss
> Sent: Sunday, November 06, 2016 3:31 PM
> To: Zhu, Rex; Deucher, Alexander; amd-gfx@lists.freedesktop.org
> Subject: Re: [PATCH] drm/amdgpu: set bypass mode when uvd is idle.
>
De-numberify indirect register access for gfx v8.
Signed-off-by: Tom St Denis
---
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
index 4f46d706675b..8d16
De-numberify indirect register access for gfx v7.
Signed-off-by: Tom St Denis
---
drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c
index 4dda3ddb3fec..bd9a
Denumberify the two indirect accessors to make the code cleaner.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
On 7 November 2016 at 09:09, Michel Dänzer wrote:
> +static struct amdgpu_asic_id_table_t {
> + uint32_t did;
> + uint32_t rid;
> + char marketing_name[64];
Using a char * here might be a better. From a quick look [64] is quite wasteful.
-Emil
__
On 7 November 2016 at 09:14, Michel Dänzer wrote:
> On 05/11/16 03:14 AM, Emil Velikov wrote:
>> On 2 November 2016 at 03:07, Michel Dänzer wrote:
>>>
>>> The first attached patch will result in drmParsePciDeviceInfo always
>>> reporting revision 0 on kernels without the second attached patch. Wi
Hi Alex,
We don't need to set bypass mode for uvd.
For the issue uvd clock stay in high clock when uvd is idle, just need to set
the default uvd clock to 100MHz when initialize.
Please Review the attached patch.
Best Regards
Rex
-Original Message-
From: Deucher, Alexander
Sent: Friday
Am 07.11.2016 um 10:29 schrieb Michel Dänzer:
On 07/11/16 06:21 PM, Christian König wrote:
From: Christian König
We don't need to use the PCI BAR on APUs. This allows us to access
the full VRAM directly without being limited by the BAR size.
Signed-off-by: Christian König
The series is
Rev
On 07/11/16 06:21 PM, Christian König wrote:
> From: Christian König
>
> We don't need to use the PCI BAR on APUs. This allows us to access
> the full VRAM directly without being limited by the BAR size.
>
> Signed-off-by: Christian König
The series is
Reviewed-by: Michel Dänzer
We could a
From: Christian König
We don't need to use the PCI BAR on APUs. This allows us to access
the full VRAM directly without being limited by the BAR size.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --
From: Christian König
We don't need to use the PCI BAR on APUs. This allows us to access
the full VRAM directly without being limited by the BAR size.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --
On 05/11/16 03:14 AM, Emil Velikov wrote:
> On 2 November 2016 at 03:07, Michel Dänzer wrote:
>>
>> The first attached patch will result in drmParsePciDeviceInfo always
>> reporting revision 0 on kernels without the second attached patch. Will
>> that be an issue for the amdgpu-pro stack?
>>
>> Pl
Am 07.11.2016 um 10:09 schrieb Michel Dänzer:
From: Junwei Zhang
This function is used to look up the marking name
for a specific board.
v2: agd: Squash in subsequent updates to the table.
v3: [Michel Dänzer]
* Make amdgpu_asic_id_table static, so it's not exported from
libdrm_amdgpu.so.1
*
On 02/11/16 10:48 PM, Deucher, Alexander wrote:
>> -Original Message-
>> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
>> Of Michel Dänzer
>> Sent: Tuesday, November 01, 2016 11:51 PM
>> To: Alex Deucher
>> Cc: Zhang, Jerry; amd-gfx@lists.freedesktop.org
>> Subject:
From: Junwei Zhang
This function is used to look up the marking name
for a specific board.
v2: agd: Squash in subsequent updates to the table.
v3: [Michel Dänzer]
* Make amdgpu_asic_id_table static, so it's not exported from
libdrm_amdgpu.so.1
* Add amdgpu_get_marketing_name to amdgpu-symbols-
Am 07.11.2016 um 05:35 schrieb Edward O'Callaghan:
These are rather minor however should help stop some folks
machines grinding to a halt when a userspace application somehow
gets the GPU into some horrible state causing the console to fill
very quickly. Applies on top of master.
Please kindly r
Yeah, please send that out.
Maybe just to me first, since we probably need to simplify and clean it
up a bit, e.g. use a callback instead of duplicating much code etc...
But in general that sounded like a step into the right direction in out
internal discussion.
We just need to change the p
Hi David,
well that additional placement range actually caused a performance problem.
It's only effect is that we check the invisible space twice, which can
burn quite a bunch of CPU cycles during allocation.
Can you somehow easily check for performance regressions?
Regards,
Christian.
Am 0
Hi Christian:
Could the patch for mmap splited pages be applied to ttm? if so, I can sent out
the patch.
Thanks
JimQu
发件人: amd-gfx 代表 Christian König
发送时间: 2016年11月7日 16:12
收件人: Qu, Jim; amd-gfx@lists.freedesktop.org
主题: Re: 答复: [PATCH 1/2] drm/amdgpu
Here , checking place->lpfn , is that mean if required place is located in
visible vram, driver run none pages split code path?
Yes, exactly. CPU accessible allocations weren't meant to be split with
the initial implementation.
For this we need to be able map scattered allocations into the CPU
Am 07.11.2016 um 02:55 schrieb jimqu:
Change-Id: I8b89da005b8c312a13d5df0c7f82a7921410797e
Signed-off-by: JimQu
Ops, nice catch. Patch is Reviewed-by: Christian König
.
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a
Am 07.11.2016 um 02:10 schrieb Gustavo Padovan:
Hi Alex,
2016-11-04 Alex Deucher :
From: Junwei Zhang
v2: agd: rebase and squash in all the previous optimizations and
changes so everything compiles.
v3: squash in Slava's 32bit build fix
v4: rebase on drm-next (fence -> dma_fence),
squas
43 matches
Mail list logo
