View Full Version : subregion compressed texture

11-26-2003, 12:54 PM
Well, considering I hit a unbelievable 0 reply with my previous topic, I hope this question will be a little bit easier. We'll see.

My program needs to transfer large compressed textures to the card in little time. So my original function which was downloading all of a mipmap at one time was taking too long. See the line below

glCompressedTexImage2DARB (GL_TEXTURE_2D, nMipMap, nFormat, width, height, 0, size, pdata);

So I though of sending it by pieces. First step is to make sure it still work if I try to send the same information with glCompressedSubTexImage2DARB. Right? That's what I did (see line below)

glCompressedSubTexImage2DARB (GL_TEXTURE_2D, nMipMap, 0, 0, width, height, nFormat, size, pdata);

I've been suprised that juste replace the first line by the second line gives me an invalid operation, and the textures don't show up any more. Am I doing anything wrong cause I think those 2 lines shoulld behave the exact same way.

Any ideas?


11-26-2003, 01:23 PM
you must create a texture with glCompressedTexImage2DARB before you can update it with the sub command

11-26-2003, 01:31 PM
In order to use TextureSubImage command, you must first use a TextureImage command to define the whole texture and in your case possibly with a NULL image pointer.

11-27-2003, 06:23 AM
I'll definitely give it a try and give a word on how it went.


11-27-2003, 06:40 AM
Thinking about it... ok, I have to use glCompressedTexImage2DARB to first create the texture. But if I do so, it will download the texture, so I'm back to square one (to much data to transfer in too little time). If I provide a NULL pointer, is it going to download anything?

11-27-2003, 12:42 PM
You can pass NULL as data to {Compressed}TexImage() to "reserve space" without downloading.

However, I don't understand why you think uploading the compressed data is too slow. A 1024x1024 texture is 512 KB. Assuming AGP 4x, you have 1 GB/s of bandwidth, so you could theoretically upload 2,000 of those textures per second.

If you're supplying un-compressed data, and let the driver compress, then you should know that:
1) the driver doesn't do as good a job as the Photoshop DDS plug-in does
2) it still takes forever
3) you are entirely CPU limited at this point

I highly recommend against it. If you use S3TC compression, you should compress offline. For cards that don't support compression, you can de-compress from the S3TC data in software on your own (it's really simple). Box-filter one level and shrink 2x in each direction to get less blockiness in that case (and not be entirely insane on memory usage).

11-27-2003, 01:06 PM
1GB/s on AGP 4x? Cool, I didn't know that. However, that makes me wonder why I have those results. When I send a 1024x1024 compressed texture (171 Kb), everytime I transfer the first mipmap (131Kb), my frame time jumps over 20 ms. I'm trying to mainting 60Hz, so that's no good. But your numbers give me a bandwidth of 16666Kb/it, which is a lot larger than what I'm really using. Is there anything I must do to have the 1GB/s bandwidth? Cause for sure I don't have that. (yes, I have vertex data to transfer, but not that much.). I'm using AGP 4x.

I read something about AGP aperture... what is that?


12-09-2003, 12:22 PM
Originally posted by jwatte:
You can pass NULL as data to {Compressed}TexImage() to "reserve space" without downloading.

For some reason, that works on a Radeon, but my GeForce FX crashes whan I pass a NULL pointer. Tried with to different drivers. Same results. Weird...