[Ffmpeg-devel] Re: [PATCH] SIMD accelected SNOW decoding
Guillaume POIRIER
poirierg
Mon Nov 28 23:16:04 CET 2005
Hi,
On 11/28/05, Guillaume POIRIER <poirierg at gmail.com> wrote:
> Hi,
>
> On 11/28/05, Guillaume Poirier
> <guillaume.poirier at etudiant.univ-rennes1.fr> wrote:
> [..]
> > Ok, by bad; that had absolutely no chance to work whatsoever . I had
> > broken the register name while converting the IA-32 style regs to AMD64
> > style regs.
> >
> > Please find in attachment the updated untested ASM. If someone could
> > test it on AMD64 64bit mode during the day, that would be most appreciated.
>
> Tested, it still doesn't work (I get a grayish picture, then a segfault).
commenting out _just_ vertical_compose97i_asm in snow.c give me a
correct picture but a segfault while commenting out _just_
inner_add_yblock_mmx in snow.c gives me a grayish picture but no
segfault. Cool, 2 bugs for the price of one! :)
The segfault lies in inner_add_yblock_mmx, and is the same as the one
I ran into earlier (which is not surprising I imagine), i.e it failled
on after those instructions:
disasm:
0x00000000006b0a4f <decode_frame+11759>: paddusw %xmm3,%xmm6
0x00000000006b0a53 <decode_frame+11763>: mov
0xfffffffffffffde8(%rbp),%rdx
0x00000000006b0a5a <decode_frame+11770>: movdqa (%rdi),%xmm3
As I'm an absolute SIMD illiterate, I can't figure out if this
segfault could be due to an illegal memory access (wrong address) or
if the problem could be an unaligned MOVDQA exception.
here is what a 'info registers' give me:
(gdb) info registers
rax 0x7fffffab20e0 140737482793184
rbx 0x4 4
rcx 0x2f0 752
rdx 0xcfdaac 13621932
rsi 0x7df0c0 8253632
rdi 0xad73ba9000002aba -5948205555188225350
rbp 0x7fffffab21b0 0x7fffffab21b0
rsp 0x7fffffab0940 0x7fffffab0940
r8 0x0 0
r9 0x8cafa26d5fef5 2474975555878645
r10 0x81 129
r11 0x8100 33024
r12 0x2aaaad3f3720 46912539408160
r13 0xc47d70 12877168
r14 0x0 0
r15 0xc47d7a 12877178
rip 0x6b0a5a 0x6b0a5a <decode_frame+11770>
eflags 0x10282 66178
cs 0x33 51
ss 0x2b 43
As you can see, the value of rdi can't point to an memory address
aligned to the quadword boundary (at least, that's how it looks to me,
maybe the problem is not there as the value 0xad73ba9000002aba my just
be bogus)...
Does anyone have an idea of what could be done to fix that code?
Guillaume
--
MPlayer's doc is offline. Find some fresh one here:
http://tuxrip.free.fr//MPlayer-DOCS-HTML/en/
http://tuxrip.free.fr//MPlayer-DOCS-HTML/fr/
More information about the ffmpeg-devel
mailing list