<p>Doing it in the CPU side during initialization is what I'd go for, this is assuming you are initialising that data once and passing it to the GPU.</p>

<p>On the GPU side, doing the calculations per fragment would be too costly and should be out of the question, unless it's really needed for a special effect then you shouldn't add unneeded ALU work to the fragment shader, this will only cause your application to slow down. On the vertex shader is more acceptable but again if you have highly tessellated geometry, it'll be expensive. </p>

<p>Whenever there is data that you can compute just once, then go for that instead of doing it every frame. Even if you were planning on doing it just once on the GPU and using transform feedback or an FBO to store the data, I think this approach would be more costly. As always though, profile your application, careful tradeoffs are specific to architectures.</p>

CC BY-SA 3.0
2016-09-13T14:17:57.563Z
Just to add some more details about how the right answer can be situational, if your application is CPU bound, that means your GPU is doing less work and is waiting on your CPU between frames.  In this case, it would be less expensive to do it on the GPU since the CPU is already working the entire time, but the GPU isn't.  If you are GPU bound, the reverse is true.  Also, passing tangent and bitangent increases memory usage. If you are memory bound, calculating in the shader can be a good move.
Alan Wolfe
CC BY-SA 3.0
2016-09-12T23:08:32.867Z
2016-09-12T23:08:32.867Z
Fred Garnier
<p>I have two methods of calculating tangent and cotengent (needed for normalMap lighting calculation).</p>

<ul>
<li>The one is doing it from CPP code (with assimp library for example)</li>
<li>The second is doing it directly in shader (in Vertex shader/in fragment shader)</li>
</ul>

<p>What is the best optimized method? (optimized for speed, with vsync activated)</p>

<p>I use Opengl 3.3+</p>

CC BY-SA 3.0
2016-09-12T07:32:48.470Z
Optimized for what? Memory use, speed etc. ? How often does your data update  and so on.
joojaa
CC BY-SA 3.0
2016-09-12T07:36:12.413Z
Optimized for speed
Irrmich
<opengl><shader><gpu>
Where is the best place for Tangent-bitangent calculation, in shader or in C/CPP code?
Irrmich
# Where is the best place for Tangent-bitangent calculation, in shader or in C/CPP code?

(Asked by: username_0 on 2016-09-12)

I have two methods of calculating tangent and cotengent (needed for normalMap lighting calculation).

* The one is doing it from CPP code (with assimp library for example)
* The second is doing it directly in shader (in Vertex shader/in fragment shader)

What is the best optimized method? (optimized for speed, with vsync activated)

I use Opengl 3.3+

**Tags:** opengl, shader, gpu

> **Comments:**
> **username_1**: Optimized for what? Memory use, speed etc. ? How often does your data update  and so on.  
> **username_0**: Optimized for speed  

---

## 1 answers

### Answer by username_2 on 2016-09-12. Score: 7 | Accepted answer

Doing it in the CPU side during initialization is what I'd go for, this is assuming you are initialising that data once and passing it to the GPU.

On the GPU side, doing the calculations per fragment would be too costly and should be out of the question, unless it's really needed for a special effect then you shouldn't add unneeded ALU work to the fragment shader, this will only cause your application to slow down. On the vertex shader is more acceptable but again if you have highly tessellated geometry, it'll be expensive.

Whenever there is data that you can compute just once, then go for that instead of doing it every frame. Even if you were planning on doing it just once on the GPU and using transform feedback or an FBO to store the data, I think this approach would be more costly. As always though, profile your application, careful tradeoffs are specific to architectures.

> **Comments:**
> **username_3**: Just to add some more details about how the right answer can be situational, if your application is CPU bound, that means your GPU is doing less work and is waiting on your CPU between frames.  In this case, it would be less expensive to do it on the GPU since the CPU is already working the entire time, but the GPU isn't.  If you are GPU bound, the reverse is true.  Also, passing tangent and bitangent increases memory usage. If you are memory bound, calculating in the shader can be a good move.  

---

