Re: 3D texture size limitations in mesa/r200?

On Jan 4, 2008 1:48 PM, Roland Scheidegger <[email protected]>
wrote:

> R. Aditya Kadambi wrote:
> >
> >
> > On Jan 4, 2008 11:52 AM, Roland Scheidegger
> > <[email protected] <mailto:[email protected]>>
> 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


Hi;

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


Thanks,
Aditya

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

--
_______________________________________________
Dri-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dri-users