[Mesa-dev] [Bug 99481] glsl_parser_extras.cpp:1253:18: error: expected ')' before 'PRId64'

[bugzilla-daemon]

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

Bug ID: 99481
   Summary: glsl_parser_extras.cpp:1253:18: error: expected ')'
before 'PRId64'
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Keywords: bisected, regression
  Severity: normal
  Priority: medium
 Component: Mesa core
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: v...@freedesktop.org
QA Contact: mesa-dev@lists.freedesktop.org
CC: airl...@freedesktop.org, i...@freedesktop.org,
matts...@gmail.com, nhaeh...@gmail.com

mesa: bb5db5564ffa5beeda19279c67fca5f623a36d03 (master 17.1.0-devel)

  CXX  glsl/glsl_parser_extras.lo
glsl/glsl_parser_extras.cpp: In member function 'virtual void
ast_expression::print() const':
glsl/glsl_parser_extras.cpp:1253:18: error: expected ')' before 'PRId64'
   printf("%" PRId64 " ", primary_expression.int64_constant);
  ^

$ gcc --version
gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-11)
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


commit bbce1c538dc0cb8bf3769510283d11847dc07540
Author: Dave Airlie 
Date:   Thu Jun 9 09:39:48 2016 +1000

glsl/ast/ir: Add 64-bit integer constant support

This adds support for 64-bit integer constants to the parser,
ast and ir.

v2: fix a few issues found in testing.

v3: Add missing ir_constant copy contructor support.

v4: Use PRIu64 and PRId64 in printfs in glsl_parser_extras.cpp.
Suggested by Nicolai.  Rebase on Marek's linalloc changes.

Signed-off-by: Dave Airlie 
Reviewed-by: Ian Romanick  [v2]
Reviewed-by: Matt Turner  [v3]
Reviewed-by: Nicolai Hähnle 

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

[Mesa-dev] [PATCH] i965: Support the force_glsl_version driconf option.

[Kenneth Graunke]

Gallium drivers have had this for a while.  It makes sense to support
it consistently across drivers, so expose it in i965 as well.

Signed-off-by: Kenneth Graunke 
---
 src/mesa/drivers/dri/i965/brw_context.c  | 3 +++
 src/mesa/drivers/dri/i965/intel_screen.c | 1 +
 2 files changed, 4 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/brw_context.c 
b/src/mesa/drivers/dri/i965/brw_context.c
index 84d34c0f6a0..f738199b75f 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -910,6 +910,9 @@ brw_process_driconf_options(struct brw_context *brw)
ctx->Const.ForceGLSLExtensionsWarn =
   driQueryOptionb(options, "force_glsl_extensions_warn");
 
+   ctx->Const.ForceGLSLVersion =
+  driQueryOptioni(options, "force_glsl_version");
+
ctx->Const.DisableGLSLLineContinuations =
   driQueryOptionb(options, "disable_glsl_line_continuations");
 
diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
b/src/mesa/drivers/dri/i965/intel_screen.c
index 6ae211da3a1..66b4643971f 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -79,6 +79,7 @@ DRI_CONF_BEGIN
   DRI_CONF_ALWAYS_FLUSH_CACHE("false")
   DRI_CONF_DISABLE_THROTTLING("false")
   DRI_CONF_FORCE_GLSL_EXTENSIONS_WARN("false")
+  DRI_CONF_FORCE_GLSL_VERSION(0)
   DRI_CONF_DISABLE_GLSL_LINE_CONTINUATIONS("false")
   DRI_CONF_DISABLE_BLEND_FUNC_EXTENDED("false")
   DRI_CONF_DUAL_COLOR_BLEND_BY_LOCATION("false")
-- 
2.11.0

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

[Mesa-dev] [Bug 93089] mesa fails to check for gcc atomic primitives before using them

[bugzilla-daemon]

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

--- Comment #11 from Jonathan Gray  ---
Previously 64 bit atomics were contained to i965.  The on disk shader cache
introduced in Mesa 13.0 in 87ab26b2ab35a29d446ae66f1795d40c184c0739 now
requires 64 bit atomics as well which breaks Mesa on 32 bit powerpc which
doesn't have 64 bit atomic instructions:

glxinfo:/usr/X11R6/lib/modules/dri/r300_dri.so: undefined symbol
'__sync_add_and_fetch_8'
libGL error: unable to load driver: r300_dri.so
libGL error: driver pointer missing
libGL error: failed to load driver: r300
glxinfo:/usr/X11R6/lib/modules/dri/swrast_dri.so: undefined symbol
'__sync_add_and_fetch_8'
libGL error: unable to load driver: swrast_dri.so
libGL error: failed to load driver: swrast
X Error of failed request:  GLXBadContext
  Major opcode of failed request:  155 (GLX)
  Minor opcode of failed request:  6 (X_GLXIsDirect)
  Serial number of failed request:  47
  Current serial number in output stream:  0
name of display: :0

This was reported by Stefan Sperling on OpenBSD/macppc along with the
workaround of using --disable-shader-cache.

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

[Mesa-dev] [PATCH 2/4] llvmpipe: enable the front buffer blit fix

[Karl Lessard]

The "drawbuffer-modes -auto" piglit test was also failing on llvmpipe
approx. 1/5 times, and the glarea sample app had the same issue as the
softpipe. The PIPE_BIND_DISPLAY_SYNC fix seems to apply well on both
drivers.

Signed-off-by: Karl Lessard 
---
 src/gallium/drivers/llvmpipe/lp_texture.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/llvmpipe/lp_texture.c 
b/src/gallium/drivers/llvmpipe/lp_texture.c
index 733253b..9dfff77 100644
--- a/src/gallium/drivers/llvmpipe/lp_texture.c
+++ b/src/gallium/drivers/llvmpipe/lp_texture.c
@@ -802,7 +802,7 @@ llvmpipe_init_screen_resource_funcs(struct pipe_screen 
*screen)
 #endif
 
screen->resource_create = llvmpipe_resource_create;
-/*   screen->resource_create_front = llvmpipe_resource_create_front; */
+   screen->resource_create_front = llvmpipe_resource_create_front;
screen->resource_destroy = llvmpipe_resource_destroy;
screen->resource_from_handle = llvmpipe_resource_from_handle;
screen->resource_get_handle = llvmpipe_resource_get_handle;
-- 
2.7.4

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

[Mesa-dev] [PATCH 4/4] gallium/swrast: avoid syncing with drawable on unmap

[Karl Lessard]

I think that we do not have to force a display/drawable refresh right
after unmapping the front buffer, this could be handled later on when
the pipe is being flushed or buffers are swapped (for optimisation).

Signed-off-by: Karl Lessard 
---
 src/gallium/winsys/sw/dri/dri_sw_winsys.c | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/src/gallium/winsys/sw/dri/dri_sw_winsys.c 
b/src/gallium/winsys/sw/dri/dri_sw_winsys.c
index f3756f4..7bf77ee 100644
--- a/src/gallium/winsys/sw/dri/dri_sw_winsys.c
+++ b/src/gallium/winsys/sw/dri/dri_sw_winsys.c
@@ -146,16 +146,20 @@ dri_sw_displaytarget_map(struct sw_winsys *ws,
  unsigned flags)
 {
struct dri_sw_displaytarget *dri_sw_dt = dri_sw_displaytarget(dt);
+
dri_sw_dt->mapped = dri_sw_dt->data;
+   dri_sw_dt->map_flags = flags;
 
if ((dri_sw_dt->usage & PIPE_BIND_DISPLAY_SYNC) && dri_sw_dt->drawable
  && (dri_sw_dt->snapshot_nb != 
dri_sw_dt->drawable->current_snapshot_nb)) {
   struct dri_sw_winsys *dri_sw_ws = dri_sw_winsys(ws);
-  dri_sw_ws->lf->get_image((void *)dri_sw_dt->drawable->handle, 0, 0, 
dri_sw_dt->width, dri_sw_dt->height, dri_sw_dt->stride, dri_sw_dt->data);
+
+  dri_sw_ws->lf->get_image((void *)dri_sw_dt->drawable->handle,
+   0, 0, dri_sw_dt->width, dri_sw_dt->height,
+   dri_sw_dt->stride, dri_sw_dt->data);
 
   dri_sw_dt->snapshot_nb = dri_sw_dt->drawable->current_snapshot_nb;
}
-   dri_sw_dt->map_flags = flags;
return dri_sw_dt->mapped;
 }
 
