Advertisement

GLSL efficiency issues about different sizes of texture

Started by November 25, 2013 12:41 PM
4 comments, last by nowubeing2 10 years, 11 months ago
Hi there,
We got some issues using GLSL developing Html5 apps. In a word, different sizes(power of 2) of textures resuilt in different execution efficiency.
In this DEMO, when Mickey Mouse is displayed, FPS will be sharply decreased. Because Mickey Mouse is a 2048*2048 texture and displayed in 128*128. All the other pics are 128*128 texture. 128 texture can be displayed more than 10000 times, while 2048 texture less than 500.
We made the same test in C++ and JAVA using opengl es 2.0, and we don't get this problem.
Could you please tell us the reason and give us some suggestions about how to improve execution efficiency using GLSL?
Thanks

I have no html5 experience, but with OpenGL I would expect performance to be unaffected by texture size, on condition that you are using mipmaps. Have you generated and enabled mipmaps for the 2048x2048 texture?

Advertisement

I have no html5 experience, but with OpenGL I would expect performance to be unaffected by texture size, on condition that you are using mipmaps. Have you generated and enabled mipmaps for the 2048x2048 texture?

No, we haven't(generated or enabled). All textures are level 0.

part of source:
this.newTexture = System2D.prototype.gl.createTexture();
System2D.prototype.gl.bindTexture(System2D.prototype.gl.TEXTURE_2D,this.newTexture);
System2D.prototype.gl.pixelStorei(System2D.prototype.gl.UNPACK_FLIP_Y_WEBGL, true);
System2D.prototype.gl.pixelStorei(System2D.prototype.gl.UNPACK_PREMULTIPLY_ALPHA_WEBGL, true);
System2D.prototype.gl.texImage2D(System2D.prototype.gl.TEXTURE_2D,0, System2D.prototype.gl.RGBA,System2D.prototype.gl.RGBA, System2D.prototype.gl.UNSIGNED_BYTE, v_image);
System2D.prototype.gl.texParameteri(System2D.prototype.gl.TEXTURE_2D, System2D.prototype.gl.TEXTURE_MAG_FILTER, System2D.prototype.gl.LINEAR);
System2D.prototype.gl.texParameteri(System2D.prototype.gl.TEXTURE_2D, System2D.prototype.gl.TEXTURE_MIN_FILTER, System2D.prototype.gl.LINEAR);
System2D.prototype.gl.bindTexture(System2D.prototype.gl.TEXTURE_2D, null);

I have no html5 experience, but with OpenGL I would expect performance to be unaffected by texture size, on condition that you are using mipmaps.

This^^

Without mip-maps, then if you're displaying a 2048 texture at a size of 128 pixels, then you're only using 1/16th of the data in each axis (or 1/256th of the data in total).

the GPU has to read 1 texel, skip 15 texels, read 1 texel, skip 15 texels....

This is really bad for cache coherency. The GPU is not built to read lots of small pieces of individual data -- it much prefers to read large pieces of data. When it is asked to read one single texel from RAM, it will not just download that one single texel into the cache -- to save time, it will download (as an example, say) a 4*4 area of texels into the cache.

If you enable mip-maps, then the GPU has available to it, many versions of your texture: a 2048, a 1024, a 512 etc, etc...

In this case, the GPU will instead choose to use the 128 sized mipmap, and it will regain cache efficiency.

I have no html5 experience, but with OpenGL I would expect performance to be unaffected by texture size, on condition that you are using mipmaps.

This^^

Without mip-maps, then if you're displaying a 2048 texture at a size of 128 pixels, then you're only using 1/16th of the data in each axis (or 1/256th of the data in total).

the GPU has to read 1 texel, skip 15 texels, read 1 texel, skip 15 texels....

This is really bad for cache coherency. The GPU is not built to read lots of small pieces of individual data -- it much prefers to read large pieces of data. When it is asked to read one single texel from RAM, it will not just download that one single texel into the cache -- to save time, it will download (as an example, say) a 4*4 area of texels into the cache.

If you enable mip-maps, then the GPU has available to it, many versions of your texture: a 2048, a 1024, a 512 etc, etc...

In this case, the GPU will instead choose to use the 128 sized mipmap, and it will regain cache efficiency.

And it'll look better too.

Mipmaps are great. Massive performance boost+major visual quality improvement all for the cost of just 33% more memory than the unmipped texture.

I have no html5 experience, but with OpenGL I would expect performance to be unaffected by texture size, on condition that you are using mipmaps.

This^^

Without mip-maps, then if you're displaying a 2048 texture at a size of 128 pixels, then you're only using 1/16th of the data in each axis (or 1/256th of the data in total).

the GPU has to read 1 texel, skip 15 texels, read 1 texel, skip 15 texels....

This is really bad for cache coherency. The GPU is not built to read lots of small pieces of individual data -- it much prefers to read large pieces of data. When it is asked to read one single texel from RAM, it will not just download that one single texel into the cache -- to save time, it will download (as an example, say) a 4*4 area of texels into the cache.

If you enable mip-maps, then the GPU has available to it, many versions of your texture: a 2048, a 1024, a 512 etc, etc...

In this case, the GPU will instead choose to use the 128 sized mipmap, and it will regain cache efficiency.

thank you for your help!However, we are using this only in 2D games, not 3D. We just make the full clip(u,v,x,y) of 2048 texture and scaled it in 128.Knowing that 2048 texture should be less efficient than 128, but the difference is too big. We think it is something special only in WebGL, but not for sure~

This topic is closed to new replies.

Advertisement