This allows a BO to have busy placements that are not part of its normal
placements.
Users that want the busy placements to be the same can change the
placement.busy_placement pointer and corresponding count to be the same as
the regular placements.
Signed-off-by: John Brooks
---
drivers/gpu
Signed-off-by: John Brooks
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 3 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 5 +
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 ++
3 files changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd
he flag in amdgpu_fault_reserve_notify() also means that we can
remove the loop to restrict lpfn to the end of visible VRAM, because
amdgpu_ttm_placement_init() will do it for us.
Signed-off-by: John Brooks
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_obj
evictions are needed when moving a BO to visible VRAM,
unreserve the BO while performing them, so as to not block other tasks for
too long. Also, sleep for an interval between each eviction so that the
worker doesn't hog lru_lock.
Signed-off-by: John Brooks
---
drivers/gpu/drm/amd/a
Allow specifying a limit on visible VRAM via a module parameter. This is
helpful for testing performance under visible VRAM pressure.
Signed-off-by: John Brooks
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 4
drivers/gpu/drm/amd/amdgpu
lated stuttering in DiRT Rally as well as very low performance if
visible VRAM is limited to 64MB. It also fixes severely low framerates that
occurred in some areas of Dying Light. All my testing was done with an R9 290
with 4GB of visible VRAM with an Intel i7 4790.
--
John Brooks (Frogging101)
igned-off-by: John Brooks
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index 244a7d3..751bc05 100644
--- a/drivers/gpu/dr
amdgpu_ttm_placement_init() callers that are using both VRAM and GTT as
domains usually don't want visible VRAM as a busy placement.
Signed-off-by: John Brooks
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/dr
y and severity of visible-VRAM-related
stuttering.
Signed-off-by: John Brooks
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 5
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 14 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 45 ++
drivers/gpu/drm/amd/a
))
Signed-off-by: John Brooks
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 6 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 76 +++---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 10 ++--
3 files changed, 70 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm
, at least for this series.
Testing takes a long time and I wanted to focus those testing efforts as much
as possible, produce something well-tested (I hope), and get feedback on this
limited application of the concept before expanding its reach.
John
>
> On 17-06-23 01:39 PM, John B
On Sat, Jun 24, 2017 at 08:07:15PM +0200, Christian König wrote:
> Am 23.06.2017 um 19:39 schrieb John Brooks:
> >This patch series is intended to improve performance when limited CPU-visible
> >VRAM is under pressure.
> >
> >Moving BOs into visible VRAM is essentiall
On Sat, Jun 24, 2017 at 08:09:56PM +0200, Christian König wrote:
> Am 23.06.2017 um 19:39 schrieb John Brooks:
> >amdgpu_ttm_placement_init() callers that are using both VRAM and GTT as
> >domains usually don't want visible VRAM as a busy placement.
> >
> >Signed-
On Sat, Jun 24, 2017 at 08:20:22PM +0200, Christian König wrote:
> Am 24.06.2017 um 01:16 schrieb John Brooks:
> >On Fri, Jun 23, 2017 at 05:02:58PM -0400, Felix Kuehling wrote:
> >>Hi John,
> >>
> >>I haven't read your patches. Just a question based on the
On Sat, Jun 24, 2017 at 08:00:05PM +0200, Christian König wrote:
> Am 23.06.2017 um 19:39 schrieb John Brooks:
> >When the AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED flag is given by userspace,
> >it should only be treated as a hint to initially place a BO somewhere CPU
> >ac
On Mon, Jun 26, 2017 at 06:44:30PM +0900, Michel Dänzer wrote:
> On 24/06/17 02:39 AM, John Brooks wrote:
> > The BO move throttling code is designed to allow VRAM to fill quickly if it
> > is relatively empty. However, this does not take into account situations
> > wher
On Mon, Jun 26, 2017 at 06:38:29PM +0900, Michel Dänzer wrote:
> On 24/06/17 02:39 AM, John Brooks wrote:
> > There is no need for page faults to force BOs into visible VRAM if it's
> > full, and the time it takes to do so is great enough to cause noticeable
> > stutter
he flag in amdgpu_fault_reserve_notify() also means that we can
remove the loop to restrict lpfn to the end of visible VRAM, because
amdgpu_ttm_placement_init() will do it for us.
Signed-off-by: John Brooks
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_obj
Allow specifying a limit on visible VRAM via a module parameter. This is
helpful for testing performance under visible VRAM pressure.
v2: Add cast to 64-bit (Christian König)
Signed-off-by: John Brooks
Reviewed-by: Michel Dänzer
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu
n which side of this tradeoff we want to end up on
for now.
--
John Brooks (Frogging101)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
. (Michel Dänzer)
Fixes: 95844d20ae02 (drm/amdgpu: throttle buffer migrations at CS using a fixed
MBps limit (v2))
Signed-off-by: John Brooks
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 6 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 84 +++---
drivers/gpu/drm/amd
igned-off-by: John Brooks
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index 658d7b1..a215d8c 100644
--- a/drivers/gpu/dr
Signed-off-by: John Brooks
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 3 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 5 +
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 ++
3 files changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd
On Wed, Jun 28, 2017 at 03:06:47PM +0200, Christian König wrote:
> Am 28.06.2017 um 04:33 schrieb John Brooks:
> >Signed-off-by: John Brooks
> >---
> > drivers/gpu/drm/amd/amdgpu/amdgpu.h| 3 +++
> > drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 5 +
>
On Wed, Jun 28, 2017 at 03:05:32PM +0200, Christian König wrote:
> Am 28.06.2017 um 04:33 schrieb John Brooks:
> >When the AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED flag is given by userspace,
> >it should only be treated as a hint to initially place a BO somewhere CPU
> >ac
On Thu, Jun 29, 2017 at 11:35:53AM +0900, Michel Dänzer wrote:
> On 29/06/17 08:26 AM, John Brooks wrote:
> > On Wed, Jun 28, 2017 at 03:05:32PM +0200, Christian König wrote:
> >> Am 28.06.2017 um 04:33 schrieb John Brooks:
> >>> When the AMDGPU_GEM_CREATE_CPU_AC
On 2017-06-29 09:56 PM, John Brooks wrote:
On Thu, Jun 29, 2017 at 11:35:53AM +0900, Michel Dänzer wrote:
On 29/06/17 08:26 AM, John Brooks wrote:
On Wed, Jun 28, 2017 at 03:05:32PM +0200, Christian König wrote:
Am 28.06.2017 um 04:33 schrieb John Brooks:
When the
00 00 48 89 e5 e8 9f fe ff
[149492.279557] ---[ end trace 2d4e0ffcb66a1016 ]---
Unref the fence *after* waiting for it.
Fixes: aff98ba1fdb8 (drm/ttm: wait for eviction in ttm_bo_force_list_clean)
Signed-off-by: John Brooks
---
drivers/gpu/drm/ttm/ttm_bo.c | 3 ++-
1 file changed, 2 inserti
rm/amd/powerplay: refine powerplay interface.)
Signed-off-by: John Brooks
---
drivers/gpu/drm/amd/amdgpu/amdgpu_powerplay.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_powerplay.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_powerplay.c
index 7
s can figure out
why. But at least it unloads now.
--
John Brooks (Frogging101)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
00 00 48 89 e5 e8 9f fe ff
[149492.279557] ---[ end trace 2d4e0ffcb66a1016 ]---
Unref the fence *after* waiting for it.
v2: Set man->move to NULL after dropping the last ref (Christian König)
Fixes: aff98ba1fdb8 (drm/ttm: wait for eviction in ttm_bo_force_list_clean)
Signed-off-by: John Broo
rm/amd/powerplay: refine powerplay interface.)
Signed-off-by: John Brooks
Acked-by: Christian König
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_powerplay.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_powerplay.c
b/d
Resending because it got caught in moderation last time.
What I'm using:
- R9 290
- Kernel 4.9.0
- ASUS PB278Q monitor, connected with DisplayPort
- OpenGL core profile version string: 4.5 (Core Profile) Mesa 13.1.0-devel
(git-d9fef84)
- radeon DDX 7.8.99 (Git)
For as long as I remember I've h
What I'm using:
- R9 290
- Kernel 4.9.0
- ASUS PB278Q monitor, connected with DisplayPort
- OpenGL core profile version string: 4.5 (Core Profile) Mesa 13.1.0-devel
(git-d9fef84)
- radeon DDX 7.8.99 (Git)
For as long as I remember I've had a couple of issues with DisplayPort on the
above setup.
34 matches
Mail list logo
