glTexSubImage

Hi,
I’m planning a texture paging system, and I want to try a method detailed on this SGI page . It uses a single texture object updated with glTexSubImage. This requires updating smaller regions of the texture. My question concerns the performance of glTexSubImage on modern hardware ( >= TNT), specifically when updating narrow regions of texture. Do cards upload entire scanlines even if only a small part of them are updated? Do they perform worse when using GL_SKIP_PIXELS and/or GL_SKIP_ROWS? Are there alignment issues, or some kind of minimum granularity (like 4x4 blocks)?

Thanks,
david

The problem is that then ALL your textures
will go through the bus for EACH frame. That’s
a good way of slowing down rendering.

Uploading a bunch of textures and having them
sitting on the card (in close RAM to the GPU)
is absolutely preferrable from a performance
standpoint.

If you know how much memory you want to spend
on textures, and which textures will be much
re-used, and which are less likely to be
re-used, you can upload as much as you can
fit to the card of the much-reuse ones, and
page the others in using the mechanism you
describe.

Carmack had an interesting article on why
using texture memory as a MRU replacement
cache (not LRU!) with last-frame usage as a
keeper condition would be a Good Thing, a
while ago; I don’t have an URL though.

Originally posted by bgl:
The problem is that then ALL your textures
will go through the bus for EACH frame. That’s
a good way of slowing down rendering…

Yes, that would be a good way to slow down rendering. But that’s not what I’m doing. That method is shown on the SGI page, but look further down. They’re only updating small regions of the texture each frame, hence the question about glTexSubImage’s performace on narrow strips. It only works on 2d function type surfaces, like terrain, which is what I’m gonna use it for.

The vast majority of the texture is kept on the card thru each frame, only the new parts are sent.

Originally posted by bgl:
Carmack had an interesting article on why
using texture memory as a MRU replacement
cache (not LRU!) with last-frame usage as a
keeper condition would be a Good Thing, a
while ago; I don’t have an URL though.

I think I read this too. Probably a .plan update, perhaps the one where he talks about virtualizing texture memory. It will be very interesting to see how he does it in Doom3 .

[This message has been edited by dufke (edited 03-04-2001).]

[This message has been edited by dufke (edited 03-04-2001).]