Search results

I have neither OMAP4 HW or specific information (which I probably couldn't share anyway) :( Anyway even if the AXI interface between A9 and PL310 was at full speed (A9 frequency) then 9 cycles isn't doable. I'll e-mail him, that will be faster :) EDIT: Mans kindly made more tests on his...

The test methodology is probably broken, as the number for OMAP4 looks too low (see this and keep in mind this is what happens in pl310, so this doesn't take into account A9->PL310 and PL310->A9 added latencies). Seeing he claims L2 miss on Tegra is 43 cycles, he probably ran some lmbench test...

I'd be surprised if the board really needed that much power. C-A9 shouldn't require much more power than C-A8. Of course there are two of them... I wonder if the rest of the SoC consumes much more. Also IIUC the OMAP4 on Pandaboard are engineering samples, which means they are not yet tuned.

These are not real figures, but rough ones to compare the benefits of using a L2 vs not using one. The L1 typical access time of 1-2 cycles proves this as you never get a 1 cycle access time out of d$. Look at this for L2 latency as measured on Tegra2...

One quick note: Cortex-A8 and Cortex-A9 don't share any RTL except for the NEON unit and even so the NEON ld/st don't behave the same. So don't assume anything about Cortex-A9 based on your Cortex-A8 experiments :) In particular a NEON memcpy won't be faster.

Oh I won't blame you for your approach, I'd do the same :) I just wanted to point you to something that might ease your dev. BTW the MIT license is one of the least restrictive license, it doesn't require you to release source code.

Why don't you use an already implemented and hopefully well-tested library for your transformations? For instance: http://glm.g-truc.net/

One should be cautious: there's not a single set of flags that works equally well for all projects. In particular -Os is *very* suspicious :)

I forgot to say that the OpenGL ES 2.0 Programming Guide book contains vertex and fragment shaders that replicate the fixed pipeline of ES 1.1.

I'm a complete newbie too :) So I'm just accumulating some random links about OpenGL ES 2 and modern OpenGL (that is OpenGL without usage of the fixed pipeline). Tracking iPhone dev might be interesting too. math libs to replace OpenGL matrix stuff: GLM...

Hello, while learning modern OpenGL (ES 2 or not), I found it handy to update 3Dlabs ShaderGen that reproduces some of the fixed pipeline functionality using shaders. Here is my quick hack. It replaces the source directory found in ShaderGen source package. I tested it using Mesa 7.8.2 on a...

I'm toying with what I have. If I had a Pandora, I'd target it, but I don't see the point wasting my time trying to support a platform I don't own.

I decided to buy the sources. But that doesn't mean a Pandora port since I don't own one. I'll probably play with it for Tegra2 and OpenGL ES 2.0 instead :)

I think that TI changed the way they do things late in OMAP3 dev cycle, they are now much more open than they used to be; they've always done software for their chips, some of them being of very high quality, but they were for customers only.

That's the reason why I provided results on real x86 machines using 2.96, look here. As far as the memory score goes it's partly due to the way QEMU translates rep-prefixed instructions. I changed that for some other project.

The OS could turn off VFP/NEON and there's nothing a user app could do to regain access if the OS doesn't cooperate. But why would an OS do that? Can't say, but I've seen more stupid things :P

That's vague indeed, but on what do you base your expectation that P90 speed isn't possible? Current QEMU should be at about this level except for floating-point and unless the devs broke QEMU on ARM, since my major speedups were integrated into QEMU before I stopped working on it. I agree an...

Random things: - QEMU can now use KVM or Xen to avoid having to translate code (of course this means you run for instance x86 on x86) - QEMU on ARM can reach the speed of ~K6 @100 MHz (see here) - having the Wine libraries compiled as x86 libs isn't the way to go :) - Wine on x86 has...

I think this was an Athlon XP @ 2GHz: http://www.3dfxzone.it/enboard/topic.asp?TOPIC_ID=1462 That CPU certainly is more powerful than Cortex-A8.

Yes, that's more or less the story. And at about the same time some MAME dev's decided to create SDLMAME, so there really was little point in putting any effort in XMAME.