[Mesa-dev] Gallium proposal: add a user pointer in pipe_resource

[Marek Olšák]

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 <keithw at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20110208/ed8574d0/attachment.htm>