Hi,
I am having difficulty in understanding why you implemented pipe_surface in
st_atom_atomicbuf.c.
On Mon, Nov 17, 2014 at 2:24 AM, Aditya Avinash adityaavina...@gmail.com
wrote:
Hi,
On Sunday, November 16, 2014, Ilia Mirkin imir...@alum.mit.edu wrote:
The direction I went in was by
Because shader resources were already specified as pipe_surfaces (in
the existing, albeit presently unused API). A pipe_surface is a
wrapper around a resource that specifies what view of the resource
should be writable, and attaches an optional format to that resource.
Normally pipe_surfaces are
Hi,
I agree with the solution. Considering images as buffers or buffers
as images (as they are operated inside shaders but not texture units)
makes sense. I think we can make atomic buffers as a part of
ARB_shader_image_load_store. Because, images are 2D array of buffers with
atomic operations run
The issue with STORE isn't whether it's necessary (it is!), but the
exact semantics of the TGSI opcode. The way I have it in my patch
right now is that it doesn't have a destination, which upsets the dead
code removal logic in st_glsl_to_tgsi greatly. For now I've just
commented it out, but that's
The direction I went in was by adapting the shader resources interface
for this. I believe it will be possible to use for
shader_image_load_store as well.
See https://github.com/imirkin/mesa/commits/atomic
I believe that makes a lot more sense than creating a special counter
buffer type only to
---
src/gallium/include/pipe/p_context.h | 5 +
src/gallium/include/pipe/p_defines.h | 7 ++-
src/gallium/include/pipe/p_state.h | 10 ++
3 files changed, 21 insertions(+), 1 deletion(-)
diff --git a/src/gallium/include/pipe/p_context.h
b/src/gallium/include/pipe/p_context.h
