Ignoring the Voodoo texture size limit, this discussion of texture
management is essentially correct in that it is up to the app to manage
texture memory.

When using D3D as the interface to the hardware its possible for the J3D
runtime to create "managed" textures on your behalf that then use the
texture manager we provide in the D3D runtime. Its been there since DX 6.

Its not really a driver issue since in many cases the driver is unable to be
aware of application texture use behavior and therefor couldnt do as a good
job as the application. DX 7 provided an ability to have "driver-managed"
textures but again the app would have to make use of those via flag bits at
texture creation time. Note in the year since DX 7 shipped only 1 IHV has
made use of "driver-managed" textures.

Note that in this case the app is the J3D runtime, but its the J3D programs
that create/use the textures. Unless there is some way for the J3D API to
allow programs to inform it of usage intents ( static, dynamic,
high-priority, etc ) its real hard to do a good job at this.

What this means in practice is if you must overcommit texture memory beyond
25% ( a rough rule of thumb that allows reasonable bus bandwidth for texture
updates as well as rendering primitives ) then expect frame rate
degradation. Please dont expect to load and use 40m of texture on an 8m card
without hardship.

-----Original Message-----
From: Justin Couch [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, July 18, 2000 5:33 AM
To: [EMAIL PROTECTED]
Subject: Re: [JAVA3D] J3D 1.2beta DirectX on Voodoo3


"J. Lee Dixon" wrote:

> After debugging, I figured out that the culprit was that I had a LARGE
> (>4mb) texture.  After replacing this texture with a much smaller one
> (256x128), texturing worked fine.  Sounds to me like this board does not
> like textures probably greater than 2mb or some other limit.

Funny you should mention this as I was involved in a conversation about
this today (well, actually more like an innocent bystander at the time).
As a big disclaimer, I'm relaying all of this second hand as I have
absolutely no background knowledge on the subject so I'll probably get
something wrong in the process. However my sources were Kevin Rushforth
(he's down under at the moment) and a guy that did a masters thesis on
texture mapping. So hopefully they know what they are talking about.....

It appears that a lot of boards don't release texture memory or attempt
to swap textures in/out of memory when the texture cache gets full. This
is actually a driver implementation problem and a small contribution
from Java 3D. What happens is some drivers fill the texture cache as you
request textures. Because video cards tend to use only video memory for
the cache, when this fills up (say 4MB of the 8MB video memory on your
card) the drivers fail to free memory when another texture is needed.
The visible result of this is that some objects don't get textures or
the wrong ones because the old ones are not swapped out of memory when
not needed.

>From the Java 3D perspective, it assumes that the boards handle their
own texture memory. J3D just requests textures to be loaded and assumes
the board looks after the rest of the details. For the card drivers that
properly manage their own memory resources (They use a concept of
virtual memory by automagically swapping stuff in and out of video
memory) you don't see these bugs. For cards that don't do anything (far
simpler to implement!) you see these problems. Now to solve this, Java
3D is going to have to be more intelligent about knowing what
implementation the driver supports and then do The Right Thing from
there.

So, the wash up of all this is that it may be a J3D problem, but
probably not, but J3D is helping to contribute to it.

--
Justin Couch                                    Author, Java Hacker
http://www.vlc.com.au/~justin/               Java 3D FAQ Maintainer
http://www.j3d.org/              J3D.org The Java 3D Community Site
-------------------------------------------------------------------
"Humanism is dead. Animals think, feel; so do machines now.
Neither man nor woman is the measure of all things. Every organism
process data according to its domain, its environment; you, with
all your brains, would be useless in a mouse's universe..."
                                              - Greg Bear, Slant
-------------------------------------------------------------------

===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA3D-INTEREST".  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".

===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA3D-INTEREST".  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".

Reply via email to