Keith, redefine_user_buffer() would be a good compromise and I believe the performance hit wouldn't be so noticable. It would also allow partial uploads of constants in a user buffer, which is something we'd like to have too. Currently, st/mesa in st_draw_vbo is doing: - N calls to resource_destroy - some unnecessary computations - N calls to user_buffer_create - 1 call to set_vertex_buffers - 1 call to set_vertex_elements_state If we can replace this by N calls to redefine_user_buffer, then I am all for it, provided neither _NEW_ARRAY nor _NEW_PROGRAM is dirty of course. Can the function look, let's say, like this? void redefine_user_buffer(struct pipe_context *, struct pipe_resource *, const struct pipe_box *); Marek <div class="gmail_quote">On Mon, Feb 7, 2011 at 5:15 PM, Keith Whitwell <<a href="mailto:keithw@vmware.com">keithw@vmware.com</a>> wrote: <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><div style="font-family: Times New Roman; font-size: 12pt; color: rgb(0, 0, 0);">Marek, I'm fine with keeping user buffers -- it's only a vague hope they'll fade away over time, and I'm comfortable with keeping them as long as their behaviour is well understood. The really important thing for me is to preserve traceability. That is to say it should be possible to observe what happens over the interface and infer directly from that when something important happens. In this case, that would mean having a way to notice that the contents and/or size of a userbuffer changed. That could be as simple as a notification call that this has happened, for example "redefine_user_buffer()". On your current drivers that call would be a noop -- hopefully that's not going to be a noticiable performance hit? Then in some tracing or recording module, that call could be used to log the contents of the userbuffer to a file, or in some future indirect-rendering equivalent, the new contents could be transmitted across the wire, etc. This would mean that userbuffers continue to have a known size, etc, and would require the state-tracker to issue the redefine call as necessary. You're in a better position than me to comment on the performance impact of this. If you're saying this isn't workable from a performance POV, then as you suggest we'll have to find a way to push the logic for identifying when userbuffers changed down into those components (tracing, remoting, etc) which care about it. Keith </div></div></blockquote></div>