[MPlayer-dev-eng] [PATCH] Replaced deprecated QuickDraw calls in vo_quartz

[Reimar Döffinger]

On Mon, Dec 15, 2008 at 04:59:24PM +0100, Gregor Riepl wrote:
> > It's a good idea to work on this in advance, before many users ask for
> > it. Also, this enables to use MEncoder in 64-bits mode, which is quite
> > cool since most codecs are faster when compiled in 64-bits mode.
> 
> is that true? i didn't measure codec performance, only that of fspp.

Mostly H.264, but 10 % should be realistic there.

> >> Why is this necessary? Does OSX 64 bit not support relocations _at  
> >> all_?
> >
> > Yes, it does, see this doc:
> > http://developer.apple.com/DOCUMENTATION/DeveloperTools/Conceptual/MachOTopics/Articles/dynamic_code.html#/ 
> > /apple_ref/doc/uid/TP40002528-SW2
> 
> the long answer is: this is not about relocations but about the code  
> model (see the next section in the documentation above).
> as long as the compiler takes care of loading data from elsewhere, you  
> don't have to care. referencing data directly from inline assembly is  
> much trickier, because you have to take care of the loading process  
> yourself. simple data values that are not more than 2gb away from the  
> instruction pointer are easy to load/store - just use (%rip).  
> everything else has to go through a global offset table, which is  
> again local and addressed rip-relative. i have no idea why apple chose  
> this implementation - maybe just to save on complexity. local and pic  
> addressing cover most use cases, so why bother?

Huh? That sounds like the completely normal process for 64 bit systems,
but that normally only applies to PIC/PIE code (rip-relative addressing
is just an attempt to make PIC not be uselessly slow in the worst-case).


> actually, there is more:
> mp3lib/decode_mmx.c
> but if i'm not mistaken, the fixes for this file are simple.
> there might be even more places to fix. so far, i've identified liba52/ 
> imdct.c, liba52/resample_mmx.c, libmpcodecs/vf_fspp.c and mp3lib/ 
> decode_mmx.c.
> here's a patch that should be portable (didn't test it yet though):
> --- mp3lib/decode_mmx.c	2008-12-04 03:26:17.000000000 +0100
> +++ mp3lib/decode_mmx.c.edit	2008-12-15 16:43:02.000000000 +0100
> @@ -258,2 +258,2 @@
> -	"pand   "MANGLE(one_null)", %%mm1\n\t"
> -	"pand   "MANGLE(null_one)", %%mm0\n\t"
> +	"pand   %4, %%mm1\n\t"
> +	"pand   %5, %%mm0\n\t"
> @@ -334,2 +334,2 @@
> -	"pand   "MANGLE(one_null)", %%mm1\n\t"
> -	"pand   "MANGLE(null_one)", %%mm0\n\t"
> +	"pand   %4, %%mm1\n\t"
> +	"pand   %5, %%mm0\n\t"
> @@ -367 +367 @@
> -	:
> +	:"m"(one_null), "m"(null_one)

I don't like it much because my compilation attempts on OpenBSD and
FreeBSD have made me painfully aware that gcc will mess it up most of
the time - using "m" constraints is simply a sure way to get the "could
not find a register in GENERAL_REGS" error in at least one gcc version
(unless you have less than 5 arguments + register clobbers total).
In addition I am not sure if the generated code properly uses
PIC-relative addressing, if not it will be slower.
Btw. libav* uses this code instead of what is on mangle.h:

> // Use rip-relative addressing if compiling PIC code on x86-64.
> #if defined(ARCH_X86_64) && defined(PIC)
> #    define LOCAL_MANGLE(a) #a "(%%rip)"
> #else
> #    define LOCAL_MANGLE(a) #a
> #endif
> 
> #define MANGLE(a) EXTERN_PREFIX LOCAL_MANGLE(a)

As you can see it does not think there is any reason to do anything
different unless you are building a library, if OSX indeed is different
FFmpeg needs to be fixed as well.

Greetings,
Reimar Döffinger