I have the following Fragment Shader:
#version 450
uniform int umsch;//umschalten
layout(location = 0) out vec4 Helligkeit;
void main( void ){
do {
if(umsch != 0){
Helligkeit = vec4(0.0, 1.0, 1.0, 1.0);
return;
}
//break;
} while(false);
Helligkeit = vec4(0.5f);
return;
}
where umsch a uniform variable that I can toggle via the OpenGL API by a keystroke.
Now, if I'm not completely crazy then it shouldn't make a difference whether the break statement is there or not. But (in the FS) it does.
When the break statement is uncommented then I can't achieve an early return from the FS. But early returns are allowed in the FS according to the GLSL spec.
I can achieve the desired result if I toggle a flag inside the if body and check for it later.
I have the most recent drivers and checked the code on an HD5870 and a RX480 card. My operating system is Windows 7 64bit.
Thanks for reporting this. Can you provide a repro for this issue? Thanks.
>Can you provide a repro for this issue?
What do you mean with repro? You want the additional Shader code for the VS and the initialising C++ code to run the problematic FS?
Correct. A simple application which would let us reproduce the issue without writing all the boilerplate code.
Ok, I think I have condensed the code down to a working minimum.
I've attached a zip file to this post which has a Visual C++ 2010 project in it if that helps you.
However, if it doesn't then the relevant files are:
Quelle1.cpp main C++ code for initialisation
Shader/test.vert a trivial VS
Shader/test.frag the FS code in consideration
+ some header files (glext.h, wglext.h, resource.h)
When you get it running then press the F4 button to toggle the colour of the rendering.
It erroneously either switches or doesn't, depending on the break statement in the FS (some further info see there).
Let me know if you have problems running the code or if you don't observe the wrong behaviour I'm describing.
I've passed this report to the compiler team. Will get back to you as soon as I can.
I've been told this issue has recently been fixed. Please observe the upcoming driver releases for a patched version. Thanks.
>I've been told this issue has recently been fixed.
Sorry, I still have the same issue.
I've tried out several driver updates since your post was made.
My current driver version is 17.6.2
Radeon Settings Version - 2017.0612.1651.28496
Driver Packaging Version - 17.10.3211.1011-170612a-315162E-CrimsonReLive
Provider - Advanced Micro Devices, Inc.
2D Driver Version - 8.1.1.1599
Direct3D® Version - 9.14.10.01261
OpenGL® Version - 6.14.10.13476
OpenCL™ Version - 22.19.171.257
AMD Mantle Version - 9.1.10.0189
AMD Mantle API Version - 102400
AMD Audio Driver Version - 7.12.0.7724
Vulkan™ Driver Version - 1.5.0
Vulkan™ API Version - 1.0.39
Sorry. I've asked the person who handled your case to have another look at this.
Got an update this morning that the regression has been addressed internally. One of the coming driver releases should contain the patch. Thank you for your patience.