Repeating texture performance

[kkl]

I have two models (8 tris each) which has repeating texture (128x8). On top of that, I added a second texture (128x128) in Blend mode. When I use them, it slows my phone alot (android main UI). But when i remove that, and even added few animated 3d models with bones (~2000K tris total), and it looks completely fine and framerate is ok. I was just wondering if the repeating texture may cause performance in some cases.

[EgonOlsen]

Not sure...i actually don't see why it should. It might depend on the hardware of the device. Some gpus don't like certain things...maybe that's one of those. Have you enabled mip mapping for that texture?

[kkl]

Yes, I tried it with other texture with 64x64 and mipmap (the 128x8 shows nothing as mipmap requires to be square), it still slows down the main UI alot. My test device is s4. I think it's PowerVR GPU version with octa core. That's odd, I checked from other live wallpaper and they are using almost the same technique and they made it really smooth on my s4.

[EgonOlsen]

If they would do the same thing, the outcome would be same. Rendering such a plane is gpu only. Mipmaps don't need to be square, but 128*8 is indeed a strange format, so this might be an issue. Have you tried to make it square, apply mipmapping to it and try again?

[kkl]

Yes. I tried again using 32x32 image and enable mipmap. It still look slow. I even tried by fitting the UV map into the texture so it doesn't repeat the texture and removing the mask blending in second texture, and it's still the same. I haven't encountered this before and I'm completely puzzled with this. It should be a simple model with texture. I think there might be something else that cause it slow in certain cases.

[EgonOlsen]

Sounds strange. I don't see how a 8 polygon mesh can cause this regardless of the texture that it uses. Have you done some actual profiling of is this just a gut feeling?

[kkl]

I tried checking with method profiling and opengl es tracer. Both look ok with and without the object that cause it slow. Just that from opengl es tracer, sometime that object takes 1-2ms just to call the glDrawArray, more than the one with >100 poly with non-transparent texture. Sometimes, it just take ~0.345ms to draw.

However, i did further testing by checking the framerate I print out in onDrawFrame. When I keep scrolling the homescreen non-stop for awhile (I have removed the camera panning for the LWP), the reading shows these:

With that object: ~39-44 fps
Without that object + animated models + few static objects: ~53fps

If I don't scroll the homescreen, it is ~59fps for both cases. Very odd~

[EgonOlsen]

There sometimes is a slowdown in some apps, when the cpu has less work to do than the gpu, because that causes the cpu to clock down. Try to create a thread with an endless loop to keep the cpu busy to see if that is the "problem".

[kkl]

Yea. I created a thread and loop 10K of matrix invert() function. It does slow the UI abit, almost like the problem we're having. But the small model shouldn't take that much of CPU, should it?

[EgonOlsen]

No, that's not what i meant. If an app uses only a little of the CPU, the device may clock down. So what should actually be faster might turn out slower in the end.

[kkl]

I thought into another context. Sorry bout that. I created a thread again to have endless empty loop. It looks slow too. If it's clock down, when the object is removed and it should be slow as well, but it got good framerate when removed. I think I gotta track back my code from the very beginning to see what went wrong.

[kkl]

Hi Egon,

I was just wondering that it might relate to depth testing. The 3d model is placed in such a way that it spreads across the scene in z axis and gets really close to camera (with transparent texture). Do you think it might be the factor that causes the down performance caused by the depth testing or sorting?

[EgonOlsen]

No. But if it fills the screen (almost) and is transparent, it might simply be a fill rate issue.

[kkl]

Yes, it almost fills 80% of the screen and it's transparent. How does it get affected that way? Is there any workaround to fix this?

[EgonOlsen]

No. Mobile GPUs don't have that much fillrate. They usually work around this by doing tile based, deferred rendering. But this doesn't help for transparent polygons, so they have a larger impact on fillrate than opaque polygons that overlap.