[Mesa-dev] [PATCH 1/2] r600: kill off native_integer shader ctx flag

2017-12-22 Thread sroland 
From: Roland Scheidegger 

Maybe upon a time it wasn't always true.
---
 src/gallium/drivers/r600/r600_shader.c | 18 --
 1 file changed, 18 deletions(-)

diff --git a/src/gallium/drivers/r600/r600_shader.c 
b/src/gallium/drivers/r600/r600_shader.c
index 06d7ca02e9..6cdbfd3063 100644
--- a/src/gallium/drivers/r600/r600_shader.c
+++ b/src/gallium/drivers/r600/r600_shader.c
@@ -350,7 +350,6 @@ struct r600_shader_ctx {
int cs_grid_size_reg;
bool cs_block_size_loaded, cs_grid_size_loaded;
int fragcoord_input;
-   int native_integers;
int next_ring_offset;
int gs_out_ring_offset;
int gs_next_vertex;
@@ -998,22 +997,6 @@ static int tgsi_declaration(struct r600_shader_ctx *ctx)
d->Semantic.Name == TGSI_SEMANTIC_SAMPLEPOS) {
break; /* Already handled from 
allocate_system_value_inputs */
} else if (d->Semantic.Name == TGSI_SEMANTIC_INSTANCEID) {
-   if (!ctx->native_integers) {
-   struct r600_bytecode_alu alu;
-   memset(, 0, sizeof(struct 
r600_bytecode_alu));
-
-   alu.op = ALU_OP1_INT_TO_FLT;
-   alu.src[0].sel = 0;
-   alu.src[0].chan = 3;
-
-   alu.dst.sel = 0;
-   alu.dst.chan = 3;
-   alu.dst.write = 1;
-   alu.last = 1;
-
-   if ((r = r600_bytecode_add_alu(ctx->bc, )))
-   return r;
-   }
break;
} else if (d->Semantic.Name == TGSI_SEMANTIC_VERTEXID)
break;
@@ -3128,7 +3111,6 @@ static int r600_shader_from_tgsi(struct r600_context 
*rctx,
 
ctx.bc = >bc;
ctx.shader = shader;
-   ctx.native_integers = true;
 
r600_bytecode_init(ctx.bc, rscreen->b.chip_class, rscreen->b.family,
   rscreen->has_compressed_msaa_texturing);
-- 
2.12.3

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

[Mesa-dev] [PATCH 2/2] r600: fix textureSize queries with tbos

2017-12-22 Thread sroland 
From: Roland Scheidegger 

piglit doesn't care, but I'm quite confident that the size actually bound
as range should be reported and not the base size of the resource.
Also, the array in the constant buffer looks overallocated by a factor of 4.
For eg, also decrease the size by another factor of 2 by using the same
constant slot for both buffer size (required for txq for TBOs) and the number
of layers for cube arrays, as these are mutually exclusive. Could of course use
some more logic and only actually do this for the samplers/images/buffers where
it's required rather than for all, but ah well...
(FWIW I believe the txq for TBOs would be fixable on EG without using a
constant buffer by using the GET_BUFFER_RESINFO vc fetch, but for cube map
arrays we'd still need the buffer as it's unfixable since the hw requires
always 0 unfortunately.)
---
 src/gallium/drivers/r600/r600_shader.c   | 18 +++---
 src/gallium/drivers/r600/r600_state_common.c | 35 +---
 2 files changed, 31 insertions(+), 22 deletions(-)

diff --git a/src/gallium/drivers/r600/r600_shader.c 
b/src/gallium/drivers/r600/r600_shader.c
index 6cdbfd3063..8a63621c2f 100644
--- a/src/gallium/drivers/r600/r600_shader.c
+++ b/src/gallium/drivers/r600/r600_shader.c
@@ -6955,9 +6955,9 @@ static int r600_do_buffer_txq(struct r600_shader_ctx 
*ctx, int reg_idx, int offs
alu.op = ALU_OP1_MOV;
alu.src[0].sel = R600_SHADER_BUFFER_INFO_SEL;
if (ctx->bc->chip_class >= EVERGREEN) {
-   /* channel 0 or 2 of each word */
-   alu.src[0].sel += (id / 2);
-   alu.src[0].chan = (id % 2) * 2;
+   /* with eg each dword is either buf size or number of cubes */
+   alu.src[0].sel += id / 4;
+   alu.src[0].chan = id % 4;
} else {
/* r600 we have them at channel 2 of the second dword */
alu.src[0].sel += (id * 2) + 1;
@@ -7615,9 +7615,9 @@ static int tgsi_tex(struct r600_shader_ctx *ctx)
 
alu.src[0].sel = R600_SHADER_BUFFER_INFO_SEL;
if (ctx->bc->chip_class >= EVERGREEN) {
-   /* channel 1 or 3 of each word */
-   alu.src[0].sel += (id / 2);
-   alu.src[0].chan = ((id % 2) * 2) + 1;
+   /* with eg each dword is either buf size or number of 
cubes */
+   alu.src[0].sel += id / 4;
+   alu.src[0].chan = id % 4;
} else {
/* r600 we have them at channel 2 of the second dword */
alu.src[0].sel += (id * 2) + 1;
@@ -8782,9 +8782,9 @@ static int tgsi_resq(struct r600_shader_ctx *ctx)
alu.op = ALU_OP1_MOV;
 
alu.src[0].sel = R600_SHADER_BUFFER_INFO_SEL;
-   /* channel 1 or 3 of each word */
-   alu.src[0].sel += (id / 2);
-   alu.src[0].chan = ((id % 2) * 2) + 1;
+   /* with eg each dword is either buf size or number of cubes */
+   alu.src[0].sel += id / 4;
+   alu.src[0].chan = id % 4;
alu.src[0].kc_bank = R600_BUFFER_INFO_CONST_BUFFER;
tgsi_dst(ctx, >Dst[0], 2, );
alu.last = 1;
diff --git a/src/gallium/drivers/r600/r600_state_common.c 
b/src/gallium/drivers/r600/r600_state_common.c
index e5a5a33367..e9996cb3fa 100644
--- a/src/gallium/drivers/r600/r600_state_common.c
+++ b/src/gallium/drivers/r600/r600_state_common.c
@@ -902,7 +902,6 @@ struct r600_pipe_shader_selector 
*r600_create_shader_state_tokens(struct pipe_co
  unsigned 
pipe_shader_type)
 {
struct r600_pipe_shader_selector *sel = 
CALLOC_STRUCT(r600_pipe_shader_selector);
-   int i;
 
sel->type = pipe_shader_type;
sel->tokens = tgsi_dup_tokens(tokens);
@@ -1326,7 +1325,7 @@ static void r600_setup_buffer_constants(struct 
r600_context *rctx, int shader_ty
samplers->views.dirty_buffer_constants = FALSE;
 
bits = util_last_bit(samplers->views.enabled_mask);
-   array_size = bits * 8 * sizeof(uint32_t) * 4;
+   array_size = bits * 8 * sizeof(uint32_t);
 
constants = r600_alloc_buf_consts(rctx, shader_type, array_size, 
_offset);
 
@@ -1349,7 +1348,8 @@ static void r600_setup_buffer_constants(struct 
r600_context *rctx, int shader_ty
} else
constants[offset + 4] = 0;
 
-   constants[offset + 5] = 
samplers->views.views[i]->base.texture->width0 / 
util_format_get_blocksize(samplers->views.views[i]->base.format);
+   constants[offset + 5] = 
samplers->views.views[i]->base.u.buf.size /
+   
util_format_get_blocksize(samplers->views.views[i]->base.format);
constants[offset + 6] =

[Mesa-dev] [Bug 100430] [radv] graphical glitches on dolphin emulator

2017-12-22 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=100430

freeb...@hoot.tech changed:

   What|Removed |Added

 CC||freeb...@hoot.tech

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

[Mesa-dev] [Bug 103852] Rendering errors when running dolphin-emu with Vulkan backend, radv (Super Smash Bros. Melee)

2017-12-22 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=103852

freeb...@hoot.tech changed:

   What|Removed |Added

 CC||freeb...@hoot.tech

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

[Mesa-dev] [PATCH] radv: Fix DCC compatible formats.

2017-12-22 Thread Bas Nieuwenhuizen 
DCC was disabled when the image format is !!supported, which is one ! too many.

Ironically the commit that introduced it was supposed to lead to more DCC use 
...

Fixes: 969537d9358 "radv: Add support for more DCC compression with 
VK_KHR_image_format_list."
---
 src/amd/vulkan/radv_image.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/amd/vulkan/radv_image.c b/src/amd/vulkan/radv_image.c
index 15410f140e7..b1c4f3340ed 100644
--- a/src/amd/vulkan/radv_image.c
+++ b/src/amd/vulkan/radv_image.c
@@ -127,7 +127,7 @@ radv_init_surface(struct radv_device *device,
 
surface->flags |= RADEON_SURF_OPTIMIZE_FOR_SPACE;
 
-   bool dcc_compatible_formats = 
!radv_is_colorbuffer_format_supported(pCreateInfo->format, );
+   bool dcc_compatible_formats = 
radv_is_colorbuffer_format_supported(pCreateInfo->format, );
if (pCreateInfo->flags & VK_IMAGE_CREATE_MUTABLE_FORMAT_BIT) {
const struct  VkImageFormatListCreateInfoKHR *format_list =
  (const struct  VkImageFormatListCreateInfoKHR *)
-- 
2.15.1

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

Re: [Mesa-dev] [PATCH 3/3] broadcom/vc4: Add support for HW perfmon

2017-12-22 Thread Eric Anholt 
Boris Brezillon  writes:

> The V3D engine provides several perf counters.
> Implement ->get_driver_query_[group_]info() so that these counters are
> exposed through the GL_AMD_performance_monitor extension.

Thanks for working on this!  I've successfully used it to inform some
work I'm doing on 3DMMES.

> Signed-off-by: Boris Brezillon 
> ---
>  src/gallium/drivers/vc4/vc4_context.h |  13 +++
>  src/gallium/drivers/vc4/vc4_job.c |   9 +-
>  src/gallium/drivers/vc4/vc4_query.c   | 197 
> --
>  src/gallium/drivers/vc4/vc4_screen.c  |   7 ++
>  src/gallium/drivers/vc4/vc4_screen.h  |   1 +
>  5 files changed, 215 insertions(+), 12 deletions(-)
>
> diff --git a/src/gallium/drivers/vc4/vc4_context.h 
> b/src/gallium/drivers/vc4/vc4_context.h
> index 4a1e4093f1a0..b6d9f041efc7 100644
> --- a/src/gallium/drivers/vc4/vc4_context.h
> +++ b/src/gallium/drivers/vc4/vc4_context.h
> @@ -309,6 +309,11 @@ struct vc4_job {
>  struct vc4_job_key key;
>  };
>  
> +struct vc4_hwperfmon {
> +uint32_t id;
> +uint64_t counters[DRM_VC4_MAX_PERF_COUNTERS];
> +};
> +
>  struct vc4_context {
>  struct pipe_context base;
>  
> @@ -387,6 +392,8 @@ struct vc4_context {
>  struct pipe_viewport_state viewport;
>  struct vc4_constbuf_stateobj constbuf[PIPE_SHADER_TYPES];
>  struct vc4_vertexbuf_stateobj vertexbuf;
> +
> +struct vc4_hwperfmon *perfmon;
>  /** @} */
>  };
>  
> @@ -444,6 +451,12 @@ vc4_sampler_state(struct pipe_sampler_state *psampler)
>  return (struct vc4_sampler_state *)psampler;
>  }
>  
> +int vc4_get_driver_query_group_info(struct pipe_screen *pscreen,
> +unsigned index,
> +struct pipe_driver_query_group_info 
> *info);
> +int vc4_get_driver_query_info(struct pipe_screen *pscreen, unsigned index,
> +  struct pipe_driver_query_info *info);
> +
>  struct pipe_context *vc4_context_create(struct pipe_screen *pscreen,
>  void *priv, unsigned flags);
>  void vc4_draw_init(struct pipe_context *pctx);
> diff --git a/src/gallium/drivers/vc4/vc4_job.c 
> b/src/gallium/drivers/vc4/vc4_job.c
> index fb0c5bbc78cf..f75a32565603 100644
> --- a/src/gallium/drivers/vc4/vc4_job.c
> +++ b/src/gallium/drivers/vc4/vc4_job.c
> @@ -362,7 +362,7 @@ vc4_submit_setup_rcl_msaa_surface(struct vc4_job *job,
>  rsc->writes++;
>  }
>  
> -#define MAX_CHUNKS   1
> +#define MAX_CHUNKS   2
>  
>  /**
>   * Submits the job to the kernel and then reinitializes it.
> @@ -467,6 +467,13 @@ vc4_job_submit(struct vc4_context *vc4, struct vc4_job 
> *job)
>  submit.uniforms = (uintptr_t)job->uniforms.base;
>  submit.uniforms_size = cl_offset(>uniforms);
>  
> +if (vc4->perfmon && screen->has_extended_cl) {
> +chunks[nchunks].perfmon.type = VC4_PERFMON_CHUNK;
> +chunks[nchunks].perfmon.id = vc4->perfmon->id;
> +chunks[nchunks].perfmon.pad = 0;
> +nchunks++;
> +}
> +
>  if (nchunks) {
>  submit.flags |= VC4_SUBMIT_CL_EXTENDED;
>  submit.cl_chunks = (uintptr_t)chunks;
> diff --git a/src/gallium/drivers/vc4/vc4_query.c 
> b/src/gallium/drivers/vc4/vc4_query.c
> index ddf8f8fb0c2c..d6b081bb15d7 100644
> --- a/src/gallium/drivers/vc4/vc4_query.c
> +++ b/src/gallium/drivers/vc4/vc4_query.c
> @@ -32,49 +32,224 @@
>  
>  struct vc4_query
>  {
> -uint8_t pad;
> +unsigned num_queries;
> +struct vc4_hwperfmon *hwperfmon;
>  };
>  
> +static const char *v3d_counter_names[] = {
> +"FEP-valid-primitives-no-rendered-pixels",
> +"FEP-valid-primitives-rendered-pixels",
> +"FEP-clipped-quads",
> +"FEP-valid-quads",
> +"TLB-quads-not-passing-stencil-test",
> +"TLB-quads-not-passing-z-and-stencil-test",

Looks like you missed "TLB-quads-passing-z-and-stencil-test" here.

> +"TLB-quads-with-zero-coverage",
> +"TLB-quads-with-non-zero-coverage",
> +"TLB-quads-written-to-color-buffer",
> +"PTB-primitives-discarded-outside-viewport",
> +"PTB-primitives-need-clipping",
> +"PTB-primitives-discared-reversed",
> +"QPU-total-idle-clk-cycles",
> +"QPU-total-clk-cycles-vertex-coord-shading",
> +"QPU-total-clk-cycles-fragment-shading",
> +"QPU-total-clk-cycles-executing-valid-instr",
> +"QPU-total-clk-cycles-waiting-TMU",
> +"QPU-total-clk-cycles-waiting-scoreboard",
> +"QPU-total-clk-cycles-waiting-varyings",
> +"QPU-total-instr-cache-hit",
> +"QPU-total-instr-cache-miss",
> +"QPU-total-uniform-cache-hit",
> +"QPU-total-uniform-cache-miss",
> +"TMU-total-text-quads-processed",
> +

[Mesa-dev] [ANNOUNCE] mesa 17.2.8

2017-12-22 Thread Andres Gomez 
Mesa 17.2.8 is now available.

In this release we have:

The SPIR-V compiler has seen corrected a possible SEGFAULT.

The Intel i965 driver includes a correction for Haswell involving
doubles management. 

The AMD drivers have also received some fixes. A couple have gone for
radv and radeon's VCE while r600 has seen corrected some glitches
detected with This War of Mine.

Gallium has also received a patch fixing a problem affecting the VMware
driver and the st/nine state tracker.

The endianness detection in Windows platform has been corrected to
default to little endian.

Finally, the X11 driver has been improved to notify properly a mesa
warning rather than using fprintf.


Andres Gomez (7):
  cherry-ignore: swr: Fix KNOB_MAX_WORKER_THREADS thread creation override.
  cherry-ignore: added 17.3 nominations.
  cherry-ignore: radv: port merge tess info from anv
  cherry-ignore: main: Clear shader program data whenever ProgramBinary is 
called
  cherry-ignore: r600: set DX10_CLAMP for compute shader too
  Update version to 17.2.8
  docs: add release notes for 17.2.8

Bas Nieuwenhuizen (2):
  spirv: Fix loading an entire block at once.
  radv: Fix multi-layer blits.

Brian Paul (2):
  xlib: call _mesa_warning() instead of fprintf()
  gallium/aux: include nr_samples in util_resource_size() computation

Emil Velikov (1):
  docs: add sha256 checksums for 17.2.7

Iago Toral Quiroga (1):
  i965/vec4: use a temp register to compute offsets for pull loads

Leo Liu (1):
  radeon/vce: move destroy command before feedback command

Matt Turner (2):
  util: Assume little endian in the absence of platform-specific handling
  util: Add a SHA1 unit test program

Roland Scheidegger (2):
  r600: use min_dx10/max_dx10 instead of min/max
  r600: use DX10_CLAMP bit in shader setup

git tag: mesa-17.2.8

https://mesa.freedesktop.org/archive/mesa-17.2.8.tar.gz
MD5:  19832be1bc5784fc7bbad4d138537619  mesa-17.2.8.tar.gz
SHA1: d70df98f1a7a5108171d7699c0da7564da9d0800  mesa-17.2.8.tar.gz
SHA256: c715c3a3d6fe26a69c096f573ec416e038a548f0405e3befedd5136517527a84  
mesa-17.2.8.tar.gz
SHA512: 
69a1c8ada492145b6415c6955652a33266463d21b4b584539d22a7716981f05343b318b171bd12d88ab7e23660fdf42c2033cad90c1c8535958eeb4f026c6ef9
  mesa-17.2.8.tar.gz
PGP:  https://mesa.freedesktop.org/archive/mesa-17.2.8.tar.gz.sig

https://mesa.freedesktop.org/archive/mesa-17.2.8.tar.xz
MD5:  b90ef86280242b670a58fda988bef27c  mesa-17.2.8.tar.xz
SHA1: 7d0594744fefa5ebe035caf8e04dacf0a883ffa5  mesa-17.2.8.tar.xz
SHA256: 6e940345cceaadfd805d701ed2b956589fa77fe8c39991da30ed51ea6b9d095f  
mesa-17.2.8.tar.xz
SHA512: 
ce05ad2d3e1b55ffe9c8ef65023a840c04b29014c7876b23182a6a6dd0b768f248ec21bc5b738d21b846f59f4b73501a9fe834d6a87e7dba16c6f821008e0f01
  mesa-17.2.8.tar.xz
PGP:  https://mesa.freedesktop.org/archive/mesa-17.2.8.tar.xz.sig

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

[Mesa-dev] [Bug 104251] st_update_single_texture: Assertion `texObj' failed.

2017-12-22 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=104251

--- Comment #1 from Andreas Schultes  ---
I did an apitrace and I have some gdb output:

p ctx->Texture.Unit[0]
$6 = {Enabled = 0, EnvMode = 8448, EnvColor = {0, 0, 0, 0}, 
  EnvColorUnclamped = {0, 0, 0, 0}, GenS = {Mode = 9216, _ModeBit = 4, 
ObjectPlane = {1, 0, 0, 0}, EyePlane = {1, 0, 0, 0}}, GenT = {Mode = 9216, 
_ModeBit = 4, ObjectPlane = {0, 1, 0, 0}, EyePlane = {0, 1, 0, 0}}, 
  GenR = {Mode = 9216, _ModeBit = 4, ObjectPlane = {0, 0, 0, 0}, EyePlane = {
  0, 0, 0, 0}}, GenQ = {Mode = 9216, _ModeBit = 4, ObjectPlane = {0, 0, 0, 
  0}, EyePlane = {0, 0, 0, 0}}, TexGenEnabled = 0, _GenFlags = 0, 
  LodBias = 0, _BoundTextures = 3200, Sampler = 0x0, Combine = {
ModeRGB = 8448, ModeA = 8448, SourceRGB = {5890, 34168, 34166, 34166}, 
SourceA = {5890, 34168, 34166, 34166}, OperandRGB = {768, 768, 770, 770}, 
OperandA = {770, 770, 770, 770}, ScaleShiftRGB = 0, ScaleShiftA = 0, 
_NumArgsRGB = 2, _NumArgsA = 2}, _EnvMode = {ModeRGB = 8448, ModeA = 8448, 
SourceRGB = {5890, 34168, 34166, 34166}, SourceA = {5890, 34168, 34166, 
  34166}, OperandRGB = {768, 768, 770, 770}, OperandA = {770, 770, 770, 
  770}, ScaleShiftRGB = 0, ScaleShiftA = 0, _NumArgsRGB = 2, 
_NumArgsA = 2}, _CurrentCombine = 0x56c378b8, CurrentTex = {0x56e581d0, 
0x56e7a920, 0x56e5a670, 0x56e5c220, 0x56d86280, 0x56d4d110, 0x56daa460, 
0x5b81ab00, 0x56da97a0, 0x56e63b10, 0x5b81e790, 0x56e6e940}, 
  _Current = 0x0, _CurrentCombinePacked = {ModeRGB = 1, ModeA = 1, 
ScaleShiftRGB = 0, ScaleShiftA = 0, NumArgsRGB = 2, NumArgsA = 2, 
ArgsRGB = {{Source = 8 '\b', Operand = 0 '\000'}, {Source = 9 '\t', 
Operand = 0 '\000'}, {Source = 0 '\000', Operand = 0 '\000'}, {
Source = 0 '\000', Operand = 0 '\000'}}, ArgsA = {{Source = 8 '\b', 
---Type  to continue, or q  to quit---
Operand = 2 '\002'}, {Source = 9 '\t', Operand = 2 '\002'}, {
Source = 0 '\000', Operand = 0 '\000'}, {Source = 0 '\000', 
Operand = 0 '\000'
(gdb) p ctx->Texture.Unit[0]._Current
$7 = (struct gl_texture_object *) 0x0
(gdb) bt
#0  st_update_single_texture (st=0x56d57ca0, sampler_view=0xc8a4, 
texUnit=0, glsl130_or_later=false, ignore_srgb_decode=false)
at ../../../../src/mesa/state_tracker/st_atom_texture.c:76
#1  0xf6a94eef in update_textures (st=0x56d57ca0, 
shader_stage=PIPE_SHADER_FRAGMENT, prog=0x56ce1bb8, 
sampler_views=0x56d595fc, out_num_textures=0x56d59880)
at ../../../../src/mesa/state_tracker/st_atom_texture.c:157
#2  0xf6a951ba in st_update_fragment_textures (st=0x56d57ca0)
at ../../../../src/mesa/state_tracker/st_atom_texture.c:241
#3  0xf6a90732 in st_validate_state (st=, 
pipeline=ST_PIPELINE_RENDER)
at ../../../../src/mesa/state_tracker/st_atom.c:251
#4  0xf6aaf675 in st_draw_vbo (ctx=0x56c34f60, prims=0xca4c, nr_prims=1, 
ib=0xca3c, index_bounds_valid=0 '\000', min_index=, 
max_index=, tfb_vertcount=0x0, stream=0, indirect=0x0)
at ../../../../src/mesa/state_tracker/st_draw.c:122
#5  0xf6a71f7c in vbo_validated_drawrangeelements (ctx=0x56c34f60, mode=4, 
index_bounds_valid=, start=0, end=4294967295, count=1074, 
type=5123, indices=0x96b1db20, basevertex=0, numInstances=1, 
baseInstance=0) at ../../../../src/mesa/vbo/vbo_exec_array.c:925
#6  0xf6a72609 in vbo_exec_DrawElements (mode=4, count=1074, type=5123, 
indices=0x96b1db20) at ../../../../src/mesa/vbo/vbo_exec_array.c:1075
#7  0x56668f42 in retrace_glDrawElements (call=...)
---Type  to continue, or q  to quit---
at /home/andreas/Develop/apitrace/build32/retrace/glretrace_gl.cpp:10346
#8  0x56580f39 in retrace::retraceCall (call=)
at /home/andreas/Develop/apitrace/retrace/retrace_main.cpp:279
#9  0x5657a99b in retrace::mainLoop ()
at /home/andreas/Develop/apitrace/retrace/retrace_main.cpp:606
#10 main (argc=, argv=)
at /home/andreas/Develop/apitrace/retrace/retrace_main.cpp:1090

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

Re: [Mesa-dev] [PATCH] Revert "i965/fs: Use align1 mode on ternary instructions on Gen10+"

2017-12-22 Thread Rafael Antognolli 
I can confirm this fixes the 2000+ failures.

Tested-by: Rafael Antognolli 

On Fri, Dec 22, 2017 at 01:54:08PM -0800, Anuj Phogat wrote:
> This reverts commit 9cd60fce9c22737000a8f8dc711141f8a523fe75.
> Above commit caused 2000+ piglit tests to assert fail. Disabling
> the align1 mode on gen10 for now to avoid failures.
> 
> Cc: Matt Turner 
> Cc: Rafael Antognolli 
> Signed-off-by: Anuj Phogat 
> ---
> ---
>  src/intel/compiler/brw_fs_generator.cpp | 12 
>  1 file changed, 4 insertions(+), 8 deletions(-)
> 
> diff --git a/src/intel/compiler/brw_fs_generator.cpp 
> b/src/intel/compiler/brw_fs_generator.cpp
> index 679c1f1916..6a3b2dcf8a 100644
> --- a/src/intel/compiler/brw_fs_generator.cpp
> +++ b/src/intel/compiler/brw_fs_generator.cpp
> @@ -1758,15 +1758,13 @@ fs_generator::generate_code(const cfg_t *cfg, int 
> dispatch_width)
>  
>case BRW_OPCODE_MAD:
>   assert(devinfo->gen >= 6);
> - if (devinfo->gen < 10)
> -brw_set_default_access_mode(p, BRW_ALIGN_16);
> +  brw_set_default_access_mode(p, BRW_ALIGN_16);
>   brw_MAD(p, dst, src[0], src[1], src[2]);
>break;
>  
>case BRW_OPCODE_LRP:
>   assert(devinfo->gen >= 6);
> - if (devinfo->gen < 10)
> -brw_set_default_access_mode(p, BRW_ALIGN_16);
> +  brw_set_default_access_mode(p, BRW_ALIGN_16);
>   brw_LRP(p, dst, src[0], src[1], src[2]);
>break;
>  
> @@ -1864,8 +1862,7 @@ fs_generator::generate_code(const cfg_t *cfg, int 
> dispatch_width)
>  
>case BRW_OPCODE_BFE:
>   assert(devinfo->gen >= 7);
> - if (devinfo->gen < 10)
> -brw_set_default_access_mode(p, BRW_ALIGN_16);
> + brw_set_default_access_mode(p, BRW_ALIGN_16);
>   brw_BFE(p, dst, src[0], src[1], src[2]);
>   break;
>  
> @@ -1875,8 +1872,7 @@ fs_generator::generate_code(const cfg_t *cfg, int 
> dispatch_width)
>   break;
>case BRW_OPCODE_BFI2:
>   assert(devinfo->gen >= 7);
> - if (devinfo->gen < 10)
> -brw_set_default_access_mode(p, BRW_ALIGN_16);
> + brw_set_default_access_mode(p, BRW_ALIGN_16);
>   brw_BFI2(p, dst, src[0], src[1], src[2]);
>   break;
>  
> -- 
> 2.13.3
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] Revert "i965/fs: Use align1 mode on ternary instructions on Gen10+"

2017-12-22 Thread Anuj Phogat 
This reverts commit 9cd60fce9c22737000a8f8dc711141f8a523fe75.
Above commit caused 2000+ piglit tests to assert fail. Disabling
the align1 mode on gen10 for now to avoid failures.

Cc: Matt Turner 
Cc: Rafael Antognolli 
Signed-off-by: Anuj Phogat 
---
---
 src/intel/compiler/brw_fs_generator.cpp | 12 
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/src/intel/compiler/brw_fs_generator.cpp 
b/src/intel/compiler/brw_fs_generator.cpp
index 679c1f1916..6a3b2dcf8a 100644
--- a/src/intel/compiler/brw_fs_generator.cpp
+++ b/src/intel/compiler/brw_fs_generator.cpp
@@ -1758,15 +1758,13 @@ fs_generator::generate_code(const cfg_t *cfg, int 
dispatch_width)
 
   case BRW_OPCODE_MAD:
  assert(devinfo->gen >= 6);
- if (devinfo->gen < 10)
-brw_set_default_access_mode(p, BRW_ALIGN_16);
+brw_set_default_access_mode(p, BRW_ALIGN_16);
  brw_MAD(p, dst, src[0], src[1], src[2]);
 break;
 
   case BRW_OPCODE_LRP:
  assert(devinfo->gen >= 6);
- if (devinfo->gen < 10)
-brw_set_default_access_mode(p, BRW_ALIGN_16);
+brw_set_default_access_mode(p, BRW_ALIGN_16);
  brw_LRP(p, dst, src[0], src[1], src[2]);
 break;
 
@@ -1864,8 +1862,7 @@ fs_generator::generate_code(const cfg_t *cfg, int 
dispatch_width)
 
   case BRW_OPCODE_BFE:
  assert(devinfo->gen >= 7);
- if (devinfo->gen < 10)
-brw_set_default_access_mode(p, BRW_ALIGN_16);
+ brw_set_default_access_mode(p, BRW_ALIGN_16);
  brw_BFE(p, dst, src[0], src[1], src[2]);
  break;
 
@@ -1875,8 +1872,7 @@ fs_generator::generate_code(const cfg_t *cfg, int 
dispatch_width)
  break;
   case BRW_OPCODE_BFI2:
  assert(devinfo->gen >= 7);
- if (devinfo->gen < 10)
-brw_set_default_access_mode(p, BRW_ALIGN_16);
+ brw_set_default_access_mode(p, BRW_ALIGN_16);
  brw_BFI2(p, dst, src[0], src[1], src[2]);
  break;
 
-- 
2.13.3

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

Re: [Mesa-dev] [PATCH 06/22] gallium: add semaphore_server_signal()

2017-12-22 Thread Andres Rodriguez 



On 2017-12-22 10:56 AM, Roland Scheidegger wrote:

Am 22.12.2017 um 01:41 schrieb Andres Rodriguez:

Calling this function will emit a semaphore signal operation into the
GPU's command stream.

Signed-off-by: Andres Rodriguez 
---
  src/gallium/docs/source/context.rst  | 31 +++
  src/gallium/include/pipe/p_context.h |  6 ++
  2 files changed, 37 insertions(+)

diff --git a/src/gallium/docs/source/context.rst 
b/src/gallium/docs/source/context.rst
index a8ff3dc..bab9613 100644
--- a/src/gallium/docs/source/context.rst
+++ b/src/gallium/docs/source/context.rst
@@ -567,7 +567,38 @@ by a single pipe_screen and is not shared with another 
process.
  (i.e. you shouldn't use it to flush caches explicitly if you want to e.g.
  use the resource for texturing)
  
+Semaphores

+^^
  
+``pipe_semaphore_handle``, and related methods, are used to synchronize

+execution between multiple parties. Examples include CPU <-> GPU 
syncrhonization,
+rederer <-> windowing system, multiple external APIs, etc.
+
+A ``pipe_semaphore_handle`` can either be 'one time use' or 're-usable'. A 
'one time use'
+semaphore behaves like a traditional GPU fence. Once it reaches the signaled 
state it
+is forever considered to be signaled.
+
+Once a re-usable ``pipe_semaphore_handle`` becomes signaled, it can be reset
+back into an unsignaled state. The ``pipe_semaphore_handle`` will be reset to
+the unsignaled state by performing a wait operation on said object, i.e.
+``semaphore_server_sync``. As a corollary to this behaviour, a re-usable
+``pipe_semaphore_handle`` can only have one waiter.


I've only skimmed through this, but how are one-time use semaphores
(which can have multiple waiters) and re-usable ones (only one waiter)
distinguished? Just by the use of semaphore_server_sync?



Yes, the difference is that only re-usable semaphores can be used for 
semaphore_server_sync(). I should probably document that better and add 
an assert so that it is also clear on the code side.


If anything else that is unclear let me know.

-Andres


Roland




+
+This behaviour is useful in producer <-> consumer chains. It helps avoid
+unecessarily sharing a new ``pipe_semaphore_handle`` each time a new frame is
+ready. Instead, the semaphores are exchanged once ahead of time, and access is 
synchronized
+through GPU signaling instead of direct producer <-> consumer communication.
+
+``semaphore_server_sync`` inserts a wait command into the GPU's command stream.
+
+``semaphore_server_signal`` inserts a signal command into the GPU's command 
stream.
+
+There are no guarantees that the wait/signal commands will be flushed when
+calling ``semaphore_server_sync`` or ``semaphore_server_signal``. An explicit
+call to ``flush`` is required to make sure the commands are emitted to the GPU.
+
+The Gallium implementation may implicitly ``flush`` the command stream during a
+``semaphore_server_sync`` or ``semaphore_server_signal`` call if necessary.
  
  Resource Busy Queries

  ^
diff --git a/src/gallium/include/pipe/p_context.h 
b/src/gallium/include/pipe/p_context.h
index 72e4b9d..5827491 100644
--- a/src/gallium/include/pipe/p_context.h
+++ b/src/gallium/include/pipe/p_context.h
@@ -527,6 +527,12 @@ struct pipe_context {
   struct pipe_semaphore_handle *semaphore);
  
 /**

+* Insert commands to have the GPU signal a semaphore.
+*/
+   void (*semaphore_server_signal)(struct pipe_context *pipe,
+   struct pipe_semaphore_handle *semaphore);
+
+   /**
  * Create a view on a texture to be used by a shader stage.
  */
 struct pipe_sampler_view * (*create_sampler_view)(struct pipe_context *ctx,




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

Re: [Mesa-dev] [ANNOUNCE] Wayland/Weston/Mesa HDR support (proof of concept)

2017-12-22 Thread Kristian Høgsberg 
On Thu, Dec 21, 2017 at 6:21 AM, Ville Syrjälä
 wrote:
> Here's a quick proof of concept implementation of HDR support
> for Wayland/Weston/Mesa.
>
> I'm not posting this as patches right now because I'm not sure
> that would do much good given how rough this is. But here are
> all the repos/branches:
> git://github.com/vsyrjala/wayland.git hdr_poc
> git://github.com/vsyrjala/wayland-protocols.git hdr_poc
> git://github.com/vsyrjala/weston.git hdr_poc
> git://github.com/vsyrjala/mesa.git hdr_poc
> git://github.com/vsyrjala/linux.git hdr_poc
>
> The kernel HDR bits were partially done by Uma Shankar, the rest
> I hacked together myself.

Hi Ville,

This looks really interesting, thanks for the heads up.

Kristian

> As far as Wayland protocol goes I'm adding three new
> extensions (should probably just have one with several requests?):
> - zwp_colorspace_v1 - Specify the primaries/whitepoint chromacities
>   and transfer function for a surface
> - zwp_ycbcr_encoding_v1 - Specify the encoding for YCbCr surfaces
> - zwp_hdr_metadata_v1 - Allow the client to pass HDR metadata to
>   the compositor
> Note that I've not given any thought to how the compositor might
> advertize its capabilities.
>
> I also hacked in a bunch of 10bpc+ YCbCr support to the protocol and
> Weston so that I can actually get some HDR video onto the screen.
>
> On the Mesa side I've crudely implementated the following egl/vk
> extesions:
> - EXT_gl_colorspace_*
> - EXT_surface_SMPTE2086_metadata
> - EXT_surface_CTA861_3_metadata
>   (sidenote: these egl extension don't seem to match CTA-861.3 nicely
>when it comes to the min/max luminance stuff)
> - VK_EXT_hdr_metadata
>
> VK_EXT_hdr_metadata I plugged in for anv only, but the implementation
> is in the common wayland wsi code. Note that I haven't actually tested
> the vulkan stuff at all because I don't talk Vulkan (at least not yet).
>
> Also note that I've not connected up the HDR metadata pipeline
> properly. The client can provide the metadata, but the compositor
> doesn't actually pass it on to the display. For the time being the
> HDR metadata that gets passed to the display is partially specified
> in weston.ini and partially just hardocded (see
> libweston/compositor-drm.c).
>
> The Weston implementation involves a bunch of shaders and matrices to
> do the ycbcr->rgb, "degamma", csc for each surface, blend it all as
> linear RGB into an fp16 fbo, and finally blit that out to the final
> framebuffer while applying the ST2084 PQ transfer function in the
> process.
>
> The reason for the fp16 fbo is that we store the full 1 nits of
> linear RGB. That needs plenty of precisions in the low end so your
> regular 10bpc fb doesn't seem to cut it. And also the display gamma LUT
> doesn't have enough input precision for it either. Sadly there's no
> fixed function hardware in the GPU to do the ST2084 PQ when blending.
> When the output is not HDR I do skip the fp16 fbo step and use the
> gamma LUT in the display engine instead.
>
> Another approach to the precisions problem might be to not store the
> entire 1 nits of linear, and just cut off the super bright stuff
> (your display can't show it anyway). But I've not really bothered to
> figure out how low in nits we'd have to go here, probably too low.
> Maybe blending as sRGB and the doing sRGB->PQ with the gamma LUT might
> help a little bit?
>
> Ideally we would bypass this all for a single fullscreen HDR surface
> and just pass the PQ encoded data directly through. But I've not
> implemented that. In fact I even disable the buffer_age damage stuff
> when using the fp16 fbo, so we'll recompose the entire screen every
> time. Yeah, I'm lazy.
>
> Another thought that occurred to me was that it shouldn't be too hard
> to make Weston do some tone mapping when there's a HDR client and no
> HDR screen. To that end I included the ACES colorspaces in my
> colorspace list, but I didn't actually look into plugging the ACES tone
> mapping curve into the shaders. Might be a fun excercise, even though
> the practical applications might be close to nil. Probably better to
> not advertize HDR/wide gamuts when we can't actually output the stuff,
> and instead let the client do its own tone mapping.
>
> OK, so what can you do with this? I've included a few test clients:
> - simple-colorspace
>   Just a copy of simple-egl but it uses the egl extension to specify
>   the colorspace, and produces ST2084 PQ encoded data when asked
> - simple-hdr-video
>   Uses ffmpeg to decode video into shm buffers, and sets the
>   colorspace/ycbcr encoding etc. appropriately. Ie. this one can
>   actually output HDR video
>
> Here's a weston.ini snippet that gets you outputting HDR:
> [core]
> gbm-format=xrgb2101010
>
> [output]
> name=HDMI-A-2
> colorspace=BT.2020
> gamma=ST2084
> max_sdr_nits=100
>
> Hardware wise you'll need a HDR capable display obviously, and
> you'll need an Intel Geminilake GPU. Older Intel platforms

Re: [Mesa-dev] Initial release of AMD Open Source Driver for Vulkan

2017-12-22 Thread Mike Lothian 
Hi

No I'm not using ICC however that section prevents you using Clang, it
basically says if not GCC then assumes Intel's compiler

Cheers

Mike

On Fri, 22 Dec 2017, 3:04 pm Mao, David,  wrote:

> Hi Lothian,
> Thanks for testing out out driver!
> Officially we recommend you to stick to GCC5 for now, however, we do have
> a fix for the constexpr issue mentioned below that just didn’t make it to
> this first release.
> According to your diff, are you using ICC?
> Could you let us know the compiler version as well as your distro?
>
> Thanks.
> Best Regards,
> David
>
>
> On Dec 22, 2017, at 9:48 PM, Mike Lothian  wrote:
>
> Congratulations on getting this out the door
>
> It didn't compile for me without these changes:
>
> In pal:
>
> diff --git a/src/util/math.cpp b/src/util/math.cpp
> index 46e9ede..3af4259 100644
> --- a/src/util/math.cpp
> +++ b/src/util/math.cpp
> @@ -54,7 +54,7 @@ static uint32 Float32ToFloatN(float f, const
> NBitFloatInfo& info);
>  static float FloatNToFloat32(uint32 fBits, const NBitFloatInfo& info);
>
>  // Initialize the descriptors for various N-bit floating point
> representations:
> -static constexpr NBitFloatInfo Float16Info =
> +static NBitFloatInfo Float16Info =
>  {
>  16,   // numBits
>  10,   //
> numFracBits
> @@ -72,7 +72,7 @@ static constexpr NBitFloatInfo Float16Info =
>  (23 - 10),//
> fracBitsDiff
>  };
>
> -static constexpr NBitFloatInfo Float11Info =
> +static NBitFloatInfo Float11Info =
>  {
>  11,   // numBits
>  6,//
> numFracBits
> @@ -90,7 +90,7 @@ static constexpr NBitFloatInfo Float11Info =
>  23 - 6,   //
> fracBitsDiff
>  };
>
> -static constexpr NBitFloatInfo Float10Info =
> +static NBitFloatInfo Float10Info =
>  {
>  10,   // numBits
>  5,//
> numFracBits
>
> In xgl:
>
> diff --git a/icd/CMakeLists.txt b/icd/CMakeLists.txt
> index 4e4d669..5006184 100644
> --- a/icd/CMakeLists.txt
> +++ b/icd/CMakeLists.txt
> @@ -503,16 +503,16 @@ if (UNIX)
>
>  target_link_libraries(xgl PRIVATE c stdc++ ${CMAKE_DL_LIBS} pthread)
>
> -if(NOT ICD_USE_GCC)
> -message(WARNING "Intel ICC untested in CMake.")
> -target_link_libraries(xgl PRIVATE -fabi-version=0 -static-intel)
> -endif()
> +#if(NOT ICD_USE_GCC)
> +#message(WARNING "Intel ICC untested in CMake.")
> +#target_link_libraries(xgl PRIVATE -fabi-version=0 -static-intel)
> +#endif()
>
>  if(CMAKE_BUILD_TYPE_RELEASE)
>  if("${CMAKE_CXX_COMPILER_ID}" STREQUAL "GNU")
>  execute_process(COMMAND ${CMAKE_C_COMPILER} -dumpversion
> OUTPUT_VARIABLE GCC_VERSION)
>  if (GCC_VERSION VERSION_GREATER 5.3 OR GCC_VERSION
> VERSION_EQUAL 5.3)
> -target_link_libraries(xgl PRIVATE -flto=4
> -fuse-linker-plugin -Wno-odr)
> +target_link_libraries(xgl PRIVATE -Wno-odr)
>  message(WARNING "LTO enabled for Linking")
>  endif()
>  endif()
> @@ -530,17 +530,17 @@ if (UNIX)
>
>  # CMAKE-TODO: What is whole-archive used for?
>  #target_link_libraries(xgl -Wl,--whole-archive ${ICD_LIBS}
> -Wl,--no-whole-archive)
> -if(CMAKE_BUILD_TYPE_RELEASE)
> -execute_process(COMMAND ${CMAKE_C_COMPILER} -dumpversion
> OUTPUT_VARIABLE GCC_VERSION)
> -if (GCC_VERSION VERSION_GREATER 5.3 OR GCC_VERSION VERSION_EQUAL
> 5.3)
> -target_link_libraries(xgl PRIVATE -Wl,--whole-archive
> ${PROJECT_BINARY_DIR}/pal/src/libpal.a -Wl,--no-whole-archive)
> -target_link_libraries(xgl PUBLIC -Wl,--whole-archive
> ${PROJECT_BINARY_DIR}/pal/metrohash/libmetrohash.a -Wl,--no-whole-archive)
> -target_link_libraries(xgl PUBLIC -Wl,--whole-archive
> ${PROJECT_BINARY_DIR}/pal/gpuopen/libgpuopen.a -Wl,--no-whole-archive)
> -target_link_libraries(xgl PUBLIC -Wl,--whole-archive
> ${PROJECT_BINARY_DIR}/pal/vam/libvam.a -Wl,--no-whole-archive)
> -target_link_libraries(xgl PUBLIC -Wl,--whole-archive
> ${PROJECT_BINARY_DIR}/pal/addrlib/libaddrlib.a -Wl,--no-whole-archive)
> -target_link_libraries(xgl PUBLIC -Wl,--whole-archive
> ${PROJECT_BINARY_DIR}/pal/jemalloc/libjemalloc.a -Wl,--no-whole-archive)
> -endif()
> -endif()
> +#if(CMAKE_BUILD_TYPE_RELEASE)
> +#execute_process(COMMAND ${CMAKE_C_COMPILER} -dumpversion
> OUTPUT_VARIABLE GCC_VERSION)
> +#if (GCC_VERSION VERSION_GREATER 5.3 OR GCC_VERSION VERSION_EQUAL
> 5.3)
> +#target_link_libraries(xgl PRIVATE -Wl,--whole-archive
>

Re: [Mesa-dev] [PATCH 06/22] gallium: add semaphore_server_signal()

2017-12-22 Thread Roland Scheidegger 
Am 22.12.2017 um 01:41 schrieb Andres Rodriguez:
> Calling this function will emit a semaphore signal operation into the
> GPU's command stream.
> 
> Signed-off-by: Andres Rodriguez 
> ---
>  src/gallium/docs/source/context.rst  | 31 +++
>  src/gallium/include/pipe/p_context.h |  6 ++
>  2 files changed, 37 insertions(+)
> 
> diff --git a/src/gallium/docs/source/context.rst 
> b/src/gallium/docs/source/context.rst
> index a8ff3dc..bab9613 100644
> --- a/src/gallium/docs/source/context.rst
> +++ b/src/gallium/docs/source/context.rst
> @@ -567,7 +567,38 @@ by a single pipe_screen and is not shared with another 
> process.
>  (i.e. you shouldn't use it to flush caches explicitly if you want to e.g.
>  use the resource for texturing)
>  
> +Semaphores
> +^^
>  
> +``pipe_semaphore_handle``, and related methods, are used to synchronize
> +execution between multiple parties. Examples include CPU <-> GPU 
> syncrhonization,
> +rederer <-> windowing system, multiple external APIs, etc.
> +
> +A ``pipe_semaphore_handle`` can either be 'one time use' or 're-usable'. A 
> 'one time use'
> +semaphore behaves like a traditional GPU fence. Once it reaches the signaled 
> state it
> +is forever considered to be signaled.
> +
> +Once a re-usable ``pipe_semaphore_handle`` becomes signaled, it can be reset
> +back into an unsignaled state. The ``pipe_semaphore_handle`` will be reset to
> +the unsignaled state by performing a wait operation on said object, i.e.
> +``semaphore_server_sync``. As a corollary to this behaviour, a re-usable
> +``pipe_semaphore_handle`` can only have one waiter.

I've only skimmed through this, but how are one-time use semaphores
(which can have multiple waiters) and re-usable ones (only one waiter)
distinguished? Just by the use of semaphore_server_sync?

Roland



> +
> +This behaviour is useful in producer <-> consumer chains. It helps avoid
> +unecessarily sharing a new ``pipe_semaphore_handle`` each time a new frame is
> +ready. Instead, the semaphores are exchanged once ahead of time, and access 
> is synchronized
> +through GPU signaling instead of direct producer <-> consumer communication.
> +
> +``semaphore_server_sync`` inserts a wait command into the GPU's command 
> stream.
> +
> +``semaphore_server_signal`` inserts a signal command into the GPU's command 
> stream.
> +
> +There are no guarantees that the wait/signal commands will be flushed when
> +calling ``semaphore_server_sync`` or ``semaphore_server_signal``. An explicit
> +call to ``flush`` is required to make sure the commands are emitted to the 
> GPU.
> +
> +The Gallium implementation may implicitly ``flush`` the command stream 
> during a
> +``semaphore_server_sync`` or ``semaphore_server_signal`` call if necessary.
>  
>  Resource Busy Queries
>  ^
> diff --git a/src/gallium/include/pipe/p_context.h 
> b/src/gallium/include/pipe/p_context.h
> index 72e4b9d..5827491 100644
> --- a/src/gallium/include/pipe/p_context.h
> +++ b/src/gallium/include/pipe/p_context.h
> @@ -527,6 +527,12 @@ struct pipe_context {
>   struct pipe_semaphore_handle *semaphore);
>  
> /**
> +* Insert commands to have the GPU signal a semaphore.
> +*/
> +   void (*semaphore_server_signal)(struct pipe_context *pipe,
> +   struct pipe_semaphore_handle *semaphore);
> +
> +   /**
>  * Create a view on a texture to be used by a shader stage.
>  */
> struct pipe_sampler_view * (*create_sampler_view)(struct pipe_context 
> *ctx,
> 

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

[Mesa-dev] [Bug 100613] Regression in Mesa 17 on s390x (zSystems)

2017-12-22 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=100613

--- Comment #48 from Emil Velikov  ---
Stefan, we had a number of fixes in Mesa 17.2.1 and later that reference this
bug. Is it save to assume the original regression is resolved, should we close
this?

-- 
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] Initial release of AMD Open Source Driver for Vulkan

2017-12-22 Thread Mao, David 
Hi Lothian,
Thanks for testing out out driver!
Officially we recommend you to stick to GCC5 for now, however, we do have a fix 
for the constexpr issue mentioned below that just didn’t make it to this first 
release.
According to your diff, are you using ICC?
Could you let us know the compiler version as well as your distro?

Thanks.
Best Regards,
David

On Dec 22, 2017, at 9:48 PM, Mike Lothian 
> wrote:

Congratulations on getting this out the door

It didn't compile for me without these changes:

In pal:

diff --git a/src/util/math.cpp b/src/util/math.cpp
index 46e9ede..3af4259 100644
--- a/src/util/math.cpp
+++ b/src/util/math.cpp
@@ -54,7 +54,7 @@ static uint32 Float32ToFloatN(float f, const NBitFloatInfo& 
info);
 static float FloatNToFloat32(uint32 fBits, const NBitFloatInfo& info);

 // Initialize the descriptors for various N-bit floating point representations:
-static constexpr NBitFloatInfo Float16Info =
+static NBitFloatInfo Float16Info =
 {
 16,   // numBits
 10,   // numFracBits
@@ -72,7 +72,7 @@ static constexpr NBitFloatInfo Float16Info =
 (23 - 10),// fracBitsDiff
 };

-static constexpr NBitFloatInfo Float11Info =
+static NBitFloatInfo Float11Info =
 {
 11,   // numBits
 6,// numFracBits
@@ -90,7 +90,7 @@ static constexpr NBitFloatInfo Float11Info =
 23 - 6,   // fracBitsDiff
 };

-static constexpr NBitFloatInfo Float10Info =
+static NBitFloatInfo Float10Info =
 {
 10,   // numBits
 5,// numFracBits

In xgl:

diff --git a/icd/CMakeLists.txt b/icd/CMakeLists.txt
index 4e4d669..5006184 100644
--- a/icd/CMakeLists.txt
+++ b/icd/CMakeLists.txt
@@ -503,16 +503,16 @@ if (UNIX)

 target_link_libraries(xgl PRIVATE c stdc++ ${CMAKE_DL_LIBS} pthread)

-if(NOT ICD_USE_GCC)
-message(WARNING "Intel ICC untested in CMake.")
-target_link_libraries(xgl PRIVATE -fabi-version=0 -static-intel)
-endif()
+#if(NOT ICD_USE_GCC)
+#message(WARNING "Intel ICC untested in CMake.")
+#target_link_libraries(xgl PRIVATE -fabi-version=0 -static-intel)
+#endif()

 if(CMAKE_BUILD_TYPE_RELEASE)
 if("${CMAKE_CXX_COMPILER_ID}" STREQUAL "GNU")
 execute_process(COMMAND ${CMAKE_C_COMPILER} -dumpversion 
OUTPUT_VARIABLE GCC_VERSION)
 if (GCC_VERSION VERSION_GREATER 5.3 OR GCC_VERSION VERSION_EQUAL 
5.3)
-target_link_libraries(xgl PRIVATE -flto=4  -fuse-linker-plugin 
-Wno-odr)
+target_link_libraries(xgl PRIVATE -Wno-odr)
 message(WARNING "LTO enabled for Linking")
 endif()
 endif()
@@ -530,17 +530,17 @@ if (UNIX)

 # CMAKE-TODO: What is whole-archive used for?
 #target_link_libraries(xgl -Wl,--whole-archive ${ICD_LIBS} 
-Wl,--no-whole-archive)
-if(CMAKE_BUILD_TYPE_RELEASE)
-execute_process(COMMAND ${CMAKE_C_COMPILER} -dumpversion 
OUTPUT_VARIABLE GCC_VERSION)
-if (GCC_VERSION VERSION_GREATER 5.3 OR GCC_VERSION VERSION_EQUAL 5.3)
-target_link_libraries(xgl PRIVATE -Wl,--whole-archive 
${PROJECT_BINARY_DIR}/pal/src/libpal.a -Wl,--no-whole-archive)
-target_link_libraries(xgl PUBLIC -Wl,--whole-archive 
${PROJECT_BINARY_DIR}/pal/metrohash/libmetrohash.a -Wl,--no-whole-archive)
-target_link_libraries(xgl PUBLIC -Wl,--whole-archive 
${PROJECT_BINARY_DIR}/pal/gpuopen/libgpuopen.a -Wl,--no-whole-archive)
-target_link_libraries(xgl PUBLIC -Wl,--whole-archive 
${PROJECT_BINARY_DIR}/pal/vam/libvam.a -Wl,--no-whole-archive)
-target_link_libraries(xgl PUBLIC -Wl,--whole-archive 
${PROJECT_BINARY_DIR}/pal/addrlib/libaddrlib.a -Wl,--no-whole-archive)
-target_link_libraries(xgl PUBLIC -Wl,--whole-archive 
${PROJECT_BINARY_DIR}/pal/jemalloc/libjemalloc.a -Wl,--no-whole-archive)
-endif()
-endif()
+#if(CMAKE_BUILD_TYPE_RELEASE)
+#execute_process(COMMAND ${CMAKE_C_COMPILER} -dumpversion 
OUTPUT_VARIABLE GCC_VERSION)
+#if (GCC_VERSION VERSION_GREATER 5.3 OR GCC_VERSION VERSION_EQUAL 5.3)
+#target_link_libraries(xgl PRIVATE -Wl,--whole-archive 
${PROJECT_BINARY_DIR}/pal/src/libpal.a -Wl,--no-whole-archive)
+#target_link_libraries(xgl PUBLIC -Wl,--whole-archive 
${PROJECT_BINARY_DIR}/pal/metrohash/libmetrohash.a -Wl,--no-whole-archive)
+#target_link_libraries(xgl PUBLIC -Wl,--whole-archive 
${PROJECT_BINARY_DIR}/pal/gpuopen/libgpuopen.a -Wl,--no-whole-archive)
+#target_link_libraries(xgl PUBLIC -Wl,--whole-archive

[Mesa-dev] [Bug 102904] piglit and gl45 cts linker tests regressed

2017-12-22 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=102904

Emil Velikov  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #4 from Emil Velikov  ---
Patch was applied to master and propagated to the respective stable branches.

commit df8767a14e3eae4dcb8241b731b34e9379706795
Author: Nicolai Hähnle 
Date:   Wed Sep 20 21:56:26 2017 +0200

glsl/linker: properly fix output variable overlap check

-- 
You are receiving this mail because:
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 103732] [swr] often gets stuck in piglit's glx-multi-context-single-window test

2017-12-22 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=103732

Emil Velikov  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #13 from Emil Velikov  ---
Should be fixed with Mesa 17.2.7

-- 
You are receiving this mail because:
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 104351] X Error of failed request: BadAlloc (insufficient resources for operation)

2017-12-22 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=104351

--- Comment #3 from Emil Velikov  ---
(In reply to Breno Souza from comment #2)
> Same error on fresh install. I have installed the following packages:
> 
> base, base-devel, gnome, gnome-extra, freeglut, qt5-base, cower, pacaur,
> google-chrome (from aur), mesa-demos
> 
> I also have lost access to mesa 17.2.6-1 since I haven't saved it from my
> previously installation.
> 
You might have overdone it a bit (aka fresh install isn't necessary), but at
least we know it's a nice clean setup.

Regarding old binaries/packages see the wiki
https://wiki.archlinux.org/index.php/Arch_Linux_Archive

> As of $ LD_DEBUG=libs glxinfo, binaries are located under /usr/lib. It
> halted on this line:
> 
>  10721:   calling init: /usr/lib/libnss_files.so.2
>  10721:
> 
> I don't "make install" anything, maybe pacaur did. I don't know what to
> check in the disowned list.
> 
I'd recommend slowing learning the tools you use (pacaur). Normally you'll be
looking for libraries (*.so*), but that's not applicable now since you've got a
clean setup.

> I forget to mention that I use a Radeon HD 7850. Could it be something in my
> setup still? Is this distro related?
> 
Knowing the hardware is a important detail - it sounds similar (sort of) to bug
104306.

Most likely you're using a Wayland session - try a Xorg one (there should be
some toggles on the login screen).

-- 
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] Initial release of AMD Open Source Driver for Vulkan

2017-12-22 Thread Mike Lothian 
Congratulations on getting this out the door

It didn't compile for me without these changes:

In pal:

diff --git a/src/util/math.cpp b/src/util/math.cpp
index 46e9ede..3af4259 100644
--- a/src/util/math.cpp
+++ b/src/util/math.cpp
@@ -54,7 +54,7 @@ static uint32 Float32ToFloatN(float f, const
NBitFloatInfo& info);
 static float FloatNToFloat32(uint32 fBits, const NBitFloatInfo& info);

 // Initialize the descriptors for various N-bit floating point
representations:
-static constexpr NBitFloatInfo Float16Info =
+static NBitFloatInfo Float16Info =
 {
 16,   // numBits
 10,   //
numFracBits
@@ -72,7 +72,7 @@ static constexpr NBitFloatInfo Float16Info =
 (23 - 10),//
fracBitsDiff
 };

-static constexpr NBitFloatInfo Float11Info =
+static NBitFloatInfo Float11Info =
 {
 11,   // numBits
 6,//
numFracBits
@@ -90,7 +90,7 @@ static constexpr NBitFloatInfo Float11Info =
 23 - 6,   //
fracBitsDiff
 };

-static constexpr NBitFloatInfo Float10Info =
+static NBitFloatInfo Float10Info =
 {
 10,   // numBits
 5,//
numFracBits

In xgl:

diff --git a/icd/CMakeLists.txt b/icd/CMakeLists.txt
index 4e4d669..5006184 100644
--- a/icd/CMakeLists.txt
+++ b/icd/CMakeLists.txt
@@ -503,16 +503,16 @@ if (UNIX)

 target_link_libraries(xgl PRIVATE c stdc++ ${CMAKE_DL_LIBS} pthread)

-if(NOT ICD_USE_GCC)
-message(WARNING "Intel ICC untested in CMake.")
-target_link_libraries(xgl PRIVATE -fabi-version=0 -static-intel)
-endif()
+#if(NOT ICD_USE_GCC)
+#message(WARNING "Intel ICC untested in CMake.")
+#target_link_libraries(xgl PRIVATE -fabi-version=0 -static-intel)
+#endif()

 if(CMAKE_BUILD_TYPE_RELEASE)
 if("${CMAKE_CXX_COMPILER_ID}" STREQUAL "GNU")
 execute_process(COMMAND ${CMAKE_C_COMPILER} -dumpversion
OUTPUT_VARIABLE GCC_VERSION)
 if (GCC_VERSION VERSION_GREATER 5.3 OR GCC_VERSION
VERSION_EQUAL 5.3)
-target_link_libraries(xgl PRIVATE -flto=4
-fuse-linker-plugin -Wno-odr)
+target_link_libraries(xgl PRIVATE -Wno-odr)
 message(WARNING "LTO enabled for Linking")
 endif()
 endif()
@@ -530,17 +530,17 @@ if (UNIX)

 # CMAKE-TODO: What is whole-archive used for?
 #target_link_libraries(xgl -Wl,--whole-archive ${ICD_LIBS}
-Wl,--no-whole-archive)
-if(CMAKE_BUILD_TYPE_RELEASE)
-execute_process(COMMAND ${CMAKE_C_COMPILER} -dumpversion
OUTPUT_VARIABLE GCC_VERSION)
-if (GCC_VERSION VERSION_GREATER 5.3 OR GCC_VERSION VERSION_EQUAL
5.3)
-target_link_libraries(xgl PRIVATE -Wl,--whole-archive
${PROJECT_BINARY_DIR}/pal/src/libpal.a -Wl,--no-whole-archive)
-target_link_libraries(xgl PUBLIC -Wl,--whole-archive
${PROJECT_BINARY_DIR}/pal/metrohash/libmetrohash.a -Wl,--no-whole-archive)
-target_link_libraries(xgl PUBLIC -Wl,--whole-archive
${PROJECT_BINARY_DIR}/pal/gpuopen/libgpuopen.a -Wl,--no-whole-archive)
-target_link_libraries(xgl PUBLIC -Wl,--whole-archive
${PROJECT_BINARY_DIR}/pal/vam/libvam.a -Wl,--no-whole-archive)
-target_link_libraries(xgl PUBLIC -Wl,--whole-archive
${PROJECT_BINARY_DIR}/pal/addrlib/libaddrlib.a -Wl,--no-whole-archive)
-target_link_libraries(xgl PUBLIC -Wl,--whole-archive
${PROJECT_BINARY_DIR}/pal/jemalloc/libjemalloc.a -Wl,--no-whole-archive)
-endif()
-endif()
+#if(CMAKE_BUILD_TYPE_RELEASE)
+#execute_process(COMMAND ${CMAKE_C_COMPILER} -dumpversion
OUTPUT_VARIABLE GCC_VERSION)
+#if (GCC_VERSION VERSION_GREATER 5.3 OR GCC_VERSION VERSION_EQUAL
5.3)
+#target_link_libraries(xgl PRIVATE -Wl,--whole-archive
${PROJECT_BINARY_DIR}/pal/src/libpal.a -Wl,--no-whole-archive)
+#target_link_libraries(xgl PUBLIC -Wl,--whole-archive
${PROJECT_BINARY_DIR}/pal/metrohash/libmetrohash.a -Wl,--no-whole-archive)
+#target_link_libraries(xgl PUBLIC -Wl,--whole-archive
${PROJECT_BINARY_DIR}/pal/gpuopen/libgpuopen.a -Wl,--no-whole-archive)
+#target_link_libraries(xgl PUBLIC -Wl,--whole-archive
${PROJECT_BINARY_DIR}/pal/vam/libvam.a -Wl,--no-whole-archive)
+#target_link_libraries(xgl PUBLIC -Wl,--whole-archive
${PROJECT_BINARY_DIR}/pal/addrlib/libaddrlib.a -Wl,--no-whole-archive)
+#target_link_libraries(xgl PUBLIC -Wl,--whole-archive
${PROJECT_BINARY_DIR}/pal/jemalloc/libjemalloc.a -Wl,--no-whole-archive)
+#endif()
+#endif()

 #${ICD_TARGET}.so${SO_VERSION_NUMBER} : ${filter-out -Wl%,$(LLLIBS})


diff --git a/icd/api/llpc/util/llpcDebug.cpp

[Mesa-dev] Initial release of AMD Open Source Driver for Vulkan

2017-12-22 Thread Mao, David 
We are pleased to announce the initial release of AMD Open Source Driver for 
Vulkan.



The AMD Open Source Driver for Vulkan is an open-source Vulkan driver for 
Radeon graphics adapters on Linux. It is built on top of AMD's Platform 
Abstraction Library (PAL), a shared component that is designed to encapsulate 
certain hardware and OS-specific programming details for many of AMD's 3D and 
compute drivers. Leveraging PAL can help provide a consistent experience across 
platforms, including support for recently released GPUs and compatibility with 
AMD developer tools.



The driver uses the LLVM-Based Pipeline Compiler (LLPC) library to compile 
shaders that compose a particular VkPipeline object. LLPC builds on LLVM's 
existing shader compilation infrastructure for AMD GPUs to generate code 
objects compatible with PAL's pipeline ABI.



The AMD Open Source Driver for Vulkan is designed to support the following 
features:

- Vulkan 1.0

- More than 30 extensions

- Radeon GPUProfiler tracing

- Built-in debug and profiling tools

- Mid-command buffer preemption and SR-IOV virtualization



The following features and improvements are planned in future releases:

