Oxygen GVX1 + 3D textures --> very slow

[PhilY]

Hi,

I just wrote a small code in glut, with LOT's of dorbie's help; it runs quite slow on my card above using 128^3, 32 bit color, blending.

That's only 8megs so my card should be able to handle that. I tried drawing and blending 128 128^2 textures; they run a lot quicker than the 3D texture counter part.

The way I'm implementing is:

- Transform texture matrix
- set up clipping planes and enable
- Change to modelview matrix
- Generate texture coordinates
- and draw about 80 quads, view aligned

It's especially slow (like 2-3 seconds for a single frame on 300X300 viewport taking up less than 30% of the viewport area!) when it's rotated 45 degrees about the X and Y axes - that's when the most number of quads are rendered since the 3D texture is longest in the z-direction.

I was suspecting if 3D texturing is only implemented in software for this card but the guy from 3D Labs assures me that it is implemented in hardware. Plus, the rotations about one single axis are too fast to be software since I only have P2-450 Xeon - maybe 7 fps.

So is this about the normal speed for 3D textures? Anyone have GVX1 and tried 3D textures? Any comments/suggestions are greatly appreciated.

If you wanna see the details of my code, you can look at this post: http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/006597.html

- Phil

[dorbie]

80 (quads) * 300*300 (viewport) * 7 (fps) *.33 (coverage) = 17 Megapixels/sec 3D rgba textured blended fill performance.

This is a very approximate number. I dunno what it's supposed on your system but that might not be a bad number on your card.

You might try disabling texturing and comparing performance. Try a smaller texture format (32 bits per pixel might slow you)

Another option is to increase 'a' in your loop to draw fewer than 80 quads, only do this when in 'interactive' mode, when you stop moving increase the quad cound again and generate ona frame. You need to compensate my adjusting the alpha of the color fragment.

You should disable depth testing unless you need it. Mess around with the texture filter & see what happens, try a NEAREST instead of LINEAR just to see if you might be texture limited. Are you MIPmapping? Try it without. Try rendering along a different axis & see if the performance changes, sometimes memory access can be slow depending on axis alignment especially in bad 3D texture implementations.

You might want to turn off clipping or other state just to estimate the performance impact on your system since implementations might do something unexpected that hurts performance (texture based clipping springs to mind) My feeling is that 80 quads is a breeze but the hefty 3D fill performance might not be on most graphics cards, even if they support 3D texture in hardware.

[dorbie]

P.S.

Make sure you're using texture objects and binding the texture not loading it each frame, sorry if this is obvious, but you never know. I've seen some crazy code.

[PhilY]

Thanks once again, dorbie.

I ran the code on Radeon VE 32DDR (64bit), it ran like 20 times faster! Radeon VE is faster than the GVX1 (550M texels/s vs 200M), but that wouldn't make the result that much diff. Memory size are the same and so should be the throughput - roughly - since GVX1 has 128 bit SDR.

The machine with Radeon did have P4 1.6GHz so I guess there are other variables as well. I tried GL_NEAREST, it came out about 1.5 times faster which is nice. I'll try some of other stuff you've listed there. Maybe GVX1 just have really crappy 3D texture implementation. I should really get a new vid card http://www.opengl.org/discussion_boards/ubb/smile.gif

[dorbie]

GL_NEAREST was just for testing, it will produce poorer quality results. Congrats on your Radeon success.