synchronization issue with ARB_fragment_program?

First off, I’m experiencing similar problems on Radeon9800SE on WinXP as well as GF6800 and Radeon9800Pro on MacOSX, and only when ARB_fragment_program is enabled, so it’s likely something that I’m universally doing wrong. (FWIW, the app uses GLUT in a window.) The fragment program implements 2-texture bumpmapping: RGB decal map and RGBA normal/gloss map (RGB for normal, alpha for gloss). I’m rendering geometry in 8 tiled sections due to texture-size limitations. The basic rendering loop boils down to:

  struct Vert { float x, y, z, s0, t0, s1, t1; };
  glEnable(GL_COLOR_MATERIAL);
  ...
  void display() {
    glColor3d(1, 1, 1); // set white
    ... // render background quad
    glColor3d(1, 1, 0);  // set yellow
    for (int i = 0; i < 8; ++i) {
      glActiveTextureARB(GL_TEXTURE0_ARB);
      glBindTexture(GL_TEXTURE_2D, decal[i]);
      glActiveTextureARB(GL_TEXTURE1_ARB);
      glBindTexture(GL_TEXTURE_2D, normalGloss);
      glClientActiveTextureARB(GL_TEXTURE0_ARB);
      glTexCoordPointer(2, GL_FLOAT, sizeof(Vert), &verts[i].s0);
      glClientActiveTextureARB(GL_TEXTURE1_ARB);
      glTexCoordPointer(2, GL_FLOAT, sizeof(Vert), &verts[i].s1);
      glVertexPointer(3, GL_FLOAT, sizeof(Vert), &verts[i].x);
      glDrawArrays(GL_TRIANGLES, 0, nVerts);
    }
    glutSwapBuffers();
  }

The fragment program modulates state.material.diffuse (intended in this case to be the yellow from the second glColor call) with the diffuse result of bump-mapping, after which the specular bump component is added. Everything renders fine, except that the first tile flickers between yellow-tinted and white-tinted (i.e. non-tinted), while the remaining 7 tiles correctly get the yellow tint always, without flickering or any other noticeable problems. In some cases, adding glFlush or glFinish commands between the glColor(yellow) and the 8-tile loop eliminates the flickering of the first tile, although some triangles in that tile still get the wrong color modulated its fragments.

This leads me to believe that there’s a timing issue at play. But how is it possible that a command as straightforward as glColor isn’t always being reflected by the fragment program’s state.material.diffuse property? Is it actually taking time for state.material.diffuse to track glColor?

Furthermore, on some configurations, the flickering situation is even worse, and has nothing to do with color or material; the texture itself flickers between the correct image and what appears to be garbage, but the flickering subsides as flushes are added or enough geometry is submitted.

The decal texture is loaded directly as GL_COMPRESSED_RGB_S3TC_DXT1_EXT (prepared by TheCompressonator, with mipmaps), while the normal/gloss map is loaded as GL_RGBA8_EXT.

Any ideas?

Driver bugs. This just shouldn’t happen.

Possible workarounds (wild guesses):
1)Try glColor3f instead of glColor3d
2)disable color material, and, in your fragment program, replace state.material.diffuse with fragment.color

OK, after entirely too much debugging, I’ve discovered that the artifacts disappear when everything is rendered via fragment programs. Apparently some drivers don’t like mixing fragment programs with the fixed pipeline. Very annoying, since I also need to render lines, and fragment programs don’t even try to render GL_LINES, AFAIK.

Any suggestions/links for manual line rendering? Not silhouette/toon rendering, but something GL_LINES-like.

and fragment programs don’t even try to render GL_LINES, AFAIK.

Not true, vertex and fragment programs do not know about the type of primitive.

You’re right, GL_LINES should work with fragment programs. (I was using the wrong fragment program for lines at first.) But on my system, the lines lose their smoothness/blending when rendered through a fragment program, whereas they rendered correctly with anti-aliasing with the fixed-function fragment pipeline.

Has anyone else encountered problems with smooth lines when rendered with fragment programs?

I’ve discovered that the artifacts disappear when everything is rendered via fragment programs
perhaps youre seeing the flicking cause of position invariance
are u using gl_position = ftransform()

Nope, just using the fixed-function vertex pipeline. The fragment program that’s rendering the lines is as follows:

!!ARBfp1.0
TEMP tex;
TEX tex, fragment.texcoord[0], texture[0], 1D;
MOV result.color.xyz, fragment.color;
MUL result.color.w, fragment.color.w, tex.w;
END

(The 1D texture is grayscale and provides the line with faded ends, making them appear tapered: white in the middle fading to black near the ends.)

Both GL_BLEND and GL_LINE_SMOOTH are enabled, but the lines are clearly not anti-aliased when using the above fragment program.

Originally posted by maxuser:
[b]You’re right, GL_LINES should work with fragment programs. (I was using the wrong fragment program for lines at first.) But on my system, the lines lose their smoothness/blending when rendered through a fragment program, whereas they rendered correctly with anti-aliasing with the fixed-function fragment pipeline.

Has anyone else encountered problems with smooth lines when rendered with fragment programs?[/b]
I have. Let me guess: you’re using an ATI card.

Catalyst 3.8 and earlier had a nasty bug where mixing smooth lines, shaders (ARB_fp and ATI_fs) and untextured polygons just didn’t work together on R300+ hardware. Nothing would get rendered. I reported that, and the fix they implemented, and kept around to this day, apparently was to disable line smoothing altogether while any of these two fragment programming extensions is enabled :eek:

Just so you know that it could have been much worse.

This all works fine on Radeon 8500-9250 (via ATI_fragment_shader) and GeforceFX hardware btw.