I was a bit confused to find out that loading 20 Full HD RGB images on the Raspberry Pi 2 was too much for the available GPU memory of 256MB. Thinking that each image should only take up 6.95 MB. Then I took a look at the memory allocated on the GPU and each texture blob was taking up 13.9MB. Why is this happening? Is the ofPixels object also residing on the GPU? I always thought only the texture sits in GPU memory and the ofPixels object sits in system memory.
If the extra space comes from the ofPixels object, can I get rid of it if I just want to draw a texture to the screen?
(Yes, I can allocated more memory to the GPU but for this case its a really bad option for me)
I’m not sure about the memory but if you just need the texture but not the pixels, you can use:
this will load the image directly into the gpu and bypass storing the pixels on the cpu.
likewise, if you just need the pixels and not the texture, you can use ofLoadImage( … ) to load a file into an ofPixels object.
Unless doing a raw pixel operation or image resizing, we use ofTexture instead of ofImage.
(EDIT: Resizing means here raw image resizing,. If you want to draw a scaled image, you can still do that better with ofTexture)
Ah good to know, haven’t noticed that function yet. That is very very handy, thanks for the heads up.
So it seems that the Pixels object is definitely not loaded into the VRAM (wouldn’t make sense anyway).
But why is a texture taking up so much space then? I can’t really see a good reason why this is the case.
Without digging into it too much, maybe mipmapping is the culprit? Mipmapping allocates more memory to store scaled versions of a texture so that drawing at it different scales is (visually, I think) optimized
Right, thats a good point. Would tex.setCompression(OF_COMPRESS_NONE) disable mipmaps?
Atleast thats what I’m kind of getting from the description here, though it sounds a bit weird…
E: nvm there is a disableMipmap() function (https://github.com/openframeworks/openFrameworks/blob/master/libs/openFrameworks/gl/ofTexture.cpp#L928)
Apparently mipmaps are off by default anyway. So mipmaps don’t seem like the cause here.