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

I get these debug messages at start on setting R200_DEBUG=tex. Same messages
for the successful rendering and unsuccessful rendering!

r200AllocTexObj( 0x802bf2800, 0x802ef0800 )
r200AllocTexObj( 0x802bf2c00, 0x802ef1000 )
r200AllocTexObj( 0x802bf3000, 0x802ef1800 )
r200AllocTexObj( 0x802bf3400, 0x802ef2000 )
r200AllocTexObj( 0x802bf3800, 0x802ef2800 )
r200AllocTexObj( 0x802bf4800, 0x80bb02000 )
r200AllocTexObj( 0x802bf4c00, 0x80bb02800 )
r200AllocTexObj( 0x802bf5000, 0x80bb03000 )
r200AllocTexObj( 0x802bf5400, 0x80bb03800 )
r200AllocTexObj( 0x802bf5800, 0x80bb04000 )

Thanks,
Aditya


On Jan 4, 2008 1:56 PM, R. Aditya Kadambi <[email protected]> wrote:

>
>
> 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
> >
> Thanks. Looks like the patch is for drivers/dri/radeon/*. I thought the
> driver was drivers/dri/r200/*. Am I missing something here?
>
> In the meantime, I will put in the debug flags and report back. Also I
> will try out the different sizes mentioned.
>
> -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