Am 17.05.2016 um 20:16 schrieb Rob Herring: > On Tue, May 17, 2016 at 11:35 AM, Axel Davy <axel.d...@ens.fr> wrote: >> On 16/05/2016 23:28, Rob Herring wrote: >>> >>> On Sun, May 15, 2016 at 5:45 AM, Axel Davy <axel.d...@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.d...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
