GL_FRAMEBUFFER_INCOMPLETE_DUPLICATE_ATTACHMENT_EXT errors - opengl

I'm using FBOs in my OpenGL code and I'm seeing compilation errors on GL\_FRAMEBUFFER\_INCOMPLETE\_DUPLICATE\_ATTACHMENT\_EXT. What's the cause of this and how do I fix it?

The cause of this error is an older version of NVIDIA's glext.h, which still has this definition. Whereas the most recent versions of GLEW don't. This leads to compilation errors in code that you had written previously or got from the web.
The GL_FRAMEBUFFER_INCOMPLETE_DUPLICATE_ATTACHMENT_EXT definition for FBO used to be present in the specification (and hence in header files). But, it was later removed. The reason for this can be found in the FBO extension specification (look for Issue 87):
(87) What happens if a single image is attached more than once to a
framebuffer object?
RESOLVED: The value written to the pixel is undefined.
There used to be a rule in section 4.4.4.2 that resulted in
FRAMEBUFFER_INCOMPLETE_DUPLICATE_ATTACHMENT_EXT if a single
image was attached more than once to a framebuffer object.
FRAMEBUFFER_INCOMPLETE_DUPLICATE_ATTACHMENT_EXT 0x8CD8
* A single image is not attached more than once to the
framebuffer object.
{ FRAMEBUFFER_INCOMPLETE_DUPLICATE_ATTACHMENT_EXT }
This rule was removed in version #117 of the
EXT_framebuffer_object specification after discussion at the
September 2005 ARB meeting. The rule essentially required an
O(n*lg(n)) search. Some implementations would not need to do that
search if the completeness rules did not require it. Instead,
language was added to section 4.10 which says the values
written to the framebuffer are undefined when this rule is
violated.
To fix this error, remove all usage of GL_FRAMEBUFFER_INCOMPLETE_DUPLICATE_ATTACHMENT_EXT from your code.
If this isn't possible in your setup, then add a dummy definition to your glext.h or glew.h file like this:
#define GL_FRAMEBUFFER_INCOMPLETE_DUPLICATE_ATTACHMENT_EXT 0x8CD8

Related

C++ mark a function as experimental/not fully implemented

I have a function I will need to leave partially implemented for a variety of reasons and I want to prevent future users (read as me in the future when I have forgotten that I did this) to know the function is incomplete, buggy and untested.
Option n1 is merely adding a comment // Warning this thing is partially implemented and will break randomly
This however won't create compile time warnings so, I am not a fan.
Option n2 is to use [[deprecated("reason")]] which has the advantage of raising compile warnings but its misleading, the function wasn't deprecated it's actually the opposite of deprecation, it's a WIP and will perhaps one day be fully implemented.
Are there alternatives?
The [[deprecated]] attribute is exactly what this is for (emphasis mine) :
https://en.cppreference.com/w/cpp/language/attributes
[deprecated]
[deprecated("reason")]
indicates that the use of the name or entity declared with this attribute is allowed, but discouraged for some reason
You can still use the function, you just get a warning message that you shouldn't rely on its use.
Caveat: MSVC breaks the standard and emits a compiler error (due to SDL flag being turned on by default) instead of a warning.
The only thing in standard C++ for this is the [[deprecated("message")]] attribute.
GNU has a non-standard Function Attribute for warning messages:
warning ("message")
If this attribute is used on a function declaration and a call to such a function is not eliminated through dead code elimination or other optimizations, a warning which will include message will be diagnosed. This is useful for compile time checking, especially together with __builtin_constant_p and inline functions. While it is possible to define the function with a message in .gnu.warning* section, when using this attribute the problem will be diagnosed earlier and with exact location of the call even in presence of inline functions or when not emitting debugging information.

create_directory() vs. create_directories()

Currently I am trying to work with the std::filesystem. I'm working on Windows 7 64-bit using MinGW-W64 GCC 7.1.0. Since this compiler does not support the std::filesystem, I have to include the experimental version and link with -lstdc++fs.
#include <experimental/filesystem>
namespace fs = std::experimental::filesystem;
This worked fine up to the point where I wanted to create nested directories. If I create the directories one at a time using create_directory(), everything works perfect. Now if I use create_directories() instead, it throws a filesystem_error if one of the directories already exists.
fs::path levelA{"."};
fs::path levelB{"folder"};
fs::path levelAB = levelA / levelB; // "./folder"
bool create_separately; // set this bool as needed
if (create_separately) {
/* This works perfectly */
fs::create_directory(levelA);
fs::create_directory(levelAB);
}
else {
/* This throws because "." already exists */
fs::create_directories(levelAB);
}
Comparing the documentation of the experimental version to the standard version, an additional sentence was added for the standard version:
Executes (1) for every element of p that does not already exist. If p already exists, the function does nothing (this condition is not treated as an error).
Why was this treated as an error in the first place? Is this considered a bug?
Additionaly, is there an easy way to update GCC on Windows? I read something about GCC 8.1.0 being released and some new MinGW version supporting it, but I can't seem to find any downloads.
Maybe you meant this, but note that only the second sentence you quoted is changed relative to the TS version—and has changed again since this question was asked. It refers to the case where p already exists and might not be a directory; the function returns false to indicate that it did nothing, but at the time of asking it didn’t report any error, regardless of the nature of p. The logic was that most operating systems do not distinguish this situation, so it was left to the application developer to ask, if they care.
It was added as a result of an LWG issue; the meaning of the previous wording was unclear at best, with no explanation of what happened if the function failed to satisfy its stated postcondition. There is no general notion of “postcondition failure is an error”, but rather that “postcondition failure in the absence of a reported error is logically impossible”.
Since the initial version of this answer, a paper was accepted that changed it to be an error if and only if the conflicting object is not a directory, requiring a subsequent check on many platforms. This is unusual for C++, but the result was thought to be more intuitive and the operation is relatively expensive anyway.
Regardless, the reason your implementation fails on . would seem to be that it’s buggy. (I don’t have any special hints about how to most easily obtain a newer version.)

