ATI Radeon &3D-texturing

How many frames per second can i get when using 3d-texturing on ATI Radeon 64MB for a volume (about 256256256) ??

not much, and why? cause it does not support such a size of texture… i think 64x64x64 is the hightest…

GL_RGBA textures:
64x64x64: 1 megabyte
128x128x128: 8 megabytes
256x256x256: 64 megabytes

yeah, it has 64mb ram, the ati, but it does not fill the whole ram just for your texture… win2k dont use 0mb ram, eigher ( 70mb here )… so this size is just not acceptable

try using 32x32x32x3 or x1… ( RGB or just ALPHA )…

smaller the bether…

texture2d:
64x64 = 16 kilobytes
256x256 = 256 kilobytes
1024x1024 = 4 megabytes

so your 256x256x256 texture represents a: 4096x4096 texture in 2d… ever seen such a texture yet?

128x128x128 works without problems.
I’ve tried 256x256x256 too, but got very strange results and really bad performance …

I don’t have the specs in front of me, but I think the actual harware limitation is something like 128x128x256 or 128x256x256.

      -Jason

As for the original question, “how many frames per second can I get…,” what are you drawing?

           -Jason

if i used a volume of sie 256256256 (NOT RGBA) just only Alpha it will takes about 16MB…
How many frames per second can i render this volume in 3d-texture ???

Are there any other “unknown” limitations of Radeon’s 3d textures that we should know of as developers? (Such as using 3d textures disables 1 of 3 texture units, no trilinear filtering (mip-mapping) or no mip-maps used ever, etc.

Does it suffer performance greatly when its against the Z-grain or mildly against Y-grain? Does that change with the block-sizzled DXT1 (DXV1 ? ) compression? Can we combine an Env-map perturbation of the X,Y tex coords of a 3d? (currently fails under GL).

Its a major waste of time to assume there’s a bug in one’s code when its a hardware limit.

Is 24bit RGB an actual savings on the Radeon? I’d assume all textures internally are 8,16, or 32 bits in size…no 24bit RGBs right? Are there penalities for using 16bit LA textures?

There is a lot that should be published about developing for Radeon that can currently only be known through trial and error-

Any info is of much help as ATI’s developer relations seem to be really overwhelmed/swamped right now and not able to answer direct questions via email.

I’ll try to answer your questions:

3-D textures can only be used on texture unit 0. Additionally, using the 3-D texture on unit 0 implicitly takes up unit 2. This means that you really only have two texture units for multitexturing when using 3-D textures: unit 0 and unit 1.

As for filtering, there is no mip-mapping for 3-D textures on Radeon.

As for your performance questions, I’m not 100% sure the answer to those.

EMBM can not be used with 3-D textures…it only works on two texture coordinates. Additionally, since unit 2 is used for the 3-d texture, you can’t do EMBM (since the bumpmap also is required to be on unit 2).

As for 24bit RGB images…these are stored as 32-bit RGBX images on the card, so there is no savings. I don’t know of any penalties for using 16-bit LA textures.

Hope this answers some of your questions…

Thanks DGinsburg,

Can you also say anything about exposing the Priority Buffers of Radeon? Great feature with no api-

(At least can you expose the Priority test?(assuming this is a “ColorTest”, like a 16 bit Alpha test. ))

Also, any word on the vertex streams or some method of opening a 1-copy, AGP buffer to place dynamic verts in? (or a vid-mem buffer for static verts). The Nvidia VAR extensions do offer some good performance over CVAs (except the context switch and no index buffers).

Thx-

What does EMBM stand for? Embeded Geometry?
I found that I could not render embeded geometry with 3d texture in perspective mode(Ok in ortho mode). Do you have any idea?

I think EMBM stands for enviroment mapped bump mapping, I am not 100% sure though.

> Also, any word on the vertex streams
> or some method of opening a 1-copy,
> AGP buffer to place dynamic verts
> in? (or a vid-mem buffer for static
> verts). The Nvidia VAR extensions do
> offer some good performance over CVAs
> (except the context switch and no
> index buffers).

We have an extension mostly implemented (currently called ATI_vertex_array_store, but will probably ship as an EXT_) which addresses these issues.  Index buffers would probably come in a separate extension.  Vertex streams is a different extension from this.

> I think EMBM stands for enviroment
> mapped bump mapping, I am not 100%
> sure though.

Indeed, EMBM is environment mapped bump mapping.  Have a look at the  [ATIX_envmap_bumpmap doc](http://www.ati.com/na/pages/resource_centre/dev_rel/sdk/RadeonSDK/Html/Info/Extensions/ATIX_envmap_bumpmap.html)  for specifics.  Sample code is forthcoming.

  -Jason

Vertex streams should be no different from the currently available VertexPointer, TexCoordPointer, and other 1.1 calls (plus the 1.2 DrawRangeElements).

If you ship an EXT_ extension, who else is using the same thing? Does this mean it will work the same as NV_vertex_array_range? (pretty please, I hate multiplication of code paths

Now, for nVidia: ATI will make index buffers happen. What’s your response?

> Vertex streams should be no different
> from the currently available
> VertexPointer, TexCoordPointer…

It is orthogonal to these, and provides a means for specifying secondary position and normal arrays for hardware tweening.

    -Jason

This is good news for those that wish to exploit the 3d texturing of the Radeon as well as hardware tweening. Am glad to hear of EXT_vertex_array_store and that ATI_Vertex_Streams will arrive in the future.

Does anyone know anything further about exposing ATI_Priority_Buffers? Or some form of ColorTest (similar to Alpha Test…)?