[vlc-devel] [PATCH v3] picture: align pictures on 64 bytes

[Rémi Denis-Courmont]

Maths don't work that way. If you add a multiple of 512 offset to a multiple of 16 pointer, you get a multiple of GCD(512, 16) = 16 pointer. Your plane is aligned to 16 bytes (or 32 bytes with the patch).

Le 12 novembre 2018 15:31:16 GMT+02:00, Steve Lhomme <robux4 at ycbcr.xyz> a écrit :
>On 12/11/2018 14:09, Rémi Denis-Courmont wrote:
>> No. The plane offset from the start of the buffer / the first plane 
>> will be a multiple of 512 maybe. But the plane alignment cannot be 
>> larger than the containing buffer alignment.
>
>I don't see a problem here.
>
>If you allocate a 4:4:4 1x1 pixels picture it's adjusted to 32x16
>pixels 
>internally. Your lines will be 32 bytes and you'll have 16 of them per 
>plane. Each plane will be 512 bytes after the previous one.
>If you allocate a 4:2:0 1x1 pixels picture it's adjusted to 32x32
>pixels 
>internally. The first plane is 1024 bytes big, the other two are 256 
>bytes big.
>
>(this wasn't true when we arbitrarily added the 2 extra lines)
>
>So with the current picture_Setup() was cannot go lower than 256 bytes 
>aligned for any planes. That's far more than the 64 bytes alignment
>lavc 
>requires on all planes.
>
>> So we should probably align the allocation to at least 512 for 
>> consistency. IMO we should align to page size and forget about the 
>> problem going forward, as we can probably never align beyond that.
>>
>> Le 12 novembre 2018 13:44:08 GMT+02:00, Steve Lhomme 
>> <robux4 at ycbcr.xyz> a écrit :
>>
>>     On 12/11/2018 11:59, Rémi Denis-Courmont wrote:
>>
>>         As far as I am concerned, the picture buffer could and maybe
>>         should be page-aligned anyway. The real question is what the
>>         plane and scan line alignment should be, which this patch
>>         leaves entirely open. 
>>
>>
>>     picture_Allocate() is called after picture_Setup() which aligns
>lines to
>>     at least 32 bytes. Then the amount of lines is also made a
>multiple of
>>     16. So all the planes are always aligned to 512 bytes.
>>
>>     >
>>
>>         Le 12 novembre 2018 11:48:25 GMT+02:00, Francois Cartegnie
>>         <fcvlcdev at free.fr> a écrit : Le 12/11/2018 à 09:39, Steve
>>         Lhomme a écrit : Code relying on AVX-2 (like dav1d) cannot
>>         work without an alignment of 32 bytes at least. Even avcodec
>>         has a requirement of 64 (likely to get at least 32 on all
>>         planes). So it's probably time to upgrade. picture_Setup
>>         ensures a horizontal alignment to 32 bytes and a vertical to
>>         16 bytes. So for all buffers allocated by the core, we have a
>>         size multiple of 512 bytes. Didn't we had an issue with some
>>         codec*filter*idontremember and anything 16 ? -- Envoyé de mon
>>         appareil Android avec Courriel K-9 Mail. Veuillez excuser ma
>>         brièveté.
>>        
>------------------------------------------------------------------------
>>         vlc-devel mailing list To unsubscribe or modify your
>>         subscription options:
>>         https://mailman.videolan.org/listinfo/vlc-devel 
>>
>>    
>------------------------------------------------------------------------
>>     vlc-devel mailing list
>>     To unsubscribe or modify your subscription options:
>>     https://mailman.videolan.org/listinfo/vlc-devel
>>
>>
>> -- 
>> Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez 
>> excuser ma brièveté.
>>
>>
>> _______________________________________________
>> vlc-devel mailing list
>> To unsubscribe or modify your subscription options:
>> https://mailman.videolan.org/listinfo/vlc-devel
>
>_______________________________________________
>vlc-devel mailing list
>To unsubscribe or modify your subscription options:
>https://mailman.videolan.org/listinfo/vlc-devel

-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20181112/25d5fe07/attachment.html>