[Mesa-dev] [PATCH] mesa: include stdarg.h for va_list
Include stdarg.h for va_list. Unbreaks the build on OpenBSD: In file included from mesa/program/dummy_errors.c:24: ../src/mesa/main/errors.h:85: error: expected declaration specifiers or '...' be fore 'va_list' Signed-off-by: Jonathan Gray --- src/mesa/main/errors.h | 1 + 1 file changed, 1 insertion(+) diff --git a/src/mesa/main/errors.h b/src/mesa/main/errors.h index 24f234f..81e47a8 100644 --- a/src/mesa/main/errors.h +++ b/src/mesa/main/errors.h @@ -37,6 +37,7 @@ #include +#include #include "compiler.h" #include "glheader.h" #include "mtypes.h" -- 2.4.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa: automake: replace $(RM) with rm -f
$(RM) is set to 'rm -f' by GNU make, this is not true of other versions
of make and RM is not one of the macros required by POSIX.
Signed-off-by: Jonathan Gray
---
Makefile.am | 2 +-
src/gallium/targets/dri/Makefile.am | 6 +++---
src/gallium/targets/vdpau/Makefile.am | 6 +++---
src/gallium/targets/xvmc/Makefile.am | 4 ++--
src/glsl/Makefile.am | 6 +++---
src/mesa/drivers/dri/Makefile.am | 8
6 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/Makefile.am b/Makefile.am
index 9f49ce6..6243b4d 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -58,4 +58,4 @@ noinst_HEADERS = \
# We list some directories in EXTRA_DIST, but don't actually want to include
# the .gitignore files in the tarball.
dist-hook:
- find $(distdir) -name .gitignore -exec $(RM) {} +
+ find $(distdir) -name .gitignore -exec rm -f {} +
diff --git a/src/gallium/targets/dri/Makefile.am
b/src/gallium/targets/dri/Makefile.am
index 7c86ea1..e047f33 100644
--- a/src/gallium/targets/dri/Makefile.am
+++ b/src/gallium/targets/dri/Makefile.am
@@ -117,7 +117,7 @@ all-local: $(dri_LTLIBRARIES)
clean-local:
$(AM_V_GEN)link_dir=$(top_builddir)/$(LIB_DIR)/gallium; \
$(AM_V_GEN)for i in $(TARGET_DRIVERS); do \
- $(RM) $${link_dir}/$${i}_dri.so;\
+ rm -f $${link_dir}/$${i}_dri.so;\
done;
endif
@@ -128,9 +128,9 @@ install-data-hook:
ln -f $(DESTDIR)$(dridir)/gallium_dri.so\
$(DESTDIR)$(dridir)/$${i}_dri.so; \
done; \
- $(RM) $(DESTDIR)$(dridir)/gallium_dri.*
+ rm -f $(DESTDIR)$(dridir)/gallium_dri.*
uninstall-hook:
for i in $(TARGET_DRIVERS); do \
- $(RM) $(DESTDIR)$(dridir)/$${i}_dri.so; \
+ rm -f $(DESTDIR)$(dridir)/$${i}_dri.so; \
done;
diff --git a/src/gallium/targets/vdpau/Makefile.am
b/src/gallium/targets/vdpau/Makefile.am
index 7eb62c1..67d8cac 100644
--- a/src/gallium/targets/vdpau/Makefile.am
+++ b/src/gallium/targets/vdpau/Makefile.am
@@ -97,7 +97,7 @@ all-local: $(vdpau_LTLIBRARIES)
clean-local:
$(AM_V_GEN)link_dir=$(top_builddir)/$(LIB_DIR)/gallium; \
$(AM_V_GEN)for i in $(TARGET_DRIVERS); do \
- $(RM)
$${link_dir}/libvdpau_$${i}.so{,.$(VDPAU_MAJOR){,.$(VDPAU_MINOR){,.0}}}; \
+ rm -f
$${link_dir}/libvdpau_$${i}.so{,.$(VDPAU_MAJOR){,.$(VDPAU_MINOR){,.0}}}; \
done;
endif
@@ -118,9 +118,9 @@ install-data-hook:
ln -sf $${l}\
$${dest_dir}/$${k}; \
done; \
- $(RM) $${dest_dir}/libvdpau_gallium.*
+ rm -f $${dest_dir}/libvdpau_gallium.*
uninstall-hook:
for i in $(TARGET_DRIVERS); do \
- $(RM)
$(DESTDIR)$(vdpaudir)/libvdpau_$${i}.so{,.$(VDPAU_MAJOR){,.$(VDPAU_MINOR){,.0}}};
\
+ rm -f
$(DESTDIR)$(vdpaudir)/libvdpau_$${i}.so{,.$(VDPAU_MAJOR){,.$(VDPAU_MINOR){,.0}}};
\
done;
diff --git a/src/gallium/targets/xvmc/Makefile.am
b/src/gallium/targets/xvmc/Makefile.am
index b328589..28f98ce 100644
--- a/src/gallium/targets/xvmc/Makefile.am
+++ b/src/gallium/targets/xvmc/Makefile.am
@@ -80,9 +80,9 @@ install-data-hook:
ln -sf $${l}\
$${dest_dir}/$${k}; \
done; \
- $(RM) $${dest_dir}/libXvMCgallium.*
+ rm -f $${dest_dir}/libXvMCgallium.*
uninstall-hook:
for i in $(TARGET_DRIVERS); do \
- $(RM)
$(DESTDIR)$(xvmcdir)/libXvMC$${i}.so{,.$(XVMC_MAJOR){,.$(XVMC_MINOR){,.0}}}; \
+ rm -f
$(DESTDIR)$(xvmcdir)/libXvMC$${i}.so{,.$(XVMC_MAJOR){,.$(XVMC_MINOR){,.0}}}; \
done;
diff --git a/src/glsl/Makefile.am b/src/glsl/Makefile.am
index e87b8bb..bb7d169 100644
--- a/src/glsl/Makefile.am
+++ b/src/glsl/Makefile.am
@@ -223,11 +223,11 @@ CLEANFILES =
\
$(BUILT_SOURCES)
clean-local:
- $(RM) -r subtest-cr subtest-cr-lf subtest-lf subtest-lf-cr
+ rm -f -r subtest-cr subtest-cr-lf subtest-lf subtest-lf-cr
dist-hook:
- $(RM) glcpp/tests/*.out
- $(RM) glcpp/tests/subtest*/*.out
+ rm -f glcpp/tests/*.out
+ rm -f glcpp/tests/subtest*/*.out
PYTHON_GEN = $(AM_V_GEN)$(PYTHON2) $(PYTHON_FLAGS)
diff --git a/src/mesa/drivers/dri/Makefile.am b/src/mesa/drivers/dri/Makefile.a
Re: [Mesa-dev] [Mesa-stable] [PATCH v2] configure.ac: ensure RM is set
On Tue, Oct 13, 2015 at 11:25:08AM +0100, Emil Velikov wrote: > On 10 October 2015 at 07:42, Jonathan Gray wrote: > > GNU make predefines RM to rm -f but this is not required by POSIX > > so ensure that RM is set. This fixes "make clean" on OpenBSD. > > > > v2: use AC_CHECK_PROG > > > I'm ambivalent if we go the AC_CHECK_PROG vs ?= route. > > I'll let others pick their favourite, but both are > Reviewed-by: Emil Velikov > > -Emil The ?= diff was a screwup as that syntax is valid in make but not shell. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Add new fast mtx_t mutex type for basic use cases
Including under __GNUC__ is going to break the build of Mesa on everything compiled with clang/gcc that isn't Linux. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] gallium/util: Define ffsll on OpenBSD.
OpenBSD has ffs in libc but does not have ffsll so use the compiler builtin. PIPE_OS_BSD isn't suitable here as FreeBSD has ffsll in libc. Signed-off-by: Jonathan Gray --- src/gallium/auxiliary/util/u_math.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/gallium/auxiliary/util/u_math.h b/src/gallium/auxiliary/util/u_math.h index 5db5b66..ec282f3 100644 --- a/src/gallium/auxiliary/util/u_math.h +++ b/src/gallium/auxiliary/util/u_math.h @@ -531,6 +531,8 @@ unsigned ffs( unsigned u ) #elif defined(__MINGW32__) || defined(PIPE_OS_ANDROID) #define ffs __builtin_ffs #define ffsll __builtin_ffsll +#elif defined(__OpenBSD__) +#define ffsll __builtin_ffsll #endif #endif /* FFS_DEFINED */ -- 2.2.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium/util: Define ffsll on OpenBSD.
On Fri, Feb 06, 2015 at 08:11:51AM -0700, Brian Paul wrote: > On 02/06/2015 04:38 AM, Jonathan Gray wrote: > >OpenBSD has ffs in libc but does not have ffsll so use the compiler > >builtin. PIPE_OS_BSD isn't suitable here as FreeBSD has ffsll in libc. > > > >Signed-off-by: Jonathan Gray > >--- > > src/gallium/auxiliary/util/u_math.h | 2 ++ > > 1 file changed, 2 insertions(+) > > > >diff --git a/src/gallium/auxiliary/util/u_math.h > >b/src/gallium/auxiliary/util/u_math.h > >index 5db5b66..ec282f3 100644 > >--- a/src/gallium/auxiliary/util/u_math.h > >+++ b/src/gallium/auxiliary/util/u_math.h > >@@ -531,6 +531,8 @@ unsigned ffs( unsigned u ) > > #elif defined(__MINGW32__) || defined(PIPE_OS_ANDROID) > > #define ffs __builtin_ffs > > #define ffsll __builtin_ffsll > >+#elif defined(__OpenBSD__) > >+#define ffsll __builtin_ffsll > > #endif > > > > #endif /* FFS_DEFINED */ > > > > Or maybe > > #elif defined(PIPE_OS_OPENBSD) && defined(PIPE_CC_GCC) > > Assuming you're talking about gcc. Well clang tends to have the same builtins as gcc. Though clang defines __GNUC__ and it seems clang would be picked up as PIPE_CC_GCC currently and there is no PIPE_CC_CLANG. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] auxilary/os: correct sysctl use in os_get_total_physical_memory()
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" Signed-off-by: Jonathan Gray --- src/gallium/auxiliary/os/os_misc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/gallium/auxiliary/os/os_misc.c b/src/gallium/auxiliary/os/os_misc.c index ebf033c..c46078b 100644 --- a/src/gallium/auxiliary/os/os_misc.c +++ b/src/gallium/auxiliary/os/os_misc.c @@ -118,7 +118,7 @@ os_get_total_physical_memory(uint64_t *size) *size = phys_pages * page_size; return (phys_pages > 0 && page_size > 0); #elif defined(PIPE_OS_APPLE) || defined(PIPE_OS_BSD) - size_t len = sizeof(size); + size_t len = sizeof(*size); int mib[2]; mib[0] = CTL_HW; @@ -134,7 +134,7 @@ os_get_total_physical_memory(uint64_t *size) #error Unsupported *BSD #endif - return (sysctl(mib, 2, &size, &len, NULL, 0) == 0); + return (sysctl(mib, 2, size, &len, NULL, 0) == 0); #elif defined(PIPE_OS_HAIKU) system_info info; status_t ret; -- 2.3.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] auxilary/os: correct sysctl use in os_get_total_physical_memory()
On Tue, Feb 24, 2015 at 04:53:03PM +, Emil Velikov wrote: > On 22 February 2015 at 08:19, Jonathan Gray 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" > > Signed-off-by: Jonathan Gray > Seems like my attempt was enough but not quite there yet. > Thanks for fixing my goof-up. > > Reviewed-by: Emil Velikov > > 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. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] auxilary/os: correct sysctl use in os_get_total_physical_memory()
On Wed, Feb 25, 2015 at 08:49:52PM +, Emil Velikov wrote:
> On 24/02/15 22:48, Jonathan Gray wrote:
> > On Tue, Feb 24, 2015 at 04:53:03PM +, Emil Velikov wrote:
> >> On 22 February 2015 at 08:19, Jonathan Gray 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"
> >>> Signed-off-by: Jonathan Gray
> >> Seems like my attempt was enough but not quite there yet.
> >> Thanks for fixing my goof-up.
> >>
> >> Reviewed-by: Emil Velikov
> >>
> >> 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...
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium/util: Define ffsll on OpenBSD.
On Mon, Feb 09, 2015 at 07:22:35PM +, Jose Fonseca wrote: > On 09/02/15 16:59, Jon TURNEY wrote: > >On 06/02/2015 19:58, Matt Turner wrote: > >>On Fri, Feb 6, 2015 at 3:38 AM, Jonathan Gray wrote: > >>>OpenBSD has ffs in libc but does not have ffsll so use the compiler > >>>builtin. PIPE_OS_BSD isn't suitable here as FreeBSD has ffsll in libc. > >>> > >>>Signed-off-by: Jonathan Gray > >>>--- > >>> src/gallium/auxiliary/util/u_math.h | 2 ++ > >>> 1 file changed, 2 insertions(+) > >>> > >>>diff --git a/src/gallium/auxiliary/util/u_math.h > >>>b/src/gallium/auxiliary/util/u_math.h > >>>index 5db5b66..ec282f3 100644 > >>>--- a/src/gallium/auxiliary/util/u_math.h > >>>+++ b/src/gallium/auxiliary/util/u_math.h > >>>@@ -531,6 +531,8 @@ unsigned ffs( unsigned u ) > >>> #elif defined(__MINGW32__) || defined(PIPE_OS_ANDROID) > >>> #define ffs __builtin_ffs > >>> #define ffsll __builtin_ffsll > >>>+#elif defined(__OpenBSD__) > >>>+#define ffsll __builtin_ffsll > >>> #endif > >> > >>Autoconf checks for presence of a bunch of builtins. Please use those > >>instead (in this case, HAVE___BUILTIN_FFSLL). > > > >Yes, please. > > > >This has just been 'fixed' for MinGW, now for OpenBSD, and also needs > >fixing for Cygwin. > > > > >Attached is a patch which attempts to do this using autoconf checks. > > The issue is that this will break scons builds unless these checks are > replicated there. And SCons implementation of configure checks are not > great to be honest -- they either are cached (but in such way were multiple > builds from same source tree pick up wrong values) or they need to be > re-checked on every build (wasting time for incremental builds). > > This is why, within reason, I personally like to avoid configure checks when > practical. > > > So for now I'd prefer to leave MinGW 'fixed' as you put it. > > But fell free to fix the other platforms as you propose. If it isn't going to be configure checks could someone merge the original patch in this thread? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] auxilary/os: correct sysctl use in os_get_total_physical_memory()
On Wed, Feb 25, 2015 at 10:43:39PM +, Emil Velikov wrote:
> On 25 February 2015 at 22:19, Jonathan Gray wrote:
> > On Wed, Feb 25, 2015 at 08:49:52PM +, Emil Velikov wrote:
> >> On 24/02/15 22:48, Jonathan Gray wrote:
> >> > On Tue, Feb 24, 2015 at 04:53:03PM +, Emil Velikov wrote:
> >> >> On 22 February 2015 at 08:19, Jonathan Gray 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"
> >> >>> Signed-off-by: Jonathan Gray
> >> >> Seems like my attempt was enough but not quite there yet.
> >> >> Thanks for fixing my goof-up.
> >> >>
> >> >> Reviewed-by: Emil Velikov
> >> >>
> >> >> 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.
> Perhaps one could have tried 10.4.4/10.4.5 but I guess I'm pushing it :-)
> What kind of bug tracking system do you guys use ? Please don't forget
> to give us a shout as you find the culprit for the issue.
10.4.4 made no difference, I doubt 10.4.5 would either.
As it's hard for me to build Mesa it's going to be hard to bisect.
I would be interested to hear if newer Mesa releases work on
~ Linux 3.8.
>
> > 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
> >
> Hmm those should not be executed if you have the distribution tarball.
> Can you open a bug or two if my assumption is incorrect ?
https://bugs.freedesktop.org/show_bug.cgi?id=89328
It seems gnu make is a hard requirement as well, is that intentional?
Making all in mapi/glapi/gen
make all-am
Making all in mapi
*** Parse error in /home/jsg/mesa-10.5.0-rc2/src/mapi: Need an operator in
'glapi_gen_mapi' (Makefile:2118)
*** Parse error: Missing dependency operator (Makefile:2119)
*** Parse error: Need an operator in '$@' (Makefile:2121)
*** Parse error: Need an operator in 'endef' (Makefile:2122)
*** Error 1 in src (Makefile:693 'all-recursive')
*** Error 1 in /home/jsg/mesa-10.5.0-rc2 (Makefile:636 'all-recursive')
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium/util: Define ffsll on OpenBSD.
On Wed, Feb 25, 2015 at 06:53:14PM -0800, Matt Turner wrote: > On Wed, Feb 25, 2015 at 5:37 PM, Jonathan Gray wrote: > > If it isn't going to be configure checks could someone merge the > > original patch in this thread? > > I committed > > commit 3492e88090d2d0c0bfbc934963b8772b45fc8880 > Author: Matt Turner > Date: Fri Feb 20 18:46:43 2015 -0800 > > gallium/util: Use HAVE___BUILTIN_* macros. > > Reviewed-by: Eric Anholt > Reviewed-by: Jose Fonseca > > which switched over a bunch of preprocessor checks around __builtin* > calls to use the macros defined by autotools. > > So I think cleaning it up to use __builtin_ffs* first #ifdef > HAVE___BUILTIN_* can go forward now. Yes but there is no HAVE_FFSLL for constructs like #if !defined(HAVE_FFSLL) && defined(HAVE___BUILTIN_FFSLL) or is it ok to always use the builtin? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium/util: Define ffsll on OpenBSD.
On Wed, Feb 25, 2015 at 07:09:26PM -0800, Matt Turner wrote:
> On Wed, Feb 25, 2015 at 7:03 PM, Jonathan Gray wrote:
> > On Wed, Feb 25, 2015 at 06:53:14PM -0800, Matt Turner wrote:
> >> On Wed, Feb 25, 2015 at 5:37 PM, Jonathan Gray wrote:
> >> > If it isn't going to be configure checks could someone merge the
> >> > original patch in this thread?
> >>
> >> I committed
> >>
> >> commit 3492e88090d2d0c0bfbc934963b8772b45fc8880
> >> Author: Matt Turner
> >> Date: Fri Feb 20 18:46:43 2015 -0800
> >>
> >> gallium/util: Use HAVE___BUILTIN_* macros.
> >>
> >> Reviewed-by: Eric Anholt
> >> Reviewed-by: Jose Fonseca
> >>
> >> which switched over a bunch of preprocessor checks around __builtin*
> >> calls to use the macros defined by autotools.
> >>
> >> So I think cleaning it up to use __builtin_ffs* first #ifdef
> >> HAVE___BUILTIN_* can go forward now.
> >
> > Yes but there is no HAVE_FFSLL for constructs like
> >
> > #if !defined(HAVE_FFSLL) && defined(HAVE___BUILTIN_FFSLL)
> >
> > or is it ok to always use the builtin?
>
> I think the question is whether it's okay to always use the builtin if
> it's available (as opposed to libc functions). I think the answer to
> that is yes.
So in that case how about the following? Or is it going to break
the android scons build?
From cba39ba72115e57d262cb4b099c4e72106f01812 Mon Sep 17 00:00:00 2001
From: Jonathan Gray
Date: Thu, 26 Feb 2015 14:46:45 +1100
Subject: [PATCH] gallium/util: use ffs* builtins if available
Required to build on OpenBSD which doesn't have ffsll in libc.
Signed-off-by: Jonathan Gray
---
src/gallium/auxiliary/util/u_math.h | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_math.h
b/src/gallium/auxiliary/util/u_math.h
index b4a65e4..5bc9b97 100644
--- a/src/gallium/auxiliary/util/u_math.h
+++ b/src/gallium/auxiliary/util/u_math.h
@@ -384,9 +384,6 @@ unsigned ffs( unsigned u )
return i;
}
-#elif defined(__MINGW32__) || defined(PIPE_OS_ANDROID)
-#define ffs __builtin_ffs
-#define ffsll __builtin_ffsll
#endif
#endif /* FFS_DEFINED */
@@ -435,7 +432,11 @@ util_last_bit_signed(int i)
static INLINE int
u_bit_scan(unsigned *mask)
{
+#if defined(HAVE___BUILTIN_FFS)
+ int i = __builtin_ffs(*mask) - 1;
+#else
int i = ffs(*mask) - 1;
+#endif
*mask &= ~(1 << i);
return i;
}
@@ -444,7 +445,11 @@ u_bit_scan(unsigned *mask)
static INLINE int
u_bit_scan64(uint64_t *mask)
{
+#if defined(HAVE___BUILTIN_FFSLL)
+ int i = __builtin_ffsll(*mask) - 1;
+#else
int i = ffsll(*mask) - 1;
+#endif
*mask &= ~(1llu << i);
return i;
}
--
2.3.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] util: Add utility build-id code.
On Wed, Feb 15, 2017 at 11:11:50AM -0800, Matt Turner wrote: > Provides the ability to read the .note.gnu.build-id section of ELF > binaries, which is inserted by the --build-id=... flag to ld. > > Reviewed-by: Emil Velikov I don't have time to dig into details right now but this broke the Mesa build on OpenBSD and likely other non-linux platforms: libtool: compile: gcc -DPACKAGE_NAME=\"Mesa\" -DPACKAGE_TARNAME=\"mesa\" -DPACKAGE_VERSION=\"17.1.0-devel\" "-DPACKAGE_STRING=\"Mesa 17.1.0-devel\"" "-DPACKAGE_BUGREPORT=\"https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa\""; -DPACKAGE_URL=\"\" -DPACKAGE=\"mesa\" -DVERSION=\"17.1.0-devel\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DYYTEXT_POINTER=1 -DHAVE___BUILTIN_CLZ=1 -DHAVE___BUILTIN_CLZLL=1 -DHAVE___BUILTIN_CTZ=1 -DHAVE___BUILTIN_EXPECT=1 -DHAVE___BUILTIN_FFS=1 -DHAVE___BUILTIN_FFSLL=1 -DHAVE___BUILTIN_POPCOUNT=1 -DHAVE___BUILTIN_POPCOUNTLL=1 -DHAVE_FUNC_ATTRIBUTE_CONST=1 -DHAVE_FUNC_ATTRIBUTE_FLATTEN=1 -DHAVE_FUNC_ATTRIBUTE_FORMAT=1 -DHAVE_FUNC_ATTRIBUTE_MALLOC=1 -DHAVE_FUNC_ATTRIBUTE_PACKED=1 -DHAVE_FUNC_ATTRIBUTE_PURE=1 -DHAVE_FUNC_ATTRIBUTE_UNUSED=1 -DHAVE_FUNC_ATTRIBUTE_VISIBILITY=1 -DHAVE_FUNC_ATTRIBUTE_WARN_UNUSED_RESULT=1 -DHAVE_FUNC_ATTRIBUTE_WEAK=1 -DHAVE_FUNC_ATTRIBUTE_ALIAS=1 -DHAVE_DLADDR=1 -DHAVE_CLOCK_GETTIME=1 -DHAVE_PTHREAD_PRIO_INHERIT=1 -DHAVE_PTHREAD=1 -I. -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -DDEBUG -DTEXTURE_FLOAT_ENABLED -DUSE_X86_64_ASM -DHAVE_SYS_SYSCTL_H -DHAVE_STRTOF -DHAVE_MKOSTEMP -DHAVE_DLOPEN -DHAVE_DL_ITERATE_PHDR -DHAVE_POSIX_MEMALIGN -DHAVE_LIBDRM -DGLX_USE_DRM -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING -DENABLE_SHADER_CACHE -DHAVE_MINCORE -I../../include -I../../src -I../../src/mapi -I../../src/mesa -I../../src/gallium/include -I../../src/gallium/auxiliary -fvisibility=hidden -Werror=pointer-arith -g -O2 -Wall -std=gnu99 -Werror=implicit-function-declaration -Werror=missing-prototypes -fno-math-errno -fno-trapping-math -MT libmesautil_la-build_id.lo -MD -MP -MF .deps/libmesautil_la-build_id.Tpo -c build_id.c -fPIC -DPIC -o .libs/libmesautil_la-build_id.o In file included from /usr/include/elf_abi.h:31, from /usr/include/link_elf.h:10, from /usr/include/link.h:39, from build_id.c:25: /usr/include/sys/exec_elf.h:585: error: expected specifier-qualifier-list before 'uint32_t' In file included from /usr/include/link.h:39, from build_id.c:25: /usr/include/link_elf.h:22: error: expected specifier-qualifier-list before 'caddr_t' /usr/include/link_elf.h:37: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'int' In file included from build_id.c:25: /usr/include/link.h:49: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'struct' /usr/include/link.h:65: error: expected specifier-qualifier-list before 'caddr_t' build_id.c:34: error: expected specifier-qualifier-list before 'ElfW' build_id.c: In function 'build_id_find_nhdr_callback': build_id.c:63: error: 'struct build_id_note' has no member named 'nhdr' build_id.c:63: error: 'NT_GNU_BUILD_ID' undeclared (first use in this function) build_id.c:63: error: (Each undeclared identifier is reported only once build_id.c:63: error: for each function it appears in.) build_id.c:64: error: 'struct build_id_note' has no member named 'nhdr' build_id.c:65: error: 'struct build_id_note' has no member named 'nhdr' build_id.c:66: error: 'struct build_id_note' has no member named 'name' build_id.c:71: warning: implicit declaration of function 'ElfW' build_id.c:71: error: 'Nhdr' undeclared (first use in this function) build_id.c:72: error: 'struct build_id_note' has no member named 'nhdr' build_id.c:73: error: 'struct build_id_note' has no member named 'nhdr' build_id.c: In function 'build_id_find_nhdr': build_id.c:90: warning: implicit declaration of function 'dl_iterate_phdr' build_id.c: In function 'build_id_length': build_id.c:99: error: 'const struct build_id_note' has no member named 'nhdr' build_id.c: In function 'build_id_read': build_id.c:106: error: 'const struct build_id_note' has no member named 'build_id' *** Error 1 in target 'libmesautil_la-build_id.lo' mv -f .deps/libmesautil_la-strndup.Tpo .deps/libmesautil_la-strndup.Plo mv -f sha1/.deps/libmesautil_la-sha1.Tpo sha1/.deps/libmesautil_la-sha1.Plo *** Error 1 in src/util (Makefile:730 'libmesautil_la-build_id.lo') *** Error 1 in src/util (Makefile:919 'all-recursive') *** Error 2 in src/util (Makefile:596 'all') *** Error 1 in src (Makefile:819 'all-recursive') *** Error 2 in src (Makefile:584 'all') adding a sys/types.h include before link.h gets slightly further libtool: compile: gcc -DPACKAGE_NAME=\"Mesa\" -DPACKAGE_TARNAME=\"mesa\" -DPACKAGE_VERSION=\"17.1.0-devel\" "-D
Re: [Mesa-dev] [PATCH 1/2] util: Add utility build-id code.
On Thu, Feb 16, 2017 at 04:25:02PM +, Emil Velikov wrote:
> On 16 February 2017 at 14:23, Jonathan Gray wrote:
> > On Wed, Feb 15, 2017 at 11:11:50AM -0800, Matt Turner wrote:
> >> Provides the ability to read the .note.gnu.build-id section of ELF
> >> binaries, which is inserted by the --build-id=... flag to ld.
> >>
> >> Reviewed-by: Emil Velikov
> >
> > I don't have time to dig into details right now but this broke the Mesa
> > build on OpenBSD and likely other non-linux platforms:
> >
> > libtool: compile: gcc -DPACKAGE_NAME=\"Mesa\" -DPACKAGE_TARNAME=\"mesa\"
> > -DPACKAGE_VERSION=\"17.1.0-devel\" "-DPACKAGE_STRING=\"Mesa 17.1.0-devel\""
> > "-DPACKAGE_BUGREPORT=\"https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa\"";
> > -DPACKAGE_URL=\"\" -DPACKAGE=\"mesa\" -DVERSION=\"17.1.0-devel\"
> > -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1
> > -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1
> > -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\"
> > -DYYTEXT_POINTER=1 -DHAVE___BUILTIN_CLZ=1 -DHAVE___BUILTIN_CLZLL=1
> > -DHAVE___BUILTIN_CTZ=1 -DHAVE___BUILTIN_EXPECT=1 -DHAVE___BUILTIN_FFS=1
> > -DHAVE___BUILTIN_FFSLL=1 -DHAVE___BUILTIN_POPCOUNT=1
> > -DHAVE___BUILTIN_POPCOUNTLL=1 -DHAVE_FUNC_ATTRIBUTE_CONST=1
> > -DHAVE_FUNC_ATTRIBUTE_FLATTEN=1 -DHAVE_FUNC_ATTRIBUTE_FORMAT=1
> > -DHAVE_FUNC_ATTRIBUTE_MALLOC=1 -DHAVE_FUNC_ATTRIBUTE_PACKED=1
> > -DHAVE_FUNC_ATTRIBUTE_PURE=1 -DHAVE_FUNC_ATTRIBUTE_UNUSED=1
> > -DHAVE_FUNC_ATTRIBUTE_VISIBILITY=1
> > -DHAVE_FUNC_ATTRIBUTE_WARN_UNUSED_RESULT=1 -DHAVE_FUNC_ATTRIBUTE_WEAK=1
> > -DHAVE_FUNC_ATTRIBUTE_ALIAS=1 -DHAVE_DLADDR=1 -DHAVE_CLOCK_GETTIME=1
> > -DHAVE_PTHREAD_PRIO_INHERIT=1 -DHAVE_PTHREAD=1 -I. -D__STDC_CONSTANT_MACROS
> > -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -DDEBUG
> > -DTEXTURE_FLOAT_ENABLED -DUSE_X86_64_ASM -DHAVE_SYS_SYSCTL_H -DHAVE_STRTOF
> > -DHAVE_MKOSTEMP -DHAVE_DLOPEN -DHAVE_DL_ITERATE_PHDR -DHAVE_POSIX_MEMALIGN
> > -DHAVE_LIBDRM -DGLX_USE_DRM -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING
> > -DENABLE_SHADER_CACHE -DHAVE_MINCORE -I../../include -I../../src
> > -I../../src/mapi -I../../src/mesa -I../../src/gallium/include
> > -I../../src/gallium/auxiliary -fvisibility=hidden -Werror=pointer-arith -g
> > -O2 -Wall -std=gnu99 -Werror=implicit-function-declaration
> > -Werror=missing-prototypes -fno-math-errno -fno-trapping-math -MT
> > libmesautil_la-build_id.lo -MD -MP -MF .deps/libmesautil_la-build_id.Tpo -c
> > build_id.c -fPIC -DPIC -o .libs/libmesautil_la-build_id.o
> > In file included from /usr/include/elf_abi.h:31,
> > from /usr/include/link_elf.h:10,
> > from /usr/include/link.h:39,
> > from build_id.c:25:
> > /usr/include/sys/exec_elf.h:585: error: expected specifier-qualifier-list
> > before 'uint32_t'
> > In file included from /usr/include/link.h:39,
> > from build_id.c:25:
> > /usr/include/link_elf.h:22: error: expected specifier-qualifier-list before
> > 'caddr_t'
> > /usr/include/link_elf.h:37: error: expected '=', ',', ';', 'asm' or
> > '__attribute__' before 'int'
> > In file included from build_id.c:25:
> > /usr/include/link.h:49: error: expected '=', ',', ';', 'asm' or
> > '__attribute__' before 'struct'
> > /usr/include/link.h:65: error: expected specifier-qualifier-list before
> > 'caddr_t'
> These look like issue in your platform code/headers. Perhaps some bad
> interaction with the bits that Mesa defines ?
>
> Quick workaround is to check the function only when needed, roughly
> like this pseudo code:
>
> if test $building_any_vulkan_driver = yes ;then
> require_dl...=yes
>
> fi
>
>
> if test $require_dl... = yes ; then
>AC_CHECK_FUNC([dl_iterate_phdr], [DEFINES="$DEFINES
> -DHAVE_DL_ITERATE_PHDR"], [AC_MSG_ERROR([required not found])])
> fi
>
>
> Please give it a bash and send us a patch that works on your end.
Leaning towards something along the lines of the following.
With Nhdr struct definitions added to system exec_elf.h.
The need for sys/types.h here may go away shortly as well.
diff --git a/src/util/build_id.c b/src/util/build_id.c
index 2993a80cfe..92250a1f5f 100644
--- a/src/util/build_id.c
+++ b/src/util/build_id.c
@@ -22,12 +22,22 @@
*/
#ifdef HAVE_DL_ITERATE_PHDR
+
+#include
#include
#include
#include
#include "build_id.h"
+#ifndef NT_GNU_BUILD_ID
+#define NT_GNU_BUILD_ID 3
+#endif
+
+#ifndef ElfW
+#define ElfW(type) Elf_##type
+#endif
+
#define ALIGN(val, align) (((val) + (align) - 1) & ~((align) - 1))
struct build_id_note {
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] util: Add utility build-id code.
On Fri, Feb 17, 2017 at 08:30:17AM -0800, Matt Turner wrote: > On Fri, Feb 17, 2017 at 5:39 AM, Emil Velikov > wrote: > > On 17 February 2017 at 01:10, Jonathan Gray wrote: > >> On Thu, Feb 16, 2017 at 04:25:02PM +, Emil Velikov wrote: > >>> On 16 February 2017 at 14:23, Jonathan Gray wrote: > >>> > On Wed, Feb 15, 2017 at 11:11:50AM -0800, Matt Turner wrote: > >>> >> Provides the ability to read the .note.gnu.build-id section of ELF > >>> >> binaries, which is inserted by the --build-id=... flag to ld. > >>> >> > >>> >> Reviewed-by: Emil Velikov > >>> > > >>> > I don't have time to dig into details right now but this broke the Mesa > >>> > build on OpenBSD and likely other non-linux platforms: > >>> > > >>> > libtool: compile: gcc -DPACKAGE_NAME=\"Mesa\" > >>> > -DPACKAGE_TARNAME=\"mesa\" -DPACKAGE_VERSION=\"17.1.0-devel\" > >>> > "-DPACKAGE_STRING=\"Mesa 17.1.0-devel\"" > >>> > "-DPACKAGE_BUGREPORT=\"https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa\""; > >>> > -DPACKAGE_URL=\"\" -DPACKAGE=\"mesa\" -DVERSION=\"17.1.0-devel\" > >>> > -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 > >>> > -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 > >>> > -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 > >>> > -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" > >>> > -DYYTEXT_POINTER=1 -DHAVE___BUILTIN_CLZ=1 -DHAVE___BUILTIN_CLZLL=1 > >>> > -DHAVE___BUILTIN_CTZ=1 -DHAVE___BUILTIN_EXPECT=1 -DHAVE___BUILTIN_FFS=1 > >>> > -DHAVE___BUILTIN_FFSLL=1 -DHAVE___BUILTIN_POPCOUNT=1 > >>> > -DHAVE___BUILTIN_POPCOUNTLL=1 -DHAVE_FUNC_ATTRIBUTE_CONST=1 > >>> > -DHAVE_FUNC_ATTRIBUTE_FLATTEN=1 -DHAVE_FUNC_ATTRIBUTE_FORMAT=1 > >>> > -DHAVE_FUNC_ATTRIBUTE_MALLOC=1 -DHAVE_FUNC_ATTRIBUTE_PACKED=1 > >>> > -DHAVE_FUNC_ATTRIBUTE_PURE=1 -DHAVE_FUNC_ATTRIBUTE_UNUSED=1 > >>> > -DHAVE_FUNC_ATTRIBUTE_VISIBILITY=1 > >>> > -DHAVE_FUNC_ATTRIBUTE_WARN_UNUSED_RESULT=1 -DHAVE_FUNC_ATTRIBUTE_WEAK=1 > >>> > -DHAVE_FUNC_ATTRIBUTE_ALIAS=1 -DHAVE_DLADDR=1 -DHAVE_CLOCK_GETTIME=1 > >>> > -DHAVE_PTHREAD_PRIO_INHERIT=1 -DHAVE_PTHREAD=1 -I. > >>> > -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS > >>> > -DDEBUG -DTEXTURE_FLOAT_ENABLED -DUSE_X86_64_ASM -DHAVE_SYS_SYSCTL_H > >>> > -DHAVE_STRTOF -DHAVE_MKOSTEMP -DHAVE_DLOPEN -DHAVE_DL_ITERATE_PHDR > >>> > -DHAVE_POSIX_MEMALIGN -DHAVE_LIBDRM -DGLX_USE_DRM > >>> > -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING -DENABLE_SHADER_CACHE > >>> > -DHAVE_MINCORE -I../../include -I../../src -I../../src/mapi > >>> > -I../../src/mesa -I../../src/gallium/include > >>> > -I../../src/gallium/auxiliary -fvisibility=hidden -Werror=pointer-arith > >>> > -g -O2 -Wall -std=gnu99 -Werror=implicit-function-declaration > >>> > -Werror=missing-prototypes -fno-math-errno -fno-trapping-math -MT > >>> > libmesautil_la-build_id.lo -MD -MP -MF > >>> > .deps/libmesautil_la-build_id.Tpo -c build_id.c -fPIC -DPIC -o > >>> > .libs/libmesautil_la-build_id.o > >>> > In file included from /usr/include/elf_abi.h:31, > >>> > from /usr/include/link_elf.h:10, > >>> > from /usr/include/link.h:39, > >>> > from build_id.c:25: > >>> > /usr/include/sys/exec_elf.h:585: error: expected > >>> > specifier-qualifier-list before 'uint32_t' > >>> > In file included from /usr/include/link.h:39, > >>> > from build_id.c:25: > >>> > /usr/include/link_elf.h:22: error: expected specifier-qualifier-list > >>> > before 'caddr_t' > >>> > /usr/include/link_elf.h:37: error: expected '=', ',', ';', 'asm' or > >>> > '__attribute__' before 'int' > >>> > In file included from build_id.c:25: > >>> > /usr/include/link.h:49: error: expected '=', ',', ';', 'asm' or > >>> > '__attribute__' before 'struct' > >>> > /usr/include/link.h:65: error: expected specifier-q
[Mesa-dev] [PATCH] util/build-id: define ElfW and NT_GNU_BUILD_ID if needed
Define ElfW() and NT_GNU_BUILD_ID if needed as these defines are not
present on at least OpenBSD and FreeBSD. Fixes the build on OpenBSD.
Signed-off-by: Jonathan Gray
---
src/util/build_id.c | 8
1 file changed, 8 insertions(+)
diff --git a/src/util/build_id.c b/src/util/build_id.c
index 2993a80cfe..cc0f852730 100644
--- a/src/util/build_id.c
+++ b/src/util/build_id.c
@@ -28,6 +28,14 @@
#include "build_id.h"
+#ifndef NT_GNU_BUILD_ID
+#define NT_GNU_BUILD_ID 3
+#endif
+
+#ifndef ElfW
+#define ElfW(type) Elf_##type
+#endif
+
#define ALIGN(val, align) (((val) + (align) - 1) & ~((align) - 1))
struct build_id_note {
--
2.11.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2] i965: Implement INTEL_performance_query backend
On Thu, Feb 16, 2017 at 01:20:37PM +, Robert Bragg wrote: > diff --git a/src/mesa/drivers/dri/i965/brw_performance_query.c > b/src/mesa/drivers/dri/i965/brw_performance_query.c > new file mode 100644 > index 00..f1b6f583bf > --- /dev/null > +++ b/src/mesa/drivers/dri/i965/brw_performance_query.c > +/** > + * \file brw_performance_query.c > + * > + * Implementation of the GL_INTEL_performance_query extension. > + * > + * Currently this driver only exposes the 64bit Pipeline Statistics > + * Registers for Gen6+, with support for Observability Counters to be > + * added later for Gen7.5+ > + */ > + > +#include > + > +#include Is this include needed on Linux? It broke the Mesa build on OpenBSD and builds fine with it removed here. > +#include > +#include > +#include > +#include > +#include > + > +#include "main/hash.h" > +#include "main/macros.h" > +#include "main/mtypes.h" > +#include "main/performance_query.h" > + > +#include "util/bitset.h" > +#include "util/ralloc.h" > + > +#include "brw_context.h" > +#include "brw_defines.h" > +#include "brw_performance_query.h" > +#include "intel_batchbuffer.h" > + > +#define FILE_DEBUG_FLAG DEBUG_PERFMON ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] r600: port si_conv_prim_to_gs_out from radeonsi
On Fri, Aug 28, 2015 at 10:47:44AM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> This code we broken by the tess merge, and I totally missed it
> until now. I'm not sure this fixes anything but it stops the assert.
>
> Cc: "11.0"
> Signed-off-by: Dave Airlie
> ---
> src/gallium/drivers/r600/r600_pipe.h | 31 ---
> 1 file changed, 16 insertions(+), 15 deletions(-)
>
> diff --git a/src/gallium/drivers/r600/r600_pipe.h
> b/src/gallium/drivers/r600/r600_pipe.h
> index 384ba80..3247aba 100644
> --- a/src/gallium/drivers/r600/r600_pipe.h
> +++ b/src/gallium/drivers/r600/r600_pipe.h
> @@ -939,21 +939,22 @@ static inline bool r600_can_read_depth(struct
> r600_texture *rtex)
> static inline unsigned r600_conv_prim_to_gs_out(unsigned mode)
> {
> static const int prim_conv[] = {
> - V_028A6C_OUTPRIM_TYPE_POINTLIST,
> - V_028A6C_OUTPRIM_TYPE_LINESTRIP,
> - V_028A6C_OUTPRIM_TYPE_LINESTRIP,
> - V_028A6C_OUTPRIM_TYPE_LINESTRIP,
> - V_028A6C_OUTPRIM_TYPE_TRISTRIP,
> - V_028A6C_OUTPRIM_TYPE_TRISTRIP,
> - V_028A6C_OUTPRIM_TYPE_TRISTRIP,
> - V_028A6C_OUTPRIM_TYPE_TRISTRIP,
> - V_028A6C_OUTPRIM_TYPE_TRISTRIP,
> - V_028A6C_OUTPRIM_TYPE_TRISTRIP,
> - V_028A6C_OUTPRIM_TYPE_LINESTRIP,
> - V_028A6C_OUTPRIM_TYPE_LINESTRIP,
> - V_028A6C_OUTPRIM_TYPE_TRISTRIP,
> - V_028A6C_OUTPRIM_TYPE_TRISTRIP,
> - V_028A6C_OUTPRIM_TYPE_TRISTRIP
> + [PIPE_PRIM_POINTS] =
> V_028A6C_OUTPRIM_TYPE_POINTLIST,
> + [PIPE_PRIM_LINES] =
> V_028A6C_OUTPRIM_TYPE_LINESTRIP,
> + [PIPE_PRIM_LINE_LOOP] =
> V_028A6C_OUTPRIM_TYPE_LINESTRIP,
> + [PIPE_PRIM_LINE_STRIP] =
> V_028A6C_OUTPRIM_TYPE_LINESTRIP,
> + [PIPE_PRIM_TRIANGLES] =
> V_028A6C_OUTPRIM_TYPE_TRISTRIP,
> + [PIPE_PRIM_TRIANGLE_STRIP] =
> V_028A6C_OUTPRIM_TYPE_TRISTRIP,
> + [PIPE_PRIM_TRIANGLE_FAN]=
> V_028A6C_OUTPRIM_TYPE_TRISTRIP,
> + [PIPE_PRIM_QUADS] =
> V_028A6C_OUTPRIM_TYPE_TRISTRIP,
> + [PIPE_PRIM_QUAD_STRIP] =
> V_028A6C_OUTPRIM_TYPE_TRISTRIP,
> + [PIPE_PRIM_POLYGON] =
> V_028A6C_OUTPRIM_TYPE_TRISTRIP,
> + [PIPE_PRIM_LINES_ADJACENCY] =
> V_028A6C_OUTPRIM_TYPE_LINESTRIP,
> + [PIPE_PRIM_LINE_STRIP_ADJACENCY]=
> V_028A6C_OUTPRIM_TYPE_LINESTRIP,
> + [PIPE_PRIM_TRIANGLES_ADJACENCY] =
> V_028A6C_OUTPRIM_TYPE_TRISTRIP,
> + [PIPE_PRIM_TRIANGLE_STRIP_ADJACENCY]=
> V_028A6C_OUTPRIM_TYPE_TRISTRIP,
> + [PIPE_PRIM_PATCHES] =
> V_028A6C_OUTPRIM_TYPE_POINTLIST,
> + [R600_PRIM_RECTANGLE_LIST] =
> V_028A6C_OUTPRIM_TYPE_TRISTRIP
> };
> assert(mode < Elements(prim_conv));
This seems to have broken the build on OpenBSD with gcc 4.2.1:
In file included from sb/sb_bc_parser.cpp:35:
./r600_pipe.h: In function 'unsigned int r600_conv_prim_to_gs_out(unsigned
int)':
./r600_pipe.h:942: error: expected primary-expression before '[' token
./r600_pipe.h:943: error: expected primary-expression before '[' token
./r600_pipe.h:944: error: expected primary-expression before '[' token
./r600_pipe.h:945: error: expected primary-expression before '[' token
./r600_pipe.h:946: error: expected primary-expression before '[' token
./r600_pipe.h:947: error: expected primary-expression before '[' token
./r600_pipe.h:948: error: expected primary-expression before '[' token
./r600_pipe.h:949: error: expected primary-expression before '[' token
./r600_pipe.h:950: error: expected primary-expression before '[' token
./r600_pipe.h:951: error: expected primary-expression before '[' token
./r600_pipe.h:952: error: expected primary-expression before '[' token
./r600_pipe.h:953: error: expected primary-expression before '[' token
./r600_pipe.h:954: error: expected primary-expression before '[' token
./r600_pipe.h:955: error: expected primary-expression before '[' token
./r600_pipe.h:956: error: expected primary-expression before '[' token
./r600_pipe.h:957: error: expected primary-expression before '[' token
Makefile:801: recipe for target 'sb/sb_bc_parser.lo' failed
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] r600: port si_conv_prim_to_gs_out from radeonsi
On Sun, Aug 30, 2015 at 01:38:49AM -0400, Ilia Mirkin wrote:
> On Sun, Aug 30, 2015 at 1:27 AM, Jonathan Gray wrote:
> > On Fri, Aug 28, 2015 at 10:47:44AM +1000, Dave Airlie wrote:
> >> From: Dave Airlie
> >>
> >> This code we broken by the tess merge, and I totally missed it
> >> until now. I'm not sure this fixes anything but it stops the assert.
> >>
> >> Cc: "11.0"
> >> Signed-off-by: Dave Airlie
> >> ---
> >> src/gallium/drivers/r600/r600_pipe.h | 31 ---
> >> 1 file changed, 16 insertions(+), 15 deletions(-)
> >>
> >> diff --git a/src/gallium/drivers/r600/r600_pipe.h
> >> b/src/gallium/drivers/r600/r600_pipe.h
> >> index 384ba80..3247aba 100644
> >> --- a/src/gallium/drivers/r600/r600_pipe.h
> >> +++ b/src/gallium/drivers/r600/r600_pipe.h
> >> @@ -939,21 +939,22 @@ static inline bool r600_can_read_depth(struct
> >> r600_texture *rtex)
> >> static inline unsigned r600_conv_prim_to_gs_out(unsigned mode)
> >> {
> >> static const int prim_conv[] = {
> >> - V_028A6C_OUTPRIM_TYPE_POINTLIST,
> >> - V_028A6C_OUTPRIM_TYPE_LINESTRIP,
> >> - V_028A6C_OUTPRIM_TYPE_LINESTRIP,
> >> - V_028A6C_OUTPRIM_TYPE_LINESTRIP,
> >> - V_028A6C_OUTPRIM_TYPE_TRISTRIP,
> >> - V_028A6C_OUTPRIM_TYPE_TRISTRIP,
> >> - V_028A6C_OUTPRIM_TYPE_TRISTRIP,
> >> - V_028A6C_OUTPRIM_TYPE_TRISTRIP,
> >> - V_028A6C_OUTPRIM_TYPE_TRISTRIP,
> >> - V_028A6C_OUTPRIM_TYPE_TRISTRIP,
> >> - V_028A6C_OUTPRIM_TYPE_LINESTRIP,
> >> - V_028A6C_OUTPRIM_TYPE_LINESTRIP,
> >> - V_028A6C_OUTPRIM_TYPE_TRISTRIP,
> >> - V_028A6C_OUTPRIM_TYPE_TRISTRIP,
> >> - V_028A6C_OUTPRIM_TYPE_TRISTRIP
> >> + [PIPE_PRIM_POINTS] =
> >> V_028A6C_OUTPRIM_TYPE_POINTLIST,
> >> + [PIPE_PRIM_LINES] =
> >> V_028A6C_OUTPRIM_TYPE_LINESTRIP,
> >> + [PIPE_PRIM_LINE_LOOP] =
> >> V_028A6C_OUTPRIM_TYPE_LINESTRIP,
> >> + [PIPE_PRIM_LINE_STRIP] =
> >> V_028A6C_OUTPRIM_TYPE_LINESTRIP,
> >> + [PIPE_PRIM_TRIANGLES] =
> >> V_028A6C_OUTPRIM_TYPE_TRISTRIP,
> >> + [PIPE_PRIM_TRIANGLE_STRIP] =
> >> V_028A6C_OUTPRIM_TYPE_TRISTRIP,
> >> + [PIPE_PRIM_TRIANGLE_FAN]=
> >> V_028A6C_OUTPRIM_TYPE_TRISTRIP,
> >> + [PIPE_PRIM_QUADS] =
> >> V_028A6C_OUTPRIM_TYPE_TRISTRIP,
> >> + [PIPE_PRIM_QUAD_STRIP] =
> >> V_028A6C_OUTPRIM_TYPE_TRISTRIP,
> >> + [PIPE_PRIM_POLYGON] =
> >> V_028A6C_OUTPRIM_TYPE_TRISTRIP,
> >> + [PIPE_PRIM_LINES_ADJACENCY] =
> >> V_028A6C_OUTPRIM_TYPE_LINESTRIP,
> >> + [PIPE_PRIM_LINE_STRIP_ADJACENCY]=
> >> V_028A6C_OUTPRIM_TYPE_LINESTRIP,
> >> + [PIPE_PRIM_TRIANGLES_ADJACENCY] =
> >> V_028A6C_OUTPRIM_TYPE_TRISTRIP,
> >> + [PIPE_PRIM_TRIANGLE_STRIP_ADJACENCY]=
> >> V_028A6C_OUTPRIM_TYPE_TRISTRIP,
> >> + [PIPE_PRIM_PATCHES] =
> >> V_028A6C_OUTPRIM_TYPE_POINTLIST,
> >> + [R600_PRIM_RECTANGLE_LIST] =
> >> V_028A6C_OUTPRIM_TYPE_TRISTRIP
> >> };
> >> assert(mode < Elements(prim_conv));
> >
> > This seems to have broken the build on OpenBSD with gcc 4.2.1:
> >
> > In file included from sb/sb_bc_parser.cpp:35:
> > ./r600_pipe.h: In function 'unsigned int r600_conv_prim_to_gs_out(unsigned
> > int)':
> > ./r600_pipe.h:942: error: expected primary-expression before '[' token
> > ./r600_pipe.h:943: error: expected primary-expression before '[' token
> > ./r600_pipe.h:944: error: expected primary-expression before '[' token
> > ./r600_pipe.h:945: error: expected primary-expression before '[' token
> > ./r600_pipe.h:946: error: expected primary-expression before '[' token
> > ./r600_pipe.h:947: error: expected primary-expression before '[' token
> > ./r600_pipe.h:948: error: expected primary-expression before '[' token
Re: [Mesa-dev] [PATCH 02/16] loader: slim down loader_get_pci_id_for_fd implementation(s)
On Tue, Oct 11, 2016 at 07:31:46PM +0100, Emil Velikov wrote:
> From: Emil Velikov
>
> Currently mesa has three code paths in the loader - libudev, manual
> sysfs and drm ioctl one.
>
> Considering the issues we had with libudev - strip those down in favour
> of the libdrm drm device API. The latter can be implemented in any way
> depending on the platform and can be reused by others.
>
> Cc: Jonathan Gray
> Cc: Jean-S??bastien P??dron
> Signed-off-by: Emil Velikov
> ---
> Jonathan, Jean-S??bastien I believe I've prodded you guys for a *BSD
> implementation of the drm*Device API a while back. With this commit
> you'll be 'forced' to prep some ;-)
It has been a while since I looked into that. The design seemed to
assume that the user running code that called into libdrm had the
ability to enumerate pci busses.
On OpenBSD /dev/pci* is only read/writable by root. /dev/drm* is
chowned after a user logs into a console.
We don't use filesystems for communicating with the kernel like linux
does so ioctls are really the best fit. The loader parts used at the
moment use drm driver specific ioctls, hopefully a generic version of
those that can return the vid/pid, subids and function id numbers would
cover most of it.
>
> About the implementation itself feel free to use libudev/equivalent (we
> cannot do so on Linux, since due to fun interactions with Steam's one)
> or any other means available on your platform. Fwiw I would strongly
> suggest _against_ adding DRM specific ioctls just for this purpose but
> at the end of the day it's your code/userbase.
>
> On the FreeBSD/DragonFly side this means that you no londer require a
> handful of patches for mesa, which is always a plus.
> ---
> src/loader/loader.c | 172
> +---
> 1 file changed, 16 insertions(+), 156 deletions(-)
>
> diff --git a/src/loader/loader.c b/src/loader/loader.c
> index 3e60e4c..41ea016 100644
> --- a/src/loader/loader.c
> +++ b/src/loader/loader.c
> @@ -204,57 +204,6 @@ udev_device_new_from_fd(struct udev *udev, int fd)
> return device;
> }
>
> -static int
> -libudev_get_pci_id_for_fd(int fd, int *vendor_id, int *chip_id)
> -{
> - struct udev *udev = NULL;
> - struct udev_device *device = NULL, *parent;
> - const char *pci_id;
> - UDEV_SYMBOL(struct udev *, udev_new, (void));
> - UDEV_SYMBOL(struct udev_device *, udev_device_get_parent,
> - (struct udev_device *));
> - UDEV_SYMBOL(const char *, udev_device_get_property_value,
> - (struct udev_device *, const char *));
> - UDEV_SYMBOL(struct udev_device *, udev_device_unref,
> - (struct udev_device *));
> - UDEV_SYMBOL(struct udev *, udev_unref, (struct udev *));
> -
> - *chip_id = -1;
> -
> - if (dlsym_failed)
> - return 0;
> -
> - udev = udev_new();
> - device = udev_device_new_from_fd(udev, fd);
> - if (!device)
> - goto out;
> -
> - parent = udev_device_get_parent(device);
> - if (parent == NULL) {
> - log_(_LOADER_WARNING, "MESA-LOADER: could not get parent device\n");
> - goto out;
> - }
> -
> - pci_id = udev_device_get_property_value(parent, "PCI_ID");
> - if (pci_id == NULL) {
> - log_(_LOADER_INFO, "MESA-LOADER: no PCI ID\n");
> - *chip_id = -1;
> - goto out;
> - } else if (sscanf(pci_id, "%x:%x", vendor_id, chip_id) != 2) {
> - log_(_LOADER_WARNING, "MESA-LOADER: malformed PCI ID\n");
> - *chip_id = -1;
> - goto out;
> - }
> -
> -out:
> - if (device)
> - udev_device_unref(device);
> - if (udev)
> - udev_unref(udev);
> -
> - return (*chip_id >= 0);
> -}
> -
> static char *
> get_render_node_from_id_path_tag(struct udev *udev,
> char *id_path_tag,
> @@ -471,113 +420,32 @@ dev_node_from_fd(int fd, unsigned int *maj, unsigned
> int *min)
> }
> #endif
>
> -#if defined(HAVE_SYSFS)
> -static int
> -sysfs_get_pci_id_for_fd(int fd, int *vendor_id, int *chip_id)
> -{
> - unsigned int maj, min;
> - FILE *f;
> - char buf[0x40];
> -
> - if (dev_node_from_fd(fd, &maj, &min) < 0) {
> - *chip_id = -1;
> - return 0;
> - }
> -
> - snprintf(buf, sizeof(buf), "/sys/dev/char/%d:%d/device/vendor", maj, min);
> - if (!(f = fopen(buf, "r"))) {
> - *chip_id = -1;
> - return 0;
> - }
> - if (fscanf(f, "%x", vendor_id) != 1) {
> - *chip_id = -1;
> - fclose(f);
> - return 0;
> - }
> - fclose(f);
> - snpr
[Mesa-dev] [PATCH] egl/dri2: add a libname to dlopen for OpenBSD
On OpenBSD try to dlopen 'libglapi.so', ld.so will find
the highest major/minor version and open it in this case.
Avoids '#error Unknown glapi provider for this platform' at build time.
Signed-off-by: Jonathan Gray
---
src/egl/drivers/dri2/egl_dri2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
index 8785e31..9655a49 100644
--- a/src/egl/drivers/dri2/egl_dri2.c
+++ b/src/egl/drivers/dri2/egl_dri2.c
@@ -2802,7 +2802,7 @@ static EGLBoolean
dri2_load(_EGLDriver *drv)
{
struct dri2_egl_driver *dri2_drv = dri2_egl_driver(drv);
-#ifdef HAVE_ANDROID_PLATFORM
+#if defined(HAVE_ANDROID_PLATFORM) || defined(__OpenBSD__)
const char *libname = "libglapi.so";
#elif defined(__APPLE__)
const char *libname = "libglapi.0.dylib";
--
2.9.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] genxml: avoid using a GNU make pattern rule
% pattern rules are a GNU extension. Convert the use of one to a
inference rule to allow this to build on OpenBSD.
This is a related change to the one made in
e3d43dc5eae5271e2c87bab702aa7409d3dd0b23
Signed-off-by: Jonathan Gray
---
src/intel/Makefile.genxml.am | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/intel/Makefile.genxml.am b/src/intel/Makefile.genxml.am
index 519f30e..39f579c 100644
--- a/src/intel/Makefile.genxml.am
+++ b/src/intel/Makefile.genxml.am
@@ -34,7 +34,10 @@ $(GENXML_GENERATED_FILES): genxml/gen_pack_header.py
# xxd generates variable names based on the path of the input file. We
# prefer to generate our own name here, so it doesn't vary from
# in/out-of-tree builds.
-%_xml.h: %.xml Makefile
+
+$(GENXML_GENERATED_FILES): Makefile
+
+.xml_xml.h:
$(MKDIR_GEN)
$(AM_V_GEN) echo -n "static const uint8_t " > $@; \
echo "$(@F)_xml[] = {" | sed -e 's,_xml.h,,' >> $@; \
--
2.9.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] egl: remove docs directory from EXTRA_DIST
The egl docs directory no longer exists as of 88b5c36fe1a1546bf633ee161a6715efc593acbd. Remove it from EXTRA_DIST to unbreak 'make dist' Signed-off-by: Jonathan Gray --- src/egl/Makefile.am | 1 - 1 file changed, 1 deletion(-) diff --git a/src/egl/Makefile.am b/src/egl/Makefile.am index 95ee6cc..304b0d3 100644 --- a/src/egl/Makefile.am +++ b/src/egl/Makefile.am @@ -132,6 +132,5 @@ EXTRA_DIST = \ egl-symbols-check \ SConscript \ drivers/haiku \ - docs \ main/egl.def \ main/README.txt -- 2.9.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] genxml: add generated headers to EXTRA_DIST
Building the Mesa 12.0.3 distfile failed on a system without python as generated files were not included in the distfile. Cc: "12.0" Signed-off-by: Jonathan Gray --- src/intel/Makefile.genxml.am | 4 1 file changed, 4 insertions(+) diff --git a/src/intel/Makefile.genxml.am b/src/intel/Makefile.genxml.am index 39f579c..2df223a 100644 --- a/src/intel/Makefile.genxml.am +++ b/src/intel/Makefile.genxml.am @@ -23,6 +23,10 @@ BUILT_SOURCES += \ $(GENXML_GENERATED_FILES) \ $(AUBINATOR_GENERATED_FILES) +EXTRA_DIST += \ + $(GENXML_GENERATED_FILES) \ + $(AUBINATOR_GENERATED_FILES) + SUFFIXES = _pack.h _xml.h .xml $(GENXML_GENERATED_FILES): genxml/gen_pack_header.py -- 2.9.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa: automake: include mesa_glinterop.h in distfile
Add mesa_glinterop.h to the list of headers that will get included in the distfile as it is required to build Mesa itself. Corrects a regression introduced in a89faa2022fd995af2019c886b152b49a01f9392. Signed-off-by: Jonathan Gray --- src/Makefile.am | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/Makefile.am b/src/Makefile.am index 17c8798..b63d135 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -131,7 +131,8 @@ SUBDIRS += gallium endif EXTRA_DIST = \ - getopt hgl SConscript + getopt hgl SConscript \ + $(top_srcdir)/include/GL/mesa_glinterop.h AM_CFLAGS = $(VISIBILITY_CFLAGS) AM_CXXFLAGS = $(VISIBILITY_CXXFLAGS) -- 2.9.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] genxml: add generated headers to EXTRA_DIST
On Sun, Oct 16, 2016 at 11:08:42PM +1100, Jonathan Gray wrote: > Building the Mesa 12.0.3 distfile failed on a system without python > as generated files were not included in the distfile. > > Cc: "12.0" > Signed-off-by: Jonathan Gray > --- > src/intel/Makefile.genxml.am | 4 > 1 file changed, 4 insertions(+) > > diff --git a/src/intel/Makefile.genxml.am b/src/intel/Makefile.genxml.am > index 39f579c..2df223a 100644 > --- a/src/intel/Makefile.genxml.am > +++ b/src/intel/Makefile.genxml.am > @@ -23,6 +23,10 @@ BUILT_SOURCES += \ > $(GENXML_GENERATED_FILES) \ > $(AUBINATOR_GENERATED_FILES) > > +EXTRA_DIST += \ > + $(GENXML_GENERATED_FILES) \ > + $(AUBINATOR_GENERATED_FILES) > + > SUFFIXES = _pack.h _xml.h .xml > > $(GENXML_GENERATED_FILES): genxml/gen_pack_header.py > -- > 2.9.3 The makefiles are different on the 12.0 branch and there is no aubinator. Here is a patch against the 12.0 branch: diff --git a/src/intel/genxml/Makefile.am b/src/intel/genxml/Makefile.am index f98cf78..32f5ace 100644 --- a/src/intel/genxml/Makefile.am +++ b/src/intel/genxml/Makefile.am @@ -37,6 +37,7 @@ endif CLEANFILES = $(BUILT_SOURCES) EXTRA_DIST = \ + $(GENXML_GENERATED_FILES) \ gen6.xml \ gen7.xml \ gen75.xml \ ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/3] aubinator: stop using non portable error() function
error() is a gnu extension and is not present on OpenBSD
and likely other systems.
Convert use of error to fprintf/strerror/exit.
Signed-off-by: Jonathan Gray
---
src/intel/tools/aubinator.c | 46 +
1 file changed, 30 insertions(+), 16 deletions(-)
diff --git a/src/intel/tools/aubinator.c b/src/intel/tools/aubinator.c
index 811f707..66107711 100644
--- a/src/intel/tools/aubinator.c
+++ b/src/intel/tools/aubinator.c
@@ -30,7 +30,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -794,8 +793,10 @@ handle_trace_block(struct gen_spec *spec, uint32_t *p)
case AUB_TRACE_OP_DATA_WRITE:
if (address_space != AUB_TRACE_MEMTYPE_GTT)
break;
- if (gtt_size < offset + size)
- error(EXIT_FAILURE, errno, "overflow gtt space");
+ if (gtt_size < offset + size) {
+ fprintf(stderr, "overflow gtt space: %s", strerror(errno));
+ exit(EXIT_FAILURE);
+ }
memcpy((char *) gtt + offset, data, size);
if (gtt_end < offset + size)
gtt_end = offset + size;
@@ -834,16 +835,22 @@ aub_file_open(const char *filename)
file = malloc(sizeof *file);
file->filename = strdup(filename);
file->fd = open(file->filename, O_RDONLY);
- if (file->fd == -1)
- error(EXIT_FAILURE, errno, "open %s failed", file->filename);
+ if (file->fd == -1) {
+ fprintf(stderr, "open %s failed: %s", file->filename, strerror(errno));
+ exit(EXIT_FAILURE);
+ }
- if (fstat(file->fd, &file->sb) == -1)
- error(EXIT_FAILURE, errno, "stat failed");
+ if (fstat(file->fd, &file->sb) == -1) {
+ fprintf(stderr, "stat failed: %s", strerror(errno));
+ exit(EXIT_FAILURE);
+ }
file->map = mmap(NULL, file->sb.st_size,
PROT_READ, MAP_SHARED, file->fd, 0);
- if (file->map == MAP_FAILED)
- error(EXIT_FAILURE, errno, "mmap failed");
+ if (file->map == MAP_FAILED) {
+ fprintf(stderr, "mmap failed: %s", strerror(errno));
+ exit(EXIT_FAILURE);
+ }
file->cursor = file->map;
file->end = file->map + file->sb.st_size / 4;
@@ -852,8 +859,10 @@ aub_file_open(const char *filename)
gtt_size = 1ul << 40;
gtt = mmap(NULL, gtt_size, PROT_READ | PROT_WRITE,
MAP_PRIVATE | MAP_ANONYMOUS | MAP_NORESERVE, -1, 0);
- if (gtt == MAP_FAILED)
- error(EXIT_FAILURE, errno, "failed to alloc gtt space");
+ if (gtt == MAP_FAILED) {
+ fprintf(stderr, "failed to alloc gtt space: %s", strerror(errno));
+ exit(1);
+ }
return file;
}
@@ -1056,8 +1065,10 @@ int main(int argc, char *argv[])
} else if (strcmp(argv[i], "--no-offsets") == 0) {
option_print_offsets = false;
} else if (is_prefix(argv[i], "--gen", &value)) {
- if (value == NULL)
-error(EXIT_FAILURE, 0, "option '--gen' requires an argument\n");
+ if (value == NULL) {
+fprintf(stderr, "option '--gen' requires an argument\n");
+exit(EXIT_FAILURE);
+ }
found_arg_gen = true;
gen_major = 0;
gen_minor = 0;
@@ -1071,8 +1082,10 @@ int main(int argc, char *argv[])
option_color = COLOR_NEVER;
else if (strcmp(value, "auto") == 0)
option_color = COLOR_AUTO;
- else
-error(EXIT_FAILURE, 0, "invalid value for --color: %s", value);
+ else {
+fprintf(stderr, "invalid value for --color: %s", value);
+exit(EXIT_FAILURE);
+ }
} else if (strcmp(argv[i], "--help") == 0) {
print_help(stdout);
exit(EXIT_SUCCESS);
@@ -1131,8 +1144,9 @@ int main(int argc, char *argv[])
gen_major = 9;
gen_minor = 0;
} else {
- error(EXIT_FAILURE, 0, "can't parse gen: %s, expected ivb, byt, hsw, "
+ fprintf(stderr, "can't parse gen: %s, expected ivb, byt, hsw, "
"bdw, chv, skl, kbl or bxt\n", gen_val);
+ exit(EXIT_FAILURE);
}
/* Do this before we redirect stdout to pager. */
--
2.9.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/3] aubinator: only use program_invocation_short_name with glibc/cygwin
program_invocation_short_name is a gnu extension. Limit use of it
to glibc and cygwin and otherwise use getprogname() which is available
on BSD and OS X.
Signed-off-by: Jonathan Gray
---
src/intel/tools/aubinator.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/src/intel/tools/aubinator.c b/src/intel/tools/aubinator.c
index df84469..fe1f369 100644
--- a/src/intel/tools/aubinator.c
+++ b/src/intel/tools/aubinator.c
@@ -1014,6 +1014,12 @@ setup_pager(void)
static void
print_help(FILE *file)
{
+ const char *progname;
+#if defined(__GLIBC__) || defined(__CYGWIN__)
+ progname = program_invocation_short_name;
+#else
+ progname = getprogname();
+#endif
fprintf(file,
"Usage: %s [OPTION]... FILE\n"
"Decode aub file contents.\n\n"
@@ -1025,7 +1031,7 @@ print_help(FILE *file)
"if omitted), 'always', or 'never'\n"
" --no-pager don't launch pager\n"
" --no-offsetsdon't print instruction offsets\n",
- basename(program_invocation_name));
+ basename(progname));
}
static bool
--
2.9.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] Disable the code that allocates W|X memory on OpenBSD
OpenBSD now has strict W^X enforcement. Processes that violate
the policy get killed by the kernel. Don't attempt to use
executable memory on OpenBSD to avoid this.
Patch from Mark Kettenis.
Cc: 11.2 12.0
Signed-off-by: Mark Kettenis
Signed-off-by: Jonathan Gray
---
src/gallium/auxiliary/rtasm/rtasm_execmem.c | 12
src/mapi/u_execmem.c| 9 -
src/mesa/main/execmem.c | 15 ++-
3 files changed, 34 insertions(+), 2 deletions(-)
diff --git a/src/gallium/auxiliary/rtasm/rtasm_execmem.c
b/src/gallium/auxiliary/rtasm/rtasm_execmem.c
index f7e605e..edbb459 100644
--- a/src/gallium/auxiliary/rtasm/rtasm_execmem.c
+++ b/src/gallium/auxiliary/rtasm/rtasm_execmem.c
@@ -69,6 +69,16 @@ static struct mem_block *exec_heap = NULL;
static unsigned char *exec_mem = NULL;
+#ifdef __OpenBSD__
+
+static int
+init_heap(void)
+{
+ return 0;
+}
+
+#else
+
static int
init_heap(void)
{
@@ -83,6 +93,8 @@ init_heap(void)
return (exec_mem != MAP_FAILED);
}
+#endif
+
void *
rtasm_exec_malloc(size_t size)
diff --git a/src/mapi/u_execmem.c b/src/mapi/u_execmem.c
index 89d5c1d..3af9d0a 100644
--- a/src/mapi/u_execmem.c
+++ b/src/mapi/u_execmem.c
@@ -45,8 +45,15 @@ static unsigned int head = 0;
static unsigned char *exec_mem = (unsigned char *)0;
+#if defined(__OpenBSD__)
-#if defined(__linux__) || defined(__OpenBSD__) || defined(_NetBSD__) ||
defined(__sun) || defined(__HAIKU__)
+static int
+init_map(void)
+{
+ return 0;
+}
+
+#elif defined(__linux__) || defined(_NetBSD__) || defined(__sun) ||
defined(__HAIKU__)
#include
#include
diff --git a/src/mesa/main/execmem.c b/src/mesa/main/execmem.c
index 3a13385..87e4a38 100644
--- a/src/mesa/main/execmem.c
+++ b/src/mesa/main/execmem.c
@@ -36,7 +36,20 @@
-#if defined(__linux__) || defined(__OpenBSD__) || defined(_NetBSD__) ||
defined(__sun) || defined(__HAIKU__)
+#if defined(__OpenBSD__)
+
+void *
+_mesa_exec_malloc(GLuint size)
+{
+ return NULL;
+}
+
+void
+_mesa_exec_free(void *addr)
+{
+}
+
+#elif defined(__linux__) || defined(_NetBSD__) || defined(__sun) ||
defined(__HAIKU__)
/*
* Allocate a large block of memory which can hold code then dole it out
--
2.9.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/3] aubinator: include libgen.h for basename(3)
Include libgen.h for basename as required by posix. The definition is not found on at least OpenBSD otherwise. Signed-off-by: Jonathan Gray --- src/intel/tools/aubinator.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/intel/tools/aubinator.c b/src/intel/tools/aubinator.c index 66107711..df84469 100644 --- a/src/intel/tools/aubinator.c +++ b/src/intel/tools/aubinator.c @@ -30,6 +30,7 @@ #include #include #include +#include #include #include #include -- 2.9.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/5] mesa: bump required GCC version to 4.8.0
LLVM was imported yes, but the integration of it has only
started around the same time and it is not enabled by default yet.
And it was only imported around two days or so ago.
And LLVM does not support all the architectures OpenBSD builds Mesa
on.
Can you point to something specific that needs a newer GCC version?
Do you want to target c++11 or the like?
We have patched the GCC included in the base tree multiple times
to support Mesa and could possibly do so again if you mention
specifics.
On Wed, Sep 07, 2016 at 02:28:16PM +1000, Timothy Arceri wrote:
> The last time this was bumped we settled on 4.2.0 because OpenBSD
> wasn't shipping anything greater than 4.2.1 (as that was the last
> GPLv2 licensed version) however they have now imported llvm to
> there base repo.
>
> As far as I can tell the oldest distro still using a current version
> of Mesa is Red Hat Enterprise Linux 6 which ships with 4.4.7. However
> Dave reported that they build Mesa with GCC 4.8.
>
> Cc: Jonathan Gray
> ---
> configure.ac | 18 +++---
> include/c99_compat.h | 17 +++--
> 2 files changed, 10 insertions(+), 25 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index a413a3a..5128fc4 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -171,7 +171,6 @@ AC_MSG_RESULT([$acv_mesa_CLANG])
> dnl If we're using GCC, make sure that it is at least version 4.2.0. Older
> dnl versions are explictly not supported.
> GEN_ASM_OFFSETS=no
> -USE_GNU99=no
> if test "x$GCC" = xyes -a "x$acv_mesa_CLANG" = xno; then
> AC_MSG_CHECKING([whether gcc version is sufficient])
> major=0
> @@ -183,16 +182,13 @@ if test "x$GCC" = xyes -a "x$acv_mesa_CLANG" = xno; then
> GCC_VERSION_MINOR=`echo $GCC_VERSION | cut -d. -f2`
> fi
>
> -if test $GCC_VERSION_MAJOR -lt 4 -o $GCC_VERSION_MAJOR -eq 4 -a
> $GCC_VERSION_MINOR -lt 2 ; then
> +if test $GCC_VERSION_MAJOR -lt 4 -o $GCC_VERSION_MAJOR -eq 4 -a
> $GCC_VERSION_MINOR -lt 8 ; then
> AC_MSG_RESULT([no])
> -AC_MSG_ERROR([If using GCC, version 4.2.0 or later is required.])
> +AC_MSG_ERROR([If using GCC, version 4.8.0 or later is required.])
> else
> AC_MSG_RESULT([yes])
> fi
>
> -if test $GCC_VERSION_MAJOR -lt 4 -o $GCC_VERSION_MAJOR -eq 4 -a
> $GCC_VERSION_MINOR -lt 6 ; then
> -USE_GNU99=yes
> -fi
> if test "x$cross_compiling" = xyes; then
> GEN_ASM_OFFSETS=yes
> fi
> @@ -269,12 +265,7 @@ AM_CONDITIONAL(HAVE_ANDROID, test "x$android" = xyes)
> dnl Add flags for gcc and g++
> if test "x$GCC" = xyes; then
> CFLAGS="$CFLAGS -Wall"
> -
> -if test "x$USE_GNU99" = xyes; then
> - CFLAGS="$CFLAGS -std=gnu99"
> -else
> - CFLAGS="$CFLAGS -std=c99"
> -fi
> +CFLAGS="$CFLAGS -std=c99"
>
> # Enable -Werror=implicit-function-declaration and
> # -Werror=missing-prototypes, if available, or otherwise, just
> @@ -401,9 +392,6 @@ AC_MSG_CHECKING(whether gcc supports -mpower8-vector)
> save_CFLAGS=$CFLAGS
> CFLAGS="$PWR8_CFLAGS $CFLAGS"
> AC_COMPILE_IFELSE([AC_LANG_SOURCE([[
> -#if defined(__GNUC__) && (__GNUC__ < 4 || (__GNUC__ == 4 && __GNUC_MINOR__ <
> 8))
> -#error "Need GCC >= 4.8 for sane POWER8 support"
> -#endif
> #include
> int main () {
> vector unsigned char r;
> diff --git a/include/c99_compat.h b/include/c99_compat.h
> index 24e96e0..d76171c 100644
> --- a/include/c99_compat.h
> +++ b/include/c99_compat.h
> @@ -145,8 +145,8 @@ test_c99_compat_h(const void * restrict a,
> # endif
>
> # ifdef __GNUC__
> -#if __GNUC__ < 4 || (__GNUC__ == 4 && __GNUC_MINOR__ < 2)
> -# error "GCC version 4.2 or higher required"
> +#if __GNUC__ < 4 || (__GNUC__ == 4 && __GNUC_MINOR__ < 8)
> +# error "GCC version 4.8 or higher required"
> #endif
>
> /* https://gcc.gnu.org/onlinedocs/gcc-4.2.4/gcc/Other-Builtins.html */
> @@ -164,15 +164,12 @@ test_c99_compat_h(const void * restrict a,
> #define HAVE_FUNC_ATTRIBUTE_FORMAT 1
> #define HAVE_FUNC_ATTRIBUTE_PACKED 1
>
> -#if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 3)
> - /* https://gcc.gnu.org/onlinedocs/gcc-4.3.6/gcc/Other-Builtins.html */
> -# define HAVE___BUILTIN_BSWAP32 1
> -# define HAVE___BUILTIN_BSWAP64 1
> -#endif
> + /* https://gcc.gnu.org/onlinedocs/gcc-4.3.6/gcc/Other-Builtins.html */
> +#define HAVE___BUILTIN_BSWAP32 1
> +#define HAVE___BUILTIN_BSWAP64 1
>
> -#if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 5)
> -# define HAVE___BUILTIN_UNREACHABLE 1
> -#endif
> + /* GCC 4.5 */
> +#define HAVE___BUILTIN_UNREACHABLE 1
>
> # endif /* __GNUC__ */
>
> --
> 2.7.4
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/5] mesa: bump required GCC version to 4.8.0
On Wed, Sep 07, 2016 at 11:52:39PM +1000, Timothy Arceri wrote: > On Wed, 2016-09-07 at 19:26 +1000, Jonathan Gray wrote: > > LLVM was imported yes, but the integration of it has only > > started around the same time and it is not enabled by default yet. > > And it was only imported around two days or so ago. > > > > Which means its a good time to start a discussion on what the inclusion means > for Mesa :) > > > And LLVM does not support all the architectures OpenBSD builds Mesa > > on. > > > > Can you point to something specific that needs a newer GCC version? > > Do you want to target c++11 or the like? > > We have discussed specific features in the past. At this point its move about > giving developers the freedom to use any new features they wish. And > ultimately the ability to bump the required version again in future. > > It seems you are talking about the possibly of never switching to clang for > building Mesa and sticking with gcc 4.2 for years to come. There is also the > issue as I understand it that your gcc 4.2 is not really gcc 4.2, as you say > features have been back ported to support Mesa so its possible that Mesa would > not even build for a normal gcc 4.2 build and our build requirements act more > as a restriction on developers using features rather than enforcing a building > requirement.?? You seem to have misinterpreted. The current plan is to switch some architectures to clang in the future. If your patch gets committed to Mesa I'll have to either revert it locally or stop updating Mesa in the short term. Ideally configure would be a bit more intelligent and test functionality rather than a version number. I don't have a full list of changes made to acommodate Mesa, here are some found with a quick search, I believe FreeBSD has also adopted many of these. - binary integer constants (gnu extension clang also has) http://marc.info/?l=openbsd-cvs&m=137290441510098&w=2 - support for \ in regcomp (sysv/gnu extension) http://marc.info/?l=openbsd-cvs&m=141019114911164&w=2 - named initialisers for anonymous structs/unions (required by C11) http://marc.info/?l=openbsd-cvs&m=146244074408249&w=2 alpha ICE fix with __sync builtins http://marc.info/?l=openbsd-cvs&m=145663405924066&w=2 i386 fix __sync_val_compare_and_swap_8() for -fPIC http://marc.info/?l=openbsd-cvs&m=144898317222499&w=2 The sync builtins are assumed to be present on architectures where they are not available at the instruction level. GCC was modified to additionally provide/expand these on at least mips64 and alpha. mips bfd -Bsymbolic fix http://marc.info/?l=openbsd-cvs&m=144856828610069&w=2 enum attribute handling fix http://marc.info/?l=openbsd-cvs&m=144421363218215&w=2 recognise 'F'/'f' suffix for indent (cat is now used if gnu indent not found) http://marc.info/?l=openbsd-cvs&m=142190494629047&w=2 > It is my feeling that we should be bumping the gcc requirements for Mesa based > on the actual gcc project. Freezing the limit at the version of a forked gcc > variant, and using features from higher versions that have been back ported to > that fork seems backwards to me. > > To me the current situation seems??untenable, besides the issues with having a > minimum version that won't actually build Mesa I don't believe we should be > forced to worry about ancient compilers indefinitely??due to the > decisions??of a > singe distro. In my opinion we should bump the version and let OpenBSD resolve > any issues however it sees fit (patch gcc/mesa, freeze mesa, etc). Others may > feel differently. There are already various local patches required to build Mesa, many pending review. Another could be added. Subportions of the Mesa tree such as those that aren't built by visual studio or recently merged projects such as the intel vulkan support already assume the compiler is a new version of gcc in my experience. It seems anonymous structs/unions turned up everywhere when redhat declared the rhel version which didn't have them eol for example. Where as the vulkan code seems to directly depend on linux syscalls for at least futexes and memfd (checks for which should be added to configure as well, currently the build errors out). ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Disable the code that allocates W|X memory on OpenBSD
On Thu, Sep 08, 2016 at 06:57:44PM +0100, Emil Velikov wrote:
> On 1 September 2016 at 18:23, Jonathan Gray wrote:
> > OpenBSD now has strict W^X enforcement. Processes that violate
> > the policy get killed by the kernel. Don't attempt to use
> > executable memory on OpenBSD to avoid this.
> >
> > Patch from Mark Kettenis.
> >
>
> > --- a/src/gallium/auxiliary/rtasm/rtasm_execmem.c
> > +++ b/src/gallium/auxiliary/rtasm/rtasm_execmem.c
> > @@ -69,6 +69,16 @@ static struct mem_block *exec_heap = NULL;
> > static unsigned char *exec_mem = NULL;
> >
> >
> > +#ifdef __OpenBSD__
> > +
> > +static int
> > +init_heap(void)
> > +{
> > + return 0;
> > +}
> Afaict this is equivalent to using the #else path in translate_see.c.
> In general I'm wondering if we can/should not have a configure toggle
> for this. Then again please look below.
>
>
> > --- a/src/mapi/u_execmem.c
> > +++ b/src/mapi/u_execmem.c
> > @@ -45,8 +45,15 @@ static unsigned int head = 0;
> >
> > static unsigned char *exec_mem = (unsigned char *)0;
> >
> > +#if defined(__OpenBSD__)
> >
> > -#if defined(__linux__) || defined(__OpenBSD__) || defined(_NetBSD__) ||
> > defined(__sun) || defined(__HAIKU__)
> > +static int
> > +init_map(void)
> > +{
> > + return 0;
> > +}
> > +
> And this one to --disable-glx-tls and/or --disable-asm. Which reminds
> me of - have you guys tried enabling either/both of them. Has there
> been (m)any issues ?
>
> For a long while the intent has been to use --enable-glx-tls by
> default and kill off the other codepaths. But with the write xor
> execute policy, it's going to be (close to) impossible.
Full tls support is not in the OpenBSD tree currently, though the
remaining parts were being looked at including enabling tls with Mesa
last week. I'm not sure what state that work is in currently.
> Have you guys considered a way to disable the restriction for usecases
> that need the behaviour ?
The limited exceptions involve flagging binaries and having to mount
the filesystem containing them with a flag. This is mostly a temporary
measure as I understand it and libraries especially should not be creating
W|X mappings.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/3] aubinator: only use program_invocation_short_name with glibc/cygwin
On Mon, Sep 12, 2016 at 09:28:58AM +1000, Timothy Arceri wrote:
> On Thu, 2016-09-08 at 18:39 +0100, Emil Velikov wrote:
> > On 1 September 2016 at 18:12, Jonathan Gray wrote:
> > >
> > > program_invocation_short_name is a gnu extension.Limit use of it
> > > to glibc and cygwin and otherwise use getprogname() which is
> > > available
> > > on BSD and OS X.
> > >
> > > Signed-off-by: Jonathan Gray
> > > ---
> > > ??src/intel/tools/aubinator.c | 8 +++-
> > > ??1 file changed, 7 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/src/intel/tools/aubinator.c
> > > b/src/intel/tools/aubinator.c
> > > index df84469..fe1f369 100644
> > > --- a/src/intel/tools/aubinator.c
> > > +++ b/src/intel/tools/aubinator.c
> > > @@ -1014,6 +1014,12 @@ setup_pager(void)
> > > ??static void
> > > ??print_help(FILE *file)
> > > ??{
> > > +??const char *progname;
> > > +#if defined(__GLIBC__) || defined(__CYGWIN__)
> > > +??progname = program_invocation_short_name;
> > > +#else
> > > +??progname = getprogname();
> > > +#endif
> > We could really fold the ~5 hunks somehow. Then again it shouldn't
> > block this fix from getting it.
> >
> > R-b and pushed the series. Thanks !
> > Emil
>
> This is causing a warning in GCC:
>
> aubinator.c: In function ???print_help???:
> aubinator.c:1034:21: warning: passing argument 1 of ???__xpg_basename???
> discards ???const??? qualifier from pointer target type [-Wdiscarded-
> qualifiers]
> basename(progname));
> ??^~~~
> In file included from aubinator.c:33:0:
> /usr/include/libgen.h:34:14: note: expected ???char *??? but argument is of
> type ???const char *???
> ??extern char *__xpg_basename (char *__path) __THROW;
> ^~
getprogname() returns const, it seems odd that program_invocation_short_name
would not be as well.
Note that the gallium code in src/gallium/auxiliary/os/os_process.c
os_get_process_name() also stores program_invocation_short_name in
"const char *".
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] aubinator: rework print_help()
On Mon, Sep 12, 2016 at 12:59:11PM +0100, Emil Velikov wrote:
> From: Emil Velikov
>
> Rather than using platform specific methods to retrieve the program
> name pass it explicitly. The function is called directly from main().
>
> Similarly - basename comes in two versions POSIX (can modify string,
> always pass a copy) and GNU (never modifies the string).
>
> Just printout the complete program name, esp. since the program is not
> meant to be installed, thus using $basename is unlikely to work, not to
> mention it is misleading.
>
> Cc: Jonathan Gray
> Cc: Timothy Arceri
> Signed-off-by: Emil Velikov
Looks good and builds here.
Reviewed-by: Jonathan Gray
> ---
> src/intel/tools/aubinator.c | 17 +
> 1 file changed, 5 insertions(+), 12 deletions(-)
>
> diff --git a/src/intel/tools/aubinator.c b/src/intel/tools/aubinator.c
> index fe1f369..9d29b68 100644
> --- a/src/intel/tools/aubinator.c
> +++ b/src/intel/tools/aubinator.c
> @@ -30,7 +30,6 @@
> #include
> #include
> #include
> -#include
> #include
> #include
> #include
> @@ -1012,14 +1011,8 @@ setup_pager(void)
> }
>
> static void
> -print_help(FILE *file)
> +print_help(const char *progname, FILE *file)
> {
> - const char *progname;
> -#if defined(__GLIBC__) || defined(__CYGWIN__)
> - progname = program_invocation_short_name;
> -#else
> - progname = getprogname();
> -#endif
> fprintf(file,
> "Usage: %s [OPTION]... FILE\n"
> "Decode aub file contents.\n\n"
> @@ -1031,7 +1024,7 @@ print_help(FILE *file)
> "if omitted), 'always', or 'never'\n"
> " --no-pager don't launch pager\n"
> " --no-offsetsdon't print instruction offsets\n",
> - basename(progname));
> + progname);
> }
>
> static bool
> @@ -1062,7 +1055,7 @@ int main(int argc, char *argv[])
> char gen_file[256], gen_val[24];
>
> if (argc == 1) {
> - print_help(stderr);
> + print_help(argv[0], stderr);
>exit(EXIT_FAILURE);
> }
>
> @@ -1094,7 +1087,7 @@ int main(int argc, char *argv[])
> exit(EXIT_FAILURE);
> }
>} else if (strcmp(argv[i], "--help") == 0) {
> - print_help(stdout);
> + print_help(argv[0], stdout);
> exit(EXIT_SUCCESS);
>} else {
> if (argv[i][0] == '-') {
> @@ -1174,7 +1167,7 @@ int main(int argc, char *argv[])
> disasm = gen_disasm_create(pci_id);
>
> if (argv[i] == NULL) {
> - print_help(stderr);
> + print_help(argv[0], stderr);
> exit(EXIT_FAILURE);
> } else {
> file = aub_file_open(argv[i]);
> --
> 2.9.3
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] egl/dri2: add a libname to dlopen for OpenBSD
On Mon, Oct 17, 2016 at 12:39:11PM +0100, Emil Velikov wrote:
> On 17 October 2016 at 10:53, Eric Engestrom wrote:
> > On Sunday, 2016-10-16 16:38:35 +1100, Jonathan Gray wrote:
> >> On OpenBSD try to dlopen 'libglapi.so', ld.so will find
> >> the highest major/minor version and open it in this case.
> >>
> >> Avoids '#error Unknown glapi provider for this platform' at build time.
> >>
> >> Signed-off-by: Jonathan Gray
> >
> > LGTM, and I guess the other *BSD will want the same since 7a9c92d0 broke
> > them too.
> >
> I'm not 100% sure about that. OpenBSD (unlike other BSD) did bump the
> major when the ABI breaks due to 'internal' changes - think of
> off_t/time_t on 32 vs 64bit systems and alike.
>
> Unlike Linux kernel/distros, BSDs tend to be more relaxed when in
> comes to ABI, I believe. Don't quote me on that one ;-)
OpenBSD tends to favour simplified interfaces over backwards compatiblity
and is more like a research system in that respect. As the kernel
and userland are one source tree ioctl compat largely doesn't exist.
System calls get deprecated and removed over the course of a few releases.
So we didn't go through the pain of duplicated systems calls for off_t
as mentioned, and don't go in for symbol versioning. Just major.minor
library versioning, which is roughly symbol removals, major crank,
symbol additions minor crank.
I believe FreeBSD tends to go in for backwards compatibility more
but am not familiar with the details. They also have a different ld.so.
Perhaps an else case for 'libglapi.so.0' would be appropriate for all
the other various unices instead of the #error ?
>
> > Fixes: 7a9c92d071d010066349 ("egl/dri2: non-shared glapi cleanups")
> > Reviewed-by: Eric Engestrom
> >
> > Side note, I don't understand why we hardcode the version everywhere
> > (except Android). I can see it's been like that since that code was
> > added nearly 6 years ago (218381d9), but I couldn't find an explanation
> > in the logs, or any mention of it in the thread I found [1].
> > Emil, do you know?
> >
> The ABI must be stable. Since a) we (and linux distros in general)
> have the greater flexibility to "mix and match" components and b)
> glapi is/was used by xserver as well, the initial goal was that the
> ABI should not break, ever. See some the src/mapi changes by Brian
> Paul, which rework the nop calls due to different calling convention
> and stack corruption on Windows and the follow up fix to keep those
> Windows only and stable for everyone else
> be71bbfaa2ad201b570b56847a13328fc359d0ee.
>
> Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] egl/dri2: add a libname to dlopen for OpenBSD
On Mon, Oct 17, 2016 at 05:34:02PM +0100, Emil Velikov wrote: > On 17 October 2016 at 16:39, Eric Engestrom wrote: > > On Monday, 2016-10-17 22:53:20 +1100, Jonathan Gray wrote: > >> On Mon, Oct 17, 2016 at 12:39:11PM +0100, Emil Velikov wrote: > >> > On 17 October 2016 at 10:53, Eric Engestrom > >> > wrote: > >> > > On Sunday, 2016-10-16 16:38:35 +1100, Jonathan Gray wrote: > >> > >> On OpenBSD try to dlopen 'libglapi.so', ld.so will find > >> > >> the highest major/minor version and open it in this case. > >> > >> > >> > >> Avoids '#error Unknown glapi provider for this platform' at build > >> > >> time. > >> > >> > >> > >> Signed-off-by: Jonathan Gray > >> > > > >> > > LGTM, and I guess the other *BSD will want the same since 7a9c92d0 > >> > > broke > >> > > them too. > >> > > > >> > I'm not 100% sure about that. OpenBSD (unlike other BSD) did bump the > >> > major when the ABI breaks due to 'internal' changes - think of > >> > off_t/time_t on 32 vs 64bit systems and alike. > >> > > >> > Unlike Linux kernel/distros, BSDs tend to be more relaxed when in > >> > comes to ABI, I believe. Don't quote me on that one ;-) > >> > >> OpenBSD tends to favour simplified interfaces over backwards compatiblity > >> and is more like a research system in that respect. As the kernel > >> and userland are one source tree ioctl compat largely doesn't exist. > >> System calls get deprecated and removed over the course of a few releases. > >> So we didn't go through the pain of duplicated systems calls for off_t > >> as mentioned, and don't go in for symbol versioning. Just major.minor > >> library versioning, which is roughly symbol removals, major crank, > >> symbol additions minor crank. > >> > >> I believe FreeBSD tends to go in for backwards compatibility more > >> but am not familiar with the details. They also have a different ld.so. > >> > >> Perhaps an else case for 'libglapi.so.0' would be appropriate for all > >> the other various unices instead of the #error ? > > > > Yeah actually, I'm thinking reverting this hunk of 7a9c92d0 might be a > > better, > > to avoid the potentially huge list of every *BSD and other Unix: > > > Fwiw I've intentionally added the hunk since I was a bit lazy to check > if the BSD(s?)/Solaris/others have bumped the major locally. Having a > closer look that's not the case, so indeed we can add revert to > libglapi.so.0 in the else statement. > > Jonathan, how about we with the above instead ? At the moment OpenBSD has libglapi.so.0.2 for Mesa 11.2.2. New versions of Mesa add new shared_dispatch_stub_* symbols, which the minor would crank for. I'd prefer the diff I mailed for OpenBSD for if the major version should crank for some reason. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] egl/dri2: add a libname to dlopen for OpenBSD
On Tue, Oct 18, 2016 at 04:24:20PM +0100, Emil Velikov wrote: > On 18 October 2016 at 00:58, Jonathan Gray wrote: > > On Mon, Oct 17, 2016 at 05:34:02PM +0100, Emil Velikov wrote: > >> On 17 October 2016 at 16:39, Eric Engestrom > >> wrote: > >> > On Monday, 2016-10-17 22:53:20 +1100, Jonathan Gray wrote: > >> >> On Mon, Oct 17, 2016 at 12:39:11PM +0100, Emil Velikov wrote: > >> >> > On 17 October 2016 at 10:53, Eric Engestrom > >> >> > wrote: > >> >> > > On Sunday, 2016-10-16 16:38:35 +1100, Jonathan Gray wrote: > >> >> > >> On OpenBSD try to dlopen 'libglapi.so', ld.so will find > >> >> > >> the highest major/minor version and open it in this case. > >> >> > >> > >> >> > >> Avoids '#error Unknown glapi provider for this platform' at build > >> >> > >> time. > >> >> > >> > >> >> > >> Signed-off-by: Jonathan Gray > >> >> > > > >> >> > > LGTM, and I guess the other *BSD will want the same since 7a9c92d0 > >> >> > > broke > >> >> > > them too. > >> >> > > > >> >> > I'm not 100% sure about that. OpenBSD (unlike other BSD) did bump the > >> >> > major when the ABI breaks due to 'internal' changes - think of > >> >> > off_t/time_t on 32 vs 64bit systems and alike. > >> >> > > >> >> > Unlike Linux kernel/distros, BSDs tend to be more relaxed when in > >> >> > comes to ABI, I believe. Don't quote me on that one ;-) > >> >> > >> >> OpenBSD tends to favour simplified interfaces over backwards > >> >> compatiblity > >> >> and is more like a research system in that respect. As the kernel > >> >> and userland are one source tree ioctl compat largely doesn't exist. > >> >> System calls get deprecated and removed over the course of a few > >> >> releases. > >> >> So we didn't go through the pain of duplicated systems calls for off_t > >> >> as mentioned, and don't go in for symbol versioning. Just major.minor > >> >> library versioning, which is roughly symbol removals, major crank, > >> >> symbol additions minor crank. > >> >> > >> >> I believe FreeBSD tends to go in for backwards compatibility more > >> >> but am not familiar with the details. They also have a different ld.so. > >> >> > >> >> Perhaps an else case for 'libglapi.so.0' would be appropriate for all > >> >> the other various unices instead of the #error ? > >> > > >> > Yeah actually, I'm thinking reverting this hunk of 7a9c92d0 might be a > >> > better, > >> > to avoid the potentially huge list of every *BSD and other Unix: > >> > > >> Fwiw I've intentionally added the hunk since I was a bit lazy to check > >> if the BSD(s?)/Solaris/others have bumped the major locally. Having a > >> closer look that's not the case, so indeed we can add revert to > >> libglapi.so.0 in the else statement. > >> > >> Jonathan, how about we with the above instead ? > > > > At the moment OpenBSD has libglapi.so.0.2 for Mesa 11.2.2. > > New versions of Mesa add new shared_dispatch_stub_* symbols, > > which the minor would crank for. > > > Don't think we [intentionally] added any symbols for a long while. Comparing 11.2.2 libglapi and the latest Mesa I see: Dynamic export changes: added: shared_dispatch_stub_1323 shared_dispatch_stub_1324 shared_dispatch_stub_1325 shared_dispatch_stub_1326 shared_dispatch_stub_1327 shared_dispatch_stub_1328 shared_dispatch_stub_1329 Perhaps this is unique to the non-tls dispatch case though. > > > I'd prefer the diff I mailed for OpenBSD for if the major version > > should crank for some reason. > Let's worry about that if/when it happens ? sure > > Emil > /me lands the rest of the patches thankS ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] egl/dri2: add a libname to dlopen for OpenBSD
On Wed, Oct 19, 2016 at 10:29:47AM +0100, Emil Velikov wrote: > On 19 October 2016 at 01:05, Jonathan Gray wrote: > > On Tue, Oct 18, 2016 at 04:24:20PM +0100, Emil Velikov wrote: > >> On 18 October 2016 at 00:58, Jonathan Gray wrote: > >> > On Mon, Oct 17, 2016 at 05:34:02PM +0100, Emil Velikov wrote: > >> >> On 17 October 2016 at 16:39, Eric Engestrom > >> >> wrote: > >> >> > On Monday, 2016-10-17 22:53:20 +1100, Jonathan Gray wrote: > >> >> >> On Mon, Oct 17, 2016 at 12:39:11PM +0100, Emil Velikov wrote: > >> >> >> > On 17 October 2016 at 10:53, Eric Engestrom > >> >> >> > wrote: > >> >> >> > > On Sunday, 2016-10-16 16:38:35 +1100, Jonathan Gray wrote: > >> >> >> > >> On OpenBSD try to dlopen 'libglapi.so', ld.so will find > >> >> >> > >> the highest major/minor version and open it in this case. > >> >> >> > >> > >> >> >> > >> Avoids '#error Unknown glapi provider for this platform' at > >> >> >> > >> build time. > >> >> >> > >> > >> >> >> > >> Signed-off-by: Jonathan Gray > >> >> >> > > > >> >> >> > > LGTM, and I guess the other *BSD will want the same since > >> >> >> > > 7a9c92d0 broke > >> >> >> > > them too. > >> >> >> > > > >> >> >> > I'm not 100% sure about that. OpenBSD (unlike other BSD) did bump > >> >> >> > the > >> >> >> > major when the ABI breaks due to 'internal' changes - think of > >> >> >> > off_t/time_t on 32 vs 64bit systems and alike. > >> >> >> > > >> >> >> > Unlike Linux kernel/distros, BSDs tend to be more relaxed when in > >> >> >> > comes to ABI, I believe. Don't quote me on that one ;-) > >> >> >> > >> >> >> OpenBSD tends to favour simplified interfaces over backwards > >> >> >> compatiblity > >> >> >> and is more like a research system in that respect. As the kernel > >> >> >> and userland are one source tree ioctl compat largely doesn't exist. > >> >> >> System calls get deprecated and removed over the course of a few > >> >> >> releases. > >> >> >> So we didn't go through the pain of duplicated systems calls for > >> >> >> off_t > >> >> >> as mentioned, and don't go in for symbol versioning. Just > >> >> >> major.minor > >> >> >> library versioning, which is roughly symbol removals, major crank, > >> >> >> symbol additions minor crank. > >> >> >> > >> >> >> I believe FreeBSD tends to go in for backwards compatibility more > >> >> >> but am not familiar with the details. They also have a different > >> >> >> ld.so. > >> >> >> > >> >> >> Perhaps an else case for 'libglapi.so.0' would be appropriate for all > >> >> >> the other various unices instead of the #error ? > >> >> > > >> >> > Yeah actually, I'm thinking reverting this hunk of 7a9c92d0 might be > >> >> > a better, > >> >> > to avoid the potentially huge list of every *BSD and other Unix: > >> >> > > >> >> Fwiw I've intentionally added the hunk since I was a bit lazy to check > >> >> if the BSD(s?)/Solaris/others have bumped the major locally. Having a > >> >> closer look that's not the case, so indeed we can add revert to > >> >> libglapi.so.0 in the else statement. > >> >> > >> >> Jonathan, how about we with the above instead ? > >> > > >> > At the moment OpenBSD has libglapi.so.0.2 for Mesa 11.2.2. > >> > New versions of Mesa add new shared_dispatch_stub_* symbols, > >> > which the minor would crank for. > >> > > >> Don't think we [intentionally] added any symbols for a long while. > > > > Comparing 11.2.2 libglapi and the latest Mesa I see: > > > > Dynamic export changes: > > added: > > shared_dispatch_stub_1323 > > shared_dispatch_stub_1324 > > shared_dispatch_stub_1325 > > shared_dispatch_stub_1326 > > shared_dispatch_stub_1327 > > shared_dispatch_stub_1328 > > shared_dispatch_stub_1329 > > > > Perhaps this is unique to the non-tls dispatch case though. > > > Seems like it. Either way, the symbols are exported unintentionally, > since they are not part of the glapi API and are not used outside of > libglapi.so. > > Any patch(es) to hide them will be gladly appreciated. It seems only the arch specific glapi asm stubs get it right? I manually extracted the libglapi from debian's Mesa 12.0.3 for amd64 and armhf and the shared_dispatch_stub symbols show up with debian's armhf library (but not amd64). http://ftp.au.debian.org/debian/pool/main/m/mesa/libglapi-mesa_12.0.3-1_armhf.deb $ nm usr/lib/arm-linux-gnueabihf/libglapi.so.0.0.0 | fgrep ' T shared_dispatch_stub' | wc -l 1324 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] egl/dri2: add a libname to dlopen for OpenBSD
On Wed, Oct 19, 2016 at 03:17:07PM +0100, Emil Velikov wrote: > On 19 October 2016 at 14:16, Jonathan Gray wrote: > > On Wed, Oct 19, 2016 at 10:29:47AM +0100, Emil Velikov wrote: > >> On 19 October 2016 at 01:05, Jonathan Gray wrote: > >> > On Tue, Oct 18, 2016 at 04:24:20PM +0100, Emil Velikov wrote: > >> >> On 18 October 2016 at 00:58, Jonathan Gray wrote: > >> >> > On Mon, Oct 17, 2016 at 05:34:02PM +0100, Emil Velikov wrote: > >> >> >> On 17 October 2016 at 16:39, Eric Engestrom > >> >> >> wrote: > >> >> >> > On Monday, 2016-10-17 22:53:20 +1100, Jonathan Gray wrote: > >> >> >> >> On Mon, Oct 17, 2016 at 12:39:11PM +0100, Emil Velikov wrote: > >> >> >> >> > On 17 October 2016 at 10:53, Eric Engestrom > >> >> >> >> > wrote: > >> >> >> >> > > On Sunday, 2016-10-16 16:38:35 +1100, Jonathan Gray wrote: > >> >> >> >> > >> On OpenBSD try to dlopen 'libglapi.so', ld.so will find > >> >> >> >> > >> the highest major/minor version and open it in this case. > >> >> >> >> > >> > >> >> >> >> > >> Avoids '#error Unknown glapi provider for this platform' at > >> >> >> >> > >> build time. > >> >> >> >> > >> > >> >> >> >> > >> Signed-off-by: Jonathan Gray > >> >> >> >> > > > >> >> >> >> > > LGTM, and I guess the other *BSD will want the same since > >> >> >> >> > > 7a9c92d0 broke > >> >> >> >> > > them too. > >> >> >> >> > > > >> >> >> >> > I'm not 100% sure about that. OpenBSD (unlike other BSD) did > >> >> >> >> > bump the > >> >> >> >> > major when the ABI breaks due to 'internal' changes - think of > >> >> >> >> > off_t/time_t on 32 vs 64bit systems and alike. > >> >> >> >> > > >> >> >> >> > Unlike Linux kernel/distros, BSDs tend to be more relaxed when > >> >> >> >> > in > >> >> >> >> > comes to ABI, I believe. Don't quote me on that one ;-) > >> >> >> >> > >> >> >> >> OpenBSD tends to favour simplified interfaces over backwards > >> >> >> >> compatiblity > >> >> >> >> and is more like a research system in that respect. As the kernel > >> >> >> >> and userland are one source tree ioctl compat largely doesn't > >> >> >> >> exist. > >> >> >> >> System calls get deprecated and removed over the course of a few > >> >> >> >> releases. > >> >> >> >> So we didn't go through the pain of duplicated systems calls for > >> >> >> >> off_t > >> >> >> >> as mentioned, and don't go in for symbol versioning. Just > >> >> >> >> major.minor > >> >> >> >> library versioning, which is roughly symbol removals, major crank, > >> >> >> >> symbol additions minor crank. > >> >> >> >> > >> >> >> >> I believe FreeBSD tends to go in for backwards compatibility more > >> >> >> >> but am not familiar with the details. They also have a different > >> >> >> >> ld.so. > >> >> >> >> > >> >> >> >> Perhaps an else case for 'libglapi.so.0' would be appropriate for > >> >> >> >> all > >> >> >> >> the other various unices instead of the #error ? > >> >> >> > > >> >> >> > Yeah actually, I'm thinking reverting this hunk of 7a9c92d0 might > >> >> >> > be a better, > >> >> >> > to avoid the potentially huge list of every *BSD and other Unix: > >> >> >> > > >> >> >> Fwiw I've intentionally added the hunk since I was a bit lazy to > >> >> >> check > >> >> >> if the BSD(s?)/Solaris/others have bumped t
Re: [Mesa-dev] [PATCH 02/16] loader: slim down loader_get_pci_id_for_fd implementation(s)
On Sat, Oct 15, 2016 at 01:32:02PM +0100, Emil Velikov wrote: > On Saturday, 15 October 2016, Jonathan Gray wrote: > > > On Tue, Oct 11, 2016 at 07:31:46PM +0100, Emil Velikov wrote: > > > From: Emil Velikov > > > > > > > Currently mesa has three code paths in the loader - libudev, manual > > > sysfs and drm ioctl one. > > > > > > Considering the issues we had with libudev - strip those down in favour > > > of the libdrm drm device API. The latter can be implemented in any way > > > depending on the platform and can be reused by others. > > > > > > Cc: Jonathan Gray > > > > Cc: Jean-S??bastien P??dron > > > Signed-off-by: Emil Velikov > > > > --- > > > Jonathan, Jean-S??bastien I believe I've prodded you guys for a *BSD > > > implementation of the drm*Device API a while back. With this commit > > > you'll be 'forced' to prep some ;-) > > > > It has been a while since I looked into that. The design seemed to > > assume that the user running code that called into libdrm had the > > ability to enumerate pci busses. > > > > On OpenBSD /dev/pci* is only read/writable by root. /dev/drm* is > > chowned after a user logs into a console. > > > > Yes that's correct. The principle is that the platform/kernel has a method > of enumerating and providing basic information for the available devices. > Note that there are multiple applications explicitly dropping OpenBSD > support from their TODO because it lacks the ability [from unprivileged > context]. > > We don't use filesystems for communicating with the kernel like linux > > does so ioctls are really the best fit. The loader parts used at the > > moment use drm driver specific ioctls, hopefully a generic version of > > those that can return the vid/pid, subids and function id numbers would > > cover most of it. > > Afaict retrieving the vendor/device ID et al is not a security concern > (admittedly I'm not a security person) nor drm specific. > > As-is one will end up with multiple implementations - one per subsystem > leading to extra code and maintenance burden on both OpenBSD end and for > apps who want to support the platform. > > Hope that makes things clear and doesn't sound too ranty ;-) > Emil The drm functions in question ask for pci information by passing in major and minor numbers of drm devices or in the case of drmParsePciDeviceInfo bizzarely just "drm0", not sure why the inconsistency there. They aren't enumerating buses they are responding based on information from drm sources. So it's going to be drm not pci ioctls. The real problem is going to be in adding drm ioctls I'd have to convince the linux kernel people to reserve numbers, people involved in libdrm and people involved in OpenBSD. Though the functions would then be useable for systems beyond just those with sysfs if they implemented the ioctls. I had diffs from a few months ago to do drmGetMinorNameForFD based on loader drm_get_device_name_for_fd, drmParsePciDeviceInfo based on drm_get_pci_id_for_fd and defaulting to DRM_BUS_PCI rather than an error in drmParseSubsystemType. I don't think there is a way to retrieve the drmParsePciBusInfo data with the existing ioctls though. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 02/16] loader: slim down loader_get_pci_id_for_fd implementation(s)
On Thu, Oct 20, 2016 at 11:44:46AM +0100, Emil Velikov wrote:
> On 20 October 2016 at 05:35, Jonathan Gray wrote:
> > On Sat, Oct 15, 2016 at 01:32:02PM +0100, Emil Velikov wrote:
> >> On Saturday, 15 October 2016, Jonathan Gray wrote:
> >>
> >> > On Tue, Oct 11, 2016 at 07:31:46PM +0100, Emil Velikov wrote:
> >> > > From: Emil Velikov >
> >> > >
> >> > > Currently mesa has three code paths in the loader - libudev, manual
> >> > > sysfs and drm ioctl one.
> >> > >
> >> > > Considering the issues we had with libudev - strip those down in favour
> >> > > of the libdrm drm device API. The latter can be implemented in any way
> >> > > depending on the platform and can be reused by others.
> >> > >
> >> > > Cc: Jonathan Gray >
> >> > > Cc: Jean-S??bastien P??dron
> >> > > Signed-off-by: Emil Velikov >
> >> > > ---
> >> > > Jonathan, Jean-S??bastien I believe I've prodded you guys for a *BSD
> >> > > implementation of the drm*Device API a while back. With this commit
> >> > > you'll be 'forced' to prep some ;-)
> >> >
> >> > It has been a while since I looked into that. The design seemed to
> >> > assume that the user running code that called into libdrm had the
> >> > ability to enumerate pci busses.
> >> >
> >> > On OpenBSD /dev/pci* is only read/writable by root. /dev/drm* is
> >> > chowned after a user logs into a console.
> >> >
> >> > Yes that's correct. The principle is that the platform/kernel has a
> >> > method
> >> of enumerating and providing basic information for the available devices.
> >> Note that there are multiple applications explicitly dropping OpenBSD
> >> support from their TODO because it lacks the ability [from unprivileged
> >> context].
> >>
> >> We don't use filesystems for communicating with the kernel like linux
> >> > does so ioctls are really the best fit. The loader parts used at the
> >> > moment use drm driver specific ioctls, hopefully a generic version of
> >> > those that can return the vid/pid, subids and function id numbers would
> >> > cover most of it.
> >>
> >> Afaict retrieving the vendor/device ID et al is not a security concern
> >> (admittedly I'm not a security person) nor drm specific.
> >>
> >> As-is one will end up with multiple implementations - one per subsystem
> >> leading to extra code and maintenance burden on both OpenBSD end and for
> >> apps who want to support the platform.
> >>
> >> Hope that makes things clear and doesn't sound too ranty ;-)
> >> Emil
> >
> > The drm functions in question ask for pci information by passing in
> > major and minor numbers of drm devices or in the case of
> > drmParsePciDeviceInfo bizzarely just "drm0", not sure why the
> > inconsistency there. They aren't enumerating buses they are responding
> > based on information from drm sources. So it's going to be drm not pci
> > ioctls.
> >
> One could rework the lot via a) enumerate {PCI,other} devices first,
> b) retrieve bus/device info (vendor/device/nodes) and feed that back
> to the user. In practise the end result should not matter.
> But I have to agree - the current implementation is not that pretty.
> Thus I won't object if one has patches to improve/rewrite it :-)
>
> Wrt the rest, I'm not sure I fully parse what you're saying. It sounds
> like you've noticed multiple deficiencies, so it'll be better to keep
> that a separate thread
>
> > The real problem is going to be in adding drm ioctls I'd have to convince
> > the linux kernel people to reserve numbers, people involved in libdrm
> > and people involved in OpenBSD. Though the functions would then be
> > useable for systems beyond just those with sysfs if they implemented the
> > ioctls.
> >
> Chances are you'll get a Nack straight away from the Linux kernel
> devs. The idea being that a) there's an already existing userspace
> interfaces to do all this stuff and b) the linux kernel ABI must stay
> forever, so people are more cautious what gets added.
>
> Regardless, please forward what you have in mind to dri-devel, in case
> situation/opinions have changed or I'm misunderstood things.
>
> > I had diffs from a few months ago to do drmGetMinorNameForFD based on
> > loader drm_get_device_name_for_fd, drmParsePciDeviceInfo based on
> > drm_get_pci_id_for_fd and defaulting to DRM_BUS_PCI rather than an error
> > in drmParseSubsystemType.
>
> > I don't think there is a way to retrieve the
> > drmParsePciBusInfo data with the existing ioctls though.
> No there isn't any afaict.
>
> In general feel free to approach the whole thing from a different
> angle - if it makes more sense/is easier/better wrt OpenBSD.
>
> Thanks
> Emil
Thanks, I'll try find some time to come up with something that works
first and then propose it on dri-devel.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mapi: automake: set VISIBILITY_CFLAGS for shared glapi
shared glapi was previously built without setting CFLAGS for AM_CFLAGS and VISIBILITY_CFLAGS. This resulted in symbols being exported that shouldn't be. The x86 and sparc assembly versions of the dispatch table partially mitigated this by using .hidden. Otherwise shared_dispatch_stub_* were being exported. Signed-off-by: Jonathan Gray Cc: "11.2 12.0 13.0" --- src/mapi/Makefile.am | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/mapi/Makefile.am b/src/mapi/Makefile.am index 5a58ca2..f35cedc 100644 --- a/src/mapi/Makefile.am +++ b/src/mapi/Makefile.am @@ -64,6 +64,9 @@ BUILT_SOURCES += shared-glapi/glapi_mapi_tmp.h lib_LTLIBRARIES += shared-glapi/libglapi.la shared_glapi_libglapi_la_SOURCES = $(MAPI_GLAPI_FILES) shared-glapi/glapi_mapi_tmp.h +shared_glapi_libglapi_la_CFLAGS = \ + $(AM_CFLAGS) \ + $(VISIBILITY_CFLAGS) shared_glapi_libglapi_la_CPPFLAGS = \ $(AM_CPPFLAGS) \ -DMAPI_MODE_GLAPI \ -- 2.9.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/1] Fix endianess detection with musl-based toolchains
On Fri, Nov 04, 2016 at 07:53:25PM +0100, Bernd Kuhls wrote: > Musl does not define __GLIBC__ and will not provide a __MUSL__ macro: > http://wiki.musl-libc.org/wiki/FAQ#Q:_why_is_there_no_MUSL_macro_.3F > > This patch checks for the presence of endian.h and promotes the result > to src/amd/Makefile.addrlib.am which executes the broken build command. > Fixes compile errors detected by the autobuilder infrastructure of the > buildroot project: This will break OpenBSD and perhaps other platforms which have endian.h that does not define glibc definitions. > > http://autobuild.buildroot.net/results/e27/e27a9a95f72dba3076549beb2a2ccfdbea2fcfee/ > http://autobuild.buildroot.net/results/e27/e27a9a95f72dba3076549beb2a2ccfdbea2fcfee/ > Signed-off-by: Bernd Kuhls > --- > configure.ac| 1 + > src/amd/Makefile.addrlib.am | 1 + > src/util/u_endian.h | 2 +- > 3 files changed, 3 insertions(+), 1 deletion(-) > > diff --git a/configure.ac b/configure.ac > index 4761c59..7991b52 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -786,6 +786,7 @@ fi > AC_HEADER_MAJOR > AC_CHECK_HEADER([xlocale.h], [DEFINES="$DEFINES -DHAVE_XLOCALE_H"]) > AC_CHECK_HEADER([sys/sysctl.h], [DEFINES="$DEFINES -DHAVE_SYS_SYSCTL_H"]) > +AC_CHECK_HEADER([endian.h], [DEFINES="$DEFINES -DHAVE_ENDIAN_H"]) > AC_CHECK_FUNC([strtof], [DEFINES="$DEFINES -DHAVE_STRTOF"]) > AC_CHECK_FUNC([mkostemp], [DEFINES="$DEFINES -DHAVE_MKOSTEMP"]) > > diff --git a/src/amd/Makefile.addrlib.am b/src/amd/Makefile.addrlib.am > index 64823fc..4e2fb1d 100644 > --- a/src/amd/Makefile.addrlib.am > +++ b/src/amd/Makefile.addrlib.am > @@ -28,6 +28,7 @@ addrlib_libamdgpu_addrlib_la_CPPFLAGS = \ > -I$(srcdir)/addrlib/core \ > -I$(srcdir)/addrlib/inc/chip/r800 \ > -I$(srcdir)/addrlib/r800/chip \ > + $(DEFINES) \ > -DBRAHMA_BUILD=1 > > addrlib_libamdgpu_addrlib_la_CXXFLAGS = \ > diff --git a/src/util/u_endian.h b/src/util/u_endian.h > index b9d563d..266fb4a 100644 > --- a/src/util/u_endian.h > +++ b/src/util/u_endian.h > @@ -27,7 +27,7 @@ > #ifndef U_ENDIAN_H > #define U_ENDIAN_H > > -#if defined(__GLIBC__) || defined(ANDROID) > +#if defined(__GLIBC__) || defined(ANDROID) || defined(HAVE_ENDIAN_H) > #include > > #if __BYTE_ORDER == __LITTLE_ENDIAN > -- > 2.10.1 > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa 13.0.2 release candidate
On Thu, Nov 24, 2016 at 05:25:26PM +, Emil Velikov wrote: > Hello list, > > The candidate for the Mesa 13.0.2 is now available. Currently we have: > - 49 queued > - 4 nominated (outstanding) > - and 1 rejected patch(es) > > > With this series we have - fixes for vc4, i965 and radeon drivers. In addition > to that PCI IDs for Geminilake have been added to the i965 driver, > > The respective Vulkan drivers have seen multiple improvements some of which > include improved smoketesting and addressed memory leaks. > > Races during _mesa_HashWalk() (while using glDeleteFramebuffers alongside > glTexImage2D) and "#version 0" in GLSL programs have been addressed. > > BSD and Hurd users should be above to build the latest code as we no longer > use PATH_MAX. You seem to be confusing things there. BSD has had PATH_MAX since 1989. commit dcc36b4d161e5d44274cc4bd6d375d04b758b61e Author: Keith Bostic Date: Thu Feb 16 14:11:48 1989 -0800 system limits for POSIX 1003.1; included by include/limits.h SCCS-vsn: 7.1 diff --git a/sys/sys/syslimits.h b/sys/sys/syslimits.h new file mode 100644 index 000..c60f25d --- /dev/null +++ b/sys/sys/syslimits.h @@ -0,0 +1,29 @@ +/* + * Copyright (c) 1988 The Regents of the University of California. + * All rights reserved. + * + * Redistribution and use in source and binary forms are permitted + * provided that the above copyright notice and this paragraph are + * duplicated in all such forms and that any documentation, + * advertising materials, and other materials related to such + * distribution and use acknowledge that the software was developed + * by the University of California, Berkeley. The name of the + * University may not be used to endorse or promote products derived + * from this software without specific prior written permission. + * THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR + * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED + * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. + * + * @(#)syslimits.h 7.1 (Berkeley) 02/16/89 + */ + +#defineARG_MAX 20480 /* max bytes for an exec function */ +#defineCHILD_MAX 40 /* max simultaneous processes */ +#defineLINK_MAX8 /* max file link count */ +#defineMAX_CANON 255 /* max bytes in terminal canonical input line */ +#defineMAX_INPUT 255 /* max bytes in terminal input */ +#defineNAME_MAX255 /* max number of bytes in a file name */ +#defineNGROUPS_MAX 16 /* max number of supplemental group id's */ +#defineOPEN_MAX64 /* max open files per process */ +#definePATH_MAX1024/* max number of bytes in pathname */ +#definePIPE_BUF512 /* max number of bytes for atomic pipe writes */ > > > Take a look at section "Mesa stable queue" for more information. > > > Testing reports/general approval > > Any testing reports (or general approval of the state of the branch) will be > greatly appreciated. > > The plan is to have 13.0.2 this Saturday (25th of November), around or > shortly after 17:00 GMT. > > If you have any questions or suggestions - be that about the current patch > queue or otherwise, please go ahead. > > > Trivial merge conflicts > --- > commit 9d5c3fc12b05d944508ef4e3b1f2ddc4f23c0a82 > Author: Jason Ekstrand > > i965/gs: Allow primitive id to be a system value > > (cherry picked from commit a5e88e66e633aaeb587b274d80e21cd46c8ee2cb) > > > commit 8dbdbc21910a6d37c381535186f9e728fff8690d > Author: Jason Ekstrand > > anv: Handle null in all destructors > > (cherry picked from commit 49f08ad77f51cc344e4bfe60ba9f8d9fccfbd753) > > > commit 1809f17bda56d4f9d6385f63a9c4a5df890e3cad > Author: Kenneth Graunke > > mesa: Drop PATH_MAX usage. > > (cherry picked from commit 9bfee7047b70cb0aa026ca9536465762f96cb2b1) > > Cheers, > Emil > > > Mesa stable queue > - > > Nominated (4) > = > > Dave Airlie (1): > 2de85eb radv: fix texturesamples to handle single sample case > > Jason Ekstrand (2): > e73d136 vulkan/wsi/x11: Implement FIFO mode. > > Note: temporary on hold. > Commit seems to be a feature and provides no clear indication about the bugs > it addresses. Jason, is this really applicable for stable ? > > 054e48e anv/cmd_buffer: Re-emit MEDIA_CURBE_LOAD when CS push > constants are dirty > > Note: temporary on hold. > Depends on the refactoring d33e2ad67c3 (anv: Move INTERFACE_DESCRIPTOR_DATA > setup to the pipeline) which in itself depends on another refactoring > (cleanup) > commit 623e1e06d8c and likely others. Jason, any input ? > > Kevin Strasser (1): > 932bb3f vulkan/wsi: Add a thread-safe queue implementation > Requirement for "Implement FIFO mode above" above. > > > Queued (49) > === >
Re: [Mesa-dev] [PATCH libdrm v2 5/5] xf86drm: implement an OpenBSD specific drmGetDevice2
On Mon, Dec 05, 2016 at 05:56:40PM +, Emil Velikov wrote: > On 1 December 2016 at 04:18, Jonathan Gray wrote: > > DRI devices on OpenBSD are not in their own directory. They reside in > > /dev with a large number of statically generated /dev nodes. > > > > Avoid stat'ing all of /dev on OpenBSD by implementing this custom path. > > > > v2: > >- use drmGetMinorType to get node type > >- adapt to drmProcessPciDevice changes > >- verify drmParseSubsystemType type is PCI > >- add a comment describing why this was added > > > Thanks for the update Jonathan. > > I've pulled v2 in master, > Emil Thanks, going over what went in I see drmGetMinorNameForFD and the OpenBSD drmGetDevice2 paths need to be adjusted to have the correct minor for the control/render nodes. ie base = drmGetMinorBase(type); if (min < base) return error; min -= base; I'll send another patch for this. And the common code could be split into a shared function? drmGetDeviceNameFromFd2 would do the same thing as drmGetDeviceNameFromFd on OpenBSD as far as I can tell so that could be another shared function instead of the current "missing implementation" warning. Or should drmGetDeviceNameFromFd purposefully not handle render/control nodes? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa: don't attempt to unlock an unlocked debug state mutex
Commit 929fcee47e46781c57f2a354ce0a013915c033d1 introduced code that
attempts to unlock an unlocked mutex which is undefined behaviour.
On OpenBSD this leads to an abort:
0 0x124dadfa96ba in thrkill () at :2
1 0x124dadf3da39 in *_libc_abort () at /usr/src/lib/libc/stdlib/abort.c:52
2 0x124d2c1165b5 in *_libpthread_pthread_mutex_unlock (mutexp=)
at /usr/src/lib/librthread/rthread_sync.c:221
3 0x124d279c02e4 in init_attrib_groups (ctx=0x124df0fda000) at
main/context.c:825
4 _mesa_initialize_context (ctx=ctx@entry=0x124df0fda000,
api=api@entry=API_OPENGL_CORE,
visual=visual@entry=0x7f7bdfd0, share_list=share_list@entry=0x0,
driverFunctions=driverFunctions@entry=0x7f7bda60) at main/context.c:1204
5 0x124d27b507ec in st_create_context (api=api@entry=API_OPENGL_CORE,
pipe=pipe@entry=0x124dc491, visual=visual@entry=0x7f7bdfd0,
share=share@entry=0x0, options=options@entry=0x7f7be128)
at state_tracker/st_context.c:545
6 0x124d27b8639f in st_api_create_context (stapi=,
smapi=0x124d1b608800, attribs=0x7f7be100, error=0x7f7be0fc,
shared_stctxi=0x0)
at state_tracker/st_manager.c:669
7 0x124d27cc5b9c in dri_create_context (api=,
visual=0x124d8a0f8a00,
cPriv=0x124de473f240, major_version=,
minor_version=,
flags=, notify_reset=false, error=0x7f7be2b4,
sharedContextPrivate=0x0) at dri_context.c:123
8 0x124d27cc5029 in driCreateContextAttribs (screen=0x124d8a0f8400,
api=, config=0x124d8a0f8a00, shared=,
num_attribs=, attribs=, error=0x7f7be2b4,
data=0x124d77814a00) at dri_util.c:448
9 0x124d8e109b00 in drisw_create_context_attribs (base=0x124df3e08700,
config_base=0x124d7a0e7300, shareList=,
num_attribs=,
attribs=, error=0x7f7be2b4) at drisw_glx.c:476
10 0x124d8e104b4a in glXCreateContextAttribsARB (dpy=0x124d533f,
config=0x124d7a0e7300, share_context=0x0, direct=1,
attrib_list=0x7f7be300)
at create_context.c:78
Signed-off-by: Jonathan Gray
---
src/mesa/main/debug_output.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/src/mesa/main/debug_output.c b/src/mesa/main/debug_output.c
index 48dbbb3..bc933db 100644
--- a/src/mesa/main/debug_output.c
+++ b/src/mesa/main/debug_output.c
@@ -1282,14 +1282,13 @@ _mesa_init_debug_output(struct gl_context *ctx)
*/
struct gl_debug_state *debug = _mesa_lock_debug_state(ctx);
if (!debug) {
- goto done;
+ return;
}
debug->DebugOutput = GL_TRUE;
debug->LogToStderr = GL_TRUE;
ctx->Const.ContextFlags |= GL_CONTEXT_FLAG_DEBUG_BIT;
+ _mesa_unlock_debug_state(ctx);
}
-done:
- _mesa_unlock_debug_state(ctx);
}
--
2.10.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: don't attempt to unlock an unlocked debug state mutex
Previously there was no _mesa_unlock_debug_state() call at all,
one is still retained here for the case where _mesa_lock_debug_state()
is called and did not return NULL (which is documented as being
unlocked).
On Mon, Dec 12, 2016 at 11:40:32AM +1100, Edward O'Callaghan wrote:
> Hold up..
>
> Does this reintroduce the hang in glsl-fs-loop piglit test with
> MESA_DEBUG=context though? Was that tested? I'm interested to know how
> this got so muddled up in the first place.
>
> Kind Regards,
> Edward.
>
> On 12/12/2016 05:21 AM, Eduardo Lima Mitev wrote:
> > Looks good.
> >
> > Reviewed-by: Eduardo Lima Mitev
> >
> > On 12/11/2016 04:42 PM, Jonathan Gray wrote:
> >> Commit 929fcee47e46781c57f2a354ce0a013915c033d1 introduced code that
> >> attempts to unlock an unlocked mutex which is undefined behaviour.
> >>
> >> On OpenBSD this leads to an abort:
> >>
> >> 0 0x124dadfa96ba in thrkill () at :2
> >> 1 0x124dadf3da39 in *_libc_abort () at
> >> /usr/src/lib/libc/stdlib/abort.c:52
> >> 2 0x124d2c1165b5 in *_libpthread_pthread_mutex_unlock
> >> (mutexp=)
> >> at /usr/src/lib/librthread/rthread_sync.c:221
> >> 3 0x124d279c02e4 in init_attrib_groups (ctx=0x124df0fda000) at
> >> main/context.c:825
> >> 4 _mesa_initialize_context (ctx=ctx@entry=0x124df0fda000,
> >> api=api@entry=API_OPENGL_CORE,
> >> visual=visual@entry=0x7f7bdfd0, share_list=share_list@entry=0x0,
> >> driverFunctions=driverFunctions@entry=0x7f7bda60) at
> >> main/context.c:1204
> >> 5 0x124d27b507ec in st_create_context (api=api@entry=API_OPENGL_CORE,
> >> pipe=pipe@entry=0x124dc491, visual=visual@entry=0x7f7bdfd0,
> >> share=share@entry=0x0, options=options@entry=0x7f7be128)
> >> at state_tracker/st_context.c:545
> >> 6 0x124d27b8639f in st_api_create_context (stapi=,
> >> smapi=0x124d1b608800, attribs=0x7f7be100, error=0x7f7be0fc,
> >> shared_stctxi=0x0)
> >> at state_tracker/st_manager.c:669
> >> 7 0x124d27cc5b9c in dri_create_context (api=,
> >> visual=0x124d8a0f8a00,
> >> cPriv=0x124de473f240, major_version=,
> >> minor_version=,
> >> flags=, notify_reset=false, error=0x7f7be2b4,
> >> sharedContextPrivate=0x0) at dri_context.c:123
> >> 8 0x124d27cc5029 in driCreateContextAttribs (screen=0x124d8a0f8400,
> >> api=, config=0x124d8a0f8a00, shared=,
> >> num_attribs=, attribs=,
> >> error=0x7f7be2b4,
> >> data=0x124d77814a00) at dri_util.c:448
> >> 9 0x124d8e109b00 in drisw_create_context_attribs (base=0x124df3e08700,
> >> config_base=0x124d7a0e7300, shareList=,
> >> num_attribs=,
> >> attribs=, error=0x7f7be2b4) at drisw_glx.c:476
> >> 10 0x124d8e104b4a in glXCreateContextAttribsARB (dpy=0x124d533f,
> >> config=0x124d7a0e7300, share_context=0x0, direct=1,
> >> attrib_list=0x7f7be300)
> >> at create_context.c:78
> >>
> >> Signed-off-by: Jonathan Gray
> >> ---
> >> src/mesa/main/debug_output.c | 5 ++---
> >> 1 file changed, 2 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/src/mesa/main/debug_output.c b/src/mesa/main/debug_output.c
> >> index 48dbbb3..bc933db 100644
> >> --- a/src/mesa/main/debug_output.c
> >> +++ b/src/mesa/main/debug_output.c
> >> @@ -1282,14 +1282,13 @@ _mesa_init_debug_output(struct gl_context *ctx)
> >> */
> >>struct gl_debug_state *debug = _mesa_lock_debug_state(ctx);
> >>if (!debug) {
> >> - goto done;
> >> + return;
> >>}
> >>debug->DebugOutput = GL_TRUE;
> >>debug->LogToStderr = GL_TRUE;
> >>ctx->Const.ContextFlags |= GL_CONTEXT_FLAG_DEBUG_BIT;
> >> + _mesa_unlock_debug_state(ctx);
> >> }
> >> -done:
> >> - _mesa_unlock_debug_state(ctx);
> >> }
> >>
> >>
> >>
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> >
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Mesa-maintainers] Proposal of date-based Mesa versioning for 2017
On Mon, Dec 12, 2016 at 03:28:45PM +, Emil Velikov wrote:
> [adding mesa-maintainers to the mix]
>
> On 1 October 2016 at 20:46, Marek Olk wrote:
> > Hi,
> >
> > I propose that we use versioning in the form of "year.quarter".
> >
> > 2017 would start with 17.0, then 17.1, 17.2, 17.3 for following
> > quarters of the year, respectively.
> > 2018 would start with 18.0, then 18.1, 18.2, 18.3.
> >
> > The motivation is that you can easily tell when a specific Mesa
> > version was released with an accuracy of 3 months.
> >
> > That's the only scheme that seems practical to me. Everything else
> > seems arbitrary or random.
> >
> Afaict the only expectation from version numbers, is to never go back
> in time. Anything else is a manner of personal interpretation and
> there is will always someone who get confused.
> Look at how [some] projects steadily roll in their 50s ;-)
>
> That said, having a bit of a change is a good idea, esp. since we're
> unlikely to have a major bump anytime soon.
>
> As mentioned by others - having the second number represent the month
> would be better, afaict.
> Namely: YY.MM.PP. Thus 17.02.01 provides direct and clear feedback that
> - 2017 release, from the second month (Feb).
> - first bugfix release.
>
> * Distro/package maintainers, let us know if the above sounds fine on your
> end.
>
> Since this will have an impact on the tarball URL I'm bringing forward
> a question which has been asked a few times:
>
> * Should we drop the $VERSION directory in the URL, since it causes a
> fair bit of nuisance during RC stage.
> Namely from:
> https://mesa.freedesktop.org/archive/$VERSION/mesa-$VERSION.tar.{xz,gz}
> to:
> https://mesa.freedesktop.org/archive/mesa-$VERSION.tar.{xz,gz}
>
> Maintainers, kindly reply on both topics, even if you're neutral.
On the OpenBSD side, Mesa is imported into a larger tree (xenocara)
which has libdrm, xorg, fonts etc, so location of the distfile isn't a
problem. The version would only show up in the form of pkg-config
files and the version strings accessible from GL contexts.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: don't attempt to unlock an unlocked debug state mutex
Can someone push this to master?
On Sun, Dec 11, 2016 at 07:21:36PM +0100, Eduardo Lima Mitev wrote:
> Looks good.
>
> Reviewed-by: Eduardo Lima Mitev
>
> On 12/11/2016 04:42 PM, Jonathan Gray wrote:
> > Commit 929fcee47e46781c57f2a354ce0a013915c033d1 introduced code that
> > attempts to unlock an unlocked mutex which is undefined behaviour.
> >
> > On OpenBSD this leads to an abort:
> >
> > 0 0x124dadfa96ba in thrkill () at :2
> > 1 0x124dadf3da39 in *_libc_abort () at
> > /usr/src/lib/libc/stdlib/abort.c:52
> > 2 0x124d2c1165b5 in *_libpthread_pthread_mutex_unlock
> > (mutexp=)
> > at /usr/src/lib/librthread/rthread_sync.c:221
> > 3 0x124d279c02e4 in init_attrib_groups (ctx=0x124df0fda000) at
> > main/context.c:825
> > 4 _mesa_initialize_context (ctx=ctx@entry=0x124df0fda000,
> > api=api@entry=API_OPENGL_CORE,
> > visual=visual@entry=0x7f7bdfd0, share_list=share_list@entry=0x0,
> > driverFunctions=driverFunctions@entry=0x7f7bda60) at
> > main/context.c:1204
> > 5 0x124d27b507ec in st_create_context (api=api@entry=API_OPENGL_CORE,
> > pipe=pipe@entry=0x124dc491, visual=visual@entry=0x7f7bdfd0,
> > share=share@entry=0x0, options=options@entry=0x7f7be128)
> > at state_tracker/st_context.c:545
> > 6 0x124d27b8639f in st_api_create_context (stapi=,
> > smapi=0x124d1b608800, attribs=0x7f7be100, error=0x7f7be0fc,
> > shared_stctxi=0x0)
> > at state_tracker/st_manager.c:669
> > 7 0x124d27cc5b9c in dri_create_context (api=,
> > visual=0x124d8a0f8a00,
> > cPriv=0x124de473f240, major_version=,
> > minor_version=,
> > flags=, notify_reset=false, error=0x7f7be2b4,
> > sharedContextPrivate=0x0) at dri_context.c:123
> > 8 0x124d27cc5029 in driCreateContextAttribs (screen=0x124d8a0f8400,
> > api=, config=0x124d8a0f8a00, shared=,
> > num_attribs=, attribs=,
> > error=0x7f7be2b4,
> > data=0x124d77814a00) at dri_util.c:448
> > 9 0x124d8e109b00 in drisw_create_context_attribs (base=0x124df3e08700,
> > config_base=0x124d7a0e7300, shareList=,
> > num_attribs=,
> > attribs=, error=0x7f7ffffbe2b4) at drisw_glx.c:476
> > 10 0x124d8e104b4a in glXCreateContextAttribsARB (dpy=0x124d533f,
> > config=0x124d7a0e7300, share_context=0x0, direct=1,
> > attrib_list=0x7f7be300)
> > at create_context.c:78
> >
> > Signed-off-by: Jonathan Gray
> > ---
> > src/mesa/main/debug_output.c | 5 ++---
> > 1 file changed, 2 insertions(+), 3 deletions(-)
> >
> > diff --git a/src/mesa/main/debug_output.c b/src/mesa/main/debug_output.c
> > index 48dbbb3..bc933db 100644
> > --- a/src/mesa/main/debug_output.c
> > +++ b/src/mesa/main/debug_output.c
> > @@ -1282,14 +1282,13 @@ _mesa_init_debug_output(struct gl_context *ctx)
> > */
> >struct gl_debug_state *debug = _mesa_lock_debug_state(ctx);
> >if (!debug) {
> > - goto done;
> > + return;
> >}
> >debug->DebugOutput = GL_TRUE;
> >debug->LogToStderr = GL_TRUE;
> >ctx->Const.ContextFlags |= GL_CONTEXT_FLAG_DEBUG_BIT;
> > + _mesa_unlock_debug_state(ctx);
> > }
> > -done:
> > - _mesa_unlock_debug_state(ctx);
> > }
> >
> >
> >
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: don't attempt to unlock an unlocked debug state mutex
On Tue, Dec 20, 2016 at 11:52:26AM -0800, Kenneth Graunke wrote: > On Tuesday, December 20, 2016 12:08:06 PM PST Jonathan Gray wrote: > > Can someone push this to master? > > Pushed: > > To ssh://git.freedesktop.org/git/mesa/mesa >ab8ea1b..62b8bcd master -> master > > Have you thought about applying for commit access? Thanks, I'll look into that in future. I assume the part about only accepting rsa ssh keys on https://www.freedesktop.org/wiki/AccountRequests/ is outdated with ecdsa and ed25519 keys also being accepted? Though perhaps that is a question better put to the fdo admins. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] configure.ac: add OpenBSD
On Wed, Jul 17, 2013 at 09:26:34PM -0700, Vinson Lee wrote: > On Wed, Jun 26, 2013 at 12:11 AM, Jonathan Gray wrote: > > Signed-off-by: Jonathan Gray > > --- > > configure.ac | 6 +++--- > > 1 file changed, 3 insertions(+), 3 deletions(-) > > > > diff --git configure.ac configure.ac > > index 6832b0d..6a817d0 100644 > > --- configure.ac > > +++ configure.ac > > @@ -449,7 +449,7 @@ if test "x$enable_asm" = xyes; then > > case "$host_cpu" in > > i?86) > > case "$host_os" in > > -linux* | *freebsd* | dragonfly* | *netbsd*) > > +linux* | *freebsd* | dragonfly* | *netbsd* | openbsd*) > > test "x$enable_64bit" = xyes && asm_arch=x86_64 || asm_arch=x86 > > ;; > > gnu*) > > @@ -459,7 +459,7 @@ if test "x$enable_asm" = xyes; then > > ;; > > x86_64) > > case "$host_os" in > > -linux* | *freebsd* | dragonfly* | *netbsd*) > > +linux* | *freebsd* | dragonfly* | *netbsd* | openbsd*) > > test "x$enable_32bit" = xyes && asm_arch=x86 || asm_arch=x86_64 > > ;; > > esac > > @@ -985,7 +985,7 @@ if test "x$enable_dri" = xyes; then > > ;; > > esac > > ;; > > -freebsd* | dragonfly* | *netbsd*) > > +freebsd* | dragonfly* | *netbsd* | openbsd*) > > DEFINES="$DEFINES -DHAVE_PTHREAD -DUSE_EXTERNAL_DXTN_LIB=1" > > DEFINES="$DEFINES -DHAVE_ALIAS" > > > > -- > > 1.8.3.1 > > > > ___ > > mesa-dev mailing list > > mesa-dev@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > > > Patch applied to master. Thanks, could you take a look at some of the other configure.ac patches as well? http://marc.info/?l=mesa3d-dev&m=137172335614808&w=2 http://marc.info/?l=mesa3d-dev&m=137225132130064&w=2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] don't include libdrm in an include statement
Signed-off-by: Jonathan Gray --- src/gallium/drivers/radeonsi/Makefile.am | 3 ++- src/gallium/winsys/radeon/drm/radeon_winsys.h | 2 +- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git src/gallium/drivers/radeonsi/Makefile.am src/gallium/drivers/radeonsi/Makefile.am index 46aa998..1cd85c4 100644 --- src/gallium/drivers/radeonsi/Makefile.am +++ src/gallium/drivers/radeonsi/Makefile.am @@ -29,7 +29,8 @@ AM_CPPFLAGS = \ -I$(top_srcdir)/src/gallium/drivers/radeon \ -I$(top_srcdir)/src/gallium/drivers \ -I$(top_srcdir)/include \ - $(GALLIUM_CFLAGS) + $(GALLIUM_CFLAGS) \ + $(LIBDRM_CFLAGS) AM_CFLAGS = $(LLVM_CFLAGS) libradeonsi_la_SOURCES = $(C_SOURCES) diff --git src/gallium/winsys/radeon/drm/radeon_winsys.h src/gallium/winsys/radeon/drm/radeon_winsys.h index a619d70..a500193 100644 --- src/gallium/winsys/radeon/drm/radeon_winsys.h +++ src/gallium/winsys/radeon/drm/radeon_winsys.h @@ -41,7 +41,7 @@ */ #include "pipebuffer/pb_buffer.h" -#include "libdrm/radeon_surface.h" +#include "radeon_surface.h" #define RADEON_MAX_CMDBUF_DWORDS (16 * 1024) -- 1.8.3.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] use the correct variable for x11 includes
Signed-off-by: Jonathan Gray --- src/egl/drivers/glx/Makefile.am| 2 +- src/gallium/winsys/sw/xlib/Makefile.am | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git src/egl/drivers/glx/Makefile.am src/egl/drivers/glx/Makefile.am index 6bf67ea..220134d 100644 --- src/egl/drivers/glx/Makefile.am +++ src/egl/drivers/glx/Makefile.am @@ -22,7 +22,7 @@ AM_CFLAGS = \ -I$(top_srcdir)/include \ -I$(top_srcdir)/src/egl/main \ - $(X11_CFLAGS) \ + $(X11_INCLUDES) \ $(DEFINES) noinst_LTLIBRARIES = libegl_glx.la diff --git src/gallium/winsys/sw/xlib/Makefile.am src/gallium/winsys/sw/xlib/Makefile.am index 59da37d..ea6b742 100644 --- src/gallium/winsys/sw/xlib/Makefile.am +++ src/gallium/winsys/sw/xlib/Makefile.am @@ -24,7 +24,7 @@ include $(top_srcdir)/src/gallium/Automake.inc AM_CPPFLAGS = \ $(GALLIUM_CFLAGS) \ - $(X11_CFLAGS) + $(X11_INCLUDES) noinst_LTLIBRARIES = libws_xlib.la -- 1.8.3.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] use the correct variable for x11 includes
I'm not entirely sure if this one is right, but a change along these lines is required to build on systems with X11 outside of the system path in say /usr/X11R6 like on OpenBSD. On Thu, Jul 18, 2013 at 02:57:14PM +1000, Jonathan Gray wrote: > Signed-off-by: Jonathan Gray > --- > src/egl/drivers/glx/Makefile.am| 2 +- > src/gallium/winsys/sw/xlib/Makefile.am | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git src/egl/drivers/glx/Makefile.am src/egl/drivers/glx/Makefile.am > index 6bf67ea..220134d 100644 > --- src/egl/drivers/glx/Makefile.am > +++ src/egl/drivers/glx/Makefile.am > @@ -22,7 +22,7 @@ > AM_CFLAGS = \ > -I$(top_srcdir)/include \ > -I$(top_srcdir)/src/egl/main \ > - $(X11_CFLAGS) \ > + $(X11_INCLUDES) \ > $(DEFINES) > > noinst_LTLIBRARIES = libegl_glx.la > diff --git src/gallium/winsys/sw/xlib/Makefile.am > src/gallium/winsys/sw/xlib/Makefile.am > index 59da37d..ea6b742 100644 > --- src/gallium/winsys/sw/xlib/Makefile.am > +++ src/gallium/winsys/sw/xlib/Makefile.am > @@ -24,7 +24,7 @@ include $(top_srcdir)/src/gallium/Automake.inc > > AM_CPPFLAGS = \ > $(GALLIUM_CFLAGS) \ > - $(X11_CFLAGS) > + $(X11_INCLUDES) > > noinst_LTLIBRARIES = libws_xlib.la > > -- > 1.8.3.2 > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] r300g: make use of gallium's os_get_process_name()
Lets the code compile on non Linux systems.
Signed-off-by: Jonathan Gray
---
src/gallium/drivers/r300/r300_chipset.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git src/gallium/drivers/r300/r300_chipset.c
src/gallium/drivers/r300/r300_chipset.c
index 11061ed..30e085a 100644
--- src/gallium/drivers/r300/r300_chipset.c
+++ src/gallium/drivers/r300/r300_chipset.c
@@ -26,6 +26,7 @@
#include "util/u_debug.h"
#include "util/u_memory.h"
+#include "os/os_process.h"
#include
#include
@@ -47,9 +48,13 @@ static void r300_apply_hyperz_blacklist(struct
r300_capabilities* caps)
"firefox",
};
int i;
+char proc_name[128];
+
+if (!os_get_process_name(proc_name, sizeof(proc_name)))
+return;
for (i = 0; i < Elements(list); i++) {
-if (strcmp(list[i], program_invocation_short_name) == 0) {
+if (strcmp(list[i], proc_name) == 0) {
caps->zmask_ram = 0;
caps->hiz_ram = 0;
break;
--
1.8.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] don't include libdrm in an include statement
On Thu, Jul 18, 2013 at 10:24:00AM +0200, Michel Dänzer wrote: > On Don, 2013-07-18 at 14:45 +1000, Jonathan Gray wrote: > > Signed-off-by: Jonathan Gray > > --- > > src/gallium/drivers/radeonsi/Makefile.am | 3 ++- > > src/gallium/winsys/radeon/drm/radeon_winsys.h | 2 +- > > 2 files changed, 3 insertions(+), 2 deletions(-) > > > > diff --git src/gallium/drivers/radeonsi/Makefile.am > > src/gallium/drivers/radeonsi/Makefile.am > > index 46aa998..1cd85c4 100644 > > --- src/gallium/drivers/radeonsi/Makefile.am > > +++ src/gallium/drivers/radeonsi/Makefile.am > > @@ -29,7 +29,8 @@ AM_CPPFLAGS = \ > > -I$(top_srcdir)/src/gallium/drivers/radeon \ > > -I$(top_srcdir)/src/gallium/drivers \ > > -I$(top_srcdir)/include \ > > - $(GALLIUM_CFLAGS) > > + $(GALLIUM_CFLAGS) \ > > + $(LIBDRM_CFLAGS) > > AM_CFLAGS = $(LLVM_CFLAGS) > > > > libradeonsi_la_SOURCES = $(C_SOURCES) > > diff --git src/gallium/winsys/radeon/drm/radeon_winsys.h > > src/gallium/winsys/radeon/drm/radeon_winsys.h > > index a619d70..a500193 100644 > > --- src/gallium/winsys/radeon/drm/radeon_winsys.h > > +++ src/gallium/winsys/radeon/drm/radeon_winsys.h > > @@ -41,7 +41,7 @@ > > */ > > > > #include "pipebuffer/pb_buffer.h" > > -#include "libdrm/radeon_surface.h" > > +#include "radeon_surface.h" > > > > #define RADEON_MAX_CMDBUF_DWORDS (16 * 1024) > > > > I guess this is okay for now, though in the long run we shouldn't leak > winsys/platform specific details into the Gallium pipe driver like this. > > > Don't you need to add $(LIBDRM_CFLAGS) to > src/gallium/drivers/r600/Makefile.am as well though? I don't need to. Apparently because RADEON_CFLAGS includes the paths, perhaps the radeonsi Makefile.am should have RADEON_CFLAGS instead? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2] don't include libdrm in an include statement
v2: use RADEON_CFLAGS instead of LIBDRM_CFLAGS Signed-off-by: Jonathan Gray --- src/gallium/drivers/radeonsi/Makefile.am | 3 ++- src/gallium/winsys/radeon/drm/radeon_winsys.h | 2 +- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git src/gallium/drivers/radeonsi/Makefile.am src/gallium/drivers/radeonsi/Makefile.am index 46aa998..0c27973 100644 --- src/gallium/drivers/radeonsi/Makefile.am +++ src/gallium/drivers/radeonsi/Makefile.am @@ -29,7 +29,8 @@ AM_CPPFLAGS = \ -I$(top_srcdir)/src/gallium/drivers/radeon \ -I$(top_srcdir)/src/gallium/drivers \ -I$(top_srcdir)/include \ - $(GALLIUM_CFLAGS) + $(GALLIUM_CFLAGS) \ + $(RADEON_CFLAGS) AM_CFLAGS = $(LLVM_CFLAGS) libradeonsi_la_SOURCES = $(C_SOURCES) diff --git src/gallium/winsys/radeon/drm/radeon_winsys.h src/gallium/winsys/radeon/drm/radeon_winsys.h index a619d70..a500193 100644 --- src/gallium/winsys/radeon/drm/radeon_winsys.h +++ src/gallium/winsys/radeon/drm/radeon_winsys.h @@ -41,7 +41,7 @@ */ #include "pipebuffer/pb_buffer.h" -#include "libdrm/radeon_surface.h" +#include "radeon_surface.h" #define RADEON_MAX_CMDBUF_DWORDS (16 * 1024) -- 1.8.3.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] nouveau: don't assume libdrm include prefix
Signed-off-by: Jonathan Gray --- src/gallium/drivers/nouveau/Makefile.am | 2 +- src/gallium/drivers/nouveau/nouveau_context.h | 2 +- src/gallium/drivers/nouveau/nouveau_screen.c | 2 +- src/gallium/drivers/nouveau/nouveau_winsys.h | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git src/gallium/drivers/nouveau/Makefile.am src/gallium/drivers/nouveau/Makefile.am index 12e3da0..85f0b33 100644 --- src/gallium/drivers/nouveau/Makefile.am +++ src/gallium/drivers/nouveau/Makefile.am @@ -30,6 +30,6 @@ AM_CPPFLAGS = \ -I$(top_srcdir)/src/gallium/drivers \ -I$(top_srcdir)/include \ $(GALLIUM_CFLAGS) \ - $(LIBDRM_CFLAGS) + $(NOUVEAU_CFLAGS) libnouveau_la_SOURCES = $(C_SOURCES) diff --git src/gallium/drivers/nouveau/nouveau_context.h src/gallium/drivers/nouveau/nouveau_context.h index bad5ab7..c8d9d84 100644 --- src/gallium/drivers/nouveau/nouveau_context.h +++ src/gallium/drivers/nouveau/nouveau_context.h @@ -2,7 +2,7 @@ #define __NOUVEAU_CONTEXT_H__ #include "pipe/p_context.h" -#include +#include #define NOUVEAU_MAX_SCRATCH_BUFS 4 diff --git src/gallium/drivers/nouveau/nouveau_screen.c src/gallium/drivers/nouveau/nouveau_screen.c index d129a55..4eb730a 100644 --- src/gallium/drivers/nouveau/nouveau_screen.c +++ src/gallium/drivers/nouveau/nouveau_screen.c @@ -14,7 +14,7 @@ #include #include -#include +#include #include "nouveau_winsys.h" #include "nouveau_screen.h" diff --git src/gallium/drivers/nouveau/nouveau_winsys.h src/gallium/drivers/nouveau/nouveau_winsys.h index 9993ed6..51effb1 100644 --- src/gallium/drivers/nouveau/nouveau_winsys.h +++ src/gallium/drivers/nouveau/nouveau_winsys.h @@ -6,7 +6,7 @@ #include "pipe/p_defines.h" -#include +#include #ifndef NV04_PFIFO_MAX_PACKET_LEN #define NV04_PFIFO_MAX_PACKET_LEN 2047 -- 1.8.3.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] dri/nouveau: don't assume libdrm include prefix
Signed-off-by: Jonathan Gray --- src/mesa/drivers/dri/nouveau/nouveau_driver.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git src/mesa/drivers/dri/nouveau/nouveau_driver.h src/mesa/drivers/dri/nouveau/nouveau_driver.h index e03b2c1..c65c7c8 100644 --- src/mesa/drivers/dri/nouveau/nouveau_driver.h +++ src/mesa/drivers/dri/nouveau/nouveau_driver.h @@ -38,7 +38,7 @@ #undef NDEBUG #include -#include +#include #include "nouveau_screen.h" #include "nouveau_state.h" #include "nouveau_surface.h" -- 1.8.3.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa: use c99 functions on non-linux platforms if supported
Signed-off-by: Jonathan Gray --- src/mesa/main/imports.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git src/mesa/main/imports.h src/mesa/main/imports.h index 53e40b4..aa7dc49 100644 --- src/mesa/main/imports.h +++ src/mesa/main/imports.h @@ -230,7 +230,7 @@ static inline int IS_INF_OR_NAN( float x ) *** LDEXPF: multiply value by an integral power of two *** FREXPF: extract mantissa and exponent from value ***/ -#if defined(__gnu_linux__) +#if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L /* C99 functions */ #define CEILF(x) ceilf(x) #define FLOORF(x) floorf(x) -- 1.8.3.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: use c99 functions on non-linux platforms if supported
On Thu, Aug 01, 2013 at 11:21:57AM -0700, Ian Romanick wrote: > On 08/01/2013 09:54 AM, Chad Versace wrote: > >On 08/01/2013 09:48 AM, Chad Versace wrote: > >>On 08/01/2013 12:27 AM, Jonathan Gray wrote: > >>>Signed-off-by: Jonathan Gray > >>>--- > >>> src/mesa/main/imports.h | 2 +- > >>> 1 file changed, 1 insertion(+), 1 deletion(-) > >>> > >>>diff --git src/mesa/main/imports.h src/mesa/main/imports.h > >>>index 53e40b4..aa7dc49 100644 > >>>--- src/mesa/main/imports.h > >>>+++ src/mesa/main/imports.h > >>>@@ -230,7 +230,7 @@ static inline int IS_INF_OR_NAN( float x ) > >>> *** LDEXPF: multiply value by an integral power of two > >>> *** FREXPF: extract mantissa and exponent from value > >>> ***/ > >>>-#if defined(__gnu_linux__) > >>>+#if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L > >>> /* C99 functions */ > >>> #define CEILF(x) ceilf(x) > >>> #define FLOORF(x) floorf(x) > >> > >>This patch looks good to me, but I'm unable to test it. > >>On what platform did you test it? > > OpenBSD. > >I retract the "looks good". These functions are also available > >when compiling with `gcc -std=gnu89`, yet gnu89 does not > >define __STDC_VERSION__. > > This is the sort of issue I had in mind in my reply to this patch. > That's why autoconf (and other build systems) can figure out what > library functions are available and generate HAVE_CEILF, etc. macros > for them. There are already checks along the lines of what I'm adding as configure.ac makes gcc compile with -std=c99 > > >So, use > >#if defined(__gnu_linux) || (your_new_c99_checks) It doesn't really make sense to do that, especially as the rest of the file is different. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: use c99 functions on non-linux platforms if supported
On Mon, Aug 05, 2013 at 09:46:58AM -0700, Chad Versace wrote: > On 08/01/2013 03:52 PM, Jonathan Gray wrote: > >On Thu, Aug 01, 2013 at 11:21:57AM -0700, Ian Romanick wrote: > >>On 08/01/2013 09:54 AM, Chad Versace wrote: > >>>On 08/01/2013 09:48 AM, Chad Versace wrote: > >>>>On 08/01/2013 12:27 AM, Jonathan Gray wrote: > >>>>>Signed-off-by: Jonathan Gray > >>>>>--- > >>>>> src/mesa/main/imports.h | 2 +- > >>>>> 1 file changed, 1 insertion(+), 1 deletion(-) > >>>>> > >>>>>diff --git src/mesa/main/imports.h src/mesa/main/imports.h > >>>>>index 53e40b4..aa7dc49 100644 > >>>>>--- src/mesa/main/imports.h > >>>>>+++ src/mesa/main/imports.h > >>>>>@@ -230,7 +230,7 @@ static inline int IS_INF_OR_NAN( float x ) > >>>>> *** LDEXPF: multiply value by an integral power of two > >>>>> *** FREXPF: extract mantissa and exponent from value > >>>>> ***/ > >>>>>-#if defined(__gnu_linux__) > >>>>>+#if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L > >>>>> /* C99 functions */ > >>>>> #define CEILF(x) ceilf(x) > >>>>> #define FLOORF(x) floorf(x) > >>>> > >>>>This patch looks good to me, but I'm unable to test it. > >>>>On what platform did you test it? > >>> > > > >OpenBSD. > > > >>>I retract the "looks good". These functions are also available > >>>when compiling with `gcc -std=gnu89`, yet gnu89 does not > >>>define __STDC_VERSION__. > >> > >>This is the sort of issue I had in mind in my reply to this patch. > >>That's why autoconf (and other build systems) can figure out what > >>library functions are available and generate HAVE_CEILF, etc. macros > >>for them. > > > >There are already checks along the lines of what I'm adding > >as configure.ac makes gcc compile with -std=c99 > > > >> > >>>So, use > >>>#if defined(__gnu_linux) || (your_new_c99_checks) > > > >It doesn't really make sense to do that, especially as the > >rest of the file is different. > > > I see your point. The #ifdefs throughout the rest of the file have > sensible conditions. This is the only #ifdef that uses __gnu_linux__. > > I checked the Linux manpages for all functions in this #ifdef block. > According to the manpages, at least for glibc, all the functions have > the same feature macro requirement. > > _BSD_SOURCE || _SVID_SOURCE || _XOPEN_SOURCE >= 600 || _ISOC99_SOURCE || > _POSIX_C_SOURCE >= 200112L > > Do you see any problem with using this as the #ifdef condition? It seems > that this condition will be safe to use on BSD as well as Linux. The various _SOURCE macros control the visibility of definitions in headers and have to be defined by the program being compiled so I think you're a bit confused there, see http://linux.die.net/man/7/feature_test_macros The ifdef test is more about trying to spot systems that don't have c99 functions (msvc and ?). The impression I get from the glibc man page is you'll have to compile with --std=c99 (which mesa already does) or define _ISOC99_SOURCE before the relevant include. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] build: fix out-of-tree builds in gallium/auxiliary
The problems with the build system are bad enough without depending on non posix gnu only options. This should be mkdir -p On Tue, Aug 06, 2013 at 12:01:06PM +0100, Ross Burton wrote: > The rules were writing files to e.g. util/u_indices_gen.py, but in an > out-of-tree build this directory doesn't exist in the build directory. So, > create the directories just in case. > > NOTE: This is a candidate for the stable branches. > > Cc: mesa-sta...@lists.freedesktop.org > > Signed-off-by: Ross Burton > --- > src/gallium/auxiliary/Makefile.am |4 > 1 file changed, 4 insertions(+) > > diff --git a/src/gallium/auxiliary/Makefile.am > b/src/gallium/auxiliary/Makefile.am > index f14279b..0c3e7ba 100644 > --- a/src/gallium/auxiliary/Makefile.am > +++ b/src/gallium/auxiliary/Makefile.am > @@ -38,13 +38,17 @@ libgallium_la_SOURCES += \ > endif > > indices/u_indices_gen.c: $(srcdir)/indices/u_indices_gen.py > + mkdir --parents indices > $(AM_V_GEN) $(PYTHON2) $< > $@ > > indices/u_unfilled_gen.c: $(srcdir)/indices/u_unfilled_gen.py > + mkdir --parents indices > $(AM_V_GEN) $(PYTHON2) $< > $@ > > util/u_format_srgb.c: $(srcdir)/util/u_format_srgb.py > + mkdir --parents util > $(AM_V_GEN) $(PYTHON2) $< > $@ > > util/u_format_table.c: $(srcdir)/util/u_format_table.py > $(srcdir)/util/u_format_pack.py $(srcdir)/util/u_format_parse.py > $(srcdir)/util/u_format.csv > + mkdir --parents util > $(AM_V_GEN) $(PYTHON2) $(srcdir)/util/u_format_table.py > $(srcdir)/util/u_format.csv > $@ > -- > 1.7.10.4 > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] gallium: add endian detection for OpenBSD
Signed-off-by: Jonathan Gray --- src/gallium/include/pipe/p_config.h | 10 ++ 1 file changed, 10 insertions(+) diff --git src/gallium/include/pipe/p_config.h src/gallium/include/pipe/p_config.h index 1588a92..9af5df7 100644 --- src/gallium/include/pipe/p_config.h +++ src/gallium/include/pipe/p_config.h @@ -153,6 +153,16 @@ # define PIPE_ARCH_BIG_ENDIAN #endif +#elif defined(__OpenBSD__) +#include +#include + +#if _BYTE_ORDER == _LITTLE_ENDIAN +# define PIPE_ARCH_LITTLE_ENDIAN +#elif _BYTE_ORDER == _BIG_ENDIAN +# define PIPE_ARCH_BIG_ENDIAN +#endif + #else #if defined(PIPE_ARCH_X86) || defined(PIPE_ARCH_X86_64) || defined(PIPE_ARCH_ARM) || defined(PIPE_ARCH_AARCH64) -- 1.8.3.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] build: Install libwayland-egl.so.* symlinks in lib/
Going behind the back of libtool like this will break on any system that does not use linux style library versioning. No one wants to comment on any patches to avoid this. But if nothing else the comment about providing compatibility to the old build system is wrong as several people objected to removing the symlinks altogether. On Sun, Aug 18, 2013 at 06:00:05PM -0700, Kenneth Graunke wrote: > Like we do for all the other libraries. > > Signed-off-by: Kenneth Graunke > --- > src/egl/wayland/wayland-egl/Makefile.am | 8 > 1 file changed, 8 insertions(+) > > diff --git a/src/egl/wayland/wayland-egl/Makefile.am > b/src/egl/wayland/wayland-egl/Makefile.am > index 138c170..174d305 100644 > --- a/src/egl/wayland/wayland-egl/Makefile.am > +++ b/src/egl/wayland/wayland-egl/Makefile.am > @@ -9,3 +9,11 @@ lib_LTLIBRARIES = libwayland-egl.la > noinst_HEADERS = wayland-egl-priv.h > libwayland_egl_la_SOURCES = wayland-egl.c > libwayland_egl_la_LDFLAGS = -version-info 1 > + > +# Provide compatibility with scripts for the old Mesa build system for > +# a while by putting a link to the driver into /lib of the build tree. > +all-local: libwayland-egl.la > + $(MKDIR_P) $(top_builddir)/$(LIB_DIR); > + ln -f .libs/libwayland-egl.so.1.0.0 > $(top_builddir)/$(LIB_DIR)/libwayland-egl.so.1.0.0 > + ln -sf libwayland-egl.so.1.0.0 > $(top_builddir)/$(LIB_DIR)/libwayland-egl.so.1 > + ln -sf libwayland-egl.so.1 $(top_builddir)/$(LIB_DIR)/libwayland-egl.so > -- > 1.8.3.4 > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] automake: don't enable -Wl, --no-undefined on OpenBSD
OpenBSD does not have DT_NEEDED entries for libc by design, over concerns how the symbols would be referenced after changing the major version of the library. So avoid -no-undefined checks on OpenBSD as they will fail. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76856 Signed-off-by: Jonathan Gray --- configure.ac| 13 + src/egl/main/Makefile.am| 3 +-- src/egl/wayland/wayland-egl/Makefile.am | 3 +-- src/gallium/targets/egl-static/Makefile.am | 3 +-- src/gallium/targets/gbm/Makefile.am | 3 +-- src/gallium/targets/libgl-xlib/Makefile.am | 3 +-- src/gallium/targets/opencl/Makefile.am | 3 +-- src/gallium/targets/osmesa/Makefile.am | 3 +-- src/gallium/targets/pipe-loader/Makefile.am | 3 +-- src/gallium/targets/xa/Makefile.am | 3 +-- src/gbm/Makefile.am | 3 +-- src/glx/Makefile.am | 3 +-- src/mapi/es1api/Makefile.am | 3 +-- src/mapi/es2api/Makefile.am | 3 +-- src/mapi/shared-glapi/Makefile.am | 3 +-- src/mapi/vgapi/Makefile.am | 3 +-- src/mesa/drivers/osmesa/Makefile.am | 3 +-- src/mesa/drivers/x11/Makefile.am| 3 +-- 18 files changed, 30 insertions(+), 34 deletions(-) diff --git a/configure.ac b/configure.ac index 187006a..c1ce3e9 100644 --- a/configure.ac +++ b/configure.ac @@ -332,6 +332,19 @@ LDFLAGS=$save_LDFLAGS AC_SUBST([GC_SECTIONS]) dnl +dnl OpenBSD does not have DT_NEEDED entries for libc by design +dnl so these checks will fail +dnl +case "$host_os" in +openbsd*) +LD_NO_UNDEFINED="" ;; +*) +LD_NO_UNDEFINED="-no-undefined -Wl,--no-undefined" ;; +esac + +AC_SUBST([LD_NO_UNDEFINED]) + +dnl dnl compatibility symlinks dnl case "$host_os" in diff --git a/src/egl/main/Makefile.am b/src/egl/main/Makefile.am index e4c2539..d7d2581 100644 --- a/src/egl/main/Makefile.am +++ b/src/egl/main/Makefile.am @@ -74,11 +74,10 @@ libEGL_la_SOURCES = \ libEGL_la_LIBADD = \ $(EGL_LIB_DEPS) libEGL_la_LDFLAGS = \ - -no-undefined \ -version-number 1:0 \ -Wl,-Bsymbolic \ $(GC_SECTIONS) \ - -Wl,--no-undefined + $(LD_NO_UNDEFINED) if HAVE_EGL_PLATFORM_X11 AM_CFLAGS += -DHAVE_X11_PLATFORM diff --git a/src/egl/wayland/wayland-egl/Makefile.am b/src/egl/wayland/wayland-egl/Makefile.am index d3fe117..9a12448 100644 --- a/src/egl/wayland/wayland-egl/Makefile.am +++ b/src/egl/wayland/wayland-egl/Makefile.am @@ -9,10 +9,9 @@ lib_LTLIBRARIES = libwayland-egl.la noinst_HEADERS = wayland-egl-priv.h libwayland_egl_la_SOURCES = wayland-egl.c libwayland_egl_la_LDFLAGS = \ - -no-undefined \ -version-info 1 \ $(GC_SECTIONS) \ - -Wl,--no-undefined + $(LD_NO_UNDEFINED) TESTS = wayland-egl-symbols-check diff --git a/src/gallium/targets/egl-static/Makefile.am b/src/gallium/targets/egl-static/Makefile.am index 58ecf69..fb2b4a8 100644 --- a/src/gallium/targets/egl-static/Makefile.am +++ b/src/gallium/targets/egl-static/Makefile.am @@ -46,10 +46,9 @@ AM_CPPFLAGS = \ AM_LDFLAGS = \ -module \ - -no-undefined \ -avoid-version \ $(GC_SECTIONS) \ - -Wl,--no-undefined \ + $(LD_NO_UNDEFINED) \ -Wl,--version-script=$(top_srcdir)/src/gallium/targets/egl-static/egl.link egldir = $(EGL_DRIVER_INSTALL_DIR) diff --git a/src/gallium/targets/gbm/Makefile.am b/src/gallium/targets/gbm/Makefile.am index 22b4826..956802a 100644 --- a/src/gallium/targets/gbm/Makefile.am +++ b/src/gallium/targets/gbm/Makefile.am @@ -68,10 +68,9 @@ endif gbm_gallium_drm_la_LDFLAGS = \ -module \ - -no-undefined \ -avoid-version \ $(GC_SECTIONS) \ - -Wl,--no-undefined + $(LD_NO_UNDEFINED) if HAVE_MESA_LLVM gbm_gallium_drm_la_LIBADD += $(LLVM_LIBS) diff --git a/src/gallium/targets/libgl-xlib/Makefile.am b/src/gallium/targets/libgl-xlib/Makefile.am index ef3d23e..a45fc7b 100644 --- a/src/gallium/targets/libgl-xlib/Makefile.am +++ b/src/gallium/targets/libgl-xlib/Makefile.am @@ -45,10 +45,9 @@ lib_LTLIBRARIES = libGL.la nodist_EXTRA_libGL_la_SOURCES = dummy.cpp libGL_la_SOURCES = xlib.c libGL_la_LDFLAGS = \ - -no-undefined \ -version-number $(GL_MAJOR):$(GL_MINOR):$(GL_TINY) \ $(GC_SECTIONS) \ - -Wl,--no-undefined + $(LD_NO_UNDEFINED) libGL_la_LIBADD = \ $(top_builddir)/src/gallium/state_trackers/glx/xlib/libxlib.la \ diff --git a/src/gallium/targets/opencl/Makefile.am b/src/gallium/targets/opencl/Makefile.am index aae31ff..8a59151 100644 --- a/src/gallium/targets/opencl/Makefile.am +++ b/src/gallium/targets/opencl/Makefile.am @@ -4,10 +4,9 @@ lib_LTLIBRARIES = lib@OPENCL_LIBNAME@.la lib@OPENCL_LIBNAME@_la_LDFLAGS = \ $(LLVM_LDFLAGS) \ - -no-undefined \ -version-number 1:0 \ $(G
[Mesa-dev] [PATCH v2] automake: don't enable -Wl, --no-undefined on OpenBSD
OpenBSD does not have DT_NEEDED entries for libc by design, over concerns how the symbols would be referenced after changing the major version of the library. So avoid -no-undefined checks on OpenBSD as they will fail. v2: don't include the -no-undefined libtool option in the variable and change -Wl,--no-undefined references in Automake.inc as well. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76856 Signed-off-by: Jonathan Gray --- configure.ac| 13 + src/egl/main/Makefile.am| 2 +- src/egl/wayland/wayland-egl/Makefile.am | 2 +- src/gallium/Automake.inc| 6 +++--- src/gallium/targets/egl-static/Makefile.am | 2 +- src/gallium/targets/gbm/Makefile.am | 2 +- src/gallium/targets/libgl-xlib/Makefile.am | 2 +- src/gallium/targets/opencl/Makefile.am | 2 +- src/gallium/targets/osmesa/Makefile.am | 2 +- src/gallium/targets/pipe-loader/Makefile.am | 2 +- src/gallium/targets/xa/Makefile.am | 2 +- src/gbm/Makefile.am | 2 +- src/glx/Makefile.am | 2 +- src/mapi/es1api/Makefile.am | 2 +- src/mapi/es2api/Makefile.am | 2 +- src/mapi/shared-glapi/Makefile.am | 2 +- src/mapi/vgapi/Makefile.am | 2 +- src/mesa/drivers/osmesa/Makefile.am | 2 +- src/mesa/drivers/x11/Makefile.am| 2 +- 19 files changed, 33 insertions(+), 20 deletions(-) diff --git a/configure.ac b/configure.ac index 187006a..94b6dc2 100644 --- a/configure.ac +++ b/configure.ac @@ -332,6 +332,19 @@ LDFLAGS=$save_LDFLAGS AC_SUBST([GC_SECTIONS]) dnl +dnl OpenBSD does not have DT_NEEDED entries for libc by design +dnl so when these flags are passed to ld via libtool the checks will fail +dnl +case "$host_os" in +openbsd*) +LD_NO_UNDEFINED="" ;; +*) +LD_NO_UNDEFINED="-Wl,--no-undefined" ;; +esac + +AC_SUBST([LD_NO_UNDEFINED]) + +dnl dnl compatibility symlinks dnl case "$host_os" in diff --git a/src/egl/main/Makefile.am b/src/egl/main/Makefile.am index e4c2539..4b42bd6 100644 --- a/src/egl/main/Makefile.am +++ b/src/egl/main/Makefile.am @@ -78,7 +78,7 @@ libEGL_la_LDFLAGS = \ -version-number 1:0 \ -Wl,-Bsymbolic \ $(GC_SECTIONS) \ - -Wl,--no-undefined + $(LD_NO_UNDEFINED) if HAVE_EGL_PLATFORM_X11 AM_CFLAGS += -DHAVE_X11_PLATFORM diff --git a/src/egl/wayland/wayland-egl/Makefile.am b/src/egl/wayland/wayland-egl/Makefile.am index d3fe117..a03a7bf 100644 --- a/src/egl/wayland/wayland-egl/Makefile.am +++ b/src/egl/wayland/wayland-egl/Makefile.am @@ -12,7 +12,7 @@ libwayland_egl_la_LDFLAGS = \ -no-undefined \ -version-info 1 \ $(GC_SECTIONS) \ - -Wl,--no-undefined + $(LD_NO_UNDEFINED) TESTS = wayland-egl-symbols-check diff --git a/src/gallium/Automake.inc b/src/gallium/Automake.inc index 56f1433..beec755 100644 --- a/src/gallium/Automake.inc +++ b/src/gallium/Automake.inc @@ -67,7 +67,7 @@ GALLIUM_VDPAU_LINKER_FLAGS = \ -version-number $(VDPAU_MAJOR):$(VDPAU_MINOR) \ -export-symbols-regex $(VDPAU_EXPORTS) \ $(GC_SECTIONS) \ - -Wl,--no-undefined + $(LD_NO_UNDEFINED) GALLIUM_XVMC_LINKER_FLAGS = \ -shared \ @@ -76,7 +76,7 @@ GALLIUM_XVMC_LINKER_FLAGS = \ -version-number $(XVMC_MAJOR):$(XVMC_MINOR) \ -export-symbols-regex '^XvMC' \ $(GC_SECTIONS) \ - -Wl,--no-undefined + $(LD_NO_UNDEFINED) GALLIUM_OMX_LINKER_FLAGS = \ -shared \ @@ -84,7 +84,7 @@ GALLIUM_OMX_LINKER_FLAGS = \ -no-undefined \ -export-symbols-regex $(EXPORTS) \ $(GC_SECTIONS) \ - -Wl,--no-undefined + $(LD_NO_UNDEFINED) GALLIUM_VDPAU_LIB_DEPS = \ $(top_builddir)/src/gallium/auxiliary/libgallium.la \ diff --git a/src/gallium/targets/egl-static/Makefile.am b/src/gallium/targets/egl-static/Makefile.am index 58ecf69..40e7a96 100644 --- a/src/gallium/targets/egl-static/Makefile.am +++ b/src/gallium/targets/egl-static/Makefile.am @@ -49,7 +49,7 @@ AM_LDFLAGS = \ -no-undefined \ -avoid-version \ $(GC_SECTIONS) \ - -Wl,--no-undefined \ + $(LD_NO_UNDEFINED) \ -Wl,--version-script=$(top_srcdir)/src/gallium/targets/egl-static/egl.link egldir = $(EGL_DRIVER_INSTALL_DIR) diff --git a/src/gallium/targets/gbm/Makefile.am b/src/gallium/targets/gbm/Makefile.am index 22b4826..2b54e3c 100644 --- a/src/gallium/targets/gbm/Makefile.am +++ b/src/gallium/targets/gbm/Makefile.am @@ -71,7 +71,7 @@ gbm_gallium_drm_la_LDFLAGS = \ -no-undefined \ -avoid-version \ $(GC_SECTIONS) \ - -Wl,--no-undefined + $(LD_NO_UNDEFINED) if HAVE_MESA_LLVM gbm_gallium_drm_la_LIBADD += $(LLVM_LIBS) diff --git a/src/gallium/targets/libgl-xlib/Makefile.am b/src/gallium/targets/libgl-xlib/Make
[Mesa-dev] [PATCH v3] egl/dri2: use drm macros to construct device name
Don't hardcode /dev/dri/card0 but instead use the drm
macros which allows the correct /dev/drm0 device to be
opened on OpenBSD.
v2: use snprintf and fallback to /dev/dri/card0
v3: check for snprintf truncation
Signed-off-by: Jonathan Gray
---
src/egl/drivers/dri2/platform_drm.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/src/egl/drivers/dri2/platform_drm.c
b/src/egl/drivers/dri2/platform_drm.c
index 2f7edb9..9a7633a 100644
--- a/src/egl/drivers/dri2/platform_drm.c
+++ b/src/egl/drivers/dri2/platform_drm.c
@@ -492,7 +492,12 @@ dri2_initialize_drm(_EGLDriver *drv, _EGLDisplay *disp)
gbm = disp->PlatformDisplay;
if (gbm == NULL) {
- fd = open("/dev/dri/card0", O_RDWR);
+ char buf[64];
+ int n = snprintf(buf, sizeof(buf), DRM_DEV_NAME, DRM_DIR_NAME, 0);
+ if (n != -1 && n < sizeof(buf))
+ fd = open(buf, O_RDWR);
+ if (fd < 0)
+ fd = open("/dev/dri/card0", O_RDWR);
dri2_dpy->own_device = 1;
gbm = gbm_create_device(fd);
if (gbm == NULL)
--
1.9.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3] egl/dri2: use drm macros to construct device name
On Wed, Apr 02, 2014 at 11:09:09PM -0700, Matt Turner wrote:
> On Wed, Apr 2, 2014 at 10:22 PM, Jonathan Gray wrote:
> > Don't hardcode /dev/dri/card0 but instead use the drm
> > macros which allows the correct /dev/drm0 device to be
> > opened on OpenBSD.
> >
> > v2: use snprintf and fallback to /dev/dri/card0
> > v3: check for snprintf truncation
> >
> > Signed-off-by: Jonathan Gray
> > ---
> > src/egl/drivers/dri2/platform_drm.c | 7 ++-
> > 1 file changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/egl/drivers/dri2/platform_drm.c
> > b/src/egl/drivers/dri2/platform_drm.c
> > index 2f7edb9..9a7633a 100644
> > --- a/src/egl/drivers/dri2/platform_drm.c
> > +++ b/src/egl/drivers/dri2/platform_drm.c
> > @@ -492,7 +492,12 @@ dri2_initialize_drm(_EGLDriver *drv, _EGLDisplay *disp)
> >
> > gbm = disp->PlatformDisplay;
> > if (gbm == NULL) {
> > - fd = open("/dev/dri/card0", O_RDWR);
> > + char buf[64];
> > + int n = snprintf(buf, sizeof(buf), DRM_DEV_NAME, DRM_DIR_NAME, 0);
> > + if (n != -1 && n < sizeof(buf))
>
> n <= sizeof(buf), right? snprintf writes up to sizeof(buf) bytes,
> including the nul character.
>
> With that fixed,
>
> Reviewed-by: Matt Turner
No, see the description from the manual page:
http://www.openbsd.org/cgi-bin/man.cgi?query=snprintf&sektion=3&format=html
snprintf() and vsnprintf() will write at most size-1 of the characters
printed into the output string (the size'th character then gets the
terminating `\0'); if the return value is greater than or equal to the
size argument, the string was too short and some of the printed
characters were discarded.
So n == sizeof(buf) is a truncation.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] egl/dri2: don't require libudev to build drm/wayland platforms
On Sat, Apr 05, 2014 at 02:12:31PM +0100, Emil Velikov wrote: > Hi Jonathan, > > Just pushed as many of your patches as I can see to master. Let me know if I > missed any. > > Some of the patches are stable material, so I've tagged them for the 10.1 > stable branch. > > Thanks again. > -Emil Great, thank you. There are still a few things, not all of which I've sent out patches for. http://marc.info/?l=mesa3d-dev&m=137534209528776&w=2 removed a misused __gnu_linux__ ifdef, there was some discussion but no clear alternative out of it. http://marc.info/?l=mesa3d-dev&m=139446389719785&w=2 removed a grep escape sequence in ax_prog_flex.m4 that isn't as portable as grep -w. This was later accepted upstream in http://git.savannah.gnu.org/cgit/autoconf-archive.git/commit/?id=98e799a84f7aa040ff755277c5788f6ffce541d6 though they didn't reply to a mail after that on how to handle a string like 'gflex 2.5.35'. In order to build I have to revert 'fix vdpau interop when using -Bsymbolic-functions in ldflags' 8c136b53b79e90b9e8f30f891b8bef112fee375d as there is no --dynamic-list in ld here. In r600/sb I have to move two '#include "r600_pipe.h"' lines outside of extern "C" to build, no patch sent out for that yet. and I have an unsubmitted patch for configure.ac along the lines of -CFLAGS="$CFLAGS -Wall -std=c99" +CFLAGS="$CFLAGS -Wall -std=c99 -fms-extensions" for https://bugs.freedesktop.org/show_bug.cgi?id=76789 otherwise radeonsi doesn't build. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] glsl: simplify the M_PI*f macros, fixes build on OpenBSD
The M_PI*f macros used a preprocessor paste to append 'f' to M_PI defines, which works if the values are only numbers but breaks on OpenBSD where M_PI definitions have casts and brackets to meet requirements of a future version of POSIX, http://austingroupbugs.net/view.php?id=801 http://austingroupbugs.net/view.php?id=828 Simplify the M_PI*f macros by using casts directly in the defines as suggested by Kenneth Graunke. Cc: "10.2" Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78665 Signed-off-by: Jonathan Gray --- src/glsl/builtin_functions.cpp | 8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/src/glsl/builtin_functions.cpp b/src/glsl/builtin_functions.cpp index 3991f9d..aeed96e 100644 --- a/src/glsl/builtin_functions.cpp +++ b/src/glsl/builtin_functions.cpp @@ -62,11 +62,9 @@ #include "program/prog_instruction.h" #include -#define f(x) join(x) -#define join(x) x ## f -#define M_PIf f(M_PI) -#define M_PI_2f f(M_PI_2) -#define M_PI_4f f(M_PI_4) +#define M_PIf ((float) M_PI) +#define M_PI_2f((float) M_PI_2) +#define M_PI_4f((float) M_PI_4) using namespace ir_builder; -- 1.9.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] configure: correctly set LD_NO_UNDEFINED
Reviewed-by: Jonathan Gray ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 16/23] targets/vdpau: convert to static and shared pipe-drivers
On Sun, May 18, 2014 at 08:07:38AM +0100, Emil Velikov wrote: > Create a single library containing the state-tracker etc. > thus have a smaller overall size footprint of mesa. > > The driver can be built with the relevant pipe-drivers > statically linked in, or loaded as shared modules. > Currently we default to static link. > > Add SPLIT_TARGETS to guard the other VL targets. > > Note: symlink handling is rather ugly at the moment due > to versioning of the libvdpau library. Tested only on > linux plarform. BSD and other platforms will likely need > and update. Given these links will fail and break builds perhaps only do them on systems where the library versioning is known to work like it does on linux, otherwise install multiple copies of the library? That or find a way to get libtool to create them. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 16/23] targets/vdpau: convert to static and shared pipe-drivers
On Sun, May 18, 2014 at 09:44:00AM +0100, Emil Velikov wrote: > On 18/05/14 08:41, Jonathan Gray wrote: > > On Sun, May 18, 2014 at 08:07:38AM +0100, Emil Velikov wrote: > >> Create a single library containing the state-tracker etc. > >> thus have a smaller overall size footprint of mesa. > >> > >> The driver can be built with the relevant pipe-drivers > >> statically linked in, or loaded as shared modules. > >> Currently we default to static link. > >> > >> Add SPLIT_TARGETS to guard the other VL targets. > >> > >> Note: symlink handling is rather ugly at the moment due > >> to versioning of the libvdpau library. Tested only on > >> linux plarform. BSD and other platforms will likely need > >> and update. > > > > Given these links will fail and break builds perhaps > > only do them on systems where the library versioning > > is known to work like it does on linux, otherwise > > install multiple copies of the library? > > > > That or find a way to get libtool to create them. > > > Hi Jonathan, > > Just had a look but did not manage to see a OpenBSD repo that uses latest (or > 10+ era) mesa. > > I was looking for the targets which are built under OpenBSD, although > xanocara's mesa 9.2.x is not too informative. I have an updated set of xenocara makefiles for Mesa 10.2 that I haven't put up yet, those will be committed after a newer Mesa release is imported. Thanks to the loader changes libgbm can even be included allowing glamor to work. The 'src' tree in OpenBSD is self contained and contains all of the tools required to build itself. The 'xenocara' tree contains X11 related parts and can only depend on other things in the xenocara and src trees. Packages are built from the 'ports' tree which has makefiles/patches for building things but does not include the source to the packages directly unlike the src and xenocara trees. That is why Mesa in xenocara has a seperate set of makefiles, otherwise we would have to import python, gnu make, and other things which isn't going to happen. To try to reduce the pain in doing this I do builds of Mesa every so often using the autotools setup. With a collection of various patches. The patches can be found here: https://github.com/jonathangray/mesa/commits/fixes not all of them are appropriate for the main Mesa tree. > > - Which of the targets addressed in these series are built/used with OpenBSD ? Currently I run my autotools builds like this: export LDFLAGS=-L/usr/local/lib export CPPFLAGS="-I/usr/local/include -I/usr/local/include/libelf" export AUTOMAKE_VERSION=1.12 export AUTOCONF_VERSION=2.69 export LEX=/usr/local/bin/gflex ./autogen.sh \ --with-gallium-drivers=r300,r600,radeonsi,swrast,nouveau \ --with-dri-drivers=i915,i965,r200,radeon,swrast \ --disable-silent-rules \ --enable-r600-llvm-compiler --enable-gallium-llvm \ --disable-llvm-shared-libs \ --enable-gles1 --enable-gles2 \ --enable-shared-glapi \ --disable-osmesa \ --enable-debug \ --enable-gbm \ --with-egl-platforms="x11,drm" \ --prefix=/usr/mesa > - Do you have a link/spec/doc that I can lookup the platform's shared library > versioning scheme ? It is sunos 4.x style versioning, where as Linux seems to use System V style? Libraries are all libfoo.so.major.minor with no revision and no symlinks. ld.so will search for the newest library with "libfoo.so.major" or the like but "libfoo.so.major" never exists on the filesystem. The OpenBSD scheme is a simplified one with no symbol versioning, so DT_SONAME doesn't make a lot of sense. ELF shared libraries do not have DT_NEEDED entries for libc by design (which is why the configure script doesn't use -Wl,--no-undefined on OpenBSD). I suspect FreeBSD/NetBSD work in a similiar manner given FreeBSD couldn't build Mesa without symlink related patches some time ago. Though FreeBSD apparently have introduced symbol versioning and changed the behaviour when they switched to ELF. Shared libraries are briefly mentioned here http://www.openbsd.org/faq/ports/specialtopics.html#SharedLibs similiar text for FreeBSD can be found here https://www.freebsd.org/doc/en/books/developers-handbook/policies-shlib.html > - Are you aware of any projects that go through these hoops (hardlinks + > versioned fun) that I can get some inspiration from ? Libtool, cmake and other things along those lines, but anything that builds shared libraries and doesn't use those likely contains some knowledge of how to construct names for Mac OS X, windows, linux, bsd etc as they all seem to be different. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 16/23] targets/vdpau: convert to static and shared pipe-drivers
On Mon, May 19, 2014 at 11:57:58PM +0100, Emil Velikov wrote: > On 18/05/14 12:22, Jonathan Gray wrote: > [snip] > > > > Currently I run my autotools builds like this: > > > > export LDFLAGS=-L/usr/local/lib > > export CPPFLAGS="-I/usr/local/include -I/usr/local/include/libelf" > > export AUTOMAKE_VERSION=1.12 > > export AUTOCONF_VERSION=2.69 > > export LEX=/usr/local/bin/gflex > > ./autogen.sh \ > > --with-gallium-drivers=r300,r600,radeonsi,swrast,nouveau \ > > --with-dri-drivers=i915,i965,r200,radeon,swrast \ > > --disable-silent-rules \ > > --enable-r600-llvm-compiler --enable-gallium-llvm \ > > --disable-llvm-shared-libs \ > > --enable-gles1 --enable-gles2 \ > > --enable-shared-glapi \ > > --disable-osmesa \ > > --enable-debug \ > > --enable-gbm \ > > --with-egl-platforms="x11,drm" \ > > --prefix=/usr/mesa > > > I'm a bit curious how xenocara's CVS is going to handle the symlinks when > building dri/radeon, dri/r200 and st/dri (all gallium dri drivers). AFAICS it > will fail miserably :\ > If interested you can rework the former two and effectively drop a handful > symbol redefinition, shed off some code and size off the classic dri. I'm > planning to address the st/dri case after this series is merged. I'm not really sure what xenocara has to do with the autotools build? As said before xenocara uses it's own set of makefiles, ie http://www.openbsd.org/cgi-bin/cvsweb/xenocara/lib/libGL/dri/radeon/Makefile?rev=HEAD;content-type=text%2Fplain http://www.openbsd.org/cgi-bin/cvsweb/xenocara/lib/libGL/dri/r600g/Makefile?rev=HEAD;content-type=text%2Fplain with seperate directories for libglapi libGL libEGL libGLESv1_CM libGLESv2 that refer to the source in http://www.openbsd.org/cgi-bin/cvsweb/xenocara/dist/Mesa/ > > >From the above configure one cannot determine if you're building vdpau. > Current code enables the vdpau targets if the vdpau package is available. Can > you confirm if this is the case or not ? My autotools builds are not done on a system with vdpau installed. The resulting target list from configure here looks like: Gallium: yes Target dirs: dri-nouveau dri-swrast r300/dri r600/dri radeonsi/dri Winsys dirs: nouveau/drm radeon/drm sw sw/dri sw/xlib Driver dirs: galahad identity llvmpipe noop nouveau r300 r600 radeonsi rbug softpipe trace Trackers dirs: dri The build does not seem to reference gallium/state_trackers/vdpau but does build mesa/main/vdpau.c and mesa/state_tracker/st_vdpau.c It would be nice to have the possibility of building the gallium vdpau code in future however. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] radeon/winsys: correct RADEON_GEM_WAIT_IDLE use
RADEON_GEM_WAIT_IDLE is declared DRM_IOW but mesa
uses it with drmCommandWriteRead instead of drmCommandWrite
which leads to the ioctl being unmatched and returning an
error on at least OpenBSD.
Problem originally noticed in libdrm by Mark Kettenis.
Dave Airlie pointed out that mesa has the same issue.
Signed-off-by: Jonathan Gray
---
src/gallium/winsys/radeon/drm/radeon_drm_bo.c | 2 +-
src/gallium/winsys/radeon/tools/radeon_ctx.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git src/gallium/winsys/radeon/drm/radeon_drm_bo.c
src/gallium/winsys/radeon/drm/radeon_drm_bo.c
index 6ec1713..bcd4b27 100644
--- src/gallium/winsys/radeon/drm/radeon_drm_bo.c
+++ src/gallium/winsys/radeon/drm/radeon_drm_bo.c
@@ -167,7 +167,7 @@ static void radeon_bo_wait(struct pb_buffer *_buf, enum
radeon_bo_usage usage)
struct drm_radeon_gem_wait_idle args;
memset(&args, 0, sizeof(args));
args.handle = bo->handle;
-while (drmCommandWriteRead(bo->rws->fd, DRM_RADEON_GEM_WAIT_IDLE,
+while (drmCommandWrite(bo->rws->fd, DRM_RADEON_GEM_WAIT_IDLE,
&args, sizeof(args)) == -EBUSY);
}
}
diff --git src/gallium/winsys/radeon/tools/radeon_ctx.h
src/gallium/winsys/radeon/tools/radeon_ctx.h
index c2967ff..1eecfd5 100644
--- src/gallium/winsys/radeon/tools/radeon_ctx.h
+++ src/gallium/winsys/radeon/tools/radeon_ctx.h
@@ -98,7 +98,7 @@ static void bo_wait(struct ctx *ctx, struct bo *bo)
memset(&args, 0, sizeof(args));
args.handle = bo->handle;
do {
-r = drmCommandWriteRead(ctx->fd, DRM_RADEON_GEM_WAIT_IDLE, &args,
sizeof(args));
+r = drmCommandWrite(ctx->fd, DRM_RADEON_GEM_WAIT_IDLE, &args,
sizeof(args));
} while (r == -EBUSY);
}
--
1.8.2.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] radeon/winsys: correct RADEON_GEM_WAIT_IDLE use
On Thu, Jun 06, 2013 at 11:30:50AM +0200, Michel Dänzer wrote:
> On Mit, 2013-06-05 at 15:00 +1000, Jonathan Gray wrote:
> > RADEON_GEM_WAIT_IDLE is declared DRM_IOW but mesa
> > uses it with drmCommandWriteRead instead of drmCommandWrite
> > which leads to the ioctl being unmatched and returning an
> > error on at least OpenBSD.
> >
> > Problem originally noticed in libdrm by Mark Kettenis.
> > Dave Airlie pointed out that mesa has the same issue.
> >
> > Signed-off-by: Jonathan Gray
>
> Pushed, thanks!
>
> For the libdrm patch, if it really is from Mark, can you set him as the
> Git commit author, and maybe get a Signed-off-by: from him?
His diff was against an older version we track via cvs.
While I seem to have done the right incantations for this
locally, due to the way git format-patch seems to depend on
email headers would I still be able to send the resulting
patch without having to subscribe Mark to the list?
I've attached the raw format-patch output here instead
of trying to mail it normally.
>From c66207b904890bd8cc15822cad091b0e797f4a47 Mon Sep 17 00:00:00 2001
From: Mark Kettenis
Date: Wed, 5 Jun 2013 13:04:30 +1000
Subject: [PATCH] radeon: correct RADEON_GEM_WAIT_IDLE use
RADEON_GEM_WAIT_IDLE is declared DRM_IOW but libdrm
uses it with drmCommandWriteRead instead of drmCommandWrite
which leads to the ioctl being unmatched and returning an
error on at least OpenBSD.
Signed-off-by: Mark Kettenis
Signed-off-by: Jonathan Gray
---
radeon/radeon_bo_gem.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git radeon/radeon_bo_gem.c radeon/radeon_bo_gem.c
index fca0aaf..4ea405f 100644
--- radeon/radeon_bo_gem.c
+++ radeon/radeon_bo_gem.c
@@ -211,8 +211,8 @@ static int bo_wait(struct radeon_bo_int *boi)
memset(&args, 0, sizeof(args));
args.handle = boi->handle;
do {
-ret = drmCommandWriteRead(boi->bom->fd, DRM_RADEON_GEM_WAIT_IDLE,
- &args, sizeof(args));
+ret = drmCommandWrite(boi->bom->fd, DRM_RADEON_GEM_WAIT_IDLE,
+ &args, sizeof(args));
} while (ret == -EBUSY);
return ret;
}
--
1.8.2.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] gallium: replace bswap_32 calls with util_bswap32
byteswap.h and bswap_32 aren't portable, replace them with calls to
gallium's util_bswap32 as suggested by Mark Kettenis. Lets these files
build on OpenBSD.
Signed-off-by: Jonathan Gray
---
src/gallium/drivers/r600/r600_asm.c | 4 ++--
src/gallium/drivers/r600/r600_shader.c | 4 ++--
src/gallium/drivers/r600/r600_state_common.c | 4 ++--
src/gallium/drivers/radeonsi/r600_buffer.c | 4 +---
4 files changed, 7 insertions(+), 9 deletions(-)
diff --git src/gallium/drivers/r600/r600_asm.c
src/gallium/drivers/r600/r600_asm.c
index 08fe24e..b8eedae 100644
--- src/gallium/drivers/r600/r600_asm.c
+++ src/gallium/drivers/r600/r600_asm.c
@@ -27,9 +27,9 @@
#include "r600d.h"
#include
-#include
#include "util/u_dump.h"
#include "util/u_memory.h"
+#include "util/u_math.h"
#include "pipe/p_shader_tokens.h"
#include "sb/sb_public.h"
@@ -2419,7 +2419,7 @@ void *r600_create_vertex_fetch_shader(struct pipe_context
*ctx,
if (R600_BIG_ENDIAN) {
for (i = 0; i < fs_size / 4; ++i) {
- bytecode[i] = bswap_32(bc.bytecode[i]);
+ bytecode[i] = util_bswap32(bc.bytecode[i]);
}
} else {
memcpy(bytecode, bc.bytecode, fs_size);
diff --git src/gallium/drivers/r600/r600_shader.c
src/gallium/drivers/r600/r600_shader.c
index 81ed3ce..3a734bc 100644
--- src/gallium/drivers/r600/r600_shader.c
+++ src/gallium/drivers/r600/r600_shader.c
@@ -35,9 +35,9 @@
#include "tgsi/tgsi_scan.h"
#include "tgsi/tgsi_dump.h"
#include "util/u_memory.h"
+#include "util/u_math.h"
#include
#include
-#include
/* CAYMAN notes
Why CAYMAN got loops for lots of instructions is explained here.
@@ -194,7 +194,7 @@ int r600_pipe_shader_create(struct pipe_context *ctx,
ptr = r600_buffer_mmap_sync_with_rings(rctx, shader->bo,
PIPE_TRANSFER_WRITE);
if (R600_BIG_ENDIAN) {
for (i = 0; i < shader->shader.bc.ndw; ++i) {
- ptr[i] =
bswap_32(shader->shader.bc.bytecode[i]);
+ ptr[i] =
util_bswap32(shader->shader.bc.bytecode[i]);
}
} else {
memcpy(ptr, shader->shader.bc.bytecode,
shader->shader.bc.ndw * sizeof(*ptr));
diff --git src/gallium/drivers/r600/r600_state_common.c
src/gallium/drivers/r600/r600_state_common.c
index 4995c81..b9a8f0b 100644
--- src/gallium/drivers/r600/r600_state_common.c
+++ src/gallium/drivers/r600/r600_state_common.c
@@ -32,8 +32,8 @@
#include "util/u_index_modify.h"
#include "util/u_memory.h"
#include "util/u_upload_mgr.h"
+#include "util/u_math.h"
#include "tgsi/tgsi_parse.h"
-#include
#define R600_PRIM_RECTANGLE_LIST PIPE_PRIM_MAX
@@ -953,7 +953,7 @@ static void r600_set_constant_buffer(struct pipe_context
*ctx, uint shader, uint
}
for (i = 0; i < size / 4; ++i) {
- tmpPtr[i] = bswap_32(((uint32_t *)ptr)[i]);
+ tmpPtr[i] = util_bswap32(((uint32_t *)ptr)[i]);
}
u_upload_data(rctx->uploader, 0, size, tmpPtr,
&cb->buffer_offset, &cb->buffer);
diff --git src/gallium/drivers/radeonsi/r600_buffer.c
src/gallium/drivers/radeonsi/r600_buffer.c
index 3d295e8..2bc47c1 100644
--- src/gallium/drivers/radeonsi/r600_buffer.c
+++ src/gallium/drivers/radeonsi/r600_buffer.c
@@ -25,8 +25,6 @@
* Corbin Simpson
*/
-#include
-
#include "pipe/p_screen.h"
#include "util/u_format.h"
#include "util/u_math.h"
@@ -185,7 +183,7 @@ void r600_upload_const_buffer(struct r600_context *rctx,
struct si_resource **rb
}
for (i = 0; i < size / 4; ++i) {
- tmpPtr[i] = bswap_32(((uint32_t *)ptr)[i]);
+ tmpPtr[i] = util_bswap32(((uint32_t *)ptr)[i]);
}
u_upload_data(rctx->uploader, 0, size, tmpPtr, const_offset,
--
1.8.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium: replace bswap_32 calls with util_bswap32
On Mon, Jun 17, 2013 at 07:47:11AM +0200, Michel Dänzer wrote: > On Mon, 2013-06-17 at 01:11 +1000, Jonathan Gray wrote: > > byteswap.h and bswap_32 aren't portable, replace them with calls to > > gallium's util_bswap32 as suggested by Mark Kettenis. Lets these files > > build on OpenBSD. > > > > Signed-off-by: Jonathan Gray > > Reviewed-by: Michel Dänzer > > Do you need someone to apply this for you? Yes, I don't have access. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] configure.ac: make grep tests more portable
Use grep -w instead of the empty string escape sequences
which are less portable. Makes the grep tests
function as intended on OpenBSD.
Signed-off-by: Jonathan Gray
---
configure.ac | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git configure.ac configure.ac
index 6832b0d..45d9b1c 100644
--- configure.ac
+++ configure.ac
@@ -1580,14 +1580,14 @@ if test "x$enable_gallium_llvm" = xyes; then
LLVM_VERSION=`$LLVM_CONFIG --version | sed 's/svn.*//g'`
LLVM_VERSION_INT=`echo $LLVM_VERSION | sed -e
's/\([[0-9]]\)\.\([[0-9]]\)/\10\2/g'`
LLVM_COMPONENTS="engine bitwriter"
-if $LLVM_CONFIG --components | grep -q '\'; then
+if $LLVM_CONFIG --components | grep -qw 'mcjit'; then
LLVM_COMPONENTS="${LLVM_COMPONENTS} mcjit"
fi
if test "x$enable_opencl" = xyes; then
LLVM_COMPONENTS="${LLVM_COMPONENTS} ipo linker instrumentation"
# LLVM 3.3 >= 177971 requires IRReader
-if $LLVM_CONFIG --components | grep -q '\'; then
+if $LLVM_CONFIG --components | grep -qw 'irreader'; then
LLVM_COMPONENTS="${LLVM_COMPONENTS} irreader"
fi
fi
@@ -1709,7 +1709,7 @@ radeon_llvm_check() {
if test "$LLVM_VERSION_INT" -lt
"${LLVM_REQUIRED_VERSION_MAJOR}0${LLVM_REQUIRED_VERSION_MINOR}"; then
AC_MSG_ERROR([LLVM
$LLVM_REQUIRED_VERSION_MAJOR.$LLVM_REQUIRED_VERSION_MINOR or newer is required
for r600g and radeonsi.])
fi
-if test true && $LLVM_CONFIG --targets-built | grep -qv '\' ; then
+if test true && $LLVM_CONFIG --targets-built | grep -qvw 'R600' ; then
AC_MSG_ERROR([LLVM R600 Target not enabled. You can enable it when
building the LLVM
sources with the --enable-experimental-targets=R600
configure flag])
--
1.8.3.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] build: remove script compatibility symlinks
The symlinks for compatibility with old scripts assumes sysv shared library versioning and breaks other systems. For example OpenBSD uses sunos 4 style .so.major.minor versioning so the targets with ln will fail. Fixes bug 63269. Signed-off-by: Jonathan Gray --- src/egl/main/Makefile.am | 7 --- src/gallium/targets/dri-freedreno/Makefile.am | 6 -- src/gallium/targets/dri-i915/Makefile.am | 6 -- src/gallium/targets/dri-ilo/Makefile.am| 7 --- src/gallium/targets/dri-nouveau/Makefile.am| 6 -- src/gallium/targets/dri-r300/Makefile.am | 6 -- src/gallium/targets/dri-r600/Makefile.am | 6 -- src/gallium/targets/dri-radeonsi/Makefile.am | 6 -- src/gallium/targets/dri-swrast/Makefile.am | 6 -- src/gallium/targets/dri-vmwgfx/Makefile.am | 6 -- src/gallium/targets/egl-static/Makefile.am | 20 src/gallium/targets/libgl-xlib/Makefile.am | 6 -- src/gallium/targets/opencl/Makefile.am | 6 -- src/gallium/targets/osmesa/Makefile.am | 11 --- src/gallium/targets/vdpau-nouveau/Makefile.am | 6 -- src/gallium/targets/vdpau-r300/Makefile.am | 6 -- src/gallium/targets/vdpau-r600/Makefile.am | 6 -- src/gallium/targets/vdpau-radeonsi/Makefile.am | 6 -- src/gallium/targets/vdpau-softpipe/Makefile.am | 6 -- src/gallium/targets/xa-vmwgfx/Makefile.am | 6 -- src/gallium/targets/xorg-i915/Makefile.am | 6 -- src/gallium/targets/xorg-nouveau/Makefile.am | 6 -- src/gallium/targets/xorg-r600/Makefile.am | 6 -- src/gallium/targets/xorg-radeonsi/Makefile.am | 6 -- src/gallium/targets/xvmc-nouveau/Makefile.am | 6 -- src/gallium/targets/xvmc-r300/Makefile.am | 6 -- src/gallium/targets/xvmc-r600/Makefile.am | 6 -- src/gallium/targets/xvmc-softpipe/Makefile.am | 6 -- src/gbm/Makefile.am| 4 src/glx/Makefile.am| 7 --- src/mapi/es1api/Makefile.am| 8 src/mapi/es2api/Makefile.am| 8 src/mapi/shared-glapi/Makefile.am | 6 -- src/mapi/vgapi/Makefile.am | 8 src/mesa/drivers/dri/i915/Makefile.am | 6 -- src/mesa/drivers/dri/i965/Makefile.am | 6 -- src/mesa/drivers/dri/nouveau/Makefile.am | 6 -- src/mesa/drivers/dri/r200/Makefile.am | 6 -- src/mesa/drivers/dri/radeon/Makefile.am| 6 -- src/mesa/drivers/dri/swrast/Makefile.am| 6 -- src/mesa/drivers/osmesa/Makefile.am| 9 - src/mesa/drivers/x11/Makefile.am | 9 - src/mesa/libdricore/Makefile.am| 7 --- 43 files changed, 291 deletions(-) diff --git src/egl/main/Makefile.am src/egl/main/Makefile.am index ca5257a..61192d6 100644 --- src/egl/main/Makefile.am +++ src/egl/main/Makefile.am @@ -116,13 +116,6 @@ libEGL_la_LIBADD += ../drivers/dri2/libegl_dri2.la libEGL_la_LIBADD += $(LIBUDEV_LIBS) $(DLOPEN_LIBS) $(LIBDRM_LIBS) endif -# Provide compatibility with scripts for the old Mesa build system for -# a while by putting a link to the driver into /lib of the build tree. -all-local: libEGL.la - $(MKDIR_P) $(top_builddir)/$(LIB_DIR); - ln -f .libs/libEGL.so.1.0.0 $(top_builddir)/$(LIB_DIR)/libEGL.so.1 - ln -sf libEGL.so.1 $(top_builddir)/$(LIB_DIR)/libEGL.so - pkgconfigdir = $(libdir)/pkgconfig pkgconfig_DATA = egl.pc diff --git src/gallium/targets/dri-freedreno/Makefile.am src/gallium/targets/dri-freedreno/Makefile.am index cfa1f37..b39723e 100644 --- src/gallium/targets/dri-freedreno/Makefile.am +++ src/gallium/targets/dri-freedreno/Makefile.am @@ -65,9 +65,3 @@ if HAVE_MESA_LLVM kgsl_dri_la_LDFLAGS += $(LLVM_LDFLAGS) kgsl_dri_la_LIBADD += $(LLVM_LIBS) endif - -# Provide compatibility with scripts for the old Mesa build system for -# a while by putting a link to the driver into /lib of the build tree. -all-local: kgsl_dri.la - $(MKDIR_P) $(top_builddir)/$(LIB_DIR)/gallium - ln -f .libs/kgsl_dri.so $(top_builddir)/$(LIB_DIR)/gallium/kgsl_dri.so diff --git src/gallium/targets/dri-i915/Makefile.am src/gallium/targets/dri-i915/Makefile.am index ce6be78..818d340 100644 --- src/gallium/targets/dri-i915/Makefile.am +++ src/gallium/targets/dri-i915/Makefile.am @@ -68,9 +68,3 @@ if HAVE_MESA_LLVM AM_CPPFLAGS += -DGALLIUM_LLVMPIPE i915_dri_la_LIBADD += $(top_builddir)/src/gallium/drivers/llvmpipe/libllvmpipe.la $(LLVM_LIBS) endif - -# Provide compatibility with scripts for the old Mesa build system for -# a while by putting a link to the driver into /lib of the build tree. -all-local: i915_dri.la - $(MKDIR_P) $(top_builddir)/$(LIB_DIR)/gallium - ln -f .libs/i915_dri.so $(top_builddir)/$(LIB_DIR)/gallium/i915_dri.so diff --git src
Re: [Mesa-dev] [PATCH] build: remove script compatibility symlinks
On Thu, Jun 20, 2013 at 04:00:04PM -0600, Brian Paul wrote: > On 06/20/2013 03:32 PM, Dave Airlie wrote: > >On Fri, Jun 21, 2013 at 2:28 AM, Jonathan Gray wrote: > >>The symlinks for compatibility with old scripts assumes > >>sysv shared library versioning and breaks other systems. > >> > >>For example OpenBSD uses sunos 4 style .so.major.minor > >>versioning so the targets with ln will fail. > >> > >>Fixes bug 63269. > >> > > > >totally nak. > > Yeah, I don't want to loose this feature either. > > > >My fix you mean avoids? > > > >A lot of developers use this feature, I do wonder if maybe we can move > >it behind a configure switch though as I think it also causes some > >rpaths to be emitted that I think distro packages would like to avoid. > > We could certainly be smarter about whether to make the links or how > they're made. I'd rather pursue that. Perhaps it is enough to glob the ln calls so the .patch part is never explicitly referenced. The additional symlinks to the library won't always make sense on non linux systems but at least mesa would actually build again then. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] build: remove script compatibility symlinks
On Thu, Jun 20, 2013 at 08:32:03PM -0700, Kenneth Graunke wrote: > On 06/20/2013 06:45 PM, Jonathan Gray wrote: > >On Thu, Jun 20, 2013 at 04:00:04PM -0600, Brian Paul wrote: > >>On 06/20/2013 03:32 PM, Dave Airlie wrote: > >>>On Fri, Jun 21, 2013 at 2:28 AM, Jonathan Gray wrote: > >>>>The symlinks for compatibility with old scripts assumes > >>>>sysv shared library versioning and breaks other systems. > >>>> > >>>>For example OpenBSD uses sunos 4 style .so.major.minor > >>>>versioning so the targets with ln will fail. > >>>> > >>>>Fixes bug 63269. > >>>> > >>> > >>>totally nak. > >> > >>Yeah, I don't want to loose this feature either. > >> > >> > >>>My fix you mean avoids? > >>> > >>>A lot of developers use this feature, I do wonder if maybe we can move > >>>it behind a configure switch though as I think it also causes some > >>>rpaths to be emitted that I think distro packages would like to avoid. > >> > >>We could certainly be smarter about whether to make the links or how > >>they're made. I'd rather pursue that. > > > >Perhaps it is enough to glob the ln calls so the .patch part > >is never explicitly referenced. The additional symlinks to > >the library won't always make sense on non linux systems but > >at least mesa would actually build again then. > > We could almost do: > > for lib in .libs/foo.so*; do ln -f $lib > $(top_builddir)/$(LIB_DIR)/`basename $lib`; done > > This would create hardlinks for every library that actually got > built. Unfortunately, I think it means that the symlinks will point > to the original .libs/foo.so.1.0.0 file, which means that you can't > just copy 'lib' around anymore. Hm. > > Alternatively, what about simply having 'make' run 'make > DESTDIR=$(top_builddir)/$(LIB_DIR) install' or the like? I guess > that would put libraries in mesa/lib// and DRI > drivers in mesa/lib///dri, which is a little > annoying. And does rpath nonsense... The following is enough to avoid the specific problem on OpenBSD. There doesn't appear to be any easy way to get the name of the shared library from automake/libtool. diff --git src/egl/main/Makefile.am src/egl/main/Makefile.am index ca5257a..ebe15f6 100644 --- src/egl/main/Makefile.am +++ src/egl/main/Makefile.am @@ -120,7 +120,7 @@ endif # a while by putting a link to the driver into /lib of the build tree. all-local: libEGL.la $(MKDIR_P) $(top_builddir)/$(LIB_DIR); - ln -f .libs/libEGL.so.1.0.0 $(top_builddir)/$(LIB_DIR)/libEGL.so.1 + ln -f .libs/libEGL.so.1.0* $(top_builddir)/$(LIB_DIR)/libEGL.so.1 ln -sf libEGL.so.1 $(top_builddir)/$(LIB_DIR)/libEGL.so pkgconfigdir = $(libdir)/pkgconfig diff --git src/gbm/Makefile.am src/gbm/Makefile.am index e22c55c..cc4ba61 100644 --- src/gbm/Makefile.am +++ src/gbm/Makefile.am @@ -43,4 +43,4 @@ endif all-local: libgbm.la $(MKDIR_P) $(top_builddir)/$(LIB_DIR); - ln -f .libs/libgbm.so.1.0.0 $(top_builddir)/$(LIB_DIR)/libgbm.so + ln -f .libs/libgbm.so.1.0* $(top_builddir)/$(LIB_DIR)/libgbm.so diff --git src/glx/Makefile.am src/glx/Makefile.am index f01709b..faecfd6 100644 --- src/glx/Makefile.am +++ src/glx/Makefile.am @@ -112,5 +112,5 @@ lib@GL_LIB@_la_LDFLAGS = $(GL_LDFLAGS) # a while by putting a link to the driver into /lib of the build tree. all-local: lib@GL_LIB@.la $(MKDIR_P) $(top_builddir)/$(LIB_DIR); - ln -f .libs/lib@GL_LIB@.so.1.2.0 $(top_builddir)/$(LIB_DIR)/lib@GL_LIB@.so.1 + ln -f .libs/lib@GL_LIB@.so.1.2* $(top_builddir)/$(LIB_DIR)/lib@GL_LIB@.so.1 ln -sf lib@GL_LIB@.so.1 $(top_builddir)/$(LIB_DIR)/lib@GL_LIB@.so diff --git src/mapi/es1api/Makefile.am src/mapi/es1api/Makefile.am index eb98f16..f7bcce2 100644 --- src/mapi/es1api/Makefile.am +++ src/mapi/es1api/Makefile.am @@ -61,6 +61,4 @@ CLEANFILES = $(BUILT_SOURCES) # a while by putting a link to the driver into /lib of the build tree. all-local: libGLESv1_CM.la $(MKDIR_P) $(top_builddir)/$(LIB_DIR); - ln -f .libs/libGLESv1_CM.so $(top_builddir)/$(LIB_DIR)/libGLESv1_CM.so - ln -f .libs/libGLESv1_CM.so.1 $(top_builddir)/$(LIB_DIR)/libGLESv1_CM.so.1 - ln -f .libs/libGLESv1_CM.so.1.1.0 $(top_builddir)/$(LIB_DIR)/libGLESv1_CM.so.1.1.0 + ln -f .libs/libGLESv1_CM.so* $(top_builddir)/$(LIB_DIR)/ diff --git src/mapi/es2api/Makefile.am src/mapi/es2api/Makefile.am index c6b0ca4..9e0419a 100644 --- src/mapi/es2api/Makefile.am +++ src/mapi/es2api/Makefile.am @@ -65,6 +65,4 @@ CLEANFILES = $(BUILT_SOURCES) # a while by putting a link to the driver into /lib of the build tree.
[Mesa-dev] [PATCH] st/xvmc/tests: avoid non portable error.h functions
Signed-off-by: Jonathan Gray
---
src/gallium/state_trackers/xvmc/tests/xvmc_bench.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git src/gallium/state_trackers/xvmc/tests/xvmc_bench.c
src/gallium/state_trackers/xvmc/tests/xvmc_bench.c
index fe85802..37360a6 100644
--- src/gallium/state_trackers/xvmc/tests/xvmc_bench.c
+++ src/gallium/state_trackers/xvmc/tests/xvmc_bench.c
@@ -28,7 +28,7 @@
#include
#include
#include
-#include
+#include
#include
#include "testlib.h"
@@ -144,9 +144,9 @@ void ParseArgs(int argc, char **argv, struct Config *config)
}
if (fail)
- error
- (
- 1, 0,
+ {
+ fprintf(
+ stderr,
"Bad argument.\n"
"\n"
"Usage: %s [options]\n"
@@ -161,6 +161,8 @@ void ParseArgs(int argc, char **argv, struct Config *config)
"\tMB types: i,p,b\n",
argv[0]
);
+ exit(1);
+ }
if (config->output_width == 0)
config->output_width = config->input_width;
@@ -214,7 +216,8 @@ int main(int argc, char **argv)
))
{
XCloseDisplay(display);
- error(1, 0, "Error, unable to find a good port.\n");
+ fprintf(stderr, "Error, unable to find a good port.\n");
+ exit(1);
}
if (is_overlay)
--
1.8.3.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] r300g: add program name check for BSD
program_invocation_short_name is glibc specific. Provide an
alternative using getprogname(), which can be found on *BSD and OS X.
Signed-off-by: Jonathan Gray
---
src/gallium/drivers/r300/r300_chipset.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git src/gallium/drivers/r300/r300_chipset.c
src/gallium/drivers/r300/r300_chipset.c
index 11061ed..7f51ccb 100644
--- src/gallium/drivers/r300/r300_chipset.c
+++ src/gallium/drivers/r300/r300_chipset.c
@@ -30,6 +30,14 @@
#include
#include
+#undef GET_PROGRAM_NAME
+#ifdef __GLIBC__
+# define GET_PROGRAM_NAME() program_invocation_short_name
+#else /* *BSD and OS X */
+# include
+# define GET_PROGRAM_NAME() getprogname()
+#endif
+
/* r300_chipset: A file all to itself for deducing the various properties of
* Radeons. */
@@ -49,7 +57,7 @@ static void r300_apply_hyperz_blacklist(struct
r300_capabilities* caps)
int i;
for (i = 0; i < Elements(list); i++) {
-if (strcmp(list[i], program_invocation_short_name) == 0) {
+if (strcmp(list[i], GET_PROGRAM_NAME()) == 0) {
caps->zmask_ram = 0;
caps->hiz_ram = 0;
break;
--
1.8.3.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] configure.ac: add OpenBSD
Signed-off-by: Jonathan Gray --- configure.ac | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git configure.ac configure.ac index 6832b0d..6a817d0 100644 --- configure.ac +++ configure.ac @@ -449,7 +449,7 @@ if test "x$enable_asm" = xyes; then case "$host_cpu" in i?86) case "$host_os" in -linux* | *freebsd* | dragonfly* | *netbsd*) +linux* | *freebsd* | dragonfly* | *netbsd* | openbsd*) test "x$enable_64bit" = xyes && asm_arch=x86_64 || asm_arch=x86 ;; gnu*) @@ -459,7 +459,7 @@ if test "x$enable_asm" = xyes; then ;; x86_64) case "$host_os" in -linux* | *freebsd* | dragonfly* | *netbsd*) +linux* | *freebsd* | dragonfly* | *netbsd* | openbsd*) test "x$enable_32bit" = xyes && asm_arch=x86 || asm_arch=x86_64 ;; esac @@ -985,7 +985,7 @@ if test "x$enable_dri" = xyes; then ;; esac ;; -freebsd* | dragonfly* | *netbsd*) +freebsd* | dragonfly* | *netbsd* | openbsd*) DEFINES="$DEFINES -DHAVE_PTHREAD -DUSE_EXTERNAL_DXTN_LIB=1" DEFINES="$DEFINES -DHAVE_ALIAS" -- 1.8.3.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] r300g: add program name check for BSD
On Wed, Jun 26, 2013 at 07:21:59AM -0500, Patrick Baggett wrote: > On Wed, Jun 26, 2013 at 2:11 AM, Jonathan Gray wrote: > > > program_invocation_short_name is glibc specific. Provide an > > alternative using getprogname(), which can be found on *BSD and OS X. > > > > Signed-off-by: Jonathan Gray > > --- > > src/gallium/drivers/r300/r300_chipset.c | 10 +- > > 1 file changed, 9 insertions(+), 1 deletion(-) > > > > diff --git src/gallium/drivers/r300/r300_chipset.c > > src/gallium/drivers/r300/r300_chipset.c > > index 11061ed..7f51ccb 100644 > > --- src/gallium/drivers/r300/r300_chipset.c > > +++ src/gallium/drivers/r300/r300_chipset.c > > @@ -30,6 +30,14 @@ > > #include > > #include > > > > +#undef GET_PROGRAM_NAME > > +#ifdef __GLIBC__ > > +# define GET_PROGRAM_NAME() program_invocation_short_name > > > > I think you are missing parentheses on the end of > program_invocation_short_name It is a variable not a function, see http://www.gnu.org/software/libc/manual/html_node/Error-Messages.html ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Fix symlinking of libraries in /lib on non-Linux systems
On Wed, Jun 26, 2013 at 02:39:40PM +0200, Jean-Sébastien Pédron wrote: > On 26.06.2013 14:37, Jean-Sébastien Pédron wrote: > > Makefiles were explicitly looking for a libraries suffixed with the full > > libtool versioning, such as "libglapi.so.0.0.0". However, on some > > systems (at least FreeBSD and OpenBSD), libtool only uses a shorter > > name, such as "libglapi.so.0". > > Always better with the patch attached... > > -- > Jean-Sébastien Pédron > From 72a4a551010634956daf6c9df528b4ec1aa26445 Mon Sep 17 00:00:00 2001 > From: =?UTF-8?q?Jean-S=C3=A9bastien=20P=C3=A9dron?= > Date: Wed, 5 Jun 2013 13:30:06 +0200 > Subject: [PATCH 2/9] Fix symlinking of libraries in /lib on non-Linux systems > > Makefiles were explicitly looking for a libraries suffixed with the full > libtool versioning, such as "libglapi.so.0.0.0". However, on some > systems, libtool only uses a shorter name, such as "libglapi.so.0". > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=63269 This misses a few places see http://marc.info/?l=mesa3d-dev&m=137179411405480&w=2 namely src/gbm/Makefile.am src/mapi/es1api/Makefile.am src/mapi/es2api/Makefile.am src/mapi/vgapi/Makefile.am In your above example "libglapi.so.0" would not exist on OpenBSD only "libglapi.so.0.0" ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Use and bswap32(x) on FreeBSD
On Wed, Jun 26, 2013 at 03:05:47PM +0200, Jean-Sébastien Pédron wrote: > Hello, > > This is the equivalent to and bswap_32(x) on Linux. this is already fixed in a cleaner way, see ebd68dd02998a8595cb10844c37a6b02dc3078a8 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] configure.ac: On some systems, "x86-64" is called "amd64"
On Wed, Jun 26, 2013 at 02:54:34PM +0200, Jean-Sébastien Pédron wrote: > Hello, > > On FreeBSD, the x86-64 arch is named "amd64". This patch fixes its > detection in the configure script. Shouldn't config.guess/config.sub remap it? from config.log here: uname -m = amd64 uname -r = 5.3 uname -s = OpenBSD uname -v = GENERIC.MP#5 host='x86_64-unknown-openbsd5.3' host_alias='' host_cpu='x86_64' host_os='openbsd5.3' host_vendor='unknown' ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] r300g: add program name check for BSD
On Wed, Jun 26, 2013 at 09:49:08AM -0600, Brian Paul wrote:
> On 06/26/2013 01:11 AM, Jonathan Gray wrote:
> >program_invocation_short_name is glibc specific. Provide an
> >alternative using getprogname(), which can be found on *BSD and OS X.
> >
> >Signed-off-by: Jonathan Gray
> >---
> > src/gallium/drivers/r300/r300_chipset.c | 10 +-
> > 1 file changed, 9 insertions(+), 1 deletion(-)
> >
> >diff --git src/gallium/drivers/r300/r300_chipset.c
> >src/gallium/drivers/r300/r300_chipset.c
> >index 11061ed..7f51ccb 100644
> >--- src/gallium/drivers/r300/r300_chipset.c
> >+++ src/gallium/drivers/r300/r300_chipset.c
> >@@ -30,6 +30,14 @@
> > #include
> > #include
> >
> >+#undef GET_PROGRAM_NAME
> >+#ifdef __GLIBC__
> >+# define GET_PROGRAM_NAME() program_invocation_short_name
> >+#else /* *BSD and OS X */
> >+# include
> >+# define GET_PROGRAM_NAME() getprogname()
> >+#endif
> >+
> > /* r300_chipset: A file all to itself for deducing the various properties
> > of
> > * Radeons. */
> >
> >@@ -49,7 +57,7 @@ static void r300_apply_hyperz_blacklist(struct
> >r300_capabilities* caps)
> > int i;
> >
> > for (i = 0; i < Elements(list); i++) {
> >-if (strcmp(list[i], program_invocation_short_name) == 0) {
> >+if (strcmp(list[i], GET_PROGRAM_NAME()) == 0) {
> > caps->zmask_ram = 0;
> > caps->hiz_ram = 0;
> > break;
> >
>
> I think a new gallium utility function for this would be helpful.
> In fact I've already implemented something like this for our windows
> driver.
>
> Does the attached code look OK you to guys?
looks good to me, a few nitpicks inline
>
> -Brian
>
>
> #include "pipe/p_config.h"
> #include "os/os_process.h"
> #include "util/u_memory.h"
>
> #if defined(PIPE_SUBSYSTEM_WINDOWS_USER)
> # include
> #endif
it isn't clear if stdlib.h is included here?
>
>
> /**
> * Return the name of the current process.
> * \param procname returns the process name, always 0-terminated
> * \param size size of the procname buffer
> * \return TRUE or FALSE for success, failure
> */
> boolean
> os_get_process_name(char *procname, size_t size)
> {
>const char *name;
> #if defined(PIPE_SUBSYSTEM_WINDOWS_USER)
>char szProcessPath[MAX_PATH];
>char *lpProcessName;
>char *lpProcessExt;
>
>GetModuleFileNameA(NULL, szProcessPath, Elements(szProcessPath));
>
>lpProcessName = strrchr(szProcessPath, '\\');
>lpProcessName = lpProcessName ? lpProcessName + 1 : szProcessPath;
>
>lpProcessExt = strrchr(lpProcessName, '.');
>if (lpProcessExt) {
> *lpProcessExt = '\0';
>}
>
>name = lpProcessName;
>
> #elif defined(__GLIBC__)
>name = program_invocation_short_name;
> #else /* *BSD and OS X */
>name = getprogname();
> #endif
>
>assert(procname);
>assert(size > 0);
>
>if (name) {
> strncpy(procname, name, size);
> procname[size - 1] = 0;
and this should be '\0' not 0, though the end result is the same
> return TRUE;
>}
>else {
> return FALSE;
>}
> }
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/xvmc/tests: avoid non portable error.h functions
On Wed, Jun 26, 2013 at 09:13:13AM +0200, Christian König wrote:
> Am 26.06.2013 09:10, schrieb Jonathan Gray:
> >Signed-off-by: Jonathan Gray
>
> Looks good on first glance, patch is:
>
> Reviewed-by: Christian König
Can you push it to the repo then?
>
> >---
> > src/gallium/state_trackers/xvmc/tests/xvmc_bench.c | 13 -
> > 1 file changed, 8 insertions(+), 5 deletions(-)
> >
> >diff --git src/gallium/state_trackers/xvmc/tests/xvmc_bench.c
> >src/gallium/state_trackers/xvmc/tests/xvmc_bench.c
> >index fe85802..37360a6 100644
> >--- src/gallium/state_trackers/xvmc/tests/xvmc_bench.c
> >+++ src/gallium/state_trackers/xvmc/tests/xvmc_bench.c
> >@@ -28,7 +28,7 @@
> > #include
> > #include
> > #include
> >-#include
> >+#include
> > #include
> > #include "testlib.h"
> >@@ -144,9 +144,9 @@ void ParseArgs(int argc, char **argv, struct Config
> >*config)
> > }
> > if (fail)
> >-error
> >-(
> >-1, 0,
> >+{
> >+fprintf(
> >+stderr,
> > "Bad argument.\n"
> > "\n"
> > "Usage: %s [options]\n"
> >@@ -161,6 +161,8 @@ void ParseArgs(int argc, char **argv, struct Config
> >*config)
> > "\tMB types: i,p,b\n",
> > argv[0]
> > );
> >+exit(1);
> >+}
> > if (config->output_width == 0)
> > config->output_width = config->input_width;
> >@@ -214,7 +216,8 @@ int main(int argc, char **argv)
> > ))
> > {
> > XCloseDisplay(display);
> >-error(1, 0, "Error, unable to find a good port.\n");
> >+fprintf(stderr, "Error, unable to find a good port.\n");
> >+exit(1);
> > }
> > if (is_overlay)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] configure.ac: make grep tests more portable
anyone get a chance to look at this?
On Thu, Jun 20, 2013 at 08:14:33PM +1000, Jonathan Gray wrote:
> Use grep -w instead of the empty string escape sequences
> which are less portable. Makes the grep tests
> function as intended on OpenBSD.
>
> Signed-off-by: Jonathan Gray
> ---
> configure.ac | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git configure.ac configure.ac
> index 6832b0d..45d9b1c 100644
> --- configure.ac
> +++ configure.ac
> @@ -1580,14 +1580,14 @@ if test "x$enable_gallium_llvm" = xyes; then
> LLVM_VERSION=`$LLVM_CONFIG --version | sed 's/svn.*//g'`
> LLVM_VERSION_INT=`echo $LLVM_VERSION | sed -e
> 's/\([[0-9]]\)\.\([[0-9]]\)/\10\2/g'`
> LLVM_COMPONENTS="engine bitwriter"
> -if $LLVM_CONFIG --components | grep -q '\'; then
> +if $LLVM_CONFIG --components | grep -qw 'mcjit'; then
> LLVM_COMPONENTS="${LLVM_COMPONENTS} mcjit"
> fi
>
> if test "x$enable_opencl" = xyes; then
> LLVM_COMPONENTS="${LLVM_COMPONENTS} ipo linker instrumentation"
> # LLVM 3.3 >= 177971 requires IRReader
> -if $LLVM_CONFIG --components | grep -q '\'; then
> +if $LLVM_CONFIG --components | grep -qw 'irreader'; then
> LLVM_COMPONENTS="${LLVM_COMPONENTS} irreader"
> fi
> fi
> @@ -1709,7 +1709,7 @@ radeon_llvm_check() {
> if test "$LLVM_VERSION_INT" -lt
> "${LLVM_REQUIRED_VERSION_MAJOR}0${LLVM_REQUIRED_VERSION_MINOR}"; then
> AC_MSG_ERROR([LLVM
> $LLVM_REQUIRED_VERSION_MAJOR.$LLVM_REQUIRED_VERSION_MINOR or newer is
> required for r600g and radeonsi.])
> fi
> -if test true && $LLVM_CONFIG --targets-built | grep -qv '\' ; then
> +if test true && $LLVM_CONFIG --targets-built | grep -qvw 'R600' ; then
> AC_MSG_ERROR([LLVM R600 Target not enabled. You can enable it when
> building the LLVM
>sources with the --enable-experimental-targets=R600
>configure flag])
> --
> 1.8.3.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium: add endian detection for OpenBSD
Still looking to have this merged... On Thu, Aug 15, 2013 at 12:17:27AM +1000, Jonathan Gray wrote: > Signed-off-by: Jonathan Gray > --- > src/gallium/include/pipe/p_config.h | 10 ++ > 1 file changed, 10 insertions(+) > > diff --git src/gallium/include/pipe/p_config.h > src/gallium/include/pipe/p_config.h > index 1588a92..9af5df7 100644 > --- src/gallium/include/pipe/p_config.h > +++ src/gallium/include/pipe/p_config.h > @@ -153,6 +153,16 @@ > # define PIPE_ARCH_BIG_ENDIAN > #endif > > +#elif defined(__OpenBSD__) > +#include > +#include > + > +#if _BYTE_ORDER == _LITTLE_ENDIAN > +# define PIPE_ARCH_LITTLE_ENDIAN > +#elif _BYTE_ORDER == _BIG_ENDIAN > +# define PIPE_ARCH_BIG_ENDIAN > +#endif > + > #else > > #if defined(PIPE_ARCH_X86) || defined(PIPE_ARCH_X86_64) || > defined(PIPE_ARCH_ARM) || defined(PIPE_ARCH_AARCH64) > -- > 1.8.3.3 > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] glsl: Link glsl_compiler with pthreads library.
Fixes the following build error on OpenBSD: ./.libs/libglsl.a(builtin_functions.o)(.text+0x973): In function `mtx_lock': ../../include/c11/threads_posix.h:195: undefined reference to `pthread_mutex_lock' ./.libs/libglsl.a(builtin_functions.o)(.text+0x9a5): In function `mtx_unlock': ../../include/c11/threads_posix.h:248: undefined reference to `pthread_mutex_unlock' Signed-off-by: Jonathan Gray --- src/glsl/Makefile.am | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git src/glsl/Makefile.am src/glsl/Makefile.am index 8516459..534eaa3 100644 --- src/glsl/Makefile.am +++ src/glsl/Makefile.am @@ -128,7 +128,9 @@ glsl_compiler_SOURCES = \ $(top_srcdir)/src/mesa/program/symbol_table.c \ $(GLSL_COMPILER_CXX_FILES) -glsl_compiler_LDADD = libglsl.la +glsl_compiler_LDADD = \ + libglsl.la \ + $(PTHREAD_LIBS) glsl_test_SOURCES = \ $(top_srcdir)/src/mesa/main/hash_table.c \ -- 1.8.5.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium: add endian detection for OpenBSD
On Mon, Mar 10, 2014 at 08:27:17AM -0600, Brian Paul wrote: > On 03/10/2014 06:20 AM, Jonathan Gray wrote: > >Still looking to have this merged... > > > >On Thu, Aug 15, 2013 at 12:17:27AM +1000, Jonathan Gray wrote: > >>Signed-off-by: Jonathan Gray > >>--- > >> src/gallium/include/pipe/p_config.h | 10 ++ > >> 1 file changed, 10 insertions(+) > >> > >>diff --git src/gallium/include/pipe/p_config.h > >>src/gallium/include/pipe/p_config.h > >>index 1588a92..9af5df7 100644 > >>--- src/gallium/include/pipe/p_config.h > >>+++ src/gallium/include/pipe/p_config.h > >>@@ -153,6 +153,16 @@ > >> # define PIPE_ARCH_BIG_ENDIAN > >> #endif > >> > >>+#elif defined(__OpenBSD__) > >>+#include > >>+#include > >>+ > >>+#if _BYTE_ORDER == _LITTLE_ENDIAN > >>+# define PIPE_ARCH_LITTLE_ENDIAN > >>+#elif _BYTE_ORDER == _BIG_ENDIAN > >>+# define PIPE_ARCH_BIG_ENDIAN > >>+#endif > >>+ > >> #else > >> > >> #if defined(PIPE_ARCH_X86) || defined(PIPE_ARCH_X86_64) || > >> defined(PIPE_ARCH_ARM) || defined(PIPE_ARCH_AARCH64) > >>-- > > Reviewed-by: Brian Paul > > Do you need someone to push this to master for you? Yes, that'd be great. thanks ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] ax_prog_flex.m4: change grep syntax to accept e.g. flex.real
On Thu, Jul 18, 2013 at 01:59:37PM -0700, Matt Turner wrote: > On Mon, Apr 15, 2013 at 1:46 PM, Andreas Oberritter wrote: > > This is required in case a wrapper or symlink is used. This patch > > has also been sent upstream, awaiting moderation. > > > > Signed-off-by: Andreas Oberritter > > --- > > Thanks, committed (finally). Trying to catch up with recent versions of mesa and noticed that this introduced the use of the gnu specific empty string escape sequences that were removed from configure.ac for the llvm-config tests in favour of using -w. How about something like the following which makes the test work as intended on OpenBSD? diff --git m4/ax_prog_flex.m4 m4/ax_prog_flex.m4 index 82fbc30..f83f42c 100644 --- m4/ax_prog_flex.m4 +++ m4/ax_prog_flex.m4 @@ -53,7 +53,7 @@ AC_DEFUN([AX_PROG_FLEX], [ AC_REQUIRE([AC_PROG_EGREP]) AC_CACHE_CHECK([if flex is the lexer generator],[ax_cv_prog_flex],[ -AS_IF([$LEX --version 2>/dev/null | $EGREP -q '^\'], +AS_IF([$LEX --version 2>/dev/null | $EGREP -qw '^flex'], [ax_cv_prog_flex=yes], [ax_cv_prog_flex=no]) ]) AS_IF([test "$ax_cv_prog_flex" = "yes"], ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/4] loader: use 0 instead of FALSE which isn't defined
Signed-off-by: Jonathan Gray
---
src/loader/loader.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git src/loader/loader.c src/loader/loader.c
index 811f8a2..caeeebf 100644
--- src/loader/loader.c
+++ src/loader/loader.c
@@ -219,12 +219,12 @@ loader_get_pci_id_for_fd(int fd, int *vendor_id, int
*chip_id)
version = drmGetVersion(fd);
if (!version) {
log_(_LOADER_WARNING, "MESA-LOADER: invalid drm fd\n");
- return FALSE;
+ return 0;
}
if (!version->name) {
log_(_LOADER_WARNING, "MESA-LOADER: unable to determine the driver
name\n");
drmFreeVersion(version);
- return FALSE;
+ return 0;
}
if (strcmp(version->name, "i915") == 0) {
--
1.8.5.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
