Re: [Mesa-dev] [PATCH 07.1/20] targets/vdpau: use install-gallium-links.mk

[Christian König]

Am 08.03.2014 21:30, schrieb Emil Velikov:

Drop the duplication across all vdpau targets.

Signed-off-by: Emil Velikov 


Reviewed-by: Christian König 


---
  src/gallium/targets/r600/vdpau/Makefile.am | 6 +-
  src/gallium/targets/radeonsi/vdpau/Makefile.am | 6 +-
  src/gallium/targets/vdpau-nouveau/Makefile.am  | 6 +-
  3 files changed, 3 insertions(+), 15 deletions(-)

diff --git a/src/gallium/targets/r600/vdpau/Makefile.am 
b/src/gallium/targets/r600/vdpau/Makefile.am
index 509b954..b760afb 100644
--- a/src/gallium/targets/r600/vdpau/Makefile.am
+++ b/src/gallium/targets/r600/vdpau/Makefile.am
@@ -52,8 +52,4 @@ libvdpau_r600_la_LDFLAGS += $(LLVM_LDFLAGS)
  libvdpau_r600_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: libvdpau_r600.la
-   $(MKDIR_P) $(top_builddir)/$(LIB_DIR)/gallium
-   ln -f .libs/libvdpau_r600.so* $(top_builddir)/$(LIB_DIR)/gallium/
+include $(top_srcdir)/install-gallium-links.mk
diff --git a/src/gallium/targets/radeonsi/vdpau/Makefile.am 
b/src/gallium/targets/radeonsi/vdpau/Makefile.am
index 54d65b3..adad4c6 100644
--- a/src/gallium/targets/radeonsi/vdpau/Makefile.am
+++ b/src/gallium/targets/radeonsi/vdpau/Makefile.am
@@ -49,8 +49,4 @@ libvdpau_radeonsi_la_LDFLAGS += $(LLVM_LDFLAGS)
  libvdpau_radeonsi_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: libvdpau_radeonsi.la
-   $(MKDIR_P) $(top_builddir)/$(LIB_DIR)/gallium
-   ln -f .libs/libvdpau_radeonsi.so* $(top_builddir)/$(LIB_DIR)/gallium/
+include $(top_srcdir)/install-gallium-links.mk
diff --git a/src/gallium/targets/vdpau-nouveau/Makefile.am 
b/src/gallium/targets/vdpau-nouveau/Makefile.am
index 3cdf103..16af16a 100644
--- a/src/gallium/targets/vdpau-nouveau/Makefile.am
+++ b/src/gallium/targets/vdpau-nouveau/Makefile.am
@@ -49,8 +49,4 @@ libvdpau_nouveau_la_LDFLAGS += $(LLVM_LDFLAGS)
  libvdpau_nouveau_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: libvdpau_nouveau.la
-   $(MKDIR_P) $(top_builddir)/$(LIB_DIR)/gallium
-   ln -f .libs/libvdpau_nouveau.so* $(top_builddir)/$(LIB_DIR)/gallium/
+include $(top_srcdir)/install-gallium-links.mk


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

Re: [Mesa-dev] [PATCHv2 09/20] gallium/targets: drop link generation for non DRI targets

[Christian König]

Am 08.03.2014 21:31, schrieb Emil Velikov:

All three (xvmc and omx) do not have an alternative loading
similar to the dri modules. Thus one needs to explicitly install
them in order to use/test them.


Double checking that (again) there actually there is a 
BELLAGIO_SEARCH_PATH environment variable for omx components. I just 
haven't used it before. On the other hand adding that option back is now 
trivial if anybody needs it.


Christian.



v2:
  - Keep vdpau targets, as an equivalent of LIBGL_DRIVERS_PATH
is being worked on.

Signed-off-by: Emil Velikov 
Reviewed-by: Jon TURNEY 
---
  src/gallium/targets/r600/omx/Makefile.am | 6 --
  src/gallium/targets/r600/xvmc/Makefile.am| 6 --
  src/gallium/targets/radeonsi/omx/Makefile.am | 6 --
  src/gallium/targets/xvmc-nouveau/Makefile.am | 6 --
  4 files changed, 24 deletions(-)

diff --git a/src/gallium/targets/r600/omx/Makefile.am 
b/src/gallium/targets/r600/omx/Makefile.am
index 3aef9e1..98b064f 100644
--- a/src/gallium/targets/r600/omx/Makefile.am
+++ b/src/gallium/targets/r600/omx/Makefile.am
@@ -70,9 +70,3 @@ libomx_r600_la_LINK = $(LINK) $(libomx_r600_la_LDFLAGS)
  # Mention a dummy pure C file to trigger generation of the $(LINK) variable
  nodist_EXTRA_libomx_r600_la_SOURCES = dummy-c.c
  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: libomx_r600.la
-   $(MKDIR_P) $(top_builddir)/$(LIB_DIR)/gallium
-   ln -f .libs/libomx_r600.so* $(top_builddir)/$(LIB_DIR)/gallium/
diff --git a/src/gallium/targets/r600/xvmc/Makefile.am 
b/src/gallium/targets/r600/xvmc/Makefile.am
index 7fe9b1a..6e71ffa 100644
--- a/src/gallium/targets/r600/xvmc/Makefile.am
+++ b/src/gallium/targets/r600/xvmc/Makefile.am
@@ -54,9 +54,3 @@ libXvMCr600_la_LINK = $(LINK) $(libXvMCr600_la_LDFLAGS)
  # Mention a dummy pure C file to trigger generation of the $(LINK) variable
  nodist_EXTRA_libXvMCr600_la_SOURCES = dummy-c.c
  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: libXvMCr600.la
-   $(MKDIR_P) $(top_builddir)/$(LIB_DIR)/gallium
-   ln -f .libs/libXvMCr600.so* $(top_builddir)/$(LIB_DIR)/gallium/
diff --git a/src/gallium/targets/radeonsi/omx/Makefile.am 
b/src/gallium/targets/radeonsi/omx/Makefile.am
index 0d47912..14e9dbb 100644
--- a/src/gallium/targets/radeonsi/omx/Makefile.am
+++ b/src/gallium/targets/radeonsi/omx/Makefile.am
@@ -65,9 +65,3 @@ nodist_EXTRA_libomx_radeonsi_la_SOURCES = dummy-cpp.cpp
  libomx_radeonsi_la_LDFLAGS += $(LLVM_LDFLAGS)
  libomx_radeonsi_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: libomx_radeonsi.la
-   $(MKDIR_P) $(top_builddir)/$(LIB_DIR)/gallium
-   ln -f .libs/libomx_radeonsi.so* $(top_builddir)/$(LIB_DIR)/gallium/
diff --git a/src/gallium/targets/xvmc-nouveau/Makefile.am 
b/src/gallium/targets/xvmc-nouveau/Makefile.am
index 4a45f41..4abf81c 100644
--- a/src/gallium/targets/xvmc-nouveau/Makefile.am
+++ b/src/gallium/targets/xvmc-nouveau/Makefile.am
@@ -47,9 +47,3 @@ if HAVE_MESA_LLVM
  libXvMCnouveau_la_LDFLAGS += $(LLVM_LDFLAGS)
  libXvMCnouveau_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: libXvMCnouveau.la
-   $(MKDIR_P) $(top_builddir)/$(LIB_DIR)/gallium
-   ln -f .libs/libXvMCnouveau.so* $(top_builddir)/$(LIB_DIR)/gallium/


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

Re: [Mesa-dev] [PATCHv2 14/20] automake: create compat symlinks only for linux systems

[Christian König]

Am 08.03.2014 21:33, schrieb Emil Velikov:

The primary users of these are linux developers, although
it can be extended for *BSD and others if needed.

Fixes make install for Cygwin and OpenBSD at least.

v2:
  - Wrap vdpau targets as well.


Can't we have the check inside install-lib-links.mk instead? Would avoid 
the extra check on every new target.


Christian.



Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=63269
Signed-off-by: Emil Velikov 
Reviewed-by: Jon TURNEY 
---
  configure.ac   | 12 
  src/egl/main/Makefile.am   |  2 ++
  src/egl/wayland/wayland-egl/Makefile.am|  2 ++
  src/gallium/targets/dri-freedreno/Makefile.am  |  2 ++
  src/gallium/targets/dri-i915/Makefile.am   |  2 ++
  src/gallium/targets/dri-ilo/Makefile.am|  2 ++
  src/gallium/targets/dri-nouveau/Makefile.am|  2 ++
  src/gallium/targets/dri-swrast/Makefile.am |  2 ++
  src/gallium/targets/dri-vmwgfx/Makefile.am |  2 ++
  src/gallium/targets/egl-static/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/r300/dri/Makefile.am   |  2 ++
  src/gallium/targets/r600/dri/Makefile.am   |  2 ++
  src/gallium/targets/r600/vdpau/Makefile.am |  2 ++
  src/gallium/targets/radeonsi/dri/Makefile.am   |  2 ++
  src/gallium/targets/radeonsi/vdpau/Makefile.am |  2 ++
  src/gallium/targets/vdpau-nouveau/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 ++
  28 files changed, 66 insertions(+)

diff --git a/configure.ac b/configure.ac
index 5e1d091..620f76e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -317,6 +317,18 @@ if test "x$enable_debug" = xyes; then
  fi
  
  dnl

+dnl compatibility symlinks
+dnl
+case "$host_os" in
+linux* )
+HAVE_COMPAT_SYMLINKS=yes ;;
+* )
+HAVE_COMPAT_SYMLINKS=no ;;
+esac
+
+AM_CONDITIONAL(HAVE_COMPAT_SYMLINKS, test x$HAVE_COMPAT_SYMLINKS = xyes)
+
+dnl
  dnl library names
  dnl
  if test "$enable_static" = yes; then
diff --git a/src/egl/main/Makefile.am b/src/egl/main/Makefile.am
index 46e890a..e08a06c 100644
--- a/src/egl/main/Makefile.am
+++ b/src/egl/main/Makefile.am
@@ -109,7 +109,9 @@ libEGL_la_LIBADD += ../drivers/dri2/libegl_dri2.la
  libEGL_la_LIBADD += $(DLOPEN_LIBS) $(LIBDRM_LIBS)
  endif
  
+if HAVE_COMPAT_SYMLINKS

  include $(top_srcdir)/install-lib-links.mk
+endif
  
  pkgconfigdir = $(libdir)/pkgconfig
  
diff --git a/src/egl/wayland/wayland-egl/Makefile.am b/src/egl/wayland/wayland-egl/Makefile.am

index c8d0196..264d7ad 100644
--- a/src/egl/wayland/wayland-egl/Makefile.am
+++ b/src/egl/wayland/wayland-egl/Makefile.am
@@ -12,4 +12,6 @@ libwayland_egl_la_LDFLAGS = -version-info 1
  
  TESTS = wayland-egl-symbols-check
  
+if HAVE_COMPAT_SYMLINKS

  include $(top_srcdir)/install-lib-links.mk
+endif
diff --git a/src/gallium/targets/dri-freedreno/Makefile.am 
b/src/gallium/targets/dri-freedreno/Makefile.am
index f71fd32..5810e45 100644
--- a/src/gallium/targets/dri-freedreno/Makefile.am
+++ b/src/gallium/targets/dri-freedreno/Makefile.am
@@ -63,4 +63,6 @@ msm_dri_la_SOURCES  = target-msm.c
  msm_dri_la_LDFLAGS  = $(COMMON_LDFLAGS)
  msm_dri_la_LIBADD   = $(COMMON_LIBADD)
  
+if HAVE_COMPAT_SYMLINKS

  include $(top_srcdir)/install-gallium-links.mk
+endif
diff --git a/src/gallium/targets/dri-i915/Makefile.am 
b/src/gallium/targets/dri-i915/Makefile.am
index bba0886..f2852a6 100644
--- a/src/gallium/targets/dri-i915/Makefile.am
+++ b/src/gallium/targets/dri-i915/Makefile.am
@@ -59,4 +59,6 @@ AM_CPPFLAGS += -DGALLIUM_LLVMPIPE
  i915_dri_la_LIBADD += 
$(top_builddir)/src/gallium/drivers/llvmpipe/libllvmpipe.la $(LLVM_LIBS)
  endif
  
+if HAVE_COMPAT_SYMLINKS

  include $(top_srcdir)/install-gallium-links.mk
