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 <mic...@daenzer.net> wrote: > From: Michel Dänzer <michel.daen...@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.daen...@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@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
