I see the previous poster mentioned around 3000 faces running with OK
speed.. i really don't understand that. although i'm using textures
and normals for my loaded quake 2 models, i get like < 1 FPS. Even if
I only load the vertex, texture, and normal buffers once, at model
loading time and i never refresh it during the main loop. I only
access the drawelements once each frame, still get a pathetic result.
When the judges test the applications, will they use the same emulator
used by us? OpenGL applications won't be test-able at all in my
opinion then. Or i am doing some serious mishandling of something, as
for me, 1 loaded quake 2 model ~ 500 triangles makes that <1 FPS
alone... Any feedback would be highly appreciated!
Thanks,
Gabor
On Feb 24, 3:19 pm, Digit <[EMAIL PROTECTED]> wrote:
> It is nearly impossible to give really meaningful equivalence numbers
> between a real device and the emulator runnign CPU.even something like the
> "BogoMips" reported by the Linux kernel is misleading (try "adb cat
> /proc/cpuinfo" to get it).
>
> to understand this, consider the following:
>
> while purely ARM arithmetic operations can be translated into x86 machine
> instructions with a rather fixed performance "ratio", things get murky
> quickly because:
>
> - conditional ARM instructions need to be translated into branching
> x86 instruction sequence, whose performance varies greatly depending on x86
> branch prediction.
>
> - any memory load/store in user programs need to be emulated through a
> software MMU, so a simple operation like "ldr r0, [r1]" (load in r0 the
> word
> at address r1), which normally takes a single ARM cycle is going to require
> at the minimum a hash table lookup and several indirect memory access in
> the
> generated x86 machine code (things get even worse in the case of a cache
> miss)
>
> - most branching ARM instructions require a hash table lookup to find
> the address of the generated code fragment of the target address. in case
> of
> a miss, you also need to generate the target address code before being able
> to run it.
>
> - when the generated code fragment becomes full, it is totally wiped
> and you start again from zero. very fortunately, the fact that most of the
> execution time is spent in the small Dalvik interpreter loop considerably
> reduces this occurence :-) We might not be so lucky when we implement
> precompilation or a JIT in the system.
>
> all of this means that the performance characteristics of the emulator are
> very different from a real device. And I have only been talking about the
> CPU.
> memory, flash and other devices have also widely different latencies and
> bandwidths anyway.
>
> now, regarding OpenGL: you should never use glReadPixels(), this function is
> bound to be considerably slow on any hardware-accelerated OpenGL
> implementation. GL is designed as a mostly write-only API, so use it like
> that...
>
>
>
> On Sun, Feb 24, 2008 at 1:03 AM, eugenk <[EMAIL PROTECTED]> wrote:
>
> > Thank you ! I think earlier that emulator uses my videocard hardware
> > directly. But now find sources and make sure that it is usual ARM. But
> > can you say, what will be approximately emulated ARM clock frequency
> > with my Athlon 3000 under Windows XP ? I think that real Android
> > hardware will use ARM with frequency not lower that 300Mhz. And I hear
> > about video-accelerator. Now, my application maximum complexity is
> > about 3000 non-textured triangles. I not know about QUAKE complexity.
> > But think, it is much great.
> > About code piece, that slows down. To speed up my application, I save
> > not changed OpenGL objects as a Bitmap. And then output saved picture
> > as a background. Unfortunately, Android native Bitmap is incompatible
> > with OpenGL format. So, to save picture I use the next method:
>
> > public static Bitmap SavePixels(int x, int y, int w, int h, GL10
> > gl)
> > {
> > int b[]=new int[w*(y+h)];
> > int bt[]=new int[w*h];
> > IntBuffer ib=IntBuffer.wrap(b);
> > ib.position(0);
> > gl.glReadPixels(x, 0, w, y+h, GL10.GL_RGBA,
> > GL10.GL_UNSIGNED_BYTE, ib);
>
> > int i,j,pix;
> > for(i=0; i<h; i++)
> > {
> > for(j=0; j<w; j++)
> > {
> > pix=b[i*w+j];
> > bt[(h-i-1)*w+j]=(pix&0xff00ff00) |
> > ((pix<<16)&0x00ff0000) | ((pix>>16)&0xff);
> > }
> > }
> > Bitmap sb=Bitmap.createBitmap(bt, w, h, true);
> > return sb;
> > }
>
> > It slows down in double cycle "for". So I interest, how it will works
> > on real Android hardware in comparison with emulator, running on
> > Athlon 3000 ?- Hide quoted text -
>
> - Show quoted text -
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[EMAIL PROTECTED]
Announcing the new M5 SDK!
http://android-developers.blogspot.com/2008/02/android-sdk-m5-rc14-now-available.html
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
