[Mesa-dev] [PATCH 2/2] st/mesa: Handle GL_MAP_INVALIDATE_BUFFER_BIT in st_bufferobj_map_range().
Jose Fonseca
jfonseca at vmware.com
Sun Jul 17 17:09:30 PDT 2011
PIPE_TRANSFER_DISCARD_WHOLE_RESOURCE was added recently, and is the preferred interface, because:
- it can give better performance when the kernel memory manager supports; it requires less kernel roundtrips than try-map + create + map + dereference.
- it also allows the drivers to do more fancy implementations when kernel doesn't, e.g., keep a round robin of buffers, to avoid consst, which can be freed when memory is low
Preferably, all drivers should implement PIPE_TRANSFER_DISCARD_WHOLE_RESOURCE -- they can simply internally do the try-map + create + map + dereference if there's no way pass that flag to the kernel map ioctl.
If there are strong reasons to not support PIPE_TRANSFER_DISCARD_WHOLE_RESOURCE in certain drivers, then a new PIPE CAP should be added, so that drivers that do support don't limited to the lowest common denominator.
Note that this can happen in other places as well:
- glBufferData
- glTexImage of single level textures.
Jose
----- Original Message -----
> Alternatively, individual drivers could actually implement
> PIPE_TRANSFER_DISCARD_WHOLE_RESOURCE. As far as I can tell only svga
> currently implements that, and st_bufferobj_map_range() seems to be
> the main
> user. I wonder if in general PIPE_TRANSFER_DISCARD_WHOLE_RESOURCE is
> something
> that should just be handled by the state trackers.
>
> As for the actual implementation, we could also try a map with
> PIPE_TRANSFER_DONTBLOCK first, and avoid invalidating
> _NEW_BUFFER_OBJECT in
> some cases. I'm not sure if that's worth it without doing more
> benchmarking
> though, since in the typical case GL_MAP_INVALIDATE_BUFFER_BIT will
> probably
> imply that the buffer is in use.
>
> Signed-off-by: Henri Verbeet <hverbeet at gmail.com>
> ---
> src/mesa/state_tracker/st_cb_bufferobjects.c | 15 +++++++++++++++
> 1 files changed, 15 insertions(+), 0 deletions(-)
>
> diff --git a/src/mesa/state_tracker/st_cb_bufferobjects.c
> b/src/mesa/state_tracker/st_cb_bufferobjects.c
> index 7374bb0..7aa859e 100644
> --- a/src/mesa/state_tracker/st_cb_bufferobjects.c
> +++ b/src/mesa/state_tracker/st_cb_bufferobjects.c
> @@ -332,6 +332,21 @@ st_bufferobj_map_range(struct gl_context *ctx,
> GLenum target,
> obj->Pointer = &st_bufferobj_zero_length;
> }
> else {
> + if (flags & PIPE_TRANSFER_DISCARD_WHOLE_RESOURCE) {
> + struct pipe_resource *buffer;
> +
> + buffer = pipe_buffer_create(pipe->screen,
> + st_obj->buffer->bind,
> + st_obj->buffer->usage,
> + st_obj->buffer->width0);
> + if (buffer) {
> + st_invalidate_state(ctx, _NEW_BUFFER_OBJECT);
> + pipe_resource_reference(&st_obj->buffer, NULL);
> + st_obj->buffer = buffer;
> + flags &= ~PIPE_TRANSFER_DISCARD_WHOLE_RESOURCE;
> + }
> + }
> +
> obj->Pointer = pipe_buffer_map_range(pipe,
> st_obj->buffer,
> offset, length,
> --
> 1.7.2.5
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
More information about the mesa-dev
mailing list