Current version: 0.17.x
»GeeXLab homepage

Current version: 1.19.1
»FurMark homepage
»FurMark 1.9.x Submissions

GPU Caps Viewer
Current version:
»GPU Caps Viewer homepage
»GPU DB Submissions

GPU Shark
Current version:
»GPU Shark homepage

»JeGX's HackLab

Geeks3D's Articles
»GPU Memory Speed Demystified

»Multi-Threading Programming Resources

»GeForce and Radeon OpenCL Overview

»How to Get your Multi-core CPU Busy at 100%

»How To Make a VGA Dummy Plug

»Night Vision Post Processing Filter

PhysX FluidMark
Current version: 1.5.2
»FluidMark homepage
»FluidMark 1.4.x Submissions

Current version: 0.3.0
»TessMark homepage

Current version: 0.3.0
»ShaderToyMark homepage
»ShaderToyMark Scores

Current Version: 1.23.0
»Libraries and Plugins
»Online Help - Reference Guide
»Codes Samples

3D Graphics Search Engine:

The Geeks Of 3D


NVIDIA NVIDIA Developer Blog
NVIDIA G80: OpenGL Programming

By: Christophe [Groove] Riccio -
Initial Version: November 12, 2006
Edited and Translated by the oZone3D Team
Last Update: March 25, 2007

[ Index ]

Introduction | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9

»Next Page

5 - Textures

5.1 - Unsigned float textures

Among the improvements brought by the GeForce 8800, there is all that concerns textures.

The EXT_packed_float extension allows storing an RGB color in 32 bits instead of 96 bits with single floats or 48 bits with the half floats. To do that, 6 bits are dedicated to the red and green components, but only 5 bits for the blue at the mentisses level and a total of 11 bits for the red and the green, but only 10 bits for the blue. The components cannot be signed, it is only positive numbers. We can consider that this extension brings the unsigned float to OpenGL. EXT_texture_shared_exponent has a similar goal with 32 bits storage. Nevertheless, in that case, each component uses 9 bits for their mentisse and shears 5 bits for the exponents. We have here also an unsigned float.

5.2 - Texture buffers

Here is another type of textures: the buffers textures brought by the EXT_texture_buffer_object extension. Vertex Buffer Object, Pixel Buffer Object, Bindable Uniform Buffer Object and now Texture Buffer Object? Yes, and that's all for the GeForce 8800. This new object is intended to store data that will be accessed afterwards by using non normalized texture coordinates. The mipmaps and filtering are not available. It is also possible to get the varying variables of the vertex and geometry shaders in this buffer by performing a joint action with the NV_transform_feedback extension. This output flow, at the level of the vertex shader or the geometry shader, can of course be copied into other buffer objects such as the vertex buffer object, which introduce the iteration notion at the vertex and geometry buffers level. Besides, this is the manner the geometry subdivision is made possible for a number of N iterations.

5.3 - Integer representation

Close to the EXT_texture_buffer_object extension but even more to the usual OpenGL textures, the EXT_texture_integer extension makes it possible to use all type of textures whose representation in the shaders is performed through integers. Although most of the time a 2D texture is stored in the memory as a set of integers, with shaders, each component is displayed as a float number between 0 and 1. With this extension, it is not the case anymore, and we can access data such as integers, signed or not. Everything works at the level of the internal storage format of the textures from the GL_RGB8UI_EXT OpenGL API side for example, and through new lookup texture functions in GLSL.

5.4 - Texture arrays

As shows its name, EXT_texture_array brings the texture array notion. A one dimension texture array corresponds to a collection of 2D textures, and a two dimensions texture array corresponds to a collection of 3D textures, each texture of each array needing to have the same size. To access each entry of the array, we can use the texture coordinates, the coordinates corresponding to the entry of the array being sent in the shader as a non normalized float number. Except this, texture arrays behave like 2D or 3D textures, except that there is no filtering between two entries in the array, but this operation may be done in the shader.

5.5 Texture compression

Two new extensions bring two brand new compression formats…or just one. From one side, we have EXT_texture_compression_rgtc (Red-Green Texture Compression) that allow storing a texture featuring one or two chromatic components in a compressed manner, as a block (like S3TC). On the other hand, we have GL_EXT_texture_compression_latc (Luminance-Alpha Texture Compression) that does exactly the same thing and with the same compression rate (2x). Frankly speaking, I suppose that the reason for having those two extensions is for semantic or compatibility reasons with Direct3D 10. These formats are appropriate for the normalmaps storage, because a normalmap is normalized and we can then easily find back the last component: B = 1 – R –G

[ Index ]

Introduction | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9

»Next Page

GeeXLab demos

GLSL - Mesh exploder

PhysX 3 cloth demo

Normal visualizer with GS

Compute Shaders test on Radeon

Raymarching in GLSL

Geeks3D latest news

Geeks3D forum news

»Texture DataPack #1
»Asus Silent Knight CPU Cooler
Page generated in 0.0075619220733643 seconds.