Re: [Mesa-dev] [PATCH] nir: copy front interpolation when creating fake back color input

[Rob Clark]

On Fri, Jul 7, 2017 at 8:34 PM, Ilia Mirkin  wrote:
> Fixes a bunch of gl_BackColor interpolation tests that had explicit
> interpolation specified on the fragment shader gl_Color.
>
> Signed-off-by: Ilia Mirkin 

(as mentioned on irc, but repeated here for posterity)

Reviewed-by: Rob Clark 

> ---
>  src/compiler/nir/nir_lower_two_sided_color.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/src/compiler/nir/nir_lower_two_sided_color.c 
> b/src/compiler/nir/nir_lower_two_sided_color.c
> index 7d1a3bd236d..90da1013ec8 100644
> --- a/src/compiler/nir/nir_lower_two_sided_color.c
> +++ b/src/compiler/nir/nir_lower_two_sided_color.c
> @@ -46,7 +46,8 @@ typedef struct {
>   */
>
>  static nir_variable *
> -create_input(nir_shader *shader, unsigned drvloc, gl_varying_slot slot)
> +create_input(nir_shader *shader, unsigned drvloc, gl_varying_slot slot,
> + enum glsl_interp_mode interpolation)
>  {
> nir_variable *var = rzalloc(shader, nir_variable);
>
> @@ -56,6 +57,7 @@ create_input(nir_shader *shader, unsigned drvloc, 
> gl_varying_slot slot)
> var->name = ralloc_asprintf(var, "in_%d", drvloc);
> var->data.index = 0;
> var->data.location = slot;
> +   var->data.interpolation = interpolation;
>
> exec_list_push_tail(>inputs, >node);
>
> @@ -116,7 +118,9 @@ setup_inputs(lower_2side_state *state)
>else
>   slot = VARYING_SLOT_BFC1;
>
> -  state->colors[i].back = create_input(state->shader, ++maxloc, slot);
> +  state->colors[i].back = create_input(
> +state->shader, ++maxloc, slot,
> +state->colors[i].front->data.interpolation);
> }
>
> return 0;
> --
> 2.13.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 99856] OpenCL Hello world returns "unsupported call to function get_local_size"

[bugzilla-daemon]

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

EoD  changed:

   What|Removed |Added

 CC||e...@xmw.de

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

Re: [Mesa-dev] [PATCH 1/2] vbo: fix glPrimitiveRestartNV crash inside a display list

[Andres Gomez]

It looks like we could want this series into -stable (?)

On Fri, 2017-07-07 at 08:10 -0600, Brian Paul wrote:
> From: Olivier Lauffenburger 
> 
> glPrimitiveRestartNV crashes when it is called during the compilation
> of a display list.
> 
> There are two reasons:
> - ctx->Driver.CurrentSavePrimitive is not set to the current primitive
> - save_PrimitiveRestartNV() calls _save_Begin() which only sets an
>   OpenGL error, instead of calling vbo_save_NotifyBegin().
> 
> This patch correctly calls vbo_save_NotifyBegin() but it detects
> the current primitive mode by looking at the latest saved primitive.
> 
> Additional work by Brian Paul
> 
> Signed-off-by: Olivier Lauffenburger 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101464
> Reviewed-by: Brian Paul 
> ---
>  src/mesa/vbo/vbo_save_api.c | 20 +++-
>  1 file changed, 15 insertions(+), 5 deletions(-)
> 
> diff --git a/src/mesa/vbo/vbo_save_api.c b/src/mesa/vbo/vbo_save_api.c
> index a42a3c3..aab5f54 100644
> --- a/src/mesa/vbo/vbo_save_api.c
> +++ b/src/mesa/vbo/vbo_save_api.c
> @@ -1108,13 +1108,23 @@ _save_Begin(GLenum mode)
>  static void GLAPIENTRY
>  _save_PrimitiveRestartNV(void)
>  {
> -   GLenum curPrim;
> GET_CURRENT_CONTEXT(ctx);
> +   struct vbo_save_context *save = _context(ctx)->save;
>  
> -   curPrim = ctx->Driver.CurrentSavePrimitive;
> -
> -   _save_End();
> -   _save_Begin(curPrim);
> +   if (save->prim_count == 0) {
> +  /* We're not inside a glBegin/End pair, so calling 
> glPrimitiverRestartNV
> +   * is an error.
> +   */
> +  _mesa_compile_error(ctx, GL_INVALID_OPERATION,
> +  "glPrimitiveRestartNV called outside glBegin/End");
> +   } else {
> +  /* get current primitive mode */
> +  GLenum curPrim = save->prim[save->prim_count - 1].mode;
> +
> +  /* restart primitive */
> +  CALL_End(GET_DISPATCH(), ());
> +  vbo_save_NotifyBegin(ctx, curPrim);
> +   }
>  }
>  
>  
-- 
Br,

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

Re: [Mesa-dev] [PATCH] gallium: use "ull" number suffix to keep the QtCreator parser happy

[Thomas Helland]

Yes please!
I find this much more intuitive, as a bonus =)

Reviewed-by: Thomas Helland 

2017-07-08 2:36 GMT+02:00 Marek Olšák :
> From: Marek Olšák 
>
> It can't parse "llu".
> ---
>  src/gallium/drivers/r600/r600_state_common.c|  4 +--
>  src/gallium/drivers/radeon/r600_pipe_common.h   | 44 
> -
>  src/gallium/drivers/radeonsi/si_debug.c |  4 +--
>  src/gallium/drivers/radeonsi/si_shader.c|  2 +-
>  src/gallium/drivers/radeonsi/si_state_shaders.c | 10 +++---
>  src/gallium/winsys/amdgpu/drm/amdgpu_cs.c   |  2 +-
>  src/gallium/winsys/radeon/drm/radeon_drm_cs.c   |  2 +-
>  src/mesa/state_tracker/st_atom.h|  4 +--
>  8 files changed, 36 insertions(+), 36 deletions(-)
>
> diff --git a/src/gallium/drivers/r600/r600_state_common.c 
> b/src/gallium/drivers/r600/r600_state_common.c
> index 8ace779..4c97efa 100644
> --- a/src/gallium/drivers/r600/r600_state_common.c
> +++ b/src/gallium/drivers/r600/r600_state_common.c
> @@ -840,25 +840,25 @@ static void *r600_create_shader_state(struct 
> pipe_context *ctx,
>
> for (i = 0; i < sel->info.num_outputs; i++) {
> unsigned name = sel->info.output_semantic_name[i];
> unsigned index = sel->info.output_semantic_index[i];
>
> switch (name) {
> case TGSI_SEMANTIC_TESSINNER:
> case TGSI_SEMANTIC_TESSOUTER:
> case TGSI_SEMANTIC_PATCH:
> sel->lds_patch_outputs_written_mask |=
> -   1llu << 
> r600_get_lds_unique_index(name, index);
> +   1ull << 
> r600_get_lds_unique_index(name, index);
> break;
> default:
> sel->lds_outputs_written_mask |=
> -   1llu << 
> r600_get_lds_unique_index(name, index);
> +   1ull << 
> r600_get_lds_unique_index(name, index);
> }
> }
> break;
> default:
> break;
> }
>
> return sel;
>  }
>
> diff --git a/src/gallium/drivers/radeon/r600_pipe_common.h 
> b/src/gallium/drivers/radeon/r600_pipe_common.h
> index b22a3a7..5c761f3 100644
> --- a/src/gallium/drivers/radeon/r600_pipe_common.h
> +++ b/src/gallium/drivers/radeon/r600_pipe_common.h
> @@ -83,42 +83,42 @@
>  #define DBG_NO_TGSI(1 << 13)
>  #define DBG_NO_ASM (1 << 14)
>  #define DBG_PREOPT_IR  (1 << 15)
>  #define DBG_CHECK_IR   (1 << 16)
>  #define DBG_NO_OPT_VARIANT (1 << 17)
>  #define DBG_FS_CORRECT_DERIVS_AFTER_KILL (1 << 18)
>  /* gaps */
>  #define DBG_TEST_DMA   (1 << 20)
>  /* Bits 21-31 are reserved for the r600g driver. */
>  /* features */
> -#define DBG_NO_ASYNC_DMA   (1llu << 32)
> -#define DBG_NO_HYPERZ  (1llu << 33)
> -#define DBG_NO_DISCARD_RANGE   (1llu << 34)
> -#define DBG_NO_2D_TILING   (1llu << 35)
> -#define DBG_NO_TILING  (1llu << 36)
> -#define DBG_SWITCH_ON_EOP  (1llu << 37)
> -#define DBG_FORCE_DMA  (1llu << 38)
> -#define DBG_PRECOMPILE (1llu << 39)
> -#define DBG_INFO   (1llu << 40)
> -#define DBG_NO_WC  (1llu << 41)
> -#define DBG_CHECK_VM   (1llu << 42)
> -#define DBG_NO_DCC (1llu << 43)
> -#define DBG_NO_DCC_CLEAR   (1llu << 44)
> -#define DBG_NO_RB_PLUS (1llu << 45)
> -#define DBG_SI_SCHED   (1llu << 46)
> -#define DBG_MONOLITHIC_SHADERS (1llu << 47)
> -#define DBG_NO_CE  (1llu << 48)
> -#define DBG_UNSAFE_MATH(1llu << 49)
> -#define DBG_NO_DCC_FB  (1llu << 50)
> -#define DBG_TEST_VMFAULT_CP(1llu << 51)
> -#define DBG_TEST_VMFAULT_SDMA  (1llu << 52)
> -#define DBG_TEST_VMFAULT_SHADER(1llu << 53)
> +#define DBG_NO_ASYNC_DMA   (1ull << 32)
> +#define DBG_NO_HYPERZ  (1ull << 33)
> +#define DBG_NO_DISCARD_RANGE   (1ull << 34)
> +#define DBG_NO_2D_TILING   (1ull << 35)
> +#define DBG_NO_TILING  (1ull << 36)
> +#define DBG_SWITCH_ON_EOP  (1ull << 37)
> +#define DBG_FORCE_DMA  (1ull << 38)
> +#define DBG_PRECOMPILE (1ull << 39)
> +#define DBG_INFO   (1ull << 40)
> +#define DBG_NO_WC  (1ull << 41)
> +#define DBG_CHECK_VM   (1ull << 42)
> +#define DBG_NO_DCC (1ull << 43)
> +#define DBG_NO_DCC_CLEAR   (1ull << 44)
> +#define DBG_NO_RB_PLUS (1ull << 45)
> +#define DBG_SI_SCHED   (1ull << 46)
> +#define DBG_MONOLITHIC_SHADERS (1ull << 47)
> +#define DBG_NO_CE  (1ull << 48)
> +#define DBG_UNSAFE_MATH(1ull << 49)
> +#define DBG_NO_DCC_FB  (1ull << 50)
> +#define DBG_TEST_VMFAULT_CP(1ull 

[Mesa-dev] [PATCH] gallium/util: Remove unused keymap

[Thomas Helland]

This is not used anywhere in the codebase. It's a hashtable
implementation that is based around cso_hash, and is therefore
(and as mentioned in a comment in the source) quite similar to
u_hash_table.

CC: Brian Paul
---
 src/gallium/auxiliary/Makefile.sources |   2 -
 src/gallium/auxiliary/util/u_keymap.c  | 318 -
 src/gallium/auxiliary/util/u_keymap.h  |  68 ---
 3 files changed, 388 deletions(-)
 delete mode 100644 src/gallium/auxiliary/util/u_keymap.c
 delete mode 100644 src/gallium/auxiliary/util/u_keymap.h

diff --git a/src/gallium/auxiliary/Makefile.sources 
b/src/gallium/auxiliary/Makefile.sources
index 9ae8e6c8ca..cdf7e0aa35 100644
--- a/src/gallium/auxiliary/Makefile.sources
+++ b/src/gallium/auxiliary/Makefile.sources
@@ -256,8 +256,6 @@ C_SOURCES := \
util/u_index_modify.c \
util/u_index_modify.h \
util/u_inlines.h \
-   util/u_keymap.c \
-   util/u_keymap.h \
util/u_linear.c \
util/u_linear.h \
util/u_math.c \
diff --git a/src/gallium/auxiliary/util/u_keymap.c 
b/src/gallium/auxiliary/util/u_keymap.c
deleted file mode 100644
index daa2991ced..00
--- a/src/gallium/auxiliary/util/u_keymap.c
+++ /dev/null
@@ -1,318 +0,0 @@
-/**
- *
- * Copyright 2008 VMware, Inc.
- * All Rights Reserved.
- *
- * Permission is hereby granted, free of charge, to any person obtaining a
- * copy of this software and associated documentation files (the
- * "Software"), to deal in the Software without restriction, including
- * without limitation the rights to use, copy, modify, merge, publish,
- * distribute, sub license, and/or sell copies of the Software, and to
- * permit persons to whom the Software is furnished to do so, subject to
- * the following conditions:
- *
- * The above copyright notice and this permission notice (including the
- * next paragraph) shall be included in all copies or substantial portions
- * of the Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
- * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
- * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT.
- * IN NO EVENT SHALL VMWARE AND/OR ITS SUPPLIERS BE LIABLE FOR
- * ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
- * TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
- * SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
- *
- **/
-
-/**
- * Key lookup/associative container.
- *
- * Like Jose's util_hash_table, based on CSO cache code for now.
- *
- * Author: Brian Paul
- */
-
-
-#include "pipe/p_compiler.h"
-#include "util/u_debug.h"
-
-#include "cso_cache/cso_hash.h"
-
-#include "util/u_memory.h"
-#include "util/u_keymap.h"
-
-
-struct keymap
-{
-   struct cso_hash *cso;   
-   unsigned key_size;
-   unsigned max_entries; /* XXX not obeyed net */
-   unsigned num_entries;
-   keymap_delete_func delete_func;
-};
-
-
-struct keymap_item
-{
-   void *key, *value;
-};
-
-
-/**
- * This the default key-delete function used when the client doesn't
- * provide one.
- */
-static void
-default_delete_func(const struct keymap *map,
-const void *key, void *data, void *user)
-{
-   FREE((void*) data);
-}
-
-
-static inline struct keymap_item *
-hash_table_item(struct cso_hash_iter iter)
-{
-   return (struct keymap_item *) cso_hash_iter_data(iter);
-}
-
-
-/**
- * Return 4-byte hash key for a block of bytes.
- */
-static unsigned
-hash(const void *key, unsigned keySize)
-{
-   unsigned i, hash;
-
-   keySize /= 4; /* convert from bytes to uints */
-
-   hash = 0;
-   for (i = 0; i < keySize; i++) {
-  hash ^= (i + 1) * ((const unsigned *) key)[i];
-   }
-
-   /*hash = hash ^ (hash >> 11) ^ (hash >> 22);*/
-
-   return hash;
-}
-
-
-/**
- * Create a new map.
- * \param keySize  size of the keys in bytes
- * \param maxEntries  max number of entries to allow (~0 = infinity)
- * \param deleteFunc  optional callback to call when entries
- *are deleted/replaced
- */
-struct keymap *
-util_new_keymap(unsigned keySize, unsigned maxEntries,
- keymap_delete_func deleteFunc)
-{
-   struct keymap *map = MALLOC_STRUCT(keymap);
-   if (!map)
-  return NULL;
-   
-   map->cso = cso_hash_create();
-   if (!map->cso) {
-  FREE(map);
-  return NULL;
-   }
-   
-   map->max_entries = maxEntries;
-   map->num_entries = 0;
-   map->key_size = keySize;
-   map->delete_func = deleteFunc ? deleteFunc : default_delete_func;
-
-   return map;
-}
-
-
-/**
- * Delete/free a keymap and all entries.  The deleteFunc that was given at
- * create time will be called for each entry.
- * \param user  user-provided pointer passed through to the delete callback
- */
-void
-util_delete_keymap(struct keymap *map, void *user)
-{
-   

[Mesa-dev] How to write using EGLImage?

[Gurkirpal Singh]

Hi,

As a part of my GSoC project[1] I'm working on adding OMX_UseEGLImage
support in gallium/st/omx.

I have an egl_display[1] (OMX_NATIVE_WINDOWTYPE) and the EGLImage[2] in the
H.264 decoder component. I'm looking some sort of method to get mesa pipe
screen pointer (or some other pipe structure) from the egl_display and from
which I can get struct pipe_surface and eglimage pointer/id.

[1] https://summerofcode.withgoogle.com/projects/#4737166321123328
[2]
https://github.com/gpalsingh/mesa/blob/gsoc-dev/src/gallium/state_trackers/omx_tizonia/h264dprc.c#L205

Thanks,
Gurkirpal
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] gallium: improve selection of pixel format

[Andres Gomez]

Olivier, Brian, do we want this into -stable?

On Thu, 2017-07-06 at 17:08 +0200, Olivier Lauffenburger wrote:
> Current selection of pixel format does not enforce the request of
> stencil or depth buffer if the color depth is not the same as
> requested.
> For instance, GLUT requests a 32-bit color buffer with an 8-bit
> stencil buffer, but because color buffers are only 24-bit, no
> priority is given to creating a stencil buffer.
> 
> This patch gives more priority to the creation of requested buffers
> and less priority to the difference in bit depth.
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101703
> 
> Signed-off-by: Olivier Lauffenburger 
> ---
>  src/gallium/state_trackers/wgl/stw_pixelformat.c | 36 
> +++-
>  1 file changed, 29 insertions(+), 7 deletions(-)
> 
> diff --git a/src/gallium/state_trackers/wgl/stw_pixelformat.c 
> b/src/gallium/state_trackers/wgl/stw_pixelformat.c
> index 7763f71cbc..833308d964 100644
> --- a/src/gallium/state_trackers/wgl/stw_pixelformat.c
> +++ b/src/gallium/state_trackers/wgl/stw_pixelformat.c
> @@ -432,17 +432,39 @@ stw_pixelformat_choose(HDC hdc, CONST 
> PIXELFORMATDESCRIPTOR *ppfd)
>!!(pfi->pfd.dwFlags & PFD_DOUBLEBUFFER))
>   continue;
>  
> -  /* FIXME: Take in account individual channel bits */
> -  if (ppfd->cColorBits != pfi->pfd.cColorBits)
> - delta += 8;
> +  /* Selection logic:
> +  * - Enabling a feature (depth, stencil...) is given highest priority.
> +  * - Giving as many bits as requested is given medium priority.
> +  * - Giving no more bits than requested is given lowest priority.
> +  */
>  
> -  if (ppfd->cDepthBits != pfi->pfd.cDepthBits)
> - delta += 4;
> +  /* FIXME: Take in account individual channel bits */
> +  if (ppfd->cColorBits && !pfi->pfd.cColorBits)
> + delta += 1;
> +  else if (ppfd->cColorBits > pfi->pfd.cColorBits)
> + delta += 100;
> +  else if (ppfd->cColorBits < pfi->pfd.cColorBits)
> + delta++;
>  
> -  if (ppfd->cStencilBits != pfi->pfd.cStencilBits)
> +  if (ppfd->cDepthBits && !pfi->pfd.cDepthBits)
> + delta += 1;
> +  else if (ppfd->cDepthBits > pfi->pfd.cDepthBits)
> + delta += 200;
> +  else if (ppfd->cDepthBits < pfi->pfd.cDepthBits)
>   delta += 2;
>  
> -  if (ppfd->cAlphaBits != pfi->pfd.cAlphaBits)
> +  if (ppfd->cStencilBits && !pfi->pfd.cStencilBits)
> + delta += 1;
> +  else if (ppfd->cStencilBits > pfi->pfd.cStencilBits)
> + delta += 400;
> +  else if (ppfd->cStencilBits < pfi->pfd.cStencilBits)
> + delta++;
> +
> +  if (ppfd->cAlphaBits && !pfi->pfd.cAlphaBits)
> + delta += 1;
> +  else if (ppfd->cAlphaBits > pfi->pfd.cAlphaBits)
> + delta += 100;
> +  else if (ppfd->cAlphaBits < pfi->pfd.cAlphaBits)
>   delta++;
>  
>if (delta < bestdelta) {
-- 
Br,

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

[Mesa-dev] [PATCH 3/4] docs: avoid overwrite of LD_LIBRARY_PATH during basic testing

[Andres Gomez]

The LD_LIBRARY_PATH environment variable could be already defined so
we extend it and restore it rather than just overwriting it.

Signed-off-by: Andres Gomez 
---
 docs/releasing.html | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/docs/releasing.html b/docs/releasing.html
index 8e6e4d1a6d..99235d8412 100644
--- a/docs/releasing.html
+++ b/docs/releasing.html
@@ -472,7 +472,8 @@ Here is one solution that I've been using.
__glxgears_cmd='glxgears 2>1 | grep -v "configuration file"'
__es2info_cmd='es2_info 2>1 | egrep 
"GL_VERSION|GL_RENDERER|.*dri\.so"'
__es2gears_cmd='es2gears_x11 2>1 | grep -v "configuration file"'
-   export LD_LIBRARY_PATH=`pwd`/test/usr/local/lib/
+   'x$LD_LIBRARY_PATH' -ne 'x'  __old_ld='$LD_LIBRARY_PATH' 
 __token=':'
+   export LD_LIBRARY_PATH=`pwd`/test/usr/local/lib/'${__token}${__old_ld}'
export LIBGL_DRIVERS_PATH=`pwd`/test/usr/local/lib/dri/
export LIBGL_DEBUG=verbose
eval $__glxinfo_cmd
@@ -492,6 +493,7 @@ Here is one solution that I've been using.
eval $__es2gears_cmd
# Smoke test DOTA2
unset LD_LIBRARY_PATH
+   'x$__old_ld' -ne 'x'  export LD_LIBRARY_PATH='$__old_ld' 
 unset __token
unset LIBGL_DRIVERS_PATH
unset LIBGL_DEBUG
unset LIBGL_ALWAYS_SOFTWARE
-- 
2.11.0

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

[Mesa-dev] [PATCH 4/4] docs: update master's release notes, news and calendar commit

[Andres Gomez]

This reflects closer what we are actually doing.

Signed-off-by: Andres Gomez 
---
 docs/releasing.html | 15 ---
 1 file changed, 4 insertions(+), 11 deletions(-)

diff --git a/docs/releasing.html b/docs/releasing.html
index 99235d8412..152f5cea73 100644
--- a/docs/releasing.html
+++ b/docs/releasing.html
@@ -24,7 +24,6 @@
 Making a branchpoint
 Pre-release announcement
 Making a new release
-Update the calendar
 Announce the release
 Update the mesa3d.org website
 Update Bugzilla
@@ -574,23 +573,17 @@ Something like the following steps will do the trick:
 
 
 
-Also, edit docs/relnotes.html to add a link to the new release notes, and edit
-docs/index.html to add a news entry. Then commit and push:
+Also, edit docs/relnotes.html to add a link to the new release notes,
+edit docs/index.html to add a news entry, and remove the version from
+docs/release-calendar.html. Then commit and push:
 
 
 
-   git commit -as -m "docs: add news item and link release notes for X.Y.Z"
+   git commit -as -m "docs: update calendar, add news item and link 
release notes for X.Y.Z"
git push origin master X.Y
 
 
 
-Update the calendar
-
-
-Remove the version from the calendar.
-
-
-
 Announce the release
 
 
-- 
2.11.0

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

[Mesa-dev] [PATCH 2/4] docs: remove redundant parameter for scons build basic testing

[Andres Gomez]

toolchain=crossmingw is the default option for platform=windows when
invoking scons.

Signed-off-by: Andres Gomez 
---
 docs/releasing.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/releasing.html b/docs/releasing.html
index ceb6e365e4..8e6e4d1a6d 100644
--- a/docs/releasing.html
+++ b/docs/releasing.html
@@ -450,7 +450,7 @@ Here is one solution that I've been using.
# You may need to unset LLVM if you set it before:
# unset LLVM_CONFIG
tar -xaf mesa-$__version.tar.xz  cd mesa-$__version
-   scons platform=windows toolchain=crossmingw
+   scons platform=windows
cd ..  rm -rf mesa-$__version
 
# Test the automake binaries
-- 
2.11.0

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

[Mesa-dev] [PATCH 1/4] docs: add instructions to specify LLVM version for basic testing

[Andres Gomez]

The "Perform basic testing" section provides some instructions to do
so. We add now some comments in order to use a recent enough LLVM
version to test the distcheck and the automake generated binaries.

Signed-off-by: Andres Gomez 
---
 docs/releasing.html | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/docs/releasing.html b/docs/releasing.html
index 99707bee3f..ceb6e365e4 100644
--- a/docs/releasing.html
+++ b/docs/releasing.html
@@ -437,6 +437,8 @@ Here is one solution that I've been using.
chmod 755 -fR $__build_root; rm -rf $__build_root
mkdir -p $__build_root  cd $__build_root
 
+   # For the distcheck, you may want to specify which LLVM to use:
+   # export LLVM_CONFIG=/usr/lib/llvm-3.9/bin/llvm-config
$__mesa_root/autogen.sh  make -j2 distcheck
 
# Build check the tarballs (scons, linux)
@@ -445,18 +447,22 @@ Here is one solution that I've been using.
cd ..  rm -rf mesa-$__version
 
# Build check the tarballs (scons, windows/mingw)
+   # You may need to unset LLVM if you set it before:
+   # unset LLVM_CONFIG
tar -xaf mesa-$__version.tar.xz  cd mesa-$__version
scons platform=windows toolchain=crossmingw
cd ..  rm -rf mesa-$__version
 
# Test the automake binaries
tar -xaf mesa-$__version.tar.xz  cd mesa-$__version
+   # You may want to specify which LLVM to use:
./configure \
--with-dri-drivers=i965,swrast \
--with-gallium-drivers=swrast \
--with-vulkan-drivers=intel \
--enable-llvm-shared-libs \
--enable-llvm \
+   --with-llvm-prefix=/usr/lib/llvm-3.9 \
--enable-glx-tls \
--enable-gbm \
--enable-egl \
-- 
2.11.0

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

[Mesa-dev] [PATCH 0/4] docs: update basic testing on the releasing instructions

[Andres Gomez]

Some small update on the "Making a new release" section of the
releasing instructions.

Patches 1-3 add some small modifications for performing the basic
testing.

Patch 4 merges the section for updating the calendar into the previous
one to reflect closer what we are actually doing.

Andres Gomez (4):
  docs: add instructions to specify LLVM version for basic testing
  docs: remove redundant parameter for scons build basic testing
  docs: avoid overwrite of LD_LIBRARY_PATH during basic testing
  docs: update master's release notes, news and calendar commit

 docs/releasing.html | 27 ++-
 1 file changed, 14 insertions(+), 13 deletions(-)

-- 
2.11.0

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

Re: [Mesa-dev] [PATCH] anv: Stop setting domains to RENDER on EXEC_OBJECT_WRITE

[Matt Turner]

On Sat, Jul 8, 2017 at 11:05 AM, Jason Ekstrand  wrote:
> On July 7, 2017 1:52:54 PM Chris Wilson  wrote:
>
>> Quoting Jason Ekstrand (2017-07-07 21:37:29)
>>>
>>> The reason we were doing this was to ensure that the kernel did the
>>> appropriate cross-ring synchronization and flushing.  However, the
>>> kernel only looks at EXEC_OBJECT_WRITE to determine whether or not to
>>> insert a fence.  It only cares about the domain for determining whether
>>> or not it needs to clflush the BO before using it for scanout but the
>>> domain automatically gets set to RENDER internally by the kernel if
>>> EXEC_OBJECT_WRITE is set.
>>
>>
>> Once upon a time we also depended upon EXEC_OBJECT_WRITE for correct
>> swapout. That was until I saw what you were planning to do for anv. Hmm,
>> that puts the oldest kernel that might support anv as
>>
>> commit 51bc140431e233284660b1d22c47dec9ecdb521e [v4.3]
>> Author: Chris Wilson 
>> Date:   Mon Aug 31 15:10:39 2015 +0100
>>
>> drm/i915: Always mark the object as dirty when used by the GPU
>
>
> I think we're probably ok there.  We have a hard requirement on memfd which
> I think landed in 4.6 though I could be wrong about that.

No. memfd_create was added in 3.17.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2 10/27] i965/miptree: Add a colorspace parameter to create_for_dri_image

