Jump to content

  • Log In with Google      Sign In   
  • Create Account


10 Bit textures and bit-shifting on the GPU


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
5 replies to this topic

#1 Gazoo101   Members   -  Reputation: 100

Like
0Likes
Like

Posted 26 December 2011 - 09:47 AM

Dear Forum,

I've found myself in an odd situation where space-conservation is of the utmost priority. I currently have a large amount of 2D vectors expressed in floats (x and y value). These floats are placed in a texture and uploaded to the GPU for usage in a GLSL program.

An easy way to minimize space is to compress the data down to 8 bits per component. So x and y in 8 bits. This provides ok results, but there's some loss of precision that I'd like to avoid or at least mitigate.

It occurred to me that by expressing the vector in polar form, I can more accuratly determine where I need precision the most. In the direction or the length of the vector. Consequently, I'd like to try and use 10 bits for the direction, and 6 bits for the length. But I am at a loss if this is even possible on the GPU? If anyone has any idea or feedback, I'd be very grateful. This is what I know so far:

  • I'm uncertain if the GLSL specifications allow for textures consisting of types that use 10 or 6 bits. Even if it does, it seems as though it might be very inefficient, due to it being quite non-standard...
  • The GPU now supports bit-wise operations. So perhaps I could upload the values combined in a 16 bit texture and then use bit-shifting operations to put them into two separate 16 bit varaibles? What do you think?
Regards,

Gazoo

Sponsor:

#2 Samith   Members   -  Reputation: 2255

Like
1Likes
Like

Posted 26 December 2011 - 01:42 PM

I don't see anything wrong with the bitwise approach, except that it may not have the best performance (but honestly, I can't tell you whether it would be significantly slower or not). If space really is of utmost priority, then you don't have many other options.

In addition, you'll have to take care to make sure you are reading the actual integer data from your textures. The GLSL texture2D function will convert the texture data to a vec4 of float32s, which would make your proposed bitwise operations impossible. I found this forum post that seems to do a good job explaining how to do bit operations on texel data.

#3 mhagain   Crossbones+   -  Reputation: 7865

Like
1Likes
Like

Posted 26 December 2011 - 07:10 PM

For textures you can use the GL_RGB10 or GL_RGB10_A2 formats; these will give you 10-bit per channel data and are standard since - I believe - OpenGL 1.2 (if not 1.1; they're even in Microsoft's gl.h).

It does mean that you won't be able to go all the way with your 10/6 plan, but you could potentially use 10/10 and have 10 bits (plus 2 extra if you need them) for storing something else in.

It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.


#4 V-man   Members   -  Reputation: 805

Like
1Likes
Like

Posted 28 December 2011 - 05:08 PM

Why don't you use a floating point format like GL_RG16F or GL_RG32F?
Sig: http://glhlib.sourceforge.net
an open source GLU replacement library. Much more modern than GLU.
float matrix[16], inverse_matrix[16];
glhLoadIdentityf2(matrix);
glhTranslatef2(matrix, 0.0, 0.0, 5.0);
glhRotateAboutXf2(matrix, angleInRadians);
glhScalef2(matrix, 1.0, 1.0, -1.0);
glhQuickInvertMatrixf2(matrix, inverse_matrix);
glUniformMatrix4fv(uniformLocation1, 1, FALSE, matrix);
glUniformMatrix4fv(uniformLocation2, 1, FALSE, inverse_matrix);

#5 Gazoo101   Members   -  Reputation: 100

Like
0Likes
Like

Posted 30 December 2011 - 12:06 PM

Super cool awesome bananas feedback on the topic. Love how helpful people are on this forum!

Samith - good point with taking care on how the data is converted..!

mhagain - Wow... I didn't even know that specific 10 bit formats existed, but given that I probably need at least 16 bits, it'll be mostly a feature I'll use depending on my curiosity.

V-man - Useful to know that the format exists... I'm curious though... Is there a reason that that particular internal format is not mentioned on the follow page:

http://www.opengl.org/sdk/docs/man/xhtml/glTexImage3D.xml

#6 V-man   Members   -  Reputation: 805

Like
1Likes
Like

Posted 30 December 2011 - 12:15 PM

V-man - Useful to know that the format exists... I'm curious though... Is there a reason that that particular internal format is not mentioned on the follow page:

http://www.opengl.or...lTexImage3D.xml


It depends on the GL version. That page is link into http://www.opengl.org/sdk/docs/man/xhtml/
which says GL 2.1 at the top

You might want to use GL 3.3 http://www.opengl.org/sdk/docs/man3/
or GL 4.2 http://www.opengl.org/sdk/docs/man4/

and the spec files
http://www.opengl.org/documentation/specs/
Sig: http://glhlib.sourceforge.net
an open source GLU replacement library. Much more modern than GLU.
float matrix[16], inverse_matrix[16];
glhLoadIdentityf2(matrix);
glhTranslatef2(matrix, 0.0, 0.0, 5.0);
glhRotateAboutXf2(matrix, angleInRadians);
glhScalef2(matrix, 1.0, 1.0, -1.0);
glhQuickInvertMatrixf2(matrix, inverse_matrix);
glUniformMatrix4fv(uniformLocation1, 1, FALSE, matrix);
glUniformMatrix4fv(uniformLocation2, 1, FALSE, inverse_matrix);




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS