[Mesa-dev] [RFC] gallium: add interface for writable shader images

Ilia Mirkin imirkin at alum.mit.edu
Thu Jul 9 14:38:05 PDT 2015

On Thu, Jul 9, 2015 at 5:30 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
> On Thu, Jul 9, 2015 at 5:05 PM, Marek Olšák <maraeo at gmail.com> wrote:
>> I'd like to discuss one more thing that will affect whether image
>> slots will be global (shared by all shaders) or not.
>> Which image unit an image uniform uses is not a compile-time thing,
>> but it's specified later using glUniform1i. That means we need a
>> per-shader table that maps image uniforms to global image units. One
>> possible solution is to add this pipe_context function:
>> void (*set_shader_image_mapping)(
>>    struct pipe_context *, unsigned shader,
>>    unsigned start_decl_index, unsigned count,
>>    unsigned *decl_to_slot_mapping);
>> This is only required if the shader image slots are global and not
>> per-shader. (if they are per-shader, st/mesa can reorder the slots for
>> each shader independently just like it already does for textures and
>> UBOs) Shader storage buffer objects suffer from the same issue. Atomic
>> counters don't.
>> Therefore, image slots must be per-shader (like sampler slots) to
>> avoid this craziness and keep things simple.
> I think that's reasonable. The image slots can be fixed at
> compile-time (like sampler slots), and we can just stick the right
> images into the right places. But in order to do that, we need the
> per-stage mapping, so making it like sampler views seems reasonable.

Oh, except that for textures there's a BIND_TIC/BIND_TSC per shader
stage that lets you point a particular index at an arbitrary
texture/sampler. But the IMAGE things are global from what I can tell
-- there's no extra remapping stage. Ugh, I really don't want to have
to introduce shader variants :( I guess I could just expose images in
fragment shaders.

On Kepler, this should all work out. For texturing, you point it at a
constant buffer that contains the relevant data, I suspect it's
similar for images.

More information about the mesa-dev mailing list