date:20170628

Re: [Mesa-dev] [PATCH] i965: skip varyings without slot

2017-06-28 Thread Timothy Arceri


On 27/06/17 21:20, Juan A. Suarez Romero wrote:

On Tue, 2017-06-27 at 09:29 +1000, Timothy Arceri wrote:

On 16/06/17 18:12, Juan A. Suarez Romero wrote:


Commit 00620782c9 (i965: use nir_shader_gather_info() over
do_set_program_inouts()) changed how we compute the outputs written.

In the previous version it was using the IR declared outputs, while in
the new one it uses NIR to parse the instructions that write outputs.

Thus, if the shader has declared some output that is not written later
in the code, like this:

~~~
struct S {
  vec4 a;
  vec4 b;
  vec4 c;
};

layout (xfb_offset = sizeof_type) out S s;

void main()
{

  s.a = vec4(1.0, 0.0, 0.0, 1.0);
  s.c = vec4(0.0, 1.0, 0.0, 1.0);
}
~~~

The former version computing 3 outputs written (s.a, s.b and s.c), while
the new version only counts 2 (s.a and s.c).

This means that with the new version, then could be varyings in the VUE
map that do not have an slot assigned (s.b), that must be skipped.

This fixes KHR-GL45.enhanced_layouts.xfb_capture_struct.
---
   src/mesa/drivers/dri/i965/genX_state_upload.c | 5 +++--
   1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/genX_state_upload.c 
b/src/mesa/drivers/dri/i965/genX_state_upload.c
index a5ad2ca..573f0e3 100644
--- a/src/mesa/drivers/dri/i965/genX_state_upload.c
+++ b/src/mesa/drivers/dri/i965/genX_state_upload.c
@@ -3102,9 +3102,10 @@ genX(upload_3dstate_so_decl_list)(struct brw_context 
*brw,
 const unsigned stream_id = output->StreamId;
 assert(stream_id < MAX_VERTEX_STREAMS);
   
-  buffer_mask[stream_id] |= 1 << buffer;

+  if (vue_map->varying_to_slot[varying] == -1)
+ continue;
   
-  assert(vue_map->varying_to_slot[varying] >= 0);

+  buffer_mask[stream_id] |= 1 << buffer;
   


My feeling is we should try to avoid adding it to the VUE map in the
first place rather than trying to work around it.



It isn't in the VUE map. That's the reason to skip it.

Maybe you mean not adding it in the linked_xfb_info?


oh, right. I had it the wrong way around in my head.

I think the problem is we setup xfb in the glsl linker but then run all 
the NIR optimisation before calling nir_shader_gather_info().


However I'm not sure removing the assert is the best idea, as it could 
result in real issues being hidden.


Ideally we would run the NIR opts before we do the final linking in GLSL 
IR. I've outlined how this can be done in past emails (which I can't 
seem to find), but its a lot of work. Nicolai's spirv might make is 
easier to do, but there will still be things like a nir varying packing 
pass required which I believe will be outside of what Nicolai needs for 
his changes.


For now I believe this issue only impacts debug builds so I'm not sure 
removing the assert and silently skipping is a good idea.


I'll let others comment further.



J.A.




Is it not possible to do that instead?



 /* Mesa doesn't store entries for gl_SkipComponents in the Outputs[]
  * array.  Instead, it simply increments DstOffset for the following




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

[Mesa-dev] [PATCH v1 2/3] gallium/hud: Prevent buffer overflow in hud_thread_counter_install

2017-06-28 Thread Robert Foss

Switch to using strncopy to avoid potential overflow of
name array in struct hud_graph.

Coverity-id: 1413761

Signed-off-by: Robert Foss 
---
 src/gallium/auxiliary/hud/hud_cpu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/auxiliary/hud/hud_cpu.c 
b/src/gallium/auxiliary/hud/hud_cpu.c
index 4caaab6977..468c36207b 100644
--- a/src/gallium/auxiliary/hud/hud_cpu.c
+++ b/src/gallium/auxiliary/hud/hud_cpu.c
@@ -362,7 +362,7 @@ void hud_thread_counter_install(struct hud_pane *pane, 
const char *name,
if (!gr)
   return;
 
-   strcpy(gr->name, name);
+   strncpy(gr->name, name, HUD_GRAPH_NAME_LEN);
 
gr->query_data = CALLOC_STRUCT(counter_info);
if (!gr->query_data) {
-- 
2.11.0

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

[Mesa-dev] [PATCH v1 3/3] gallium/hud: Prevent buffer overflow in hud_thread_busy_install

2017-06-28 Thread Robert Foss

Switch to using strncopy to avoid potential overflow of
name array in struct hud_graph.

Coverity-id: 1413760

Signed-off-by: Robert Foss 
---
 src/gallium/auxiliary/hud/hud_cpu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/auxiliary/hud/hud_cpu.c 
b/src/gallium/auxiliary/hud/hud_cpu.c
index 468c36207b..ceadccb377 100644
--- a/src/gallium/auxiliary/hud/hud_cpu.c
+++ b/src/gallium/auxiliary/hud/hud_cpu.c
@@ -288,7 +288,7 @@ hud_thread_busy_install(struct hud_pane *pane, const char 
*name, bool main)
if (!gr)
   return;
 
-   strcpy(gr->name, name);
+   strcpy(gr->name, name, HUD_GRAPH_NAME_LEN);
 
gr->query_data = CALLOC_STRUCT(thread_info);
if (!gr->query_data) {
-- 
2.11.0

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

[Mesa-dev] [PATCH v1 1/3] gallium/hud: Add define for struct hud_graph name array

2017-06-28 Thread Robert Foss

Define the length of the name field of struct hud_graph with
HUD_GRAPH_NAME_LEN.

Signed-off-by: Robert Foss 
---
 src/gallium/auxiliary/hud/hud_private.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/gallium/auxiliary/hud/hud_private.h 
b/src/gallium/auxiliary/hud/hud_private.h
index 2b1717d2c4..3a958d3146 100644
--- a/src/gallium/auxiliary/hud/hud_private.h
+++ b/src/gallium/auxiliary/hud/hud_private.h
@@ -87,6 +87,7 @@ struct hud_context {
bool has_srgb;
 };
 
+#define HUD_GRAPH_NAME_LEN 128
 struct hud_graph {
/* initialized by common code */
struct list_head head;
@@ -95,7 +96,7 @@ struct hud_graph {
float *vertices; /* ring buffer of vertices */
 
/* name and query */
-   char name[128];
+   char name[HUD_GRAPH_NAME_LEN];
void *query_data;
void (*begin_query)(struct hud_graph *gr);
void (*query_new_value)(struct hud_graph *gr);
-- 
2.11.0

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

Re: [Mesa-dev] [PATCH] svga: add texture size/levels sanity check code in svga_texture_create()

2017-06-28 Thread Charmaine Lee


Reviewed-by: Charmaine Lee 


From: Brian Paul 
Sent: Wednesday, June 28, 2017 3:13 PM
To: mesa-dev@lists.freedesktop.org
Cc: Charmaine Lee; Neha Bhende
Subject: [PATCH] svga: add texture size/levels sanity check code in 
svga_texture_create()

The state tracker should never ask us to create a texture with invalid
dimensions / mipmap levels.  Do some assertions to check that.

No Piglit regressions.
---
 src/gallium/drivers/svga/svga_resource_texture.c | 33 
 1 file changed, 33 insertions(+)

diff --git a/src/gallium/drivers/svga/svga_resource_texture.c 
b/src/gallium/drivers/svga/svga_resource_texture.c
index 670100c..84441d1 100644
--- a/src/gallium/drivers/svga/svga_resource_texture.c
+++ b/src/gallium/drivers/svga/svga_resource_texture.c
@@ -916,6 +916,39 @@ svga_texture_create(struct pipe_screen *screen,
   goto fail_notex;
}

+   /* Verify the number of mipmap levels isn't impossibly large.  For example,
+* if the base 2D image is 16x16, we can't have 8 mipmap levels.
+* The state tracker should never ask us to create a resource with invalid
+* parameters.
+*/
+   {
+  unsigned max_dim = template->width0;
+
+  switch (template->target) {
+  case PIPE_TEXTURE_1D:
+  case PIPE_TEXTURE_1D_ARRAY:
+ // nothing
+ break;
+  case PIPE_TEXTURE_2D:
+  case PIPE_TEXTURE_CUBE:
+  case PIPE_TEXTURE_CUBE_ARRAY:
+  case PIPE_TEXTURE_2D_ARRAY:
+ max_dim = MAX2(max_dim, template->height0);
+ break;
+  case PIPE_TEXTURE_3D:
+ max_dim = MAX3(max_dim, template->height0, template->depth0);
+ break;
+  case PIPE_TEXTURE_RECT:
+  case PIPE_BUFFER:
+ assert(template->last_level == 0);
+ /* the assertion below should always pass */
+ break;
+  default:
+ debug_printf("Unexpected texture target type\n");
+  }
+  assert(1 << template->last_level <= max_dim);
+   }
+
tex = CALLOC_STRUCT(svga_texture);
if (!tex) {
   goto fail_notex;
--
1.9.1

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

[Mesa-dev] [Bug 101614] OSMesa 17.1.3 simd16intrin build FAIL on Win/MinGW - 'expected initializer before _simd16_setzero_ps ...'

2017-06-28 Thread bugzilla-daemon

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

--- Comment #7 from Trevor SANDY  ---
You can see in options listing of the logged output I posted all the component
versions of my MSYS/MINGW dev env.

I'm using...
- MSYS bash at /usr/bin
- MSYS python at /usr/bin (#02 below)

For python, be careful. There are 3 instances available for MSYS/MinGW which
can cause the native windows/posix confusion you describe. They are:

1. Native win32 python: From python.org, sys.platform == "win32", os.path.sep
== "", os.name == "nt"
2. MSYS2 python: "msys2/python2" package  installed in /usr/bin/python,
sys.platform == "msys", os.path.sep == "/", os.name == "posix"
3. mingw64 python:  "mingw64/mingw-w64-x86_64-python2" package, installed in
/mingw64/bin/python, sys.platform == "win32", os.path.sep == "/", os.name ==
"nt"

If you use MSYS' package manager to setup your MSYS components, scons will be
in base-devel so it will be deposited in /usr/bin so it will rightly use the
python instance located there also - which happens to be the msys/posix
instance. This instance of python will properly interpret your paths as unix
paths. 

Native windows and mingw64 python will interpret paths as Windows paths. If you
setup MinGW outside of MSYS like it is described here
https://stackoverflow.com/questions/17871781/building-mesa-for-windows-7-mesa-9-1,
your setup will likely not properly interpret unix paths even if you run it
from a MSYS command shell.

-- 
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 5/5] dri3: Use SwapBuffer flips for back- and fake front

2017-06-28 Thread Axel Davy


Hi,

To my knowledge, this is invalid to switch the front fake buffer with 
the back buffer.


The front buffer is supposed to take into account what the app draws 
with the xserver commands, etc.


Plus, if there is draw->width and back->width, I guess they can be 
different size, thus switching may be incorrect relative to buffer size too.


Yours,

Axel Davy

On 22/06/2017 12:42, Thomas Hellstrom wrote:

Use flips for back- and fake front buffers.
This might lead to fake front and real front being shared if the hardware
is page-flip capable.

In any case it will save a full-drawable copy and also the subsequent wait for
the X server to submit that copy to hardware if front-buffer reading or
rendering is enabled.

Signed-off-by: Thomas Hellstrom 
---
  src/loader/loader_dri3_helper.c | 26 --
  1 file changed, 8 insertions(+), 18 deletions(-)

diff --git a/src/loader/loader_dri3_helper.c b/src/loader/loader_dri3_helper.c
index f012e55..041bfc4 100644
--- a/src/loader/loader_dri3_helper.c
+++ b/src/loader/loader_dri3_helper.c
@@ -652,14 +652,14 @@ loader_dri3_swap_buffers_msc(struct loader_dri3_drawable 
*draw,
back->height,
0, 0, back->width,
back->height, __BLIT_FLAG_FLUSH);
-  /* Update the fake front */
-  if (draw->have_fake_front)
- draw->ext->image->blitImage(dri_context,
- 
draw->buffers[LOADER_DRI3_FRONT_ID]->image,
- back->image,
- 0, 0, draw->width, draw->height,
- 0, 0, draw->width, draw->height,
- __BLIT_FLAG_FLUSH);
+   }
+
+   if (back && draw->have_fake_front) {
+  struct loader_dri3_buffer *tmp;
+
+  tmp = dri3_fake_front_buffer(draw);
+  draw->buffers[LOADER_DRI3_FRONT_ID] = back;
+  draw->buffers[LOADER_DRI3_BACK_ID(draw->cur_back)] = tmp;
 }
  
 dri3_flush_present_events(draw);

@@ -727,16 +727,6 @@ loader_dri3_swap_buffers_msc(struct loader_dri3_drawable 
*draw,
 * to reset the fence and make future users block until
 * the X server is done copying the bits
 */
-  if (draw->have_fake_front && !draw->is_different_gpu) {
- dri3_fence_reset(draw->conn, draw->buffers[LOADER_DRI3_FRONT_ID]);
- dri3_copy_area(draw->conn,
-back->pixmap,
-draw->buffers[LOADER_DRI3_FRONT_ID]->pixmap,
-dri3_drawable_gc(draw),
-0, 0, 0, 0,
-draw->width, draw->height);
- dri3_fence_trigger(draw->conn, draw->buffers[LOADER_DRI3_FRONT_ID]);
-  }
xcb_flush(draw->conn);
if (draw->stamp)
   ++(*draw->stamp);



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

[Mesa-dev] OSMesa 17.1.3 simd16intrin build FAIL on Win/MinGW - 'expected initializer before _simd16_setzero_ps ...'

2017-06-28 Thread Trevor Sandy

Please help ! My mesa build consistently fails with starting with this log
trace:

src/gallium/drivers/swr/rasterizer/common/simd16intrin.h:127:35: *error*:
expected initializer before '_simd16_setzero_ps'
SIMD16_EMU_AVX512_0(simd16scalar, _simd16_setzero_ps, _mm256_setzero_ps).
Builds on Linux and OSX are unaffected.

You can see a detailed log output for Mesa *17.1.3* at
https://gist.github.com/trevorsandy/0f8f83a9f8963911d5a42f8723c772fb and
the same
for *17.1.2* at
https://gist.github.com/trevorsandy/69d22f8a0ceeafe298baba9587cd37e9

I have been chasing this issue for the past week without success. I've read
the content at Mesa3D.org and search across the mail archives. I've also
followed the documented dev env requirements.

The gist URLs above provide a detailed capture of the installation output -
based on this customized install script.
https://github.com/trevorsandy/osmesa-install/blob/master/osmesa-install.sh.

Here is the initial options section logged output for Mesa 17.1.3:

Mesa build options for platform MINGW64_NT-10.0:
- build date: 28/06/2017 01:15:39
- release, non-debug build
- non-mangled
- swr Gallium renderer
- reuse built source at rebuild
- build llvm: No (Note: using llvm version 4.0.0 already built successfully)
- mesa version: 17.1.3
- osmesa prefix: /opt/osmesa
- glu version: 9.0.0
- execute osmesa demo: No
- CC: gcc
- CXX: g++
- CFLAGS: -O3
- CXXFLAGS: -O3
- msys version: 2017.05-1
- mingw version: 2.28-1
- gcc version: 6.3.0-1
- cmake version: 3.8.1-3
- scons version: 2.5.1-1
- bison/yacc version: 3.0.4-1
- python2 version: 2.7.13-1
- python2-mako version: 1.0.6-2
- libxml2 version: 2.9.2-3
- silent logging
- log file: /home/Trevor/Projects/osmesa-install/osmesa-install_27.log
* extracting Mesa...
* applying patches...
* applying patch add_pi.patch...
(Stripping trailing CRs from patch; use --binary to disable.)
patching file src/compiler/glsl/builtin_functions.cpp
Hunk #1 succeeded at 84 with fuzz 2 (offset 22 lines).
* applying patch gallium-osmesa-threadsafe.patch...
(Stripping trailing CRs from patch; use --binary to disable.)
patching file src/gallium/state_trackers/osmesa/osmesa.c
Hunk #16 succeeded at 881 (offset -1 lines).
* applying patch install-GL-headers.patch...
...

Many thanks in advance.

Cheers,

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

Re: [Mesa-dev] [PATCH 5/5] dri3: Use SwapBuffer flips for back- and fake front

2017-06-28 Thread Axel Davy


On 28/06/2017 20:40, Thomas Hellstrom wrote:

On 06/28/2017 07:36 PM, Axel Davy wrote:

Hi,

To my knowledge, this is invalid to switch the front fake buffer with 
the back buffer.


The front buffer is supposed to take into account what the app draws 
with the xserver commands, etc.


SwapBuffers should bring the contents of the back buffer to the front 
(and fake front if applicable) buffer, and the backbuffer contents 
become undefined, or tagged with a certain age. None of this is 
violated here. The old back buffer will become the new fake front and 
appropriately synced with X rendering as needed.


Is there a specific scenario you are concerned with?


When I investigated the use of front buffer when writing the patch to 
add secondary gpu support, I understood almost all apps don't use front 
buffer at all, but when they do, it's to interact with the real content 
displayed to the user, which can see some modifications.






Plus, if there is draw->width and back->width, I guess they can be 
different size, thus switching may be incorrect relative to buffer 
size too.


Fake front and back are resized at the same time with dri3 AFAICT. 
This means that with respect to dimensions, the new code should be 
equivalent to the old one.
I don't remember the code enough to remember if and why the sizes can be 
different.


Thanks,

Thomas




Yours,


Axel Davy

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

[Mesa-dev] [PATCH 4/5] vc4: Use vc4_setup_slices for resource import

2017-06-28 Thread Eric Anholt

Rather than open-coding populating the first slice inside resource
import, use vc4_setup_slices to do it for us.

v2: Rebase on VC4_DEBUG=surf change
---
 src/gallium/drivers/vc4/vc4_resource.c | 52 +-
 1 file changed, 19 insertions(+), 33 deletions(-)

diff --git a/src/gallium/drivers/vc4/vc4_resource.c 
b/src/gallium/drivers/vc4/vc4_resource.c
index dd34dadf2af8..304ca600f0ea 100644
--- a/src/gallium/drivers/vc4/vc4_resource.c
+++ b/src/gallium/drivers/vc4/vc4_resource.c
@@ -425,7 +425,7 @@ vc4_resource_get_handle(struct pipe_screen *pscreen,
 }
 
 static void
-vc4_setup_slices(struct vc4_resource *rsc)
+vc4_setup_slices(struct vc4_resource *rsc, const char *caller)
 {
 struct pipe_resource *prsc = >base;
 uint32_t width = prsc->width0;
@@ -491,9 +491,9 @@ vc4_setup_slices(struct vc4_resource *rsc)
 [VC4_TILING_FORMAT_T] = 'T'
 };
 fprintf(stderr,
-"rsc setup %p (format %s: vc4 %d), %dx%d: "
+"rsc %s %p (format %s: vc4 %d), %dx%d: "
 "level %d (%c) -> %dx%d, stride %d@0x%08x\n",
-rsc,
+caller, rsc,
 util_format_short_name(prsc->format),
 rsc->vc4_format,
 prsc->width0, prsc->height0,
@@ -590,7 +590,7 @@ vc4_resource_create(struct pipe_screen *pscreen,
 if (tmpl->target != PIPE_BUFFER)
 rsc->vc4_format = get_resource_texture_format(prsc);
 
-vc4_setup_slices(rsc);
+vc4_setup_slices(rsc, "create");
 if (!vc4_resource_bo_alloc(rsc))
 goto fail;
 
@@ -617,29 +617,10 @@ vc4_resource_from_handle(struct pipe_screen *pscreen,
 struct vc4_resource *rsc = vc4_resource_setup(pscreen, tmpl);
 struct pipe_resource *prsc = >base;
 struct vc4_resource_slice *slice = >slices[0];
-uint32_t expected_stride =
-align(prsc->width0, vc4_utile_width(rsc->cpp)) * rsc->cpp;
 
 if (!rsc)
 return NULL;
 
-if (whandle->stride != expected_stride) {
-static bool warned = false;
-if (!warned) {
-warned = true;
-fprintf(stderr,
-"Attempting to import %dx%d %s with "
-"unsupported stride %d instead of %d\n",
-prsc->width0, prsc->height0,
-util_format_short_name(prsc->format),
-whandle->stride,
-expected_stride);
-}
-goto fail;
-}
-
-rsc->tiled = false;
-
 if (whandle->offset != 0) {
 fprintf(stderr,
 "Attempt to import unsupported winsys offset %u\n",
@@ -665,10 +646,9 @@ vc4_resource_from_handle(struct pipe_screen *pscreen,
 if (!rsc->bo)
 goto fail;
 
-slice->stride = whandle->stride;
-slice->tiling = VC4_TILING_FORMAT_LINEAR;
-
+rsc->tiled = false;
 rsc->vc4_format = get_resource_texture_format(prsc);
+vc4_setup_slices(rsc, "import");
 
 if (screen->ro) {
 /* Make sure that renderonly has a handle to our buffer in the
@@ -682,13 +662,19 @@ vc4_resource_from_handle(struct pipe_screen *pscreen,
 goto fail;
 }
 
-if (vc4_debug & VC4_DEBUG_SURFACE) {
-fprintf(stderr,
-"rsc import %p (format %d), %dx%d: "
-"level 0 (R) -> stride %d@0x%08x\n",
-rsc, rsc->vc4_format,
-prsc->width0, prsc->height0,
-slice->stride, slice->offset);
+if (whandle->stride != slice->stride) {
+static bool warned = false;
+if (!warned) {
+warned = true;
+fprintf(stderr,
+"Attempting to import %dx%d %s with "
+"unsupported stride %d instead of %d\n",
+prsc->width0, prsc->height0,
+util_format_short_name(prsc->format),
+whandle->stride,
+slice->stride);
+}
+goto fail;
 }
 
 return prsc;
-- 
2.11.0

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

[Mesa-dev] [PATCH 1/5] intel: Move the DRM uapi headers to a non-Intel location.

2017-06-28 Thread Eric Anholt

I want to remove vc4's dependency on headers from libdrm as well, but
storing multiple copies of drm_fourcc.h in our tree would be silly.
---
 {src/intel/drm => include/drm-uapi}/README   | 0
 {src/intel/drm => include/drm-uapi}/drm.h| 0
 {src/intel/drm => include/drm-uapi}/drm_fourcc.h | 0
 {src/intel/drm => include/drm-uapi}/drm_mode.h   | 0
 {src/intel/drm => include/drm-uapi}/i915_drm.h   | 0
 src/intel/Makefile.vulkan.am | 2 +-
 src/mesa/drivers/dri/i965/Makefile.am| 2 +-
 7 files changed, 2 insertions(+), 2 deletions(-)
 rename {src/intel/drm => include/drm-uapi}/README (100%)
 rename {src/intel/drm => include/drm-uapi}/drm.h (100%)
 rename {src/intel/drm => include/drm-uapi}/drm_fourcc.h (100%)
 rename {src/intel/drm => include/drm-uapi}/drm_mode.h (100%)
 rename {src/intel/drm => include/drm-uapi}/i915_drm.h (100%)

diff --git a/src/intel/drm/README b/include/drm-uapi/README
similarity index 100%
rename from src/intel/drm/README
rename to include/drm-uapi/README
diff --git a/src/intel/drm/drm.h b/include/drm-uapi/drm.h
similarity index 100%
rename from src/intel/drm/drm.h
rename to include/drm-uapi/drm.h
diff --git a/src/intel/drm/drm_fourcc.h b/include/drm-uapi/drm_fourcc.h
similarity index 100%
rename from src/intel/drm/drm_fourcc.h
rename to include/drm-uapi/drm_fourcc.h
diff --git a/src/intel/drm/drm_mode.h b/include/drm-uapi/drm_mode.h
similarity index 100%
rename from src/intel/drm/drm_mode.h
rename to include/drm-uapi/drm_mode.h
diff --git a/src/intel/drm/i915_drm.h b/include/drm-uapi/i915_drm.h
similarity index 100%
rename from src/intel/drm/i915_drm.h
rename to include/drm-uapi/i915_drm.h
diff --git a/src/intel/Makefile.vulkan.am b/src/intel/Makefile.vulkan.am
index 3857a5dc628b..6550f6846f3b 100644
--- a/src/intel/Makefile.vulkan.am
+++ b/src/intel/Makefile.vulkan.am
@@ -84,7 +84,7 @@ VULKAN_CFLAGS = \
 VULKAN_CPPFLAGS = \
-I$(top_srcdir)/src/compiler \
-I$(top_srcdir)/src/intel/compiler \
-   -I$(top_srcdir)/src/intel/drm \
+   -I$(top_srcdir)/include/drm-uapi \
-I$(top_builddir)/src/intel/vulkan \
-I$(top_srcdir)/src/intel/vulkan \
-I$(top_srcdir)/src/vulkan/wsi \
diff --git a/src/mesa/drivers/dri/i965/Makefile.am 
b/src/mesa/drivers/dri/i965/Makefile.am
index 4b56b4b0efec..ecc1e766f11c 100644
--- a/src/mesa/drivers/dri/i965/Makefile.am
+++ b/src/mesa/drivers/dri/i965/Makefile.am
@@ -38,7 +38,7 @@ AM_CFLAGS = \
-I$(top_srcdir)/src/compiler/nir \
-I$(top_builddir)/src/intel \
-I$(top_srcdir)/src/intel \
-   -I$(top_srcdir)/src/intel/drm \
+   -I$(top_srcdir)/include/drm-uapi \
$(DEFINES) \
$(VISIBILITY_CFLAGS) \
$(LIBDRM_CFLAGS) \
-- 
2.11.0

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

[Mesa-dev] [PATCH 2/5] vc4: Switch back to using a local copy of vc4_drm.h.

2017-06-28 Thread Eric Anholt

Needing to get our uapi header from libdrm has only complicated things.
Follow intel's lead and drop our requirement for it.

Generated from the same commit mentioned in the README.
---
 configure.ac |   2 -
 include/drm-uapi/vc4_drm.h   | 318 +++
 src/gallium/drivers/vc4/Makefile.am  |   4 +-
 src/gallium/drivers/vc4/Makefile.sources |   1 +
 4 files changed, 321 insertions(+), 4 deletions(-)
 create mode 100644 include/drm-uapi/vc4_drm.h

diff --git a/configure.ac b/configure.ac
index 7fade23b6af6..bb90a63edf23 100644
--- a/configure.ac
+++ b/configure.ac
@@ -79,7 +79,6 @@ LIBDRM_INTEL_REQUIRED=2.4.75
 LIBDRM_NVVIEUX_REQUIRED=2.4.66
 LIBDRM_NOUVEAU_REQUIRED=2.4.66
 LIBDRM_FREEDRENO_REQUIRED=2.4.74
-LIBDRM_VC4_REQUIRED=2.4.69
 LIBDRM_ETNAVIV_REQUIRED=2.4.80
 
 dnl Versions for external dependencies
@@ -2503,7 +2502,6 @@ if test -n "$with_gallium_drivers"; then
 ;;
 xvc4)
 HAVE_GALLIUM_VC4=yes
-PKG_CHECK_MODULES([VC4], [libdrm >= $LIBDRM_VC4_REQUIRED 
libdrm_vc4 >= $LIBDRM_VC4_REQUIRED])
 require_libdrm "vc4"
 
 PKG_CHECK_MODULES([SIMPENROSE], [simpenrose],
diff --git a/include/drm-uapi/vc4_drm.h b/include/drm-uapi/vc4_drm.h
new file mode 100644
index ..0caeaf3a1f24
--- /dev/null
+++ b/include/drm-uapi/vc4_drm.h
@@ -0,0 +1,318 @@
+/*
+ * Copyright © 2014-2015 Broadcom
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#ifndef _VC4_DRM_H_
+#define _VC4_DRM_H_
+
+#include "drm.h"
+
+#if defined(__cplusplus)
+extern "C" {
+#endif
+
+#define DRM_VC4_SUBMIT_CL 0x00
+#define DRM_VC4_WAIT_SEQNO0x01
+#define DRM_VC4_WAIT_BO   0x02
+#define DRM_VC4_CREATE_BO 0x03
+#define DRM_VC4_MMAP_BO   0x04
+#define DRM_VC4_CREATE_SHADER_BO  0x05
+#define DRM_VC4_GET_HANG_STATE0x06
+#define DRM_VC4_GET_PARAM 0x07
+#define DRM_VC4_SET_TILING0x08
+#define DRM_VC4_GET_TILING0x09
+
+#define DRM_IOCTL_VC4_SUBMIT_CL   DRM_IOWR(DRM_COMMAND_BASE + 
DRM_VC4_SUBMIT_CL, struct drm_vc4_submit_cl)
+#define DRM_IOCTL_VC4_WAIT_SEQNO  DRM_IOWR(DRM_COMMAND_BASE + 
DRM_VC4_WAIT_SEQNO, struct drm_vc4_wait_seqno)
+#define DRM_IOCTL_VC4_WAIT_BO DRM_IOWR(DRM_COMMAND_BASE + 
DRM_VC4_WAIT_BO, struct drm_vc4_wait_bo)
+#define DRM_IOCTL_VC4_CREATE_BO   DRM_IOWR(DRM_COMMAND_BASE + 
DRM_VC4_CREATE_BO, struct drm_vc4_create_bo)
+#define DRM_IOCTL_VC4_MMAP_BO DRM_IOWR(DRM_COMMAND_BASE + 
DRM_VC4_MMAP_BO, struct drm_vc4_mmap_bo)
+#define DRM_IOCTL_VC4_CREATE_SHADER_BODRM_IOWR(DRM_COMMAND_BASE + 
DRM_VC4_CREATE_SHADER_BO, struct drm_vc4_create_shader_bo)
+#define DRM_IOCTL_VC4_GET_HANG_STATE  DRM_IOWR(DRM_COMMAND_BASE + 
DRM_VC4_GET_HANG_STATE, struct drm_vc4_get_hang_state)
+#define DRM_IOCTL_VC4_GET_PARAM   DRM_IOWR(DRM_COMMAND_BASE + 
DRM_VC4_GET_PARAM, struct drm_vc4_get_param)
+#define DRM_IOCTL_VC4_SET_TILING  DRM_IOWR(DRM_COMMAND_BASE + 
DRM_VC4_SET_TILING, struct drm_vc4_set_tiling)
+#define DRM_IOCTL_VC4_GET_TILING  DRM_IOWR(DRM_COMMAND_BASE + 
DRM_VC4_GET_TILING, struct drm_vc4_get_tiling)
+
+struct drm_vc4_submit_rcl_surface {
+   __u32 hindex; /* Handle index, or ~0 if not present. */
+   __u32 offset; /* Offset to start of buffer. */
+   /*
+* Bits for either render config (color_write) or load/store packet.
+* Bits should all be 0 for MSAA load/stores.
+*/
+   __u16 bits;
+
+#define VC4_SUBMIT_RCL_SURFACE_READ_IS_FULL_RES(1 << 0)
+   __u16 flags;
+};
+
+/**
+ * struct drm_vc4_submit_cl - ioctl argument for submitting commands to the 3D
+ * engine.
+ *
+ * Drivers

[Mesa-dev] [PATCH 5/5] vc4: Set shareable BOs as T tiled if possible

2017-06-28 Thread Eric Anholt

X11 and GL compositor performance on VC4 has been terrible because of our
SHARED-usage buffers all being forced to linear.  This swaps SHARED &&
!LINEAR buffers over to being tiled.

This is an expected win for all GL compositors during rendering (a full
copy of each shared texture per draw call), allows X11 to be used with
decent performance without a GL compositor, and improves X11 windowed
swapbuffers performance as well.  It also halves the memory usage of
shared buffers that get textured from.  The only cost should be idle
systems with a scanout-only buffer that isn't flagged as LINEAR, in which
case the memory bandwidth cost of scanout goes up ~25%.

This implements the EGL_EXT_image_dma_buf_import_modifiers extension,
supporting the VC4 T_TILED modifier.

v2: Added modifier support to resource creation/import, and
advertisement (by daniels).
v3: Fix old-kernel fallback path, fix compiler error and warnings, and
comment touchups (by anholt).

Reviewed-by: Daniel Stone 
---
 src/gallium/drivers/vc4/vc4_resource.c  | 157 +---
 src/gallium/drivers/vc4/vc4_screen.c|  30 ++
 src/gallium/drivers/vc4/vc4_screen.h|   1 +
 src/gallium/drivers/vc4/vc4_simulator.c |   7 ++
 4 files changed, 182 insertions(+), 13 deletions(-)

diff --git a/src/gallium/drivers/vc4/vc4_resource.c 
b/src/gallium/drivers/vc4/vc4_resource.c
index 304ca600f0ea..b2cd49d27294 100644
--- a/src/gallium/drivers/vc4/vc4_resource.c
+++ b/src/gallium/drivers/vc4/vc4_resource.c
@@ -29,11 +29,17 @@
 #include "util/u_surface.h"
 #include "util/u_upload_mgr.h"
 
+#include "drm_fourcc.h"
+#include "vc4_drm.h"
 #include "vc4_screen.h"
 #include "vc4_context.h"
 #include "vc4_resource.h"
 #include "vc4_tiling.h"
 
+#ifndef DRM_FORMAT_MOD_INVALID
+#define DRM_FORMAT_MOD_INVALID ((1ULL << 56) - 1)
+#endif
+
 static bool
 vc4_resource_bo_alloc(struct vc4_resource *rsc)
 {
@@ -391,6 +397,7 @@ vc4_resource_get_handle(struct pipe_screen *pscreen,
 struct vc4_resource *rsc = vc4_resource(prsc);
 
 whandle->stride = rsc->slices[0].stride;
+whandle->offset = 0;
 
 /* If we're passing some reference to our BO out to some other part of
  * the system, then we can't do any optimizations about only us being
@@ -398,6 +405,11 @@ vc4_resource_get_handle(struct pipe_screen *pscreen,
  */
 rsc->bo->private = false;
 
+if (rsc->tiled)
+whandle->modifier = DRM_FORMAT_MOD_BROADCOM_VC4_T_TILED;
+else
+whandle->modifier = DRM_FORMAT_MOD_LINEAR;
+
 switch (whandle->type) {
 case DRM_API_HANDLE_TYPE_SHARED:
 if (screen->ro) {
@@ -565,26 +577,77 @@ get_resource_texture_format(struct pipe_resource *prsc)
 return format;
 }
 
-struct pipe_resource *
-vc4_resource_create(struct pipe_screen *pscreen,
-const struct pipe_resource *tmpl)
+static bool
+find_modifier(uint64_t needle, const uint64_t *haystack, int count)
+{
+int i;
+
+for (i = 0; i < count; i++) {
+if (haystack[i] == needle)
+return true;
+}
+
+return false;
+}
+
+static struct pipe_resource *
+vc4_resource_create_with_modifiers(struct pipe_screen *pscreen,
+   const struct pipe_resource *tmpl,
+   const uint64_t *modifiers,
+   int count)
 {
 struct vc4_screen *screen = vc4_screen(pscreen);
 struct vc4_resource *rsc = vc4_resource_setup(pscreen, tmpl);
 struct pipe_resource *prsc = >base;
+bool linear_ok = find_modifier(DRM_FORMAT_MOD_LINEAR, modifiers, 
count);
+/* Use a tiled layout if we can, for better 3D performance. */
+bool should_tile = true;
 
-/* We have to make shared be untiled, since we don't have any way to
- * communicate metadata about tiling currently.
+/* VBOs/PBOs are untiled (and 1 height). */
+if (tmpl->target == PIPE_BUFFER)
+should_tile = false;
+
+/* MSAA buffers are linear. */
+if (tmpl->nr_samples > 1)
+should_tile = false;
+
+/* No tiling when we're sharing with another device (pl111). */
+if (screen->ro && (tmpl->bind & PIPE_BIND_SCANOUT))
+should_tile = false;
+
+/* Cursors are always linear, and the user can request linear as well.
+ */
+if (tmpl->bind & (PIPE_BIND_LINEAR | PIPE_BIND_CURSOR))
+should_tile = false;
+
+/* No shared objects with LT format -- the kernel only has T-format
+ * metadata.  LT objects are small enough it's not worth the trouble to
+ * give them metadata to tile.
+ */
+if ((tmpl->bind & (PIPE_BIND_SHARED | PIPE_BIND_SCANOUT)) &&
+vc4_size_is_lt(prsc->width0, prsc->height0, rsc->cpp))
+should_tile =

[Mesa-dev] [PATCH 3/5] vc4: Make the miptree debug code available under VC4_DEBUG=surf

2017-06-28 Thread Eric Anholt

I kept flipping the bool on for debug, so let's just make it available.
---
 src/gallium/drivers/vc4/vc4_resource.c | 8 +++-
 src/gallium/drivers/vc4/vc4_screen.c   | 2 ++
 src/gallium/drivers/vc4/vc4_screen.h   | 1 +
 3 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/src/gallium/drivers/vc4/vc4_resource.c 
b/src/gallium/drivers/vc4/vc4_resource.c
index 5aaa31d6e67d..dd34dadf2af8 100644
--- a/src/gallium/drivers/vc4/vc4_resource.c
+++ b/src/gallium/drivers/vc4/vc4_resource.c
@@ -34,8 +34,6 @@
 #include "vc4_resource.h"
 #include "vc4_tiling.h"
 
-static bool miptree_debug = false;
-
 static bool
 vc4_resource_bo_alloc(struct vc4_resource *rsc)
 {
@@ -43,7 +41,7 @@ vc4_resource_bo_alloc(struct vc4_resource *rsc)
 struct pipe_screen *pscreen = prsc->screen;
 struct vc4_bo *bo;
 
-if (miptree_debug) {
+if (vc4_debug & VC4_DEBUG_SURFACE) {
 fprintf(stderr, "alloc %p: size %d + offset %d -> %d\n",
 rsc,
 rsc->slices[0].size,
@@ -486,7 +484,7 @@ vc4_setup_slices(struct vc4_resource *rsc)
 
 offset += slice->size;
 
-if (miptree_debug) {
+if (vc4_debug & VC4_DEBUG_SURFACE) {
 static const char tiling_chars[] = {
 [VC4_TILING_FORMAT_LINEAR] = 'R',
 [VC4_TILING_FORMAT_LT] = 'L',
@@ -684,7 +682,7 @@ vc4_resource_from_handle(struct pipe_screen *pscreen,
 goto fail;
 }
 
-if (miptree_debug) {
+if (vc4_debug & VC4_DEBUG_SURFACE) {
 fprintf(stderr,
 "rsc import %p (format %d), %dx%d: "
 "level 0 (R) -> stride %d@0x%08x\n",
diff --git a/src/gallium/drivers/vc4/vc4_screen.c 
b/src/gallium/drivers/vc4/vc4_screen.c
index cbeb6830deb7..07395487d776 100644
--- a/src/gallium/drivers/vc4/vc4_screen.c
+++ b/src/gallium/drivers/vc4/vc4_screen.c
@@ -43,6 +43,8 @@
 static const struct debug_named_value debug_options[] = {
 { "cl",   VC4_DEBUG_CL,
   "Dump command list during creation" },
+{ "surf",   VC4_DEBUG_SURFACE,
+  "Dump surface layouts" },
 { "qpu",  VC4_DEBUG_QPU,
   "Dump generated QPU instructions" },
 { "qir",  VC4_DEBUG_QIR,
diff --git a/src/gallium/drivers/vc4/vc4_screen.h 
b/src/gallium/drivers/vc4/vc4_screen.h
index 295633db4695..7887adee9418 100644
--- a/src/gallium/drivers/vc4/vc4_screen.h
+++ b/src/gallium/drivers/vc4/vc4_screen.h
@@ -48,6 +48,7 @@ struct vc4_bo;
 #define VC4_DEBUG_ALWAYS_SYNC  0x0100
 #define VC4_DEBUG_NIR   0x0200
 #define VC4_DEBUG_DUMP  0x0400
+#define VC4_DEBUG_SURFACE   0x0800
 
 #define VC4_MAX_MIP_LEVELS 12
 #define VC4_MAX_TEXTURE_SAMPLERS 16
-- 
2.11.0

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

[Mesa-dev] [PATCH] android: anv: drop libdrm_intel dependency

2017-06-28 Thread Mauro Rossi

In addition to Rob Herring "Android: i965: remove libdrm_intel dependency",
we can drop libdrm_intel dependency in anv for Android.

Please check if libdrm has to stay as shared dependency and drop this comment 
line.

Fixes: 7dd20bc ("anv/i965: drop libdrm_intel dependency completely")
---
 src/intel/Android.vulkan.mk  |  3 ++-
 1 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/intel/Android.vulkan.mk b/src/intel/Android.vulkan.mk
index 095a75bbd4..8f8366aa7f 100644
--- a/src/intel/Android.vulkan.mk
+++ b/src/intel/Android.vulkan.mk
@@ -33,6 +33,7 @@ VULKAN_COMMON_INCLUDES := \
$(MESA_TOP)/src/vulkan/wsi \
$(MESA_TOP)/src/vulkan/util \
$(MESA_TOP)/src/intel \
+   $(MESA_TOP)/src/intel/drm \
$(MESA_TOP)/src/intel/vulkan
 
 # libmesa_anv_entrypoints with header and dummy.c
@@ -93,7 +94,7 @@ LOCAL_C_INCLUDES := $(ANV_INCLUDES)
 
 LOCAL_WHOLE_STATIC_LIBRARIES := libmesa_anv_entrypoints libmesa_genxml
 
-LOCAL_SHARED_LIBRARIES := libdrm_intel
+LOCAL_SHARED_LIBRARIES := libdrm
 
 include $(MESA_COMMON_MK)
 include $(BUILD_STATIC_LIBRARY)
-- 
2.11.0

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

Re: [Mesa-dev] [PATCH] svga: update a few surface format names

2017-06-28 Thread Neha Bhende

Looks good to me.


Reviewed-by:  Neha Bhende


Regards,

Neha


From: Brian Paul 
Sent: Wednesday, June 28, 2017 3:44:35 PM
To: mesa-dev@lists.freedesktop.org
Cc: Charmaine Lee; Neha Bhende
Subject: [PATCH] svga: update a few surface format names

To sync with in-house changes.
---
 .../drivers/svga/include/svga3d_surfacedefs.h  |  8 +++---
 src/gallium/drivers/svga/include/svga3d_types.h|  8 +++---
 src/gallium/drivers/svga/svga_format.c | 32 +++---
 3 files changed, 24 insertions(+), 24 deletions(-)

diff --git a/src/gallium/drivers/svga/include/svga3d_surfacedefs.h 
b/src/gallium/drivers/svga/include/svga3d_surfacedefs.h
index efa358b..89baff3 100644
--- a/src/gallium/drivers/svga/include/svga3d_surfacedefs.h
+++ b/src/gallium/drivers/svga/include/svga3d_surfacedefs.h
@@ -486,12 +486,12 @@ static const struct svga3d_surface_desc 
svga3d_surface_descs[] = {
   64, {{0}, {8}, {32}, {0}},
   {{0}, {32}, {0}, {0}}},

-   {SVGA3D_R32_FLOAT_X8X24_TYPELESS, SVGA3DBLOCKDESC_R_FP,
+   {SVGA3D_R32_FLOAT_X8X24, SVGA3DBLOCKDESC_R_FP,
   {1, 1, 1},  8, 8,
   64, {{0}, {0}, {32}, {0}},
   {{0}, {0}, {0}, {0}}},

-   {SVGA3D_X32_TYPELESS_G8X24_UINT, SVGA3DBLOCKDESC_GREEN,
+   {SVGA3D_X32_G8X24_UINT, SVGA3DBLOCKDESC_GREEN,
   {1, 1, 1},  8, 8,
   64, {{0}, {8}, {0}, {0}},
   {{0}, {32}, {0}, {0}}},
@@ -581,12 +581,12 @@ static const struct svga3d_surface_desc 
svga3d_surface_descs[] = {
   32, {{0}, {8}, {24}, {0}},
   {{0}, {24}, {0}, {0}}},

-   {SVGA3D_R24_UNORM_X8_TYPELESS, SVGA3DBLOCKDESC_RED,
+   {SVGA3D_R24_UNORM_X8, SVGA3DBLOCKDESC_RED,
   {1, 1, 1},  4, 4,
   32, {{0}, {0}, {24}, {0}},
   {{0}, {0}, {0}, {0}}},

-   {SVGA3D_X24_TYPELESS_G8_UINT, SVGA3DBLOCKDESC_GREEN,
+   {SVGA3D_X24_G8_UINT, SVGA3DBLOCKDESC_GREEN,
   {1, 1, 1},  4, 4,
   32, {{0}, {8}, {0}, {0}},
   {{0}, {24}, {0}, {0}}},
diff --git a/src/gallium/drivers/svga/include/svga3d_types.h 
b/src/gallium/drivers/svga/include/svga3d_types.h
index de711c3..ddd9e35 100644
--- a/src/gallium/drivers/svga/include/svga3d_types.h
+++ b/src/gallium/drivers/svga/include/svga3d_types.h
@@ -204,8 +204,8 @@ typedef enum SVGA3dSurfaceFormat {
SVGA3D_R32G32_SINT  = 59,
SVGA3D_R32G8X24_TYPELESS= 60,
SVGA3D_D32_FLOAT_S8X24_UINT = 61,
-   SVGA3D_R32_FLOAT_X8X24_TYPELESS = 62,
-   SVGA3D_X32_TYPELESS_G8X24_UINT  = 63,
+   SVGA3D_R32_FLOAT_X8X24  = 62,
+   SVGA3D_X32_G8X24_UINT   = 63,
SVGA3D_R10G10B10A2_TYPELESS = 64,
SVGA3D_R10G10B10A2_UINT = 65,
SVGA3D_R11G11B10_FLOAT  = 66,
@@ -223,8 +223,8 @@ typedef enum SVGA3dSurfaceFormat {
SVGA3D_R32_SINT = 78,
SVGA3D_R24G8_TYPELESS   = 79,
SVGA3D_D24_UNORM_S8_UINT= 80,
-   SVGA3D_R24_UNORM_X8_TYPELESS= 81,
-   SVGA3D_X24_TYPELESS_G8_UINT = 82,
+   SVGA3D_R24_UNORM_X8 = 81,
+   SVGA3D_X24_G8_UINT  = 82,
SVGA3D_R8G8_TYPELESS= 83,
SVGA3D_R8G8_UNORM   = 84,
SVGA3D_R8G8_UINT= 85,
diff --git a/src/gallium/drivers/svga/svga_format.c 
b/src/gallium/drivers/svga/svga_format.c
index a914b23..95dd04d 100644
--- a/src/gallium/drivers/svga/svga_format.c
+++ b/src/gallium/drivers/svga/svga_format.c
@@ -530,10 +530,10 @@ struct format_cap {
  * avoid querying the host.  In particular, depth/stencil formats which
  * can be rendered to and sampled from.  For example, the gallium format
  * PIPE_FORMAT_Z24_UNORM_S8_UINT is converted to SVGA3D_D24_UNORM_S8_UINT
- * for rendering but converted to SVGA3D_R24_UNORM_X8_TYPELESS for sampling.
+ * for rendering but converted to SVGA3D_R24_UNORM_X8 for sampling.
  * If we want to query if a format supports both rendering and sampling the
  * host will tell us no for SVGA3D_D24_UNORM_S8_UINT, SVGA3D_D16_UNORM and
- * SVGA3D_R24_UNORM_X8_TYPELESS.  So we override the host query for those
+ * SVGA3D_R24_UNORM_X8.  So we override the host query for those
  * formats and report that both can do rendering and sampling.
  */
 static const struct format_cap format_cap_table[] = {
@@ -1026,8 +1026,8 @@ static const struct format_cap format_cap_table[] = {
{
   /* Special case: no devcap / report sampler and depth/stencil ability
*/
-  "SVGA3D_R32_FLOAT_X8X24_TYPELESS",
-  SVGA3D_R32_FLOAT_X8X24_TYPELESS,
+  "SVGA3D_R32_FLOAT_X8X24",
+  SVGA3D_R32_FLOAT_X8X24,
   0, /*SVGA3D_DEVCAP_DXFMT_R32_FLOAT_X8X24_TYPELESS*/
   1, 1, 8,
   SVGA3DFORMAT_OP_TEXTURE |
@@ -1036,8 +1036,8 @@ static const struct format_cap format_cap_table[] = {
   SVGA3DFORMAT_OP_ZSTENCIL
},
{
-  "SVGA3D_X32_TYPELESS_G8X24_UINT",
-  SVGA3D_X32_TYPELESS_G8X24_UINT,
+  "SVGA3D_X32_G8X24_UINT",
+

[Mesa-dev] [Bug 101614] OSMesa 17.1.3 simd16intrin build FAIL on Win/MinGW - 'expected initializer before _simd16_setzero_ps ...'

2017-06-28 Thread bugzilla-daemon

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

--- Comment #6 from George Kyriazis  ---
I tried compiling just osmesa, but still got the same issue.

I've always had trouble using bash with python on windows (bash from Cygwin).

Regardless of whether I use python from the windows python distribution of
python from Cygwin, I always run into trouble with windows vs linux paths.  If
I use windows python, then bash does not understand the windows paths that
python uses, and if I use the Cygwin python, then scons tries to append windows
paths on top of Cygwin paths.

Which bash and which python are you using?

Thanks!

-- 
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 101614] OSMesa 17.1.3 simd16intrin build FAIL on Win/MinGW - 'expected initializer before _simd16_setzero_ps ...'

2017-06-28 Thread bugzilla-daemon

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

--- Comment #5 from Trevor SANDY  ---
George,

One more point. I did not use the windows command environment. My toolchain is
MSYS2/Mingw64. My command environment is Bash. Looking at your command output,
it looks like you are using mingw64 under the native Windows command
environment ?

-- 
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 101614] OSMesa 17.1.3 simd16intrin build FAIL on Win/MinGW - 'expected initializer before _simd16_setzero_ps ...'

2017-06-28 Thread bugzilla-daemon

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

--- Comment #4 from Trevor SANDY  ---
George,

I haven't personally experienced this error but I did come across it in several
places. In fact, Bug 94072 - error: The command line is too long when building
MESA on Windows with MinGW-W64 I think covers this behaviour.

I likely haven't seen it because I'm only building osmesa - not the full build.
It looks like those experiencing this behaviour are also building libgl-gdi.
Nevertheless, the problem appears to be rooted in SCons which is probably where
the behaviour I'm experiencing is rooted also. I say this because osmesa w/
llvm (swr on Ubuntu Linux 16.04 and llvmpipe on OSX Sierra both run to
completion without issue.

Try your build without libgl-gdi - just osmesa. If you have a MSYS/MinGW env
with the required pre-reqs installed, my script
(https://github.com/trevorsandy/osmesa-install/blob/master/osmesa-install.sh)
automates the build quite nicely. You tweak and run quite efficiently to better
narrow down the cause of failure.

Cheers,

-- 
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 101614] OSMesa 17.1.3 simd16intrin build FAIL on Win/MinGW - 'expected initializer before _simd16_setzero_ps ...'

2017-06-28 Thread bugzilla-daemon

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

George Kyriazis  changed:

   What|Removed |Added

 CC||george.kyria...@intel.com

--- Comment #3 from George Kyriazis  ---
Trevor,

We haven't targeted mingw as a compile platform for windows, yet.  That's not
to say we are not going to, we just haven't gotten to it yet.

The compiler error seems to be in swr proper, meaning that it is not related to
osmesa.  OSMesa should be independent from swr, so if llvmpipe compiles with
osmesa on windows, swr should too.

Having said that, I just tried to compile mesa/swr with mingw64, and I am
having problems, too, but at a different location.  Namely:

C:\Python27\python.exe 'C:\Python27\Scripts\scons.py swr=1 -j 1 build=debug
toolchain=mingw libgl-gdi osmesa
scons: Reading SConscript files ...
Checking for MSVC ...  no
Checking for GCC ...  yes
Checking for Clang ...  no
Checking for win_flex ...  no
Checking for win_bison ...  no
scons: Found LLVM version 3.9
Checking for X11 (x11 xext xdamage >= 1.1 xfixes glproto >= 1.4.13 dri2proto >=
2.8)... no
Checking for XCB (x11-xcb xcb-glx >= 1.8.1 xcb-dri2 >= 1.8)... no
Checking for XF86VIDMODE (xxf86vm)... no
Checking for DRM (libdrm >= 2.4.75)... no
scons: done reading SConscript files.
scons: Building targets ...
  Archiving build\windows-x86_64-debug\mesa\libmesa.a ...
The command line is too long.
scons: *** [build\windows-x86_64-debug\mesa\libmesa.a] Error 1
scons: building terminated because of errors.

Have you hit this?  (that's an incremental build; building with -j 1 after I
hit a compiler error for the full build)

-- 
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] svga: update a few surface format names

2017-06-28 Thread Brian Paul

To sync with in-house changes.
---
 .../drivers/svga/include/svga3d_surfacedefs.h  |  8 +++---
 src/gallium/drivers/svga/include/svga3d_types.h|  8 +++---
 src/gallium/drivers/svga/svga_format.c | 32 +++---
 3 files changed, 24 insertions(+), 24 deletions(-)

diff --git a/src/gallium/drivers/svga/include/svga3d_surfacedefs.h 
b/src/gallium/drivers/svga/include/svga3d_surfacedefs.h
index efa358b..89baff3 100644
--- a/src/gallium/drivers/svga/include/svga3d_surfacedefs.h
+++ b/src/gallium/drivers/svga/include/svga3d_surfacedefs.h
@@ -486,12 +486,12 @@ static const struct svga3d_surface_desc 
svga3d_surface_descs[] = {
   64, {{0}, {8}, {32}, {0}},
   {{0}, {32}, {0}, {0}}},
 
-   {SVGA3D_R32_FLOAT_X8X24_TYPELESS, SVGA3DBLOCKDESC_R_FP,
+   {SVGA3D_R32_FLOAT_X8X24, SVGA3DBLOCKDESC_R_FP,
   {1, 1, 1},  8, 8,
   64, {{0}, {0}, {32}, {0}},
   {{0}, {0}, {0}, {0}}},
 
-   {SVGA3D_X32_TYPELESS_G8X24_UINT, SVGA3DBLOCKDESC_GREEN,
+   {SVGA3D_X32_G8X24_UINT, SVGA3DBLOCKDESC_GREEN,
   {1, 1, 1},  8, 8,
   64, {{0}, {8}, {0}, {0}},
   {{0}, {32}, {0}, {0}}},
@@ -581,12 +581,12 @@ static const struct svga3d_surface_desc 
svga3d_surface_descs[] = {
   32, {{0}, {8}, {24}, {0}},
   {{0}, {24}, {0}, {0}}},
 
-   {SVGA3D_R24_UNORM_X8_TYPELESS, SVGA3DBLOCKDESC_RED,
+   {SVGA3D_R24_UNORM_X8, SVGA3DBLOCKDESC_RED,
   {1, 1, 1},  4, 4,
   32, {{0}, {0}, {24}, {0}},
   {{0}, {0}, {0}, {0}}},
 
-   {SVGA3D_X24_TYPELESS_G8_UINT, SVGA3DBLOCKDESC_GREEN,
+   {SVGA3D_X24_G8_UINT, SVGA3DBLOCKDESC_GREEN,
   {1, 1, 1},  4, 4,
   32, {{0}, {8}, {0}, {0}},
   {{0}, {24}, {0}, {0}}},
diff --git a/src/gallium/drivers/svga/include/svga3d_types.h 
b/src/gallium/drivers/svga/include/svga3d_types.h
index de711c3..ddd9e35 100644
--- a/src/gallium/drivers/svga/include/svga3d_types.h
+++ b/src/gallium/drivers/svga/include/svga3d_types.h
@@ -204,8 +204,8 @@ typedef enum SVGA3dSurfaceFormat {
SVGA3D_R32G32_SINT  = 59,
SVGA3D_R32G8X24_TYPELESS= 60,
SVGA3D_D32_FLOAT_S8X24_UINT = 61,
-   SVGA3D_R32_FLOAT_X8X24_TYPELESS = 62,
-   SVGA3D_X32_TYPELESS_G8X24_UINT  = 63,
+   SVGA3D_R32_FLOAT_X8X24  = 62,
+   SVGA3D_X32_G8X24_UINT   = 63,
SVGA3D_R10G10B10A2_TYPELESS = 64,
SVGA3D_R10G10B10A2_UINT = 65,
SVGA3D_R11G11B10_FLOAT  = 66,
@@ -223,8 +223,8 @@ typedef enum SVGA3dSurfaceFormat {
SVGA3D_R32_SINT = 78,
SVGA3D_R24G8_TYPELESS   = 79,
SVGA3D_D24_UNORM_S8_UINT= 80,
-   SVGA3D_R24_UNORM_X8_TYPELESS= 81,
-   SVGA3D_X24_TYPELESS_G8_UINT = 82,
+   SVGA3D_R24_UNORM_X8 = 81,
+   SVGA3D_X24_G8_UINT  = 82,
SVGA3D_R8G8_TYPELESS= 83,
SVGA3D_R8G8_UNORM   = 84,
SVGA3D_R8G8_UINT= 85,
diff --git a/src/gallium/drivers/svga/svga_format.c 
b/src/gallium/drivers/svga/svga_format.c
index a914b23..95dd04d 100644
--- a/src/gallium/drivers/svga/svga_format.c
+++ b/src/gallium/drivers/svga/svga_format.c
@@ -530,10 +530,10 @@ struct format_cap {
  * avoid querying the host.  In particular, depth/stencil formats which
  * can be rendered to and sampled from.  For example, the gallium format
  * PIPE_FORMAT_Z24_UNORM_S8_UINT is converted to SVGA3D_D24_UNORM_S8_UINT
- * for rendering but converted to SVGA3D_R24_UNORM_X8_TYPELESS for sampling.
+ * for rendering but converted to SVGA3D_R24_UNORM_X8 for sampling.
  * If we want to query if a format supports both rendering and sampling the
  * host will tell us no for SVGA3D_D24_UNORM_S8_UINT, SVGA3D_D16_UNORM and
- * SVGA3D_R24_UNORM_X8_TYPELESS.  So we override the host query for those
+ * SVGA3D_R24_UNORM_X8.  So we override the host query for those
  * formats and report that both can do rendering and sampling.
  */
 static const struct format_cap format_cap_table[] = {
@@ -1026,8 +1026,8 @@ static const struct format_cap format_cap_table[] = {
{
   /* Special case: no devcap / report sampler and depth/stencil ability
*/
-  "SVGA3D_R32_FLOAT_X8X24_TYPELESS",
-  SVGA3D_R32_FLOAT_X8X24_TYPELESS,
+  "SVGA3D_R32_FLOAT_X8X24",
+  SVGA3D_R32_FLOAT_X8X24,
   0, /*SVGA3D_DEVCAP_DXFMT_R32_FLOAT_X8X24_TYPELESS*/
   1, 1, 8,
   SVGA3DFORMAT_OP_TEXTURE |
@@ -1036,8 +1036,8 @@ static const struct format_cap format_cap_table[] = {
   SVGA3DFORMAT_OP_ZSTENCIL
},
{
-  "SVGA3D_X32_TYPELESS_G8X24_UINT",
-  SVGA3D_X32_TYPELESS_G8X24_UINT,
+  "SVGA3D_X32_G8X24_UINT",
+  SVGA3D_X32_G8X24_UINT,
   SVGA3D_DEVCAP_DXFMT_X32_TYPELESS_G8X24_UINT,
   1, 1, 4, 0
},
@@ -1158,8 +1158,8 @@ static const struct format_cap format_cap_table[] = {
{
   /* Special case: no devcap / report sampler and depth/stencil ability
*/
-  "SVGA3D_R24_UNORM_X8_TYPELESS",
-

[Mesa-dev] [PATCH] svga: add texture size/levels sanity check code in svga_texture_create()

2017-06-28 Thread Brian Paul

The state tracker should never ask us to create a texture with invalid
dimensions / mipmap levels.  Do some assertions to check that.

No Piglit regressions.
---
 src/gallium/drivers/svga/svga_resource_texture.c | 33 
 1 file changed, 33 insertions(+)

diff --git a/src/gallium/drivers/svga/svga_resource_texture.c 
b/src/gallium/drivers/svga/svga_resource_texture.c
index 670100c..84441d1 100644
--- a/src/gallium/drivers/svga/svga_resource_texture.c
+++ b/src/gallium/drivers/svga/svga_resource_texture.c
@@ -916,6 +916,39 @@ svga_texture_create(struct pipe_screen *screen,
   goto fail_notex;
}
 
+   /* Verify the number of mipmap levels isn't impossibly large.  For example,
+* if the base 2D image is 16x16, we can't have 8 mipmap levels.
+* The state tracker should never ask us to create a resource with invalid
+* parameters.
+*/
+   {
+  unsigned max_dim = template->width0;
+
+  switch (template->target) {
+  case PIPE_TEXTURE_1D:
+  case PIPE_TEXTURE_1D_ARRAY:
+ // nothing
+ break;
+  case PIPE_TEXTURE_2D:
+  case PIPE_TEXTURE_CUBE:
+  case PIPE_TEXTURE_CUBE_ARRAY:
+  case PIPE_TEXTURE_2D_ARRAY:
+ max_dim = MAX2(max_dim, template->height0);
+ break;
+  case PIPE_TEXTURE_3D:
+ max_dim = MAX3(max_dim, template->height0, template->depth0);
+ break;
+  case PIPE_TEXTURE_RECT:
+  case PIPE_BUFFER:
+ assert(template->last_level == 0);
+ /* the assertion below should always pass */
+ break;
+  default:
+ debug_printf("Unexpected texture target type\n");
+  }
+  assert(1 << template->last_level <= max_dim);
+   }
+
tex = CALLOC_STRUCT(svga_texture);
if (!tex) {
   goto fail_notex;
-- 
1.9.1

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

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

2017-06-28 Thread Brian Paul

Return early from st_finalize_texture() if we have an incomplete
texture.  This avoids trying to create a texture resource with invalid
parameters (too many mipmap levels given the base dimension).

Specifically, the Piglit fbo-incomplete-texture-03 test winds up
calling pipe_screen::resource_create() with width0=32, height0=32 and
last_level=6 because the first five cube faces are 32x32 but the sixth
face is 64x64.  Some drivers handle this, but others (like VMware svga)
do not (generates device errors).

Note that this code is on the path that's usually not taken (we normally
build consistent textures).

No Piglit regressions.
---
 src/mesa/state_tracker/st_cb_texture.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/src/mesa/state_tracker/st_cb_texture.c 
b/src/mesa/state_tracker/st_cb_texture.c
index 9798321..7708443 100644
--- a/src/mesa/state_tracker/st_cb_texture.c
+++ b/src/mesa/state_tracker/st_cb_texture.c
@@ -2543,6 +2543,20 @@ st_finalize_texture(struct gl_context *ctx,
 stObj->base.Target == GL_TEXTURE_CUBE_MAP_ARRAY)
ptHeight = ptWidth;
  }
+
+ /* At this point, the texture may be incomplete (mismatched cube
+  * face sizes, for example).  If that's the case, give up, but
+  * don't return GL_FALSE as that would raise an incorrect
+  * GL_OUT_OF_MEMORY error.  See Piglit fbo-incomplete-texture-03 test.
+  */
+ if (!stObj->base._BaseComplete ||
+ !stObj->base._MipmapComplete) {
+_mesa_test_texobj_completeness(ctx, >base);
+if (!stObj->base._BaseComplete ||
+!stObj->base._MipmapComplete) {
+   return TRUE;
+}
+ }
   }
 
   ptNumSamples = firstImage->base.NumSamples;
-- 
1.9.1

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

[Mesa-dev] [PATCH 2/2] st/mesa: fix texture image resource selection in st_render_texture()

2017-06-28 Thread Brian Paul

If we're rendering to an incomplete/inconsistent (cube) texture, the
different faces/levels of the texture may be stored in different
resources.  Before, we always used the texture object resource.  Now,
we use the texture image resource.  In normal circumstances, that's
the same resource.  But in some cases, such as the Piglit
fbo-incomplete-texture-03 test, the cube faces are in different
resources and we need to render to the texture image resource.

Fixes fbo-incomplete-texture-03 with VMware driver.
---
 src/mesa/state_tracker/st_cb_fbo.c | 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/src/mesa/state_tracker/st_cb_fbo.c 
b/src/mesa/state_tracker/st_cb_fbo.c
index 2559c23..a4d710c 100644
--- a/src/mesa/state_tracker/st_cb_fbo.c
+++ b/src/mesa/state_tracker/st_cb_fbo.c
@@ -470,6 +470,21 @@ st_update_renderbuffer_surface(struct st_context *st,
strb->surface = *psurf;
 }
 
+
+/**
+ * Return the pipe_resource which stores a particular texture image.
+ */
+static struct pipe_resource *
+get_teximage_resource(struct gl_texture_object *texObj,
+  unsigned face, unsigned level)
+{
+   struct st_texture_image *stImg =
+  st_texture_image(texObj->Image[face][level]);
+
+   return stImg->pt;
+}
+
+
 /**
  * Called by ctx->Driver.RenderTexture
  */
@@ -487,7 +502,9 @@ st_render_texture(struct gl_context *ctx,
if (!st_finalize_texture(ctx, pipe, att->Texture, att->CubeMapFace))
   return;
 
-   pt = st_get_texobj_resource(att->Texture);
+   pt = get_teximage_resource(att->Texture,
+  att->CubeMapFace,
+  att->TextureLevel);
assert(pt);
 
/* point renderbuffer at texobject */
-- 
1.9.1

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

[Mesa-dev] [Bug 101467] swr driver leaks memory (texture management)

2017-06-28 Thread bugzilla-daemon

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

--- Comment #2 from Bruce Cherniak  ---
For the curious, this is the same result as allowing llvmpipe to build larger
scenes by setting the defines LP_SCENE_MAX_SIZE and LP_SCENE_MAX_RESOURCE_SIZE
to *large* values.

This suggests that when/if the oom-killer kicks in is more dependent on the
amount of system memory than indicative of a memory leak.

-- 
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] i965: Fix anisotropic filtering for mag filter

2017-06-28 Thread Rob Herring

On Wed, Jun 28, 2017 at 5:07 PM, Rob Herring  wrote:
> From: Eero Tamminen 

Ignore this.

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

[Mesa-dev] [PATCH] Android: i965: remove libdrm_intel dependency

2017-06-28 Thread Rob Herring

Commit 7dd20bc3ee8f ("anv/i965: drop libdrm_intel dependency completely")
removed the libdrm_intel dependency for automake, but Android builds still
depended on it. Now the build requires a newer version of i915_drm.h and
fails on Android builds:

src/mesa/drivers/dri/i965/brw_performance_query.c:616:9: error: use of 
undeclared identifier 'I915_OA_FORMAT_A32u40_A4u32_B8_C8'
   case I915_OA_FORMAT_A32u40_A4u32_B8_C8:
^
src/mesa/drivers/dri/i965/brw_performance_query.c:1887:18: error: use of 
undeclared identifier 'I915_PARAM_SLICE_MASK'
  gp.param = I915_PARAM_SLICE_MASK;
 ^
src/mesa/drivers/dri/i965/brw_performance_query.c:1893:18: error: use of 
undeclared identifier 'I915_PARAM_SUBSLICE_MASK'
  gp.param = I915_PARAM_SUBSLICE_MASK;
 ^

Remove the libdrm_intel dependency for Android builds and add the necessary
include paths for the local copy of i915_drm.h.

Signed-off-by: Rob Herring 
---
 src/mesa/drivers/dri/i965/Android.mk | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/Android.mk 
b/src/mesa/drivers/dri/i965/Android.mk
index 7ee9ab784c33..8996aec3b6a5 100644
--- a/src/mesa/drivers/dri/i965/Android.mk
+++ b/src/mesa/drivers/dri/i965/Android.mk
@@ -29,11 +29,11 @@ include $(LOCAL_PATH)/Makefile.sources
 
 I965_PERGEN_COMMON_INCLUDES := \
$(MESA_DRI_C_INCLUDES) \
-   $(MESA_TOP)/src/intel
+   $(MESA_TOP)/src/intel \
+   $(MESA_TOP)/src/intel/drm
 
 I965_PERGEN_SHARED_LIBRARIES := \
-   $(MESA_DRI_SHARED_LIBRARIES) \
-   libdrm_intel
+   $(MESA_DRI_SHARED_LIBRARIES)
 
 I965_PERGEN_STATIC_LIBRARIES := \
libmesa_genxml \
@@ -257,7 +257,8 @@ LOCAL_CFLAGS += \
 endif
 
 LOCAL_C_INCLUDES := \
-   $(MESA_DRI_C_INCLUDES)
+   $(MESA_DRI_C_INCLUDES) \
+   $(MESA_TOP)/src/intel/drm
 
 LOCAL_SRC_FILES := \
$(i965_FILES)
@@ -271,8 +272,7 @@ LOCAL_WHOLE_STATIC_LIBRARIES := \
libmesa_intel_compiler
 
 LOCAL_SHARED_LIBRARIES := \
-   $(MESA_DRI_SHARED_LIBRARIES) \
-   libdrm_intel
+   $(MESA_DRI_SHARED_LIBRARIES)
 
 LOCAL_GENERATED_SOURCES := \
$(MESA_DRI_OPTIONS_H) \
-- 
2.11.0

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

[Mesa-dev] [PATCH] i965: Fix anisotropic filtering for mag filter

2017-06-28 Thread Rob Herring

From: Eero Tamminen 

Commit f8d69beed49c64f883bb8ffb28d4960306baf575 moving sampler
handling to genxml messed up change done by commit
6a7c5257cac23cd9767aa4bc8fdab68925b11157.

This broke rendering in SynMark CSDof and TexFilterAniso tests.

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

Thanks to Kevin, who spotted the actual typo!
Reviewed-by: Ian Romanick 
Reviewed-by: Kenneth Graunke 
---
 src/mesa/drivers/dri/i965/genX_state_upload.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/genX_state_upload.c 
b/src/mesa/drivers/dri/i965/genX_state_upload.c
index d65b46886388..06b9cd507286 100644
--- a/src/mesa/drivers/dri/i965/genX_state_upload.c
+++ b/src/mesa/drivers/dri/i965/genX_state_upload.c
@@ -4551,7 +4551,7 @@ genX(update_sampler_state)(struct brw_context *brw,
if (sampler->MaxAnisotropy > 1.0f) {
   if (samp_st.MinModeFilter == MAPFILTER_LINEAR)
  samp_st.MinModeFilter = MAPFILTER_ANISOTROPIC;
-  if (samp_st.MinModeFilter == MAPFILTER_LINEAR)
+  if (samp_st.MagModeFilter == MAPFILTER_LINEAR)
  samp_st.MagModeFilter = MAPFILTER_ANISOTROPIC;
 
   if (sampler->MaxAnisotropy > 2.0f) {
-- 
2.11.0

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

[Mesa-dev] [PATCH v3 5/5] android: build imx-drm winsys

2017-06-28 Thread Robert Foss

From: Tomeu Vizoso 

Add Android.mk for winsys/imx/drm.

Signed-off-by: Tomeu Vizoso 
Reviewed-by: Tapani Pälli 
---
Changes since v2:
  - Rebased on upstream/master
  - Added commit message

Changes since v1:
  Emil Velikov 
   - Fix C_SOURCES include
   - Fix GALLIUM_LIBS assignment

 Android.mk|  5 +++--
 src/gallium/Android.mk|  1 +
 src/gallium/winsys/imx/drm/Android.mk | 39 +++
 3 files changed, 43 insertions(+), 2 deletions(-)
 create mode 100644 src/gallium/winsys/imx/drm/Android.mk

diff --git a/Android.mk b/Android.mk
index 2118405e1a..479a975999 100644
--- a/Android.mk
+++ b/Android.mk
@@ -24,7 +24,7 @@
 # BOARD_GPU_DRIVERS should be defined.  The valid values are
 #
 #   classic drivers: i915 i965
-#   gallium drivers: swrast freedreno i915g nouveau pl111 r300g r600g radeonsi 
vc4 virgl vmwgfx etnaviv
+#   gallium drivers: swrast freedreno i915g nouveau pl111 r300g r600g radeonsi 
vc4 virgl vmwgfx etnaviv imx
 #
 # The main target is libGLES_mesa.  For each classic driver enabled, a DRI
 # module will also be built.  DRI modules will be loaded by libGLES_mesa.
@@ -58,7 +58,8 @@ gallium_drivers := \
vmwgfx.HAVE_GALLIUM_VMWGFX \
vc4.HAVE_GALLIUM_VC4 \
virgl.HAVE_GALLIUM_VIRGL \
-   etnaviv.HAVE_GALLIUM_ETNAVIV
+   etnaviv.HAVE_GALLIUM_ETNAVIV \
+   imx.HAVE_GALLIUM_IMX
 
 ifeq ($(BOARD_GPU_DRIVERS),all)
 MESA_BUILD_CLASSIC := $(filter HAVE_%, $(subst ., , $(classic_drivers)))
diff --git a/src/gallium/Android.mk b/src/gallium/Android.mk
index dc98fa00ed..8743dd6d26 100644
--- a/src/gallium/Android.mk
+++ b/src/gallium/Android.mk
@@ -45,6 +45,7 @@ SUBDIRS += winsys/vc4/drm drivers/vc4
 SUBDIRS += winsys/virgl/drm winsys/virgl/vtest drivers/virgl
 SUBDIRS += winsys/svga/drm drivers/svga
 SUBDIRS += winsys/etnaviv/drm drivers/etnaviv drivers/renderonly
+SUBDIRS += winsys/imx/drm
 SUBDIRS += state_trackers/dri
 
 # sort to eliminate any duplicates
diff --git a/src/gallium/winsys/imx/drm/Android.mk 
b/src/gallium/winsys/imx/drm/Android.mk
new file mode 100644
index 00..51649f8b87
--- /dev/null
+++ b/src/gallium/winsys/imx/drm/Android.mk
@@ -0,0 +1,39 @@
+# Copyright (C) 2016 Linaro, Ltd, Rob Herring 
+#
+# Permission is hereby granted, free of charge, to any person obtaining a
+# copy of this software and associated documentation files (the "Software"),
+# to deal in the Software without restriction, including without limitation
+# the rights to use, copy, modify, merge, publish, distribute, sublicense,
+# and/or sell copies of the Software, and to permit persons to whom the
+# Software is furnished to do so, subject to the following conditions:
+#
+# The above copyright notice and this permission notice shall be included
+# in all copies or substantial portions of the Software.
+#
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+# DEALINGS IN THE SOFTWARE.
+
+LOCAL_PATH := $(call my-dir)
+
+include $(LOCAL_PATH)/Makefile.sources
+
+include $(CLEAR_VARS)
+
+LOCAL_SRC_FILES := $(C_SOURCES)
+
+LOCAL_SHARED_LIBRARIES := libdrm_etnaviv
+
+LOCAL_MODULE := libmesa_winsys_imx
+
+include $(GALLIUM_COMMON_MK)
+include $(BUILD_STATIC_LIBRARY)
+
+ifneq ($(HAVE_GALLIUM_FREEDRENO),)
+$(eval GALLIUM_LIBS += $(LOCAL_MODULE) libmesa_winsys_imx)
+$(eval GALLIUM_SHARED_LIBS += $(LOCAL_SHARED_LIBRARIES))
+endif
-- 
2.11.0

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

[Mesa-dev] [PATCH v3 3/5] gbm: add XBGR8888 support for dumb buffers

2017-06-28 Thread Robert Foss

From: Rob Herring 

Add GBM_FORMAT_XBGR format support which is needed for Android.

Signed-off-by: Rob Herring 
Reviewed-by: Tapani Pälli 
Reviewed-by: Daniel Stone 
Reviewed-by: Emil Velikov 
---
Changes since v2:
  - Rebased on upstream/master

Changes since v1:
  Emil Velikov 
   - Added commit msg


 src/gbm/backends/dri/gbm_dri.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gbm/backends/dri/gbm_dri.c b/src/gbm/backends/dri/gbm_dri.c
index 19be440d48..58b62ac361 100644
--- a/src/gbm/backends/dri/gbm_dri.c
+++ b/src/gbm/backends/dri/gbm_dri.c
@@ -1067,7 +1067,7 @@ create_dumb(struct gbm_device *gbm,
is_cursor = (usage & GBM_BO_USE_CURSOR) != 0 &&
   format == GBM_FORMAT_ARGB;
is_scanout = (usage & GBM_BO_USE_SCANOUT) != 0 &&
-  format == GBM_FORMAT_XRGB;
+  (format == GBM_FORMAT_XRGB || format == GBM_FORMAT_XBGR);
if (!is_cursor && !is_scanout) {
   errno = EINVAL;
   return NULL;
-- 
2.11.0

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

[Mesa-dev] [PATCH v3 2/5] gallium: os_process fixes for Android

2017-06-28 Thread Robert Foss

From: Rob Herring 

The function getprogname() is available on Android, since it reuses
various BSD solutions C runtime.

Signed-off-by: Rob Herring 
Reviewed-by: Tapani Pälli 
Reviewed-by: Emil Velikov 
---
Changes since v2:
  - Rebased on upstream/master

Changes since v1:
  Emil Velikov 
   - Added commit msg
   - Dropped whitepace change

 src/gallium/auxiliary/os/os_process.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/gallium/auxiliary/os/os_process.c 
b/src/gallium/auxiliary/os/os_process.c
index 6622b9b2bc..035bd228e7 100644
--- a/src/gallium/auxiliary/os/os_process.c
+++ b/src/gallium/auxiliary/os/os_process.c
@@ -34,7 +34,7 @@
 #  include 
 #elif defined(__GLIBC__) || defined(__CYGWIN__)
 #  include 
-#elif defined(PIPE_OS_BSD) || defined(PIPE_OS_APPLE)
+#elif defined(PIPE_OS_BSD) || defined(PIPE_OS_APPLE) || 
defined(PIPE_OS_ANDROID)
 #  include 
 #elif defined(PIPE_OS_HAIKU)
 #  include 
@@ -86,7 +86,7 @@ os_get_process_name(char *procname, size_t size)
 
 #elif defined(__GLIBC__) || defined(__CYGWIN__)
   name = program_invocation_short_name;
-#elif defined(PIPE_OS_BSD) || defined(PIPE_OS_APPLE)
+#elif defined(PIPE_OS_BSD) || defined(PIPE_OS_APPLE) || 
defined(PIPE_OS_ANDROID)
   /* *BSD and OS X */
   name = getprogname();
 #elif defined(PIPE_OS_HAIKU)
-- 
2.11.0

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

[Mesa-dev] [PATCH v3 4/5] android: add etnaviv driver build support

2017-06-28 Thread Robert Foss

From: Rob Herring 

Add etnaviv to Android makefiles.

Signed-off-by: Rob Herring 
Reviewed-by: Tapani Pälli 
---
Changes since v2:
  - Rebased on upstream/master

Changes since v1:
  Tapani Pälli 
   - Remove copy-pasta

  Emil Velikov 
   - Remove libmesa_loader inclusion
   - Remove copy-pasta
   - Remove spurious include
   - Fix C_SOURCES include


 Android.mk|  5 ++--
 src/gallium/Android.mk|  1 +
 src/gallium/drivers/etnaviv/Android.mk| 40 +++
 src/gallium/winsys/etnaviv/drm/Android.mk | 33 +
 4 files changed, 77 insertions(+), 2 deletions(-)
 create mode 100644 src/gallium/drivers/etnaviv/Android.mk
 create mode 100644 src/gallium/winsys/etnaviv/drm/Android.mk

diff --git a/Android.mk b/Android.mk
index 418570e607..2118405e1a 100644
--- a/Android.mk
+++ b/Android.mk
@@ -24,7 +24,7 @@
 # BOARD_GPU_DRIVERS should be defined.  The valid values are
 #
 #   classic drivers: i915 i965
-#   gallium drivers: swrast freedreno i915g nouveau pl111 r300g r600g radeonsi 
vc4 virgl vmwgfx
+#   gallium drivers: swrast freedreno i915g nouveau pl111 r300g r600g radeonsi 
vc4 virgl vmwgfx etnaviv
 #
 # The main target is libGLES_mesa.  For each classic driver enabled, a DRI
 # module will also be built.  DRI modules will be loaded by libGLES_mesa.
@@ -57,7 +57,8 @@ gallium_drivers := \
radeonsi.HAVE_GALLIUM_RADEONSI \
vmwgfx.HAVE_GALLIUM_VMWGFX \
vc4.HAVE_GALLIUM_VC4 \
-   virgl.HAVE_GALLIUM_VIRGL
+   virgl.HAVE_GALLIUM_VIRGL \
+   etnaviv.HAVE_GALLIUM_ETNAVIV
 
 ifeq ($(BOARD_GPU_DRIVERS),all)
 MESA_BUILD_CLASSIC := $(filter HAVE_%, $(subst ., , $(classic_drivers)))
diff --git a/src/gallium/Android.mk b/src/gallium/Android.mk
index 451bba4d17..dc98fa00ed 100644
--- a/src/gallium/Android.mk
+++ b/src/gallium/Android.mk
@@ -44,6 +44,7 @@ SUBDIRS += winsys/radeon/drm winsys/amdgpu/drm 
drivers/radeonsi drivers/radeon
 SUBDIRS += winsys/vc4/drm drivers/vc4
 SUBDIRS += winsys/virgl/drm winsys/virgl/vtest drivers/virgl
 SUBDIRS += winsys/svga/drm drivers/svga
+SUBDIRS += winsys/etnaviv/drm drivers/etnaviv drivers/renderonly
 SUBDIRS += state_trackers/dri
 
 # sort to eliminate any duplicates
diff --git a/src/gallium/drivers/etnaviv/Android.mk 
b/src/gallium/drivers/etnaviv/Android.mk
new file mode 100644
index 00..a0c55a464b
--- /dev/null
+++ b/src/gallium/drivers/etnaviv/Android.mk
@@ -0,0 +1,40 @@
+# Copyright (C) 2016 Linaro, Ltd, Rob Herring 
+#
+# Permission is hereby granted, free of charge, to any person obtaining a
+# copy of this software and associated documentation files (the "Software"),
+# to deal in the Software without restriction, including without limitation
+# the rights to use, copy, modify, merge, publish, distribute, sublicense,
+# and/or sell copies of the Software, and to permit persons to whom the
+# Software is furnished to do so, subject to the following conditions:
+#
+# The above copyright notice and this permission notice shall be included
+# in all copies or substantial portions of the Software.
+#
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+# DEALINGS IN THE SOFTWARE.
+
+LOCAL_PATH := $(call my-dir)
+
+# get C_SOURCES
+include $(LOCAL_PATH)/Makefile.sources
+
+include $(CLEAR_VARS)
+
+LOCAL_SRC_FILES := \
+   $(C_SOURCES)
+
+LOCAL_SHARED_LIBRARIES := libdrm_etnaviv
+LOCAL_MODULE := libmesa_pipe_etnaviv
+
+include $(GALLIUM_COMMON_MK)
+include $(BUILD_STATIC_LIBRARY)
+
+ifneq ($(HAVE_GALLIUM_ETNAVIV),)
+$(eval GALLIUM_LIBS += $(LOCAL_MODULE) libmesa_winsys_etnaviv)
+$(eval GALLIUM_SHARED_LIBS += $(LOCAL_SHARED_LIBRARIES))
+endif
diff --git a/src/gallium/winsys/etnaviv/drm/Android.mk 
b/src/gallium/winsys/etnaviv/drm/Android.mk
new file mode 100644
index 00..32091bea0e
--- /dev/null
+++ b/src/gallium/winsys/etnaviv/drm/Android.mk
@@ -0,0 +1,33 @@
+# Copyright (C) 2016 Linaro, Ltd, Rob Herring 
+#
+# Permission is hereby granted, free of charge, to any person obtaining a
+# copy of this software and associated documentation files (the "Software"),
+# to deal in the Software without restriction, including without limitation
+# the rights to use, copy, modify, merge, publish, distribute, sublicense,
+# and/or sell copies of the Software, and to permit persons to whom the
+# Software is furnished to do so, subject to the following conditions:
+#
+# The above copyright notice and this

[Mesa-dev] [PATCH v3 0/5] Android etnaviv and imx support

2017-06-28 Thread Robert Foss

This series enables etnaviv and imx for the android platform.
This is done through updating the Android build scripts.

Rob Herring (3):
  gallium: os_process fixes for Android
  gbm: add XBGR support for dumb buffers
  android: add etnaviv driver build support

Tomeu Vizoso (2):
  etnaviv: Add unreachable statement to etna_amode to fix compilation
warnings
  android: build imx-drm winsys

 Android.mk |  6 ++--
 src/gallium/Android.mk |  2 ++
 src/gallium/auxiliary/os/os_process.c  |  4 +--
 src/gallium/drivers/etnaviv/Android.mk | 40 ++
 src/gallium/drivers/etnaviv/etnaviv_compiler.c |  2 ++
 src/gallium/winsys/etnaviv/drm/Android.mk  | 33 +
 src/gallium/winsys/imx/drm/Android.mk  | 39 +
 src/gbm/backends/dri/gbm_dri.c |  2 +-
 8 files changed, 123 insertions(+), 5 deletions(-)
 create mode 100644 src/gallium/drivers/etnaviv/Android.mk
 create mode 100644 src/gallium/winsys/etnaviv/drm/Android.mk
 create mode 100644 src/gallium/winsys/imx/drm/Android.mk

-- 
2.11.0

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

[Mesa-dev] [PATCH v3 1/5] etnaviv: Add unreachable statement to etna_amode to fix compilation warnings

2017-06-28 Thread Robert Foss

From: Tomeu Vizoso 

Signed-off-by: Robert Foss 
Reviewed-by: Tapani Pälli 
---
Chages since v2:
  - Rebased on upstream/master

Changes since v1:
  Emil Velikov 
   - Replaced return with unreachable call

 src/gallium/drivers/etnaviv/etnaviv_compiler.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/gallium/drivers/etnaviv/etnaviv_compiler.c 
b/src/gallium/drivers/etnaviv/etnaviv_compiler.c
index af0f76b586..2e8dd8643a 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_compiler.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_compiler.c
@@ -885,6 +885,8 @@ etna_amode(struct tgsi_ind_register indirect)
default:
   assert(!"Invalid swizzle");
}
+
+   unreachable("bad swizzle");
 }
 
 /* convert destination operand */
-- 
2.11.0

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

Re: [Mesa-dev] [PATCH v2] mesa: Add _mesa_format_fallback_rgba_to_rgbx()

2017-06-28 Thread Jason Ekstrand

On Tue, Jun 20, 2017 at 4:53 PM, Jason Ekstrand 
wrote:

> From: Chad Versace 
>
> The new function takes a mesa_format and, if the format is an alpha
> format with a non-alpha variant, returns the non-alpha format.
> Otherwise, it returns the original format.
>
> Example:
>   input -> output
>
>   // Fallback exists
>   MESA_FORMAT_R8G8B8X8_UNORM -> MESA_FORMAT_R8G8B8A8_UNORM
>   MESA_FORMAT_RGBX_UNORM16 -> MESA_FORMAT_RGBA_UNORM16
>
>   // No fallback
>   MESA_FORMAT_R8G8B8A8_UNORM -> MESA_FORMAT_R8G8B8A8_UNORM
>   MESA_FORMAT_Z_FLOAT32 -> MESA_FORMAT_Z_FLOAT32
>
> i965 will use this for EGLImages and DRIimages.
>
> v2 (Jason Ekstrand):
>  - Use mako
>  - Rework to be easier to read
>  - Write directly to the output file
> ---
>  src/mesa/Android.gen.mk  |  12 +
>  src/mesa/Makefile.am |   7 +++
>  src/mesa/Makefile.sources|   2 +
>  src/mesa/main/.gitignore |   1 +
>  src/mesa/main/format_fallback.h  |  31 
>  src/mesa/main/format_fallback.py | 104 ++
> +
>  src/mesa/main/formats.h  |   3 ++
>  7 files changed, 160 insertions(+)
>  create mode 100644 src/mesa/main/format_fallback.h
>  create mode 100644 src/mesa/main/format_fallback.py
>
> diff --git a/src/mesa/Android.gen.mk b/src/mesa/Android.gen.mk
> index 366a6b1..8d24260 100644
> --- a/src/mesa/Android.gen.mk
> +++ b/src/mesa/Android.gen.mk
> @@ -34,6 +34,7 @@ sources := \
> main/enums.c \
> main/api_exec.c \
> main/dispatch.h \
> +   main/format_fallback.c \
> main/format_pack.c \
> main/format_unpack.c \
> main/format_info.h \
> @@ -123,6 +124,17 @@ $(intermediates)/main/get_hash.h:
> $(glapi)/gl_and_es_API.xml \
> $(LOCAL_PATH)/main/get_hash_params.py $(GET_HASH_GEN)
> $(call es-gen)
>
> +FORMAT_FALLBACK := $(LOCAL_PATH)/main/format_fallback.py
> +format_fallback_deps := \
> +   $(LOCAL_PATH)/main/formats.csv \
> +   $(LOCAL_PATH)/main/format_parser.py \
> +   $(FORMAT_FALLBACK)
> +
> +$(intermediates)/main/format_fallback.c: PRIVATE_SCRIPT :=
> $(MESA_PYTHON2) $(FORMAT_FALLBACK)
> +$(intermediates)/main/format_fallback.c: PRIVATE_XML :=
> +$(intermediates)/main/format_fallback.c: $(format_fallback_deps)
> +   $(call es-gen, $<)
> +
>  FORMAT_INFO := $(LOCAL_PATH)/main/format_info.py
>  format_info_deps := \
> $(LOCAL_PATH)/main/formats.csv \
> diff --git a/src/mesa/Makefile.am b/src/mesa/Makefile.am
> index 53f311d..97a9bbd 100644
> --- a/src/mesa/Makefile.am
> +++ b/src/mesa/Makefile.am
> @@ -37,6 +37,7 @@ include Makefile.sources
>
>  EXTRA_DIST = \
> drivers/SConscript \
> +   main/format_fallback.py \
> main/format_info.py \
> main/format_pack.py \
> main/format_parser.py \
> @@ -54,6 +55,7 @@ EXTRA_DIST = \
>
>  BUILT_SOURCES = \
> main/get_hash.h \
> +   main/format_fallback.c \
> main/format_info.h \
> main/format_pack.c \
> main/format_unpack.c \
> @@ -70,6 +72,11 @@ main/get_hash.h: ../mapi/glapi/gen/gl_and_es_API.xml
> main/get_hash_params.py \
> $(PYTHON_GEN) $(srcdir)/main/get_hash_generator.py \
> -f $(srcdir)/../mapi/glapi/gen/gl_and_es_API.xml > $@
>
> +main/format_fallback.c: main/format_fallback.py \
> +main/format_parser.py \
> +   main/formats.csv
> +   $(PYTHON_GEN) $(srcdir)/main/format_fallback.py
> $(srcdir)/main/formats.csv $@
> +
>  main/format_info.h: main/formats.csv \
>  main/format_parser.py main/format_info.py
> $(PYTHON_GEN) $(srcdir)/main/format_info.py
> $(srcdir)/main/formats.csv > $@
> diff --git a/src/mesa/Makefile.sources b/src/mesa/Makefile.sources
> index b80882f..3756e33 100644
> --- a/src/mesa/Makefile.sources
> +++ b/src/mesa/Makefile.sources
> @@ -94,6 +94,8 @@ MAIN_FILES = \
> main/ffvertex_prog.h \
> main/fog.c \
> main/fog.h \
> +   main/format_fallback.h \
> +   main/format_fallback.c \
> main/format_info.h \
> main/format_pack.h \
> main/format_pack.c \
> diff --git a/src/mesa/main/.gitignore b/src/mesa/main/.gitignore
> index 836d8f1..8cc33cf 100644
> --- a/src/mesa/main/.gitignore
> +++ b/src/mesa/main/.gitignore
> @@ -4,6 +4,7 @@ enums.c
>  remap_helper.h
>  get_hash.h
>  get_hash.h.tmp
> +format_fallback.c
>  format_info.h
>  format_info.c
>  format_pack.c
> diff --git a/src/mesa/main/format_fallback.h b/src/mesa/main/format_
> fallback.h
> new file mode 100644
> index 000..5ca8269
> --- /dev/null
> +++ b/src/mesa/main/format_fallback.h
> @@ -0,0 +1,31 @@
> +/*
> + * Copyright 2017 Google
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the
> "Software"),
> + * to deal in the Software without restriction, including without
>

Re: [Mesa-dev] [PATCH 1/3] mesa: Add _mesa_format_fallback_rgbx_to_rgba() [v2]

2017-06-28 Thread Rob Herring

On Wed, Jun 28, 2017 at 4:23 PM, Chad Versace  wrote:
> On Wed 28 Jun 2017, Rob Herring wrote:
>> On Tue, Jun 27, 2017 at 1:00 PM, Chad Versace  
>> wrote:
>> > The new function takes a mesa_format and, if the format is an alpha
>> > format with a non-alpha variant, returns the non-alpha format.
>> > Otherwise, it returns the original format.
>>
>> [...]
>>
>> > @@ -123,6 +124,17 @@ $(intermediates)/main/get_hash.h: 
>> > $(glapi)/gl_and_es_API.xml \
>> > $(LOCAL_PATH)/main/get_hash_params.py $(GET_HASH_GEN)
>> > $(call es-gen)
>> >
>> > +FORMAT_FALLBACK := $(LOCAL_PATH)/main/format_fallback.py
>> > +format_fallback_deps := \
>> > +   $(LOCAL_PATH)/main/formats.csv \
>> > +   $(LOCAL_PATH)/main/format_parser.py \
>> > +   $(FORMAT_FALLBACK)
>> > +
>> > +$(intermediates)/main/format_fallback.c: PRIVATE_SCRIPT := 
>> > $(MESA_PYTHON2) $(FORMAT_FALLBACK)
>> > +$(intermediates)/main/format_fallback.c: PRIVATE_XML :=
>> > +$(intermediates)/main/format_fallback.c: $(format_fallback_deps)
>> > +   $(call es-gen, $<)
>>
>> This breaks on Android because the script wants the output in $2 and
>> es-gen outputs to stdout:
>>
>> FAILED: 
>> out/target/product/linaro_x86_64/gen/STATIC_LIBRARIES/libmesa_st_mesa_intermediates/main/format_fallback.c
>> /bin/bash -c "python external/mesa3d/src/mesa/main/format_fallback.py
>> external/mesa3d/src/mesa/main/formats.csv  >
>> out/target/product/linaro_x86_64/gen/STATIC_LIBRARIES/libmesa_st_mesa_intermediates/main/format_fallback.c"
>> usage: format_fallback.py [-h] csv out
>> format_fallback.py: error: too few arguments
>
> My fault. After Jason rewrote the script, I forgot to re-test the
> Android.mk build. Do you already have a fix? If not, I'll make one.

I've hacked up the makefile just open coding the commands instead of
using es-gen. Did you want to fix it there or in the
format_fallback.py script to make  optional?

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

Re: [Mesa-dev] [PATCH 1/3] mesa: Add _mesa_format_fallback_rgbx_to_rgba() [v2]

2017-06-28 Thread Chad Versace

On Wed 28 Jun 2017, Rob Herring wrote:
> On Tue, Jun 27, 2017 at 1:00 PM, Chad Versace  
> wrote:
> > The new function takes a mesa_format and, if the format is an alpha
> > format with a non-alpha variant, returns the non-alpha format.
> > Otherwise, it returns the original format.
> 
> [...]
> 
> > @@ -123,6 +124,17 @@ $(intermediates)/main/get_hash.h: 
> > $(glapi)/gl_and_es_API.xml \
> > $(LOCAL_PATH)/main/get_hash_params.py $(GET_HASH_GEN)
> > $(call es-gen)
> >
> > +FORMAT_FALLBACK := $(LOCAL_PATH)/main/format_fallback.py
> > +format_fallback_deps := \
> > +   $(LOCAL_PATH)/main/formats.csv \
> > +   $(LOCAL_PATH)/main/format_parser.py \
> > +   $(FORMAT_FALLBACK)
> > +
> > +$(intermediates)/main/format_fallback.c: PRIVATE_SCRIPT := $(MESA_PYTHON2) 
> > $(FORMAT_FALLBACK)
> > +$(intermediates)/main/format_fallback.c: PRIVATE_XML :=
> > +$(intermediates)/main/format_fallback.c: $(format_fallback_deps)
> > +   $(call es-gen, $<)
> 
> This breaks on Android because the script wants the output in $2 and
> es-gen outputs to stdout:
> 
> FAILED: 
> out/target/product/linaro_x86_64/gen/STATIC_LIBRARIES/libmesa_st_mesa_intermediates/main/format_fallback.c
> /bin/bash -c "python external/mesa3d/src/mesa/main/format_fallback.py
> external/mesa3d/src/mesa/main/formats.csv  >
> out/target/product/linaro_x86_64/gen/STATIC_LIBRARIES/libmesa_st_mesa_intermediates/main/format_fallback.c"
> usage: format_fallback.py [-h] csv out
> format_fallback.py: error: too few arguments

I pushed a fix.

commit a56f0203c34b587da423133647d242f4b3a567ad
Author: Chad Versace 
Date:   Wed Jun 28 14:36:29 2017 -0700

mesa: Fix Android build

The format_fallback.py script wants two arguments: 'csv-file' and
'out-file'.

Fixes: 20c99eaece "mesa: Add _mesa_format_fallback_rgbx_to_rgba() [v2]"
Reported-by: Rob Herring 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] mesa: Add _mesa_format_fallback_rgbx_to_rgba() [v2]

2017-06-28 Thread Chad Versace

On Wed 28 Jun 2017, Rob Herring wrote:
> On Tue, Jun 27, 2017 at 1:00 PM, Chad Versace  
> wrote:
> > The new function takes a mesa_format and, if the format is an alpha
> > format with a non-alpha variant, returns the non-alpha format.
> > Otherwise, it returns the original format.
> 
> [...]
> 
> > @@ -123,6 +124,17 @@ $(intermediates)/main/get_hash.h: 
> > $(glapi)/gl_and_es_API.xml \
> > $(LOCAL_PATH)/main/get_hash_params.py $(GET_HASH_GEN)
> > $(call es-gen)
> >
> > +FORMAT_FALLBACK := $(LOCAL_PATH)/main/format_fallback.py
> > +format_fallback_deps := \
> > +   $(LOCAL_PATH)/main/formats.csv \
> > +   $(LOCAL_PATH)/main/format_parser.py \
> > +   $(FORMAT_FALLBACK)
> > +
> > +$(intermediates)/main/format_fallback.c: PRIVATE_SCRIPT := $(MESA_PYTHON2) 
> > $(FORMAT_FALLBACK)
> > +$(intermediates)/main/format_fallback.c: PRIVATE_XML :=
> > +$(intermediates)/main/format_fallback.c: $(format_fallback_deps)
> > +   $(call es-gen, $<)
> 
> This breaks on Android because the script wants the output in $2 and
> es-gen outputs to stdout:
> 
> FAILED: 
> out/target/product/linaro_x86_64/gen/STATIC_LIBRARIES/libmesa_st_mesa_intermediates/main/format_fallback.c
> /bin/bash -c "python external/mesa3d/src/mesa/main/format_fallback.py
> external/mesa3d/src/mesa/main/formats.csv  >
> out/target/product/linaro_x86_64/gen/STATIC_LIBRARIES/libmesa_st_mesa_intermediates/main/format_fallback.c"
> usage: format_fallback.py [-h] csv out
> format_fallback.py: error: too few arguments

My fault. After Jason rewrote the script, I forgot to re-test the
Android.mk build. Do you already have a fix? If not, I'll make one.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 15/30] i965: Use create_for_dri_image in intel_update_image_buffer

2017-06-28 Thread Chad Versace

Patches 14 and 15 are
Reviewed-by: Chad Versace 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v3 10/16] anv/cmd_buffer: Always enable CCS_D in render passes

2017-06-28 Thread Nanley Chery

The lifespan of the fast-clear data will surpass the render pass scope.
We need CCS_D to be enabled in order to invalidate blocks previously
marked as cleared and to sample cleared data correctly.

v2: Avoid refactoring.

Signed-off-by: Nanley Chery 
---
 src/intel/vulkan/anv_blorp.c   | 5 -
 src/intel/vulkan/genX_cmd_buffer.c | 5 +
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/src/intel/vulkan/anv_blorp.c b/src/intel/vulkan/anv_blorp.c
index 84b01e8792..7ae07808bc 100644
--- a/src/intel/vulkan/anv_blorp.c
+++ b/src/intel/vulkan/anv_blorp.c
@@ -1608,8 +1608,11 @@ ccs_resolve_attachment(struct anv_cmd_buffer *cmd_buffer,
cmd_buffer->state.pending_pipe_bits |=
   ANV_PIPE_RENDER_TARGET_CACHE_FLUSH_BIT | ANV_PIPE_CS_STALL_BIT;
 
+   const uint32_t aux_layers =
+  anv_image_aux_layers(image, iview->isl.base_level);
anv_ccs_resolve(cmd_buffer, att_state->color_rt_state, image,
-   iview->isl.base_level, fb->layers, resolve_op);
+   iview->isl.base_level, MIN2(fb->layers, aux_layers),
+   resolve_op);
 
cmd_buffer->state.pending_pipe_bits |=
   ANV_PIPE_RENDER_TARGET_CACHE_FLUSH_BIT | ANV_PIPE_CS_STALL_BIT;
diff --git a/src/intel/vulkan/genX_cmd_buffer.c 
b/src/intel/vulkan/genX_cmd_buffer.c
index 4bd38d0310..49ad41edbd 100644
--- a/src/intel/vulkan/genX_cmd_buffer.c
+++ b/src/intel/vulkan/genX_cmd_buffer.c
@@ -329,7 +329,7 @@ color_attachment_compute_aux_usage(struct anv_device * 
device,
if (iview->image->aux_usage == ISL_AUX_USAGE_CCS_E) {
   att_state->aux_usage = ISL_AUX_USAGE_CCS_E;
   att_state->input_aux_usage = ISL_AUX_USAGE_CCS_E;
-   } else if (att_state->fast_clear) {
+   } else {
   att_state->aux_usage = ISL_AUX_USAGE_CCS_D;
   /* From the Sky Lake PRM, RENDER_SURFACE_STATE::AuxiliarySurfaceMode:
*
@@ -346,9 +346,6 @@ color_attachment_compute_aux_usage(struct anv_device * 
device,
  att_state->input_aux_usage = ISL_AUX_USAGE_CCS_D;
   else
  att_state->input_aux_usage = ISL_AUX_USAGE_NONE;
-   } else {
-  att_state->aux_usage = ISL_AUX_USAGE_NONE;
-  att_state->input_aux_usage = ISL_AUX_USAGE_NONE;
}
 }
 
-- 
2.13.1

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

[Mesa-dev] [PATCH v3 12/16] anv/cmd_buffer: Warn about not enabling CCS_E

2017-06-28 Thread Nanley Chery

Use the performance warning infrastructure to provide helpful
information when testing applications.

Signed-off-by: Nanley Chery 
---
 src/intel/vulkan/genX_cmd_buffer.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/src/intel/vulkan/genX_cmd_buffer.c 
b/src/intel/vulkan/genX_cmd_buffer.c
index 1aa79c8e7b..d71c3c92c9 100644
--- a/src/intel/vulkan/genX_cmd_buffer.c
+++ b/src/intel/vulkan/genX_cmd_buffer.c
@@ -270,16 +270,18 @@ color_attachment_compute_aux_usage(struct anv_device * 
device,
* also supports color compression.
*/
   if (isl_format_supports_ccs_e(>info, iview->isl.format)) {
- /* TODO: Consider using a heuristic to determine if temporarily 
enabling
-  * CCS_E for this image view would be beneficial.
-  *
-  * While fast-clear resolves and partial resolves are fairly cheap in 
the
+ att_state->input_aux_usage = ISL_AUX_USAGE_CCS_D;
+
+ /* While fast-clear resolves and partial resolves are fairly cheap in 
the
   * case where you render to most of the pixels, full resolves are not
   * because they potentially involve reading and writing the entire
   * framebuffer.  If we can't texture with CCS_E, we should leave it 
off and
   * limit ourselves to fast clears.
   */
- att_state->input_aux_usage = ISL_AUX_USAGE_CCS_D;
+ if (cmd_state->pass->attachments[att].first_subpass_layout ==
+ VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL) {
+anv_perf_warn("Not temporarily enabling CCS_E.");
+ }
   } else {
  att_state->input_aux_usage = ISL_AUX_USAGE_NONE;
   }
-- 
2.13.1

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

[Mesa-dev] [PATCH v3 15/16] intel/blorp: Allow BLORP calls to be predicated

2017-06-28 Thread Nanley Chery

Signed-off-by: Nanley Chery 
---
 src/intel/blorp/blorp.h   | 3 +++
 src/intel/blorp/blorp_genX_exec.h | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/src/intel/blorp/blorp.h b/src/intel/blorp/blorp.h
index d5226c2248..1e96fb42b0 100644
--- a/src/intel/blorp/blorp.h
+++ b/src/intel/blorp/blorp.h
@@ -75,6 +75,9 @@ enum blorp_batch_flags {
 * hardware.
 */
BLORP_BATCH_NO_EMIT_DEPTH_STENCIL = (1 << 0),
+
+   /* This flag indicates that the blorp call should be predicated. */
+   BLORP_BATCH_PREDICATE_ENABLE  = (1 << 1),
 };
 
 struct blorp_batch {
diff --git a/src/intel/blorp/blorp_genX_exec.h 
b/src/intel/blorp/blorp_genX_exec.h
index 91c0756bf3..93534169ef 100644
--- a/src/intel/blorp/blorp_genX_exec.h
+++ b/src/intel/blorp/blorp_genX_exec.h
@@ -1543,6 +1543,9 @@ blorp_exec(struct blorp_batch *batch, const struct 
blorp_params *params)
blorp_emit(batch, GENX(3DPRIMITIVE), prim) {
   prim.VertexAccessType = SEQUENTIAL;
   prim.PrimitiveTopologyType = _3DPRIM_RECTLIST;
+#if GEN_GEN >= 7
+  prim.PredicateEnable = batch->flags & BLORP_BATCH_PREDICATE_ENABLE;
+#endif
   prim.VertexCountPerInstance = 3;
   prim.InstanceCount = params->num_layers;
}
-- 
2.13.1

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

[Mesa-dev] [PATCH v3 16/16] anv: Predicate fast-clear resolves

2017-06-28 Thread Nanley Chery

Image layouts only let us know that an image *may* be fast-cleared. For
this reason we can end up with redundant resolves. Testing has shown
that such resolves can measurably hurt performance and that predicating
them can avoid the penalty.

Signed-off-by: Nanley Chery 
---
 src/intel/vulkan/anv_blorp.c   |  3 +-
 src/intel/vulkan/anv_private.h | 13 --
 src/intel/vulkan/genX_cmd_buffer.c | 87 --
 3 files changed, 95 insertions(+), 8 deletions(-)

diff --git a/src/intel/vulkan/anv_blorp.c b/src/intel/vulkan/anv_blorp.c
index 35317ba6be..d06d7e2cc3 100644
--- a/src/intel/vulkan/anv_blorp.c
+++ b/src/intel/vulkan/anv_blorp.c
@@ -1619,7 +1619,8 @@ anv_ccs_resolve(struct anv_cmd_buffer * const cmd_buffer,
   return;
 
struct blorp_batch batch;
-   blorp_batch_init(_buffer->device->blorp, , cmd_buffer, 0);
+   blorp_batch_init(_buffer->device->blorp, , cmd_buffer,
+BLORP_BATCH_PREDICATE_ENABLE);
 
struct blorp_surf surf;
get_blorp_surf_for_anv_image(image, VK_IMAGE_ASPECT_COLOR_BIT,
diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_private.h
index be1623f3c3..951cf50842 100644
--- a/src/intel/vulkan/anv_private.h
+++ b/src/intel/vulkan/anv_private.h
@@ -2118,11 +2118,16 @@ anv_fast_clear_state_entry_size(const struct anv_device 
*device)
 {
assert(device);
/* Entry contents:
-*   +--+
-*   | clear value dword(s) |
-*   +--+
+*   ++
+*   | clear value dword(s) | needs resolve dword |
+*   ++
 */
-   return device->isl_dev.ss.clear_value_size;
+
+   /* Ensure that the needs resolve dword is in fact dword-aligned to enable
+* GPU memcpy operations.
+*/
+   assert(device->isl_dev.ss.clear_value_size % 4 == 0);
+   return device->isl_dev.ss.clear_value_size + 4;
 }
 
 /* Returns true if a HiZ-enabled depth buffer can be sampled from. */
diff --git a/src/intel/vulkan/genX_cmd_buffer.c 
b/src/intel/vulkan/genX_cmd_buffer.c
index 62a2f22782..65d9c92783 100644
--- a/src/intel/vulkan/genX_cmd_buffer.c
+++ b/src/intel/vulkan/genX_cmd_buffer.c
@@ -421,6 +421,59 @@ get_fast_clear_state_entry_offset(const struct anv_device 
*device,
return offset;
 }
 
+#define MI_PREDICATE_SRC0  0x2400
+#define MI_PREDICATE_SRC1  0x2408
+
+enum ccs_resolve_state {
+   CCS_RESOLVE_NOT_NEEDED,
+   CCS_RESOLVE_NEEDED,
+   CCS_RESOLVE_STARTING,
+};
+
+/* Manages the state of an color image subresource to ensure resolves are
+ * performed properly.
+ */
+static void
+genX(set_resolve_state)(struct anv_cmd_buffer *cmd_buffer,
+const struct anv_image *image,
+unsigned level,
+enum ccs_resolve_state state)
+{
+   assert(cmd_buffer && image);
+   assert(image->aspects == VK_IMAGE_ASPECT_COLOR_BIT);
+   assert(level < anv_image_aux_levels(image));
+
+   const uint32_t resolve_flag_offset =
+  get_fast_clear_state_entry_offset(cmd_buffer->device, image, level) +
+  cmd_buffer->device->isl_dev.ss.clear_value_size;
+
+   if (state != CCS_RESOLVE_STARTING) {
+  assert(state == CCS_RESOLVE_NEEDED || state == CCS_RESOLVE_NOT_NEEDED);
+  /* The HW docs say that there is no way to guarantee the completion of
+   * the following command. We use it nevertheless because it shows no
+   * issues in testing is currently being used in the GL driver.
+   */
+  anv_batch_emit(_buffer->batch, GENX(MI_STORE_DATA_IMM), sdi) {
+ sdi.Address = (struct anv_address) { image->bo, resolve_flag_offset };
+ sdi.ImmediateData = state == CCS_RESOLVE_NEEDED;
+  }
+   } else {
+  /* Make the pending predicated resolve a no-op if one is not needed.
+   * predicate = do_resolve = resolve_flag != 0;
+   */
+  emit_lri(_buffer->batch, MI_PREDICATE_SRC1, 0);
+  emit_lri(_buffer->batch, MI_PREDICATE_SRC1 + 4, 0);
+  emit_lri(_buffer->batch, MI_PREDICATE_SRC0, 0);
+  emit_lrm(_buffer->batch, MI_PREDICATE_SRC0 + 4,
+   image->bo, resolve_flag_offset);
+  anv_batch_emit(_buffer->batch, GENX(MI_PREDICATE), mip) {
+ mip.LoadOperation= LOAD_LOADINV;
+ mip.CombineOperation = COMBINE_SET;
+ mip.CompareOperation = COMPARE_SRCS_EQUAL;
+  }
+   }
+}
+
 static void
 init_fast_clear_state_entry(struct anv_cmd_buffer *cmd_buffer,
 const struct anv_image *image,
@@ -430,6 +483,16 @@ init_fast_clear_state_entry(struct anv_cmd_buffer 
*cmd_buffer,
assert(image->aspects == VK_IMAGE_ASPECT_COLOR_BIT);
assert(level < anv_image_aux_levels(image));
 
+   /* The resolve flag should updated to signify that fast-clear/compression
+* data needs to be removed when leaving the undefined layout. Such data
+* may need to be removed if it would cause accesses to the color

[Mesa-dev] [PATCH v3 07/16] anv/cmd_buffer: Ensure fast-clear values are current

2017-06-28 Thread Nanley Chery

v2: Rewrite functions, change location of synchronization.

Signed-off-by: Nanley Chery 
---
 src/intel/vulkan/genX_cmd_buffer.c | 114 +
 1 file changed, 114 insertions(+)

diff --git a/src/intel/vulkan/genX_cmd_buffer.c 
b/src/intel/vulkan/genX_cmd_buffer.c
index 253e68cd1f..decf0b28d6 100644
--- a/src/intel/vulkan/genX_cmd_buffer.c
+++ b/src/intel/vulkan/genX_cmd_buffer.c
@@ -479,6 +479,51 @@ init_fast_clear_state_entry(struct anv_cmd_buffer 
*cmd_buffer,
}
 }
 
+/* Copy the fast-clear value dword(s) between a surface state object and an
+ * image's fast clear state buffer.
+ */
+static void
+genX(copy_fast_clear_dwords)(struct anv_cmd_buffer *cmd_buffer,
+ struct anv_state surface_state,
+ const struct anv_image *image,
+ unsigned level,
+ bool copy_from_surface_state)
+{
+   assert(cmd_buffer && image);
+   assert(image->aspects == VK_IMAGE_ASPECT_COLOR_BIT);
+   assert(level < anv_image_aux_levels(image));
+
+   struct anv_bo *ss_bo =
+  _buffer->device->surface_state_pool.block_pool.bo;
+   uint32_t ss_clear_offset = surface_state.offset +
+  cmd_buffer->device->isl_dev.ss.clear_value_offset;
+   uint32_t entry_offset =
+  get_fast_clear_state_entry_offset(cmd_buffer->device, image, level);
+   unsigned copy_size = cmd_buffer->device->isl_dev.ss.clear_value_size;
+
+   if (copy_from_surface_state) {
+  genX(cmd_buffer_mi_memcpy)(cmd_buffer, image->bo, entry_offset,
+ ss_bo, ss_clear_offset, copy_size);
+   } else {
+  genX(cmd_buffer_mi_memcpy)(cmd_buffer, ss_bo, ss_clear_offset,
+ image->bo, entry_offset, copy_size);
+
+  /* Updating a surface state object may require that the state cache be
+   * invalidated. From the SKL PRM, Shared Functions -> State -> State
+   * Caching:
+   *
+   *Whenever the RENDER_SURFACE_STATE object in memory pointed to by
+   *the Binding Table Pointer (BTP) and Binding Table Index (BTI) is
+   *modified [...], the L1 state cache must be invalidated to ensure
+   *the new surface or sampler state is fetched from system memory.
+   *
+   * In testing, SKL doesn't actually seem to need this, but HSW does.
+   */
+  cmd_buffer->state.pending_pipe_bits |=
+ ANV_PIPE_STATE_CACHE_INVALIDATE_BIT;
+   }
+}
+
 static void
 transition_color_buffer(struct anv_cmd_buffer *cmd_buffer,
 const struct anv_image *image,
@@ -2615,6 +2660,66 @@ cmd_buffer_subpass_transition_layouts(struct 
anv_cmd_buffer * const cmd_buffer,
}
 }
 
+/* Update the clear value dword(s) in surface state objects or the fast clear
+ * state buffer entry for the color attachments used in this subpass.
+ */
+static void
+cmd_buffer_subpass_sync_fast_clear_values(struct anv_cmd_buffer *cmd_buffer)
+{
+   assert(cmd_buffer && cmd_buffer->state.subpass);
+
+   const struct anv_cmd_state *state = _buffer->state;
+
+   /* Iterate through every color attachment used in this subpass. */
+   for (uint32_t i = 0; i < state->subpass->color_count; ++i) {
+
+  /* The attachment should be one of the attachments described in the
+   * render pass and used in the subpass.
+   */
+  const uint32_t a = state->subpass->color_attachments[i].attachment;
+  assert(a < state->pass->attachment_count);
+  if (a == VK_ATTACHMENT_UNUSED)
+ continue;
+
+  /* Store some information regarding this attachment. */
+  const struct anv_attachment_state *att_state = >attachments[a];
+  const struct anv_image_view *iview = state->framebuffer->attachments[a];
+  const struct anv_render_pass_attachment *rp_att =
+ >pass->attachments[a];
+
+  if (att_state->aux_usage == ISL_AUX_USAGE_NONE)
+ continue;
+
+  /* The fast clear state entry must be updated if a fast clear is going to
+   * happen. The surface state must be updated if the clear value from a
+   * prior fast clear may be needed.
+   */
+  if (att_state->pending_clear_aspects && att_state->fast_clear) {
+ /* Update the fast clear state entry. */
+ genX(copy_fast_clear_dwords)(cmd_buffer, att_state->color_rt_state,
+  iview->image, iview->isl.base_level,
+  true /* copy from ss */);
+  } else if (rp_att->load_op == VK_ATTACHMENT_LOAD_OP_LOAD) {
+ /* The attachment may have been fast-cleared in a previous render
+  * pass and the value is needed now. Update the surface state(s).
+  *
+  * TODO: Do this only once per render pass instead of every subpass.
+  */
+ genX(copy_fast_clear_dwords)(cmd_buffer, att_state->color_rt_state,
+  iview->image, iview->isl.base_level,
+

[Mesa-dev] [PATCH v3 13/16] anv: Stop resolving CCS implicitly

2017-06-28 Thread Nanley Chery

With an earlier patch from this series, resolves are additionally
performed on layout transitions. Remove the now unnecessary implicit
resolves within render passes.

Signed-off-by: Nanley Chery 
---
 src/intel/vulkan/anv_blorp.c   | 150 ++---
 src/intel/vulkan/anv_pass.c|  14 
 src/intel/vulkan/anv_private.h |  10 ---
 3 files changed, 5 insertions(+), 169 deletions(-)

diff --git a/src/intel/vulkan/anv_blorp.c b/src/intel/vulkan/anv_blorp.c
index 7ae07808bc..35317ba6be 100644
--- a/src/intel/vulkan/anv_blorp.c
+++ b/src/intel/vulkan/anv_blorp.c
@@ -1496,150 +1496,16 @@ anv_image_ccs_clear(struct anv_cmd_buffer *cmd_buffer,
   ANV_PIPE_RENDER_TARGET_CACHE_FLUSH_BIT | ANV_PIPE_CS_STALL_BIT;
 }
 
-static void
-ccs_resolve_attachment(struct anv_cmd_buffer *cmd_buffer,
-   uint32_t att)
-{
-   struct anv_framebuffer *fb = cmd_buffer->state.framebuffer;
-   struct anv_attachment_state *att_state =
-  _buffer->state.attachments[att];
-
-   if (att_state->aux_usage == ISL_AUX_USAGE_NONE ||
-   att_state->aux_usage == ISL_AUX_USAGE_MCS)
-  return; /* Nothing to resolve */
-
-   assert(att_state->aux_usage == ISL_AUX_USAGE_CCS_E ||
-  att_state->aux_usage == ISL_AUX_USAGE_CCS_D);
-
-   struct anv_render_pass *pass = cmd_buffer->state.pass;
-   const uint32_t subpass_idx = anv_get_subpass_id(_buffer->state);
-
-   /* Scan forward to see what all ways this attachment will be used.
-* Ideally, we would like to resolve in the same subpass as the last write
-* of a particular attachment.  That way we only resolve once but it's
-* still hot in the cache.
-*/
-   bool found_draw = false;
-   enum anv_subpass_usage usage = 0;
-   for (uint32_t s = subpass_idx + 1; s < pass->subpass_count; s++) {
-  usage |= pass->attachments[att].subpass_usage[s];
-
-  if (usage & (ANV_SUBPASS_USAGE_DRAW | ANV_SUBPASS_USAGE_RESOLVE_DST)) {
- /* We found another subpass that draws to this attachment.  We'll
-  * wait to resolve until then.
-  */
- found_draw = true;
- break;
-  }
-   }
-
-   struct anv_image_view *iview = fb->attachments[att];
-   const struct anv_image *image = iview->image;
-   assert(image->aspects == VK_IMAGE_ASPECT_COLOR_BIT);
-
-   enum blorp_fast_clear_op resolve_op = BLORP_FAST_CLEAR_OP_NONE;
-   if (!found_draw) {
-  /* This is the last subpass that writes to this attachment so we need to
-   * resolve here.  Ideally, we would like to only resolve if the storeOp
-   * is set to VK_ATTACHMENT_STORE_OP_STORE.  However, we need to ensure
-   * that the CCS bits are set to "resolved" because there may be copy or
-   * blit operations (which may ignore CCS) between now and the next time
-   * we render and we need to ensure that anything they write will be
-   * respected in the next render.  Unfortunately, the hardware does not
-   * provide us with any sort of "invalidate" pass that sets the CCS to
-   * "resolved" without writing to the render target.
-   */
-  if (iview->image->aux_usage != ISL_AUX_USAGE_CCS_E) {
- /* The image destination surface doesn't support compression outside
-  * the render pass.  We need a full resolve.
-  */
- resolve_op = BLORP_FAST_CLEAR_OP_RESOLVE_FULL;
-  } else if (att_state->fast_clear) {
- /* We don't know what to do with clear colors outside the render
-  * pass.  We need a partial resolve. Only transparent black is
-  * built into the surface state object and thus no resolve is
-  * required for this case.
-  */
- if (att_state->clear_value.color.uint32[0] ||
- att_state->clear_value.color.uint32[1] ||
- att_state->clear_value.color.uint32[2] ||
- att_state->clear_value.color.uint32[3])
-resolve_op = BLORP_FAST_CLEAR_OP_RESOLVE_PARTIAL;
-  } else {
- /* The image "natively" supports all the compression we care about
-  * and we don't need to resolve at all.  If this is the case, we also
-  * don't need to resolve for any of the input attachment cases below.
-  */
-  }
-   } else if (usage & ANV_SUBPASS_USAGE_INPUT) {
-  /* Input attachments are clear-color aware so, at least on Sky Lake, we
-   * can frequently sample from them with no resolves at all.
-   */
-  if (att_state->aux_usage != att_state->input_aux_usage) {
- assert(att_state->input_aux_usage == ISL_AUX_USAGE_NONE);
- resolve_op = BLORP_FAST_CLEAR_OP_RESOLVE_FULL;
-  } else if (!att_state->clear_color_is_zero_one) {
- /* Sky Lake PRM, Vol. 2d, RENDER_SURFACE_STATE::Red Clear Color:
-  *
-  *"If Number of Multisamples is MULTISAMPLECOUNT_1 AND if this RT
-  *is fast cleared with non-0/1 clear value, this RT must be
-  *partially resolved

[Mesa-dev] [PATCH v3 11/16] anv/cmd_buffer: Move aux_usage assignment up

2017-06-28 Thread Nanley Chery

For readability, bring the assignment of CCS closer to the assignment of
NONE and MCS.

Signed-off-by: Nanley Chery 
---
 src/intel/vulkan/genX_cmd_buffer.c | 62 ++
 1 file changed, 30 insertions(+), 32 deletions(-)

diff --git a/src/intel/vulkan/genX_cmd_buffer.c 
b/src/intel/vulkan/genX_cmd_buffer.c
index 49ad41edbd..1aa79c8e7b 100644
--- a/src/intel/vulkan/genX_cmd_buffer.c
+++ b/src/intel/vulkan/genX_cmd_buffer.c
@@ -253,6 +253,36 @@ color_attachment_compute_aux_usage(struct anv_device * 
device,
   att_state->input_aux_usage = ISL_AUX_USAGE_MCS;
   att_state->fast_clear = false;
   return;
+   } else if (iview->image->aux_usage == ISL_AUX_USAGE_CCS_E) {
+  att_state->aux_usage = ISL_AUX_USAGE_CCS_E;
+  att_state->input_aux_usage = ISL_AUX_USAGE_CCS_E;
+   } else {
+  att_state->aux_usage = ISL_AUX_USAGE_CCS_D;
+  /* From the Sky Lake PRM, RENDER_SURFACE_STATE::AuxiliarySurfaceMode:
+   *
+   *"If Number of Multisamples is MULTISAMPLECOUNT_1, AUX_CCS_D
+   *setting is only allowed if Surface Format supported for Fast
+   *Clear. In addition, if the surface is bound to the sampling
+   *engine, Surface Format must be supported for Render Target
+   *Compression for surfaces bound to the sampling engine."
+   *
+   * In other words, we can only sample from a fast-cleared image if it
+   * also supports color compression.
+   */
+  if (isl_format_supports_ccs_e(>info, iview->isl.format)) {
+ /* TODO: Consider using a heuristic to determine if temporarily 
enabling
+  * CCS_E for this image view would be beneficial.
+  *
+  * While fast-clear resolves and partial resolves are fairly cheap in 
the
+  * case where you render to most of the pixels, full resolves are not
+  * because they potentially involve reading and writing the entire
+  * framebuffer.  If we can't texture with CCS_E, we should leave it 
off and
+  * limit ourselves to fast clears.
+  */
+ att_state->input_aux_usage = ISL_AUX_USAGE_CCS_D;
+  } else {
+ att_state->input_aux_usage = ISL_AUX_USAGE_NONE;
+  }
}
 
assert(iview->image->aux_surface.isl.usage & ISL_SURF_USAGE_CCS_BIT);
@@ -315,38 +345,6 @@ color_attachment_compute_aux_usage(struct anv_device * 
device,
} else {
   att_state->fast_clear = false;
}
-
-   /**
-* TODO: Consider using a heuristic to determine if temporarily enabling
-* CCS_E for this image view would be beneficial.
-*
-* While fast-clear resolves and partial resolves are fairly cheap in the
-* case where you render to most of the pixels, full resolves are not
-* because they potentially involve reading and writing the entire
-* framebuffer.  If we can't texture with CCS_E, we should leave it off and
-* limit ourselves to fast clears.
-*/
-   if (iview->image->aux_usage == ISL_AUX_USAGE_CCS_E) {
-  att_state->aux_usage = ISL_AUX_USAGE_CCS_E;
-  att_state->input_aux_usage = ISL_AUX_USAGE_CCS_E;
-   } else {
-  att_state->aux_usage = ISL_AUX_USAGE_CCS_D;
-  /* From the Sky Lake PRM, RENDER_SURFACE_STATE::AuxiliarySurfaceMode:
-   *
-   *"If Number of Multisamples is MULTISAMPLECOUNT_1, AUX_CCS_D
-   *setting is only allowed if Surface Format supported for Fast
-   *Clear. In addition, if the surface is bound to the sampling
-   *engine, Surface Format must be supported for Render Target
-   *Compression for surfaces bound to the sampling engine."
-   *
-   * In other words, we can only sample from a fast-cleared image if it
-   * also supports color compression.
-   */
-  if (isl_format_supports_ccs_e(>info, iview->isl.format))
- att_state->input_aux_usage = ISL_AUX_USAGE_CCS_D;
-  else
- att_state->input_aux_usage = ISL_AUX_USAGE_NONE;
-   }
 }
 
 static bool
-- 
2.13.1

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

[Mesa-dev] [PATCH v3 14/16] anv/cmd_buffer: Skip some input attachment transitions

2017-06-28 Thread Nanley Chery

Signed-off-by: Nanley Chery 
---
 src/intel/vulkan/genX_cmd_buffer.c | 31 ++-
 1 file changed, 26 insertions(+), 5 deletions(-)

diff --git a/src/intel/vulkan/genX_cmd_buffer.c 
b/src/intel/vulkan/genX_cmd_buffer.c
index d71c3c92c9..62a2f22782 100644
--- a/src/intel/vulkan/genX_cmd_buffer.c
+++ b/src/intel/vulkan/genX_cmd_buffer.c
@@ -2760,14 +2760,12 @@ cmd_buffer_subpass_transition_layouts(struct 
anv_cmd_buffer * const cmd_buffer,
   * this is not the last use of the buffer. The layout should not have
   * changed from the first call and no transition is necessary.
   */
- assert(att_ref->layout == att_state->current_layout);
+ assert(att_state->current_layout == att_ref->layout ||
+att_state->current_layout ==
+VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL);
  continue;
   }
 
-  /* Get the appropriate target layout for this attachment. */
-  const VkImageLayout target_layout = subpass_end ?
- att_desc->final_layout : att_ref->layout;
-
   /* The attachment index must be less than the number of attachments
* within the framebuffer.
*/
@@ -2777,6 +2775,29 @@ cmd_buffer_subpass_transition_layouts(struct 
anv_cmd_buffer * const cmd_buffer,
  cmd_state->framebuffer->attachments[att_ref->attachment];
   const struct anv_image * const image = iview->image;
 
+  /* Get the appropriate target layout for this attachment. */
+  VkImageLayout target_layout;
+
+  /* A resolve is necessary before use as an input attachment if the clear
+   * color or auxiliary buffer usage isn't supported by the sampler.
+   */
+  const bool input_needs_resolve =
+(att_state->fast_clear && !att_state->clear_color_is_zero_one) ||
+att_state->input_aux_usage != att_state->aux_usage;
+  if (subpass_end) {
+ target_layout = att_desc->final_layout;
+  } else if (iview->aspect_mask == VK_IMAGE_ASPECT_COLOR_BIT &&
+ !input_needs_resolve) {
+ /* Layout transitions before the final only help to enable sampling as
+  * an input attachment. If the input attachment supports sampling
+  * using the auxiliary surface, we can skip such transitions by making
+  * the target layout one that is CCS-aware.
+  */
+ target_layout = VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL;
+  } else {
+ target_layout = att_ref->layout;
+  }
+
   /* Perform the layout transition. */
   if (image->aspects & VK_IMAGE_ASPECT_DEPTH_BIT) {
  transition_depth_buffer(cmd_buffer, image,
-- 
2.13.1

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

[Mesa-dev] [PATCH v3 02/16] anv/image: Append CCS/MCS with a fast-clear state buffer

2017-06-28 Thread Nanley Chery

v2: Update comments, function signatures, and add assertions.

Signed-off-by: Nanley Chery 
---
 src/intel/vulkan/anv_image.c   | 78 ++
 src/intel/vulkan/anv_private.h | 12 +++
 2 files changed, 90 insertions(+)

diff --git a/src/intel/vulkan/anv_image.c b/src/intel/vulkan/anv_image.c
index c84fc8ddea..58d76ef951 100644
--- a/src/intel/vulkan/anv_image.c
+++ b/src/intel/vulkan/anv_image.c
@@ -116,6 +116,82 @@ add_surface(struct anv_image *image, struct anv_surface 
*surf)
 }
 
 /**
+ * For color images that have an auxiliary surface, request allocation for an
+ * additional buffer that mainly stores fast-clear values. Use of this buffer
+ * allows us to access the image's subresources while being aware of their
+ * fast-clear values in non-trivial cases (e.g., outside of a render pass in
+ * which a fast clear has occurred).
+ *
+ * For the purpose of discoverability, the algorithm used to manage this buffer
+ * is described here. A clear value in this buffer is updated when a fast clear
+ * is performed on a subresource. One of two synchronization operations is
+ * performed in order for a following memory access to use the fast-clear
+ * value:
+ *a. Copy the value from the buffer to the surface state object used for
+ *   reading. This is done implicitly when the value is the clear value
+ *   predetermined to be the default in other surface state objects. This
+ *   is currently only done explicitly for the operation below.
+ *b. Do (a) and use the surface state object to resolve the subresource.
+ *   This is only done during layout transitions for decent performance.
+ *
+ * With the above scheme, we can fast-clear whenever the hardware allows except
+ * for two cases in which synchronization becomes impossible or undesirable:
+ ** The subresource is in the GENERAL layout and is cleared to a value
+ *  other than the special default value.
+ *
+ *  Performing a synchronization operation in order to read from the
+ *  subresource is undesirable in this case. Firstly, b) is not an option
+ *  because a layout transition isn't required between a write and read of
+ *  an image in the GENERAL layout. Secondly, it's undesirable to do a)
+ *  explicitly because it would require large infrastructural changes. The
+ *  Vulkan API supports us in deciding not to optimize this layout by
+ *  stating that using this layout may cause suboptimal performance. NOTE:
+ *  the auxiliary buffer must always be enabled to support a) implicitly.
+ *
+ *
+ ** For the given miplevel, only some of the layers are cleared at once.
+ *
+ *  If the user clears each layer to a different value, then tries to
+ *  render to multiple layers at once, we have no ability to perform a
+ *  synchronization operation in between. a) is not helpful because the
+ *  object can only hold one clear value. b) is not an option because a
+ *  layout transition isn't required in this case.
+ */
+static void
+add_fast_clear_state_buffer(struct anv_image *image,
+const struct anv_device *device)
+{
+   assert(image && device);
+   assert(image->aux_surface.isl.size > 0 &&
+  image->aspects == VK_IMAGE_ASPECT_COLOR_BIT);
+
+   /* The offset to the buffer of clear values must be dword-aligned for GPU
+* memcpy operations. It is located immediately after the auxiliary surface.
+*/
+
+   /* Tiled images are guaranteed to be 4K aligned, so the image alignment
+* should also be dword-aligned.
+*/
+   assert(image->alignment % 4 == 0);
+
+   /* Auxiliary buffers should be a multiple of 4K, so the start of the clear
+* values buffer should already be dword-aligned.
+*/
+   assert(image->aux_surface.isl.size % 4 == 0);
+
+   /* This buffer should be at the very end of the image. */
+   assert(image->size ==
+  image->aux_surface.offset + image->aux_surface.isl.size);
+
+   const unsigned entry_size = anv_fast_clear_state_entry_size(device);
+   /* There's no padding between entries, so ensure that they're always a
+* multiple of 32 bits in order to enable GPU memcpy operations.
+*/
+   assert(entry_size % 4 == 0);
+   image->size += entry_size * anv_image_aux_levels(image);
+}
+
+/**
  * Initialize the anv_image::*_surface selected by \a aspect. Then update the
  * image's memory requirements (that is, the image's size and alignment).
  *
@@ -214,6 +290,7 @@ make_surface(const struct anv_device *dev,
 >aux_surface.isl);
  if (ok) {
 add_surface(image, >aux_surface);
+add_fast_clear_state_buffer(image, dev);
 
 /* For images created without MUTABLE_FORMAT_BIT set, we know that
  * they will always be used with the original format.  In
@@ -237,6 +314,7 @@ make_surface(const struct anv_device *dev,

[Mesa-dev] [PATCH v3 09/16] anv/cmd_buffer: Disable CCS on gen7 color attachments upfront

2017-06-28 Thread Nanley Chery

The next patch enables the use of CCS_D even when the color attachment
will not be fast-cleared. Catch the gen7 case early to simplify the
changes required.

Signed-off-by: Nanley Chery 
---
 src/intel/vulkan/genX_cmd_buffer.c | 16 +---
 1 file changed, 5 insertions(+), 11 deletions(-)

diff --git a/src/intel/vulkan/genX_cmd_buffer.c 
b/src/intel/vulkan/genX_cmd_buffer.c
index 1a9b841c7c..4bd38d0310 100644
--- a/src/intel/vulkan/genX_cmd_buffer.c
+++ b/src/intel/vulkan/genX_cmd_buffer.c
@@ -239,7 +239,11 @@ color_attachment_compute_aux_usage(struct anv_device * 
device,
struct anv_attachment_state *att_state = _state->attachments[att];
struct anv_image_view *iview = cmd_state->framebuffer->attachments[att];
 
-   if (iview->image->aux_surface.isl.size == 0) {
+   if (iview->isl.base_array_layer >=
+   anv_image_aux_layers(iview->image, iview->isl.base_level)) {
+  /* There is no aux buffer which corresponds to the level and layer(s)
+   * being accessed.
+   */
   att_state->aux_usage = ISL_AUX_USAGE_NONE;
   att_state->input_aux_usage = ISL_AUX_USAGE_NONE;
   att_state->fast_clear = false;
@@ -275,16 +279,6 @@ color_attachment_compute_aux_usage(struct anv_device * 
device,
   render_area.extent.height != iview->extent.height)
  att_state->fast_clear = false;
 
-  if (GEN_GEN <= 7) {
- /* On gen7, we can't do multi-LOD or multi-layer fast-clears.  We
-  * technically can, but it comes with crazy restrictions that we
-  * don't want to deal with now.
-  */
- if (iview->isl.base_level > 0 ||
- iview->isl.base_array_layer > 0)
-att_state->fast_clear = false;
-  }
-
   /* On Broadwell and earlier, we can only handle 0/1 clear colors */
   if (GEN_GEN <= 8 && !att_state->clear_color_is_zero_one)
  att_state->fast_clear = false;
-- 
2.13.1

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

[Mesa-dev] [PATCH v3 08/16] anv: Transition more color buffer layouts

2017-06-28 Thread Nanley Chery

v2: Expound on comment for the pipe controls (Jason Ekstrand).

Signed-off-by: Nanley Chery 
---
 src/intel/vulkan/anv_blorp.c   |   4 +-
 src/intel/vulkan/genX_cmd_buffer.c | 183 +
 2 files changed, 167 insertions(+), 20 deletions(-)

diff --git a/src/intel/vulkan/anv_blorp.c b/src/intel/vulkan/anv_blorp.c
index 459d57ec57..84b01e8792 100644
--- a/src/intel/vulkan/anv_blorp.c
+++ b/src/intel/vulkan/anv_blorp.c
@@ -1451,7 +1451,9 @@ anv_image_ccs_clear(struct anv_cmd_buffer *cmd_buffer,
 
struct blorp_surf surf;
get_blorp_surf_for_anv_image(image, VK_IMAGE_ASPECT_COLOR_BIT,
-image->aux_usage, );
+image->aux_usage == ISL_AUX_USAGE_CCS_E ?
+ISL_AUX_USAGE_CCS_E : ISL_AUX_USAGE_CCS_D,
+);
 
/* From the Sky Lake PRM Vol. 7, "Render Target Fast Clear":
 *
diff --git a/src/intel/vulkan/genX_cmd_buffer.c 
b/src/intel/vulkan/genX_cmd_buffer.c
index decf0b28d6..1a9b841c7c 100644
--- a/src/intel/vulkan/genX_cmd_buffer.c
+++ b/src/intel/vulkan/genX_cmd_buffer.c
@@ -524,6 +524,17 @@ genX(copy_fast_clear_dwords)(struct anv_cmd_buffer 
*cmd_buffer,
}
 }
 
+/**
+ * @brief Transitions a color buffer from one layout to another.
+ *
+ * See section 6.1.1. Image Layout Transitions of the Vulkan 1.0.50 spec for
+ * more information.
+ *
+ * @param level_count VK_REMAINING_MIP_LEVELS isn't supported.
+ * @param layer_count VK_REMAINING_ARRAY_LAYERS isn't supported. For 3D images,
+ *this represents the maximum layers to transition at each
+ *specified miplevel.
+ */
 static void
 transition_color_buffer(struct anv_cmd_buffer *cmd_buffer,
 const struct anv_image *image,
@@ -532,13 +543,27 @@ transition_color_buffer(struct anv_cmd_buffer *cmd_buffer,
 VkImageLayout initial_layout,
 VkImageLayout final_layout)
 {
-   assert(image->aspects == VK_IMAGE_ASPECT_COLOR_BIT);
-
-   if (image->aux_surface.isl.size == 0)
-  return;
-
-   if (initial_layout != VK_IMAGE_LAYOUT_UNDEFINED &&
-   initial_layout != VK_IMAGE_LAYOUT_PREINITIALIZED)
+   /* Validate the inputs. */
+   assert(cmd_buffer);
+   assert(image && image->aspects == VK_IMAGE_ASPECT_COLOR_BIT);
+   /* These values aren't supported for simplicity's sake. */
+   assert(level_count != VK_REMAINING_MIP_LEVELS &&
+  layer_count != VK_REMAINING_ARRAY_LAYERS);
+   /* Ensure the subresource range is valid. */
+   uint64_t last_level_num = base_level + level_count;
+   const uint32_t max_depth = anv_minify(image->extent.depth, base_level);
+   const uint32_t image_layers = MAX2(image->array_size, max_depth);
+   assert(base_layer + layer_count  <= image_layers);
+   assert(last_level_num <= image->levels);
+   /* The spec disallows these final layouts. */
+   assert(final_layout != VK_IMAGE_LAYOUT_UNDEFINED &&
+  final_layout != VK_IMAGE_LAYOUT_PREINITIALIZED);
+
+   /* No work is necessary if the layout stays the same or if this subresource
+* range lacks auxiliary data.
+*/
+   if (initial_layout == final_layout ||
+   base_layer >= anv_image_aux_layers(image, base_level))
   return;
 
/* A transition of a 3D subresource works on all slices at a time. */
@@ -549,22 +574,142 @@ transition_color_buffer(struct anv_cmd_buffer 
*cmd_buffer,
 
/* We're interested in the subresource range subset that has aux data. */
level_count = MIN2(level_count, anv_image_aux_levels(image));
+   layer_count = MIN2(layer_count, anv_image_aux_layers(image, base_level));
+   last_level_num = base_level + level_count;
+
+   /* Record whether or not the layout is undefined. Pre-initialized images
+* with auxiliary buffers have a non-linear layout and are thus undefined.
+*/
+   assert(image->tiling == VK_IMAGE_TILING_OPTIMAL);
+   const bool undef_layout = initial_layout == VK_IMAGE_LAYOUT_UNDEFINED ||
+ initial_layout == VK_IMAGE_LAYOUT_PREINITIALIZED;
 
-   /* We're transitioning from an undefined layout. We must ensure that the
-* clear values buffer is filled with valid data.
+   /* Do preparatory work before the resolve operation or return early if no
+* resolve is actually needed.
 */
-   for (unsigned l = 0; l < level_count; l++)
-  init_fast_clear_state_entry(cmd_buffer, image, base_level + l);
-
-   if (image->aux_usage == ISL_AUX_USAGE_CCS_E) {
-  /* We're transitioning from an undefined layout so it doesn't really
-   * matter what data ends up in the color buffer.  We do, however, need to
-   * ensure that the CCS has valid data in it.  One easy way to do that is
-   * to fast-clear the specified range.
+   if (undef_layout) {
+  /* A subresource in the undefined layout may have been aliased and
+   * populated with any arrangement of bits.

[Mesa-dev] [PATCH v3 05/16] anv/cmd_buffer: Restrict fast clears in the GENERAL layout

2017-06-28 Thread Nanley Chery

v2: Remove ::first_subpass_layout assertion (Jason Ekstrand).
v3: Allow some fast clears in the GENERAL layout.

Signed-off-by: Nanley Chery 
---
 src/intel/vulkan/anv_pass.c| 22 ++
 src/intel/vulkan/anv_private.h |  2 ++
 src/intel/vulkan/genX_cmd_buffer.c | 17 -
 3 files changed, 40 insertions(+), 1 deletion(-)

diff --git a/src/intel/vulkan/anv_pass.c b/src/intel/vulkan/anv_pass.c
index 1b30c1409d..ab0733fc10 100644
--- a/src/intel/vulkan/anv_pass.c
+++ b/src/intel/vulkan/anv_pass.c
@@ -34,6 +34,16 @@ num_subpass_attachments(const VkSubpassDescription *desc)
   (desc->pDepthStencilAttachment != NULL);
 }
 
+static void
+init_first_subpass_layout(struct anv_render_pass_attachment * const att,
+  const VkAttachmentReference att_ref)
+{
+   if (att->first_subpass_layout == VK_IMAGE_LAYOUT_UNDEFINED) {
+  att->first_subpass_layout = att_ref.layout;
+  assert(att->first_subpass_layout != VK_IMAGE_LAYOUT_UNDEFINED);
+   }
+}
+
 VkResult anv_CreateRenderPass(
 VkDevice_device,
 const VkRenderPassCreateInfo*   pCreateInfo,
@@ -91,6 +101,7 @@ VkResult anv_CreateRenderPass(
   att->stencil_load_op = pCreateInfo->pAttachments[i].stencilLoadOp;
   att->initial_layout = pCreateInfo->pAttachments[i].initialLayout;
   att->final_layout = pCreateInfo->pAttachments[i].finalLayout;
+  att->first_subpass_layout = VK_IMAGE_LAYOUT_UNDEFINED;
   att->subpass_usage = subpass_usages;
   subpass_usages += pass->subpass_count;
}
@@ -119,6 +130,8 @@ VkResult anv_CreateRenderPass(
pass->attachments[a].subpass_usage[i] |= 
ANV_SUBPASS_USAGE_INPUT;
pass->attachments[a].last_subpass_idx = i;
 
+   init_first_subpass_layout(>attachments[a],
+ desc->pInputAttachments[j]);
if (desc->pDepthStencilAttachment &&
a == desc->pDepthStencilAttachment->attachment)
   subpass->has_ds_self_dep = true;
@@ -138,6 +151,9 @@ VkResult anv_CreateRenderPass(
pass->attachments[a].usage |= 
VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT;
pass->attachments[a].subpass_usage[i] |= ANV_SUBPASS_USAGE_DRAW;
pass->attachments[a].last_subpass_idx = i;
+
+   init_first_subpass_layout(>attachments[a],
+ desc->pColorAttachments[j]);
 }
  }
   }
@@ -162,6 +178,9 @@ VkResult anv_CreateRenderPass(
pass->attachments[a].subpass_usage[i] |=
   ANV_SUBPASS_USAGE_RESOLVE_DST;
pass->attachments[a].last_subpass_idx = i;
+
+   init_first_subpass_layout(>attachments[a],
+ desc->pResolveAttachments[j]);
 }
  }
   }
@@ -176,6 +195,9 @@ VkResult anv_CreateRenderPass(
VK_IMAGE_USAGE_DEPTH_STENCIL_ATTACHMENT_BIT;
 pass->attachments[a].subpass_usage[i] |= ANV_SUBPASS_USAGE_DRAW;
 pass->attachments[a].last_subpass_idx = i;
+
+init_first_subpass_layout(>attachments[a],
+  *desc->pDepthStencilAttachment);
  }
   } else {
  subpass->depth_stencil_attachment.attachment = VK_ATTACHMENT_UNUSED;
diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_private.h
index a95188ac30..c5a2ba0888 100644
--- a/src/intel/vulkan/anv_private.h
+++ b/src/intel/vulkan/anv_private.h
@@ -1518,6 +1518,7 @@ struct anv_attachment_state {
bool fast_clear;
VkClearValue clear_value;
bool clear_color_is_zero_one;
+   bool clear_color_is_zero;
 };
 
 /** State required while building cmd buffer */
@@ -2336,6 +2337,7 @@ struct anv_render_pass_attachment {
VkAttachmentLoadOp   stencil_load_op;
VkImageLayoutinitial_layout;
VkImageLayoutfinal_layout;
+   VkImageLayoutfirst_subpass_layout;
 
/* An array, indexed by subpass id, of how the attachment will be used. */
enum anv_subpass_usage * subpass_usage;
diff --git a/src/intel/vulkan/genX_cmd_buffer.c 
b/src/intel/vulkan/genX_cmd_buffer.c
index 15927d32ad..253e68cd1f 100644
--- a/src/intel/vulkan/genX_cmd_buffer.c
+++ b/src/intel/vulkan/genX_cmd_buffer.c
@@ -253,7 +253,12 @@ color_attachment_compute_aux_usage(struct anv_device * 
device,
 
assert(iview->image->aux_surface.isl.usage & ISL_SURF_USAGE_CCS_BIT);
 
-   att_state->clear_color_is_zero_one =
+   att_state->clear_color_is_zero =
+  att_state->clear_value.color.uint32[0] == 0 &&
+

[Mesa-dev] [PATCH v3 06/16] anv/gpu_memcpy: Add a lighter-weight GPU memcpy function

2017-06-28 Thread Nanley Chery

We'll be performing a GPU memcpy in more places to copy small amounts of
data. Add an alternate function that thrashes less state.

v2:
- Make a new function (Jason Ekstrand).
- Move the #define into the function.
v3:
- Update the function name (Jason).
- Update comments.

Signed-off-by: Nanley Chery 
---
 src/intel/vulkan/anv_genX.h|  5 +
 src/intel/vulkan/genX_gpu_memcpy.c | 40 ++
 2 files changed, 45 insertions(+)

diff --git a/src/intel/vulkan/anv_genX.h b/src/intel/vulkan/anv_genX.h
index 8da5e075dc..0b7322e281 100644
--- a/src/intel/vulkan/anv_genX.h
+++ b/src/intel/vulkan/anv_genX.h
@@ -69,5 +69,10 @@ void genX(cmd_buffer_so_memcpy)(struct anv_cmd_buffer 
*cmd_buffer,
 struct anv_bo *src, uint32_t src_offset,
 uint32_t size);
 
+void genX(cmd_buffer_mi_memcpy)(struct anv_cmd_buffer *cmd_buffer,
+struct anv_bo *dst, uint32_t dst_offset,
+struct anv_bo *src, uint32_t src_offset,
+uint32_t size);
+
 void genX(blorp_exec)(struct blorp_batch *batch,
   const struct blorp_params *params);
diff --git a/src/intel/vulkan/genX_gpu_memcpy.c 
b/src/intel/vulkan/genX_gpu_memcpy.c
index 5ef35e6283..9c6b46de94 100644
--- a/src/intel/vulkan/genX_gpu_memcpy.c
+++ b/src/intel/vulkan/genX_gpu_memcpy.c
@@ -52,6 +52,46 @@ gcd_pow2_u64(uint64_t a, uint64_t b)
 }
 
 void
+genX(cmd_buffer_mi_memcpy)(struct anv_cmd_buffer *cmd_buffer,
+   struct anv_bo *dst, uint32_t dst_offset,
+   struct anv_bo *src, uint32_t src_offset,
+   uint32_t size)
+{
+   /* This memcpy operates in units of dwords. */
+   assert(size % 4 == 0);
+   assert(dst_offset % 4 == 0);
+   assert(src_offset % 4 == 0);
+
+   for (uint32_t i = 0; i < size; i += 4) {
+  const struct anv_address src_addr =
+ (struct anv_address) { src, src_offset + i};
+  const struct anv_address dst_addr =
+ (struct anv_address) { dst, dst_offset + i};
+#if GEN_GEN >= 8
+  anv_batch_emit(_buffer->batch, GENX(MI_COPY_MEM_MEM), cp) {
+ cp.DestinationMemoryAddress = dst_addr;
+ cp.SourceMemoryAddress = src_addr;
+  }
+#else
+  /* IVB does not have a general purpose register for command streamer
+   * commands. Therefore, we use an alternate temporary register.
+   */
+#define TEMP_REG 0x2400 /* MI_PREDICATE_SRC0 */
+  anv_batch_emit(_buffer->batch, GENX(MI_LOAD_REGISTER_MEM), load) {
+ load.RegisterAddress = TEMP_REG;
+ load.MemoryAddress = src_addr;
+  }
+  anv_batch_emit(_buffer->batch, GENX(MI_STORE_REGISTER_MEM), store) {
+ store.RegisterAddress = TEMP_REG;
+ store.MemoryAddress = dst_addr;
+  }
+#undef TEMP_REG
+#endif
+   }
+   return;
+}
+
+void
 genX(cmd_buffer_so_memcpy)(struct anv_cmd_buffer *cmd_buffer,
struct anv_bo *dst, uint32_t dst_offset,
struct anv_bo *src, uint32_t src_offset,
-- 
2.13.1

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

[Mesa-dev] [PATCH v3 03/16] anv/cmd_buffer: Initialize the clear values buffer

2017-06-28 Thread Nanley Chery

v2: Rewrite functions.

Signed-off-by: Nanley Chery 
---
 src/intel/vulkan/genX_cmd_buffer.c | 93 ++
 1 file changed, 84 insertions(+), 9 deletions(-)

diff --git a/src/intel/vulkan/genX_cmd_buffer.c 
b/src/intel/vulkan/genX_cmd_buffer.c
index 53c58ca5b3..8601d706d1 100644
--- a/src/intel/vulkan/genX_cmd_buffer.c
+++ b/src/intel/vulkan/genX_cmd_buffer.c
@@ -384,6 +384,70 @@ transition_depth_buffer(struct anv_cmd_buffer *cmd_buffer,
   anv_gen8_hiz_op_resolve(cmd_buffer, image, hiz_op);
 }
 
+static inline uint32_t
+get_fast_clear_state_entry_offset(const struct anv_device *device,
+  const struct anv_image *image,
+  unsigned level)
+{
+   assert(device && image);
+   assert(image->aspects == VK_IMAGE_ASPECT_COLOR_BIT);
+   assert(level < anv_image_aux_levels(image));
+   const uint32_t offset = image->offset + image->aux_surface.offset +
+   image->aux_surface.isl.size +
+   anv_fast_clear_state_entry_size(device) * level;
+   assert(offset < image->offset + image->size);
+   return offset;
+}
+
+static void
+init_fast_clear_state_entry(struct anv_cmd_buffer *cmd_buffer,
+const struct anv_image *image,
+unsigned level)
+{
+   assert(cmd_buffer && image);
+   assert(image->aspects == VK_IMAGE_ASPECT_COLOR_BIT);
+   assert(level < anv_image_aux_levels(image));
+
+   /* The fast clear value dword(s) will be copied into a surface state object.
+* Ensure that the restrictions of the fields in the dword(s) are followed.
+*
+* CCS buffers on SKL+ can have any value set for the clear colors.
+*/
+   if (image->samples == 1 && GEN_GEN >= 9)
+  return;
+
+   /* Other combinations of auxiliary buffers and platforms require specific
+* values in the clear value dword(s).
+*/
+   unsigned i = 0;
+   for (; i < cmd_buffer->device->isl_dev.ss.clear_value_size; i += 4) {
+  anv_batch_emit(_buffer->batch, GENX(MI_STORE_DATA_IMM), sdi) {
+ const uint32_t entry_offset =
+get_fast_clear_state_entry_offset(cmd_buffer->device, image, 
level);
+ sdi.Address = (struct anv_address) { image->bo, entry_offset + i };
+
+ if (GEN_GEN >= 9) {
+/* MCS buffers on SKL+ can only have 1/0 clear colors. */
+assert(image->aux_usage == ISL_AUX_USAGE_MCS);
+sdi.ImmediateData = 0;
+ } else {
+/* Pre-SKL, the dword containing the clear values also contains
+ * other fields, so we need to initialize those fields to match the
+ * values that would be in a color attachment.
+ */
+assert(i == 0);
+sdi.ImmediateData = level << 8;
+if (GEN_VERSIONx10 >= 75) {
+   sdi.ImmediateData |= ISL_CHANNEL_SELECT_RED   << 25 |
+ISL_CHANNEL_SELECT_GREEN << 22 |
+ISL_CHANNEL_SELECT_BLUE  << 19 |
+ISL_CHANNEL_SELECT_ALPHA << 16;
+}
+ }
+  }
+   }
+}
+
 static void
 transition_color_buffer(struct anv_cmd_buffer *cmd_buffer,
 const struct anv_image *image,
@@ -392,7 +456,9 @@ transition_color_buffer(struct anv_cmd_buffer *cmd_buffer,
 VkImageLayout initial_layout,
 VkImageLayout final_layout)
 {
-   if (image->aux_usage != ISL_AUX_USAGE_CCS_E)
+   assert(image->aspects == VK_IMAGE_ASPECT_COLOR_BIT);
+
+   if (image->aux_surface.isl.size == 0)
   return;
 
if (initial_layout != VK_IMAGE_LAYOUT_UNDEFINED &&
@@ -405,15 +471,24 @@ transition_color_buffer(struct anv_cmd_buffer *cmd_buffer,
   layer_count = anv_minify(image->extent.depth, base_level);
}
 
-#if GEN_GEN >= 9
-   /* We're transitioning from an undefined layout so it doesn't really matter
-* what data ends up in the color buffer.  We do, however, need to ensure
-* that the CCS has valid data in it.  One easy way to do that is to
-* fast-clear the specified range.
+   /* We're interested in the subresource range subset that has aux data. */
+   level_count = MIN2(level_count, anv_image_aux_levels(image));
+
+   /* We're transitioning from an undefined layout. We must ensure that the
+* clear values buffer is filled with valid data.
 */
-   anv_image_ccs_clear(cmd_buffer, image, base_level, level_count,
-   base_layer, layer_count);
-#endif
+   for (unsigned l = 0; l < level_count; l++)
+  init_fast_clear_state_entry(cmd_buffer, image, base_level + l);
+
+   if (image->aux_usage == ISL_AUX_USAGE_CCS_E) {
+  /* We're transitioning from an undefined layout so it doesn't really
+   * matter what data ends up in the color buffer.  We do, however, need to
+   * ensure that the CCS has valid data in it.  One easy

[Mesa-dev] [PATCH v3 00/16] anv: Do CCS resolves at layout transitions

2017-06-28 Thread Nanley Chery

A quick test shows that this change still improves frame rates on a 
Dota 2 benchmark by about 3% at 1080p.

Cc: Jason Ekstrand 

Nanley Chery (16):
  intel/isl: Add surface state clear value information
  anv/image: Append CCS/MCS with a fast-clear state buffer
  anv/cmd_buffer: Initialize the clear values buffer
  anv/cmd_buffer: Don't partially fast clear image layers
  anv/cmd_buffer: Restrict fast clears in the GENERAL layout
  anv/gpu_memcpy: Add a lighter-weight GPU memcpy function
  anv/cmd_buffer: Ensure fast-clear values are current
  anv: Transition more color buffer layouts
  anv/cmd_buffer: Disable CCS on gen7 color attachments upfront
  anv/cmd_buffer: Always enable CCS_D in render passes
  anv/cmd_buffer: Move aux_usage assignment up
  anv/cmd_buffer: Warn about not enabling CCS_E
  anv: Stop resolving CCS implicitly
  anv/cmd_buffer: Skip some input attachment transitions
  intel/blorp: Allow BLORP calls to be predicated
  anv: Predicate fast-clear resolves

 src/intel/blorp/blorp.h|   3 +
 src/intel/blorp/blorp_genX_exec.h  |   3 +
 src/intel/isl/isl.c|   9 +
 src/intel/isl/isl.h|   4 +
 src/intel/vulkan/anv_blorp.c   | 154 +-
 src/intel/vulkan/anv_genX.h|   5 +
 src/intel/vulkan/anv_image.c   |  78 +
 src/intel/vulkan/anv_pass.c|  36 ++-
 src/intel/vulkan/anv_private.h |  29 +-
 src/intel/vulkan/genX_cmd_buffer.c | 607 -
 src/intel/vulkan/genX_gpu_memcpy.c |  40 +++
 11 files changed, 725 insertions(+), 243 deletions(-)

-- 
2.13.1

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

[Mesa-dev] [PATCH v3 04/16] anv/cmd_buffer: Don't partially fast clear image layers

2017-06-28 Thread Nanley Chery

v2: Don't pass in the command buffer (Jason Ekstrand).
v3: Remove an incorrect assertion and an if condition for gen7.

Signed-off-by: Nanley Chery 
---
 src/intel/vulkan/genX_cmd_buffer.c | 31 +++
 1 file changed, 23 insertions(+), 8 deletions(-)

diff --git a/src/intel/vulkan/genX_cmd_buffer.c 
b/src/intel/vulkan/genX_cmd_buffer.c
index 8601d706d1..15927d32ad 100644
--- a/src/intel/vulkan/genX_cmd_buffer.c
+++ b/src/intel/vulkan/genX_cmd_buffer.c
@@ -231,12 +231,14 @@ color_is_zero_one(VkClearColorValue value, enum 
isl_format format)
 }
 
 static void
-color_attachment_compute_aux_usage(struct anv_device *device,
-   struct anv_attachment_state *att_state,
-   struct anv_image_view *iview,
-   VkRect2D render_area,
+color_attachment_compute_aux_usage(struct anv_device * device,
+   struct anv_cmd_state * cmd_state,
+   uint32_t att, VkRect2D render_area,
union isl_color_value *fast_clear_color)
 {
+   struct anv_attachment_state *att_state = _state->attachments[att];
+   struct anv_image_view *iview = cmd_state->framebuffer->attachments[att];
+
if (iview->image->aux_surface.isl.size == 0) {
   att_state->aux_usage = ISL_AUX_USAGE_NONE;
   att_state->input_aux_usage = ISL_AUX_USAGE_NONE;
@@ -274,8 +276,7 @@ color_attachment_compute_aux_usage(struct anv_device 
*device,
   * don't want to deal with now.
   */
  if (iview->isl.base_level > 0 ||
- iview->isl.base_array_layer > 0 ||
- iview->isl.array_len > 1)
+ iview->isl.base_array_layer > 0)
 att_state->fast_clear = false;
   }
 
@@ -283,6 +284,21 @@ color_attachment_compute_aux_usage(struct anv_device 
*device,
   if (GEN_GEN <= 8 && !att_state->clear_color_is_zero_one)
  att_state->fast_clear = false;
 
+  /* We allow fast clears when all aux layers of the miplevel are targeted.
+   * See add_fast_clear_state_buffer() for more information. Also, because
+   * we only either do a fast clear or a normal clear and not both, this
+   * complies with the gen7 restriction of not fast-clearing multiple
+   * layers.
+   */
+  if (cmd_state->framebuffer->layers !=
+  anv_image_aux_layers(iview->image, iview->isl.base_level)) {
+ att_state->fast_clear = false;
+ if (GEN_GEN == 7) {
+anv_perf_warn("Not fast-clearing the first layer in "
+  "a multi-layer fast clear.");
+ }
+  }
+
   if (att_state->fast_clear) {
  memcpy(fast_clear_color->u32, att_state->clear_value.color.uint32,
 sizeof(fast_clear_color->u32));
@@ -611,8 +627,7 @@ genX(cmd_buffer_setup_attachments)(struct anv_cmd_buffer 
*cmd_buffer,
  union isl_color_value clear_color = { .u32 = { 0, } };
  if (att_aspects == VK_IMAGE_ASPECT_COLOR_BIT) {
 color_attachment_compute_aux_usage(cmd_buffer->device,
-   >attachments[i],
-   iview, begin->renderArea,
+   state, i, begin->renderArea,
_color);
 
 struct isl_view view = iview->isl;
-- 
2.13.1

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

[Mesa-dev] [PATCH v3 01/16] intel/isl: Add surface state clear value information

2017-06-28 Thread Nanley Chery

This will be used to load and store clear values from surface state
objects.

Signed-off-by: Nanley Chery 
---
 src/intel/isl/isl.c | 9 +
 src/intel/isl/isl.h | 4 
 2 files changed, 13 insertions(+)

diff --git a/src/intel/isl/isl.c b/src/intel/isl/isl.c
index bbbdb19df2..26e1676d61 100644
--- a/src/intel/isl/isl.c
+++ b/src/intel/isl/isl.c
@@ -73,6 +73,15 @@ isl_device_init(struct isl_device *dev,
dev->ss.size = RENDER_SURFACE_STATE_length(info) * 4;
dev->ss.align = isl_align(dev->ss.size, 32);
 
+   dev->ss.clear_value_size =
+  isl_align(RENDER_SURFACE_STATE_RedClearColor_bits(info) +
+RENDER_SURFACE_STATE_GreenClearColor_bits(info) +
+RENDER_SURFACE_STATE_BlueClearColor_bits(info) +
+RENDER_SURFACE_STATE_AlphaClearColor_bits(info), 32) / 8;
+
+   dev->ss.clear_value_offset =
+  RENDER_SURFACE_STATE_RedClearColor_start(info) / 32 * 4;
+
assert(RENDER_SURFACE_STATE_SurfaceBaseAddress_start(info) % 8 == 0);
dev->ss.addr_offset =
   RENDER_SURFACE_STATE_SurfaceBaseAddress_start(info) / 8;
diff --git a/src/intel/isl/isl.h b/src/intel/isl/isl.h
index 07ff01a427..2b5c36218b 100644
--- a/src/intel/isl/isl.h
+++ b/src/intel/isl/isl.h
@@ -919,6 +919,10 @@ struct isl_device {
   uint8_t align;
   uint8_t addr_offset;
   uint8_t aux_addr_offset;
+
+  /* Rounded up to the nearest dword to simplify GPU memcpy operations. */
+  uint8_t clear_value_size;
+  uint8_t clear_value_offset;
} ss;
 
/**
-- 
2.13.1

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

Re: [Mesa-dev] [PATCH 16/30] i965/miptree: Move CCS allocation into create_for_dri_image

2017-06-28 Thread Chad Versace

On Fri 16 Jun 2017, Jason Ekstrand wrote:
> Any form of CCS on gen9+ only works on Y-tiled images.  The only caller
> of create_for_bo which uses Y-tiled BOs is create_for_dri_image.

If I understand ARC++ correctly, then intel_update_image_buffer() also
calls intel_miptree_create_for_bo() for Android Y-tiled winsys buffers.
(I've confirmed it with code inspection, but not with actual debug
logging). That should be noted in the commit message.

This patch shouldn't degrade ARC++ performance, though, because ARC++ is
still using an old Mesa that never allocated CCS for Android winsys
buffers.

At the end of the patch series, will Android's Y-tiled winsys buffers
get the benefit of a private CCS?

> +   /* Since CCS_E can compress more than just clear color, we create the
> +* CCS for it up-front.  For CCS_D which only compresses clears, we
> +* create the CCS on-demand when a clear occurs that wants one.
> +*/
> +   if (mt->aux_usage == ISL_AUX_USAGE_CCS_E) {
> +  if (!intel_miptree_alloc_ccs(brw, mt)) {
> + intel_miptree_release();
> + return NULL;
> +  }
> +   }
> +

The above hunk is a duplicate. The same 'if' tree appears immediately
above it.

With the hunk de-duplicated, this patch is
Reviewed-by: Chad Versace 

> return mt;
>  }
>  
> -- 
> 2.5.0.400.gff86faf
> 
> ___
> 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 101467] swr driver leaks memory (texture management)

2017-06-28 Thread bugzilla-daemon

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

--- Comment #1 from Bruce Cherniak  ---
Well, technically the swr driver isn't "leaking" memory, it's just deferring
deletion of the underlying storage until a sync point.

Because the loop is simply:
   for (bigly_number_of_textures) {
  allocate_texture()
  draw_something()
  delete_texture()
   }
   read_pixels()

There is nothing forcing synchronization until the read_pixels.  So, at the end
of the loop, there are 5000 free() queued up, that all get flushed on the
read_pixels.  This accounts for ~20GB of allocated system memory.

-- 
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] gallium: Reduce trace_dump_box_bytes size by box->x.

2017-06-28 Thread Marek Olšák

On Wed, Jun 28, 2017 at 6:54 PM, Cherniak, Bruce
 wrote:
>
>> On Jun 26, 2017, at 2:10 PM, Marek Olšák  wrote:
>>
>> In my opinion, dumping resources isn't very useful. I think it would
>> be better to remove that completely.
>
> From Michel's response, sounds like dumping resources is useful, so... Back 
> to my original
> question, is this a valid fix?  It prevents a crash that happens on occasion 
> while running
> GALLIUM_TRACE.
>
> I too would be interested in learning how to replay traces.  Would be very 
> handy.

I don't think you can change the stride like that. It doesn't seem correct.

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

Re: [Mesa-dev] [PATCH 1/3] mesa: Add _mesa_format_fallback_rgbx_to_rgba() [v2]

2017-06-28 Thread Rob Herring

On Tue, Jun 27, 2017 at 1:00 PM, Chad Versace  wrote:
> The new function takes a mesa_format and, if the format is an alpha
> format with a non-alpha variant, returns the non-alpha format.
> Otherwise, it returns the original format.

[...]

> @@ -123,6 +124,17 @@ $(intermediates)/main/get_hash.h: 
> $(glapi)/gl_and_es_API.xml \
> $(LOCAL_PATH)/main/get_hash_params.py $(GET_HASH_GEN)
> $(call es-gen)
>
> +FORMAT_FALLBACK := $(LOCAL_PATH)/main/format_fallback.py
> +format_fallback_deps := \
> +   $(LOCAL_PATH)/main/formats.csv \
> +   $(LOCAL_PATH)/main/format_parser.py \
> +   $(FORMAT_FALLBACK)
> +
> +$(intermediates)/main/format_fallback.c: PRIVATE_SCRIPT := $(MESA_PYTHON2) 
> $(FORMAT_FALLBACK)
> +$(intermediates)/main/format_fallback.c: PRIVATE_XML :=
> +$(intermediates)/main/format_fallback.c: $(format_fallback_deps)
> +   $(call es-gen, $<)

This breaks on Android because the script wants the output in $2 and
es-gen outputs to stdout:

FAILED: 
out/target/product/linaro_x86_64/gen/STATIC_LIBRARIES/libmesa_st_mesa_intermediates/main/format_fallback.c
/bin/bash -c "python external/mesa3d/src/mesa/main/format_fallback.py
external/mesa3d/src/mesa/main/formats.csv  >
out/target/product/linaro_x86_64/gen/STATIC_LIBRARIES/libmesa_st_mesa_intermediates/main/format_fallback.c"
usage: format_fallback.py [-h] csv out
format_fallback.py: error: too few arguments

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

Re: [Mesa-dev] [PATCH 26/30] intel/isl: Add a row_pitch parameter to surf_get_ccs_surf

2017-06-28 Thread Chad Versace

On Fri 16 Jun 2017, Jason Ekstrand wrote:
> ---
>  src/intel/isl/isl.c   | 4 +++-
>  src/intel/isl/isl.h   | 3 ++-
>  src/intel/vulkan/anv_image.c  | 2 +-
>  src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 8 +---
>  4 files changed, 11 insertions(+), 6 deletions(-)

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

Re: [Mesa-dev] [PATCH 5/5] dri3: Use SwapBuffer flips for back- and fake front

2017-06-28 Thread Thomas Hellstrom


On 06/28/2017 08:48 PM, Axel Davy wrote:

On 28/06/2017 20:40, Thomas Hellstrom wrote:

On 06/28/2017 07:36 PM, Axel Davy wrote:

Hi,

To my knowledge, this is invalid to switch the front fake buffer 
with the back buffer.


The front buffer is supposed to take into account what the app draws 
with the xserver commands, etc.


SwapBuffers should bring the contents of the back buffer to the front 
(and fake front if applicable) buffer, and the backbuffer contents 
become undefined, or tagged with a certain age. None of this is 
violated here. The old back buffer will become the new fake front and 
appropriately synced with X rendering as needed.


Is there a specific scenario you are concerned with?


When I investigated the use of front buffer when writing the patch to 
add secondary gpu support, I understood almost all apps don't use 
front buffer at all, but when they do, it's to interact with the real 
content displayed to the user, which can see some modifications.


So this behaviour doesn't change with the patch. As soon as the old back 
buffer is swapped in place as the new fake front, it starts 
synchronizing with the X rendered content when needed. Specifically that 
happens during glXWaitGL and glXWaitX.


/Thomas

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

[Mesa-dev] [Bug 100951] vkcube fails with vkMapMemory failed

2017-06-28 Thread bugzilla-daemon

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

--- Comment #1 from Fabian Maurer  ---
Still present with 7bbcf3ac70.

-- 
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 101614] OSMesa 17.1.3 simd16intrin build FAIL on Win/MinGW - 'expected initializer before _simd16_setzero_ps ...'

2017-06-28 Thread bugzilla-daemon

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

--- Comment #2 from Trevor SANDY  ---
Hi George,
Unfortunately no, I have not. 

My solution is Qt-based and I use QMake across all platforms (OSX, Linux and
Win). For Win, I use the MinGW/GCC toolchain.

Just the check, I ran the installation on the latest git source as there were
some updates to simd16intrin.h since 17.1.3. However, the behaviour is the
same. The build fails in precisely the same place. You can see the log output
here: https://gist.github.com/trevorsandy/b7c3275dabe6494c247e3ebece28ebbd

Perhaps the SWR driver is not currently buildable on Win/MinGW ?

I've seen several Win/MSVS build configurations, including those in the source
for AppVeyor and Travis, but none appear to target osmesa with llvm and swr
drivers - which is the configuration I'm looking to build.

Cheers,

-- 
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] ac/nir: Use correct LLVM intrinsics for atomic ops on imageBuffers

2017-06-28 Thread Bas Nieuwenhuizen

Thanks, pushed.

On Mon, Jun 26, 2017 at 6:17 PM, Alex Smith  wrote:
> The buffer intrinsics should be used instead of the image ones.
>
> Signed-off-by: Alex Smith 
> Cc: 
> ---
> This applies on top of James Legg's recent series [1], since they both
> touch the same function.
>
> [1] https://lists.freedesktop.org/archives/mesa-dev/2017-June/160245.html
> ---
>  src/amd/common/ac_nir_to_llvm.c | 63 
> ++---
>  1 file changed, 34 insertions(+), 29 deletions(-)
>
> diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
> index 5e9f147..468ce4d 100644
> --- a/src/amd/common/ac_nir_to_llvm.c
> +++ b/src/amd/common/ac_nir_to_llvm.c
> @@ -3369,37 +3369,14 @@ static LLVMValueRef visit_image_atomic(struct 
> nir_to_llvm_context *ctx,
> int param_count = 0;
> const nir_variable *var = instr->variables[0]->var;
>
> -   const char *base_name = "llvm.amdgcn.image.atomic";
> const char *atomic_name;
> -   LLVMValueRef coords;
> -   char intrinsic_name[41], coords_type[8];
> +   char intrinsic_name[41];
> const struct glsl_type *type = glsl_without_array(var->type);
> +   MAYBE_UNUSED int length;
>
> if (ctx->stage == MESA_SHADER_FRAGMENT)
> ctx->shader_info->fs.writes_memory = true;
>
> -   params[param_count++] = get_src(ctx, instr->src[2]);
> -   if (instr->intrinsic == nir_intrinsic_image_atomic_comp_swap)
> -   params[param_count++] = get_src(ctx, instr->src[3]);
> -
> -   if (glsl_get_sampler_dim(type) == GLSL_SAMPLER_DIM_BUF) {
> -   params[param_count++] = get_sampler_desc(ctx, 
> instr->variables[0], DESC_BUFFER);
> -   coords = params[param_count++] = 
> LLVMBuildExtractElement(ctx->builder, get_src(ctx, instr->src[0]),
> -   
> LLVMConstInt(ctx->i32, 0, false), ""); /* vindex */
> -   params[param_count++] = ctx->i32zero; /* voffset */
> -   params[param_count++] = ctx->i1false;  /* glc */
> -   params[param_count++] = ctx->i1false;  /* slc */
> -   } else {
> -   bool da = glsl_sampler_type_is_array(type) ||
> - glsl_get_sampler_dim(type) == GLSL_SAMPLER_DIM_CUBE;
> -
> -   coords = params[param_count++] = get_image_coords(ctx, instr);
> -   params[param_count++] = get_sampler_desc(ctx, 
> instr->variables[0], DESC_IMAGE);
> -   params[param_count++] = ctx->i1false; /* r128 */
> -   params[param_count++] = da ? ctx->i1true : ctx->i1false;  
> /* da */
> -   params[param_count++] = ctx->i1false;  /* slc */
> -   }
> -
> switch (instr->intrinsic) {
> case nir_intrinsic_image_atomic_add:
> atomic_name = "add";
> @@ -3428,11 +3405,39 @@ static LLVMValueRef visit_image_atomic(struct 
> nir_to_llvm_context *ctx,
> default:
> abort();
> }
> -   build_int_type_name(LLVMTypeOf(coords),
> -   coords_type, sizeof(coords_type));
>
> -   MAYBE_UNUSED const int length = snprintf(intrinsic_name, 
> sizeof(intrinsic_name),
> -"%s.%s.%s", base_name, 
> atomic_name, coords_type);
> +   params[param_count++] = get_src(ctx, instr->src[2]);
> +   if (instr->intrinsic == nir_intrinsic_image_atomic_comp_swap)
> +   params[param_count++] = get_src(ctx, instr->src[3]);
> +
> +   if (glsl_get_sampler_dim(type) == GLSL_SAMPLER_DIM_BUF) {
> +   params[param_count++] = get_sampler_desc(ctx, 
> instr->variables[0], DESC_BUFFER);
> +   params[param_count++] = LLVMBuildExtractElement(ctx->builder, 
> get_src(ctx, instr->src[0]),
> +   
> LLVMConstInt(ctx->i32, 0, false), ""); /* vindex */
> +   params[param_count++] = ctx->i32zero; /* voffset */
> +   params[param_count++] = ctx->i1false;  /* slc */
> +
> +   length = snprintf(intrinsic_name, sizeof(intrinsic_name),
> + "llvm.amdgcn.buffer.atomic.%s", 
> atomic_name);
> +   } else {
> +   char coords_type[8];
> +
> +   bool da = glsl_sampler_type_is_array(type) ||
> + glsl_get_sampler_dim(type) == GLSL_SAMPLER_DIM_CUBE;
> +
> +   LLVMValueRef coords = params[param_count++] = 
> get_image_coords(ctx, instr);
> +   params[param_count++] = get_sampler_desc(ctx, 
> instr->variables[0], DESC_IMAGE);
> +   params[param_count++] = ctx->i1false; /* r128 */
> +   params[param_count++] = da ? ctx->i1true : ctx->i1false;  
> /* da */
> +   params[param_count++] = ctx->i1false;  /* slc */
> +

Re: [Mesa-dev] [PATCH v2 3/3] ac/nir: assert printfs will fit

2017-06-28 Thread Bas Nieuwenhuizen

Thanks, pushed patches 2& 3.

On Mon, Jun 26, 2017 at 10:05 AM, Nicolai Hähnle  wrote:
> Patches 2 & 3:
>
> Reviewed-by: Nicolai Hähnle 
>
>
> On 23.06.2017 12:18, James Legg wrote:
>>
>> ---
>>   src/amd/common/ac_nir_to_llvm.c | 17 -
>>   1 file changed, 12 insertions(+), 5 deletions(-)
>>
>> diff --git a/src/amd/common/ac_nir_to_llvm.c
>> b/src/amd/common/ac_nir_to_llvm.c
>> index 3a26668..b32a9f5 100644
>> --- a/src/amd/common/ac_nir_to_llvm.c
>> +++ b/src/amd/common/ac_nir_to_llvm.c
>> @@ -1134,7 +1134,9 @@ static LLVMValueRef emit_intrin_1f_param(struct
>> nir_to_llvm_context *ctx,
>> to_float(ctx, src0),
>> };
>>   - sprintf(name, "%s.f%d", intrin, get_elem_bits(ctx, result_type));
>> +   MAYBE_UNUSED const int length = snprintf(name, sizeof(name),
>> "%s.f%d", intrin,
>> +get_elem_bits(ctx,
>> result_type));
>> +   assert(length < sizeof(name));
>> return ac_build_intrinsic(>ac, name, result_type, params, 1,
>> AC_FUNC_ATTR_READNONE);
>>   }
>>   @@ -1149,7 +1151,9 @@ static LLVMValueRef emit_intrin_2f_param(struct
>> nir_to_llvm_context *ctx,
>> to_float(ctx, src1),
>> };
>>   - sprintf(name, "%s.f%d", intrin, get_elem_bits(ctx, result_type));
>> +   MAYBE_UNUSED const int length = snprintf(name, sizeof(name),
>> "%s.f%d", intrin,
>> +get_elem_bits(ctx,
>> result_type));
>> +   assert(length < sizeof(name));
>> return ac_build_intrinsic(>ac, name, result_type, params, 2,
>> AC_FUNC_ATTR_READNONE);
>>   }
>>   @@ -1165,7 +1169,9 @@ static LLVMValueRef emit_intrin_3f_param(struct
>> nir_to_llvm_context *ctx,
>> to_float(ctx, src2),
>> };
>>   - sprintf(name, "%s.f%d", intrin, get_elem_bits(ctx, result_type));
>> +   MAYBE_UNUSED const int length = snprintf(name, sizeof(name),
>> "%s.f%d", intrin,
>> +get_elem_bits(ctx,
>> result_type));
>> +   assert(length < sizeof(name));
>> return ac_build_intrinsic(>ac, name, result_type, params, 3,
>> AC_FUNC_ATTR_READNONE);
>>   }
>>   @@ -3425,8 +3431,9 @@ static LLVMValueRef visit_image_atomic(struct
>> nir_to_llvm_context *ctx,
>> build_int_type_name(LLVMTypeOf(coords),
>> coords_type, sizeof(coords_type));
>>   - snprintf(intrinsic_name, sizeof(intrinsic_name),
>> -"%s.%s.%s", base_name, atomic_name, coords_type);
>> +   MAYBE_UNUSED const int length = snprintf(intrinsic_name,
>> sizeof(intrinsic_name),
>> +"%s.%s.%s", base_name,
>> atomic_name, coords_type);
>> +   assert(length < sizeof(intrinsic_name));
>> return ac_build_intrinsic(>ac, intrinsic_name, ctx->i32,
>> params, param_count, 0);
>>   }
>>
>
>
>
> --
> Lerne, wie die Welt wirklich ist,
> Aber vergiss niemals, wie sie sein sollte.
>
> ___
> 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] ac/nir: remove last remnants of v16i8

2017-06-28 Thread Dave Airlie

From: Dave Airlie 

llvm doesn't need this workaround anymore.

Signed-off-by: Dave Airlie 
---
 src/amd/common/ac_llvm_build.c  |  1 -
 src/amd/common/ac_llvm_build.h  |  1 -
 src/amd/common/ac_nir_to_llvm.c | 10 +++---
 3 files changed, 3 insertions(+), 9 deletions(-)

diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c
index 9d78b12..2cc4eae 100644
--- a/src/amd/common/ac_llvm_build.c
+++ b/src/amd/common/ac_llvm_build.c
@@ -65,7 +65,6 @@ ac_llvm_context_init(struct ac_llvm_context *ctx, 
LLVMContextRef context)
ctx->v4i32 = LLVMVectorType(ctx->i32, 4);
ctx->v4f32 = LLVMVectorType(ctx->f32, 4);
ctx->v8i32 = LLVMVectorType(ctx->i32, 8);
-   ctx->v16i8 = LLVMVectorType(ctx->i8, 16);
 
ctx->i32_0 = LLVMConstInt(ctx->i32, 0, false);
ctx->i32_1 = LLVMConstInt(ctx->i32, 1, false);
diff --git a/src/amd/common/ac_llvm_build.h b/src/amd/common/ac_llvm_build.h
index b9aeacd..10efabb 100644
--- a/src/amd/common/ac_llvm_build.h
+++ b/src/amd/common/ac_llvm_build.h
@@ -49,7 +49,6 @@ struct ac_llvm_context {
LLVMTypeRef v4i32;
LLVMTypeRef v4f32;
LLVMTypeRef v8i32;
-   LLVMTypeRef v16i8;
 
LLVMValueRef i32_0;
LLVMValueRef i32_1;
diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index 8877c22..191d68e 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -136,7 +136,6 @@ struct nir_to_llvm_context {
LLVMTypeRef f16;
LLVMTypeRef v2f32;
LLVMTypeRef v4f32;
-   LLVMTypeRef v16i8;
LLVMTypeRef voidt;
 
LLVMValueRef i1true;
@@ -715,7 +714,7 @@ static void create_function(struct nir_to_llvm_context *ctx)
 
allocate_user_sgprs(ctx, _sgpr_info);
if (user_sgpr_info.need_ring_offsets && !ctx->options->supports_spill) {
-   add_user_sgpr_argument(, const_array(ctx->v16i8, 16), 
>ring_offsets); /* address of rings */
+   add_user_sgpr_argument(, const_array(ctx->v4i32, 16), 
>ring_offsets); /* address of rings */
}
 
/* 1 for each descriptor set */
@@ -744,7 +743,7 @@ static void create_function(struct nir_to_llvm_context *ctx)
case MESA_SHADER_VERTEX:
if (!ctx->is_gs_copy_shader) {
if (ctx->shader_info->info.vs.has_vertex_buffers)
-   add_user_sgpr_argument(, 
const_array(ctx->v16i8, 16), >vertex_buffers); /* vertex buffers */
+   add_user_sgpr_argument(, 
const_array(ctx->v4i32, 16), >vertex_buffers); /* vertex buffers */
add_user_sgpr_argument(, ctx->i32, 
>base_vertex); // base vertex
add_user_sgpr_argument(, ctx->i32, 
>start_instance);// start instance
if (ctx->shader_info->info.vs.needs_draw_id)
@@ -853,7 +852,7 @@ static void create_function(struct nir_to_llvm_context *ctx)
   
LLVMPointerType(ctx->i8, CONST_ADDR_SPACE),
   NULL, 0, 
AC_FUNC_ATTR_READNONE);
ctx->ring_offsets = LLVMBuildBitCast(ctx->builder, 
ctx->ring_offsets,
-
const_array(ctx->v16i8, 16), "");
+
const_array(ctx->v4i32, 16), "");
}
}
 
@@ -945,7 +944,6 @@ static void setup_types(struct nir_to_llvm_context *ctx)
ctx->f64 = LLVMDoubleTypeInContext(ctx->context);
ctx->v2f32 = LLVMVectorType(ctx->f32, 2);
ctx->v4f32 = LLVMVectorType(ctx->f32, 4);
-   ctx->v16i8 = LLVMVectorType(ctx->i8, 16);
 
ctx->i1false = LLVMConstInt(ctx->i1, 0, false);
ctx->i1true = LLVMConstInt(ctx->i1, 1, false);
@@ -5863,8 +5861,6 @@ ac_setup_rings(struct nir_to_llvm_context *ctx)
tmp = LLVMBuildExtractElement(ctx->builder, ctx->gsvs_ring, 
ctx->i32one, "");
tmp = LLVMBuildOr(ctx->builder, tmp, ctx->gsvs_ring_stride, "");
ctx->gsvs_ring = LLVMBuildInsertElement(ctx->builder, 
ctx->gsvs_ring, tmp, ctx->i32one, "");
-
-   ctx->gsvs_ring = LLVMBuildBitCast(ctx->builder, ctx->gsvs_ring, 
ctx->v16i8, "");
}
 
if (ctx->stage == MESA_SHADER_TESS_CTRL ||
-- 
2.9.4

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

[Mesa-dev] [Bug 101614] OSMesa 17.1.3 simd16intrin build FAIL on Win/MinGW - 'expected initializer before _simd16_setzero_ps ...'

2017-06-28 Thread bugzilla-daemon

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

--- Comment #1 from George Kyriazis  ---
Trevor,

have you tried compiling with devenv?  We don't have a problem compiling 17.1.3
there.

We haven't tried compiling with mingw.

-- 
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] swr: Remove need to allocate vertex buffer scratch space all in one go.

2017-06-28 Thread Bruce Cherniak

Deferred deletion (via "fence_work") has obsoleted the need to allocate
all client vertex buffer scratch space in a single chunk.  Scratch
allocations are now valid until the referenced fence is complete.
---
 src/gallium/drivers/swr/swr_state.cpp | 25 ++---
 1 file changed, 2 insertions(+), 23 deletions(-)

diff --git a/src/gallium/drivers/swr/swr_state.cpp 
b/src/gallium/drivers/swr/swr_state.cpp
index 6dc06ed156..7a8786d96f 100644
--- a/src/gallium/drivers/swr/swr_state.cpp
+++ b/src/gallium/drivers/swr/swr_state.cpp
@@ -1219,32 +1219,12 @@ swr_update_derived(struct pipe_context *pipe,
 */
if (ctx->dirty & SWR_NEW_VERTEX ||
   (p_draw_info && p_draw_info->index_size)) {
-  uint32_t scratch_total;
-  uint8_t *scratch = NULL;
 
   /* If being called by swr_draw_vbo, copy draw details */
   struct pipe_draw_info info = {0};
   if (p_draw_info)
  info = *p_draw_info;
 
-  /* We must get all the scratch space in one go */
-  scratch_total = 0;
-  for (UINT i = 0; i < ctx->num_vertex_buffers; i++) {
- struct pipe_vertex_buffer *vb = >vertex_buffer[i];
-
- if (!vb->is_user_buffer)
-continue;
-
- uint32_t elems, base, size;
- swr_user_vbuf_range(, ctx->velems, vb, i, , , );
- scratch_total += AlignUp(size, 4);
-  }
-
-  if (scratch_total) {
- scratch = (uint8_t *)swr_copy_to_scratch_space(
-   ctx, >scratch->vertex_buffer, NULL, scratch_total);
-  }
-
   /* vertex buffers */
   SWR_VERTEX_BUFFER_STATE swrVertexBuffers[PIPE_MAX_ATTRIBS];
   for (UINT i = 0; i < ctx->num_vertex_buffers; i++) {
@@ -1289,9 +1269,8 @@ swr_update_derived(struct pipe_context *pipe,
 /* Copy only needed vertices to scratch space */
 size = AlignUp(size, 4);
 const void *ptr = (const uint8_t *) vb->buffer.user + base;
-memcpy(scratch, ptr, size);
-ptr = scratch;
-scratch += size;
+ptr = (uint8_t *)swr_copy_to_scratch_space(
+   ctx, >scratch->vertex_buffer, ptr, size);
 p_data = (const uint8_t *)ptr - base;
  }
 
-- 
2.11.0

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

Re: [Mesa-dev] [PATCH 5/5] dri3: Use SwapBuffer flips for back- and fake front

2017-06-28 Thread Thomas Hellstrom


On 06/28/2017 07:36 PM, Axel Davy wrote:

Hi,

To my knowledge, this is invalid to switch the front fake buffer with 
the back buffer.


The front buffer is supposed to take into account what the app draws 
with the xserver commands, etc.


SwapBuffers should bring the contents of the back buffer to the front 
(and fake front if applicable) buffer, and the backbuffer contents 
become undefined, or tagged with a certain age. None of this is violated 
here. The old back buffer will become the new fake front and 
appropriately synced with X rendering as needed.


Is there a specific scenario you are concerned with?



Plus, if there is draw->width and back->width, I guess they can be 
different size, thus switching may be incorrect relative to buffer 
size too.


Fake front and back are resized at the same time with dri3 AFAICT. This 
means that with respect to dimensions, the new code should be equivalent 
to the old one.




Yours,

Axel Davy


Thanks,

Thomas





On 22/06/2017 12:42, Thomas Hellstrom wrote:

Use flips for back- and fake front buffers.
This might lead to fake front and real front being shared if the 
hardware

is page-flip capable.

In any case it will save a full-drawable copy and also the subsequent 
wait for

the X server to submit that copy to hardware if front-buffer reading or
rendering is enabled.

Signed-off-by: Thomas Hellstrom 
---
  src/loader/loader_dri3_helper.c | 26 --
  1 file changed, 8 insertions(+), 18 deletions(-)

diff --git a/src/loader/loader_dri3_helper.c 
b/src/loader/loader_dri3_helper.c

index f012e55..041bfc4 100644
--- a/src/loader/loader_dri3_helper.c
+++ b/src/loader/loader_dri3_helper.c
@@ -652,14 +652,14 @@ loader_dri3_swap_buffers_msc(struct 
loader_dri3_drawable *draw,

back->height,
0, 0, back->width,
back->height, __BLIT_FLAG_FLUSH);
-  /* Update the fake front */
-  if (draw->have_fake_front)
- draw->ext->image->blitImage(dri_context,
- draw->buffers[LOADER_DRI3_FRONT_ID]->image,
- back->image,
- 0, 0, draw->width, draw->height,
- 0, 0, draw->width, draw->height,
- __BLIT_FLAG_FLUSH);
+   }
+
+   if (back && draw->have_fake_front) {
+  struct loader_dri3_buffer *tmp;
+
+  tmp = dri3_fake_front_buffer(draw);
+  draw->buffers[LOADER_DRI3_FRONT_ID] = back;
+  draw->buffers[LOADER_DRI3_BACK_ID(draw->cur_back)] = tmp;
 }
   dri3_flush_present_events(draw);
@@ -727,16 +727,6 @@ loader_dri3_swap_buffers_msc(struct 
loader_dri3_drawable *draw,

 * to reset the fence and make future users block until
 * the X server is done copying the bits
 */
-  if (draw->have_fake_front && !draw->is_different_gpu) {
- dri3_fence_reset(draw->conn, 
draw->buffers[LOADER_DRI3_FRONT_ID]);

- dri3_copy_area(draw->conn,
-back->pixmap,
- draw->buffers[LOADER_DRI3_FRONT_ID]->pixmap,
-dri3_drawable_gc(draw),
-0, 0, 0, 0,
-draw->width, draw->height);
- dri3_fence_trigger(draw->conn, 
draw->buffers[LOADER_DRI3_FRONT_ID]);

-  }
xcb_flush(draw->conn);
if (draw->stamp)
   ++(*draw->stamp);





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

Re: [Mesa-dev] [PATCH 23/30] intel/isl: Add support for I915_FORMAT_MOD_Y_TILED_CCS

2017-06-28 Thread Chad Versace

On Fri 16 Jun 2017, Jason Ekstrand wrote:
> ---
>  src/intel/isl/isl_drm.c | 11 +++
>  1 file changed, 11 insertions(+)

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

[Mesa-dev] [PATCH] vc4: Introduce XML-based packet header generation like Intel's.

2017-06-28 Thread Eric Anholt

I really liked this idea, as it should help with management of packet
parsing tools like the CL dump.  The python script is forked off of theirs
because our packets are byte-based instead of dwords, and the changes to
do so while avoiding performance regressions due to unaligned accesses
were quite invasive.
---

I'm hoping for an ack from Jason or Kenneth on the genxml script fork
to the new location, and an Android test from Rob.  Full branch using
the XML stuff is at vc4-xml of my Mesa tree.

 Android.mk |   1 +
 configure.ac   |   1 +
 src/Makefile.am|   4 +
 src/broadcom/.gitignore|   1 +
 .../Android.genxml.mk} |  43 +-
 src/{intel => broadcom}/Android.mk |   5 -
 src/{amd => broadcom}/Makefile.am  |  22 +-
 .../Makefile.genxml.am}|  18 +-
 src/broadcom/Makefile.sources  |  12 +
 src/broadcom/cle/gen_pack_header.py| 547 +
 src/broadcom/cle/v3d_packet_helpers.h  | 189 +++
 src/broadcom/cle/v3d_packet_v21.xml| 220 +
 src/gallium/drivers/vc4/Android.mk |   5 +-
 13 files changed, 1035 insertions(+), 33 deletions(-)
 create mode 100644 src/broadcom/.gitignore
 copy src/{mesa/Android.libmesa_git_sha1.mk => broadcom/Android.genxml.mk} (60%)
 copy src/{intel => broadcom}/Android.mk (86%)
 copy src/{amd => broadcom}/Makefile.am (75%)
 copy src/{intel/Makefile.common.am => broadcom/Makefile.genxml.am} (74%)
 create mode 100644 src/broadcom/Makefile.sources
 create mode 100644 src/broadcom/cle/gen_pack_header.py
 create mode 100644 src/broadcom/cle/v3d_packet_helpers.h
 create mode 100644 src/broadcom/cle/v3d_packet_v21.xml

diff --git a/Android.mk b/Android.mk
index 418570e607bb..9203c87a4e35 100644
--- a/Android.mk
+++ b/Android.mk
@@ -112,6 +112,7 @@ SUBDIRS := \
src/util \
src/egl \
src/amd \
+   src/broadcom \
src/intel \
src/mesa/drivers/dri \
src/vulkan
diff --git a/configure.ac b/configure.ac
index c9dc51bc0d86..cb5d6683afe6 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2734,6 +2734,7 @@ AC_CONFIG_FILES([Makefile
src/Makefile
src/amd/Makefile
src/amd/vulkan/Makefile
+   src/broadcom/Makefile
src/compiler/Makefile
src/egl/Makefile
src/egl/main/egl.pc
diff --git a/src/Makefile.am b/src/Makefile.am
index df912c442af1..1f18cb65699a 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -93,6 +93,10 @@ if HAVE_INTEL_DRIVERS
 SUBDIRS += intel
 endif
 
+if HAVE_GALLIUM_VC4
+SUBDIRS += broadcom
+endif
+
 if NEED_OPENGL_COMMON
 SUBDIRS += mesa
 endif
diff --git a/src/broadcom/.gitignore b/src/broadcom/.gitignore
new file mode 100644
index ..fcc603f0cf01
--- /dev/null
+++ b/src/broadcom/.gitignore
@@ -0,0 +1 @@
+cle/*_pack.h
diff --git a/src/mesa/Android.libmesa_git_sha1.mk 
b/src/broadcom/Android.genxml.mk
similarity index 60%
copy from src/mesa/Android.libmesa_git_sha1.mk
copy to src/broadcom/Android.genxml.mk
index 0fd176bf7d5d..461efd61085f 100644
--- a/src/mesa/Android.libmesa_git_sha1.mk
+++ b/src/broadcom/Android.genxml.mk
@@ -1,6 +1,5 @@
-# Mesa 3-D graphics library
-#
-# Copyright (C) 2017 Mauro Rossi 
+# Copyright © 2016 Intel Corporation
+# Copyright © 2016 Mauro Rossi 
 #
 # Permission is hereby granted, free of charge, to any person obtaining a
 # copy of this software and associated documentation files (the "Software"),
@@ -19,18 +18,18 @@
 # LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
 # FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
 # DEALINGS IN THE SOFTWARE.
+#
 
-# --
-# libmesa_git_sha1
-# --
-
-LOCAL_PATH := $(call my-dir)
+# ---
+# Build libmesa_genxml
+# ---
 
 include $(CLEAR_VARS)
 
-LOCAL_MODULE := libmesa_git_sha1
+LOCAL_MODULE := libmesa_broadcom_genxml
 
 LOCAL_MODULE_CLASS := STATIC_LIBRARIES
+
 intermediates := $(call local-generated-sources-dir)
 
 # dummy.c source file is generated to meet the build system's rules.
@@ -41,19 +40,23 @@ $(intermediates)/dummy.c:
@echo "Gen Dummy: $(PRIVATE_MODULE) <= $(notdir $(@))"
$(hide) touch $@
 
-LOCAL_GENERATED_SOURCES += $(addprefix $(intermediates)/, git_sha1.h)
+# This is the list of auto-generated files headers
+LOCAL_GENERATED_SOURCES += $(addprefix $(intermediates)/, 
$(BROADCOM_GENXML_GENERATED_FILES))
 
-$(intermediates)/git_sha1.h: $(wildcard $(MESA_TOP)/.git/logs/HEAD)
+define header-gen
@mkdir -p $(dir

Re: [Mesa-dev] [PATCH 13/30] i965/miptree: Add an explicit format parameter to create_for_dri_image

2017-06-28 Thread Jason Ekstrand

On Wed, Jun 28, 2017 at 10:59 AM, Daniel Stone  wrote:

> Hi,
>
> On 28 June 2017 at 16:35, Jason Ekstrand  wrote:
> > On Wed, Jun 28, 2017 at 4:06 AM, Daniel Stone 
> wrote:
> >> On 28 June 2017 at 02:05, Jason Ekstrand  wrote:
> >> > The long answer is that the DRI formats do not specify a colorspace.
> >>
> >> Also, strictly speaking, the DRI_IMAGE_FORMAT_* tokens don't specify a
> >> colourspace, nor do the DRM FourCC tokens. DRI_IMAGE_FOURCC_* is
> >> equivalent to the latter, bar the addition of a special and unique
> >> SARGB8 token, i.e. ARGB with the sRGB transfer function (and
> >> presumably primaries?). The rest are presumed UNORM.
> >
> > Wha?  What's the difference between SARGB8 and ARGB then?  My
> > understanding was that scanout basically treats everything as sRGB
> anyway.
> > Clearly, my sRGB knowledge is imperfect.
>
> GBM_FORMAT_ARGB (aka DRI_IMAGE_FOURCC_ARGB), gets mapped to
> DRI_IMAGE_FORMAT_ARGB, which gets mapped to
> MESA_FORMAT_B8G8R8X8_UNORM (dri_util.c). Only
> DRI_IMAGE_{FORMAT,FOURCC}_SARGB8 (no defined GBM token, but you can
> pass it through the GBM API and it'll work sometimes) gets mapped to a
> MESA_FORMAT_*_SRGB. So AFAICT, to get an sRGB scanout buffer from
> Mesa/GBM, you'd need to allocate UNORM and do inverse-gamma in your
> frag shader.
>
> Wayland similarly never maps anything to sRGB.
>
> X11 always imports EGLImages as UNORM, so blending would be broken in
> a composited environment if we were actually allocating sRGB.
>

Blending *is* broken.  I had a long chat with Owen Taylor about this some
time ago.  Everything comes into X11 sRGB encoded and scanout treats it's
buffer as sRGB.  X11 then stomps everything to UNORM and blends in the
wrong colorspace.


> i965 tries pretty hard to allocate sRGB images in the pre-DRIImage,
> DRI2 (as in the X11 protocol named 'DRI2') codepath, but this isn't
> used by Wayland, GBM, or DRI3.
>

Except that whether you get an sRGB renderbuffer or not is governed by GLX
and EGL and not Wayland/DRI2/DRI3.  In one of them (I think it's ES), the
default is to get an sRGB renderbuffer but either is possible with both
independent of how the image comes in.  We *do* see it on DRI3 and Wayland
which is why this patch exists in the first place.


> So no, not for pretty much any externally-visible images AFAICT. Even
> if it were true for scanout, the client would need to tell KMS, so KMS
> could send a HDMI infoframe telling the display.
>

But scanout always does sRGB.  If you want real UNORM, then you'll have to
add kernel API.


> Colourspaces \_o_/
>
> > As for enums, sure, that can probably happen.  GL and ISL both have enums
> > for colorspace that we could re-use.
>
> Yes, having too few format tokens is not a problem we have. We seem to
> have about as many of those as we have things called 'DRI2'.
>

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

Re: [Mesa-dev] [PATCH 0/2] Fix distcheck

2017-06-28 Thread Lionel Landwerlin


Oops, thanks a lot!

This series is :

Reviewed-by: Lionel Landwerlin 

On 28/06/17 18:47, Juan A. Suarez Romero wrote:

The following two patches fix distcheck.

Juan A. Suarez Romero (2):
   intel: automake: include Makefile.drm.am
   intel: tools: add intel_aub.h as part of aubinator

  src/intel/Makefile.am   | 1 +
  src/intel/Makefile.tools.am | 3 ++-
  2 files changed, 3 insertions(+), 1 deletion(-)



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

Re: [Mesa-dev] [PATCH 13/30] i965/miptree: Add an explicit format parameter to create_for_dri_image

2017-06-28 Thread Daniel Stone

Hi,

On 28 June 2017 at 16:35, Jason Ekstrand  wrote:
> On Wed, Jun 28, 2017 at 4:06 AM, Daniel Stone  wrote:
>> On 28 June 2017 at 02:05, Jason Ekstrand  wrote:
>> > The long answer is that the DRI formats do not specify a colorspace.
>>
>> Also, strictly speaking, the DRI_IMAGE_FORMAT_* tokens don't specify a
>> colourspace, nor do the DRM FourCC tokens. DRI_IMAGE_FOURCC_* is
>> equivalent to the latter, bar the addition of a special and unique
>> SARGB8 token, i.e. ARGB with the sRGB transfer function (and
>> presumably primaries?). The rest are presumed UNORM.
>
> Wha?  What's the difference between SARGB8 and ARGB then?  My
> understanding was that scanout basically treats everything as sRGB anyway.
> Clearly, my sRGB knowledge is imperfect.

GBM_FORMAT_ARGB (aka DRI_IMAGE_FOURCC_ARGB), gets mapped to
DRI_IMAGE_FORMAT_ARGB, which gets mapped to
MESA_FORMAT_B8G8R8X8_UNORM (dri_util.c). Only
DRI_IMAGE_{FORMAT,FOURCC}_SARGB8 (no defined GBM token, but you can
pass it through the GBM API and it'll work sometimes) gets mapped to a
MESA_FORMAT_*_SRGB. So AFAICT, to get an sRGB scanout buffer from
Mesa/GBM, you'd need to allocate UNORM and do inverse-gamma in your
frag shader.

Wayland similarly never maps anything to sRGB.

X11 always imports EGLImages as UNORM, so blending would be broken in
a composited environment if we were actually allocating sRGB.

i965 tries pretty hard to allocate sRGB images in the pre-DRIImage,
DRI2 (as in the X11 protocol named 'DRI2') codepath, but this isn't
used by Wayland, GBM, or DRI3.

So no, not for pretty much any externally-visible images AFAICT. Even
if it were true for scanout, the client would need to tell KMS, so KMS
could send a HDMI infoframe telling the display.

Colourspaces \_o_/

> As for enums, sure, that can probably happen.  GL and ISL both have enums
> for colorspace that we could re-use.

Yes, having too few format tokens is not a problem we have. We seem to
have about as many of those as we have things called 'DRI2'.

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

[Mesa-dev] Mesa 17.1.4 release candidate

2017-06-28 Thread Andres Gomez

Hello list,

The candidate for the Mesa 17.1.4 is now available. Currently we have:
 - 54 queued
 - 0 nominated (outstanding)
 - and 2 rejected patch(es)


In the current queue we have:

In Mesa Core we include some fixes that involve flushing vertices
before some state changes.

The state tracker also received a fix for the Scissor with multiple
viewports.

The SPIR-V compiler has gotten a work around to prevent a shader bug in
Doom.

i965 has gotten many patches, including a couple of fixes for having
proper color interpolation in gen3, a bunch of corrections to avoid
hangings on Haswell, specially with fast-clear operations that happen
at the start of a batch, an initialization of the step rate for
interleaved vertex buffers to avoid rendering errors, a correction to
set the depth offset when there is only stencil attachment, a fix for
incorrect renderings due to using anisotropic filtering in nearest
mode, a fix for gl_Fragcoord's interpolation, a fix for Broxton 2x6 l3
config, a correction in Sky Lake for getting in-range clear colors, and
an improvement in gen7+ has been added to comply with OpenGL 4.1+.

anv has gotten a fix for L3 cache programming on Bay Trail.

Gallivm has seen a fix to avoid a segfault when we get invalid
glDrawRangeElements, a recursion that might have impacted performance
has been broken and, in the VA library, another fix has been added to
avoid memory corruptions.

The etnaviv driver has gotten a handful of patches, including fixes for
some resource copy issues, to prevent some fallout from the RB swapped
rendertarget work, to correct the max LOD bias, and a performance
regression has also been fixed.

The AMD drivers have received a fix for the proper generation of the
sid tables. radeonsi has gotten several improvements, including a new
polaris12 pci id and a deadlock fix while r600 is receiving a fix to
upload PBO textures to compressed textures.

The svga driver has received some patches to invalidate surfaces
correctly and a fix to properly unbind the GS.

nouveau's codegen has seen some improvements, including a fix to
properly fold constants in SPLIT operation.

EGL has gotten a couple of fixes to make the platform detection thread-
safe. The DRI2 drivers include now a fix to properly count configs. In
the case of the Android driver, we also got a workaround for apps which
choose their EGLConfig incorrectly and, in the case of the X11 one, a
crash fix has also been included.

From build and integration point of view, we have added a fix to solve
a linking problem for systems that lack libpthread.so, we have fixed a
recent build problem with Android and we have included also a missing
header for EGL, GLES and VG headers that was not included when EGL
building was disabled.

Take a look at section "Mesa stable queue" for more information.


Testing reports/general approval


Any testing reports (or general approval of the state of the branch)
will be greatly appreciated.

The plan is to have 17.1.4 this Friday (30th of June), around or
shortly after 18:00 GMT.

If you have any questions or suggestions - be that about the current
patch queue or otherwise, please go ahead.


Trivial merge conflicts
---
commit 4379c53b9b6b7a272ab852c908b723cca24d4ca8
Author: Jason Ekstrand 

i965: Take a uint64_t immediate in emit_pipe_control_write

(cherry picked from commit a8ea68bc930f212dddf78a4e2073bcbd698b9140)

commit 4cd15cf137a640a59b7ff8a7208d98306d91dbdf
Author: Anuj Phogat 

i965: Fix broxton 2x6 l3 config

(cherry picked from commit 8521559e086a3d56f549962ab8e9f45a6a5989d8)

commit 695493671af0efaabf039147e19367de926e5d67
Author: Brian Paul 

gallium/vbuf: avoid segfault when we get invalid glDrawRangeElements()

(cherry picked from commit
d8148ed10ae5faea6f88f2f964797f4b0590c083)

commit 863756e6856a0fc3d9b973d5adf995943f736414
Author: Jason Ekstrand 

i965: Clamp clear colors to the representable range

(cherry picked from commit f1fa4be871e13c68b50685aaf64dc095b49ed0b5)


Cheers,
Andres


Mesa stable queue
-

Nominated (0)
==


Queued (54)
===

Alex Deucher (1):
  radeonsi: add new polaris12 pci id

Andres Gomez (2):
  cherry-ignore: 17.1.4 rejected commits
  cherry-ignore: bin/get-fixes-pick-list.sh: better identify multiple 
"fixes:" tags

Anuj Phogat (2):
  i965: Add and initialize l3_banks field for gen7+
  i965: Fix broxton 2x6 l3 config

Ben Crocker (1):
  egl_dri2: swrastGetDrawableInfo: set *x, *y [v2]

Brian Paul (2):
  svga: check return value from svga_set_shader( SVGA3D_SHADERTYPE_GS, NULL)
  gallium/vbuf: avoid segfault when we get invalid glDrawRangeElements()

Chad Versace (1):
  egl/android: Change order of EGLConfig generation (v2)

Chandu Babu N (1):
  change va max_entrypoints

Charmaine Lee (1):
  svga:

[Mesa-dev] [PATCH 2/2] intel: tools: add intel_aub.h as part of aubinator

2017-06-28 Thread Juan A. Suarez Romero

Include intel_aub.h in the Makefile.tools.am
---
 src/intel/Makefile.tools.am | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/intel/Makefile.tools.am b/src/intel/Makefile.tools.am
index 45891e7..8071220 100644
--- a/src/intel/Makefile.tools.am
+++ b/src/intel/Makefile.tools.am
@@ -26,7 +26,8 @@ noinst_PROGRAMS += \
 tools_aubinator_SOURCES = \
tools/aubinator.c \
tools/disasm.c \
-   tools/gen_disasm.h
+   tools/gen_disasm.h \
+   tools/intel_aub.h
 
 tools_aubinator_CFLAGS = \
$(AM_CFLAGS) \
-- 
2.9.4

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

[Mesa-dev] [PATCH 1/2] intel: automake: include Makefile.drm.am

2017-06-28 Thread Juan A. Suarez Romero

---
 src/intel/Makefile.am | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/intel/Makefile.am b/src/intel/Makefile.am
index 269d73d..dad54b7 100644
--- a/src/intel/Makefile.am
+++ b/src/intel/Makefile.am
@@ -62,6 +62,7 @@ EXTRA_DIST =
 include Makefile.blorp.am
 include Makefile.common.am
 include Makefile.compiler.am
+include Makefile.drm.am
 include Makefile.genxml.am
 include Makefile.isl.am
 include Makefile.tools.am
-- 
2.9.4

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

[Mesa-dev] [PATCH 0/2] Fix distcheck

2017-06-28 Thread Juan A. Suarez Romero

The following two patches fix distcheck.

Juan A. Suarez Romero (2):
  intel: automake: include Makefile.drm.am
  intel: tools: add intel_aub.h as part of aubinator

 src/intel/Makefile.am   | 1 +
 src/intel/Makefile.tools.am | 3 ++-
 2 files changed, 3 insertions(+), 1 deletion(-)

-- 
2.9.4

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

Re: [Mesa-dev] [PATCH 10/11] etnaviv: implement resource creation with modifier

2017-06-28 Thread Wladimir J. van der Laan

On Fri, Jun 23, 2017 at 05:50:27PM +0200, Lucas Stach wrote:
> This allows to create buffers with a specific tiling layout, which is 
> primarily
> used by GBM to allocate the EGL back buffers with the correct tiling/modifier
> for use with the scanout engines.
> 
> Signed-off-by: Lucas Stach 
> ---
>  src/gallium/drivers/etnaviv/etnaviv_resource.c | 97 
> --
>  src/gallium/drivers/etnaviv/etnaviv_resource.h |  2 +-
>  src/gallium/drivers/etnaviv/etnaviv_texture.c  |  2 +-
>  src/gallium/drivers/etnaviv/etnaviv_transfer.c |  2 +-
>  4 files changed, 96 insertions(+), 7 deletions(-)
> 
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.c 
> b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> index df5a5700bc19..8462012b9d5f 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_resource.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> @@ -161,7 +161,7 @@ setup_miptree(struct etna_resource *rsc, unsigned 
> paddingX, unsigned paddingY,
>  /* Create a new resource object, using the given template info */
>  struct pipe_resource *
>  etna_resource_alloc(struct pipe_screen *pscreen, unsigned layout,
> -const struct pipe_resource *templat)
> +uint64_t modifier, const struct pipe_resource *templat)
>  {
> struct etna_screen *screen = etna_screen(pscreen);
> struct etna_resource *rsc;
> @@ -217,8 +217,13 @@ etna_resource_alloc(struct pipe_screen *pscreen, 
> unsigned layout,
>unsigned padX, padY;
>  
>/* pad scanout buffer size to be compatible with the RS */
> -  padX = ETNA_RS_WIDTH_MASK + 1;
> -  padY = (ETNA_RS_HEIGHT_MASK + 1) * screen->specs.pixel_pipes;
> +  if (modifier != DRM_FORMAT_MOD_LINEAR) {
> + padX = paddingX;
> + padY = paddingY;
> +  } else {
> + padX = ETNA_RS_WIDTH_MASK + 1;
> + padY = (ETNA_RS_HEIGHT_MASK + 1) * screen->specs.pixel_pipes;

We repeat `4 * screen->specs.pixel_pipes`, or in this case
`(ETNA_RS_HEIGHT_MASK + 1) * screen->specs.pixel_pipes` in many places.

Maybe this 'minimum padding for RS' computation logic could factored
out for more readable code.

> +  }
>scanout_templat.width0 = align(scanout_templat.width0, padX);
>scanout_templat.height0 = align(scanout_templat.height0, padY);
>  
> @@ -227,6 +232,7 @@ etna_resource_alloc(struct pipe_screen *pscreen, unsigned 
> layout,
>if (!scanout)
>   return NULL;
>  
> +  handle.modifier = modifier;
>rsc = etna_resource(pscreen->resource_from_handle(pscreen, templat,
>  ,
>  
> PIPE_HANDLE_USAGE_WRITE));
> @@ -331,7 +337,89 @@ etna_resource_create(struct pipe_screen *pscreen,
> if (templat->target == PIPE_TEXTURE_3D)
>layout = ETNA_LAYOUT_LINEAR;
>  
> -   return etna_resource_alloc(pscreen, layout, templat);
> +   /* modifier is only used for scanout surfaces, so safe to use LINEAR here 
> */
> +   return etna_resource_alloc(pscreen, layout, DRM_FORMAT_MOD_LINEAR, 
> templat);
> +}
> +
> +enum modifier_priority {
> +   MODIFIER_PRIORITY_INVALID = 0,
> +   MODIFIER_PRIORITY_LINEAR,
> +   MODIFIER_PRIORITY_SPLIT_TILED,
> +   MODIFIER_PRIORITY_SPLIT_SUPER_TILED,
> +   MODIFIER_PRIORITY_TILED,
> +   MODIFIER_PRIORITY_SUPER_TILED,
> +};
> +
> +const uint64_t priority_to_modifier[] = {
> +   [MODIFIER_PRIORITY_INVALID] = DRM_FORMAT_MOD_INVALID,
> +   [MODIFIER_PRIORITY_LINEAR] = DRM_FORMAT_MOD_LINEAR,
> +   [MODIFIER_PRIORITY_SPLIT_TILED] = DRM_FORMAT_MOD_VIVANTE_SPLIT_TILED,
> +   [MODIFIER_PRIORITY_SPLIT_SUPER_TILED] = 
> DRM_FORMAT_MOD_VIVANTE_SPLIT_SUPER_TILED,
> +   [MODIFIER_PRIORITY_TILED] = DRM_FORMAT_MOD_VIVANTE_TILED,
> +   [MODIFIER_PRIORITY_SUPER_TILED] = DRM_FORMAT_MOD_VIVANTE_SUPER_TILED,
> +};
> +
> +static uint64_t
> +select_best_modifier(const struct etna_screen * screen,
> + const uint64_t *modifiers, const unsigned count)
> +{
> +   enum modifier_priority prio = MODIFIER_PRIORITY_INVALID;
> +
> +   for (int i = 0; i < count; i++) {
> +  switch (modifiers[i]) {
> +  case DRM_FORMAT_MOD_VIVANTE_SUPER_TILED:
> + if ((screen->specs.pixel_pipes > 1 && !screen->specs.single_buffer) 
> ||
> + !screen->specs.can_supertile)
> +break;
> + prio = MAX2(prio, MODIFIER_PRIORITY_SUPER_TILED);
> + break;
> +  case DRM_FORMAT_MOD_VIVANTE_TILED:
> + if (screen->specs.pixel_pipes > 1 && !screen->specs.single_buffer)
> +break;
> + prio = MAX2(prio, MODIFIER_PRIORITY_TILED);
> + break;
> +  case DRM_FORMAT_MOD_VIVANTE_SPLIT_SUPER_TILED:
> + if ((screen->specs.pixel_pipes < 2) || !screen->specs.can_supertile)
> +break;
> + prio = MAX2(prio, MODIFIER_PRIORITY_SPLIT_SUPER_TILED);
> + break;
> +  case DRM_FORMAT_MOD_VIVANTE_SPLIT_TILED:
> +

Re: [Mesa-dev] [PATCH 09/11] etnaviv: fill in modifier in etna_resource_get_handle

2017-06-28 Thread Wladimir J. van der Laan

On Fri, Jun 23, 2017 at 05:50:26PM +0200, Lucas Stach wrote:
> This allows the state trackers to know the tiling layout of the
> resource and pass this through the various userspace protocols.

> Signed-off-by: Lucas Stach 

Comment inline.

Reviewed-by: Wladimir J. van der Laan 

> ---
>  src/gallium/drivers/etnaviv/etnaviv_resource.c | 30 
> +-
>  1 file changed, 29 insertions(+), 1 deletion(-)
> 
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.c 
> b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> index 66d96aacbbe7..df5a5700bc19 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_resource.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> @@ -464,6 +464,24 @@ fail:
> return NULL;
>  }
>  
> +static uint64_t layout_to_modifier(unsigned int layout)
> +{
> +   switch (layout) {
> +   case ETNA_LAYOUT_TILED:
> +  return DRM_FORMAT_MOD_VIVANTE_TILED;
> +   case ETNA_LAYOUT_SUPER_TILED:
> +  return DRM_FORMAT_MOD_VIVANTE_SUPER_TILED;
> +   case ETNA_LAYOUT_MULTI_TILED:
> +  return DRM_FORMAT_MOD_VIVANTE_SPLIT_TILED;
> +   case ETNA_LAYOUT_MULTI_SUPERTILED:
> +  return DRM_FORMAT_MOD_VIVANTE_SPLIT_SUPER_TILED;
> +   case ETNA_LAYOUT_LINEAR:
> +  return DRM_FORMAT_MOD_LINEAR;
> +   default:
> +  return DRM_FORMAT_MOD_INVALID;
> +   }
> +}
> +

It would make sense to put this function after modifier_to_layout
as introduced in 07/11: in the rare case when a tiling layout is added,
both need to be updated, after all. 

>  static boolean
>  etna_resource_get_handle(struct pipe_screen *pscreen,
>   struct pipe_context *pctx,
> @@ -472,10 +490,20 @@ etna_resource_get_handle(struct pipe_screen *pscreen,
>  {
> struct etna_resource *rsc = etna_resource(prsc);
> handle->stride = rsc->levels[0].stride;
> +   handle->modifier = layout_to_modifier(rsc->layout);
>  
> if (handle->type == DRM_API_HANDLE_TYPE_KMS &&
> -   renderonly_get_handle(rsc->scanout, handle))
> +   renderonly_get_handle(rsc->scanout, handle)) {
> +  /*
> +   * If we export the renderonly handle and the scanout BO is attached as
> +   * an external resource we need to fill in the modifier from the 
> external
> +   * resource.
> +   */
> +  if (rsc->external)
> + handle->modifier = 
> layout_to_modifier(etna_resource(rsc->external)->layout);
> +
>return TRUE;
> +   }
>  
> if (handle->type == DRM_API_HANDLE_TYPE_SHARED) {
>return etna_bo_get_name(rsc->bo, >handle) == 0;
> -- 
> 2.11.0
> 
> ___
> etnaviv mailing list
> etna...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/etnaviv
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 22/30] i965/screen: Drop get_tiled_height

2017-06-28 Thread Chad Versace

On Fri 16 Jun 2017, Jason Ekstrand wrote:
> It's no longer used.

And the tree still builds.
Reviewed-by: Chad Versace 

> ---
>  src/mesa/drivers/dri/i965/intel_screen.c | 20 +++-
>  1 file changed, 3 insertions(+), 17 deletions(-)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 07/11] etnaviv: implement resource import with modifier

2017-06-28 Thread Wladimir J. van der Laan

On Fri, Jun 23, 2017 at 05:50:24PM +0200, Lucas Stach wrote:
> This implements resource import with modifier, deriving the correct
> internal layout from the modifier and constructing a render compatible
> base resource if needed.
> 
> This removes the special cases for DDX and renderonly scanout allocated
> buffers, as the linear modifier is enough to trigger correct handling
> of those buffers.

Reviewed-by: Wladimir J. van der Laan 

> Signed-off-by: Lucas Stach 
> ---
>  src/gallium/drivers/etnaviv/etnaviv_resource.c | 112 
> +
>  1 file changed, 78 insertions(+), 34 deletions(-)
> 
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.c 
> b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> index 43f63f8908a0..f006d24a1bba 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_resource.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> @@ -36,6 +36,29 @@
>  #include "util/u_inlines.h"
>  #include "util/u_memory.h"
>  
> +#include 
> +
> +#ifndef DRM_FORMAT_MOD_INVALID
> +#define DRM_FORMAT_MOD_INVALID ((1ULL<<56) - 1)
> +#endif
> +
> +static unsigned int modifier_to_layout(uint64_t modifier)
> +{
> +   switch (modifier) {
> +   case DRM_FORMAT_MOD_VIVANTE_TILED:
> +  return ETNA_LAYOUT_TILED;
> +   case DRM_FORMAT_MOD_VIVANTE_SUPER_TILED:
> +  return ETNA_LAYOUT_SUPER_TILED;
> +   case DRM_FORMAT_MOD_VIVANTE_SPLIT_TILED:
> +  return ETNA_LAYOUT_MULTI_TILED;
> +   case DRM_FORMAT_MOD_VIVANTE_SPLIT_SUPER_TILED:
> +  return ETNA_LAYOUT_MULTI_SUPERTILED;
> +   case DRM_FORMAT_MOD_LINEAR:
> +   default:
> +  return ETNA_LAYOUT_LINEAR;
> +   }
> +}
> +
>  /* A tile is 4x4 pixels, having 'screen->specs.bits_per_tile' of tile status.
>   * So, in a buffer of N pixels, there are N / (4 * 4) tiles.
>   * We need N * screen->specs.bits_per_tile / (4 * 4) bits of tile status, or
> @@ -141,6 +164,7 @@ etna_resource_alloc(struct pipe_screen *pscreen, unsigned 
> layout,
>  const struct pipe_resource *templat)
>  {
> struct etna_screen *screen = etna_screen(pscreen);
> +   struct etna_resource *rsc;
> unsigned size;
>  
> DBG_F(ETNA_DBG_RESOURCE_MSGS,
> @@ -186,8 +210,36 @@ etna_resource_alloc(struct pipe_screen *pscreen, 
> unsigned layout,
>   paddingY = min_paddingY;
> }
>  
> -   struct etna_resource *rsc = CALLOC_STRUCT(etna_resource);
> +   if (templat->bind & PIPE_BIND_SCANOUT) {
> +  struct pipe_resource scanout_templat = *templat;
> +  struct renderonly_scanout *scanout;
> +  struct winsys_handle handle;
> +  unsigned padX, padY;
>  
> +  /* pad scanout buffer size to be compatible with the RS */
> +  padX = ETNA_RS_WIDTH_MASK + 1;
> +  padY = (ETNA_RS_HEIGHT_MASK + 1) * screen->specs.pixel_pipes;
> +  scanout_templat.width0 = align(scanout_templat.width0, padX);
> +  scanout_templat.height0 = align(scanout_templat.height0, padY);
> +
> +  scanout = renderonly_scanout_for_resource(_templat,
> +screen->ro, );
> +  if (!scanout)
> + return NULL;
> +
> +  rsc = etna_resource(pscreen->resource_from_handle(pscreen, templat,
> +,
> +
> PIPE_HANDLE_USAGE_WRITE));
> +  close(handle.handle);
> +  if (!rsc)
> + return NULL;
> +
> +  rsc->scanout = scanout;
> +
> +  return >base;
> +   }
> +
> +   rsc = CALLOC_STRUCT(etna_resource);
> if (!rsc)
>return NULL;
>  
> @@ -214,30 +266,6 @@ etna_resource_alloc(struct pipe_screen *pscreen, 
> unsigned layout,
> rsc->bo = bo;
> rsc->ts_bo = 0; /* TS is only created when first bound to surface */
>  
> -   if (templat->bind & PIPE_BIND_SCANOUT) {
> -  struct pipe_resource scanout_templat = *templat;
> -  struct winsys_handle handle;
> -  unsigned padX, padY;
> -
> -  /* pad scanout buffer size to be compatible with the RS */
> -  padX = ETNA_RS_WIDTH_MASK + 1;
> -  padY = (ETNA_RS_HEIGHT_MASK + 1) * screen->specs.pixel_pipes;
> -  scanout_templat.width0 = align(scanout_templat.width0, padX);
> -  scanout_templat.height0 = align(scanout_templat.height0, padY);
> -
> -  rsc->scanout = renderonly_scanout_for_resource(_templat,
> - screen->ro, );
> -  if (!rsc->scanout)
> - goto free_rsc;
> -
> -  rsc->external = pscreen->resource_from_handle(pscreen, >base,
> -,
> -PIPE_HANDLE_USAGE_WRITE);
> -  close(handle.handle);
> -  if (!rsc->external)
> - goto free_rsc;
> -   }
> -
> if (DBG_ENABLED(ETNA_DBG_ZERO)) {
>void *map = etna_bo_map(bo);
>memset(map, 0, size);
> @@ -370,14 +398,21 @@ etna_resource_from_handle(struct pipe_screen *pscreen,
>

Re: [Mesa-dev] [PATCH 06/11] etnaviv: also update textures from external resources

2017-06-28 Thread Wladimir J. van der Laan

> > Why do this copy if to==from?
> 
> Tile-status resolve. We currently don't support sampler TS (which is

Ah of course.

Might make sense to add a comment mentioning this, it's not straightforward
when reading the code :)

> probably worth implementing, as it has potentially large performance
> gains for the render to texture cases).

Agreed.

Reviewed-by: Wladimir J. van der Laan 

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

Re: [Mesa-dev] [PATCH 21/30] i965/screen: Use ISL for doing image import checks

2017-06-28 Thread Chad Versace

On Fri 16 Jun 2017, Jason Ekstrand wrote:
> ---
>  src/mesa/drivers/dri/i965/intel_screen.c | 32 
> 
>  1 file changed, 28 insertions(+), 4 deletions(-)

This patch adds more code, but it's code I trust.
Reviewed-by: Chad Versace 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 20/30] i965/screen: Use ISL for allocating image BOs

2017-06-28 Thread Chad Versace

On Fri 16 Jun 2017, Jason Ekstrand wrote:
> ---
>  src/mesa/drivers/dri/i965/intel_screen.c | 51 
> ++--
>  1 file changed, 29 insertions(+), 22 deletions(-)

Reviewed-by: Chad Versace 

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

Re: [Mesa-dev] [PATCH] Android: use symlinks for driver loading

2017-06-28 Thread Rob Clark

On Wed, Jun 28, 2017 at 12:51 PM, Rob Herring  wrote:
> On Wed, Jun 28, 2017 at 11:46 AM, Eric Anholt  wrote:
>> Rob Herring  writes:
>>
>>> Instead of having special driver loading logic for Android, create
>>> symlinks to gallium_dri.so so we can use the standard loading logic.
>>>
>>> Signed-off-by: Rob Herring 
>>
>>
>>> diff --git a/src/gallium/drivers/freedreno/Android.mk 
>>> b/src/gallium/drivers/freedreno/Android.mk
>>> index 330e82420426..7b543097987c 100644
>>> --- a/src/gallium/drivers/freedreno/Android.mk
>>> +++ b/src/gallium/drivers/freedreno/Android.mk
>>> @@ -50,6 +50,7 @@ include $(GALLIUM_COMMON_MK)
>>>  include $(BUILD_STATIC_LIBRARY)
>>>
>>>  ifneq ($(HAVE_GALLIUM_FREEDRENO),)
>>> +GALLIUM_TARGET_DRIVERS += msm
>>>  $(eval GALLIUM_LIBS += $(LOCAL_MODULE) libmesa_winsys_freedreno)
>>>  $(eval GALLIUM_SHARED_LIBS += $(LOCAL_SHARED_LIBRARIES))
>>>  endif
>>
>> Looks like the automake build also gives this one a symlink under "kgsl"
>
> IIUC, that's for use with downstream components. We don't support that
> on Android already, and I see no reason that we need to.

using downstream kgsl kernel also probably doesn't work with any
kernel that supported a4xx or a5xx.. and when it worked, it was a
kernel old enough not to have dma-buf, dma-fence, etc.  So I tend to
agree that there is no need for kgsl symlink.

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

Re: [Mesa-dev] [PATCH 08/11] etnaviv: fold etna_screen_bo_get_handle into etna_resource_get_handle

2017-06-28 Thread Wladimir J. van der Laan

On Fri, Jun 23, 2017 at 05:50:25PM +0200, Lucas Stach wrote:
> There is no point in keeping this indirection. Makes the code easier to
> follow.
> 
> Signed-off-by: Lucas Stach 

Seems to make sense - etna_screen_bo_get_handle doesn't actually do anything
screen specific.

Reviewed-by: Wladimir J. van der Laan 

> ---
>  src/gallium/drivers/etnaviv/etnaviv_resource.c | 14 --
>  src/gallium/drivers/etnaviv/etnaviv_screen.c   | 19 ---
>  src/gallium/drivers/etnaviv/etnaviv_screen.h   |  4 
>  3 files changed, 12 insertions(+), 25 deletions(-)
> 
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.c 
> b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> index f006d24a1bba..66d96aacbbe7 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_resource.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> @@ -471,13 +471,23 @@ etna_resource_get_handle(struct pipe_screen *pscreen,
>   struct winsys_handle *handle, unsigned usage)
>  {
> struct etna_resource *rsc = etna_resource(prsc);
> +   handle->stride = rsc->levels[0].stride;
>  
> if (handle->type == DRM_API_HANDLE_TYPE_KMS &&
> renderonly_get_handle(rsc->scanout, handle))
>return TRUE;
>  
> -   return etna_screen_bo_get_handle(pscreen, rsc->bo, rsc->levels[0].stride,
> -handle);
> +   if (handle->type == DRM_API_HANDLE_TYPE_SHARED) {
> +  return etna_bo_get_name(rsc->bo, >handle) == 0;
> +   } else if (handle->type == DRM_API_HANDLE_TYPE_KMS) {
> +  handle->handle = etna_bo_handle(rsc->bo);
> +  return TRUE;
> +   } else if (handle->type == DRM_API_HANDLE_TYPE_FD) {
> +  handle->handle = etna_bo_dmabuf(rsc->bo);
> +  return TRUE;
> +   } else {
> +  return FALSE;
> +   }
>  }
>  
>  void
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_screen.c 
> b/src/gallium/drivers/etnaviv/etnaviv_screen.c
> index 6c0735e0fbf2..b70897b6e41f 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_screen.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_screen.c
> @@ -696,25 +696,6 @@ fail:
> return false;
>  }
>  
> -boolean
> -etna_screen_bo_get_handle(struct pipe_screen *pscreen, struct etna_bo *bo,
> -  unsigned stride, struct winsys_handle *whandle)
> -{
> -   whandle->stride = stride;
> -
> -   if (whandle->type == DRM_API_HANDLE_TYPE_SHARED) {
> -  return etna_bo_get_name(bo, >handle) == 0;
> -   } else if (whandle->type == DRM_API_HANDLE_TYPE_KMS) {
> -  whandle->handle = etna_bo_handle(bo);
> -  return TRUE;
> -   } else if (whandle->type == DRM_API_HANDLE_TYPE_FD) {
> -  whandle->handle = etna_bo_dmabuf(bo);
> -  return TRUE;
> -   } else {
> -  return FALSE;
> -   }
> -}
> -
>  struct etna_bo *
>  etna_screen_bo_from_handle(struct pipe_screen *pscreen,
> struct winsys_handle *whandle, unsigned 
> *out_stride)
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_screen.h 
> b/src/gallium/drivers/etnaviv/etnaviv_screen.h
> index bec740b0a000..dc57a38dbb80 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_screen.h
> +++ b/src/gallium/drivers/etnaviv/etnaviv_screen.h
> @@ -84,10 +84,6 @@ etna_screen(struct pipe_screen *pscreen)
> return (struct etna_screen *)pscreen;
>  }
>  
> -boolean
> -etna_screen_bo_get_handle(struct pipe_screen *pscreen, struct etna_bo *bo,
> -  unsigned stride, struct winsys_handle *whandle);
> -
>  struct etna_bo *
>  etna_screen_bo_from_handle(struct pipe_screen *pscreen,
> struct winsys_handle *whandle, unsigned 
> *out_stride);
> -- 
> 2.11.0
> 
> ___
> etnaviv mailing list
> etna...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/etnaviv
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 0/5] dri3, gallium: Correctness and performance fixes

2017-06-28 Thread Thomas Hellstrom


On 06/22/2017 12:42 PM, Thomas Hellstrom wrote:

A patch series that deals with dri3 correctness- and performance fixes.

The corectness fixes attempts to deal with the fact that we need to wait for
all pending swapbuffers before we touch the front buffer. Otherwise a
front buffer change may be overwritten by a pending swapbuffer when it
was actually intended to be drawn *after* the swapbuffer. Also a post
swapbuffer front read could actually occur *before* the swapbuffer.

Patch 1 deals with the dri3 internal synchronization. All frontbuffer
accesses introduce a "swapbuffer barrier" to order with respect to
pending swapbuffers.
The exception is _WaitX because if we call _WaitX we're ordering with
respect to X rendering and if there are pending swapbuffers, an application
would already have called _WaitGL to be able to do the X rendering correctly,
and _WaitGL is ordering with respect to pending swapbuffers. This patch
fixes the piglit copysubbuffer test.

Patch 2 to 4 deals with having glFinish() order with respect to pending
swapbuffers. The behaviour is actually not correct in that it doesn't wait
for the pending swapbuffers to complete, but a user shouldn't be able to
tell the difference. This patch series is motivated by the fact that the
glXWaitGL man page states that glFinish() can be used instead of glXWaitGL,
and without this series it can't. The functionality is only implemented for
gallium. Other drivers need to provide their own implementation. Ideally
we should have accomplished this without the dri interface changes by
calling an unconditional flush_frontbuffer, but at least the gallium
flush_frontbuffer implementation is relying on us having a fake front which
is not always the case.

Patch 5 replaces the back-to-fake-front full buffer copies with a swap
during swapbuffers. Should be saving a lot of work when we actually have a
fake front. There were some conserns raised when this was posted as an RFC
that the separate-server-gpu case would be broken as well as the buffer
age functionality. I've audited the code and I think that's not the case.
The piglit buffer age test still reports a pass after this change. The
separate-server-gpu case I guess needs additional testing.

Tested wih piglit -quick without regressions.


Hi!

Patches 1,2 and 5 are still unreviewed. It would be good to have at 
least a pair of extra eyes on them.


Thanks,

Thomas

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

Re: [Mesa-dev] [PATCH 19/30] intel/isl: Add a helper to convert tilings fro ISL to i915

2017-06-28 Thread Chad Versace

On Fri 16 Jun 2017, Jason Ekstrand wrote:
> ---
>  src/intel/isl/isl.h |  3 +++
>  src/intel/isl/isl_drm.c | 23 +++
>  2 files changed, 26 insertions(+)

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

Re: [Mesa-dev] [PATCH 5/5] dri3: Use SwapBuffer flips for back- and fake front

2017-06-28 Thread Thomas Hellstrom


On 06/22/2017 12:42 PM, Thomas Hellstrom wrote:

Use flips for back- and fake front buffers.
This might lead to fake front and real front being shared if the hardware
is page-flip capable.

In any case it will save a full-drawable copy and also the subsequent wait for
the X server to submit that copy to hardware if front-buffer reading or
rendering is enabled.

Signed-off-by: Thomas Hellstrom 


This will actually break even more the already broken eglSwapBuffers() 
with EGL_BUFFER_PRESERVED on the x11-dri3 platform. I'm working on a 
follow-up patch, though that should fix it.


/Thomas


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

Re: [Mesa-dev] [PATCH 2/5] dri: Add a flushSwapBuffers method to the image loader extension

2017-06-28 Thread Thomas Hellstrom


On 06/22/2017 12:42 PM, Thomas Hellstrom wrote:

This method may be used by dri drivers to make sure all outstanding
buffer swaps have been flushed to hardware. Also add a dri3 implementation.

Signed-off-by: Thomas Hellstrom 
---
  include/GL/internal/dri_interface.h | 16 +++-
  src/glx/dri3_glx.c  | 29 +
  2 files changed, 44 insertions(+), 1 deletion(-)

diff --git a/include/GL/internal/dri_interface.h 
b/include/GL/internal/dri_interface.h
index fc2d4bb..ff70ba0 100644
--- a/include/GL/internal/dri_interface.h
+++ b/include/GL/internal/dri_interface.h
@@ -1690,7 +1690,7 @@ struct __DRIimageList {
  };
  
  #define __DRI_IMAGE_LOADER "DRI_IMAGE_LOADER"

-#define __DRI_IMAGE_LOADER_VERSION 1
+#define __DRI_IMAGE_LOADER_VERSION 2
  
  struct __DRIimageLoaderExtensionRec {

  __DRIextension base;
@@ -1726,6 +1726,20 @@ struct __DRIimageLoaderExtensionRec {
   *   into __DRIdri2ExtensionRec::createNewDrawable
   */
  void (*flushFrontBuffer)(__DRIdrawable *driDrawable, void *loaderPrivate);
+
+/**
+ * Flush swap buffers
+ *
+ * Make sure any outstanding swap buffers have been submitted to the
+ * device.
+ *
+ * \param driDrawableDrawable whose swaps need to be flushed
+ * \param loaderPrivate  Loader's private data that was previously passed
+ *   into __DRIdri2ExtensionRec::createNewDrawable
+ *
+ * \since 2
+ */
+void (*flushSwapBuffers)(__DRIdrawable *driDrawable, void *loaderPrivate);
  };
  
  /**

diff --git a/src/glx/dri3_glx.c b/src/glx/dri3_glx.c
index 5091606..39ffcfa 100644
--- a/src/glx/dri3_glx.c
+++ b/src/glx/dri3_glx.c
@@ -502,6 +502,34 @@ dri3_flush_front_buffer(__DRIdrawable *driDrawable, void 
*loaderPrivate)
 loader_dri3_wait_gl(draw);
  }
  
+/**

+ * Make sure all pending swapbuffers have been submitted to hardware
+ *
+ * \param driDrawable[in]  Pointer to the dri drawable whose swaps we are
+ * flushing.
+ * \param loaderPrivate[in]  Pointer to the corresponding struct
+ * loader_dri_drawable.
+ */
+static void
+dri3_flush_swap_buffers(__DRIdrawable *driDrawable, void *loaderPrivate)
+{
+   struct loader_dri3_drawable *draw = loaderPrivate;
+   struct dri3_drawable *pdraw = loader_drawable_to_dri3_drawable(draw);
+   struct dri3_screen *psc;
+   int64_t ust, msc, sbc;


The above variables are an unused leftover. Will be removed in v2.

/Thomas


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

Re: [Mesa-dev] gallium: Reduce trace_dump_box_bytes size by box->x.

2017-06-28 Thread Cherniak, Bruce


> On Jun 26, 2017, at 2:10 PM, Marek Olšák  wrote:
> 
> In my opinion, dumping resources isn't very useful. I think it would
> be better to remove that completely.

From Michel's response, sounds like dumping resources is useful, so... Back to 
my original
question, is this a valid fix?  It prevents a crash that happens on occasion 
while running
GALLIUM_TRACE.

I too would be interested in learning how to replay traces.  Would be very 
handy.

Thanks,
Bruce

> Marek
> 
> On Mon, Jun 26, 2017 at 6:28 PM, Cherniak, Bruce
>  wrote:
>> Back in February, I submitted a patch for review to address an a crash in 
>> GALLIUM_TRACE.
>> 
>> It never got a review, and I forgot to follow up on it.  Is this a correct 
>> fix and useful to anyone
>> else?
>> 
>> Thanks,
>> Bruce
>> 
>> 
>> 
>> From patchwork Wed Feb  1 20:20:38 2017
>> Content-Type: text/plain; charset="utf-8"
>> MIME-Version: 1.0
>> Content-Transfer-Encoding: 7bit
>> Subject: [Mesa-dev] gallium: Reduce trace_dump_box_bytes size by box->x.
>> From: Bruce Cherniak 
>> X-Patchwork-Id: 136378
>> Message-Id: <1485980438-102650-1-git-send-email-bruce.chern...@intel.com>
>> To: mesa-dev@lists.freedesktop.org
>> Date: Wed,  1 Feb 2017 14:20:38 -0600
>> 
>> If stride is supplied (as either stride or slice_stride),
>> trace_dump_box_bytes will try to read stride bytes, regardless whether
>> start address is offset by box->x.  This causes access outside mapped
>> region, and possible segv. (transfer_map stride and layer_stride are not
>> adjusted for box dimensions)
>> 
>> Note:  trace_dump_box_bytes only dumps PIPE_BUFFER resources, so there
>> shouldn't be any complicated boxes.  trace_dump_bytes doesn't handle them
>> anyway.
>> ---
>> src/gallium/drivers/trace/tr_dump.c | 8 +---
>> 1 file changed, 5 insertions(+), 3 deletions(-)
>> 
>> diff --git a/src/gallium/drivers/trace/tr_dump.c 
>> b/src/gallium/drivers/trace/tr_dump.c
>> index b173b8a..591e273 100644
>> --- a/src/gallium/drivers/trace/tr_dump.c
>> +++ b/src/gallium/drivers/trace/tr_dump.c
>> @@ -510,11 +510,13 @@ void trace_dump_box_bytes(const void *data,
>>   size = 0;
>>} else {
>>   enum pipe_format format = resource->format;
>> -  if (slice_stride)
>> +  if (slice_stride) {
>> + slice_stride -= util_format_get_blockwidth(format) * box->x;
>>  size = box->depth * slice_stride;
>> -  else if (stride)
>> +  } else if (stride) {
>> + stride -= util_format_get_blockwidth(format) * box->x;
>>  size = util_format_get_nblocksy(format, box->height) * stride;
>> -  else {
>> +  } else {
>>  size = util_format_get_nblocksx(format, box->width) * 
>> util_format_get_blocksize(format);
>>   }
>>}
>> 
>> ___
>> 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 13/30] i965/miptree: Add an explicit format parameter to create_for_dri_image

2017-06-28 Thread Chad Versace

On Wed 28 Jun 2017, Daniel Stone wrote:
> Hi,
> 
> On 28 June 2017 at 02:05, Jason Ekstrand  wrote:

> > Would you feel more comfortable with a boolean sRGB parameter?  That would
> > make the answers to the above questions much more obvious at the cost of
> > some code.
> 
> s/boolean/enum/ and you're on. As said before, the number of booleans
> in this series already makes me sad, let alone adding more.

Yes, please. Pass an enum, and this code will become understandable.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] Android: use symlinks for driver loading

2017-06-28 Thread Rob Herring

On Wed, Jun 28, 2017 at 11:46 AM, Eric Anholt  wrote:
> Rob Herring  writes:
>
>> Instead of having special driver loading logic for Android, create
>> symlinks to gallium_dri.so so we can use the standard loading logic.
>>
>> Signed-off-by: Rob Herring 
>
>
>> diff --git a/src/gallium/drivers/freedreno/Android.mk 
>> b/src/gallium/drivers/freedreno/Android.mk
>> index 330e82420426..7b543097987c 100644
>> --- a/src/gallium/drivers/freedreno/Android.mk
>> +++ b/src/gallium/drivers/freedreno/Android.mk
>> @@ -50,6 +50,7 @@ include $(GALLIUM_COMMON_MK)
>>  include $(BUILD_STATIC_LIBRARY)
>>
>>  ifneq ($(HAVE_GALLIUM_FREEDRENO),)
>> +GALLIUM_TARGET_DRIVERS += msm
>>  $(eval GALLIUM_LIBS += $(LOCAL_MODULE) libmesa_winsys_freedreno)
>>  $(eval GALLIUM_SHARED_LIBS += $(LOCAL_SHARED_LIBRARIES))
>>  endif
>
> Looks like the automake build also gives this one a symlink under "kgsl"

IIUC, that's for use with downstream components. We don't support that
on Android already, and I see no reason that we need to.

> Other than that, nice cleanup:
>
> Reviewed-by: Eric Anholt 

Thanks.

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

Re: [Mesa-dev] [PATCH 12/30] i965/miptree: Allocate mt earlier in update winsys

2017-06-28 Thread Chad Versace

On Tue 27 Jun 2017, Jason Ekstrand wrote:
> On Tue, Jun 27, 2017 at 12:19 PM, Chad Versace <[1]chadvers...@chromium.org>
> wrote:
> 
> On Mon 26 Jun 2017, Pohjolainen, Topi wrote:
> > On Fri, Jun 16, 2017 at 03:41:34PM -0700, Jason Ekstrand wrote:
> > > From: Ben Widawsky <[2]b...@bwidawsk.net>
> > >
> > > Allows us to continue utilizing common miptree creation using
> __DRIimage
> > > without creating a new DRIimage (for the intel_process_dri2_buffer()
> > > case).
> >
> > Just looking this patch locally I don't really understand this commit
> > message. I'll keep on reading if the answer is later in the series..
> 
> I second Topi. I don't understand the commit message.
> 
> 
> I took a very slightly modified version of what topi wrote.

Then this patch is
Reviewed-by: Chad Versace 



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

Re: [Mesa-dev] [PATCH] Android: use symlinks for driver loading

2017-06-28 Thread Eric Anholt

Rob Herring  writes:

> Instead of having special driver loading logic for Android, create
> symlinks to gallium_dri.so so we can use the standard loading logic.
>
> Signed-off-by: Rob Herring 


> diff --git a/src/gallium/drivers/freedreno/Android.mk 
> b/src/gallium/drivers/freedreno/Android.mk
> index 330e82420426..7b543097987c 100644
> --- a/src/gallium/drivers/freedreno/Android.mk
> +++ b/src/gallium/drivers/freedreno/Android.mk
> @@ -50,6 +50,7 @@ include $(GALLIUM_COMMON_MK)
>  include $(BUILD_STATIC_LIBRARY)
>  
>  ifneq ($(HAVE_GALLIUM_FREEDRENO),)
> +GALLIUM_TARGET_DRIVERS += msm
>  $(eval GALLIUM_LIBS += $(LOCAL_MODULE) libmesa_winsys_freedreno)
>  $(eval GALLIUM_SHARED_LIBS += $(LOCAL_SHARED_LIBRARIES))
>  endif

Looks like the automake build also gives this one a symlink under "kgsl"

Other than that, nice cleanup:

Reviewed-by: Eric Anholt 


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 5/5] vulkan: util: add macros to extract extension/offset number from enums

2017-06-28 Thread Lionel Landwerlin

Signed-off-by: Lionel Landwerlin 
---
 src/vulkan/util/vk_util.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/src/vulkan/util/vk_util.h b/src/vulkan/util/vk_util.h
index 2ed601f881e..a152984d14d 100644
--- a/src/vulkan/util/vk_util.h
+++ b/src/vulkan/util/vk_util.h
@@ -199,4 +199,11 @@ __vk_find_struct(void *start, VkStructureType sType)
 
 uint32_t vk_get_driver_version(void);
 
+#define VK_EXT_OFFSET (10UL)
+#define vk_enum_extension(__enum) \
+   ((__enum) >= VK_EXT_OFFSET ? __enum) - VK_EXT_OFFSET) / 1000UL) + 1) : 
0)
+#define vk_enum_offset(__enum) \
+   ((__enum) >= VK_EXT_OFFSET ? \
+((__enum) - VK_EXT_OFFSET - ((vk_enum_extension(__enum) - 1) * 1000)) : 
(__enum))
+
 #endif /* VK_UTIL_H */
-- 
2.13.2

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

[Mesa-dev] [PATCH 0/5] Vulkan: add extensions numbers to generated enums

2017-06-28 Thread Lionel Landwerlin

Hi,

We already have seen extensions like VK_IMG_format_pvrtc introduce new
formats. The way the Vulkan specification seems to deal with new
formats is to place them at an offset based on the associated
extension number.

The anv driver currently stores the formats in an array indexed by the
format id. This is kind of convenient and avoids really long switch
statements. Unfortunately new formats with id numbers well beyong
1000 mean we cannot keep on doing this.

This series introduce new generated defines for extension numbers so
we can deal with those new id using an indirection table based off the
extension number. The first 3 patches are just rework, the generated
defines are in patch 4 and associated helpers in patch 5.

Cheers,

Lionel Landwerlin (5):
  vulkan: enum generator: align function declarations/prototypes
  vulkan: enum generator: sort enums by names
  vulkan: enum generator: make registry more flexible
  vulkan: enum generator: generate extension number defines
  vulkan: util: add macros to extract extension/offset number from enums

 src/vulkan/util/gen_enum_to_str.py | 68 --
 src/vulkan/util/vk_util.h  |  7 
 2 files changed, 51 insertions(+), 24 deletions(-)

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

[Mesa-dev] [PATCH 1/5] vulkan: enum generator: align function declarations/prototypes

2017-06-28 Thread Lionel Landwerlin

Signed-off-by: Lionel Landwerlin 
---
 src/vulkan/util/gen_enum_to_str.py | 27 ++-
 1 file changed, 14 insertions(+), 13 deletions(-)

diff --git a/src/vulkan/util/gen_enum_to_str.py 
b/src/vulkan/util/gen_enum_to_str.py
index fb31addf94f..ab77ccc7c49 100644
--- a/src/vulkan/util/gen_enum_to_str.py
+++ b/src/vulkan/util/gen_enum_to_str.py
@@ -63,18 +63,19 @@ C_TEMPLATE = Template(textwrap.dedent(u"""\
 
 % for enum in enums:
 
-const char *
-vk_${enum.name[2:]}_to_str(${enum.name} input)
-{
-switch(input) {
-% for v in enum.values:
-case ${v}:
-return "${v}";
-% endfor
-default:
-unreachable("Undefined enum value.");
-}
-}
+const char *
+vk_${enum.name[2:]}_to_str(${enum.name} input)
+{
+   switch(input) {
+   % for v in enum.values:
+   case ${v}:
+  return "${v}";
+   % endfor
+   default:
+  unreachable("Undefined enum value.");
+   }
+}
+
 %endfor"""),
 output_encoding='utf-8')
 
@@ -91,7 +92,7 @@ H_TEMPLATE = Template(textwrap.dedent(u"""\
 #include 
 
 % for enum in enums:
-const char * vk_${enum.name[2:]}_to_str(${enum.name} input);
+const char * vk_${enum.name[2:]}_to_str(${enum.name} input);
 % endfor
 
 #endif"""),
-- 
2.13.2

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

1 2 >

1 - 100 of 193 matches

Mail list logo