[Chad Versace]

On Thu 29 Jun 2017, Jason Ekstrand wrote:
> The __DRI_FORMAT enums are all UNORM but we will frequently want sRGB
> when creating miptrees for renderbuffers.  This lets us specify.
> ---
>  src/mesa/drivers/dri/i965/intel_fbo.c |  3 ++-
>  src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 24 ++--
>  src/mesa/drivers/dri/i965/intel_mipmap_tree.h |  3 ++-
>  src/mesa/drivers/dri/i965/intel_tex_image.c   |  3 ++-
>  4 files changed, 28 insertions(+), 5 deletions(-)

I like this patch.
Reviewed-by: Chad Versace 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2 09/27] main/formats: Add a get_linear_format_srgb helper

[Chad Versace]

Patch 9 is
Reviewed-by: Chad Versace 

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

Re: [Mesa-dev] [PATCH v2 08/27] main/formats: Autogenerate _mesa_get_srgb_format_linear

[Chad Versace]

On Thu 29 Jun 2017, Jason Ekstrand wrote:
> ---
>  src/mesa/main/format_fallback.py |  46 +++
>  src/mesa/main/formats.c  | 117 
> ---
>  2 files changed, 46 insertions(+), 117 deletions(-)
> 
> diff --git a/src/mesa/main/format_fallback.py 
> b/src/mesa/main/format_fallback.py
> index e3b9916..ec86938 100644
> --- a/src/mesa/main/format_fallback.py
> +++ b/src/mesa/main/format_fallback.py
> @@ -38,6 +38,34 @@ def parse_args():
>  p.add_argument("out")
>  return p.parse_args()
>  
> +def get_unorm_to_srgb_map(formats):
> +names = {fmt.name for fmt in formats}

Set comprehenstions broke the build on CentOS. See
commit 95731b7ccc605bbfe2c3cb3d533219bc0788cbaa.

Also, please say in the commit message that the new function covers more
formats than the originl. The additional formats covered by the new
function are the 3D ASTC formats below:

MESA_FORMAT_SRGB8_ALPHA8_ASTC_3x3x3 
MESA_FORMAT_SRGB8_ALPHA8_ASTC_4x3x3 
MESA_FORMAT_SRGB8_ALPHA8_ASTC_4x4x3 
MESA_FORMAT_SRGB8_ALPHA8_ASTC_4x4x4 
MESA_FORMAT_SRGB8_ALPHA8_ASTC_5x4x4 
MESA_FORMAT_SRGB8_ALPHA8_ASTC_5x5x4 
MESA_FORMAT_SRGB8_ALPHA8_ASTC_5x5x5 
MESA_FORMAT_SRGB8_ALPHA8_ASTC_6x5x5 
MESA_FORMAT_SRGB8_ALPHA8_ASTC_6x6x5 
MESA_FORMAT_SRGB8_ALPHA8_ASTC_6x6x6 

With those two things fixed:
Reviewed-by: Chad Versace 

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

Re: [Mesa-dev] [PATCH] anv: Stop setting domains to RENDER on EXEC_OBJECT_WRITE

[Jason Ekstrand]

On July 7, 2017 1:52:54 PM Chris Wilson  wrote:


Quoting Jason Ekstrand (2017-07-07 21:37:29)

The reason we were doing this was to ensure that the kernel did the
appropriate cross-ring synchronization and flushing.  However, the
kernel only looks at EXEC_OBJECT_WRITE to determine whether or not to
insert a fence.  It only cares about the domain for determining whether
or not it needs to clflush the BO before using it for scanout but the
domain automatically gets set to RENDER internally by the kernel if
EXEC_OBJECT_WRITE is set.


Once upon a time we also depended upon EXEC_OBJECT_WRITE for correct
swapout. That was until I saw what you were planning to do for anv. Hmm,
that puts the oldest kernel that might support anv as

commit 51bc140431e233284660b1d22c47dec9ecdb521e [v4.3]
Author: Chris Wilson 
Date:   Mon Aug 31 15:10:39 2015 +0100

drm/i915: Always mark the object as dirty when used by the GPU


I think we're probably ok there.  We have a hard requirement on memfd which 
I think landed in 4.6 though I could be wrong about that.



Cc: Chris Wilson 
---
 src/intel/vulkan/anv_batch_chain.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/src/intel/vulkan/anv_batch_chain.c 
b/src/intel/vulkan/anv_batch_chain.c

index 9def174..9776a45 100644
--- a/src/intel/vulkan/anv_batch_chain.c
+++ b/src/intel/vulkan/anv_batch_chain.c
@@ -148,9 +148,6 @@ anv_reloc_list_add(struct anv_reloc_list *list,
struct drm_i915_gem_relocation_entry *entry;
int index;

-   const uint32_t domain =
-  (target_bo->flags & EXEC_OBJECT_WRITE) ? I915_GEM_DOMAIN_RENDER : 0;
-
VkResult result = anv_reloc_list_grow(list, alloc, 1);
if (result != VK_SUCCESS)
   return result;
@@ -163,8 +160,8 @@ anv_reloc_list_add(struct anv_reloc_list *list,
entry->delta = delta;
entry->offset = offset;
entry->presumed_offset = target_bo->offset;
-   entry->read_domains = domain;
-   entry->write_domain = domain;
+   entry->read_domains = 0;
+   entry->write_domain = 0;


The first time I saw this I was amazed we let 0 through. It is true that
the kernel only cares about EXEC_OBJECT_WRITE, and doesn't care whether
that is from an execobject.flag or from accumulation of
reloc[].write_domain. (That has been true for all kernels since the
introduction of NORELOC and the EXEC_OBJECT_WRITE flag)  We don't even
use the reloc.write_domain information during reloc itself, so

Reviewed-by: Chris Wilson 
-Chris



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

Re: [Mesa-dev] [Mesa-stable] [PATCH] etnaviv: don't dereference etna_resource pointer if allocation fails

[Andres Gomez]

On Sat, 2017-07-08 at 18:45 +0200, Christian Gmeiner wrote:
> 2017-07-08 14:42 GMT+02:00 Andres Gomez :
> > It looks like we could want this into -stable (?)
> 
> Forgot to add CC during push but I have nominated it for stable now.

Great! Thanks a lot! ☺

-- 
Br,

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

Re: [Mesa-dev] [Mesa-stable] [PATCH] mesa: Require mipmap completeness for glCopyImageSubData() at times.

[Andres Gomez]

On Sat, 2017-07-08 at 07:52 -0700, Kenneth Graunke wrote:
> On Saturday, July 8, 2017 7:01:30 AM PDT Andres Gomez wrote:
> > Kenneth, worth cherry-picking for -stable?
> 
> I wouldn't - this patch just imposes additional restrictions, making
> things we used to support illegal.  That means it carries a risk of
> breaking existing applications, and really only benefits test cases
> that try illegal things and expect an error.
> 
> We usually skip such patches for stable.

Thanks for the feedback! I will have that into account in the future ☺

-- 
Br,

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

Re: [Mesa-dev] [PATCH] etnaviv: don't dereference etna_resource pointer if allocation fails

[Christian Gmeiner]

2017-07-08 14:42 GMT+02:00 Andres Gomez :
> It looks like we could want this into -stable (?)

Forgot to add CC during push but I have nominated it for stable now.

greets
--
Christian Gmeiner, MSc

https://christian-gmeiner.info
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] mesa: Require mipmap completeness for glCopyImageSubData() at times.

[Kenneth Graunke]

On Saturday, July 8, 2017 7:01:30 AM PDT Andres Gomez wrote:
> Kenneth, worth cherry-picking for -stable?

I wouldn't - this patch just imposes additional restrictions, making
things we used to support illegal.  That means it carries a risk of
breaking existing applications, and really only benefits test cases
that try illegal things and expect an error.

We usually skip such patches for stable.

--Ken

signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] nir/spirv: Remove unnecessary comment.

[Jason Ekstrand]

Rb


On July 8, 2017 5:22:01 AM Andres Gomez  wrote:


It should have been removed after 00c47e111c.

Cc: Jason Ekstrand 
Cc: Connor Abbott 
Signed-off-by: Andres Gomez 
---
 src/compiler/spirv/spirv_to_nir.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/src/compiler/spirv/spirv_to_nir.c 
b/src/compiler/spirv/spirv_to_nir.c

index 1743d8915a..8da58a7a3e 100644
--- a/src/compiler/spirv/spirv_to_nir.c
+++ b/src/compiler/spirv/spirv_to_nir.c
@@ -759,11 +759,6 @@ vtn_handle_type(struct vtn_builder *b, SpvOp opcode,
   assert(glsl_type_is_scalar(base->type));
   val->type->base_type = vtn_base_type_vector;
   val->type->type = glsl_vector_type(glsl_get_base_type(base->type), 
elems);
-
-  /* Vectors implicitly have sizeof(base_type) stride.  For now, this
-   * is always 4 bytes.  This will have to change if we want to start
-   * supporting doubles or half-floats.
-   */
   val->type->stride = glsl_get_bit_size(base->type) / 8;
   val->type->array_element = base;
   break;
--
2.11.0




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

Re: [Mesa-dev] [PATCH 03/14] gallium/radeon: fix a possible crash for buffer exports

[Andres Gomez]

Marek, do we want this into -stable?

On Thu, 2017-06-29 at 21:47 +0200, Marek Olšák wrote:
> From: Marek Olšák 
> 
> ---
>  src/gallium/drivers/radeon/r600_texture.c | 24 +++-
>  1 file changed, 15 insertions(+), 9 deletions(-)
> 
> diff --git a/src/gallium/drivers/radeon/r600_texture.c 
> b/src/gallium/drivers/radeon/r600_texture.c
> index d68587b..139ab13 100644
> --- a/src/gallium/drivers/radeon/r600_texture.c
> +++ b/src/gallium/drivers/radeon/r600_texture.c
> @@ -582,30 +582,36 @@ static boolean r600_texture_get_handle(struct 
> pipe_screen* screen,
>* doesn't set it.
>*/
>   res->external_usage |= usage & 
> ~PIPE_HANDLE_USAGE_EXPLICIT_FLUSH;
>   if (!(usage & PIPE_HANDLE_USAGE_EXPLICIT_FLUSH))
>   res->external_usage &= 
> ~PIPE_HANDLE_USAGE_EXPLICIT_FLUSH;
>   } else {
>   res->b.is_shared = true;
>   res->external_usage = usage;
>   }
>  
> - if (rscreen->chip_class >= GFX9) {
> - offset = rtex->surface.u.gfx9.surf_offset;
> - stride = rtex->surface.u.gfx9.surf_pitch *
> -  rtex->surface.bpe;
> - slice_size = rtex->surface.u.gfx9.surf_slice_size;
> + if (res->b.b.target == PIPE_BUFFER) {
> + offset = 0;
> + stride = 0;
> + slice_size = 0;
>   } else {
> - offset = rtex->surface.u.legacy.level[0].offset;
> - stride = rtex->surface.u.legacy.level[0].nblk_x *
> -  rtex->surface.bpe;
> - slice_size = rtex->surface.u.legacy.level[0].slice_size;
> + if (rscreen->chip_class >= GFX9) {
> + offset = rtex->surface.u.gfx9.surf_offset;
> + stride = rtex->surface.u.gfx9.surf_pitch *
> +  rtex->surface.bpe;
> + slice_size = rtex->surface.u.gfx9.surf_slice_size;
> + } else {
> + offset = rtex->surface.u.legacy.level[0].offset;
> + stride = rtex->surface.u.legacy.level[0].nblk_x *
> +  rtex->surface.bpe;
> + slice_size = rtex->surface.u.legacy.level[0].slice_size;
> + }
>   }
>   return rscreen->ws->buffer_get_handle(res->buf, stride, offset,
> slice_size, whandle);
>  }
>  
>  static void r600_texture_destroy(struct pipe_screen *screen,
>struct pipe_resource *ptex)
>  {
>   struct r600_texture *rtex = (struct r600_texture*)ptex;
>   struct r600_resource *resource = >resource;
-- 
Br,

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

Re: [Mesa-dev] [PATCH 1/2] st/mesa: check for incomplete texture in st_finalize_texture()

[Andres Gomez]

Brian, it looks like we could want this series into -stable (?)

On Wed, 2017-06-28 at 16:12 -0600, Brian Paul wrote:
> Return early from st_finalize_texture() if we have an incomplete
> texture.  This avoids trying to create a texture resource with invalid
> parameters (too many mipmap levels given the base dimension).
> 
> Specifically, the Piglit fbo-incomplete-texture-03 test winds up
> calling pipe_screen::resource_create() with width0=32, height0=32 and
> last_level=6 because the first five cube faces are 32x32 but the sixth
> face is 64x64.  Some drivers handle this, but others (like VMware svga)
> do not (generates device errors).
> 
> Note that this code is on the path that's usually not taken (we normally
> build consistent textures).
> 
> No Piglit regressions.
> ---
>  src/mesa/state_tracker/st_cb_texture.c | 14 ++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/src/mesa/state_tracker/st_cb_texture.c 
> b/src/mesa/state_tracker/st_cb_texture.c
> index 9798321..7708443 100644
> --- a/src/mesa/state_tracker/st_cb_texture.c
> +++ b/src/mesa/state_tracker/st_cb_texture.c
> @@ -2543,6 +2543,20 @@ st_finalize_texture(struct gl_context *ctx,
>  stObj->base.Target == GL_TEXTURE_CUBE_MAP_ARRAY)
> ptHeight = ptWidth;
>   }
> +
> + /* At this point, the texture may be incomplete (mismatched cube
> +  * face sizes, for example).  If that's the case, give up, but
> +  * don't return GL_FALSE as that would raise an incorrect
> +  * GL_OUT_OF_MEMORY error.  See Piglit fbo-incomplete-texture-03 
> test.
> +  */
> + if (!stObj->base._BaseComplete ||
> + !stObj->base._MipmapComplete) {
> +_mesa_test_texobj_completeness(ctx, >base);
> +if (!stObj->base._BaseComplete ||
> +!stObj->base._MipmapComplete) {
> +   return TRUE;
> +}
> + }
>}
>  
>ptNumSamples = firstImage->base.NumSamples;
-- 
Br,

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

Re: [Mesa-dev] [PATCH] mesa: Require mipmap completeness for glCopyImageSubData() at times.

[Andres Gomez]

Kenneth, worth cherry-picking for -stable?

