Hi,
I'm using OpenGL ES 3.0 libs that came with AdrenoSDK 3.6 for Windows7 64 bits.
glCompressedTexImage2D does not work as expected: 2348 KB are allocated when calling this function with the following setup:
glPixelStorei(GL_UNPACK_ALIGNMENT, 1); GLuint handle; glGenTextures(1, &handle); glBindTexture(GL_TEXTURE_2D, handle); GLenum _format = GL_COMPRESSED_SRGB8_ALPHA8_ETC2_EAC; dword _width = 128, _height = 128, _bpp = 8; dword _size = (128*128*_bpp)/8; byte *_pdata = (byte*)malloc(_size); memset(_pdata, 0, _size); glCompressedTexImage2D( GL_TEXTURE_2D, 0, _format, _width, _height, 0, _size, _pdata );
Does anyone has any idea what am I doing wrong?
Help would be much appreciated,
Thanks!
Hi..
glCompressedTexImage2D is used to specify a compressed texture. It apopears that the memory you are passing in is not in the specified format.
1) How are you calculating the 2348K size?
2) Are you checking the glGetError generated by the call?
ref: https://www.khronos.org/opengles/sdk/docs/man/xhtml/glCompressedTexImage...
Hi,
What does it mean the data is not in the specified format?... it containes 128*128 bytes describing a black, fully transparent RGBA texture in GL_COMPRESSED_SRGB8_ALPHA8_ETC2_EAC internal format... does it not? Anyway, the buffer data in the example is just for testing purposes. This happens even if I pass a buffer data describing a valid texture; the texture loads correctly, the image on screen is what I expect. The only problem is the memory issue.
1) I checked the allocation with Windows Task Manager. This amount of memory is also allocated for each mipmap of the texture (64x64, 32x32, ... 1x1) so the texture with mipmaps takes up 8*2348 KB of memory... :( Also, the memory allocated by the texture in RAM is not freed when I call glDeleteTextures(1, &handle), so after loading and unloading my texture(s) multiple times, I get a std::bad_alloc (out-of-memory) error, as the process is using 3+ GB of memory.
2) Yes, I am - GL_NO_ERROR is generated.
Yes, you are correct regarding the leaks. We confirmed that there are some memory leaks in our desktop Windows emulator. We expect to be addressing them in a upcoming SDK release.