+endif
diff --git a/src/gallium/targets/dri-ilo/Makefile.am 
b/src/gallium/targets/dri-ilo/Makefile.am
index 18d3c44..10eb7c4 100644
--- a/src/gallium/targets/dri-ilo/Makefile.am
+++ b/src/gallium/targets/dri-ilo/Makefile.am
@@ -59,4 +59,6 @@ ilo_dri_la_LDFLAGS += $(LLVM_LDFLAGS)
  ilo_dri_la_LIBADD += $(LLVM_LIBS)
  endif
  
+if HAVE_COMPAT_SYMLINKS

  include $(top_srcdir)/install-gallium-links.mk
+endif
diff --git a/src/gallium/targets/dri-nouveau/Makefile.am 
b/src/gallium/targets/dri-nouveau/Makefile.am
index 6a00a66..8c3a6f5 100644
--- a/src/gallium/targets/dri-nouveau/Makefile.am
+++ b/src/gallium/targets/dri-nouveau/Makefile.am
@@ -55,4 +55,6 @@

Re: [Mesa-dev] [PATCH 1/3] r600g, radeonsi: use a fallback in dma_copy instead of failing

[Niels Ole Salscheider]

On Sunday 09 March 2014, 02:24:51, Marek Olšák wrote:
> From: Marek Olšák 
> 
> ---
>  src/gallium/drivers/r600/evergreen_state.c  | 37 +---
>  src/gallium/drivers/r600/r600_state.c   | 41 ++---
>  src/gallium/drivers/radeon/r600_buffer_common.c | 58
> +++-- src/gallium/drivers/radeon/r600_pipe_common.h   |
> 17 
>  src/gallium/drivers/radeon/r600_texture.c   | 18 +++-
>  src/gallium/drivers/radeonsi/si_state.c | 19 
>  6 files changed, 97 insertions(+), 93 deletions(-)
> 
> diff --git a/src/gallium/drivers/r600/evergreen_state.c
> b/src/gallium/drivers/r600/evergreen_state.c index dca7c58..5e57f8d 100644
> --- a/src/gallium/drivers/r600/evergreen_state.c
> +++ b/src/gallium/drivers/r600/evergreen_state.c
> @@ -3329,13 +3329,13 @@ static void evergreen_dma_copy_tile(struct
> r600_context *rctx, }
>  }
> 
> -static boolean evergreen_dma_blit(struct pipe_context *ctx,
> -   struct pipe_resource *dst,
> -   unsigned dst_level,
> -   unsigned dst_x, unsigned dst_y, unsigned 
> dst_z,
> -   struct pipe_resource *src,
> -   unsigned src_level,
> -   const struct pipe_box *src_box)
> +static void evergreen_dma_blit(struct pipe_context *ctx,
> +struct pipe_resource *dst,
> +unsigned dst_level,
> +unsigned dst_x, unsigned dst_y, unsigned dst_z,
> +struct pipe_resource *src,
> +unsigned src_level,
> +const struct pipe_box *src_box)
>  {
>   struct r600_context *rctx = (struct r600_context *)ctx;
>   struct r600_texture *rsrc = (struct r600_texture*)src;
> @@ -3345,19 +3345,22 @@ static boolean evergreen_dma_blit(struct
> pipe_context *ctx, unsigned src_x, src_y;
> 
>   if (rctx->b.rings.dma.cs == NULL) {
> - return FALSE;
> + goto fallback;
>   }
> 
>   if (dst->target == PIPE_BUFFER && src->target == PIPE_BUFFER) {
> + if (dst_x % 4 || src_box->x % 4 || src_box->width % 4)
> + goto fallback;

Why do we need this? I think that the async DMA engine can handle byte aligned 
copies. It is streamout that needs x and width to be dw aligned, isn't it?

> +
>   evergreen_dma_copy(rctx, dst, src, dst_x, src_box->x, src_box-
>width);
> - return TRUE;
> + return;
>   }
> 
>   if (src->format != dst->format) {
> - return FALSE;
> + goto fallback;
>   }
>   if (rdst->dirty_level_mask != 0) {
> - return FALSE;
> + goto fallback;
>   }
>   if (rsrc->dirty_level_mask) {
>   ctx->flush_resource(ctx, src);
> @@ -3383,13 +3386,13 @@ static boolean evergreen_dma_blit(struct
> pipe_context *ctx,
> 
>   if (src_pitch != dst_pitch || src_box->x || dst_x || src_w != dst_w) {
>   /* FIXME evergreen can do partial blit */
> - return FALSE;
> + goto fallback;
>   }
>   /* the x test here are currently useless (because we don't support 
partial
> blit) * but keep them around so we don't forget about those
>*/
>   if ((src_pitch & 0x7) || (src_box->x & 0x7) || (dst_x & 0x7) ||
> (src_box->y & 0x7) || (dst_y & 0x7)) { -  return FALSE;
> + goto fallback;
>   }
> 
>   /* 128 bpp surfaces require non_disp_tiling for both
> @@ -3400,7 +3403,7 @@ static boolean evergreen_dma_blit(struct pipe_context
> *ctx, if ((rctx->b.chip_class == CAYMAN) &&
>   (src_mode != dst_mode) &&
>   (util_format_get_blocksize(src->format) >= 16)) {
> - return FALSE;
> + goto fallback;
>   }
> 
>   if (src_mode == dst_mode) {
> @@ -3423,7 +3426,11 @@ static boolean evergreen_dma_blit(struct pipe_context
> *ctx, src, src_level, src_x, src_y, src_box->z,
>   copy_height, dst_pitch, bpp);
>   }
> - return TRUE;
> + return;
> +
> +fallback:
> + ctx->resource_copy_region(ctx, dst, dst_level, dst_x, dst_y, dst_z,
> +   src, src_level, src_box);
>  }
> 
>  void evergreen_init_state_functions(struct r600_context *rctx)
> diff --git a/src/gallium/drivers/r600/r600_state.c
> b/src/gallium/drivers/r600/r600_state.c index 6d89e6c..a0e6d2d 100644
> --- a/src/gallium/drivers/r600/r600_state.c
> +++ b/src/gallium/drivers/r600/r600_state.c
> @@ -2883,13 +2883,13 @@ static boolean r600_dma_copy_tile(struct
> r600_context *rctx, return TRUE;
>  }
> 
> -static boolean r600_dma_blit(struct pipe_context *ctx,
> -  struct pipe_resource *dst,
> -  unsigned dst_level,
> -  unsigned dst_x, unsigned dst

Re: [Mesa-dev] [PATCH 1/3] r600g, radeonsi: use a fallback in dma_copy instead of failing

[Marek Olšák]

The buffer upload code required dword alignment. I don't know why. It
might have been for R600-R700.

Marek

On Sun, Mar 9, 2014 at 11:59 AM, Niels Ole Salscheider
 wrote:
> On Sunday 09 March 2014, 02:24:51, Marek Olšák wrote:
>> From: Marek Olšák 
>>
>> ---
>>  src/gallium/drivers/r600/evergreen_state.c  | 37 +---
>>  src/gallium/drivers/r600/r600_state.c   | 41 ++---
>>  src/gallium/drivers/radeon/r600_buffer_common.c | 58
>> +++-- src/gallium/drivers/radeon/r600_pipe_common.h   |
>> 17 
>>  src/gallium/drivers/radeon/r600_texture.c   | 18 +++-
>>  src/gallium/drivers/radeonsi/si_state.c | 19 
>>  6 files changed, 97 insertions(+), 93 deletions(-)
>>
>> diff --git a/src/gallium/drivers/r600/evergreen_state.c
>> b/src/gallium/drivers/r600/evergreen_state.c index dca7c58..5e57f8d 100644
>> --- a/src/gallium/drivers/r600/evergreen_state.c
>> +++ b/src/gallium/drivers/r600/evergreen_state.c
>> @@ -3329,13 +3329,13 @@ static void evergreen_dma_copy_tile(struct
>> r600_context *rctx, }
>>  }
>>
>> -static boolean evergreen_dma_blit(struct pipe_context *ctx,
>> -   struct pipe_resource *dst,
>> -   unsigned dst_level,
>> -   unsigned dst_x, unsigned dst_y, unsigned 
>> dst_z,
>> -   struct pipe_resource *src,
>> -   unsigned src_level,
>> -   const struct pipe_box *src_box)
>> +static void evergreen_dma_blit(struct pipe_context *ctx,
>> +struct pipe_resource *dst,
>> +unsigned dst_level,
>> +unsigned dst_x, unsigned dst_y, unsigned dst_z,
>> +struct pipe_resource *src,
>> +unsigned src_level,
>> +const struct pipe_box *src_box)
>>  {
>>   struct r600_context *rctx = (struct r600_context *)ctx;
>>   struct r600_texture *rsrc = (struct r600_texture*)src;
>> @@ -3345,19 +3345,22 @@ static boolean evergreen_dma_blit(struct
>> pipe_context *ctx, unsigned src_x, src_y;
>>
>>   if (rctx->b.rings.dma.cs == NULL) {
>> - return FALSE;
>> + goto fallback;
>>   }
>>
>>   if (dst->target == PIPE_BUFFER && src->target == PIPE_BUFFER) {
>> + if (dst_x % 4 || src_box->x % 4 || src_box->width % 4)
>> + goto fallback;
>
> Why do we need this? I think that the async DMA engine can handle byte aligned
> copies. It is streamout that needs x and width to be dw aligned, isn't it?
>
>> +
>>   evergreen_dma_copy(rctx, dst, src, dst_x, src_box->x, src_box-
>>width);
>> - return TRUE;
>> + return;
>>   }
>>
>>   if (src->format != dst->format) {
>> - return FALSE;
>> + goto fallback;
>>   }
>>   if (rdst->dirty_level_mask != 0) {
>> - return FALSE;
>> + goto fallback;
>>   }
>>   if (rsrc->dirty_level_mask) {
>>   ctx->flush_resource(ctx, src);
>> @@ -3383,13 +3386,13 @@ static boolean evergreen_dma_blit(struct
>> pipe_context *ctx,
>>
>>   if (src_pitch != dst_pitch || src_box->x || dst_x || src_w != dst_w) {
>>   /* FIXME evergreen can do partial blit */
>> - return FALSE;
>> + goto fallback;
>>   }
>>   /* the x test here are currently useless (because we don't support
> partial
>> blit) * but keep them around so we don't forget about those
>>*/
>>   if ((src_pitch & 0x7) || (src_box->x & 0x7) || (dst_x & 0x7) ||
>> (src_box->y & 0x7) || (dst_y & 0x7)) { -  return FALSE;
>> + goto fallback;
>>   }
>>
>>   /* 128 bpp surfaces require non_disp_tiling for both
>> @@ -3400,7 +3403,7 @@ static boolean evergreen_dma_blit(struct pipe_context
>> *ctx, if ((rctx->b.chip_class == CAYMAN) &&
>>   (src_mode != dst_mode) &&
>>   (util_format_get_blocksize(src->format) >= 16)) {
>> - return FALSE;
>> + goto fallback;
>>   }
>>
>>   if (src_mode == dst_mode) {
>> @@ -3423,7 +3426,11 @@ static boolean evergreen_dma_blit(struct pipe_context
>> *ctx, src, src_level, src_x, src_y, src_box->z,
>>   copy_height, dst_pitch, bpp);
>>   }
>> - return TRUE;
>> + return;
>> +
>> +fallback:
>> + ctx->resource_copy_region(ctx, dst, dst_level, dst_x, dst_y, dst_z,
>> +   src, src_level, src_box);
>>  }
>>
>>  void evergreen_init_state_functions(struct r600_context *rctx)
>> diff --git a/src/gallium/drivers/r600/r600_state.c
>> b/src/gallium/drivers/r600/r600_state.c index 6d89e6c..a0e6d2d 100644
>> --- a/src/gallium/drivers/r600/r600_state.c
>> +++ b/src/gallium/drivers/r600/r600_state.c
>> @@ -2883,13 +2883,13 @@ static boolean r600_dma_

[Mesa-dev] [PATCH] automake: create compat symlinks only for linux systems

[Emil Velikov]

The primary users of these are linux developers, although
it can be extended for *BSD and others if needed.

Fixes make install for Cygwin and OpenBSD at least.

v2:
 - Wrap vdpau targets as well.
v3:
 - Fold HAVE_COMPAT_SYMLINKS checks within install*links.mk

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=63269
Signed-off-by: Emil Velikov 
Reviewed-by: Jon TURNEY 

Signed-off-by: Emil Velikov 
---

Interesting the first time tried it I've got some unusual
results, while it's works nicely now. I'm assuming that
there was a silly typo somewhere.

Thanks for the reminder Christian, I was not too keen on
the previous approach either :)

-Emil

 configure.ac | 12 
 install-gallium-links.mk |  2 ++
 install-lib-links.mk |  2 ++
 src/mesa/drivers/dri/Makefile.am |  2 ++
 4 files changed, 18 insertions(+)

diff --git a/configure.ac b/configure.ac
index 7fbf2cf..c5042f9 100644
--- a/configure.ac
+++ b/configure.ac
@@ -314,6 +314,18 @@ if test "x$enable_debug" = xyes; then
 fi
 
 dnl
+dnl compatibility symlinks
+dnl
+case "$host_os" in
+linux* )
+HAVE_COMPAT_SYMLINKS=yes ;;
+* )
+HAVE_COMPAT_SYMLINKS=no ;;
+esac
+
+AM_CONDITIONAL(HAVE_COMPAT_SYMLINKS, test "x$HAVE_COMPAT_SYMLINKS" = xyes)
+
+dnl
 dnl library names
 dnl
 case "$host_os" in
diff --git a/install-gallium-links.mk b/install-gallium-links.mk
index be69326..e655608 100644
--- a/install-gallium-links.mk
+++ b/install-gallium-links.mk
@@ -1,6 +1,7 @@
 # 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.
 
+if HAVE_COMPAT_SYMLINKS
 all-local : .libs/install-gallium-links
 
 .libs/install-gallium-links : $(dri_LTLIBRARIES) $(vdpau_LTLIBRARIES) 
$(egl_LTLIBRARIES) $(lib_LTLIBRARIES)
@@ -21,3 +22,4 @@ all-local : .libs/install-gallium-links
ln -f $$f $$link_dir;   \
fi; \
done && touch $@
+endif
diff --git a/install-lib-links.mk b/install-lib-links.mk
index 2707eb8..0e13719 100644
--- a/install-lib-links.mk
+++ b/install-lib-links.mk
@@ -1,6 +1,7 @@
 # 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.
 
+if HAVE_COMPAT_SYMLINKS
 all-local : .libs/install-mesa-links
 
 .libs/install-mesa-links : $(lib_LTLIBRARIES)
@@ -12,3 +13,4 @@ all-local : .libs/install-mesa-links
ln -f $$f $(top_builddir)/$(LIB_DIR);   \
fi; \
done && touch $@
+endif
diff --git a/src/mesa/drivers/dri/Makefile.am b/src/mesa/drivers/dri/Makefile.am
index 187e478..17ac76b 100644
--- a/src/mesa/drivers/dri/Makefile.am
+++ b/src/mesa/drivers/dri/Makefile.am
@@ -65,6 +65,7 @@ mesa_dri_drivers_la_LIBADD = \
 if NEED_MEGADRIVER
 dri_LTLIBRARIES = mesa_dri_drivers.la
 
+if HAVE_COMPAT_SYMLINKS
 # Add a link to allow setting LD_LIBRARY_PATH/LIBGL_DRIVERS_PATH to /lib of 
the build tree.
 all-local: mesa_dri_drivers.la
$(AM_V_at)$(MKDIR_P) $(top_builddir)/$(LIB_DIR);
@@ -74,6 +75,7 @@ all-local: mesa_dri_drivers.la
ln -f $(top_builddir)/$(LIB_DIR)/mesa_dri_drivers.@LIB_EXT@ \
  $(top_builddir)/$(LIB_DIR)/$$i; \
done;
+endif
 
 # hardlink each megadriver instance, but don't actually have
 # mesa_dri_drivers.@LIB_EXT@ in the set of final installed files.
-- 
1.9.0

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

Re: [Mesa-dev] [PATCH 1/3] r600g, radeonsi: use a fallback in dma_copy instead of failing

[Bruno Jimenez]

This series fixes some of the opencv opencl-related tests for me.

Thanks!

On Sun, 2014-03-09 at 02:24 +0100, Marek Olšák wrote:
> From: Marek Olšák 
> 
> ---
>  src/gallium/drivers/r600/evergreen_state.c  | 37 +---
>  src/gallium/drivers/r600/r600_state.c   | 41 ++---
>  src/gallium/drivers/radeon/r600_buffer_common.c | 58 
> +++--
>  src/gallium/drivers/radeon/r600_pipe_common.h   | 17 
>  src/gallium/drivers/radeon/r600_texture.c   | 18 +++-
>  src/gallium/drivers/radeonsi/si_state.c | 19 
>  6 files changed, 97 insertions(+), 93 deletions(-)
> 
> diff --git a/src/gallium/drivers/r600/evergreen_state.c 
> b/src/gallium/drivers/r600/evergreen_state.c
> index dca7c58..5e57f8d 100644
> --- a/src/gallium/drivers/r600/evergreen_state.c
> +++ b/src/gallium/drivers/r600/evergreen_state.c
> @@ -3329,13 +3329,13 @@ static void evergreen_dma_copy_tile(struct 
> r600_context *rctx,
>   }
>  }
>  
> -static boolean evergreen_dma_blit(struct pipe_context *ctx,
> -   struct pipe_resource *dst,
> -   unsigned dst_level,
> -   unsigned dst_x, unsigned dst_y, unsigned 
> dst_z,
> -   struct pipe_resource *src,
> -   unsigned src_level,
> -   const struct pipe_box *src_box)
> +static void evergreen_dma_blit(struct pipe_context *ctx,
> +struct pipe_resource *dst,
> +unsigned dst_level,
> +unsigned dst_x, unsigned dst_y, unsigned dst_z,
> +struct pipe_resource *src,
> +unsigned src_level,
> +const struct pipe_box *src_box)
>  {
>   struct r600_context *rctx = (struct r600_context *)ctx;
>   struct r600_texture *rsrc = (struct r600_texture*)src;
> @@ -3345,19 +3345,22 @@ static boolean evergreen_dma_blit(struct pipe_context 
> *ctx,
>   unsigned src_x, src_y;
>  
>   if (rctx->b.rings.dma.cs == NULL) {
> - return FALSE;
> + goto fallback;
>   }
>  
>   if (dst->target == PIPE_BUFFER && src->target == PIPE_BUFFER) {
> + if (dst_x % 4 || src_box->x % 4 || src_box->width % 4)
> + goto fallback;
> +
>   evergreen_dma_copy(rctx, dst, src, dst_x, src_box->x, 
> src_box->width);
> - return TRUE;
> + return;
>   }
>  
>   if (src->format != dst->format) {
> - return FALSE;
> + goto fallback;
>   }
>   if (rdst->dirty_level_mask != 0) {
> - return FALSE;
> + goto fallback;
>   }
>   if (rsrc->dirty_level_mask) {
>   ctx->flush_resource(ctx, src);
> @@ -3383,13 +3386,13 @@ static boolean evergreen_dma_blit(struct pipe_context 
> *ctx,
>  
>   if (src_pitch != dst_pitch || src_box->x || dst_x || src_w != dst_w) {
>   /* FIXME evergreen can do partial blit */
> - return FALSE;
> + goto fallback;
>   }
>   /* the x test here are currently useless (because we don't support 
> partial blit)
>* but keep them around so we don't forget about those
>*/
>   if ((src_pitch & 0x7) || (src_box->x & 0x7) || (dst_x & 0x7) || 
> (src_box->y & 0x7) || (dst_y & 0x7)) {
> - return FALSE;
> + goto fallback;
>   }
>  
>   /* 128 bpp surfaces require non_disp_tiling for both
> @@ -3400,7 +3403,7 @@ static boolean evergreen_dma_blit(struct pipe_context 
> *ctx,
>   if ((rctx->b.chip_class == CAYMAN) &&
>   (src_mode != dst_mode) &&
>   (util_format_get_blocksize(src->format) >= 16)) {
> - return FALSE;
> + goto fallback;
>   }
>  
>   if (src_mode == dst_mode) {
> @@ -3423,7 +3426,11 @@ static boolean evergreen_dma_blit(struct pipe_context 
> *ctx,
>   src, src_level, src_x, src_y, 
> src_box->z,
>   copy_height, dst_pitch, bpp);
>   }
> - return TRUE;
> + return;
> +
> +fallback:
> + ctx->resource_copy_region(ctx, dst, dst_level, dst_x, dst_y, dst_z,
> +   src, src_level, src_box);
>  }
>  
>  void evergreen_init_state_functions(struct r600_context *rctx)
> diff --git a/src/gallium/drivers/r600/r600_state.c 
> b/src/gallium/drivers/r600/r600_state.c
> index 6d89e6c..a0e6d2d 100644
> --- a/src/gallium/drivers/r600/r600_state.c
> +++ b/src/gallium/drivers/r600/r600_state.c
> @@ -2883,13 +2883,13 @@ static boolean r600_dma_copy_tile(struct r600_context 
> *rctx,
>   return TRUE;
>  }
>  
> -static boolean r600_dma_blit(struct pipe_context *ctx,
> -  struct pipe_resource *dst,
> -  unsigned dst_level,
> -

[Mesa-dev] [Bug 75919] LLVM changed output of llvm-config, again

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=75919

--- Comment #1 from Dave Witbrodt  ---
(In reply to comment #0)
> Created attachment 95368 [details]
> Is there even a point?
> 
> llvm-config-3.5 --version now prints 3.5.0 instead of 3.5.
> config is unable to find a shared llvm library if there is only one so. It
> searches for a libLLVM-3.5.0.so but only libLLVM-3.5.so exists.

Thanks Krzysztof!  I've been trying to get shared LLVM 3.5 working again, and
you found the fix.  (More details at comment 2 of bug 75929.)

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 75919] LLVM changed output of llvm-config, again

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=75919

--- Comment #2 from Tom Stellard  ---
(In reply to comment #0)
> Created attachment 95368 [details]
> Is there even a point?
> 
> llvm-config-3.5 --version now prints 3.5.0 instead of 3.5.
> config is unable to find a shared llvm library if there is only one so. It
> searches for a libLLVM-3.5.0.so but only libLLVM-3.5.so exists.

Are you using cmake or autoconf to build LLVM?  I use autoconf and on my system
llvm-config --version reports 3.5.0 and llvm install libLLVM-3.5.0.so and also
a symlink from libLLVM-3.5.0.so to libLLV-3.5.so.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] gallium: allow setting of the internal stream output offset

[Marek Olšák]

Reviewed-by: Marek Olšák 

Marek

On Fri, Mar 7, 2014 at 4:09 AM, Zack Rusin  wrote:
> (This version includes comments from Roland.)
>
> D3D10 allows setting of the internal offset of a buffer, which is
> in general only incremented via actual stream output writes. By
> allowing setting of the internal offset draw_auto is capable
> of rendering from buffers which have not been actually streamed
> out to. Our interface didn't allow. This change functionally
> shouldn't make any difference to OpenGL where instead of an
> append_bitmask you just get a real array where -1 means append
> (like in D3D) and 0 means do not append.
>
> Signed-off-by: Zack Rusin 
> ---
>  src/gallium/auxiliary/cso_cache/cso_context.c | 13 -
>  src/gallium/auxiliary/cso_cache/cso_context.h |  2 +-
>  src/gallium/auxiliary/draw/draw_context.h |  3 +--
>  src/gallium/auxiliary/draw/draw_pt.c  |  8 +---
>  src/gallium/auxiliary/draw/draw_pt_so_emit.c  |  3 +--
>  src/gallium/auxiliary/hud/hud_context.c   |  2 +-
>  src/gallium/auxiliary/postprocess/pp_run.c|  2 +-
>  src/gallium/auxiliary/util/u_blit.c   |  2 +-
>  src/gallium/auxiliary/util/u_blitter.c| 13 +
>  src/gallium/auxiliary/util/u_gen_mipmap.c |  2 +-
>  src/gallium/docs/source/context.rst   |  9 +
>  src/gallium/drivers/galahad/glhd_context.c|  4 ++--
>  src/gallium/drivers/ilo/ilo_state.c   |  8 ++--
>  src/gallium/drivers/llvmpipe/lp_state_so.c| 12 ++--
>  src/gallium/drivers/noop/noop_state.c |  2 +-
>  src/gallium/drivers/nouveau/nv50/nv50_state.c |  7 ---
>  src/gallium/drivers/nouveau/nvc0/nvc0_state.c |  7 ---
>  src/gallium/drivers/radeon/r600_pipe_common.h |  2 +-
>  src/gallium/drivers/radeon/r600_streamout.c   |  5 -
>  src/gallium/drivers/radeonsi/si_descriptors.c |  4 ++--
>  src/gallium/drivers/softpipe/sp_state_so.c|  2 +-
>  src/gallium/drivers/trace/tr_context.c|  6 +++---
>  src/gallium/include/pipe/p_context.h  |  2 +-
>  src/gallium/tools/trace/dump_state.py |  4 ++--
>  src/mesa/state_tracker/st_cb_bitmap.c |  2 +-
>  src/mesa/state_tracker/st_cb_clear.c  |  2 +-
>  src/mesa/state_tracker/st_cb_drawpixels.c |  2 +-
>  src/mesa/state_tracker/st_cb_drawtex.c|  2 +-
>  src/mesa/state_tracker/st_cb_xformfb.c| 20 +---
>  29 files changed, 88 insertions(+), 64 deletions(-)
>
> diff --git a/src/gallium/auxiliary/cso_cache/cso_context.c 
> b/src/gallium/auxiliary/cso_cache/cso_context.c
> index 2dcf01d..9146684 100644
> --- a/src/gallium/auxiliary/cso_cache/cso_context.c
> +++ b/src/gallium/auxiliary/cso_cache/cso_context.c
> @@ -332,7 +332,7 @@ void cso_release_all( struct cso_context *ctx )
>ctx->pipe->bind_vertex_elements_state( ctx->pipe, NULL );
>
>if (ctx->pipe->set_stream_output_targets)
> - ctx->pipe->set_stream_output_targets(ctx->pipe, 0, NULL, 0);
> + ctx->pipe->set_stream_output_targets(ctx->pipe, 0, NULL, NULL);
> }
>
> /* free fragment sampler views */
> @@ -1241,7 +1241,7 @@ void
>  cso_set_stream_outputs(struct cso_context *ctx,
> unsigned num_targets,
> struct pipe_stream_output_target **targets,
> -   unsigned append_bitmask)
> +   const unsigned *offsets)
>  {
> struct pipe_context *pipe = ctx->pipe;
> uint i;
> @@ -1266,7 +1266,7 @@ cso_set_stream_outputs(struct cso_context *ctx,
> }
>
> pipe->set_stream_output_targets(pipe, num_targets, targets,
> -   append_bitmask);
> +   offsets);
> ctx->nr_so_targets = num_targets;
>  }
>
> @@ -1292,6 +1292,7 @@ cso_restore_stream_outputs(struct cso_context *ctx)
>  {
> struct pipe_context *pipe = ctx->pipe;
> uint i;
> +   unsigned offset[PIPE_MAX_SO_BUFFERS];
>
> if (!ctx->has_streamout) {
>return;
> @@ -1302,19 +1303,21 @@ cso_restore_stream_outputs(struct cso_context *ctx)
>return;
> }
>
> +   assert(ctx->nr_so_targets_saved <= PIPE_MAX_SO_BUFFERS);
> for (i = 0; i < ctx->nr_so_targets_saved; i++) {
>pipe_so_target_reference(&ctx->so_targets[i], NULL);
>/* move the reference from one pointer to another */
>ctx->so_targets[i] = ctx->so_targets_saved[i];
>ctx->so_targets_saved[i] = NULL;
> +  /* -1 means append */
> +  offset[i] = (unsigned)-1;
> }
> for (; i < ctx->nr_so_targets; i++) {
>pipe_so_target_reference(&ctx->so_targets[i], NULL);
> }
>
> -   /* ~0 means append */
> pipe->set_stream_output_targets(pipe, ctx->nr_so_targets_saved,
> -   ctx->so_targets, ~0);
> +   ctx->so_targets, offset);
>
> ctx->nr_so_targets = ctx->nr_so_targets_saved;
> ctx->nr_so_targets_saved = 0;
> diff --git a/src/gallium/auxiliary/cso

Re: [Mesa-dev] [PATCH] mesa: fix glGet size queries for L/LA/I color buffers

[Marek Olšák]

Do you have any opinion on this patch, anyone?

Marek

On Tue, Mar 4, 2014 at 12:32 PM, Marek Olšák  wrote:
> From: Marek Olšák 
>
> There is no API for returning the number of luminance and intensity bits and
> the 3.3 spec doesn't seem to specify any behavior for the queries if the 
> format
> is one of L, LA, I. It seems to be a spec bug.
>
> This helps to fix piglit tests that rely on the number of color bits to be
> non-zero, for example:
>   spec/EXT_texture_integer/multisample-formats  
> GL_EXT_texture_integer
> ---
>  src/mesa/main/formats.c   | 24 ++---
>  src/mesa/main/glformats.c | 53 
> ---
>  2 files changed, 62 insertions(+), 15 deletions(-)
>
> diff --git a/src/mesa/main/formats.c b/src/mesa/main/formats.c
> index f6c399e..8f847cb 100644
> --- a/src/mesa/main/formats.c
> +++ b/src/mesa/main/formats.c
> @@ -1842,25 +1842,34 @@ _mesa_get_format_bits(mesa_format format, GLenum 
> pname)
> const struct gl_format_info *info = _mesa_get_format_info(format);
>
> switch (pname) {
> +   /* color buffer enums */
> case GL_RED_BITS:
> -   case GL_TEXTURE_RED_SIZE:
> case GL_RENDERBUFFER_RED_SIZE_EXT:
> case GL_FRAMEBUFFER_ATTACHMENT_RED_SIZE:
> -  return info->RedBits;
> +  return info->IntensityBits ? info->IntensityBits :
> + info->LuminanceBits ? info->LuminanceBits : info->RedBits;
> case GL_GREEN_BITS:
> -   case GL_TEXTURE_GREEN_SIZE:
> case GL_RENDERBUFFER_GREEN_SIZE_EXT:
> case GL_FRAMEBUFFER_ATTACHMENT_GREEN_SIZE:
> -  return info->GreenBits;
> +  return info->IntensityBits ? info->IntensityBits :
> + info->LuminanceBits ? info->LuminanceBits : info->GreenBits;
> case GL_BLUE_BITS:
> -   case GL_TEXTURE_BLUE_SIZE:
> case GL_RENDERBUFFER_BLUE_SIZE_EXT:
> case GL_FRAMEBUFFER_ATTACHMENT_BLUE_SIZE:
> -  return info->BlueBits;
> +  return info->IntensityBits ? info->IntensityBits :
> + info->LuminanceBits ? info->LuminanceBits : info->BlueBits;
> case GL_ALPHA_BITS:
> -   case GL_TEXTURE_ALPHA_SIZE:
> case GL_RENDERBUFFER_ALPHA_SIZE_EXT:
> case GL_FRAMEBUFFER_ATTACHMENT_ALPHA_SIZE:
> +  return info->IntensityBits ? info->IntensityBits : info->AlphaBits;
> +   /* texture enums */
> +   case GL_TEXTURE_RED_SIZE:
> +  return info->RedBits;
> +   case GL_TEXTURE_GREEN_SIZE:
> +  return info->GreenBits;
> +   case GL_TEXTURE_BLUE_SIZE:
> +  return info->BlueBits;
> +   case GL_TEXTURE_ALPHA_SIZE:
>return info->AlphaBits;
> case GL_TEXTURE_INTENSITY_SIZE:
>return info->IntensityBits;
> @@ -1868,6 +1877,7 @@ _mesa_get_format_bits(mesa_format format, GLenum pname)
>return info->LuminanceBits;
> case GL_INDEX_BITS:
>return info->IndexBits;
> +   /* depth/stencil enums */
> case GL_DEPTH_BITS:
> case GL_TEXTURE_DEPTH_SIZE_ARB:
> case GL_RENDERBUFFER_DEPTH_SIZE_EXT:
> diff --git a/src/mesa/main/glformats.c b/src/mesa/main/glformats.c
> index 77cf263..71064ed 100644
> --- a/src/mesa/main/glformats.c
> +++ b/src/mesa/main/glformats.c
> @@ -984,11 +984,53 @@ GLboolean
>  _mesa_base_format_has_channel(GLenum base_format, GLenum pname)
>  {
> switch (pname) {
> -   case GL_TEXTURE_RED_SIZE:
> -   case GL_TEXTURE_RED_TYPE:
> +   /* color buffer enums */
> case GL_RENDERBUFFER_RED_SIZE_EXT:
> case GL_FRAMEBUFFER_ATTACHMENT_RED_SIZE:
>if (base_format == GL_RED ||
> +  base_format == GL_RG ||
> +  base_format == GL_RGB ||
> +  base_format == GL_RGBA ||
> +  base_format == GL_LUMINANCE ||
> +  base_format == GL_LUMINANCE_ALPHA ||
> +  base_format == GL_INTENSITY) {
> + return GL_TRUE;
> +  }
> +  return GL_FALSE;
> +   case GL_RENDERBUFFER_GREEN_SIZE_EXT:
> +   case GL_FRAMEBUFFER_ATTACHMENT_GREEN_SIZE:
> +  if (base_format == GL_RG ||
> +  base_format == GL_RGB ||
> +  base_format == GL_RGBA ||
> +  base_format == GL_LUMINANCE ||
> +  base_format == GL_LUMINANCE_ALPHA ||
> +  base_format == GL_INTENSITY) {
> + return GL_TRUE;
> +  }
> +  return GL_FALSE;
> +   case GL_RENDERBUFFER_BLUE_SIZE_EXT:
> +   case GL_FRAMEBUFFER_ATTACHMENT_BLUE_SIZE:
> +  if (base_format == GL_RGB ||
> +  base_format == GL_RGBA ||
> +  base_format == GL_LUMINANCE ||
> +  base_format == GL_LUMINANCE_ALPHA ||
> +  base_format == GL_INTENSITY) {
> + return GL_TRUE;
> +  }
> +  return GL_FALSE;
> +   case GL_RENDERBUFFER_ALPHA_SIZE_EXT:
> +   case GL_FRAMEBUFFER_ATTACHMENT_ALPHA_SIZE:
> +  if (base_format == GL_RGBA ||
> +  base_format == GL_ALPHA ||
> +  base_format == GL_LUMINANCE_ALPHA ||
> +  base_format == GL_INTENSITY) {
> + return GL_TRUE;
> +  }
> +  return GL_FALSE;
> +   /* texture enums */
> +   case GL_TEXTURE_RED_SIZE:
> +   case GL_TEXTURE_RED_TYPE:
> +

Re: [Mesa-dev] [PATCH 1/3] r600g, radeonsi: use a fallback in dma_copy instead of failing

[Niels Ole Salscheider]

You are right, r600-r700 require dword alignment while linear copies can be 
byte aligned on EG+.
Apart from that, patch 1 and 2 look good to me...

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

Re: [Mesa-dev] [PATCH 4/4] mesa: stop aliasing ARB and core shader API functions

[Emil Velikov]

On 09/03/14 01:10, Brian Paul wrote:
> For example, we now we have separate dispatch functions for
> glCompileShader(GLuint) and glCompileShaderARB(GLhandleARB).
> 
> With this change and the previous ones we should be able to build/run
> on MacOS again (where GLhandleARB is a void pointer, not a GLuint).
> 
Hi Brian,

Wondering if with the drop of the aliases one would need to update the
gl function tables in dispatch_sanity.cpp. AFAICS it currently checks
the non ARB functions but does not list the ARB ones (unlike other
aliased functions).

Are they any special (apart from the ifdef APPLE piece in the spec) ?

Thanks
-Emil
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66346
> ---
>  src/mapi/glapi/gen/gl_API.xml |   28 +++-
>  src/mesa/main/dlist.c |2 +-
>  2 files changed, 16 insertions(+), 14 deletions(-)
> 
> diff --git a/src/mapi/glapi/gen/gl_API.xml b/src/mapi/glapi/gen/gl_API.xml
> index 7e1946e..76f56c4 100644
> --- a/src/mapi/glapi/gen/gl_API.xml
> +++ b/src/mapi/glapi/gen/gl_API.xml
> @@ -7829,14 +7829,14 @@
>  
>  
>  
> -
> +
>  
>  
>  
>  
>  
>  
> -
> +
>  
>  
>  
> @@ -7851,15 +7851,17 @@
>  
>  
>  
> -
> +
>  
>  
>  
> -
> +
>  
> +
> +
>  
>  
> -
> +
>  
>  
>  
> @@ -8014,13 +8016,13 @@
>  
>  
>  
> -
> +
>  
>  
>  
>  
>  
> -
> +
>  
>  
>  
> @@ -8030,19 +8032,19 @@
>  
>  
>  
> -
> +
>  
>  
>  
>  
>  
> -
> +
>  
>  
>  
>  
>  
> -
> +
>  
>  
>  
> @@ -8059,13 +8061,13 @@
>  
>  
>  
> -
> +
>  
>  
>  
>  
>  
> -
> +
>  
>  
>  
> @@ -8075,7 +8077,7 @@
>  
>  
>  
> -
> +
>  
>  
>  
> diff --git a/src/mesa/main/dlist.c b/src/mesa/main/dlist.c
> index 6035ec0..b29b440 100644
> --- a/src/mesa/main/dlist.c
> +++ b/src/mesa/main/dlist.c
> @@ -8728,7 +8728,7 @@ _mesa_initialize_save_table(const struct gl_context 
> *ctx)
> SET_BlitFramebuffer(table, save_BlitFramebufferEXT);
>  
> SET_UseProgram(table, save_UseProgram);
> -//   SET_UseProgramObjectARB(table, save_UseProgramObjectARB);
> +   SET_UseProgramObjectARB(table, save_UseProgramObjectARB);
> SET_Uniform1f(table, save_Uniform1fARB);
> SET_Uniform2f(table, save_Uniform2fARB);
> SET_Uniform3f(table, save_Uniform3fARB);
> 

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

[Mesa-dev] [Bug 75919] LLVM changed output of llvm-config, again

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=75919

Krzysztof A. Sobiecki  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |NOTOURBUG

--- Comment #3 from Krzysztof A. Sobiecki  ---
(In reply to comment #2)
> (In reply to comment #0)
> > Created attachment 95368 [details]
> > Is there even a point?
> > 
> > llvm-config-3.5 --version now prints 3.5.0 instead of 3.5.
> > config is unable to find a shared llvm library if there is only one so. It
> > searches for a libLLVM-3.5.0.so but only libLLVM-3.5.so exists.
> 
> Are you using cmake or autoconf to build LLVM?  I use autoconf and on my
> system
> llvm-config --version reports 3.5.0 and llvm install libLLVM-3.5.0.so and
> also a symlink from libLLVM-3.5.0.so to libLLV-3.5.so.

I use packages from:
http://llvm.org/apt/unstable/pool/main/l/llvm-toolchain-snapshot/
After a short look into it, I think that there is a small bug in it.

One package populates link farm in usr/lib/llvm-3.5/lib/ and while it links
usr/lib/@DEB_HOST_MULTIARCH@/libLLVM-3.5.so.1  
usr/lib/llvm-3.5/lib/libLLVM-3.5.so
it doesn't do the same for 3.5.0 variant.

Mystery solved, time to poke the maintainer.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 75919] LLVM changed output of llvm-config, again

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=75919

--- Comment #4 from Krzysztof A. Sobiecki  ---
It should be fixed soon.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] mesa: mark GL_RGB9_E5 as not color-renderable

[Marek Olšák]

From: Marek Olšák 

The GL 4.4 spec says it's not color-renderable and not accepted
by RenderBufferStorage. The EXT_texture_shared_exponent spec says
it's not color-renderable but it's accepted by RenderBufferStorageEXT.
This seems to be a bug in the extension spec.

Let's do what GL 4.4 says.

Cc: mesa-sta...@lists.freedesktop.org
---
 src/mesa/main/fbobject.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index a9dcc51..dfe2f1e 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -1565,10 +1565,6 @@ _mesa_base_fbo_format(struct gl_context *ctx, GLenum 
internalFormat)
   return ctx->API == API_OPENGL_COMPAT &&
  ctx->Extensions.ARB_texture_float &&
  ctx->Extensions.ARB_framebuffer_object ? GL_INTENSITY : 0;
-   case GL_RGB9_E5:
-  return (_mesa_is_desktop_gl(ctx)
-  && ctx->Extensions.EXT_texture_shared_exponent)
- ? GL_RGB : 0;
case GL_R11F_G11F_B10F:
   return ((_mesa_is_desktop_gl(ctx) && ctx->Extensions.EXT_packed_float) ||
   _mesa_is_gles3(ctx) /* EXT_color_buffer_float */ )
-- 
1.8.3.2

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

[Mesa-dev] [PATCH 1/5] r600g, radeonsi: fix MAX_TEXTURE_3D_LEVELS and MAX_TEXTURE_ARRAY_LAYERS limits

[Marek Olšák]

From: Marek Olšák 

CB_COLORi_VIEW.SLICE_MAX can be at most 2047.

This fixes the maxlayers piglit test.

Cc: mesa-sta...@lists.freedesktop.org
---
 src/gallium/drivers/r600/r600_pipe.c   | 8 +---
 src/gallium/drivers/radeonsi/si_pipe.c | 9 ++---
 2 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/src/gallium/drivers/r600/r600_pipe.c 
b/src/gallium/drivers/r600/r600_pipe.c
index 2fceb3c..88fbdd8 100644
--- a/src/gallium/drivers/r600/r600_pipe.c
+++ b/src/gallium/drivers/r600/r600_pipe.c
@@ -423,15 +423,17 @@ static int r600_get_param(struct pipe_screen* pscreen, 
enum pipe_cap param)
 
/* Texturing. */
case PIPE_CAP_MAX_TEXTURE_2D_LEVELS:
-   case PIPE_CAP_MAX_TEXTURE_3D_LEVELS:
case PIPE_CAP_MAX_TEXTURE_CUBE_LEVELS:
if (family >= CHIP_CEDAR)
return 15;
else
return 14;
+   case PIPE_CAP_MAX_TEXTURE_3D_LEVELS:
+   /* textures support 8192, but layered rendering supports 2048 */
+   return 12;
case PIPE_CAP_MAX_TEXTURE_ARRAY_LAYERS:
-   return rscreen->b.info.drm_minor >= 9 ?
-   (family >= CHIP_CEDAR ? 16384 : 8192) : 0;
+   /* textures support 8192, but layered rendering supports 2048 */
+   return rscreen->b.info.drm_minor >= 9 ? 2048 : 0;
 
/* Render targets. */
case PIPE_CAP_MAX_RENDER_TARGETS:
diff --git a/src/gallium/drivers/radeonsi/si_pipe.c 
b/src/gallium/drivers/radeonsi/si_pipe.c
index 040fc5c..95f022b 100644
--- a/src/gallium/drivers/radeonsi/si_pipe.c
+++ b/src/gallium/drivers/radeonsi/si_pipe.c
@@ -307,11 +307,14 @@ static int si_get_param(struct pipe_screen* pscreen, enum 
pipe_cap param)
 
/* Texturing. */
case PIPE_CAP_MAX_TEXTURE_2D_LEVELS:
-   case PIPE_CAP_MAX_TEXTURE_3D_LEVELS:
case PIPE_CAP_MAX_TEXTURE_CUBE_LEVELS:
-   return 15;
+   return 15; /* 16384 */
+   case PIPE_CAP_MAX_TEXTURE_3D_LEVELS:
+   /* textures support 8192, but layered rendering supports 2048 */
+   return 12;
case PIPE_CAP_MAX_TEXTURE_ARRAY_LAYERS:
-   return 16384;
+   /* textures support 8192, but layered rendering supports 2048 */
+   return 2048;
 
/* Render targets. */
case PIPE_CAP_MAX_RENDER_TARGETS:
-- 
1.8.3.2

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

[Mesa-dev] [PATCH 2/5] r600g, radeonsi: don't add streamout.num_dw_for_end twice

[Marek Olšák]

From: Marek Olšák 

It's already added in need_cs_space.

Also don't calculate anything if there are no buffers.
---
 src/gallium/drivers/radeon/r600_streamout.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/gallium/drivers/radeon/r600_streamout.c 
b/src/gallium/drivers/radeon/r600_streamout.c
index 34139df..1604fdd 100644
--- a/src/gallium/drivers/radeon/r600_streamout.c
+++ b/src/gallium/drivers/radeon/r600_streamout.c
@@ -79,6 +79,9 @@ void r600_streamout_buffers_dirty(struct r600_common_context 
*rctx)
unsigned num_bufs_appended = util_bitcount(rctx->streamout.enabled_mask 
&
   
rctx->streamout.append_bitmask);
 
+   if (!num_bufs)
+   return;
+
rctx->streamout.num_dw_for_end =
12 + /* flush_vgt_streamout */
num_bufs * 8 + /* STRMOUT_BUFFER_UPDATE */
@@ -99,8 +102,7 @@ void r600_streamout_buffers_dirty(struct r600_common_context 
*rctx)
begin->num_dw +=
num_bufs_appended * 8 + /* STRMOUT_BUFFER_UPDATE */
(num_bufs - num_bufs_appended) * 6 + /* STRMOUT_BUFFER_UPDATE */
-   (rctx->family > CHIP_R600 && rctx->family < CHIP_RS780 ? 2 : 0) 
+ /* SURFACE_BASE_UPDATE */
-   rctx->streamout.num_dw_for_end;
+   (rctx->family > CHIP_R600 && rctx->family < CHIP_RS780 ? 2 : 
0); /* SURFACE_BASE_UPDATE */
 
begin->dirty = true;
 }
-- 
1.8.3.2

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

[Mesa-dev] [PATCH 5/5] radeonsi: small cleanup in get_param

[Marek Olšák]

From: Marek Olšák 

---
 src/gallium/drivers/radeonsi/si_pipe.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_pipe.c 
b/src/gallium/drivers/radeonsi/si_pipe.c
index 0850269..827e9fe 100644
--- a/src/gallium/drivers/radeonsi/si_pipe.c
+++ b/src/gallium/drivers/radeonsi/si_pipe.c
@@ -258,11 +258,8 @@ static int si_get_param(struct pipe_screen* pscreen, enum 
pipe_cap param)
return HAVE_LLVM >= 0x0304 && (sscreen->b.chip_class < CIK ||
   sscreen->b.info.drm_minor >= 35);
 
-   case PIPE_CAP_TGSI_TEXCOORD:
-   return 0;
-
 case PIPE_CAP_MIN_MAP_BUFFER_ALIGNMENT:
-return 64;
+return R600_MAP_BUFFER_ALIGNMENT;
 
case PIPE_CAP_CONSTANT_BUFFER_OFFSET_ALIGNMENT:
case PIPE_CAP_TEXTURE_BUFFER_OFFSET_ALIGNMENT:
@@ -285,6 +282,7 @@ static int si_get_param(struct pipe_screen* pscreen, enum 
pipe_cap param)
case PIPE_CAP_CUBE_MAP_ARRAY:
case PIPE_CAP_MAX_TEXTURE_GATHER_COMPONENTS:
case PIPE_CAP_TEXTURE_GATHER_SM5:
+   case PIPE_CAP_TGSI_TEXCOORD:
return 0;
 
case PIPE_CAP_TEXTURE_BORDER_COLOR_QUIRK:
-- 
1.8.3.2

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

[Mesa-dev] [PATCH 4/5] radeonsi: set correct alignment for texture buffers and constant buffers

[Marek Olšák]

From: Marek Olšák 

I think these are all equivalent to vertex buffer fetches which should be
dword-aligned. Scalar loads are also dword-aligned.
---
 src/gallium/drivers/radeonsi/si_pipe.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_pipe.c 
b/src/gallium/drivers/radeonsi/si_pipe.c
index 0efd4eb..0850269 100644
--- a/src/gallium/drivers/radeonsi/si_pipe.c
+++ b/src/gallium/drivers/radeonsi/si_pipe.c
@@ -265,13 +265,12 @@ static int si_get_param(struct pipe_screen* pscreen, enum 
pipe_cap param)
 return 64;
 
case PIPE_CAP_CONSTANT_BUFFER_OFFSET_ALIGNMENT:
-   return 256;
+   case PIPE_CAP_TEXTURE_BUFFER_OFFSET_ALIGNMENT:
+   return 4;
 
case PIPE_CAP_GLSL_FEATURE_LEVEL:
return HAVE_LLVM >= 0x0305 ? 330 : 140;
 
-   case PIPE_CAP_TEXTURE_BUFFER_OFFSET_ALIGNMENT:
-   return 1;
case PIPE_CAP_MAX_TEXTURE_BUFFER_SIZE:
return MIN2(sscreen->b.info.vram_size, 0x);
 
-- 
1.8.3.2

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

[Mesa-dev] [PATCH 3/5] r600g, radeonsi: fix primitives-generated query with disabled streamout

[Marek Olšák]

From: Marek Olšák 

Buffers are disabled by VGT_STRMOUT_BUFFER_CONFIG, but the query only works
if VGT_STRMOUT_CONFIG.STREAMOUT_0_EN is enabled.

This moves VGT_STRMOUT_CONFIG to its own state. The register is set to 1
if either streamout or the primitives-generated query is enabled.

However, the primitives-emitted query is also incremented, so it's disabled
by setting VGT_STRMOUT_BUFFER_SIZE to 0 when there is no buffer bound.

This fixes piglit:
  ARB_transform_feedback2/counting with pause
  EXT_transform_feedback/primgen-query transform-feedback-disabled
---
 src/gallium/drivers/r600/evergreen_state.c|   9 +--
 src/gallium/drivers/r600/r600_hw_context.c|   2 +-
 src/gallium/drivers/r600/r600_pipe.h  |   2 +-
 src/gallium/drivers/r600/r600_state.c |   4 +-
 src/gallium/drivers/radeon/r600_pipe_common.h |   8 ++
 src/gallium/drivers/radeon/r600_query.c   |   2 +
 src/gallium/drivers/radeon/r600_streamout.c   | 105 --
 src/gallium/drivers/radeonsi/si_hw_context.c  |   1 +
 src/gallium/drivers/radeonsi/si_pipe.c|   1 +
 src/gallium/drivers/radeonsi/si_pipe.h|   1 +
 src/gallium/drivers/radeonsi/si_state.c   |   1 -
 11 files changed, 87 insertions(+), 49 deletions(-)

diff --git a/src/gallium/drivers/r600/evergreen_state.c 
b/src/gallium/drivers/r600/evergreen_state.c
index 5e57f8d..984cc84 100644
--- a/src/gallium/drivers/r600/evergreen_state.c
+++ b/src/gallium/drivers/r600/evergreen_state.c
@@ -2248,9 +2248,7 @@ static void cayman_init_atom_start_cs(struct r600_context 
*rctx)
r600_store_value(cb, 0); /* R_028A3C_VGT_GROUP_VECT_1_FMT_CNTL */
r600_store_value(cb, 0); /* R_028A40_VGT_GS_MODE */
 
-   r600_store_context_reg_seq(cb, R_028B94_VGT_STRMOUT_CONFIG, 2);
-   r600_store_value(cb, 0); /* R_028B94_VGT_STRMOUT_CONFIG */
-   r600_store_value(cb, 0); /* R_028B98_VGT_STRMOUT_BUFFER_CONFIG */
+   r600_store_context_reg(cb, R_028B98_VGT_STRMOUT_BUFFER_CONFIG, 0);
 
r600_store_context_reg_seq(cb, R_028AB4_VGT_REUSE_OFF, 2);
r600_store_value(cb, 0); /* R_028AB4_VGT_REUSE_OFF */
@@ -2809,9 +2807,7 @@ void evergreen_init_atom_start_cs(struct r600_context 
*rctx)
r600_store_value(cb, 0);
r600_store_value(cb, 0);
 
-   r600_store_context_reg_seq(cb, R_028B94_VGT_STRMOUT_CONFIG, 2);
-   r600_store_value(cb, 0); /* R_028B94_VGT_STRMOUT_CONFIG */
-   r600_store_value(cb, 0); /* R_028B98_VGT_STRMOUT_BUFFER_CONFIG */
+   r600_store_context_reg(cb, R_028B98_VGT_STRMOUT_BUFFER_CONFIG, 0);
 
if (rctx->screen->b.has_streamout) {
r600_store_context_reg(cb, 
R_028B28_VGT_STRMOUT_DRAW_OPAQUE_OFFSET, 0);
@@ -3495,6 +3491,7 @@ void evergreen_init_state_functions(struct r600_context 
*rctx)
r600_init_atom(rctx, &rctx->stencil_ref.atom, id++, 
r600_emit_stencil_ref, 4);
r600_init_atom(rctx, &rctx->vertex_fetch_shader.atom, id++, 
evergreen_emit_vertex_fetch_shader, 5);
rctx->atoms[id++] = &rctx->b.streamout.begin_atom;
+   rctx->atoms[id++] = &rctx->b.streamout.enable_atom;
r600_init_atom(rctx, &rctx->vertex_shader.atom, id++, r600_emit_shader, 
23);
r600_init_atom(rctx, &rctx->pixel_shader.atom, id++, r600_emit_shader, 
0);
r600_init_atom(rctx, &rctx->geometry_shader.atom, id++, 
r600_emit_shader, 0);
diff --git a/src/gallium/drivers/r600/r600_hw_context.c 
b/src/gallium/drivers/r600/r600_hw_context.c
index 3d0da2c..3a3b3d5 100644
--- a/src/gallium/drivers/r600/r600_hw_context.c
+++ b/src/gallium/drivers/r600/r600_hw_context.c
@@ -311,7 +311,7 @@ void r600_begin_new_cs(struct r600_context *ctx)
ctx->gs_rings.atom.dirty = true;
}
ctx->vertex_shader.atom.dirty = true;
-
+   ctx->b.streamout.enable_atom.dirty = true;
 
if (ctx->blend_state.cso)
ctx->blend_state.atom.dirty = true;
diff --git a/src/gallium/drivers/r600/r600_pipe.h 
b/src/gallium/drivers/r600/r600_pipe.h
index e5bb2b8..6d627e5 100644
--- a/src/gallium/drivers/r600/r600_pipe.h
+++ b/src/gallium/drivers/r600/r600_pipe.h
@@ -37,7 +37,7 @@
 #include "util/u_double_list.h"
 #include "util/u_transfer.h"
 
-#define R600_NUM_ATOMS 72
+#define R600_NUM_ATOMS 73
 
 /* the number of CS dwords for flushing and drawing */
 #define R600_MAX_FLUSH_CS_DWORDS   16
diff --git a/src/gallium/drivers/r600/r600_state.c 
b/src/gallium/drivers/r600/r600_state.c
index a0e6d2d..58ab1a2 100644
--- a/src/gallium/drivers/r600/r600_state.c
+++ b/src/gallium/drivers/r600/r600_state.c
@@ -2316,8 +2316,7 @@ void r600_init_atom_start_cs(struct r600_context *rctx)
r600_store_context_reg(cb, R_028AA0_VGT_INSTANCE_STEP_RATE_0, 0);
r600_store_context_reg(cb, R_028AA4_VGT_INSTANCE_STEP_RATE_1, 0);
 
-   r600_store_context_reg_seq(cb, R_028AB0_VGT_STRMOUT_EN, 3);
-   r600_store_value(cb, 0); /* R_028AB0_VGT_STRMOUT_EN */
+   r600_store_context_reg_seq(cb, R_028AB4_VGT_REUSE_OFF, 2);
  

[Mesa-dev] Question on OpenCL Image Support for r600g/radeonsi

[ANUJ SHARMA]

Hello Sir ,
  I am Anuj Sharma from India. I am pursuing my M.Tech Degree at Indian
Institute of Technology, Kanpur, India.
Sir Where Can i get the more detail on what should we need to implement for
the "OpenCL Image Support".

Thanks & regards
Anuj Sharma
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 0/3] formats.h clean-ups

[Michel Dänzer]

On Sam, 2014-03-08 at 18:28 -0700, Brian Paul wrote:
> This patch series:
> 1. removes an unnecessary section of comments.
> 2. Reorders the MESA_FORMAT_x enums to be more logical.
> 3. Renames MESA_FORMAT_X8Z24_UNORM
> 
> 
> Since it's hard to read from the diff, here's how the relevant part of 
> formats.h looks afterward (omitting a big comment block at the top):
> 
> [...]

Looks great to me.


-- 
Earthling Michel Dänzer|  http://www.amd.com
Libre software enthusiast  |Mesa and X developer

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

[Mesa-dev] [Bug 75797] EGL application crashes with BadDrawable at SwapBuffers

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=75797

Jasper St. Pierre  changed:

   What|Removed |Added

 CC||jstpie...@mecheye.net

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Wrong colors in 3D apps on big-endian systems

[Michel Dänzer]

On Sam, 2014-03-08 at 01:34 +0100, Christian Zigotzky wrote:
> Hi All,
> 
> I have figured out that the following definitions are not necessary for 
> big-endian systems in the file "src/gallium/include/pipe/p_format.h":
> 
> #if defined(PIPE_ARCH_LITTLE_ENDIAN)
> #define PIPE_FORMAT_RGBA_UNORM PIPE_FORMAT_R8G8B8A8_UNORM
> #define PIPE_FORMAT_RGBX_UNORM PIPE_FORMAT_R8G8B8X8_UNORM
> #define PIPE_FORMAT_BGRA_UNORM PIPE_FORMAT_B8G8R8A8_UNORM
> #define PIPE_FORMAT_BGRX_UNORM PIPE_FORMAT_B8G8R8X8_UNORM
> #define PIPE_FORMAT_ARGB_UNORM PIPE_FORMAT_A8R8G8B8_UNORM
> #define PIPE_FORMAT_XRGB_UNORM PIPE_FORMAT_X8R8G8B8_UNORM
> #define PIPE_FORMAT_ABGR_UNORM PIPE_FORMAT_A8B8G8R8_UNORM
> #define PIPE_FORMAT_XBGR_UNORM PIPE_FORMAT_X8B8G8R8_UNORM
> #elif defined(PIPE_ARCH_BIG_ENDIAN)
> #define PIPE_FORMAT_ABGR_UNORM PIPE_FORMAT_R8G8B8A8_UNORM
> #define PIPE_FORMAT_XBGR_UNORM PIPE_FORMAT_R8G8B8X8_UNORM
> #define PIPE_FORMAT_XRGB_UNORM PIPE_FORMAT_B8G8R8X8_UNORM
> #define PIPE_FORMAT_ARGB_UNORM PIPE_FORMAT_B8G8R8A8_UNORM
> #define PIPE_FORMAT_XRGB_UNORM PIPE_FORMAT_B8G8R8X8_UNORM
> #define PIPE_FORMAT_BGRA_UNORM PIPE_FORMAT_A8R8G8B8_UNORM
> #define PIPE_FORMAT_BGRX_UNORM PIPE_FORMAT_X8R8G8B8_UNORM
> #define PIPE_FORMAT_RGBA_UNORM PIPE_FORMAT_A8B8G8R8_UNORM
> #define PIPE_FORMAT_RGBX_UNORM PIPE_FORMAT_X8B8G8R8_UNORM
> #endif
> 
> This definitions for big-endian systems are responsible for the wrong 
> colors problem. I have commented out the big-endian definitions.
> 
> //#if defined(PIPE_ARCH_LITTLE_ENDIAN)
> #define PIPE_FORMAT_RGBA_UNORM PIPE_FORMAT_R8G8B8A8_UNORM
> #define PIPE_FORMAT_RGBX_UNORM PIPE_FORMAT_R8G8B8X8_UNORM
> #define PIPE_FORMAT_BGRA_UNORM PIPE_FORMAT_B8G8R8A8_UNORM
> #define PIPE_FORMAT_BGRX_UNORM PIPE_FORMAT_B8G8R8X8_UNORM
> #define PIPE_FORMAT_ARGB_UNORM PIPE_FORMAT_A8R8G8B8_UNORM
> #define PIPE_FORMAT_XRGB_UNORM PIPE_FORMAT_X8R8G8B8_UNORM
> #define PIPE_FORMAT_ABGR_UNORM PIPE_FORMAT_A8B8G8R8_UNORM
> #define PIPE_FORMAT_XBGR_UNORM PIPE_FORMAT_X8B8G8R8_UNORM
> //#elif defined(PIPE_ARCH_BIG_ENDIAN)
> //#define PIPE_FORMAT_ABGR_UNORM PIPE_FORMAT_R8G8B8A8_UNORM
> //#define PIPE_FORMAT_XBGR_UNORM PIPE_FORMAT_R8G8B8X8_UNORM
> //#define PIPE_FORMAT_XRGB_UNORM PIPE_FORMAT_B8G8R8X8_UNORM
> //#define PIPE_FORMAT_ARGB_UNORM PIPE_FORMAT_B8G8R8A8_UNORM
> //#define PIPE_FORMAT_XRGB_UNORM PIPE_FORMAT_B8G8R8X8_UNORM
> //#define PIPE_FORMAT_BGRA_UNORM PIPE_FORMAT_A8R8G8B8_UNORM
> //#define PIPE_FORMAT_BGRX_UNORM PIPE_FORMAT_X8R8G8B8_UNORM
> //#define PIPE_FORMAT_RGBA_UNORM PIPE_FORMAT_A8B8G8R8_UNORM
> //#define PIPE_FORMAT_RGBX_UNORM PIPE_FORMAT_X8B8G8R8_UNORM
> //#endif
> 
> And Mesa 10.1.0 works with the right colors on my PPC Linux system.

Congratulations, you just broke llvmpipe again on big endian systems. ;)
Did you even look at the commits introducing those defines? Did you
really think those defines, with explicit endianness checks, were
introduced for no reason but to break drivers on big endian systems?


I explained the problem in r600g and how it could be solved. Please
explore that.


-- 
Earthling Michel Dänzer|  http://www.amd.com
Libre software enthusiast  |Mesa and X developer

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

Re: [Mesa-dev] [PATCH 05/10] mesa: Stop skipping the FinishRenderTexture calls for winsys FBOs.

[Kenneth Graunke]

On 03/04/2014 02:17 PM, Eric Anholt wrote:
> Now that BindRenderbufferTexImage() is a thing that drivers can do, winsys
> FBOs *can* have NeedsFinishRenderTexture set.  The early exit here
> predated the NFRT flag, so it did make sense at the time.
> ---
>  src/mesa/main/fbobject.c | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
> index a9dcc51..12d6332 100644
> --- a/src/mesa/main/fbobject.c
> +++ b/src/mesa/main/fbobject.c
> @@ -2008,9 +2008,6 @@ check_begin_texture_render(struct gl_context *ctx, 
> struct gl_framebuffer *fb)
>  static void
>  check_end_texture_render(struct gl_context *ctx, struct gl_framebuffer *fb)
>  {
> -   if (_mesa_is_winsys_fbo(fb))
> -  return; /* can't render to texture with winsys framebuffers */
> -
> if (ctx->Driver.FinishRenderTexture) {
>GLuint i;
>for (i = 0; i < BUFFER_COUNT; i++) {
> 

The asymmetry here strikes me as a little odd...now you can have
FinishRenderTexture called for renderbuffers, but RenderTexture still
retains the "no winsys fbos" check.  I guess that makes some sense,
since the driver is already handling BindRenderbufferTexImage, so
there's no need for a second "begin" hook.

This is all fairly theoretical though: i965 is the only driver that
exposes BindRenderbufferTexImage, and it no longer has RenderTexture or
FinishRenderTexture hooks.

So, you could actually drop this patch.  But I'm not thrilled about
that, since other drivers may implement BindRenderbufferTexImage, and
would almost certainly forget this.

Maybe instead change it to:
if (_mesa_is_winsys_fbo(fb) && !ctx->Driver.BindRenderbufferTexImage)

That avoids the overhead of the BUFFER_COUNT loop for existing drivers.

*shrug*



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] radeonsi: Use proper member name for deleting export shader PM4 state

[Michel Dänzer]

From: Michel Dänzer 

Fixes double-free with some piglit tests using geometry shaders.

Signed-off-by: Michel Dänzer 
---
 src/gallium/drivers/radeonsi/si_state.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/gallium/drivers/radeonsi/si_state.c 
b/src/gallium/drivers/radeonsi/si_state.c
index 0ee4154..7d4f3c7 100644
--- a/src/gallium/drivers/radeonsi/si_state.c
+++ b/src/gallium/drivers/radeonsi/si_state.c
@@ -2360,6 +2360,8 @@ static void si_delete_shader_selector(struct pipe_context 
*ctx,
si_pm4_delete_state(sctx, gs, p->pm4);
else if (sel->type == PIPE_SHADER_FRAGMENT)
si_pm4_delete_state(sctx, ps, p->pm4);
+   else if (p->key.vs.as_es)
+   si_pm4_delete_state(sctx, es, p->pm4);
else
si_pm4_delete_state(sctx, vs, p->pm4);
si_pipe_shader_destroy(ctx, p);
-- 
1.9.0

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

Re: [Mesa-dev] [PATCH] radeonsi: Use proper member name for deleting export shader PM4 state

[Marek Olšák]

Reviewed-by: Marek Olšák 

Marek

On Mon, Mar 10, 2014 at 4:36 AM, Michel Dänzer  wrote:
> From: Michel Dänzer 
>
> Fixes double-free with some piglit tests using geometry shaders.
>
> Signed-off-by: Michel Dänzer 
> ---
>  src/gallium/drivers/radeonsi/si_state.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/src/gallium/drivers/radeonsi/si_state.c 
> b/src/gallium/drivers/radeonsi/si_state.c
> index 0ee4154..7d4f3c7 100644
> --- a/src/gallium/drivers/radeonsi/si_state.c
> +++ b/src/gallium/drivers/radeonsi/si_state.c
> @@ -2360,6 +2360,8 @@ static void si_delete_shader_selector(struct 
> pipe_context *ctx,
> si_pm4_delete_state(sctx, gs, p->pm4);
> else if (sel->type == PIPE_SHADER_FRAGMENT)
> si_pm4_delete_state(sctx, ps, p->pm4);
> +   else if (p->key.vs.as_es)
> +   si_pm4_delete_state(sctx, es, p->pm4);
> else
> si_pm4_delete_state(sctx, vs, p->pm4);
> si_pipe_shader_destroy(ctx, p);
> --
> 1.9.0
>
> ___
> 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 02/10] i965: Drop broken front_buffer_reading/drawing optimization.

[Kenneth Graunke]

On 03/04/2014 02:17 PM, Eric Anholt wrote:
> The flag wasn't getting updated correctly when the ctx->DrawBuffer or
> ctx->ReadBuffer changed.  It usually ended up working out because most
> apps only have one window system framebuffer, or if they have more than
> one and they have any front read/drawing, they will have called
> glReadBuffer()/glDrawBuffer() on it when they get started on the new
> buffer.

Yep, it sure doesn't look like they're getting updated when the buffers
change.  I like your fix here.

Patches 1-4 are:
Reviewed-by: Kenneth Graunke 




signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 06/10] i965: Change the winsys MSAA blits from blorp to meta.

[Kenneth Graunke]

On 03/04/2014 02:17 PM, Eric Anholt wrote:
> This gets us equivalent code paths on BDW and pre-BDW, except for stencil
> (where we don't have MSAA stencil resolve code yet)
> ---
>  src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 111 
> --
>  1 file changed, 103 insertions(+), 8 deletions(-)

A couple of comments below...

> diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c 
> b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> index 202bb52..3c09a42 100644
> --- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> +++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> @@ -40,12 +40,16 @@
>  #include "brw_blorp.h"
>  #include "brw_context.h"
>  
> +#include "main/blit.h"
> +#include "main/buffers.h"
>  #include "main/enums.h"
> +#include "main/fbobject.h"
>  #include "main/formats.h"
>  #include "main/glformats.h"
>  #include "main/texcompress_etc.h"
>  #include "main/teximage.h"
>  #include "main/streaming-load-memcpy.h"
> +#include "drivers/common/meta.h"
>  
>  #define FILE_DEBUG_FLAG DEBUG_MIPTREE
>  
> @@ -1538,19 +1542,110 @@ intel_offset_S8(uint32_t stride, uint32_t x, 
> uint32_t y, bool swizzled)
> return u;
>  }
>  

/**
 * Creates a new named renderbuffer that wraps the first slice
 * of an existing miptree.
 *
 * Clobbers the current renderbuffer binding (ctx->CurrentRenderbuffer).
 */

> +static void
> +intel_rb_storage_first_mt_slice(struct brw_context *brw,
> +GLuint rbo,
> +struct intel_mipmap_tree *mt)
> +{
> +   struct gl_context *ctx = &brw->ctx;
> +   struct gl_renderbuffer *rb;
> +   struct intel_renderbuffer *irb;
> +

Perhaps move the GenRenderbuffers call into this function, and make it
return the RB number?  Having the name generation and actual
renderbuffer structure population in separate functions seems a little
strange to me.  Just an idea, though; I could be convinced otherwise.

> +   /* This turns the GenRenderbuffers name into an actual struct
> +* intel_renderbuffer.
> +*/
> +   _mesa_BindRenderbuffer(GL_RENDERBUFFER, rbo);
> +
> +   rb = ctx->CurrentRenderbuffer;
> +   irb = intel_renderbuffer(rb);
> +
> +   rb->Format = mt->format;
> +   rb->_BaseFormat = _mesa_base_fbo_format(ctx, mt->format);
> +
> +   rb->NumSamples = mt->num_samples;
> +   rb->Width = mt->logical_width0;
> +   rb->Height = mt->logical_height0;
> +
> +   intel_miptree_reference(&irb->mt, mt);
> +}
> +
> +/**
> + * Implementation of up or downsampling for window-system MSAA miptrees.
> + */
> +static void
> +intel_miptree_msaa_copy(struct brw_context *brw,
> +struct intel_mipmap_tree *src_mt,
> +struct intel_mipmap_tree *dst_mt)

This code looks reasonable, but I'm not crazy about it living here in
intel_mipmap_tree.c with names like intel_mipmap_do_stuff().  Normally,
I think of intel_mipmap_tree.c/intel_mipmap_...() functions as the core
miptree support.

It's the first code outside of meta*.c that calls _mesa_meta_begin/end,
and the only code in intel_mipmap_tree.c that calls API functions like
_mesa_BindRenderbuffer.  So, it looks rather surprising at first glance.

Putting it in another file might help, but that may be overkill.  I'd at
least like to see "_meta_" in the names.  Perhaps
brw_meta_updownsample() or such?

> +{
> +   struct gl_context *ctx = &brw->ctx;
> +   GLuint rbos[2], fbos[2], src_rbo, dst_rbo, src_fbo, dst_fbo;
> +   GLenum drawbuffer;
> +   GLbitfield attachment, blit_bit;
> +
> +   if (_mesa_get_format_base_format(src_mt->format) == GL_DEPTH_COMPONENT ||
> +   _mesa_get_format_base_format(src_mt->format) == GL_DEPTH_STENCIL) {
> +  attachment = GL_DEPTH_ATTACHMENT;
> +  drawbuffer = GL_NONE;
> +  blit_bit = GL_DEPTH_BUFFER_BIT;
> +   } else {
> +  attachment = GL_COLOR_ATTACHMENT0;
> +  drawbuffer = GL_COLOR_ATTACHMENT0;
> +  blit_bit = GL_COLOR_BUFFER_BIT;
> +   }
> +
> +   intel_batchbuffer_emit_mi_flush(brw);
> +
> +   _mesa_meta_begin(ctx, MESA_META_ALL);
> +   _mesa_GenRenderbuffers(2, rbos);
> +   _mesa_GenFramebuffers(2, fbos);
> +   src_rbo = rbos[0];
> +   dst_rbo = rbos[1];
> +   src_fbo = fbos[0];
> +   dst_fbo = fbos[1];
> +
> +   _mesa_BindFramebuffer(GL_READ_FRAMEBUFFER, src_fbo);
> +   intel_rb_storage_first_mt_slice(brw, src_rbo, src_mt);
> +   _mesa_FramebufferRenderbuffer(GL_READ_FRAMEBUFFER, attachment,
> + GL_RENDERBUFFER, src_rbo);
> +   _mesa_ReadBuffer(drawbuffer);
> +
> +   _mesa_BindFramebuffer(GL_DRAW_FRAMEBUFFER, dst_fbo);
> +   intel_rb_storage_first_mt_slice(brw, dst_rbo, dst_mt);
> +   _mesa_FramebufferRenderbuffer(GL_DRAW_FRAMEBUFFER, attachment,
> + GL_RENDERBUFFER, dst_rbo);
> +   _mesa_DrawBuffer(drawbuffer);
> +
> +   _mesa_BlitFramebuffer(0, 0,
> + src_mt->logical_width0, src_mt->logical_height0,
> + 0, 0,
> + dst_mt->logical_width

Re: [Mesa-dev] [PATCH 08/10] i965: Remove the blorp CTSI path.

[Kenneth Graunke]

On 03/04/2014 02:17 PM, Eric Anholt wrote:
> The meta patch supports all the same, except for the stencil case being
> unaccelerated.
> ---
>  src/mesa/drivers/dri/i965/brw_blorp_blit.cpp | 105 
> ---
>  src/mesa/drivers/dri/i965/brw_context.h  |   9 ---
>  src/mesa/drivers/dri/i965/intel_tex_copy.c   |   9 +--
>  3 files changed, 1 insertion(+), 122 deletions(-)
> 
> diff --git a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp 
> b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
> index acdc9c7..fbed8ce 100644
> --- a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
> @@ -334,111 +334,6 @@ try_blorp_blit(struct brw_context *brw,
> return true;
>  }
>  
> -bool
> -brw_blorp_copytexsubimage(struct brw_context *brw,
> -  struct gl_renderbuffer *src_rb,
> -  struct gl_texture_image *dst_image,
> -  int slice,
> -  int srcX0, int srcY0,
> -  int dstX0, int dstY0,
> -  int width, int height)
> -{
> -   struct gl_context *ctx = &brw->ctx;
> -   struct intel_renderbuffer *src_irb = intel_renderbuffer(src_rb);
> -   struct intel_texture_image *intel_image = intel_texture_image(dst_image);
> -
> -   /* Sync up the state of window system buffers.  We need to do this before
> -* we go looking at the src renderbuffer's miptree.
> -*/
> -   intel_prepare_render(brw);
> -
> -   struct intel_mipmap_tree *src_mt = src_irb->mt;
> -   struct intel_mipmap_tree *dst_mt = intel_image->mt;
> -
> -   /* BLORP is not supported before Gen6. */
> -   if (brw->gen < 6 || brw->gen >= 8)
> -  return false;
> -
> -   if (_mesa_get_format_base_format(src_mt->format) !=
> -   _mesa_get_format_base_format(dst_mt->format)) {
> -  return false;
> -   }
> -
> -   /* We can't handle format conversions between Z24 and other formats since
> -* we have to lie about the surface format.  See the comments in
> -* brw_blorp_surface_info::set().
> -*/
> -   if ((src_mt->format == MESA_FORMAT_Z24_UNORM_X8_UINT) !=
> -   (dst_mt->format == MESA_FORMAT_Z24_UNORM_X8_UINT)) {
> -  return false;
> -   }
> -
> -   if (!brw->format_supported_as_render_target[dst_mt->format])
> -  return false;
> -
> -   /* Source clipping shouldn't be necessary, since copytexsubimage (in
> -* src/mesa/main/teximage.c) calls _mesa_clip_copytexsubimage() which
> -* takes care of it.
> -*
> -* Destination clipping shouldn't be necessary since the restrictions on
> -* glCopyTexSubImage prevent the user from specifying a destination 
> rectangle
> -* that falls outside the bounds of the destination texture.
> -* See error_check_subtexture_dimensions().
> -*/
> -
> -   int srcY1 = srcY0 + height;
> -   int srcX1 = srcX0 + width;
> -   int dstX1 = dstX0 + width;
> -   int dstY1 = dstY0 + height;
> -
> -   /* Account for the fact that in the system framebuffer, the origin is at
> -* the lower left.
> -*/
> -   bool mirror_y = false;
> -   if (_mesa_is_winsys_fbo(ctx->ReadBuffer)) {
> -  GLint tmp = src_rb->Height - srcY0;
> -  srcY0 = src_rb->Height - srcY1;
> -  srcY1 = tmp;
> -  mirror_y = true;
> -   }
> -
> -   brw_blorp_blit_miptrees(brw,
> -   src_mt, src_irb->mt_level, src_irb->mt_layer,
> -   dst_mt, dst_image->Level, dst_image->Face + slice,
> -   srcX0, srcY0, srcX1, srcY1,
> -   dstX0, dstY0, dstX1, dstY1,
> -   GL_NEAREST, false, mirror_y);
> -
> -   /* If we're copying to a packed depth stencil texture and the source
> -* framebuffer has separate stencil, we need to also copy the stencil data
> -* over.
> -*/
> -   src_rb = ctx->ReadBuffer->Attachment[BUFFER_STENCIL].Renderbuffer;
> -   if (_mesa_get_format_bits(dst_image->TexFormat, GL_STENCIL_BITS) > 0 &&
> -   src_rb != NULL) {
> -  src_irb = intel_renderbuffer(src_rb);
> -  src_mt = src_irb->mt;
> -
> -  if (src_mt->stencil_mt)
> - src_mt = src_mt->stencil_mt;
> -  if (dst_mt->stencil_mt)
> - dst_mt = dst_mt->stencil_mt;
> -
> -  if (src_mt != dst_mt) {
> - brw_blorp_blit_miptrees(brw,
> - src_mt, src_irb->mt_level, 
> src_irb->mt_layer,
> - dst_mt, dst_image->Level,
> - dst_image->Face + slice,
> - srcX0, srcY0, srcX1, srcY1,
> - dstX0, dstY0, dstX1, dstY1,
> - GL_NEAREST, false, mirror_y);
> -  }
> -   }
> -
> -   return true;
> -}
> -
> -
>  GLbitfield
>  brw_blorp_framebuffer(struct brw_context *brw,
>GLint srcX0, GLint srcY0, GLint srcX1, GLint srcY1,
> diff --git a/src/mesa/drivers/dri/i965/brw_context.h 

Re: [Mesa-dev] [PATCH 09/10] meta: Add support for MSAA resolves from 2D_MS_ARRAY textures.

[Kenneth Graunke]

On 03/04/2014 02:17 PM, Eric Anholt wrote:
> ---
>  src/mesa/drivers/common/meta.h  |  8 
>  src/mesa/drivers/common/meta_blit.c | 23 +++
>  2 files changed, 27 insertions(+), 4 deletions(-)
> 
> diff --git a/src/mesa/drivers/common/meta.h b/src/mesa/drivers/common/meta.h
> index 00553e2..5d60690 100644
> --- a/src/mesa/drivers/common/meta.h
> +++ b/src/mesa/drivers/common/meta.h
> @@ -238,6 +238,14 @@ enum blit_msaa_shader {
> BLIT_MSAA_SHADER_2D_MULTISAMPLE_COPY_UINT,
> BLIT_MSAA_SHADER_2D_MULTISAMPLE_DEPTH_RESOLVE,
> BLIT_MSAA_SHADER_2D_MULTISAMPLE_DEPTH_COPY,
> +   BLIT_MSAA_SHADER_2D_MULTISAMPLE_ARRAY_RESOLVE,
> +   BLIT_MSAA_SHADER_2D_MULTISAMPLE_ARRAY_RESOLVE_INT,
> +   BLIT_MSAA_SHADER_2D_MULTISAMPLE_ARRAY_RESOLVE_UINT,
> +   BLIT_MSAA_SHADER_2D_MULTISAMPLE_ARRAY_COPY,
> +   BLIT_MSAA_SHADER_2D_MULTISAMPLE_ARRAY_COPY_INT,
> +   BLIT_MSAA_SHADER_2D_MULTISAMPLE_ARRAY_COPY_UINT,
> +   BLIT_MSAA_SHADER_2D_MULTISAMPLE_ARRAY_DEPTH_RESOLVE,
> +   BLIT_MSAA_SHADER_2D_MULTISAMPLE_ARRAY_DEPTH_COPY,
> BLIT_MSAA_SHADER_COUNT,
>  };
>  
> diff --git a/src/mesa/drivers/common/meta_blit.c 
> b/src/mesa/drivers/common/meta_blit.c
> index 9756d86..550133f 100644
> --- a/src/mesa/drivers/common/meta_blit.c
> +++ b/src/mesa/drivers/common/meta_blit.c
> @@ -97,6 +97,7 @@ setup_glsl_msaa_blit_shader(struct gl_context *ctx,
> bool dst_is_msaa = false;
> GLenum src_datatype;
> const char *vec4_prefix;
> +   const char *sampler_array_suffix = "";
> char *name;
>  
> if (src_rb) {
> @@ -125,6 +126,7 @@ setup_glsl_msaa_blit_shader(struct gl_context *ctx,
>  
> switch (target) {
> case GL_TEXTURE_2D_MULTISAMPLE:
> +   case GL_TEXTURE_2D_MULTISAMPLE_ARRAY:
>if (src_rb->_BaseFormat == GL_DEPTH_COMPONENT ||
>src_rb->_BaseFormat == GL_DEPTH_STENCIL) {
>   if (dst_is_msaa)
> @@ -137,6 +139,12 @@ setup_glsl_msaa_blit_shader(struct gl_context *ctx,
>   else
>  shader_index = BLIT_MSAA_SHADER_2D_MULTISAMPLE_RESOLVE;
>}
> +
> +  if (target == GL_TEXTURE_2D_MULTISAMPLE_ARRAY) {
> + shader_index += (BLIT_MSAA_SHADER_2D_MULTISAMPLE_ARRAY_RESOLVE -
> +  BLIT_MSAA_SHADER_2D_MULTISAMPLE_RESOLVE);
> + sampler_array_suffix = "Array";
> +  }
>break;
> default:
>_mesa_problem(ctx, "Unkown texture target %s\n",
> @@ -167,6 +175,8 @@ setup_glsl_msaa_blit_shader(struct gl_context *ctx,
> mem_ctx = ralloc_context(NULL);
>  
> if (shader_index == BLIT_MSAA_SHADER_2D_MULTISAMPLE_DEPTH_RESOLVE ||
> +   shader_index == BLIT_MSAA_SHADER_2D_MULTISAMPLE_ARRAY_DEPTH_RESOLVE ||
> +   shader_index == BLIT_MSAA_SHADER_2D_MULTISAMPLE_ARRAY_DEPTH_COPY ||
> shader_index == BLIT_MSAA_SHADER_2D_MULTISAMPLE_DEPTH_COPY) {
>char *sample_index;
>const char *arb_sample_shading_extension_string;
> @@ -208,7 +218,7 @@ setup_glsl_msaa_blit_shader(struct gl_context *ctx,
>"#version 130\n"
>"#extension GL_ARB_texture_multisample : 
> enable\n"
>"%s\n"
> -  "uniform sampler2DMS texSampler;\n"
> +  "uniform sampler2DMS%s texSampler;\n"
>"in vec2 texCoords;\n"
>"out vec4 out_color;\n"
>"\n"
> @@ -217,6 +227,7 @@ setup_glsl_msaa_blit_shader(struct gl_context *ctx,
>"   gl_FragDepth = texelFetch(texSampler, 
> ivec2(texCoords), %s).r;\n"
>"}\n",
>arb_sample_shading_extension_string,
> +  sampler_array_suffix,
>sample_index);
> } else {
>/* You can create 2D_MULTISAMPLE textures with 0 sample count (meaning 
> 1
> @@ -306,7 +317,7 @@ setup_glsl_msaa_blit_shader(struct gl_context *ctx,
>"#extension GL_ARB_texture_multisample : 
> enable\n"
>"%s\n"
>"#define gvec4 %svec4\n"
> -  "uniform %ssampler2DMS texSampler;\n"
> +  "uniform %ssampler2DMS%s texSampler;\n"
>"in vec2 texCoords;\n"
>"out gvec4 out_color;\n"
>"\n"
> @@ -318,6 +329,7 @@ setup_glsl_msaa_blit_shader(struct gl_context *ctx,
>arb_sample_shading_extension_string,
>vec4_prefix,
>vec4_prefix,
> +  sampler_array_suffix,
>merge_function,
>sample_