PDA

View Full Version : Anything better than textures for per-polygon attributes?



hidefromkgb
08-22-2015, 04:47 AM
Is storing polygon attribute data in 2D textures and fetching them from a vertex shader an optimal (fastest, most compatible, least VRAM-consuming, etc.) approach in OpenGL 2.x when typical data sizes span from several hundred thousand to several millions of independent polys?

Plain old per-vertex attrs are hardly an option: most polygons` properties are updated every frame, based on the data generated by foreign code, so cloning them via CPU tends to be quite expensive.

The very question is due to an unpleasant surprise: vertex texture fetch, a technology I presumed to be around since ~2004, has proven to be absent in Radeon X1700M GPU manufactured in 2008. Despite (declared) full GL 2.1 support, this card reports GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS == 0.

There are two options I currently have: replacing VTF with something else (like pixel shader output to vertex buffer) vs. simply documenting the lack of support for non-VTF cards. This is not a victory-at-all-costs question, so all I`m asking is whether VTF was best for the task.

Alfonse Reinheart
08-22-2015, 08:08 AM
Is storing polygon attribute data in 2D textures and fetching them from a vertex shader an optimal (fastest, most compatible, least VRAM-consuming, etc.) approach in OpenGL 2.x when typical data sizes span from several hundred thousand to several millions of independent polys?

Generally speaking, people don't usually need polygons to have polygon-specific properties. So you're already having to do something that is rather out of the norm.

If I had polygons that needed specific data associated with them, I would probably use vertex attributes. They're easier to work with than textures, and the data can be formatted in a variety of ways that textures can't. Also, you don't have to pay the price of fetching a texture.


Plain old per-vertex attrs are hardly an option: most polygons` properties are updated every frame, based on the data generated by foreign code, so cloning them via CPU tends to be quite expensive.

... if your per-polygon properties are being updated every frame by some "foreign code", then you'll need to transfer that data to the GPU somehow, no matter what. That's either going to be via a buffer object or via a texture object. But either way, you're doing work.

So I don't see why uploading to a buffer (for per-vertex attributes) would be any slower than uploading to a texture.


Despite (declared) full GL 2.1 support, this card reports GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS == 0.

Which is perfectly allowed by the GL 2.1 specification. Yes, the minimum value of GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS, which all 2.1 implementations must support, is 0. So implementations are not required to support any vertex texture fetching.

hidefromkgb
08-22-2015, 10:03 AM
... if your per-polygon properties are being updated every frame by some "foreign code", then you'll need to transfer that data to the GPU somehow, no matter what. That's either going to be via a buffer object or via a texture object. But either way, you're doing work.

So I don't see why uploading to a buffer (for per-vertex attributes) would be any slower than uploading to a texture.Naturally, some work has to be done to upload fresh data into the texture. But compared to per-pixel attrs, it`s 4 times less redundant data going through the video bus per frame, and also no CPU overhead otherwise required to quadruple each attribute. This is the only reason I stick to textures — however, I now doubt the reason`s validity. Unlike textures, my VBO is all static, using a W-coordinate as makeshift gl_InstanceID.

Which is perfectly allowed by the GL 2.1 specification. Yes, the minimum value of GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS, which all 2.1 implementations must support, is 0. So implementations are not required to support any vertex texture fetching.Oh heck, well… It`s really not in the standard. OK, clarified.

Alfonse Reinheart
08-22-2015, 11:15 AM
Naturally, some work has to be done to upload fresh data into the texture. But compared to per-pixel attrs, it`s 4 times less redundant data going through the video bus per frame, and also no CPU overhead otherwise required to quadruple each attribute.

I'll assume that your "per-pixel" here was supposed to be "per-polygon". Those are very different things, and you originally asked about "per-polygon" attributes.

You mention "CPU overhead otherwise required to quadruple each attribute". I assume you're talking about having to replicate per-polygon attributes so that they become per-vertex attributes. Well, I was going to explain how to work around that, but then I remembered that you're limited to GL 2.1, which doesn't have the `flat` interpolation qualifier. Varyings in 2.1 are either all interpolated or all are not.

So yeah, that's a non-trivial issue.