[x264-devel] x264 Solaris

[Sean McGovern]

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

-----Original Message-----
From: Doug Jackson <ddjack59 at gmail.com>

Date: Sun, 9 Aug 2009 15:19:21 
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/0a828642/attachment-0001.htm>