On Jan 4, 2008 1:48 PM, Roland Scheidegger <sroland@tungstengraphics.com> wrote:
R. Aditya Kadambi wrote:
>
>
> On Jan 4, 2008 11:52 AM, Roland Scheidegger
> <sroland@tungstengraphics.com <mailto:sroland@tungstengraphics.com>> wrote:
>
>     R. Aditya Kadambi wrote:
>     > Hi;
>     >
>     > I am trying do hardware accelerated volume rendering with 3D textures
>     > using a scenegraph called OpenRM( www.openrm.org
>     <http://www.openrm.org>
>     > < http://www.openrm.org/>). The program is called vrend which uses 3D
>     > textures
>     > to HW render 3D raw data.
>     >
>     > I am using ATI X9250 (R200) card. I am trying to render two sets
>     of raw
>     > data. The smaller one which is 64x64x64 is successfully rendered
>     with 3D
>     > textures with r200 driver. The bigger volume which is 256x64x256 only
>     > appears to be rendered in "half" along the z axis. The other half
>     > appears as garbage.
>     >
>     > I put in a call for 3D texture size and it comes as 256 (which
>     probably
>     > means I can render a 256x256x256 cube??).
>     >
>     > I was able to successfully Software render it on Mesa. It renders
>     fine.
>     > Furthermore, it is rendered fine with the ATI proprietary driver (V
>     > 8.28.8) (surprise! surprise!).
>     >
>     > This makes me suspect the r200 driver. Is there an inherent
>     limitation
>     > or a bug or a missing feature in the driver (r200/mesa) which might
>     > cause this. Is there any way for me to compile mesa with debug
>     flags to
>     > test this? Or is there a bug in the lower level ati driver?
>     This should work. The hw seems to have a limit for the depth of a
>     texture of 256 (not sure why ati's driver can support more, maybe the
>     limit is actually not what's stated...), the other directions might
>     potentially work even up to 2048 (or not, maybe it would exceed the
>     internal range of the address calculation somewhere).
>     I suspect what's happening is that the driver exceeds the blitter limits
>     somewhere when uploading textures, since 3d textures are submitted to
>     the hw as huge 2d textures (well the width is normal but the height is
>     huge). There were similar problems in the past with large, mipmapped 2d
>     textures (the fix for that was
>     554e5a2eaf4b681b5c43b6aeb66f100a66da4a42).
>
>     Roland
>
> How do I debug this in the r200 driver? Any specific debug flags I can
> compile with and report back?
R200_DEBUG=tex might provide some useful information. Also, if it
currently gets half the texture correct with 256x64x256 it should be
fully correct if you use 256x32x256 or 256x64x128 instead if it's really
a blitter problem.
Alternatively, you could try out the attached quick patch against radeon
drm, which is completely untested. I guess the problem could be fixed in
userspace instead by breaking up a single texture upload into several
smaller ones (ugly).

Roland

I tried 256x256x32 (widthxheightxdepth) and it renders fine.

So successes are (in terms of widthxheightxdepth)

64x64x64
256x256x32

Failures

256x256x64

It looks like depth of more than 32 can cause issues of "half-rendering" when the other parameters are 255x256.
So is this blitter problem?

Thanks,
Aditya