texture2D Cycle Count

This topic contains 3 replies, has 2 voices, and was last updated by  Joe Davis 7 years ago.

Viewing 4 posts - 1 through 4 (of 4 total)
  • Author
    Posts
  • #30248

    pail
    Member

    I’m examining a shader using PVRUniSCoEditor v1.3. I have a question regarding the cycle counts for texture2D in an OpenGL ES 2.0 fragment shader. The cycle counts are shown in parentheses below for reading just the rgb values of a texture:

        (4) vec3 c0 = texture2D(img0, vTexture0.xy).rgb;
        (3) vec3 c1 = texture2D(img0, vTexture0.zw).rgb;
        (3) vec3 c2 = texture2D(img0, vTexture1.xy).rgb;

    If I read in the rgba values, the cycle counts are:

        (2) vec4 c0 = texture2D(img0, vTexture0.xy);
        (1) vec4 c1 = texture2D(img0, vTexture0.zw);
        (1) vec4 c2 = texture2D(img0, vTexture1.xy);

    I would have thought that reading in less data would have resulted in the rgb version having lower cycle counts. I’m not entirely sure what the cycle counts mean for texture2D, I guess. (This shader will be reading from an RGBA texture.)

    I would imagine the cycles aren’t including the time it takes to actually retrieve the data. It seems that would depend more on the hardware.

    So, is it generally better for one to read in rgba rather than rgb?

    (I know the ultimate answer is to test it out on the hardware, but I generally don’t have access to the hardware, an iPhone 4.)

    Thanks.

    #34225

    Joe Davis
    Member

    Hi pail,

    I apologise for the slow response on this.

    The reason you are seeing a difference in cycle counts between the .xy and .zw samples is that the hardware treats .zw texture coordinates as dependent texture reads. This is a result of the swizzle causes by using the zw values of the vector. As the compiler only estimates per line cycle counts, the extra cycle is added to the first line that is encountered (as the dependent texture read is not tied to a particular line of code as far as the compiler is concerned).

    In the case of the xy sample, the hardware is able to sample the texture ahead of time, thereby saving the additional cycles a dependent read induces (as well as avoiding a stall it may cause).

    You can resolve this issue by using two vec2 texture coordinates instead of packing this into a vec4. Both scenarios require two 32 bit registers to store this information, so there is no advantage to packing the data into a vec4.

    As for the difference between the .rgb and full rgba sampling, the difference in cycle counts is due to the data being natively stored as a vec4. This means a single vec4 move operation is required to sample this data, whereas only using a subset of this data requires a more complex operation to retrieve the required information.

    Regards,

    JoeJoe2010-10-05 10:54:18

    #34226

    pail
    Member

    Thanks. That is great information. I was able to eke out 1 more fps. While that may not seem like much, we are targeting 15 fps, so to me that is good progress. We are doing many passes with many filters. Our worst case is now about 12 fps.

    #34227

    Joe Davis
    Member

    Glad to hear it helped 🙂

    If you have any other shader compiler related questions to help you further improve the performance of your code, feel free to start a new topic. I’ll try to get back sooner next time

Viewing 4 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic.