On Tue, Jan 19, 2016 at 10:42 AM, Nicolai Hähnle <nhaeh...@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 <imir...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev