I am filing this issue for the purpose of opening the can of worms on shader and shader-performance portability. One theme that has come up is the expectation of portability in that incorrect use of the API would not work on one platform but work on another, the example issue being #862 . For compute shaders, there is the issue of size of shared memory (and for that matter how much padding arrays of structs in shared memory will take). Another issue which is more common is array access.

Consider the following code

uniform int M, MM;
uniform isampler1D S, T;
out float V;
float my_array[SomeMaxSize];
int size = 0;

my_array[0] = some_ugly_computation(0, ..);
for (int i = 1; i < M; ++i)
{
    my_array[i] = some_ugly_computation(my_array[i - 1], ..);
}

float R = 0.0;
for (int i =0; i < MM; ++i)
 {
   R += texture(S, my_array[texture(T, i, 0)], 0);
}

this is perfectly legal shader code as far as I can tell and will run and work on Intel GPU's and drivers.

However, in the past, random array access from shaders (especially fragment) of local arrays was dicy on lots of GPU's.

Another ugly issue is how much shared memory is available to compute? Will it be queryable and a compute application adapts to the value? Or is the value the minimum across all minimums of the backend API's? Same question for work group sizes as well.

What is the plan for these kind of things?