All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] drm/ttm: do not try to preserve caching state
@ 2012-11-28 15:05 j.glisse
  2012-11-28 20:09 ` Jerome Glisse
  0 siblings, 1 reply; 5+ messages in thread
From: j.glisse @ 2012-11-28 15:05 UTC (permalink / raw)
  To: dri-devel; +Cc: Jerome Glisse

From: Jerome Glisse <jglisse@redhat.com>

It make no sense to preserve caching state especialy when
moving from vram to system. It burden the page allocator to
match the vram caching (often WC) which just burn CPU cycle
for no good reasons.

Signed-off-by: Jerome Glisse <jglisse@redhat.com>
---
 drivers/gpu/drm/ttm/ttm_bo.c | 15 +++------------
 1 file changed, 3 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index bf6e4b5..39dcc58 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -896,19 +896,12 @@ static int ttm_bo_mem_force_space(struct ttm_buffer_object *bo,
 }
 
 static uint32_t ttm_bo_select_caching(struct ttm_mem_type_manager *man,
-				      uint32_t cur_placement,
 				      uint32_t proposed_placement)
 {
 	uint32_t caching = proposed_placement & TTM_PL_MASK_CACHING;
 	uint32_t result = proposed_placement & ~TTM_PL_MASK_CACHING;
 
-	/**
-	 * Keep current caching if possible.
-	 */
-
-	if ((cur_placement & caching) != 0)
-		result |= (cur_placement & caching);
-	else if ((man->default_caching & caching) != 0)
+	if ((man->default_caching & caching) != 0)
 		result |= man->default_caching;
 	else if ((TTM_PL_FLAG_CACHED & caching) != 0)
 		result |= TTM_PL_FLAG_CACHED;
@@ -978,8 +971,7 @@ int ttm_bo_mem_space(struct ttm_buffer_object *bo,
 		if (!type_ok)
 			continue;
 
-		cur_flags = ttm_bo_select_caching(man, bo->mem.placement,
-						  cur_flags);
+		cur_flags = ttm_bo_select_caching(man, cur_flags);
 		/*
 		 * Use the access and other non-mapping-related flag bits from
 		 * the memory placement flags to the current flags
@@ -1023,8 +1015,7 @@ int ttm_bo_mem_space(struct ttm_buffer_object *bo,
 						&cur_flags))
 			continue;
 
-		cur_flags = ttm_bo_select_caching(man, bo->mem.placement,
-						  cur_flags);
+		cur_flags = ttm_bo_select_caching(man, cur_flags);
 		/*
 		 * Use the access and other non-mapping-related flag bits from
 		 * the memory placement flags to the current flags
-- 
1.7.11.7

^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: [PATCH] drm/ttm: do not try to preserve caching state
  2012-11-28 15:05 [PATCH] drm/ttm: do not try to preserve caching state j.glisse
@ 2012-11-28 20:09 ` Jerome Glisse
  2012-11-28 22:18   ` Thomas Hellstrom
  0 siblings, 1 reply; 5+ messages in thread
From: Jerome Glisse @ 2012-11-28 20:09 UTC (permalink / raw)
  To: dri-devel; +Cc: Jerome Glisse

On Wed, Nov 28, 2012 at 10:05 AM,  <j.glisse@gmail.com> wrote:
> From: Jerome Glisse <jglisse@redhat.com>
>
> It make no sense to preserve caching state especialy when
> moving from vram to system. It burden the page allocator to
> match the vram caching (often WC) which just burn CPU cycle
> for no good reasons.
>
> Signed-off-by: Jerome Glisse <jglisse@redhat.com>
> ---
>  drivers/gpu/drm/ttm/ttm_bo.c | 15 +++------------
>  1 file changed, 3 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index bf6e4b5..39dcc58 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -896,19 +896,12 @@ static int ttm_bo_mem_force_space(struct ttm_buffer_object *bo,
>  }
>
>  static uint32_t ttm_bo_select_caching(struct ttm_mem_type_manager *man,
> -                                     uint32_t cur_placement,
>                                       uint32_t proposed_placement)
>  {
>         uint32_t caching = proposed_placement & TTM_PL_MASK_CACHING;
>         uint32_t result = proposed_placement & ~TTM_PL_MASK_CACHING;
>
> -       /**
> -        * Keep current caching if possible.
> -        */
> -
> -       if ((cur_placement & caching) != 0)
> -               result |= (cur_placement & caching);
> -       else if ((man->default_caching & caching) != 0)
> +       if ((man->default_caching & caching) != 0)
>                 result |= man->default_caching;
>         else if ((TTM_PL_FLAG_CACHED & caching) != 0)
>                 result |= TTM_PL_FLAG_CACHED;
> @@ -978,8 +971,7 @@ int ttm_bo_mem_space(struct ttm_buffer_object *bo,
>                 if (!type_ok)
>                         continue;
>
> -               cur_flags = ttm_bo_select_caching(man, bo->mem.placement,
> -                                                 cur_flags);
> +               cur_flags = ttm_bo_select_caching(man, cur_flags);
>                 /*
>                  * Use the access and other non-mapping-related flag bits from
>                  * the memory placement flags to the current flags
> @@ -1023,8 +1015,7 @@ int ttm_bo_mem_space(struct ttm_buffer_object *bo,
>                                                 &cur_flags))
>                         continue;
>
> -               cur_flags = ttm_bo_select_caching(man, bo->mem.placement,
> -                                                 cur_flags);
> +               cur_flags = ttm_bo_select_caching(man, cur_flags);
>                 /*
>                  * Use the access and other non-mapping-related flag bits from
>                  * the memory placement flags to the current flags
> --
> 1.7.11.7
>

Note this is mostly to mitigate performance decrease when a lot of
eviction happen. It increase perf by as much of 60% on my computer.

Cheers,
Jerome

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] drm/ttm: do not try to preserve caching state
  2012-11-28 20:09 ` Jerome Glisse
