Following GLSL conventions is a really strict policy of GLM. GLM has been designed according to the idea that everyone writes their own math library with their own conventions. The idea is that brilliant developers (the OpenGL ARB) worked together and agreed to make GLSL. Following GLSL conventions is a way to find consensus. Moreover, basically when a developer knows GLSL, he knows GLM.
No, GLM is a C++ implementation of a subset of GLSL.
No, this is not what GLM intends to do!
GTX Extensions (Experimental) are experimental. In GLM this means that these extensions might change from version to version without restriction. In practice, it doesn't really change except time to time. GTC extensions are stabled, tested and perfectly reliable in time. Many GTX extensions extend GTC extensions and provide a way to explore features and implementations before becoming stable by a promotion as GTC extensions. This is similar to how OpenGL extensions can be EXT or ARB extensions before becoming core functionality.
In short, if you use a GTX extension, the API is much more likely to change from version to version than if you don't. But you should not feel too uncomfortable about using them.
A good place is the OpenGL Toolkits forum on OpenGL.org: http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=postlist&Board=10&page=1
The Doxygen generated documentation includes a complete list of all extensions available. Explore this documentation to get a complete view of all GLM capabilities! http://glm.g-truc.net/html/index.html
This is unwise. Chances are that if 'using namespace glm;' is called, name collisions will happen. GLSL names for functions are fairly generic, so it is entirely likely that there is another function called, for example, sqrt .
For frequent use of particular types, they can be brough into the global namespace with a 'using' declaration like this:
/code using glm::mat4;
mat4 someVariable(3.0f); /endcode
GLM is mainly designed to be convenient; that's why it is written against GLSL specification.
The 80-20 rule suggests that 80% of a program's performance comes from 20% of its code. Therefore, one should first identify which 20% of the code is impacting the performance.
In general, if one identifies certain math code to be a performance bottleneck, the only way to solve this is to write specialized code for those particular math needs. So no canned library solution would be suitable.
That being said, GLM can provides some descent performances alternatives based on approximations or SIMD instructions.