[Mesa-dev] [PATCH 05/10] llvmpipe: implement user constant buffers

Roland Scheidegger sroland at vmware.com
Wed Jan 10 23:12:05 UTC 2018


Am 10.01.2018 um 20:49 schrieb Marek Olšák:
> From: Marek Olšák <marek.olsak at amd.com>
> 
> ---
>  src/gallium/drivers/llvmpipe/lp_screen.c   |  2 +-
>  src/gallium/drivers/llvmpipe/lp_state_fs.c | 18 +++++++++++++++++-
>  2 files changed, 18 insertions(+), 2 deletions(-)
> 
> diff --git a/src/gallium/drivers/llvmpipe/lp_screen.c b/src/gallium/drivers/llvmpipe/lp_screen.c
> index b5b4d29..1f881be 100644
> --- a/src/gallium/drivers/llvmpipe/lp_screen.c
> +++ b/src/gallium/drivers/llvmpipe/lp_screen.c
> @@ -205,21 +205,21 @@ llvmpipe_get_param(struct pipe_screen *screen, enum pipe_cap param)
>        return 1;
>     case PIPE_CAP_GLSL_FEATURE_LEVEL:
>        return 330;
>     case PIPE_CAP_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION:
>        return 0;
>     case PIPE_CAP_COMPUTE:
>        return 0;
>     case PIPE_CAP_USER_VERTEX_BUFFERS:
>        return 1;
>     case PIPE_CAP_USER_CONSTANT_BUFFERS:
> -      return 0;
> +      return 1;
>     case PIPE_CAP_VERTEX_BUFFER_OFFSET_4BYTE_ALIGNED_ONLY:
>     case PIPE_CAP_VERTEX_BUFFER_STRIDE_4BYTE_ALIGNED_ONLY:
>     case PIPE_CAP_VERTEX_ELEMENT_SRC_OFFSET_4BYTE_ALIGNED_ONLY:
>     case PIPE_CAP_TGSI_TEXCOORD:
>        return 0;
>     case PIPE_CAP_DRAW_INDIRECT:
>        return 1;
>  
>     case PIPE_CAP_CUBE_MAP_ARRAY:
>        return 1;
> diff --git a/src/gallium/drivers/llvmpipe/lp_state_fs.c b/src/gallium/drivers/llvmpipe/lp_state_fs.c
> index 0daf7ae..f29d672 100644
> --- a/src/gallium/drivers/llvmpipe/lp_state_fs.c
> +++ b/src/gallium/drivers/llvmpipe/lp_state_fs.c
> @@ -61,20 +61,21 @@
>  #include "pipe/p_defines.h"
>  #include "util/u_inlines.h"
>  #include "util/u_memory.h"
>  #include "util/u_pointer.h"
>  #include "util/u_format.h"
>  #include "util/u_dump.h"
>  #include "util/u_string.h"
>  #include "util/simple_list.h"
>  #include "util/u_dual_blend.h"
>  #include "util/os_time.h"
> +#include "util/u_upload_mgr.h"
>  #include "pipe/p_shader_tokens.h"
>  #include "draw/draw_context.h"
>  #include "tgsi/tgsi_dump.h"
>  #include "tgsi/tgsi_scan.h"
>  #include "tgsi/tgsi_parse.h"
>  #include "gallivm/lp_bld_type.h"
>  #include "gallivm/lp_bld_const.h"
>  #include "gallivm/lp_bld_conv.h"
>  #include "gallivm/lp_bld_init.h"
>  #include "gallivm/lp_bld_intr.h"
> @@ -3072,25 +3073,40 @@ llvmpipe_delete_fs_state(struct pipe_context *pipe, void *fs)
>  }
>  
>  
>  
>  static void
>  llvmpipe_set_constant_buffer(struct pipe_context *pipe,
>                               enum pipe_shader_type shader, uint index,
>                               const struct pipe_constant_buffer *cb)
>  {
>     struct llvmpipe_context *llvmpipe = llvmpipe_context(pipe);
> -   struct pipe_resource *constants = cb ? cb->buffer : NULL;
> +   struct pipe_constant_buffer c;
>  
>     assert(shader < PIPE_SHADER_TYPES);
>     assert(index < ARRAY_SIZE(llvmpipe->constants[shader]));
>  
> +   if (shader != PIPE_SHADER_VERTEX &&
> +       shader != PIPE_SHADER_GEOMETRY &&
> +       cb && cb->user_buffer) {
> +	   c.buffer = NULL;
> +	   c.buffer_size = cb->buffer_size;
> +	   c.user_buffer = NULL;
> +
> +	   u_upload_data(pipe->const_uploader, 0, cb->buffer_size, 64,
> +		         cb->user_buffer, &c.buffer_offset, &c.buffer);
> +	   u_upload_unmap(pipe->const_uploader);
> +	   cb = &c;
> +   }
Is that actually necessary? I thought for fragment shaders it should also
just work, because we copy all constant data to scene memory in any case,
and the place where this is happening (try_update_scene_state()) looks
like it should handle user buffers.

Roland


> +   struct pipe_resource *constants = cb ? cb->buffer : NULL;
> +
>     /* note: reference counting */
>     util_copy_constant_buffer(&llvmpipe->constants[shader][index], cb);
>  
>     if (constants) {
>         if (!(constants->bind & PIPE_BIND_CONSTANT_BUFFER)) {
>           debug_printf("Illegal set constant without bind flag\n");
>           constants->bind |= PIPE_BIND_CONSTANT_BUFFER;
>        }
>     }
>  
> 



More information about the mesa-dev mailing list