@@ -165,11 +169,6 @@ dri_sw_displaytarget_unmap(struct sw_winsys *ws,
 {
struct dri_sw_displaytarget *dri_sw_dt = dri_sw_displaytarget(dt);

-   if ((dri_sw_dt->usage & PIPE_BIND_DISPLAY_SYNC) && dri_sw_dt->drawable 
-   && (dri_sw_dt->map_flags & PIPE_TRANSFER_WRITE)) {
-  struct dri_sw_winsys *dri_sw_ws = dri_sw_winsys(ws);
-  dri_sw_ws->lf->put_image2((void *)dri_sw_dt->drawable->handle, 
dri_sw_dt->data, 0, 0, dri_sw_dt->width, dri_sw_dt->height, dri_sw_dt->stride);
-   }
dri_sw_dt->map_flags = 0;
dri_sw_dt->mapped = NULL;
 }
-- 
2.7.4

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

[Mesa-dev] [PATCH 3/4] gallium/swrast: rename "resource_create_front" method

[Karl Lessard]

Rename pipe_screen "resource_create_front" method to "resource_create2"
since it is not only invoked for front buffer creation (I'm not a big
fan of the '2' suffix but nothing else came up to my mind...)

Signed-off-by: Karl Lessard 
---
 src/gallium/drivers/llvmpipe/lp_texture.c | 19 ++-
 src/gallium/drivers/softpipe/sp_texture.c | 16 
 src/gallium/include/pipe/p_screen.h   | 12 
 src/gallium/state_trackers/dri/drisw.c|  4 ++--
 4 files changed, 28 insertions(+), 23 deletions(-)

diff --git a/src/gallium/drivers/llvmpipe/lp_texture.c 
b/src/gallium/drivers/llvmpipe/lp_texture.c
index 9dfff77..99122eb 100644
--- a/src/gallium/drivers/llvmpipe/lp_texture.c
+++ b/src/gallium/drivers/llvmpipe/lp_texture.c
@@ -201,7 +201,7 @@ llvmpipe_can_create_resource(struct pipe_screen *screen,
 static boolean
 llvmpipe_displaytarget_layout(struct llvmpipe_screen *screen,
   struct llvmpipe_resource *lpr,
-  const void *map_front_private)
+  const void *winsys_private)
 {
struct sw_winsys *winsys = screen->winsys;
 
@@ -216,13 +216,13 @@ llvmpipe_displaytarget_layout(struct llvmpipe_screen 
*screen,
   lpr->base.format,
   width, height,
   64,
-  map_front_private,
+  winsys_private,
   >row_stride[0] );
 
if (lpr->dt == NULL)
   return FALSE;
 
-   if (!map_front_private) {
+   if (!winsys_private) {
   void *map = winsys->displaytarget_map(winsys, lpr->dt,
 PIPE_TRANSFER_WRITE);
 
@@ -237,9 +237,9 @@ llvmpipe_displaytarget_layout(struct llvmpipe_screen 
*screen,
 
 
 static struct pipe_resource *
-llvmpipe_resource_create_front(struct pipe_screen *_screen,
-   const struct pipe_resource *templat,
-   const void *map_front_private)
+llvmpipe_resource_create2(struct pipe_screen *_screen,
+  const struct pipe_resource *templat,
+  const void *winsys_private)
 {
struct llvmpipe_screen *screen = llvmpipe_screen(_screen);
struct llvmpipe_resource *lpr = CALLOC_STRUCT(llvmpipe_resource);
@@ -257,7 +257,7 @@ llvmpipe_resource_create_front(struct pipe_screen *_screen,
 PIPE_BIND_SCANOUT |
 PIPE_BIND_SHARED)) {
  /* displayable surface */
- if (!llvmpipe_displaytarget_layout(screen, lpr, map_front_private))
+ if (!llvmpipe_displaytarget_layout(screen, lpr, winsys_private))
 goto fail;
   }
   else {
@@ -303,11 +303,12 @@ llvmpipe_resource_create_front(struct pipe_screen 
*_screen,
FREE(lpr);
return NULL;
 }
+
 static struct pipe_resource *
 llvmpipe_resource_create(struct pipe_screen *_screen,
  const struct pipe_resource *templat)
 {
-   return llvmpipe_resource_create_front(_screen, templat, NULL);
+   return llvmpipe_resource_create2(_screen, templat, NULL);
 }
 
 static void
@@ -802,7 +803,7 @@ llvmpipe_init_screen_resource_funcs(struct pipe_screen 
*screen)
 #endif
 
screen->resource_create = llvmpipe_resource_create;
-   screen->resource_create_front = llvmpipe_resource_create_front;
+   screen->resource_create2 = llvmpipe_resource_create2;
screen->resource_destroy = llvmpipe_resource_destroy;
screen->resource_from_handle = llvmpipe_resource_from_handle;
screen->resource_get_handle = llvmpipe_resource_get_handle;
diff --git a/src/gallium/drivers/softpipe/sp_texture.c 
b/src/gallium/drivers/softpipe/sp_texture.c
index 8dca158..57ccb0e 100644
--- a/src/gallium/drivers/softpipe/sp_texture.c
+++ b/src/gallium/drivers/softpipe/sp_texture.c
@@ -128,7 +128,7 @@ softpipe_can_create_resource(struct pipe_screen *screen,
 static boolean
 softpipe_displaytarget_layout(struct pipe_screen *screen,
   struct softpipe_resource *spr,
-  const void *map_front_private)
+  const void *winsys_private)
 {
struct sw_winsys *winsys = softpipe_screen(screen)->winsys;
 
@@ -140,7 +140,7 @@ softpipe_displaytarget_layout(struct pipe_screen *screen,
   spr->base.width0, 
   spr->base.height0,
   64,
-  map_front_private,
+  winsys_private,
   >stride[0] );
 
return spr->dt != NULL;
@@ -151,9 +151,9 @@ softpipe_displaytarget_layout(struct pipe_screen *screen,
  * Create new pipe_resource given the template 

[Mesa-dev] [PATCH 2/4] llvmpipe: enable the front buffer blit fix

[Karl Lessard]

The "drawbuffer-modes -auto" piglit test was also failing on llvmpipe
approx. 1/5 times, and the glarea sample app had the same issue as the
softpipe. The PIPE_BIND_DISPLAY_SYNC fix seems to apply well on both
drivers.

Signed-off-by: Karl Lessard 
---
 src/gallium/drivers/llvmpipe/lp_texture.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/llvmpipe/lp_texture.c 
b/src/gallium/drivers/llvmpipe/lp_texture.c
index 733253b..9dfff77 100644
--- a/src/gallium/drivers/llvmpipe/lp_texture.c
+++ b/src/gallium/drivers/llvmpipe/lp_texture.c
@@ -802,7 +802,7 @@ llvmpipe_init_screen_resource_funcs(struct pipe_screen 
*screen)
 #endif
 
screen->resource_create = llvmpipe_resource_create;
-/*   screen->resource_create_front = llvmpipe_resource_create_front; */
+   screen->resource_create_front = llvmpipe_resource_create_front;
screen->resource_destroy = llvmpipe_resource_destroy;
screen->resource_from_handle = llvmpipe_resource_from_handle;
screen->resource_get_handle = llvmpipe_resource_get_handle;
-- 
2.7.4

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

[Mesa-dev] [PATCH 3/4] gallium/swrast: rename "resource_create_front" method

[Karl Lessard]

Rename pipe_screen "resource_create_front" method to "resource_create2"
since it is not only invoked for front buffer creation (I'm not a big
fan of the '2' suffix but nothing else came up to my mind...)

Signed-off-by: Karl Lessard 
---
 src/gallium/drivers/llvmpipe/lp_texture.c | 19 ++-
 src/gallium/drivers/softpipe/sp_texture.c | 16 
 src/gallium/include/pipe/p_screen.h   | 12 
 src/gallium/state_trackers/dri/drisw.c|  4 ++--
 4 files changed, 28 insertions(+), 23 deletions(-)

diff --git a/src/gallium/drivers/llvmpipe/lp_texture.c 
b/src/gallium/drivers/llvmpipe/lp_texture.c
index 9dfff77..99122eb 100644
--- a/src/gallium/drivers/llvmpipe/lp_texture.c
+++ b/src/gallium/drivers/llvmpipe/lp_texture.c
@@ -201,7 +201,7 @@ llvmpipe_can_create_resource(struct pipe_screen *screen,
 static boolean
 llvmpipe_displaytarget_layout(struct llvmpipe_screen *screen,
   struct llvmpipe_resource *lpr,
-  const void *map_front_private)
+  const void *winsys_private)
 {
struct sw_winsys *winsys = screen->winsys;
 
@@ -216,13 +216,13 @@ llvmpipe_displaytarget_layout(struct llvmpipe_screen 
*screen,
   lpr->base.format,
   width, height,
   64,
-  map_front_private,
+  winsys_private,
   >row_stride[0] );
 
if (lpr->dt == NULL)
   return FALSE;
 
-   if (!map_front_private) {
+   if (!winsys_private) {
   void *map = winsys->displaytarget_map(winsys, lpr->dt,
 PIPE_TRANSFER_WRITE);
 
@@ -237,9 +237,9 @@ llvmpipe_displaytarget_layout(struct llvmpipe_screen 
*screen,
 
 
 static struct pipe_resource *
-llvmpipe_resource_create_front(struct pipe_screen *_screen,
-   const struct pipe_resource *templat,
-   const void *map_front_private)
+llvmpipe_resource_create2(struct pipe_screen *_screen,
+  const struct pipe_resource *templat,
+  const void *winsys_private)
 {
struct llvmpipe_screen *screen = llvmpipe_screen(_screen);
struct llvmpipe_resource *lpr = CALLOC_STRUCT(llvmpipe_resource);
@@ -257,7 +257,7 @@ llvmpipe_resource_create_front(struct pipe_screen *_screen,
 PIPE_BIND_SCANOUT |
 PIPE_BIND_SHARED)) {
  /* displayable surface */
- if (!llvmpipe_displaytarget_layout(screen, lpr, map_front_private))
+ if (!llvmpipe_displaytarget_layout(screen, lpr, winsys_private))
 goto fail;
   }
   else {
@@ -303,11 +303,12 @@ llvmpipe_resource_create_front(struct pipe_screen 
*_screen,
FREE(lpr);
return NULL;
 }
+
 static struct pipe_resource *
 llvmpipe_resource_create(struct pipe_screen *_screen,
  const struct pipe_resource *templat)
 {
-   return llvmpipe_resource_create_front(_screen, templat, NULL);
+   return llvmpipe_resource_create2(_screen, templat, NULL);
 }
 
 static void
@@ -802,7 +803,7 @@ llvmpipe_init_screen_resource_funcs(struct pipe_screen 
*screen)
 #endif
 
screen->resource_create = llvmpipe_resource_create;
-   screen->resource_create_front = llvmpipe_resource_create_front;
+   screen->resource_create2 = llvmpipe_resource_create2;
screen->resource_destroy = llvmpipe_resource_destroy;
screen->resource_from_handle = llvmpipe_resource_from_handle;
screen->resource_get_handle = llvmpipe_resource_get_handle;
diff --git a/src/gallium/drivers/softpipe/sp_texture.c 
b/src/gallium/drivers/softpipe/sp_texture.c
index 8dca158..57ccb0e 100644
--- a/src/gallium/drivers/softpipe/sp_texture.c
+++ b/src/gallium/drivers/softpipe/sp_texture.c
@@ -128,7 +128,7 @@ softpipe_can_create_resource(struct pipe_screen *screen,
 static boolean
 softpipe_displaytarget_layout(struct pipe_screen *screen,
   struct softpipe_resource *spr,
-  const void *map_front_private)
+  const void *winsys_private)
 {
struct sw_winsys *winsys = softpipe_screen(screen)->winsys;
 
@@ -140,7 +140,7 @@ softpipe_displaytarget_layout(struct pipe_screen *screen,
   spr->base.width0, 
   spr->base.height0,
   64,
-  map_front_private,
+  winsys_private,
   >stride[0] );
 
return spr->dt != NULL;
@@ -151,9 +151,9 @@ softpipe_displaytarget_layout(struct pipe_screen *screen,
  * Create new pipe_resource given the template information.
  */
 

[Mesa-dev] [PATCH 4/4] gallium/swrast: avoid syncing with drawable on unmap (optimisation)

[Karl Lessard]

I think that we do not have to force a display/drawable refresh right
after unmapping the front buffer, this could be handled later on when
the pipe is being flushed or buffers are swapped.

Signed-off-by: Karl Lessard 
---
 src/gallium/winsys/sw/dri/dri_sw_winsys.c | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/src/gallium/winsys/sw/dri/dri_sw_winsys.c 
b/src/gallium/winsys/sw/dri/dri_sw_winsys.c
index f3756f4..7bf77ee 100644
--- a/src/gallium/winsys/sw/dri/dri_sw_winsys.c
+++ b/src/gallium/winsys/sw/dri/dri_sw_winsys.c
@@ -146,16 +146,20 @@ dri_sw_displaytarget_map(struct sw_winsys *ws,
  unsigned flags)
 {
struct dri_sw_displaytarget *dri_sw_dt = dri_sw_displaytarget(dt);
+
dri_sw_dt->mapped = dri_sw_dt->data;
+   dri_sw_dt->map_flags = flags;
 
if ((dri_sw_dt->usage & PIPE_BIND_DISPLAY_SYNC) && dri_sw_dt->drawable
  && (dri_sw_dt->snapshot_nb != 
dri_sw_dt->drawable->current_snapshot_nb)) {
   struct dri_sw_winsys *dri_sw_ws = dri_sw_winsys(ws);
-  dri_sw_ws->lf->get_image((void *)dri_sw_dt->drawable->handle, 0, 0, 
dri_sw_dt->width, dri_sw_dt->height, dri_sw_dt->stride, dri_sw_dt->data);
+
+  dri_sw_ws->lf->get_image((void *)dri_sw_dt->drawable->handle,
+   0, 0, dri_sw_dt->width, dri_sw_dt->height,
+   dri_sw_dt->stride, dri_sw_dt->data);
 
   dri_sw_dt->snapshot_nb = dri_sw_dt->drawable->current_snapshot_nb;
}
-   dri_sw_dt->map_flags = flags;
return dri_sw_dt->mapped;
 }
 
@@ -165,11 +169,6 @@ dri_sw_displaytarget_unmap(struct sw_winsys *ws,
 {
struct dri_sw_displaytarget *dri_sw_dt = dri_sw_displaytarget(dt);

-   if ((dri_sw_dt->usage & PIPE_BIND_DISPLAY_SYNC) && dri_sw_dt->drawable 
-   && (dri_sw_dt->map_flags & PIPE_TRANSFER_WRITE)) {
-  struct dri_sw_winsys *dri_sw_ws = dri_sw_winsys(ws);
-  dri_sw_ws->lf->put_image2((void *)dri_sw_dt->drawable->handle, 
dri_sw_dt->data, 0, 0, dri_sw_dt->width, dri_sw_dt->height, dri_sw_dt->stride);
-   }
dri_sw_dt->map_flags = 0;
dri_sw_dt->mapped = NULL;
 }
-- 
2.7.4

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

[Mesa-dev] [PATCH 1/4] gallium/swrast: fix software blitting with front buffers

[Karl Lessard]

This patch is mainly a workaround of commit
2b676570960277d47477822ffeccc672613f914 and fixes many problems with
framebuffer blitting in software drivers when the front buffer is
involved. It resolves regression issues listed above but also problems
with gtk-gl applications (like
https://github.com/ebassi/glarea-example.git, which was still
broken).

The new idea is to keep track of when a resource such as a fake front
buffer needs to be refreshed from the drawable data before being mapped
for read/write operations:

Every time a resource is being written/displayed to the drawable, a
"snapshot" number is increased and set to both the resource and the
drawable. If the snapshot number of the front buffer does not
match the drawable one at map time, it means that another resource has
been displayed meanwhile and therefore, a refresh is required.

Signed-off-by: Karl Lessard 
Bugzilla [1]: https://bugs.freedesktop.org/show_bug.cgi?id=92954
Bugzilla [2]: https://bugs.freedesktop.org/show_bug.cgi?id=92946
Bugzilla [3]: https://bugs.freedesktop.org/show_bug.cgi?id=93203 
---
 src/gallium/include/pipe/p_defines.h  |  5 +++
 src/gallium/include/state_tracker/drisw_api.h |  7 
 src/gallium/include/state_tracker/sw_winsys.h |  2 +-
 src/gallium/state_trackers/dri/dri_drawable.c |  2 --
 src/gallium/state_trackers/dri/dri_drawable.h |  2 +-
 src/gallium/state_trackers/dri/drisw.c| 46 +--
 src/gallium/winsys/sw/dri/dri_sw_winsys.c | 38 +-
 7 files changed, 81 insertions(+), 21 deletions(-)

diff --git a/src/gallium/include/pipe/p_defines.h 
b/src/gallium/include/pipe/p_defines.h
index 3eb5b3b..342923e 100644
--- a/src/gallium/include/pipe/p_defines.h
+++ b/src/gallium/include/pipe/p_defines.h
@@ -451,6 +451,11 @@ enum pipe_flush_flags
 #define PIPE_BIND_SHARED  (1 << 20) /* get_texture_handle ??? */
 #define PIPE_BIND_LINEAR  (1 << 21)
 
+/**
+ * This flag, in addition to PIPE_BIND_DISPLAY_TARGET, ensure that the resource
+ * will be kept in sync with any changes that could occur on the display.
+ */
+#define PIPE_BIND_DISPLAY_SYNC  (1 << 22)
 
 /**
  * Flags for the driver about resource behaviour:
diff --git a/src/gallium/include/state_tracker/drisw_api.h 
b/src/gallium/include/state_tracker/drisw_api.h
index 03d5ee4..ca0b361 100644
--- a/src/gallium/include/state_tracker/drisw_api.h
+++ b/src/gallium/include/state_tracker/drisw_api.h
@@ -20,4 +20,11 @@ struct drisw_loader_funcs
void *data, int x, int y, unsigned width, unsigned 
height, unsigned stride);
 };
 
+struct drisw_drawable_ref
+{
+   struct dri_drawable *handle;
+
+   uint32_t current_snapshot_nb;
+};
+
 #endif
diff --git a/src/gallium/include/state_tracker/sw_winsys.h 
b/src/gallium/include/state_tracker/sw_winsys.h
index 0b792cd..d1342cd 100644
--- a/src/gallium/include/state_tracker/sw_winsys.h
+++ b/src/gallium/include/state_tracker/sw_winsys.h
@@ -90,7 +90,7 @@ struct sw_winsys
 enum pipe_format format,
 unsigned width, unsigned height,
 unsigned alignment,
-const void *front_private,
+const void *winsys_private,
 unsigned *stride );
 
/**
diff --git a/src/gallium/state_trackers/dri/dri_drawable.c 
b/src/gallium/state_trackers/dri/dri_drawable.c
index edcd0e6..854b14a 100644
--- a/src/gallium/state_trackers/dri/dri_drawable.c
+++ b/src/gallium/state_trackers/dri/dri_drawable.c
@@ -168,8 +168,6 @@ dri_destroy_buffer(__DRIdrawable * dPriv)
struct dri_drawable *drawable = dri_drawable(dPriv);
int i;
 
-   pipe_surface_reference(>drisw_surface, NULL);
-
for (i = 0; i < ST_ATTACHMENT_COUNT; i++)
   pipe_resource_reference(>textures[i], NULL);
for (i = 0; i < ST_ATTACHMENT_COUNT; i++)
diff --git a/src/gallium/state_trackers/dri/dri_drawable.h 
b/src/gallium/state_trackers/dri/dri_drawable.h
index 1f9842e..3829232 100644
--- a/src/gallium/state_trackers/dri/dri_drawable.h
+++ b/src/gallium/state_trackers/dri/dri_drawable.h
@@ -68,7 +68,7 @@ struct dri_drawable
boolean flushing; /* prevents recursion in dri_flush */
 
/* used only by DRISW */
-   struct pipe_surface *drisw_surface;
+   struct drisw_drawable_ref *drisw_reference;
 
/* hooks filled in by dri2 & drisw */
void (*allocate_textures)(struct dri_context *ctx,
diff --git a/src/gallium/state_trackers/dri/drisw.c 
b/src/gallium/state_trackers/dri/drisw.c
index b85a73c..072ba07 100644
--- a/src/gallium/state_trackers/dri/drisw.c
+++ b/src/gallium/state_trackers/dri/drisw.c
@@ -264,7 +264,7 @@ drisw_allocate_textures(struct dri_context *stctx,
 unsigned count)
 {
struct dri_screen *screen = dri_screen(drawable->sPriv);
-   const __DRIswrastLoaderExtension *loader = 
drawable->dPriv->driScreenPriv->swrast_loader;
+   struct pipe_screen *pscreen = 

[Mesa-dev] [PATCH 4/4] gallium/swrast: avoid syncing with drawable on unmap (optimisation)

[Karl Lessard]

I think that we do not have to force a display/drawable refresh right
after unmapping the front buffer, this could be handled later on when
the pipe is being flushed or buffers are swapped.

Signed-off-by: Karl Lessard 
---
 src/gallium/winsys/sw/dri/dri_sw_winsys.c | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/src/gallium/winsys/sw/dri/dri_sw_winsys.c 
b/src/gallium/winsys/sw/dri/dri_sw_winsys.c
index f3756f4..7bf77ee 100644
--- a/src/gallium/winsys/sw/dri/dri_sw_winsys.c
+++ b/src/gallium/winsys/sw/dri/dri_sw_winsys.c
@@ -146,16 +146,20 @@ dri_sw_displaytarget_map(struct sw_winsys *ws,
  unsigned flags)
 {
struct dri_sw_displaytarget *dri_sw_dt = dri_sw_displaytarget(dt);
+
dri_sw_dt->mapped = dri_sw_dt->data;
+   dri_sw_dt->map_flags = flags;
 
if ((dri_sw_dt->usage & PIPE_BIND_DISPLAY_SYNC) && dri_sw_dt->drawable
  && (dri_sw_dt->snapshot_nb != 
dri_sw_dt->drawable->current_snapshot_nb)) {
   struct dri_sw_winsys *dri_sw_ws = dri_sw_winsys(ws);
-  dri_sw_ws->lf->get_image((void *)dri_sw_dt->drawable->handle, 0, 0, 
dri_sw_dt->width, dri_sw_dt->height, dri_sw_dt->stride, dri_sw_dt->data);
+
+  dri_sw_ws->lf->get_image((void *)dri_sw_dt->drawable->handle,
+   0, 0, dri_sw_dt->width, dri_sw_dt->height,
+   dri_sw_dt->stride, dri_sw_dt->data);
 
   dri_sw_dt->snapshot_nb = dri_sw_dt->drawable->current_snapshot_nb;
}
-   dri_sw_dt->map_flags = flags;
return dri_sw_dt->mapped;
 }
 
@@ -165,11 +169,6 @@ dri_sw_displaytarget_unmap(struct sw_winsys *ws,
 {
struct dri_sw_displaytarget *dri_sw_dt = dri_sw_displaytarget(dt);

-   if ((dri_sw_dt->usage & PIPE_BIND_DISPLAY_SYNC) && dri_sw_dt->drawable 
-   && (dri_sw_dt->map_flags & PIPE_TRANSFER_WRITE)) {
-  struct dri_sw_winsys *dri_sw_ws = dri_sw_winsys(ws);
-  dri_sw_ws->lf->put_image2((void *)dri_sw_dt->drawable->handle, 
dri_sw_dt->data, 0, 0, dri_sw_dt->width, dri_sw_dt->height, dri_sw_dt->stride);
-   }
dri_sw_dt->map_flags = 0;
dri_sw_dt->mapped = NULL;
 }
-- 
2.7.4

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

[Mesa-dev] [PATCH 2/4] llvmpipe: enable the front buffer blit fix

[Karl Lessard]

The "drawbuffer-modes -auto" piglit test was also failing on llvmpipe
approx. 1/5 times, and the glarea sample app had the same issue as the
softpipe. The PIPE_BIND_DISPLAY_SYNC fix seems to apply well on both
drivers.

Signed-off-by: Karl Lessard 
---
 src/gallium/drivers/llvmpipe/lp_texture.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/llvmpipe/lp_texture.c 
b/src/gallium/drivers/llvmpipe/lp_texture.c
index 733253b..9dfff77 100644
--- a/src/gallium/drivers/llvmpipe/lp_texture.c
+++ b/src/gallium/drivers/llvmpipe/lp_texture.c
@@ -802,7 +802,7 @@ llvmpipe_init_screen_resource_funcs(struct pipe_screen 
*screen)
 #endif
 
screen->resource_create = llvmpipe_resource_create;
-/*   screen->resource_create_front = llvmpipe_resource_create_front; */
+   screen->resource_create_front = llvmpipe_resource_create_front;
screen->resource_destroy = llvmpipe_resource_destroy;
screen->resource_from_handle = llvmpipe_resource_from_handle;
screen->resource_get_handle = llvmpipe_resource_get_handle;
-- 
2.7.4

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

[Mesa-dev] [PATCH 3/4] gallium/swrast: rename "resource_create_front" method

[Karl Lessard]

Rename pipe_screen "resource_create_front" method to "resource_create2"
since it is not only invoked for front buffer creation (I'm not a big
fan of the '2' suffix but nothing else came up to my mind...)

Signed-off-by: Karl Lessard 
---
 src/gallium/drivers/llvmpipe/lp_texture.c | 19 ++-
 src/gallium/drivers/softpipe/sp_texture.c | 16 
 src/gallium/include/pipe/p_screen.h   | 12 
 src/gallium/state_trackers/dri/drisw.c|  4 ++--
 4 files changed, 28 insertions(+), 23 deletions(-)

diff --git a/src/gallium/drivers/llvmpipe/lp_texture.c 
b/src/gallium/drivers/llvmpipe/lp_texture.c
index 9dfff77..99122eb 100644
--- a/src/gallium/drivers/llvmpipe/lp_texture.c
+++ b/src/gallium/drivers/llvmpipe/lp_texture.c
@@ -201,7 +201,7 @@ llvmpipe_can_create_resource(struct pipe_screen *screen,
 static boolean
 llvmpipe_displaytarget_layout(struct llvmpipe_screen *screen,
   struct llvmpipe_resource *lpr,
-  const void *map_front_private)
+  const void *winsys_private)
 {
struct sw_winsys *winsys = screen->winsys;
 
@@ -216,13 +216,13 @@ llvmpipe_displaytarget_layout(struct llvmpipe_screen 
*screen,
   lpr->base.format,
   width, height,
   64,
-  map_front_private,
+  winsys_private,
   >row_stride[0] );
 
if (lpr->dt == NULL)
   return FALSE;
 
-   if (!map_front_private) {
+   if (!winsys_private) {
   void *map = winsys->displaytarget_map(winsys, lpr->dt,
 PIPE_TRANSFER_WRITE);
 
@@ -237,9 +237,9 @@ llvmpipe_displaytarget_layout(struct llvmpipe_screen 
*screen,
 
 
 static struct pipe_resource *
-llvmpipe_resource_create_front(struct pipe_screen *_screen,
-   const struct pipe_resource *templat,
-   const void *map_front_private)
+llvmpipe_resource_create2(struct pipe_screen *_screen,
+  const struct pipe_resource *templat,
+  const void *winsys_private)
 {
struct llvmpipe_screen *screen = llvmpipe_screen(_screen);
struct llvmpipe_resource *lpr = CALLOC_STRUCT(llvmpipe_resource);
@@ -257,7 +257,7 @@ llvmpipe_resource_create_front(struct pipe_screen *_screen,
 PIPE_BIND_SCANOUT |
 PIPE_BIND_SHARED)) {
  /* displayable surface */
- if (!llvmpipe_displaytarget_layout(screen, lpr, map_front_private))
+ if (!llvmpipe_displaytarget_layout(screen, lpr, winsys_private))
 goto fail;
   }
   else {
@@ -303,11 +303,12 @@ llvmpipe_resource_create_front(struct pipe_screen 
*_screen,
FREE(lpr);
return NULL;
 }
+
 static struct pipe_resource *
 llvmpipe_resource_create(struct pipe_screen *_screen,
  const struct pipe_resource *templat)
 {
-   return llvmpipe_resource_create_front(_screen, templat, NULL);
+   return llvmpipe_resource_create2(_screen, templat, NULL);
 }
 
 static void
@@ -802,7 +803,7 @@ llvmpipe_init_screen_resource_funcs(struct pipe_screen 
*screen)
 #endif
 
screen->resource_create = llvmpipe_resource_create;
-   screen->resource_create_front = llvmpipe_resource_create_front;
+   screen->resource_create2 = llvmpipe_resource_create2;
screen->resource_destroy = llvmpipe_resource_destroy;
screen->resource_from_handle = llvmpipe_resource_from_handle;
screen->resource_get_handle = llvmpipe_resource_get_handle;
diff --git a/src/gallium/drivers/softpipe/sp_texture.c 
b/src/gallium/drivers/softpipe/sp_texture.c
index 8dca158..57ccb0e 100644
--- a/src/gallium/drivers/softpipe/sp_texture.c
+++ b/src/gallium/drivers/softpipe/sp_texture.c
@@ -128,7 +128,7 @@ softpipe_can_create_resource(struct pipe_screen *screen,
 static boolean
 softpipe_displaytarget_layout(struct pipe_screen *screen,
   struct softpipe_resource *spr,
-  const void *map_front_private)
+  const void *winsys_private)
 {
struct sw_winsys *winsys = softpipe_screen(screen)->winsys;
 
@@ -140,7 +140,7 @@ softpipe_displaytarget_layout(struct pipe_screen *screen,
   spr->base.width0, 
   spr->base.height0,
   64,
-  map_front_private,
+  winsys_private,
   >stride[0] );
 
return spr->dt != NULL;
@@ -151,9 +151,9 @@ softpipe_displaytarget_layout(struct pipe_screen *screen,
  * Create new pipe_resource given the template information.
  */
 

[Mesa-dev] [PATCH 1/4] gallium/swrast: fix software blitting with front buffers

[Karl Lessard]

This patch is mainly a workaround of commit
2b676570960277d47477822ffeccc672613f914 and fixes many problems with
framebuffer blitting in software drivers when the front buffer is
involved. It resolves regression issues listed above but also problems
with gtk-gl applications (like
https://github.com/ebassi/glarea-example.git, which was still
broken).

The new idea is to keep track of when a resource such as a fake front
buffer needs to be refreshed from the drawable data before being mapped
for read/write operations:

Every time a resource is being written/displayed to the drawable, a
"snapshot" number is increased and set to both the resource and the
drawable. If the snapshot number of the front buffer does not
match the drawable one at map time, it means that another resource has
been displayed meanwhile and therefore, a refresh is required.

Signed-off-by: Karl Lessard 
Bugzilla [1]: https://bugs.freedesktop.org/show_bug.cgi?id=92954
Bugzilla [2]: https://bugs.freedesktop.org/show_bug.cgi?id=92946
Bugzilla [3]: https://bugs.freedesktop.org/show_bug.cgi?id=93203 
---
 src/gallium/include/pipe/p_defines.h  |  5 +++
 src/gallium/include/state_tracker/drisw_api.h |  7 
 src/gallium/include/state_tracker/sw_winsys.h |  2 +-
 src/gallium/state_trackers/dri/dri_drawable.c |  2 --
 src/gallium/state_trackers/dri/dri_drawable.h |  2 +-
 src/gallium/state_trackers/dri/drisw.c| 46 +--
 src/gallium/winsys/sw/dri/dri_sw_winsys.c | 38 +-
 7 files changed, 81 insertions(+), 21 deletions(-)

diff --git a/src/gallium/include/pipe/p_defines.h 
b/src/gallium/include/pipe/p_defines.h
index 3eb5b3b..342923e 100644
--- a/src/gallium/include/pipe/p_defines.h
+++ b/src/gallium/include/pipe/p_defines.h
@@ -451,6 +451,11 @@ enum pipe_flush_flags
 #define PIPE_BIND_SHARED  (1 << 20) /* get_texture_handle ??? */
 #define PIPE_BIND_LINEAR  (1 << 21)
 
+/**
+ * This flag, in addition to PIPE_BIND_DISPLAY_TARGET, ensure that the resource
+ * will be kept in sync with any changes that could occur on the display.
+ */
+#define PIPE_BIND_DISPLAY_SYNC  (1 << 22)
 
 /**
  * Flags for the driver about resource behaviour:
diff --git a/src/gallium/include/state_tracker/drisw_api.h 
b/src/gallium/include/state_tracker/drisw_api.h
index 03d5ee4..ca0b361 100644
--- a/src/gallium/include/state_tracker/drisw_api.h
+++ b/src/gallium/include/state_tracker/drisw_api.h
@@ -20,4 +20,11 @@ struct drisw_loader_funcs
void *data, int x, int y, unsigned width, unsigned 
height, unsigned stride);
 };
 
+struct drisw_drawable_ref
+{
+   struct dri_drawable *handle;
+
+   uint32_t current_snapshot_nb;
+};
+
 #endif
diff --git a/src/gallium/include/state_tracker/sw_winsys.h 
b/src/gallium/include/state_tracker/sw_winsys.h
index 0b792cd..d1342cd 100644
--- a/src/gallium/include/state_tracker/sw_winsys.h
+++ b/src/gallium/include/state_tracker/sw_winsys.h
@@ -90,7 +90,7 @@ struct sw_winsys
 enum pipe_format format,
 unsigned width, unsigned height,
 unsigned alignment,
-const void *front_private,
+const void *winsys_private,
 unsigned *stride );
 
/**
diff --git a/src/gallium/state_trackers/dri/dri_drawable.c 
b/src/gallium/state_trackers/dri/dri_drawable.c
index edcd0e6..854b14a 100644
--- a/src/gallium/state_trackers/dri/dri_drawable.c
+++ b/src/gallium/state_trackers/dri/dri_drawable.c
@@ -168,8 +168,6 @@ dri_destroy_buffer(__DRIdrawable * dPriv)
struct dri_drawable *drawable = dri_drawable(dPriv);
int i;
 
-   pipe_surface_reference(>drisw_surface, NULL);
-
for (i = 0; i < ST_ATTACHMENT_COUNT; i++)
   pipe_resource_reference(>textures[i], NULL);
for (i = 0; i < ST_ATTACHMENT_COUNT; i++)
diff --git a/src/gallium/state_trackers/dri/dri_drawable.h 
b/src/gallium/state_trackers/dri/dri_drawable.h
index 1f9842e..3829232 100644
--- a/src/gallium/state_trackers/dri/dri_drawable.h
+++ b/src/gallium/state_trackers/dri/dri_drawable.h
@@ -68,7 +68,7 @@ struct dri_drawable
boolean flushing; /* prevents recursion in dri_flush */
 
/* used only by DRISW */
-   struct pipe_surface *drisw_surface;
+   struct drisw_drawable_ref *drisw_reference;
 
/* hooks filled in by dri2 & drisw */
void (*allocate_textures)(struct dri_context *ctx,
diff --git a/src/gallium/state_trackers/dri/drisw.c 
b/src/gallium/state_trackers/dri/drisw.c
index b85a73c..072ba07 100644
--- a/src/gallium/state_trackers/dri/drisw.c
+++ b/src/gallium/state_trackers/dri/drisw.c
@@ -264,7 +264,7 @@ drisw_allocate_textures(struct dri_context *stctx,
 unsigned count)
 {
struct dri_screen *screen = dri_screen(drawable->sPriv);
-   const __DRIswrastLoaderExtension *loader = 
drawable->dPriv->driScreenPriv->swrast_loader;
+   struct pipe_screen *pscreen = 

[Mesa-dev] [AppVeyor] mesa master #3219 completed

[AppVeyor]

Build mesa 3219 completed



Commit bb5db5564f by Kenneth Graunke on 1/21/2017 3:14 AM:

glsl: Rename [u]int64_t tokens.\n\nbasetsd.h on Windows defines INT64 and UINT64 typedefs which conflict\nwith these.  Append "_TOK" to avoid conflicts.\n\nShould fix the Windows build.\n\nSigned-off-by: Kenneth Graunke \nReviewed-by: Matt Turner 


Configure your notification preferences

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

Re: [Mesa-dev] [PATCH] glsl: Rename [u]int64_t tokens.

[Matt Turner]

Elsewhere we use _TOK. Not sure if you want to move to _TOKEN everywhere.

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

[Mesa-dev] [PATCH] glsl: Rename [u]int64_t tokens.

[Kenneth Graunke]

basetsd.h on Windows defines INT64 and UINT64 typedefs which conflict
with these.  Append "_TOKEN" to avoid conflicts.

Should fix the Windows build.

Signed-off-by: Kenneth Graunke 
---
 src/compiler/glsl/glsl_lexer.ll  | 4 ++--
 src/compiler/glsl/glsl_parser.yy | 6 +++---
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/src/compiler/glsl/glsl_lexer.ll b/src/compiler/glsl/glsl_lexer.ll
index 039eb43038d..a0754af311b 100644
--- a/src/compiler/glsl/glsl_lexer.ll
+++ b/src/compiler/glsl/glsl_lexer.ll
@@ -607,12 +607,12 @@ sampleKEYWORD_WITH_ALT(400, 300, 400, 320, 
yyextra->ARB_gpu_shader5_enable ||
 subroutine KEYWORD_WITH_ALT(400, 300, 400, 0, 
yyextra->ARB_shader_subroutine_enable, SUBROUTINE);
 
 /* Additional words for ARB_gpu_shader_int64 */
-int64_tKEYWORD_WITH_ALT(0, 0, 0, 0, 
yyextra->ARB_gpu_shader_int64_enable, INT64);
+int64_tKEYWORD_WITH_ALT(0, 0, 0, 0, 
yyextra->ARB_gpu_shader_int64_enable, INT64_TOKEN);
 i64vec2KEYWORD_WITH_ALT(0, 0, 0, 0, 
yyextra->ARB_gpu_shader_int64_enable, I64VEC2);
 i64vec3KEYWORD_WITH_ALT(0, 0, 0, 0, 
yyextra->ARB_gpu_shader_int64_enable, I64VEC3);
 i64vec4KEYWORD_WITH_ALT(0, 0, 0, 0, 
yyextra->ARB_gpu_shader_int64_enable, I64VEC4);
 
-uint64_t   KEYWORD_WITH_ALT(0, 0, 0, 0, 
yyextra->ARB_gpu_shader_int64_enable, UINT64);
+uint64_t   KEYWORD_WITH_ALT(0, 0, 0, 0, 
yyextra->ARB_gpu_shader_int64_enable, UINT64_TOKEN);
 u64vec2KEYWORD_WITH_ALT(0, 0, 0, 0, 
yyextra->ARB_gpu_shader_int64_enable, U64VEC2);
 u64vec3KEYWORD_WITH_ALT(0, 0, 0, 0, 
yyextra->ARB_gpu_shader_int64_enable, U64VEC3);
 u64vec4KEYWORD_WITH_ALT(0, 0, 0, 0, 
yyextra->ARB_gpu_shader_int64_enable, U64VEC4);
diff --git a/src/compiler/glsl/glsl_parser.yy b/src/compiler/glsl/glsl_parser.yy
index 852607455a2..bafc48c472a 100644
--- a/src/compiler/glsl/glsl_parser.yy
+++ b/src/compiler/glsl/glsl_parser.yy
@@ -137,7 +137,7 @@ static bool match_layout_qualifier(const char *s1, const 
char *s2,
 %token ATTRIBUTE CONST_TOK BOOL_TOK FLOAT_TOK INT_TOK UINT_TOK DOUBLE_TOK
 %token BREAK BUFFER CONTINUE DO ELSE FOR IF DISCARD RETURN SWITCH CASE DEFAULT
 %token BVEC2 BVEC3 BVEC4 IVEC2 IVEC3 IVEC4 UVEC2 UVEC3 UVEC4 VEC2 VEC3 VEC4 
DVEC2 DVEC3 DVEC4
-%token INT64 UINT64 I64VEC2 I64VEC3 I64VEC4 U64VEC2 U64VEC3 U64VEC4
+%token INT64_TOKEN UINT64_TOKEN I64VEC2 I64VEC3 I64VEC4 U64VEC2 U64VEC3 U64VEC4
 %token CENTROID IN_TOK OUT_TOK INOUT_TOK UNIFORM VARYING SAMPLE
 %token NOPERSPECTIVE FLAT SMOOTH
 %token MAT2X2 MAT2X3 MAT2X4
@@ -2321,11 +2321,11 @@ basic_type_specifier_nonarray:
| UIMAGE2DMS { $$ = "uimage2DMS"; }
| UIMAGE2DMSARRAY{ $$ = "uimage2DMSArray"; }
| ATOMIC_UINT{ $$ = "atomic_uint"; }
-   | INT64  { $$ = "int64_t"; }
+   | INT64_TOKEN{ $$ = "int64_t"; }
| I64VEC2{ $$ = "i64vec2"; }
| I64VEC3{ $$ = "i64vec3"; }
| I64VEC4{ $$ = "i64vec4"; }
-   | UINT64 { $$ = "uint64_t";}
+   | UINT64_TOKEN   { $$ = "uint64_t";}
| U64VEC2{ $$ = "u64vec2"; }
| U64VEC3{ $$ = "u64vec3"; }
| U64VEC4{ $$ = "u64vec4"; }
-- 
2.11.0

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

Re: [Mesa-dev] [PATCH 1/2] i965: Select DF type for 64-bit integers on Gen < 8.

[Kenneth Graunke]

On Friday, January 20, 2017 7:07:31 PM PST Matt Turner wrote:
> Gen8 adds Q/UQ types. We attempted to change the types back to DF in the
> generator (commit c95380c40), but an assertion added in the FP64 series
> (commit e481dcc3) triggers before that code has a chance to execute.
> 
> In fact, using Q/UQ in the IR and then changing to DF in the generator
> would not work in the presence of source modifiers, etc.
> 
> Fixes: d6fcede6 ("i965: Return Q and UQ types for int64 and uint64")
> ---
>  src/mesa/drivers/dri/i965/brw_fs_nir.cpp   | 8 
>  src/mesa/drivers/dri/i965/brw_nir.c| 6 +++---
>  src/mesa/drivers/dri/i965/brw_nir.h| 3 ++-
>  src/mesa/drivers/dri/i965/brw_vec4_nir.cpp | 5 +++--
>  4 files changed, 12 insertions(+), 10 deletions(-)

Thanks for the quick fire extinguisher usage :)

Series is:
Reviewed-by: Kenneth Graunke 


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

[Mesa-dev] [PATCH 1/2] i965: Select DF type for 64-bit integers on Gen < 8.

[Matt Turner]

Gen8 adds Q/UQ types. We attempted to change the types back to DF in the
generator (commit c95380c40), but an assertion added in the FP64 series
(commit e481dcc3) triggers before that code has a chance to execute.

In fact, using Q/UQ in the IR and then changing to DF in the generator
would not work in the presence of source modifiers, etc.

Fixes: d6fcede6 ("i965: Return Q and UQ types for int64 and uint64")
---
 src/mesa/drivers/dri/i965/brw_fs_nir.cpp   | 8 
 src/mesa/drivers/dri/i965/brw_nir.c| 6 +++---
 src/mesa/drivers/dri/i965/brw_nir.h| 3 ++-
 src/mesa/drivers/dri/i965/brw_vec4_nir.cpp | 5 +++--
 4 files changed, 12 insertions(+), 10 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp 
b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
index c6c91eb..e1ab598 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
@@ -419,7 +419,7 @@ fs_visitor::optimize_extract_to_float(nir_alu_instr *instr,
   src0->op == nir_op_extract_i16 || src0->op == nir_op_extract_i8);
 
fs_reg op0 = get_nir_src(src0->src[0].src);
-   op0.type = brw_type_for_nir_type(
+   op0.type = brw_type_for_nir_type(devinfo,
   (nir_alu_type)(nir_op_infos[src0->op].input_types[0] |
  nir_src_bit_size(src0->src[0].src)));
op0 = offset(op0, bld, src0->src[0].swizzle[0]);
@@ -554,14 +554,14 @@ fs_visitor::nir_emit_alu(const fs_builder , 
nir_alu_instr *instr)
fs_inst *inst;
 
fs_reg result = get_nir_dest(instr->dest.dest);
-   result.type = brw_type_for_nir_type(
+   result.type = brw_type_for_nir_type(devinfo,
   (nir_alu_type)(nir_op_infos[instr->op].output_type |
  nir_dest_bit_size(instr->dest.dest)));
 
fs_reg op[4];
for (unsigned i = 0; i < nir_op_infos[instr->op].num_inputs; i++) {
   op[i] = get_nir_src(instr->src[i].src);
-  op[i].type = brw_type_for_nir_type(
+  op[i].type = brw_type_for_nir_type(devinfo,
  (nir_alu_type)(nir_op_infos[instr->op].input_types[i] |
 nir_src_bit_size(instr->src[i].src)));
   op[i].abs = instr->src[i].abs;
@@ -4525,7 +4525,7 @@ fs_visitor::nir_emit_texture(const fs_builder , 
nir_tex_instr *instr)
   }
}
 
-   fs_reg dst = bld.vgrf(brw_type_for_nir_type(instr->dest_type), 4);
+   fs_reg dst = bld.vgrf(brw_type_for_nir_type(devinfo, instr->dest_type), 4);
fs_inst *inst = bld.emit(opcode, dst, srcs, ARRAY_SIZE(srcs));
inst->offset = header_bits;
 
diff --git a/src/mesa/drivers/dri/i965/brw_nir.c 
b/src/mesa/drivers/dri/i965/brw_nir.c
index 3ead880..0a8d3a8 100644
--- a/src/mesa/drivers/dri/i965/brw_nir.c
+++ b/src/mesa/drivers/dri/i965/brw_nir.c
@@ -704,7 +704,7 @@ brw_nir_apply_sampler_key(nir_shader *nir,
 }
 
 enum brw_reg_type
-brw_type_for_nir_type(nir_alu_type type)
+brw_type_for_nir_type(const struct gen_device_info *devinfo, nir_alu_type type)
 {
switch (type) {
case nir_type_uint:
@@ -721,9 +721,9 @@ brw_type_for_nir_type(nir_alu_type type)
case nir_type_float64:
   return BRW_REGISTER_TYPE_DF;
case nir_type_int64:
-  return BRW_REGISTER_TYPE_Q;
+  return devinfo->gen < 8 ? BRW_REGISTER_TYPE_DF : BRW_REGISTER_TYPE_Q;
case nir_type_uint64:
-  return BRW_REGISTER_TYPE_UQ;
+  return devinfo->gen < 8 ? BRW_REGISTER_TYPE_DF : BRW_REGISTER_TYPE_UQ;
default:
   unreachable("unknown type");
}
diff --git a/src/mesa/drivers/dri/i965/brw_nir.h 
b/src/mesa/drivers/dri/i965/brw_nir.h
index 7e2f279..76d7ec8 100644
--- a/src/mesa/drivers/dri/i965/brw_nir.h
+++ b/src/mesa/drivers/dri/i965/brw_nir.h
@@ -129,7 +129,8 @@ nir_shader *brw_nir_apply_sampler_key(nir_shader *nir,
   const struct brw_sampler_prog_key_data 
*key,
   bool is_scalar);
 
-enum brw_reg_type brw_type_for_nir_type(nir_alu_type type);
+enum brw_reg_type brw_type_for_nir_type(const struct gen_device_info *devinfo,
+nir_alu_type type);
 
 enum glsl_base_type brw_glsl_base_type_for_nir_type(nir_alu_type type);
 
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_nir.cpp 
b/src/mesa/drivers/dri/i965/brw_vec4_nir.cpp
index 71156ec..2127415 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_nir.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_nir.cpp
@@ -296,7 +296,7 @@ vec4_visitor::get_nir_dest(const nir_dest , enum 
brw_reg_type type)
 dst_reg
 vec4_visitor::get_nir_dest(const nir_dest , nir_alu_type type)
 {
-   return get_nir_dest(dest, brw_type_for_nir_type(type));
+   return get_nir_dest(dest, brw_type_for_nir_type(devinfo, type));
 }
 
 src_reg
@@ -325,7 +325,8 @@ src_reg
 vec4_visitor::get_nir_src(const nir_src , nir_alu_type type,
   unsigned num_components)
 {
-   return get_nir_src(src, brw_type_for_nir_type(type), num_components);
+   return get_nir_src(src, brw_type_for_nir_type(devinfo, type),
+  num_components);
 }
 
 src_reg

[Mesa-dev] [PATCH 2/2] Revert "i965: Really don't emit Q or UQ moves on Gen < 8"

[Matt Turner]

This reverts commit c95380c4044237d73fb537511667c3c8f658fcee.
---
 src/mesa/drivers/dri/i965/brw_eu_emit.c | 8 
 1 file changed, 8 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_eu_emit.c 
b/src/mesa/drivers/dri/i965/brw_eu_emit.c
index 4b557d9..de6a1d9 100644
--- a/src/mesa/drivers/dri/i965/brw_eu_emit.c
+++ b/src/mesa/drivers/dri/i965/brw_eu_emit.c
@@ -94,14 +94,6 @@ unsigned
 brw_reg_type_to_hw_type(const struct gen_device_info *devinfo,
 enum brw_reg_type type, enum brw_reg_file file)
 {
-   /* If the type is Q or UQ and Gen < 8, change the type to DF.  On Gen < 8,
-* the only Q or UQ moves the should occur are actually to move doubles
-* anyway.
-*/
-   if (devinfo->gen < 8 && (type == BRW_REGISTER_TYPE_UQ ||
-type == BRW_REGISTER_TYPE_Q))
-  type = BRW_REGISTER_TYPE_DF;
-
if (file == BRW_IMMEDIATE_VALUE) {
   static const int imm_hw_types[] = {
  [BRW_REGISTER_TYPE_UD] = BRW_HW_REG_TYPE_UD,
-- 
2.7.3

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

[Mesa-dev] [Bug 99467] [radv] DOOM 2016 + wine. Green screen everywhere (but can be started)

[bugzilla-daemon]

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

--- Comment #6 from Pierre-Loup A. Griffais  ---
[re-posting with proper account]

The developers are already aware of the problem; it'll probably get addressed
in the next major update for DOOM.

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

[Mesa-dev] [Bug 99467] [radv] DOOM 2016 + wine. Green screen everywhere (but can be started)

[bugzilla-daemon]

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

--- Comment #5 from Pierre-Loup A. Griffais  ---
The developers are already aware of the problem; it'll probably get addressed
in the next major update for DOOM.

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

[Mesa-dev] [Bug 99467] [radv] DOOM 2016 + wine. Green screen everywhere (but can be started)

[bugzilla-daemon]

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

--- Comment #4 from Grazvydas Ignotas  ---
Good luck getting in touch with any of the devs of an AAA game company.

And I can't imagine why they'd want to fix it and have to redo the whole QA
just for some obscure platform the game is not supposed to work on in the first
place.

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

Re: [Mesa-dev] [PATCH] [rfc] spirv: work around doom shaders having load/store to sampler types

[Jason Ekstrand]

On Fri, Jan 20, 2017 at 4:46 PM, Ian Romanick  wrote:

> On 12/23/2016 06:46 AM, Jason Ekstrand wrote:
> > Bah... It's definitely illegal.  I had fix glslang myself.  I have some
> > NIR reworks planned that would make this work "properly" but it's a bit
> > more complicated than this hack.  That said, I'm very reluctant to fix
> > app bugs in our driver.  There are a lot of ways apps can go wrong with
> > Vulkan and we don't want to start down the road of hacking around them.
>
> Is this something the SPIR-V validator would flag?
>

Ideally, yes.  Unfortunately, I'm not sure how much SPIR-V validation
actually gets done.  Also, it's kind-of a weird corner of the spec that's
not as clear-cut as one would like it to be.  I interpreted it as "No, you
can't store a sampler in a variable.  That's silly" and fixed glslang.  I
believe I did try to get the spec fixed and it didn't really go anywhere.

--Jason


> > On Dec 22, 2016 22:57, "Dave Airlie"  > > wrote:
> >
> > From: Dave Airlie >
> >
> > Doom appears to generate SPIR-V that loads/store samplers before
> > passing them to functions, this confuses NIR, but I'm not sure
> > it's illegal.
> >
> > Workaround this by replacing the value on store with the access
> > chain from the src.
> >
> > This gets doom a bit further.
> >
> > Signed-off-by: Dave Airlie  > >
> > ---
> >  src/compiler/spirv/vtn_variables.c | 8 
> >  1 file changed, 8 insertions(+)
> >
> > diff --git a/src/compiler/spirv/vtn_variables.c
> > b/src/compiler/spirv/vtn_variables.c
> > index be64dd9..f6672c0 100644
> > --- a/src/compiler/spirv/vtn_variables.c
> > +++ b/src/compiler/spirv/vtn_variables.c
> > @@ -1437,6 +1437,14 @@ vtn_handle_variables(struct vtn_builder *b,
> > SpvOp opcode,
> > case SpvOpStore: {
> >struct vtn_access_chain *dest =
> >   vtn_value(b, w[1], vtn_value_type_access_chain)->
> access_chain;
> > +
> > +  if (glsl_get_base_type(dest->var->type->type) ==
> > GLSL_TYPE_SAMPLER) {
> > + struct vtn_value *val = vtn_untyped_value(b, w[2]);
> > + dest->var = val->access_chain->var;
> > + b->values[w[1]].value_type = vtn_value_type_invalid;
> > + vtn_push_value(b, w[1],
> > vtn_value_type_access_chain)->access_chain = val->access_chain;
> > + return;
> > +  }
> >struct vtn_ssa_value *src = vtn_ssa_value(b, w[2]);
> >vtn_variable_store(b, src, dest);
> >break;
> > --
> > 2.7.4
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org  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 mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] [rfc] spirv: work around doom shaders having load/store to sampler types

[Ian Romanick]

On 12/23/2016 06:46 AM, Jason Ekstrand wrote:
> Bah... It's definitely illegal.  I had fix glslang myself.  I have some
> NIR reworks planned that would make this work "properly" but it's a bit
> more complicated than this hack.  That said, I'm very reluctant to fix
> app bugs in our driver.  There are a lot of ways apps can go wrong with
> Vulkan and we don't want to start down the road of hacking around them.

Is this something the SPIR-V validator would flag?

> On Dec 22, 2016 22:57, "Dave Airlie"  > wrote:
> 
> From: Dave Airlie >
> 
> Doom appears to generate SPIR-V that loads/store samplers before
> passing them to functions, this confuses NIR, but I'm not sure
> it's illegal.
> 
> Workaround this by replacing the value on store with the access
> chain from the src.
> 
> This gets doom a bit further.
> 
> Signed-off-by: Dave Airlie  >
> ---
>  src/compiler/spirv/vtn_variables.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/src/compiler/spirv/vtn_variables.c
> b/src/compiler/spirv/vtn_variables.c
> index be64dd9..f6672c0 100644
> --- a/src/compiler/spirv/vtn_variables.c
> +++ b/src/compiler/spirv/vtn_variables.c
> @@ -1437,6 +1437,14 @@ vtn_handle_variables(struct vtn_builder *b,
> SpvOp opcode,
> case SpvOpStore: {
>struct vtn_access_chain *dest =
>   vtn_value(b, w[1], vtn_value_type_access_chain)->access_chain;
> +
> +  if (glsl_get_base_type(dest->var->type->type) ==
> GLSL_TYPE_SAMPLER) {
> + struct vtn_value *val = vtn_untyped_value(b, w[2]);
> + dest->var = val->access_chain->var;
> + b->values[w[1]].value_type = vtn_value_type_invalid;
> + vtn_push_value(b, w[1],
> vtn_value_type_access_chain)->access_chain = val->access_chain;
> + return;
> +  }
>struct vtn_ssa_value *src = vtn_ssa_value(b, w[2]);
>vtn_variable_store(b, src, dest);
>break;
> --
> 2.7.4
> 
> ___
> 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 mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 99467] [radv] DOOM 2016 + wine. Green screen everywhere (but can be started)

[bugzilla-daemon]

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

--- Comment #3 from Edward O'Callaghan  ---
(In reply to Grazvydas Ignotas from comment #2)
> Supposedly it's because the game is doing something illegal:
> https://lists.freedesktop.org/archives/mesa-dev/2016-December/138955.html
> 
> However because all the binary drivers handle it, and Doom (which I'd call
> Vulkan "killer app") relies on it, I'd say it's in the "de facto" Vulkan
> standard now and it'd be better if mesa handled it. I suspect others will
> disagree though...

Handling broken behavior is exactly how the vendor GL drivers got into a mess
so do you want that to happen to Vulkan also?

Why not try to contact the game vendor with a detailed report how they can
patch their shader code.

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

Re: [Mesa-dev] [PATCH 12/27] i965/gen6: Calculate stencil offset on demand

[Jason Ekstrand]

On Mon, Jan 16, 2017 at 1:13 AM, Topi Pohjolainen <
topi.pohjolai...@gmail.com> wrote:

> This is kept on purpose in i965. It can be moved to ISL if it
> is needed in vulkan.
>
> Pointers to miptrees are given solely for verification purposes.
> These will be dropped in following patches.
>
> Signed-off-by: Topi Pohjolainen 
> ---
>  src/mesa/drivers/dri/i965/brw_tex_layout.c| 65
> +++
>  src/mesa/drivers/dri/i965/gen6_depth_state.c  | 14 +++---
>  src/mesa/drivers/dri/i965/intel_mipmap_tree.h |  5 +++
>  3 files changed, 78 insertions(+), 6 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_tex_layout.c
> b/src/mesa/drivers/dri/i965/brw_tex_layout.c
> index 768f8a8..80b341a 100644
> --- a/src/mesa/drivers/dri/i965/brw_tex_layout.c
> +++ b/src/mesa/drivers/dri/i965/brw_tex_layout.c
> @@ -288,6 +288,71 @@ gen9_miptree_layout_1d(struct intel_mipmap_tree *mt)
> }
>  }
>
> +static unsigned
> +all_slices_at_each_lod_x_offset(unsigned w0, unsigned align, unsigned
> level)
> +{
> +   const unsigned w = level >= 2 ? minify(w0, 1) : 0;
> +   return ALIGN(w, align);
> +}
> +
> +static unsigned
> +all_slices_at_each_lod_y_offset(const struct isl_extent4d
> *phys_level0_sa,
> +enum isl_surf_dim dim, unsigned align,
> +unsigned level)
> +{
> +   unsigned y = 0;
> +
> +   /* Add vertical space taken by lower levels one by one. Levels one and
> two
> +* are side-by-side just below level zero. Levels three and greater are
> +* stacked one after another below level two.
> +*/
> +   for (unsigned i = 1; i <= level; ++i) {
> +  const unsigned d = dim == ISL_SURF_DIM_3D ?
> + minify(phys_level0_sa->depth, i - 1) :
> + phys_level0_sa->array_len;
> +
> +  /* Levels two and greater are stacked just below level zero. */
> +  if (i != 2) {
> + const unsigned h = minify(phys_level0_sa->height, i - 1);
> + y += d * ALIGN(h, align);
> +  }
> +   }
> +
> +   return y;
> +}
> +
> +uint32_t
> +brw_stencil_all_slices_at_each_lod_offset(const struct isl_surf *surf,
> +  const struct intel_mipmap_tree
> *mt,
> +  unsigned level)
> +{
> +   assert(mt->array_layout == ALL_SLICES_AT_EACH_LOD);
> +
> +   const unsigned halign = 64;
> +   const unsigned valign = 64;
> +   const unsigned level_x = all_slices_at_each_lod_x_offset(
> +  surf->phys_level0_sa.width, halign, level);
> +   const unsigned level_y = all_slices_at_each_lod_y_offset(
> +  >phys_level0_sa, surf->dim, valign, level);
> +
> +   assert(level_x == mt->level[level].level_x);
> +   assert(level_y == mt->level[level].level_y);
> +
> +   /* From Vol 2a, 11.5.6.2.1 3DSTATE_STENCIL_BUFFER, field "Surface
> Pitch":
> +*The pitch must be set to 2x the value computed based on width, as
> +*the stencil buffer is stored with two rows interleaved.
> +*
> +* While ISL surface stores the pitch expected by hardware, the offset
> +* into individual slices needs to be calculated as if rows are
> +* interleaved.
> +*/
> +   const unsigned two_rows_interleaved_pitch = surf->row_pitch / 2;
> +
> +   assert(two_rows_interleaved_pitch == mt->pitch);
> +
> +   return level_y * two_rows_interleaved_pitch + level_x * 64;
> +}
>

There's really no good place in this series to make this comment but I
think this is as good as I'm going to get...

I can't quite tell what your long-term plan is for gen6 stencil and HiZ.
Eventually, I'd like to kill the ALL_SLICES_AT_EACH_LOD stuff.  The only
reason why Jordan and the Igalia people did that in the first place was so
that they could re-use existing surface calculation code.  Really, the
requirement is that gen6 doesn't support multiple miplevels with HiZ and
Stencil even though it does support arrays.  The point of the
ALL_SLICES_AT_EACH_LOD layout is to, instead of making it an array of
miptrees, it lays it out into a bunch of single-LOD arrays.  The fact that
they happen to be layed out like a miptree is immaterial.

When Nanley and I were talking about this in the office, he had a very good
suggestion.  What he suggested was to just have an array of isl_surf's, one
for each miplevel and lay the single-LOD arrays out linearly in memory.  To
compute the size of the gen6 stencil or HiZ buffer you would do something
like this;

uint32_t size = 0;
for (level = 0; level < num_levels; level++) {
   isl_surf_init(>gen6_per_level[level].surf,
  .width = minify(width, level),
  .height = minify(height, level),
  .depth = 1,
  .levels = 1,
  .array_len = array_len,
  .format = ISL_FORMAT_HIZ,
  ...);
   mt->gen6_per_level[level].offset = size;
   size += mt->gen6_per_level[level].surf.size;
}

Then in the gen6 hiz and stencil setup code, 

Re: [Mesa-dev] [PATCH 21/27] intel/isl/gen7: Add CCS alignment restrictions

[Jason Ekstrand]

On Mon, Jan 16, 2017 at 1:13 AM, Topi Pohjolainen <
topi.pohjolai...@gmail.com> wrote:

> Gen8 and Gen9 are already more heavily constrained as one
> applies arrayed/mipmapped alignment even for non-arrayed and
> non-mipmapped.
>
> Signed-off-by: Topi Pohjolainen 
> ---
>  src/intel/isl/isl_gen7.c | 39 +++
>  1 file changed, 39 insertions(+)
>
> diff --git a/src/intel/isl/isl_gen7.c b/src/intel/isl/isl_gen7.c
> index 18687b5..b1874c1 100644
> --- a/src/intel/isl/isl_gen7.c
> +++ b/src/intel/isl/isl_gen7.c
> @@ -403,6 +403,45 @@ isl_gen7_choose_image_alignment_el(const struct
> isl_device *dev,
> /* IVB+ does not support combined depthstencil. */
> assert(!isl_surf_usage_is_depth_and_stencil(info->usage));
>
> +   const struct isl_format_layout *fmtl = isl_format_get_layout(info->
> format);
> +   if (fmtl->txc == ISL_TXC_CCS) {
> +  assert(tiling == ISL_TILING_CCS);
> +
> +  /*
> +   * IvyBrigde PRM Vol 2, Part 1, "11.7 MCS Buffer for Render
> Target(s)":
> +   *
> +   *  The following table describes the RT alignment
> +   *Pixels   Lines
> +   *  TiledY RT CL
> +   *  bpp
> +   *  32  84
> +   *  64  44
> +   *  128 24
> +   */
>

This isn't quite correct... Yes, the table above describes the horizontal
and vertical alignment of the single-sampled MCS on Ivy Bridge.  However,
ISL already takes care of this for us by its choice of block sizes.  Each
of the CCS formats is a "compressed" format with a block size that exactly
matches the alignment given in the table.  Since the alignment returned by
this function is in units of *elements*, the correct value should be 1x1
for all CCS formats on gen7.  For instance, GEN7_CCS_32BPP_Y is a
compressed format with a block size of 8x4 pixels per element and a 1x1el
alignment becomes 8x4px.  Does that make sense?  It's a bit subtle.


> +  switch (fmtl->format) {
> +  case ISL_FORMAT_GEN7_CCS_32BPP_X:
> + *image_align_el = isl_extent3d(8, 4, 1);
> + return;
> +  case ISL_FORMAT_GEN7_CCS_64BPP_X:
> + *image_align_el = isl_extent3d(4, 4, 1);
> + return;
> +  case ISL_FORMAT_GEN7_CCS_128BPP_X:
> + *image_align_el = isl_extent3d(2, 4, 1);
> + return;
> +  case ISL_FORMAT_GEN7_CCS_32BPP_Y:
> + *image_align_el = isl_extent3d(8, 4, 1);
> + return;
> +  case ISL_FORMAT_GEN7_CCS_64BPP_Y:
> + *image_align_el = isl_extent3d(4, 4, 1);
> + return;
> +  case ISL_FORMAT_GEN7_CCS_128BPP_Y:
> + *image_align_el = isl_extent3d(2, 4, 1);
> + return;
> +  default:
> + unreachable("Invalid CCS format");
> +  }
> +   }
> +
> *image_align_el = (struct isl_extent3d) {
>.w = gen7_choose_halign_el(dev, info),
>.h = gen7_choose_valign_el(dev, info, tiling),
> --
> 2.5.5
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 22/27] intel/isl: Apply render target alignment constraints for MCS

[Jason Ekstrand]

For HiZ, we did this directly in isl_choose_image_alignment_el in isl.c.
Maybe it's better to do it there given that they're all 4x4.

On Mon, Jan 16, 2017 at 1:13 AM, Topi Pohjolainen <
topi.pohjolai...@gmail.com> wrote:

> Otherwise i965 driver will start experiencing failures with
> "texelFetch fs sampler2DMSArray 4 98x1x9-98x129x9 -auto -fbo"
> on IVB, HSW and BDW when starts to use ISL to calculate the
> layout.
>
> The test is fine on SKL because one already hits:
>
>   if (isl_format_is_compressed(info->format)) {
>   /* On Gen9, the meaning of RENDER_SURFACE_STATE's
>* SurfaceHorizontalAlignment and SurfaceVerticalAlignment changed
> for
>* compressed formats. They now indicate a multiple of the
> compression
>* block.  For example, if the compression mode is ETC2 then HALIGN_4
>* indicates a horizontal alignment of 16 pixels.
>*
>* To avoid wasting memory, choose the smallest alignment possible:
>* HALIGN_4 and VALIGN_4.
>*/
>   *image_align_el = isl_extent3d(4, 4, 1);
>
> in isl_gen9_choose_image_alignment_el().
>
> However, the same fix is applied on Gen9 for consistency sake.
>
> Signed-off-by: Topi Pohjolainen 
> ---
>  src/intel/isl/isl_gen7.c | 16 
>  src/intel/isl/isl_gen8.c | 16 
>  src/intel/isl/isl_gen9.c | 16 
>  3 files changed, 48 insertions(+)
>
> diff --git a/src/intel/isl/isl_gen7.c b/src/intel/isl/isl_gen7.c
> index b1874c1..776d3bf 100644
> --- a/src/intel/isl/isl_gen7.c
> +++ b/src/intel/isl/isl_gen7.c
> @@ -442,6 +442,22 @@ isl_gen7_choose_image_alignment_el(const struct
> isl_device *dev,
>}
> }
>
> +   if (fmtl->txc == ISL_TXC_MCS) {
> +  assert(tiling == ISL_TILING_Y0);
> +
> +  /*
> +   * IvyBrigde PRM Vol 2, Part 1, "11.7 MCS Buffer for Render
> Target(s)":
> +   *
> +   * Height, width, and layout of MCS buffer in this case must match
> with
> +   * Render Target height, width, and layout. MCS buffer is tiledY.
> +   *
> +   * To avoid wasting memory, choose the smallest alignment possible:
> +   * HALIGN_4 and VALIGN_4.
> +   */
> +  *image_align_el = isl_extent3d(4, 4, 1);
> +  return;
> +   }
> +
> *image_align_el = (struct isl_extent3d) {
>.w = gen7_choose_halign_el(dev, info),
>.h = gen7_choose_valign_el(dev, info, tiling),
> diff --git a/src/intel/isl/isl_gen8.c b/src/intel/isl/isl_gen8.c
> index 81c69dc..c4f8f53 100644
> --- a/src/intel/isl/isl_gen8.c
> +++ b/src/intel/isl/isl_gen8.c
> @@ -205,6 +205,22 @@ isl_gen8_choose_image_alignment_el(const struct
> isl_device *dev,
>return;
> }
>
> +   if (fmtl->txc == ISL_TXC_MCS) {
> +  assert(tiling == ISL_TILING_Y0);
> +
> +  /*
> +   * Broadwell PRM Vol 7, "MCS Buffer for Render Target(s)":
> +   *
> +   * Height, width, and layout of MCS buffer in this case must match
> with
> +   * Render Target height, width, and layout. MCS buffer is tiledY.
> +   *
> +   * To avoid wasting memory, choose the smallest alignment possible:
> +   * HALIGN_4 and VALIGN_4.
> +   */
> +  *image_align_el = isl_extent3d(4, 4, 1);
> +  return;
> +   }
> +
> /* The below text from the Broadwell PRM provides some insight into the
>  * hardware's requirements for LOD alignment.  From the Broadwell PRM
> >>
>  * Volume 5: Memory Views >> Surface Layout >> 2D Surfaces:
> diff --git a/src/intel/isl/isl_gen9.c b/src/intel/isl/isl_gen9.c
> index e5d0f95..8709235 100644
> --- a/src/intel/isl/isl_gen9.c
> +++ b/src/intel/isl/isl_gen9.c
> @@ -119,6 +119,22 @@ isl_gen9_choose_image_alignment_el(const struct
> isl_device *dev,
>return;
> }
>
> +   if (fmtl->txc == ISL_TXC_MCS) {
> +  assert(tiling == ISL_TILING_Y0);
> +
> +  /*
> +   * Skylake PRM Vol 7, "MCS Buffer for Render Target(s)":
> +   *
> +   * Height, width, and layout of MCS buffer in this case must match
> with
> +   * Render Target height, width, and layout. MCS buffer is tiledY.
> +   *
> +   * To avoid wasting memory, choose the smallest alignment possible:
> +   * HALIGN_4 and VALIGN_4.
> +   */
> +  *image_align_el = isl_extent3d(4, 4, 1);
> +  return;
> +   }
> +
> /* This BSpec text provides some insight into the hardware's alignment
>  * requirements [Skylake BSpec > Memory Views > Common Surface Formats
> >
>  * Surface Layout and Tiling > 2D Surfaces]:
> --
> 2.5.5
>
> ___
> 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] [AppVeyor] mesa master #3217 failed

[AppVeyor]

Build mesa 3217 failed


Commit db6d23cfd2 by Ian Romanick on 9/1/2016 7:06 PM:

i965: Enable ARB_gpu_shader_int64 on Gen8+\n\nSigned-off-by: Ian Romanick \nReviewed-by: Matt Turner 


Configure your notification preferences

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

Re: [Mesa-dev] [PATCH v2 3/5] st/nine: set the MUL_ZERO_WINS flag when supported

[Ilia Mirkin]

Thanks!

In practice, on nv50, it checks the vertex shader for the flag, and on
nvc0 it's per-stage (since they killed the global override on
kepler+).

On Fri, Jan 20, 2017 at 5:48 PM, Axel Davy  wrote:
> With this patch, there is one case where we hit the "undefined case" of the
> spec (mismatch between different shaders): With streamout we use a dummy
> pixel created by utils instead of nine_shader.
>
> As we use software renderers for the feature doing the streamout, I guess
> that's ok for now.
>
> Thanks for the patches. I hope support from more drivers will follow, and
> that a GL extension will be implemented for wine.
>
> Patches 1-3 are Reviewed-by: 
>
>
> On 17/01/2017 04:28, Ilia Mirkin wrote:
>>
>> Signed-off-by: Ilia Mirkin 
>> ---
>>
>> v1 -> v2: make conditional on the cap being there
>>
>>   src/gallium/state_trackers/nine/nine_shader.c | 3 +++
>>   1 file changed, 3 insertions(+)
>>
>> diff --git a/src/gallium/state_trackers/nine/nine_shader.c
>> b/src/gallium/state_trackers/nine/nine_shader.c
>> index 0a75c07..95bc6ec 100644
>> --- a/src/gallium/state_trackers/nine/nine_shader.c
>> +++ b/src/gallium/state_trackers/nine/nine_shader.c
>> @@ -3564,6 +3564,9 @@ nine_translate_shader(struct NineDevice9 *device,
>> struct nine_shader_info *info,
>>   ureg_property(tx->ureg, TGSI_PROPERTY_FS_COORD_PIXEL_CENTER,
>> TGSI_FS_COORD_PIXEL_CENTER_INTEGER);
>>   }
>>   +if (GET_CAP(TGSI_MUL_ZERO_WINS))
>> +   ureg_property(tx->ureg, TGSI_PROPERTY_MUL_ZERO_WINS, 1);
>> +
>>   while (!sm1_parse_eof(tx) && !tx->failure)
>>   sm1_parse_instruction(tx);
>>   tx->parse++; /* for byte_size */
>
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 99477] [Master of Orion] Shader compile error: no matching function for call to `texture2DLod(sampler2D, vec2, float)';

[bugzilla-daemon]

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

Andreas Schultes  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO

--- Comment #4 from Andreas Schultes  ---
Thanks, I did a new run with apitrace and the shader compile error didn't
appear. This could be a missing #version 130. But still rendering errors in the
game. I'll do further investigations. I think this bug could be closed. On the
first apitrace with the error there was a GL state of a GLSL version, which
says it is 130. I'll check that tomorrow.

-- 
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 v2 3/5] st/nine: set the MUL_ZERO_WINS flag when supported

[Axel Davy]

With this patch, there is one case where we hit the "undefined case" of 
the spec (mismatch between different shaders): With streamout we use a 
dummy pixel created by utils instead of nine_shader.


As we use software renderers for the feature doing the streamout, I 
guess that's ok for now.


Thanks for the patches. I hope support from more drivers will follow, 
and that a GL extension will be implemented for wine.


Patches 1-3 are Reviewed-by: 

On 17/01/2017 04:28, Ilia Mirkin wrote:

Signed-off-by: Ilia Mirkin 
---

v1 -> v2: make conditional on the cap being there

  src/gallium/state_trackers/nine/nine_shader.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/src/gallium/state_trackers/nine/nine_shader.c 
b/src/gallium/state_trackers/nine/nine_shader.c
index 0a75c07..95bc6ec 100644
--- a/src/gallium/state_trackers/nine/nine_shader.c
+++ b/src/gallium/state_trackers/nine/nine_shader.c
@@ -3564,6 +3564,9 @@ nine_translate_shader(struct NineDevice9 *device, struct 
nine_shader_info *info,
  ureg_property(tx->ureg, TGSI_PROPERTY_FS_COORD_PIXEL_CENTER, 
TGSI_FS_COORD_PIXEL_CENTER_INTEGER);
  }
  
+if (GET_CAP(TGSI_MUL_ZERO_WINS))

+   ureg_property(tx->ureg, TGSI_PROPERTY_MUL_ZERO_WINS, 1);
+
  while (!sm1_parse_eof(tx) && !tx->failure)
  sm1_parse_instruction(tx);
  tx->parse++; /* for byte_size */



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

[Mesa-dev] [Bug 99477] [Master of Orion] Shader compile error: no matching function for call to `texture2DLod(sampler2D, vec2, float)';

[bugzilla-daemon]

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

--- Comment #3 from Kenneth Graunke  ---
Sorry, nevermind that - it exists in 1.30, it's just deprecated.  Should work
though.

-- 
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

[Mesa-dev] [Bug 99477] [Master of Orion] Shader compile error: no matching function for call to `texture2DLod(sampler2D, vec2, float)';

[bugzilla-daemon]

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

--- Comment #2 from Kenneth Graunke  ---
GLSL 1.30 does not include texture2DLod().  The function is called textureLod()
in #version 130.

-- 
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 3/3] i965: Use correct VertStride on align16 instructions.

[Francisco Jerez]

Matt Turner  writes:

> In commit c35fa7a, we changed the "width" of DF source registers to 2,
> which is conceptually fine. Unfortunately a VertStride of 2 is not
> allowed by align16 instructions on IVB/BYT, and the regular VertStride
> of 4 works fine in any case.
>

I'll try to throw some light onto why this works -- AFAIUI, in Align16
mode the vertical stride control doesn't behave as you would expect -- A
VertStride=0 does behave as expected and steps zero elements across rows
(modulo instruction decompression bugs), but on Gen7 any other value
simply behaves as "step by a fixed offset of 16B across rows".  On HSW
they explicitly allowed VertStride=2, but I don't think the hardware
became any smarter, it's still most likely a 16B fixed offset.  On IVB
neither VertStride=2 nor VertStride=4 is supposed to work for our
purposes (the former because it's supposedly not supported and the
latter because one would expect it to step by 4 DF elements = 32B per
16B row), but they both likely work in practice.  Anyway let's stick to
what the docs say is not illegal, a couple more comments below.

> See 
> generated_tests/spec/arb_gpu_shader_fp64/execution/built-in-functions/vs-round-double.shader_test
> for example:
>
> cmp.ge.f0(8)g18<1>DFg1<0>.xyxyDF-g8<2>DF{ align16 1Q 
> };
> ERROR: In Align16 mode, only VertStride of 0 or 4 is allowed
> cmp.ge.f0(8)g19<1>DFg1<0>.xyxyDF-g9<2>DF{ align16 2N 
> };
> ERROR: In Align16 mode, only VertStride of 0 or 4 is allowed
> ---
>  src/mesa/drivers/dri/i965/brw_eu_emit.c | 18 ++
>  1 file changed, 14 insertions(+), 4 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_eu_emit.c 
> b/src/mesa/drivers/dri/i965/brw_eu_emit.c
> index 888f95e..a01083f 100644
> --- a/src/mesa/drivers/dri/i965/brw_eu_emit.c
> +++ b/src/mesa/drivers/dri/i965/brw_eu_emit.c
> @@ -512,10 +512,15 @@ brw_set_src0(struct brw_codegen *p, brw_inst *inst, 
> struct brw_reg reg)
>/* This is an oddity of the fact we're using the same
> * descriptions for registers in align_16 as align_1:
> */

Maybe move the comment above into the BRW_VERTICAL_STRIDE_8 block so
nobody gets confused and thinks that the code you added has to do with
our representation of align_16 regions?

> -  if (reg.vstride == BRW_VERTICAL_STRIDE_8)
> + if (reg.vstride == BRW_VERTICAL_STRIDE_8) {
>  brw_inst_set_src0_vstride(devinfo, inst, BRW_VERTICAL_STRIDE_4);
> -  else
> + } else if (devinfo->gen == 7 && !devinfo->is_haswell &&
> +reg.type == BRW_REGISTER_TYPE_DF &&
> +reg.vstride >= BRW_VERTICAL_STRIDE_1) {

I think I'd only do this for BRW_VERTICAL_STRIDE_2, because DF Align16
regions with VertStride=4 really behave like VertStride=2.  If the
caller expected anything else it's not going to get it.

Maybe copy-paste the relevant spec text here and below to explain why we
only use BRW_VERTICAL_STRIDE_4?

> +brw_inst_set_src0_vstride(devinfo, inst, BRW_VERTICAL_STRIDE_4);
> + } else {
>  brw_inst_set_src0_vstride(devinfo, inst, reg.vstride);
> + }
>}
> }
>  }
> @@ -594,10 +599,15 @@ brw_set_src1(struct brw_codegen *p, brw_inst *inst, 
> struct brw_reg reg)
>/* This is an oddity of the fact we're using the same
> * descriptions for registers in align_16 as align_1:
> */
> -  if (reg.vstride == BRW_VERTICAL_STRIDE_8)
> + if (reg.vstride == BRW_VERTICAL_STRIDE_8) {
>  brw_inst_set_src1_vstride(devinfo, inst, BRW_VERTICAL_STRIDE_4);
> -  else
> + } else if (devinfo->gen == 7 && !devinfo->is_haswell &&
> +reg.type == BRW_REGISTER_TYPE_DF &&
> +reg.vstride >= BRW_VERTICAL_STRIDE_1) {
> +brw_inst_set_src1_vstride(devinfo, inst, BRW_VERTICAL_STRIDE_4);
> + } else {
>  brw_inst_set_src1_vstride(devinfo, inst, reg.vstride);
> + }
>}
> }
>  }
> -- 
> 2.7.3


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

[Mesa-dev] [PATCH] glsl: there is no need to check for < 0

[Christian Gmeiner]

size_t is defined in the C Standard section 4.1.5 as an
'unsigned integral type'.

Fixes the following clang compile warning:

glsl/blob.c:110:15: warning: comparison of unsigned expression < 0 is
always false [-Wtautological-compare]
   if (offset < 0 || blob->size - offset < to_write)
   ~~ ^ ~

Signed-off-by: Christian Gmeiner 
---
 src/compiler/glsl/blob.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/compiler/glsl/blob.c b/src/compiler/glsl/blob.c
index dd4341b..ef17255 100644
--- a/src/compiler/glsl/blob.c
+++ b/src/compiler/glsl/blob.c
@@ -107,7 +107,7 @@ blob_overwrite_bytes(struct blob *blob,
  size_t to_write)
 {
/* Detect an attempt to overwrite data out of bounds. */
-   if (offset < 0 || blob->size - offset < to_write)
+   if (blob->size - offset < to_write)
   return false;
 
memcpy(blob->data + offset, bytes, to_write);
-- 
2.9.3

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

[Mesa-dev] [Bug 97879] [amdgpu] Rocket League: long hangs (several seconds) when loading assets (models/textures/shaders?)

[bugzilla-daemon]

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

m...@pepelino.de changed:

   What|Removed |Added

 CC||m...@pepelino.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] etnaviv: Avoid infinite loop in find_frame()

[Christian Gmeiner]

Hi Rhys,

2017-01-19 7:02 GMT+01:00 Rhys Kidd :
> Use of unsigned loop control variable with '>= 0' would lead to infinite loop.
>
> Reported by clang:
>
> etnaviv_compiler.c:1024:39: warning: comparison of unsigned expression >= 0 is
>   always true [-Wtautological-compare]
>for (unsigned sp = c->frame_sp; sp >= 0; sp--)
>~~ ^  ~
>
> Signed-off-by: Rhys Kidd 
> ---
>  src/gallium/drivers/etnaviv/etnaviv_compiler.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> I compile tested etnaviv but have not functionally tested on real hardware.
>
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_compiler.c 
> b/src/gallium/drivers/etnaviv/etnaviv_compiler.c
> index 59e1452..f1c6787 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_compiler.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_compiler.c
> @@ -1021,7 +1021,7 @@ label_mark_use(struct etna_compile *c, struct 
> etna_compile_label *label)
>  static struct etna_compile_frame *
>  find_frame(struct etna_compile *c, enum etna_compile_frame_type type)
>  {
> -   for (unsigned sp = c->frame_sp; sp >= 0; sp--)
> +   for (unsigned sp = c->frame_sp + 1; sp-- > 0 ; )

looks quite ugly - I have a better and simpler fix.

>if (c->frame_stack[sp].type == type)
>   return >frame_stack[sp];
>
> --
> 2.9.3
>

8<---

Subject: [PATCH] etnaviv: Avoid infinite loop in find_frame()

Use of unsigned loop control variable with '>= 0' would lead to infinite
loop.

Reported by clang:

etnaviv_compiler.c:1024:39: warning: comparison of unsigned expression
>= 0 is always true [-Wtautological-compare]
   for (unsigned sp = c->frame_sp; sp >= 0; sp--)
   ~~ ^  ~

v2: Simply use the same datatype as c->frame_sp is using.

Reported-by: Rhys Kidd 
Signed-off-by: Christian Gmeiner 
---
 src/gallium/drivers/etnaviv/etnaviv_compiler.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/etnaviv/etnaviv_compiler.c
b/src/gallium/drivers/etnaviv/etnaviv_compiler.c
index 59e1452..dc9af57 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_compiler.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_compiler.c
@@ -1021,7 +1021,7 @@ label_mark_use(struct etna_compile *c, struct
etna_compile_label *label)
 static struct etna_compile_frame *
 find_frame(struct etna_compile *c, enum etna_compile_frame_type type)
 {
-   for (unsigned sp = c->frame_sp; sp >= 0; sp--)
+   for (int sp = c->frame_sp; sp >= 0; sp--)
   if (c->frame_stack[sp].type == type)
  return >frame_stack[sp];

-- 
2.9.3
8<---

If you are okay with that I will push it in the next days.

greets
--
Christian Gmeiner, MSc

https://www.youtube.com/user/AloryOFFICIAL
https://soundcloud.com/christian-gmeiner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 0/7] i965: Implement EGL_ANDROID_native_fence_sync

[Rafael Antognolli]

I have tested this series with the branches that you mentioned, and with
piglit with the patches from my own branch:

https://github.com/rantogno/piglit/tree/review/fences-v02

Everything seems to work fine. You can add:

Tested-by: Rafael Antognolli 

I also have gone through these patches several times while they were
under development, and they look good to me. So if you disregard my
shallow knowledge of Mesa, you could add:

Reviewed-by: Rafael Antognolli 

Thanks,
Rafael

On Fri, Jan 13, 2017 at 10:51:27AM -0800, Chad Versace wrote:
> This series depends on fence fd support in I915_GEM_EXECBUFFER2, which
> isn't upstream in libdrm nor the kernel yet.  I tested this with kmscube
> on Skylake, and everything looked good to me.
> 
> I pushed tags for this series as well as all the code I tested with:
> 
> mesa: 
> http://git.kiwitree.net/cgit/~chadv/mesa/tag/?h=chadv/review/i965-exec-fence-v03
> libdrm: 
> http://git.kiwitree.net/cgit/~chadv/libdrm/tag/?h=chadv/review/intel-exec-fence-v01
> linux: 
> http://git.kiwitree.net/cgit/~chadv/linux/tag/?h=chadv/test/i915-exec-fence-v03
> kmscube: 
> http://git.kiwitree.net/cgit/~chadv/kmscube/tag/?h=chadv/test/fences-v02
> 
> I submitted the libdrm patches to the intel-gfx list. Someone else
> should submit the kernel patches, as I tested them but don't grok them.
> 
> Chad Versace (7):
>   i965: Add intel_screen::has_fence_fd
>   i965: Add intel_batchbuffer_flush_fence()
>   i965/sync: Add brw_fence::type
>   i965/sync: Fail sync creation when batchbuffer flush fails
>   i965/sync: Rename brw_fence_insert()
>   WAIT: configure: Bump libdrm requirement to 2.4.XX
>   i965/sync: Implement fences based on Linux sync_file
> 
>  configure.ac  |   3 +-
>  src/mesa/drivers/dri/i965/brw_sync.c  | 293 
> ++
>  src/mesa/drivers/dri/i965/intel_batchbuffer.c |  24 ++-
>  src/mesa/drivers/dri/i965/intel_batchbuffer.h |  14 +-
>  src/mesa/drivers/dri/i965/intel_screen.c  |   3 +
>  src/mesa/drivers/dri/i965/intel_screen.h  |   2 +-
>  6 files changed, 287 insertions(+), 52 deletions(-)
> 
> -- 
> 2.11.0.21.ga274e0a
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 99477] [Master of Orion] Shader compile error: no matching function for call to `texture2DLod(sampler2D, vec2, float)';

[bugzilla-daemon]

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

--- Comment #1 from Ilia Mirkin  ---
Are you sure that the GLSL version is 1.30? i.e. do those shaders have a
#version 130 at the top? If not, they get GLSL version 1.10, which does not
have those functions.

You can force it globally with force_glsl_version=130 in case you're working
around buggy shaders.

-- 
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] spirv: don't assert with location decorations on non i/o variables

[Lionel Landwerlin]

On 20/01/17 20:40, Dave Airlie wrote:

On 21 January 2017 at 03:08, Jason Ekstrand  wrote:

On Fri, Jan 20, 2017 at 8:45 AM, Lionel Landwerlin
 wrote:

Some applications might add location decoration to samplers. Rather
than raising an error it seems it would make more sense to just
discard these decorations.


That's annoying but not the end of the world.  Please CC to 17.0 stable (but
not 13.0)  Also, please try and file a bug with the Unit3D people as this is
a bug in their SPIR-V generator.

I came across this a while ago and reported it via Valve.

I'm not sure where it got to, I had a patch that did much the same as this.

Maybe we should consider a mesa spir-v bugs layer to rewrite incoming
spir-v bugs before the driver.

Dave.



I'm trying to raise the issue with the debug layers : 
https://github.com/KhronosGroup/Vulkan-LoaderAndValidationLayers/issues/1378

We'll see where that leads.

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

[Mesa-dev] [AppVeyor] mesa master #3216 completed

[AppVeyor]

Build mesa 3216 completed



Commit 74c23bde5b by Lionel Landwerlin on 1/19/2017 4:20 PM:

anv: don't require render target isl bit for depth/stencil surfaces\n\nBlorp can deal with depth/stencil surfaces blits/copies without the\nrender target requirement. Also having both render target and\ndepth/stencil requirement is incompatible from isl's point of view.\n\nThis fixes an image creation issue in the high level quality settings\nof the Unity3D player, which requires a depth texture with src/dst\ntransfer & 4x multisampling.\n\nv2: Simply aspect checking condition (Jason)\n\nSigned-off-by: Lionel Landwerlin \nReviewed-by: Jason Ekstrand \nCc: 13.0 17.0 


Configure your notification preferences

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

Re: [Mesa-dev] [PATCH v2 09/20] i965/fs: indirect addressing with doubles is not supported in IVB/BYT

[Matt Turner]

On Tue, Jan 17, 2017 at 1:49 AM, Samuel Iglesias Gonsálvez
 wrote:
> It is tested empirically that IVB/BYT don't support indirect addressing
> with doubles but it is not documented in the PRM.
>
> This patch applies the same solution than for Cherryview/Broxton and
> takes into account that we cannot double the stride, since the
> hardware will do it internally.
>
> v2:
> - Fix assert to take into account Indirect DF MOVs in IVB and HSW.
>
> Signed-off-by: Samuel Iglesias Gonsálvez 
> ---

These two tests uncover a bug in this patch

spec/arb_gpu_shader_fp64/execution/fs-indirect-temp-double-const-src
spec/arb_gpu_shader_fp64/uniform_buffers/fs-double-uniform-array-direct-indirect

They generate

add(8)  a0<1>UW g6<4,4,1>UW 0x0070UW{ align1 1Q };
mov(8)  g10<1>UDg[a0]UD{ align1 1Q };
add(8)  a0<1>UW g6.8<4,4,1>UW   0x0070UW{ align1 2N };
mov(8)  g7<1>UD g[a0]UD{ align1 2N };
add(8)  a0<1>UW g8<4,4,1>UW 0x0070UW{ align1 1Q };
mov(8)  g10.1<1>UD  g[a0]UD{ align1 1Q };
ERROR: Writes must be evenly split between the two destination registers
add(8)  a0<1>UW g8.8<4,4,1>UW   0x0070UW{ align1 2N };
mov(8)  g7.1<1>UD   g[a0]UD{ align1 2N };
ERROR: Writes must be evenly split between the two destination registers

I think the mov(8)s from g[a0]UD are supposed to be mov(4).

I would have thought that lower_simd_width was the appropriate place
to split SHADER_OPCODE_MOV_INDIRECT, rather than directly in the
translation from NIR (as in commit bdab572a8). Maybe if that were
fixed the solution to this problem would be somewhat simpler?

Curro, what do you think?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 99477] [Master of Orion] Shader compile error: no matching function for call to `texture2DLod(sampler2D, vec2, float)';

[bugzilla-daemon]

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

Bug ID: 99477
   Summary: [Master of Orion] Shader compile error: no matching
function for call to `texture2DLod(sampler2D, vec2,
float)';
   Product: Mesa
   Version: git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: glsl-compiler
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: andreas.schul...@googlemail.com
QA Contact: intel-3d-b...@lists.freedesktop.org

Shader compile error: no matching function for call to `texture2DLod(sampler2D,
vec2, float)';

It's implemented in builtin_functions.cpp! GLSL Version is 1.30 

Got from apitrace:

//Vertex
uniform vec4 vfuniforms[144];
attribute vec4 pos;
attribute float vbatch;
varying vec4 fucxadd;
varying vec4 fucxmul;
varying vec2 tc0;
void main() {
gl_Position = vec4(0.0,0,0.0,1);
gl_Position.x = dot(pos, vfuniforms[int(vbatch * 6.0 + 2.0+ 0.1 + 0.0)]);
gl_Position.y = dot(pos, vfuniforms[int(vbatch * 6.0 + 2.0+ 0.1 + 1.0)]);
tc0.x = dot(pos, vfuniforms[int(vbatch * 6.0 + 4.0+ 0.1 + 0.0)]);
tc0.y = dot(pos, vfuniforms[int(vbatch * 6.0 + 4.0+ 0.1 + 1.0)]);
fucxadd = vfuniforms[int(vbatch * 6.0 + 0.0+ 0.1)];
fucxmul = vfuniforms[int(vbatch * 6.0 + 1.0+ 0.1)];
}


//Fragment
uniform vec4 fsize;
uniform sampler2D tex;
uniform vec4 texscale;
varying vec4 fucxadd;
varying vec4 fucxmul;
varying vec2 tc0;
void main() {
gl_FragColor   = vec4(0.0, 0.0, 0.0, 0.0);
vec4 color = vec4(0.0, 0.0, 0.0, 0.0);
float  i = 0.0;
for (i = -fsize.x; i <= fsize.x; i++)
{{
color += texture2DLod(tex, tc0 + i * texscale.xy, 0.0);
}} // EndBox1/2.
gl_FragColor = color * fsize.w;
gl_FragColor = (gl_FragColor * vec4(fucxmul.rgb,1.0)) * fucxmul.a;
gl_FragColor += fucxadd * gl_FragColor.a;
gl_FragColor = gl_FragColor;
}

0:13(10): error: no matching function for call to `texture2DLod(sampler2D,
vec2, float)'; candidates are:
0:13(1): error: operands to arithmetic operators must be numeric
0:13(1): error: could not implicitly convert error to vec4

-- 
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

[Mesa-dev] [PATCH 2/3] i965/vec4: Fix exec size for MOVs SET_{HIGH, LOW}_32BIT.

[Matt Turner]

Otherwise for a pack_double_2x32_split opcode, we emit:

   vec1 64 ssa_135 = pack_double_2x32_split ssa_133, ssa_134
mov(8)  g5<1>UD g5<4>.xUD   { align16 1Q 
compacted };
mov(8)  g7<2>UD g5<4,4,1>UD { align1 1Q };
ERROR: When the destination spans two registers, the source must span 
two registers
   (exceptions for scalar source and packed-word to packed-dword 
expansion)
mov(8)  g8<2>UD g5.4<4,4,1>UD   { align1 2N };
ERROR: The offset from the two source registers must be the same
mov(8)  g5<1>UD g6<4>.xUD   { align16 1Q 
compacted };
mov(8)  g7.1<2>UD   g5<4,4,1>UD { align1 1Q };
ERROR: When the destination spans two registers, the source must span 
two registers
   (exceptions for scalar source and packed-word to packed-dword 
expansion)
mov(8)  g8.1<2>UD   g5.4<4,4,1>UD   { align1 2N };
ERROR: The offset from the two source registers must be the same

The intention was to emit mov(4)s for the instructions that have ERROR
annotations.

See tests/spec/arb_gpu_shader_fp64/execution/vs-isinf-dvec.shader_test
for example.
---
 src/mesa/drivers/dri/i965/brw_vec4_generator.cpp | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/brw_vec4_generator.cpp 
b/src/mesa/drivers/dri/i965/brw_vec4_generator.cpp
index b570792..f6034bc 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_generator.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_generator.cpp
@@ -2025,6 +2025,7 @@ generate_code(struct brw_codegen *p,
  assert(type_sz(dst.type) == 8);
 
  brw_set_default_access_mode(p, BRW_ALIGN_1);
+ brw_set_default_exec_size(p, BRW_EXECUTE_4);
 
  dst = retype(dst, BRW_REGISTER_TYPE_UD);
  if (inst->opcode == VEC4_OPCODE_SET_HIGH_32BIT)
@@ -2037,6 +2038,7 @@ generate_code(struct brw_codegen *p,
  src[0].hstride = BRW_HORIZONTAL_STRIDE_1;
  brw_MOV(p, dst, src[0]);
 
+ brw_set_default_exec_size(p, BRW_EXECUTE_8);
  brw_set_default_access_mode(p, BRW_ALIGN_16);
  break;
   }
-- 
2.7.3

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

[Mesa-dev] [PATCH 1/3] i965: Handle IVB DF differences in the validator.

[Matt Turner]

On IVB/BYT, region parameters and execution size for DF are in terms of
32-bit elements, so they are doubled. For evaluating the validity of an
instruction, we halve them.
---
 src/mesa/drivers/dri/i965/brw_eu_validate.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/brw_eu_validate.c 
b/src/mesa/drivers/dri/i965/brw_eu_validate.c
index 2265394..0787029 100644
--- a/src/mesa/drivers/dri/i965/brw_eu_validate.c
+++ b/src/mesa/drivers/dri/i965/brw_eu_validate.c
@@ -466,6 +466,10 @@ general_restrictions_based_on_operand_types(const struct 
gen_device_info *devinf
   brw_hw_reg_type_to_size(devinfo, exec_type, BRW_GENERAL_REGISTER_FILE);
unsigned dst_type_size = brw_element_size(devinfo, inst, dst);
 
+   if (devinfo->gen == 7 && !devinfo->is_haswell &&
+   exec_type_size == 8 && dst_type_size == 4)
+  dst_type_size = 8;
+
if (exec_type_size > dst_type_size) {
   ERROR_IF(dst_stride * dst_type_size != exec_type_size,
"Destination stride must be equal to the ratio of the sizes of "
@@ -575,6 +579,10 @@ general_restrictions_on_region_parameters(const struct 
gen_device_info *devinfo,
   }
 #undef DO_SRC
 
+  if (devinfo->gen == 7 && !devinfo->is_haswell &&
+  element_size == 8)
+ element_size = 4;
+
   /* ExecSize must be greater than or equal to Width. */
   ERROR_IF(exec_size < width, "ExecSize must be greater than or equal "
   "to Width");
@@ -791,6 +799,10 @@ region_alignment_rules(const struct gen_device_info 
*devinfo,
if (error_msg.str)
   return error_msg;
 
+   if (devinfo->gen == 7 && !devinfo->is_haswell &&
+   element_size == 8)
+  element_size = 4;
+
align1_access_mask(dst_access_mask, exec_size, element_size, subreg,
   exec_size == 1 ? 0 : exec_size * stride,
   exec_size == 1 ? 1 : exec_size,
-- 
2.7.3

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

[Mesa-dev] [PATCH 0/3] i965: IVB/BYT fp64 fixes

[Matt Turner]

I committed my EU validator earlier today. It's caught three bugs in the IVB
fp64 series. Patches 2 and 3 fix two of them. I'll respond directly to the
patch in Igalia's series that introduces the other bug.

These should go in with Igalia's series, before the extension is turned on.

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

[Mesa-dev] [PATCH 3/3] i965: Use correct VertStride on align16 instructions.

[Matt Turner]

In commit c35fa7a, we changed the "width" of DF source registers to 2,
which is conceptually fine. Unfortunately a VertStride of 2 is not
allowed by align16 instructions on IVB/BYT, and the regular VertStride
of 4 works fine in any case.

See 
generated_tests/spec/arb_gpu_shader_fp64/execution/built-in-functions/vs-round-double.shader_test
for example:

cmp.ge.f0(8)g18<1>DFg1<0>.xyxyDF-g8<2>DF{ align16 1Q };
ERROR: In Align16 mode, only VertStride of 0 or 4 is allowed
cmp.ge.f0(8)g19<1>DFg1<0>.xyxyDF-g9<2>DF{ align16 2N };
ERROR: In Align16 mode, only VertStride of 0 or 4 is allowed
---
 src/mesa/drivers/dri/i965/brw_eu_emit.c | 18 ++
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_eu_emit.c 
b/src/mesa/drivers/dri/i965/brw_eu_emit.c
index 888f95e..a01083f 100644
--- a/src/mesa/drivers/dri/i965/brw_eu_emit.c
+++ b/src/mesa/drivers/dri/i965/brw_eu_emit.c
@@ -512,10 +512,15 @@ brw_set_src0(struct brw_codegen *p, brw_inst *inst, 
struct brw_reg reg)
 /* This is an oddity of the fact we're using the same
  * descriptions for registers in align_16 as align_1:
  */
-if (reg.vstride == BRW_VERTICAL_STRIDE_8)
+ if (reg.vstride == BRW_VERTICAL_STRIDE_8) {
 brw_inst_set_src0_vstride(devinfo, inst, BRW_VERTICAL_STRIDE_4);
-else
+ } else if (devinfo->gen == 7 && !devinfo->is_haswell &&
+reg.type == BRW_REGISTER_TYPE_DF &&
+reg.vstride >= BRW_VERTICAL_STRIDE_1) {
+brw_inst_set_src0_vstride(devinfo, inst, BRW_VERTICAL_STRIDE_4);
+ } else {
 brw_inst_set_src0_vstride(devinfo, inst, reg.vstride);
+ }
   }
}
 }
@@ -594,10 +599,15 @@ brw_set_src1(struct brw_codegen *p, brw_inst *inst, 
struct brw_reg reg)
 /* This is an oddity of the fact we're using the same
  * descriptions for registers in align_16 as align_1:
  */
-if (reg.vstride == BRW_VERTICAL_STRIDE_8)
+ if (reg.vstride == BRW_VERTICAL_STRIDE_8) {
 brw_inst_set_src1_vstride(devinfo, inst, BRW_VERTICAL_STRIDE_4);
-else
+ } else if (devinfo->gen == 7 && !devinfo->is_haswell &&
+reg.type == BRW_REGISTER_TYPE_DF &&
+reg.vstride >= BRW_VERTICAL_STRIDE_1) {
+brw_inst_set_src1_vstride(devinfo, inst, BRW_VERTICAL_STRIDE_4);
+ } else {
 brw_inst_set_src1_vstride(devinfo, inst, reg.vstride);
+ }
   }
}
 }
-- 
2.7.3

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

[Mesa-dev] [PATCH] intel/blorp/copy: Properly handle clear colors for CCS_E images

[Jason Ekstrand]

In order to handle CCS_E, we stomp the image format to a UINT format and
then do some bitcasting logic in the shader.  This works fine since SKL
render compression only considers the channel layout of the format and
not the format itself.  In order for this to work on images that have
been fast-cleared, we need to also convert the clear color so that, when
interpreted as UINT, it provides the same bit value as it would have in
the original format.  This fixes a bunch of OpenGL ES CTS tests for
copy_image when we start using CCS more aggressively.

Cc: "17.0" 
Cc: Ben Widawsky 
Cc: Topi Pohjolainen 
---
 src/intel/blorp/blorp_blit.c | 82 
 1 file changed, 82 insertions(+)

diff --git a/src/intel/blorp/blorp_blit.c b/src/intel/blorp/blorp_blit.c
index 1cbd940..111f1c1 100644
--- a/src/intel/blorp/blorp_blit.c
+++ b/src/intel/blorp/blorp_blit.c
@@ -26,6 +26,9 @@
 #include "blorp_priv.h"
 #include "brw_meta_util.h"
 
+/* header-only include needed for _mesa_unorm_to_float and friends. */
+#include "mesa/main/format_utils.h"
+
 #define FILE_DEBUG_FLAG DEBUG_BLORP
 
 static const bool split_blorp_blit_debug = false;
@@ -2204,6 +2207,75 @@ get_ccs_compatible_uint_format(const struct 
isl_format_layout *fmtl)
}
 }
 
+/* Takes an isl_color_value and returns a color value that is the original
+ * color value only bit-casted to a UINT format.  This value, together with
+ * the format from get_ccs_compatible_uint_format, will yield the same bit
+ * value as the original color and format.
+ */
+static union isl_color_value
+bitcast_color_value_to_uint(union isl_color_value color,
+const struct isl_format_layout *fmtl)
+{
+   /* All CCS formats have the same number of bits in each channel */
+   const struct isl_channel_layout *chan = >channels.r;
+
+   union isl_color_value bits;
+   switch (chan->type) {
+   case ISL_UINT:
+   case ISL_SINT:
+  /* Hardware will ignore the high bits so there's no need to cast */
+  bits = color;
+  break;
+
+   case ISL_UNORM:
+  for (unsigned i = 0; i < 4; i++)
+ bits.u32[i] = _mesa_float_to_unorm(color.f32[i], chan->bits);
+  break;
+
+   case ISL_SNORM:
+  for (unsigned i = 0; i < 4; i++)
+ bits.i32[i] = _mesa_float_to_snorm(color.f32[i], chan->bits);
+  break;
+
+   case ISL_SFLOAT:
+  switch (chan->bits) {
+  case 16:
+ for (unsigned i = 0; i < 4; i++)
+bits.u32[i] = _mesa_float_to_half(color.f32[i]);
+ break;
+
+  case 32:
+ bits = color;
+ break;
+
+  default:
+ unreachable("Invalid float format size");
+  }
+  break;
+
+   default:
+  unreachable("Invalid channel type");
+   }
+
+   switch (fmtl->format) {
+   case ISL_FORMAT_B8G8R8A8_UNORM:
+   case ISL_FORMAT_B8G8R8A8_UNORM_SRGB:
+   case ISL_FORMAT_B8G8R8X8_UNORM:
+   case ISL_FORMAT_B8G8R8X8_UNORM_SRGB: {
+  /* If it's a BGRA format, we need to swap blue and red */
+  uint32_t tmp = bits.u32[0];
+  bits.u32[0] = bits.u32[2];
+  bits.u32[2] = tmp;
+  break;
+   }
+
+   default:
+  break; /* Nothing to do */
+   }
+
+   return bits;
+}
+
 static void
 surf_convert_to_uncompressed(const struct isl_device *isl_dev,
  struct brw_blorp_surface_info *info,
@@ -2320,6 +2392,16 @@ blorp_copy(struct blorp_batch *batch,
   params.src.view.format = get_copy_format_for_bpb(isl_dev, src_fmtl->bpb);
}
 
+   if (params.src.aux_usage == ISL_AUX_USAGE_CCS_E) {
+  params.src.clear_color =
+ bitcast_color_value_to_uint(params.src.clear_color, src_fmtl);
+   }
+
+   if (params.dst.aux_usage == ISL_AUX_USAGE_CCS_E) {
+  params.dst.clear_color =
+ bitcast_color_value_to_uint(params.dst.clear_color, dst_fmtl);
+   }
+
wm_prog_key.src_bpc =
   isl_format_get_layout(params.src.view.format)->channels.r.bits;
wm_prog_key.dst_bpc =
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [Bug 99413] Rust game have wrong colors

[bugzilla-daemon]

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

--- Comment #2 from Gustaw Smolarczyk  ---
IIRC Rust has undefined behavior in its shader(s) or something like that.

>From what I remember, running Rust without steam overlay (I think just running
it from command line instead of Steam GUI did the trick) fixed this issue
(based on what I wrote above it might have been pure luck).

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
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] spirv: don't assert with location decorations on non i/o variables

[Dave Airlie]

On 21 January 2017 at 03:08, Jason Ekstrand  wrote:
> On Fri, Jan 20, 2017 at 8:45 AM, Lionel Landwerlin
>  wrote:
>>
>> Some applications might add location decoration to samplers. Rather
>> than raising an error it seems it would make more sense to just
>> discard these decorations.
>
>
> That's annoying but not the end of the world.  Please CC to 17.0 stable (but
> not 13.0)  Also, please try and file a bug with the Unit3D people as this is
> a bug in their SPIR-V generator.

I came across this a while ago and reported it via Valve.

I'm not sure where it got to, I had a patch that did much the same as this.

Maybe we should consider a mesa spir-v bugs layer to rewrite incoming
spir-v bugs before the driver.

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

[Mesa-dev] [Bug 99413] Rust game have wrong colors

[bugzilla-daemon]

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

--- Comment #1 from gtc...@gmail.com ---
Same here. Ubuntu 16.10, kernel 4.8, Mesa 17-dev padoka ppa. GPU Radeon HD 7870

That said: the driver performance is great if compared to the closed source
driver. Absolutely superior! But the colors are wrong: blue/pink trees, neon
green water, white or reddish grass. Trees, water and flowers (decor) are
glowing like neon in the night. If shaders reduced below 200 (game options),
ground textures are lost.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
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] nir: add min/max optimisation

[Jason Ekstrand]

On Wed, Jan 18, 2017 at 8:27 AM, Jason Ekstrand 
wrote:

> Reviewed-by: Jason Ekstrand 
>
>
pushed.


> On Jan 18, 2017 3:23 AM, "Elie Tournier"  wrote:
>
> Add the following optimisations:
>
> min(x, -x) = -abs(x)
> min(x, -abs(x)) = -abs(x)
> min(x, abs(x)) = x
> max(x, -abs(x)) = x
> max(x, abs(x)) = abs(x)
> max(x, -x) = abs(x)
>
> shader-db:
>
> total instructions in shared programs: 13067779 -> 13067775 (-0.00%)
> instructions in affected programs: 249 -> 245 (-1.61%)
> helped: 4
> HURT: 0
>
> total cycles in shared programs: 252054838 -> 252054806 (-0.00%)
> cycles in affected programs: 504 -> 472 (-6.35%)
> helped: 2
> HURT: 0
>
> Signed-off-by: Elie Tournier 
> ---
>  src/compiler/nir/nir_opt_algebraic.py | 12 
>  1 file changed, 12 insertions(+)
>
> diff --git a/src/compiler/nir/nir_opt_algebraic.py
> b/src/compiler/nir/nir_opt_algebraic.py
> index a557f7bf37..0dfa53fbf4 100644
> --- a/src/compiler/nir/nir_opt_algebraic.py
> +++ b/src/compiler/nir/nir_opt_algebraic.py
> @@ -171,6 +171,18 @@ optimizations = [
> (('imax', a, a), a),
> (('umin', a, a), a),
> (('umax', a, a), a),
> +   (('fmin', a, ('fneg', a)), ('fneg', ('fabs', a))),
> +   (('imin', a, ('ineg', a)), ('ineg', ('iabs', a))),
> +   (('fmin', a, ('fneg', ('fabs', a))), ('fneg', ('fabs', a))),
> +   (('imin', a, ('ineg', ('iabs', a))), ('ineg', ('iabs', a))),
> +   (('fmin', a, ('fabs', a)), a),
> +   (('imin', a, ('iabs', a)), a),
> +   (('fmax', a, ('fneg', ('fabs', a))), a),
> +   (('imax', a, ('ineg', ('iabs', a))), a),
> +   (('fmax', a, ('fabs', a)), ('fabs', a)),
> +   (('imax', a, ('iabs', a)), ('iabs', a)),
> +   (('fmax', a, ('fneg', a)), ('fabs', a)),
> +   (('imax', a, ('ineg', a)), ('iabs', a)),
> (('~fmin', ('fmax', a, 0.0), 1.0), ('fsat', a),
> '!options->lower_fsat'),
> (('~fmax', ('fmin', a, 1.0), 0.0), ('fsat', a),
> '!options->lower_fsat'),
> (('fsat', a), ('fmin', ('fmax', a, 0.0), 1.0), 'options->lower_fsat'),
> --
> 2.11.0
>
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [AppVeyor] mesa master #3215 failed

[AppVeyor]

Build mesa 3215 failed


Commit 0ae1f4a5ea by Matt Turner on 11/22/2016 6:40 PM:

i965: Split gen_device_info_i965 between brw and cl.\n\ncl (Crestline) supports a few more things than brw (Broadwater). Sort\nand sync PCI IDs from the kernel.\n\nThe G45 PRMs use the following code names\n\n   PRM Codename   Marketing\n   DevBW Broadwater   GMA X3000\n   DevCL CrestlineGMA X3100\n   DevBW-E   Bearlake GMA X3500\n\nDevBW-E seems to just be the "E stepping" of Broadwater, with some\nsoftware-visible fixes that we've never implemented.\n\nhttps://en.wikipedia.org/wiki/List_of_Intel_chipsets


Configure your notification preferences

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

Re: [Mesa-dev] [PATCH] [swr] Align query results allocation

[Cherniak, Bruce]

Reviewed-by: Bruce Cherniak 


> On Jan 20, 2017, at 1:44 PM, George Kyriazis  
> wrote:
> 
> Some query results struct contents are declared as cache line aligned.
> Use aligned malloc, and align the whole struct, to be safe.
> 
> Fixes crash when compiling with clang.
> 
> CC: 
> 
> ---
> src/gallium/drivers/swr/swr_query.cpp | 7 ---
> src/gallium/drivers/swr/swr_query.h   | 2 +-
> 2 files changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/src/gallium/drivers/swr/swr_query.cpp 
> b/src/gallium/drivers/swr/swr_query.cpp
> index 6eb0781..e097790 100644
> --- a/src/gallium/drivers/swr/swr_query.cpp
> +++ b/src/gallium/drivers/swr/swr_query.cpp
> @@ -29,7 +29,7 @@
> #include "swr_query.h"
> #include "swr_screen.h"
> #include "swr_state.h"
> -
> +#include "common/os.h"
> 
> static struct swr_query *
> swr_query(struct pipe_query *p)
> @@ -45,7 +45,8 @@ swr_create_query(struct pipe_context *pipe, unsigned type, 
> unsigned index)
>assert(type < PIPE_QUERY_TYPES);
>assert(index < MAX_SO_STREAMS);
> 
> -   pq = CALLOC_STRUCT(swr_query);
> +   pq = (struct swr_query *) AlignedMalloc(sizeof(struct swr_query), 64);
> +   memset(pq, 0, sizeof(*pq));
> 
>if (pq) {
>   pq->type = type;
> @@ -67,7 +68,7 @@ swr_destroy_query(struct pipe_context *pipe, struct 
> pipe_query *q)
>   swr_fence_reference(pipe->screen, >fence, NULL);
>}
> 
> -   FREE(pq);
> +   AlignedFree(pq);
> }
> 
> 
> diff --git a/src/gallium/drivers/swr/swr_query.h 
> b/src/gallium/drivers/swr/swr_query.h
> index c5160ce..1c736e4 100644
> --- a/src/gallium/drivers/swr/swr_query.h
> +++ b/src/gallium/drivers/swr/swr_query.h
> @@ -34,7 +34,7 @@ struct swr_query_result {
>uint64_t timestamp_end;
> };
> 
> -struct swr_query {
> +OSALIGNLINE(struct) swr_query {
>unsigned type; /* PIPE_QUERY_* */
>unsigned index;
> 
> -- 
> 2.7.4
> 
> ___
> 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] [PATCH] [swr] Align query results allocation

[George Kyriazis]

Some query results struct contents are declared as cache line aligned.
Use aligned malloc, and align the whole struct, to be safe.

Fixes crash when compiling with clang.

CC: 

---
 src/gallium/drivers/swr/swr_query.cpp | 7 ---
 src/gallium/drivers/swr/swr_query.h   | 2 +-
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/src/gallium/drivers/swr/swr_query.cpp 
b/src/gallium/drivers/swr/swr_query.cpp
index 6eb0781..e097790 100644
--- a/src/gallium/drivers/swr/swr_query.cpp
+++ b/src/gallium/drivers/swr/swr_query.cpp
@@ -29,7 +29,7 @@
 #include "swr_query.h"
 #include "swr_screen.h"
 #include "swr_state.h"
-
+#include "common/os.h"
 
 static struct swr_query *
 swr_query(struct pipe_query *p)
@@ -45,7 +45,8 @@ swr_create_query(struct pipe_context *pipe, unsigned type, 
unsigned index)
assert(type < PIPE_QUERY_TYPES);
assert(index < MAX_SO_STREAMS);
 
-   pq = CALLOC_STRUCT(swr_query);
+   pq = (struct swr_query *) AlignedMalloc(sizeof(struct swr_query), 64);
+   memset(pq, 0, sizeof(*pq));
 
if (pq) {
   pq->type = type;
@@ -67,7 +68,7 @@ swr_destroy_query(struct pipe_context *pipe, struct 
pipe_query *q)
   swr_fence_reference(pipe->screen, >fence, NULL);
}
 
-   FREE(pq);
+   AlignedFree(pq);
 }
 
 
diff --git a/src/gallium/drivers/swr/swr_query.h 
b/src/gallium/drivers/swr/swr_query.h
index c5160ce..1c736e4 100644
--- a/src/gallium/drivers/swr/swr_query.h
+++ b/src/gallium/drivers/swr/swr_query.h
@@ -34,7 +34,7 @@ struct swr_query_result {
uint64_t timestamp_end;
 };
 
-struct swr_query {
+OSALIGNLINE(struct) swr_query {
unsigned type; /* PIPE_QUERY_* */
unsigned index;
 
-- 
2.7.4

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

Re: [Mesa-dev] [PATCH 11/27] i965/hiz/gen6: Stop setting false qpitch

[Jason Ekstrand]

Reviewed-by: Jason Ekstrand 

On Mon, Jan 16, 2017 at 1:13 AM, Topi Pohjolainen <
topi.pohjolai...@gmail.com> wrote:

> which is not applicable for "all slices at each lod". Current
> logic makes one to believe it has some purpose. When miptree
> layout is calculated brw_miptree_layout_texture_array() sets
> the qpitch unconditionally but later on ignores it altogether
> for ALL_SLICES_AT_EACH_LOD.
>
> Signed-off-by: Topi Pohjolainen 
> ---
>  src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> index 606d4c2..825c6a0 100644
> --- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> +++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> @@ -1901,7 +1901,13 @@ intel_hiz_miptree_buf_create(struct brw_context
> *brw,
> buf->aux_base.bo = buf->mt->bo;
> buf->aux_base.size = buf->mt->total_height * buf->mt->pitch;
> buf->aux_base.pitch = buf->mt->pitch;
> -   buf->aux_base.qpitch = buf->mt->qpitch;
> +
> +   /* On gen6 hiz is unconditionally laid out packing all slices
> +* at each level-of-detail (LOD). This means there is no valid qpitch
> +* setting. In fact, this is ignored when hardware is setup - there is
> no
> +* hardware qpitch setting of hiz on gen6.
> +*/
> +   buf->aux_base.qpitch = 0;
>
> return buf;
>  }
> --
> 2.5.5
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 10/27] i965/blorp/gen6: Drop unnecessary stencil/hiz surf dimension adjust

[Jason Ekstrand]

On Mon, Jan 16, 2017 at 1:13 AM, Topi Pohjolainen <
topi.pohjolai...@gmail.com> wrote:

> Hardware state setup only needs offset and pitch and ignores the
> rest.
>

True... But it seems a a bit sketchy to lie to blorp even if the lie is
ok.  This isn't a NAK, just a comment for now.  I need to read further to
get more context.


> Signed-off-by: Topi Pohjolainen 
> ---
>  src/mesa/drivers/dri/i965/brw_blorp.c | 57 --
> -
>  1 file changed, 20 insertions(+), 37 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_blorp.c
> b/src/mesa/drivers/dri/i965/brw_blorp.c
> index ecf27a1..2001cf3 100644
> --- a/src/mesa/drivers/dri/i965/brw_blorp.c
> +++ b/src/mesa/drivers/dri/i965/brw_blorp.c
> @@ -107,36 +107,6 @@ brw_blorp_init(struct brw_context *brw)
>  }
>
>  static void
> -apply_gen6_stencil_hiz_offset(struct isl_surf *surf,
> -  struct intel_mipmap_tree *mt,
> -  uint32_t lod,
> -  uint32_t *offset)
> -{
> -   assert(mt->array_layout == ALL_SLICES_AT_EACH_LOD);
> -
> -   if (mt->format == MESA_FORMAT_S_UINT8) {
> -  /* Note: we can't compute the stencil offset using
> -   * intel_miptree_get_aligned_offset(), because the miptree
> -   * claims that the region is untiled even though it's W tiled.
> -   */
> -  *offset = mt->level[lod].level_y * mt->pitch +
> -mt->level[lod].level_x * 64;
> -   } else {
> -  *offset = intel_miptree_get_aligned_offset(mt,
> - mt->level[lod].level_x,
> - mt->level[lod].level_y);
> -   }
> -
> -   surf->logical_level0_px.width = minify(surf->logical_level0_px.width,
> lod);
> -   surf->logical_level0_px.height = minify(surf->logical_level0_px.height,
> lod);
> -   surf->phys_level0_sa.width = minify(surf->phys_level0_sa.width, lod);
> -   surf->phys_level0_sa.height = minify(surf->phys_level0_sa.height,
> lod);
> -   surf->levels = 1;
> -   surf->array_pitch_el_rows =
> -  ALIGN(surf->phys_level0_sa.height, surf->image_alignment_el.
> height);
> -}
> -
> -static void
>  blorp_surf_for_miptree(struct brw_context *brw,
> struct blorp_surf *surf,
> struct intel_mipmap_tree *mt,
> @@ -181,10 +151,17 @@ blorp_surf_for_miptree(struct brw_context *brw,
> * hacks inside the i965 driver.
> *
> * See also gen6_depth_stencil_state.c
> +   *
> +   * Note: we can't compute the stencil offset using
> +   * intel_miptree_get_aligned_offset(), because the miptree
> +   * claims that the region is untiled even though it's W tiled.
> +   *
> +   * In stencil state setup only surf->row_pitch and surf->addr get
> +   * consulted. Otherwise surf is ignored and there is no need to
> adjust
> +   * it any further.  See blorp_emit_depth_stencil_config().
> */
> -  uint32_t offset;
> -  apply_gen6_stencil_hiz_offset(_surfs[0], mt, *level, );
> -  surf->addr.offset += offset;
> +  surf->addr.offset += (mt->level[*level].level_y * mt->pitch +
> +mt->level[*level].level_x * 64);
>*level = 0;
> }
>
> @@ -254,11 +231,17 @@ blorp_surf_for_miptree(struct brw_context *brw,
> hiz_mt->array_layout == ALL_SLICES_AT_EACH_LOD);
>
>  /* gen6 requires the HiZ buffer to be manually offset to the
> - * right location.  We could fixup the surf but it doesn't
> - * matter since most of those fields don't matter.
> + * right location.
> + * In depth state setup only surf->aux_surf.row_pitch gets
> + * consulted. Otherwise surf->aux_surf is ignored and there is
> + * no need to adjust it.  See blorp_emit_depth_stencil_
> config().
> + *
> + * surf->aux_surf.row_pitch in turn is set by
> + * intel_miptree_get_aux_isl_surf().
>   */
> -apply_gen6_stencil_hiz_offset(aux_surf, hiz_mt, *level,
> -  >aux_addr.offset);
> +surf->aux_addr.offset = intel_miptree_get_aligned_
> offset(hiz_mt,
> +   hiz_mt->level[*level].level_x,
> +   hiz_mt->level[*level].level_y);
>  assert(hiz_mt->pitch == aux_surf->row_pitch);
>   }
>}
> --
> 2.5.5
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 09/27] i965/gen6: Remove dead code in hiz surface setup

[Jason Ekstrand]

6-9 are

Reviewed-by: Jason Ekstrand 

On Mon, Jan 16, 2017 at 1:13 AM, Topi Pohjolainen <
topi.pohjolai...@gmail.com> wrote:

> In intel_hiz_miptree_buf_create() the miptree is unconditionally
> created with MIPTREE_LAYOUT_FORCE_ALL_SLICE_AT_LOD.
>
> Signed-off-by: Topi Pohjolainen 
> ---
>  src/mesa/drivers/dri/i965/gen6_depth_state.c | 13 ++---
>  1 file changed, 6 insertions(+), 7 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/gen6_depth_state.c
> b/src/mesa/drivers/dri/i965/gen6_depth_state.c
> index 0ff2407..cda66e8 100644
> --- a/src/mesa/drivers/dri/i965/gen6_depth_state.c
> +++ b/src/mesa/drivers/dri/i965/gen6_depth_state.c
> @@ -162,14 +162,13 @@ gen6_emit_depth_stencil_hiz(struct brw_context *brw,
>if (hiz) {
>   assert(depth_mt);
>   struct intel_mipmap_tree *hiz_mt = depth_mt->hiz_buf->mt;
> - uint32_t offset = 0;
>
> - if (hiz_mt->array_layout == ALL_SLICES_AT_EACH_LOD) {
> -offset = intel_miptree_get_aligned_offset(
> -hiz_mt,
> -hiz_mt->level[lod].level_x,
> -hiz_mt->level[lod].level_y);
> - }
> + assert(hiz_mt->array_layout == ALL_SLICES_AT_EACH_LOD);
> +
> + const uint32_t offset = intel_miptree_get_aligned_offset(
> +hiz_mt,
> +hiz_mt->level[lod].level_x,
> +hiz_mt->level[lod].level_y);
>
>  BEGIN_BATCH(3);
>  OUT_BATCH((_3DSTATE_HIER_DEPTH_BUFFER << 16) | (3 - 2));
> --
> 2.5.5
>
> ___
> 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] [PATCH 1/2] gallium/radeon: refactor the GRBM counters path

[Samuel Pitoiset]

This will allow to expose more queries in order to know which
blocks are busy/idle.

Signed-off-by: Samuel Pitoiset 
---
 src/gallium/drivers/radeon/r600_gpu_load.c| 55 ++-
 src/gallium/drivers/radeon/r600_pipe_common.h | 18 +
 src/gallium/drivers/radeon/r600_query.c   | 14 +++
 3 files changed, 44 insertions(+), 43 deletions(-)

diff --git a/src/gallium/drivers/radeon/r600_gpu_load.c 
b/src/gallium/drivers/radeon/r600_gpu_load.c
index e3488b3ac7..38ddda1652 100644
--- a/src/gallium/drivers/radeon/r600_gpu_load.c
+++ b/src/gallium/drivers/radeon/r600_gpu_load.c
@@ -35,6 +35,7 @@
  */
 
 #include "r600_pipe_common.h"
+#include "r600_query.h"
 #include "os/os_time.h"
 
 /* For good accuracy at 1000 fps or lower. This will be inaccurate for higher
@@ -45,6 +46,12 @@
 #define SPI_BUSY(x)(((x) >> 22) & 0x1)
 #define GUI_ACTIVE(x)  (((x) >> 31) & 0x1)
 
+#define UPDATE_COUNTER(field, mask)\
+   if (mask(value))\
+   p_atomic_inc(>named.field.busy);  \
+   else\
+   p_atomic_inc(>named.field.idle);
+
 static void r600_update_grbm_counters(struct r600_common_screen *rscreen,
  union r600_grbm_counters *counters)
 {
@@ -52,15 +59,8 @@ static void r600_update_grbm_counters(struct 
r600_common_screen *rscreen,
 
rscreen->ws->read_registers(rscreen->ws, GRBM_STATUS, 1, );
 
-   if (SPI_BUSY(value))
-   p_atomic_inc(>named.spi_busy);
-   else
-   p_atomic_inc(>named.spi_idle);
-
-   if (GUI_ACTIVE(value))
-   p_atomic_inc(>named.gui_busy);
-   else
-   p_atomic_inc(>named.gui_idle);
+   UPDATE_COUNTER(spi, SPI_BUSY);
+   UPDATE_COUNTER(gui, GUI_ACTIVE);
 }
 
 static PIPE_THREAD_ROUTINE(r600_gpu_load_thread, param)
@@ -104,8 +104,8 @@ void r600_gpu_load_kill_thread(struct r600_common_screen 
*rscreen)
rscreen->gpu_load_thread = 0;
 }
 
-static uint64_t r600_read_counter(struct r600_common_screen *rscreen,
- unsigned busy_index)
+static uint64_t r600_read_grbm_counter(struct r600_common_screen *rscreen,
+  unsigned busy_index)
 {
/* Start the thread if needed. */
if (!rscreen->gpu_load_thread) {
@@ -123,10 +123,10 @@ static uint64_t r600_read_counter(struct 
r600_common_screen *rscreen,
return busy | ((uint64_t)idle << 32);
 }
 
-static unsigned r600_end_counter(struct r600_common_screen *rscreen,
-uint64_t begin, unsigned busy_index)
+static unsigned r600_end_grbm_counter(struct r600_common_screen *rscreen,
+ uint64_t begin, unsigned busy_index)
 {
-   uint64_t end = r600_read_counter(rscreen, busy_index);
+   uint64_t end = r600_read_grbm_counter(rscreen, busy_index);
unsigned busy = (end & 0x) - (begin & 0x);
unsigned idle = (end >> 32) - (begin >> 32);
 
@@ -147,25 +147,28 @@ static unsigned r600_end_counter(struct 
r600_common_screen *rscreen,
}
 }
 
-#define BUSY_INDEX(rscreen, field) (>grbm_counters.named.field##_busy 
- \
+#define BUSY_INDEX(rscreen, field) (>grbm_counters.named.field.busy - 
\
rscreen->grbm_counters.array)
 
-uint64_t r600_begin_counter_spi(struct r600_common_screen *rscreen)
-{
-   return r600_read_counter(rscreen, BUSY_INDEX(rscreen, spi));
-}
-
-unsigned r600_end_counter_spi(struct r600_common_screen *rscreen, uint64_t 
begin)
+static unsigned busy_index_from_type(struct r600_common_screen *rscreen,
+unsigned type)
 {
-   return r600_end_counter(rscreen, begin, BUSY_INDEX(rscreen, spi));
+   switch (type) {
+   case R600_QUERY_GPU_LOAD: return BUSY_INDEX(rscreen, gui);
+   case R600_QUERY_GPU_SHADERS_BUSY: return BUSY_INDEX(rscreen, spi);
+   default: unreachable("query type does not correspond to grbm id");
+   }
 }
 
-uint64_t r600_begin_counter_gui(struct r600_common_screen *rscreen)
+uint64_t r600_begin_counter(struct r600_common_screen *rscreen, unsigned type)
 {
-   return r600_read_counter(rscreen, BUSY_INDEX(rscreen, gui));
+   unsigned busy_index = busy_index_from_type(rscreen, type);
+   return r600_read_grbm_counter(rscreen, busy_index);
 }
 
-unsigned r600_end_counter_gui(struct r600_common_screen *rscreen, uint64_t 
begin)
+unsigned r600_end_counter(struct r600_common_screen *rscreen, unsigned type,
+ uint64_t begin)
 {
-   return r600_end_counter(rscreen, begin, BUSY_INDEX(rscreen, gui));
+   unsigned busy_index = busy_index_from_type(rscreen, type);
+   return r600_end_grbm_counter(rscreen, begin, busy_index);
 }
diff --git 

[Mesa-dev] [PATCH 2/2] gallium/radeon: add HUD queries for monitoring some hw blocks

[Samuel Pitoiset]

It's also possible to monitor them via performance counters but
the hardware can only use two counters simultaneously. It seems
easier to re-use the existing code which reads from MMIO instead
of writing a multi-pass approach.

Signed-off-by: Samuel Pitoiset 
---
 src/gallium/drivers/radeon/r600_gpu_load.c| 36 +
 src/gallium/drivers/radeon/r600_pipe_common.h | 12 +
 src/gallium/drivers/radeon/r600_query.c   | 39 ++-
 src/gallium/drivers/radeon/r600_query.h   | 12 +
 4 files changed, 98 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/radeon/r600_gpu_load.c 
b/src/gallium/drivers/radeon/r600_gpu_load.c
index 38ddda1652..8f5568c2dc 100644
--- a/src/gallium/drivers/radeon/r600_gpu_load.c
+++ b/src/gallium/drivers/radeon/r600_gpu_load.c
@@ -43,7 +43,19 @@
 #define SAMPLES_PER_SEC 1
 
 #define GRBM_STATUS0x8010
+#define TA_BUSY(x) (((x) >> 14) & 0x1)
+#define GDS_BUSY(x)(((x) >> 15) & 0x1)
+#define VGT_BUSY(x)(((x) >> 17) & 0x1)
+#define IA_BUSY(x) (((x) >> 19) & 0x1)
+#define SX_BUSY(x) (((x) >> 20) & 0x1)
+#define WD_BUSY(x) (((x) >> 21) & 0x1)
 #define SPI_BUSY(x)(((x) >> 22) & 0x1)
+#define BCI_BUSY(x)(((x) >> 23) & 0x1)
+#define SC_BUSY(x) (((x) >> 24) & 0x1)
+#define PA_BUSY(x) (((x) >> 25) & 0x1)
+#define DB_BUSY(x) (((x) >> 26) & 0x1)
+#define CP_BUSY(x) (((x) >> 29) & 0x1)
+#define CB_BUSY(x) (((x) >> 30) & 0x1)
 #define GUI_ACTIVE(x)  (((x) >> 31) & 0x1)
 
 #define UPDATE_COUNTER(field, mask)\
@@ -59,7 +71,19 @@ static void r600_update_grbm_counters(struct 
r600_common_screen *rscreen,
 
rscreen->ws->read_registers(rscreen->ws, GRBM_STATUS, 1, );
 
+   UPDATE_COUNTER(ta, TA_BUSY);
+   UPDATE_COUNTER(gds, GDS_BUSY);
+   UPDATE_COUNTER(vgt, VGT_BUSY);
+   UPDATE_COUNTER(ia, IA_BUSY);
+   UPDATE_COUNTER(sx, SX_BUSY);
+   UPDATE_COUNTER(wd, WD_BUSY);
UPDATE_COUNTER(spi, SPI_BUSY);
+   UPDATE_COUNTER(bci, BCI_BUSY);
+   UPDATE_COUNTER(sc, SC_BUSY);
+   UPDATE_COUNTER(pa, PA_BUSY);
+   UPDATE_COUNTER(db, DB_BUSY);
+   UPDATE_COUNTER(cp, CP_BUSY);
+   UPDATE_COUNTER(cb, CB_BUSY);
UPDATE_COUNTER(gui, GUI_ACTIVE);
 }
 
@@ -156,6 +180,18 @@ static unsigned busy_index_from_type(struct 
r600_common_screen *rscreen,
switch (type) {
case R600_QUERY_GPU_LOAD: return BUSY_INDEX(rscreen, gui);
case R600_QUERY_GPU_SHADERS_BUSY: return BUSY_INDEX(rscreen, spi);
+   case R600_QUERY_GPU_TA_BUSY: return BUSY_INDEX(rscreen, ta);
+   case R600_QUERY_GPU_GDS_BUSY: return BUSY_INDEX(rscreen, gds);
+   case R600_QUERY_GPU_VGT_BUSY: return BUSY_INDEX(rscreen, vgt);
+   case R600_QUERY_GPU_IA_BUSY: return BUSY_INDEX(rscreen, ia);
+   case R600_QUERY_GPU_SX_BUSY: return BUSY_INDEX(rscreen, sx);
+   case R600_QUERY_GPU_WD_BUSY: return BUSY_INDEX(rscreen, wd);
+   case R600_QUERY_GPU_BCI_BUSY: return BUSY_INDEX(rscreen, bci);
+   case R600_QUERY_GPU_SC_BUSY: return BUSY_INDEX(rscreen, sc);
+   case R600_QUERY_GPU_PA_BUSY: return BUSY_INDEX(rscreen, pa);
+   case R600_QUERY_GPU_DB_BUSY: return BUSY_INDEX(rscreen, db);
+   case R600_QUERY_GPU_CP_BUSY: return BUSY_INDEX(rscreen, cp);
+   case R600_QUERY_GPU_CB_BUSY: return BUSY_INDEX(rscreen, cb);
default: unreachable("query type does not correspond to grbm id");
}
 }
diff --git a/src/gallium/drivers/radeon/r600_pipe_common.h 
b/src/gallium/drivers/radeon/r600_pipe_common.h
index e340e6f7f1..afb1385f97 100644
--- a/src/gallium/drivers/radeon/r600_pipe_common.h
+++ b/src/gallium/drivers/radeon/r600_pipe_common.h
@@ -361,6 +361,18 @@ union r600_grbm_counters {
struct {
struct r600_grbm_counter spi;
struct r600_grbm_counter gui;
+   struct r600_grbm_counter ta;
+   struct r600_grbm_counter gds;
+   struct r600_grbm_counter vgt;
+   struct r600_grbm_counter ia;
+   struct r600_grbm_counter sx;
+   struct r600_grbm_counter wd;
+   struct r600_grbm_counter bci;
+   struct r600_grbm_counter sc;
+   struct r600_grbm_counter pa;
+   struct r600_grbm_counter db;
+   struct r600_grbm_counter cp;
+   struct r600_grbm_counter cb;
} named;
unsigned array[0];
 };
diff --git a/src/gallium/drivers/radeon/r600_query.c 
b/src/gallium/drivers/radeon/r600_query.c
index 1f9f191049..25e7f5bb23 100644
--- a/src/gallium/drivers/radeon/r600_query.c
+++ b/src/gallium/drivers/radeon/r600_query.c
@@ -146,6 +146,18 @@ static bool r600_query_sw_begin(struct r600_common_context 
*rctx,
}
case R600_QUERY_GPU_LOAD:
case 

[Mesa-dev] [PATCH 7/8] android: support creating texture from gralloc buffer

[Mauro Rossi]

Il lunedì 9 gennaio 2017, Zhen Wu > ha scritto:

> Thanks for your review, Rob. Using kms-dri would mean writing a new
> gralloc to basically the same thing as
> gralloc.default and moving to grm_gralloc seems to be a bigger task meant
> for another day. But I agree we would
> want to avoid introducing dependency. Would extending drisw loader func
> and limit gralloc dependency in egl_android
> ok with you?
>

Just to avoid a stall situation,

I get that Rob comments are here as here is the gralloc dependency to be
avoided.
Is this assumption correct?

BTW I can also confirm patches are working as I tested with Android CTS
dEQP test for EGL and GLES2 modules with marshmallow-x86

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

[Mesa-dev] [PATCH 2/7] winsys/amdgpu: drop all IBs if at least one was rejected within the context

[Marek Olšák]

From: Marek Olšák 

The corruption is inevitable and hangs are possible too.
---
 src/gallium/winsys/amdgpu/drm/amdgpu_cs.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c 
b/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c
index d63ff36..0bc4ce9 100644
--- a/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c
+++ b/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c
@@ -1032,25 +1032,31 @@ void amdgpu_cs_submit_ib(void *job, int thread_index)
}
 
if (r) {
   fprintf(stderr, "amdgpu: buffer list creation failed (%d)\n", r);
   cs->request.resources = NULL;
   amdgpu_fence_signalled(cs->fence);
   cs->error_code = r;
   goto cleanup;
}
 
-   r = amdgpu_cs_submit(acs->ctx->ctx, 0, >request, 1);
+   if (acs->ctx->num_rejected_cs)
+  r = -ECANCELED;
+   else
+  r = amdgpu_cs_submit(acs->ctx->ctx, 0, >request, 1);
+
cs->error_code = r;
if (r) {
   if (r == -ENOMEM)
  fprintf(stderr, "amdgpu: Not enough memory for command 
submission.\n");
+  else if (r == -ECANCELED)
+ fprintf(stderr, "amdgpu: The CS has been cancelled because the 
context is lost.\n");
   else
  fprintf(stderr, "amdgpu: The CS has been rejected, "
  "see dmesg for more information (%i).\n", r);
 
   amdgpu_fence_signalled(cs->fence);
 
   acs->ctx->num_rejected_cs++;
   ws->num_total_rejected_cs++;
} else {
   /* Success. */
-- 
2.7.4

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

[Mesa-dev] [PATCH 3/7] gallium/radeon: adjust the rule for using the LINEAR_ALIGNED layout

[Marek Olšák]

From: Marek Olšák 

---
 src/gallium/drivers/radeon/r600_texture.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/radeon/r600_texture.c 
b/src/gallium/drivers/radeon/r600_texture.c
index cba4e7d..0b77c82 100644
--- a/src/gallium/drivers/radeon/r600_texture.c
+++ b/src/gallium/drivers/radeon/r600_texture.c
@@ -1177,21 +1177,23 @@ r600_choose_tiling(struct r600_common_screen *rscreen,
if (rscreen->chip_class >= SI &&
(templ->bind & PIPE_BIND_CURSOR))
return RADEON_SURF_MODE_LINEAR_ALIGNED;
 
if (templ->bind & PIPE_BIND_LINEAR)
return RADEON_SURF_MODE_LINEAR_ALIGNED;
 
/* Textures with a very small height are recommended to be 
linear. */
if (templ->target == PIPE_TEXTURE_1D ||
templ->target == PIPE_TEXTURE_1D_ARRAY ||
-   templ->height0 <= 4)
+   /* Only very thin and long 2D textures should benefit from
+* linear_aligned. */
+   (templ->width0 > 8 && templ->height0 <= 2))
return RADEON_SURF_MODE_LINEAR_ALIGNED;
 
/* Textures likely to be mapped often. */
if (templ->usage == PIPE_USAGE_STAGING ||
templ->usage == PIPE_USAGE_STREAM)
return RADEON_SURF_MODE_LINEAR_ALIGNED;
}
 
/* Make small textures 1D tiled. */
if (templ->width0 <= 16 || templ->height0 <= 16 ||
-- 
2.7.4

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

[Mesa-dev] [PATCH 1/7] winsys/amdgpu: report a rejected IB as a lost context

[Marek Olšák]

From: Marek Olšák 

---
 src/gallium/winsys/amdgpu/drm/amdgpu_cs.c | 11 +++
 src/gallium/winsys/amdgpu/drm/amdgpu_cs.h |  2 ++
 src/gallium/winsys/amdgpu/drm/amdgpu_winsys.h |  1 +
 3 files changed, 14 insertions(+)

diff --git a/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c 
b/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c
index 87246f7..d63ff36 100644
--- a/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c
+++ b/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c
@@ -171,20 +171,21 @@ static struct radeon_winsys_ctx *amdgpu_ctx_create(struct 
radeon_winsys *ws)
struct amdgpu_ctx *ctx = CALLOC_STRUCT(amdgpu_ctx);
int r;
struct amdgpu_bo_alloc_request alloc_buffer = {};
amdgpu_bo_handle buf_handle;
 
if (!ctx)
   return NULL;
 
ctx->ws = amdgpu_winsys(ws);
ctx->refcount = 1;
+   ctx->initial_num_total_rejected_cs = ctx->ws->num_total_rejected_cs;
 
r = amdgpu_cs_ctx_create(ctx->ws->dev, >ctx);
if (r) {
   fprintf(stderr, "amdgpu: amdgpu_cs_ctx_create failed. (%i)\n", r);
   goto error_create;
}
 
alloc_buffer.alloc_size = ctx->ws->info.gart_page_size;
alloc_buffer.phys_alignment = ctx->ws->info.gart_page_size;
alloc_buffer.preferred_heap = AMDGPU_GEM_DOMAIN_GTT;
@@ -220,20 +221,27 @@ static void amdgpu_ctx_destroy(struct radeon_winsys_ctx 
*rwctx)
amdgpu_ctx_unref((struct amdgpu_ctx*)rwctx);
 }
 
 static enum pipe_reset_status
 amdgpu_ctx_query_reset_status(struct radeon_winsys_ctx *rwctx)
 {
struct amdgpu_ctx *ctx = (struct amdgpu_ctx*)rwctx;
uint32_t result, hangs;
int r;
 
+   /* Return a failure due to a rejected command submission. */
+   if (ctx->ws->num_total_rejected_cs > ctx->initial_num_total_rejected_cs) {
+  return ctx->num_rejected_cs ? PIPE_GUILTY_CONTEXT_RESET :
+PIPE_INNOCENT_CONTEXT_RESET;
+   }
+
+   /* Return a failure due to a GPU hang. */
r = amdgpu_cs_query_reset_state(ctx->ctx, , );
if (r) {
   fprintf(stderr, "amdgpu: amdgpu_cs_query_reset_state failed. (%i)\n", r);
   return PIPE_NO_RESET;
}
 
switch (result) {
case AMDGPU_CTX_GUILTY_RESET:
   return PIPE_GUILTY_CONTEXT_RESET;
case AMDGPU_CTX_INNOCENT_RESET:
@@ -1034,20 +1042,23 @@ void amdgpu_cs_submit_ib(void *job, int thread_index)
r = amdgpu_cs_submit(acs->ctx->ctx, 0, >request, 1);
cs->error_code = r;
if (r) {
   if (r == -ENOMEM)
  fprintf(stderr, "amdgpu: Not enough memory for command 
submission.\n");
   else
  fprintf(stderr, "amdgpu: The CS has been rejected, "
  "see dmesg for more information (%i).\n", r);
 
   amdgpu_fence_signalled(cs->fence);
+
+  acs->ctx->num_rejected_cs++;
+  ws->num_total_rejected_cs++;
} else {
   /* Success. */
   uint64_t *user_fence = NULL;
   if (amdgpu_cs_has_user_fence(cs))
  user_fence = acs->ctx->user_fence_cpu_address_base +
   cs->request.fence_info.offset;
   amdgpu_fence_submitted(cs->fence, >request, user_fence);
}
 
/* Cleanup. */
diff --git a/src/gallium/winsys/amdgpu/drm/amdgpu_cs.h 
b/src/gallium/winsys/amdgpu/drm/amdgpu_cs.h
index 5f181a5..90b9e83 100644
--- a/src/gallium/winsys/amdgpu/drm/amdgpu_cs.h
+++ b/src/gallium/winsys/amdgpu/drm/amdgpu_cs.h
@@ -34,20 +34,22 @@
 
 #include "amdgpu_bo.h"
 #include "util/u_memory.h"
 
 struct amdgpu_ctx {
struct amdgpu_winsys *ws;
amdgpu_context_handle ctx;
amdgpu_bo_handle user_fence_bo;
uint64_t *user_fence_cpu_address_base;
int refcount;
+   unsigned initial_num_total_rejected_cs;
+   unsigned num_rejected_cs;
 };
 
 struct amdgpu_cs_buffer {
struct amdgpu_winsys_bo *bo;
union {
   struct {
  uint64_t priority_usage;
   } real;
   struct {
  uint32_t real_idx; /* index of underlying real BO */
diff --git a/src/gallium/winsys/amdgpu/drm/amdgpu_winsys.h 
b/src/gallium/winsys/amdgpu/drm/amdgpu_winsys.h
index 2a7900a..c56c342 100644
--- a/src/gallium/winsys/amdgpu/drm/amdgpu_winsys.h
+++ b/src/gallium/winsys/amdgpu/drm/amdgpu_winsys.h
@@ -48,20 +48,21 @@ struct amdgpu_winsys {
struct radeon_winsys base;
struct pipe_reference reference;
struct pb_cache bo_cache;
struct pb_slabs bo_slabs;
 
amdgpu_device_handle dev;
 
pipe_mutex bo_fence_lock;
 
int num_cs; /* The number of command streams created. */
+   unsigned num_total_rejected_cs;
uint32_t next_bo_unique_id;
uint64_t allocated_vram;
uint64_t allocated_gtt;
uint64_t mapped_vram;
uint64_t mapped_gtt;
uint64_t buffer_wait_time; /* time spent in buffer_wait in ns */
uint64_t num_gfx_IBs;
uint64_t num_sdma_IBs;
 
struct radeon_info info;
-- 
2.7.4

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

[Mesa-dev] [PATCH 5/7] radeonsi: don't declare LDS in TES

[Marek Olšák]

From: Marek Olšák 

not used since we started using the offchip tess ring
---
 src/gallium/drivers/radeonsi/si_shader.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_shader.c 
b/src/gallium/drivers/radeonsi/si_shader.c
index 10f40a9..5ca974e 100644
--- a/src/gallium/drivers/radeonsi/si_shader.c
+++ b/src/gallium/drivers/radeonsi/si_shader.c
@@ -5856,22 +5856,21 @@ static void create_function(struct si_shader_context 
*ctx)
 bld_base->info->opcode_count[TGSI_OPCODE_DDY_FINE] > 0 ||
 bld_base->info->opcode_count[TGSI_OPCODE_INTERP_OFFSET] > 0 ||
 bld_base->info->opcode_count[TGSI_OPCODE_INTERP_SAMPLE] > 0))
ctx->lds =
LLVMAddGlobalInAddressSpace(gallivm->module,
LLVMArrayType(ctx->i32, 64),
"ddxy_lds",
LOCAL_ADDR_SPACE);
 
if ((ctx->type == PIPE_SHADER_VERTEX && shader->key.as_ls) ||
-   ctx->type == PIPE_SHADER_TESS_CTRL ||
-   ctx->type == PIPE_SHADER_TESS_EVAL)
+   ctx->type == PIPE_SHADER_TESS_CTRL)
declare_tess_lds(ctx);
 }
 
 /**
  * Load ESGS and GSVS ring buffer resource descriptors and save the variables
  * for later use.
  */
 static void preload_ring_buffers(struct si_shader_context *ctx)
 {
struct gallivm_state *gallivm = ctx->bld_base.base.gallivm;
-- 
2.7.4

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

[Mesa-dev] [PATCH 6/7] radeonsi: always set the TCL1_ACTION_ENA when invalidating L2

[Marek Olšák]

From: Marek Olšák 

Some CIK-VI docs say this is the default behavior on SI. That doesn't
answer whether it's also the default behavior on CIK-VI.

Cc: 17.0 13.0 
---
 src/gallium/drivers/radeonsi/si_state_draw.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/radeonsi/si_state_draw.c 
b/src/gallium/drivers/radeonsi/si_state_draw.c
index 837c025..d296874 100644
--- a/src/gallium/drivers/radeonsi/si_state_draw.c
+++ b/src/gallium/drivers/radeonsi/si_state_draw.c
@@ -843,25 +843,26 @@ void si_emit_cache_flush(struct si_context *sctx)
 * in PFP.
 *
 * cp_coher_cntl should contain all necessary flags except TC flags
 * at this point.
 *
 * SI-CIK don't support L2 write-back.
 */
if (rctx->flags & SI_CONTEXT_INV_GLOBAL_L2 ||
(rctx->chip_class <= CIK &&
 (rctx->flags & SI_CONTEXT_WRITEBACK_GLOBAL_L2))) {
-   /* Invalidate L1 & L2. (L1 is always invalidated)
+   /* Invalidate L1 & L2. (L1 is always invalidated on SI)
 * WB must be set on VI+ when TC_ACTION is set.
 */
si_emit_surface_sync(rctx, cp_coher_cntl |
 S_0085F0_TC_ACTION_ENA(1) |
+S_0085F0_TCL1_ACTION_ENA(1) |
 S_0301F0_TC_WB_ACTION_ENA(rctx->chip_class 
>= VI));
cp_coher_cntl = 0;
sctx->b.num_L2_invalidates++;
} else {
/* L1 invalidation and L2 writeback must be done separately,
 * because both operations can't be done together.
 */
if (rctx->flags & SI_CONTEXT_WRITEBACK_GLOBAL_L2) {
/* WB = write-back
 * NC = apply to non-coherent MTYPEs
-- 
2.7.4

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

[Mesa-dev] [PATCH 7/7] radeonsi: handle first_non_void correctly in si_create_vertex_elements

[Marek Olšák]

From: Marek Olšák 

Cc: 17.0 
---
 src/gallium/drivers/radeonsi/si_state.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_state.c 
b/src/gallium/drivers/radeonsi/si_state.c
index 876cbf6..01edff9 100644
--- a/src/gallium/drivers/radeonsi/si_state.c
+++ b/src/gallium/drivers/radeonsi/si_state.c
@@ -3361,21 +3361,21 @@ static void *si_create_vertex_elements(struct 
pipe_context *ctx,
 
if (!used[vbo_index]) {
v->first_vb_use_mask |= 1 << i;
used[vbo_index] = true;
}
 
desc = util_format_description(elements[i].src_format);
first_non_void = 
util_format_get_first_non_void_channel(elements[i].src_format);
data_format = si_translate_buffer_dataformat(ctx->screen, desc, 
first_non_void);
num_format = si_translate_buffer_numformat(ctx->screen, desc, 
first_non_void);
-   channel = >channel[first_non_void];
+   channel = first_non_void >= 0 ? >channel[first_non_void] 
: NULL;
 
v->rsrc_word3[i] = 
S_008F0C_DST_SEL_X(si_map_swizzle(desc->swizzle[0])) |
   
S_008F0C_DST_SEL_Y(si_map_swizzle(desc->swizzle[1])) |
   
S_008F0C_DST_SEL_Z(si_map_swizzle(desc->swizzle[2])) |
   
S_008F0C_DST_SEL_W(si_map_swizzle(desc->swizzle[3])) |
   S_008F0C_NUM_FORMAT(num_format) |
   S_008F0C_DATA_FORMAT(data_format);
v->format_size[i] = desc->block.bits / 8;
 
/* The hardware always treats the 2-bit alpha channel as
@@ -3383,26 +3383,26 @@ static void *si_create_vertex_elements(struct 
pipe_context *ctx,
 */
if (data_format == V_008F0C_BUF_DATA_FORMAT_2_10_10_10) {
if (num_format == V_008F0C_BUF_NUM_FORMAT_SNORM) {
v->fix_fetch |= (uint64_t)SI_FIX_FETCH_A2_SNORM 
<< (4 * i);
} else if (num_format == 
V_008F0C_BUF_NUM_FORMAT_SSCALED) {
v->fix_fetch |= 
(uint64_t)SI_FIX_FETCH_A2_SSCALED << (4 * i);
} else if (num_format == V_008F0C_BUF_NUM_FORMAT_SINT) {
/* This isn't actually used in OpenGL. */
v->fix_fetch |= (uint64_t)SI_FIX_FETCH_A2_SINT 
<< (4 * i);
}
-   } else if (channel->type == UTIL_FORMAT_TYPE_FIXED) {
+   } else if (channel && channel->type == UTIL_FORMAT_TYPE_FIXED) {
if (desc->swizzle[3] == PIPE_SWIZZLE_1)
v->fix_fetch |= 
(uint64_t)SI_FIX_FETCH_RGBX_32_FIXED << (4 * i);
else
v->fix_fetch |= 
(uint64_t)SI_FIX_FETCH_RGBA_32_FIXED << (4 * i);
-   } else if (channel->size == 32 && !channel->pure_integer) {
+   } else if (channel && channel->size == 32 && 
!channel->pure_integer) {
if (channel->type == UTIL_FORMAT_TYPE_SIGNED) {
if (channel->normalized) {
if (desc->swizzle[3] == PIPE_SWIZZLE_1)
v->fix_fetch |= 
(uint64_t)SI_FIX_FETCH_RGBX_32_SNORM << (4 * i);
else
v->fix_fetch |= 
(uint64_t)SI_FIX_FETCH_RGBA_32_SNORM << (4 * i);
} else {
v->fix_fetch |= 
(uint64_t)SI_FIX_FETCH_RGBA_32_SSCALED << (4 * i);
}
} else if (channel->type == UTIL_FORMAT_TYPE_UNSIGNED) {
-- 
2.7.4

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

[Mesa-dev] [PATCH 4/7] radeonsi: preload PS inputs only if KILL is used

[Marek Olšák]

From: Marek Olšák 

so that most shaders can get lower VGPR usage thanks to lazy input loading.
I think this is a more accurate constraint that prevents the black transitions
in Witcher 2.

Affected shaders (7758):
Max Waves: 57437 -> 58231 (1.38 %)
---
 src/gallium/drivers/radeonsi/si_shader_tgsi_setup.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_shader_tgsi_setup.c 
b/src/gallium/drivers/radeonsi/si_shader_tgsi_setup.c
index 8d19a4e..4f355e5 100644
--- a/src/gallium/drivers/radeonsi/si_shader_tgsi_setup.c
+++ b/src/gallium/drivers/radeonsi/si_shader_tgsi_setup.c
@@ -630,25 +630,29 @@ store_value_to_array(struct lp_build_tgsi_context 
*bld_base,
}
value = LLVMBuildExtractElement(builder, array,
lp_build_const_int32(gallivm, i), "");
LLVMBuildStore(builder, value, temp_ptr);
}
}
 }
 
 /* If this is true, preload FS inputs at the beginning of shaders. Otherwise,
  * reload them at each use. This must be true if the shader is using
- * derivatives, because all inputs should be loaded in the WQM mode.
+ * derivatives and KILL, because KILL can leave the WQM and then a lazy
+ * input load isn't in the WQM anymore.
  */
 static bool si_preload_fs_inputs(struct si_shader_context *ctx)
 {
-   return ctx->shader->selector->info.uses_derivatives;
+   struct si_shader_selector *sel = ctx->shader->selector;
+
+   return sel->info.uses_derivatives &&
+  sel->info.uses_kill;
 }
 
 static LLVMValueRef
 get_output_ptr(struct lp_build_tgsi_context *bld_base, unsigned index,
   unsigned chan)
 {
struct si_shader_context *ctx = si_shader_context(bld_base);
 
assert(index <= ctx->bld_base.info->file_max[TGSI_FILE_OUTPUT]);
return ctx->outputs[index][chan];
-- 
2.7.4

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

[Mesa-dev] [PATCH] st/mesa: destroy pipe_context before destroying st_context

[Marek Olšák]

From: Marek Olšák 

If radeonsi starts compiling an optimized shader variant for asynchronously
with a GL debug callback set and the application destroys the GL context,
radeonsi crashes when trying to write shader stats into the debug output
of a non-existent context after compilation, because st/mesa was destroyed
before pipe_context.

Firefox with WebGL2 enabled hits this bug.

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

Cc: 17.0 
---
 src/mesa/state_tracker/st_context.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/src/mesa/state_tracker/st_context.c 
b/src/mesa/state_tracker/st_context.c
index 0eae971..7a99e82 100644
--- a/src/mesa/state_tracker/st_context.c
+++ b/src/mesa/state_tracker/st_context.c
@@ -307,20 +307,24 @@ st_destroy_context_priv(struct st_context *st)
}
 
/* free glDrawPixels cache data */
free(st->drawpix_cache.image);
pipe_resource_reference(>drawpix_cache.texture, NULL);
 
/* free glReadPixels cache data */
st_invalidate_readpix_cache(st);
 
cso_destroy_context(st->cso_context);
+
+   if (st->pipe)
+  st->pipe->destroy(st->pipe);
+
free( st );
 }
 
 
 static struct st_context *
 st_create_context_priv( struct gl_context *ctx, struct pipe_context *pipe,
const struct st_config_options *options)
 {
struct pipe_screen *screen = pipe->screen;
uint i;
@@ -572,21 +576,20 @@ static void
 destroy_tex_sampler_cb(GLuint id, void *data, void *userData)
 {
struct gl_texture_object *texObj = (struct gl_texture_object *) data;
struct st_context *st = (struct st_context *) userData;
 
st_texture_release_sampler_view(st, st_texture_object(texObj));
 }
  
 void st_destroy_context( struct st_context *st )
 {
-   struct pipe_context *pipe = st->pipe;
struct gl_context *ctx = st->ctx;
GLuint i;
 
_mesa_HashWalk(ctx->Shared->TexObjects, destroy_tex_sampler_cb, st);
 
st_reference_fragprog(st, >fp, NULL);
st_reference_geomprog(st, >gp, NULL);
st_reference_vertprog(st, >vp, NULL);
st_reference_tesscprog(st, >tcp, NULL);
st_reference_tesseprog(st, >tep, NULL);
@@ -604,22 +607,20 @@ void st_destroy_context( struct st_context *st )
 
st_destroy_program_variants(st);
 
_mesa_free_context_data(ctx);
 
/* This will free the st_context too, so 'st' must not be accessed
 * afterwards. */
st_destroy_context_priv(st);
st = NULL;
 
-   pipe->destroy( pipe );
-
free(ctx);
 }
 
 static void
 st_emit_string_marker(struct gl_context *ctx, const GLchar *string, GLsizei 
len)
 {
struct st_context *st = ctx->st;
st->pipe->emit_string_marker(st->pipe, string, len);
 }
 
-- 
2.7.4

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

Re: [Mesa-dev] [PATCH] mesa: Enable EXT_compressed_ETC1_RGB8_sub_texture

[Jason Ekstrand]

On Fri, Jan 20, 2017 at 10:26 AM, Ilia Mirkin  wrote:

> On Fri, Jan 20, 2017 at 1:25 PM, Jason Ekstrand 
> wrote:
> > On Fri, Jan 20, 2017 at 10:16 AM, Ilia Mirkin 
> wrote:
> >>
> >> What level of support would a driver need to provide? Can this just be
> >> enabled for all drivers? [This seems like largely a driver-side
> >> feature rather than hardware-based.]
> >
> >
> > My understanding is that we should just expose this extension on all
> > hardware that supports ETC1.  Obviously, if it doesn't support ETC1, you
> > don't get this extension. :-)
>
> Isn't ETC1 required for ES1 and ES2? If not, ignore me.


I just looked at the specs.  It's required starting with ES 3.0.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] mesa: Enable EXT_compressed_ETC1_RGB8_sub_texture

[Ilia Mirkin]

On Fri, Jan 20, 2017 at 1:25 PM, Jason Ekstrand  wrote:
> On Fri, Jan 20, 2017 at 10:16 AM, Ilia Mirkin  wrote:
>>
>> What level of support would a driver need to provide? Can this just be
>> enabled for all drivers? [This seems like largely a driver-side
>> feature rather than hardware-based.]
>
>
> My understanding is that we should just expose this extension on all
> hardware that supports ETC1.  Obviously, if it doesn't support ETC1, you
> don't get this extension. :-)

Isn't ETC1 required for ES1 and ES2? If not, ignore me.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] mesa: Enable EXT_compressed_ETC1_RGB8_sub_texture

[Jason Ekstrand]

On Fri, Jan 20, 2017 at 10:16 AM, Ilia Mirkin  wrote:

> What level of support would a driver need to provide? Can this just be
> enabled for all drivers? [This seems like largely a driver-side
> feature rather than hardware-based.]
>

My understanding is that we should just expose this extension on all
hardware that supports ETC1.  Obviously, if it doesn't support ETC1, you
don't get this extension. :-)


> On Fri, Jan 20, 2017 at 1:12 PM, Plamena Manolova
>  wrote:
> > Since we already have the functionality in place and games
> > like Game of Thrones seem to depend on this extension, I
> > think it makes sense to enable it by making it part of
> > the extension string even though its still a draft:
> >
> > https://www.khronos.org/registry/gles/extensions/EXT/
> EXT_compressed_ETC1_RGB8_sub_texture.txt
> >
> > Note: OES_compressed_ETC1_RGB8_sub_texture seems to be listed
> > in gl2ext.h, but there's no documentation for it in the KHR
> > registry
> >
> > Signed-off-by: Plamena Manolova 
> > ---
> >  src/mesa/drivers/dri/i965/intel_extensions.c | 1 +
> >  src/mesa/main/extensions_table.h | 1 +
> >  src/mesa/main/mtypes.h   | 1 +
> >  src/mesa/main/teximage.c | 5 +
> >  4 files changed, 8 insertions(+)
> >
> > diff --git a/src/mesa/drivers/dri/i965/intel_extensions.c
> b/src/mesa/drivers/dri/i965/intel_extensions.c
> > index b674b2f..bdf2fa5 100644
> > --- a/src/mesa/drivers/dri/i965/intel_extensions.c
> > +++ b/src/mesa/drivers/dri/i965/intel_extensions.c
> > @@ -93,6 +93,7 @@ intelInitExtensions(struct gl_context *ctx)
> > ctx->Extensions.EXT_blend_equation_separate = true;
> > ctx->Extensions.EXT_blend_func_separate = true;
> > ctx->Extensions.EXT_blend_minmax = true;
> > +   ctx->Extensions.EXT_compressed_ETC1_RGB8_sub_texture = true;
> > ctx->Extensions.EXT_draw_buffers2 = true;
> > ctx->Extensions.EXT_framebuffer_sRGB = true;
> > ctx->Extensions.EXT_gpu_program_parameters = true;
> > diff --git a/src/mesa/main/extensions_table.h
> b/src/mesa/main/extensions_table.h
> > index 2de3c59..8b52a97 100644
> > --- a/src/mesa/main/extensions_table.h
> > +++ b/src/mesa/main/extensions_table.h
> > @@ -198,6 +198,7 @@ EXT(EXT_buffer_storage  ,
> ARB_buffer_storage
> >  EXT(EXT_clip_cull_distance  , ARB_cull_distance
>   ,  x ,  x ,  x ,  30, 2016)
> >  EXT(EXT_color_buffer_float  , dummy_true
>  ,  x ,  x ,  x ,  30, 2013)
> >  EXT(EXT_compiled_vertex_array   , dummy_true
>  , GLL,  x ,  x ,  x , 1996)
> > +EXT(EXT_compressed_ETC1_RGB8_sub_texture,
> EXT_compressed_ETC1_RGB8_sub_texture   ,  x ,  x , ES1, ES2, 2014)
> >  EXT(EXT_copy_image  , OES_copy_image
>  ,  x ,  x ,  x ,  30, 2014)
> >  EXT(EXT_copy_texture, dummy_true
>  , GLL,  x ,  x ,  x , 1995)
> >  EXT(EXT_depth_bounds_test   , EXT_depth_bounds_test
>   , GLL, GLC,  x ,  x , 2002)
> > diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
> > index f04ec51..719e248 100644
> > --- a/src/mesa/main/mtypes.h
> > +++ b/src/mesa/main/mtypes.h
> > @@ -3948,6 +3948,7 @@ struct gl_extensions
> > GLboolean EXT_timer_query;
> > GLboolean EXT_vertex_array_bgra;
> > GLboolean EXT_window_rectangles;
> > +   GLboolean EXT_compressed_ETC1_RGB8_sub_texture;
> > GLboolean OES_copy_image;
> > GLboolean OES_primitive_bounding_box;
> > GLboolean OES_sample_variables;
> > diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
> > index bc3b76a..14fe4db 100644
> > --- a/src/mesa/main/teximage.c
> > +++ b/src/mesa/main/teximage.c
> > @@ -1323,6 +1323,11 @@ compressedteximage_only_format(const struct
> gl_context *ctx, GLenum format)
> >  {
> > switch (format) {
> > case GL_ETC1_RGB8_OES:
> > +  if (ctx->Extensions.EXT_compressed_ETC1_RGB8_sub_texture)
> > + return false;
> > +  else
> > + return true;
> > +  break;
> > case GL_PALETTE4_RGB8_OES:
> > case GL_PALETTE4_RGBA8_OES:
> > case GL_PALETTE4_R5_G6_B5_OES:
> > --
> > 2.4.3
> >
> > ___
> > 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 mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] mesa: Enable EXT_compressed_ETC1_RGB8_sub_texture

[Ilia Mirkin]

What level of support would a driver need to provide? Can this just be
enabled for all drivers? [This seems like largely a driver-side
feature rather than hardware-based.]

On Fri, Jan 20, 2017 at 1:12 PM, Plamena Manolova
 wrote:
> Since we already have the functionality in place and games
> like Game of Thrones seem to depend on this extension, I
> think it makes sense to enable it by making it part of
> the extension string even though its still a draft:
>
> https://www.khronos.org/registry/gles/extensions/EXT/EXT_compressed_ETC1_RGB8_sub_texture.txt
>
> Note: OES_compressed_ETC1_RGB8_sub_texture seems to be listed
> in gl2ext.h, but there's no documentation for it in the KHR
> registry
>
> Signed-off-by: Plamena Manolova 
> ---
>  src/mesa/drivers/dri/i965/intel_extensions.c | 1 +
>  src/mesa/main/extensions_table.h | 1 +
>  src/mesa/main/mtypes.h   | 1 +
>  src/mesa/main/teximage.c | 5 +
>  4 files changed, 8 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/i965/intel_extensions.c 
> b/src/mesa/drivers/dri/i965/intel_extensions.c
> index b674b2f..bdf2fa5 100644
> --- a/src/mesa/drivers/dri/i965/intel_extensions.c
> +++ b/src/mesa/drivers/dri/i965/intel_extensions.c
> @@ -93,6 +93,7 @@ intelInitExtensions(struct gl_context *ctx)
> ctx->Extensions.EXT_blend_equation_separate = true;
> ctx->Extensions.EXT_blend_func_separate = true;
> ctx->Extensions.EXT_blend_minmax = true;
> +   ctx->Extensions.EXT_compressed_ETC1_RGB8_sub_texture = true;
> ctx->Extensions.EXT_draw_buffers2 = true;
> ctx->Extensions.EXT_framebuffer_sRGB = true;
> ctx->Extensions.EXT_gpu_program_parameters = true;
> diff --git a/src/mesa/main/extensions_table.h 
> b/src/mesa/main/extensions_table.h
> index 2de3c59..8b52a97 100644
> --- a/src/mesa/main/extensions_table.h
> +++ b/src/mesa/main/extensions_table.h
> @@ -198,6 +198,7 @@ EXT(EXT_buffer_storage  , 
> ARB_buffer_storage
>  EXT(EXT_clip_cull_distance  , ARB_cull_distance  
> ,  x ,  x ,  x ,  30, 2016)
>  EXT(EXT_color_buffer_float  , dummy_true 
> ,  x ,  x ,  x ,  30, 2013)
>  EXT(EXT_compiled_vertex_array   , dummy_true 
> , GLL,  x ,  x ,  x , 1996)
> +EXT(EXT_compressed_ETC1_RGB8_sub_texture, 
> EXT_compressed_ETC1_RGB8_sub_texture   ,  x ,  x , ES1, ES2, 2014)
>  EXT(EXT_copy_image  , OES_copy_image 
> ,  x ,  x ,  x ,  30, 2014)
>  EXT(EXT_copy_texture, dummy_true 
> , GLL,  x ,  x ,  x , 1995)
>  EXT(EXT_depth_bounds_test   , EXT_depth_bounds_test  
> , GLL, GLC,  x ,  x , 2002)
> diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
> index f04ec51..719e248 100644
> --- a/src/mesa/main/mtypes.h
> +++ b/src/mesa/main/mtypes.h
> @@ -3948,6 +3948,7 @@ struct gl_extensions
> GLboolean EXT_timer_query;
> GLboolean EXT_vertex_array_bgra;
> GLboolean EXT_window_rectangles;
> +   GLboolean EXT_compressed_ETC1_RGB8_sub_texture;
> GLboolean OES_copy_image;
> GLboolean OES_primitive_bounding_box;
> GLboolean OES_sample_variables;
> diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
> index bc3b76a..14fe4db 100644
> --- a/src/mesa/main/teximage.c
> +++ b/src/mesa/main/teximage.c
> @@ -1323,6 +1323,11 @@ compressedteximage_only_format(const struct gl_context 
> *ctx, GLenum format)
>  {
> switch (format) {
> case GL_ETC1_RGB8_OES:
> +  if (ctx->Extensions.EXT_compressed_ETC1_RGB8_sub_texture)
> + return false;
> +  else
> + return true;
> +  break;
> case GL_PALETTE4_RGB8_OES:
> case GL_PALETTE4_RGBA8_OES:
> case GL_PALETTE4_R5_G6_B5_OES:
> --
> 2.4.3
>
> ___
> 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] [PATCH] mesa: Enable EXT_compressed_ETC1_RGB8_sub_texture

[Plamena Manolova]

Since we already have the functionality in place and games
like Game of Thrones seem to depend on this extension, I
think it makes sense to enable it by making it part of
the extension string even though its still a draft:

https://www.khronos.org/registry/gles/extensions/EXT/EXT_compressed_ETC1_RGB8_sub_texture.txt

Note: OES_compressed_ETC1_RGB8_sub_texture seems to be listed
in gl2ext.h, but there's no documentation for it in the KHR
registry

Signed-off-by: Plamena Manolova 
---
 src/mesa/drivers/dri/i965/intel_extensions.c | 1 +
 src/mesa/main/extensions_table.h | 1 +
 src/mesa/main/mtypes.h   | 1 +
 src/mesa/main/teximage.c | 5 +
 4 files changed, 8 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/intel_extensions.c 
b/src/mesa/drivers/dri/i965/intel_extensions.c
index b674b2f..bdf2fa5 100644
--- a/src/mesa/drivers/dri/i965/intel_extensions.c
+++ b/src/mesa/drivers/dri/i965/intel_extensions.c
@@ -93,6 +93,7 @@ intelInitExtensions(struct gl_context *ctx)
ctx->Extensions.EXT_blend_equation_separate = true;
ctx->Extensions.EXT_blend_func_separate = true;
ctx->Extensions.EXT_blend_minmax = true;
+   ctx->Extensions.EXT_compressed_ETC1_RGB8_sub_texture = true;
ctx->Extensions.EXT_draw_buffers2 = true;
ctx->Extensions.EXT_framebuffer_sRGB = true;
ctx->Extensions.EXT_gpu_program_parameters = true;
diff --git a/src/mesa/main/extensions_table.h b/src/mesa/main/extensions_table.h
index 2de3c59..8b52a97 100644
--- a/src/mesa/main/extensions_table.h
+++ b/src/mesa/main/extensions_table.h
@@ -198,6 +198,7 @@ EXT(EXT_buffer_storage  , 
ARB_buffer_storage
 EXT(EXT_clip_cull_distance  , ARB_cull_distance
  ,  x ,  x ,  x ,  30, 2016)
 EXT(EXT_color_buffer_float  , dummy_true   
  ,  x ,  x ,  x ,  30, 2013)
 EXT(EXT_compiled_vertex_array   , dummy_true   
  , GLL,  x ,  x ,  x , 1996)
+EXT(EXT_compressed_ETC1_RGB8_sub_texture, 
EXT_compressed_ETC1_RGB8_sub_texture   ,  x ,  x , ES1, ES2, 2014)
 EXT(EXT_copy_image  , OES_copy_image   
  ,  x ,  x ,  x ,  30, 2014)
 EXT(EXT_copy_texture, dummy_true   
  , GLL,  x ,  x ,  x , 1995)
 EXT(EXT_depth_bounds_test   , EXT_depth_bounds_test
  , GLL, GLC,  x ,  x , 2002)
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index f04ec51..719e248 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -3948,6 +3948,7 @@ struct gl_extensions
GLboolean EXT_timer_query;
GLboolean EXT_vertex_array_bgra;
GLboolean EXT_window_rectangles;
+   GLboolean EXT_compressed_ETC1_RGB8_sub_texture;
GLboolean OES_copy_image;
GLboolean OES_primitive_bounding_box;
GLboolean OES_sample_variables;
diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index bc3b76a..14fe4db 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -1323,6 +1323,11 @@ compressedteximage_only_format(const struct gl_context 
*ctx, GLenum format)
 {
switch (format) {
case GL_ETC1_RGB8_OES:
+  if (ctx->Extensions.EXT_compressed_ETC1_RGB8_sub_texture)
+ return false;
+  else
+ return true;
+  break;
case GL_PALETTE4_RGB8_OES:
case GL_PALETTE4_RGBA8_OES:
case GL_PALETTE4_R5_G6_B5_OES:
-- 
2.4.3

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

[Mesa-dev] [PATCH v4 4/6] i965: Add support for xfb overflow on query buffer objects.

[Rafael Antognolli]

Enable getting the results of a transform feedback overflow query with a
buffer object.

v4:
- hsw_overflow_result_to_gpr0 a public function, so it can be used
  by conditional render. (Kenneth)
- fix typo grp0/gpr0 (Kenneth)
- rename load_gen_written_data_to_regs to
  load_overflow_data_to_cs_gprs (Kenneth)

Signed-off-by: Rafael Antognolli 
---
 src/mesa/drivers/dri/i965/brw_context.h  |   3 +
 src/mesa/drivers/dri/i965/hsw_queryobj.c | 112 +++
 2 files changed, 115 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/brw_context.h 
b/src/mesa/drivers/dri/i965/brw_context.h
index aa1499a..917af10 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -1274,6 +1274,9 @@ void brw_write_timestamp(struct brw_context *brw, 
drm_intel_bo *bo, int idx);
 void brw_write_depth_count(struct brw_context *brw, drm_intel_bo *bo, int idx);
 
 /** hsw_queryobj.c */
+void hsw_overflow_result_to_gpr0(struct brw_context *brw,
+ struct brw_query_object *query,
+ int count);
 void hsw_init_queryobj_functions(struct dd_function_table *functions);
 
 /** brw_conditional_render.c */
diff --git a/src/mesa/drivers/dri/i965/hsw_queryobj.c 
b/src/mesa/drivers/dri/i965/hsw_queryobj.c
index 0da2c3d..938fe06 100644
--- a/src/mesa/drivers/dri/i965/hsw_queryobj.c
+++ b/src/mesa/drivers/dri/i965/hsw_queryobj.c
@@ -187,6 +187,107 @@ gpr0_to_bool(struct brw_context *brw)
 }
 
 static void
+load_overflow_data_to_cs_gprs(struct brw_context *brw,
+  struct brw_query_object *query,
+  int idx)
+{
+   int offset = idx * sizeof(uint64_t) * 4;
+
+   brw_load_register_mem64(brw,
+   HSW_CS_GPR(1),
+   query->bo,
+   I915_GEM_DOMAIN_INSTRUCTION,
+   I915_GEM_DOMAIN_INSTRUCTION,
+   offset);
+
+   offset += sizeof(uint64_t);
+   brw_load_register_mem64(brw,
+   HSW_CS_GPR(2),
+   query->bo,
+   I915_GEM_DOMAIN_INSTRUCTION,
+   I915_GEM_DOMAIN_INSTRUCTION,
+   offset);
+
+   offset += sizeof(uint64_t);
+   brw_load_register_mem64(brw,
+   HSW_CS_GPR(3),
+   query->bo,
+   I915_GEM_DOMAIN_INSTRUCTION,
+   I915_GEM_DOMAIN_INSTRUCTION,
+   offset);
+
+   offset += sizeof(uint64_t);
+   brw_load_register_mem64(brw,
+   HSW_CS_GPR(4),
+   query->bo,
+   I915_GEM_DOMAIN_INSTRUCTION,
+   I915_GEM_DOMAIN_INSTRUCTION,
+   offset);
+}
+
+/*
+ * R3 = R4 - R3;
+ * R1 = R2 - R1;
+ * R1 = R3 - R1;
+ * R0 = R0 | R1;
+ */
+static void
+calc_overflow_for_stream(struct brw_context *brw)
+{
+   static const uint32_t maths[] = {
+  MI_MATH_ALU2(LOAD, SRCA, R4),
+  MI_MATH_ALU2(LOAD, SRCB, R3),
+  MI_MATH_ALU0(SUB),
+  MI_MATH_ALU2(STORE, R3, ACCU),
+  MI_MATH_ALU2(LOAD, SRCA, R2),
+  MI_MATH_ALU2(LOAD, SRCB, R1),
+  MI_MATH_ALU0(SUB),
+  MI_MATH_ALU2(STORE, R1, ACCU),
+  MI_MATH_ALU2(LOAD, SRCA, R3),
+  MI_MATH_ALU2(LOAD, SRCB, R1),
+  MI_MATH_ALU0(SUB),
+  MI_MATH_ALU2(STORE, R1, ACCU),
+  MI_MATH_ALU2(LOAD, SRCA, R1),
+  MI_MATH_ALU2(LOAD, SRCB, R0),
+  MI_MATH_ALU0(OR),
+  MI_MATH_ALU2(STORE, R0, ACCU),
+   };
+
+   BEGIN_BATCH(1 + ARRAY_SIZE(maths));
+   OUT_BATCH(HSW_MI_MATH | (1 + ARRAY_SIZE(maths) - 2));
+
+   for (int m = 0; m < ARRAY_SIZE(maths); m++)
+  OUT_BATCH(maths[m]);
+
+   ADVANCE_BATCH();
+}
+
+static void
+calc_overflow_to_gpr0(struct brw_context *brw, struct brw_query_object *query,
+   int count)
+{
+   brw_load_register_imm64(brw, HSW_CS_GPR(0), 0ull);
+
+   for (int i = 0; i < count; i++) {
+  load_overflow_data_to_cs_gprs(brw, query, i);
+  calc_overflow_for_stream(brw);
+   }
+}
+
+/*
+ * Take a query and calculate whether there was overflow during transform
+ * feedback. Store the result in the gpr0 register.
+ */
+void
+hsw_overflow_result_to_gpr0(struct brw_context *brw,
+struct brw_query_object *query,
+int count)
+{
+   calc_overflow_to_gpr0(brw, query, count);
+   gpr0_to_bool(brw);
+}
+
+static void
 hsw_result_to_gpr0(struct gl_context *ctx, struct brw_query_object *query,
struct gl_buffer_object *buf, intptr_t offset,
GLenum pname, GLenum ptype)
@@ -223,6 +324,11 @@ hsw_result_to_gpr0(struct gl_context *ctx, struct 
brw_query_object *query,
   I915_GEM_DOMAIN_INSTRUCTION,
   

Re: [Mesa-dev] [PATCH v4 6/6] i965/gen6+: Enable arb_transform_feedback_overflow_query.

[Rafael Antognolli]

On Fri, Jan 20, 2017 at 09:53:27AM -0800, Rafael Antognolli wrote:
> This extension adds new query types which can be used to detect overflow
> of transform feedback buffers. The new query types are also accepted by
> conditional rendering commands.
> 
> v3:
> - s/gen7+/gen6+/ in the relnotes (Jordan Justen)
> 
> Signed-off-by: Rafael Antognolli 
> ---
>  docs/features.txt| 2 +-
>  docs/relnotes/17.0.0.html| 1 +
>  src/mesa/drivers/dri/i965/intel_extensions.c | 1 +
>  3 files changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/docs/features.txt b/docs/features.txt
> index aff0016..ef3534b 100644
> --- a/docs/features.txt
> +++ b/docs/features.txt
> @@ -303,7 +303,7 @@ Khronos, ARB, and OES extensions that are not part of any 
> OpenGL or OpenGL ES ve
>GL_ARB_sparse_texture2not started
>GL_ARB_sparse_texture_clamp   not started
>GL_ARB_texture_filter_minmax  not started
> -  GL_ARB_transform_feedback_overflow_query  not started
> +  GL_ARB_transform_feedback_overflow_query  DONE (i965/gen6+)
>GL_KHR_blend_equation_advanced_coherent   DONE (i965/gen9+)
>GL_KHR_no_error   not started
>GL_KHR_texture_compression_astc_hdr   DONE (core only)
> diff --git a/docs/relnotes/17.0.0.html b/docs/relnotes/17.0.0.html
> index 71fb4c3..ae77b88 100644
> --- a/docs/relnotes/17.0.0.html
> +++ b/docs/relnotes/17.0.0.html
> @@ -45,6 +45,7 @@ Note: some of the new features are only available with 
> certain drivers.
>  
>  
>  GL_ARB_post_depth_coverage on i965/gen9+
> +GL_ARB_transform_feedback_overflow_query on i965/gen6+

Ugh, I guess this is not the right file anymore. Please ignore it, I'll
fix on a next patch once I get more reviews.

Rafael

>  GL_KHR_blend_equation_advanced on nvc0
>  GL_INTEL_conservative_rasterization on i965/gen9+
>  GL_NV_image_formats on any driver supporting 
> GL_ARB_shader_image_load_store (i965, nvc0, radeonsi, softpipe)
> diff --git a/src/mesa/drivers/dri/i965/intel_extensions.c 
> b/src/mesa/drivers/dri/i965/intel_extensions.c
> index b674b2f..e516fd6 100644
> --- a/src/mesa/drivers/dri/i965/intel_extensions.c
> +++ b/src/mesa/drivers/dri/i965/intel_extensions.c
> @@ -181,6 +181,7 @@ intelInitExtensions(struct gl_context *ctx)
>ctx->Extensions.EXT_framebuffer_multisample = true;
>ctx->Extensions.EXT_framebuffer_multisample_blit_scaled = true;
>ctx->Extensions.EXT_transform_feedback = true;
> +  ctx->Extensions.ARB_transform_feedback_overflow_query = true;
>ctx->Extensions.OES_depth_texture_cube_map = true;
>ctx->Extensions.OES_sample_variables = true;
>  
> -- 
> 2.7.4
> 
> ___
> 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] [PATCH v4 6/6] i965/gen6+: Enable arb_transform_feedback_overflow_query.

[Rafael Antognolli]

This extension adds new query types which can be used to detect overflow
of transform feedback buffers. The new query types are also accepted by
conditional rendering commands.

v3:
- s/gen7+/gen6+/ in the relnotes (Jordan Justen)

Signed-off-by: Rafael Antognolli 
---
 docs/features.txt| 2 +-
 docs/relnotes/17.0.0.html| 1 +
 src/mesa/drivers/dri/i965/intel_extensions.c | 1 +
 3 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/docs/features.txt b/docs/features.txt
index aff0016..ef3534b 100644
--- a/docs/features.txt
+++ b/docs/features.txt
@@ -303,7 +303,7 @@ Khronos, ARB, and OES extensions that are not part of any 
OpenGL or OpenGL ES ve
   GL_ARB_sparse_texture2not started
   GL_ARB_sparse_texture_clamp   not started
   GL_ARB_texture_filter_minmax  not started
-  GL_ARB_transform_feedback_overflow_query  not started
+  GL_ARB_transform_feedback_overflow_query  DONE (i965/gen6+)
   GL_KHR_blend_equation_advanced_coherent   DONE (i965/gen9+)
   GL_KHR_no_error   not started
   GL_KHR_texture_compression_astc_hdr   DONE (core only)
diff --git a/docs/relnotes/17.0.0.html b/docs/relnotes/17.0.0.html
index 71fb4c3..ae77b88 100644
--- a/docs/relnotes/17.0.0.html
+++ b/docs/relnotes/17.0.0.html
@@ -45,6 +45,7 @@ Note: some of the new features are only available with 
certain drivers.
 
 
 GL_ARB_post_depth_coverage on i965/gen9+
+GL_ARB_transform_feedback_overflow_query on i965/gen6+
 GL_KHR_blend_equation_advanced on nvc0
 GL_INTEL_conservative_rasterization on i965/gen9+
 GL_NV_image_formats on any driver supporting 
GL_ARB_shader_image_load_store (i965, nvc0, radeonsi, softpipe)
diff --git a/src/mesa/drivers/dri/i965/intel_extensions.c 
b/src/mesa/drivers/dri/i965/intel_extensions.c
index b674b2f..e516fd6 100644
--- a/src/mesa/drivers/dri/i965/intel_extensions.c
+++ b/src/mesa/drivers/dri/i965/intel_extensions.c
@@ -181,6 +181,7 @@ intelInitExtensions(struct gl_context *ctx)
   ctx->Extensions.EXT_framebuffer_multisample = true;
   ctx->Extensions.EXT_framebuffer_multisample_blit_scaled = true;
   ctx->Extensions.EXT_transform_feedback = true;
+  ctx->Extensions.ARB_transform_feedback_overflow_query = true;
   ctx->Extensions.OES_depth_texture_cube_map = true;
   ctx->Extensions.OES_sample_variables = true;
 
-- 
2.7.4

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

[Mesa-dev] [PATCH v4 1/6] mesa: Add types for ARB_transform_feedback_oveflow_query.

[Rafael Antognolli]

Add some basic types and storage for the queries of this extension.

v2:
- update date of extension (Kenneth)

Signed-off-by: Rafael Antognolli 
---
 src/mesa/main/extensions_table.h | 1 +
 src/mesa/main/mtypes.h   | 5 +
 2 files changed, 6 insertions(+)

diff --git a/src/mesa/main/extensions_table.h b/src/mesa/main/extensions_table.h
index 2de3c59..27de41c 100644
--- a/src/mesa/main/extensions_table.h
+++ b/src/mesa/main/extensions_table.h
@@ -161,6 +161,7 @@ EXT(ARB_timer_query , 
ARB_timer_query
 EXT(ARB_transform_feedback2 , ARB_transform_feedback2  
  , GLL, GLC,  x ,  x , 2010)
 EXT(ARB_transform_feedback3 , ARB_transform_feedback3  
  , GLL, GLC,  x ,  x , 2010)
 EXT(ARB_transform_feedback_instanced, ARB_transform_feedback_instanced 
  , GLL, GLC,  x ,  x , 2011)
+EXT(ARB_transform_feedback_overflow_query   , 
ARB_transform_feedback_overflow_query  , GLL, GLC,  x ,  x , 2014)
 EXT(ARB_transpose_matrix, dummy_true   
  , GLL,  x ,  x ,  x , 1999)
 EXT(ARB_uniform_buffer_object   , ARB_uniform_buffer_object
  , GLL, GLC,  x ,  x , 2009)
 EXT(ARB_vertex_array_bgra   , EXT_vertex_array_bgra
  , GLL, GLC,  x ,  x , 2008)
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index f04ec51..19a6c30 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -3023,6 +3023,10 @@ struct gl_query_state
struct gl_query_object *PrimitivesGenerated[MAX_VERTEX_STREAMS];
struct gl_query_object *PrimitivesWritten[MAX_VERTEX_STREAMS];
 
+   /** GL_ARB_transform_feedback_overflow_query */
+   struct gl_query_object *TransformFeedbackOverflow[MAX_VERTEX_STREAMS];
+   struct gl_query_object *TransformFeedbackOverflowAny;
+
/** GL_ARB_timer_query */
struct gl_query_object *TimeElapsed;
 
@@ -3906,6 +3910,7 @@ struct gl_extensions
GLboolean ARB_transform_feedback2;
GLboolean ARB_transform_feedback3;
GLboolean ARB_transform_feedback_instanced;
+   GLboolean ARB_transform_feedback_overflow_query;
GLboolean ARB_uniform_buffer_object;
GLboolean ARB_vertex_attrib_64bit;
GLboolean ARB_vertex_program;
-- 
2.7.4

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

[Mesa-dev] [PATCH v4 2/6] mesa: Track transform feedback overflow query objects.

[Rafael Antognolli]

Also update checks on conditional rendering.

Signed-off-by: Rafael Antognolli 
---
 src/mesa/main/condrender.c  |  4 +++-
 src/mesa/main/queryobj.c| 21 +
 src/mesa/state_tracker/st_cb_queryobj.c |  6 ++
 3 files changed, 30 insertions(+), 1 deletion(-)

diff --git a/src/mesa/main/condrender.c b/src/mesa/main/condrender.c
index 46c6036..2ea2c88 100644
--- a/src/mesa/main/condrender.c
+++ b/src/mesa/main/condrender.c
@@ -99,7 +99,9 @@ _mesa_BeginConditionalRender(GLuint queryId, GLenum mode)
 */
if ((q->Target != GL_SAMPLES_PASSED &&
 q->Target != GL_ANY_SAMPLES_PASSED &&
-q->Target != GL_ANY_SAMPLES_PASSED_CONSERVATIVE) || q->Active) {
+q->Target != GL_ANY_SAMPLES_PASSED_CONSERVATIVE &&
+q->Target != GL_TRANSFORM_FEEDBACK_STREAM_OVERFLOW_ARB &&
+q->Target != GL_TRANSFORM_FEEDBACK_OVERFLOW_ARB) || q->Active) {
   _mesa_error(ctx, GL_INVALID_OPERATION, "glBeginConditionalRender()");
   return;
}
diff --git a/src/mesa/main/queryobj.c b/src/mesa/main/queryobj.c
index 1fa0279..e4edb51 100644
--- a/src/mesa/main/queryobj.c
+++ b/src/mesa/main/queryobj.c
@@ -197,6 +197,16 @@ get_query_binding_point(struct gl_context *ctx, GLenum 
target, GLuint index)
  return >Query.PrimitivesWritten[index];
   else
  return NULL;
+   case GL_TRANSFORM_FEEDBACK_STREAM_OVERFLOW_ARB:
+  if (ctx->Extensions.ARB_transform_feedback_overflow_query)
+ return >Query.TransformFeedbackOverflow[index];
+  else
+ return NULL;
+   case GL_TRANSFORM_FEEDBACK_OVERFLOW_ARB:
+  if (ctx->Extensions.ARB_transform_feedback_overflow_query)
+ return >Query.TransformFeedbackOverflowAny;
+  else
+ return NULL;
 
case GL_VERTICES_SUBMITTED_ARB:
case GL_PRIMITIVES_SUBMITTED_ARB:
@@ -293,6 +303,8 @@ _mesa_CreateQueries(GLenum target, GLsizei n, GLuint *ids)
case GL_TIMESTAMP:
case GL_PRIMITIVES_GENERATED:
case GL_TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN:
+   case GL_TRANSFORM_FEEDBACK_STREAM_OVERFLOW_ARB:
+   case GL_TRANSFORM_FEEDBACK_OVERFLOW_ARB:
   break;
default:
   _mesa_error(ctx, GL_INVALID_ENUM, "glCreateQueries(invalid target = %s)",
@@ -368,6 +380,7 @@ query_error_check_index(struct gl_context *ctx, GLenum 
target, GLuint index)
switch (target) {
case GL_TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN:
case GL_PRIMITIVES_GENERATED:
+   case GL_TRANSFORM_FEEDBACK_STREAM_OVERFLOW_ARB:
   if (index >= ctx->Const.MaxVertexStreams) {
  _mesa_error(ctx, GL_INVALID_VALUE,
  "glBeginQueryIndexed(index>=MaxVertexStreams)");
@@ -677,6 +690,14 @@ _mesa_GetQueryIndexediv(GLenum target, GLuint index, 
GLenum pname,
  case GL_TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN:
 *params = ctx->Const.QueryCounterBits.PrimitivesWritten;
 break;
+ case GL_TRANSFORM_FEEDBACK_STREAM_OVERFLOW_ARB:
+ case GL_TRANSFORM_FEEDBACK_OVERFLOW_ARB:
+/* The minimum value of this is 1 if it's nonzero, and the value
+ * is only ever GL_TRUE or GL_FALSE, so no sense in reporting more
+ * bits.
+ */
+*params = 1;
+break;
  case GL_VERTICES_SUBMITTED_ARB:
 *params = ctx->Const.QueryCounterBits.VerticesSubmitted;
 break;
diff --git a/src/mesa/state_tracker/st_cb_queryobj.c 
b/src/mesa/state_tracker/st_cb_queryobj.c
index 2489676..b1ac2aa 100644
--- a/src/mesa/state_tracker/st_cb_queryobj.c
+++ b/src/mesa/state_tracker/st_cb_queryobj.c
@@ -114,6 +114,12 @@ st_BeginQuery(struct gl_context *ctx, struct 
gl_query_object *q)
case GL_TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN:
   type = PIPE_QUERY_PRIMITIVES_EMITTED;
   break;
+   case GL_TRANSFORM_FEEDBACK_STREAM_OVERFLOW_ARB:
+  type = PIPE_QUERY_SO_OVERFLOW_PREDICATE;
+  break;
+   case GL_TRANSFORM_FEEDBACK_OVERFLOW_ARB:
+  type = PIPE_QUERY_SO_OVERFLOW_PREDICATE;
+  break;
case GL_TIME_ELAPSED:
   if (st->has_time_elapsed)
  type = PIPE_QUERY_TIME_ELAPSED;
-- 
2.7.4

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

[Mesa-dev] [PATCH v4 3/6] i965: add plumbing for ARB_transform_feedback_overflow_query.

[Rafael Antognolli]

When querying for transform feedback overflow on one or all of the
streams, store information about number of generated and written
primitives. Then check whether generated == written.

v2:
- use only SO_PRIM_STORAGE_NEEDED, do not fallback to
  CL_INVOCATION_COUNT. (Kenneth)

Signed-off-by: Rafael Antognolli 
---
 src/mesa/drivers/dri/i965/brw_queryobj.c  |  2 +
 src/mesa/drivers/dri/i965/gen6_queryobj.c | 73 +++
 2 files changed, 75 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/brw_queryobj.c 
b/src/mesa/drivers/dri/i965/brw_queryobj.c
index dda17de..40b86a0 100644
--- a/src/mesa/drivers/dri/i965/brw_queryobj.c
+++ b/src/mesa/drivers/dri/i965/brw_queryobj.c
@@ -530,6 +530,8 @@ brw_is_query_pipelined(struct brw_query_object *query)
 
case GL_PRIMITIVES_GENERATED:
case GL_TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN:
+   case GL_TRANSFORM_FEEDBACK_STREAM_OVERFLOW_ARB:
+   case GL_TRANSFORM_FEEDBACK_OVERFLOW_ARB:
case GL_VERTICES_SUBMITTED_ARB:
case GL_PRIMITIVES_SUBMITTED_ARB:
case GL_VERTEX_SHADER_INVOCATIONS_ARB:
diff --git a/src/mesa/drivers/dri/i965/gen6_queryobj.c 
b/src/mesa/drivers/dri/i965/gen6_queryobj.c
index bbd3c44..98cbbff 100644
--- a/src/mesa/drivers/dri/i965/gen6_queryobj.c
+++ b/src/mesa/drivers/dri/i965/gen6_queryobj.c
@@ -98,6 +98,54 @@ write_xfb_primitives_written(struct brw_context *brw,
}
 }
 
+static void
+write_xfb_overflow_streams(struct gl_context *ctx,
+   drm_intel_bo *bo, int stream, int count,
+   int idx)
+{
+   struct brw_context *brw = brw_context(ctx);
+
+   brw_emit_mi_flush(brw);
+
+   for (int i = 0; i < count; i++) {
+  int w_idx = 4 * i + idx;
+  int g_idx = 4 * i + idx + 2;
+
+  if (brw->gen >= 7) {
+ brw_store_register_mem64(brw, bo,
+  GEN7_SO_NUM_PRIMS_WRITTEN(stream + i),
+  g_idx * sizeof(uint64_t));
+ brw_store_register_mem64(brw, bo,
+  GEN7_SO_PRIM_STORAGE_NEEDED(stream + i),
+  w_idx * sizeof(uint64_t));
+  } else {
+ brw_store_register_mem64(brw, bo,
+  GEN6_SO_NUM_PRIMS_WRITTEN,
+  g_idx * sizeof(uint64_t));
+ brw_store_register_mem64(brw, bo,
+  GEN6_SO_PRIM_STORAGE_NEEDED,
+  w_idx * sizeof(uint64_t));
+  }
+   }
+}
+
+static bool
+check_xfb_overflow_streams(uint64_t *results, int count)
+{
+   bool overflow = false;
+
+   for (int i = 0; i < count; i++) {
+  uint64_t *result_i = [4 * i];
+
+  if ((result_i[3] - result_i[2]) != (result_i[1] - result_i[0])) {
+ overflow = true;
+ break;
+  }
+   }
+
+   return overflow;
+}
+
 static inline int
 pipeline_target_to_index(int target)
 {
@@ -225,6 +273,14 @@ gen6_queryobj_get_results(struct gl_context *ctx,
   query->Base.Result = results[1] - results[0];
   break;
 
+   case GL_TRANSFORM_FEEDBACK_STREAM_OVERFLOW_ARB:
+  query->Base.Result = check_xfb_overflow_streams(results, 1);
+  break;
+
+   case GL_TRANSFORM_FEEDBACK_OVERFLOW_ARB:
+  query->Base.Result = check_xfb_overflow_streams(results, 
MAX_VERTEX_STREAMS);
+  break;
+
case GL_FRAGMENT_SHADER_INVOCATIONS_ARB:
   query->Base.Result = (results[1] - results[0]);
   /* Implement the "WaDividePSInvocationCountBy4:HSW,BDW" workaround:
@@ -314,6 +370,14 @@ gen6_begin_query(struct gl_context *ctx, struct 
gl_query_object *q)
   write_xfb_primitives_written(brw, query->bo, query->Base.Stream, 0);
   break;
 
+   case GL_TRANSFORM_FEEDBACK_STREAM_OVERFLOW_ARB:
+  write_xfb_overflow_streams(ctx, query->bo, query->Base.Stream, 1, 0);
+  break;
+
+   case GL_TRANSFORM_FEEDBACK_OVERFLOW_ARB:
+  write_xfb_overflow_streams(ctx, query->bo, 0, MAX_VERTEX_STREAMS, 0);
+  break;
+
case GL_VERTICES_SUBMITTED_ARB:
case GL_PRIMITIVES_SUBMITTED_ARB:
case GL_VERTEX_SHADER_INVOCATIONS_ARB:
@@ -368,6 +432,15 @@ gen6_end_query(struct gl_context *ctx, struct 
gl_query_object *q)
   write_xfb_primitives_written(brw, query->bo, query->Base.Stream, 1);
   break;
 
+   case GL_TRANSFORM_FEEDBACK_STREAM_OVERFLOW_ARB:
+  write_xfb_overflow_streams(ctx, query->bo, query->Base.Stream, 1, 1);
+  break;
+
+   case GL_TRANSFORM_FEEDBACK_OVERFLOW_ARB:
+  write_xfb_overflow_streams(ctx, query->bo, 0, MAX_VERTEX_STREAMS, 1);
+  break;
+
+  /* calculate overflow here */
case GL_VERTICES_SUBMITTED_ARB:
case GL_PRIMITIVES_SUBMITTED_ARB:
case GL_VERTEX_SHADER_INVOCATIONS_ARB:
-- 
2.7.4

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

[Mesa-dev] [PATCH v4 0/6] Add support for ARB_transform_feedback_overflow_query.

[Rafael Antognolli]

This patch series implements the ARB_transform_feedback_overflow_query
extension for i965.

Changes for v4:
- Reuse of MI_MATH calcs from hsw_queryobj.c in brw_conditional_render.c
- Renamed a couple functions as suggested by Kenneth
- Fallback to CPU-side conditional rendering if MI_MATH is not available.

The series is available on github here:

https://github.com/rantogno/mesa/tree/review/overflow_query-v04

There are also piglit tests available for it here:

https://github.com/rantogno/piglit/tree/review/overflow_query-v05

Regards,
Rafael

Rafael Antognolli (6):
  mesa: Add types for ARB_transform_feedback_oveflow_query.
  mesa: Track transform feedback overflow query objects.
  i965: add plumbing for ARB_transform_feedback_overflow_query.
  i965: Add support for xfb overflow on query buffer objects.
  i965: Add support for xfb overflow query on conditional render.
  i965/gen6+: Enable arb_transform_feedback_overflow_query.

 docs/features.txt  |   2 +-
 docs/relnotes/17.0.0.html  |   1 +
 src/mesa/drivers/dri/i965/brw_conditional_render.c |  73 ++
 src/mesa/drivers/dri/i965/brw_context.h|   3 +
 src/mesa/drivers/dri/i965/brw_queryobj.c   |   2 +
 src/mesa/drivers/dri/i965/gen6_queryobj.c  |  73 ++
 src/mesa/drivers/dri/i965/hsw_queryobj.c   | 112 +
 src/mesa/drivers/dri/i965/intel_extensions.c   |   1 +
 src/mesa/main/condrender.c |   4 +-
 src/mesa/main/extensions_table.h   |   1 +
 src/mesa/main/mtypes.h |   5 +
 src/mesa/main/queryobj.c   |  21 
 src/mesa/state_tracker/st_cb_queryobj.c|   6 ++
 13 files changed, 284 insertions(+), 20 deletions(-)

-- 
2.7.4

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

[Mesa-dev] [PATCH v4 5/6] i965: Add support for xfb overflow query on conditional render.

[Rafael Antognolli]

Enable the use of a transform feedback overflow query with
glBeginConditionalRender. The render commands will only execute if the
query is true (i.e. if there was an overflow).

Use ARB_conditional_render_inverted to change this behavior.

v4:
- reuse MI_MATH calcs from hsw_queryob (Kenneth)
- fallback to software conditional rendering when MI_MATH is not
  available (Kenneth)

Signed-off-by: Rafael Antognolli 
---
 src/mesa/drivers/dri/i965/brw_conditional_render.c | 73 --
 1 file changed, 55 insertions(+), 18 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_conditional_render.c 
b/src/mesa/drivers/dri/i965/brw_conditional_render.c
index 122a4ec..af6be97 100644
--- a/src/mesa/drivers/dri/i965/brw_conditional_render.c
+++ b/src/mesa/drivers/dri/i965/brw_conditional_render.c
@@ -48,20 +48,19 @@ set_predicate_enable(struct brw_context *brw,
 }
 
 static void
-set_predicate_for_result(struct brw_context *brw,
- struct brw_query_object *query,
- bool inverted)
+set_predicate_for_overflow_query(struct brw_context *brw,
+ struct brw_query_object *query,
+ int stream_start, int count)
 {
-   int load_op;
-
-   assert(query->bo != NULL);
-
-   /* Needed to ensure the memory is coherent for the MI_LOAD_REGISTER_MEM
-* command when loading the values into the predicate source registers for
-* conditional rendering.
-*/
-   brw_emit_pipe_control_flush(brw, PIPE_CONTROL_FLUSH_ENABLE);
+   hsw_overflow_result_to_gpr0(brw, query, count);
+   brw_load_register_reg64(brw, HSW_CS_GPR(0), MI_PREDICATE_SRC0);
+   brw_load_register_imm64(brw, MI_PREDICATE_SRC1, 0ull);
+}
 
+static void
+set_predicate_for_occlusion_query(struct brw_context *brw,
+  struct brw_query_object *query)
+{
brw_load_register_mem64(brw,
MI_PREDICATE_SRC0,
query->bo,
@@ -74,6 +73,34 @@ set_predicate_for_result(struct brw_context *brw,
I915_GEM_DOMAIN_INSTRUCTION,
0, /* write domain */
8 /* offset */);
+}
+
+static void
+set_predicate_for_result(struct brw_context *brw,
+ struct brw_query_object *query,
+ bool inverted)
+{
+
+   int load_op;
+
+   assert(query->bo != NULL);
+
+   /* Needed to ensure the memory is coherent for the MI_LOAD_REGISTER_MEM
+* command when loading the values into the predicate source registers for
+* conditional rendering.
+*/
+   brw_emit_pipe_control_flush(brw, PIPE_CONTROL_FLUSH_ENABLE);
+
+   switch (query->Base.Target) {
+   case GL_TRANSFORM_FEEDBACK_STREAM_OVERFLOW_ARB:
+  set_predicate_for_overflow_query(brw, query, 0, 1);
+  break;
+   case GL_TRANSFORM_FEEDBACK_OVERFLOW_ARB:
+  set_predicate_for_overflow_query(brw, query, 0, MAX_VERTEX_STREAMS);
+  break;
+   default:
+  set_predicate_for_occlusion_query(brw, query);
+   }
 
if (inverted)
   load_op = MI_PREDICATE_LOADOP_LOAD;
@@ -102,6 +129,11 @@ brw_begin_conditional_render(struct gl_context *ctx,
if (!brw->predicate.supported)
   return;
 
+   if ((brw->ctx.Query.Target == GL_TRANSFORM_FEEDBACK_OVERFLOW_ARB ||
+brw->ctx.Query.Target == GL_TRANSFORM_FEEDBACK_STREAM_OVERFLOW_ARB) &&
+   !can_do_mi_math_and_lrr(brw->screen))
+  return;
+
switch (mode) {
case GL_QUERY_WAIT:
case GL_QUERY_NO_WAIT:
@@ -152,12 +184,17 @@ bool
 brw_check_conditional_render(struct brw_context *brw)
 {
if (brw->predicate.supported) {
-  /* In some cases it is possible to determine that the primitives should
-   * be skipped without needing the predicate enable bit and still without
-   * stalling.
-   */
-  return brw->predicate.state != BRW_PREDICATE_STATE_DONT_RENDER;
-   } else if (brw->ctx.Query.CondRenderQuery) {
+  if ((brw->ctx.Query.Target != GL_TRANSFORM_FEEDBACK_OVERFLOW_ARB &&
+   brw->ctx.Query.Target != GL_TRANSFORM_FEEDBACK_STREAM_OVERFLOW_ARB)
+  || can_do_mi_math_and_lrr(brw->screen))
+ /* In some cases it is possible to determine that the primitives 
should
+  * be skipped without needing the predicate enable bit and still
+  * without stalling.
+  */
+ return brw->predicate.state != BRW_PREDICATE_STATE_DONT_RENDER;
+   }
+
+   if (brw->ctx.Query.CondRenderQuery) {
   perf_debug("Conditional rendering is implemented in software and may "
  "stall.\n");
   return _mesa_check_conditional_render(>ctx);
-- 
2.7.4

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

Re: [Mesa-dev] [PATCH v2 2/2] anv: don't require render target isl bit for depth/stencil surfaces

[Jason Ekstrand]

Cc: "13.0 17.0" 
Reviewed-by: Jason Ekstrand 

On Fri, Jan 20, 2017 at 9:31 AM, Lionel Landwerlin <
lionel.g.landwer...@intel.com> wrote:

> Blorp can deal with depth/stencil surfaces blits/copies without the
> render target requirement. Also having both render target and
> depth/stencil requirement is incompatible from isl's point of view.
>
> This fixes an image creation issue in the high level quality settings
> of the Unity3D player, which requires a depth texture with src/dst
> transfer & 4x multisampling.
>
> v2: Simply aspect checking condition (Jason)
>
> Signed-off-by: Lionel Landwerlin 
> ---
>  src/intel/vulkan/anv_image.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/src/intel/vulkan/anv_image.c b/src/intel/vulkan/anv_image.c
> index 9e5cebe188..12cca67a98 100644
> --- a/src/intel/vulkan/anv_image.c
> +++ b/src/intel/vulkan/anv_image.c
> @@ -75,8 +75,11 @@ choose_isl_surf_usage(VkImageUsageFlags vk_usage,
>isl_usage |= ISL_SURF_USAGE_TEXTURE_BIT;
> }
>
> -   if (vk_usage & VK_IMAGE_USAGE_TRANSFER_DST_BIT) {
> -  /* blorp implements transfers by rendering into the destination
> image. */
> +   if (vk_usage & VK_IMAGE_USAGE_TRANSFER_DST_BIT &&
> +   aspect == VK_IMAGE_ASPECT_COLOR_BIT) {
> +  /* blorp implements transfers by rendering into the destination
> image.
> +   * Only request this with color images, as we deal with
> depth/stencil
> +   * formats differently. */
>isl_usage |= ISL_SURF_USAGE_RENDER_TARGET_BIT;
> }
>
> --
> 2.11.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] [PATCH v2 2/2] anv: don't require render target isl bit for depth/stencil surfaces

[Lionel Landwerlin]

Blorp can deal with depth/stencil surfaces blits/copies without the
render target requirement. Also having both render target and
depth/stencil requirement is incompatible from isl's point of view.

This fixes an image creation issue in the high level quality settings
of the Unity3D player, which requires a depth texture with src/dst
transfer & 4x multisampling.

v2: Simply aspect checking condition (Jason)

Signed-off-by: Lionel Landwerlin 
---
 src/intel/vulkan/anv_image.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/src/intel/vulkan/anv_image.c b/src/intel/vulkan/anv_image.c
index 9e5cebe188..12cca67a98 100644
--- a/src/intel/vulkan/anv_image.c
+++ b/src/intel/vulkan/anv_image.c
@@ -75,8 +75,11 @@ choose_isl_surf_usage(VkImageUsageFlags vk_usage,
   isl_usage |= ISL_SURF_USAGE_TEXTURE_BIT;
}

-   if (vk_usage & VK_IMAGE_USAGE_TRANSFER_DST_BIT) {
-  /* blorp implements transfers by rendering into the destination image. */
+   if (vk_usage & VK_IMAGE_USAGE_TRANSFER_DST_BIT &&
+   aspect == VK_IMAGE_ASPECT_COLOR_BIT) {
+  /* blorp implements transfers by rendering into the destination image.
+   * Only request this with color images, as we deal with depth/stencil
+   * formats differently. */
   isl_usage |= ISL_SURF_USAGE_RENDER_TARGET_BIT;
}

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

Re: [Mesa-dev] [PATCH 1/2] spirv: don't assert with location decorations on non i/o variables

[Jason Ekstrand]

On Fri, Jan 20, 2017 at 8:45 AM, Lionel Landwerlin <
lionel.g.landwer...@intel.com> wrote:

> Some applications might add location decoration to samplers. Rather
> than raising an error it seems it would make more sense to just
> discard these decorations.
>

That's annoying but not the end of the world.  Please CC to 17.0 stable
(but not 13.0)  Also, please try and file a bug with the Unit3D people as
this is a bug in their SPIR-V generator.

Reviewed-by: Jason Ekstrand 


> Signed-off-by: Lionel Landwerlin 
> ---
>  src/compiler/spirv/vtn_variables.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/src/compiler/spirv/vtn_variables.c b/src/compiler/spirv/vtn_
> variables.c
> index 61a3701e43..61373d4e88 100644
> --- a/src/compiler/spirv/vtn_variables.c
> +++ b/src/compiler/spirv/vtn_variables.c
> @@ -1199,7 +1199,8 @@ var_decoration_cb(struct vtn_builder *b, struct
> vtn_value *val, int member,
>   is_vertex_input = false;
>   location += vtn_var->patch ? VARYING_SLOT_PATCH0 :
> VARYING_SLOT_VAR0;
>} else {
> - unreachable("Location must be on input or output variable");
> + vtn_warn("Location must be on input or output variable");
>
+ return;
>}
>
>if (vtn_var->var) {
> --
> 2.11.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

Re: [Mesa-dev] [PATCH 2/2] anv: don't require render target isl bit for depth/stencil surfaces

[Jason Ekstrand]

On Fri, Jan 20, 2017 at 8:45 AM, Lionel Landwerlin <
lionel.g.landwer...@intel.com> wrote:

> Blorp can deal with depth/stencil surfaces blits/copies without the
> render target requirement. Also having both render target and
> depth/stencil requirement is incompatible from isl's point of view.
>
> This fixes an image creation issue in the high level quality settings
> of the Unity3D player, which requires a depth texture with src/dst
> transfer & 4x multisampling.
>
> Signed-off-by: Lionel Landwerlin 
> ---
>  src/intel/vulkan/anv_image.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/src/intel/vulkan/anv_image.c b/src/intel/vulkan/anv_image.c
> index 9e5cebe188..8f738b2042 100644
> --- a/src/intel/vulkan/anv_image.c
> +++ b/src/intel/vulkan/anv_image.c
> @@ -75,8 +75,12 @@ choose_isl_surf_usage(VkImageUsageFlags vk_usage,
>isl_usage |= ISL_SURF_USAGE_TEXTURE_BIT;
> }
>
> -   if (vk_usage & VK_IMAGE_USAGE_TRANSFER_DST_BIT) {
> -  /* blorp implements transfers by rendering into the destination
> image. */
> +   if (vk_usage & VK_IMAGE_USAGE_TRANSFER_DST_BIT &&
> +   (aspect & (VK_IMAGE_ASPECT_DEPTH_BIT |
> +  VK_IMAGE_ASPECT_STENCIL_BIT)) == 0) {
>

How about just "aspect == VK_IMAGE_ASPECT_COLOR_BIT"?  That would be
simpler.  Also, this should get CC'd to stable.


> +  /* blorp implements transfers by rendering into the destination
> image.
> +   * Only request this with color images, as we deal with
> depth/stencil
> +   * formats differently. */
>isl_usage |= ISL_SURF_USAGE_RENDER_TARGET_BIT;
> }
>
> --
> 2.11.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] [PATCH 0/2] anv/spirv: Fixes for Unity3D

[Lionel Landwerlin]

Hi,

While testing Unity3D demos, I've noticed a couple of issues with our
driver.

Cheers,

Lionel Landwerlin (2):
  spirv: don't assert with location decorations on non i/o variables
  anv: don't require render target isl bit for depth/stencil surfaces

 src/compiler/spirv/vtn_variables.c | 3 ++-
 src/intel/vulkan/anv_image.c   | 8 ++--
 2 files changed, 8 insertions(+), 3 deletions(-)

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

[Mesa-dev] [PATCH 1/2] spirv: don't assert with location decorations on non i/o variables

[Lionel Landwerlin]

Some applications might add location decoration to samplers. Rather
than raising an error it seems it would make more sense to just
discard these decorations.

Signed-off-by: Lionel Landwerlin 
---
 src/compiler/spirv/vtn_variables.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/compiler/spirv/vtn_variables.c 
b/src/compiler/spirv/vtn_variables.c
index 61a3701e43..61373d4e88 100644
--- a/src/compiler/spirv/vtn_variables.c
+++ b/src/compiler/spirv/vtn_variables.c
@@ -1199,7 +1199,8 @@ var_decoration_cb(struct vtn_builder *b, struct vtn_value 
*val, int member,
  is_vertex_input = false;
  location += vtn_var->patch ? VARYING_SLOT_PATCH0 : VARYING_SLOT_VAR0;
   } else {
- unreachable("Location must be on input or output variable");
+ vtn_warn("Location must be on input or output variable");
+ return;
   }
 
   if (vtn_var->var) {
-- 
2.11.0

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

[Mesa-dev] [PATCH 2/2] anv: don't require render target isl bit for depth/stencil surfaces

[Lionel Landwerlin]

Blorp can deal with depth/stencil surfaces blits/copies without the
render target requirement. Also having both render target and
depth/stencil requirement is incompatible from isl's point of view.

This fixes an image creation issue in the high level quality settings
of the Unity3D player, which requires a depth texture with src/dst
transfer & 4x multisampling.

Signed-off-by: Lionel Landwerlin 
---
 src/intel/vulkan/anv_image.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/src/intel/vulkan/anv_image.c b/src/intel/vulkan/anv_image.c
index 9e5cebe188..8f738b2042 100644
--- a/src/intel/vulkan/anv_image.c
+++ b/src/intel/vulkan/anv_image.c
@@ -75,8 +75,12 @@ choose_isl_surf_usage(VkImageUsageFlags vk_usage,
   isl_usage |= ISL_SURF_USAGE_TEXTURE_BIT;
}
 
-   if (vk_usage & VK_IMAGE_USAGE_TRANSFER_DST_BIT) {
-  /* blorp implements transfers by rendering into the destination image. */
+   if (vk_usage & VK_IMAGE_USAGE_TRANSFER_DST_BIT &&
+   (aspect & (VK_IMAGE_ASPECT_DEPTH_BIT |
+  VK_IMAGE_ASPECT_STENCIL_BIT)) == 0) {
+  /* blorp implements transfers by rendering into the destination image.
+   * Only request this with color images, as we deal with depth/stencil
+   * formats differently. */
   isl_usage |= ISL_SURF_USAGE_RENDER_TARGET_BIT;
}
 
-- 
2.11.0

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

Re: [Mesa-dev] Time to update GSoC/EVoC ideas page

[Jason Ekstrand]

On Fri, Jan 20, 2017 at 2:15 AM, Nicolai Hähnle  wrote:

> Hi Rob,
>
> On 19.01.2017 23:32, Rob Clark wrote:
>
>> Just a friendly reminder that now would be a good time to update the
>> wiki page for GSoC/EVoC ideas:
>>
>>   https://www.x.org/wiki/SummerOfCodeIdeas/
>>
>> There are currently still some stale ideas there (and probably plenty
>> of missing good ideas).
>>
>> Also, I've added a "Potential Mentors" section.  Please add yourself
>> if you are willing to be a mentor (and what sorts of projects you
>> would be willing to mentor)
>>
>
> I'd be happy to be listed as a possible mentor on the DriConf replacement
> project (nha on IRC/freenode), but I either don't have a Wiki account or
> forgot it a long time ago. Could you put my name down on the page?
>

Pro tip: You can just git clone the wiki, change a markdown file, and git
push it back up.  That's the way I always make edits.  Way nicer than a web
GUI. :-)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/3] spirv: fix warn string typo

[Jason Ekstrand]

All three are

Reviewed-by: Jason Ekstrand 

On Fri, Jan 20, 2017 at 8:38 AM, Lionel Landwerlin <
lionel.g.landwer...@intel.com> wrote:

> Signed-off-by: Lionel Landwerlin 
> ---
>  src/compiler/spirv/vtn_variables.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/compiler/spirv/vtn_variables.c b/src/compiler/spirv/vtn_
> variables.c
> index 61a3701e43..a543a52dd0 100644
> --- a/src/compiler/spirv/vtn_variables.c
> +++ b/src/compiler/spirv/vtn_variables.c
> @@ -1132,7 +1132,7 @@ apply_var_decoration(struct vtn_builder *b,
> nir_variable *nir_var,
> case SpvDecorationFPRoundingMode:
> case SpvDecorationFPFastMathMode:
> case SpvDecorationAlignment:
> -  vtn_warn("Decoraiton only allowed for CL-style kernels: %s",
> +  vtn_warn("Decoration only allowed for CL-style kernels: %s",
> spirv_decoration_to_string(dec->decoration));
>break;
> }
> --
> 2.11.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

Re: [Mesa-dev] [PATCH] i965/blorp: Add also depth buffer to render cache

[Jason Ekstrand]

On Thu, Jan 19, 2017 at 11:48 PM, Pohjolainen, Topi <
topi.pohjolai...@gmail.com> wrote:

> On Thu, Jan 19, 2017 at 01:39:49PM -0800, Jason Ekstrand wrote:
> >On Thu, Jan 19, 2017 at 12:40 PM, Francisco Jerez
> ><[1]curroje...@riseup.net> wrote:
> >
> >  "Pohjolainen, Topi" <[2]topi.pohjolai...@gmail.com> writes:
> >  > On Thu, Jan 19, 2017 at 12:10:02PM -0800, Francisco Jerez wrote:
> >  >> Topi Pohjolainen <[3]topi.pohjolai...@gmail.com> writes:
> >  >>
> >  >> > CC: Francisco Jerez <[4]curroje...@riseup.net>
> >  >> > CC: Kenneth Graunke <[5]kenn...@whitecape.org>
> >  >> > CC: Jason Ekstrand <[6]ja...@jlekstrand.net>
> >  >> > Signed-off-by: Topi Pohjolainen <[7]topi.pohjolai...@intel.com
> >
> >  >> > ---
> >  >> >  src/mesa/drivers/dri/i965/genX_blorp_exec.c | 3 +++
> >  >> >  1 file changed, 3 insertions(+)
> >  >> >
> >  >> > diff --git a/src/mesa/drivers/dri/i965/genX_blorp_exec.c
> >  b/src/mesa/drivers/dri/i965/genX_blorp_exec.c
> >  >> > index 647a362..594bd5a 100644
> >  >> > --- a/src/mesa/drivers/dri/i965/genX_blorp_exec.c
> >  >> > +++ b/src/mesa/drivers/dri/i965/genX_blorp_exec.c
> >  >> > @@ -261,4 +261,7 @@ retry:
> >  >> >
> >  >> > if (params->dst.enabled)
> >  >> >brw_render_cache_set_add_bo(brw,
> >  params->dst.addr.buffer);
> >  >> > +
> >  >> > +   if (params->depth.enabled)
> >  >> > +  brw_render_cache_set_add_bo(brw,
> >  params->depth.addr.buffer);
> >  >>
> >  >> What about the stencil buffer?  Stencil texturing is likely to be
> >  >> unhappy unless you mark it as pending flush as well...
> >  >
> >  > As far as I know i965 only clears depth and color using blorp,
> >  stencil gets
> >  > cleared using meta. Blits in turn have it as destination.
> >  >
> >  That doesn't sound like a safe assumption to rely on looking forward
> >  if
> >  the blorp api already exposes support for stencil writes -- Tracking
> >  down the ultimate cause of a memory coherency bugs can be really
> >  hard,
> >  why make our future lives more intentionally difficult by
> >  introducing
> >  buggy corner cases like this?  The extra check is not going to hurt
> >  performance or cause any other harmful side effects unless stencil
> >  writes are used...
> >
> >Agreed.  Let's stick it in there for stencil too.  I've got patches to
> >switch i965 over to blorp for depth/stencil blits.  I never landed
> them
> >because of what was most likely flushing bugs.  I'm hoping that you've
> >fixed those and I'll revive the patches.
> >Also, please make sure these fixes hit stable.
>
> This sits on top the four earlier patches. Rebasing this alone against
> stable
> requires manual work but can be done. How do you want to handle that?
>

Ken, Curro, and I had a little chat about this in the office.  I think the
conclusion we came to was the following:

1) The patches to add flushing around HiZ ops and fast clear ops should get
back-ported all the way to 13.0.  They fix potentially serious bugs that
could cause problems.
2) The patches that switch us over to the render cache should get
backported to 17.0.  They aren't so much a bug fix as an enhancement but
keeping 17.0 consistent with future will help in backporting other fixes.
For the record, this was me and Ken; Curro preferred to not backport these.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/3] blorp: remove unnecessary struct declaration

[Lionel Landwerlin]

Signed-off-by: Lionel Landwerlin 
---
 src/intel/blorp/blorp.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/src/intel/blorp/blorp.h b/src/intel/blorp/blorp.h
index ff60567fc4..e0687e9261 100644
--- a/src/intel/blorp/blorp.h
+++ b/src/intel/blorp/blorp.h
@@ -29,7 +29,6 @@
 
 #include "isl/isl.h"
 
-struct brw_context;
 struct brw_stage_prog_data;
 
 #ifdef __cplusplus
-- 
2.11.0

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

[Mesa-dev] [PATCH 2/3] spirv: fix warn string typo

[Lionel Landwerlin]

Signed-off-by: Lionel Landwerlin 
---
 src/compiler/spirv/vtn_variables.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/compiler/spirv/vtn_variables.c 
b/src/compiler/spirv/vtn_variables.c
index 61a3701e43..a543a52dd0 100644
--- a/src/compiler/spirv/vtn_variables.c
+++ b/src/compiler/spirv/vtn_variables.c
@@ -1132,7 +1132,7 @@ apply_var_decoration(struct vtn_builder *b, nir_variable 
*nir_var,
case SpvDecorationFPRoundingMode:
case SpvDecorationFPFastMathMode:
case SpvDecorationAlignment:
-  vtn_warn("Decoraiton only allowed for CL-style kernels: %s",
+  vtn_warn("Decoration only allowed for CL-style kernels: %s",
spirv_decoration_to_string(dec->decoration));
   break;
}
-- 
2.11.0

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

[Mesa-dev] [PATCH 3/3] anv: fix comment typo

[Lionel Landwerlin]

Signed-off-by: Lionel Landwerlin 
---
 src/intel/vulkan/anv_descriptor_set.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/intel/vulkan/anv_descriptor_set.c 
b/src/intel/vulkan/anv_descriptor_set.c
index 2926e7a259..4367c0ebe0 100644
--- a/src/intel/vulkan/anv_descriptor_set.c
+++ b/src/intel/vulkan/anv_descriptor_set.c
@@ -217,7 +217,7 @@ sha1_update_descriptor_set_layout(struct mesa_sha1 *ctx,
 
 /*
  * Pipeline layouts.  These have nothing to do with the pipeline.  They are
- * just muttiple descriptor set layouts pasted together
+ * just multiple descriptor set layouts pasted together
  */
 
 VkResult anv_CreatePipelineLayout(
-- 
2.11.0

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

[Mesa-dev] [Bug 99446] [anv] (and radv) Regression enabling Vulkan loader interface version 3

[bugzilla-daemon]

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

yann  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

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

[Mesa-dev] [Bug 99446] [anv] (and radv) Regression enabling Vulkan loader interface version 3

[bugzilla-daemon]

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

Jason Ekstrand  changed:

   What|Removed |Added

 Resolution|--- |NOTOURBUG
 Status|NEEDINFO|RESOLVED

--- Comment #9 from Jason Ekstrand  ---
(In reply to Eero Tamminen from comment #8)
> Sorry, that was yesterday's git, in today's upstream git, vulkaninfo handles
> gracefully connection failures too.

That makes it sound a whole lot like it's a loader/vulkaninfo bug.

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

Re: [Mesa-dev] [PATCH 01/19] i965: automake: correctly set MKDIR_GEN

[Emil Velikov]

On 16 January 2017 at 18:30, Kenneth Graunke  wrote:
> On Monday, January 16, 2017 3:45:32 PM PST Emil Velikov wrote:
>> From: Emil Velikov 
>>
>> Otherwise we might end up w/o the respective folder (depending on
>> autotools version) and fail at build time.
>>
>> Fixes: bfd17c76c12 "i965: Port INTEL_PRECISE_TRIG=1 to NIR."
>> Cc: "12.0 13.0" 
>> Cc: Kenneth Graunke 
>> Signed-off-by: Emil Velikov 
>> ---
>> Worth setting in configure and/or using @MKDIR_GEN@ + AC_SUBST ?
>> ---
>>  src/mesa/drivers/dri/i965/Makefile.am | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/src/mesa/drivers/dri/i965/Makefile.am 
>> b/src/mesa/drivers/dri/i965/Makefile.am
>> index 4b009770ab..92cb5b5ba0 100644
>> --- a/src/mesa/drivers/dri/i965/Makefile.am
>> +++ b/src/mesa/drivers/dri/i965/Makefile.am
>> @@ -45,6 +45,7 @@ AM_CFLAGS = \
>>
>>  AM_CXXFLAGS = $(AM_CFLAGS)
>>
>> +MKDIR_GEN = $(AM_V_at)$(MKDIR_P) $(@D)
>>  brw_nir_trig_workarounds.c: brw_nir_trig_workarounds.py 
>> $(top_srcdir)/src/compiler/nir/nir_algebraic.py
>>   $(MKDIR_GEN)
>>   $(AM_V_GEN) PYTHONPATH=$(top_srcdir)/src/compiler/nir $(PYTHON2) 
>> $(PYTHON_FLAGS) $(srcdir)/brw_nir_trig_workarounds.py > $@ || ($(RM) $@; 
>> false)
>>
>
> autotools...where making a directory requires piles of hacks... :/
>
Fwiw newer versions do implicitly create such folders, so it's getting there ;-)

If anyone can skim through the series that will be appreciated. I
would like to push the lot (in ~3 days or so) and mark this type of
issue as "fixed throughout".

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