- Upcoming versions of the Vulkan API

- Hardware performance counter collection through RenderDoc

- LLPC optimizations to improve GPU-limited performance and compile time

- Optimizations to improve CPU-limited performance



Please refer to  the README file under 
https://github.com/GPUOpen-Drivers/AMDVLK   for more information.  Looking 
forward to hearing your feedback.



Thanks,



The AMD driver team for Vulkan

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

Re: [Mesa-dev] [RFC libdrm 0/5] Move alloc_handle_t from gralloc impls.

2017-12-22 Thread Tomasz Figa 
On Fri, Dec 22, 2017 at 10:09 AM, Gurchetan Singh
 wrote:
> So the plan is for alloc_handle_t to not be sub-classed by the
> implementations, but have all necessary information that an implementation
> would need?
>
> If so, how do we reconcile the implementation specific information that is
> often in the handle:
>
> https://github.com/intel/minigbm/blob/master/cros_gralloc/cros_gralloc_handle.h
> [consumer_usage, producer_usage, yuv_color_range, is_updated etc.]
>
> https://chromium.googlesource.com/chromiumos/platform/minigbm/+/master/cros_gralloc/cros_gralloc_handle.h
> [use_flags, pixel_stride]
>
> In our case, removing our minigbm specific use flags from the handle would
> add complexity to our (*registerBuffer) path.
>
> On Thu, Dec 21, 2017 at 10:14 AM, Rob Herring  wrote:
>>
>> On Wed, Dec 13, 2017 at 5:02 PM, Gurchetan Singh
>>  wrote:
>> > Hi Robert,
>> >
>> > Thanks for looking into this!  We need to decide if we want:
>> >
>> > (1) A common struct that implementations can subclass, i.e:
>> >
>> > struct blah_gralloc_handle {
>> > alloc_handle_t alloc_handle;
>> > int x, y, z;
>> > 
>> > }
>> >
>> > (2) An accessor library that vendors can implement, i.e:
>> >
>> > struct drmAndroidHandleInfo {
>> >uint32_t (*get_fourcc)(buffer_handle_t handle);
>> >uint32_t (*get_stride)(buffer_handle_t handle, uint32_t plane);
>> >uint32_t (*get_offsets)(buffer_handle_t handle, uint32_t plane);
>> >uint64_t (*get_modifier)(buffer_handle_t handle);
>> > };
>> >
>> > From my perspective as someone who has to maintain the minigbm gralloc
>> > implementation, (2) is preferable since:
>>
>> Yeah, I'd prefer not to encourage 1 as the default.
>>
>> > a) We really don't have a need for fields like data_owner, void *data,
>> > etc.
>>
>> We should be able to get rid of this. It's just for tracking imports.
>>
>> > Also, minigbm puts per plane fds, strides, offsets into the handle.
>> > Separating the information for the first plane (for the alloc_handle_t)
>> > and
>> > then rest of the planes would be annoying.
>>
>> The plan is to add those to alloc_handle_t.
>>
>> > b) we can avoid the struct within a struct that happens when we
>> > subclass,
>> > since alignment/padding issues often pop up during
>> > serialization/de-serialization.  Using __attribute__((aligned(xx))) is
>> > less
>> > portable than maintaining a POD struct.
>>
>> Yes. Even just between 32 and 64 bit it's problematic.
>>
>>
>> > c) IMO creating the handle should be left to the gralloc implementation.
>> > Having accessor functions clearly defines what we need from libdrm -- to
>> > make up for shortcomings of the gralloc API for DRM/KMS use cases.
>> >

I think there might be also d). Define a standard struct in libdrm
headers and add a custom call to gralloc that would fill in such
struct for given buffer. This would keep the libdrm handle independent
of gralloc's internal handle.

P.S. Top-posting is bad.

Best regards,
Tomasz

>> >
>> > On Wed, Dec 13, 2017 at 9:30 AM, Robert Foss 
>> > wrote:
>> >>
>> >> This series moves {gbm,drm,cros}_gralloc_handle_t struct to libdrm,
>> >> since at least 4 implementations exist, and share a lot of contents.
>> >> The idea is to keep the common stuff defined in one place, and libdrm
>> >> is the common codebase to all of these platforms.
>> >>
>> >> Additionally, having this struct defined in libdrm will make it
>> >> easier for mesa and grallocs to communicate.
>> >>
>> >> Curretly missing is:
>> >>  - Planar formats
>> >>  - Get/Set functions
>> >>
>> >>
>> >> Planar formats
>> >> --
>> >> Support for planar formats is needed, but has not been added
>> >> yet, mostly since this was not already implemented in {gbm,drm}_gralloc
>> >> and the fact the having at least initial backwards compatability would
>> >> be nice. Anonymous unions can of course be used later on to provide
>> >> backwards compatability if so desired.
>> >>
>> >>
>> >> Get/Set functions
>> >> -
>> >> During the previous discussion[1] one suggestion was to add accessor
>> >> functions. In this RFC I've only provided a alloc_handle_create()
>> >> function.
>> >>
>> >> The Get/Set functions have not been added yet, I was hoping for some
>> >> conclusive arguments for them being adeded.
>> >>
>> >> Lastly it was suggested by Rob Herring that having a fourcc<->android
>> >> pixel format conversion function would be useful.
>> >>
>> >>
>> >> [1]
>> >>
>> >> https://lists.freedesktop.org/archives/mesa-dev/2017-November/178199.html
>> >>
>> >> Robert Foss (5):
>> >>   android: Move gralloc handle struct to libdrm
>> >>   android: Add version variable to alloc_handle_t
>> >>   android: Mark alloc_handle_t magic variable as const
>> >>   android: Remove member name from alloc_handle_t
>> >>   android: Change alloc_handle_t format from Android format to fourcc
>> >>
>> >>  Android.mk

Re: [Mesa-dev] [RFC libdrm 0/5] Move alloc_handle_t from gralloc impls.

2017-12-22 Thread Emil Velikov 
On 21 December 2017 at 18:14, Rob Herring  wrote:
> On Wed, Dec 13, 2017 at 5:02 PM, Gurchetan Singh
>  wrote:
>> Hi Robert,
>>
>> Thanks for looking into this!  We need to decide if we want:
>>
>> (1) A common struct that implementations can subclass, i.e:
>>
>> struct blah_gralloc_handle {
>> alloc_handle_t alloc_handle;
>> int x, y, z;
>> 
>> }
>>
>> (2) An accessor library that vendors can implement, i.e:
>>
>> struct drmAndroidHandleInfo {
>>uint32_t (*get_fourcc)(buffer_handle_t handle);
>>uint32_t (*get_stride)(buffer_handle_t handle, uint32_t plane);
>>uint32_t (*get_offsets)(buffer_handle_t handle, uint32_t plane);
>>uint64_t (*get_modifier)(buffer_handle_t handle);
>> };
>>
>> From my perspective as someone who has to maintain the minigbm gralloc
>> implementation, (2) is preferable since:
>
> Yeah, I'd prefer not to encourage 1 as the default.
>
>> a) We really don't have a need for fields like data_owner, void *data, etc.
>
> We should be able to get rid of this. It's just for tracking imports.
>
>> Also, minigbm puts per plane fds, strides, offsets into the handle.
>> Separating the information for the first plane (for the alloc_handle_t) and
>> then rest of the planes would be annoying.
>
> The plan is to add those to alloc_handle_t.
>
>> b) we can avoid the struct within a struct that happens when we subclass,
>> since alignment/padding issues often pop up during
>> serialization/de-serialization.  Using __attribute__((aligned(xx))) is less
>> portable than maintaining a POD struct.
>
> Yes. Even just between 32 and 64 bit it's problematic.
>
Mostly a drive-by comment:

Iff alignment/padding is the major concern one could use something
like the wayland-egl ABI checks [1] and enforcing extra constrains.
Although in reality even without those, a similar test would be
strongly recommended. It will help greatly with versioning and ABI
stability.

Couple of important suggestions, wrt documentation:
 - is the version field bidirectional (aka Vulkan style) or not
 - how do things work, as various users support different version
 - the macro defined in the header is the current _defined_ version of
the interface and _not_ the one _implemented_ by A/B

Thanks
Emil

[1] 
https://cgit.freedesktop.org/mesa/mesa/tree/src/egl/wayland/wayland-egl/wayland-egl-abi-check.c
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] spirv: avoid infinite loop / freeze in vtn_cfg_walk_blocks()

2017-12-22 Thread Eero Tamminen 

Hi,

On 22.12.2017 11:42, Eero Tamminen wrote:

On 21.12.2017 22:19, Mark Janes wrote:

This patch doesn't apply to master as formatted.


It was against master.  Could you try the attached patch instead?


Argh, I meant the patch attached to this mail.  Sorry again.


- Eero


I assume I had screwed something when I inlined it to my earlier mail. :-/



I've reverted the bisected commit, since it disables testing on master.


My fix is rather obvious, just moving few lines, to make sure loop is 
incremented every round, like it was before the bad commit.



 - Eero


Eero Tamminen  writes:


Fixes: 9702fac68e (spirv: consider bitsize when handling OpSwitch cases)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104359
---
   src/compiler/spirv/vtn_cfg.c | 14 +++---
   1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/src/compiler/spirv/vtn_cfg.c b/src/compiler/spirv/vtn_cfg.c
index 9c4cbe2..3d5de37 100644
--- a/src/compiler/spirv/vtn_cfg.c
+++ b/src/compiler/spirv/vtn_cfg.c
@@ -549,19 +549,19 @@ vtn_cfg_walk_blocks(struct vtn_builder *b, struct
list_head *cf_list,
   struct vtn_block *case_block =
  vtn_value(b, *w, vtn_value_type_block)->block;

-    if (case_block == break_block)
-   continue;
-
-    vtn_assert(case_block->switch_case);
-
-    vtn_order_case(swtch, case_block->switch_case);
-
   if (bitsize <= 32) {
  w += 2;
   } else {
  assert(bitsize == 64);
  w += 3;
   }
+
+    if (case_block == break_block)
+   continue;
+
+    vtn_assert(case_block->switch_case);
+
+    vtn_order_case(swtch, case_block->switch_case);
    }

    enum vtn_branch_type branch_type =
--
2.7.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev




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



>From b4094813c55eddcb14bae712bf33d9d3ab8910d1 Mon Sep 17 00:00:00 2001
From: Eero Tamminen 
Date: Thu, 21 Dec 2017 15:30:16 +0200
Subject: [PATCH] spirv: avoid infinite loop / freeze in vtn_cfg_walk_blocks()

Fixes: 9702fac68e (spirv: consider bitsize when handling OpSwitch cases)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104359
---
 src/compiler/spirv/vtn_cfg.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/src/compiler/spirv/vtn_cfg.c b/src/compiler/spirv/vtn_cfg.c
index 9c4cbe2..3d5de37 100644
--- a/src/compiler/spirv/vtn_cfg.c
+++ b/src/compiler/spirv/vtn_cfg.c
@@ -549,19 +549,19 @@ vtn_cfg_walk_blocks(struct vtn_builder *b, struct list_head *cf_list,
 struct vtn_block *case_block =
vtn_value(b, *w, vtn_value_type_block)->block;
 
-if (case_block == break_block)
-   continue;
-
-vtn_assert(case_block->switch_case);
-
-vtn_order_case(swtch, case_block->switch_case);
-
 if (bitsize <= 32) {
w += 2;
 } else {
assert(bitsize == 64);
w += 3;
 }
+
+if (case_block == break_block)
+   continue;
+
+vtn_assert(case_block->switch_case);
+
+vtn_order_case(swtch, case_block->switch_case);
  }
 
  enum vtn_branch_type branch_type =
-- 
2.7.4

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

Re: [Mesa-dev] [PATCH] spirv: avoid infinite loop / freeze in vtn_cfg_walk_blocks()

2017-12-22 Thread Eero Tamminen 

Hi,

On 21.12.2017 22:19, Mark Janes wrote:

This patch doesn't apply to master as formatted.


It was against master.  Could you try the attached patch instead?

I assume I had screwed something when I inlined it to my earlier mail. :-/



I've reverted the bisected commit, since it disables testing on master.


My fix is rather obvious, just moving few lines, to make sure loop is 
incremented every round, like it was before the bad commit.



- Eero


Eero Tamminen  writes:


Fixes: 9702fac68e (spirv: consider bitsize when handling OpSwitch cases)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104359
---
   src/compiler/spirv/vtn_cfg.c | 14 +++---
   1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/src/compiler/spirv/vtn_cfg.c b/src/compiler/spirv/vtn_cfg.c
index 9c4cbe2..3d5de37 100644
--- a/src/compiler/spirv/vtn_cfg.c
+++ b/src/compiler/spirv/vtn_cfg.c
@@ -549,19 +549,19 @@ vtn_cfg_walk_blocks(struct vtn_builder *b, struct
list_head *cf_list,
   struct vtn_block *case_block =
  vtn_value(b, *w, vtn_value_type_block)->block;

-if (case_block == break_block)
-   continue;
-
-vtn_assert(case_block->switch_case);
-
-vtn_order_case(swtch, case_block->switch_case);
-
   if (bitsize <= 32) {
  w += 2;
   } else {
  assert(bitsize == 64);
  w += 3;
   }
+
+if (case_block == break_block)
+   continue;
+
+vtn_assert(case_block->switch_case);
+
+vtn_order_case(swtch, case_block->switch_case);
}

enum vtn_branch_type branch_type =
--
2.7.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


diff --git a/src/intel/compiler/brw_fs_copy_propagation.cpp b/src/intel/compiler/brw_fs_copy_propagation.cpp
index af5635eacef..92cc0a8de58 100644
--- a/src/intel/compiler/brw_fs_copy_propagation.cpp
+++ b/src/intel/compiler/brw_fs_copy_propagation.cpp
@@ -186,8 +186,7 @@ fs_copy_prop_dataflow::setup_initial_values()
 
/* Populate the initial values for the livein and liveout sets.  For the
 * block at the start of the program, livein = 0 and liveout = copy.
-* For the others, set liveout to 0 (the empty set) and livein to ~0
-* (the universal set).
+* For the others, set liveout and livein to ~0 (the universal set).
 */
foreach_block (block, cfg) {
   if (block->parents.is_empty()) {
@@ -197,7 +196,7 @@ fs_copy_prop_dataflow::setup_initial_values()
  }
   } else {
  for (int i = 0; i < bitset_words; i++) {
-bd[block->num].liveout[i] = 0u;
+bd[block->num].liveout[i] = ~0u;
 bd[block->num].livein[i] = ~0u;
  }
   }
@@ -228,34 +227,17 @@ fs_copy_prop_dataflow::run()
do {
   progress = false;
 
-  /* Update liveout for all blocks. */
   foreach_block (block, cfg) {
  if (block->parents.is_empty())
 continue;
 
  for (int i = 0; i < bitset_words; i++) {
 const BITSET_WORD old_liveout = bd[block->num].liveout[i];
-
-bd[block->num].liveout[i] =
-   bd[block->num].copy[i] | (bd[block->num].livein[i] &
- ~bd[block->num].kill[i]);
-
-if (old_liveout != bd[block->num].liveout[i])
-   progress = true;
- }
-  }
-
-  /* Update livein for all blocks.  If a copy is live out of all parent
-   * blocks, it's live coming in to this block.
-   */
-  foreach_block (block, cfg) {
- if (block->parents.is_empty())
-continue;
-
- for (int i = 0; i < bitset_words; i++) {
-const BITSET_WORD old_livein = bd[block->num].livein[i];
 BITSET_WORD livein_from_any_block = 0;
 
+/* Update livein for this block.  If a copy is live out of all
+ * parent blocks, it's live coming in to this block.
+ */
 bd[block->num].livein[i] = ~0u;
 foreach_list_typed(bblock_link, parent_link, link, >parents) {
bblock_t *parent = parent_link->block;
@@ -278,7 +260,12 @@ fs_copy_prop_dataflow::run()
  */
 bd[block->num].livein[i] &= livein_from_any_block;
 
-if (old_livein != bd[block->num].livein[i])
+/* Update liveout for this block. */
+bd[block->num].liveout[i] =
+   bd[block->num].copy[i] | (bd[block->num].livein[i] &
+ ~bd[block->num].kill[i]);
+
+if (old_liveout != bd[block->num].liveout[i])
progress = true;
  }
   }
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org