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).



Also, on the FreeBSD 7.0 RC1 system, I see bus_dmamem_alloc misaligned error when drm is loaded. Do you think this causes blitter problem?
If so, I can try it on a linux system and or FreeBSD 6.2 to see if I encounter the same issue.

The messages are reproduced below.

 drm0: <ATI Radeon RV280 9250> on vgapci0
info: [drm] Initialized radeon 1.25.0 20060524
info: [drm] Setting GART location based on new memory map
bus_dmamem_alloc failed to align memory properly.
info: [drm] Loading R200 Microcode
info: [drm] writeback test succeeded in 2 usecs