texture2d with bias without dependent texture read.

This topic contains 3 replies, has 2 voices, and was last updated by  PaulL 2 years, 10 months ago.

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

    Hi there, I’m looking for some clarification.

    Is it possible to use the texture2(texcoord.xy,bias) without a dependent texture read being generated?

    The fact the bias is added after the mip calculation lends me to beleive that using the bias param with always generate a dt-read.

    At the moment, our engine has the bias param in all our shader so the bias can be adjusted at any point. I guess this will be leading
    to a dt-read in every one of our shaders.

    Many thanks,




    Could you expand a little about your use case? Are you setting the bias as a uniform?

    Generally, it’s recommended to set the bias as a constant to avoid dependent texture reads. If you’re sure it you don’t need the bias on a particular platform, then avoid setting the bias parameter at all with a macro.


    Hi there,

    It’s for our iOS/Android/Steam game Combat Monsters.

    During game-play the mip levels are fine. During the card view, the mip levels need biasing in order to get more detail.

    Game view:

    Card view (the characters animate, does not show the problem, but you get the idea):

    I’ve tried setting the bias as a uniform and also tried passed through as a varying as the texture co-ordinates z.

    Both are reported as d-texture reads on the iOS profiler, I’m assuming this is true for GLES in general.

    I’d rather not have a second set of fragment shaders with a different bias if possible.

    It’s more of a general question, than platform specific. I guess I’m asking:

    Assuming all platforms need variable mip biasing during the game, is there a d-texture read penalty?

    Many thanks,




    The question needs to be a bit more platform specific. On PowerVR Series 5 hardware, performing a calculation on a texture coordinate means the texture and shading processor may not pre-fetch the texture data correctly, and the fragment shader is stalled waiting for the texture read.

    On PowerVR Series 6 devices, the scheduler hides data fetches behind other computation tasks, which means dependent texture fetches would have negligible impact on performance and are not worth consideration on those platforms.

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