Quote:

Yes, an issue with e5500 cored cpus, but not as big a deal as the e500v2's fpu.

> firmware updates are extra

That was ACube, not A-Eon.

> Efika level performance in real life.

This would depend on the amount of floating point code in one's particular real life. Tabor's integer performance per core should be about 4 times Efika 5200B's.

Quote:

Isn't Acube a partner with A-Eonkit for the Tabor?

[ Edited by redrumloa 09.10.2016 - 13:17 ]

>>> firmware updates are extra

>> That was ACube, not A-Eon.

> Isn't Acube a partner with A-Eonkit for the Tabor?

Yes, they are. That still doesn't mean A-Eon will adopt ACube's firmware update policy, does it?

> The releasedate should now be importent, to keep some momentum....

It's gotten a little bit nearer: https://www.youtube.com/watch?v=fMSvxQIfq2w

Quote:

Well, they always said they would focus on this once the X5000 was ready for delivery, and that is close, so...

It will be interesting to see how the whole issue of the P1022's spe fpu plays out.
In software specifically compiled for the A1222, no problem, BUT...

> It will be interesting to see how the whole issue of the P1022's spe fpu plays out.
> In software specifically compiled for the A1222, no problem, BUT...

A year later and Daniel "Daytona675x" Müßener posts "a good demonstration of why you must not mix FPU and SPE code as soon as floating point values are involved" (i.e. mixing as in SPE-compiled executable calls FPU-compiled library or vice versa):

https://www.facebook.com/daniel.mussener/posts/2086799091346527

Quote:

Daniel Müßener: "Note: VoxelNoid is barely playable (if shadowing is turned off it's okay) on the Tabor as of now, the Warp3D SI driver is simply doing to much stuff internally that involves FPU instructions and therefore constantly and frequently triggers the emulation.

My tests revealed that this is apparently due to FPU-register-based memcpy (when drawing vertex data and when uploading textures) and RGBA-color-format-conversions from packed uint32 to unpacked float[4] done using FPU code.
Hans has been informed, hopefully his time allows it to make the respective code more Tabor-friendly soon "

"Barely playable", and we are not exactly talking about Star Wars Battlefront 2.

And so it begins, the parallel development of both "normal" code and "franken-code", just to satisfy a small group of customers with a one-time-deal HW that will never see the sun again.

It makes so much sense that only Amiga makes it possible!





[ Edited by takemehomegrandma 03.01.2018 - 13:12 ]

VoxelNoid works fluently at 720p with all settings to max on my mdd g4 1.25 soooo...

Quote:

Oh yeah? But does it get anywhere near the spectacular count of 1075037508 FPS? LOL...
The issue described by Daytona will make porting for Tabor oh-so-more-funny for the devs.

Quote:


This comment has not aged well.

Quote:

I can see the future it seems.

sorry but i have to make a quick reply
tabor is not like a pi in performances just because a pi3 overkill it. the only good point of tabor is the pcie slot that the pi dont have.

just for, this is the imx6 board from freescale with arm cpu ... dont think you will have this performances on tabor

https://www.youtube.com/watch?v=N3QY74keH_E

ogre demo https://www.youtube.com/watch?v=foOm9OQ9IE8


about A-Cube and A-eon for the tabor ... are you sure than a-cube made the tabor or do something about?

[ Edited by tlosmx 04.01.2018 - 09:34 ]

Quote:

A day after the 31st December 2018 it will be the year 2019!!

I can see the future too !!!!!



Now tell me this weeks Lotto numbers and we might be onto something ;)

>> A-Eonkit will be selling a Raspberry Pi class motherboard

> tabor is not like a pi in performances just because a pi3 overkill it.

There are various Raspberry Pi models with CPUs ranging from 700 MHz single-core ARMv6 to 1.2 GHz quad-core ARMv8, where the latter should be over twice as fast as the former on per-core basis alone. So talking about "Raspberry Pi class" or similar without specifying the model doesn't make sense anyway.
Tabor is definitely way faster than all Raspberry Pi 1 models (700 MHz ARMv6). Regarding quad-core Raspberry Pi 2 (900 MHz, ARMv7 initially, ARMv8 in later revisions), Tabor should be faster on per-core base but is slower in SMP. Comparing against quad-core Raspberry Pi 3 (1.2 GHz ARMv8), one's as good/bad as the other on a per-core base, so Tabor obviously loses in SMP.

> this is the imx6 board from freescale with arm cpu

No, this is a board from FEDEVEL/VOIPAC with an ARM-based i.MX6 CPU from NXP :-)

> dont think you will have this performances on tabor

The i.MX6 used on the board is a quad-core, yes. Comparing the 1.2 GHz Cortex-A9 and the 1.2 GHz e500v2 on a per-core base, one's as good/bad as the other.

> are you sure than a-cube made the tabor or do something about?

As is well known, the Tabor has been designed by Varisys. Regarding the ACube connection:

"Working in cooperation with ACube srl, a beta test programme is about to commence"
http://www.a-eon.com/news/News_Release_A1222.pdf

...and there was this in 2013:

http://www.a-eon.com/news/14-12-2013.html
http://www.acube-systems.biz/news.php?id=127

...and this in 2015:

http://www.a-eon.com/PDF/News_Release_Summit.pdf
http://www.acube-systems.biz/news.php?id=135

Tabor is all Varisys and acube dint nothing . i was thinking the same about tabor that there was acube hands on it ... but no they at the end didnt nothing on that crappy.

about freescale or nxp ... we are speak now about the same company

about pi3 ... blender using the 4 cores on the pi is faster in blender bench compared the x5000-20 that use two cores . tested by me... pratically if you render something you will have same time on a 35 euro computer compared a 2300 euro computer :P

darkplace on SPE Linux on Radeonhd = 70 fps on Tabor if some one have better result because what i have is old pls post here it .Thanks

[ Edited by tlosmx 04.01.2018 - 18:21 ]

Quote:

Actually, I was under the impression that Acube was to develop the firmware for the platform.

Quote: I was thinking the same...but ..

[ Edited by tlosmx 04.01.2018 - 18:25 ]

Quote:

Its not really an issue for me, as Tabor holds no appeal for me.
But Acube would be the natural company for the T2081 laptop project to go to for firmware (after all, they've already been tapped for design work).

i can say sure yes about openlaptop and acube :)
i know many people involved in this project and for sure acube is involved


[ Edited by tlosmx 04.01.2018 - 18:46 ]

Quote:

Quote:

Quote:

So it's not all doom and gloom after all.

[ Edited by rob 04.01.2018 - 20:19 ]

> about freescale or nxp ... we are speak now about the same company ;-)

My point was that the board you mentioned was not from this company, just the SoC is.

> about pi3 ... blender using the 4 cores on the pi is faster in blender bench compared
> the x5000-20 that use two cores . [...] if you render something you will have same time

So the X5000/20 is about twice as fast per core as the Raspberry Pi 3. And as the X5000/20 is about twice as fast as Tabor, Tabor is about as fast per core as the Raspberry Pi 3. Just as I said :-)

> the T2081 laptop project

http://morph.zone/modules/newbb_plus/viewtopic.php?forum=11&topic_id=10318&start=104 ;-)

>> The issue described by Daytona will make porting for Tabor oh-so-more-funny for the devs.

> [...]
> So it's not all doom and gloom after all.

The comment you replied to was about the compatibility problems developers will have to cope with, not about speed (non-)issues. What does speed help when it's not working right, except that it'll crash and burn or show nonsense faster?

Quote:

Only if they are using SPE code. If you can get the same performance from Tabor as the Sam460 with standard FPU code then you may not have a need for special binaries.