0

My question may not be very correct, but let me describe it in details. I use cocos2d-x (renders using opengl-es 2) game engine to show images on Android device. In some cases when image dimensions are very large the images are not being displayed. They just get skipped. But I see that the size of the image is smaller then the size of my device VRAM. Checked with this method with /dev/graphics/fb0: How to measure VRAM consumption on Android?. So my file size is 532,042 bytes, its dimension are 2160x1224 and my vram size is 3072000 bytes. Why this image is not being handled by the device? And what is the criteria and limit? How can I check the limit for a device?

Community
  • 1
  • 1
Narek
  • 38,779
  • 79
  • 233
  • 389
  • See http://stackoverflow.com/questions/26410799/portably-and-correctly-getting-maximum-1d-2d-3d-cube-texture-resolution-in-openg. – Reto Koradi Oct 25 '14 at 14:34

1 Answers1

2

Why this image is not being handled by the device?

Because there's a difference between how much can be placed in RAM and the maximum size of a single chunk of data that can be processed. There's a certain limit to each GPU on the maximum size of an image it can handle. The size of the RAM just tells you, how many images will fit there. However OpenGL's memory model is purely abstract and the amount of VRAM doesn't tell you anything about how many textures you can load. Data can and will be swapped in and out of VRAM whenever required. The actual limit is in fact the amount of memory available to your system as a whole.

I can't tell you for Cocos2D but in OpenGL and OpenGL-ES you can query the maximum sizes supported for various texture types using glGetInteger OpenGL-ES glGetInteger reference. In your case you're probably interested in the value GL_MAX_TEXTURE_SIZE. Note that for texture targets other than GL_TEXTURE_1D and GL_TEXTURE_2D different values must be queried.

datenwolf
  • 159,371
  • 13
  • 185
  • 298
  • This is completely true. I have just found out independently from your answer that `GL_MAX_TEXTURE_SIZE` is the limit, and my device has 2048, hence 2160x1224 is not being handled. But now I don't understand where this constraint comes? Is it pure opne-gl constraint? Why there is such constraint? – Narek Oct 25 '14 at 10:50
  • @Narek: Because the GPU simply cannot handle more. This is an implementation limit (other implementations may have completely different limits) and in most cases the limit is imposed by the capabilities of the hardware. The GPU in your device simply cannot deal with more. – datenwolf Oct 25 '14 at 12:28
  • It's a hardware limitation (GPU). Certain GPUs can only handle textures up to 1024x1024. Most support up to 2048x2048. The higher end (ie iPad 2 and above) can do 4096x4096. Same is true for all GPUs, not just mobile but also consoles and desktop computers. – CodeSmile Oct 25 '14 at 12:29
  • Guys but as I understand GPU should handle as much as VRAM size is, isn't it? – Narek Oct 25 '14 at 16:14
  • @Narek: No. VRAM is basically a cache for the GPU. But applying a texture involves a special kind of data processing, which is implemented by special hardware (texture fetch and interpolation unit TFIU) which (even on programmable GPUs) is a hardwired piece of silicon in current GPU designs. The design and implementation of this special piece of the GPU inherently limits the amount of pixels in a texture that the texturing unit can handle. If the TFIU has been designed with a limit of 2048 pixels in one dimension, then that's that. No way around it. – datenwolf Oct 25 '14 at 17:41
  • @Narek: This is very similar (but not identical) to how there's a certain limit on the size of a processor's registers (8 bit, 16 bit, 32 bit, 64 bits) and anything larger than what fits into the register can not be directly processed. Similar for GPUs. The TFIU has a certain size limit on what it can deal with. – datenwolf Oct 25 '14 at 17:43