I'd like to ask the developers how hard it would be, how much work involved, how many things would have to be changed to support more than one processor.

Second, what if we avoid making the whole OS use a 2nd processor and just provide a way for app developers to use mcpus if they are willing to take the time to reprogram their apps?

No burden to reprogram the whole OS or provide backwards compatibility.



Can it be done?

> what if we avoid making the whole OS use a 2nd processor and just provide
> a way for app developers to use mcpus if they are willing to take the time to
> reprogram their apps? [...] Can it be done?

https://morph.zone/modules/newbb_plus/viewtopic.php?topic_id=9204&forum=11&start=1

Quote:

Read Krashan's posts from https://morph.zone/modules/newbb_plus/viewtopic.php?forum=11&topic_id=6465&viewmode=flat&sortorder=0&start=60

The idea is there.Maybe a bounty for ASMP could actually move things.

Zylesea,
Quote:

I'm ready to donate. Everything except my laptop is dual processor.

quote:
> Could somebody show me a MorphOS app, which doesn't runs well on
> a 1.5 GHz processor and really needs the dual core supported?

You could try playing a 1080p video with MPlayer.

unquote:


I saw this in that thread you linked.
The app I am thinking of is called b.o.c.h.s.
It needs all the speed it can get.

Quote:

Even thought I lack multicpu morphos machine I would donate some bucks

Krashan should be asked first as I guess he's the one who may be interested... something like:
-Implement asymetric multi core support in MorphOS 3.x performing required changes to Exec/DOS and the rest of the OS
-performing the required changes to libnix/ixemul to make easier supporting various cores. Perhaps modifying CISC libpthread to support the new MProcess... he's the one who decides.
-Provide developer docs and examples (a reggae class perhaps?)

maybe as part of the bounty providing a bigger app (or game?) of his choice to prove that the implementation is more or less useful: MPlayer (for codecs that support various cores or perhaps performing some parts of the rendering), Blender, OWB (running javascript core for example)... I don't know. I think that providing a "bigger" app (or game) would help to increase the number of donations as people would notice an inmediate benefit in the completion of the bounty. Perhaps it should be a second bounty.

@Krashan: if you are reading this please reply and tell us what do you think and what would be the minimum you require. Perhaps setting some smaller goals: If bounty reaches X€ I will implement AMP, if it reaches X*2 € I will also adapt XYZ system component to use various threads (reggae or cairo.library for example), if it reaches X*4 I'll adapt OWB and MPlayer (and perhaps share a part with Fab)

@Crumb

please reply and tell us what do you think and what would be the minimum you require

The cash is not a problem here. The problem may be my lack of knowledge especially about Quark internals and basics of Exec. While I have some sketched ideas, I may simply be not aware of serious obstacles. Said that it is clear that implementing assymetric multiprocessing would require cooperation with other team members, especially those with needed knowledge and source code access. Some of them may be not convinced that AMP is a good idea, when one considers that CPU architecture switch will be unavoidable in the future. While AMP may be designed in a way making it forward compatible with hypothetic SMP of "nextgen" MorphOS, it still may be considered pointless temporary complication.

Remember that the base I would need is that extra processors/cores have basic setup done by Quark. They will need a MMU map consistent with the map of the primary processor. There are also many more details of PowerPC processor initialization. Then Quark has to launch the main code loop on each extra processor. Basic IPC primitives (signals, semaphores) must be verified to be multicore safe. Only having that one can proceed further implementing process scheduler for secondary cores, load balancer and set of API-s needed.

All this would require significant amount of work not only from me, but other team members. Some of them may consider it a waste of time.

Also one has to live with the fact that libnix and especially ixemul will probably never be made to use multiple processors, at least it would require some serious rewrite. As I use neither of them in my projects, I'm not really motivated to dive into this mud.

Taking it all into account and adding the fact that I have several projects in progress, rushing a bounty now may be premature.

@Krashan

thank you for your prompt reply, please let us know in the future if you (and other members) have time and interest to implement AMP.

I guess a lot of us thought too lightly of the task.

Here's just a thought: would it be simpler to make a program access the unused processor exclusively? If the system use one processor, and another program (like MPlayer) the other it should free up some extra power right?

I guess this has already been thought about but, I would like to be enlightened

Quote:

The application is using system components, which are used/modified by the other cpu. You would need mechanisms to keep data intact and this is not possible without loosing compatibly with all applications out there.

Even "just" using mplayer decoders with a second cpu is not as easy as it sounds. Where are the datas coming from? Where do they go after being processed? This is more complicated than it looks.

Geit

@geit

I guessed as much. But in my non-programmer logic it sounded like you could "just" take the same data and ask it to be processed somewhere else. I guess I was wrong again

I wonder if anyone other than Ralph has much knowledge about Quark.
Bigfoot was supposed to have had to make some changes for the G5, so a few others must.

hmmmmmmmm...
Could you run two copies of MOS, one on each CPU and talk to each other?

Hello!

Quote:

...I get that in mind too...

Amigalement!

Quote:

One higher instance must be present to control shared resources like RAM, bus access etc. On modern processors this may be done in silicon (hypervisor), but on G4 or G5 this would be done in software. I guess Quark could do that, but I also guess it's quite some work to make that actually happen.

> One higher instance must be present to control shared resources like RAM, bus
> access etc. On modern processors this may be done in silicon (hypervisor), but
> on G4 or G5 this would be done in software.

The PPC970 CPUs themselves have hypervisor capability (inherited from POWER4 which was IBM's first hypervisor-enabled CPU) but which is disabled on Apple's G5 machines via OpenFirmware (and cannot be re-enabled). I suspect this may have been due to a deal with IBM so that IBM's server customers wouldn't even consider buying cheaper Xserve G5 instead.

Quote:

Are you absolutely certain it can't be re-enabled Andreas?
That would make multiprocessing easier.
Its obviously still possible without it, but having something supervising both cores would be very handy.

Edit - Yet another dumb question answered by research. Apparently it can't be (unless its possible by completelly replacing Open Firmware - and how would you do that?).

[ Edited by Jim 20.06.2013 - 00:19 ]