25 Mar 2022, 20:49 by mar...@martin.st:
> On Fri, 25 Mar 2022, Lynne wrote:
>
>> 25 Mar 2022, 19:52 by bavi...@riscosopen.org:
>>
>>> +@ VC-1 in-loop deblocking filter for 4 pixel pairs at boundary of
>>> vertically-neighbouring blocks
>>> +@ On entry:
>>> +@ r0 -> top-left pel of lower block
>>> +@ r1 = row stride, bytes
>>> +@ r2 = PQUANT bitstream parameter
>>> +function ff_vc1_v_loop_filter4_neon, export=1
>>> + sub r3, r0, r1, lsl #2
>>> + vldr d0, .Lcoeffs
>>> + vld1.32 {d1[0]}, [r0], r1 @ P5
>>> + vld1.32 {d2[0]}, [r3], r1 @ P1
>>> + vld1.32 {d3[0]}, [r3], r1 @ P2
>>> + vld1.32 {d4[0]}, [r0], r1 @ P6
>>> + vld1.32 {d5[0]}, [r3], r1 @ P3
>>> + vld1.32 {d6[0]}, [r0], r1 @ P7
>>> + vld1.32 {d7[0]}, [r3] @ P4
>>> + vld1.32 {d16[0]}, [r0] @ P8
>>>
>>
>> Nice patches, but 2 notes so far:
>>
>
> Indeed, the first glance seems great so far, I haven't applied and poked them
> closer yet.
>
>> What's with the weird comment syntax used only in this commit?
>>
>
> In 32 bit arm assembly, @ is a native assembler comment character, and lots
> of our existing 32 bit assembly uses that so far.
>
>> Different indentation style used. We try to indent our Arm assembly to:
>> <8 spaces><instruction><spaces until and column 24><instruction arguments>.
>>
>
> Hmm, I haven't applied this patch locally and checked yet, but at least from
> browsing just the patch, it seems to be quite correctly indented?
>
> We already discussed this in the previous iteration of his patchset, and the
> cover letter mentioned that he had fixed it to match the convention now. (And
> even in the previous iteration, the 32 bit assembly matched the existing
> code.)
>
Oh, right, my email client mangled them.
All looks good to me then.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
