www.jpct.net
jPCT-AE - a 3d engine for Android => Support => Topic started by: kkl on May 11, 2014, 04:47:50 pm
-
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.
-
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?
-
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.
-
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?
-
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.
-
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?
-
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~
-
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".
-
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?
-
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.
-
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.
-
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?
-
No. But if it fills the screen (almost) and is transparent, it might simply be a fill rate issue.
-
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?
-
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.
-
I resized the objects so it doesn't fill up the screen and it gets alot smoother! But it gets abit slowdown occasionally when I scroll homescreen really fast for some time. At least the issue goes away nw. Wonder how other live wallpaper does so well despite of this issue.
-
...by using less fillrate?
-
Do you have any recommendation to reduce the fillrate other than reducing the texture size?
-
Texture size has almost no impact on fillrate. Fillrate simply depends on how much you draw on the screen, how much overlap you have and how much of this comes from overlapping transparent polygons.
-
Hi Egon, sry having to bring this up again. I checked from forum and many people are saying that transparent object are the most expensive process for fillrate, but I don't quite sure how transparent object would affect the fillrate, in technical speaking. Hope I can hear more about it from you.
From what i can understand, the more transparent part fills up the screen, the more hardware cost it would be. Is it caused by the z buffer where it checks the z buffer and rewrite again, or something else?
Say, if I put a all transparent objects at background (they takes almost more than half of the screen), and leave the opaque 3D objects at front, does it help in fillrate?
-
Mobile gpus are optimized for reducing overdraw of opaque polygons. They do this by using an approach called tile based rendering/deferred rendering. If you want to know more about this approach, just google for it or search the forum. IIRC, i briefly explained the idea once.
This doesn't help for transparent polygons and they require a framebuffer read per pixel in addition. Both things combined roughly explain the higher fill rate need of transparent polygons. If that's any better in the situation that you described depends on the gpus and maybe the drivers. I wouldn't expect too much from it.
-
Hi Egon,
Thanks for the idea. I spent a good amount of time to study the deferred rendering. It seems like it will skip drawing/processing the polygon that is located behind any opaque polygon to improve performance, CMIIW. What if the polygon is partial opaque and transparent (say, an object with opaque at the center and a small portion of transparent area around its sides)? Does it defered if most area of texture is opaque or it simple treats it as all transparent?
-
My guess is that it treats them as transparent.