Difference between texture viewer and output on screen

[ibachar]

Description

I have an issue where the texture viewer shows a different image than what is displayed on screen. When I use the texture viewer to display the color values in the image below, they appear as 0 but actually the final image is displayed as white (as it should be).

Steps to reproduce

This is the image as displayed in the capture preview (which is the same as displayed in the actual application)

This image is from the texture viewer

As you can see, when picking the colors they are displayed as black.

Also here is a capture of the entire frame:

As you can see the input to the blit (which is the final step of the frame) is a black cube

Environment

• RenderDoc version: 1.10
• Operating System: Win10 x64
• Graphics API: OpenGL 3.3

I'm on a laptop (Asus) with nVidia MX250, Driver version 442.94

[baldurk]

You have not provided steps to reproduce. Steps to reproduce are exactly what they sound like - steps I can follow to reproduce the issue, not screenshots that show little to no useful information.

Please list actual reproduction steps with your bug report.

[ibachar]

Yeah I understand but I can't provide you with simple steps to reproduce since this issue started to happen once I switched to using floating point framebuffer. I can't try to create a minimal example showing the issue but that will take some time. Anyway, if this is not a known issue and didn't happen to anyone else, I'll investigate it further and if I come to a conclusion I'll post it. In the mean time feel free to close this issue

[baldurk]

The reproduction steps don't have to be simple or minimal, as long as I can get the bug to happen I can investigate it. For example if you could share the capture or your application that would be fine and I can reproduce with that. If you can't share any of those things then it would be useful to know exactly what is going wrong beyond just that the colour of one element is wrong. For example knowing that the element is wrong because XYZ uniform has the incorrect value because it should be 'x' instead of 'y' as set with 'glFoobar' is more specific information even if not sufficient.

I generally fix issues as soon as I know about them so there isn't a large list of known problems, and even if it were it would not be possible to tell from your description what the problem might be since it could be explained by a vast number of causes.

[ibachar]

capture.zip
I've attached the capture. Thank you for your time

[baldurk]

The draw that renders the black square has a pixel shader that after #ifdef processing returns an output of only materialDiffuse * ambientColor, where ambientColor is set to 0.0, 0.0, 0.0. This is set just before the draw, the uniform is at location 5 (in this capture) and there's a call to glUniform3fv that sets location 5 to 0.0, 0.0, 0.0.

I don't know how it was drawing as white in the application but that seems inconsistent with what should be happening, so my guess is either you're relying on undefined behaviour somewhere or else there's a driver bug. I see you're using an Intel GPU, I've found Intel's drivers to be unreliable in the past particularly for GL so I'd suggest it is worth trying a different GPU.

[ibachar]

The ambientColor is indeed set to black, but there is another rendering pass (EID 212) which takes a directional light into account which should cause the box to appear white (the light is white, pointing directly at the box).
Regarding the GPU, I have an nVidia MX250 graphics card on my laptop, but it will be interesting to run it on my desktop (GTX 1060) and see the result of the capture

[baldurk]

EID 212 looks to invoke undefined behaviour, it has sampler2DShadow textures that it uses, but the sampler objects bound at those slots do not have depth comparisons enabled. The nvidia driver points this out specifically:

Program undefined behavior warning: The current GL state uses a sampler (6) that has depth comparisons disabled, with a texture object (7) with a depth format, by a shader that samples it with a shadow sampler. This will result in undefined behavior.

[ibachar]

Thanks, that is probably the issue. I'm using a sampler object with the texture but set GL_TEXTURE_COMPARE_MODE using glTexParameteri. As stated in the OpenGL wiki:

When a sampler object is bound to a texture image unit, the internal sampling parameters for a texture bound to the same image unit are all ignored. Instead, the sampling parameters are taken from this sampler object.

It is weird that it still displayed properly on my application.

BTW, where in RenderDoc did you see this warning?

Thanks again.

[baldurk]

I found it by enabling API validation when loading the capture, but note that RenderDoc is not intended to diagnose API use faults so this should not be relied upon. You should enable the API validation directly in your application and fix any issues it identifies. Since OpenGL leaves the validation up to the driver andyou're running on an Intel GPU it might not find this issue, but nvidia's driver does.

[ibachar]

Great, thank you very much!