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

Roland Scheidegger sroland at vmware.com
Thu Jan 11 01:19:42 UTC 2018


Am 11.01.2018 um 00:27 schrieb Marek Olšák:
> On Thu, Jan 11, 2018 at 12:12 AM, Roland Scheidegger <sroland at vmware.com> wrote:
>> 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.
> 
> OK, I didn't notice that. llvmpipe seems to work without this patch.

Ok, for 1,2,3,5,7,8
Reviewed-by: Roland Scheidegger <sroland at vmware.com>


More information about the mesa-dev mailing list