I think I've found something to scrap my head on. Well, I'm sure of this since I've spent a whole day debugging this c|24p. Here's what I did understand in the last 6 hours... or maybe I haven't. Your comment would be welcome as a good brainstorming. There are two textures. There are also other textures as well, but those two are the hateful duo. The first is a fully-fledged RGBA FLOAT32 texture which is 8x8, the other is a RGB16F. I'm rather sure those two textures are correct by themselves. Yes, I use them as look-up-tables for constants in fragment shader. It happens, that using the default settings, the RGBA32F texture, no matter how hard I push it, looks up as black. The other is fine. If in the program, I swap the binding to texture unit, I see the contents of the RGBA32F (which really cannot be rendered correctly since it's not color but I'm sure it's there). I felt I missed the uniform setting, so I redid all the code path to use specific texture units instead of "guessed" ones. By default, those two textures would be bound to TEXTURE15 (RGBA32F) and TEXTURE14 (RGB16F) (the shading system do have some kind of dynamic compiling, but I've really checked them with the debugger). Sidestepping it, I set those two to TEXTURE7 and TEXTURE6, which are somewhat more conventional but without wonder, the issue remains. Thinking at some hardware limitation or driver bug, I've tried changing the format to RGBA8. Nope. I'm quite sure the GL state is correct... but it obviously cannot be since it would otherwise render correctly. The Enable(TEXTURE_2D) follows the ActiveTexture(unit) and BindTexture(TEXTURE_2D, texture) is after Enable for both. The RGB16F is the last texture created and bound (unless I swap the two things). What do you suggest?

When it comes to RGBA_32F it has to be unfiltered.
Other than that im not sure.

Both min filter and mag filter are set to NEAREST and no mipmaps are built (nor they are requested as far as I know - those two are LUTs).

Strange thing: by default, RGBA32F goes to TEXTURE15 (or TEXTURE7 in debug path) while RGB16F goes to TEXTURE14 (TEXTURE6 for debug).
In I swap the two so RGBA32F goes to EXTURE14 (TEXTURE6) the texture is here and the other becomes black.

I was really thinking about some issues with uniforms so I did some hacks to allow the binding to also re-init uniform settings. Nothing changed: I've also had the opportunity to check everything was correctly initialized.

I didn't mention my glGetError value: NO_ERROR is reported.
The whole program shall eat up around 36MB. I hardly believe I'm hitting some issues with memory management, yet I'll still try something today.

Edit: I'll post following hints here, in the hope they'll be useful. Debugging this is really no fun, so I hope this will shorten the wastage for other people.

Since it didn't work, I tried some permutations which should produce the same result.
What actually happens is:

int prog = 0;GetIntegerv(CURRENT_PROGRAM, &prog);dbg_posRadiUni = GetUniformLocation(prog, "lpr");dbg_colorUni = GetUniformLocation(prog, "lc");Uniform1i(dbg_posRadiUni, 7);Uniform1i(dbg_colorUni, 6);// The above should not really be done on a performance path!// It is here for debugging purposes only! IT IS NOT GOOD HABIT.ActiveTexture(TEXTURE7);         // This will be called "SetTexture(unit, obj)"Enable(TEXTURE_2D);              // in following discussionsBindTexture(TEXTURE_2D, cLUT);   // cLUT is RGB16FActiveTexture(TEXTURE6);Enable(TEXTURE_2D);BindTexture(TEXTURE_2D, prLUT);  // RGB32F, this would be SetTexture(6, prLut);

What really happens is

cLUT  --> TEX7 --> lprprLUT --> TEX6 --> lc

The lc sampler is correctly used by the fragment program and shows the expected results going thuru TEX6. The lpr sampler is zeroed away for debugging purposes so it really does not count. (1)

Changing this to:

...SetTexture(7, prLUT);SetTexture(6, cLUT);

This gives:

prLut --> TEX7 --> lprcLut  --> TEX6 --> lc

Again, the expected results are shown. Information from cLut is correctly taken. (2)

Checking something which should be equivalent to (1):

...Uniform1i(dbg_posRadiUni, 6);Uniform1i(dbg_colorUni, 7);// The above should not really be done on a performance path!// It is here for debugging purposes only! IT IS NOT GOOD HABIT.ActiveTexture(TEXTURE7);         Enable(TEXTURE_2D);              BindTexture(TEXTURE_2D, cLUT);   // cLUT is RGB16FActiveTexture(TEXTURE6);Enable(TEXTURE_2D);BindTexture(TEXTURE_2D, prLUT);  // RGB32F

Does not render as expected. Reason: non-masked data passes thuru TEX7.

Double check (shall be as (2)):

...Uniform1i(dbg_posRadiUni, 6);Uniform1i(dbg_colorUni, 7);// The above should not really be done on a performance path!// It is here for debugging purposes only! IT IS NOT GOOD HABIT.ActiveTexture(TEXTURE7);         Enable(TEXTURE_2D);              BindTexture(TEXTURE_2D, prLUT);   // cLUT is RGB16FActiveTexture(TEXTURE6);Enable(TEXTURE_2D);BindTexture(TEXTURE_2D, cLUT);  // RGB32F

Does not render as expected.

Conclusion: TEX7 is broken.
More in general, all TEXn (in contrast to TEXn-1) are broken.
I'm now going to understand why the GL doesn't like this poor thing which is TEXn.

UPDATE: fixed.
I was planning to write here the details but it turned out to pe so much application-specific I hardly believe there's any usefulness.

So, at the end of the issue, the only thing which remains is:
--> Float textures really do not take any special care to get working. They obviously eat up bandwidth and memory. Surprisingly, on my system they take a rather high amount of fragment power, which I believe it's because of filtering. I am confindent this will go away for more recent vidcards.

Nothing else.

[Edited by - Krohm on June 26, 2006 9:21:39 AM]