   16 bit vertex arrays?
  Hello,I'm hoping to speed things up a little by using 16bit floats in my algorithm instead of 32bit floats. However, I can't quite figure out how to load my data. I have an array of floats on the host and want to send them into a VBO of halffloats on the card. Is there some way to do the conversion automatically? Or do I have to convert them myself before calling glBufferData? If so, does anyone have a working method to convert a float to a half float on the host? Thank you,Erik Sintorn - erik.sintorn@chalmers.se   
  The spec has a bit of info about packing FP16 values, but if you're lazy, OpenEXR by IL&M includes an Half data type which has been tested to be industry safe!Maybe tell us if you gain anything: vertex data is so well fetched even doubling the data will have minimal performance loss.   ;  Wonderful, For anyone else interested, just download the ilmbase source package, copy the Half/ directory and compile and run the toFloat.cpp and eLut.cpp files there to generate toFloat.h and eLut.h. Then you have a brand new half-float data type that you can use just as a normal float. Thank you Krohm.My program relies heavily on transform feedback, which is why I'm hoping that half-floats will be faster. This however, leads me to a second problem. When starting a transform feedback, you tell GL what you want to stream out by calling glTransformFeedbackVaryingsNV. The output data will take on the format of the GLSL variable you're recording, however, there doesn't seem to be a "half" data type in GLSL! How do I make OpenGL feed back 16 bit float data? Is it possible? Does anyone know? Thank you,   Erik Sintorn   ;  I'd be interested to know how much of an improvement you get.  I remember being told to use 32bit numbers on a 32 bit processor as it avoids the need to pack the extra space before it is operated on.  I.e. if I'm using a counter that only ever counts to 10, I'll still use a 32 bit int rather than a 8 bit char as it avoids packing the space on the CPU which can take extra time.But then again now everyone is using 64bit CPU's I imagine it's still packing even for 32bit variables.   ;  Yes, I have no hopes of getting faster calculations in my program, but since it's mainly memory latency bound, I'm hoping for a speed increase since I only have to stream out half the amount of data. Have to find a way to stream out 16 bit floats first though. Is there any way I can pack two 16 bit floats into one 32 bit float in a shader? If I could just do something like:float a; int b = *((int*)&a); It woudln't be a problem to pack them myself, but glsl does not seem to support that sort of float-as-int stuff. Anyone?   Erik Sintorn   ;  I think it's not necessary to pack 2 16 bit floats. I mean, how would that improve performance?However, Cg functions are available to the nVidia implementation of GLSL so you can use the pack and unpack functions. RTM   ;  Again, Since the application is mainly mem latency bound, in a rendering pass most of the time will be spent waiting for write operations to complete. If I can halve the amount of data that shall be written, I halve the time waiting for memory. What Cg operations are these? How can I access them in GLSL? Thank you very much,   Erik Sintorn   ;  If you have a 32 bit float in RAM and read this, the performance would be the same as reading 2 16 bit floats. This is because of the cache on the GPU which I'm sure you are aware of.It's not going to help to read a 32 bit float and unpack it to 16 bit floats.nVidia drivers advertise the GL_EXT_Cg_shader extension, which means you can use those in your GLSL code. You will have to read the manual on Cg.   ;  No no, that's not what I'm after. If the compiler does an even half decent job, reading 32-bits will take the same time whether they are one float value or two half floats. Obviously. But in the current implementation of my algorithm, the Geometry Shader WRITES a large number of floats to an output stream. If I can write 8 16-bit float values instead of 8 32-bit float values this can be compiled into one 128-bit write instead of two 128 bit writes. I'll post here when done to tell you if there was any speedup (in a couple days. Have to do a lot of other stuff right now).   