Oh well I will add to the, somethings. Right now, as far as I know, to get GL+CL to have all the goodies as the D3D11+DirectCompute, one needs:
[ul][li] GL_EXT_shader_image_load_store[] GL_NV_shader_buffer_load[] GL_NV_shader_buffer_store[*] Something new and funky to build commands in other threads outside to be executed[/ul] [/li]
The NV extensions are needed because, if I remember correctly, D3D11 also has a link list traversal thing in there too.
You can do linked list traversal with GL_EXT_shader_image_load_store and you can use buffers with that extension as well if you use buffer textures.
The only major thing that the NV extensions provide is pointers to GPU memory but that is a not so portable feature so you should not expect anything like that get into GL (at least that what would be logical).
You can do linked list traversal with GL_EXT_shader_image_load_store and you can use buffers with that extension as well if you use buffer textures.
Very true in spirit, but the pain of setting it up is notable, since… likely what would happen is that one would use a texture buffer object (R16UI or such) to make a list of indices to walk, or needing to create a linked list, one would have an image of format RG16UI or similar for the list of indices “addresses”, the .r for which value to use from a texture buffer object and the .g for the next element in a linked list…
but shudders, setting that up well… write a linked list in a shader would be quite painful too… where as NV_shader_buffer_load/store make it so much easier 
It is just an API thing. I’m pretty sure that D3D 11 does the same thing under-the-hood just it abstracts it with API.
Why I think that this is maybe not the best idea is that this way you hide the actual memory access pattern from the user.
I agree that it is much easier to have struct fetches built-in but personally I would rather go with atomic texel fetches as this way at least I know how the various fetching instructions perform on the various cards (e.g. R32F or RGBA32F, etc.).
So, to sum it up, I’m happy with the current solution but not against struct fetches if they will come somewhen.