Marek Olšák <mar...@gmail.com> writes:
> On Fri, Mar 23, 2012 at 1:40 AM, Francisco Jerez <curroje...@riseup.net>
> wrote:
>> diff --git a/src/gallium/include/pipe/p_context.h
>> b/src/gallium/include/pipe/p_context.h
>> index aaeeb81..de990fe 100644
>> --- a/src/gallium/include/pipe/p_context.h
>> +++ b/src/gallium/include/pipe/p_context.h
>> @@ -63,6 +63,7 @@ struct pipe_vertex_element;
>> struct pipe_video_buffer;
>> struct pipe_video_decoder;
>> struct pipe_viewport_state;
>> +struct pipe_compute_state;
>> union pipe_color_union;
>>
>> /**
>> @@ -140,6 +141,9 @@ struct pipe_context {
>> void (*bind_geometry_sampler_states)(struct pipe_context *,
>> unsigned num_samplers,
>> void **samplers);
>> + void (*bind_compute_sampler_states)(struct pipe_context *,
>> + unsigned num_samplers,
>> + void **samplers);
>
> Hi,
>
Hi,
> could you please add an "unsigned start_slot" parameter in
> bind_compute_sampler_states? The function would then look like this:
>
> void (*bind_compute_sampler_states)(struct pipe_context *,
> unsigned start_slot,
> unsigned num_samplers,
> void **samplers);
>
> Where start_slot+num_samplers <= max_samplers, and max_samplers =
> get(SHADER_CAP_MAX_TEXTURE_SAMPLERS).
>
> The reason for this is that state changes will be faster if you only
> need to change a subset of the bound states (less work for the pipe
> driver).
This sounds reasonable to me. I'll make that change on the three entry
points and resend later today.
> The disadvantage is that the states will have to be unbound
> using something like this:
>
> void *null_ptrs[MAX_SAMPLERS] = {NULL};
> bind_compute_sampler_states(pipe, 0, max_samplers, null_ptrs);
>
Another option would be to take 'samplers == NULL' as meaning that the
specified slot range has to be unbound, e.g.:
| bind_compute_sampler_states(pipe, 0, max_samplers, NULL);
To keep things as simple as possible in the driver we could add the
restriction that no 'samplers[i]' will ever be NULL in cases where
samplers is non-NULL. The usefulness of being able to bind and unbind
states at the same time with the same call is quite dubious anyway...
> I am aware that the other functions don't have the start_slot
> parameter and I'd like to update them so that they do (I have started
> reworking set_vertex_buffers), but that will be a lot of work. In the
> case of compute, where the interface hasn't landed yet, it would be
> wise to add start_slot as soon as possible, so that we don't have to
> rewrite drivers for it later on.
>
>[...]
pgpNvs8Zm5bgm.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
