[FFmpeg-devel] [FFmpeg-commits] Implement a SIMD version of emulated_edge_mc() for x86.

[Orphis]

On 08/02/2011 02:34, Daniel Verkamp wrote:
> On Mon, Feb 7, 2011 at 5:51 AM, Ronald S. Bultje<rsbultje at gmail.com>  wrote:
>> Hi Daniel,
>>
>> On Mon, Feb 7, 2011 at 2:18 AM, Daniel Verkamp<daniel at drv.nu>  wrote:
>>> On Mon, Jan 31, 2011 at 7:01 PM, Ronald S. Bultje<git at ffmpeg.org>  wrote:
>>>> Module: ffmpeg
>>>> Branch: master
>>>> Commit: 81f2a3f4ffcc6935b8b8ada4954700b3f333ae4f
>>>>
>>>> Author: Ronald S. Bultje<rsbultje at gmail.com>
>>>> Date:   Mon Jan 31 20:55:56 2011 -0500
>>>>
>>>> Implement a SIMD version of emulated_edge_mc() for x86.
>>> This crashes on a mingw-w64 build run on Win7 x64:
>> I'm not 100% surprised.
>>
>> If we want to continue to support win64, I need a win64 ssh login with
>> complete mingw64+mingw32 installed, and I need a fate system for each
>> also. Could you consider setting that up?
>>
>> As soon as I have a SSH login, I'll see if I can fix it. Almost
>> certainly, the v_extend_15 is>128bytes. Switching some instructions
>> or registers will fix it.
> I've been poking around at setting up a FATE box for Windows, but
> frankly the native compilation situation with mingw+msys is next to
> unusable (terribly slow configure/build, no package management, buggy
> headers) and Cygwin-hosted cross compilation speed is even worse
> (though it at least has some semblance of package management); I've
> been using a Linux-hosted cross compiler instead, but that doesn't
> allow me to run FATE directly, and remote exec with Cygwin sshd + key
> auth apparently doesn't play nice with Windows permissions.  I will
> probably work something out for FATE at least (doesn't matter too much
> if it's slow as long as I don't have to sit and watch it), but only
> when I get a large dose of patience some weekend.

I've been working with Ronald yesterday and provided him ssh access to a 
Windows 7 64bit computer I own.
I managed to find an environment that works using mingw-w64 for cygwin 
(as an external package to add to the path) and recompiled yasm under 
cygwin so it understands "cygwin" paths. The configure is painfully slow 
because of a known limitation of cygwin's "fork" under Win64. 
Compilation time is okay (I've seen better but well...). The binary 
built is a native Windows one and can't recognize Cygwin's paths. The 
configure options are : --enable-gpl --cross-prefix=x86_64-w64-mingw32- 
--arch=x86_64 --target-os=mingw32 --samples=/home/fate/samples 
--enable-memalign-hack

Then, I tried to run the fate test and some aren't properly working yet. 
For reference, I run it with : make fate TARGET_PATH=`cygpath -aw .`
TARGET_PATH override is to ensure that fate doesn't give cygwin paths to 
the ffmpeg binary. Works for some cases.
I'm still playing with the options so I might find a way to improve the 
situation. For example, the ffmpeg command doesn't recognize the 
printf-like glob passed as an input and many tests are failing because 
of this :

TEST    vsynth1-qtrle
diff: tests/data/regression/vsynth1/qtrle: No such file or directory
make: *** [fate-vsynth1-qtrle] Error 127
TEST    vsynth1-rc
diff: tests/data/regression/vsynth1/rc: No such file or directory
/cygdrive/d/Programming/ffmpeg/tests/fate-run.sh: line 125: 
/usr/bin/diff: Bad address
make: *** [fate-vsynth1-rc] Error 127

Then the other test seem to fail for a different reason, and I'm still 
looking for it !

> I don't really want to give out SSH access to my personal Windows
> desktop for security and performance reasons, but perhaps a VM on
> another machine could be set up.  On the other hand, it's probably
> more convenient for the developer to have his own VM in that case...
> If you are really unable to run one yourself, I can consider setting
> one up here.
>
> Thanks,
> -- Daniel Verkamp
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at mplayerhq.hu
> https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel