Texture Residency Check (Problem With)

Hi all,

I’m having some problems with a texture residency check, and was wondering if anyone could shed some light on what’s going on.

glAreTexturesResident() is not available to me, so I’m going the glGetTexParameter() route here. The man page for this function contains the following:

GL_TEXTURE_RESIDENT
Returns the residence status of the target texture. If the value returned in [i]params[/i] is [b]GL_TRUE[/b], the texture is resident in texture memory.

I am therefore expecting to see a boolean value returned.

I’m using a Java binding (LWJGL 0.7-pre2), but it’s not interfering with the method call - it gets routed straight through to the driver. My code is as follows:

Image grass = BMP.read("data\\grass.bmp") ;
ByteBuffer pixels = grass.getPixels() ;
GL.glGenTextures(intBuf) ;
id0 = intBuf.get(0) ;

GL.glPixelStorei(GL.GL_UNPACK_ALIGNMENT, 1) ;
GL.glBindTexture(GL.GL_TEXTURE_2D, id0) ;
GL.glTexImage2D(GL.GL_TEXTURE_2D, 0, 4,
	grass.getWidth(), grass.getHeight(),
	0, GL.GL_RGBA, GL.GL_UNSIGNED_BYTE, pixels) ;

System.out.println("Grass ID = " + id0) ;
GL.glGetTexParameter(id0, GL.GL_TEXTURE_RESIDENT, intBuf) ;
System.out.println("Result = " + intBuf.get(0)) ;

This creates the output:

Grass ID = 1
Result = 1

Now at this point I was happy - GL_TRUE is 1, so the texture is resident! But then I went further, with two blocks similar to this:

ByteBuffer pixels =
	(ByteBuffer)ByteBuffer.allocateDirect(2048 * 2048 * 4)
	.order(ByteOrder.nativeOrder())
	.position(0)
	.limit(2048 * 2048) ;
GL.glGenTextures(intBuf) ;
id1 = intBuf.get(0) ;
			
GL.glPixelStorei(GL.GL_UNPACK_ALIGNMENT, 1) ;
GL.glBindTexture(GL.GL_TEXTURE_2D, id1) ;
GL.glTexImage2D(GL.GL_TEXTURE_2D, 0, 4,
	2048, 2048,
	0, GL.GL_RGBA, GL.GL_UNSIGNED_BYTE, pixels) ;
				
System.out.println("id1 = " + id1) ;
GL.glGetTexParameter(id1, GL.GL_TEXTURE_RESIDENT, intBuf) ;
System.out.println("Result = " + intBuf.get(0)) ;

Two of these blocks in addition to the first block give the output:

Grass ID = 1
Result = 1
id1 = 2
Result = 2
id2 = 3
Result = 3

So that’s not a boolean coming back. Also, those two pixel arrays are 16MB in size, and I only have 8MB VRAM, so it’s not that it’s returning the id if it’s resident, like glAreTexturesResident does.

So where have I gone wrong? Have I misinterpreted the proper operation of glGetTexParameter? Am I calling things incorrectly? Or is the driver misbehaving?

Or have I got things totally mixed up here?

Cheers,
Charlie.

Spec:

The residence status of a single bound texture object
can also be queried by calling GetTexParameteriv or GetTexParameterfv with
target set to the target to which the texture object is bound, and pname set to
TEXTURE RESIDENT.

I don’t know the exact syntax for your Java bindings, but that should then look something like this:

GL.glGetTexParameter(GL.GL_TEXTURE_2D, GL.GL_TEXTURE_RESIDENT, intBuf) ;

Hi Zeckensack, thanks for your response.

Ah, I see, well spotted!

Well, I’ve changed that line and given it another go, and it’s still producing weird results:

Texture ID 1, residency = 1
Texture ID 2, residency = 1
Texture ID 3, residency = 1

I’m expecting a boolean return, so that 1 is a GL_TRUE. So they’re all resident! Even the two that individually are twice as large as my total VRAM…

As I can’t use glAreTexturesResident() I have to bind each texture before checking residency - doesn’t that mean the driver could be uploading the texture data on bind in preperation for use, then lo-and-behold it’s resident? But that doesn’t explain how the 16MB texture gets in there.

It’s an S3 Savage/IX-MV and supports S3TC, but it’s not likely that it compresses things without being asked, is it?

I’ll fill the ByteBuffers with random data and see what it does with that.

Cheers,
Charlie.

Nope, even with 16MB of random data it’s still “resident”. Methinks the driver is lying to me…

Or there’s still some error in the code somewhere?

Cheers,
Charlie.

Mostly older Chipsets (like yours) don’t give you reliable infos on the residency of your textures, and as the way you do it is the same that glAreTexturesResident does it (technically), you won’t get reliable results on your S3 Savage/IX-MV.