0

I try to implement a Volume Renderer with OpenGL and ray casting. Everything works well but I get a performance problem when I look in a negative direction. This means if I look in positive x direction (viewing vector 1, 0, 0) is the performance ok. But if I look in negative x direction (-1, 0, 0) the framerate goes down to 2-3 fps. I use a 3D texture to hold the data of im dataset. Is there maybe a problem with the caching of the texture on the GPU? Or what could be the problem that the framerate goes down, when I look in a negative direction?

It would be great if I get some tipps, what the problem could be.

user1844213
  • 47
  • 1
  • 6
  • 1
    Maybe it's a problem of you raytracing through a 3D volume. I see no reason to expect this to be *fast* when you're potentially doing dozens of texture accesses *per fragment*. – Nicol Bolas May 29 '13 at 10:08
  • I know that I do many texture accesses per fragment, an I've implemented some optimization stuff. My raycast is fast when the ray has a positive direction. So the GPU can handle this number of memory accesses. – user1844213 May 29 '13 at 10:28
  • I've set the Mig and Mag Filter to GL_NEAREST and the performance become a little bit better, but not perfect. Would changing the 3D texture to a texture buffer object become more performant? – user1844213 May 29 '13 at 10:59

1 Answers1

1

There are two things to consider in this situation:

  • memory access pattern

and

  • texture data swapping

The performance of a GPU is strongly influenced by the pattern in which data is addressed in accessed from memory. A ray caster casts its ray from front to back of the view (or in the opposite direction, depending on the implementation and internal blending mode) so depending on from which side you look at a 3D texture you get completely different access patterns. And that can have a very large influence.

3D textures consume very large amounts of memory. OpenGL uses an abstract memory model, where there's no explicit limit on the size of objects like textures. Either loading them works or not. And if a driver can manage it, you can load textures larger than what fits into GPU memory. Effectively the GPU memory is a cache for OpenGL data. And if your 3D texture happens to be larger than the available GPU memory it might be, that the OpenGL implementation swaps out texture data while its being accessed at rendering. If your access pattern is lucky, this swapping processed nicely fits "into the gaps" and can sort of stream the texture data into the cache (by which I mean GPU memory) right before its required, without stalling the rendering process. However a different access pattern (other view) will not work well with on demand swapping of data, trashing performance.

I suggest you reduce the size of your 3D texture.

datenwolf
  • 159,371
  • 13
  • 185
  • 298
  • I think texture data swapping is not the problem. I've analysed the memory of the GPU during rendering and there are enough free memory after loading the texture. I think memory access pattern could be the right think. Can I change or influence the memory access pattern with OpenGL? I cannot find anything about it. – user1844213 May 29 '13 at 10:10
  • @user1844213: There's nothing you can do about it. The order in which fragments on the framebuffer a processed is either hardcoded or hardwired by the GPU/driver combination and in a raycaster there's little more than choosing in which direction you process the ray. Some direct volume rendering styles can be processed front to back and terminated early (per ray) while others work only back to front and must process the whole span within the volume. You could get a faster GPU ;) Also ray subsampling can have a large influence; it the one "knob" I turn when running into performance issues. – datenwolf May 29 '13 at 11:42