<p>I wrote a 2D fluid-solver in OpenGL (<a href="https://github.com/nilspin/SDL_OpenGL_Project" rel="noreferrer">code here</a>) some time back. </p>

<p>While it runs flawlessly on my onboard Intel GPU, </p>

<p><a href="https://i.sstatic.net/RPBpF.png" rel="noreferrer"><img src="https://i.sstatic.net/RPBpF.png" alt="when running on Intel GPU"></a></p>

<p>the simulation very quickly "blows-up" when same code is run using nvidia card :  </p>

<p><a href="https://i.sstatic.net/Xs5Sm.png" rel="noreferrer"><img src="https://i.sstatic.net/Xs5Sm.png" alt="mere half a second into the program"></a></p>

<p>In the second picture, the fluid is being "added" to the system and "diffusing away" too, but unlike the 1st picture there is no advection.  </p>

<p>I would like to know what might possibly cause this. Could this be because different vendors might be interpreting the standard differently?  </p>

<p>PS : The "red" and "green" colors represent magnitude of vector-field in <em>x</em> and <em>y</em> directions respectively.</p>

CC BY-SA 3.0
2015-08-21T20:20:52.653Z
There can definitely be differences between IHV implementations. It could be due to a driver bug, or different interpretations of ambiguities in the standard, or even possibly differences in how the compilers treat floating-point arithmetic, etc. Would need some more detailed debugging to understand what's going on.
Nathan Reed
CC BY-SA 3.0
2015-08-22T00:20:14.553Z
@NathanReed ,what kind of information could be helpful?
nilspin
CC BY-SA 3.0
2015-08-22T00:47:23.243Z
Start by debugging it like any other graphics/shader problem. Isolate each pass and see in which pass the error is being introduced, then isolate where in that shader is something going wrong.
Nathan Reed
CC BY-SA 3.0
2015-08-28T04:09:40.887Z
This might be a vsync issue if you're using a variable timestep per-frame.
Mokosha
CC BY-SA 3.0
2015-09-08T22:42:38.267Z
Are you using any vendor-dependent GLSL functions like noise*(which as far as I know, most vendors don't implement anyway)?
Sam
CC BY-SA 3.0
2015-09-09T10:00:19.927Z
@Sam no. I am only using texture(). That shouldn't cause a problem, right?
nilspin
CC BY-SA 3.0
2015-09-09T23:25:30.043Z
@nilspin I don't think so. They're both running on the same OpenGL version, right?
Sam
CC BY-SA 3.0
2015-09-10T04:36:55.543Z
@Sam yes they are.
nilspin
<opengl><fluid-sim>
Code runs differently on different hardware
nilspin
# Code runs differently on different hardware

(Asked by: username_0 on 2015-08-21)

I wrote a 2D fluid-solver in OpenGL ([code here](https://github.com/username_0/SDL_OpenGL_Project)) some time back.

While it runs flawlessly on my onboard Intel GPU,

[![when running on Intel GPU](https://i.sstatic.net/RPBpF.png)](https://i.sstatic.net/RPBpF.png)

the simulation very quickly "blows-up" when same code is run using nvidia card :

[![mere half a second into the program](https://i.sstatic.net/Xs5Sm.png)](https://i.sstatic.net/Xs5Sm.png)

In the second picture, the fluid is being "added" to the system and "diffusing away" too, but unlike the 1st picture there is no advection.

I would like to know what might possibly cause this. Could this be because different vendors might be interpreting the standard differently?

PS : The "red" and "green" colors represent magnitude of vector-field in *x* and *y* directions respectively.

**Tags:** opengl, fluid-sim

> **Comments:**
> **username_1**: There can definitely be differences between IHV implementations. It could be due to a driver bug, or different interpretations of ambiguities in the standard, or even possibly differences in how the compilers treat floating-point arithmetic, etc. Would need some more detailed debugging to understand what's going on.  
> **username_0**: @username_1 ,what kind of information could be helpful?  
> **username_1**: Start by debugging it like any other graphics/shader problem. Isolate each pass and see in which pass the error is being introduced, then isolate where in that shader is something going wrong.  
> **username_2**: This might be a vsync issue if you're using a variable timestep per-frame.  
> **username_3**: Are you using any vendor-dependent GLSL functions like noise*(which as far as I know, most vendors don't implement anyway)?  
> **username_0**: @username_3 no. I am only using texture(). That shouldn't cause a problem, right?  
> **username_3**: @username_0 I don't think so. They're both running on the same OpenGL version, right?  
> **username_0**: @username_3 yes they are.  

---

## 0 answers

