Stephen J Baker wrote:
>
>
> Is it possible that the multitexture is trying to ensure that
> BOTH of the two maps that it needs are loaded - yet there
> is not enough RAM for them both - so the first texture loads
> then in order to get the second one jammed in, a texture that
> is in memory currently has to be tossed out - and the least
> used is the first one that we just loaded? In that way, it
> might swap the two textures in and out forever and lock up
> as you describe.
>
> There is an interesting problem with that (aside from any possible
> bug) because of the semantics of proxy textures which can't
> guarantee that two maps that are SIMULTANEOUSLY needed during
> rendering will BOTH fit at the same time.
>
This is an interesting problem for OpenGL, and seems to
need some more extensions to the language.
Based on a quick look at the source, the fx driver will
not suffer for this on Voodoo2, because it appears to place
the two textures into the different texture units. So
they don't compete for the same memory areas.
I don't know for sure how V3 works in this case.
Also I suspect that multitexture and real trilinear
filtering are mutually exclusive on Voodoo2???
On V 1 the fake multitexture appears to work by doing two
passes on the data. It does not seem to try to get both
textures into memory at once, insteads checks that
they are in only when they are needed. So there should
not be problems here.
Also what I found out was that the texture handling just got
hung somehere inside grDownloadMipMapLevel, I don't know
glide but I thought that these functions are not really
aware which memory areas are used, and they should not
get stuck unless the library or hardware state is corrupted.
(Or when given invalid parameters, which based on my checking
looked ok)
I did some extra testing and apparently my program gets
stuck also when the the multitexture is not used but
when there is sufficient amount of textures loaded.
(but much less than the 2 M on board)
(I have not looked at this before because I have used
a V2 previously, I have not been able to duplicate the
problem with it, even us
The reason why I suspected the usefulness of the
multitexture emulation is that without multitexture
for example my application minimizes texture swapping,
but the emulation will swap actively between the two
textures. On the other hand the multitexture emulation
will ofcourse decrease the amount of geometry
transformations into half.
I would benchmark, if my application would run
After writing all this I realized that I should be able
to try the same configuration on my V2.
Setting FX_EMULATE_SINGLE_TMU and using control
panel to limit glide to 2 Mb memory per TMU, gave
me an emulated Voodoo 1 !
It was dog slow because of texture swapping
(6 MB per frame, I will have to check texture LOD)
and the debugging prints I have added into Mesa
did not help either, but it worked, both with multitexture
emulation and without. So the problem is something
specific to (my?) Voodoo 1 setup.
Eero
___
Mesa-bug maillist - [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-bug
___
Mesa-dev maillist - [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev
