Octree textures on GPU, why texture memory instead of global GPU memory?

Hi there,

I was trying to implement octree textures on GPU, following the great article in GPU Gems 2: https://developer.nvidia.com/gpugems/gpugems2/part-v-image-oriented-computing/chapter-37-octree-textures-gpu .

However, while implementing I got a bit confused. If I understand it correctly, the octree texture on GPU is represented by a 3D texture (the indirection pool), which on its turn is subdivided into 2x2x2 indirection grids. These indirection grids contains indices to child nodes or color values in each of its 8 cells. Each indirection grid thus represents an octree node, together with pointers (3D texture indices) to its child nodes. Successive indirection grids are thus not necessarily spatially nearby. If my understanding is incorrect, please correct me.

Now my question was why do we explicitly have to use texture memory for this and can’t we just use globally allocated GPU memory that is readable and writable (e.g. cudaArray)? Are features such as texture filtering usable for a representation like this, because filtering would involve interpolation which will alter the indirection grid indices (pointers), correct me if I am wrong. In my program I will need to read and write to the octree texture, which is why I thought something like a cudaArray would be more convenient to work with.

Thanks in advance,

Best regards,

– Chuppa

why do you say that?

I’m sure you don’t. I’m sure you could do an equivalent realization using ordinary global memory.

A cudaArray is readable and writable? That is news to me. Certainly you can read a cudaArray (after a fashion) by using it as the basis for a texture, and you can write to it (after a fashion) by using it as the basis for a surface, but that doesn’t sound like what you are asking.

In the cases I am familiar with, a cudaArray is an “opaque” entity. You definitely cannot infer underlying organization, adjacency, or indexing, except via surface write and texture read functions.

It also seems odd to me to ask about interpolation in the context of indexed indirection, but I probably don’t understand the use case.

As an aside, that book was written in the infancy of CUDA (in fact, it may predate CUDA, since it has Cg in view), when there was a significant population of GPUs that had no caches at all, other than the texture cache. Today, such GPUs are obsolete. Modern programs, running on modern GPUs, may see less dramatic benefits from using texture for caching.

1 Like

My bad, in fact I just meant an arbitrary allocated block of device memory that I access via a device pointer.

Since textures support automated filtering I thought maybe this was the reason to store the octree in texture memory, which neither made sense to me in the context of indexed indirection and that is what confused me.

Provided the historic context of older GPUs and their limited caching capabilities this makes more sense now, thanks for clearing that up.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.