Am 06.08.2018 02:13, schrieb Dieter Nützel:
Am 04.08.2018 06:18, schrieb Dieter Nützel:
Am 04.08.2018 06:12, schrieb Dieter Nützel:
Am 04.08.2018 05:27, schrieb Dieter Nützel:
Am 03.08.2018 13:09, schrieb Christian König:
Am 03.08.2018 um 03:08 schrieb Dieter Nützel:
Hello Christian, AMD
On 2018年08月08日 12:08, Junwei Zhang wrote:
Userspace needs to know if the user memory is from BO or malloc.
v2: update mutex range and rebase
Signed-off-by: Junwei Zhang
---
amdgpu/amdgpu.h| 23 +++
amdgpu/amdgpu_bo.c | 34 ++
2
Add a test for API to query bo by CPU mapping
Signed-off-by: Junwei Zhang
Reviewed-by: Christian König
---
tests/amdgpu/bo_tests.c | 33 +
1 file changed, 33 insertions(+)
diff --git a/tests/amdgpu/bo_tests.c b/tests/amdgpu/bo_tests.c
index 9d4da4a..dc2de9b
a helper function to create and initialize amdgpu bo
Signed-off-by: Junwei Zhang
---
amdgpu/amdgpu_bo.c | 81 ++
1 file changed, 33 insertions(+), 48 deletions(-)
diff --git a/amdgpu/amdgpu_bo.c b/amdgpu/amdgpu_bo.c
index a7f0662..59cba69
Userspace needs to know if the user memory is from BO or malloc.
v2: update mutex range and rebase
Signed-off-by: Junwei Zhang
---
amdgpu/amdgpu.h| 23 +++
amdgpu/amdgpu_bo.c | 34 ++
2 files changed, 57 insertions(+)
diff --git
When create bo from user memory, add it to handle table
for future query.
Signed-off-by: Junwei Zhang
Reviewed-by: Christian König
---
amdgpu/amdgpu_bo.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/amdgpu/amdgpu_bo.c b/amdgpu/amdgpu_bo.c
index
Modify the commit message
Extend the timeout for recovering vram bos from shadows on sr-iov
to cover the worst case scenario for timeslices and VFs
Under runtime, the wait fence time could be quite long when
other VFs are in exclusive mode. For example, for 4 VF, every
VF's exclusive timeout
Hi Alex,
Thanks for your review.
The host gim driver gives every VF fullaccess_timeout is 3000, so for 4
vf, the worst case is 3*3000(9000), if the vf number is more than 4,
then the time will be longer, so 8000 is not the worst time.
But with using 8000, it will pass all the TDR
Series is:
Reviewed-by: Rex Zhu
Regards
Rex
-Original Message-
From: amd-gfx On Behalf Of Alex Deucher
Sent: Wednesday, August 8, 2018 5:32 AM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander
Subject: [PATCH 2/2] drm/amdgpu/pp: endian fixes for processpptables.c
Properly swap
Reviewed-by: Evan Quan
> -Original Message-
> From: amd-gfx On Behalf Of Alex
> Deucher
> Sent: Wednesday, August 08, 2018 5:32 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander
> Subject: [PATCH 2/2] drm/amdgpu/pp: endian fixes for processpptables.c
>
> Properly swap
Reviewed-by: Evan Quan
> -Original Message-
> From: amd-gfx On Behalf Of Alex
> Deucher
> Sent: Wednesday, August 08, 2018 5:32 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander
> Subject: [PATCH 1/2] drm/amdgpu/pp: endian fixes for
> process_pptables_v1_0.c
>
> Properly
Properly swap when reading from the vbios.
Signed-off-by: Alex Deucher
---
.../gpu/drm/amd/powerplay/hwmgr/processpptables.c | 30 --
1 file changed, 16 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/processpptables.c
Properly swap when reading from the vbios.
Signed-off-by: Alex Deucher
---
.../amd/powerplay/hwmgr/process_pptables_v1_0.c| 194 ++---
1 file changed, 97 insertions(+), 97 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/process_pptables_v1_0.c
amdgpu only uses shared-fences internally, but dmabuf importers rely on
implicit write hazard tracking via the reservation_object.fence_excl.
For example, the importer use the write hazard for timing a page flip to
only occur after the exporter has finished flushing its write into the
surface. As
Am 07.08.2018 um 20:32 schrieb Chris Wilson:
amdgpu only uses shared-fences internally, but dmabuf importers rely on
implicit write hazard tracking via the reservation_object.fence_excl.
For example, the importer use the write hazard for timing a page flip to
only occur after the exporter has
amdgpu only uses shared-fences internally, but dmabuf importers rely on
implicit write hazard tracking via the reservation_object.fence_excl.
For example, the importer use the write hazard for timing a page flip to
only occur after the exporter has finished flushing its write into the
surface. As
Quoting Christian König (2018-08-07 19:18:55)
> Am 07.08.2018 um 20:14 schrieb Chris Wilson:
> > Quoting Christian König (2018-08-07 18:57:16)
> >> Am 07.08.2018 um 18:08 schrieb Chris Wilson:
> >>> amdgpu only uses shared-fences internally, but dmabuf importers rely on
> >>> implicit write hazard
Am 07.08.2018 um 20:14 schrieb Chris Wilson:
Quoting Christian König (2018-08-07 18:57:16)
Am 07.08.2018 um 18:08 schrieb Chris Wilson:
amdgpu only uses shared-fences internally, but dmabuf importers rely on
implicit write hazard tracking via the reservation_object.fence_excl.
For example, the
Quoting Christian König (2018-08-07 18:57:16)
> Am 07.08.2018 um 18:08 schrieb Chris Wilson:
> > amdgpu only uses shared-fences internally, but dmabuf importers rely on
> > implicit write hazard tracking via the reservation_object.fence_excl.
> > For example, the importer use the write hazard for
Am 07.08.2018 um 18:08 schrieb Chris Wilson:
amdgpu only uses shared-fences internally, but dmabuf importers rely on
implicit write hazard tracking via the reservation_object.fence_excl.
For example, the importer use the write hazard for timing a page flip to
only occur after the exporter has
On Tue, Aug 07, 2018 at 06:47:48PM +0100, Chris Wilson wrote:
> Since commit 09ea0dfbf972 ("dma-buf: make map_atomic and map function
> pointers optional"), we no longer need to provide stub no-op functions
> as the core now provides them directly.
>
> References: 09ea0dfbf972 ("dma-buf: make
Am 07.08.2018 um 19:47 schrieb Chris Wilson:
Since commit 09ea0dfbf972 ("dma-buf: make map_atomic and map function
pointers optional"), we no longer need to provide stub no-op functions
as the core now provides them directly.
References: 09ea0dfbf972 ("dma-buf: make map_atomic and map function
Since commit 09ea0dfbf972 ("dma-buf: make map_atomic and map function
pointers optional"), we no longer need to provide stub no-op functions
as the core now provides them directly.
References: 09ea0dfbf972 ("dma-buf: make map_atomic and map function pointers
optional")
Signed-off-by: Chris
On Tue, Aug 7, 2018 at 6:22 AM, Emily Deng wrote:
> Under runtime, the wait fence time could be quite long when
> other VFs are in exclusive mode.
>
> SWDEV-161490
>
> Change-Id: Ifc32d56ca7fde01b1f4fe2b0db6959b51909008a
> Signed-off-by: Monk Liu
> Signed-off-by: Emily Deng
Seems pretty long.
amdgpu only uses shared-fences internally, but dmabuf importers rely on
implicit write hazard tracking via the reservation_object.fence_excl.
For example, the importer use the write hazard for timing a page flip to
only occur after the exporter has finished flushing its write into the
surface. As
On Sun, Jul 29, 2018 at 4:39 PM, Christian König
wrote:
>> Do you need further informations?
>
> No, that is a known issue.
>
Hi,
is there any progress on this?
Thanks.
Regards,
- Sedat -
> Regards,
> Christian.
>
>
> Am 29.07.2018 um 15:52 schrieb Sedat Dilek:
>>
>> Hi,
>>
>> when compiling
On Tue, Aug 7, 2018 at 3:54 PM, Christian König
wrote:
> Am 07.08.2018 um 15:37 schrieb Daniel Vetter:
>>
>> On Tue, Aug 07, 2018 at 03:17:06PM +0200, Christian König wrote:
>>>
>>> Am 07.08.2018 um 14:59 schrieb Daniel Vetter:
On Tue, Aug 07, 2018 at 02:51:50PM +0200, Christian König
Am 07.08.2018 um 15:37 schrieb Daniel Vetter:
On Tue, Aug 07, 2018 at 03:17:06PM +0200, Christian König wrote:
Am 07.08.2018 um 14:59 schrieb Daniel Vetter:
On Tue, Aug 07, 2018 at 02:51:50PM +0200, Christian König wrote:
Am 07.08.2018 um 14:43 schrieb Daniel Vetter:
On Tue, Aug 07, 2018 at
On Tue, Aug 07, 2018 at 03:17:06PM +0200, Christian König wrote:
> Am 07.08.2018 um 14:59 schrieb Daniel Vetter:
> > On Tue, Aug 07, 2018 at 02:51:50PM +0200, Christian König wrote:
> > > Am 07.08.2018 um 14:43 schrieb Daniel Vetter:
> > > > On Tue, Aug 07, 2018 at 01:23:19PM +0200, Christian
Am 07.08.2018 um 14:59 schrieb Daniel Vetter:
On Tue, Aug 07, 2018 at 02:51:50PM +0200, Christian König wrote:
Am 07.08.2018 um 14:43 schrieb Daniel Vetter:
On Tue, Aug 07, 2018 at 01:23:19PM +0200, Christian König wrote:
Am 07.08.2018 um 13:05 schrieb Chris Wilson:
amdgpu only uses
On Tue, Aug 07, 2018 at 02:51:50PM +0200, Christian König wrote:
> Am 07.08.2018 um 14:43 schrieb Daniel Vetter:
> > On Tue, Aug 07, 2018 at 01:23:19PM +0200, Christian König wrote:
> > > Am 07.08.2018 um 13:05 schrieb Chris Wilson:
> > > > amdgpu only uses shared-fences internally, but dmabuf
Am 07.08.2018 um 14:43 schrieb Daniel Vetter:
On Tue, Aug 07, 2018 at 01:23:19PM +0200, Christian König wrote:
Am 07.08.2018 um 13:05 schrieb Chris Wilson:
amdgpu only uses shared-fences internally, but dmabuf importers rely on
implicit write hazard tracking via the
On Tue, Aug 07, 2018 at 02:43:22PM +0200, Daniel Vetter wrote:
> On Tue, Aug 07, 2018 at 01:23:19PM +0200, Christian König wrote:
> > Am 07.08.2018 um 13:05 schrieb Chris Wilson:
> > > amdgpu only uses shared-fences internally, but dmabuf importers rely on
> > > implicit write hazard tracking via
On Tue, Aug 07, 2018 at 01:23:19PM +0200, Christian König wrote:
> Am 07.08.2018 um 13:05 schrieb Chris Wilson:
> > amdgpu only uses shared-fences internally, but dmabuf importers rely on
> > implicit write hazard tracking via the reservation_object.fence_excl.
>
> Well I would rather suggest a
Am 07.08.2018 um 09:26 schrieb Junwei Zhang:
Userspace needs to know if the user memory is from BO or malloc.
Signed-off-by: Junwei Zhang
---
amdgpu/amdgpu.h| 23 +++
amdgpu/amdgpu_bo.c | 34 ++
2 files changed, 57 insertions(+)
diff
Am 07.08.2018 um 12:23 schrieb Zhang, Jerry (Junwei):
On 08/07/2018 05:59 PM, Christian König wrote:
Am 07.08.2018 um 11:52 schrieb Zhang, Jerry (Junwei):
On 08/07/2018 05:33 PM, Christian König wrote:
Am 07.08.2018 um 10:28 schrieb Zhang, Jerry (Junwei):
On 08/07/2018 04:20 PM, Christian
Am 07.08.2018 um 13:05 schrieb Chris Wilson:
amdgpu only uses shared-fences internally, but dmabuf importers rely on
implicit write hazard tracking via the reservation_object.fence_excl.
Well I would rather suggest a solution where we stop doing this.
The problem here is that i915 assumes
amdgpu only uses shared-fences internally, but dmabuf importers rely on
implicit write hazard tracking via the reservation_object.fence_excl.
For example, the importer use the write hazard for timing a page flip to
only occur after the exporter has finished flushing its write into the
surface. As
Quoting Huang Rui (2018-08-07 11:56:24)
> On Tue, Aug 07, 2018 at 11:45:00AM +0100, Chris Wilson wrote:
> > amdgpu only uses shared-fences internally, but dmabuf importers rely on
> > implicit write hazard tracking via the reservation_object.fence_excl.
> > For example, the importer use the write
amdgpu only uses shared-fences internally, but dmabuf importers rely on
implicit write hazard tracking via the reservation_object.fence_excl.
For example, the importer use the write hazard for timing a page flip to
only occur after the exporter has finished flushing its write into the
surface. As
On Tue, Aug 07, 2018 at 11:45:00AM +0100, Chris Wilson wrote:
> amdgpu only uses shared-fences internally, but dmabuf importers rely on
> implicit write hazard tracking via the reservation_object.fence_excl.
> For example, the importer use the write hazard for timing a page flip to
> only occur
amdgpu only uses shared-fences internally, but dmabuf importers rely on
implicit write hazard tracking via the reservation_object.fence_excl.
For example, the importer use the write hazard for timing a page flip to
only occur after the exporter has finished flushing its write into the
surface. As
Thanks for that!
Reviewed-by: Kent Russell
-Original Message-
From: amd-gfx On Behalf Of Huang Rui
Sent: Tuesday, August 07, 2018 1:28 AM
To: Gustavo A. R. Silva ; Kuehling, Felix
Cc: Oded Gabbay ; Zhou, David(ChunMing)
; David Airlie ;
linux-ker...@vger.kernel.org;
On 08/07/2018 05:59 PM, Christian König wrote:
Am 07.08.2018 um 11:52 schrieb Zhang, Jerry (Junwei):
On 08/07/2018 05:33 PM, Christian König wrote:
Am 07.08.2018 um 10:28 schrieb Zhang, Jerry (Junwei):
On 08/07/2018 04:20 PM, Christian König wrote:
Well NAK, that wasn't the intention of
Under runtime, the wait fence time could be quite long when
other VFs are in exclusive mode.
SWDEV-161490
Change-Id: Ifc32d56ca7fde01b1f4fe2b0db6959b51909008a
Signed-off-by: Monk Liu
Signed-off-by: Emily Deng
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +-
1 file changed, 1
On 2018年08月07日 17:30, Christian König wrote:
Am 07.08.2018 um 09:55 schrieb zhoucm1:
On 2018年08月07日 15:26, Junwei Zhang wrote:
Userspace needs to know if the user memory is from BO or malloc.
Signed-off-by: Junwei Zhang
---
amdgpu/amdgpu.h | 23 +++
Am 07.08.2018 um 11:54 schrieb Zhang, Jerry (Junwei):
On 08/07/2018 03:51 PM, zhoucm1 wrote:
On 2018年08月07日 15:26, Junwei Zhang wrote:
When create bo from user memory, add it to handle table
for future query.
Signed-off-by: Junwei Zhang
---
amdgpu/amdgpu_bo.c | 11 ++-
1 file
Am 07.08.2018 um 11:52 schrieb Zhang, Jerry (Junwei):
On 08/07/2018 05:33 PM, Christian König wrote:
Am 07.08.2018 um 10:28 schrieb Zhang, Jerry (Junwei):
On 08/07/2018 04:20 PM, Christian König wrote:
Well NAK, that wasn't the intention of putting all BOs into the
handle table.
You should
On 08/07/2018 03:51 PM, zhoucm1 wrote:
On 2018年08月07日 15:26, Junwei Zhang wrote:
When create bo from user memory, add it to handle table
for future query.
Signed-off-by: Junwei Zhang
---
amdgpu/amdgpu_bo.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git
On 08/07/2018 05:33 PM, Christian König wrote:
Am 07.08.2018 um 10:28 schrieb Zhang, Jerry (Junwei):
On 08/07/2018 04:20 PM, Christian König wrote:
Well NAK, that wasn't the intention of putting all BOs into the handle table.
You should still use the kernel implementation.
I thought we have
Am 07.08.2018 um 10:28 schrieb Zhang, Jerry (Junwei):
On 08/07/2018 04:20 PM, Christian König wrote:
Well NAK, that wasn't the intention of putting all BOs into the
handle table.
You should still use the kernel implementation.
I thought we have discussed that in below mail thread. any gap?
Am 07.08.2018 um 09:55 schrieb zhoucm1:
On 2018年08月07日 15:26, Junwei Zhang wrote:
Userspace needs to know if the user memory is from BO or malloc.
Signed-off-by: Junwei Zhang
---
amdgpu/amdgpu.h | 23 +++
amdgpu/amdgpu_bo.c | 34 ++
Am 07.08.2018 um 10:47 schrieb Huang Rui:
This patch is to fix the warning to remove unused variable.
/home/ray/linux/drivers/gpu/drm//amd/amdgpu/amdgpu_ctx.c:
In function ‘amdgpu_ctx_priority_override’:
/home/ray/linux/drivers/gpu/drm//amd/amdgpu/amdgpu_ctx.c:397:23:
warning: unused variable
This patch is to fix the warning to remove unused variable.
/home/ray/linux/drivers/gpu/drm//amd/amdgpu/amdgpu_ctx.c:
In function ‘amdgpu_ctx_priority_override’:
/home/ray/linux/drivers/gpu/drm//amd/amdgpu/amdgpu_ctx.c:397:23:
warning: unused variable ‘rq’ [-Wunused-variable]
struct
On 08/07/2018 04:20 PM, Christian König wrote:
Well NAK, that wasn't the intention of putting all BOs into the handle table.
You should still use the kernel implementation.
I thought we have discussed that in below mail thread. any gap?
[PATCH 1/2] drm/amdgpu: return bo itself if userptr is
Well NAK, that wasn't the intention of putting all BOs into the handle
table.
You should still use the kernel implementation.
Christian.
Am 07.08.2018 um 09:26 schrieb Junwei Zhang:
Userspace needs to know if the user memory is from BO or malloc.
Signed-off-by: Junwei Zhang
---
On 2018年08月07日 15:26, Junwei Zhang wrote:
Userspace needs to know if the user memory is from BO or malloc.
Signed-off-by: Junwei Zhang
---
amdgpu/amdgpu.h| 23 +++
amdgpu/amdgpu_bo.c | 34 ++
2 files changed, 57 insertions(+)
diff
On 2018年08月07日 15:26, Junwei Zhang wrote:
When create bo from user memory, add it to handle table
for future query.
Signed-off-by: Junwei Zhang
---
amdgpu/amdgpu_bo.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/amdgpu/amdgpu_bo.c b/amdgpu/amdgpu_bo.c
count indicats the total number of key in handle table
max_key becomes the max value of key
Signed-off-by: Junwei Zhang
---
amdgpu/handle_table.c | 18 +++---
amdgpu/handle_table.h | 1 +
2 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/amdgpu/handle_table.c
Userspace needs to know if the user memory is from BO or malloc.
Signed-off-by: Junwei Zhang
---
amdgpu/amdgpu.h| 23 +++
amdgpu/amdgpu_bo.c | 34 ++
2 files changed, 57 insertions(+)
diff --git a/amdgpu/amdgpu.h b/amdgpu/amdgpu.h
index
Add a test for API to query bo by CPU mapping
Signed-off-by: Junwei Zhang
Reviewed-by: Christian König
---
tests/amdgpu/bo_tests.c | 33 +
1 file changed, 33 insertions(+)
diff --git a/tests/amdgpu/bo_tests.c b/tests/amdgpu/bo_tests.c
index 9d4da4a..dc2de9b
When create bo from user memory, add it to handle table
for future query.
Signed-off-by: Junwei Zhang
---
amdgpu/amdgpu_bo.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/amdgpu/amdgpu_bo.c b/amdgpu/amdgpu_bo.c
index 422c7c9..b24e698 100644
---
62 matches
Mail list logo
