[vlc-devel] [vlc-commits] arm_neon i420 -> rgb: Output pitch can be 64 bit aligned

Rafaël Carré funman at videolan.org
Mon Dec 31 14:53:42 CET 2012


Le 31/12/2012 14:35, Rémi Denis-Courmont a écrit :
> On Mon, 31 Dec 2012 14:00:05 +0100 (CET), git at videolan.org (Asad Mehmood)
> wrote:
>> vlc | branch: master | Asad Mehmood <asad78611 at googlemail.com> | Mon Dec
>> 31 00:56:00 2012 +0000| [0740e5433637c12dab43067b964248b667cda19d] |
>> committer: Rafaël Carré
>>
>> arm_neon i420 -> rgb: Output pitch can be 64 bit aligned
>>
>> When an output picure is requested from a Samsung (exynos?) device
>> it is not guarateed to be aligned to 128 bit (4 pixels).
> 
> VST with 64-bits alignment is basically useless. IIRC, only 128-bits
> alignment brings performance optimizations over unaligned on Cortex A8.

Yeah unfortunately :/

>> Signed-off-by: Rafaël Carré <funman at videolan.org>
> 
> In current VLC, all planes must be aligned to 128-bits. Filters may fail
> if this is not true.

Hum.. that's right indeed. I should have seen this, perhaps I can't
compute correctly between bits and bytes (I knew we require alignement
on 16 bytes)

However in this case it is a hardware/OS provided buffer, and of course
Samsung people are full of crap to not provide that "standard"
alignement </Linus>

We could:
- check at runtime each picture for alignement and provide a slow path
without the need for 16 bytes alignement
- request a bigger buffer in the surface provider and black out the
rightmost pixels?
  if provided pitch % 16 is not 0, request a surface with width % 16 ==
0, but I'm not sure at which level of the vout pipeline we could black
out these pixels to not show pixels with random values..

In any case I doubt that in practice we're using another filter than
this one on android.

However of course hurting performance for other ARM builds just for
android is not nice.

I propose to wait a few days to see if we find another solution before
reverting this one.



More information about the vlc-devel mailing list