Babylon-warp

6th January 2006 01:39 UTC

Split screen multiprocessing?
Is it a good idea to implement a multiprocessing of avs in Winamp by splitting the display into two halves and sending each half to one of the processors ? wouldn't it be easier to program than the current multiprocessor model?

This would be great, at least for full-screen display.

JFASI

6th January 2006 03:50 UTC

Hm...That is a very good idea.

I think that that might be tad tricky to implement, but that is really a cool thought.

DrO

6th January 2006 18:20 UTC

but then between the two halves you'd need to make all of the effects blend over/interact/etc which would really over complicate things i believe. nice idea though

-daz

PAK-9

6th January 2006 19:12 UTC

aka Scan Line Interleaving, its an idea they first introduced with the 3DFX cards. For AVS it probably would be quite effective, but only on dual processor (or dual core) machines... and most computers aren't. There wouldnt be any particular benefit on a single core hyperthreaded cpu.

Warrior of the Light

6th January 2006 22:59 UTC

PAK, it could be an option like SMP support is now

Tuggummi

7th January 2006 04:26 UTC

Originally posted by PAK-9
dual processor (or dual core) machines... and most computers aren't.

JFASI

7th January 2006 15:00 UTC

Well, Intel announced a four core CPU by 2007. That look decent.

jheriko

13th January 2006 00:45 UTC

WotL: SMP support just passes a flag to apes saying they can use the SMP entry point. mostly APE developers dont use it
since the apes predated that feature, and rewriting afterwards is a pain. or, globmgr.ape for instance, there is no easy way to speed it up with multiprocessing since all it does is run evallib code.

evallib code infact pretty much rules out converting most of the existing components too, like superscope for instance, since each point can be depedent on the last through code, although it could speed up the renderer, the bottleneck is really the evallib stuff written in the preset so it wouldnt help.

on the other hand, convolution is a pretty obvious candidate for multiprocessing. its pretty trivial to split up the work for that one...

Babylon-warp

17th January 2006 14:01 UTC

In any case, you would want to have 2 exactly the same versions of the avs running on either processor, it's just that on one instance it only processes x=0-0.5 and the other instance processes x=0.5-1. all it has to do is map a function over half the area.

The other option is to have two different versions of avs working from the same algorithm, on either processor, just that the frames are alternated and merge on the way to the graphics card.

It's normally really easy to send information 2 ways at one end of a program and to merge it at the other end.

jheriko

4th February 2006 11:09 UTC

Don't let me stop you from making it... just don't come back crying when you realise the ACTUAL implications of what I said. I wansn't particularly clear last time so I will rephrase it into simple short statements.

AVS isn't slow because of its software rendering. (from experience and testing)

AVS is slow from evallib evaluation. (from experience and testing)

Evallib evaluation is roughly equivalent to running byte code. (easily inferred from viewing source code)

There is no general solution for splitting up byte code into chunks for running in parallel if you want a speed increase (experience, + heavily supported on internet)