| (Arguments with Allen are *so* informative...and also hard to win!)
Same goes for you, Steve!
| So, you would allow rendering to a texture at the same time as
| rendering with that texture...but put some words in to allow
| this so long as the area of the map you accessed didn't overlap
| the area you were rendering with? ...
I honestly don't know. I think it could work in all the
implementations that I've seen, though the results of using modified
texels would differ from machine to machine. Thanks to this
discussion, though, now everybody understands the problem. :-)
| > In ordinary use, if a proxy query indicates that a texture can be made
| > resident, then that *does* guarantee that you can successfully load
| > the texture at any time in the future. In fact, that's one of the
| > main reasons proxy queries exist; they're the only reliable way to
| > determine if you can actually use a given texture.
|
| What the RedBook says is (quoted verbatim fron the second edition):
|
| "The texture proxy tells you if there is space for your texture, but
| only if all texture resources are available (in other words, if it's
| the only texture in town). If other textures are using resources,
| then the texture proxy query may respond affirmatively, but there may
| not be enough space to make your texture resident (that is, part of a
| possibly high-performance working set of textures)."
That's right. If the proxy query says a texture can be made resident,
then you can rely on that guarantee; the texture can be made resident,
now or at any time in the future. But the proxy query says nothing
about *sets* of textures, and it says nothing about making a new
texture fit in the *current* working set of textures. In order to
cash in on the guarantee, it might be necessary for the OpenGL
implementation to eject any or all other textures that happen to be
resident.
| > This is possible because binding a new texture will throw out any
| > other textures already in texture memory, if necessary.
|
| Well, that's an assumption that you choose to make. ...
If you assume that a texture must be ``resident'' in order to use it
for drawing, then the OpenGL implementation is *required* to throw out
any other resident textures in order to make room for one you've just
bound. That's how it enforces the guarantee on the reliability of the
proxy request.
When OpenGL was designed, there was no workstation hardware (as far as
I know) that had anything but two states for textures: resident in
on-board texture memory, or not resident there. (Some IGs had other
options, though.) Now that we have graphics systems with both on-board
texture memory and portions of main memory reserved for textures, the
term ``resident'' isn't as clear-cut as it used to be.
| ...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.
I think the right solution is a proxy request extension that's capable
of handling questions about sets of textures, rather than single
textures. I suggested one a couple of years ago, but as far as I can
tell I was the only one who liked it. :-)
Allen
_______________________________________________
Mesa-dev maillist - [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev
