Passing array with texcoords as varying.

[lusius]

I want to be able to populate an array in the vertexshader to improve the performance of texture fetches greatly but I can't seem to find a way to do this.

static var SRC = {
    @param var texture:Sampler2D;
    @param var motionDirection:Vec2;
    @param var amplitude:Float;
    @param @const var Samples:Int = 10;
    @var var texCoords:Array<Vec2, Samples>;
    function vertex() {
        var d = normalize(motionDirection) * amplitude;
        @unroll for (i in 0...Samples) {
            texCoords[i].xy = (input.uv + d * float(i));
        }
        output.position = vec4(input.position.x, input.position.y * flipY, 0, 1);
    }
    function fragment() {
        // terminate. destroy
        pixelColor *= 0.0;
        @unroll for (i in 0...Samples) {
            pixelColor.rgba += texture.get(texCoords[i]);
        }
        pixelColor *= 1.0 / float(Samples);
    }
}

gives me .hx:15: characters 5-17 : This expression cannot be assigned (refering to the vertex texCoords[i] = ... line)

What is the suggested way of passing n-sized arrays as varying in hxsl?

[ncannasse]

I don't think we support arrays of varying. Is it allowed in GLSL? Also, varying are a bit expensive so unless the UVs calculation is very complex (which is not in your sample) then I don't think that will provide some optimization here, the texture fetch will most likely be the bottleneck anyway

[lusius]

Yes there is not problem sending arrays as varying in opengl.

It's not expensive at all and especially not compared to the benefits of texture prefetching. Avoiding dependent texture reads can done by using texture coordinates passed directly to the fragment shader (meaning, if uvcalculations are done before passing it to the texture fetch in the shader, we add overhead and introduce dependency and therefore miss this crucial part.

I've made huge optimizations on several platforms just by moving for example an gaussian kernel to the vertex shader and passing it to the vertex.

https://coolcodea.wordpress.com/2014/10/09/172-optimising-shaders/

from site:

"Dynamic texture lookups, also known as dependent texture reads, occur when a fragment shader computes texture coordinates rather than using the unmodified texture coordinates passed into the shader. Dependent texture reads are supported at no performance cost on OpenGL ES 3.0–capable hardware; on other devices, dependent texture reads can delay loading of texel data, reducing performance. When a shader has no dependent texture reads, the graphics hardware may prefetch texel data before the shader executes, hiding some of the latency of accessing memory."

If hxsl doesn't support varying arrays then a way would simply be to pass a matrix but then i would strongly recommend to implement support for accessing the matrix as an array also to be able to write nice code-unrolls such as

mat[x][y] = ... or mat[x] = ...

(which is also supported in glsl and hlsl from what i know and most shader languages.)

I would be really happy if this could be done and I would gladly update many of your shaders to make use of this great opt to increase overall performance.

[ncannasse]

Thanks, I'll look into it. Please note that dependent texture reads only reduces performances on very low end devices. On modern PC hardware, there is no real gain in doing so.

[lusius]

Thanks for responding!

Regarding perfomance reduction only on low-end I'm mildly agreeing and from experience disagreeing. I/We target mostly webgl and such and we will encouter an extreme broad range of hardware and even some modern hardware have this quirk and from my experience it's always good practise to do as much work as possible in the vertex shader.

OpenGL ES 3.0 devices and up will not have this problem ackording to Apple but from our case this isn't always true and vendors come up with all kind of wierd driver implementations and since the fix for this (array passing) is already industry i would really hope you would implement this into your shaderlanguage.

I hope getting varying array support into hxsl will be easy for you since it would help us alot. We cannot deploy heavy shaders such as the built-in blur if we cannot guarantee it's optimized in a industry-standard manner for targetting many devices.

If not possible, at least it would be nice to be able to use arrayaccess on datatypes such as vec or mat to simulate this behavior.

Thanks for responding!