[x264-devel] x264 Solaris

[Doug Jackson]

Sean,

Thanks for the reply.

I was building with the gcc optimized for the Sun T1 'Niagara' (aka
CoolThreads) chip.  I don't have access to that machine any more though.  I
do have a couple of other SPARC machines that I might try.

Regards,
--Doug


On Sun, Aug 9, 2009 at 4:02 PM, Sean McGovern <gseanmcg at gmail.com> wrote:

> I don't have access to a SPARC myself. If that data is actually mis-aligned
> it is quite possible it needs to be fixed so that it is -- I don't think
> SPARCs, Itaniums or even PowerPCs are capable fixing up misaligned reads
> from memory as an x86 would (and my understanding is that the fixup does
> incur a performance hit).
>
> My error was different though -- something about an assertion about
> 'qscale' failing, and only if I apply gcc optimizations above -O2.
>
> Are you building with gcc or the Sun Studio compiler?
>
> -- Sean
>
> ------------------------------
> *From*: Doug Jackson
> *Date*: Sun, 9 Aug 2009 15:19:21 -0400
> *To*: <gseanmcg at gmail.com>
> *Subject*: x264 Solaris
> Hi Sean,
>
> Thanks for the posting about the x264 for Solaris 10 (x86).
>
> I tried compiling on Solaris 10 SPARC awhile back (several months) and
> remember having core dump issues when running.
>
> Here part of the thread:
>
>> A recent thread posted a fix for Bus Error on Solaris:
>>
>>> It seems the message was only sent to me and a few others, not to the
>>>
>>> ML.  Here it is.
>>>
>>> Dark Shikari
>>>
>>> Hello,
>>> the bs_init function has two bugs for non aligned  p_data pointer.
>>>
>>> I suggest to replace
>>>    s->i_left  = offset ? 8*offset : (WORD_SIZE*8);
>>>  s->cur_bits = endian_fix( *(intptr_t*)s->p );
>>>
>>> by
>>>  s->i_left  = (WORD_SIZE - offset )*8;
>>>  s->cur_bits = endian_fix( *(intptr_t*)s->p ) >> s->i_left;
>>>
>>> Mehdi MOSTAFAVI
>>>
>>> inline void bs_init( bs_t *s, void *p_data, int i_data )
>>> {
>>>
>>>   int offset = ((intptr_t)p_data & (WORD_SIZE-1));
>>>   s->p       = s->p_start = (uint8_t*)p_data - offset;
>>>   s->p_end   = (uint8_t*)p_data + i_data;
>>>    s->i_left  = (WORD_SIZE - offset )*8;
>>>   s->cur_bits = endian_fix( *(intptr_t*)s->p ) >> s->i_left;
>>>
>>> }
>>>
>>>
>>
>> I've tried the suggested solution, but still have the error.
>>
>> t2000-a# ./x264 -B1830 -o foo.264 /football_sif.y4m
>>> yuv4mpeg: 352x240 at 30000/1001fps, 4320:4739
>>> x264 [info]: using SAR=4320/4739
>>> x264 [info]: using cpu capabilities: none!
>>> x264 [info]: profile Main, level 2.1
>>> Bus Error (core dumped)
>>>
>>
>> And if I truss:
>>
>>> read(4, " F R A M E\n808080808080".., 8192)     = 8192
>>> read(4, " g p l N }FDFFFFDC r a t".., 8192)     = 8192
>>> read(4, " j i t z q g h q x r q v".., 8192)     = 8192
>>> read(4, " l j q j j m n j j o k i".., 8192)     = 8192
>>> read(4, " y w o v x y8FA98D i b t".., 8192)     = 8192
>>> read(4, " % % & # % & $ ( 6 1 8 i".., 8192)     = 8192
>>> read(4, " Z Z Z X X W P S O O I F".., 8192)     = 8192
>>> read(4, " n j w l c p p j d V T a".., 8192)     = 8192
>>> read(4, " } z | r w p r81 y t u81".., 8192)     = 8192
>>> read(4, " X o o i ` X a m j m d f".., 8192)     = 8192
>>> read(4, " s p t e j q7F x i c ` i".., 8192)     = 8192
>>> read(4, " y u } x y } b c d c b a".., 8192)     = 8192
>>> read(4, " a ` ` ^ ]___ ` a a_".., 8192)     = 8192
>>> read(4, "8A8C8D898A8D8D8D8D8B8A8A".., 8192)     = 8192
>>> read(4, "87858B89888988868A8C8E8D".., 8192)     = 8192
>>> read(4, "8A8D8D8F8F908C8D8C8E8E8F".., 8192)     = 8192
>>> brk(0x003DEC40)                                 = 0
>>> brk(0x003E0C40)                                 = 0
>>> brk(0x003E0C40)                                 = 0
>>> brk(0x003EAC40)                                 = 0
>>> brk(0x003EAC40)                                 = 0
>>> brk(0x003F2C40)                                 = 0
>>> brk(0x003F2C40)                                 = 0
>>> brk(0x0046EC40)                                 = 0
>>> brk(0x0046EC40)                                 = 0
>>> brk(0x0049AC40)                                 = 0
>>> brk(0x0049AC40)                                 = 0
>>> brk(0x004A0C40)                                 = 0
>>> brk(0x004A0C40)                                 = 0
>>> brk(0x004B0C40)                                 = 0
>>>     Incurred fault #5, FLTACCESS  %pc = 0x0009991C
>>>       siginfo: SIGBUS BUS_ADRALN addr=0x002BB62A
>>>     Received signal #10, SIGBUS [default]
>>>       siginfo: SIGBUS BUS_ADRALN addr=0x002BB62A
>>>
>>
>> When looking at bs.h and bs_flush, there is a comment about memory
>> alignment.
>>
>>> /* Write the rest of cur_bits to the bitstream; results in a bitstream no
>>> longer
>>>  32/64-bit aligned. */
>>> static inline void bs_flush( bs_t *s )
>>> {
>>>     *(intptr_t*)s->p = endian_fix( s->cur_bits << s->i_left );
>>>     s->p += WORD_SIZE - s->i_left / 8;
>>>     s->i_left = WORD_SIZE*8;
>>> }
>>>
>> Could this have something to do with the problem?
>> I'm a novice, so I'm afraid I can only report my experiences.
>>
>> # uname -a
>> SunOS t2000-a 5.10 Generic_137111-05 sun4v sparc SUNW,Sun-Fire-T200
>>
>> Regards,
>> --Doug
>
>
>  Any thoughts as to whether some of the work you have done addresses this?
> I know memory mgt is less forgiving in SPARC...
>
> Regards,
> --Doug
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/x264-devel/attachments/20090809/73b343cb/attachment.htm>