On Wed, 2017-06-28 at 02:44 -0700, Kenneth Graunke wrote:
> This patch makes glCopyImageSubData require mipmap completeness when the
> texture object's built-in sampler object has a mipmapping MinFilter.
> This is apparently the de facto behavior and mandated by Android's CTS.
> 
> One exception is that we ignore format based completeness rules
> (specifically integer formats with linear filtering), as this is
> also the de facto behavior that until recently was mandated by the
> OpenGL 4.5 CTS.
> 
> This was discussed with both the OpenGL and OpenGL ES working groups,
> and while everyone agrees this behavior is unfortunate and complicated,
> it is what it is at this point.  There was little appetite for relaxing
> restrictions given that all conformant Android drivers followed the
> mipmapping rule, and all conformant GL 4.5 implementations ignored the
> integer/linear rule.
> 
> Fixes (on i965):
> dEQP-GLES31.functional.debug.negative_coverage.*.buffer.copy_image_sub_data
> 
> Bugzilla: https://cvs.khronos.org/bugzilla/show_bug.cgi?id=16224
> Cc: Roland Scheidegger 
> ---
>  src/mesa/main/copyimage.c | 59 
> +--
>  1 file changed, 57 insertions(+), 2 deletions(-)
> 
> diff --git a/src/mesa/main/copyimage.c b/src/mesa/main/copyimage.c
> index 2cb617ca811..10777cfdf05 100644
> --- a/src/mesa/main/copyimage.c
> +++ b/src/mesa/main/copyimage.c
> @@ -149,9 +149,64 @@ prepare_target_err(struct gl_context *ctx, GLuint name, 
> GLenum target,
>   return false;
>}
>  
> +  /* The ARB_copy_image specification says:
> +   *
> +   *"INVALID_OPERATION is generated if either object is a texture and
> +   * the texture is not complete (as defined in section 3.9.14)"
> +   *
> +   * The cited section says:
> +   *
> +   *"Using the preceding definitions, a texture is complete unless 
> any
> +   * of the following conditions hold true: [...]
> +   *
> +   * * The minification filter requires a mipmap (is neither NEAREST
> +   *   nor LINEAR), and the texture is not mipmap complete."
> +   *
> +   * This imposes the bizarre restriction that glCopyImageSubData 
> requires
> +   * mipmap completion based on the sampler minification filter, even
> +   * though the call fundamentally ignores the sampler.  Additionally, it
> +   * doesn't work with texture units, so it can't consider any bound
> +   * separate sampler objects.  It appears that you're supposed to use
> +   * the sampler object which is built-in to the texture object.
> +   *
> +   * dEQP and the Android CTS mandate this behavior, and the Khronos
> +   * GL and ES working groups both affirmed that this is unfortunate but
> +   * correct.  See 
> https://cvs.khronos.org/bugzilla/show_bug.cgi?id=16224.
> +   *
> +   * Integer textures with filtering cause another completeness snag:
> +   *
> +   *"Any of:
> +   * – The internal format of the texture is integer (see table 
> 8.12).
> +   * – The internal format is STENCIL_INDEX.
> +   * – The internal format is DEPTH_STENCIL, and the value of
> +   *   DEPTH_STENCIL_TEXTURE_MODE for the texture is STENCIL_INDEX.
> +   * and either the magnification filter is not NEAREST, or the
> +   * minification filter is neither NEAREST nor
> +   * NEAREST_MIPMAP_NEAREST."
> +   *
> +   * However, applications in the wild (such as "Total War: WARHAMMER")
> +   * appear to call glCopyImageSubData with integer textures and the
> +   * default mipmap filters of GL_LINEAR and GL_NEAREST_MIPMAP_LINEAR,
> +   * which would be considered incomplete, but expect this to work.  In
> +   * fact, until VK-GL-CTS commit fef80039ff875a51806b54d151c5f2d0c12da,
> +   * the GL 4.5 CTS contained three tests which did the exact same thing
> +   * by accident, and all conformant implementations allowed it.
> +   *
> +   * A proposal was made to amend the spec to say "is not complete (as
> +   * defined in section , but ignoring format-based completeness
> +   * rules)" to allow this case.  It makes some sense, given that
> +   * glCopyImageSubData copies raw data without considering format.
> +   * While the official edits have not yet been made, the OpenGL
> +   * working group agreed with the idea of allowing this behavior.
> +   *
> +   * To ignore formats, we check texObj->_MipmapComplete directly
> +   * rather than calling _mesa_is_texture_complete().
> +   */
>_mesa_test_texobj_completeness(ctx, texObj);
> -  if (!texObj->_BaseComplete ||
> -  (level != 0 && !texObj->_MipmapComplete)) {
> +  const bool texture_complete_aside_from_formats =
> + _mesa_is_mipmap_filter(>Sampler) ? texObj->_MipmapComplete
> +  

Re: [Mesa-dev] [PATCH] drirc: Add glsl_correct_derivatives_after_discard for The Witcher 2

[Andres Gomez]

Related to my previous mail, do we try to pick this for -stable?

On Wed, 2017-06-21 at 22:40 +0200, Edmondo Tommasina wrote:
> This fixes the long-standing problem with black transitions in The Wicher 2.
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98238
> ---
> This patch depends on Marek's series: 
>
> https://patchwork.freedesktop.org/series/26089/
> 
>  src/mesa/drivers/dri/common/drirc | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/src/mesa/drivers/dri/common/drirc 
> b/src/mesa/drivers/dri/common/drirc
> index 7d73b1218b..494d768312 100644
> --- a/src/mesa/drivers/dri/common/drirc
> +++ b/src/mesa/drivers/dri/common/drirc
> @@ -155,6 +155,10 @@ TODO: document the other workarounds.
>  
>   value="true"/>
>  
> +
> +
> + value="true"/>
> +
>  
>  
>  
-- 
Br,

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

Re: [Mesa-dev] [PATCH 0/5] Gallium: Passing drirc options to create_screen() and fixing Rocket League

[Andres Gomez]

Marek, is it worth the effort of trying to bring this series into
-stable?

On Wed, 2017-06-21 at 00:54 +0200, Marek Olšák wrote:
> Hi,
> 
> This series updates pipe loaders so that flags such as drirc options
> can be passed to create_screen(). I have compile-tested everything
> except clover.
> 
> The first pipe_screen flag is a drirc option to fix incorrect grass
> rendering in Rocket League for radeonsi. Rocket League expects DirectX
> behavior for partial derivative computations after discard/kill, but
> radeonsi implements the more efficient but stricter OpenGL behavior
> and that will remain our default behavior. The new screen flag forces
> radeonsi to use the DX behavior for that game.
> 
> Please review.
> 
> Thanks,
> Marek
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
-- 
Br,

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

Re: [Mesa-dev] [PATCH] etnaviv: don't dereference etna_resource pointer if allocation fails

[Andres Gomez]

It looks like we could want this into -stable (?)

On Thu, 2017-07-06 at 11:35 +0200, Aleksander Morgado wrote:
> The check for the pointer being non-NULL was being done too late.
> 
> Signed-off-by: Aleksander Morgado 
> ---
>  src/gallium/drivers/etnaviv/etnaviv_resource.c | 10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.c 
> b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> index 97e0a15597..a709482c1b 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_resource.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> @@ -320,9 +320,9 @@ etna_resource_from_handle(struct pipe_screen *pscreen,
>struct winsys_handle *handle, unsigned usage)
>  {
> struct etna_screen *screen = etna_screen(pscreen);
> -   struct etna_resource *rsc = CALLOC_STRUCT(etna_resource);
> -   struct etna_resource_level *level = >levels[0];
> -   struct pipe_resource *prsc = >base;
> +   struct etna_resource *rsc;
> +   struct etna_resource_level *level;
> +   struct pipe_resource *prsc;
> struct pipe_resource *ptiled = NULL;
>  
> DBG("target=%d, format=%s, %ux%ux%u, array_size=%u, last_level=%u, "
> @@ -331,9 +331,13 @@ etna_resource_from_handle(struct pipe_screen *pscreen,
> tmpl->height0, tmpl->depth0, tmpl->array_size, tmpl->last_level,
> tmpl->nr_samples, tmpl->usage, tmpl->bind, tmpl->flags);
>  
> +   rsc = CALLOC_STRUCT(etna_resource);
> if (!rsc)
>return NULL;
>  
> +   level = >levels[0];
> +   prsc = >base;
> +
> *prsc = *tmpl;
>  
> pipe_reference_init(>reference, 1);
-- 
Br,

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

[Mesa-dev] [PATCH] nir/spirv: Remove unnecessary comment.

[Andres Gomez]

It should have been removed after 00c47e111c.

Cc: Jason Ekstrand 
Cc: Connor Abbott 
Signed-off-by: Andres Gomez 
---
 src/compiler/spirv/spirv_to_nir.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/src/compiler/spirv/spirv_to_nir.c 
b/src/compiler/spirv/spirv_to_nir.c
index 1743d8915a..8da58a7a3e 100644
--- a/src/compiler/spirv/spirv_to_nir.c
+++ b/src/compiler/spirv/spirv_to_nir.c
@@ -759,11 +759,6 @@ vtn_handle_type(struct vtn_builder *b, SpvOp opcode,
   assert(glsl_type_is_scalar(base->type));
   val->type->base_type = vtn_base_type_vector;
   val->type->type = glsl_vector_type(glsl_get_base_type(base->type), 
elems);
-
-  /* Vectors implicitly have sizeof(base_type) stride.  For now, this
-   * is always 4 bytes.  This will have to change if we want to start
-   * supporting doubles or half-floats.
-   */
   val->type->stride = glsl_get_bit_size(base->type) / 8;
   val->type->array_element = base;
   break;
-- 
2.11.0

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

Re: [Mesa-dev] [PATCH] [rfc] radv: offset images by a differing amount.

[Marek Olšák]

On Jul 8, 2017 1:59 PM, "Christian König"  wrote:

Am 08.07.2017 um 00:27 schrieb Marek Olšák:

> On Fri, Jul 7, 2017 at 9:37 PM, Dave Airlie  wrote:
>
>> On 8 July 2017 at 04:07, Christian König  wrote:
>>
>>> Am 07.07.2017 um 18:51 schrieb Marek Olšák:
>>>
 On Fri, Jul 7, 2017 at 11:18 AM, Christian König
  wrote:

> What tilling format have the destination textures?
>
> Sounds like the offset is just added so that we distribute memory
> accesses
> more equally over memory channels.
>
 You can't set an offset that is not aligned. The hardware ignores the
 low unaligned bits, so they have a different meaning. They specify
 pipe and bank rotation for macro tiling. It's like a state. It
 basically rotates the tile pattern.

>>>
>>> Yeah, I know. That's what I meant with distributing memory accesses more
>>> equally over all channels. The lower bits select a memory bank swizzle
>>> IIRC.
>>>
>>> I've tried years ago with R600 if shuffling them randomly could improve
>>> performance, but MRT wasn't widely used and/or supported at that time.
>>>
>> I'd known this and forgotten, the public CIK docs say bits 0..7 must be
>> zero,
>> but I have older docs which had more info. It would be nice if we could
>> get
>> proper docs released for the bottom bits considering AMD are using them
>> in their
>> drivers.
>>
>
I'm pretty sure AMD released that stuff years ago because I knew of it
before starting to work for AMD.


I think it was first released as addrlib source code. Some people might
have had access to docs under NDA, but it wasn't known publicly. I didn't
know it when I started at AMD.

Marek



The low 8 bits of the address are unused and can't be set, because
> CB_COLOR0_BASE is shifted by 8 bits. We are really talking about bits
> starting from 8 going higher. E.g. 8K alignment gives you 5 bits that
> can be used to express the rotation.
>
> It would be good to know what registers have the bits that matter (i.e.
>> BASE,
>> FMASK, CMASK, DCC, and resource descriptors.)
>>
>
The feature to select the memory pipe/bank to start with is implemented in
the MC. So AFAIK all blocks are programmed the same way regarding this.
E.g. you can use it for UVD/VCE as well.



>> Then I suppose we'd need to know the algorithm for programming them, and
>> if we need to make any allocations bigger in order to do so.
>>
>
As far as I understand it you don't need to make anything bigger. Addrlib
makes sure anyway that all pipe/banks are covered by a texture allocation
as soon as you select some tilling mode (linear is obviously an exception).

Regards,
Christian.


I expect this only starts to matter when we hit memory bandwidth limits,
>> the deferred demo does 3 MRT, one depth at 2kx2k then samples from those
>> down to 1280x720 displayed. This combined with a 3 instanced 57k vertex
>> draw seemed to be enough to see the pain. (Maybe a GL example doing
>> something
>> similiar might show the problem for radeonsi).
>>
> Addrlib contains the encoding code for the base address pipe/bank bits.
>
> The other open question I have, is does this just matter for MRT or does
>> texture
>> sampling also get some boost from it, my hack patch does it for only
>> surfaces which
>> will end up attached to the CB.
>>
> Yes, it should be done for read-only textures too.
>
> I'll update the patch to not call it an offset but name them the tile
>> rotation bits.
>>
> The proper name is "tile swizzle" or "pipe/bank swizzle". On gfx9,
> it's called "pipe/bank xor".
>
> Marek
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] [rfc] radv: offset images by a differing amount.

[Christian König]

Am 08.07.2017 um 00:27 schrieb Marek Olšák:

On Fri, Jul 7, 2017 at 9:37 PM, Dave Airlie  wrote:

On 8 July 2017 at 04:07, Christian König  wrote:

Am 07.07.2017 um 18:51 schrieb Marek Olšák:

On Fri, Jul 7, 2017 at 11:18 AM, Christian König
 wrote:

What tilling format have the destination textures?

Sounds like the offset is just added so that we distribute memory
accesses
more equally over memory channels.

You can't set an offset that is not aligned. The hardware ignores the
low unaligned bits, so they have a different meaning. They specify
pipe and bank rotation for macro tiling. It's like a state. It
basically rotates the tile pattern.


Yeah, I know. That's what I meant with distributing memory accesses more
equally over all channels. The lower bits select a memory bank swizzle IIRC.

I've tried years ago with R600 if shuffling them randomly could improve
performance, but MRT wasn't widely used and/or supported at that time.

I'd known this and forgotten, the public CIK docs say bits 0..7 must be zero,
but I have older docs which had more info. It would be nice if we could get
proper docs released for the bottom bits considering AMD are using them in their
drivers.


I'm pretty sure AMD released that stuff years ago because I knew of it 
before starting to work for AMD.



The low 8 bits of the address are unused and can't be set, because
CB_COLOR0_BASE is shifted by 8 bits. We are really talking about bits
starting from 8 going higher. E.g. 8K alignment gives you 5 bits that
can be used to express the rotation.


It would be good to know what registers have the bits that matter (i.e. BASE,
FMASK, CMASK, DCC, and resource descriptors.)


The feature to select the memory pipe/bank to start with is implemented 
in the MC. So AFAIK all blocks are programmed the same way regarding 
this. E.g. you can use it for UVD/VCE as well.




Then I suppose we'd need to know the algorithm for programming them, and
if we need to make any allocations bigger in order to do so.


As far as I understand it you don't need to make anything bigger. 
Addrlib makes sure anyway that all pipe/banks are covered by a texture 
allocation as soon as you select some tilling mode (linear is obviously 
an exception).


Regards,
Christian.


I expect this only starts to matter when we hit memory bandwidth limits,
the deferred demo does 3 MRT, one depth at 2kx2k then samples from those
down to 1280x720 displayed. This combined with a 3 instanced 57k vertex
draw seemed to be enough to see the pain. (Maybe a GL example doing something
similiar might show the problem for radeonsi).

Addrlib contains the encoding code for the base address pipe/bank bits.


The other open question I have, is does this just matter for MRT or does texture
sampling also get some boost from it, my hack patch does it for only
surfaces which
will end up attached to the CB.

Yes, it should be done for read-only textures too.


I'll update the patch to not call it an offset but name them the tile
rotation bits.

The proper name is "tile swizzle" or "pipe/bank swizzle". On gfx9,
it's called "pipe/bank xor".

Marek



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