GLSL issue: dfdy sign differce

[Antony_Riakiotakis]

Hi,

We have noticed an issue in blender in our Screen Space Ambient Occlusion Shader,  issue in our tracker can be found in

https://developer.blender.org/T43987

Initial report is for ATI card but I've replicated the behaviour in an Intel HD 3000 GPU too.

I have pinned down the issue to sign difference in the built-in dfdY when writing to the window framebuffer as opposed to writing to a framebuffer object. We are using EXT_framebuffer_object to do the rendering in those cases.

Not sure if the GPU is supposed to be supported still, but maybe the issue it's relevant for newer GPUs as well?

Is it possible for the driver team to quickly test for this? I only have blender here as a test application but this is probably much more complex than you need. I could probably try writing a small file but it would help to know if it's OK to use helper libraries such as GLEW or you want a file in pure C/C++

The machine I've tested this on:

Windows 7

Graphics card is HD 3000

Driver version is 9.17.10.3347 (date 29/01/2014)

[Michael_C_Intel2]

Hi Antony,

A test file in pure C/C++ would be better for our developers. It may be that HD 3000 does not support the features required, I need to check that. 

-Michael

[Antony_Riakiotakis]

Alright, attached a c++ file with cmake and glew (glew is latest static glew library for 64bit windows, feel free to subsitute the library for 32 bit if you wish, but only use the static version for this test, and make sure to update the CMakeFile if you do)

The test is simple,  it writes a quad on the screen and passes gl_Vertex in a varying variable. In the fragment shader, we calculate the dFdy derivative of the varying.

There are two cases. When you run the program you should be able to toggle between the two cases by pressing space. In one case we use the shader to draw directly on the window back buffer. dFdy is negative and we see black. In the second case, we use the exact same shader and input to draw on a texture using framebuffer objects, then we switch to drawing on the backbuffer and we use the texture to texture a quad. Result here is green, as expected (position y value increases as we go up on the buffer).

According to a new test by a user of blender, the bug influences even the HD4000 series of GPUs

Please let me know if you need anything more.

[Michael_C_Intel2]

Hi Antony,

Thanks I have passed this along to the developer investigating the issue. I will update you when we learn more.

-Michael 

[Michael_C_Intel2]

Hi Antony,

We were able to replicate the issue on 15.28.23.64.4101 and on 15.31-3165.But on the latest 15.33 production driver it no longer occurs, so for HD 4000 and newer we can recommend using this driver:

15.33.32.64.4061:https://downloadcenter.intel.com/download/24593/Intel-HD-Graphics-Driver...

Unfortunately no further drivers in the older branches (15.31 and older) are planned additional 15.33 with be EOL soon. That means that no fix will be available for HD 3000 and older GPUs. Only HD 4000 and newer will work.

-Michael

[Antony_Riakiotakis]

Thanks for the heads up. Unfortunately this means we will have to compare driver version strings in blender to detect the correct factors for dfdy calculations, but it's good that it's fixed in recent drivers at least.

[invisible-cow]

Blender will soon drop support for HD 3000 on Windows -- moving to OpenGL 3.2 minimum for our 2.8 release. So we'll be able to remove these driver specific hacks.

-- Mike