GLSL auto optimization

I have three question realted with GLSL auto optimaztion(?) process.
Unused variables -> Is glsl removes all variables which not affect on final fragment shader pixel (out variable).
Unused function -> Is glsl removes all unsed defined functions before void main...?
And what about ins and outs variables. An example: I have 100 shaders which send a texture coordinates from vertex shader to fragment shader. In fragment shader these coordiantes no affect on a final color. Will glsl remove this variable?
That is not specified clearly. The OpenGL specification says:
See OpenGL 4.6 Core Profile Specification - 7.6 Uniform Variables - p. 130:
7.6 Uniform Variables
Shaders can declare named uniform variables, as described in the OpenGL Shading Language Specification. A uniform is considered an active uniform if the compiler and linker determine that the uniform will actually be accessed when the executable code is executed. In cases where the compiler and linker cannot make a conclusive determination, the uniform will be considered active.
See OpenGL 4.6 Core Profile Specification - 7.3.1 Program Interfaces - p. 101:
7.3.1 Program Interfaces
When a program object is made part of the current rendering state, its executable code may communicate with other GL pipeline stages or application code through a variety of interfaces. When a program is linked, the GL builds a list of active resources for each interface. Examples of active resources include variables, interface blocks, and subroutines used by shader code. Resources referenced in shader code are considered active unless the compiler and linker can conclusively determine that they have no observable effect on the results produced by the executable code of the program. For example, variables might be considered inactive if they are declared but not used in executable code, used only in a clause of an if statement that would never be executed, used only in functions that are never called, or used only in computations of temporary variables having no effect on any shader output. In cases where the compiler or linker cannot make a conclusive determination, any resource referenced by shader code will be considered active. The set of active resources for any interface is implementation-dependent because it depends on various analysis and optimizations performed by the compiler and linker.
If a program is linked successfully, the GL will generate lists of active resources based on the executable code produced by the link.

OpenGL: can I mix glBindBuffer with glBindBufferARB?

Is glBindBuffer equivelent to glBindBufferARB ?
Are the enums (like GL_ARRAY_BUFFER and GL_ARRAY_BUFFER_ARB) equivilent? Can I use non-_ARB enum in glBindBufferARB?
Can I mix + match glBindBuffer() calls with glBindBufferARB()?
ALSO: if a card supports the _ARB extension, does it always support the core GL function - even if its OpenGL version isn't up to date??
In general, it is not legal to do that kind of thing, because core functionality and extensions are not exchangeable, even if they have the same name (one notable example is primitive restart).
However, in this particular case, they happen to be exactly the same with the exact same constants, so... although it's not legal, it is "ok" to use them interchangeably (i.e. nobody will notice if you don't tell them).
You cannot in general assume that if an ARB extension is present that the core funciton will be present as well. There exist many ARB extensions that are there solely to allow OpenGL implementations which cannot implement a full version for some reason to nevertheless provide at least some functionality that the hardware can provide.

Peculiar behavior in OpenGL concerning Vertex Shaders and input vertices on core profile 330

using '#version 330 core' on NVIDIA,
By using glBindAttribLocation(program, 0, "in_Vertex"); the input vertex works with an "in vec4 in_Vertex;". However, I noticed without the OGL function call in the client app, it still works. It appears to be 'the default first input variable'. Why? Should it be omitted or be explicitly connected to it via glBindAttribLocation? [What's the ideal according to the standard?] Also "in vec4 gl_Vertex;" works while the spec calls it deprecated and the compiler of shaders does not give any warning. Why? I would have expected for it to at least warn. I guess the last one may be a bug in the compiler (GLSL compiler) but the first issue is especially puzzling.
if you don't bind attributes to a location, the GL will do it for you. Which locations it uses is unspecified but you happened to have the same value.
You can ask the GL which location it's chosen with glGetAttribLocation
Even though it's not specified, I've seen implementations choose to bind locations in order of the shader. First is 0, second is 1, ...
The standard leaves those 2 options open because there are valid use cases for each.
As for deprecation, nvidia clearly stated that they thing deprecation was the wrong decision. In the end somebody has to write the code to emit the warning... So it's not that surprising they would not warn, even if they ought to.