We currently always treat contents of user-buffers as volatile so
we don't need to take any particular action when the state tracker
announces that the contents has changed.
Signed-off-by: Thomas Hellstrom <thellst...@vmware.com>
---
.../drivers/svga/svga_resource_buffer_upload.c | 17 ++---------------
1 files changed, 2 insertions(+), 15 deletions(-)
diff --git a/src/gallium/drivers/svga/svga_resource_buffer_upload.c
b/src/gallium/drivers/svga/svga_resource_buffer_upload.c
index 9239586..a657a8b 100644
--- a/src/gallium/drivers/svga/svga_resource_buffer_upload.c
+++ b/src/gallium/drivers/svga/svga_resource_buffer_upload.c
@@ -651,8 +651,6 @@ svga_redefine_user_buffer(struct pipe_context *pipe,
unsigned offset,
unsigned size)
{
- struct svga_screen *ss = svga_screen(pipe->screen);
- struct svga_context *svga = svga_context(pipe);
struct svga_buffer *sbuf = svga_buffer(resource);
assert(sbuf->user);
@@ -661,19 +659,8 @@ svga_redefine_user_buffer(struct pipe_context *pipe,
assert(!sbuf->hwbuf);
/*
- * Release any uploaded user buffer.
- *
- * TODO: As an optimization, we could try to update the uploaded buffer
- * instead.
+ * We always treat the contents of user-buffers as volatile,
+ * so no particular action needed here.
*/
- pipe_resource_reference(&sbuf->uploaded.buffer, NULL);
-
- pipe_mutex_lock(ss->swc_mutex);
-
- sbuf->key.size.width = sbuf->b.b.width0 = offset + size;
-
- pipe_mutex_unlock(ss->swc_mutex);
-
- svga->dirty |= SVGA_NEW_VBUFFER | SVGA_NEW_VELEMENT;
}
--
1.6.2.5
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
