On Thu, Jul 9, 2015 at 5:30 PM, Ilia Mirkin <imir...@alum.mit.edu> wrote: > On Thu, Jul 9, 2015 at 5:05 PM, Marek Olšák <mar...@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. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
