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 would be perfect for that hardware, but it would be ugly.
From the radeonsi point of view, writable resources are no different from textures and texture buffers. So pipe_sampler_view maps well to radeonsi. Marek On Tue, Jan 6, 2015 at 7:17 PM, Ilia Mirkin <imir...@alum.mit.edu> wrote: > 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, 2015 at 12:54 PM, Marek Olšák <mar...@gmail.com> wrote: >> 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 looks like a design fail. It >> exactly matches Evergreen/Cayman design, which is now deprecated. >> Evergreen shares UAV slots with colorbuffers. There are 12 slots, the >> first 8 can be colorbuffers, those that are unused can be UAVs, so you >> have at least 4. If you bind only one colorbuffer, you can bind 11 >> UAVs, etc. The other problem with this design is that UAVs can only be >> used in the pixel shader. It would be a bad idea to follow this design >> precisely in Gallium. We should have something more generic and let >> drivers describe any limitations with CAPs. >> >> Marek >> >> >> On Tue, Jan 6, 2015 at 6:14 PM, Roland Scheidegger <srol...@vmware.com> >> wrote: >>> 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 for render / depth stencil target). >>> I guess an alternative would be to use a new view type altogether (like >>> d3d does). >>> I admit I don't quite get how the same stuff is done with d3d11 (as we >>> should have an interface which works for that as well). It looks like >>> what's called shader resource in gallium (as in set_shader_resources) is >>> really UAVs in d3d11 (though I'm not quite sure how these are actually >>> set in d3d11 in the ddi - at the api level these are interestingly >>> enough set together with render targets >>> (OMSetRenderTargetsAndUnorderedAccessViews()) though the parameters are >>> all separate). >>> These atomics here more look like the structured buffers which are also >>> set the same way (maybe?), at least there's mention of append/consume >>> buffers too there. >>> >>> Roland >>> >>> >>> >>> Am 06.01.2015 um 16:27 schrieb Marek Olšák: >>>> 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) >>>> - images (load+store+atomic) >>>> >>>> Hardware resource categories on r600: >>>> - textures and read-only buffers (sample+load only) >>>> - constant buffers (load only) >>>> - writable buffers and images (load+store+atomic) >>>> >>>> Hardware resource categories on radeonsi: >>>> - none, everything is considered a generic shader resource and >>>> supports load+store+atomic+sample >>>> >>>> Thus, it is preferable to use set_shader_resources for all writable >>>> resources and keep the current interfaces for sampler views and >>>> constant buffers intact. >>>> >>>> Marek >>>> >>>> >>>> On Tue, Jan 6, 2015 at 2:54 PM, 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 ? >>>>> >>>>> 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 roughly matches D3D11s >>>>> "unordered access views" [1], though D3D11's UAVs can by typed [2], or raw >>>>> [3]. >>>>> >>>>> Also, are counter buffers in user memory really supported? I can't spot >>>>> any >>>>> mention of that in GL_ARB_shader_atomic_counters. >>>>> >>>>> I think that rather than mimicking pipe_constant_buffer, this feature >>>>> should >>>>> more closely to sampler views. >>>>> >>>>> >>>>> I confess I'm not familiar with counter buffers / UAVs, but I think this >>>>> needs a bit more thought to avoid being completely redone in the medium >>>>> term. >>>>> >>>>> >>>>> Jose >>>>> >>>>> >>>>> [1] >>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__msdn.microsoft.com_en-2Dgb_library_windows_desktop_ff476335.aspx-23Unordered-5FAccess&d=AwIGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=Vjtt0vs_iqoI31UfJxBl7yv9I2FeiaeAYgMTLKRBc_I&m=UKHfRUDlIPUSvsUpW3toE2gMpzd1CNUNRIK4CjGrCHo&s=qMm6xJyygPBy-qluPFLHmzH_39o-dSlbG87meenKyq8&e= >>>>> [2] >>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__msdn.microsoft.com_en-2Dgb_library_windows_desktop_ff476258.aspx&d=AwIGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=Vjtt0vs_iqoI31UfJxBl7yv9I2FeiaeAYgMTLKRBc_I&m=UKHfRUDlIPUSvsUpW3toE2gMpzd1CNUNRIK4CjGrCHo&s=f2PAAZTT1Eu1wCjexvk_Hx7otgD3wAOz_yFMUN583UM&e= >>>>> [3] >>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__msdn.microsoft.com_en-2Dgb_library_windows_desktop_ff476900.aspx-23Raw-5FBuffer-5FViews&d=AwIGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=Vjtt0vs_iqoI31UfJxBl7yv9I2FeiaeAYgMTLKRBc_I&m=UKHfRUDlIPUSvsUpW3toE2gMpzd1CNUNRIK4CjGrCHo&s=CcRwntJiBsA-k0qo9UAxZrLbluEyp3huZlvFtJCJNms&e= >>>>> >>>>> >>>>> On 04/01/15 21:44, adityaatluri wrote: >>>>>> >>>>>> --- >>>>>> 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 >>>>>> index af5674f..bf3be31 100644 >>>>>> --- a/src/gallium/include/pipe/p_context.h >>>>>> +++ b/src/gallium/include/pipe/p_context.h >>>>>> @@ -44,6 +44,7 @@ struct pipe_blit_info; >>>>>> struct pipe_box; >>>>>> struct pipe_clip_state; >>>>>> struct pipe_constant_buffer; >>>>>> +struct pipe_counter_buffer; >>>>>> struct pipe_depth_stencil_alpha_state; >>>>>> struct pipe_draw_info; >>>>>> struct pipe_fence_handle; >>>>>> @@ -201,6 +202,10 @@ struct pipe_context { >>>>>> uint shader, uint index, >>>>>> struct pipe_constant_buffer *buf ); >>>>>> >>>>>> + void (*set_counter_buffer)( struct pipe_context *, >>>>>> + uint shader, uint index, >>>>>> + struct pipe_counter_buffer *buf ); >>>>>> + >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> void (*set_framebuffer_state)( struct pipe_context *, >>>>>> const struct pipe_framebuffer_state * >>>>>> ); >>>>>> >>>>>> diff --git a/src/gallium/include/pipe/p_defines.h >>>>>> b/src/gallium/include/pipe/p_defines.h >>>>>> index 8c4e415..717ab6a 100644 >>>>>> --- a/src/gallium/include/pipe/p_defines.h >>>>>> +++ b/src/gallium/include/pipe/p_defines.h >>>>>> @@ -341,6 +341,7 @@ enum pipe_flush_flags { >>>>>> #define PIPE_BIND_VERTEX_BUFFER (1 << 4) /* set_vertex_buffers >>>>>> */ >>>>>> #define PIPE_BIND_INDEX_BUFFER (1 << 5) /* draw_elements */ >>>>>> #define PIPE_BIND_CONSTANT_BUFFER (1 << 6) /* set_constant_buffer >>>>>> */ >>>>>> +#define PIPE_BIND_COUNTER_BUFFER (1 << 7) /* set_counter_buffer */ >>>>>> #define PIPE_BIND_DISPLAY_TARGET (1 << 8) /* flush_front_buffer >>>>>> */ >>>>>> #define PIPE_BIND_TRANSFER_WRITE (1 << 9) /* transfer_map */ >>>>>> #define PIPE_BIND_TRANSFER_READ (1 << 10) /* transfer_map */ >>>>>> @@ -572,6 +573,8 @@ enum pipe_cap { >>>>>> PIPE_CAP_MAX_VERTEX_ATTRIB_STRIDE = 109, >>>>>> PIPE_CAP_SAMPLER_VIEW_TARGET = 110, >>>>>> PIPE_CAP_CLIP_HALFZ = 111, >>>>>> + PIPE_CAP_USER_COUNTER_BUFFERS = 112, >>>>>> + PIPE_CAP_COUNTER_BUFFER_OFFSET_ALIGNMENT = 113, >>>>>> }; >>>>>> >>>>>> #define PIPE_QUIRK_TEXTURE_BORDER_COLOR_SWIZZLE_NV50 (1 << 0) >>>>>> @@ -631,7 +634,9 @@ enum pipe_shader_cap >>>>>> PIPE_SHADER_CAP_PREFERRED_IR, >>>>>> PIPE_SHADER_CAP_TGSI_SQRT_SUPPORTED, >>>>>> PIPE_SHADER_CAP_MAX_SAMPLER_VIEWS, >>>>>> - PIPE_SHADER_CAP_DOUBLES >>>>>> + PIPE_SHADER_CAP_DOUBLES, >>>>>> + PIPE_SHADER_CAP_MAX_COUNTER_BUFFER_SIZE, >>>>>> + PIPE_SHADER_CAP_MAX_COUNTER_BUFFERS >>>>>> }; >>>>>> >>>>>> /** >>>>>> diff --git a/src/gallium/include/pipe/p_state.h >>>>>> b/src/gallium/include/pipe/p_state.h >>>>>> index 43bc48b..49fae5d 100644 >>>>>> --- a/src/gallium/include/pipe/p_state.h >>>>>> +++ b/src/gallium/include/pipe/p_state.h >>>>>> @@ -57,6 +57,7 @@ extern "C" { >>>>>> #define PIPE_MAX_CLIP_PLANES 8 >>>>>> #define PIPE_MAX_COLOR_BUFS 8 >>>>>> #define PIPE_MAX_CONSTANT_BUFFERS 32 >>>>>> +#define PIPE_MAX_COUNTER_BUFFERS 32 >>>>>> #define PIPE_MAX_SAMPLERS 16 >>>>>> #define PIPE_MAX_SHADER_INPUTS 32 >>>>>> #define PIPE_MAX_SHADER_OUTPUTS 48 /* 32 GENERICs + POS, PSIZE, FOG, >>>>>> etc. */ >>>>>> @@ -462,6 +463,15 @@ struct pipe_constant_buffer { >>>>>> const void *user_buffer; /**< pointer to a user buffer if buffer == >>>>>> NULL */ >>>>>> }; >>>>>> >>>>>> +/** >>>>>> + * A Counter buffer. A new buffer is set everytime a variable with >>>>>> + * atomic_uint is defined. >>>>>> + */ >>>>>> +struct pipe_counter_buffer{ >>>>>> + struct pipe_resource *buffer; /**< The actual buffer */ >>>>>> + unsigned buffer_offset; /**< The offset to start of data in buffer in >>>>>> bytes */ >>>>>> + const void *user_buffer; /**< The buffer which is created by the >>>>>> compiler */ >>>>>> +}; >>>>>> >>>>>> /** >>>>>> * A stream output target. The structure specifies the range vertices >>>>>> can >>>>>> >>>>> >>>>> _______________________________________________ >>>>> mesa-dev mailing list >>>>> mesa-dev@lists.freedesktop.org >>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.freedesktop.org_mailman_listinfo_mesa-2Ddev&d=AwIGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=Vjtt0vs_iqoI31UfJxBl7yv9I2FeiaeAYgMTLKRBc_I&m=UKHfRUDlIPUSvsUpW3toE2gMpzd1CNUNRIK4CjGrCHo&s=yeOKjr9Wd2qQqv6PMmrwzZbQJK_BqiA4FnHRgd5FD8E&e= >>>> _______________________________________________ >>>> mesa-dev mailing list >>>> mesa-dev@lists.freedesktop.org >>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.freedesktop.org_mailman_listinfo_mesa-2Ddev&d=AwIGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=Vjtt0vs_iqoI31UfJxBl7yv9I2FeiaeAYgMTLKRBc_I&m=UKHfRUDlIPUSvsUpW3toE2gMpzd1CNUNRIK4CjGrCHo&s=yeOKjr9Wd2qQqv6PMmrwzZbQJK_BqiA4FnHRgd5FD8E&e= >>>> >>> >> _______________________________________________ >> mesa-dev mailing list >> mesa-dev@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
