Re: texture quandery.

New Message Reply Date view Thread view Subject view Author view

Chikai Ohazama (chikai@talula)
Fri, 6 Aug 1999 12:17:29 -0700 (PDT)

So if I understood this correctly, you're trying to render a volume that
is 512x512x128x2bytes. This is a 64 MB volume. The 2D texture you need
for your UI is 128x128x4bytes. This is 64K.

So there is no way you're gonna be able to put in the 2D texture, no
matter how small, because you're volume takes up all of texture memory.
When you load in the 2D texture all of the 64 MB volume is swapped out of
texture into main memory, and then back in again when you render the
volume again. The bricking does not make any difference since you're
gonna be using the same amount of texture memory.

So I assume that the rendering rate you get with only the 64 MB volume
loaded is OK. So here are some possible solutions to your problem.

1. If you don't need to have your texture reside in "3D", then maybe do a
glDrawPixels, and just draw the image directly on the screen.

2. Since your image is only 128x128, maybe draw it with a bunch of
polygons. This would produce 32K tri-stripped polygons, which should be a
very minor load on the graphics pipe.

3. If you're willing to deal with a slightly smaller volume, possible
brick the volume into bricks of 512x512x16, and have a 512x512x112 volume,
therefore leaving you with some space in texture memory.

4. If you have multiple graphics pipes, draw your UI one pipe, copy the
RGBA and z values from the framebuffer to the second pipe, then render the
volume on top of that.

Hope this helps.

________________________________________________________________________
Chikai J. Ohazama, Ph.D. SGI
Member of Technical Staff 2011 N. Shoreline Blvd. ms 525
Advanced Graphics Division Mountain View, CA 94043.1389
                                     Telephone: (650) 933-6533
                                     FAX: (650) 932-0511

On Fri, 6 Aug 1999, Fred Dech wrote:

> great. a native Performer Volumizer API sounds nice. however...
>
> i guess i still don't follow exactly what is being describing. if i'm
> working with a 2byte 512x512 image list, and i'm using, say, 1 128x128rgba
> 2D texture, i can get acceptable performance using various different brick-
> sizes. but after i exceed 128 data images, whether with a brick size of
> 32x512x512 or 64 or 128, performance hits a logjam. now a 64zsize brick
> volume of 129 slices performs alot better than a 128zsize brick for that
> number of slices, but i can't live with anything less than about 12 fps,
> and i'm getting more like 1.
>
> i tried not running voAppearanceActions::volumeOptimize(). i tried
> changing the parameters to INTERLEAVE_2WAY or SHARED_OBJECT. if anything
> performance got worse.
>
> if i remove the 2D textures, i get performance back, but there goes
> the visual ID structure of my GUI. even an itibit 2x2pixel 2D texture will
> cause the app to grind to a stand-still. i have to resolve this. i can't
> make an effective GUI without textures. any more advice?
>
> thanks.
>
> --fred
>
>
>
> Chikai Ohazama wrote:
> >
> > Hmmm... I guess I misunderstood the problem. If you're willing to live
> > with a 32 MB texture and all your other 2D textures fit into 32 MB, then
> > that works too. I just reread Fred Dech, and realized that he's using
> > Performer. For those of you at SIGGRAPH, go to the Friends of Perfomer
> > session and you'll find a pleasant surprise. We've got a Volumizer node
> > working in Performer.
> >
> > ________________________________________________________________________
> > Chikai J. Ohazama, Ph.D. SGI
> > Member of Technical Staff 2011 N. Shoreline Blvd. ms 525
> > Advanced Graphics Division Mountain View, CA 94043.1389
> > Telephone: (650) 933-6533
> > FAX: (650) 932-0511
> >
> >
> >
> > On Thu, 5 Aug 1999, JB West wrote:
> >
> > > The following is NOT a great idea. I make a LOT of use of 2D textures in
> > > my application. Thus, what I do is cut the Volumizer texture size to 32Megs,
> > > interleaved, shared texture objects; works great. With the latest Volumizer
> > > & patch, I can get > 200Mbytes/second average download rate on an IR2E/2RM's.
> > >
> > >
> > > On Aug 5, 1:20pm, Chikai Ohazama wrote:
> > > > Subject: Re: texture quandery.
> > > > IR doesn't manage textures well at all, so you have to do it yourself. So
> > > > here are some suggestions on possibly making it faster. Try taking out
> > > > the volumeOptimize command in the init call. This will make it so that
> > > > texture-objects are not used, there forcing a download each frame. Also
> > > > try change it to INTERLEAVE_2WAY. It will still be slow, but hopefully
> > > > not as slow as you're going now.
> > > >
> > > > Hope this helps.
> > > >
> > > > ________________________________________________________________________
> > > > Chikai J. Ohazama, Ph.D. SGI
> > > > Member of Technical Staff 2011 N. Shoreline Blvd. ms 525
> > > > Advanced Graphics Division Mountain View, CA 94043.1389
> > > > Telephone: (650) 933-6533
> > > > FAX: (650) 932-0511
> > > >
> > > >
> > > >
> > > > On Thu, 5 Aug 1999, Fred Dech wrote:
> > > >
> > > > > hi.
> > > > >
> > > > > my dev platform is IR w/4 RMs. displaying large volumes.
> > > > > application is Performer-based, using a heavily modified version of
> > > > > Volumizer Performer node from the Performer example program.
> > > > >
> > > > > symptoms:
> > > > > 1. 512x512data at 128 (1 brick) or less slices, great performance (~20
> > > fps).
> > > > > 2. with over 128 slices (>1 brick) performance goes south, big-time
> > > > > (~0.15 fps)
> > > > > 3. remove small texture(s) from GUI portion of application and great
> > > > > performance returns to multiple brick volume (512x512ushort) over
> > > > > 128 slices.
> > > > > 4. i uninstalled patch3696, just to check. no change.
> > > > >
> > > > > conclusions:
> > > > > 1. i'm sc**wed! :o :^)
> > > > > 2. the texture(s) in my GUI are killing Volumizer performance when more
> > > > > than one brick is required to hold the voxel data. but why?
> > > > >
> > > > > any suggestions would be greatly appreciated.
> > > > >
> > > > > --fred
> > > > > --
> > > > > Fred Dech fdech@uic.edu
> > > > > VRMedLab
> > > > > (312) 413-3092: fax (312) 996-8342
> > > > >
> > > >-- End of excerpt from Chikai Ohazama
> > >
> > >
> > >
> > > --
> > > JB West | jbwest@lgc.com | downsized .sig
> > >
> >
>
>
> --
> Fred Dech fdech@uic.edu
> VRMedLab
> (312) 413-3092: fax (312) 996-8342
>

New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Mon Nov 01 1999 - 14:21:40 PST