To upload, the only way seems to be
glTexImage2D(target, 0, GL_RGBAF16_ARB, w, h, 0, GL_RGBA, GL_HALF_FLOAT_NV, pixels);
Im not sure why GL_HALF_FLOAT_NV hasnt been inserted into ARB_texture_float.
I guess the alternative is GL_FLOAT but I`m pretty sure that means 32 bit float.
It would also be nice to have some GLU functions to convert from float->half and half->float.
@ V-man: Try GL_HALF_FLOAT_ARB
@ sqrt[-1]: do you know the OpenEXR library? It provides float <-> half conversions
I just found out about ARB_half_float_pixel which has GL_HALF_FLOAT_ARB. I don’t see why they have designed it like this.
ARB_texture_float should just offer GL_HALF_FLOAT_ARB
or better yet,
ARB_texture_float (for 32 bit, if GPU can do it)
and
ARB_texture_halffloat (if GPU can do it)
and perhaps someday they can make
ARB_texture_double
PS: GLU should be updated IMO.
gluBuild*Mipmaps should support half/float.
No need. Mipmap generation is a requirement since a long time ago so the GL drivers can generate mipmaps.
The only reason i could think why they didn’t include GL_HALF_FLOAT_ARB in ARB_texture_float is, Nvidia was supporting half filtering from the begining and ATI wasn’t (still?), without half filtering maybe GL_HALF_FLOAT_ARB pointless?
Nvidia and OpenEXR both use same library.
But why would you need a conversion if you can’t upload results to gpu? And if you can upload, you can convert your data to any format using shader, you wouldn’t need any other extension/library/GLU function.
That doesn’t do me any good when I have a 20k x 20k float image to upload.
gluScaleImage / gluBuild*Mipmaps should support half/float. So we can prepare data for GL on the CPU.
gluScaleImage / gluBuild*Mipmaps should support half/float. So we can prepare data for GL on the CPU.
Not that I agree or disagree with the upgrade to GLU, but what does that have to do with GL being on the CPU? The two things seem to be rather orthogonal.
I think you mis-read what he was saying - It is not
“So we can prepare data for (a) GL (implementation running) on the CPU.”
But
“So we can prepare data (by pre processing it on the CPU) for (upload to) GL .”
The sentence can be read two ways so it is confusing.
Nvidia and OpenEXR both use same library.
But why would you need a conversion if you can’t upload results to gpu? And if you can upload, you can convert your data to any format using shader, you wouldn’t need any other extension/library/GLU function. [/QUOTE]
The extension should have been properly done so that we could upload it to the GPU. This is an issue on ATI.
I don’t know what you mean by “convert your data to any format using shader”
Yes, what we need is a proper support to what we have (arb_texture_float), not another library/GLU function.
By “convert your data to any format using shader”, nothing special, i just mean using a shader you can convert any format to another one, for example 32bit integer to fp16 texture, or rgbe to fp16 etc.
I just don’t like the idea of adding new functions to GLU, or new libraries like GLU, i just want a solid, standard, low level graphic language.
That is kinda a contradiction, you want a low level language(API) but also want to cram in stuff that can easily be done by a utility lib? You want it solid - yet you want to make the spec more complex for implementations?
I dont really think it has anything to do with any type of contradiction, solid doesn’t mean making a spec complex or not.
And as in this case, supporting a format fully, like you did for other formats, is not an utility. It must have been supported properly on the original standard extension, if it is hard to implement just don’t support, do it in your own GL_XXX as much as you want. And if it can easily be done by an utility lib, why didn’t they do it easily on the original extension? 
http://en.wikipedia.org/wiki/OpenGL_Architecture_Review_Board
“Voting members included 3Dlabs, Apple, ATI, Dell, IBM, Intel, NVIDIA, SGI and Sun Microsystems, plus other contributing members. Microsoft was an original voting member, but left in March 2003.” They vote the spec, vendors, it is on their hands making a spec more complex for implementations or not, as it is on their hands making it proper or not.
I want to upload a 16 bit float texture, not do type conversion in a shader.
Well, if you read any of my replies here, i also want nothing more than that, just with a small difference, i want it supported/complated on the original extension.
I didn’t say anything about where GL executes.
I meant that I would like to be able to use glu* to prepare data prior to glTexImage etc.
For example, scaling down a float/half float image to fix MAX_TEXTURE_SIZE.
[quote=“noncopyable”]
Well, if you read any of my replies here, i also want nothing more than that, just with a small difference, i want it supported/complated on the original extension. [/QUOTE]
I think there is some misundestanding here.
I created this thread as a commentary that ARB_texture_float doesn’t offer the ability to upload HALF float texture.
I know that they want to give glDrawPixels and the rest HALF float support but they shouldn’t have left ARB_texture_float
half done.
I hope future extensions get a better design.
Obviously, ARB_texture_float can’t be changed.
The way I see it, the extensions are written so that you can modify the GL specs according to the modifications provided in each of the supported extensions of your graphics card. Then you should arrive at a consistent spec for that particular graphics card.
According to the spec, the ‘type’ parameter for glTexImage is the same as the ‘type’ parameter for glDrawPixels which refers to Table 3.5 in the spec. GL_ARB_half_float_pixelmodifies table 3.5 by adding GL_HALF_FLOAT_ARB.
So if your hardware exposes GL_ARB_half_float_pixel, you should be able to upload fp16 data using GL_HALF_FLOAT_ARB as the type parameter of your glTexImage calls. If it doesn’t work, your hardware is not compliant with the specs.
IMHO, they should only add GL_HALF_FLOAT_ARB to the dependencies of the GL_ARB_texture_float spec.
Or maybe I still don’t get what the problem is after 2 pages on this topic
N.