[Mplayer-dev-eng] release 0.18...
Nick Kurshev
nickols_k at mail.ru
Fri May 4 22:59:32 CEST 2001
Hello!
>> > 3. MMX YV12->RGB 16bpp on SMP P3 - bug should be fixed
>> Probably bug in kernel, since if code works on uniprocessor machines therefore
>> it's workable. IMHO, mplayer does not contain SMP specific features.
>> In this case you are able only find out way to avoid problem (suggestions and so on).
>>
>I don't know what this bug is about, but mpeg decoding spawns an extra
>process to do the decoding and thus there IS a difference to single
>processor systems ... the mplayer main process could reside on one
>processor and mpeg decoding on the other - where can I find information
>about this bug?
>
Sorry! I never used multiprocessor systems, but in general there can be only
several reasons from application side for such bugs:
>From Intel manual:
#IA-32 processors provide a LOCK# signal that is asserted automatically during certain critical
#memory operations to lock the system bus. While this output signal is asserted, requests from
#other processors or bus agents for control of the bus are blocked. Software can specify other
#occasions when the LOCK semantics are to be followed by prepending the LOCK prefix to an
#instruction.
other suggestions from intel:
#* To maintain system memory coherency When two or more processors are attempting
# simultaneously to access the same address in system memory, some communication
# mechanism or memory access protocol must be available to promote data coherency and,
# in some instances, to allow one processor to temporarily lock a memory location.
# * To maintain cache consistency When one processor accesses data cached in another
# processor, it must not receive incorrect data. If it modifies data, all other processors that
# access that data must receive the modified data.
# * To allow predictable ordering of writes to memory In some circumstances, it is important
# that memory writes be observed externally in precisely the same order as programmed.
# * To distribute interrupt handling among a group of processors When several processors
# are operating in a system in parallel, it is useful to have a centralized mechanism for
# receiving interrupts and distributing them to available processors for servicing.
I you sure about several processes on separate cpus then it's sorrowful story since it requires
special coding with using all recommendation of manuals or specially designed C compiler.
Best regards! Nick
_______________________________________________
Mplayer-dev-eng mailing list
Mplayer-dev-eng at lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/mplayer-dev-eng
More information about the MPlayer-dev-eng
mailing list