On Fri, 3 Sep 1999 [EMAIL PROTECTED] wrote:
> | ...It's not
> | guaranteed to be true (Think multitexture for example - all N
> | textures have to be resident at the same time - but the proxy
> | command didn't know that the other 4 textures you are using
> | in the multitexture setup were all 2048x2048 maps!). ...
>
> OK, I understand the disagreement now. The proxy result *is*
> guaranteed to be valid in core OpenGL, and that's the reasoning behind
> what I've been saying. Multitexturing is an extension, and
> multitexturing violates the assumptions underlying the proxy guarantee
> (because it's the only operation that requires more than one texture
> to be resident at the same time). Render-to-texture would be another
> extension that would violate the proxy assumptions.
Yep. The problem is that multitexture is now becoming virtually
a required feature in the PC arena - and since it has ARB's blessing,
it's really becoming more than just an extension.
> I think the right solution is a proxy request extension that's capable
> of handling questions about sets of textures, rather than single
> textures.
Yep - so you could make multi-proxy requests that would include both
the texture(s) you are rendering WITH as well as the one you are rendering
TO in order to be assured that render-to-texture would work.
> I suggested one a couple of years ago, but as far as I can
> tell I was the only one who liked it. :-)
But it's a necessity (at least as an ARB extension) given that
multitexture is an ARB extension!
Right now, a program has no way to tell whether a multitexture
combo is too much for the hardware or not...that's NOT GOOD.
(I'd never really thought about that before - I just did a
proxy test on each texture in turn and "assumed" that they'd
play together...risky if you have large textures)
Steve Baker (817)619-2657 (Vox/Vox-Mail)
Raytheon Systems Inc. (817)619-2466 (Fax)
Work: [EMAIL PROTECTED] http://www.hti.com
Home: [EMAIL PROTECTED] http://web2.airmail.net/sjbaker1
_______________________________________________
Mesa-dev maillist - [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev
