[Mesa-dev] [PATCH] radeon/winsys: correct RADEON_GEM_WAIT_IDLE use

2013-06-04 Thread Jonathan Gray 
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 j...@jsg.id.au
---
 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

2013-06-06 Thread Jonathan Gray 
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 j...@jsg.id.au
 
 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 kette...@openbsd.org
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 kette...@openbsd.org
Signed-off-by: Jonathan Gray j...@jsg.id.au
---
 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

2013-06-16 Thread Jonathan Gray 
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 j...@jsg.id.au
---
 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 errno.h
-#include byteswap.h
 #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 stdio.h
 #include errno.h
-#include byteswap.h
 
 /* 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 byteswap.h
 
 #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 mostawesomed...@gmail.com
  */
 
-#include byteswap.h
-
 #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

2013-06-17 Thread Jonathan Gray 
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 j...@jsg.id.au
 
 Reviewed-by: Michel Dänzer michel.daen...@amd.com
 
 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

2013-06-20 Thread Jonathan Gray 
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 j...@jsg.id.au
---
 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 '\mcjit\'; 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 '\irreader\'; 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 '\R600\' ; 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

2013-06-20 Thread Jonathan Gray 
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 j...@jsg.id.au
---
 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

Re: [Mesa-dev] [PATCH] build: remove script compatibility symlinks

2013-06-20 Thread Jonathan Gray 
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 j...@jsg.id.au 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

2013-06-20 Thread Jonathan Gray 
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 j...@jsg.id.au 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/prefix/libdir and DRI
 drivers in mesa/lib/prefix/libdir/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.
 all-local: libGLESv2.la
$(MKDIR_P) $(top_builddir)/$(LIB_DIR);
-   ln -f .libs/libGLESv2.so $(top_builddir)/$(LIB_DIR)/libGLESv2.so
-   ln -f .libs/libGLESv2.so.2 $(top_builddir)/$(LIB_DIR)/libGLESv2.so.2
-   ln -f .libs/libGLESv2.so.2.0.0 
$(top_builddir)/$(LIB_DIR)/libGLESv2.so.2.0.0
+   ln -f .libs/libGLESv2.so* $(top_builddir)/$(LIB_DIR)/
diff --git src/mapi/shared-glapi/Makefile.am src/mapi/shared-glapi/Makefile.am
index 2021a73..88c0959 100644
--- src/mapi/shared-glapi/Makefile.am
+++ src/mapi

[Mesa-dev] [PATCH] st/xvmc/tests: avoid non portable error.h functions

2013-06-26 Thread Jonathan Gray 
Signed-off-by: Jonathan Gray j...@jsg.id.au
---
 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 assert.h
 #include stdio.h
 #include string.h
-#include error.h
+#include stdlib.h
 #include sys/time.h
 #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

Re: [Mesa-dev] [PATCH] Fix symlinking of libraries in /lib on non-Linux systems

2013-06-26 Thread Jonathan Gray 
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?= dumbb...@freebsd.org
 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-devm=137179411405480w=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 sys/endian.h and bswap32(x) on FreeBSD

2013-06-26 Thread Jonathan Gray 
On Wed, Jun 26, 2013 at 03:05:47PM +0200, Jean-Sébastien Pédron wrote:
 Hello,
 
 This is the equivalent to byteswap.h 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

2013-06-26 Thread Jonathan Gray 
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

2013-06-27 Thread Jonathan Gray 
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 j...@jsg.id.au
 ---
   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 stdio.h
   #include errno.h
 
 +#undef GET_PROGRAM_NAME
 +#ifdef __GLIBC__
 +#   define GET_PROGRAM_NAME() program_invocation_short_name
 +#else /* *BSD and OS X */
 +#   include stdlib.h
 +#   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 windows.h
 #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] configure.ac: add OpenBSD

2013-07-17 Thread Jonathan Gray 
On Wed, Jul 17, 2013 at 09:26:34PM -0700, Vinson Lee wrote:
 On Wed, Jun 26, 2013 at 12:11 AM, Jonathan Gray j...@jsg.id.au wrote:
  Signed-off-by: Jonathan Gray j...@jsg.id.au
  ---
   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-devm=137172335614808w=2
http://marc.info/?l=mesa3d-devm=137225132130064w=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

2013-07-17 Thread Jonathan Gray 
Signed-off-by: Jonathan Gray j...@jsg.id.au
---
 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

2013-07-17 Thread Jonathan Gray 
Signed-off-by: Jonathan Gray j...@jsg.id.au
---
 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

2013-07-17 Thread Jonathan Gray 
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 j...@jsg.id.au
 ---
  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()

2013-07-18 Thread Jonathan Gray 
Lets the code compile on non Linux systems.

Signed-off-by: Jonathan Gray j...@jsg.id.au
---
 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 stdio.h
 #include errno.h
@@ -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

2013-07-18 Thread Jonathan Gray 
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 j...@jsg.id.au
  ---
   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] mesa: use c99 functions on non-linux platforms if supported

2013-08-01 Thread Jonathan Gray 
Signed-off-by: Jonathan Gray j...@jsg.id.au
---
 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

2013-08-01 Thread Jonathan Gray 
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 j...@jsg.id.au
 ---
   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

2013-08-05 Thread Jonathan Gray 
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 j...@jsg.id.au
 ---
   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

2013-08-06 Thread Jonathan Gray 
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 ross.bur...@intel.com
 ---
  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

2013-08-14 Thread Jonathan Gray 
Signed-off-by: Jonathan Gray j...@jsg.id.au
---
 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 sys/types.h
+#include machine/endian.h
+
+#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/

2013-08-18 Thread Jonathan Gray 
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 kenn...@whitecape.org
 ---
  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

Re: [Mesa-dev] [PATCH] gallium: add endian detection for OpenBSD

2014-03-10 Thread Jonathan Gray 
Still looking to have this merged...

On Thu, Aug 15, 2013 at 12:17:27AM +1000, Jonathan Gray wrote:
 Signed-off-by: Jonathan Gray j...@jsg.id.au
 ---
  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 sys/types.h
 +#include machine/endian.h
 +
 +#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.

2014-03-10 Thread Jonathan Gray 
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 j...@jsg.id.au
---
 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

[Mesa-dev] [PATCH 1/4] loader: use 0 instead of FALSE which isn't defined

2014-03-18 Thread Jonathan Gray 
Signed-off-by: Jonathan Gray j...@jsg.id.au
---
 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

[Mesa-dev] [PATCH 3/4] glx/dri2: handle dri authenticating before calling the loader.

2014-03-18 Thread Jonathan Gray 
The loader may issue dri ioctls to determine the driver name.

Signed-off-by: Jonathan Gray j...@jsg.id.au
---
 src/glx/dri2_glx.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git src/glx/dri2_glx.c src/glx/dri2_glx.c
index 5a960b0..b61422f 100644
--- src/glx/dri2_glx.c
+++ src/glx/dri2_glx.c
@@ -1200,6 +1200,16 @@ dri2CreateScreen(int screen, struct glx_display * priv)
   goto handle_error;
}
 
+   if (drmGetMagic(psc-fd, magic)) {
+  ErrorMessageF(failed to get magic\n);
+  goto handle_error;
+   }
+
+   if (!DRI2Authenticate(priv-dpy, RootWindow(priv-dpy, screen), magic)) {
+  ErrorMessageF(failed to authenticate magic %d\n, magic);
+  goto handle_error;
+   }
+
/* If Mesa knows about the appropriate driver for this fd, then trust it.
 * Otherwise, default to the server's value.
 */
@@ -1231,16 +1241,6 @@ dri2CreateScreen(int screen, struct glx_display * priv)
   goto handle_error;
}
 
-   if (drmGetMagic(psc-fd, magic)) {
-  ErrorMessageF(failed to get magic\n);
-  goto handle_error;
-   }
-
-   if (!DRI2Authenticate(priv-dpy, RootWindow(priv-dpy, screen), magic)) {
-  ErrorMessageF(failed to authenticate magic %d\n, magic);
-  goto handle_error;
-   }
-
if (psc-dri2-base.version = 4) {
   psc-driScreen =
  psc-dri2-createNewScreen2(screen, psc-fd,
-- 
1.8.5.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 4/4] megadriver_stub.c: don't use _GNU_SOURCE to gate the compat code

2014-03-18 Thread Jonathan Gray 
_GNU_SOURCE is only set/required for linux*|*-gnu*|gnu*) and as the
functionality is available on other systems check for RTLD_DEFAULT instead.

Signed-off-by: Jonathan Gray j...@jsg.id.au
---
 src/mesa/drivers/dri/common/megadriver_stub.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git src/mesa/drivers/dri/common/megadriver_stub.c 
src/mesa/drivers/dri/common/megadriver_stub.c
index a821770..7b6d134 100644
--- src/mesa/drivers/dri/common/megadriver_stub.c
+++ src/mesa/drivers/dri/common/megadriver_stub.c
@@ -31,7 +31,7 @@
  * Dl_info, and RTLD_DEFAULT are only defined when _GNU_SOURCE is
  * defined.)
  */
-#ifdef _GNU_SOURCE
+#ifdef RTLD_DEFAULT
 
 #define MEGADRIVER_STUB_MAX_EXTENSIONS 10
 #define LIB_PATH_SUFFIX _dri.so
@@ -148,7 +148,7 @@ megadriver_stub_init(void)
}
 }
 
-#endif /* _GNU_SOURCE */
+#endif /* RTLD_DEFAULT */
 
 static const
 __DRIconfig **stub_error_init_screen(__DRIscreen *psp)
-- 
1.8.5.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2/4] loader: don't limit the non-udev path to only android

2014-03-18 Thread Jonathan Gray 
Signed-off-by: Jonathan Gray j...@jsg.id.au
---
 src/loader/loader.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git src/loader/loader.c src/loader/loader.c
index caeeebf..1744acb 100644
--- src/loader/loader.c
+++ src/loader/loader.c
@@ -202,7 +202,7 @@ out:
return (*chip_id = 0);
 }
 
-#elif defined(ANDROID)  !defined(__NOT_HAVE_DRM_H)
+#elif !defined(__NOT_HAVE_DRM_H)
 
 /* for i915 */
 #include i915_drm.h
-- 
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 2/4] loader: don't limit the non-udev path to only android

2014-03-18 Thread Jonathan Gray 
On Tue, Mar 18, 2014 at 07:56:21PM +, Emil Velikov wrote:
 On 18/03/14 14:59, Jonathan Gray wrote:
  Signed-off-by: Jonathan Gray j...@jsg.id.au
  ---
 Hi Jonathan
 
 While the summary covers what the patch does, the *ahem* commit message
 fails to explain why it's needed. AFAICS this will cause some very nasty
 breakage in some cases, which we want to avoid without a valid reason.
 
 -Emil

The summary is the commit message though?

Anyway without this I can't load dri drivers at all on OpenBSD
with mesa 10.x.  FreeBSD/NetBSD/Solaris/etc would also be broken
which strikes me as rather serious breakage...

udev is only available on Linux so every other platform
that uses dri is currently broken.
___
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

2014-03-19 Thread Jonathan Gray 
drm headers may be installed in a different directory

Signed-off-by: Jonathan Gray j...@jsg.id.au
---
 src/gallium/drivers/nouveau/nouveau_context.h   | 2 +-
 src/gallium/drivers/nouveau/nouveau_screen.c| 2 +-
 src/gallium/drivers/nouveau/nouveau_vp3_video.h | 2 +-
 src/gallium/drivers/nouveau/nouveau_winsys.h| 2 +-
 src/mesa/drivers/dri/nouveau/nouveau_driver.h   | 2 +-
 5 files changed, 5 insertions(+), 5 deletions(-)

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 libdrm/nouveau.h
+#include nouveau.h
 
 #define NOUVEAU_MAX_SCRATCH_BUFS 4
 
diff --git src/gallium/drivers/nouveau/nouveau_screen.c 
src/gallium/drivers/nouveau/nouveau_screen.c
index 19892b1..9d71bf7 100644
--- src/gallium/drivers/nouveau/nouveau_screen.c
+++ src/gallium/drivers/nouveau/nouveau_screen.c
@@ -14,7 +14,7 @@
 #include errno.h
 #include stdlib.h
 
-#include libdrm/nouveau_drm.h
+#include nouveau_drm.h
 
 #include nouveau_winsys.h
 #include nouveau_screen.h
diff --git src/gallium/drivers/nouveau/nouveau_vp3_video.h 
src/gallium/drivers/nouveau/nouveau_vp3_video.h
index 0193ed0..88c14ec 100644
--- src/gallium/drivers/nouveau/nouveau_vp3_video.h
+++ src/gallium/drivers/nouveau/nouveau_vp3_video.h
@@ -20,7 +20,7 @@
  * OTHER DEALINGS IN THE SOFTWARE.
  */
 
-#include libdrm/nouveau.h
+#include nouveau.h
 
 #include pipe/p_defines.h
 #include vl/vl_video_buffer.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 libdrm/nouveau.h
+#include nouveau.h
 
 #ifndef NV04_PFIFO_MAX_PACKET_LEN
 #define NV04_PFIFO_MAX_PACKET_LEN 2047
diff --git src/mesa/drivers/dri/nouveau/nouveau_driver.h 
src/mesa/drivers/dri/nouveau/nouveau_driver.h
index b6a8276..8b46e51 100644
--- src/mesa/drivers/dri/nouveau/nouveau_driver.h
+++ src/mesa/drivers/dri/nouveau/nouveau_driver.h
@@ -38,7 +38,7 @@
 #undef NDEBUG
 #include assert.h
 
-#include libdrm/nouveau.h
+#include nouveau.h
 #include nouveau_screen.h
 #include nouveau_state.h
 #include nouveau_surface.h
-- 
1.8.5.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] nouveau: use DLOPEN_LIBS instead of -ldl

2014-03-19 Thread Jonathan Gray 
libdl does not exist on many platforms which have dlopen in libc.

Signed-off-by: Jonathan Gray j...@jsg.id.au
---
 src/gallium/drivers/nouveau/Makefile.am | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git src/gallium/drivers/nouveau/Makefile.am 
src/gallium/drivers/nouveau/Makefile.am
index ac4f9bb..f004422 100644
--- src/gallium/drivers/nouveau/Makefile.am
+++ src/gallium/drivers/nouveau/Makefile.am
@@ -50,4 +50,4 @@ nouveau_compiler_LDADD = \
../../auxiliary/libgallium.la \
-lstdc++ \
-lm \
-   -ldl
+   $(DLOPEN_LIBS)
-- 
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] nouveau: don't assume libdrm include prefix

2014-03-20 Thread Jonathan Gray 
On Thu, Mar 20, 2014 at 07:29:32AM -0400, Ilia Mirkin wrote:
 On Wed, Mar 19, 2014 at 11:43 PM, Jonathan Gray j...@jsg.id.au wrote:
  drm headers may be installed in a different directory
 
 I'm curious -- how can this happen? Looking at Makefile.am from
 drm:nouveau/Makefile.am:
 
 libdrm_nouveauincludedir = ${includedir}/libdrm
 libdrm_nouveauinclude_HEADERS = nouveau.h

libdrm is built with bsd makefiles in the OpenBSD xenocara/X11 tree.
http://www.openbsd.org/cgi-bin/cvsweb/xenocara/lib/libdrm/

The *_drm.h headers are shared between userland and the kernel.

ie what Linux calls the 'uapi' headers can be found in
/usr/include/dev/pci/drm/
and the other libdrm headers are currently installed to
/usr/X11R6/include/

The libdrm*.pc pkg-config files reflect this.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] nouveau: don't assume libdrm include prefix

2014-03-20 Thread Jonathan Gray 
On Thu, Mar 20, 2014 at 08:09:41AM -0400, Ilia Mirkin wrote:
 On Thu, Mar 20, 2014 at 7:57 AM, Jonathan Gray j...@jsg.id.au wrote:
  On Thu, Mar 20, 2014 at 07:29:32AM -0400, Ilia Mirkin wrote:
  On Wed, Mar 19, 2014 at 11:43 PM, Jonathan Gray j...@jsg.id.au wrote:
   drm headers may be installed in a different directory
 
  I'm curious -- how can this happen? Looking at Makefile.am from
  drm:nouveau/Makefile.am:
 
  libdrm_nouveauincludedir = ${includedir}/libdrm
  libdrm_nouveauinclude_HEADERS = nouveau.h
 
  libdrm is built with bsd makefiles in the OpenBSD xenocara/X11 tree.
  http://www.openbsd.org/cgi-bin/cvsweb/xenocara/lib/libdrm/
 
  The *_drm.h headers are shared between userland and the kernel.
 
  ie what Linux calls the 'uapi' headers can be found in
  /usr/include/dev/pci/drm/
  and the other libdrm headers are currently installed to
  /usr/X11R6/include/
 
  The libdrm*.pc pkg-config files reflect this.
 
 Fair enough. I don't see nouveau in that repo, but I presume you're
 working on it, hence this change? (It should be entirely unrelated to
 the nouveau_drm.h thing from
 https://bugs.freedesktop.org/show_bug.cgi?id=76376 right?)

I'm looking into adding the userland side to reduce
the number of diffs I'm keeping track of for Mesa.
The kernel side I don't have any plans for at the moment.

And yes this is only needed if the driver is being built
but it matches the include behaviour of the other Mesa drivers.

 
 Reviewed-by: Ilia Mirkin imir...@alum.mit.edu
 
 Let me know if you need me to push these changes out.

Yes I do, thanks for looking at the diffs.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] nouveau: don't assume libdrm include prefix

2014-03-20 Thread Jonathan Gray 
On Thu, Mar 20, 2014 at 08:42:59AM -0400, Ilia Mirkin wrote:
 On Thu, Mar 20, 2014 at 8:25 AM, Jonathan Gray j...@jsg.id.au wrote:
  On Thu, Mar 20, 2014 at 08:09:41AM -0400, Ilia Mirkin wrote:
  On Thu, Mar 20, 2014 at 7:57 AM, Jonathan Gray j...@jsg.id.au wrote:
   On Thu, Mar 20, 2014 at 07:29:32AM -0400, Ilia Mirkin wrote:
   On Wed, Mar 19, 2014 at 11:43 PM, Jonathan Gray j...@jsg.id.au wrote:
drm headers may be installed in a different directory
  
   I'm curious -- how can this happen? Looking at Makefile.am from
   drm:nouveau/Makefile.am:
  
   libdrm_nouveauincludedir = ${includedir}/libdrm
   libdrm_nouveauinclude_HEADERS = nouveau.h
  
   libdrm is built with bsd makefiles in the OpenBSD xenocara/X11 tree.
   http://www.openbsd.org/cgi-bin/cvsweb/xenocara/lib/libdrm/
  
   The *_drm.h headers are shared between userland and the kernel.
  
   ie what Linux calls the 'uapi' headers can be found in
   /usr/include/dev/pci/drm/
   and the other libdrm headers are currently installed to
   /usr/X11R6/include/
  
   The libdrm*.pc pkg-config files reflect this.
 
  Fair enough. I don't see nouveau in that repo, but I presume you're
  working on it, hence this change? (It should be entirely unrelated to
  the nouveau_drm.h thing from
  https://bugs.freedesktop.org/show_bug.cgi?id=76376 right?)
 
  I'm looking into adding the userland side to reduce
  the number of diffs I'm keeping track of for Mesa.
  The kernel side I don't have any plans for at the moment.
 
  And yes this is only needed if the driver is being built
  but it matches the include behaviour of the other Mesa drivers.
 
 
  Reviewed-by: Ilia Mirkin imir...@alum.mit.edu
 
  Let me know if you need me to push these changes out.
 
  Yes I do, thanks for looking at the diffs.
 
 Pushed. Not sure how you generated the patches, but they seemed to be
 missing the a/ and b/ prefixes. The convention is for patches to be
 applied with patch -p1 (which git am enforces). I hand-edited them
 this time, not sure how you managed it if you were using git
 format-patch...

In my global git config I have

[diff]
noprefix = true

because OpenBSD patches are sent to be applied with -p0.

I'll override this for Mesa, so future patches should look
as you'd expect.

It does seem that git-am/git-apply accept a -p argument though
so you should have been able to use 'git am -p0' instead of
hand editing.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/4] loader: don't limit the non-udev path to only android

2014-03-21 Thread Jonathan Gray 
On Sat, Mar 22, 2014 at 12:10:26AM +, Emil Velikov wrote:
 On 19/03/14 01:06, Jonathan Gray wrote:
  On Tue, Mar 18, 2014 at 07:56:21PM +, Emil Velikov wrote:
  On 18/03/14 14:59, Jonathan Gray wrote:
  Signed-off-by: Jonathan Gray j...@jsg.id.au
  ---
  Hi Jonathan
 
  While the summary covers what the patch does, the *ahem* commit message
  fails to explain why it's needed. AFAICS this will cause some very nasty
  breakage in some cases, which we want to avoid without a valid reason.
 
  -Emil
  
  The summary is the commit message though?
  
  Anyway without this I can't load dri drivers at all on OpenBSD
  with mesa 10.x.  FreeBSD/NetBSD/Solaris/etc would also be broken
  which strikes me as rather serious breakage...
  
 Kind of expecting to see a fraction of the above in the commit message,
 maybe I was expecting too much.
 
 Wrt will cause some very nasty breakage I take that back, as I've
 missed the commit that enforces libudev on linux, which handles those
 lovely scenarios.
 
 FWIW For patches 1, 2 and 4.
 Reviewed-by: Emil Velikov emil.l.veli...@gmail.com

Thanks, I can send another patch with more explanation in the
commit message if you like.

 
 Btw, if you're looking for egl, wayland, opencl etc. similar fixes to
 patch 3 may be needed.

The sticking point for egl with non x11 platforms has been
the udev dependency in gbm.  Though it seems the loader changes have
removed this, the configure script still wants libudev to configure gbm.

The drm platform has the same issue issue with configure.

libgbm and drm platform support in egl seem to build and install fine
with the following patch for example:

diff --git a/configure.ac b/configure.ac
index 9c67a9b..88c26f7 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1133,10 +1133,6 @@ if test x$enable_gbm = xauto; then
 esac
 fi
 if test x$enable_gbm = xyes; then
-if test x$have_libudev != xyes; then
-AC_MSG_ERROR([gbm requires udev = $LIBUDEV_REQUIRED])
-fi
-
 if test x$enable_dri = xyes; then
 GBM_BACKEND_DIRS=$GBM_BACKEND_DIRS dri
 if test x$enable_shared_glapi = xno; then
@@ -1145,9 +1141,7 @@ if test x$enable_gbm = xyes; then
 fi
 fi
 AM_CONDITIONAL(HAVE_GBM, test x$enable_gbm = xyes)
-GBM_PC_REQ_PRIV=libudev = $LIBUDEV_REQUIRED
 GBM_PC_LIB_PRIV=$DLOPEN_LIBS
-AC_SUBST([GBM_PC_REQ_PRIV])
 AC_SUBST([GBM_PC_LIB_PRIV])
 
 dnl
@@ -1426,11 +1420,6 @@ for plat in $egl_platforms; do
AC_MSG_ERROR([EGL platform '$plat' does not exist])
;;
esac
-
-case $plat$have_libudev in
-waylandno|drmno)
-AC_MSG_ERROR([cannot build $plat platform without udev = 
$LIBUDEV_REQUIRED]) ;;
-esac
 done
 
 # libEGL wants to default to the first platform specified in
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/4] loader: don't limit the non-udev path to only android

2014-03-21 Thread Jonathan Gray 
On Sat, Mar 22, 2014 at 03:05:41PM +1100, Jonathan Gray wrote:
 On Sat, Mar 22, 2014 at 12:10:26AM +, Emil Velikov wrote:
  On 19/03/14 01:06, Jonathan Gray wrote:
   On Tue, Mar 18, 2014 at 07:56:21PM +, Emil Velikov wrote:
   On 18/03/14 14:59, Jonathan Gray wrote:
   Signed-off-by: Jonathan Gray j...@jsg.id.au
   ---
   Hi Jonathan
  
   While the summary covers what the patch does, the *ahem* commit message
   fails to explain why it's needed. AFAICS this will cause some very nasty
   breakage in some cases, which we want to avoid without a valid reason.
  
   -Emil
   
   The summary is the commit message though?
   
   Anyway without this I can't load dri drivers at all on OpenBSD
   with mesa 10.x.  FreeBSD/NetBSD/Solaris/etc would also be broken
   which strikes me as rather serious breakage...
   
  Kind of expecting to see a fraction of the above in the commit message,
  maybe I was expecting too much.
  
  Wrt will cause some very nasty breakage I take that back, as I've
  missed the commit that enforces libudev on linux, which handles those
  lovely scenarios.
  
  FWIW For patches 1, 2 and 4.
  Reviewed-by: Emil Velikov emil.l.veli...@gmail.com
 
 Thanks, I can send another patch with more explanation in the
 commit message if you like.
 
  
  Btw, if you're looking for egl, wayland, opencl etc. similar fixes to
  patch 3 may be needed.
 
 The sticking point for egl with non x11 platforms has been
 the udev dependency in gbm.  Though it seems the loader changes have
 removed this, the configure script still wants libudev to configure gbm.
 
 The drm platform has the same issue issue with configure.
 
 libgbm and drm platform support in egl seem to build and install fine
 with the following patch for example:

revised version that doesn't result in an unuseable .pc file

diff --git configure.ac configure.ac
index 9c67a9b..47c315b 100644
--- configure.ac
+++ configure.ac
@@ -1133,10 +1133,6 @@ if test x$enable_gbm = xauto; then
 esac
 fi
 if test x$enable_gbm = xyes; then
-if test x$have_libudev != xyes; then
-AC_MSG_ERROR([gbm requires udev = $LIBUDEV_REQUIRED])
-fi
-
 if test x$enable_dri = xyes; then
 GBM_BACKEND_DIRS=$GBM_BACKEND_DIRS dri
 if test x$enable_shared_glapi = xno; then
@@ -1145,7 +1141,7 @@ if test x$enable_gbm = xyes; then
 fi
 fi
 AM_CONDITIONAL(HAVE_GBM, test x$enable_gbm = xyes)
-GBM_PC_REQ_PRIV=libudev = $LIBUDEV_REQUIRED
+GBM_PC_REQ_PRIV=
 GBM_PC_LIB_PRIV=$DLOPEN_LIBS
 AC_SUBST([GBM_PC_REQ_PRIV])
 AC_SUBST([GBM_PC_LIB_PRIV])
@@ -1426,11 +1422,6 @@ for plat in $egl_platforms; do
AC_MSG_ERROR([EGL platform '$plat' does not exist])
;;
esac
-
-case $plat$have_libudev in
-waylandno|drmno)
-AC_MSG_ERROR([cannot build $plat platform without udev = 
$LIBUDEV_REQUIRED]) ;;
-esac
 done
 
 # libEGL wants to default to the first platform specified in
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/4] loader: don't limit the non-udev path to only android

2014-03-22 Thread Jonathan Gray 
On Sat, Mar 22, 2014 at 11:45:35AM +, Emil Velikov wrote:
 On 22/03/14 04:05, Jonathan Gray wrote:
  On Sat, Mar 22, 2014 at 12:10:26AM +, Emil Velikov wrote:
  On 19/03/14 01:06, Jonathan Gray wrote:
  On Tue, Mar 18, 2014 at 07:56:21PM +, Emil Velikov wrote:
  On 18/03/14 14:59, Jonathan Gray wrote:
  Signed-off-by: Jonathan Gray j...@jsg.id.au
  ---
  Hi Jonathan
 
  While the summary covers what the patch does, the *ahem* commit message
  fails to explain why it's needed. AFAICS this will cause some very nasty
  breakage in some cases, which we want to avoid without a valid reason.
 
  -Emil
 
  The summary is the commit message though?
 
  Anyway without this I can't load dri drivers at all on OpenBSD
  with mesa 10.x.  FreeBSD/NetBSD/Solaris/etc would also be broken
  which strikes me as rather serious breakage...
 
  Kind of expecting to see a fraction of the above in the commit message,
  maybe I was expecting too much.
 
  Wrt will cause some very nasty breakage I take that back, as I've
  missed the commit that enforces libudev on linux, which handles those
  lovely scenarios.
 
  FWIW For patches 1, 2 and 4.
  Reviewed-by: Emil Velikov emil.l.veli...@gmail.com
  
  Thanks, I can send another patch with more explanation in the
  commit message if you like.
  
 No problems, just as a future reference it would be nice :)
 
 
  Btw, if you're looking for egl, wayland, opencl etc. similar fixes to
  patch 3 may be needed.
  
  The sticking point for egl with non x11 platforms has been
  the udev dependency in gbm.  Though it seems the loader changes have
  removed this, the configure script still wants libudev to configure gbm.
  
  The drm platform has the same issue issue with configure.
  
  libgbm and drm platform support in egl seem to build and install fine
  with the following patch for example:
  
 Build is the smallest problem here. There is some deeper hacking
 required, as the loader functions are executed before the
 wayland/egl/gbm auth hooks are setup, let alone executed. I've never
 been too deep into the respective codebases so I could be wrong.
 
 IMHO it would be better to hold off the following patch until we make
 sure that the resulting binaries work.
 
 -Emil

Well that and two other small patches result in being able
to use glamoregl with the intel driver here

[  1003.926] (II) Loading sub module glamoregl
[  1003.926] (II) LoadModule: glamoregl
[  1003.928] (II) Loading /usr/X11R6/lib/modules/libglamoregl.so
[  1003.929] (II) Module glamoregl: vendor=X.Org Foundation
[  1003.929]compiled for 1.14.5, module version = 0.6.0
[  1003.929]ABI class: X.Org ANSI C Emulation, version 0.4
[  1003.929] (II) glamor: OpenGL accelerated X.org driver based.
[  1003.960] (II) glamor: EGL version 1.4 (DRI2):
[  1003.974] (II) intel(0): glamor detected, initialising egl layer.

commit 92681e94efe1fa3b85df431d6ddda7bbda2e5314
Author: Jonathan Gray j...@jsg.id.au
Date:   Sat Mar 22 18:44:38 2014 +1100

configure: don't require libudev for gbm or egl drm/wayland

After the loader changes libudev is no longer required for
gbm or the egl drm/wayland platforms.  Lets these build/run
on OpenBSD.

Signed-off-by: Jonathan Gray j...@jsg.id.au

diff --git a/configure.ac b/configure.ac
index 9c67a9b..47c315b 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1133,10 +1133,6 @@ if test x$enable_gbm = xauto; then
 esac
 fi
 if test x$enable_gbm = xyes; then
-if test x$have_libudev != xyes; then
-AC_MSG_ERROR([gbm requires udev = $LIBUDEV_REQUIRED])
-fi
-
 if test x$enable_dri = xyes; then
 GBM_BACKEND_DIRS=$GBM_BACKEND_DIRS dri
 if test x$enable_shared_glapi = xno; then
@@ -1145,7 +1141,7 @@ if test x$enable_gbm = xyes; then
 fi
 fi
 AM_CONDITIONAL(HAVE_GBM, test x$enable_gbm = xyes)
-GBM_PC_REQ_PRIV=libudev = $LIBUDEV_REQUIRED
+GBM_PC_REQ_PRIV=
 GBM_PC_LIB_PRIV=$DLOPEN_LIBS
 AC_SUBST([GBM_PC_REQ_PRIV])
 AC_SUBST([GBM_PC_LIB_PRIV])
@@ -1426,11 +1422,6 @@ for plat in $egl_platforms; do
AC_MSG_ERROR([EGL platform '$plat' does not exist])
;;
esac
-
-case $plat$have_libudev in
-waylandno|drmno)
-AC_MSG_ERROR([cannot build $plat platform without udev = 
$LIBUDEV_REQUIRED]) ;;
-esac
 done
 
 # libEGL wants to default to the first platform specified in

commit b5a6354509d02459a2bc04433075268fa855583c
Author: Jonathan Gray j...@jsg.id.au
Date:   Sat Mar 22 18:35:37 2014 +1100

egl/dri2: don't require libudev to build drm/wayland platforms

After the loader changes libudev is no longer required to
build gbm or the egl drm/wayland platforms.

Remove a libudev ifdef which allows the the drm egl driver
to be loaded on OpenBSD.

Signed-off-by: Jonathan Gray j...@jsg.id.au

diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
index 8abe8ac..dc541ad 100644
--- a/src/egl/drivers

[Mesa-dev] [PATCH] egl/dri2: don't require libudev to build drm/wayland platforms

2014-03-22 Thread Jonathan Gray 
After the loader changes libudev is no longer required to
build gbm or the egl drm/wayland platforms.

Remove a libudev ifdef which allows the the drm egl driver
to be loaded on OpenBSD.

Signed-off-by: Jonathan Gray j...@jsg.id.au
Reviewed-by: Emil Velikov emil.l.veli...@gmail.com
---
 src/egl/drivers/dri2/egl_dri2.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
index 8abe8ac..dc541ad 100644
--- a/src/egl/drivers/dri2/egl_dri2.c
+++ b/src/egl/drivers/dri2/egl_dri2.c
@@ -630,7 +630,6 @@ dri2_initialize(_EGLDriver *drv, _EGLDisplay *disp)
   return dri2_initialize_x11(drv, disp);
 #endif
 
-#ifdef HAVE_LIBUDEV
 #ifdef HAVE_DRM_PLATFORM
case _EGL_PLATFORM_DRM:
   if (disp-Options.TestOnly)
@@ -643,7 +642,6 @@ dri2_initialize(_EGLDriver *drv, _EGLDisplay *disp)
  return EGL_TRUE;
   return dri2_initialize_wayland(drv, disp);
 #endif
-#endif
 #ifdef HAVE_ANDROID_PLATFORM
case _EGL_PLATFORM_ANDROID:
   if (disp-Options.TestOnly)
-- 
1.8.5.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v2] egl/dri2: use drm macros to construct device name

2014-03-22 Thread Jonathan Gray 
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
suggested by Emil Velikov.

Signed-off-by: Jonathan Gray j...@jsg.id.au
---
 src/egl/drivers/dri2/platform_drm.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/src/egl/drivers/dri2/platform_drm.c 
b/src/egl/drivers/dri2/platform_drm.c
index 2f7edb9..964ac5a 100644
--- a/src/egl/drivers/dri2/platform_drm.c
+++ b/src/egl/drivers/dri2/platform_drm.c
@@ -492,7 +492,11 @@ dri2_initialize_drm(_EGLDriver *drv, _EGLDisplay *disp)
 
gbm = disp-PlatformDisplay;
if (gbm == NULL) {
-  fd = open(/dev/dri/card0, O_RDWR);
+  char buf[64];
+  if (snprintf(buf, sizeof(buf), DRM_DEV_NAME, DRM_DIR_NAME, 0) != -1)
+ 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.8.5.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v2] configure: don't require libudev for gbm or egl drm/wayland

2014-03-22 Thread Jonathan Gray 
After the loader changes libudev is no longer required for
gbm or the egl drm/wayland platforms.  Lets these build/run
on OpenBSD.

v2: preserve the libudev requirement for Linux as suggested
by Emil Velikov.

Signed-off-by: Jonathan Gray j...@jsg.id.au
---
 configure.ac | 21 -
 1 file changed, 16 insertions(+), 5 deletions(-)

diff --git a/configure.ac b/configure.ac
index 9c67a9b..ec24dbc 100644
--- a/configure.ac
+++ b/configure.ac
@@ -779,6 +779,13 @@ if test x$have_libdrm = xyes; then
DEFINES=$DEFINES -DHAVE_LIBDRM
 fi
 
+case $host_os in
+linux*)
+need_libudev=yes ;;
+*)
+need_libudev=no ;;
+esac
+
 PKG_CHECK_MODULES([LIBUDEV], [libudev = $LIBUDEV_REQUIRED],
   have_libudev=yes, have_libudev=no)
 
@@ -1133,7 +1140,7 @@ if test x$enable_gbm = xauto; then
 esac
 fi
 if test x$enable_gbm = xyes; then
-if test x$have_libudev != xyes; then
+if test x$need_libudev$have_libudev = xyesno; then
 AC_MSG_ERROR([gbm requires udev = $LIBUDEV_REQUIRED])
 fi
 
@@ -1145,7 +1152,11 @@ if test x$enable_gbm = xyes; then
 fi
 fi
 AM_CONDITIONAL(HAVE_GBM, test x$enable_gbm = xyes)
-GBM_PC_REQ_PRIV=libudev = $LIBUDEV_REQUIRED
+if test x$need_libudev = xyes; then
+GBM_PC_REQ_PRIV=libudev = $LIBUDEV_REQUIRED
+else
+GBM_PC_REQ_PRIV=
+fi
 GBM_PC_LIB_PRIV=$DLOPEN_LIBS
 AC_SUBST([GBM_PC_REQ_PRIV])
 AC_SUBST([GBM_PC_LIB_PRIV])
@@ -1427,8 +1438,8 @@ for plat in $egl_platforms; do
;;
esac
 
-case $plat$have_libudev in
-waylandno|drmno)
+case $plat$need_libudev$have_libudev in
+waylandyesno|drmyesno)
 AC_MSG_ERROR([cannot build $plat platform without udev = 
$LIBUDEV_REQUIRED]) ;;
 esac
 done
@@ -1691,7 +1702,7 @@ gallium_require_llvm() {
 
 gallium_require_drm_loader() {
 if test x$enable_gallium_loader = xyes; then
-if test x$have_libudev != xyes; then
+if test x$need_libudev$have_libudev = xyesno; then
 AC_MSG_ERROR([Gallium drm loader requires libudev = 
$LIBUDEV_REQUIRED])
 fi
 if test x$have_libdrm != xyes; then
-- 
1.8.5.3

___
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

2014-04-01 Thread Jonathan Gray 
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 j...@jsg.id.au
---
 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 \
$(GC_SECTIONS) \
-   -Wl,--no-undefined

[Mesa-dev] [PATCH v2] automake: don't enable -Wl, --no-undefined on OpenBSD

2014-04-02 Thread Jonathan Gray 
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 j...@jsg.id.au
---
 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/Makefile.am
index ef3d23e..4ee364e 100644
--- a/src

[Mesa-dev] [PATCH v3] egl/dri2: use drm macros to construct device name

2014-04-02 Thread Jonathan Gray 
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 j...@jsg.id.au
---
 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

2014-04-03 Thread Jonathan Gray 
On Wed, Apr 02, 2014 at 11:09:09PM -0700, Matt Turner wrote:
 On Wed, Apr 2, 2014 at 10:22 PM, Jonathan Gray j...@jsg.id.au 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 j...@jsg.id.au
  ---
   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 matts...@gmail.com

No, see the description from the manual page:

http://www.openbsd.org/cgi-bin/man.cgi?query=snprintfsektion=3format=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

2014-04-05 Thread Jonathan Gray 
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-devm=137534209528776w=2
removed a misused __gnu_linux__ ifdef, there was some
discussion but no clear alternative out of it.

http://marc.info/?l=mesa3d-devm=139446389719785w=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

2014-05-13 Thread Jonathan Gray 
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 mesa-sta...@lists.freedesktop.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78665
Signed-off-by: Jonathan Gray j...@jsg.id.au
---
 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 limits
 
-#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

2014-05-13 Thread Jonathan Gray 
Reviewed-by: Jonathan Gray j...@jsg.id.au
___
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

2014-05-18 Thread Jonathan Gray 
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

2014-05-18 Thread Jonathan Gray 
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

2014-05-19 Thread Jonathan Gray 
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

Re: [Mesa-dev] [PATCH] mesa: Drop USE_IEEE define.

2014-08-08 Thread Jonathan Gray 
On Wed, Aug 06, 2014 at 04:54:38PM -0700, Matt Turner wrote:
 I think OpenVMS was the only platform that Mesa ran on that used a
 non-IEEE representation for floats. We removed OpenVMS support a while
 back, and this should alleviate the need to continue updating the
 this-platform-uses-IEEE list.

OpenVMS isn't the only thing that runs on a vax, this will likely
break the software rasteriser on OpenBSD and NetBSD on vax.

It seems Mesa isn't currently built on OpenBSD/vax but is
on NetBSD.  Though NetBSD are stuck with Mesa 7.x.x due to
the DRM/KMS situation.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] st/xvmc/tests: avoid non portable error.h functions

2014-08-30 Thread Jonathan Gray 
Signed-off-by: Jonathan Gray j...@jsg.id.au
---
 src/gallium/state_trackers/xvmc/tests/test_blocks.c |  6 --
 src/gallium/state_trackers/xvmc/tests/test_context.c|  6 --
 src/gallium/state_trackers/xvmc/tests/test_rendering.c  | 13 -
 src/gallium/state_trackers/xvmc/tests/test_subpicture.c |  4 ++--
 src/gallium/state_trackers/xvmc/tests/test_surface.c|  6 --
 5 files changed, 22 insertions(+), 13 deletions(-)

diff --git a/src/gallium/state_trackers/xvmc/tests/test_blocks.c 
b/src/gallium/state_trackers/xvmc/tests/test_blocks.c
index 0baed19..a35838f 100644
--- a/src/gallium/state_trackers/xvmc/tests/test_blocks.c
+++ b/src/gallium/state_trackers/xvmc/tests/test_blocks.c
@@ -26,7 +26,8 @@
  **/
 
 #include assert.h
-#include error.h
+#include stdio.h
+#include stdlib.h
 #include testlib.h
 
 int main(int argc, char **argv)
@@ -62,7 +63,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)
diff --git a/src/gallium/state_trackers/xvmc/tests/test_context.c 
b/src/gallium/state_trackers/xvmc/tests/test_context.c
index 1b9b040..344ac76 100644
--- a/src/gallium/state_trackers/xvmc/tests/test_context.c
+++ b/src/gallium/state_trackers/xvmc/tests/test_context.c
@@ -26,7 +26,8 @@
  **/
 
 #include assert.h
-#include error.h
+#include stdio.h
+#include stdlib.h
 #include testlib.h
 
 int main(int argc, char **argv)
@@ -58,7 +59,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)
diff --git a/src/gallium/state_trackers/xvmc/tests/test_rendering.c 
b/src/gallium/state_trackers/xvmc/tests/test_rendering.c
index 5bfbea7..b3b3794 100644
--- a/src/gallium/state_trackers/xvmc/tests/test_rendering.c
+++ b/src/gallium/state_trackers/xvmc/tests/test_rendering.c
@@ -28,7 +28,7 @@
 #include assert.h
 #include stdio.h
 #include string.h
-#include error.h
+#include stdlib.h
 #include testlib.h
 
 #define BLOCK_WIDTH8
@@ -84,9 +84,9 @@ static void ParseArgs(int argc, char **argv, unsigned int 
*output_width, unsigne
}
 
if (fail)
-   error
-   (
-   1, 0,
+   {
+   fprintf(
+   stderr,
Bad argument.\n
\n
Usage: %s [options]\n
@@ -96,6 +96,8 @@ static void ParseArgs(int argc, char **argv, unsigned int 
*output_width, unsigne
\t-p\tPrompt for quit\n,
argv[0]
);
+   exit(1);
+   }
 }
 
 static void Gradient(short *block, unsigned int start, unsigned int stop, int 
horizontal, unsigned int intra_unsigned)
@@ -166,7 +168,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)
diff --git a/src/gallium/state_trackers/xvmc/tests/test_subpicture.c 
b/src/gallium/state_trackers/xvmc/tests/test_subpicture.c
index 8bd4d6d..ad9fbe3 100644
--- a/src/gallium/state_trackers/xvmc/tests/test_subpicture.c
+++ b/src/gallium/state_trackers/xvmc/tests/test_subpicture.c
@@ -26,7 +26,6 @@
  **/
 
 #include assert.h
-#include error.h
 #include stdio.h
 #include stdlib.h
 #include testlib.h
@@ -87,7 +86,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)
diff --git a/src/gallium/state_trackers/xvmc/tests/test_surface.c 
b/src/gallium/state_trackers/xvmc/tests/test_surface.c
index 8145686..964ca82 100644
--- a/src/gallium/state_trackers/xvmc/tests/test_surface.c
+++ b/src/gallium/state_trackers/xvmc/tests/test_surface.c
@@ -26,7 +26,8 @@
  **/
 
 #include assert.h
-#include error.h
+#include stdio.h
+#include stdlib.h
 #include testlib.h
 
 int main(int argc, char **argv)
@@ -59,7 +60,8 @@ int main(int argc, char **argv)
))
{
XCloseDisplay(display);
-   error(1, 0, Error

[Mesa-dev] [PATCH] automake: check if the linker supports --dynamic-list

2014-09-01 Thread Jonathan Gray 
As older versions of gnu ld did not support --dynamic-list check to see
if it is supported before using it.  Non gnu linkers such the apple one
likely lack this option as well.

Fixes the build on OpenBSD which has binutils 2.15 and 2.17.
The --dynamic-list option seems to been have introduced sometime after
binutils 2.17 was released as it is present in 2.18.

Signed-off-by: Jonathan Gray j...@jsg.id.au
---
 configure.ac  | 18 ++
 src/gallium/targets/dri/Makefile.am   |  6 +-
 src/gallium/targets/vdpau/Makefile.am |  6 +-
 3 files changed, 28 insertions(+), 2 deletions(-)

diff --git a/configure.ac b/configure.ac
index aed2a8b..5214267 100644
--- a/configure.ac
+++ b/configure.ac
@@ -356,6 +356,24 @@ LDFLAGS=$save_LDFLAGS
 AM_CONDITIONAL(HAVE_LD_VERSION_SCRIPT, test $have_ld_version_script = yes)
 
 dnl
+dnl Check if linker supports dynamic list files
+dnl
+AC_MSG_CHECKING([if the linker supports --dynamic-list])
+save_LDFLAGS=$LDFLAGS
+LDFLAGS=$LDFLAGS -Wl,--dynamic-list=conftest.dyn
+cat  conftest.dyn EOF
+{
+   radeon_drm_winsys_create;
+};
+EOF
+AC_LINK_IFELSE(
+[AC_LANG_SOURCE([int main() { return 0;}])],
+[have_ld_dynamic_list=yes;AC_MSG_RESULT(yes)],
+[have_ld_dynamic_list=no; AC_MSG_RESULT(no)])
+LDFLAGS=$save_LDFLAGS
+AM_CONDITIONAL(HAVE_LD_DYNAMIC_LIST, test $have_ld_dynamic_list = yes)
+
+dnl
 dnl compatibility symlinks
 dnl
 case $host_os in
diff --git a/src/gallium/targets/dri/Makefile.am 
b/src/gallium/targets/dri/Makefile.am
index 70b19b8..1c33a91 100644
--- a/src/gallium/targets/dri/Makefile.am
+++ b/src/gallium/targets/dri/Makefile.am
@@ -26,7 +26,6 @@ gallium_dri_la_LDFLAGS = \
-shrext .so \
-module \
-avoid-version \
-   -Wl,--dynamic-list=$(top_srcdir)/src/gallium/targets/dri-vdpau.dyn \
$(GC_SECTIONS)
 
 if HAVE_LD_VERSION_SCRIPT
@@ -34,6 +33,11 @@ gallium_dri_la_LDFLAGS += \
-Wl,--version-script=$(top_srcdir)/src/gallium/targets/dri/dri.sym
 endif # HAVE_LD_VERSION_SCRIPT
 
+if HAVE_LD_DYNAMIC_LIST
+gallium_dri_la_LDFLAGS += \
+   -Wl,--dynamic-list=$(top_srcdir)/src/gallium/targets/dri-vdpau.dyn
+endif # HAVE_LD_DYNAMIC_LIST
+
 gallium_dri_la_LIBADD = \
$(top_builddir)/src/mesa/libmesagallium.la \
$(top_builddir)/src/mesa/drivers/dri/common/libdricommon.la \
diff --git a/src/gallium/targets/vdpau/Makefile.am 
b/src/gallium/targets/vdpau/Makefile.am
index 6c92cd8..440cf22 100644
--- a/src/gallium/targets/vdpau/Makefile.am
+++ b/src/gallium/targets/vdpau/Makefile.am
@@ -15,7 +15,6 @@ libvdpau_gallium_la_LDFLAGS = \
-module \
-no-undefined \
-version-number $(VDPAU_MAJOR):$(VDPAU_MINOR) \
-   -Wl,--dynamic-list=$(top_srcdir)/src/gallium/targets/dri-vdpau.dyn \
$(GC_SECTIONS) \
$(LD_NO_UNDEFINED)
 
@@ -24,6 +23,11 @@ libvdpau_gallium_la_LDFLAGS += \
-Wl,--version-script=$(top_srcdir)/src/gallium/targets/vdpau/vdpau.sym
 endif # HAVE_LD_VERSION_SCRIPT
 
+if HAVE_LD_DYNAMIC_LIST
+libvdpau_gallium_la_LDFLAGS += \
+   -Wl,--dynamic-list=$(top_srcdir)/src/gallium/targets/dri-vdpau.dyn
+endif # HAVE_LD_DYNAMIC_LIST
+
 libvdpau_gallium_la_LIBADD = \
$(top_builddir)/src/gallium/state_trackers/vdpau/libvdpautracker.la \
$(top_builddir)/src/gallium/auxiliary/libgallium.la \
-- 
1.9.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] configure.ac: detect LLVM patch level when built via cmake

2014-09-05 Thread Jonathan Gray 
In LLVM 3.4.1 and 3.4.2 the patch level was only set in config.h when
LLVM was built via autoconf and not when it was built with cmake.
Fall back to retrieving the patch level from llvm-config --version to
handle this case.

Cc: 10.2 10.3 mesa-sta...@lists.freedesktop.org
Signed-off-by: Jonathan Gray j...@jsg.id.au
---
 configure.ac | 9 +
 1 file changed, 9 insertions(+)

diff --git a/configure.ac b/configure.ac
index 99ae6ba..98cd938 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1705,6 +1705,15 @@ if test x$enable_gallium_llvm = xyes; then
 [#include ${LLVM_INCLUDEDIR}/llvm/Config/config.h],
 LLVM_VERSION_PATCH=0) dnl Default if LLVM_VERSION_PATCH not found
 
+dnl In LLVM 3.4.1 and 3.4.2 the patch level was only set in config.h
+dnl for autoconf builds and not cmake builds
+if test $LLVM_VERSION_PATCH -eq 0; then
+LLVM_VERSION_PATCH=`echo $LLVM_VERSION | cut -d. -f3`
+if test -z $LLVM_VERSION_PATCH; then
+LLVM_VERSION_PATCH=0
+fi
+fi
+
 if test -n ${LLVM_VERSION_MAJOR}; then
 LLVM_VERSION_INT=${LLVM_VERSION_MAJOR}0${LLVM_VERSION_MINOR}
 else
-- 
1.9.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] configure.ac: strip _GNU_SOURCE from llvm-config output

2014-09-05 Thread Jonathan Gray 
Mesa already defines _GNU_SOURCE for glibc based systems and defining
_GNU_SOURCE will break the Mesa build on other systems such as OpenBSD.

_GNU_SOURCE only seems to be included in llvm-config output when
LLVM is built via autoconf and not when it is built by cmake.

Cc: 10.2 10.3 mesa-sta...@lists.freedesktop.org
Signed-off-by: Jonathan Gray j...@jsg.id.au
---
 configure.ac | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configure.ac b/configure.ac
index af950e7..0722114 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1650,6 +1650,7 @@ strip_unwanted_llvm_flags() {
 # Use \ (marks the end of the word)
 echo `$1` | sed \
-e 's/-DNDEBUG\//g' \
+   -e 's/-D_GNU_SOURCE\//g' \
-e 's/-pedantic\//g' \
-e 's/-Wcovered-switch-default\//g' \
-e 's/-O.\//g' \
-- 
1.9.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [Mesa-stable] [PATCH] configure.ac: detect LLVM patch level when built via cmake

2014-09-05 Thread Jonathan Gray 
On Fri, Sep 05, 2014 at 08:48:17PM +0100, Emil Velikov wrote:
 On 05/09/14 16:43, Jonathan Gray wrote:
  In LLVM 3.4.1 and 3.4.2 the patch level was only set in config.h when
  LLVM was built via autoconf and not when it was built with cmake.
  Fall back to retrieving the patch level from llvm-config --version to
  handle this case.
  
 Hi Jonathan,
 
 Can you please file this with the LLVM people ? Would be nice to have it fixed
 at the source, rather than patching every project that uses llvm.
 
 IIRC their cmake build tends to fall behind the autotools one occasionally -
 there was a funny bug with rtti for quite a while. Reports like this one
 will help them notice/fix the issue :)
 
 Thanks
 Emil

It seems unlikely that there will be any more 3.4 minor releases now
that LLVM 3.5 is out.

The problem is with the LLVM 3.4 branch but not the 3.5 branch or trunk.

http://llvm.org/viewvc/llvm-project/llvm/branches/release_34/include/llvm/Config/config.h.cmake?view=co
http://llvm.org/viewvc/llvm-project/llvm/branches/release_35/include/llvm/Config/config.h.cmake?view=co

It looks like a mistake was made by Tom Stellard when merging this
back to 3.4 in:
http://llvm.org/viewvc/llvm-project?view=revisionrevision=204262
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [Mesa-stable] [PATCH] configure.ac: strip _GNU_SOURCE from llvm-config output

2014-09-05 Thread Jonathan Gray 
On Fri, Sep 05, 2014 at 09:00:55PM +0100, Emil Velikov wrote:
 On 05/09/14 16:44, Jonathan Gray wrote:
  Mesa already defines _GNU_SOURCE for glibc based systems and defining
  _GNU_SOURCE will break the Mesa build on other systems such as OpenBSD.
  
  _GNU_SOURCE only seems to be included in llvm-config output when
  LLVM is built via autoconf and not when it is built by cmake.
  
 While I'm not a llvm aware person this patch makes perfect sense. We already
 define it, and regardless if the autotools, cmake or both llvm builds define
 this we are perfectly safe with dropping it.
 
 Wild suggestion - might be nice to give a shout to the llvm people about this
 inconsistency. Who knows they may have erroneously added it in the first 
 place :)

http://llvm.org/bugs/show_bug.cgi?id=20865

 
 Just one small nit - please the DEFINES in the clover state-tracker to
 AM_CPPFLAGS. This way the other two static archives will not be short of the
 define.

I'm not sure what you're getting at here, seems some words are
missing?  libclllvm_la_CXXFLAGS picks up DEFINES already?

Many of the GNU_SOURCE related ifdefs in Mesa would be better handled by
something like 

#if defined(_GNU_SOURCE)  defined(__GLIBC__)

instead of the current 

#if defined(_GNU_SOURCE)  !defined(__CYGWIN__)  !defined(__FreeBSD__)  \
   !defined(ANDROID)  !defined(__HAIKU__)  !defined(__UCLIBC__)  \
   !defined(__NetBSD__)

which quickly turns into a !defined for every platform that doesn't
use glibc...

 
 Thanks
 Emil
 
  Cc: 10.2 10.3 mesa-sta...@lists.freedesktop.org
  Signed-off-by: Jonathan Gray j...@jsg.id.au
  ---
   configure.ac | 1 +
   1 file changed, 1 insertion(+)
  
  diff --git a/configure.ac b/configure.ac
  index af950e7..0722114 100644
  --- a/configure.ac
  +++ b/configure.ac
  @@ -1650,6 +1650,7 @@ strip_unwanted_llvm_flags() {
   # Use \ (marks the end of the word)
   echo `$1` | sed \
  -e 's/-DNDEBUG\//g' \
  +   -e 's/-D_GNU_SOURCE\//g' \
  -e 's/-pedantic\//g' \
  -e 's/-Wcovered-switch-default\//g' \
  -e 's/-O.\//g' \
  
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] configure.ac: unbreak the build with non gnu grep

2014-09-10 Thread Jonathan Gray 
181581280bd430d122d416e308c1de82db82da04 changed the way the
llvm-config version is read from sed to grep and introduced
a requirement for gnu grep extension that treats BREs as EREs.

Avoid this by calling egrep instead of grep which should be
able to handle EREs everywhere.

This allows Mesa to build on OpenBSD again.

Signed-off-by: Jonathan Gray j...@jsg.id.au
---
 configure.ac | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index 985ad4c..f3ee387 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1695,7 +1695,7 @@ if test x$enable_gallium_llvm = xyes; then
 fi
 
 if test x$LLVM_CONFIG != xno; then
-LLVM_VERSION=`$LLVM_CONFIG --version | grep -o '^[[0-9.]]\+'`
+LLVM_VERSION=`$LLVM_CONFIG --version | egrep -o '^[[0-9.]]+'`
 LLVM_LDFLAGS=`$LLVM_CONFIG --ldflags`
 LLVM_BINDIR=`$LLVM_CONFIG --bindir`
 LLVM_CPPFLAGS=`strip_unwanted_llvm_flags $LLVM_CONFIG --cppflags`
-- 
2.1.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [Mesa-stable] [PATCH] configure.ac: detect LLVM patch level when built via cmake

2014-09-17 Thread Jonathan Gray 
On Tue, Sep 16, 2014 at 06:24:40PM -0400, Tom Stellard wrote:
 On Tue, Sep 09, 2014 at 07:56:03PM +0100, Emil Velikov wrote:
  On 09/09/14 16:26, Tom Stellard wrote:
   On Sat, Sep 06, 2014 at 01:43:55AM +1000, Jonathan Gray wrote:
   In LLVM 3.4.1 and 3.4.2 the patch level was only set in config.h when
   LLVM was built via autoconf and not when it was built with cmake.
   Fall back to retrieving the patch level from llvm-config --version to
   handle this case.
  
   
   We should extract LLVM_VERSION_PATH from $LLVM_VERSION and then we won't
   have to worry about which config file it is in.
   
  I believe you meant VERSION_PATCH above ? Indeed that would nice thing to 
  have
  but I doubt that it will get back-ported to the llvm 3.4 branch.
  
 
 I mean we should do this in Mesa's configure script.  Something like:
 
 LLVM_VERSION_PATCH = echo $LLVM_VERSION | sed 's/^[0-9]\+\.[0-9]\+\.//g'

This should be

LLVM_VERSION_PATCH = echo $LLVM_VERSION | sed -E 's/^[0-9]+\.[0-9]+\.//g'

$ echo 3.4.2 | sed 's/^[0-9]\+\.[0-9]\+\.//g' 
3.4.2

$ echo 3.4.2 | sed -E 's/^[0-9]+\.[0-9]+\.//g'  
2

$ echo 3.4.2 | gsed 's/^[0-9]\+\.[0-9]\+\.//g'
2

$ echo 3.4.2 | gsed -E 's/^[0-9]+\.[0-9]+\.//g'
2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [Mesa-stable] [PATCH] configure.ac: detect LLVM patch level when built via cmake

2014-09-17 Thread Jonathan Gray 
On Wed, Sep 17, 2014 at 07:03:56AM -0700, Tom Stellard wrote:
 On Wed, Sep 17, 2014 at 09:29:34PM +1000, Jonathan Gray wrote:
  On Tue, Sep 16, 2014 at 06:24:40PM -0400, Tom Stellard wrote:
   On Tue, Sep 09, 2014 at 07:56:03PM +0100, Emil Velikov wrote:
On 09/09/14 16:26, Tom Stellard wrote:
 On Sat, Sep 06, 2014 at 01:43:55AM +1000, Jonathan Gray wrote:
 In LLVM 3.4.1 and 3.4.2 the patch level was only set in config.h when
 LLVM was built via autoconf and not when it was built with cmake.
 Fall back to retrieving the patch level from llvm-config --version to
 handle this case.

 
 We should extract LLVM_VERSION_PATH from $LLVM_VERSION and then we 
 won't
 have to worry about which config file it is in.
 
I believe you meant VERSION_PATCH above ? Indeed that would nice thing 
to have
but I doubt that it will get back-ported to the llvm 3.4 branch.

   
   I mean we should do this in Mesa's configure script.  Something like:
   
   LLVM_VERSION_PATCH = echo $LLVM_VERSION | sed 's/^[0-9]\+\.[0-9]\+\.//g'
  
  This should be
  
  LLVM_VERSION_PATCH = echo $LLVM_VERSION | sed -E 's/^[0-9]+\.[0-9]+\.//g'
  
  $ echo 3.4.2 | sed 's/^[0-9]\+\.[0-9]\+\.//g' 
  3.4.2
  
  $ echo 3.4.2 | sed -E 's/^[0-9]+\.[0-9]+\.//g'  
  2
  
  $ echo 3.4.2 | gsed 's/^[0-9]\+\.[0-9]\+\.//g'
  2
  
  $ echo 3.4.2 | gsed -E 's/^[0-9]+\.[0-9]+\.//g'
  2
 
 Which of these examples are *BSD compatible?

To be compliant with POSIX you can only use + in extended regular expressions
the use of + in basic regular expressions is apparently a gnu extension?

http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap09.html

Using sed with extended regular expressions via -E is also an extension
but it would seem a more common one.

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/sed.html

In the above examples gsed is the gnu one and sed is the
Diomidis Spinellis/BSD/OS X sed.  The way the REs are handled
depends on how REs are implemented in the respective libc versions.

This is really the same issue you reviewed and pushed a
fix for in cdb353539c259d5c5137394f6a7b4dafef9a40da except
there is no 'esed' for EREs with sed.

So the version with -E should be preferred.  But either way there
is a problem with versions of llvm that don't have a patch level.

$ echo 3.4 | sed -E 's/^[0-9]+\.[0-9]+\.//g'   
3.4

so if you want to use sed it should be something like
$ echo 3.4 | sed -E 's/^[0-9]+\.[0-9]+//g'

Then check for an empty string and set it zero.
Or just use 'cut' like the cmake patch did.

LLVM_VERSION_PATCH=`echo $LLVM_VERSION | cut -d. -f3`
if test -z $LLVM_VERSION_PATCH; then
LLVM_VERSION_PATCH=0
fi
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [Mesa-stable] [PATCH] configure.ac: detect LLVM patch level when built via cmake

2014-09-22 Thread Jonathan Gray 
On Tue, Sep 23, 2014 at 12:38:55AM +0100, Emil Velikov wrote:
 On 17/09/14 15:37, Jonathan Gray wrote:
  On Wed, Sep 17, 2014 at 07:03:56AM -0700, Tom Stellard wrote:
  On Wed, Sep 17, 2014 at 09:29:34PM +1000, Jonathan Gray wrote:
  On Tue, Sep 16, 2014 at 06:24:40PM -0400, Tom Stellard wrote:
  On Tue, Sep 09, 2014 at 07:56:03PM +0100, Emil Velikov wrote:
  On 09/09/14 16:26, Tom Stellard wrote:
  On Sat, Sep 06, 2014 at 01:43:55AM +1000, Jonathan Gray wrote:
  In LLVM 3.4.1 and 3.4.2 the patch level was only set in config.h when
  LLVM was built via autoconf and not when it was built with cmake.
  Fall back to retrieving the patch level from llvm-config --version to
  handle this case.
 
 
  We should extract LLVM_VERSION_PATH from $LLVM_VERSION and then we 
  won't
  have to worry about which config file it is in.
 
  I believe you meant VERSION_PATCH above ? Indeed that would nice thing 
  to have
  but I doubt that it will get back-ported to the llvm 3.4 branch.
 
 
  I mean we should do this in Mesa's configure script.  Something like:
 
  LLVM_VERSION_PATCH = echo $LLVM_VERSION | sed 's/^[0-9]\+\.[0-9]\+\.//g'
 
  This should be
 
  LLVM_VERSION_PATCH = echo $LLVM_VERSION | sed -E 's/^[0-9]+\.[0-9]+\.//g'
 
  $ echo 3.4.2 | sed 's/^[0-9]\+\.[0-9]\+\.//g' 
  3.4.2
 
  $ echo 3.4.2 | sed -E 's/^[0-9]+\.[0-9]+\.//g'  
  2
 
  $ echo 3.4.2 | gsed 's/^[0-9]\+\.[0-9]\+\.//g'
  2
 
  $ echo 3.4.2 | gsed -E 's/^[0-9]+\.[0-9]+\.//g'
  2
 
  Which of these examples are *BSD compatible?
  
  To be compliant with POSIX you can only use + in extended regular 
  expressions
  the use of + in basic regular expressions is apparently a gnu extension?
  
  http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap09.html
  
  Using sed with extended regular expressions via -E is also an extension
  but it would seem a more common one.
  
  http://pubs.opengroup.org/onlinepubs/9699919799/utilities/sed.html
  
  In the above examples gsed is the gnu one and sed is the
  Diomidis Spinellis/BSD/OS X sed.  The way the REs are handled
  depends on how REs are implemented in the respective libc versions.
  
  This is really the same issue you reviewed and pushed a
  fix for in cdb353539c259d5c5137394f6a7b4dafef9a40da except
  there is no 'esed' for EREs with sed.
  
  So the version with -E should be preferred.  But either way there
  is a problem with versions of llvm that don't have a patch level.
  
  $ echo 3.4 | sed -E 's/^[0-9]+\.[0-9]+\.//g'   
  3.4
  
  so if you want to use sed it should be something like
  $ echo 3.4 | sed -E 's/^[0-9]+\.[0-9]+//g'
  
  Then check for an empty string and set it zero.
  Or just use 'cut' like the cmake patch did.
  
  LLVM_VERSION_PATCH=`echo $LLVM_VERSION | cut -d. -f3`
  if test -z $LLVM_VERSION_PATCH; then
  LLVM_VERSION_PATCH=0
  fi
  
 AFAICT the agreement here is to drop the header parsing/searching and
 use llvm-config --version (i.e. LLVM_VERSION). And obviously zero out
 the patch version when applicable.
 
 Jonathan does this solution work properly with llvm's cmake and/or
 autoconf build ? If so can you prep a patch please :)

Both autoconf and cmake builds of LLVM install llvm-config,
and llvm-config from 3.4.2 for example does report the correct
version unlike the header method when built via cmake.

 
 A worthy mention, this is not the first time llvm's cmake build is
 causing problems and I'm not sure how well the llvm people tested it.
 Any particular reason to stick with it, or is llvm's autoconf build in a
 similar (*BSD unfriendly) state as mesa ?

It seems the general sentiment is to remove the autoconf build system
in LLVM.  See
http://comments.gmane.org/gmane.comp.compilers.llvm.devel/69072
FreeBSD has their own LLVM build system, but likely still build
llvm-config.  The OpenBSD LLVM port switched to building with
cmake for LLVM 3.0 about three years ago, I'm not entirely sure
on the reasons for that.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [Mesa-stable] [PATCH] configure.ac: Compute LLVM_VERSION_PATCH using llvm-config

2014-09-26 Thread Jonathan Gray 
On Thu, Sep 25, 2014 at 12:55:40PM -0700, Tom Stellard wrote:
 This is the only guaranteed way get the patch level for llvm,
 since the define cannot always be found in config.h depending
 on the version of llvm or the build system used.
 
 CC: mesa-sta...@lists.freedesktop.org

Reviewed-by: Jonathan Gray j...@jsg.id.au

 ---
  configure.ac | 9 -
  1 file changed, 4 insertions(+), 5 deletions(-)
 
 diff --git a/configure.ac b/configure.ac
 index bad1528..a097a5c 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -1704,11 +1704,10 @@ if test x$enable_gallium_llvm = xyes; then
  AC_COMPUTE_INT([LLVM_VERSION_MINOR], [LLVM_VERSION_MINOR],
  [#include ${LLVM_INCLUDEDIR}/llvm/Config/llvm-config.h])
  
 -dnl In LLVM 3.4.1 patch level was defined in config.h and not
 -dnl llvm-config.h
 -AC_COMPUTE_INT([LLVM_VERSION_PATCH], [LLVM_VERSION_PATCH],
 -[#include ${LLVM_INCLUDEDIR}/llvm/Config/config.h],
 -LLVM_VERSION_PATCH=0) dnl Default if LLVM_VERSION_PATCH not found
 +LLVM_VERSION_PATCH=`echo $LLVM_VERSION | cut -d. -f3 | egrep -o 
 '^[[0-9]]+'`
 +if test -z $LLVM_VERSION_PATCH; then
 +LLVM_VERSION_PATCH=0
 +fi
  
  if test -n ${LLVM_VERSION_MAJOR}; then
  LLVM_VERSION_INT=${LLVM_VERSION_MAJOR}0${LLVM_VERSION_MINOR}
 -- 
 1.8.3.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] i965: avoid anonymous struct in float - VF conversions

2014-11-29 Thread Jonathan Gray 
Anonymous structures are only supported with newer versions of
GCC.  They will not work with GCC 4.2.1 used by OpenBSD or
GCC 4.4.7 shipped with RHEL6 going by a commit to fix a similiar
problem in radeonsi earlier in the year
(74388dd24bc7fdb9e62ec18096163f5426e03fbf).

Signed-off-by: Jonathan Gray j...@jsg.id.au
---
 src/mesa/drivers/dri/i965/brw_packed_float.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_packed_float.c 
b/src/mesa/drivers/dri/i965/brw_packed_float.c
index 329ba15..9b7687a 100644
--- a/src/mesa/drivers/dri/i965/brw_packed_float.c
+++ b/src/mesa/drivers/dri/i965/brw_packed_float.c
@@ -29,7 +29,7 @@ union fu {
   unsigned mantissa:23;
   unsigned exponent:8;
   unsigned sign:1;
-   };
+   } s;
 };
 
 int
@@ -39,11 +39,11 @@ brw_float_to_vf(float f)
 
/* ±0.0f is special cased. */
if (f == 0.0f)
-  return fu.sign  7;
+  return fu.s.sign  7;
 
-   unsigned mantissa = fu.mantissa  (23 - 4);
-   unsigned exponent = fu.exponent - (127 - 3);
-   unsigned vf = (fu.sign  7) | (exponent  4) | mantissa;
+   unsigned mantissa = fu.s.mantissa  (23 - 4);
+   unsigned exponent = fu.s.exponent - (127 - 3);
+   unsigned vf = (fu.s.sign  7) | (exponent  4) | mantissa;
 
/* 0.125 would have had the same representation as 0.0, so reject it. */
if ((vf  0x7f) == 0)
@@ -67,9 +67,9 @@ brw_vf_to_float(unsigned char vf)
   return fu.f;
}
 
-   fu.sign = vf  7;
-   fu.exponent = ((vf  0x70)  4) + (127 - 3);
-   fu.mantissa = (vf  0xf)  (23 - 4);
+   fu.s.sign = vf  7;
+   fu.s.exponent = ((vf  0x70)  4) + (127 - 3);
+   fu.s.mantissa = (vf  0xf)  (23 - 4);
 
return fu.f;
 }
-- 
2.1.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] i965: Fix union usage for GCC = 4.6.

2014-12-05 Thread Jonathan Gray 
On Fri, Dec 05, 2014 at 06:56:27PM -0800, Matt Turner wrote:
 On Fri, Dec 5, 2014 at 6:18 PM, Vinson Lee v...@freedesktop.org wrote:
  This patch fixes this build error with GCC = 4.6.
 
CXXtest_vf_float_conversions.o
  test_vf_float_conversions.cpp: In function ???unsigned int f2u(float)???:
  test_vf_float_conversions.cpp:63:20: error: expected primary-expression 
  before ???.??? token
 
  Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86939
  Signed-off-by: Vinson Lee v...@freedesktop.org
  ---
   .../drivers/dri/i965/test_vf_float_conversions.cpp |3 ++-
   1 file changed, 2 insertions(+), 1 deletion(-)
 
  diff --git a/src/mesa/drivers/dri/i965/test_vf_float_conversions.cpp 
  b/src/mesa/drivers/dri/i965/test_vf_float_conversions.cpp
  index 2ea36fd..6a8bcea 100644
  --- a/src/mesa/drivers/dri/i965/test_vf_float_conversions.cpp
  +++ b/src/mesa/drivers/dri/i965/test_vf_float_conversions.cpp
  @@ -60,7 +60,8 @@ union fu {
   static unsigned
   f2u(float f)
   {
  -   union fu fu = { .f = f };
  +   union fu fu;
  +   fu.f = f;
  return fu.u;
   }
 
 I'm surprised that this is necessary. Can someone point me to some
 documentation that says that designated initializers for unions only
 were added with gcc-4.7?
 
 Jonathan, can you confirm that this is required? I suppose you didn't
 notice because you didn't build with 'make check'?

No I don't normally run make check, it seems it errors out before then
as it assumes /bin/bash is present

/bin/sh: ./es1api/ABI-check: No such file or directory
FAIL: es1api/ABI-check
/bin/sh: ./es2api/ABI-check: No such file or directory
FAIL: es2api/ABI-check

glsl_test does not link due to missing pthread symbols

And there looks to be a large amount of other scripts that want bash, ugh.

Running gmake check from src/mesa/drivers/dri instead of the top level gives:

test_vf_float_conversions.cpp: In function 'unsigned int f2u(float)':
test_vf_float_conversions.cpp:63: error: expected primary-expression before 
'union'
test_vf_float_conversions.cpp:63: error: expected `)' before 'union'
Makefile:1013: recipe for target 'test_vf_float_conversions.o' failed

With the below diff from the top level I get as far as
== Testing optimization passes ==
Testing ./lower_jumps/lower_returns_main_true.opt_test...FAIL
Traceback (most recent call last):
  File /usr/users/jsg/src/mesa/src/glsl/tests/compare_ir, line 43, in module
ir2 = sort_decls(parse_sexp(f.read()))
  File /usr/users/jsg/src/mesa/src/glsl/tests/sexps.py, line 66, in parse_sexp
raise Exception('Multiple sexps')
Exception: Multiple sexps
Testing ./lower_jumps/lower_returns_main_false.opt_test...FAIL
Traceback (most recent call last):
  File /usr/users/jsg/src/mesa/src/glsl/tests/compare_ir, line 43, in module
ir2 = sort_decls(parse_sexp(f.read()))
  File /usr/users/jsg/src/mesa/src/glsl/tests/sexps.py, line 66, in parse_sexp
raise Exception('Multiple sexps')
Exception: Multiple sexps

(and a bunch more of these)

Along with the ABI-check scripts it seems at the very least
all occurances of #!/bin/bash should be changed to
#!/usr/bin/env bash if they are actually bash specific.

In other words these:
bin/bugzilla_mesa.sh:#!/bin/bash
bin/shortlog_mesa.sh:#!/bin/bash
src/egl/wayland/wayland-egl/wayland-egl-symbols-check:#!/bin/bash
src/gallium/targets/gbm/gallium-gbm-symbols-check:#!/bin/bash
src/gallium/tools/addr2line.sh:#!/bin/bash
src/gallium/tools/trace/tracediff.sh:#!/bin/bash
src/gbm/gbm-symbols-check:#!/bin/basH

diff --git a/src/glsl/Makefile.am b/src/glsl/Makefile.am
index 0ccc81d..66986eb 100644
--- a/src/glsl/Makefile.am
+++ b/src/glsl/Makefile.am
@@ -137,7 +137,8 @@ glsl_test_SOURCES = \
test.cpp \
test_optpass.cpp
 
-glsl_test_LDADD = libglsl.la
+glsl_test_LDADD = libglsl.la   \
+   $(PTHREAD_LIBS)
 
 # We write our own rules for yacc and lex below. We'd rather use automake,
 # but automake makes it especially difficult for a number of reasons:
diff --git a/src/glsl/tests/optimization-test b/src/glsl/tests/optimization-test
index 26a51be..19e3ce5 100755
--- a/src/glsl/tests/optimization-test
+++ b/src/glsl/tests/optimization-test
@@ -1,4 +1,4 @@
-#!/usr/bin/env bash
+#!/bin/sh
 
 if [ ! -z $srcdir ]; then
compare_ir=`pwd`/tests/compare_ir
diff --git a/src/mapi/es1api/ABI-check b/src/mapi/es1api/ABI-check
index 44654cd..223658b 100755
--- a/src/mapi/es1api/ABI-check
+++ b/src/mapi/es1api/ABI-check
@@ -1,4 +1,4 @@
-#!/bin/bash
+#!/bin/sh
 
 # Print defined gl.* functions not in GL ES 1.1 or in
 # (FIXME, none of these should be part of the ABI)
diff --git a/src/mapi/es2api/ABI-check b/src/mapi/es2api/ABI-check
index abbb55c..5c9e826 100755
--- a/src/mapi/es2api/ABI-check
+++ b/src/mapi/es2api/ABI-check
@@ -1,4 +1,4 @@
-#!/bin/bash
+#!/bin/sh
 
 # Print defined gl.* functions not in GL ES 3.0 or in
 # (FIXME, none of these should be part of the ABI)
___
mesa-dev mailing

Re: [Mesa-dev] [RFC 6/8] mesa: remove support for GCC older than 4.1.0

2014-12-15 Thread Jonathan Gray 
On Sat, Dec 13, 2014 at 09:09:27PM +1100, Timothy Arceri wrote:
 On Fri, 2014-12-12 at 07:01 -0600, kallisti5 wrote:
  On 2014-12-12 05:46, Timothy Arceri wrote:
   Signed-off-by: Timothy Arceri t_arc...@yahoo.com.au
   ---
src/mesa/main/compiler.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
   
   diff --git a/src/mesa/main/compiler.h b/src/mesa/main/compiler.h
   index 34671dc..cdc843d 100644
   --- a/src/mesa/main/compiler.h
   +++ b/src/mesa/main/compiler.h
   @@ -122,7 +122,7 @@ extern C {
 * inline a static function that we later use in an alias. - ajax
 */
#ifndef PUBLIC
   -#  if (defined(__GNUC__)  __GNUC__ = 4) || (defined(__SUNPRO_C) 
   (__SUNPRO_C = 0x590))
   +#  if defined(__GNUC__) || (defined(__SUNPRO_C)  (__SUNPRO_C = 
   0x590))
#define PUBLIC __attribute__((visibility(default)))
#define USED __attribute__((used))
#  else
  
  Why not also drop the SUNPRO_C version check?
  
  #  if defined(__GNUC__) || defined(__SUNPRO_C)
  
  I downloaded SunStudio 12 (circa 2007) and __SUNPRO_C is set to 0x590.
  If we drop support for GCC 4.1 (2007), might as well drop older sun 
  compilers.
 
 
 The series is dropping support for GCC 4.0. 4.1 is shipped with Redhat
 Enterprise Linux 5 which is still in support so I've set that as the
 minimum version.

It is worth pointing out OpenBSD ships a patched GCC 4.2.1 as the base
compiler as that was the last GPLv2 licensed version.  Not relevant this
time, perhaps it will be next time.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC 6/8] mesa: remove support for GCC older than 4.1.0

2014-12-17 Thread Jonathan Gray 
On Thu, Dec 18, 2014 at 12:26:10AM +1100, Timothy Arceri wrote:
 On Tue, 2014-12-16 at 22:58 -0800, Vinson Lee wrote:
  On Mon, Dec 15, 2014 at 6:23 PM, Jonathan Gray j...@jsg.id.au wrote:
   On Sat, Dec 13, 2014 at 09:09:27PM +1100, Timothy Arceri wrote:
   On Fri, 2014-12-12 at 07:01 -0600, kallisti5 wrote:
On 2014-12-12 05:46, Timothy Arceri wrote:
 Signed-off-by: Timothy Arceri t_arc...@yahoo.com.au
 ---
  src/mesa/main/compiler.h | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/src/mesa/main/compiler.h b/src/mesa/main/compiler.h
 index 34671dc..cdc843d 100644
 --- a/src/mesa/main/compiler.h
 +++ b/src/mesa/main/compiler.h
 @@ -122,7 +122,7 @@ extern C {
   * inline a static function that we later use in an alias. - ajax
   */
  #ifndef PUBLIC
 -#  if (defined(__GNUC__)  __GNUC__ = 4) || (defined(__SUNPRO_C) 
 
 (__SUNPRO_C = 0x590))
 +#  if defined(__GNUC__) || (defined(__SUNPRO_C)  (__SUNPRO_C =
 0x590))
  #define PUBLIC __attribute__((visibility(default)))
  #define USED __attribute__((used))
  #  else
   
Why not also drop the SUNPRO_C version check?
   
#  if defined(__GNUC__) || defined(__SUNPRO_C)
   
I downloaded SunStudio 12 (circa 2007) and __SUNPRO_C is set to 0x590.
If we drop support for GCC 4.1 (2007), might as well drop older sun
compilers.
  
  
   The series is dropping support for GCC 4.0. 4.1 is shipped with Redhat
   Enterprise Linux 5 which is still in support so I've set that as the
   minimum version.
  
   It is worth pointing out OpenBSD ships a patched GCC 4.2.1 as the base
   compiler as that was the last GPLv2 licensed version.  Not relevant this
   time, perhaps it will be next time.
   ___
   mesa-dev mailing list
   mesa-dev@lists.freedesktop.org
   http://lists.freedesktop.org/mailman/listinfo/mesa-dev
  
  
  Latest master doesn't build with GCC 4.1.
  
  glsl/ir_uniform.h:45: error: use of enum ???gl_uniform_driver_format???
  without previous declaration
 
 My reasoning for using 4.1 seems to be flawed as RHEL 5 comes with
 autoconf 2.59 by default and current Mesa requires 2.60. Maybe bumping
 GCC to 4.2 would be better. I assume the above issue doesn't happen on
 4.2 since OpenBSD uses it?

I don't see that error with master here.

The problem seems to be the use of an attribute on the enum which going
by https://gcc.gnu.org/gcc-4.2/changes.html is only supported after 4.2.0?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC 6/8] mesa: remove support for GCC older than 4.1.0

2014-12-17 Thread Jonathan Gray 
On Wed, Dec 17, 2014 at 07:39:21AM -0800, Matt Turner wrote:
 On Wed, Dec 17, 2014 at 7:28 AM, Jonathan Gray j...@jsg.id.au wrote:
  On Thu, Dec 18, 2014 at 12:26:10AM +1100, Timothy Arceri wrote:
  On Tue, 2014-12-16 at 22:58 -0800, Vinson Lee wrote:
   On Mon, Dec 15, 2014 at 6:23 PM, Jonathan Gray j...@jsg.id.au wrote:
On Sat, Dec 13, 2014 at 09:09:27PM +1100, Timothy Arceri wrote:
On Fri, 2014-12-12 at 07:01 -0600, kallisti5 wrote:
 On 2014-12-12 05:46, Timothy Arceri wrote:
  Signed-off-by: Timothy Arceri t_arc...@yahoo.com.au
  ---
   src/mesa/main/compiler.h | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)
 
  diff --git a/src/mesa/main/compiler.h b/src/mesa/main/compiler.h
  index 34671dc..cdc843d 100644
  --- a/src/mesa/main/compiler.h
  +++ b/src/mesa/main/compiler.h
  @@ -122,7 +122,7 @@ extern C {
* inline a static function that we later use in an alias. - ajax
*/
   #ifndef PUBLIC
  -#  if (defined(__GNUC__)  __GNUC__ = 4) || 
  (defined(__SUNPRO_C) 
  (__SUNPRO_C = 0x590))
  +#  if defined(__GNUC__) || (defined(__SUNPRO_C)  (__SUNPRO_C =
  0x590))
   #define PUBLIC __attribute__((visibility(default)))
   #define USED __attribute__((used))
   #  else

 Why not also drop the SUNPRO_C version check?

 #  if defined(__GNUC__) || defined(__SUNPRO_C)

 I downloaded SunStudio 12 (circa 2007) and __SUNPRO_C is set to 
 0x590.
 If we drop support for GCC 4.1 (2007), might as well drop older sun
 compilers.
   
   
The series is dropping support for GCC 4.0. 4.1 is shipped with Redhat
Enterprise Linux 5 which is still in support so I've set that as the
minimum version.
   
It is worth pointing out OpenBSD ships a patched GCC 4.2.1 as the base
compiler as that was the last GPLv2 licensed version.  Not relevant 
this
time, perhaps it will be next time.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
  
  
   Latest master doesn't build with GCC 4.1.
  
   glsl/ir_uniform.h:45: error: use of enum ???gl_uniform_driver_format???
   without previous declaration
 
  My reasoning for using 4.1 seems to be flawed as RHEL 5 comes with
  autoconf 2.59 by default and current Mesa requires 2.60. Maybe bumping
  GCC to 4.2 would be better. I assume the above issue doesn't happen on
  4.2 since OpenBSD uses it?
 
  I don't see that error with master here.
 
  The problem seems to be the use of an attribute on the enum which going
  by https://gcc.gnu.org/gcc-4.2/changes.html is only supported after 4.2.0?
 
 Indeed, and that code has been in place since June and no one has
 complained as far as I can tell.
 
 I'm okay with bumping the minimum to 4.2. We're already using
 __attribute__((packed)) on enums in a number of places in the i965
 driver.

i965 also requires the GCC extension of binary integer constants which
was introduced in GCC 4.3.  I backported the GPLv2 patch in GCC PR 23479
for that to OpenBSD's 4.2.1.  I know at least FreeBSD did that as well.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] mesa: Add mesa SHA-1 functions

2014-12-22 Thread Jonathan Gray 
On Fri, Dec 19, 2014 at 11:44:42AM -0800, Kenneth Graunke wrote:
 On Sunday, December 14, 2014 03:06:41 PM Emil Velikov wrote:
  On 11/12/14 21:51, Carl Worth wrote:
   From: Kristian Høgsberg k...@bitplanet.net
   
   The upcoming shader cache uses the SHA-1 algorithm for cryptographic
   naming. These new mesa_sha1 functions are implemented with the nettle
   library.
   ---
   
   This patch is another in support of my upcoming shader-cache work. Thanks 
   to
   Kritian for coding this piece.
   
   As currently written, this patch introduces a new dependency of Mesa on 
   the
   Nettle library to implement SHA-1. I'm open to recommendations if people 
   would prefer some other option.
   
   For example, the xserver can be configured to get a SHA-1 implementation 
   from
   libmd, libc, CommonCrypto, CryptoAPI, libnettle, libgcrypt, libsha1, or
   openssl.
   
   I don't know if it's important to offer as many options as that, which is 
   why
   I'm asking for opinions here.
   
  Hi Carl,
  
  Can we try to avoid adding new dependencies to mesa unless absolutely
  needed. Neither of the proprietary drivers does so presently, so it will
  be nice to keep the trend.
  
  While currently the steam runtime does not include libnettle I can
  envision one day that they will/might. Even with steam aside I think
  that this might cause issues with gnome  others' sandboxing.
  
  Long story short - can we import a sha1 implementation from another
  project ? It will save us the libstdc++ style steam runtime issues,
  plus it will ease the question of what to do under Windows :)
  
  
  Thanks
  Emil
 
 FWIW, when I hacked together a shader cache proof of concept, I imported
 smallsha1, which is just a pair of .cpp/.h files:
 
 https://code.google.com/p/smallsha1/
 
 It's BSD-3-Clause - my main criteria was that it had to be permissively
 licensed.  Having the implementation in a single file is nice as well.
 
 --Ken

fwiw the version in OpenBSD's libc is public domain and quite small
http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/lib/libc/hash/sha1.c?rev=HEAD
http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/include/sha1.h?rev=HEAD
___
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.

2015-02-06 Thread Jonathan Gray 
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 j...@jsg.id.au
 ---
   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] gallium/util: Define ffsll on OpenBSD.

2015-02-06 Thread Jonathan Gray 
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 j...@jsg.id.au
---
 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] mesa: Add new fast mtx_t mutex type for basic use cases

2015-01-27 Thread Jonathan Gray 
Including linux/futex.h 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

Re: [Mesa-dev] [PATCH] ax_prog_flex.m4: Merge upstream OpenBSD fixes.

2015-01-05 Thread Jonathan Gray 
On Mon, Jan 05, 2015 at 03:18:54PM -0800, Vinson Lee wrote:
 Merge the following upstream autoconf-archive patches.
 
 ax_prog_flex: change grep syntax to accept e.g. flex.real in case a wrapper 
 or symlink is used.
 AX_PROG_FLEX: avoid use of grep empty string escape extension (fix for 
 OpenBSD)
 AX_PROG_FLEX: Also accept gflex.
 
 Signed-off-by: Vinson Lee v...@freedesktop.org

Reviewed-by: Jonathan Gray j...@openbsd.org

Future versions of OpenBSD will recognise the extension for the escape
sequences but it is still worth avoiding.  I'm sure there are
other systems that don't do it (NetBSD?).

http://marc.info/?l=openbsd-cvsm=141019114911164w=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.

2015-03-16 Thread Jonathan Gray 
On Mon, Mar 16, 2015 at 08:37:28PM +, Emil Velikov wrote:
 On 26/02/15 13:49, Jose Fonseca wrote:
  On 26/02/15 13:42, Jose Fonseca wrote:
  On 26/02/15 03:55, Jonathan Gray wrote:
  On Wed, Feb 25, 2015 at 07:09:26PM -0800, Matt Turner wrote:
  On Wed, Feb 25, 2015 at 7:03 PM, Jonathan Gray j...@jsg.id.au 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 j...@jsg.id.au 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 matts...@gmail.com
  Date:   Fri Feb 20 18:46:43 2015 -0800
 
   gallium/util: Use HAVE___BUILTIN_* macros.
 
   Reviewed-by: Eric Anholt e...@anholt.net
   Reviewed-by: Jose Fonseca jfons...@vmware.com
 
  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 j...@jsg.id.au
  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 j...@jsg.id.au
  ---
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
 
  Scons does define HAVE___BUILTIN_FFS for mingw.
 
  However `git grep '\ffs\` shows ffs is used directly in many other
  places.  So I suspect this change will break them.
 
#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;
}
 
 
 
  I think the right thing long term is to provide ffs and ffsll in
  c99_compat.h or c99_math.h for all platforms.  And let the rest of the
  code just always assume it's available somehow.
 
 
  Otherwise, let's just '#define ffs __builtin_ffs' on OpenBSD too.
  
  In other words, the original patch on this thread
  
http://lists.freedesktop.org/archives/mesa-dev/2015-February/076071.html
  
  is the only patch I've seen so far that doesn't break Mingw.
  
  If you rather use HAVE___BUILTIN_FFSLL, then just do
  
  diff --git a/src/gallium/auxiliary/util/u_math.h
  b/src/gallium/auxiliary/util/u_math.h
  index 959f76e..d372cfd 100644
  --- a/src/gallium/auxiliary/util/u_math.h
  +++ b/src/gallium/auxiliary/util/u_math.h
  @@ -384,7 +384,7 @@ unsigned ffs( unsigned u )
  
  return i;
   }
  -#elif defined(__MINGW32__) || defined(PIPE_OS_ANDROID)
  +#elif defined(__MINGW32__) || defined(PIPE_OS_ANDROID) ||
  defined(HAVE___BUILTIN_FFSLL)
   #define ffs __builtin_ffs
   #define ffsll __builtin_ffsll
   #endif
  
 Jonathan
 
 Seems like this has ended up a longer discussion that anticipated :\
 Can you please confirm if the above works for you ?
 
 Thanks
 Emil

It looks like that diff was mangled by the mail client and doesn't have
the newline escaped.  It also assumes a ffsll builtin implies a ffs
builtin is present.  So how about the following instead:

diff --git a/src/gallium/auxiliary/util/u_math.h 
b/src/gallium/auxiliary/util/u_math.h
index 8f62cac..89c63d7 100644
--- a/src/gallium/auxiliary/util/u_math.h
+++ b/src/gallium/auxiliary/util/u_math.h
@@ -383,14 +383,28 @@ unsigned ffs( unsigned u )
 
return i;
 }
-#elif defined(__MINGW32__) || defined(PIPE_OS_ANDROID)
+#elif defined(__MINGW32__) || defined(PIPE_OS_ANDROID) || \
+defined(HAVE___BUILTIN_FFS) 
 #define ffs __builtin_ffs
-#define

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

2015-02-22 Thread Jonathan Gray 
The length argument passed to sysctl was the size of the pointer
not the type.  The result of this is sysctl calls would fail on
32 bit BSD/Mac OS X.

Additionally the wrong pointer was passed as an argument to store
the result of the sysctl call.

Cc: 10.4, 10.5 mesa-sta...@lists.freedesktop.org
Signed-off-by: Jonathan Gray j...@jsg.id.au
---
 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()

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

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

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

Grabbing 10.5.0 rc2 it seems python is still required?

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

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

which I thought was fixed...
___
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.

2015-02-25 Thread Jonathan Gray 
On Wed, Feb 25, 2015 at 06:53:14PM -0800, Matt Turner wrote:
 On Wed, Feb 25, 2015 at 5:37 PM, Jonathan Gray j...@jsg.id.au 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 matts...@gmail.com
 Date:   Fri Feb 20 18:46:43 2015 -0800
 
 gallium/util: Use HAVE___BUILTIN_* macros.
 
 Reviewed-by: Eric Anholt e...@anholt.net
 Reviewed-by: Jose Fonseca jfons...@vmware.com
 
 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] auxilary/os: correct sysctl use in os_get_total_physical_memory()

2015-02-25 Thread Jonathan Gray 
On Wed, Feb 25, 2015 at 10:43:39PM +, Emil Velikov wrote:
 On 25 February 2015 at 22:19, Jonathan Gray j...@jsg.id.au 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 j...@jsg.id.au wrote:
   The length argument passed to sysctl was the size of the pointer
   not the type.  The result of this is sysctl calls would fail on
   32 bit BSD/Mac OS X.
  
   Additionally the wrong pointer was passed as an argument to store
   the result of the sysctl call.
  
   Cc: 10.4, 10.5 mesa-sta...@lists.freedesktop.org
   Signed-off-by: Jonathan Gray j...@jsg.id.au
   Seems like my attempt was enough but not quite there yet.
   Thanks for fixing my goof-up.
  
   Reviewed-by: Emil Velikov emil.l.veli...@gmail.com
  
   I'll push this in a couple of days unless there are any objections.
  
   Cheers
   Emil
  
   It should be possible to use the sysconf path in more places
   as well.  Classic swrast for example doesn't use sysctl at all.
  
   OpenBSD/FreeBSD have _SC_PHYS_PAGES/_SC_PAGE_SIZE
   NetBSD/Mac OS X don't document _SC_PAGE_SIZE but do document
   _SC_PAGESIZE, though I wouldn't be surprised if they
   had _SC_PAGE_SIZE in their headers.
  
  If you feel like unifying some code that would be appreciated.
 
  Although, I have a greater request from you - can you look at removing
  the symlinks in src/mesa/drivers/dri/r{adeon,200} ?  Pretty please :-)
 
  Restructuring the common bits into one place (radeon_common perhaps ?)
  will allow one to drop the links, and this will also cut down a fair
  hunk of the classic dri module binary.
 
  Btw did you have the chance to try 10.5 with a simple wrapper, similar
  to xorg-server ? I believe that most concerns should be sorted out now -
  no python, lex, etc... dependency.
 
  I have not tracked down the reason but Mesa 10.4.3 (and 10.3.7) caused
  problems with gpu compositing on chrome resulting in a black window
  on older Intel (ie 945gm) and discrete radeons (ie evergreen) but
  not newer Intel hardware like ivy bridge.
 
  As we're busy finishing off a release at the moment I've reverted
  everything to 10.2.9.
 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.

2015-02-25 Thread Jonathan Gray 
On Wed, Feb 25, 2015 at 07:09:26PM -0800, Matt Turner wrote:
 On Wed, Feb 25, 2015 at 7:03 PM, Jonathan Gray j...@jsg.id.au 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 j...@jsg.id.au 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 matts...@gmail.com
  Date:   Fri Feb 20 18:46:43 2015 -0800
 
  gallium/util: Use HAVE___BUILTIN_* macros.
 
  Reviewed-by: Eric Anholt e...@anholt.net
  Reviewed-by: Jose Fonseca jfons...@vmware.com
 
  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 j...@jsg.id.au
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 j...@jsg.id.au
---
 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] gallium/util: Define ffsll on OpenBSD.

2015-02-25 Thread Jonathan Gray 
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 j...@jsg.id.au 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 j...@jsg.id.au
 ---
   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()

2015-02-24 Thread Jonathan Gray 
On Tue, Feb 24, 2015 at 04:53:03PM +, Emil Velikov wrote:
 On 22 February 2015 at 08:19, Jonathan Gray j...@jsg.id.au wrote:
  The length argument passed to sysctl was the size of the pointer
  not the type.  The result of this is sysctl calls would fail on
  32 bit BSD/Mac OS X.
 
  Additionally the wrong pointer was passed as an argument to store
  the result of the sysctl call.
 
  Cc: 10.4, 10.5 mesa-sta...@lists.freedesktop.org
  Signed-off-by: Jonathan Gray j...@jsg.id.au
 Seems like my attempt was enough but not quite there yet.
 Thanks for fixing my goof-up.
 
 Reviewed-by: Emil Velikov emil.l.veli...@gmail.com
 
 I'll push this in a couple of days unless there are any objections.
 
 Cheers
 Emil

It should be possible to use the sysconf path in more places
as well.  Classic swrast for example doesn't use sysctl at all.

OpenBSD/FreeBSD have _SC_PHYS_PAGES/_SC_PAGE_SIZE
NetBSD/Mac OS X don't document _SC_PAGE_SIZE but do document
_SC_PAGESIZE, though I wouldn't be surprised if they
had _SC_PAGE_SIZE in their headers.
___
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

2015-07-18 Thread Jonathan Gray 
$(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 j...@jsg.id.au
---
 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.am
index

[Mesa-dev] [PATCH] mesa: include stdarg.h for va_list

2015-07-15 Thread Jonathan Gray 
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 j...@jsg.id.au
---
 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 stdio.h
+#include stdarg.h
 #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

Re: [Mesa-dev] [Mesa-stable] [PATCH v2] configure.ac: ensure RM is set

2015-10-13 Thread Jonathan Gray 
On Tue, Oct 13, 2015 at 11:25:08AM +0100, Emil Velikov wrote:
> On 10 October 2015 at 07:42, Jonathan Gray <j...@jsg.id.au> 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.l.veli...@gmail.com>
> 
> -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

[Mesa-dev] [PATCH v2] configure.ac: ensure RM is set

2015-10-10 Thread Jonathan Gray 
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

Signed-off-by: Jonathan Gray <j...@jsg.id.au>
CC: "10.6 11.0" <mesa-sta...@lists.freedesktop.org>
---
 configure.ac | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configure.ac b/configure.ac
index 3feec19..f99545f 100644
--- a/configure.ac
+++ b/configure.ac
@@ -107,6 +107,8 @@ AC_SYS_LARGEFILE
 LT_PREREQ([2.2])
 LT_INIT([disable-static])
 
+AC_CHECK_PROG(RM, rm, [rm -f])
+
 AX_PROG_BISON([],
   AS_IF([test ! -f "$srcdir/src/glsl/glcpp/glcpp-parse.c"],
 [AC_MSG_ERROR([bison not found - unable to compile 
glcpp-parse.y])]))
-- 
2.5.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] configure.ac: ensure RM is set

2015-10-09 Thread Jonathan Gray 
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.

Signed-off-by: Jonathan Gray <j...@jsg.id.au>
CC: "10.6 11.0" <mesa-sta...@lists.freedesktop.org>
---
 configure.ac | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/configure.ac b/configure.ac
index e032d77..9ba25a2 100644
--- a/configure.ac
+++ b/configure.ac
@@ -106,6 +106,9 @@ AC_SYS_LARGEFILE
 LT_PREREQ([2.2])
 LT_INIT([disable-static])
 
+RM?=rm -f
+AC_SUBST([RM])
+
 AX_PROG_BISON([],
   AS_IF([test ! -f "$srcdir/src/glsl/glcpp/glcpp-parse.c"],
 [AC_MSG_ERROR([bison not found - unable to compile 
glcpp-parse.y])]))
-- 
2.5.3

___
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

2015-08-30 Thread Jonathan Gray 
On Sun, Aug 30, 2015 at 01:38:49AM -0400, Ilia Mirkin wrote:
 On Sun, Aug 30, 2015 at 1:27 AM, Jonathan Gray j...@jsg.id.au wrote:
  On Fri, Aug 28, 2015 at 10:47:44AM +1000, Dave Airlie wrote:
  From: Dave Airlie airl...@redhat.com
 
  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 mesa-sta...@lists.freedesktop.org
  Signed-off-by: Dave Airlie airl...@redhat.com
  ---
   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
 
 We definitely do this sort of thing elsewhere... does it work if you do
 
 static const int prim_conv[PIPE_PRIM_MAX+1] = { ... }

Same error with that change.

clang++ with -pedantic warns about designated initialisers being a C99 
extension.

The following

Re: [Mesa-dev] [PATCH] r600: port si_conv_prim_to_gs_out from radeonsi

2015-08-29 Thread Jonathan Gray 
On Fri, Aug 28, 2015 at 10:47:44AM +1000, Dave Airlie wrote:
 From: Dave Airlie airl...@redhat.com
 
 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 mesa-sta...@lists.freedesktop.org
 Signed-off-by: Dave Airlie airl...@redhat.com
 ---
  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 3/3] nir: rename nir_lower_samplers.c{pp,}

2015-09-19 Thread Jonathan Gray 
On Fri, Sep 18, 2015 at 10:52:35AM -0700, Jason Ekstrand wrote:
> On Sep 18, 2015 12:40 PM, "Emil Velikov"  wrote:
> >
> > Thanks for the review/testing guys.
> >
> > Just noticed that some typos/strange wording
> >
> > On 17 September 2015 at 16:25, Emil Velikov 
> wrote:
> > > With the only C++ function having it's own wrapper we can 'demote' this
> > s/it's/its/
> >
> > > file to a normal C one. This allows us to get rid of extern C {
> > > support C99 designated initializers in CPP code.
> > >
> > This allows us to get rid of extern C { #include  } 'hacks'.
> > Plus some of the headers may use C99 initializers, which are not
> > supported by the ISO standard.
> 
> What headers are those?  All NIR headers should be C++ safe.

As mentioned in another thread already, nir_builder.h

In file included from nir/nir_lower_samplers.cpp:27:
nir/nir_builder.h: In function 'nir_ssa_def* nir_imm_float(nir_builder*, 
float)':
nir/nir_builder.h:79: error: expected primary-expression before '.' token
nir/nir_builder.h:79: error: expected primary-expression before '{' token
nir/nir_builder.h:79: error: expected `}' before '{' token
nir/nir_builder.h:79: error: expected `}' before '{' token
nir/nir_builder.h:79: warning: missing braces around initializer for 'float [4]'
nir/nir_builder.h:79: error: expected ',' or ';' before '{' token
nir/nir_builder.h:79: warning: unused variable 'v'
nir/nir_builder.h:79: warning: no return statement in function returning 
non-void
nir/nir_builder.h: At global scope:
nir/nir_builder.h:79: error: expected declaration before '}' token
Makefile:1447: recipe for target 'nir/nir_lower_samplers.lo' failed
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [Mesa-stable] [PATCH] configure.ac: use pkg-config for libelf

2015-12-05 Thread Jonathan Gray 
On Tue, Dec 01, 2015 at 04:56:54PM +, Emil Velikov wrote:
> Hi Jonathan,
> 
> On 23 November 2015 at 03:24, Jonathan Gray <j...@jsg.id.au> wrote:
> > Use PKG_CHECK_MODULES to get the flags to link libelf.
> >
> > Signed-off-by: Jonathan Gray <j...@jsg.id.au>
> > Cc: "11.0 11.1" <mesa-sta...@lists.freedesktop.org>
> > ---
> >  configure.ac   | 4 +---
> >  src/gallium/drivers/radeon/Makefile.am | 2 +-
> >  src/gallium/targets/opencl/Makefile.am | 2 +-
> >  3 files changed, 3 insertions(+), 5 deletions(-)
> >
> > diff --git a/configure.ac b/configure.ac
> > index 72a2ec1..afee3ed 100644
> > --- a/configure.ac
> > +++ b/configure.ac
> > @@ -1712,7 +1712,7 @@ AC_ARG_WITH([clang-libdir],
> > [CLANG_LIBDIR=''])
> >
> >  PKG_CHECK_EXISTS([libclc], [have_libclc=yes], [have_libclc=no])
> > -AC_CHECK_LIB([elf], [elf_memory], [have_libelf=yes;ELF_LIB=-lelf])
> > +PKG_CHECK_MODULES([LIBELF], [libelf], [have_libelf=yes], [have_libelf=no])
> >
> As suggested can you rework the patch to have the pkg check + the
> original check_lib as a fall-back.
> While you're doing this can we also make use of the _CFLAGS in
> src/gallium/drivers/radeon/ and src/gallium/state_trackers/clover/ ?
> 
> Thanks
> Emil

Can someone with a libelf provided by elfutils try this?

diff --git a/configure.ac b/configure.ac
index 71109e2..0374142 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1729,7 +1729,15 @@ AC_ARG_WITH([clang-libdir],
[CLANG_LIBDIR=''])
 
 PKG_CHECK_EXISTS([libclc], [have_libclc=yes], [have_libclc=no])
-AC_CHECK_LIB([elf], [elf_memory], [have_libelf=yes;ELF_LIB=-lelf])
+PKG_CHECK_MODULES([LIBELF], [libelf], [have_libelf=yes], [have_libelf=no])
+
+if test "x$have_libelf" = xno; then
+   LIBELF_LIBS=''
+   LIBELF_CFLAGS=''
+   AC_CHECK_LIB([elf], [elf_memory], [have_libelf=yes;LIBELF_LIBS=-lelf], 
[have_libelf=no])
+   AC_SUBST([LIBELF_LIBS])
+   AC_SUBST([LIBELF_CFLAGS])
+fi
 
 if test "x$enable_opencl" = xyes; then
 if test -z "$with_gallium_drivers"; then
@@ -2310,8 +2318,6 @@ if test "x$USE_VC4_SIMULATOR" = xyes -a 
"x$HAVE_GALLIUM_ILO" = xyes; then
 AC_MSG_ERROR([VC4 simulator on x86 replaces i965 driver build, so ilo must 
be disabled.])
 fi
 
-AC_SUBST([ELF_LIB])
-
 AM_CONDITIONAL(HAVE_LIBDRM, test "x$have_libdrm" = xyes)
 AM_CONDITIONAL(HAVE_X11_DRIVER, test "x$enable_xlib_glx" = xyes)
 AM_CONDITIONAL(HAVE_OSMESA, test "x$enable_osmesa" = xyes)
diff --git a/src/gallium/drivers/radeon/Makefile.am 
b/src/gallium/drivers/radeon/Makefile.am
index 13d8976..a6fc145 100644
--- a/src/gallium/drivers/radeon/Makefile.am
+++ b/src/gallium/drivers/radeon/Makefile.am
@@ -16,7 +16,8 @@ libradeon_la_SOURCES = \
 if NEED_RADEON_LLVM
 
 AM_CFLAGS += \
-   $(LLVM_CFLAGS)
+   $(LLVM_CFLAGS) \
+   $(LIBELF_CFLAGS)
 
 libradeon_la_SOURCES += \
$(LLVM_C_FILES)
@@ -24,7 +25,7 @@ libradeon_la_SOURCES += \
 libradeon_la_LIBADD = \
$(CLOCK_LIB) \
$(LLVM_LIBS) \
-   $(ELF_LIB)
+   $(LIBELF_LIBS)
 
 libradeon_la_LDFLAGS = \
$(LLVM_LDFLAGS)
diff --git a/src/gallium/targets/opencl/Makefile.am 
b/src/gallium/targets/opencl/Makefile.am
index 08f95e8..f3ba1e3 100644
--- a/src/gallium/targets/opencl/Makefile.am
+++ b/src/gallium/targets/opencl/Makefile.am
@@ -2,6 +2,9 @@ include $(top_srcdir)/src/gallium/Automake.inc
 
 lib_LTLIBRARIES = lib@OPENCL_LIBNAME@.la
 
+AM_CPPFLAGS = \
+$(LIBELF_CFLAGS)
+
 lib@OPENCL_LIBNAME@_la_LDFLAGS = \
$(LLVM_LDFLAGS) \
-no-undefined \
@@ -19,7 +22,7 @@ lib@OPENCL_LIBNAME@_la_LIBADD = \
$(top_builddir)/src/gallium/state_trackers/clover/libclover.la \
$(top_builddir)/src/gallium/auxiliary/libgallium.la \
$(top_builddir)/src/util/libmesautil.la \
-   $(ELF_LIB) \
+   $(LIBELF_LIBS) \
$(DLOPEN_LIBS) \
-lclangCodeGen \
-lclangFrontendTool \
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] configure: check for python2.7 for PYTHON2

2015-12-05 Thread Jonathan Gray 
Check for a 'python2.7' binary, 'python' and 'python2' are not
provided by the OpenBSD python 2.7.x packages.

Signed-off-by: Jonathan Gray <j...@jsg.id.au>
Cc: "11.0 11.1" <mesa-sta...@lists.freedesktop.org>
---
 configure.ac | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index 569ebf1..71109e2 100644
--- a/configure.ac
+++ b/configure.ac
@@ -98,7 +98,7 @@ AC_PROG_CXX
 AM_PROG_CC_C_O
 AM_PROG_AS
 AX_CHECK_GNU_MAKE
-AC_CHECK_PROGS([PYTHON2], [python2 python])
+AC_CHECK_PROGS([PYTHON2], [python2.7 python2 python])
 AC_PROG_SED
 AC_PROG_MKDIR_P
 
-- 
2.6.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] configure.ac: fix test for SSE4.1 assembler support

2015-12-08 Thread Jonathan Gray 
Change the __m128i variables to be volatile so gcc 4.9 won't optimise
all of them out with -O1 or greater.  The _mm_set1_epi32/pinsrd calls
still get optimised out but now there is at least one SSE4.1 instruction
generated via _mm_max_epu32/pmaxud.  When all of the sse4.1 instructions
got optimised out the configure test would incorrectly pass when the
compiler supported the intrinsics and the assembler didn't support the
instructions.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91806
Signed-off-by: Jonathan Gray <j...@jsg.id.au>
Cc: "11.0 11.1" <mesa-sta...@lists.freedesktop.org>
---
 configure.ac | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index 260934d..1d82e47 100644
--- a/configure.ac
+++ b/configure.ac
@@ -384,7 +384,7 @@ CFLAGS="$SSE41_CFLAGS $CFLAGS"
 AC_COMPILE_IFELSE([AC_LANG_SOURCE([[
 #include 
 int main () {
-__m128i a = _mm_set1_epi32 (0), b = _mm_set1_epi32 (0), c;
+volatile __m128i a = _mm_set1_epi32 (0), b = _mm_set1_epi32 (0), c;
 c = _mm_max_epu32(a, b);
 return 0;
 }]])], SSE41_SUPPORTED=1)
-- 
2.6.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v2] configure.ac: use pkg-config for libelf

2015-12-08 Thread Jonathan Gray 
Use PKG_CHECK_MODULES to get the flags to link libelf

v2: keep AC_CHECK_LIB as a fallback for elfutils provided
libelf that doesn't install a pkg-config file.

Signed-off-by: Jonathan Gray <j...@jsg.id.au>
Reviewed-by: Michel D�nzer <michel.daen...@amd.com>
Tested-by: Michel D�nzer <michel.daen...@amd.com>
Cc: "11.0 11.1" <mesa-sta...@lists.freedesktop.org>
---
 configure.ac   | 12 +---
 src/gallium/drivers/radeon/Makefile.am |  5 +++--
 src/gallium/targets/opencl/Makefile.am |  5 -
 3 files changed, 16 insertions(+), 6 deletions(-)

diff --git a/configure.ac b/configure.ac
index 25fdc39..260934d 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1724,7 +1724,15 @@ AC_ARG_WITH([clang-libdir],
[CLANG_LIBDIR=''])
 
 PKG_CHECK_EXISTS([libclc], [have_libclc=yes], [have_libclc=no])
-AC_CHECK_LIB([elf], [elf_memory], [have_libelf=yes;ELF_LIB=-lelf])
+PKG_CHECK_MODULES([LIBELF], [libelf], [have_libelf=yes], [have_libelf=no])
+
+if test "x$have_libelf" = xno; then
+   LIBELF_LIBS=''
+   LIBELF_CFLAGS=''
+   AC_CHECK_LIB([elf], [elf_memory], [have_libelf=yes;LIBELF_LIBS=-lelf], 
[have_libelf=no])
+   AC_SUBST([LIBELF_LIBS])
+   AC_SUBST([LIBELF_CFLAGS])
+fi
 
 if test "x$enable_opencl" = xyes; then
 if test -z "$with_gallium_drivers"; then
@@ -2305,8 +2313,6 @@ if test "x$USE_VC4_SIMULATOR" = xyes -a 
"x$HAVE_GALLIUM_ILO" = xyes; then
 AC_MSG_ERROR([VC4 simulator on x86 replaces i965 driver build, so ilo must 
be disabled.])
 fi
 
-AC_SUBST([ELF_LIB])
-
 AM_CONDITIONAL(HAVE_LIBDRM, test "x$have_libdrm" = xyes)
 AM_CONDITIONAL(HAVE_X11_DRIVER, test "x$enable_xlib_glx" = xyes)
 AM_CONDITIONAL(HAVE_OSMESA, test "x$enable_osmesa" = xyes)
diff --git a/src/gallium/drivers/radeon/Makefile.am 
b/src/gallium/drivers/radeon/Makefile.am
index 13d8976..a6fc145 100644
--- a/src/gallium/drivers/radeon/Makefile.am
+++ b/src/gallium/drivers/radeon/Makefile.am
@@ -16,7 +16,8 @@ libradeon_la_SOURCES = \
 if NEED_RADEON_LLVM
 
 AM_CFLAGS += \
-   $(LLVM_CFLAGS)
+   $(LLVM_CFLAGS) \
+   $(LIBELF_CFLAGS)
 
 libradeon_la_SOURCES += \
$(LLVM_C_FILES)
@@ -24,7 +25,7 @@ libradeon_la_SOURCES += \
 libradeon_la_LIBADD = \
$(CLOCK_LIB) \
$(LLVM_LIBS) \
-   $(ELF_LIB)
+   $(LIBELF_LIBS)
 
 libradeon_la_LDFLAGS = \
$(LLVM_LDFLAGS)
diff --git a/src/gallium/targets/opencl/Makefile.am 
b/src/gallium/targets/opencl/Makefile.am
index 08f95e8..f3ba1e3 100644
--- a/src/gallium/targets/opencl/Makefile.am
+++ b/src/gallium/targets/opencl/Makefile.am
@@ -2,6 +2,9 @@ include $(top_srcdir)/src/gallium/Automake.inc
 
 lib_LTLIBRARIES = lib@OPENCL_LIBNAME@.la
 
+AM_CPPFLAGS = \
+$(LIBELF_CFLAGS)
+
 lib@OPENCL_LIBNAME@_la_LDFLAGS = \
$(LLVM_LDFLAGS) \
-no-undefined \
@@ -19,7 +22,7 @@ lib@OPENCL_LIBNAME@_la_LIBADD = \
$(top_builddir)/src/gallium/state_trackers/clover/libclover.la \
$(top_builddir)/src/gallium/auxiliary/libgallium.la \
$(top_builddir)/src/util/libmesautil.la \
-   $(ELF_LIB) \
+   $(LIBELF_LIBS) \
$(DLOPEN_LIBS) \
-lclangCodeGen \
-lclangFrontendTool \
-- 
2.6.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [Mesa-stable] [PATCH] configure.ac: fix test for SSE4.1 assembler support

2015-12-09 Thread Jonathan Gray 
On Wed, Dec 09, 2015 at 01:39:30PM +0200, Oded Gabbay wrote:
> On Wed, Dec 9, 2015 at 1:09 PM, Emil Velikov <emil.l.veli...@gmail.com> wrote:
> > On 9 December 2015 at 05:37, Jonathan Gray <j...@jsg.id.au> wrote:
> >> Change the __m128i variables to be volatile so gcc 4.9 won't optimise
> >> all of them out with -O1 or greater.  The _mm_set1_epi32/pinsrd calls
> >> still get optimised out but now there is at least one SSE4.1 instruction
> >> generated via _mm_max_epu32/pmaxud.  When all of the sse4.1 instructions
> >> got optimised out the configure test would incorrectly pass when the
> >> compiler supported the intrinsics and the assembler didn't support the
> >> instructions.
> >>
> > Must admit that I was not expecting that one. Looks like pixman (the
> > inspiration for this check) is missing volatile as well. Does that one
> > build/run fine on OpenBSD ?
> >
> >> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91806
> >> Signed-off-by: Jonathan Gray <j...@jsg.id.au>
> >> Cc: "11.0 11.1" <mesa-sta...@lists.freedesktop.org>
> > Reviewed-by: Emil Velikov <emil.veli...@collabora.com>
> >
> > I'll pick this in a couple of days (barring any objections).
> >
> > Thanks
> > Emil
> 
> Adding pixman ML.
> I must admit ignorance on this one.
> I looked at configure.ac of pixman and I don't see any SSE4.1
> reference, and AFAIK, we don't use those instructions (only SSE2 and
> SSSE3).
> Is the above patch relevant for those as well ? because the tests in
> configure.ac does *not* contain volatile.
> 
> Oded

It looks like this is indeed a problem in pixman as well with at least
gcc 4.2 and 4.9.  Running the pixman sse2 test on amd64 I only
see xmm register use and movdqa in the generated assembly with -O0.

The pixman configure tests passes on OpenBSD but the toolchain
recognises sse2 instructions just not sse 4.1.

Introducing volatile to the pixman test stops the xmm/movdqa
use from being optimised out.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [Mesa-stable] [PATCH] configure.ac: fix test for SSE4.1 assembler support

2015-12-13 Thread Jonathan Gray 
On Sat, Dec 12, 2015 at 06:41:56PM +, Emil Velikov wrote:
> On 10 December 2015 at 08:42, Oded Gabbay <oded.gab...@gmail.com> wrote:
> > On Wed, Dec 9, 2015 at 8:30 PM, Matt Turner <matts...@gmail.com> wrote:
> >> On Tue, Dec 8, 2015 at 9:37 PM, Jonathan Gray <j...@jsg.id.au> wrote:
> >>> Change the __m128i variables to be volatile so gcc 4.9 won't optimise
> >>> all of them out with -O1 or greater.  The _mm_set1_epi32/pinsrd calls
> >>> still get optimised out but now there is at least one SSE4.1 instruction
> >>> generated via _mm_max_epu32/pmaxud.  When all of the sse4.1 instructions
> >>> got optimised out the configure test would incorrectly pass when the
> >>> compiler supported the intrinsics and the assembler didn't support the
> >>> instructions.
> >>>
> >>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91806
> >>> Signed-off-by: Jonathan Gray <j...@jsg.id.au>
> >>> Cc: "11.0 11.1" <mesa-sta...@lists.freedesktop.org>
> >>> ---
> >>>  configure.ac | 2 +-
> >>>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/configure.ac b/configure.ac
> >>> index 260934d..1d82e47 100644
> >>> --- a/configure.ac
> >>> +++ b/configure.ac
> >>> @@ -384,7 +384,7 @@ CFLAGS="$SSE41_CFLAGS $CFLAGS"
> >>>  AC_COMPILE_IFELSE([AC_LANG_SOURCE([[
> >>>  #include 
> >>>  int main () {
> >>> -__m128i a = _mm_set1_epi32 (0), b = _mm_set1_epi32 (0), c;
> >>> +volatile __m128i a = _mm_set1_epi32 (0), b = _mm_set1_epi32 (0), c;
> >>>  c = _mm_max_epu32(a, b);
> >>>  return 0;
> >>
> >> I would have extracted an int from the result of _mm_max_epu32 and
> >> returned that instead of 0.
> >
> > Instead of the volatile I assume ?
> >
> Precisely. If anyone wants to follow on Matt's suggestion we can pick
> that one as well. I'd like to get a patch for the next stable releases
> (next Friday for 11.0.x and just after new year for 11.1.1) so I'll
> take whatever's around :-)
> 
> -Emil

I avoided that as I wasn't sure if there was a case where autoconf
cared about the return code.  If someone wants to create a new diff
feel free, I have limited connectivity till the middle of next week.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] loader: add a libdrm case for loader_get_device_name_for_fd

2015-12-20 Thread Jonathan Gray 
Use dev_node_from_fd() with HAVE_LIBDRM to provide an implmentation
of loader_get_device_name_for_fd() for non-linux systems that
use libdrm but don't have udev or sysfs.

Signed-off-by: Jonathan Gray <j...@jsg.id.au>
---
 src/loader/loader.c | 26 +-
 1 file changed, 25 insertions(+), 1 deletion(-)

diff --git a/src/loader/loader.c b/src/loader/loader.c
index 8634f45..522fba3 100644
--- a/src/loader/loader.c
+++ b/src/loader/loader.c
@@ -445,7 +445,7 @@ int loader_get_user_preferred_fd(int default_fd, int 
*different_device)
 }
 #endif
 
-#if defined(HAVE_SYSFS)
+#if defined(HAVE_SYSFS) || defined(HAVE_LIBDRM)
 static int
 dev_node_from_fd(int fd, unsigned int *maj, unsigned int *min)
 {
@@ -466,7 +466,9 @@ dev_node_from_fd(int fd, unsigned int *maj, unsigned int 
*min)
 
return 0;
 }
+#endif
 
+#if defined(HAVE_SYSFS)
 static int
 sysfs_get_pci_id_for_fd(int fd, int *vendor_id, int *chip_id)
 {
@@ -671,6 +673,24 @@ sysfs_get_device_name_for_fd(int fd)
 }
 #endif
 
+#if defined(HAVE_LIBDRM)
+static char *
+drm_get_device_name_for_fd(int fd)
+{
+   unsigned int maj, min;
+   char buf[0x40];
+   int n;
+
+   if (dev_node_from_fd(fd, , ) < 0)
+  return NULL;
+
+   n = snprintf(buf, sizeof(buf), DRM_DEV_NAME, DRM_DIR_NAME, min);
+   if (n == -1 || n >= sizeof(buf))
+  return NULL;
+
+   return strdup(buf);
+}
+#endif
 
 char *
 loader_get_device_name_for_fd(int fd)
@@ -685,6 +705,10 @@ loader_get_device_name_for_fd(int fd)
if ((result = sysfs_get_device_name_for_fd(fd)))
   return result;
 #endif
+#if HAVE_LIBDRM
+   if ((result = drm_get_device_name_for_fd(fd)))
+  return result;
+#endif
return result;
 }
 
-- 
2.6.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] configure.ac: use pkg-config for libelf

2015-11-22 Thread Jonathan Gray 
Use PKG_CHECK_MODULES to get the flags to link libelf.

Signed-off-by: Jonathan Gray <j...@jsg.id.au>
Cc: "11.0 11.1" <mesa-sta...@lists.freedesktop.org>
---
 configure.ac   | 4 +---
 src/gallium/drivers/radeon/Makefile.am | 2 +-
 src/gallium/targets/opencl/Makefile.am | 2 +-
 3 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/configure.ac b/configure.ac
index 72a2ec1..afee3ed 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1712,7 +1712,7 @@ AC_ARG_WITH([clang-libdir],
[CLANG_LIBDIR=''])
 
 PKG_CHECK_EXISTS([libclc], [have_libclc=yes], [have_libclc=no])
-AC_CHECK_LIB([elf], [elf_memory], [have_libelf=yes;ELF_LIB=-lelf])
+PKG_CHECK_MODULES([LIBELF], [libelf], [have_libelf=yes], [have_libelf=no])
 
 if test "x$enable_opencl" = xyes; then
 if test -z "$with_gallium_drivers"; then
@@ -2293,8 +2293,6 @@ if test "x$USE_VC4_SIMULATOR" = xyes -a 
"x$HAVE_GALLIUM_ILO" = xyes; then
 AC_MSG_ERROR([VC4 simulator on x86 replaces i965 driver build, so ilo must 
be disabled.])
 fi
 
-AC_SUBST([ELF_LIB])
-
 AM_CONDITIONAL(HAVE_LIBDRM, test "x$have_libdrm" = xyes)
 AM_CONDITIONAL(HAVE_X11_DRIVER, test "x$enable_xlib_glx" = xyes)
 AM_CONDITIONAL(HAVE_OSMESA, test "x$enable_osmesa" = xyes)
diff --git a/src/gallium/drivers/radeon/Makefile.am 
b/src/gallium/drivers/radeon/Makefile.am
index 13d8976..fa2b5a6 100644
--- a/src/gallium/drivers/radeon/Makefile.am
+++ b/src/gallium/drivers/radeon/Makefile.am
@@ -24,7 +24,7 @@ libradeon_la_SOURCES += \
 libradeon_la_LIBADD = \
$(CLOCK_LIB) \
$(LLVM_LIBS) \
-   $(ELF_LIB)
+   $(LIBELF_LIBS)
 
 libradeon_la_LDFLAGS = \
$(LLVM_LDFLAGS)
diff --git a/src/gallium/targets/opencl/Makefile.am 
b/src/gallium/targets/opencl/Makefile.am
index 08f95e8..99532f0 100644
--- a/src/gallium/targets/opencl/Makefile.am
+++ b/src/gallium/targets/opencl/Makefile.am
@@ -19,7 +19,7 @@ lib@OPENCL_LIBNAME@_la_LIBADD = \
$(top_builddir)/src/gallium/state_trackers/clover/libclover.la \
$(top_builddir)/src/gallium/auxiliary/libgallium.la \
$(top_builddir)/src/util/libmesautil.la \
-   $(ELF_LIB) \
+   $(LIBELF_LIBS) \
$(DLOPEN_LIBS) \
-lclangCodeGen \
-lclangFrontendTool \
-- 
2.6.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] configure.ac: use pkg-config for libelf

2015-11-22 Thread Jonathan Gray 
On Mon, Nov 23, 2015 at 02:24:45PM +1100, Jonathan Gray wrote:
> Use PKG_CHECK_MODULES to get the flags to link libelf.

This should also include the part that uses cflags

If there is any interest in it going in I'll post another diff with this
included:

diff --git a/src/gallium/drivers/radeon/Makefile.am 
b/src/gallium/drivers/radeon/Makefile.am
index fa2b5a6..a6fc145 100644
--- a/src/gallium/drivers/radeon/Makefile.am
+++ b/src/gallium/drivers/radeon/Makefile.am
@@ -16,7 +16,8 @@ libradeon_la_SOURCES = \
 if NEED_RADEON_LLVM
 
 AM_CFLAGS += \
-   $(LLVM_CFLAGS)
+   $(LLVM_CFLAGS) \
+   $(LIBELF_CFLAGS)
 
 libradeon_la_SOURCES += \
$(LLVM_C_FILES)
diff --git a/src/gallium/targets/opencl/Makefile.am 
b/src/gallium/targets/opencl/Makefile.am
index 99532f0..f3ba1e3 100644
--- a/src/gallium/targets/opencl/Makefile.am
+++ b/src/gallium/targets/opencl/Makefile.am
@@ -2,6 +2,9 @@ include $(top_srcdir)/src/gallium/Automake.inc
 
 lib_LTLIBRARIES = lib@OPENCL_LIBNAME@.la
 
+AM_CPPFLAGS = \
+$(LIBELF_CFLAGS)
+
 lib@OPENCL_LIBNAME@_la_LDFLAGS = \
$(LLVM_LDFLAGS) \
-no-undefined \
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

  1   2   3   >