I have managed to get the
geometry and tessellation shader stages working. I also fixed the isosurface sample and basic triangle tessellation sample which show off each of the respective stages. I am not sure I will be able to get the remaining two geometry shader samples working because they do not appear to be functional in any rendering system. I will give them a shot near the end of my GSoC, but I cannot promise they will work.
I was sick most of last week and a few days, which slowed my progress to a crawl, though I did manage to fix
visual tests so that they are running again in GL and GL3+. (I decided to fix the tests earlier than scheduled because I need a way to quickly test RS changes so I do not pile on bugs.) I also worked on fixing a few of the samples, such as the Grass sample, which were something my disease addled brain could handle. I spent much of my remaining time trying to better understand the rather complex flow of shader processing in Ogre. Talk about levels of indirection! Calling parent class methods which call child class methods which call parent class methods which call methods of another class which calls parent class methods which call...
Confusing is an understatement. This is OOP gone wild. I am grateful that multiple inheritance appears to be rarely used.
I have about half of my work on
compute shaders completed, though I decided to set it aside and focus on something simpler, returning once I get a better understanding of the Ogre rendering system in general. In the mean time I have been working on
atomic counters, transform feedback, texture multisampling, and image load/store. Any time I hit a wall while coding, I would move on to another project and hope it would give some hints for solving the one I temporarily abandoned. The result of this strategy has been so-so. I do indeed occasionally find commonalities among topics that help me understand why each is not working, but I realize eventually I have to face each problem to completion. Thus I am now committed to completing the listed features in order, one after another, hell or high water, until I am closer be being back on schedule.
Atomic counters are 90% finished, though
I need some advisement to proceed. Ogre does an interesting dance to handle GL uniforms. First it manually parses the shader to extract a list of uniforms via GLSLProgram::buildConstantDefinitions and, particularly, GLSLProgramManagerCommon::extractConstantDefs. Later, after shader program compilation and just prior to rendering, uniforms are directly extracted from the program via OpenGL calls in GLSLProgramManagerCommon::extractUniforms and compared to the prior parsed list of uniforms. If they match, Ogre will add the uniform reference to a list so that its values can subsequently be set by Ogre via GLSLProgramPipeline::updateUniforms.
(please correct me if this description is somehow wrong)
During the first part, the manual parsing of the shader, the GLSL variable types are related to Ogre 'constant' variable types which begin with GCT (GpuConstantType). Nearly all variable types introduced in GL3+ have no direct correspondent in GCT, so they fail to be parsed. For instance, the GLSL type uint (from GL3) has no corresponding GCT type, though GCT_INT is close and has the same size. In cases like this, should I simply use the closest existing GCT type, or should I introduce new types? Currently I am reusing existing types, though GCT_INT is a little more of a stretch for atomic counters since they cannot be set using glProgramUniform and hence a special case has to be mode during binding in GLSLProgramPipeline::updateUniforms. Am I taking the right direction?
Perhaps I could answer this myself if I knew what the GCT types were meant for, besides helping with binding. To be honest I am not sure why they are used even there. Why not just directly use OpenGL types? It seems cleaner and more straightforward.
Once I get my build working again and complete at least one of the half-finished features I will push my changes.
EDIT:
Just noticed that there is a TODO comment someone left in the spot causing me uncertainly which says "Move these to a new type??" So I am not alone!
I think I understand. sampler2D stores a pointer to an array, and the pointer is an int. Is this the idea?