@ 2012-11-28 22:18   ` Thomas Hellstrom
  2012-11-28 23:13     ` Jerome Glisse
  0 siblings, 1 reply; 5+ messages in thread
From: Thomas Hellstrom @ 2012-11-28 22:18 UTC (permalink / raw)
  To: Jerome Glisse; +Cc: Jerome Glisse, dri-devel

On 11/28/2012 09:09 PM, Jerome Glisse wrote:
> On Wed, Nov 28, 2012 at 10:05 AM,  <j.glisse@gmail.com> wrote:
>> From: Jerome Glisse <jglisse@redhat.com>
>>
>> It make no sense to preserve caching state especialy when
>> moving from vram to system. It burden the page allocator to
>> match the vram caching (often WC) which just burn CPU cycle
>> for no good reasons.

Nack.
This is a driver problem.

What happens with this patch if you evict write-combined TT memory to 
system?
That's why we want to preserve caching state in the first place.

If you need a different behavior, you can fine-tune in 
driver::evict_flags, or in the
radeon-case in radeon_move_ram_vram / radeon_move_vram_ram.

/Thomas

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] drm/ttm: do not try to preserve caching state
  2012-11-28 22:18   ` Thomas Hellstrom
@ 2012-11-28 23:13     ` Jerome Glisse
  2012-11-28 23:25       ` Jerome Glisse
  0 siblings, 1 reply; 5+ messages in thread
From: Jerome Glisse @ 2012-11-28 23:13 UTC (permalink / raw)
  To: Thomas Hellstrom; +Cc: Jerome Glisse, dri-devel

On Wed, Nov 28, 2012 at 5:18 PM, Thomas Hellstrom <thomas@shipmail.org> wrote:
> On 11/28/2012 09:09 PM, Jerome Glisse wrote:
>>
>> On Wed, Nov 28, 2012 at 10:05 AM,  <j.glisse@gmail.com> wrote:
>>>
>>> From: Jerome Glisse <jglisse@redhat.com>
>>>
>>> It make no sense to preserve caching state especialy when
>>> moving from vram to system. It burden the page allocator to
>>> match the vram caching (often WC) which just burn CPU cycle
>>> for no good reasons.
>
>
> Nack.
> This is a driver problem.
>
> What happens with this patch if you evict write-combined TT memory to
> system?
> That's why we want to preserve caching state in the first place.
>
> If you need a different behavior, you can fine-tune in driver::evict_flags,
> or in the
> radeon-case in radeon_move_ram_vram / radeon_move_vram_ram.

No you can't. Because cur placement of vram will be wc, and thus it
will want to preserve it for gtt. Only way to force it is to declare
vram as cached too.

Cheers,
Jerome

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] drm/ttm: do not try to preserve caching state
  2012-11-28 23:13     ` Jerome Glisse
@ 2012-11-28 23:25       ` Jerome Glisse
  0 siblings, 0 replies; 5+ messages in thread
From: Jerome Glisse @ 2012-11-28 23:25 UTC (permalink / raw)
  To: Thomas Hellstrom; +Cc: Jerome Glisse, dri-devel

On Wed, Nov 28, 2012 at 6:13 PM, Jerome Glisse <j.glisse@gmail.com> wrote:
> On Wed, Nov 28, 2012 at 5:18 PM, Thomas Hellstrom <thomas@shipmail.org> wrote:
>> On 11/28/2012 09:09 PM, Jerome Glisse wrote:
>>>
>>> On Wed, Nov 28, 2012 at 10:05 AM,  <j.glisse@gmail.com> wrote:
>>>>
>>>> From: Jerome Glisse <jglisse@redhat.com>
>>>>
>>>> It make no sense to preserve caching state especialy when
>>>> moving from vram to system. It burden the page allocator to
>>>> match the vram caching (often WC) which just burn CPU cycle
>>>> for no good reasons.
>>
>>
>> Nack.
>> This is a driver problem.
>>
>> What happens with this patch if you evict write-combined TT memory to
>> system?
>> That's why we want to preserve caching state in the first place.
>>
>> If you need a different behavior, you can fine-tune in driver::evict_flags,
>> or in the
>> radeon-case in radeon_move_ram_vram / radeon_move_vram_ram.
>
> No you can't. Because cur placement of vram will be wc, and thus it
> will want to preserve it for gtt. Only way to force it is to declare
> vram as cached too.
>
> Cheers,
> Jerome

Now that i think a bit more to it, in all fairness you can do so from
the driver side.

Cheers,
Jerome

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2012-11-28 23:25 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-11-28 15:05 [PATCH] drm/ttm: do not try to preserve caching state j.glisse
2012-11-28 20:09 ` Jerome Glisse
2012-11-28 22:18   ` Thomas Hellstrom
2012-11-28 23:13     ` Jerome Glisse
2012-11-28 23:25       ` Jerome Glisse

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.