POT/NPOT, float tex, 2D/RECT targets and mip-maps

Hello,

Just to give some introduction before I jump into my questions:

It’s been a while since I used OpenGL for serious tasks. The past couple of years I’ve used mostly DirectX.
Yet recently I decided to develop the demo of a research project in OpenGL to keep in touch with the updates and have a grasp on GLSL. I’m satisfied with the improvements.

Now I’m trying to stop being lazy and make my OpenGl programs a bit more reliable and more “professional-looking”.
With that in mind what I’m actually doing is some rendering paths in my applications and libraries so that they’ll actually run in different hardware profiles and situations.

Well, my questions will concern mostly on POT/NPOT, float textures, 2D/RECTANGLE targets and mip-mapping.
I guess I shall start with a single question and progress on them together with the feedback you might provide me.

I know I can find NPOT support by querying ARB_texture_non_power_of_two or float texture support with ARB_texture_float.
What I want to know is if the hardware support NPOT float textures with filtering, altogether.
Can I safely infer all this solely by inspecting these individual extension strings? Will this guarantee that all these three referred features are valid when used together? If not, how can I determine this?

I’m reading through the OpenGL 3.x specification as well as some of the extensions’ documentation files. However, I have to say that it is quite difficult to follow and link all of them together… I know that pretty much every extension has exceptions that may not be well documented or updated as new extensions are proposed.

That being said, I could use some of your expertise.
(sorry if this post is supposed to be in the beginner’s forum; if this is the case let me know and I’ll move my question to there).
Thanks in advance,
Marcos Slomp

Generally, the extension specification describes all interactions with other extensions.
So, I assume, you can just inspect the support for the individual extensions.

Thanks for your reply, Dmitri.

Yes, I was hoping that I could trust the extensions’ documentation.

However, some old hardware (say, a GeForce FX5200) do support float textures and POT textures, but float texture filtering is not possible.

How could I detect this in OpenGL code?
Not sure if this can be done by simply inspecting the capabilities string. My guess would be to set the texture min/mag filtering to GL_LINEAR and check glGetError() afterwards.

Any thoughts?

You are correct, FP filtering is a HW capability that might not be mentioned in the specification.

I guess the best way to know for sure is to perform a small test on 2x2 fp texture either on program startup or on the pre-configuration stage.

Once again thank you for the reply.

As I feared, it seems that the strings alone are not enough.
Well, fortunately I already made a project of a pre-run stage to check hardware capabilities. It’s gonna be a pain in the a**… I was just wondering if there was a simpler and reliable way…

Moving on, I also had a bad time with glGenerateMipMap().
When using float textures it works fine on GeForce 9Series and GTX.
However, when I call it under a 8600M GT (notebook), it clamps the float data ([0,1]) before generating the consecutive levels…
I did not check on GeForce 8 (desktop) or 7 or lower yet, though…

Maybe it is a driver bug?
Usually mobile cards have distinct drivers than desktop cards which might be the case…

Any thoughts on this too?
Thanks in advance.

I think we’ve all complained bitterly at one time or another about the inability to query certain hardware functionality. But in the end I suspect that the spec is by design intentionally vague in certain areas to facilitate widespread adoption; the reason likely being GL has to run on a great variety of platforms for an ever greater variety of applications (unlike DX, which has enjoyed being the domain of games on Windows with relative exclusivity).


Well, fortunately I already made a project of a pre-run stage to check hardware capabilities. It's gonna be a pain in the a**...

It’s not this difficult to test several HW capabilities.
I consider thus is a good idea though didn’t try it myself.


When using float textures it works fine on GeForce 9Series and GTX.
However, when I call it under a 8600M GT (notebook), it clamps the float data ([0,1]) before generating the consecutive levels...
I did not check on GeForce 8 (desktop) or 7 or lower yet, though...

Maybe it is a driver bug?
Usually mobile cards have distinct drivers than desktop cards which might be the case...

If I were you, I’d try to play with glClampColor function.
It looks like a bug, but it may be easier to work around it than to require NV to solve it.

And, of course, you should have the latest driver for your laptop. My experience shows that Nv/ATI fix bugs in every driver release, so updating the driver is always a need.

But in the end I suspect that the spec is by design intentionally vague in certain areas to facilitate widespread adoption

Nothing stops the driver from reporting it’s capabilities.
Making the spec more explicit around, for example, FP filtering would make our life easier.
And I really don’t see how it’s going to hurt portability of GL :stuck_out_tongue:

Thank you people. It is being really worthy getting this feedback from you.

I agree with you.
It is hard to maintain a cross-platform API like OpenGL…
DirectX also has lots of problems… DX10 kind of works pretty fine, but it is bound to Vista. DX8 and DX9 is pretty much like OpenGL: the device caps query is messy and even harder to maintain than OpenGL sometimes.

I’m not complaining at all, just looking for your expertise to avoid doing unnecessary things and keep my code as clean, legible and maintainable as possible.
As I said, it is being a while since I do not do serious stuff in OpenGL and many things seem to have improved in the past couple of years.

I always keep my graphics driver up to date, so it seems more like an unnoticed bug… I’ll play around with glClampColor() =)
If that does not work I’ll report to NVIDIA.

I think all my questions were answered thus far.
I feel somehow relived in knowing that I was actually in the right track.
Your kind feedback was of great help!
Long live to OpenGL!
If I find something worth noting I’ll contact again through this forum.

DmitryM, if the xy spec states that fp filtering must be implemented then that limits what hardware can claim conformance to that particular version. Otherwise, offering a query function for a feature is a bit like saying “I don’t know what the GL version is, but go ahead and tell me if the feature is supported anyway.” And with extensions? Well, you be the judge.

Anyway the spec is riddled with examples of ambiguity of the like. Look at multisampling; here again its implementation and to an extent its interpretation are left to the implementer, within the bounds of loosely worded constraints. On that note, there was a query in this forum not too long ago concerning the stencil routed k-buffer, whose implementation I believe is contingent on the spec’d behavior of stencil and depth operations in the absence of multisampling. Don’t think this’ll fly in GL, but I haven’t really put the nose to the grindstone on it.

Well, you have a point, Brolingstanz.

Anyway, at least glGetError() is quite reliable in reporting errors. The driver usually does a good job on it. I think it only lacks in the number of reported errors which can be quite arcane depending the API call that triggers it.

Also, it would be nice to have an error callback extension so that the we could provide an user-defined error handling routine. I think I’ll use some of my spare time to develop a kind of auto-trigger using template meta programming or C’s preprocessor. It would be possible then to point the file/line where the error occurred, as well as the API call and even the given parameters’ names and values.

I was reading some entries in the OpenGL wiki and I found this one:
Floating point and mipmapping and filtering
http://www.opengl.org/wiki/Floating_point_and_mipmapping_and_filtering
It gives some ideas but they’re not so elegant.
Worth checking, though.