[Mesa-dev] [PATCH] r600g, radeonsi: Always use GTT again for PIPE_USAGE_STREAM buffers

[Marek Olšák]

Perhaps Valley uses scattered writes, which the write-combining cache
doesn't like? u_upload_mgr mostly uses sequential writes, so I think
it could still benefit from VRAM placement. Just guessing.

Does the STREAM flag which causes problems come from Valley
(glBufferData) or from Mesa (u_upload_mgr, etc.)?

Marek

On Thu, Aug 28, 2014 at 8:37 AM, Michel Dänzer <michel at daenzer.net> wrote:
> From: Michel Dänzer <michel.daenzer at amd.com>
>
> Putting those in VRAM seems to cause (worse) stutter in Unigine Valley on
> some systems.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82050
> Signed-off-by: Michel Dänzer <michel.daenzer at amd.com>
> ---
>  src/gallium/drivers/radeon/r600_buffer_common.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/radeon/r600_buffer_common.c b/src/gallium/drivers/radeon/r600_buffer_common.c
> index ee05776..acdabc0 100644
> --- a/src/gallium/drivers/radeon/r600_buffer_common.c
> +++ b/src/gallium/drivers/radeon/r600_buffer_common.c
> @@ -110,11 +110,13 @@ bool r600_init_resource(struct r600_common_screen *rscreen,
>         enum radeon_bo_flag flags = 0;
>
>         switch (res->b.b.usage) {
> +       case PIPE_USAGE_STREAM:
> +               flags = RADEON_FLAG_GTT_WC;
> +               /* fall through */
>         case PIPE_USAGE_STAGING:
>                 /* Transfers are likely to occur more often with these resources. */
>                 res->domains = RADEON_DOMAIN_GTT;
>                 break;
> -       case PIPE_USAGE_STREAM:
>         case PIPE_USAGE_DYNAMIC:
>                 /* Older kernels didn't always flush the HDP cache before
>                  * CS execution
> --
> 2.1.0
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev