This new extension in its current form allows two new changes that relax this requirement to make re-use and organisation of shaders at runtime easier for developers, to paraphrase the spec it allows developers to “mix-and-match” stages to create more flexible shader pipelines.

Seperable Programs

The first change is that a SP doesn’t need to have both vertex & fragment shaders bound at link time for it to be considered valid, however this means that an SP that only has either a vertex shader or fragment shader bound (and not both) may not be consdered “complete” in a semantic sense; as-per the spec, using a SP that is missing a stage will produce results that are undefined for the missing stages.

Setting a SP to be “seperable” is done by setting it’s GL_PROGRAM_SEPARABLE_EXT parameter to GL_TRUE (just before linking):

glProgramParameteriEXT( shaderProgramId, GL_PROGRAM_SEPARABLE_EXT, GL_TRUE );

otherwise the SP object behaves as per the unextended spec, i.e. both the vertex and fragment stages must be specified before linking the SP.

SIDE NOTE: The glCreateShaderProgramvEXT API is provided to greatly reduce boilerplate and simplifies creation of a seperable shader, and should be your preferred way of creating seperable SP’s.

Program Pipeline Object

The second offering of this extension is the Program Pipeline Object (PPO). After linking a set of SP’s these are consolidated and named by a PPO to allow you to bind a permutation of SP’s using one named OpenGL object – the PPO. The PPO also allows uniforms to be set while bypassing the currently bound program object. The glProgramUniform* set  of functions take a PPO name as an argument, and the program to apply the uniform to.

GLSL level attribute binding

Supplemental improvements to the GLSL model included in this extension are the ability to set (and override application set) vertex attribute stream locations in GLSL source text. Without this extension, developers currently have to know the attribute identifier used in GLSL code to correctly bind it at runtime e.g.:

// GLSL code:
attribute vec4 myPostion;
attribute vec3 myNormal;
void main() { ... }

// Application Code:
const int POSITION_ATTRIB_INDEX = 0;
const int NORMAL_ATTRIB_INDEX = 1;
...
glBindAttribLocation( prog, POSITION_ATTRIB_INDEX, "myPosition" );
glBindAttribLocation( prog, NORMAL_ATTRIB_INDEX, "myNormal" );
...
glVertexAttribPointer( POSITION_ATTRIB_INDEX, ... )
glVertexAttribPointer( NORMAL_ATTRIB_INDEX, ... )
...

When the EXT_seperate_shader_objects extension is available, the location index can be specified in shader source text, and also takes precedence over any glBindAttribLocation calls in application code, the above code is simplified by not needing the glBindAttribLocation calls and few changes in the GLSL text e.g.:

// GLSL code:
#extension GL_EXT_separate_shader_objects : enable
layout(location = 0) attribute vec4 myPostion;
layout(location = 1) attribute vec3 myNormal;
void main() { ... }

// Application Code:
const int POSITION_ATTRIB_INDEX = 0;
const int NORMAL_ATTRIB_INDEX = 1;
...
glVertexAttribPointer( POSITION_ATTRIB_INDEX, ... )
glVertexAttribPointer( NORMAL_ATTRIB_INDEX, ... )
...

The main caveat to this is while is simplifies application code, developers will need to be consistent across several shader files for attribute location binding, though this isn’t hard and any conflicting layout(location) indexes will cause a GLSL-linker error.

Example Usage (C++)

const GLchar* VertexProgramCode =
{
  //tell the driver we need to enable particular GLSL extensions
  //note that the \n is important here
  "#extension GL_EXT_separate_shader_objects : enable\n" 

  //use the layout(location) syntax extension
  "layout(location = 0) attribute vec4 position;"
  "uniform mat4 mvp;"
  "uniform vec4 custom_color;"
  "varying lowp vec4 color;"

  "void main() {"
  "  color = custom_color;"
  "  gl_Position = mvp * position;"
  "}"
};

const GLchar* FragmentProgramCode =
{
  "varying lowp vec4 color;"
  "void main() {"
  "  gl_FragColor = color;"
  "}"
};

class Effect
{
protected:
  void log_status(GLuint prog)
  {
    int len(0);
    const bool is_ppo(glIsProgramPipelineEXT(prog) == GL_TRUE);
    //if this looks odd, it's just an ternary function pointer select
    (is_ppo ? glGetProgramPipelineivEXT : glGetProgramiv)(prog, GL_INFO_LOG_LENGTH, &len);
    if( len > 0 ) {
      GLchar log[len];//gcc extension: non-const array size
      (is_ppo ? glGetProgramPipelineInfoLogEXT : glGetProgramInfoLog)(prog, len, &len, log);
      std::cerr << log << "\n";
    }
  }

  GLuint m_vp;
  GLuint m_fp;
  GLuint m_ppo;

  //vertex program variable locations
  GLint m_mvp_location;
  GLint m_custom_color_location;

public:
  float m_mvp[16];
  float m_custom_color[4];

  Effect() : m_vp(0), m_fp(0), m_ppo(0)
  {
    //identity
    for(int i=0; i<16; ++i)
      m_mvp[i] = (i%5==0)?1.0f:0.0f;

    //default to red
    m_custom_color[0] = 1;
    m_custom_color[1] = 0;
    m_custom_color[2] = 0;
    m_custom_color[3] = 1;
  }

  ~Effect() {
    unload_all();
  } 

  bool load_shaders()
  {
    //in a well designed system you would pick these out of an e.g. vertex/fragment effect pool
    m_vp = glCreateShaderProgramvEXT(GL_VERTEX_SHADER, 1, &VertexProgramCode);
    log_status( m_vp );

    //bind the vertex program variables we need
    m_mvp_location = glGetUniformLocation( m_vp, "mvp");
    m_custom_color_location = glGetUniformLocation( m_vp, "custom_color");
    assert(m_mvp_location > -1);
    assert(m_custom_color_location > -1);

    m_fp = glCreateShaderProgramvEXT(GL_FRAGMENT_SHADER, 1, &FragmentProgramCode);
    log_status( m_fp );

    //generate and construct our PPO
    glGenProgramPipelinesEXT(1, &m_ppo);  

    //this is where you would "mix-and-match" using the bitmask
    //in the 2nd parameter
    glUseProgramStagesEXT(m_ppo, GL_VERTEX_SHADER_BIT_EXT, m_vp);
    glUseProgramStagesEXT(m_ppo, GL_FRAGMENT_SHADER_BIT_EXT, m_fp);

    glValidateProgramPipelineEXT(m_ppo);
    log_status( m_ppo );

    int status(0);
    glGetProgramPipelineivEXT(m_ppo, GL_VALIDATE_STATUS, &status);
    if( status == 0 )
      std::cerr << "unable to create program pipeline\n";
    return status != 0;
  }

  void unload_all()
  {
    glUseProgram(0);
    glBindProgramPipelineEXT(0);
    glDeleteProgramPipelinesEXT(1, &m_ppo);
    glDeleteProgram(m_vp);
    glDeleteProgram(m_fp);
  }

  void bind_pipeline()
  {
    assert(m_ppo);
    glBindProgramPipelineEXT(m_ppo);
    glProgramUniformMatrix4fvEXT(m_vp, m_mvp_location, 1, 0, &m_mvp[0]);
    glProgramUniform4fvEXT(m_vp, m_custom_color_location, 1, &m_custom_color[0]);
  }
};

I was looking for an easy, in place solution to do this and came up with this for OSX – other OSs YMMV (the sed implementation is a little temperamental on OSX). You can fire this in a single line in terminal and can easily extend the find command to suite your match criteria e.g. find -iname "*.cpp" -or -iname "*.h" -or -iname "*.inl"

for FILE in $(find . -iname "*.cpp"); do sed -i '' 's/.$//' $FILE; done;

struct Foo {
#ifdef MY_PREPROCESSOR_FLAG
int myFlags;
#endif
int myInteger;
int myOtherInteger;
};

I know this might seem obvious, but make sure that if you define MY_PREPROCESSOR_FLAG in one project, that it is also defined at compile time of the other project! What caught me out was that the static lib and the project which uses the static lib share the same physical header file, but don’t share project settings in the same nature. So now you can easily see what happens if you have MY_PREPROCESSOR_FLAG defined in one project and not the other – in one of the projects sizeof(Foo) is 12 bytes, and in the other sizeof(Foo) is 8 bytes (on a 32bit machine).

The interesting thing – that might catch you out (it got me), is that assignments and copies will probably still work without crashing if you’re only writing to member variables directly (i.e. no function calls or vtable to crash over). In my case, I was only writing to members between this and this+8 (8 being the smaller size struct, so writes never really went out of bounds). Where the caller was expecting to have provided a Foo object where myInteger was 2 and myOtherInteger was 3, having a look at the disassembly output for myStaticLibApiFunc gives you the face palm moment (it gave me mine, I always prefer to look at assembler output, its not the most productive but I find I never have to second guess what the code is meant to be doing vs. what is actually running).

Anyway, from the assembly listing you can easily see the constant offsets on the stack register are off by the size of the #def guarded members.

(in dependant project, where MY_PREPROCESSOR_FLAG is defined)

myStaticLibApiFunc( Foo(1, 2, 3) )

(the function in the static project where MY_PREPROCESSOR_FLAG isn’t defined)void myStaticLibApiFunc( Foo f )
{
Foo x = f;
print("%d", f.myInteger, f.myOtherInteger);
}
if the two compiled version of Foo matched and were 12 bytes, the generated assembly might be something like not the offsets in bold (this is just an quick hand coded approx, not compiler output so please forgive the assumptions!):void myStaticLibApiFunc( Foo f )
{
mov $esp,$ebp
//Assuming Foo x is located 24 bytes before esp,
//and f is the 12 bytes following x
//x.myFlags = f.myFlags
mov 0x0c($ebp), $edx
mov $edx, 0x18($ebp)
//x.myInteger = f.myInteger
mov 0x08($ebp), $edx
mov $edx, 0x14($ebp)
//x.myOtherInteger = f.myOtherInteger
mov 0x04($ebp), $edx
mov $edx, 0x10($ebp)
}

but what you’ve ended up with is this suspicously shorter version (missing the first assignment, and having the “wrong” offsets for myInteger and myOtherInteger
void myStaticLibApiFunc( Foo f )
{
mov $esp,$ebp
//Assuming Foo x is located 16 bytes before esp,
//and f is the 8 bytes following x
//x.??? = f.myFlags
//x.myInteger = f.myInteger
mov 0x08($ebp), $edx
mov $edx, 0x10($ebp)
//x.myOtherInteger = f.myOtherInteger
mov 0x04($ebp), $edx
mov $edx, 0x08($ebp)
}

Quick command line way of finding is using the atos tool. For our app CubeGame, you cd your way inside CubeGame.app (inside the app package, you have your actual binary executable called CubeGame) then fire off this command:

atos -o CubeGame -arch armv7 0x000421ec

0x000421ec is obviously the last code address in the stack trace that is inside your code. this is the output that was produced:

WaveSet::createWaveSet(int, int) (in CubeGame) (WaveSet.cpp:58) 

• Correct SDK root
• “Header Search Paths” (Project Settings)
• “User Header Search Paths” (Project Settings)
• “Always search user headers” (Project Settings)

But there is one more element that will throw a spanner-of-confusing-impending-doom into the works: Header Maps.

This nifty and undocumented feature is basically a dictionary of all the filenames in your project (just the filename, not a fully qualified path), supposedly to speed up building, but it definitely gets in the way (in a big way) sometimes.

To keep a long story really short, if your build looks like the header search paths are very confused for example #include <math.h> actually includes a file in your project named Math.h regardless of folder depth that resides somewhere in your project (you can check this using  ”Build” > “Preprocess” and check which files its actually #included’ed)

Project > Edit Project Settings > (Cog Button Bottom Left) > Add User-Defined Setting

Name the setting USE_HEADERMAP and set its value to NO (EDIT 24/11/11: this was incorrectly USE_HEADERMAPS – should not be plural, thanks Simon for pointing this out)

Now all header includes MUST be relative to the file they are included from OR be explicitly relative from any of your specified header search paths.

More reading provided below:

http://web.archiveorange.com/archive/v/JT06F65y3o5h2vjWtjBo

http://www.openradar.me/7840694

http://www.omnigroup.com/mailman/archive/macosx-dev/2005-March/056049.html

http://stackoverflow.com/questions/2596695/controlling-which-project-header-file-xcode-will-include

Excuse the keyword dump here, it was hard to find this out so I hope this will help others looking:
cannot find correct system headers, header path order, include path order, search path order, Xcode include file quotes, header maps, hmap, import directive, include confused, incorrect include search path

After hunting around I found this bug report which refers to the 2010.04 SDK which is the one I have installed. The dylib with the gdb extensions that ships with this SDK is broken, but it’s amazingly simple to fix because Qt Creator allows you to rebuild the dylib from the preference panel with one click (now thats a totally new height in open source software!).

1. sudo rm /usr/local/Qt4.6/qtc-debugging-helper/libgdbmacros.dylib
2. Start Qt Creator
3. Qt Creator -> Preferences -> Select the “Qt” tab -> Select “Qt in PATH” under “Auto-detect”
4. There should be a red cross next to the label “Debugging Helper.” On the right of that there’s a rebuild button – hit it and wait.
5. The red cross should turn into a green tick.
6. Clean & Build your project.

More Reading: Bug report with the official solution: QTCREATORBUG-1799

dscl /Local/Default -list /Users UniqueID

I’m sure altering the last “UniqueID” value (as it’s referred to as a ‘key’) will yeild more interesting info, this is left as an excercise to the reader

The fix was the most paintfully simple addition to the Postfix main.cf, highlighted bold. This fix seems to only apply to Ubuntu based environments and means that the smtpd daemon will actually pay attention to the contents of /etc/postfix/sasl/smtpd.conf

smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
smtpd_sasl_local_domain = $myhostname
smtpd_sasl_application_name = smtpd
broken_sasl_auth_clients = yes


more reading: http://ubuntuforums.org/showthread.php?t=297462

I thought about how I could get around this and have the Solution Explorer folders mirror the filesystem, first obvious option was write a shell script or macro to do it. So I fired up VS macro explorer and lo-and-behold theres a Sample macro which ships with VS called “AddDirAsSlnFolder”.

Looking very promising I checked out the source code, and sure enough it does exactly what I needed. The only thing I had to do to get it working exactly right was add “.svn” to the exclusions list (this is down the bottom of the source file and should be clearly visible next to all the other exclusions in the list)

Enjoy.

error C3163: '_vsnprintf': attributes inconsistent with previous declaration

the last post in this thread clarifies how this error arrises in common practice. To get it to compile I commented out these lines:

• FUtils\Platforms.h:145
• LibXML\config.h:92
• LibXML\include\win32config.h:90
• DLLEntry:40 (this one was just a missing symbol or something deprecated in new the PSDK shipping with VC9, the case statement is empty so commenting it out should have no effect)

I should clearly note that I haven’t tested it (running etc.), I simply got it to build to help save our tools guy a bit of time. I should also note that the Unit Tests (FColladaTest) project builds but returns about 60 linker errors. I just thought I’d post here to save someone a bit of hassle if they should run into this error.

FCollada version was 3.05B Win32

-Danu