[Mesa-dev] [PATCH] anv: change BLOCK_POOL_MEMFD_SIZE to exactly 2GB

[Tapani Pälli]

On 03/08/2017 08:05 AM, Tapani Pälli wrote:
> On 03/07/2017 07:16 PM, Emil Velikov wrote:
>> On 7 March 2017 at 15:53, Eero Tamminen <eero.t.tamminen at intel.com>
>> wrote:
>>> Hi,
>>>
>>> On 07.03.2017 17:08, Jason Ekstrand wrote:
>>>> Interesting... This must only affect android for some weird reason
>>>> because 32-bit builds have been working on regular Linux for some time
>>>> now.
>>>
>>> There are couple of issues...
>>>
>>>  From "ftruncate" manual page:
>>>         int ftruncate(int fd, off_t length);
>>> ...
>>>         The original Linux truncate() and ftruncate() system calls
>>> were not
>>> designed to handle large file offsets.  Consequently, Linux 2.4 added
>>> truncate64() and ftruncate64() system calls that handle large files.
>>> However, these details can be ignored by applications using glibc, whose
>>> wrapper functions  transparently  employ the more recent system calls
>>> where
>>> they are available.
>>>
>>>         On some 32-bit architectures, the calling signature for these
>>> system
>>> calls differ, for the reasons described in syscall(2).
>>>
>>>
>>> And from "ftello" manual page:
>>>         On some architectures, both off_t and long are 32-bit types, but
>>> defining _FILE_OFFSET_BITS with the value 64 (before including any
>>> header
>>> files) will turn off_t into a 64-bit type.
>>>
>>>
>>> Not sure which one Android libc/build hits.
>>>
>> Afaict 32bit Android has been ... what's a nicer word than broken...
>> See the fun experience we have in gallium [1] to w/a their fun mmap
>> implementation ;-)
>>
>> Tapani, cannot comment on the patch itself but do take a look at [1]
>> and move/reuse it _everywhere_. Mauro can you lend a hand to Tapani ?
>
> OK, that's interesting. Will need to check if we have issues with mmap.

Apparently no issues with mmap(), I got 32bit Vulkan app to run by 
making the ftruncated size byte smaller, BLOCK_POOL_MEMFD_SIZE - 1  .. 
which equals to FAT32 max size. Sorry for not realizing this earlier.

We had some discussion today with Eero and came to conclusion that maybe 
that 2GB is actually too big for 32bit system anyway and should consider 
to have even smaller block pool size in this case? Or should I just send 
a patch that adds '- 1' to ftruncate call? Opinions?



>> -Emil
>> [1] src/gallium/auxiliary/os/os_mman.h
>> _______________________________________________
>> mesa-dev mailing list
>> mesa-dev at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>
> // Tapani
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev