[Mesa-dev] [PATCH 03/39] llvmpipe: Fix overflow for 32 bits available memory computation

[Roland Scheidegger]

Am 17.05.2016 um 20:16 schrieb Rob Herring:
> On Tue, May 17, 2016 at 11:35 AM, Axel Davy <axel.davy at ens.fr> wrote:
>> On 16/05/2016 23:28, Rob Herring wrote:
>>>
>>> On Sun, May 15, 2016 at 5:45 AM, Axel Davy <axel.davy at ens.fr> wrote:
>>>>
>>>> And cap to 2 GB on 32 bits.
>>>>
>>>> Fixes https://bugs.freedesktop.org/show_bug.cgi?id=94561
>>>>
>>>> Signed-off-by: Axel Davy <axel.davy at ens.fr>
>>>> ---
>>>>   src/gallium/auxiliary/os/os_misc.c       | 2 +-
>>>>   src/gallium/drivers/llvmpipe/lp_screen.c | 5 +++++
>>>>   2 files changed, 6 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/src/gallium/auxiliary/os/os_misc.c
>>>> b/src/gallium/auxiliary/os/os_misc.c
>>>> index d6b83e9..cf2ef95 100644
>>>> --- a/src/gallium/auxiliary/os/os_misc.c
>>>> +++ b/src/gallium/auxiliary/os/os_misc.c
>>>> @@ -117,7 +117,7 @@ os_get_total_physical_memory(uint64_t *size)
>>>>      const long phys_pages = sysconf(_SC_PHYS_PAGES);
>>>>      const long page_size = sysconf(_SC_PAGE_SIZE);
>>>>
>>>> -   *size = phys_pages * page_size;
>>>> +   *size = (int64_t)phys_pages * (int64_t)page_size;
>>>>      return (phys_pages > 0 && page_size > 0);
>>>>   #elif defined(PIPE_OS_APPLE) || defined(PIPE_OS_BSD)
>>>>      size_t len = sizeof(*size);
>>>> diff --git a/src/gallium/drivers/llvmpipe/lp_screen.c
>>>> b/src/gallium/drivers/llvmpipe/lp_screen.c
>>>> index 4f61de8..2f84b75 100644
>>>> --- a/src/gallium/drivers/llvmpipe/lp_screen.c
>>>> +++ b/src/gallium/drivers/llvmpipe/lp_screen.c
>>>> @@ -279,6 +279,11 @@ llvmpipe_get_param(struct pipe_screen *screen, enum
>>>> pipe_cap param)
>>>>         if (!os_get_total_physical_memory(&system_memory))
>>>>            return 0;
>>>>
>>>> +#ifdef PIPE_ARCH_X86
>>>> +      /* cap to 2 GB on 32 bits system */
>>>
>>> What about non-x86 32-bit systems?
>>>
>>> Rob
>>>
>> Do you have a suggestion for a better check ?
> 
> if (sizeof(void *) == 4)
>     /* cap to 2 GB on 32 bits system */
>     system_memory = MIN2(system_memory, 2048);
> 
>>
>>
>> I could add in p_config.h a PIPE_ARCH_32 (and PIPE_ARCH_64), but I'm not
>> sure what to put in there,
>>
>> since it is possible to have a 32 bits processor with 64 bits memory
>> addressing.
> 
> Yes, but userspace can still only see 32-bits worth in that case. I
> don't see how that matters here.
> 
I don't think it's quite the same though. Since once you've transferred
some texture to the gpu, you don't really see it any longer. However, in
case of software renderers, it's going to still eat away your available
memory (at least with dri).
That said, if you'd try to map a huge resource, you'd run into problems
with real hw just the same - so it might make sense to extend this to
other drivers (chances are 32bit apps aren't really going to require
that much video memory).

Roland