[Mesa-stable] [PATCH] auxilary/os: correct sysctl use in os_get_total_physical_memory()

[Jonathan Gray]

On Wed, Feb 25, 2015 at 08:49:52PM +0000, Emil Velikov wrote:
> On 24/02/15 22:48, Jonathan Gray wrote:
> > On Tue, Feb 24, 2015 at 04:53:03PM +0000, Emil Velikov wrote:
> >> On 22 February 2015 at 08:19, Jonathan Gray <jsg at jsg.id.au> wrote:
> >>> The length argument passed to sysctl was the size of the pointer
> >>> not the type.  The result of this is sysctl calls would fail on
> >>> 32 bit BSD/Mac OS X.
> >>>
> >>> Additionally the wrong pointer was passed as an argument to store
> >>> the result of the sysctl call.
> >>>
> >>> Cc: "10.4, 10.5" <mesa-stable at lists.freedesktop.org>
> >>> Signed-off-by: Jonathan Gray <jsg at jsg.id.au>
> >> Seems like my attempt was enough but not quite there yet.
> >> Thanks for fixing my goof-up.
> >>
> >> Reviewed-by: Emil Velikov <emil.l.velikov at gmail.com>
> >>
> >> I'll push this in a couple of days unless there are any objections.
> >>
> >> Cheers
> >> Emil
> > 
> > It should be possible to use the sysconf path in more places
> > as well.  Classic swrast for example doesn't use sysctl at all.
> > 
> > OpenBSD/FreeBSD have _SC_PHYS_PAGES/_SC_PAGE_SIZE
> > NetBSD/Mac OS X don't document _SC_PAGE_SIZE but do document
> > _SC_PAGESIZE, though I wouldn't be surprised if they
> > had _SC_PAGE_SIZE in their headers.
> > 
> If you feel like unifying some code that would be appreciated.
> 
> Although, I have a greater request from you - can you look at removing
> the symlinks in src/mesa/drivers/dri/r{adeon,200} ?  Pretty please :-)
> 
> Restructuring the common bits into one place (radeon_common perhaps ?)
> will allow one to drop the links, and this will also cut down a fair
> hunk of the classic dri module binary.
> 
> Btw did you have the chance to try 10.5 with a simple wrapper, similar
> to xorg-server ? I believe that most concerns should be sorted out now -
> no python, lex, etc... dependency.

I have not tracked down the reason but Mesa 10.4.3 (and 10.3.7) caused
problems with gpu compositing on chrome resulting in a black window
on older Intel (ie 945gm) and discrete radeons (ie evergreen) but
not newer Intel hardware like ivy bridge.

As we're busy finishing off a release at the moment I've reverted
everything to 10.2.9.  So it will be a while before I have some
time to look at importing 10.5.

Grabbing 10.5.0 rc2 it seems python is still required?

python  ./mapi_abi.py --mode lib --printer shared-glapi glapi/gen/gl_and_es_API.xml > shared-glapi/glapi_mapi_tmp.h
python  ./main/get_hash_generator.py            \
python  ./main/format_info.py        \
python  ./gen_xmlpool.py ./t_options.h . ca de es nl fr sv > options.h

I also see
./util/u_math.h: In function 'u_bit_scan64':
./util/u_math.h:591: warning: implicit declaration of function 'ffsll'

which I thought was fixed...