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 On Mon, Feb 7, 2011 at 5:15 PM, Keith Whitwell <kei...@vmware.com> wrote: > 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 >
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev