Do we really need a new pipe_context::set_counter_buffer method?
Shouldn't this case be covered by pipe_context::set_shader_resources ?
If we really need new method, I'd like we have better names for them, so
we can clearly distinguish them.
IIUC GL_ARB_shader_atomic_counters correctly, this
On Tue, Jan 6, 2015 at 8:54 AM, Jose Fonseca jfons...@vmware.com wrote:
Do we really need a new pipe_context::set_counter_buffer method? Shouldn't
this case be covered by pipe_context::set_shader_resources ?
FWIW this is the approach I've taken in
https://github.com/imirkin/mesa/commits/atomic
Using set_shader_resources is preferable. I'd rather it used
pipe_sampler_view, not pipe_surface.
GL has a lot of shader resource types though:
- uniform buffers (load only)
- textures and texture buffers (sample+load only)
- storage buffers (load+store)
- atomic counter buffers (atomic only)
-
Ah, OK. I was interpreting sampler view as all the things you need to
be able to sample from a resource, and surface as all the things you
need to know where to write in a resource, including a render target.
But you guys have all been playing this game for much much longer than
me...
On Tue, Jan
Am 06.01.2015 um 18:54 schrieb Marek Olšák:
I would just rename pipe_sampler_view to pipe_resource_view. I don't
think pipe_sampler_view has a lot to do with samplers. It's just a
universal view into textures and yes, buffers too. Of course, some
fields don't apply to certain types and use
Actually initially pipe_surface really was for traditional render
surface. There were even stand-alone surfaces (i.e. not based on
resources) for the non-fbo (system window) surfaces - this is why the
width/height fields are actually still in there in a pipe_surface (yes
with a XXX comment)...
So,
Hi,
I lost this mail in the mail box.
I am sorry about patch related to pipe. My work is based on Ilia Mirkin
pipe commits. As per my previous mail, you can ignore pipe patch.
My current work is related to R600 backend.
On Tue, Jan 6, 2015 at 8:54 AM, Jose Fonseca jfons...@vmware.com wrote:
Do
Having a different view type for writable shader resources sounds good.
An alternative solution would be to have separate functions for images
and buffers:
- set_image_views - image views only, pipe_image_view should look
similar to pipe_surface
- set_shader_buffers - buffers only, untyped, no
On Tue, Jan 6, 2015 at 4:23 PM, Marek Olšák mar...@gmail.com wrote:
Having a different view type for writable shader resources sounds good.
An alternative solution would be to have separate functions for images
and buffers:
- set_image_views - image views only, pipe_image_view should look
You are quite right using pipe_surface seems like a bit of an abuse.
pipe_sampler_view wouldn't be quite right though neither, no samplers
are involved. Plus, the views here cannot have multiple mip levels
(which is presumably why pipe_surface was used - nevertheless
pipe_surface was intended only
I thought that a surface was basically a writable view into a
resource. What does sampler view have that surface doesn't (that
matters)? The only thing I can think of is levels, but does anything
actually support multi-level stuff? (ARB_shader_image_load_store
doesn't seem to.)
On Tue, Jan 6,
I thought pipe_surface was a render target view.
From the r600 point of view, writable resources are pretty much
colorbuffers, because they share slots with colorbuffers and are set
up exactly like colorbuffers. So pipe_surface maps well to r600, and
using set_framebuffer_state for setting UAVs
I would just rename pipe_sampler_view to pipe_resource_view. I don't
think pipe_sampler_view has a lot to do with samplers. It's just a
universal view into textures and yes, buffers too. Of course, some
fields don't apply to certain types and use cases.
OMSetRenderTargetsAndUnorderedAccessViews
---
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
Hi,
About this patch:
1. It is not tested. I'll test it after 12th.
2. It implements atomic buffers as a surface which can be reused for
ARB_shader_image_load_store
3. You can ignore the first patch.
My questions:
1. What does R_028AC0_ALU_ATOM_CACHE_GS_0 represent?
2. What determines the values
15 matches
Mail list logo
