[Mesa-dev] [PATCH] gallium: make image views non-persistent objects

[Ilia Mirkin]

On Tue, Jan 19, 2016 at 10:42 AM, Nicolai Hähnle <nhaehnle at gmail.com> wrote:
> On 18.01.2016 22:08, Ilia Mirkin wrote:
>>
>> Make them akin to shader buffers, with no refcounting/etc. Just used to
>> pass data about the bound image in ->set_shader_images.
>>
>> Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu>
>> ---
>>
>> I don't really see a reason why these were refcounted objects. It seems
>> like
>> it would be convenient to make these line up with shader buffers, so
>> that's
>> what I've done here.
>>
>> Please let me know if I'm missing something.
>
>
> I haven't thought about this much, but at least Radeon does quite a bit of
> work in create_sampler_view.
>
> Since everything boils down to the same hardware resource descriptors in the
> end, I'd expect the same to happen for a create_image_view. I believe we'll
> want a create_image_view which ends up calling code that is shared with
> create_sampler_view.
>
> So make that a vote against this change from me.
>
> Come to think of it, from a Radeon perspective I'm not sure why there is a
> separate pipe_image_view structure in the first place (other than perhaps
> reducing confusion about which combination of fields make sense).

A key difference between images and sampler views is that images don't
have any funky parameters -- no filtering, wrapping, etc. You can only
do the equivalent of texelFetch (imageLoad) and imageStore, to exact
integer coordinates. I think it's a much simpler object than a sampler
view.

Samplers/texture views are longer lived objects on NVIDIA hardware --
there are separate binding tables with them, and remapping tables,
etc. It would be inconvenient to reupload those every time, esp as it
involves various flushes. I don't think there's any such thing with
images.

Anyways, if the consensus is to make these live longer, that's fine
too. It just seemed unnecessary.

  -ilia