OpenGL 3.x VertexTextureFetch, pixel formats

I’m interested in knowing wich formats are supported by most videocards so that I can do VTF in asafe way (I read ATI cards had some problems but that was a post of 2005 related to X1x00 series):

I need it for displacement mapping and vertex coloring, so personally I’m interested in RGBA8 and RG32F RG16F, but having a list of formats that are supported and yields generally a good performance (of course related to bandwith they require, but I would exclude particular formats that has shown causing more than needed performance penality).

Target OpenGL version 3.x

I have a 1pixel for each vertex (the reason is that I use some render target to generate coloring (GI) and displacement so I have to store that data in textures… ) is texelFetch reasonable or should I use sampler2D?


GL 4.x (however the tessellation extension is available to older hardware)
Additional question, when looking at GL wiki and spec, it is not clear to me how Geometry and the 2 tessellation stages should be considered when doing TexturesLookup? Vertex or fragment? So accessing a texture in a tessellation shader does reduce the count capped by GL_MAX_VERTEX_TEXTURE_UNITS or some other variable that I’m not aware of?).

is texelFetch reasonable or should I use sampler2D?

Well, one of those is a function and the other is a data type. So asking which to use is like asking “should I use sin or float?”

The sampler type you use depends only on the type of texture you’re rendering your data to. For displacement mapping, I would suggest computing derivatives yourself and using the sampling function [var]texture[/var]. That way, you can use filtering, so you don’t have to stick to your 1 pixel-per-vertex limitation.

However, [var]texelFetch[/var] is perfectly adequate if you don’t want filtering.

it is not clear to me how Geometry and the 2 tessellation stages should be considered when doing TexturesLookup? So accessing a texture in a tessellation shader does reduce the count capped by GL_MAX_VERTEX_TEXTURE_UNITS or some other variable that I’m not aware of?). So accessing a texture in a tessellation shader does reduce the count capped by GL_MAX_VERTEX_TEXTURE_UNITS or some other variable that I’m not aware of?).

That’s because there’s nothing to consider (OK, there’s one thing to consider). The only difference between shader stages, as far as accessing textures is concerned, is the fragment shader stage, because it implicitly has derivatives (usually). A fact that the Wiki does mention (admittedly, it could be a bit more prominent, due to the importance of the issue).

Also, each shader stage has its own set of limitations. Unless otherwise stated, the limitations for one stage do not impact the limitations on another. And the only ones that do are the combined output things (which, baring the last on the list, is really just an aggregation of all shader stages).

You’re really trying to over think this.

thanks, but main question is unsolved. :confused: Does all Framebuffer texture formats are ok for VTF? are there formats I should avoid?

thanks, but main question is unsolved.

Well, I haven’t needed to sample stuff from the vertex shader, so I have no particular implementation-dependent knowledge on that score. However, I do know that virtually all OpenGL 3.x+ class hardware uses a unified shader architecture. Which means that all of the shader stages run on the same shading units. And therefore use the same texture fetching hardware (probably). So I wouldn’t expect there to be problems, outside of the derivatives issue previously mentioned.

But again, that’s all theoretical.

Ok thanks!

You could check with glGetInternalformativ() using GL_VERTEX_TEXTURE as the query, if your GL has ARB_internalformat_query (or has this in core in the GL version you’re using). That’ll at least tell you whether it’s supported or not without having to trip GL errors to find out.

With the GL_FULL_SUPPORT​, GL_CAVEAT_SUPPORT​, or GL_NONE​ returns, you may even get insight as to whether it’s slow or not. But the only way to establish that for sure is to test it.