[FFmpeg-devel] [PATCH] HAVE_AMD3DNOW

[Pavel Pavlov]

> -----Original Message-----
> > 
> > Well, did you try to use some diff viewer that could 
> colorize my patch 
> > so it doesn't look ugly? ;)
> 
> your patch is ugly no matter which color
> 

Did you try pink??


> 
> > Little sence for you, but HUGE difference for many ppl who 
> would like 
> > to be able to debug ffmpeg code with MS dev tools. Not that 
> there is 
> > need to debug somehting in ffmpeg, but often I'd like to 
> see what some 
> > function does. For example, instead of asking mailing list 
> or manually 
> > opening .c files and reading code to find out what 
> av_picture_fill (or 
> > any other function) does internally, allocates buffers, or 
> does X or 
> > Y, I step in with ms debugger and in 15-20 seconds I know 
> everything I 
> > need to know. Another example: with some function I 
> regularly get some 
> > warnings from av_log - in a minute or two I can figure out 
> why I get 
> > this warning. I can't imagine how one could be as productive with 
> > commandline tools as with ms ide.
> 
> so
> * you cant open a C file with a text editor
> * there is some problem (that you dont further care about) 
> with some 3dnow
>   instructions on some compiler
> * you can make sense of a function in ms ide in less time 
> than ms ide needs
>   to crash your box
> 

I don't get it, what is this list is about?
I agree that ms ide is not light, but so far I didn't find any text
editor that offers what ms ide has.


> > Moreover, I still find it quite difficult to get latest 
> up-to-date mingw
> > compiler for win32 with their list of install this, downalod that,
> > overwite this and modify that instructions. After doing all 
> that magic I
> > had doubts that hello world would still compile.
> 
> maybe you should write a simple and clean 1-click installer for mingw?
> 
> > To fix --disable-3dnow it would be enough no remove 
> references to _3dnow
> > functions, but it's not enough for icl, since it can't 
> compile most of
> > _3dnow asm code.
> > Initially, I put ifdef __ICL for all 3dnow code that did 
> not compile.
> > Obviuosly, it would never be accepted; so for all _3dnow 
> code I put #if
> > HAVE_3DNOW ... #endif which is much better. There is no 
> other way to fix
> > compilation with current icl.
> > And the last point... most of win32 developers can't 
> contribute much -
> > most of them who use ffmpeg have some version of ffmepeg 
> dll's and don't
> > bother with source code which is quite useless on win32, unless they
> > took extra effort to setup build environment for ffmpeg (which is
> > overkill for most of the projects that use like 1% functionality
> > available in ffmpeg)
> > 
> > > 
> > > If OTOH you want to fix --disable-3dnow, that may be welcome 
> > > though i obviously would prefer this to be done as clean as 
> > > possible. I dont know what is cleanest but simply not 
> > > referencing 3dnow functions and letting the compiler remove 
> > > them seems like an obvious try
> > > 
> > > Also, even with iccw 3dnow should be supported not just 
> > > disabled your patch is not a clean fix for this ...
> > 
> > I have no idea what iccw is, I'm talking about icl, which is intel's
> > compiler for win32.
> 
> iccw was my abbreviation for intels c compiler for windows, it seemsed
> to make sense and given intels compiler on linux does not 
> have that bug
> i felt a w for windows should be somewhere in there  but of course
> we can call it anything you like
> 

Well, I call it exactly as it's called. Icl
Intel compiler doesn't come as a standalone toolset without any
dependencies. It needs ms compiler on windows and gcc toolset on linux.
As far as I know it doesn't have it's onwn c/c++ std lib, it's only a
tool that converts c/c++ code to object files and then it uses host
compiler libs and tools to create final executables. On linux it uses
gnu assembler to handle inline asm and that's why it works as is on
linux. On win32 masm asm is used, so they wrote builtin assembler to
handle att asm. And that's why it's so contastrained: no lables, no
direct symbol references, some instructions aren't implemented etc.

> anyway, as said fixing --disable-3dnow is welcome if clean 
> (your patch is
> not)
> and making ffmpeg compileable on intels c compiler for 
> windows first needs
> an explanation of which instructions why do not compile. Once 
> we are past
> that we can discuss which solution (like disabling all asm) 
> is appropriate
>

Disabling all asm is not appropriate solution.
See my previous thread: [BUG] : reading memory past the end of the
buffer
At some point we started to get crashes (on some pc's/cameras only) with
code that worked for years and I decided to compile ffmpeg in my spare
time with icl to be able to debug the problem. It's not importat why and
what was crashing, the point is that it would never crash if asm
optimisations were disabled.
So, it would be nice to have a complete ffmpeg built with all
optimizations enabled. 
I don't know why icl doesn't support 3dnow; I don't think it has
anything to do with competing practices, most likely att asm wasn't high
priority (since it's not used on win32), and they just didn't implement
all instructions.
Icc tries to be completely gcc compatible on linux, icl tries to be
completely compatible with cl (ms compiler) on win32. icc and icl have
just as many differences between each other as cl and gcc; the
difference is that intel compiler on windows has better support for c99
and att asm; and that's what is needed in order to be able to compile
ffmpeg.