Are there performance benefits to having power-of-2 sized texture atlases?

[ForgeableSum]

Are there benefits to having power-of-2 sized texture atlases? In Canvas or webgl? Both or neither? When does it help and when does it not matter? I'm speaking specifically of power-of-2 sized texture atlases (e.g. 512 x 512 or 512 x 1024) for sprites with lots and lots of frames.  

 

What if the difference is something like 642 x 505 (not power of 2) vs 512 x 1024 (the same texture atlas converted to power of 2 by adding lots of blank space)? Is the performance benefit big enough to justify adding so much blank space?

 

 

I've searched and searched and can't find a meaningful answer to this question.

[wayfinder]

Some WebGL features are only available to power-of-2 sized textures. 

[AshleyScirra]

It's really about saving memory. Some GPUs only support square power-of-two textures (although I think this proportion is falling over time). If you make a 513x513 image, it could be bumped up to a 1024x1024 texture for storage and waste memory. Some WebGL 1 features like mipmapping and tiling also only work for power-of-two textures, although this restriction is lifted in WebGL 2.

[ForgeableSum]

Some WebGL features are only available to power-of-2 sized textures. 

Can you please elaborate? Which features and how do they apply to Phaser/pixi? I'm trying to figure out specifics here. Like, are there any performance benefits to having texture atlases for sprites that are power of 2?

 

 

It's really about saving memory. Some GPUs only support square power-of-two textures (although I think this proportion is falling over time). If you make a 513x513 image, it could be bumped up to a 1024x1024 texture for storage and waste memory. Some WebGL 1 features like mipmapping and tiling also only work for power-of-two textures, although this restriction is lifted in WebGL 2.

 

So if the texture in questions isn't tiled, does it fall to reason that there are no performance benefits? I'm really trying to figure out specifics here. 

[chg]

It's really about saving memory. Some GPUs only support square power-of-two textures (although I think this proportion is falling over time). If you make a 513x513 image, it could be bumped up to a 1024x1024 texture for storage and waste memory. Some WebGL 1 features like mipmapping and tiling also only work for power-of-two textures, although this restriction is lifted in WebGL 2.

I think this is misleading, I doubt you'll find a GPU that lacks support for NPOT textures (it is required for Open GL ES 2.0 for mobile, ie. it is supported wherever shaders are! And it give you an idea of desktop support, it's been required since Open GL 2.0 on desktop)

 

Some WebGL features are only available to power-of-2 sized textures.

NPOT textures are required for Open GL ES 2.0 and WebGL as per:

See: https://www.khronos.org/webgl/wiki/WebGL_and_OpenGL_Differences#Non-Power_of_Two_Texture_Support

The standard does not require GPUs to support Mipmaping, samplers other than nearest or linear, or wrap modes other than clamp (ie. sampling from outside the texture) with NPOT textures, though GPUs can optional provide more and many do (thus you may have to check if you need such features).

Also, I believe best practice is to have dimensions that are divisible by 32, you probably don't want a 513x513 texture - pad it to 544x544 instead. The extra memory won't be much, and it is possible it will be a very slight amount faster than entirely arbitrary sizes.

I think the above may apply to hardware accelerated 2d canvas implementations (atleast to some extent).

[ForgeableSum]

I think this is misleading, I doubt you'll find a GPU that lacks support for NPOT textures (it is required for Open GL ES 2.0 for mobile, ie. it is supported wherever shaders are! And it give you an idea of desktop support, it's been required since Open GL 2.0 on desktop)

 

NPOT textures are required for Open GL ES 2.0 and WebGL as per:

See: https://www.khronos.org/webgl/wiki/WebGL_and_OpenGL_Differences#Non-Power_of_Two_Texture_Support

The standard does not require GPUs to support Mipmaping, samplers other than nearest or linear, or wrap modes other than clamp (ie. sampling from outside the texture) with NPOT textures, though GPUs can optional provide more and many do (thus you may have to check if you need such features).

Also, I believe best practice is to have dimensions that are divisible by 32, you probably don't want a 513x513 texture - pad it to 544x544 instead. The extra memory won't be much, and it is possible it will be a very slight amount faster than entirely arbitrary sizes.

I think the above may apply to hardware accelerated 2d canvas implementations (atleast to some extent).

 

Thanks for the info. But I'm kind of looking for something more simple and in plain english. If I want to use both canvas and webgl, should my textures be power of 2? So NPOT is everything not power of two ... wait a minute, so there are benefits to not having power of 2? I am so utterly confused now. 

 

For desktop canvas/webgl Phaser implementations should my textures be power of 2 or not? If it's 642 x 505 (not power of 2) vs 512 x 1024, are the benefits still worth adding all the extra blank space? I really don't need to know the science behind it, I just want to answer that simple question. 

 

That's really all i want to know. 

[chg]

Thanks for the info. But I'm kind of looking for something more simple and in plain english. If I want to use both canvas and webgl, should my textures be power of 2? So NPOT is everything not power of two ... wait a minute, so there are benefits to not having power of 2? I am so utterly confused now. 

 

For desktop canvas/webgl Phaser implementations should my textures be power of 2 or not? If it's 642 x 505 (not power of 2) vs 512 x 1024, are the benefits still worth adding all the extra blank space? I really don't need to know the science behind it, I just want to answer that simple question. 

 

That's really all i want to know.

"Have dimensions that are divisible by 32" (*505 is not evenly divisible by 32)

[ForgeableSum]

"Have dimensions that are divisible by 32" (*505 is not evenly divisible by 32)

Okay so in Phaser the general rule is to have your texture dimensions be divisible by 32? Do you know how much of a performance boost this gives? Interestingly, I did a google search and couldn't find anything about this. 

[chg]

Okay so in Phaser the general rule is to have your texture dimensions be divisible by 32? Do you know how much of a performance boost this gives? Interestingly, I did a google search and couldn't find anything about this.

You complained when you got a detailed explanation that you didn't need to understand the "science", suffice to say I don't feel compelled to provide further explanation. As for performance, expect the differences to be negligible.

[ForgeableSum]

You complained when you got a detailed explanation that you didn't need to understand the "science", suffice to say I don't feel compelled to provide further explanation. As for performance, expect the differences to be negligible.

I apologize if it seemed like I was complaining - that was not at all my intention. And I do appreciate you taking the time to answer my question. 

 

I think I'm going to leave me textures at their natural size since the difference is negligible. If I did go to power of 2, it would mean making the image 150% larger. Although most of it would be alpha (and therefore, it wouldn't add to file size much), it's still annoying to have all that blank space in the texture. 

[stupot]

In the olden days, GPU microcode was optimised for speed, the maths for sub-sampling a texture is much simpler and quicker if the dimensions are POT.  And in the olden days, there was a great need to boast about pixel pushing power to sell gfx cards.

 

Nowadays, even slow GPU's are beasts by comparison and there is widespread support for NPOT textures, even if they are resized to be POT under the hood.

 

So there is a performance gain for going with POT, although this will vary greatly.  Also there are some grumpy browsers out there that misbehave with NPOT textures.  The max texture size supported will always be a POT.

 

The downsides for upsizing to a POT texture for source images is that your byte count will be higher so it will take longer to download and unpack and may have a higher memory footprint to do this.