Is it reasonable to build cos/sin/acos/asin func textures? (HLSL)

Is it reasonable to build cos/sin/acos/asin func textures? (HLSL)

• Naga Kumar .J.V

  Thanks! I actually removed the acos completely using an approximation for the computation where the acos was involved. Before that I simply replaced the acos by a 2d texture lookup in an abrbitrary texture to compare the performance. As your post suggest, the acos is much faster than the texture look up in my shader context (using a GF 7800 GTX). But when I have time I may compare the shader output, as you suggest.

  Nico

  
  

• Lenn

  When it comes to sin and cos, for modern cards it's better to use math rather than texture lookup. The more modern the card, the faster math is compared to texture lookup.
  
  It's rather hard for me to tell you which cards a certain method is better for, because I don't fully remember. Offhand, all Radeon cards had pretty fast sin/cos, but as Jack said, a sincos assembly instruction still counts for 8 instruction slots, so if you're instruction limited that's a problem. I think that the GeForceFX 5x00 cards were faster at texturing than at math (though I also remember vaguely something about fast sincos). If you want to be fast on all cards, you'd just have to optimise for each of them. If you're mainly aiming to be fast on the newest generations and future cards, I think that math is the way to go.
  
  Some other considerations:
  
  The shader assembly instruction for sin/cos is only guaranteed to handle angles in the range -pi to pi, so it's possible that the HLSL compiler will generate code to bring the angles to this range. That'd slow things down. See "sincos - ps" in the DX docs.
  
  asin and acos aren't directly supported in shader assembly.
  
  I'd suggest that you write simple shaders using both sin and asin, and use fxc to see what they compile to. That'd give you some idea of what to expect regarding performance.
  
  If you try this, please post the results of your investigation.
  

  Edit: I just noticed your post about using shader model 3. SM3 cards should have pretty fast math, so going that way instead of textures may be a good idea. However, I'd still suggest checking out what the compiler outputs, and also, depending on the shader, it may be beneficial to use textures in case there isn't a lot of texture access, and so the texture units are idle. Again, the best thing is to test on different cards and optimise for them.

  
  

• RHJ

  Thanks! I didn't have instruction count limit problems so far, because I'm using a 3.0 shader, but I will try the lookup and compare frame rates. :)
  

• telespan

  All depends on task - sometimes it's reasonable to save memory and waste a little CPU cycles, sometimes CPU cycles are more precious and memory are not a problem.
  
  

• HenryHan

  Depending on your shader model, a precomputed trig lookup might actually be your *only* option. I forget the exact numbers, but a lighting model I was looking at recently exploded the ps_2_0 instruction limit if I computed it rather than looked it up.
  
  Whether it's more efficient or not is probably difficult to say for certain, but I'd imagine it'll be faster to look it up - the risk is reduced accuracy/granularity. Texture fetches have a certain latency that can often be filled with ALU operations to keep the shader cores ticking over. Although it's still a fine balance.
  
  
  Jack
  
  

• awperli

  I have one doubt : "asin and acos aren't directly supported in shader assembly."

  If I am developing a vertex shader using the assembly instructions 2.x, how do I implement asin, acos etc using the available instructions Do I need to make a taylor series approximation or something like that or is there a simpler solution kindly help me in this regard...

  Thanks in advance for replying at the earliest...

  Sridhar

  
  
  

• JesseJ

  Well, it's about the GPU, not the CPU and a cos/sin/acos/asin tecture will probably not need much storage space. What I'm interested in is if the intrinsic HLSL fuctions are quicker than a texture lookup (plus a possible index (tex coord) computation).

  
  
• Is it reasonable to build cos/sin/acos/asin func textures? (HLSL)