lardman said:
Adventus said:The floating point index seems a bit low, is it using doubles? Or without Neon?
Relative to the OMAP2, The integer and memory results are impressive.
According to this result table, the INT & MEM are about equivalent to a PIII @ 1Ghz + 133Mhz SDRAM.
Looks like its running without Neon. Those results are a bit to bad.
Yea, those Memory and Integer results at 900Mhz, are about equal to the PIII at 933Mhz
CODE
MEM INT
Pentium III (Coppermine) 933MHz 256 KB 4.587 5.374
Pandora 900Mhz 4.562 5.217
So those dhrystone MIPS results we have been using in the past seems to be backed up. The 1200 dhrystone MIPS @ 600Mhz -> 1800 dhrystone MIPS @ 900Mhz = PIII @ 900Mhz.
In other words, its we can say its a PIII in your pocketOfcourse, thats not taking in account the possible extra's gained from the NEON, DSP, And 3D ( when there are drivers
Some programs I have tried to build with q1-2008 would fail and never even build in the first place. These build options only apply to my 600MHz test. I don't know what Notaz's 900MHz setup was but his 500MHz results were pretty much exact to my 500MHz test results.
Larger L1 cache? All the platforms have 16/16KB L1, unless TI has been lying to us for some strange reason.Laurent said:Alas currently gcc does not support -mfloat-abi=hard which could bring some speedup when passing floats to functions.
As far as performance goes, I would say the speedup comes from larger L1 cache, the existence of an L2 cache and faster RAM. Basically the memory subsystem is better.
Skeezix: And for graphics complexity of the ST I agree, though I expect to see how Outcast handles hardware scrolling and border removal demos
)Exophase said:Larger L1 cache? All the platforms have 16/16KB L1, unless TI has been lying to us for some strange reason.Laurent said:Alas currently gcc does not support -mfloat-abi=hard which could bring some speedup when passing floats to functions.
As far as performance goes, I would say the speedup comes from larger L1 cache, the existence of an L2 cache and faster RAM. Basically the memory subsystem is better.
Skeezix: And for graphics complexity of the ST I agree, though I expect to see how Outcast handles hardware scrolling and border removal demos
My bad, I was thinking of the cache starved 940T
Erm... I will be REALLY surprised if that is true.Phawx said:
I've tried clearing those bits, as the manual says, but that didn't affect benchmark results. We might need to disable VFP while this is done, I haven't done that because VFP was already enabled. This also probably depends on math lib being compiled with VFP, I just used whatever compiler links by default with those flags.Adventus said:
If you have some code I'd be happy to run it for you.Exophase said:
But notice the bolded part. In the SGX RE thread the highest number according to the docs was 133MHzMWeston said:If I remember correctly, the SGX core has two ways to set its clock. It can be set to a fixed frequency of 96MHz or it can be a divided down frequency of the CPU clock. The legal dividers are 3, 4, 5 and 6. It's been a while since I looked that up but I think it's right.
The demos we saw in Texas were running at 500MHz with the SGX core at 166MHz which means they were using a divider of 3. Based on that, you can speculate which values would work for 600, 800 and 900 MHz.
From OMAP35x Applications Processor 2D/3D Graphics Accelerator (SGX)Exophase said:
i too seem to remember reading in some specs what Exophase has quoted here (MWeston's post), but when i tried to retrace the source, i came across the omap3530 (preliminary) datasheet (i believe already linked in this thread) which is clear on the subject (p.146, table 4-17, DPLL3 Clock Frequency Ranges, VDD2 OPP3):blu said:
