On 26 September 2015 at 03:32, Ilia Mirkin <imir...@alum.mit.edu> wrote:
> Hi Ian (and other spec experts),
>
> The ARB_ssbo spec mentions the following:
>
> OpenGL 4.0 (either core or compatibility profile) is required.
>
> ...
>
> Additionally, the shading language provides the memoryBarrier() function
> to control the relative order of memory accesses within individual shader
> invocations and provides various memory qualifiers controlling how the
> memory corresponding to individual variables is accessed.
>
> However the memoryBarrier() function only becomes available in GLSL
> 4.20 [along with the glMemoryBarrier() function that the spec also
> refers to] or with ARB_shader_image_load_store.
>
> Is the implication that such functionality should be auto-exposed in
> image-less drivers that support ssbo? Or that this functionality
> should just not exist unless images are supported?
>
> This is relevant to me as I plan on adding ssbo support to gallium
> before images. Also, is there really anything in there that would
> prevent this from being exposed on a GL 3.1 driver (I'm thinking of
> freedreno which doesn't support GS yet and is my initial target for
> this, since I can make atomics actually work on there, unlike NVIDIA
> where the damn things just won't budge without some magic
> yet-to-be-found make-it-work bit).
>
> Cheers,
>
> -ilia
> _______________________________________________
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
I think that is an error in the ARB_ssbo spec (as that spec also
mentions: "This extension is written against the OpenGL 4.2
(Compatibility Profile) Specification."). I believe this occurred as
ARB_ssbo was adapted from NV_ssbo; NV_ssbo does not mention
MemoryBarrier (i.e. someone forgot to update the version when NV_ssbo
was enhanced for ARB).
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
