FIXED: .gpuMemory inconsistencies 088, 099

There seem to be some GPU memory reporting problems.

An 8bit RGBA render 4x AntiAlias 1920x1080 render is being reported to use 63.28 MB in 088 while 21.75 in 099. Both by middle clicking (view info) and by using .gpuMemory member. In 099 the figure doesn’t change when changing to 1x AntiAlias. In 088 it goes down to 21.75 but I’m pretty sure 099 is accurate for 4x while 088 is not.

There are also other issues with .gpuMemory member it seems. Selects and switches are reporting their instanced texture’s memory. Middle clicking on a select reports 0 MB while using .gpuMemory reports the same number of MB it’s selecting.

Again both 088 and 099 are displaying different figures…

These are all 1920x1080 8 bit RGBA TOPs with the renders set 4x antialias.

Not the biggest issue but I though it would be good to report it.

Builds 088.62510 and 099.2017.4060.

cheers
Keith

I’ve been getting this too…I thought maybe the guys had some some magical thing where anti-aliasing somehow didnt use up any more gpu memory :laughing:

I’ve fixed the memory usage calculation being incorrect in 099 (088 was correct). I’m unable to reproduce the issue about instanced TOPs showing incorrect amounts though. gpuMemory and the popup dialog get their numbers from the same place so they should always be the same.

Ah that’s good news. Thanks Malcolm. Just curious about the render size. Would a 1x anti-alias render not be 1 texture buffer? So if it was 1920x 1080 8bit RGBA would it not be:

1920 * 1080 * 4 * 8 = 66,355,200 bits / 8 / 1024 / 1024 = 7.91 MB

Which is what TOPs such as the cropTOP or the glslTOP report?

thanks
Keith

Yes but there may be a 2nd buffer which is the output texture (vs. the render target), and you need the depth buffer as well.

Ah right. I figured I was missing something. thanks.