Re: [Mesa-dev] [PATCH] radv-report: Show biggest improvements

[Samuel Pitoiset]

Reviewed-by: Samuel Pitoiset 

On 11/22/18 1:52 AM, Timothy Arceri wrote:

Being able to see improvements as well as regressions is useful
during the development of shader opts.

Ported from commit 8f0c7aca8683 in shader-db
---
  radv-report.py | 30 ++
  1 file changed, 30 insertions(+)

diff --git a/radv-report.py b/radv-report.py
index 6396db0..027c1aa 100755
--- a/radv-report.py
+++ b/radv-report.py
@@ -675,6 +675,36 @@ def print_tables(before_all_results, after_all_results):
  if num > 0:
  print
  
+# biggest improvements

+metrics = si_stats().metrics
+for i in range(len(metrics)):
+field = metrics[i][0]
+num = 0
+more_is_better = metrics[i][0] == 'maxwaves'
+
+if more_is_better:
+sort_key = lambda v: -v[1].diff.__dict__[field]
+else:
+sort_key = lambda v: v[1].diff.__dict__[field]
+
+for name, stats in sorted(shaders.items(), key = sort_key):
+if more_is_better:
+if stats.diff.__dict__[field] <= 0:
+continue
+else:
+if stats.diff.__dict__[field] >= 0:
+continue
+
+if num == 0:
+print_yellow(" BIGGEST IMPROVEMENTS - 
{:49}".format(metrics[i][1]))
+print_yellow(" Before After Delta Percentage")
+stats.print_regression(name, field)
+num += 1
+if num == num_listed:
+break
+if num > 0:
+print
+
  # percentages
  legend = "Shaders SGPRs VGPRs SpillSGPR SpillVGPR  PrivVGPR   Scratch  
CodeSize  MaxWaves Waits"
  print_yellow(" PERCENTAGE DELTAS" + legend)


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

[Mesa-dev] [PATCH] anv: allow exporting an imported SYNC_FD semaphore type

[Tapani Pälli]

Fixes issues with following SkQP tests:

   unitTest_VulkanHardwareBuffer_Vulkan_EGL_Syncs
   unitTest_VulkanHardwareBuffer_Vulkan_Vulkan_Syncs

Signed-off-by: Tapani Pälli 
---
 src/intel/vulkan/anv_queue.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/intel/vulkan/anv_queue.c b/src/intel/vulkan/anv_queue.c
index 2a8ed2eb4ed..7887fbcb937 100644
--- a/src/intel/vulkan/anv_queue.c
+++ b/src/intel/vulkan/anv_queue.c
@@ -1056,7 +1056,8 @@ void anv_GetPhysicalDeviceExternalSemaphoreProperties(
 
case VK_EXTERNAL_SEMAPHORE_HANDLE_TYPE_SYNC_FD_BIT:
   if (device->has_exec_fence) {
- pExternalSemaphoreProperties->exportFromImportedHandleTypes = 0;
+ pExternalSemaphoreProperties->exportFromImportedHandleTypes =
+VK_EXTERNAL_SEMAPHORE_HANDLE_TYPE_SYNC_FD_BIT;
  pExternalSemaphoreProperties->compatibleHandleTypes =
 VK_EXTERNAL_SEMAPHORE_HANDLE_TYPE_SYNC_FD_BIT;
  pExternalSemaphoreProperties->externalSemaphoreFeatures =
-- 
2.17.2

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

Re: [Mesa-dev] [PATCH 1/2] anv: Put robust buffer access in the pipeline hash

[Iago Toral]

For both patches:

Reviewed-by: Iago Toral Quiroga 

On Wed, 2018-11-21 at 17:20 -0600, Jason Ekstrand wrote:
> It affects apply_pipeline_layout.  Shaders compiled with the wrong
> value
> will work but they may not be robust as requested by the app.
> 
> Cc: mesa-sta...@lists.freedesktop.org
> ---
>  src/intel/vulkan/anv_pipeline.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/src/intel/vulkan/anv_pipeline.c
> b/src/intel/vulkan/anv_pipeline.c
> index ad0f08253e7..f170366d030 100644
> --- a/src/intel/vulkan/anv_pipeline.c
> +++ b/src/intel/vulkan/anv_pipeline.c
> @@ -446,6 +446,9 @@ anv_pipeline_hash_graphics(struct anv_pipeline
> *pipeline,
> if (layout)
>_mesa_sha1_update(, layout->sha1, sizeof(layout->sha1));
>  
> +   const bool rba = pipeline->device->robust_buffer_access;
> +   _mesa_sha1_update(, , sizeof(rba));
> +
> for (unsigned s = 0; s < MESA_SHADER_STAGES; s++) {
>if (stages[s].entrypoint)
>   anv_pipeline_hash_shader(, [s]);
> @@ -466,6 +469,9 @@ anv_pipeline_hash_compute(struct anv_pipeline
> *pipeline,
> if (layout)
>_mesa_sha1_update(, layout->sha1, sizeof(layout->sha1));
>  
> +   const bool rba = pipeline->device->robust_buffer_access;
> +   _mesa_sha1_update(, , sizeof(rba));
> +
> anv_pipeline_hash_shader(, stage);
>  
> _mesa_sha1_final(, sha1_out);

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

Re: [Mesa-dev] [PATCH] llvmpipe: Always return some fence in flush

[Tomasz Figa]

Hi Brian, Keith,

+Some more Chromium folks for visibility.

On Wed, Aug 22, 2018 at 4:21 PM Tomasz Figa  wrote:
>
> Hi Michel,
>
> On Thu, Aug 16, 2018 at 6:43 PM Michel Dänzer  wrote:
> >
> > On 2018-08-16 11:34 AM, Tomasz Figa wrote:
> > > If there is no last fence, due to no rendering happening yet, just
> > > create a new signaled fence and return it, to match the expectations of
> > > the EGL sync fence API.
> > >
> > > Fixes random "Could not create sync fence 0x3003" assertion failures from
> > > Skia on Android, coming from the following code:
> > >
> > > https://android.googlesource.com/platform/frameworks/base/+/master/libs/hwui/pipeline/skia/SkiaOpenGLPipeline.cpp#427
> > >
> > > Reproducible especially with thread count >= 4.
> > >
> > > Signed-off-by: Tomasz Figa 
> > > ---
> > >  src/gallium/drivers/llvmpipe/lp_setup.c | 8 +++-
> > >  1 file changed, 7 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/src/gallium/drivers/llvmpipe/lp_setup.c 
> > > b/src/gallium/drivers/llvmpipe/lp_setup.c
> > > index b087369473..a6f1b54d69 100644
> > > --- a/src/gallium/drivers/llvmpipe/lp_setup.c
> > > +++ b/src/gallium/drivers/llvmpipe/lp_setup.c
> > > @@ -360,7 +360,13 @@ lp_setup_flush( struct lp_setup_context *setup,
> > > set_scene_state( setup, SETUP_FLUSHED, reason );
> > >
> > > if (fence) {
> > > -  lp_fence_reference((struct lp_fence **)fence, setup->last_fence);
> > > +  struct lp_fence *lp_fence = NULL;
> > > +
> > > +  lp_fence_reference(_fence, setup->last_fence);
> > > +  if (!lp_fence)
> > > + lp_fence = lp_fence_create(0);
> > > +  lp_fence_reference((struct lp_fence **)fence, lp_fence);
> > > +  lp_fence_reference(_fence, NULL);
> > > }
> > >  }
> > >
> > >
> >
> > Other drivers keep around a reference to the last fence in the context,
> > and return that if there's no new work to flush.
>
> Thanks for taking a look.
>
> Right, it sounds like a sane thing to do. LLVMpipe, however, seems to
> explicitly destroy the fence whenever a rendering pass completes and I
> didn't want to change that without understanding the intentions behind
> that. Precisely, it's lp_scene_end_rasterization():
> https://gitlab.freedesktop.org/mesa/mesa/blob/master/src/gallium/drivers/llvmpipe/lp_scene.c#L292
>
> Also, this still wouldn't solve the problem of an EGL sync fence being
> created and waited on without any rendering happening at all, which is
> also likely to happen with Android code pointed to in the commit
> message. Obviously that could be dealt with by creating a signaled
> fence in lp_setup_create(), though.
>
> Let me add Keith and Brian for more visibility.

Any thoughts on this?

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

[Mesa-dev] [PATCH 2/2] virgl: don't mark buffers as unclean after a write

[Gurchetan Singh]

We can mark the buffer unclean if it's ever bound as a TBO,
SSBO, ABO, or image.

This improves

dEQP-GLES3.performance.buffer.data_upload.function_call.map_buffer_range.new_specified_buffer.flag_write_full.stream_draw

from 9.58 MB/s to 451.17 MB/s.

v2: Using buffer bindings to track cleanliness (Ilia).
---
 src/gallium/drivers/virgl/virgl_buffer.c |  1 -
 src/gallium/drivers/virgl/virgl_encode.c | 10 ++
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/virgl/virgl_buffer.c 
b/src/gallium/drivers/virgl/virgl_buffer.c
index 88a22b56f9..f72c93f499 100644
--- a/src/gallium/drivers/virgl/virgl_buffer.c
+++ b/src/gallium/drivers/virgl/virgl_buffer.c
@@ -106,7 +106,6 @@ static void virgl_buffer_transfer_unmap(struct pipe_context 
*ctx,
if (trans->base.usage & PIPE_TRANSFER_WRITE) {
   if (!(transfer->usage & PIPE_TRANSFER_FLUSH_EXPLICIT)) {
  struct virgl_screen *vs = virgl_screen(ctx->screen);
- vbuf->base.clean = FALSE;
  vctx->num_transfers++;
  vs->vws->transfer_put(vs->vws, vbuf->base.hw_res,
>box, trans->base.stride, 
trans->base.layer_stride, trans->offset, transfer->level);
diff --git a/src/gallium/drivers/virgl/virgl_encode.c 
b/src/gallium/drivers/virgl/virgl_encode.c
index 400ba68474..6483f47031 100644
--- a/src/gallium/drivers/virgl/virgl_encode.c
+++ b/src/gallium/drivers/virgl/virgl_encode.c
@@ -61,6 +61,12 @@ static void virgl_encoder_write_res(struct virgl_context 
*ctx,
}
 }
 
+static void virgl_modify_clean(struct virgl_resource *res, boolean value)
+{
+   if (res)
+  res->clean = value;
+}
+
 int virgl_encode_bind_object(struct virgl_context *ctx,
 uint32_t handle, uint32_t object)
 {
@@ -615,6 +621,7 @@ int virgl_encode_sampler_view(struct virgl_context *ctx,
if (res->u.b.target == PIPE_BUFFER) {
   virgl_encoder_write_dword(ctx->cbuf, state->u.buf.offset / elem_size);
   virgl_encoder_write_dword(ctx->cbuf, (state->u.buf.offset + 
state->u.buf.size) / elem_size - 1);
+  virgl_modify_clean(res, FALSE);
} else {
   virgl_encoder_write_dword(ctx->cbuf, state->u.tex.first_layer | 
state->u.tex.last_layer << 16);
   virgl_encoder_write_dword(ctx->cbuf, state->u.tex.first_level | 
state->u.tex.last_level << 8);
@@ -949,6 +956,7 @@ int virgl_encode_set_shader_buffers(struct virgl_context 
*ctx,
  virgl_encoder_write_dword(ctx->cbuf, buffers[i].buffer_offset);
  virgl_encoder_write_dword(ctx->cbuf, buffers[i].buffer_size);
  virgl_encoder_write_res(ctx, res);
+ virgl_modify_clean(res, FALSE);
   } else {
  virgl_encoder_write_dword(ctx->cbuf, 0);
  virgl_encoder_write_dword(ctx->cbuf, 0);
@@ -972,6 +980,7 @@ int virgl_encode_set_hw_atomic_buffers(struct virgl_context 
*ctx,
  virgl_encoder_write_dword(ctx->cbuf, buffers[i].buffer_offset);
  virgl_encoder_write_dword(ctx->cbuf, buffers[i].buffer_size);
  virgl_encoder_write_res(ctx, res);
+ virgl_modify_clean(res, FALSE);
   } else {
  virgl_encoder_write_dword(ctx->cbuf, 0);
  virgl_encoder_write_dword(ctx->cbuf, 0);
@@ -999,6 +1008,7 @@ int virgl_encode_set_shader_images(struct virgl_context 
*ctx,
  virgl_encoder_write_dword(ctx->cbuf, images[i].u.buf.offset);
  virgl_encoder_write_dword(ctx->cbuf, images[i].u.buf.size);
  virgl_encoder_write_res(ctx, res);
+ virgl_modify_clean(res, FALSE);
   } else {
  virgl_encoder_write_dword(ctx->cbuf, 0);
  virgl_encoder_write_dword(ctx->cbuf, 0);
-- 
2.18.1

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

[Mesa-dev] [PATCH 1/2] virgl: avoid large inline transfers

[Gurchetan Singh]

We flush everytime the command buffer (16 kB) is full, which is
quite costly.

This improves

dEQP-GLES3.performance.buffer.data_upload.function_call.buffer_data.new_buffer.usage_stream_draw

from 111.16 MB/s to 1930.36 MB/s.

In addition, I made the benchmark produce buffers from 0 --> 
VIRGL_MAX_CMDBUF_DWORDS * 4,
and tried ((VIRGL_MAX_CMDBUF_DWORDS * 4) / 2), ((VIRGL_MAX_CMDBUF_DWORDS * 4) / 
4), etc.

I didn't notice any clear differences, so let's just go with the most obvious
heuristic.
---
 src/gallium/drivers/virgl/virgl_resource.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/virgl/virgl_resource.c 
b/src/gallium/drivers/virgl/virgl_resource.c
index db5e7dd61a..9174ec5cbb 100644
--- a/src/gallium/drivers/virgl/virgl_resource.c
+++ b/src/gallium/drivers/virgl/virgl_resource.c
@@ -95,7 +95,11 @@ static void virgl_buffer_subdata(struct pipe_context *pipe,
   usage |= PIPE_TRANSFER_DISCARD_RANGE;
 
u_box_1d(offset, size, );
-   virgl_transfer_inline_write(pipe, resource, 0, usage, , data, 0, 0);
+
+   if (size >= (VIRGL_MAX_CMDBUF_DWORDS * 4))
+  u_default_buffer_subdata(pipe, resource, usage, offset, size, data);
+   else
+  virgl_transfer_inline_write(pipe, resource, 0, usage, , data, 0, 0);
 }
 
 void virgl_init_context_resource_functions(struct pipe_context *ctx)
-- 
2.18.1

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

Re: [Mesa-dev] [PATCH] radv-report: Show biggest improvements

[Timothy Arceri]

Sorry the subject should probably have been something like:

 vkpipline-db: Show biggest improvements in radv-report

On 22/11/18 11:52 am, Timothy Arceri wrote:

Being able to see improvements as well as regressions is useful
during the development of shader opts.

Ported from commit 8f0c7aca8683 in shader-db
---
  radv-report.py | 30 ++
  1 file changed, 30 insertions(+)

diff --git a/radv-report.py b/radv-report.py
index 6396db0..027c1aa 100755
--- a/radv-report.py
+++ b/radv-report.py
@@ -675,6 +675,36 @@ def print_tables(before_all_results, after_all_results):
  if num > 0:
  print
  
+# biggest improvements

+metrics = si_stats().metrics
+for i in range(len(metrics)):
+field = metrics[i][0]
+num = 0
+more_is_better = metrics[i][0] == 'maxwaves'
+
+if more_is_better:
+sort_key = lambda v: -v[1].diff.__dict__[field]
+else:
+sort_key = lambda v: v[1].diff.__dict__[field]
+
+for name, stats in sorted(shaders.items(), key = sort_key):
+if more_is_better:
+if stats.diff.__dict__[field] <= 0:
+continue
+else:
+if stats.diff.__dict__[field] >= 0:
+continue
+
+if num == 0:
+print_yellow(" BIGGEST IMPROVEMENTS - 
{:49}".format(metrics[i][1]))
+print_yellow(" Before After Delta Percentage")
+stats.print_regression(name, field)
+num += 1
+if num == num_listed:
+break
+if num > 0:
+print
+
  # percentages
  legend = "Shaders SGPRs VGPRs SpillSGPR SpillVGPR  PrivVGPR   Scratch  
CodeSize  MaxWaves Waits"
  print_yellow(" PERCENTAGE DELTAS" + legend)


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

[Mesa-dev] [PATCH] radv-report: Show biggest improvements

[Timothy Arceri]

Being able to see improvements as well as regressions is useful
during the development of shader opts.

Ported from commit 8f0c7aca8683 in shader-db
---
 radv-report.py | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/radv-report.py b/radv-report.py
index 6396db0..027c1aa 100755
--- a/radv-report.py
+++ b/radv-report.py
@@ -675,6 +675,36 @@ def print_tables(before_all_results, after_all_results):
 if num > 0:
 print
 
+# biggest improvements
+metrics = si_stats().metrics
+for i in range(len(metrics)):
+field = metrics[i][0]
+num = 0
+more_is_better = metrics[i][0] == 'maxwaves'
+
+if more_is_better:
+sort_key = lambda v: -v[1].diff.__dict__[field]
+else:
+sort_key = lambda v: v[1].diff.__dict__[field]
+
+for name, stats in sorted(shaders.items(), key = sort_key):
+if more_is_better:
+if stats.diff.__dict__[field] <= 0:
+continue
+else:
+if stats.diff.__dict__[field] >= 0:
+continue
+
+if num == 0:
+print_yellow(" BIGGEST IMPROVEMENTS - 
{:49}".format(metrics[i][1]))
+print_yellow(" Before After Delta Percentage")
+stats.print_regression(name, field)
+num += 1
+if num == num_listed:
+break
+if num > 0:
+print
+
 # percentages
 legend = "Shaders SGPRs VGPRs SpillSGPR SpillVGPR  PrivVGPR   
Scratch  CodeSize  MaxWaves Waits"
 print_yellow(" PERCENTAGE DELTAS" + legend)
-- 
2.19.1

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

Re: [Mesa-dev] [PATCH 14/22] nir: add legal bit_sizes to intrinsics

[Karol Herbst]

On Wed, Nov 21, 2018 at 10:58 PM Jason Ekstrand  wrote:
>
>
>
> On Tue, Nov 13, 2018 at 9:49 AM Karol Herbst  wrote:
>>
>> With OpenCL some system values match the address bits, but in GLSL we also
>> have some system values being 64 bit.
>>
>> With this it is possible to adjust the builder functions so that depending
>> on the bit_sizes the correct bit_size is used or an additional argument is
>> added in case of multiple possible values.
>>
>> Also this allows for further validation
>>
>> Signed-off-by: Karol Herbst 
>> ---
>>  src/compiler/nir/nir.h   |  3 +++
>>  src/compiler/nir/nir_intrinsics.py   | 15 ++-
>>  src/compiler/nir/nir_intrinsics_c.py |  6 +-
>>  src/nouveau/meson.build  | 25 +
>>  4 files changed, 43 insertions(+), 6 deletions(-)
>>  create mode 100644 src/nouveau/meson.build
>>
>> diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
>> index be4f64464f9..3855eb0b582 100644
>> --- a/src/compiler/nir/nir.h
>> +++ b/src/compiler/nir/nir.h
>> @@ -1283,6 +1283,9 @@ typedef struct {
>>
>> /** semantic flags for calls to this intrinsic */
>> nir_intrinsic_semantic_flag flags;
>> +
>> +   /** bitfield of legal bit sizes */
>> +   unsigned bit_sizes : 7;
>>  } nir_intrinsic_info;
>>
>>  extern const nir_intrinsic_info nir_intrinsic_infos[nir_num_intrinsics];
>> diff --git a/src/compiler/nir/nir_intrinsics.py 
>> b/src/compiler/nir/nir_intrinsics.py
>> index ec3049ca06d..9ada44aad8a 100644
>> --- a/src/compiler/nir/nir_intrinsics.py
>> +++ b/src/compiler/nir/nir_intrinsics.py
>> @@ -32,7 +32,7 @@ class Intrinsic(object):
>> NOTE: this must be kept in sync with nir_intrinsic_info.
>> """
>> def __init__(self, name, src_components, dest_components,
>> -indices, flags, sysval):
>> +indices, flags, sysval, bit_sizes):
>> """Parameters:
>>
>> - name: the intrinsic name
>> @@ -45,6 +45,7 @@ class Intrinsic(object):
>> - indices: list of constant indicies
>> - flags: list of semantic flags
>> - sysval: is this a system-value intrinsic
>> +   - bit_sizes: allowed dest bit_sizes
>> """
>> assert isinstance(name, str)
>> assert isinstance(src_components, list)
>> @@ -58,6 +59,8 @@ class Intrinsic(object):
>> if flags:
>> assert isinstance(flags[0], str)
>> assert isinstance(sysval, bool)
>> +   if bit_sizes:
>> +   assert isinstance(bit_sizes[0], int)
>>
>> self.name = name
>> self.num_srcs = len(src_components)
>> @@ -68,6 +71,7 @@ class Intrinsic(object):
>> self.indices = indices
>> self.flags = flags
>> self.sysval = sysval
>> +   self.bit_sizes = bit_sizes
>>
>>  #
>>  # Possible indices:
>> @@ -120,10 +124,10 @@ CAN_REORDER   = "NIR_INTRINSIC_CAN_REORDER"
>>  INTR_OPCODES = {}
>>
>>  def intrinsic(name, src_comp=[], dest_comp=-1, indices=[],
>> -  flags=[], sysval=False):
>> +  flags=[], sysval=False, bit_sizes=[]):
>>  assert name not in INTR_OPCODES
>>  INTR_OPCODES[name] = Intrinsic(name, src_comp, dest_comp,
>> -   indices, flags, sysval)
>> +   indices, flags, sysval, bit_sizes)
>>
>>  intrinsic("nop", flags=[CAN_ELIMINATE])
>>
>> @@ -446,9 +450,10 @@ intrinsic("shared_atomic_fmin",  src_comp=[1, 1], 
>> dest_comp=1, indices=[BASE])
>>  intrinsic("shared_atomic_fmax",  src_comp=[1, 1], dest_comp=1, 
>> indices=[BASE])
>>  intrinsic("shared_atomic_fcomp_swap", src_comp=[1, 1, 1], dest_comp=1, 
>> indices=[BASE])
>>
>> -def system_value(name, dest_comp, indices=[]):
>> +def system_value(name, dest_comp, indices=[], bit_sizes=[32]):
>>  intrinsic("load_" + name, [], dest_comp, indices,
>> -  flags=[CAN_ELIMINATE, CAN_REORDER], sysval=True)
>> +  flags=[CAN_ELIMINATE, CAN_REORDER], sysval=True,
>> +  bit_sizes=bit_sizes)
>>
>>  system_value("frag_coord", 4)
>>  system_value("front_face", 1)
>> diff --git a/src/compiler/nir/nir_intrinsics_c.py 
>> b/src/compiler/nir/nir_intrinsics_c.py
>> index ac45b94d496..d0f1c29fa39 100644
>> --- a/src/compiler/nir/nir_intrinsics_c.py
>> +++ b/src/compiler/nir/nir_intrinsics_c.py
>> @@ -1,3 +1,5 @@
>> +from functools import reduce
>> +import operator
>>
>>  template = """\
>>  /* Copyright (C) 2018 Red Hat
>> @@ -45,6 +47,7 @@ const nir_intrinsic_info 
>> nir_intrinsic_infos[nir_num_intrinsics] = {
>>  },
>>  % endif
>> .flags = ${"0" if len(opcode.flags) == 0 else " | ".join(opcode.flags)},
>> +   .bit_sizes = ${reduce(operator.or_, opcode.bit_sizes, 0)},
>
>
> If we're going to go to all the effort to add these bit sizes to 
> nir_intrinsic_infos, we should make nir_validate validate them.
>
> Also, I'm not sure this line does what you want if bit_sizes = [].  We could 
> choose the 0 means anything goes convention or, since it's a bitfield, we 
> 

Re: [Mesa-dev] [PATCH 3/3] glsl: fix typos in comments "transfor" -> "transform"

[Chema Casanova]

On 21/11/18 20:07, Ilia Mirkin wrote:
> Oh, yay, you fixed the typos here. I just had to keep reading.
> 
> This patch is obviously
> 
> Reviewed-by: Ilia Mirkin 

Thanks.

> 
> For the others ... have you run these through intel's CI?

> I'm interested in verifying that dEQP, CTS, and piglit all remain happy
> with the changes.

Yes. The CI is happy for dEQP, OpenGL CTS and piglit.

https://mesa-ci.01.org/jmcasanova/builds/13/group/63a9f0ea7bb98050796b649e85481845

It detects a regression not related to my changes in vulkancts on BDW
dEQP-VK.­subgroups.­shuffle.­subgroupshuffleup_bvec4_graphic, but in my
BDW it is a pass. (I've just resent the series to confirm it).

> The program resource stuff took a while to nail down
> properly (and it seems like we're discovering issues to this very
> day).

Yes, it took me a while to reduce the change as much as possible to
avoid changing current behavior except for these test cases. They are
corner cases that are not really useful in a real program as data can
not be used because we don't support NV_gpu_shader5 extension.

Thanks for checking the series.

>   -ilia
> On Wed, Nov 21, 2018 at 1:46 PM Jose Maria Casanova Crespo
>  wrote:
>>
>> ---
>>  src/compiler/glsl/ir.h | 6 +++---
>>  1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/src/compiler/glsl/ir.h b/src/compiler/glsl/ir.h
>> index e09f053b77c..c3f5f1f7b05 100644
>> --- a/src/compiler/glsl/ir.h
>> +++ b/src/compiler/glsl/ir.h
>> @@ -773,17 +773,17 @@ public:
>>unsigned is_xfb_per_vertex_output:1;
>>
>>/**
>> -   * Was a transfor feedback buffer set in the shader?
>> +   * Was a transform feedback buffer set in the shader?
>> */
>>unsigned explicit_xfb_buffer:1;
>>
>>/**
>> -   * Was a transfor feedback offset set in the shader?
>> +   * Was a transform feedback offset set in the shader?
>> */
>>unsigned explicit_xfb_offset:1;
>>
>>/**
>> -   * Was a transfor feedback stride set in the shader?
>> +   * Was a transform feedback stride set in the shader?
>> */
>>unsigned explicit_xfb_stride:1;
>>
>> --
>> 2.19.1
>>
>> ___
>> 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 32211] [GLSL] lower_jumps with continue-statements in for-loops prevents loop unrolling

[bugzilla-daemon]

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

--- Comment #13 from Timothy Arceri  ---
(In reply to Danylo from comment #12)
> (In reply to Timothy Arceri from comment #11)
> > 
> > So all we need to do is move everything after the if into the else block and
> > remove the continue. Removing myself as assignee, this would probably be a
> > good beginners task.
> Hi,
> 
> I've tried to do this and it works for me however it alone doesn't solve the
> problem.
> 
> Consider the resulting nir:
> 
> loop {
> block block_1:
> /* preds: block_0 block_7 */
> vec1 32 ssa_8 = phi block_0: ssa_4, block_7: ssa_20
> vec1 32 ssa_9 = phi block_0: ssa_0, block_7: ssa_4
> vec1 32 ssa_10 = phi block_0: ssa_1, block_7: ssa_4
> vec1 32 ssa_11 = phi block_0: ssa_2, block_7: ssa_21
> vec1 32 ssa_12 = phi block_0: ssa_3, block_7: ssa_22
> vec4 32 ssa_13 = vec4 ssa_12, ssa_11, ssa_10, ssa_9
> vec1 32 ssa_14 = ige ssa_8, ssa_5
> /* succs: block_2 block_3 */
> if ssa_14 {
> block block_2:
> /* preds: block_1 */
> break
> /* succs: block_8 */
> } else {
> block block_3:
> /* preds: block_1 */
> /* succs: block_4 */
> }
> block block_4:
> /* preds: block_3 */
> vec1 32 ssa_15 = ilt ssa_6, ssa_8
> /* succs: block_5 block_6 */
> if ssa_15 {
> block block_5:
> /* preds: block_4 */
> vec1 32 ssa_16 = iadd ssa_8, ssa_7
> vec1 32 ssa_17 = load_const (0x3f80 /* 1.00
> */)
> /* succs: block_7 */
> } else {
> block block_6:
> /* preds: block_4 */
> vec1 32 ssa_18 = iadd ssa_8, ssa_7
> vec1 32 ssa_19 = load_const (0x3f80 /* 1.00
> */)
> /* succs: block_7 */
> }
> block block_7:
> /* preds: block_5 block_6 */
> vec1 32 ssa_20 = phi block_5: ssa_16, block_6: ssa_18
> vec1 32 ssa_21 = phi block_5: ssa_17, block_6: ssa_4
> vec1 32 ssa_22 = phi block_5: ssa_4, block_6: ssa_19
> /* succs: block_1 */
> }
> 
> Now in both "if" (block_5) and "else" (block_6) blocks there are identical
> expressions and no continue. 
> However there is no optimization to pull these identical expressions out -
> CSE pass won't do this since it's a local CSE, only global CSE would help.
> And there is no active global CSE pass, there is only Global Code Motion
> pass with Global Value Numbering and it is not enabled, enabling it
> optimizes the condition in question and in the end whole loop disappears as
> expected, however this pass doesn't look something we want since in other
> cases it hurts shaders and it is more than just global CSE.
> 
> Any opinions on this?

None of that should matter. If the continue if removed there should be nothing
stopping the loop from unrolling, and if the loop is unrolled the both ifs
should be able to be optimised away (assuming I'm reading the IR correctly). Is
this not what you are seeing?

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

Re: [Mesa-dev] [PATCH 1/3] glsl: XFB TSC per-vertex output varyings match as not declared as arrays

[Chema Casanova]

On 21/11/18 20:04, Ilia Mirkin wrote:
> On Wed, Nov 21, 2018 at 1:45 PM Jose Maria Casanova Crespo
>  wrote:
>>
>> Recent change on OpenGL CTS ("Use non-arrayed varying name for TCS blocks")
>> on KHR-GL*.tessellation_shader.single.xfb_captures_data_from_correct_stage
>> tests changed how to name per-vertex Tessellation Control Shader output
>> varyings in transform feedback using interface block as "BLOCK_INOUT.value"
>> rather than "BLOCK_INOUT[0].value"
>>
>> So Tessellation control shader per-vertex output variables and blocks that
>> are required to be declared as arrays, with each element representing output
>> values for a single vertex of a multi-vertex primitive are expected to be
>> named as they were not declared as arrays.
>>
>> This patch adds a new is_xfb_per_vertex_output flag at ir_variable level so
>> we mark when an ir_variable is an per-vertex TCS output varying. So we
>> treat it in terms on XFB its naming as a non array variable.
>>
>> As we don't support NV_gpu_shader5, so PATCHES mode is not accepted as
>> primitiveMode parameter of BeginTransformFeedback the test expects a
>> failure as we can use the XFB results.
>>
>> This patch uncovers that we were passing the GLES version of the tests
>> because candidates naming didn't match, not because on GLES the Tessellation
>> Control stage varyings shouldn't be XFB candidates in any case. This
>> is addressed in the following patch.
>>
>> Fixes: 
>> KHR-GL4*.tessellation_shader.single.xfb_captures_data_from_correct_stage
>>
>> Cc: mesa-sta...@lists.freedesktop.org
>> ---
>>  src/compiler/glsl/ir.cpp| 1 +
>>  src/compiler/glsl/ir.h  | 6 ++
>>  src/compiler/glsl/link_uniforms.cpp | 6 --
>>  src/compiler/glsl/link_varyings.cpp | 8 +++-
>>  4 files changed, 18 insertions(+), 3 deletions(-)
>>
>> diff --git a/src/compiler/glsl/ir.cpp b/src/compiler/glsl/ir.cpp
>> index 1d1a56ae9a5..582111d71f5 100644
>> --- a/src/compiler/glsl/ir.cpp
>> +++ b/src/compiler/glsl/ir.cpp
>> @@ -1750,6 +1750,7 @@ ir_variable::ir_variable(const struct glsl_type *type, 
>> const char *name,
>> this->data.fb_fetch_output = false;
>> this->data.bindless = false;
>> this->data.bound = false;
>> +   this->data.is_xfb_per_vertex_output = false;
>>
>> if (type != NULL) {
>>if (type->is_interface())
>> diff --git a/src/compiler/glsl/ir.h b/src/compiler/glsl/ir.h
>> index f478b29a6b5..e09f053b77c 100644
>> --- a/src/compiler/glsl/ir.h
>> +++ b/src/compiler/glsl/ir.h
>> @@ -766,6 +766,12 @@ public:
>> */
>>unsigned is_xfb_only:1;
>>
>> +  /**
>> +   * Is this varying a TSC per-vertex output candidate for transform
> 
> TCS?


Yes. I've fixed it locally at the commit summary too.


>> +   * feedback?
>> +   */
>> +  unsigned is_xfb_per_vertex_output:1;
>> +
>>/**
>> * Was a transfor feedback buffer set in the shader?
> 
> ugh, not your problem, but "transform" :(
> 
>> */
>> diff --git a/src/compiler/glsl/link_uniforms.cpp 
>> b/src/compiler/glsl/link_uniforms.cpp
>> index 63e688b19a7..547da68e216 100644
>> --- a/src/compiler/glsl/link_uniforms.cpp
>> +++ b/src/compiler/glsl/link_uniforms.cpp
>> @@ -72,8 +72,10 @@ program_resource_visitor::process(ir_variable *var, bool 
>> use_std430_as_default)
>>   get_internal_ifc_packing(use_std430_as_default) :
>>var->type->get_internal_ifc_packing(use_std430_as_default);
>>
>> -   const glsl_type *t =
>> -  var->data.from_named_ifc_block ? var->get_interface_type() : 
>> var->type;
>> +   const glsl_type *t = var->data.from_named_ifc_block ?
>> +  (var->data.is_xfb_per_vertex_output ?
>> +   var->get_interface_type()->without_array() :
>> +   var->get_interface_type()) : var->type;
>> const glsl_type *t_without_array = t->without_array();
>>
>> /* false is always passed for the row_major parameter to the other
>> diff --git a/src/compiler/glsl/link_varyings.cpp 
>> b/src/compiler/glsl/link_varyings.cpp
>> index 52e493cb599..1964dcc0a22 100644
>> --- a/src/compiler/glsl/link_varyings.cpp
>> +++ b/src/compiler/glsl/link_varyings.cpp
>> @@ -2150,7 +2150,10 @@ private:
>>tfeedback_candidate *candidate
>>   = rzalloc(this->mem_ctx, tfeedback_candidate);
>>candidate->toplevel_var = this->toplevel_var;
>> -  candidate->type = type;
>> +  if (this->toplevel_var->data.is_xfb_per_vertex_output)
>> + candidate->type = type->without_array();
>> +  else
>> + candidate->type = type;
>>candidate->offset = this->varying_floats;
>>_mesa_hash_table_insert(this->tfeedback_candidates,
>>ralloc_strdup(this->mem_ctx, name),
>> @@ -2499,6 +2502,9 @@ assign_varying_locations(struct gl_context *ctx,
>>
>>   if (num_tfeedback_decls > 0) {
>>  tfeedback_candidate_generator g(mem_ctx, tfeedback_candidates);
>> +if (producer->Stage == MESA_SHADER_TESS_CTRL &&
>> +

[Mesa-dev] [PATCH] virgl: quadruple command buffer size

[Gurchetan Singh]

Tested running WebGL aquarium on Nvidia host (10,000 fishes)

This moves us from 7 fps to 9 fps.  After quadrupling, performance
gains diminish.

Change-Id: Iba3a9929ba2d17cf5a38233b92391dd413b79bc2
---
 src/gallium/drivers/virgl/virgl_winsys.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/virgl/virgl_winsys.h 
b/src/gallium/drivers/virgl/virgl_winsys.h
index d13212c5e8..96726b409d 100644
--- a/src/gallium/drivers/virgl/virgl_winsys.h
+++ b/src/gallium/drivers/virgl/virgl_winsys.h
@@ -31,7 +31,7 @@ struct pipe_fence_handle;
 struct winsys_handle;
 struct virgl_hw_res;
 
-#define VIRGL_MAX_CMDBUF_DWORDS (16*1024)
+#define VIRGL_MAX_CMDBUF_DWORDS (64 * 1024)
 
 struct virgl_drm_caps {
union virgl_caps caps;
-- 
2.18.1

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

[Mesa-dev] [PATCH 2/2] anv/nir: Rework arguments to apply_pipeline_layout

[Jason Ekstrand]

Instead of taking a whole pipeline (which could be anything!), just take
a physical device and robust_buffer_access boolean.  This makes it
easier to verify that only the things in the hash actually affect
pipeline compilation.
---
 src/intel/vulkan/anv_nir.h   | 3 ++-
 src/intel/vulkan/anv_nir_apply_pipeline_layout.c | 5 +++--
 src/intel/vulkan/anv_pipeline.c  | 4 +++-
 3 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/src/intel/vulkan/anv_nir.h b/src/intel/vulkan/anv_nir.h
index cf90c90f857..dd6c89529ac 100644
--- a/src/intel/vulkan/anv_nir.h
+++ b/src/intel/vulkan/anv_nir.h
@@ -40,7 +40,8 @@ bool anv_nir_lower_multiview(nir_shader *shader, uint32_t 
view_mask);
 bool anv_nir_lower_ycbcr_textures(nir_shader *shader,
   struct anv_pipeline_layout *layout);
 
-void anv_nir_apply_pipeline_layout(struct anv_pipeline *pipeline,
+void anv_nir_apply_pipeline_layout(const struct anv_physical_device *pdevice,
+   bool robust_buffer_access,
struct anv_pipeline_layout *layout,
nir_shader *shader,
struct brw_stage_prog_data *prog_data,
diff --git a/src/intel/vulkan/anv_nir_apply_pipeline_layout.c 
b/src/intel/vulkan/anv_nir_apply_pipeline_layout.c
index fa967c217e7..4e405ae4bb0 100644
--- a/src/intel/vulkan/anv_nir_apply_pipeline_layout.c
+++ b/src/intel/vulkan/anv_nir_apply_pipeline_layout.c
@@ -423,7 +423,8 @@ setup_vec4_uniform_value(uint32_t *params, uint32_t offset, 
unsigned n)
 }
 
 void
-anv_nir_apply_pipeline_layout(struct anv_pipeline *pipeline,
+anv_nir_apply_pipeline_layout(const struct anv_physical_device *pdevice,
+  bool robust_buffer_access,
   struct anv_pipeline_layout *layout,
   nir_shader *shader,
   struct brw_stage_prog_data *prog_data,
@@ -434,7 +435,7 @@ anv_nir_apply_pipeline_layout(struct anv_pipeline *pipeline,
struct apply_pipeline_layout_state state = {
   .shader = shader,
   .layout = layout,
-  .add_bounds_checks = pipeline->device->robust_buffer_access,
+  .add_bounds_checks = robust_buffer_access,
};
 
void *mem_ctx = ralloc_context(NULL);
diff --git a/src/intel/vulkan/anv_pipeline.c b/src/intel/vulkan/anv_pipeline.c
index f170366d030..ee37685fccf 100644
--- a/src/intel/vulkan/anv_pipeline.c
+++ b/src/intel/vulkan/anv_pipeline.c
@@ -532,7 +532,9 @@ anv_pipeline_lower_nir(struct anv_pipeline *pipeline,
 
/* Apply the actual pipeline layout to UBOs, SSBOs, and textures */
if (layout) {
-  anv_nir_apply_pipeline_layout(pipeline, layout, nir, prog_data,
+  
anv_nir_apply_pipeline_layout(>device->instance->physicalDevice,
+pipeline->device->robust_buffer_access,
+layout, nir, prog_data,
 >bind_map);
}
 
-- 
2.19.1

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

[Mesa-dev] [PATCH 1/2] anv: Put robust buffer access in the pipeline hash

[Jason Ekstrand]

It affects apply_pipeline_layout.  Shaders compiled with the wrong value
will work but they may not be robust as requested by the app.

Cc: mesa-sta...@lists.freedesktop.org
---
 src/intel/vulkan/anv_pipeline.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/src/intel/vulkan/anv_pipeline.c b/src/intel/vulkan/anv_pipeline.c
index ad0f08253e7..f170366d030 100644
--- a/src/intel/vulkan/anv_pipeline.c
+++ b/src/intel/vulkan/anv_pipeline.c
@@ -446,6 +446,9 @@ anv_pipeline_hash_graphics(struct anv_pipeline *pipeline,
if (layout)
   _mesa_sha1_update(, layout->sha1, sizeof(layout->sha1));
 
+   const bool rba = pipeline->device->robust_buffer_access;
+   _mesa_sha1_update(, , sizeof(rba));
+
for (unsigned s = 0; s < MESA_SHADER_STAGES; s++) {
   if (stages[s].entrypoint)
  anv_pipeline_hash_shader(, [s]);
@@ -466,6 +469,9 @@ anv_pipeline_hash_compute(struct anv_pipeline *pipeline,
if (layout)
   _mesa_sha1_update(, layout->sha1, sizeof(layout->sha1));
 
+   const bool rba = pipeline->device->robust_buffer_access;
+   _mesa_sha1_update(, , sizeof(rba));
+
anv_pipeline_hash_shader(, stage);
 
_mesa_sha1_final(, sha1_out);
-- 
2.19.1

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

Re: [Mesa-dev] [PATCH] intel/compiler: Always print flag subregister number

[Matt Turner]

On Thu, Nov 15, 2018 at 2:16 PM Sagar Ghuge  wrote:
>
> While disassembling the predicate always print flag subregister number
> to keep grammar same across the generation for assembler tool.

That's reasonable.

> Signed-off-by: Sagar Ghuge 
> ---
>  src/intel/compiler/brw_disasm.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/src/intel/compiler/brw_disasm.c b/src/intel/compiler/brw_disasm.c
> index 6c79fec0a1..a218e1451c 100644
> --- a/src/intel/compiler/brw_disasm.c
> +++ b/src/intel/compiler/brw_disasm.c
> @@ -1486,8 +1486,7 @@ brw_disassemble_inst(FILE *file, const struct 
> gen_device_info *devinfo,
>err |= control(file, "predicate inverse", pred_inv,
>   brw_inst_pred_inv(devinfo, inst), NULL);
>format(file, "f%"PRIu64, devinfo->gen >= 7 ? 
> brw_inst_flag_reg_nr(devinfo, inst) : 0);
> -  if (brw_inst_flag_subreg_nr(devinfo, inst))
> - format(file, ".%"PRIu64, brw_inst_flag_subreg_nr(devinfo, inst));
> +  format(file, ".%"PRIu64, brw_inst_flag_subreg_nr(devinfo, inst));

I would combine the two format() calls here.

>if (brw_inst_access_mode(devinfo, inst) == BRW_ALIGN_1) {
>   err |= control(file, "predicate control align1", pred_ctrl_align1,
>  brw_inst_pred_control(devinfo, inst), NULL);
> --

In the same function (brw_disassemble_inst) a little below here there
is an additional place where we conditionally print the flag
subregister number. I suspect you want to change it too.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 99553] Tracker bug for runnning OpenCL applications on Clover

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99553
Bug 99553 depends on bug 108087, which changed state.

Bug 108087 Summary: Memory leak in clover::kernel::argument::create<>() (i.e. 
clEnqueueNDRangeKernel())
https://bugs.freedesktop.org/show_bug.cgi?id=108087

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

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

[Mesa-dev] [Bug 108087] Memory leak in clover::kernel::argument::create<>() (i.e. clEnqueueNDRangeKernel())

[bugzilla-daemon]

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

Dylan Baker  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #3 from Dylan Baker  ---
Mesa 18.1 is EOL at this point and there will be no more releases, if you can
still reproduce this with 18.2 or current master later please reopen.

-- 
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 14/22] nir: add legal bit_sizes to intrinsics

[Jason Ekstrand]

On Tue, Nov 13, 2018 at 9:49 AM Karol Herbst  wrote:

> With OpenCL some system values match the address bits, but in GLSL we also
> have some system values being 64 bit.
>
> With this it is possible to adjust the builder functions so that depending
> on the bit_sizes the correct bit_size is used or an additional argument is
> added in case of multiple possible values.
>
> Also this allows for further validation
>
> Signed-off-by: Karol Herbst 
> ---
>  src/compiler/nir/nir.h   |  3 +++
>  src/compiler/nir/nir_intrinsics.py   | 15 ++-
>  src/compiler/nir/nir_intrinsics_c.py |  6 +-
>  src/nouveau/meson.build  | 25 +
>  4 files changed, 43 insertions(+), 6 deletions(-)
>  create mode 100644 src/nouveau/meson.build
>
> diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
> index be4f64464f9..3855eb0b582 100644
> --- a/src/compiler/nir/nir.h
> +++ b/src/compiler/nir/nir.h
> @@ -1283,6 +1283,9 @@ typedef struct {
>
> /** semantic flags for calls to this intrinsic */
> nir_intrinsic_semantic_flag flags;
> +
> +   /** bitfield of legal bit sizes */
> +   unsigned bit_sizes : 7;
>  } nir_intrinsic_info;
>
>  extern const nir_intrinsic_info nir_intrinsic_infos[nir_num_intrinsics];
> diff --git a/src/compiler/nir/nir_intrinsics.py
> b/src/compiler/nir/nir_intrinsics.py
> index ec3049ca06d..9ada44aad8a 100644
> --- a/src/compiler/nir/nir_intrinsics.py
> +++ b/src/compiler/nir/nir_intrinsics.py
> @@ -32,7 +32,7 @@ class Intrinsic(object):
> NOTE: this must be kept in sync with nir_intrinsic_info.
> """
> def __init__(self, name, src_components, dest_components,
> -indices, flags, sysval):
> +indices, flags, sysval, bit_sizes):
> """Parameters:
>
> - name: the intrinsic name
> @@ -45,6 +45,7 @@ class Intrinsic(object):
> - indices: list of constant indicies
> - flags: list of semantic flags
> - sysval: is this a system-value intrinsic
> +   - bit_sizes: allowed dest bit_sizes
> """
> assert isinstance(name, str)
> assert isinstance(src_components, list)
> @@ -58,6 +59,8 @@ class Intrinsic(object):
> if flags:
> assert isinstance(flags[0], str)
> assert isinstance(sysval, bool)
> +   if bit_sizes:
> +   assert isinstance(bit_sizes[0], int)
>
> self.name = name
> self.num_srcs = len(src_components)
> @@ -68,6 +71,7 @@ class Intrinsic(object):
> self.indices = indices
> self.flags = flags
> self.sysval = sysval
> +   self.bit_sizes = bit_sizes
>
>  #
>  # Possible indices:
> @@ -120,10 +124,10 @@ CAN_REORDER   = "NIR_INTRINSIC_CAN_REORDER"
>  INTR_OPCODES = {}
>
>  def intrinsic(name, src_comp=[], dest_comp=-1, indices=[],
> -  flags=[], sysval=False):
> +  flags=[], sysval=False, bit_sizes=[]):
>  assert name not in INTR_OPCODES
>  INTR_OPCODES[name] = Intrinsic(name, src_comp, dest_comp,
> -   indices, flags, sysval)
> +   indices, flags, sysval, bit_sizes)
>
>  intrinsic("nop", flags=[CAN_ELIMINATE])
>
> @@ -446,9 +450,10 @@ intrinsic("shared_atomic_fmin",  src_comp=[1, 1],
> dest_comp=1, indices=[BASE])
>  intrinsic("shared_atomic_fmax",  src_comp=[1, 1], dest_comp=1,
> indices=[BASE])
>  intrinsic("shared_atomic_fcomp_swap", src_comp=[1, 1, 1], dest_comp=1,
> indices=[BASE])
>
> -def system_value(name, dest_comp, indices=[]):
> +def system_value(name, dest_comp, indices=[], bit_sizes=[32]):
>  intrinsic("load_" + name, [], dest_comp, indices,
> -  flags=[CAN_ELIMINATE, CAN_REORDER], sysval=True)
> +  flags=[CAN_ELIMINATE, CAN_REORDER], sysval=True,
> +  bit_sizes=bit_sizes)
>
>  system_value("frag_coord", 4)
>  system_value("front_face", 1)
> diff --git a/src/compiler/nir/nir_intrinsics_c.py
> b/src/compiler/nir/nir_intrinsics_c.py
> index ac45b94d496..d0f1c29fa39 100644
> --- a/src/compiler/nir/nir_intrinsics_c.py
> +++ b/src/compiler/nir/nir_intrinsics_c.py
> @@ -1,3 +1,5 @@
> +from functools import reduce
> +import operator
>
>  template = """\
>  /* Copyright (C) 2018 Red Hat
> @@ -45,6 +47,7 @@ const nir_intrinsic_info
> nir_intrinsic_infos[nir_num_intrinsics] = {
>  },
>  % endif
> .flags = ${"0" if len(opcode.flags) == 0 else " |
> ".join(opcode.flags)},
> +   .bit_sizes = ${reduce(operator.or_, opcode.bit_sizes, 0)},
>

If we're going to go to all the effort to add these bit sizes to
nir_intrinsic_infos, we should make nir_validate validate them.

Also, I'm not sure this line does what you want if bit_sizes = [].  We
could choose the 0 means anything goes convention or, since it's a
bitfield, we could do 0x78 when it's allowed to be anything.  Or we could
just change the default in python to [8, 16, 32, 64].  In any case, we
should do something sensible.

--Jason


>  },
>  % endfor
>  };
> @@ 

Re: [Mesa-dev] [PATCH 12/22] nir: add type alignment support to lower_io

[Jason Ekstrand]

On Tue, Nov 13, 2018 at 9:48 AM Karol Herbst  wrote:

> From: Rob Clark 
>
> For cl we can have structs with 8/16/32/64 bit scalar types (as well as,
> ofc, arrays/structs/etc), which are padded according to 'C' rules.  So
> for lowering struct deref's we need to not just consider a field's size,
> but also it's alignment.
>
> Signed-off-by: Karol Herbst 
> ---
>  src/compiler/nir/nir.h  | 10 +++
>  src/compiler/nir/nir_lower_io.c | 52 -
>  2 files changed, 49 insertions(+), 13 deletions(-)
>
> diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
> index c469e111b2c..11e3d18320a 100644
> --- a/src/compiler/nir/nir.h
> +++ b/src/compiler/nir/nir.h
> @@ -2825,10 +2825,20 @@ typedef enum {
>  */
> nir_lower_io_force_sample_interpolation = (1 << 1),
>  } nir_lower_io_options;
> +typedef struct nir_memory_model {
> +   int (*type_size)(const struct glsl_type *);
> +   int (*type_align)(const struct glsl_type *);
> +} nir_memory_model;
>

I don't really like the name "memory model".  In my mind, that implies a
lot more than just a scheme for laying out memory.  Maybe nir_io_layout_cb
or nir_io_type_size_align_cb?

I made this comment to Karol on IRC but I did something similar but with a
different approach with glsl_get_natural_size_align.  I think I like this
approach better.  It's potentially a bit less efficient but it's way
simpler.  We should convert the constant lowering code over to it so we can
be consistent.


>  bool nir_lower_io(nir_shader *shader,
>nir_variable_mode modes,
>int (*type_size)(const struct glsl_type *),
>nir_lower_io_options);
> +// TEMP use different name to avoid fixing all the callers yet:
> +bool nir_lower_io2(nir_shader *shader,
> +  nir_variable_mode modes,
> +  const nir_memory_model *mm,
> +  nir_lower_io_options);
> +
>  nir_src *nir_get_io_offset_src(nir_intrinsic_instr *instr);
>  nir_src *nir_get_io_vertex_index_src(nir_intrinsic_instr *instr);
>
> diff --git a/src/compiler/nir/nir_lower_io.c
> b/src/compiler/nir/nir_lower_io.c
> index 2a6c284de2b..292baf9e4fc 100644
> --- a/src/compiler/nir/nir_lower_io.c
> +++ b/src/compiler/nir/nir_lower_io.c
> @@ -38,7 +38,7 @@
>  struct lower_io_state {
> void *dead_ctx;
> nir_builder builder;
> -   int (*type_size)(const struct glsl_type *type);
> +   const nir_memory_model *mm;
> nir_variable_mode modes;
> nir_lower_io_options options;
>  };
> @@ -86,12 +86,26 @@ nir_is_per_vertex_io(const nir_variable *var,
> gl_shader_stage stage)
> return false;
>  }
>
> +static int
> +default_type_align(const struct glsl_type *type)
> +{
> +   return 1;
> +}
> +
> +static inline int
> +align(int value, int alignment)
> +{
> +   return (value + alignment - 1) & ~(alignment - 1);
> +}
>

we have an ALIGN macro which should be accessible from here which does
exactly that.


> +
>  static nir_ssa_def *
>  get_io_offset(nir_deref_instr *deref, nir_ssa_def **vertex_index,
>struct lower_io_state *state, unsigned *component)
>  {
> nir_builder *b = >builder;
> -   int (*type_size)(const struct glsl_type *) = state->type_size;
> +   int (*type_size)(const struct glsl_type *) = state->mm->type_size;
> +   int (*type_align)(const struct glsl_type *) = state->mm->type_align ?
> +  state->mm->type_align : default_type_align;
> nir_deref_path path;
> nir_deref_path_init(, deref, NULL);
>
> @@ -137,7 +151,10 @@ get_io_offset(nir_deref_instr *deref, nir_ssa_def
> **vertex_index,
>
>   unsigned field_offset = 0;
>   for (unsigned i = 0; i < (*p)->strct.index; i++) {
> -field_offset += type_size(glsl_get_struct_field(parent->type,
> i));
> +const struct glsl_type *field_type =
> +   glsl_get_struct_field(parent->type, i);
> +field_offset = align(field_offset, type_align(field_type));
> +field_offset += type_size(field_type);
>   }
>   offset = nir_iadd(b, offset, nir_imm_int(b, field_offset));
>} else {
> @@ -207,7 +224,7 @@ lower_load(nir_intrinsic_instr *intrin, struct
> lower_io_state *state,
>nir_intrinsic_set_component(load, component);
>
> if (load->intrinsic == nir_intrinsic_load_uniform)
> -  nir_intrinsic_set_range(load, state->type_size(var->type));
> +  nir_intrinsic_set_range(load, state->mm->type_size(var->type));
>
> if (vertex_index) {
>load->src[0] = nir_src_for_ssa(vertex_index);
> @@ -488,10 +505,8 @@ nir_lower_io_block(nir_block *block,
>  }
>
>  static bool
> -nir_lower_io_impl(nir_function_impl *impl,
> -  nir_variable_mode modes,
> -  int (*type_size)(const struct glsl_type *),
> -  nir_lower_io_options options)
> +nir_lower_io_impl(nir_function_impl *impl, nir_variable_mode modes,
> +  const nir_memory_model *mm, nir_lower_io_options

Re: [Mesa-dev] [PATCH 10/22] nir/vtn: add caps for some cl related capabilities

[Jason Ekstrand]

patches 6 and 10 are

Reviewed-by: Jason Ekstrand 

On Tue, Nov 13, 2018 at 9:49 AM Karol Herbst  wrote:

> From: Rob Clark 
>
> vtn supports these, so don't squalk if user is happy with enabling
> these.
>
> Signed-off-by: Karol Herbst 
> ---
>  src/compiler/shader_info.h |  3 +++
>  src/compiler/spirv/spirv_to_nir.c  | 16 +---
>  src/compiler/spirv/vtn_variables.c |  6 --
>  3 files changed, 20 insertions(+), 5 deletions(-)
>
> diff --git a/src/compiler/shader_info.h b/src/compiler/shader_info.h
> index 65bc0588d67..5286cf8fc5f 100644
> --- a/src/compiler/shader_info.h
> +++ b/src/compiler/shader_info.h
> @@ -62,6 +62,9 @@ struct spirv_supported_capabilities {
> bool post_depth_coverage;
> bool transform_feedback;
> bool geometry_streams;
> +   bool address;
> +   bool kernel;
> +   bool int8;
>  };
>
>  typedef struct shader_info {
> diff --git a/src/compiler/spirv/spirv_to_nir.c
> b/src/compiler/spirv/spirv_to_nir.c
> index d7dd5a67cc4..db2ee51340c 100644
> --- a/src/compiler/spirv/spirv_to_nir.c
> +++ b/src/compiler/spirv/spirv_to_nir.c
> @@ -792,8 +792,10 @@ struct_member_decoration_cb(struct vtn_builder *b,
> case SpvDecorationFPRoundingMode:
> case SpvDecorationFPFastMathMode:
> case SpvDecorationAlignment:
> -  vtn_warn("Decoration only allowed for CL-style kernels: %s",
> -   spirv_decoration_to_string(dec->decoration));
> +  if (!b->kernel_mode) {
> + vtn_warn("Decoration only allowed for CL-style kernels: %s",
> +  spirv_decoration_to_string(dec->decoration));
> +  }
>break;
>
> case SpvDecorationHlslSemanticGOOGLE:
> @@ -3428,7 +3430,6 @@ vtn_handle_preamble_instruction(struct vtn_builder
> *b, SpvOp opcode,
>case SpvCapabilityFloat16:
>case SpvCapabilityInt64Atomics:
>case SpvCapabilityStorageImageMultisample:
> -  case SpvCapabilityInt8:
>case SpvCapabilitySparseResidency:
>case SpvCapabilityMinLod:
>   vtn_warn("Unsupported SPIR-V capability: %s",
> @@ -3457,8 +3458,17 @@ vtn_handle_preamble_instruction(struct vtn_builder
> *b, SpvOp opcode,
>   spv_check_supported(geometry_streams, cap);
>   break;
>
> +  case SpvCapabilityInt8:
> + spv_check_supported(int8, cap);
> + break;
> +
>case SpvCapabilityAddresses:
> + spv_check_supported(address, cap);
> + break;
>case SpvCapabilityKernel:
> + spv_check_supported(kernel, cap);
> + break;
> +
>case SpvCapabilityImageBasic:
>case SpvCapabilityImageReadWrite:
>case SpvCapabilityImageMipmap:
> diff --git a/src/compiler/spirv/vtn_variables.c
> b/src/compiler/spirv/vtn_variables.c
> index c5cf345d02a..e7654b768af 100644
> --- a/src/compiler/spirv/vtn_variables.c
> +++ b/src/compiler/spirv/vtn_variables.c
> @@ -1371,8 +1371,10 @@ apply_var_decoration(struct vtn_builder *b,
> case SpvDecorationFPRoundingMode:
> case SpvDecorationFPFastMathMode:
> case SpvDecorationAlignment:
> -  vtn_warn("Decoration only allowed for CL-style kernels: %s",
> -   spirv_decoration_to_string(dec->decoration));
> +  if (!b->kernel_mode) {
> + vtn_warn("Decoration only allowed for CL-style kernels: %s",
> +  spirv_decoration_to_string(dec->decoration));
> +  }
>break;
>
> case SpvDecorationHlslSemanticGOOGLE:
> --
> 2.19.1
>
> ___
> 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 04/22] nir/spirv: add OpIsFinite and OpIsNormal

[Jason Ekstrand]

On Tue, Nov 13, 2018 at 9:48 AM Karol Herbst  wrote:

> From: Rob Clark 
>
> changes by Karol:
> v2: make compatible with 64 bit floats
> fix isfinite
> v3: use snake_case.
>
> Signed-off-by: Karol Herbst 
> ---
>  src/compiler/spirv/vtn_alu.c | 32 
>  1 file changed, 32 insertions(+)
>
> diff --git a/src/compiler/spirv/vtn_alu.c b/src/compiler/spirv/vtn_alu.c
> index b1492c1501a..ea25d4bcbdc 100644
> --- a/src/compiler/spirv/vtn_alu.c
> +++ b/src/compiler/spirv/vtn_alu.c
> @@ -583,6 +583,38 @@ vtn_handle_alu(struct vtn_builder *b, SpvOp opcode,
>break;
> }
>
> +   case SpvOpIsFinite: {
> +  nir_ssa_def *inf = nir_imm_floatN_t(>nb, INFINITY,
> src[0]->bit_size);
> +  nir_ssa_def *is_number = nir_feq(>nb, src[0], src[0]);
> +  nir_ssa_def *is_not_inf = nir_ine(>nb, nir_fabs(>nb, src[0]),
> inf);
> +  val->ssa->def = nir_iand(>nb, is_number, is_not_inf);
>

What we really want here is FOrdNotEqual.  Unfortunately, I'm not sure
we're handling ordered vs. not correctly in the NIR opcodes but you should
be able to just do return is_not_inf and the abs(x) != INF will return
false if x is NaN assuming that abs handles NaN correctly.

Also, set b->nb.exact = true prior to this sequence to make it build exact
opcodes so that NIR doesn't try to optimize anything away.

Also, I think it'd be nice to have these in builder helpers.  Not a bit
deal but it'd be nice.


> +  break;
> +   }
> +
> +   case SpvOpIsNormal: {
> +  unsigned bit_size = src[0]->bit_size;
> +
> +  uint32_t m;
> +  if (bit_size == 64)
> + m = 11;
> +  else if (bit_size == 32)
> + m = 8;
> +  else if (bit_size == 16)
> + m = 5;
> +  else
> + assert(!"unknown float type");
> +
> +  nir_ssa_def *shift = nir_imm_int(>nb, bit_size - m - 1);
> +  nir_ssa_def *abs = nir_fabs(>nb, src[0]);
> +  nir_ssa_def *exp = nir_iadd(>nb,
> +  nir_ushr(>nb, abs, shift),
> +  nir_imm_intN_t(>nb, -1, bit_size));
> +  val->ssa->def = nir_ult(>nb,
> +  exp,
> +  nir_imm_intN_t(>nb, (1 << m) - 2,
> bit_size));
>

I think you can do this way simpler:

iand(fne(x, 0.0), i2b(iand(x, 0x7f80)))

assuming 0 is considered normal.


> +  break;
> +   }
> +
> case SpvOpFUnordEqual:
> case SpvOpFUnordNotEqual:
> case SpvOpFUnordLessThan:
> --
> 2.19.1
>
> ___
> 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 3/7] util/slab: Add function to flush allocations from a child pool

[Haehnle, Nicolai]

On 21.11.18 22:23, Ian Romanick wrote:
> On 11/21/2018 12:23 PM, Haehnle, Nicolai wrote:
>> On 21.11.18 19:19, Ian Romanick wrote:
>>> On 11/21/2018 03:08 AM, Haehnle, Nicolai wrote:
 On 21.11.18 01:39, Ian Romanick wrote:
> From: Ian Romanick 
>
> Ralloc has a feature that all allocations from a temporary memory
> context can be whisked away in a single call without fear of leaks.  As
> the slab allocator is designed for use in multhreaded scenarios with a
> child pool per CPU, it lacks this feature.  However, many users will be
> single threaded with a single child pool.  For these users, we can have
> our cake and eat it too.
>
> Signed-off-by: Ian Romanick 
> Cc: Nicolai Hähnle 
> ---
> src/util/slab.c | 21 +
> src/util/slab.h |  1 +
> 2 files changed, 22 insertions(+)
>
> diff --git a/src/util/slab.c b/src/util/slab.c
> index 5f048666b56..1bcc1db6e09 100644
> --- a/src/util/slab.c
> +++ b/src/util/slab.c
> @@ -172,6 +172,27 @@ void slab_destroy_child(struct slab_child_pool *pool)
>pool->parent = NULL;
> }
> 
> +/**
> + * Flush all allocations from a pool.  Single-threaded (no mutex).
> + */
> +void
> +slab_flush_st(struct slab_mempool *parent)

 The name of the function argument should be "pool" for consistency.
>>>
>>> This is one thing that annoyed me while writing this function.
>>> Sometimes "pool" is a slab_mempool.  Sometimes "pool" is a
>>> slab_child_pool.  What do you do when you have both?  For the most part,
>>> the thing that gets the most use in a function is the thing called pool.
>>>In this case, that's the slab_child_pool, but that's not the parameter
>>> passed in.
>>>
>>> slab_alloc_st, slab_free_st, slab_create, and slab_destroy are the only
>>> other functions that take a slab_mempool.  These functions work around
>>> this issue by immediately calling some other public function with
>>> >child.  I didn't want to make a public function to flush an
>>> arbitrary slab_child_pool because that's very dangerous in the general
>>> case.  Having a one-line public function that calls a private function
>>> will just beg some newbie to come along and fix it... and end up with
>>> the same problem. :)
>>>
> +{
> +   struct slab_child_pool *const pool = >child;
> +
> +   assert(pool->migrated == NULL);
> +   assert(pool->parent == parent);

 I'm surprised this works. Why isn't pool->parent == >parent?
>>>
>>> This is just a sanity check on an invariant of the data structure.  If
>>> the slab_mempool wasn't initialized or if it has been destroyed,
>>> parent->child.parent will be garbage or NULL.
>>
>> Right, I get that, but pool->parent is of type slab_parent_pool while
>> parent is of type slab_mempool. I don't see how that adds up.
> 
> Ah, now I see what you're saying.  Ignoring the other naming discussion,
> this should be
> 
> assert(pool->parent == >parent);
> 
> On that topic... how would you feel about changing the "pool" parameter
> to be "mempool" in the 5 places (counting the one added by this patch)
> where that parameter has type 'struct slab_mempool *'?  Then we'll
> universally have 'struct slab_child_pool *pool' and 'struct slab_mempool
> *mempool'.

+1, that's a good idea!

Cheers,
Nicolai


> 
>> Cheers,
>> Nicolai
>>
 Or, with a consistently named function argument, why isn't
 pool->child.parent == >parent?

 The intention of the patch looks fine though.

 Cheers,
 Nicolai


> +
> +   while (pool->pages) {
> +  struct slab_page_header *page = pool->pages;
> +  pool->pages = page->u.next;
> +
> +  free(page);
> +   }
> +
> +   pool->free = NULL;
> +}
> +
> static bool
> slab_add_new_page(struct slab_child_pool *pool)
> {
> diff --git a/src/util/slab.h b/src/util/slab.h
> index e83f8ec1a0e..a4279d8e65b 100644
> --- a/src/util/slab.h
> +++ b/src/util/slab.h
> @@ -90,5 +90,6 @@ void slab_create(struct slab_mempool *pool,
> void slab_destroy(struct slab_mempool *pool);
> void *slab_alloc_st(struct slab_mempool *pool);
> void slab_free_st(struct slab_mempool *pool, void *ptr);
> +void slab_flush_st(struct slab_mempool *parent);
> 
> #endif
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/7] util/slab: Add function to flush allocations from a child pool

[Ian Romanick]

On 11/21/2018 12:23 PM, Haehnle, Nicolai wrote:
> On 21.11.18 19:19, Ian Romanick wrote:
>> On 11/21/2018 03:08 AM, Haehnle, Nicolai wrote:
>>> On 21.11.18 01:39, Ian Romanick wrote:
 From: Ian Romanick 

 Ralloc has a feature that all allocations from a temporary memory
 context can be whisked away in a single call without fear of leaks.  As
 the slab allocator is designed for use in multhreaded scenarios with a
 child pool per CPU, it lacks this feature.  However, many users will be
 single threaded with a single child pool.  For these users, we can have
 our cake and eat it too.

 Signed-off-by: Ian Romanick 
 Cc: Nicolai Hähnle 
 ---
src/util/slab.c | 21 +
src/util/slab.h |  1 +
2 files changed, 22 insertions(+)

 diff --git a/src/util/slab.c b/src/util/slab.c
 index 5f048666b56..1bcc1db6e09 100644
 --- a/src/util/slab.c
 +++ b/src/util/slab.c
 @@ -172,6 +172,27 @@ void slab_destroy_child(struct slab_child_pool *pool)
   pool->parent = NULL;
}

 +/**
 + * Flush all allocations from a pool.  Single-threaded (no mutex).
 + */
 +void
 +slab_flush_st(struct slab_mempool *parent)
>>>
>>> The name of the function argument should be "pool" for consistency.
>>
>> This is one thing that annoyed me while writing this function.
>> Sometimes "pool" is a slab_mempool.  Sometimes "pool" is a
>> slab_child_pool.  What do you do when you have both?  For the most part,
>> the thing that gets the most use in a function is the thing called pool.
>>   In this case, that's the slab_child_pool, but that's not the parameter
>> passed in.
>>
>> slab_alloc_st, slab_free_st, slab_create, and slab_destroy are the only
>> other functions that take a slab_mempool.  These functions work around
>> this issue by immediately calling some other public function with
>> >child.  I didn't want to make a public function to flush an
>> arbitrary slab_child_pool because that's very dangerous in the general
>> case.  Having a one-line public function that calls a private function
>> will just beg some newbie to come along and fix it... and end up with
>> the same problem. :)
>>
 +{
 +   struct slab_child_pool *const pool = >child;
 +
 +   assert(pool->migrated == NULL);
 +   assert(pool->parent == parent);
>>>
>>> I'm surprised this works. Why isn't pool->parent == >parent?
>>
>> This is just a sanity check on an invariant of the data structure.  If
>> the slab_mempool wasn't initialized or if it has been destroyed,
>> parent->child.parent will be garbage or NULL.
> 
> Right, I get that, but pool->parent is of type slab_parent_pool while 
> parent is of type slab_mempool. I don't see how that adds up.

Ah, now I see what you're saying.  Ignoring the other naming discussion,
this should be

   assert(pool->parent == >parent);

On that topic... how would you feel about changing the "pool" parameter
to be "mempool" in the 5 places (counting the one added by this patch)
where that parameter has type 'struct slab_mempool *'?  Then we'll
universally have 'struct slab_child_pool *pool' and 'struct slab_mempool
*mempool'.

> Cheers,
> Nicolai
> 
>>> Or, with a consistently named function argument, why isn't
>>> pool->child.parent == >parent?
>>>
>>> The intention of the patch looks fine though.
>>>
>>> Cheers,
>>> Nicolai
>>>
>>>
 +
 +   while (pool->pages) {
 +  struct slab_page_header *page = pool->pages;
 +  pool->pages = page->u.next;
 +
 +  free(page);
 +   }
 +
 +   pool->free = NULL;
 +}
 +
static bool
slab_add_new_page(struct slab_child_pool *pool)
{
 diff --git a/src/util/slab.h b/src/util/slab.h
 index e83f8ec1a0e..a4279d8e65b 100644
 --- a/src/util/slab.h
 +++ b/src/util/slab.h
 @@ -90,5 +90,6 @@ void slab_create(struct slab_mempool *pool,
void slab_destroy(struct slab_mempool *pool);
void *slab_alloc_st(struct slab_mempool *pool);
void slab_free_st(struct slab_mempool *pool, void *ptr);
 +void slab_flush_st(struct slab_mempool *parent);

#endif

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

Re: [Mesa-dev] [PATCH mesa 00/13] Make standard function available on non-standard platforms

[Ian Romanick]

On 11/21/2018 12:16 PM, Jose Fonseca wrote:
>>   util: use standard name for strncat()
> 
>>   util: use standard name for strncmp()
>>   util: use standard name for strcmp()
>>   util: use standard name for strchr()
>>   util: use standard name for sprintf()
>>   util: use standard name for vasprintf()
>>   util: use standard name for vsprintf()
>>   util: use standard name for snprintf()
>>   util: use standard name for vsnprintf()
> 
> 
> Generally I agree with the principle of using standard functions, and
> provide drop-in replacements for the systems where they are broken.  It
> leads to less friction, less need to learn new things.
> 
> 
> But C string functions is IMO a special case, because the standard
> functions are so poorly designed, and make writing correct and secure
> code so dawm difficult:
> 
> - snprintf doesn't write the null char
> 
> - strncat n parameter is awkard to use
> 
> -  vasprintf have different return codes on different systems. 
> According to GNU manpages, it's not even C or POSIX.
> 
> 
> And a standard for the sake of standard is just silly.
> 
> 
> So IMO, if people care and have the time to uniformize these things, I
> think they should move away standard C functions, and write some sane C
> string manipulation abstraction/helpers.  And we should make GCC throw
> warnings every time people try to use the standard C string functions.
> 
> 
>> All of these functions appear to have been added by 131a1fbc91725.  I've
> added Jose to CC since he wrote it.  [...]  
> 
> 
>> That doesn't give much insight. :(
> 
> 
>> :(
> 
> 
> *sigh*
> 
> 
> The reason for adding was in b1922de9f3478869c6788ef4e954c06c20e7aa9c . 

Right... I was more thinking about the str* functions than the *printf
functions.  Locale problems with scanf / printf are real on every
platform.  We had issues with this in the GLSL parser due to "." vs ","
as the ones to tenths separator in floating point numbers.  Other
*printf portability problems are real too.  I don't think there's any
variation with strchr or strstr, though. :)

Specifically, I (and I guess Emil also) propose removing the wrappers for:

 - strchr
 - strstr
 - strcmp (does this have locale issues?)
 - strncmp (does this have locale issues?)
 - strncat

And leave the rest for at least the time being.

> We needed those because XP kernel driver environment didn't provide a
> complete  CRT.  But we dropped XP kernel support long time ago, so
> that's no longer relevant.
> 
> 
> I believe the reason these functions became widespread since
> then was the fact that MSVC functions didn't follow C99 (e.g., ll), but
> that might no longer be an issue with MSVC 2017 runtime.  This needs to
> be verified.
> 
> 
> Finally there's also the fact that standard snprintf is sensitive to
> current locale, which is a bad idea for driver code.   I suppose this is
> not an issue for Linux, which has always used snprintf underneath.  But
> we need to double check all other util_snprintf .  It's possible that
> the mere fact we statically link CRT is sufficient to protect us from
> that (since it ends up being like a completely different CRT instant
> from the application), but I'm not 100% sure.
> 
> 
> Jose
> 
> 
> 
> *From:* Ian Romanick 
> *Sent:* Wednesday, November 21, 2018 18:47
> *To:* Eric Engestrom; mesa-dev@lists.freedesktop.org
> *Cc:* Jose Fonseca
> *Subject:* Re: [Mesa-dev] [PATCH mesa 00/13] Make standard function
> available on non-standard platforms
>  
> On 11/20/2018 05:11 AM, Eric Engestrom wrote:
>> ... instead of making standard platforms use non-standard functions.
> 
> I haven't looked at the specific patches, so this comment may not apply.
>  When we first headed down the path of adding a billion wrapper
> functions, I campaigned pretty strongly to give them the standard names.
>  The problem is that some platforms have functions with the standard
> names that deviate from the standard behavior in ways that make them
> unusable.  I think one of the printf-like functions was the main problem
> here, but it was a long time ago.
> 
> Either way, you can't give the wrapper the standard name in this case.
> Once you have to name one wrapper function _foo_standard_name, you might
> as well name them all like that.
> 
>> This also reduces the likelihood of someone forgetting to use the
>> non-standard function, and reduces the fix to a simple #include.
> 
> If we cared, I bet we could write a 'make check' test that would just
> grep through the tree for functions that are supposed to be wrapped.
> The test would fail if a non-wrapped version was used.  We'd probably
> have to use Python, so I don't know how much effort it would be.
> 
>> Changes generated using this shell function for each function name:
>>   fix() {
>> files=$(ag -lw util_$1)
>> sed s/'\'/$1/g -i $files
>> git add -up $files
>> git commit -sm 'util: use standard name for '$1'()'
>>   }
>> 

Re: [Mesa-dev] [PATCH 2/7] nir/phi_builder: Use hash table to store [value, block] -> def mapping

[Ian Romanick]

On IRC, Jason had asked about performance overhead of using the hash
table.  A full run of shader-db on a release build (with -march=native)
on my Skylake laptop is a barely measurable amount slower:

x before
+ after
++
| +  |
|xx   x +   xx*x x   + * + *  +++|
| |__|M|_M_A||
++
N   Min   MaxMedian   AvgStddev
x  10 108.5 109.3108.86   108.8380.25620304
+  10108.76109.73109.12   109.155 0.3003424
Difference at 95.0% confidence
0.317 +/- 0.262285
0.291259% +/- 0.240986%
(Student's t, pooled s = 0.279147)


On 11/20/2018 04:39 PM, Ian Romanick wrote:
> From: Ian Romanick 
> 
> Changes in peak memory usage according to Valgrind massif:
> 
> mean soft fp64 using uint64:   5,499,881,802 => 1,343,998,123
> gfxbench5 aztec ruins high 11:62,415,414 =>62,415,414
> deus ex mankind divided 148:  62,317,965 =>62,317,965
> deus ex mankind divided 2890: 72,585,466 =>72,585,466
> dirt showdown 676:74,473,151 =>75,203,703
> dolphin ubershaders 210: 109,637,096 =>83,185,248
> 
> Signed-off-by: Ian Romanick 
> ---
>  src/compiler/nir/nir_phi_builder.c | 115 
> ++---
>  1 file changed, 93 insertions(+), 22 deletions(-)
> 
> diff --git a/src/compiler/nir/nir_phi_builder.c 
> b/src/compiler/nir/nir_phi_builder.c
> index add3efd2dfc..36ab9888f48 100644
> --- a/src/compiler/nir/nir_phi_builder.c
> +++ b/src/compiler/nir/nir_phi_builder.c
> @@ -41,6 +41,25 @@ struct nir_phi_builder {
> unsigned iter_count;
> unsigned *work;
> nir_block **W;
> +
> +   /**
> +* Tables of SSA defs, indexed by block and nir_phi_builder_value.
> +*
> +* For each [value, block] tuple, this table has one of three types of
> +* values:
> +*
> +*  - NULL (i.e., not in the table). Indicates that there is no known
> +*definition in this block.  If you need to find one, look at the
> +*block's immediate dominator.
> +*
> +*  - NEEDS_PHI. Indicates that the block may need a phi node but none has
> +*been created yet.  If a def is requested for a block, a phi will 
> need
> +*to be created.
> +*
> +*  - A regular SSA def.  This will be either the result of a phi node or
> +*one of the defs provided by nir_phi_builder_value_set_blocK_def().
> +*/
> +   struct hash_table *value_block_def_hash;
>  };
>  
>  #define NEEDS_PHI ((nir_ssa_def *)(intptr_t)-1)
> @@ -61,23 +80,34 @@ struct nir_phi_builder_value {
>  * blocks.
>  */
> struct exec_list phis;
> +};
>  
> -   /* Array of SSA defs, indexed by block.  For each block, this array has 
> has
> -* one of three types of values:
> -*
> -*  - NULL. Indicates that there is no known definition in this block.  If
> -*you need to find one, look at the block's immediate dominator.
> -*
> -*  - NEEDS_PHI. Indicates that the block may need a phi node but none has
> -*been created yet.  If a def is requested for a block, a phi will 
> need
> -*to be created.
> -*
> -*  - A regular SSA def.  This will be either the result of a phi node or
> -*one of the defs provided by nir_phi_builder_value_set_blocK_def().
> -*/
> -   nir_ssa_def *defs[0];
> +/**
> + * Key for the nir_phi_builder::value_block_def_hash.
> + */
> +struct phi_builder_key {
> +   struct nir_phi_builder_value *val;
> +   unsigned block_index;
>  };
>  
> +static uint32_t
> +phi_builder_key_hash(const void *_k)
> +{
> +   const struct phi_builder_key *k = (const struct phi_builder_key *)_k;
> +
> +   return _mesa_fnv32_1a_accumulate(_mesa_fnv32_1a_accumulate(0, k->val),
> +k->block_index);
> +}
> +
> +static bool
> +phi_builder_key_equals(const void *_a, const void *_b)
> +{
> +   const struct phi_builder_key *a = (const struct phi_builder_key *)_a;
> +   const struct phi_builder_key *b = (const struct phi_builder_key *)_b;
> +
> +   return a->val == b->val && a->block_index == b->block_index;
> +}
> +
>  struct nir_phi_builder *
>  nir_phi_builder_create(nir_function_impl *impl)
>  {
> @@ -100,6 +130,9 @@ nir_phi_builder_create(nir_function_impl *impl)
> pb->iter_count = 0;
> pb->work = rzalloc_array(pb, unsigned, pb->num_blocks);
> pb->W = ralloc_array(pb, nir_block *, pb->num_blocks);
> +   pb->value_block_def_hash = _mesa_hash_table_create(pb,
> +  phi_builder_key_hash,
> +  
> phi_builder_key_equals);
>  
> 

Re: [Mesa-dev] [PATCH mesa 1/2] egl: add missing includes

[Kristian Høgsberg]

On Fri, Nov 16, 2018 at 9:34 AM Emil Velikov  wrote:
>
> On Fri, 16 Nov 2018 at 10:07, Eric Engestrom  wrote:

I find that I also need

diff --git a/src/egl/main/egldevice.h b/src/egl/main/egldevice.h
index ddcdcd17f5a..03988913ecd 100644
--- a/src/egl/main/egldevice.h
+++ b/src/egl/main/egldevice.h
@@ -30,6 +30,7 @@
 #define EGLDEVICE_INCLUDED


+#include 
 #include 
 #include "egltypedefs.h"

for the use of NULL in the inline _eglLookupDevice further down.

Kristian

> >
> > Signed-off-by: Eric Engestrom 
> > ---
> >  src/egl/drivers/dri2/egl_dri2.c | 1 +
> >  src/egl/main/eglapi.c   | 2 ++
> >  src/egl/main/eglapi.h   | 1 +
> >  src/egl/main/eglglobals.c   | 2 ++
> >  src/egl/main/eglsurface.c   | 2 ++
> >  5 files changed, 8 insertions(+)
> >
>
> I haven't explicitly checked each include but I know you're build
> tested this. For the lot
> Acked-by: Emil Velikov 
>
> -Emil
> ___
> 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 1.5/2] ac/surface/gfx9: let addrlib choose the preferred swizzle kind

[Bas Nieuwenhuizen]

On Wed, Nov 21, 2018 at 9:33 PM Marek Olšák  wrote:
>
> See what Gustaw said. Other than that:
>
> Reviewed-by: Marek Olšák 

With that change:

Reviewed-by: Bas Nieuwenhuizen 
Tested-by: Bas Nieuwenhuizen 

>
> Marek
>
> On Wed, Nov 21, 2018 at 10:21 AM Nicolai Hähnle  wrote:
>>
>> From: Nicolai Hähnle 
>>
>> Our choices here are simply redundant as long as sin.flags is set
>> correctly.
>> --
>> This is the change I was talking about.
>> ---
>>  src/amd/common/ac_surface.c | 10 --
>>  1 file changed, 10 deletions(-)
>>
>> diff --git a/src/amd/common/ac_surface.c b/src/amd/common/ac_surface.c
>> index edd710a968c..ad2cb585c9d 100644
>> --- a/src/amd/common/ac_surface.c
>> +++ b/src/amd/common/ac_surface.c
>> @@ -1057,30 +1057,20 @@ gfx9_get_preferred_swizzle_mode(ADDR_HANDLE addrlib,
>> sin.forbiddenBlock.var = 1; /* don't allow the variable-sized 
>> swizzle modes */
>> sin.forbiddenBlock.linear = 1; /* don't allow linear swizzle modes */
>> sin.bpp = in->bpp;
>> sin.width = in->width;
>> sin.height = in->height;
>> sin.numSlices = in->numSlices;
>> sin.numMipLevels = in->numMipLevels;
>> sin.numSamples = in->numSamples;
>> sin.numFrags = in->numFrags;
>>
>> -   if (flags & RADEON_SURF_SCANOUT) {
>> -   sin.preferredSwSet.sw_D = 1;
>> -   /* Raven only allows S for displayable surfaces with < 64 
>> bpp, so
>> -* allow it as fallback */
>> -   sin.preferredSwSet.sw_S = 1;
>> -   } else if (in->flags.depth || in->flags.stencil || is_fmask)
>> -   sin.preferredSwSet.sw_Z = 1;
>> -   else
>> -   sin.preferredSwSet.sw_S = 1;
>> -
>> if (is_fmask) {
>> sin.flags.display = 0;
>> sin.flags.color = 0;
>> sin.flags.fmask = 1;
>> }
>>
>> ret = Addr2GetPreferredSurfaceSetting(addrlib, , );
>> if (ret != ADDR_OK)
>> return ret;
>>
>> --
>> 2.19.1
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1.5/2] ac/surface/gfx9: let addrlib choose the preferred swizzle kind

[Marek Olšák]

See what Gustaw said. Other than that:

Reviewed-by: Marek Olšák 

Marek

On Wed, Nov 21, 2018 at 10:21 AM Nicolai Hähnle  wrote:

> From: Nicolai Hähnle 
>
> Our choices here are simply redundant as long as sin.flags is set
> correctly.
> --
> This is the change I was talking about.
> ---
>  src/amd/common/ac_surface.c | 10 --
>  1 file changed, 10 deletions(-)
>
> diff --git a/src/amd/common/ac_surface.c b/src/amd/common/ac_surface.c
> index edd710a968c..ad2cb585c9d 100644
> --- a/src/amd/common/ac_surface.c
> +++ b/src/amd/common/ac_surface.c
> @@ -1057,30 +1057,20 @@ gfx9_get_preferred_swizzle_mode(ADDR_HANDLE
> addrlib,
> sin.forbiddenBlock.var = 1; /* don't allow the variable-sized
> swizzle modes */
> sin.forbiddenBlock.linear = 1; /* don't allow linear swizzle modes
> */
> sin.bpp = in->bpp;
> sin.width = in->width;
> sin.height = in->height;
> sin.numSlices = in->numSlices;
> sin.numMipLevels = in->numMipLevels;
> sin.numSamples = in->numSamples;
> sin.numFrags = in->numFrags;
>
> -   if (flags & RADEON_SURF_SCANOUT) {
> -   sin.preferredSwSet.sw_D = 1;
> -   /* Raven only allows S for displayable surfaces with < 64
> bpp, so
> -* allow it as fallback */
> -   sin.preferredSwSet.sw_S = 1;
> -   } else if (in->flags.depth || in->flags.stencil || is_fmask)
> -   sin.preferredSwSet.sw_Z = 1;
> -   else
> -   sin.preferredSwSet.sw_S = 1;
> -
> if (is_fmask) {
> sin.flags.display = 0;
> sin.flags.color = 0;
> sin.flags.fmask = 1;
> }
>
> ret = Addr2GetPreferredSurfaceSetting(addrlib, , );
> if (ret != ADDR_OK)
> return ret;
>
> --
> 2.19.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH mesa 00/13] Make standard function available on non-standard platforms

[Jose Fonseca]

> vasprintf have different return codes on different systems.

Forget this. I was mixing up with the other  function that calculates how many 
chars a xxxprintf function would write, which we use to implement vasprintf.

Jose

From: Jose Fonseca
Sent: Wednesday, November 21, 2018 8:16:35 PM
To: Ian Romanick; Eric Engestrom; mesa-dev@lists.freedesktop.org
Cc: Brian Paul; Roland Scheidegger; Neha Bhende; Charmaine Lee
Subject: Re: [Mesa-dev] [PATCH mesa 00/13] Make standard function available on 
non-standard platforms


>   util: use standard name for strncat()

>   util: use standard name for strncmp()
>   util: use standard name for strcmp()
>   util: use standard name for strchr()
>   util: use standard name for sprintf()
>   util: use standard name for vasprintf()
>   util: use standard name for vsprintf()
>   util: use standard name for snprintf()
>   util: use standard name for vsnprintf()


Generally I agree with the principle of using standard functions, and provide 
drop-in replacements for the systems where they are broken.  It leads to less 
friction, less need to learn new things.


But C string functions is IMO a special case, because the standard functions 
are so poorly designed, and make writing correct and secure code so dawm 
difficult:

- snprintf doesn't write the null char

- strncat n parameter is awkard to use

-  vasprintf have different return codes on different systems.  According to 
GNU manpages, it's not even C or POSIX.


And a standard for the sake of standard is just silly.


So IMO, if people care and have the time to uniformize these things, I think 
they should move away standard C functions, and write some sane C string 
manipulation abstraction/helpers.  And we should make GCC throw warnings every 
time people try to use the standard C string functions.


> All of these functions appear to have been added by 131a1fbc91725.  I've
added Jose to CC since he wrote it.  [...]


> That doesn't give much insight. :(


> :(


*sigh*


The reason for adding was in b1922de9f3478869c6788ef4e954c06c20e7aa9c .  We 
needed those because XP kernel driver environment didn't provide a complete  
CRT.  But we dropped XP kernel support long time ago, so that's no longer 
relevant.


I believe the reason these functions became widespread since then was the fact 
that MSVC functions didn't follow C99 (e.g., ll), but that might no longer be 
an issue with MSVC 2017 runtime.  This needs to be verified.


Finally there's also the fact that standard snprintf is sensitive to current 
locale, which is a bad idea for driver code.   I suppose this is not an issue 
for Linux, which has always used snprintf underneath.  But we need to double 
check all other util_snprintf .  It's possible that the mere fact we statically 
link CRT is sufficient to protect us from that (since it ends up being like a 
completely different CRT instant from the application), but I'm not 100% sure.


Jose


From: Ian Romanick 
Sent: Wednesday, November 21, 2018 18:47
To: Eric Engestrom; mesa-dev@lists.freedesktop.org
Cc: Jose Fonseca
Subject: Re: [Mesa-dev] [PATCH mesa 00/13] Make standard function available on 
non-standard platforms

On 11/20/2018 05:11 AM, Eric Engestrom wrote:
> ... instead of making standard platforms use non-standard functions.

I haven't looked at the specific patches, so this comment may not apply.
 When we first headed down the path of adding a billion wrapper
functions, I campaigned pretty strongly to give them the standard names.
 The problem is that some platforms have functions with the standard
names that deviate from the standard behavior in ways that make them
unusable.  I think one of the printf-like functions was the main problem
here, but it was a long time ago.

Either way, you can't give the wrapper the standard name in this case.
Once you have to name one wrapper function _foo_standard_name, you might
as well name them all like that.

> This also reduces the likelihood of someone forgetting to use the
> non-standard function, and reduces the fix to a simple #include.

If we cared, I bet we could write a 'make check' test that would just
grep through the tree for functions that are supposed to be wrapped.
The test would fail if a non-wrapped version was used.  We'd probably
have to use Python, so I don't know how much effort it would be.

> Changes generated using this shell function for each function name:
>   fix() {
> files=$(ag -lw util_$1)
> sed s/'\'/$1/g -i $files
> git add -up $files
> git commit -sm 'util: use standard name for '$1'()'
>   }
>
> Eric Engestrom (13):
>   util: use standard name for strchrnul()
>   util: use standard name for strcasecmp()
>   util: use standard name for strdup()
>   util: use standard name for strstr()

What the... ?  strstr is part of C89.  What platform actually needs a
wrapper for this?  I see zero uses in the code base of util_strstr.
Ditto for strdup, strncmp, 

Re: [Mesa-dev] [PATCH 2/2] winsys/amdgpu: explicitly declare whether buffer_map is permanent or not

[Marek Olšák]

On Wed, Nov 21, 2018 at 12:57 PM Nicolai Hähnle  wrote:

> From: Nicolai Hähnle 
>
> Introduce a new driver-private transfer flag RADEON_TRANSFER_TEMPORARY
> that specifies whether the caller will use buffer_unmap or not. The
> default behavior is set to permanent maps, because that's what drivers
> do for Gallium buffer maps.
>
> This should eliminate the need for hacks in libdrm. Assertions are added
> to catch when the buffer_unmap calls don't match the (temporary)
> buffer_map calls.
>
> I did my best to update r600 and r300 as well for completeness (yes,
> it's a no-op for r300 because it never calls buffer_unmap), even though
> the radeon winsys ignores the new flag.
>

You didn't make any changes to r300.

You can also drop all r600 changes, because the radeon winsys doesn't care.



>
> As an added bonus, this should actually improve the performance of
> the normal fast path, because we no longer call into libdrm at all
> after the first map, and there's one less atomic in the winsys itself
> (there are now no atomics left in the UNSYNCHRONIZED fast path).
>
> Cc: Leo Liu 
> --
> Leo, it'd be nice if you could confirm that all video buffer mappings
> are temporary in this sense.
> ---
>  src/gallium/drivers/r600/evergreen_compute.c |  4 +-
>  src/gallium/drivers/r600/r600_asm.c  |  4 +-
>  src/gallium/drivers/r600/r600_shader.c   |  4 +-
>  src/gallium/drivers/r600/radeon_uvd.c|  8 +-
>  src/gallium/drivers/r600/radeon_vce.c|  4 +-
>  src/gallium/drivers/r600/radeon_video.c  |  6 +-
>  src/gallium/drivers/radeon/radeon_uvd.c  | 10 ++-
>  src/gallium/drivers/radeon/radeon_uvd_enc.c  |  6 +-
>  src/gallium/drivers/radeon/radeon_vce.c  |  4 +-
>  src/gallium/drivers/radeon/radeon_vcn_dec.c  | 18 ++--
>  src/gallium/drivers/radeon/radeon_vcn_enc.c  |  4 +-
>  src/gallium/drivers/radeon/radeon_video.c|  6 +-
>  src/gallium/drivers/radeon/radeon_winsys.h   | 17 +++-
>  src/gallium/drivers/radeonsi/si_shader.c |  3 +-
>  src/gallium/include/pipe/p_defines.h |  8 +-
>  src/gallium/winsys/amdgpu/drm/amdgpu_bo.c| 95 +---
>  src/gallium/winsys/amdgpu/drm/amdgpu_bo.h|  3 +-
>  17 files changed, 142 insertions(+), 62 deletions(-)
>
> diff --git a/src/gallium/drivers/r600/evergreen_compute.c
> b/src/gallium/drivers/r600/evergreen_compute.c
> index a77f58242e3..9085be4e2f3 100644
> --- a/src/gallium/drivers/r600/evergreen_compute.c
> +++ b/src/gallium/drivers/r600/evergreen_compute.c
> @@ -431,21 +431,23 @@ static void *evergreen_create_compute_state(struct
> pipe_context *ctx,
> COMPUTE_DBG(rctx->screen, "*** evergreen_create_compute_state\n");
> header = cso->prog;
> code = cso->prog + sizeof(struct pipe_llvm_program_header);
> radeon_shader_binary_init(>binary);
> r600_elf_read(code, header->num_bytes, >binary);
> r600_create_shader(>bc, >binary, _kill);
>
> /* Upload code + ROdata */
> shader->code_bo = r600_compute_buffer_alloc_vram(rctx->screen,
> shader->bc.ndw *
> 4);
> -   p = r600_buffer_map_sync_with_rings(>b, shader->code_bo,
> PIPE_TRANSFER_WRITE);
> +   p = r600_buffer_map_sync_with_rings(
> +   >b, shader->code_bo,
> +   PIPE_TRANSFER_WRITE | RADEON_TRANSFER_TEMPORARY);
> //TODO: use util_memcpy_cpu_to_le32 ?
> memcpy(p, shader->bc.bytecode, shader->bc.ndw * 4);
> rctx->b.ws->buffer_unmap(shader->code_bo->buf);
>  #endif
>
> return shader;
>  }
>
>  static void evergreen_delete_compute_state(struct pipe_context *ctx, void
> *state)
>  {
> diff --git a/src/gallium/drivers/r600/r600_asm.c
> b/src/gallium/drivers/r600/r600_asm.c
> index 7029be24f4b..4ba77c535f9 100644
> --- a/src/gallium/drivers/r600/r600_asm.c
> +++ b/src/gallium/drivers/r600/r600_asm.c
> @@ -2765,21 +2765,23 @@ void *r600_create_vertex_fetch_shader(struct
> pipe_context *ctx,
>
> u_suballocator_alloc(rctx->allocator_fetch_shader, fs_size, 256,
>  >offset,
>  (struct pipe_resource**)>buffer);
> if (!shader->buffer) {
> r600_bytecode_clear();
> FREE(shader);
> return NULL;
> }
>
> -   bytecode = r600_buffer_map_sync_with_rings(>b,
> shader->buffer, PIPE_TRANSFER_WRITE | PIPE_TRANSFER_UNSYNCHRONIZED);
> +   bytecode = r600_buffer_map_sync_with_rings
> +   (>b, shader->buffer,
> +   PIPE_TRANSFER_WRITE | PIPE_TRANSFER_UNSYNCHRONIZED |
> RADEON_TRANSFER_TEMPORARY);
> bytecode += shader->offset / 4;
>
> if (R600_BIG_ENDIAN) {
> for (i = 0; i < fs_size / 4; ++i) {
> bytecode[i] = util_cpu_to_le32(bc.bytecode[i]);
> }
> } else {
> memcpy(bytecode, bc.bytecode, fs_size);
> }
> 

Re: [Mesa-dev] [PATCH 3/7] util/slab: Add function to flush allocations from a child pool

[Haehnle, Nicolai]

On 21.11.18 19:19, Ian Romanick wrote:
> On 11/21/2018 03:08 AM, Haehnle, Nicolai wrote:
>> On 21.11.18 01:39, Ian Romanick wrote:
>>> From: Ian Romanick 
>>>
>>> Ralloc has a feature that all allocations from a temporary memory
>>> context can be whisked away in a single call without fear of leaks.  As
>>> the slab allocator is designed for use in multhreaded scenarios with a
>>> child pool per CPU, it lacks this feature.  However, many users will be
>>> single threaded with a single child pool.  For these users, we can have
>>> our cake and eat it too.
>>>
>>> Signed-off-by: Ian Romanick 
>>> Cc: Nicolai Hähnle 
>>> ---
>>>src/util/slab.c | 21 +
>>>src/util/slab.h |  1 +
>>>2 files changed, 22 insertions(+)
>>>
>>> diff --git a/src/util/slab.c b/src/util/slab.c
>>> index 5f048666b56..1bcc1db6e09 100644
>>> --- a/src/util/slab.c
>>> +++ b/src/util/slab.c
>>> @@ -172,6 +172,27 @@ void slab_destroy_child(struct slab_child_pool *pool)
>>>   pool->parent = NULL;
>>>}
>>>
>>> +/**
>>> + * Flush all allocations from a pool.  Single-threaded (no mutex).
>>> + */
>>> +void
>>> +slab_flush_st(struct slab_mempool *parent)
>>
>> The name of the function argument should be "pool" for consistency.
> 
> This is one thing that annoyed me while writing this function.
> Sometimes "pool" is a slab_mempool.  Sometimes "pool" is a
> slab_child_pool.  What do you do when you have both?  For the most part,
> the thing that gets the most use in a function is the thing called pool.
>   In this case, that's the slab_child_pool, but that's not the parameter
> passed in.
> 
> slab_alloc_st, slab_free_st, slab_create, and slab_destroy are the only
> other functions that take a slab_mempool.  These functions work around
> this issue by immediately calling some other public function with
> >child.  I didn't want to make a public function to flush an
> arbitrary slab_child_pool because that's very dangerous in the general
> case.  Having a one-line public function that calls a private function
> will just beg some newbie to come along and fix it... and end up with
> the same problem. :)
> 
>>> +{
>>> +   struct slab_child_pool *const pool = >child;
>>> +
>>> +   assert(pool->migrated == NULL);
>>> +   assert(pool->parent == parent);
>>
>> I'm surprised this works. Why isn't pool->parent == >parent?
> 
> This is just a sanity check on an invariant of the data structure.  If
> the slab_mempool wasn't initialized or if it has been destroyed,
> parent->child.parent will be garbage or NULL.

Right, I get that, but pool->parent is of type slab_parent_pool while 
parent is of type slab_mempool. I don't see how that adds up.

Cheers,
Nicolai


> 
>> Or, with a consistently named function argument, why isn't
>> pool->child.parent == >parent?
>>
>> The intention of the patch looks fine though.
>>
>> Cheers,
>> Nicolai
>>
>>
>>> +
>>> +   while (pool->pages) {
>>> +  struct slab_page_header *page = pool->pages;
>>> +  pool->pages = page->u.next;
>>> +
>>> +  free(page);
>>> +   }
>>> +
>>> +   pool->free = NULL;
>>> +}
>>> +
>>>static bool
>>>slab_add_new_page(struct slab_child_pool *pool)
>>>{
>>> diff --git a/src/util/slab.h b/src/util/slab.h
>>> index e83f8ec1a0e..a4279d8e65b 100644
>>> --- a/src/util/slab.h
>>> +++ b/src/util/slab.h
>>> @@ -90,5 +90,6 @@ void slab_create(struct slab_mempool *pool,
>>>void slab_destroy(struct slab_mempool *pool);
>>>void *slab_alloc_st(struct slab_mempool *pool);
>>>void slab_free_st(struct slab_mempool *pool, void *ptr);
>>> +void slab_flush_st(struct slab_mempool *parent);
>>>
>>>#endif
>>>

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

Re: [Mesa-dev] [PATCH mesa 00/13] Make standard function available on non-standard platforms

[Jose Fonseca]

>   util: use standard name for strncat()

>   util: use standard name for strncmp()
>   util: use standard name for strcmp()
>   util: use standard name for strchr()
>   util: use standard name for sprintf()
>   util: use standard name for vasprintf()
>   util: use standard name for vsprintf()
>   util: use standard name for snprintf()
>   util: use standard name for vsnprintf()


Generally I agree with the principle of using standard functions, and provide 
drop-in replacements for the systems where they are broken.  It leads to less 
friction, less need to learn new things.


But C string functions is IMO a special case, because the standard functions 
are so poorly designed, and make writing correct and secure code so dawm 
difficult:

- snprintf doesn't write the null char

- strncat n parameter is awkard to use

-  vasprintf have different return codes on different systems.  According to 
GNU manpages, it's not even C or POSIX.


And a standard for the sake of standard is just silly.


So IMO, if people care and have the time to uniformize these things, I think 
they should move away standard C functions, and write some sane C string 
manipulation abstraction/helpers.  And we should make GCC throw warnings every 
time people try to use the standard C string functions.


> All of these functions appear to have been added by 131a1fbc91725.  I've
added Jose to CC since he wrote it.  [...]


> That doesn't give much insight. :(


> :(


*sigh*


The reason for adding was in b1922de9f3478869c6788ef4e954c06c20e7aa9c .  We 
needed those because XP kernel driver environment didn't provide a complete  
CRT.  But we dropped XP kernel support long time ago, so that's no longer 
relevant.


I believe the reason these functions became widespread since then was the fact 
that MSVC functions didn't follow C99 (e.g., ll), but that might no longer be 
an issue with MSVC 2017 runtime.  This needs to be verified.


Finally there's also the fact that standard snprintf is sensitive to current 
locale, which is a bad idea for driver code.   I suppose this is not an issue 
for Linux, which has always used snprintf underneath.  But we need to double 
check all other util_snprintf .  It's possible that the mere fact we statically 
link CRT is sufficient to protect us from that (since it ends up being like a 
completely different CRT instant from the application), but I'm not 100% sure.


Jose


From: Ian Romanick 
Sent: Wednesday, November 21, 2018 18:47
To: Eric Engestrom; mesa-dev@lists.freedesktop.org
Cc: Jose Fonseca
Subject: Re: [Mesa-dev] [PATCH mesa 00/13] Make standard function available on 
non-standard platforms

On 11/20/2018 05:11 AM, Eric Engestrom wrote:
> ... instead of making standard platforms use non-standard functions.

I haven't looked at the specific patches, so this comment may not apply.
 When we first headed down the path of adding a billion wrapper
functions, I campaigned pretty strongly to give them the standard names.
 The problem is that some platforms have functions with the standard
names that deviate from the standard behavior in ways that make them
unusable.  I think one of the printf-like functions was the main problem
here, but it was a long time ago.

Either way, you can't give the wrapper the standard name in this case.
Once you have to name one wrapper function _foo_standard_name, you might
as well name them all like that.

> This also reduces the likelihood of someone forgetting to use the
> non-standard function, and reduces the fix to a simple #include.

If we cared, I bet we could write a 'make check' test that would just
grep through the tree for functions that are supposed to be wrapped.
The test would fail if a non-wrapped version was used.  We'd probably
have to use Python, so I don't know how much effort it would be.

> Changes generated using this shell function for each function name:
>   fix() {
> files=$(ag -lw util_$1)
> sed s/'\'/$1/g -i $files
> git add -up $files
> git commit -sm 'util: use standard name for '$1'()'
>   }
>
> Eric Engestrom (13):
>   util: use standard name for strchrnul()
>   util: use standard name for strcasecmp()
>   util: use standard name for strdup()
>   util: use standard name for strstr()

What the... ?  strstr is part of C89.  What platform actually needs a
wrapper for this?  I see zero uses in the code base of util_strstr.
Ditto for strdup, strncmp, strcmp, strchr, and possibly others.  I
looked, and Microsoft has strncmp at least as far back as Visual Studio
2012.

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fprevious-versions%2Fvisualstudio%2Fvisual-studio-2012%2Feywx8zcx(v%3Dvs.110data=02%7C01%7Cjfonseca%40vmware.com%7Cc87f73c43298407e4aeb08d64fe1bc31%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636784228289598865sdata=Gg%2B%2BlQmc4wmh7k0zohBEdUatGjdCkPDnmCOxse6NSFE%3Dreserved=0)

I don't see any of these functions on the list of functions that 

Re: [Mesa-dev] [PATCH 2/7] nir/phi_builder: Use hash table to store [value, block] -> def mapping

[Jason Ekstrand]

On Wed, Nov 21, 2018 at 1:35 PM Ian Romanick  wrote:

> On 11/21/2018 11:01 AM, Jason Ekstrand wrote:
> > On Tue, Nov 20, 2018 at 6:40 PM Ian Romanick  > > wrote:
> >
> > From: Ian Romanick  > >
> >
> > Changes in peak memory usage according to Valgrind massif:
> >
> > mean soft fp64 using uint64:   5,499,881,802 => 1,343,998,123
> > gfxbench5 aztec ruins high 11:62,415,414 =>62,415,414
> > deus ex mankind divided 148:  62,317,965 =>62,317,965
> > deus ex mankind divided 2890: 72,585,466 =>72,585,466
> > dirt showdown 676:74,473,151 =>75,203,703
> > dolphin ubershaders 210: 109,637,096 =>83,185,248
> >
> > Signed-off-by: Ian Romanick  > >
> > ---
> >  src/compiler/nir/nir_phi_builder.c | 115
> > ++---
> >  1 file changed, 93 insertions(+), 22 deletions(-)
> >
> > diff --git a/src/compiler/nir/nir_phi_builder.c
> > b/src/compiler/nir/nir_phi_builder.c
> > index add3efd2dfc..36ab9888f48 100644
> > --- a/src/compiler/nir/nir_phi_builder.c
> > +++ b/src/compiler/nir/nir_phi_builder.c
> > @@ -41,6 +41,25 @@ struct nir_phi_builder {
> > unsigned iter_count;
> > unsigned *work;
> > nir_block **W;
> > +
> > +   /**
> > +* Tables of SSA defs, indexed by block and
> nir_phi_builder_value.
> > +*
> > +* For each [value, block] tuple, this table has one of three
> > types of
> > +* values:
> > +*
> > +*  - NULL (i.e., not in the table). Indicates that there is no
> > known
> > +*definition in this block.  If you need to find one, look
> > at the
> > +*block's immediate dominator.
> > +*
> > +*  - NEEDS_PHI. Indicates that the block may need a phi node
> > but none has
> > +*been created yet.  If a def is requested for a block, a
> > phi will need
> > +*to be created.
> > +*
> > +*  - A regular SSA def.  This will be either the result of a
> > phi node or
> > +*one of the defs provided by
> > nir_phi_builder_value_set_blocK_def().
> > +*/
> > +   struct hash_table *value_block_def_hash;
> >  };
> >
> >  #define NEEDS_PHI ((nir_ssa_def *)(intptr_t)-1)
> > @@ -61,23 +80,34 @@ struct nir_phi_builder_value {
> >  * blocks.
> >  */
> > struct exec_list phis;
> > +};
> >
> > -   /* Array of SSA defs, indexed by block.  For each block, this
> > array has has
> > -* one of three types of values:
> > -*
> > -*  - NULL. Indicates that there is no known definition in this
> > block.  If
> > -*you need to find one, look at the block's immediate
> dominator.
> > -*
> > -*  - NEEDS_PHI. Indicates that the block may need a phi node
> > but none has
> > -*been created yet.  If a def is requested for a block, a
> > phi will need
> > -*to be created.
> > -*
> > -*  - A regular SSA def.  This will be either the result of a
> > phi node or
> > -*one of the defs provided by
> > nir_phi_builder_value_set_blocK_def().
> > -*/
> > -   nir_ssa_def *defs[0];
> > +/**
> > + * Key for the nir_phi_builder::value_block_def_hash.
> > + */
> > +struct phi_builder_key {
> > +   struct nir_phi_builder_value *val;
> > +   unsigned block_index;
> >  };
> >
> > +static uint32_t
> > +phi_builder_key_hash(const void *_k)
> > +{
> > +   const struct phi_builder_key *k = (const struct phi_builder_key
> > *)_k;
> > +
> > +   return _mesa_fnv32_1a_accumulate(_mesa_fnv32_1a_accumulate(0,
> > k->val),
> > +k->block_index);
> > +}
> > +
> > +static bool
> > +phi_builder_key_equals(const void *_a, const void *_b)
> > +{
> > +   const struct phi_builder_key *a = (const struct phi_builder_key
> > *)_a;
> > +   const struct phi_builder_key *b = (const struct phi_builder_key
> > *)_b;
> > +
> > +   return a->val == b->val && a->block_index == b->block_index;
> > +}
> >
> >
> > Would it be better to have a hash table per value?  A whole hash table
> > sounds like a lot of overhead but it may be less than a tiny allocation
> > (plus a ralloc header!) for every (block, value) pair.  I guess it
> > depends on the number of defs we expect to be registered per-value.
> >
> > Running some on-the-fly numbers... A ralloc header is 6 pointers so a
> > ralloc'd phi_builder_key is 8 pointers worth of data and a ralloc'd
> > hash_table struct is 15 pointers worth.  Throwing in the actual hash
> > table with 7 entries and you have a header and two pointers per entry so
> > that's 

Re: [Mesa-dev] [PATCH 4/7] nir/phi_builder: Use slab allocator for temporary data structures

[Jason Ekstrand]

The linear_alloc stuff that marek added to ralloc also does slab allocation
and can be parented off a ralloc context.  Did you consider that?

On Tue, Nov 20, 2018 at 6:40 PM Ian Romanick  wrote:

> From: Ian Romanick 
>
> This pass allocates a large number of two different data structures.
> This data only lives during the pass.  Use the slab allocator to reduce
> the memory overhead (from 5 pointers + possible padding per allocation
> to nearly zero per allocation) and potentially improve performance.
>
> NOTE: I have not measured the performace delta across this patch
> individually.
>
> Changes in peak memory usage according to Valgrind massif:
>
> mean soft fp64 using uint64:   1,343,998,123 => 1,343,998,123
> gfxbench5 aztec ruins high 11:62,415,414 =>62,415,414
> deus ex mankind divided 148:  62,317,965 =>62,317,965
> deus ex mankind divided 2890: 72,585,466 =>72,603,614
> dirt showdown 676:75,203,703 =>72,450,311
> dolphin ubershaders 210:  83,185,248 =>81,041,040
>
> Signed-off-by: Ian Romanick 
> ---
>  src/compiler/nir/nir_phi_builder.c | 16 ++--
>  1 file changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/src/compiler/nir/nir_phi_builder.c
> b/src/compiler/nir/nir_phi_builder.c
> index 36ab9888f48..4d4d81fcd59 100644
> --- a/src/compiler/nir/nir_phi_builder.c
> +++ b/src/compiler/nir/nir_phi_builder.c
> @@ -23,6 +23,7 @@
>
>  #include "nir_phi_builder.h"
>  #include "nir/nir_vla.h"
> +#include "util/slab.h"
>
>  struct nir_phi_builder {
> nir_shader *shader;
> @@ -60,6 +61,8 @@ struct nir_phi_builder {
>  *one of the defs provided by
> nir_phi_builder_value_set_blocK_def().
>  */
> struct hash_table *value_block_def_hash;
> +   struct slab_mempool value_pool;
> +   struct slab_mempool key_pool;
>  };
>
>  #define NEEDS_PHI ((nir_ssa_def *)(intptr_t)-1)
> @@ -134,6 +137,11 @@ nir_phi_builder_create(nir_function_impl *impl)
>
>  phi_builder_key_hash,
>
>  phi_builder_key_equals);
>
> +   slab_create(>value_pool, sizeof(struct nir_phi_builder_value),
> +   (16 * 1024 - sizeof(void *)) / sizeof(struct
> nir_phi_builder_value));
> +   slab_create(>key_pool, sizeof(struct phi_builder_key),
> +   (16 * 1024 - sizeof(void *)) / sizeof(struct
> phi_builder_key));
> +
> return pb;
>  }
>
> @@ -144,7 +152,7 @@ nir_phi_builder_add_value(struct nir_phi_builder *pb,
> unsigned num_components,
> struct nir_phi_builder_value *val;
> unsigned i, w_start = 0, w_end = 0;
>
> -   val = rzalloc_size(pb, sizeof(*val));
> +   val = slab_alloc_st(>value_pool);
> val->builder = pb;
> val->num_components = num_components;
> val->bit_size = bit_size;
> @@ -211,7 +219,7 @@ nir_phi_builder_value_set_block_def(struct
> nir_phi_builder_value *val,
> if (he != NULL) {
>he->data = def;
> } else {
> -  struct phi_builder_key *kp = ralloc(val->builder, struct
> phi_builder_key);
> +  struct phi_builder_key *kp = slab_alloc_st(>builder->key_pool);
>
>kp->val = k.val;
>kp->block_index = k.block_index;
> @@ -362,5 +370,9 @@ nir_phi_builder_finish(struct nir_phi_builder *pb)
>}
> }
>
> +   slab_flush_st(>value_pool);
> +   slab_flush_st(>key_pool);
> +   slab_destroy(>value_pool);
> +   slab_destroy(>key_pool);
> ralloc_free(pb);
>  }
> --
> 2.14.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

Re: [Mesa-dev] [PATCH 2/7] nir/phi_builder: Use hash table to store [value, block] -> def mapping

[Ian Romanick]

On 11/21/2018 11:01 AM, Jason Ekstrand wrote:
> On Tue, Nov 20, 2018 at 6:40 PM Ian Romanick  > wrote:
> 
> From: Ian Romanick  >
> 
> Changes in peak memory usage according to Valgrind massif:
> 
> mean soft fp64 using uint64:   5,499,881,802 => 1,343,998,123
> gfxbench5 aztec ruins high 11:    62,415,414 =>    62,415,414
> deus ex mankind divided 148:      62,317,965 =>    62,317,965
> deus ex mankind divided 2890:     72,585,466 =>    72,585,466
> dirt showdown 676:                74,473,151 =>    75,203,703
> dolphin ubershaders 210:         109,637,096 =>    83,185,248
> 
> Signed-off-by: Ian Romanick  >
> ---
>  src/compiler/nir/nir_phi_builder.c | 115
> ++---
>  1 file changed, 93 insertions(+), 22 deletions(-)
> 
> diff --git a/src/compiler/nir/nir_phi_builder.c
> b/src/compiler/nir/nir_phi_builder.c
> index add3efd2dfc..36ab9888f48 100644
> --- a/src/compiler/nir/nir_phi_builder.c
> +++ b/src/compiler/nir/nir_phi_builder.c
> @@ -41,6 +41,25 @@ struct nir_phi_builder {
>     unsigned iter_count;
>     unsigned *work;
>     nir_block **W;
> +
> +   /**
> +    * Tables of SSA defs, indexed by block and nir_phi_builder_value.
> +    *
> +    * For each [value, block] tuple, this table has one of three
> types of
> +    * values:
> +    *
> +    *  - NULL (i.e., not in the table). Indicates that there is no
> known
> +    *    definition in this block.  If you need to find one, look
> at the
> +    *    block's immediate dominator.
> +    *
> +    *  - NEEDS_PHI. Indicates that the block may need a phi node
> but none has
> +    *    been created yet.  If a def is requested for a block, a
> phi will need
> +    *    to be created.
> +    *
> +    *  - A regular SSA def.  This will be either the result of a
> phi node or
> +    *    one of the defs provided by
> nir_phi_builder_value_set_blocK_def().
> +    */
> +   struct hash_table *value_block_def_hash;
>  };
> 
>  #define NEEDS_PHI ((nir_ssa_def *)(intptr_t)-1)
> @@ -61,23 +80,34 @@ struct nir_phi_builder_value {
>      * blocks.
>      */
>     struct exec_list phis;
> +};
> 
> -   /* Array of SSA defs, indexed by block.  For each block, this
> array has has
> -    * one of three types of values:
> -    *
> -    *  - NULL. Indicates that there is no known definition in this
> block.  If
> -    *    you need to find one, look at the block's immediate dominator.
> -    *
> -    *  - NEEDS_PHI. Indicates that the block may need a phi node
> but none has
> -    *    been created yet.  If a def is requested for a block, a
> phi will need
> -    *    to be created.
> -    *
> -    *  - A regular SSA def.  This will be either the result of a
> phi node or
> -    *    one of the defs provided by
> nir_phi_builder_value_set_blocK_def().
> -    */
> -   nir_ssa_def *defs[0];
> +/**
> + * Key for the nir_phi_builder::value_block_def_hash.
> + */
> +struct phi_builder_key {
> +   struct nir_phi_builder_value *val;
> +   unsigned block_index;
>  };
> 
> +static uint32_t
> +phi_builder_key_hash(const void *_k)
> +{
> +   const struct phi_builder_key *k = (const struct phi_builder_key
> *)_k;
> +
> +   return _mesa_fnv32_1a_accumulate(_mesa_fnv32_1a_accumulate(0,
> k->val),
> +                                    k->block_index);
> +}
> +
> +static bool
> +phi_builder_key_equals(const void *_a, const void *_b)
> +{
> +   const struct phi_builder_key *a = (const struct phi_builder_key
> *)_a;
> +   const struct phi_builder_key *b = (const struct phi_builder_key
> *)_b;
> +
> +   return a->val == b->val && a->block_index == b->block_index;
> +}
> 
> 
> Would it be better to have a hash table per value?  A whole hash table
> sounds like a lot of overhead but it may be less than a tiny allocation
> (plus a ralloc header!) for every (block, value) pair.  I guess it
> depends on the number of defs we expect to be registered per-value.
> 
> Running some on-the-fly numbers... A ralloc header is 6 pointers so a
> ralloc'd phi_builder_key is 8 pointers worth of data and a ralloc'd
> hash_table struct is 15 pointers worth.  Throwing in the actual hash
> table with 7 entries and you have a header and two pointers per entry so
> that's another 20 pointers for a total of 35.  That's the same as four
> phi_builder_keys (without including malloc's own overhead).  So if you
> have at least four blocks involved (there have to be at least 3 or there
> is no phi), it's break-even and if there are more involved, one table
> per value is a win.

I 

Re: [Mesa-dev] [PATCH 7/7] intel/compiler: Release memory used by NIR metadata before generating machine code

[Ian Romanick]

On 11/21/2018 11:08 AM, Jason Ekstrand wrote:
> On Tue, Nov 20, 2018 at 6:40 PM Ian Romanick  > wrote:
> 
> From: Ian Romanick  >
> 
> Changes in peak memory usage according to Valgrind massif:
> 
> mean soft fp64 using uint64:   1,342,766,051 => 1,010,677,195
> gfxbench5 aztec ruins high 11:    62,369,974 =>    62,369,974
> deus ex mankind divided 148:      62,290,717 =>    62,290,717
> deus ex mankind divided 2890:     72,105,042 =>    71,930,254
> dirt showdown 676:                72,243,383 =>    72,243,383
> dolphin ubershaders 210:          80,650,936 =>    80,650,936
> 
> Signed-off-by: Ian Romanick  >
> ---
>  src/intel/compiler/brw_fs.cpp   | 6 ++
>  src/intel/compiler/brw_vec4.cpp | 6 ++
>  2 files changed, 12 insertions(+)
> 
> diff --git a/src/intel/compiler/brw_fs.cpp
> b/src/intel/compiler/brw_fs.cpp
> index 3e083723471..e0e6b34d41a 100644
> --- a/src/intel/compiler/brw_fs.cpp
> +++ b/src/intel/compiler/brw_fs.cpp
> @@ -7170,6 +7170,12 @@ brw_compile_fs(const struct brw_compiler
> *compiler, void *log_data,
>     prog_data->barycentric_interp_modes =
>        brw_compute_barycentric_interp_modes(compiler->devinfo, shader);
> 
> +   /* Release memory used by NIR metadata.  It is not needed any
> longer. */
> +   nir_foreach_function(function, shader) {
> +      if (function->impl)
> +         nir_live_ssa_defs_impl_flush(function->impl);
> +   }
> +
>     cfg_t *simd8_cfg = NULL, *simd16_cfg = NULL, *simd32_cfg = NULL;
> 
>     fs_visitor v8(compiler, log_data, mem_ctx, key,
> diff --git a/src/intel/compiler/brw_vec4.cpp
> b/src/intel/compiler/brw_vec4.cpp
> index 74a4d09fc79..3401d999a15 100644
> --- a/src/intel/compiler/brw_vec4.cpp
> +++ b/src/intel/compiler/brw_vec4.cpp
> @@ -2947,6 +2947,12 @@ brw_compile_vs(const struct brw_compiler
> *compiler, void *log_data,
>        brw_print_vue_map(stderr, _data->base.vue_map);
>     }
> 
> +   /* Release memory used by NIR metadata.  It is not needed any
> longer. */
> +   nir_foreach_function(function, shader) {
> +      if (function->impl)
> +         nir_live_ssa_defs_impl_flush(function->impl);
> +   }
> 
> 
> I just had a look at this and it looks like nir_sweep will also clean up
> the metadata.  Maybe we should just add a nir_sweep() call to the end of
> brw_postprocess_nir()?  That would clean up other artifacts of
> stage-specific lowering as well and putting it in brw_postprocess_nir()
> would make it apply to all stages.

That is interesting.  I did not know about nir_sweep.  There were some
other bits on metadata, but, since I wasn't sure that none of it was
used during code generation, I decided to err on the conservative side.
I'll give this a try.

> +
>     if (is_scalar) {
>        prog_data->base.dispatch_mode = DISPATCH_MODE_SIMD8;
> 
> -- 
> 2.14.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

Re: [Mesa-dev] [PATCH] vulkan: Allow storage images in the WSI.

[Jason Ekstrand]

We don't support storage on any WSI image formats but that shouldn't be an
actual problem.

Reviewed-by: Jason Ekstrand 

On Tue, Nov 20, 2018 at 3:30 PM Bas Nieuwenhuizen 
wrote:

> Since apps also have to follow the ImageFormatProperties query,
> we can disallow formats that don't allow image stores (for AMD
> that would be SRGB formats).
>
> Note that this only affects anything if the app actually decides
> to use the flag.
>
> Had someone ask for this on IRC and at least on the AMD side we
> can support it.
>
> CC: Jason Ekstrand 
> ---
>  src/vulkan/wsi/wsi_common_display.c | 1 +
>  src/vulkan/wsi/wsi_common_wayland.c | 1 +
>  src/vulkan/wsi/wsi_common_x11.c | 1 +
>  3 files changed, 3 insertions(+)
>
> diff --git a/src/vulkan/wsi/wsi_common_display.c
> b/src/vulkan/wsi/wsi_common_display.c
> index fd0d30ad80c..edfb166fa69 100644
> --- a/src/vulkan/wsi/wsi_common_display.c
> +++ b/src/vulkan/wsi/wsi_common_display.c
> @@ -834,6 +834,7 @@ wsi_display_surface_get_capabilities(VkIcdSurfaceBase
> *surface_base,
>VK_IMAGE_USAGE_TRANSFER_SRC_BIT |
>VK_IMAGE_USAGE_SAMPLED_BIT |
>VK_IMAGE_USAGE_TRANSFER_DST_BIT |
> +  VK_IMAGE_USAGE_STORAGE_BIT |
>VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT;
>
> return VK_SUCCESS;
> diff --git a/src/vulkan/wsi/wsi_common_wayland.c
> b/src/vulkan/wsi/wsi_common_wayland.c
> index 3d3a60167bf..c0132566ead 100644
> --- a/src/vulkan/wsi/wsi_common_wayland.c
> +++ b/src/vulkan/wsi/wsi_common_wayland.c
> @@ -508,6 +508,7 @@ wsi_wl_surface_get_capabilities(VkIcdSurfaceBase
> *surface,
>VK_IMAGE_USAGE_TRANSFER_SRC_BIT |
>VK_IMAGE_USAGE_SAMPLED_BIT |
>VK_IMAGE_USAGE_TRANSFER_DST_BIT |
> +  VK_IMAGE_USAGE_STORAGE_BIT |
>VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT;
>
> return VK_SUCCESS;
> diff --git a/src/vulkan/wsi/wsi_common_x11.c
> b/src/vulkan/wsi/wsi_common_x11.c
> index c740726fe54..6146c8f3da8 100644
> --- a/src/vulkan/wsi/wsi_common_x11.c
> +++ b/src/vulkan/wsi/wsi_common_x11.c
> @@ -515,6 +515,7 @@ x11_surface_get_capabilities(VkIcdSurfaceBase
> *icd_surface,
>VK_IMAGE_USAGE_TRANSFER_SRC_BIT |
>VK_IMAGE_USAGE_SAMPLED_BIT |
>VK_IMAGE_USAGE_TRANSFER_DST_BIT |
> +  VK_IMAGE_USAGE_STORAGE_BIT |
>VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT;
>
> return VK_SUCCESS;
> --
> 2.19.1
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 7/7] intel/compiler: Release memory used by NIR metadata before generating machine code

[Jason Ekstrand]

On Tue, Nov 20, 2018 at 6:40 PM Ian Romanick  wrote:

> From: Ian Romanick 
>
> Changes in peak memory usage according to Valgrind massif:
>
> mean soft fp64 using uint64:   1,342,766,051 => 1,010,677,195
> gfxbench5 aztec ruins high 11:62,369,974 =>62,369,974
> deus ex mankind divided 148:  62,290,717 =>62,290,717
> deus ex mankind divided 2890: 72,105,042 =>71,930,254
> dirt showdown 676:72,243,383 =>72,243,383
> dolphin ubershaders 210:  80,650,936 =>80,650,936
>
> Signed-off-by: Ian Romanick 
> ---
>  src/intel/compiler/brw_fs.cpp   | 6 ++
>  src/intel/compiler/brw_vec4.cpp | 6 ++
>  2 files changed, 12 insertions(+)
>
> diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.cpp
> index 3e083723471..e0e6b34d41a 100644
> --- a/src/intel/compiler/brw_fs.cpp
> +++ b/src/intel/compiler/brw_fs.cpp
> @@ -7170,6 +7170,12 @@ brw_compile_fs(const struct brw_compiler *compiler,
> void *log_data,
> prog_data->barycentric_interp_modes =
>brw_compute_barycentric_interp_modes(compiler->devinfo, shader);
>
> +   /* Release memory used by NIR metadata.  It is not needed any longer.
> */
> +   nir_foreach_function(function, shader) {
> +  if (function->impl)
> + nir_live_ssa_defs_impl_flush(function->impl);
> +   }
> +
> cfg_t *simd8_cfg = NULL, *simd16_cfg = NULL, *simd32_cfg = NULL;
>
> fs_visitor v8(compiler, log_data, mem_ctx, key,
> diff --git a/src/intel/compiler/brw_vec4.cpp
> b/src/intel/compiler/brw_vec4.cpp
> index 74a4d09fc79..3401d999a15 100644
> --- a/src/intel/compiler/brw_vec4.cpp
> +++ b/src/intel/compiler/brw_vec4.cpp
> @@ -2947,6 +2947,12 @@ brw_compile_vs(const struct brw_compiler *compiler,
> void *log_data,
>brw_print_vue_map(stderr, _data->base.vue_map);
> }
>
> +   /* Release memory used by NIR metadata.  It is not needed any longer.
> */
> +   nir_foreach_function(function, shader) {
> +  if (function->impl)
> + nir_live_ssa_defs_impl_flush(function->impl);
> +   }
>

I just had a look at this and it looks like nir_sweep will also clean up
the metadata.  Maybe we should just add a nir_sweep() call to the end of
brw_postprocess_nir()?  That would clean up other artifacts of
stage-specific lowering as well and putting it in brw_postprocess_nir()
would make it apply to all stages.


> +
> if (is_scalar) {
>prog_data->base.dispatch_mode = DISPATCH_MODE_SIMD8;
>
> --
> 2.14.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 108087] Memory leak in clover::kernel::argument::create<>() (i.e. clEnqueueNDRangeKernel())

[bugzilla-daemon]

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

Jan Vesely  changed:

   What|Removed |Added

 CC||baker.dyla...@gmail.com

--- Comment #2 from Jan Vesely  ---
Dylan, are there any plans wrt 18.1?
If not, I think this one should be closed as WONTFIX.

-- 
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 3/3] glsl: fix typos in comments "transfor" -> "transform"

[Ilia Mirkin]

Oh, yay, you fixed the typos here. I just had to keep reading.

This patch is obviously

Reviewed-by: Ilia Mirkin 

For the others ... have you run these through intel's CI? I'm
interested in verifying that dEQP, CTS, and piglit all remain happy
with the changes. The program resource stuff took a while to nail down
properly (and it seems like we're discovering issues to this very
day).

  -ilia
On Wed, Nov 21, 2018 at 1:46 PM Jose Maria Casanova Crespo
 wrote:
>
> ---
>  src/compiler/glsl/ir.h | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/src/compiler/glsl/ir.h b/src/compiler/glsl/ir.h
> index e09f053b77c..c3f5f1f7b05 100644
> --- a/src/compiler/glsl/ir.h
> +++ b/src/compiler/glsl/ir.h
> @@ -773,17 +773,17 @@ public:
>unsigned is_xfb_per_vertex_output:1;
>
>/**
> -   * Was a transfor feedback buffer set in the shader?
> +   * Was a transform feedback buffer set in the shader?
> */
>unsigned explicit_xfb_buffer:1;
>
>/**
> -   * Was a transfor feedback offset set in the shader?
> +   * Was a transform feedback offset set in the shader?
> */
>unsigned explicit_xfb_offset:1;
>
>/**
> -   * Was a transfor feedback stride set in the shader?
> +   * Was a transform feedback stride set in the shader?
> */
>unsigned explicit_xfb_stride:1;
>
> --
> 2.19.1
>
> ___
> 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 1/3] glsl: XFB TSC per-vertex output varyings match as not declared as arrays

[Ilia Mirkin]

On Wed, Nov 21, 2018 at 1:45 PM Jose Maria Casanova Crespo
 wrote:
>
> Recent change on OpenGL CTS ("Use non-arrayed varying name for TCS blocks")
> on KHR-GL*.tessellation_shader.single.xfb_captures_data_from_correct_stage
> tests changed how to name per-vertex Tessellation Control Shader output
> varyings in transform feedback using interface block as "BLOCK_INOUT.value"
> rather than "BLOCK_INOUT[0].value"
>
> So Tessellation control shader per-vertex output variables and blocks that
> are required to be declared as arrays, with each element representing output
> values for a single vertex of a multi-vertex primitive are expected to be
> named as they were not declared as arrays.
>
> This patch adds a new is_xfb_per_vertex_output flag at ir_variable level so
> we mark when an ir_variable is an per-vertex TCS output varying. So we
> treat it in terms on XFB its naming as a non array variable.
>
> As we don't support NV_gpu_shader5, so PATCHES mode is not accepted as
> primitiveMode parameter of BeginTransformFeedback the test expects a
> failure as we can use the XFB results.
>
> This patch uncovers that we were passing the GLES version of the tests
> because candidates naming didn't match, not because on GLES the Tessellation
> Control stage varyings shouldn't be XFB candidates in any case. This
> is addressed in the following patch.
>
> Fixes: 
> KHR-GL4*.tessellation_shader.single.xfb_captures_data_from_correct_stage
>
> Cc: mesa-sta...@lists.freedesktop.org
> ---
>  src/compiler/glsl/ir.cpp| 1 +
>  src/compiler/glsl/ir.h  | 6 ++
>  src/compiler/glsl/link_uniforms.cpp | 6 --
>  src/compiler/glsl/link_varyings.cpp | 8 +++-
>  4 files changed, 18 insertions(+), 3 deletions(-)
>
> diff --git a/src/compiler/glsl/ir.cpp b/src/compiler/glsl/ir.cpp
> index 1d1a56ae9a5..582111d71f5 100644
> --- a/src/compiler/glsl/ir.cpp
> +++ b/src/compiler/glsl/ir.cpp
> @@ -1750,6 +1750,7 @@ ir_variable::ir_variable(const struct glsl_type *type, 
> const char *name,
> this->data.fb_fetch_output = false;
> this->data.bindless = false;
> this->data.bound = false;
> +   this->data.is_xfb_per_vertex_output = false;
>
> if (type != NULL) {
>if (type->is_interface())
> diff --git a/src/compiler/glsl/ir.h b/src/compiler/glsl/ir.h
> index f478b29a6b5..e09f053b77c 100644
> --- a/src/compiler/glsl/ir.h
> +++ b/src/compiler/glsl/ir.h
> @@ -766,6 +766,12 @@ public:
> */
>unsigned is_xfb_only:1;
>
> +  /**
> +   * Is this varying a TSC per-vertex output candidate for transform

TCS?

> +   * feedback?
> +   */
> +  unsigned is_xfb_per_vertex_output:1;
> +
>/**
> * Was a transfor feedback buffer set in the shader?

ugh, not your problem, but "transform" :(

> */
> diff --git a/src/compiler/glsl/link_uniforms.cpp 
> b/src/compiler/glsl/link_uniforms.cpp
> index 63e688b19a7..547da68e216 100644
> --- a/src/compiler/glsl/link_uniforms.cpp
> +++ b/src/compiler/glsl/link_uniforms.cpp
> @@ -72,8 +72,10 @@ program_resource_visitor::process(ir_variable *var, bool 
> use_std430_as_default)
>   get_internal_ifc_packing(use_std430_as_default) :
>var->type->get_internal_ifc_packing(use_std430_as_default);
>
> -   const glsl_type *t =
> -  var->data.from_named_ifc_block ? var->get_interface_type() : var->type;
> +   const glsl_type *t = var->data.from_named_ifc_block ?
> +  (var->data.is_xfb_per_vertex_output ?
> +   var->get_interface_type()->without_array() :
> +   var->get_interface_type()) : var->type;
> const glsl_type *t_without_array = t->without_array();
>
> /* false is always passed for the row_major parameter to the other
> diff --git a/src/compiler/glsl/link_varyings.cpp 
> b/src/compiler/glsl/link_varyings.cpp
> index 52e493cb599..1964dcc0a22 100644
> --- a/src/compiler/glsl/link_varyings.cpp
> +++ b/src/compiler/glsl/link_varyings.cpp
> @@ -2150,7 +2150,10 @@ private:
>tfeedback_candidate *candidate
>   = rzalloc(this->mem_ctx, tfeedback_candidate);
>candidate->toplevel_var = this->toplevel_var;
> -  candidate->type = type;
> +  if (this->toplevel_var->data.is_xfb_per_vertex_output)
> + candidate->type = type->without_array();
> +  else
> + candidate->type = type;
>candidate->offset = this->varying_floats;
>_mesa_hash_table_insert(this->tfeedback_candidates,
>ralloc_strdup(this->mem_ctx, name),
> @@ -2499,6 +2502,9 @@ assign_varying_locations(struct gl_context *ctx,
>
>   if (num_tfeedback_decls > 0) {
>  tfeedback_candidate_generator g(mem_ctx, tfeedback_candidates);
> +if (producer->Stage == MESA_SHADER_TESS_CTRL &&
> +!output_var->data.patch)
> +   output_var->data.is_xfb_per_vertex_output = true;
>  g.process(output_var);
>   }
>
> --
> 2.19.1
>
> ___
> 

Re: [Mesa-dev] [PATCH 2/7] nir/phi_builder: Use hash table to store [value, block] -> def mapping

[Jason Ekstrand]

On Tue, Nov 20, 2018 at 6:40 PM Ian Romanick  wrote:

> From: Ian Romanick 
>
> Changes in peak memory usage according to Valgrind massif:
>
> mean soft fp64 using uint64:   5,499,881,802 => 1,343,998,123
> gfxbench5 aztec ruins high 11:62,415,414 =>62,415,414
> deus ex mankind divided 148:  62,317,965 =>62,317,965
> deus ex mankind divided 2890: 72,585,466 =>72,585,466
> dirt showdown 676:74,473,151 =>75,203,703
> dolphin ubershaders 210: 109,637,096 =>83,185,248
>
> Signed-off-by: Ian Romanick 
> ---
>  src/compiler/nir/nir_phi_builder.c | 115
> ++---
>  1 file changed, 93 insertions(+), 22 deletions(-)
>
> diff --git a/src/compiler/nir/nir_phi_builder.c
> b/src/compiler/nir/nir_phi_builder.c
> index add3efd2dfc..36ab9888f48 100644
> --- a/src/compiler/nir/nir_phi_builder.c
> +++ b/src/compiler/nir/nir_phi_builder.c
> @@ -41,6 +41,25 @@ struct nir_phi_builder {
> unsigned iter_count;
> unsigned *work;
> nir_block **W;
> +
> +   /**
> +* Tables of SSA defs, indexed by block and nir_phi_builder_value.
> +*
> +* For each [value, block] tuple, this table has one of three types of
> +* values:
> +*
> +*  - NULL (i.e., not in the table). Indicates that there is no known
> +*definition in this block.  If you need to find one, look at the
> +*block's immediate dominator.
> +*
> +*  - NEEDS_PHI. Indicates that the block may need a phi node but none
> has
> +*been created yet.  If a def is requested for a block, a phi will
> need
> +*to be created.
> +*
> +*  - A regular SSA def.  This will be either the result of a phi node
> or
> +*one of the defs provided by
> nir_phi_builder_value_set_blocK_def().
> +*/
> +   struct hash_table *value_block_def_hash;
>  };
>
>  #define NEEDS_PHI ((nir_ssa_def *)(intptr_t)-1)
> @@ -61,23 +80,34 @@ struct nir_phi_builder_value {
>  * blocks.
>  */
> struct exec_list phis;
> +};
>
> -   /* Array of SSA defs, indexed by block.  For each block, this array
> has has
> -* one of three types of values:
> -*
> -*  - NULL. Indicates that there is no known definition in this
> block.  If
> -*you need to find one, look at the block's immediate dominator.
> -*
> -*  - NEEDS_PHI. Indicates that the block may need a phi node but none
> has
> -*been created yet.  If a def is requested for a block, a phi will
> need
> -*to be created.
> -*
> -*  - A regular SSA def.  This will be either the result of a phi node
> or
> -*one of the defs provided by
> nir_phi_builder_value_set_blocK_def().
> -*/
> -   nir_ssa_def *defs[0];
> +/**
> + * Key for the nir_phi_builder::value_block_def_hash.
> + */
> +struct phi_builder_key {
> +   struct nir_phi_builder_value *val;
> +   unsigned block_index;
>  };
>
> +static uint32_t
> +phi_builder_key_hash(const void *_k)
> +{
> +   const struct phi_builder_key *k = (const struct phi_builder_key *)_k;
> +
> +   return _mesa_fnv32_1a_accumulate(_mesa_fnv32_1a_accumulate(0, k->val),
> +k->block_index);
> +}
> +
> +static bool
> +phi_builder_key_equals(const void *_a, const void *_b)
> +{
> +   const struct phi_builder_key *a = (const struct phi_builder_key *)_a;
> +   const struct phi_builder_key *b = (const struct phi_builder_key *)_b;
> +
> +   return a->val == b->val && a->block_index == b->block_index;
> +}
>

Would it be better to have a hash table per value?  A whole hash table
sounds like a lot of overhead but it may be less than a tiny allocation
(plus a ralloc header!) for every (block, value) pair.  I guess it depends
on the number of defs we expect to be registered per-value.

Running some on-the-fly numbers... A ralloc header is 6 pointers so a
ralloc'd phi_builder_key is 8 pointers worth of data and a ralloc'd
hash_table struct is 15 pointers worth.  Throwing in the actual hash table
with 7 entries and you have a header and two pointers per entry so that's
another 20 pointers for a total of 35.  That's the same as four
phi_builder_keys (without including malloc's own overhead).  So if you have
at least four blocks involved (there have to be at least 3 or there is no
phi), it's break-even and if there are more involved, one table per value
is a win.

We could also consider doing some optimizations for the case where the
value is defined in only one block but that gets tricky as everything has
an implicit undef at the top so that's probably best left for another time
unless it's a super-common case in the fp64 code.


> +
>  struct nir_phi_builder *
>  nir_phi_builder_create(nir_function_impl *impl)
>  {
> @@ -100,6 +130,9 @@ nir_phi_builder_create(nir_function_impl *impl)
> pb->iter_count = 0;
> pb->work = rzalloc_array(pb, unsigned, pb->num_blocks);
> pb->W = ralloc_array(pb, nir_block *, pb->num_blocks);
> +   pb->value_block_def_hash = 

[Mesa-dev] [Bug 108457] [OpenGL CTS] KHR-GL46.tessellation_shader.single.xfb_captures_data_from_correct_stage fails

[bugzilla-daemon]

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

--- Comment #1 from Chema Casanova  ---
I've just send a fix for review:

https://patchwork.freedesktop.org/series/52841/

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

Re: [Mesa-dev] [PATCH] meson: Bump version to 0.46 for python module

[Matt Turner]

Thanks Arfrever and Dylan.

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

Re: [Mesa-dev] [PATCH mesa 00/13] Make standard function available on non-standard platforms

[Ian Romanick]

On 11/20/2018 05:11 AM, Eric Engestrom wrote:
> ... instead of making standard platforms use non-standard functions.

I haven't looked at the specific patches, so this comment may not apply.
 When we first headed down the path of adding a billion wrapper
functions, I campaigned pretty strongly to give them the standard names.
 The problem is that some platforms have functions with the standard
names that deviate from the standard behavior in ways that make them
unusable.  I think one of the printf-like functions was the main problem
here, but it was a long time ago.

Either way, you can't give the wrapper the standard name in this case.
Once you have to name one wrapper function _foo_standard_name, you might
as well name them all like that.

> This also reduces the likelihood of someone forgetting to use the
> non-standard function, and reduces the fix to a simple #include.

If we cared, I bet we could write a 'make check' test that would just
grep through the tree for functions that are supposed to be wrapped.
The test would fail if a non-wrapped version was used.  We'd probably
have to use Python, so I don't know how much effort it would be.

> Changes generated using this shell function for each function name:
>   fix() {
> files=$(ag -lw util_$1)
> sed s/'\'/$1/g -i $files
> git add -up $files
> git commit -sm 'util: use standard name for '$1'()'
>   }
> 
> Eric Engestrom (13):
>   util: use standard name for strchrnul()
>   util: use standard name for strcasecmp()
>   util: use standard name for strdup()
>   util: use standard name for strstr()

What the... ?  strstr is part of C89.  What platform actually needs a
wrapper for this?  I see zero uses in the code base of util_strstr.
Ditto for strdup, strncmp, strcmp, strchr, and possibly others.  I
looked, and Microsoft has strncmp at least as far back as Visual Studio
2012.

https://docs.microsoft.com/en-us/previous-versions/visualstudio/visual-studio-2012/eywx8zcx(v=vs.110)

I don't see any of these functions on the list of functions that aren't
always available:

https://docs.microsoft.com/en-us/cpp/cppcx/crt-functions-not-supported-in-universal-windows-platform-apps

All of these functions appear to have been added by 131a1fbc91725.  I've
added Jose to CC since he wrote it.  The whole commit message there is:

util: Alternative implementation for standard c library string
functions.

That doesn't give much insight. :(

Give that patch was 10 years ago, some of the wrappers that were needed
in 2008 may not be needed now.  I'd prefer to see wrappers that aren't
needed in 2018 be replaced with the standard functions as a first step.
We can sort out the remainder after that.

>   util: use standard name for strncat()
>   util: use standard name for strncmp()
>   util: use standard name for strcmp()
>   util: use standard name for strchr()
>   util: use standard name for sprintf()
>   util: use standard name for vasprintf()
>   util: use standard name for vsprintf()
>   util: use standard name for snprintf()
>   util: use standard name for vsnprintf()
> 
>  src/amd/common/ac_debug.c |  2 +-
>  .../glsl/ir_builder_print_visitor.cpp |  2 +-
>  src/compiler/glsl/ir_print_visitor.cpp| 12 ++---
>  src/compiler/glsl/link_interface_blocks.cpp   |  4 +-
>  src/compiler/glsl/linker.cpp  |  2 +-
>  .../glsl/opt_dead_builtin_varyings.cpp| 10 ++--
>  src/compiler/glsl_types.cpp   | 10 ++--
>  src/gallium/auxiliary/draw/draw_llvm.c| 10 ++--
>  src/gallium/auxiliary/driver_ddebug/dd_util.h |  4 +-
>  src/gallium/auxiliary/driver_trace/tr_dump.c  |  2 +-
>  .../auxiliary/gallivm/lp_bld_arit_overflow.c  |  2 +-
>  .../auxiliary/gallivm/lp_bld_debug.cpp|  4 +-
>  src/gallium/auxiliary/gallivm/lp_bld_debug.h  |  2 +-
>  src/gallium/auxiliary/gallivm/lp_bld_gather.c |  2 +-
>  src/gallium/auxiliary/gallivm/lp_bld_init.c   |  4 +-
>  src/gallium/auxiliary/gallivm/lp_bld_intr.c   |  4 +-
>  src/gallium/auxiliary/gallivm/lp_bld_printf.c |  8 +--
>  .../auxiliary/gallivm/lp_bld_sample_soa.c |  2 +-
>  .../auxiliary/gallivm/lp_bld_tgsi_soa.c   |  2 +-
>  src/gallium/auxiliary/hud/hud_context.c   |  4 +-
>  .../auxiliary/pipe-loader/pipe_loader.c   |  6 +--
>  src/gallium/auxiliary/postprocess/pp_mlaa.c   |  2 +-
>  src/gallium/auxiliary/tgsi/tgsi_dump.c|  2 +-
>  src/gallium/auxiliary/util/u_async_debug.c|  2 +-
>  src/gallium/auxiliary/util/u_debug_describe.c | 22 
>  src/gallium/auxiliary/util/u_debug_flush.c|  2 +-
>  src/gallium/auxiliary/util/u_debug_image.c|  2 +-
>  src/gallium/auxiliary/util/u_debug_symbol.c   | 10 ++--
>  src/gallium/auxiliary/util/u_dump_state.c |  2 +-
>  src/gallium/auxiliary/util/u_log.c|  2 +-
>  src/gallium/auxiliary/util/u_network.c|  2 +-
>  src/gallium/auxiliary/util/u_simple_shaders.c |  2 +-
>  src/gallium/auxiliary/util/u_tests.c  |  4 +-
>  

[Mesa-dev] [PATCH 3/3] glsl: fix typos in comments "transfor" -> "transform"

[Jose Maria Casanova Crespo]

---
 src/compiler/glsl/ir.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/compiler/glsl/ir.h b/src/compiler/glsl/ir.h
index e09f053b77c..c3f5f1f7b05 100644
--- a/src/compiler/glsl/ir.h
+++ b/src/compiler/glsl/ir.h
@@ -773,17 +773,17 @@ public:
   unsigned is_xfb_per_vertex_output:1;
 
   /**
-   * Was a transfor feedback buffer set in the shader?
+   * Was a transform feedback buffer set in the shader?
*/
   unsigned explicit_xfb_buffer:1;
 
   /**
-   * Was a transfor feedback offset set in the shader?
+   * Was a transform feedback offset set in the shader?
*/
   unsigned explicit_xfb_offset:1;
 
   /**
-   * Was a transfor feedback stride set in the shader?
+   * Was a transform feedback stride set in the shader?
*/
   unsigned explicit_xfb_stride:1;
 
-- 
2.19.1

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

[Mesa-dev] [PATCH 2/3] glsl: TCS outputs can not be transform feedback candidates on GLES

[Jose Maria Casanova Crespo]

Fixes: 
KHR-GLES*.core.tessellation_shader.single.xfb_captures_data_from_correct_stage

Cc: mesa-sta...@lists.freedesktop.org
---
I think this patch and the previous one should be squashed or interchange
the order before landing. I'm sending splitted because it allows exposing
the incorrect behaviour on GLES.

 src/compiler/glsl/link_varyings.cpp | 29 +
 1 file changed, 25 insertions(+), 4 deletions(-)

diff --git a/src/compiler/glsl/link_varyings.cpp 
b/src/compiler/glsl/link_varyings.cpp
index 1964dcc0a22..8bb90de8072 100644
--- a/src/compiler/glsl/link_varyings.cpp
+++ b/src/compiler/glsl/link_varyings.cpp
@@ -2502,10 +2502,31 @@ assign_varying_locations(struct gl_context *ctx,
 
  if (num_tfeedback_decls > 0) {
 tfeedback_candidate_generator g(mem_ctx, tfeedback_candidates);
-if (producer->Stage == MESA_SHADER_TESS_CTRL &&
-!output_var->data.patch)
-   output_var->data.is_xfb_per_vertex_output = true;
-g.process(output_var);
+
+/* From OpenGL 4.6 (Core Profile) spec, section 11.1.2.1
+ * ("Vertex Shader Variables / Output Variables")
+ *
+ * "Each program object can specify a set of output variables from
+ * one shader to be recorded in transform feedback mode (see
+ * section 13.3). The variables that can be recorded are those
+ * emitted by the first active shader, in order, from the
+ * following list:
+ *
+ *  * geometry shader
+ *  * tessellation evaluation shader
+ *  * tessellation control shader
+ *  * vertex shader"
+ *
+ * But on OpenGL ES 3.2, section 11.1.2.1 ("Vertex Shader
+ * Variables / Output Variables") tessellation control shader is
+ * not included in the stages list.
+ */
+if (!prog->IsES || producer->Stage != MESA_SHADER_TESS_CTRL) {
+   if (producer->Stage == MESA_SHADER_TESS_CTRL &&
+   !output_var->data.patch)
+  output_var->data.is_xfb_per_vertex_output = true;
+   g.process(output_var);
+}
  }
 
  ir_variable *const input_var =
-- 
2.19.1

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

[Mesa-dev] [PATCH 1/3] glsl: XFB TSC per-vertex output varyings match as not declared as arrays

[Jose Maria Casanova Crespo]

Recent change on OpenGL CTS ("Use non-arrayed varying name for TCS blocks")
on KHR-GL*.tessellation_shader.single.xfb_captures_data_from_correct_stage
tests changed how to name per-vertex Tessellation Control Shader output
varyings in transform feedback using interface block as "BLOCK_INOUT.value"
rather than "BLOCK_INOUT[0].value"

So Tessellation control shader per-vertex output variables and blocks that
are required to be declared as arrays, with each element representing output
values for a single vertex of a multi-vertex primitive are expected to be
named as they were not declared as arrays.

This patch adds a new is_xfb_per_vertex_output flag at ir_variable level so
we mark when an ir_variable is an per-vertex TCS output varying. So we
treat it in terms on XFB its naming as a non array variable.

As we don't support NV_gpu_shader5, so PATCHES mode is not accepted as
primitiveMode parameter of BeginTransformFeedback the test expects a
failure as we can use the XFB results.

This patch uncovers that we were passing the GLES version of the tests
because candidates naming didn't match, not because on GLES the Tessellation
Control stage varyings shouldn't be XFB candidates in any case. This
is addressed in the following patch.

Fixes: KHR-GL4*.tessellation_shader.single.xfb_captures_data_from_correct_stage

Cc: mesa-sta...@lists.freedesktop.org
---
 src/compiler/glsl/ir.cpp| 1 +
 src/compiler/glsl/ir.h  | 6 ++
 src/compiler/glsl/link_uniforms.cpp | 6 --
 src/compiler/glsl/link_varyings.cpp | 8 +++-
 4 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/src/compiler/glsl/ir.cpp b/src/compiler/glsl/ir.cpp
index 1d1a56ae9a5..582111d71f5 100644
--- a/src/compiler/glsl/ir.cpp
+++ b/src/compiler/glsl/ir.cpp
@@ -1750,6 +1750,7 @@ ir_variable::ir_variable(const struct glsl_type *type, 
const char *name,
this->data.fb_fetch_output = false;
this->data.bindless = false;
this->data.bound = false;
+   this->data.is_xfb_per_vertex_output = false;
 
if (type != NULL) {
   if (type->is_interface())
diff --git a/src/compiler/glsl/ir.h b/src/compiler/glsl/ir.h
index f478b29a6b5..e09f053b77c 100644
--- a/src/compiler/glsl/ir.h
+++ b/src/compiler/glsl/ir.h
@@ -766,6 +766,12 @@ public:
*/
   unsigned is_xfb_only:1;
 
+  /**
+   * Is this varying a TSC per-vertex output candidate for transform
+   * feedback?
+   */
+  unsigned is_xfb_per_vertex_output:1;
+
   /**
* Was a transfor feedback buffer set in the shader?
*/
diff --git a/src/compiler/glsl/link_uniforms.cpp 
b/src/compiler/glsl/link_uniforms.cpp
index 63e688b19a7..547da68e216 100644
--- a/src/compiler/glsl/link_uniforms.cpp
+++ b/src/compiler/glsl/link_uniforms.cpp
@@ -72,8 +72,10 @@ program_resource_visitor::process(ir_variable *var, bool 
use_std430_as_default)
  get_internal_ifc_packing(use_std430_as_default) :
   var->type->get_internal_ifc_packing(use_std430_as_default);
 
-   const glsl_type *t =
-  var->data.from_named_ifc_block ? var->get_interface_type() : var->type;
+   const glsl_type *t = var->data.from_named_ifc_block ?
+  (var->data.is_xfb_per_vertex_output ?
+   var->get_interface_type()->without_array() :
+   var->get_interface_type()) : var->type;
const glsl_type *t_without_array = t->without_array();
 
/* false is always passed for the row_major parameter to the other
diff --git a/src/compiler/glsl/link_varyings.cpp 
b/src/compiler/glsl/link_varyings.cpp
index 52e493cb599..1964dcc0a22 100644
--- a/src/compiler/glsl/link_varyings.cpp
+++ b/src/compiler/glsl/link_varyings.cpp
@@ -2150,7 +2150,10 @@ private:
   tfeedback_candidate *candidate
  = rzalloc(this->mem_ctx, tfeedback_candidate);
   candidate->toplevel_var = this->toplevel_var;
-  candidate->type = type;
+  if (this->toplevel_var->data.is_xfb_per_vertex_output)
+ candidate->type = type->without_array();
+  else
+ candidate->type = type;
   candidate->offset = this->varying_floats;
   _mesa_hash_table_insert(this->tfeedback_candidates,
   ralloc_strdup(this->mem_ctx, name),
@@ -2499,6 +2502,9 @@ assign_varying_locations(struct gl_context *ctx,
 
  if (num_tfeedback_decls > 0) {
 tfeedback_candidate_generator g(mem_ctx, tfeedback_candidates);
+if (producer->Stage == MESA_SHADER_TESS_CTRL &&
+!output_var->data.patch)
+   output_var->data.is_xfb_per_vertex_output = true;
 g.process(output_var);
  }
 
-- 
2.19.1

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

Re: [Mesa-dev] [PATCH 1/7] nir/phi_builder: Internal users should use nir_phi_builder_value_set_block_def too

[Jason Ekstrand]

Reviewed-by: Jason Ekstrand 

On Tue, Nov 20, 2018 at 6:40 PM Ian Romanick  wrote:

> From: Ian Romanick 
>
> Signed-off-by: Ian Romanick 
> ---
>  src/compiler/nir/nir_phi_builder.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/compiler/nir/nir_phi_builder.c
> b/src/compiler/nir/nir_phi_builder.c
> index cc5ce81d120..add3efd2dfc 100644
> --- a/src/compiler/nir/nir_phi_builder.c
> +++ b/src/compiler/nir/nir_phi_builder.c
> @@ -147,7 +147,7 @@ nir_phi_builder_add_value(struct nir_phi_builder *pb,
> unsigned num_components,
>   * value to the magic value NEEDS_PHI.  Later, we create phi
> nodes
>   * on demand in nir_phi_builder_value_get_block_def().
>   */
> -val->defs[next->index] = NEEDS_PHI;
> +nir_phi_builder_value_set_block_def(val, next, NEEDS_PHI);
>
>  if (pb->work[next->index] < pb->iter_count) {
> pb->work[next->index] = pb->iter_count;
> @@ -232,7 +232,7 @@ nir_phi_builder_value_get_block_def(struct
> nir_phi_builder_value *val,
>  *  2) To avoid unneeded recreation of phi nodes and undefs.
>  */
> for (dom = block; dom && val->defs[dom->index] == NULL; dom =
> dom->imm_dom)
> -  val->defs[dom->index] = def;
> +  nir_phi_builder_value_set_block_def(val, dom, def);
>
> return def;
>  }
> --
> 2.14.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

Re: [Mesa-dev] [PATCH 03/22] nir/spirv: initial handling of OpenCL.std extension opcodes

[Karol Herbst]

On Wed, Nov 21, 2018 at 2:54 AM Jason Ekstrand  wrote:
>
> On Tue, Nov 13, 2018 at 9:48 AM Karol Herbst  wrote:
>>
>> Not complete, mostly just adding things as I encounter them in CTS. But
>> not getting far enough yet to hit most of the OpenCL.std instructions.
>>
>> Anyway, this is better than nothing and covers the most common builtins.
>>
>> Signed-off-by: Karol Herbst 
>> ---
>>  src/compiler/nir/meson.build   |   1 +
>>  src/compiler/nir/nir_builtin_builder.c | 249 +-
>>  src/compiler/nir/nir_builtin_builder.h | 150 -
>>  src/compiler/spirv/spirv_to_nir.c  |   2 +
>>  src/compiler/spirv/vtn_alu.c   |  15 ++
>>  src/compiler/spirv/vtn_glsl450.c   |   2 +-
>>  src/compiler/spirv/vtn_opencl.c| 284 +
>>  src/compiler/spirv/vtn_private.h   |   3 +
>>  8 files changed, 701 insertions(+), 5 deletions(-)
>>  create mode 100644 src/compiler/spirv/vtn_opencl.c
>>
>> diff --git a/src/compiler/nir/meson.build b/src/compiler/nir/meson.build
>> index b0c3a7feb31..00d7f56e6eb 100644
>> --- a/src/compiler/nir/meson.build
>> +++ b/src/compiler/nir/meson.build
>> @@ -206,6 +206,7 @@ files_libnir = files(
>>'../spirv/vtn_amd.c',
>>'../spirv/vtn_cfg.c',
>>'../spirv/vtn_glsl450.c',
>> +  '../spirv/vtn_opencl.c',
>>'../spirv/vtn_private.h',
>>'../spirv/vtn_subgroup.c',
>>'../spirv/vtn_variables.c',
>> diff --git a/src/compiler/nir/nir_builtin_builder.c 
>> b/src/compiler/nir/nir_builtin_builder.c
>> index 252a7691f36..e37915e92ca 100644
>> --- a/src/compiler/nir/nir_builtin_builder.c
>> +++ b/src/compiler/nir/nir_builtin_builder.c
>> @@ -21,11 +21,43 @@
>>   * IN THE SOFTWARE.
>>   */
>>
>> +#include 
>> +
>>  #include "nir.h"
>>  #include "nir_builtin_builder.h"
>>
>>  nir_ssa_def*
>> -nir_cross(nir_builder *b, nir_ssa_def *x, nir_ssa_def *y)
>> +nir_iadd_sat(nir_builder *b, nir_ssa_def *x, nir_ssa_def *y)
>
>
> For some of these, I'd rather we add NIR opcodes and some lowering code in 
> nir_opt_algebraic. Intel hardware can do them directly so I'd like to be able 
> to take advantage of that.  In particular, [iu]add_sat, [iu]sub_sat, and 
> [i]hadd.  For more information, see
>
> https://cgit.freedesktop.org/~idr/mesa/tree/docs/specs/INTEL_shader_integer_functions2.txt?h=INTEL_shader_integer_functions2
>
> We do have to do a small bit of lowering for some of them but it's way better 
> than the pile of instructions you're emitting below.
>
>>
>> +{
>> +   int64_t max;
>> +   switch (x->bit_size) {
>> +   case 64:
>> +  max = INT64_MAX;
>> +  break;
>> +   case 32:
>> +  max = INT32_MAX;
>> +  break;
>> +   case 16:
>> +  max = INT16_MAX;
>> +  break;
>> +   case  8:
>> +  max = INT8_MAX;
>> +  break;
>> +   }
>> +
>> +   nir_ssa_def *sum = nir_iadd(b, x, y);
>> +
>> +   nir_ssa_def *hi = nir_bcsel(b, nir_ilt(b, sum, x),
>> +   nir_imm_intN_t(b, max, x->bit_size), sum);
>>
>> +
>> +   nir_ssa_def *lo = nir_bcsel(b, nir_ilt(b, x, sum),
>> +   nir_imm_intN_t(b, max + 1, x->bit_size), 
>> sum);
>> +
>> +   return nir_bcsel(b, nir_ige(b, y, nir_imm_intN_t(b, 1, y->bit_size)), 
>> hi, lo);
>> +}
>> +
>> +nir_ssa_def*
>> +nir_cross3(nir_builder *b, nir_ssa_def *x, nir_ssa_def *y)
>>  {
>> unsigned yzx[3] = { 1, 2, 0 };
>> unsigned zxy[3] = { 2, 0, 1 };
>> @@ -36,6 +68,63 @@ nir_cross(nir_builder *b, nir_ssa_def *x, nir_ssa_def *y)
>>nir_swizzle(b, y, yzx, 3, true)));
>>  }
>>
>> +nir_ssa_def*
>> +nir_cross4(nir_builder *b, nir_ssa_def *x, nir_ssa_def *y)
>> +{
>> +   nir_ssa_def *cross = nir_cross3(b, x, y);
>> +
>> +   return nir_vec4(b,
>> +  nir_channel(b, cross, 0),
>> +  nir_channel(b, cross, 1),
>> +  nir_channel(b, cross, 2),
>> +  nir_imm_intN_t(b, 0, cross->bit_size));
>> +}
>> +
>> +static nir_ssa_def*
>> +nir_hadd(nir_builder *b, nir_ssa_def *x, nir_ssa_def *y, bool sign)
>
>
> We have this in hardware too. :-)
>
>>
>> +{
>> +   nir_ssa_def *imm1 = nir_imm_int(b, 1);
>> +
>> +   nir_ssa_def *t0 = nir_ixor(b, x, y);
>> +   nir_ssa_def *t1 = nir_iand(b, x, y);
>>
>> +
>> +   nir_ssa_def *t2;
>> +   if (sign)
>> +  t2 = nir_ishr(b, t0, imm1);
>> +   else
>> +  t2 = nir_ushr(b, t0, imm1);
>> +   return nir_iadd(b, t1, t2);
>
>
> This is seriously clever and needs a comment. :-)  Perhaps something like 
> this:
>
> x + y = x - (x & ~y) + (x & ~y) + y - (~x & y) + (~x & y)
>   = (x & y) + (x & ~y) + (x & y) + (~x & y)
>   = 2 * (x & y) + (x & ~y) + (~x & y)
>   = ((x & y) << 1) + (x ^ y)
>
> and, this works for any pair of N-bit numbers.  Since we know that the bottom 
> bit of (x & y) << 1 is zero,
>
> (x + y) >> 1 = (((x & y) << 1) + (x ^ y)) >> 1
>  = (x & y) + ((x ^ y) >> 1)
>
>> +}
>> +
>> +nir_ssa_def*
>> +nir_ihadd(nir_builder *b, nir_ssa_def *x, nir_ssa_def *y)
>> +{
>> +   return nir_hadd(b, x, y, true);
>> +}
>> +
>> 

Re: [Mesa-dev] [PATCH 3/7] util/slab: Add function to flush allocations from a child pool

[Ian Romanick]

On 11/21/2018 03:08 AM, Haehnle, Nicolai wrote:
> On 21.11.18 01:39, Ian Romanick wrote:
>> From: Ian Romanick 
>>
>> Ralloc has a feature that all allocations from a temporary memory
>> context can be whisked away in a single call without fear of leaks.  As
>> the slab allocator is designed for use in multhreaded scenarios with a
>> child pool per CPU, it lacks this feature.  However, many users will be
>> single threaded with a single child pool.  For these users, we can have
>> our cake and eat it too.
>>
>> Signed-off-by: Ian Romanick 
>> Cc: Nicolai Hähnle 
>> ---
>>   src/util/slab.c | 21 +
>>   src/util/slab.h |  1 +
>>   2 files changed, 22 insertions(+)
>>
>> diff --git a/src/util/slab.c b/src/util/slab.c
>> index 5f048666b56..1bcc1db6e09 100644
>> --- a/src/util/slab.c
>> +++ b/src/util/slab.c
>> @@ -172,6 +172,27 @@ void slab_destroy_child(struct slab_child_pool *pool)
>>  pool->parent = NULL;
>>   }
>>   
>> +/**
>> + * Flush all allocations from a pool.  Single-threaded (no mutex).
>> + */
>> +void
>> +slab_flush_st(struct slab_mempool *parent)
> 
> The name of the function argument should be "pool" for consistency.

This is one thing that annoyed me while writing this function.
Sometimes "pool" is a slab_mempool.  Sometimes "pool" is a
slab_child_pool.  What do you do when you have both?  For the most part,
the thing that gets the most use in a function is the thing called pool.
 In this case, that's the slab_child_pool, but that's not the parameter
passed in.

slab_alloc_st, slab_free_st, slab_create, and slab_destroy are the only
other functions that take a slab_mempool.  These functions work around
this issue by immediately calling some other public function with
>child.  I didn't want to make a public function to flush an
arbitrary slab_child_pool because that's very dangerous in the general
case.  Having a one-line public function that calls a private function
will just beg some newbie to come along and fix it... and end up with
the same problem. :)

>> +{
>> +   struct slab_child_pool *const pool = >child;
>> +
>> +   assert(pool->migrated == NULL);
>> +   assert(pool->parent == parent);
> 
> I'm surprised this works. Why isn't pool->parent == >parent?

This is just a sanity check on an invariant of the data structure.  If
the slab_mempool wasn't initialized or if it has been destroyed,
parent->child.parent will be garbage or NULL.

> Or, with a consistently named function argument, why isn't 
> pool->child.parent == >parent?
> 
> The intention of the patch looks fine though.
> 
> Cheers,
> Nicolai
> 
> 
>> +
>> +   while (pool->pages) {
>> +  struct slab_page_header *page = pool->pages;
>> +  pool->pages = page->u.next;
>> +
>> +  free(page);
>> +   }
>> +
>> +   pool->free = NULL;
>> +}
>> +
>>   static bool
>>   slab_add_new_page(struct slab_child_pool *pool)
>>   {
>> diff --git a/src/util/slab.h b/src/util/slab.h
>> index e83f8ec1a0e..a4279d8e65b 100644
>> --- a/src/util/slab.h
>> +++ b/src/util/slab.h
>> @@ -90,5 +90,6 @@ void slab_create(struct slab_mempool *pool,
>>   void slab_destroy(struct slab_mempool *pool);
>>   void *slab_alloc_st(struct slab_mempool *pool);
>>   void slab_free_st(struct slab_mempool *pool, void *ptr);
>> +void slab_flush_st(struct slab_mempool *parent);
>>   
>>   #endif
>>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] meson: Bump version to 0.46 for python module

[Dylan Baker]

From: Arfrever Frehtes Taifersar Arahesis 

Meson has two modules for finding python, the python3 module and the
python module. Python3 is older, and has some corner cases, python is
newer, has no known corner cases and can detect python2. Things have
generally seemed to work okay for us using python3, but there are cases
where things fall down (such as if you have python 3.4 as your default
python3.

Debian provides 0.48.x in buster (testing)
fedora has 0.47.x in 27 and 28
fedora has 0.48.x in 29
arch has 0.48.x

cc: matts...@gmail.com
distro-bug: https://bugs.gentoo.org/671308
Reviewed-by: Dylan Baker 
---
 docs/meson.html | 2 +-
 meson.build | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/docs/meson.html b/docs/meson.html
index 68f80d6ac42..af109d3d8b0 100644
--- a/docs/meson.html
+++ b/docs/meson.html
@@ -24,7 +24,7 @@ for production
 The meson build is tested on Linux, macOS, Cygwin and Haiku, FreeBSD,
 DragonflyBSD, NetBSD, and should work on OpenBSD.
 
-Mesa requires Meson >= 0.45.0 to build.
+Mesa requires Meson >= 0.46.0 to build.
 
 Some older versions of meson do not check that they are too old and will error
 out in odd ways.
diff --git a/meson.build b/meson.build
index 33f4e5ad3cf..ee2d1a82984 100644
--- a/meson.build
+++ b/meson.build
@@ -25,7 +25,7 @@ project(
 [find_program('python', 'python2', 'python3'), 'bin/meson_get_version.py']
   ).stdout(),
   license : 'MIT',
-  meson_version : '>= 0.45',
+  meson_version : '>= 0.46',
   default_options : ['buildtype=debugoptimized', 'b_ndebug=if-release', 
'c_std=c99', 'cpp_std=c++11']
 )
 
@@ -709,7 +709,7 @@ if with_platform_haiku
   pre_args += '-DHAVE_HAIKU_PLATFORM'
 endif
 
-prog_python = import('python3').find_python()
+prog_python = import('python').find_installation('python3')
 has_mako = run_command(
   prog_python, '-c',
   '''
-- 
2.19.1

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

Re: [Mesa-dev] [PATCH 01/21] intel/defines: Explicitly cast to uint32_t in SET_FIELD and SET_BITS

[Lionel Landwerlin]

On 17/11/2018 02:47, Jason Ekstrand wrote:

If you pass a bool in as the value to set, the C standard says that it
gets converted to an int prior to shifting.  If you try to set a bool to
bit 31, this lands you in undefined behavior.  It's better just to add
the explicit cast and let the compiler delete it for us.



I would use BITFIELD_BIT, but not a big deal.


Reviewed-by: Lionel Landwerlin 



---
  src/intel/compiler/brw_eu_defines.h | 4 ++--
  src/mesa/drivers/dri/i965/brw_defines.h | 2 +-
  2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/intel/compiler/brw_eu_defines.h 
b/src/intel/compiler/brw_eu_defines.h
index 52957882b10..025a459760c 100644
--- a/src/intel/compiler/brw_eu_defines.h
+++ b/src/intel/compiler/brw_eu_defines.h
@@ -41,14 +41,14 @@
  /* Using the GNU statement expression extension */
  #define SET_FIELD(value, field) \
 ({   \
-  uint32_t fieldval = (value) << field ## _SHIFT;   \
+  uint32_t fieldval = (uint32_t)(value) << field ## _SHIFT; \
assert((fieldval & ~ field ## _MASK) == 0);   \
fieldval & field ## _MASK;\
 })
  
  #define SET_BITS(value, high, low)  \

 ({   \
-  const uint32_t fieldval = (value) << (low);   \
+  const uint32_t fieldval = (uint32_t)(value) << (low); \
assert((fieldval & ~INTEL_MASK(high, low)) == 0); \
fieldval & INTEL_MASK(high, low); \
 })
diff --git a/src/mesa/drivers/dri/i965/brw_defines.h 
b/src/mesa/drivers/dri/i965/brw_defines.h
index 897c91aa31e..d7a41c83ee8 100644
--- a/src/mesa/drivers/dri/i965/brw_defines.h
+++ b/src/mesa/drivers/dri/i965/brw_defines.h
@@ -38,7 +38,7 @@
  /* Using the GNU statement expression extension */
  #define SET_FIELD(value, field) \
 ({   \
-  uint32_t fieldval = (value) << field ## _SHIFT;   \
+  uint32_t fieldval = (uint32_t)(value) << field ## _SHIFT; \
assert((fieldval & ~ field ## _MASK) == 0);   \
fieldval & field ## _MASK;\
 })



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

[Mesa-dev] [PATCH] st/xvmc: Add X11 include path.

[Vinson Lee]

This patch fixes this build error.

  CC   tests/xvmc_bench.o
In file included from tests/xvmc_bench.c:35:
tests/testlib.h:38:10: fatal error: 'X11/Xlib.h' file not found
 ^~~~

Signed-off-by: Vinson Lee 
---
 src/gallium/state_trackers/xvmc/Makefile.am | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/gallium/state_trackers/xvmc/Makefile.am 
b/src/gallium/state_trackers/xvmc/Makefile.am
index 85d0b5f4953d..ddb2f4b230b6 100644
--- a/src/gallium/state_trackers/xvmc/Makefile.am
+++ b/src/gallium/state_trackers/xvmc/Makefile.am
@@ -28,6 +28,7 @@ AM_CFLAGS = \
$(VISIBILITY_CFLAGS) \
$(VL_CFLAGS) \
$(XCB_DRI3_CFLAGS) \
+   $(X11_INCLUDES) \
$(XVMC_CFLAGS)
 
 noinst_LTLIBRARIES = libxvmctracker.la
-- 
2.17.1.dropbox.0

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

Re: [Mesa-dev] [PATCH] build: enable -Werror=incompatible-pointer-types

[Gert Wollny]

Am Mittwoch, den 21.11.2018, 13:14 + schrieb Emil Velikov:
> From: Emil Velikov 
> 
> More or less any issue pointed out by the compiler is an error. Make
> sure we flag and bail loudly.
> 
> Cc: Eric Engestrom 
> Signed-off-by: Emil Velikov 
> ---
> Eric, feel free to squash this with your patch.
> ---
>  Android.common.mk | 1 +
>  configure.ac  | 2 ++
>  scons/gallium.py  | 1 +
>  3 files changed, 4 insertions(+)
> 
> diff --git a/Android.common.mk b/Android.common.mk
> index aa1b266a393..4bdbf70e30b 100644
> --- a/Android.common.mk
> +++ b/Android.common.mk
> @@ -31,6 +31,7 @@ LOCAL_C_INCLUDES += \
>  
>  MESA_VERSION := $(shell cat $(MESA_TOP)/VERSION)
>  LOCAL_CFLAGS += \
> + -Werror=incompatible-pointer-types \
>   -Wno-error \
>   -Wno-unused-parameter \
>   -Wno-pointer-arith \
> diff --git a/configure.ac b/configure.ac
> index 93a52475d50..2b632cda997 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -307,6 +307,7 @@ dnl
>  AX_CHECK_COMPILE_FLAG([-
> Wall], [CFLAGS="$CFLAGS -Wall"])
>  AX_CHECK_COMPILE_FLAG([-Werror=implicit-function-declaration],
> [CFLAGS="$CFLAGS -Werror=implicit-function-declaration"])
>  AX_CHECK_COMPILE_FLAG([-Werror=missing-
> prototypes],[CFLAGS="$CFLAGS -Werror=missing-
> prototypes"])
> +AX_CHECK_COMPILE_FLAG([-Werror=incompatible-pointer-
> types],[CFLAGS="$CFLAGS -Werror=incompatible-pointer-types"])
>  AX_CHECK_COMPILE_FLAG([-Wmissing-
> prototypes],  [CFLAGS="$CFLAGS -Wmissing-
> prototypes"])
>  dnl Dylan Baker: gcc and clang always accepr -Wno-*, hence check for
> the original warning, then set the no-* flag
>  AX_CHECK_COMPILE_FLAG([-Wmissing-field-
> initializers],  [CFLAGS="$CFLAGS -Wno-missing-field-
> initializers"])
> @@ -326,6 +327,7 @@ dnl Check C++ compiler flags
>  dnl
>  AC_LANG_PUSH([C++])
>  AX_CHECK_COMPILE_FLAG([-
> Wall], [CXXFLAGS="$CXXFLAGS -Wall"])
> +AX_CHECK_COMPILE_FLAG([-Werror=incompatible-pointer-
> types],[CFXXLAGS="$CXXFLAGS -Werror=incompatible-pointer-types"])
For C++ this shoudn't be needed, because there this is already an
error. 

Cheers,
Gert

>  AX_CHECK_COMPILE_FLAG([-fno-math-
> errno],   [CXXFLAGS="$CXXFLAGS -fno-math-errno"])
>  AX_CHECK_COMPILE_FLAG([-fno-trapping-
> math],[CXXFLAGS="$CXXFLAGS -fno-trapping-math"])
>  AX_CHECK_COMPILE_FLAG([-
> fvisibility=hidden],   [VISIBILITY_CXXFLAGS="-
> fvisibility=hidden"])
> diff --git a/scons/gallium.py b/scons/gallium.py
> index 963834a5fbc..36f542d0d64 100755
> --- a/scons/gallium.py
> +++ b/scons/gallium.py
> @@ -451,6 +451,7 @@ def generate(env):
>  # - http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
>  ccflags += [
>  '-Wall',
> +'-Werror=incompatible-pointer-types'
>  '-Wno-long-long',
>  '-fmessage-length=0', # be nice to Eclipse
>  ]
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/2] winsys/amdgpu: add amdgpu_winsys_bo::lock

[Nicolai Hähnle]

From: Nicolai Hähnle 

We'll use it in the upcoming mapping change. Sparse buffers have always
had one.
---
 src/gallium/winsys/amdgpu/drm/amdgpu_bo.c | 19 +--
 src/gallium/winsys/amdgpu/drm/amdgpu_bo.h |  4 ++--
 src/gallium/winsys/amdgpu/drm/amdgpu_cs.c | 10 +-
 3 files changed, 20 insertions(+), 13 deletions(-)

diff --git a/src/gallium/winsys/amdgpu/drm/amdgpu_bo.c 
b/src/gallium/winsys/amdgpu/drm/amdgpu_bo.c
index f49fb47b80e..9f0d4c12482 100644
--- a/src/gallium/winsys/amdgpu/drm/amdgpu_bo.c
+++ b/src/gallium/winsys/amdgpu/drm/amdgpu_bo.c
@@ -196,20 +196,21 @@ void amdgpu_bo_destroy(struct pb_buffer *_buf)
   ws->allocated_gtt -= align64(bo->base.size, ws->info.gart_page_size);
 
if (bo->u.real.map_count >= 1) {
   if (bo->initial_domain & RADEON_DOMAIN_VRAM)
  ws->mapped_vram -= bo->base.size;
   else if (bo->initial_domain & RADEON_DOMAIN_GTT)
  ws->mapped_gtt -= bo->base.size;
   ws->num_mapped_buffers--;
}
 
+   simple_mtx_destroy(>lock);
FREE(bo);
 }
 
 static void amdgpu_bo_destroy_or_cache(struct pb_buffer *_buf)
 {
struct amdgpu_winsys_bo *bo = amdgpu_winsys_bo(_buf);
 
assert(bo->bo); /* slab buffers have a separate vtbl */
 
if (bo->u.real.use_reusable_pool)
@@ -461,20 +462,21 @@ static struct amdgpu_winsys_bo *amdgpu_create_bo(struct 
amdgpu_winsys *ws,
AMDGPU_VM_PAGE_EXECUTABLE;
 
if (!(flags & RADEON_FLAG_READ_ONLY))
vm_flags |= AMDGPU_VM_PAGE_WRITEABLE;
 
r = amdgpu_bo_va_op_raw(ws->dev, buf_handle, 0, size, va, vm_flags,
   AMDGPU_VA_OP_MAP);
if (r)
   goto error_va_map;
 
+   simple_mtx_init(>lock, mtx_plain);
pipe_reference_init(>base.reference, 1);
bo->base.alignment = alignment;
bo->base.usage = 0;
bo->base.size = size;
bo->base.vtbl = _winsys_bo_vtbl;
bo->ws = ws;
bo->bo = buf_handle;
bo->va = va;
bo->u.real.va_handle = va_handle;
bo->initial_domain = initial_domain;
@@ -564,20 +566,21 @@ struct pb_slab *amdgpu_bo_slab_alloc(void *priv, unsigned 
heap,
if (!slab->entries)
   goto fail_buffer;
 
LIST_INITHEAD(>base.free);
 
base_id = __sync_fetch_and_add(>next_bo_unique_id, 
slab->base.num_entries);
 
for (unsigned i = 0; i < slab->base.num_entries; ++i) {
   struct amdgpu_winsys_bo *bo = >entries[i];
 
+  simple_mtx_init(>lock, mtx_plain);
   bo->base.alignment = entry_size;
   bo->base.usage = slab->buffer->base.usage;
   bo->base.size = entry_size;
   bo->base.vtbl = _winsys_bo_slab_vtbl;
   bo->ws = ws;
   bo->va = slab->buffer->va + i * entry_size;
   bo->initial_domain = domains;
   bo->unique_id = base_id + i;
   bo->u.slab.entry.slab = >base;
   bo->u.slab.entry.group_index = group_index;
@@ -592,22 +595,24 @@ fail_buffer:
amdgpu_winsys_bo_reference(>buffer, NULL);
 fail:
FREE(slab);
return NULL;
 }
 
 void amdgpu_bo_slab_free(void *priv, struct pb_slab *pslab)
 {
struct amdgpu_slab *slab = amdgpu_slab(pslab);
 
-   for (unsigned i = 0; i < slab->base.num_entries; ++i)
+   for (unsigned i = 0; i < slab->base.num_entries; ++i) {
   amdgpu_bo_remove_fences(>entries[i]);
+  simple_mtx_destroy(>entries[i].lock);
+   }
 
FREE(slab->entries);
amdgpu_winsys_bo_reference(>buffer, NULL);
FREE(slab);
 }
 
 #if DEBUG_SPARSE_COMMITS
 static void
 sparse_dump(struct amdgpu_winsys_bo *bo, const char *func)
 {
@@ -851,22 +856,22 @@ static void amdgpu_bo_sparse_destroy(struct pb_buffer 
*_buf)
}
 
while (!list_empty(>u.sparse.backing)) {
   struct amdgpu_sparse_backing *dummy = NULL;
   sparse_free_backing_buffer(bo,
  container_of(bo->u.sparse.backing.next,
   dummy, list));
}
 
amdgpu_va_range_free(bo->u.sparse.va_handle);
-   simple_mtx_destroy(>u.sparse.commit_lock);
FREE(bo->u.sparse.commitments);
+   simple_mtx_destroy(>lock);
FREE(bo);
 }
 
 static const struct pb_vtbl amdgpu_winsys_bo_sparse_vtbl = {
amdgpu_bo_sparse_destroy
/* other functions are never called */
 };
 
 static struct pb_buffer *
 amdgpu_bo_sparse_create(struct amdgpu_winsys *ws, uint64_t size,
@@ -882,37 +887,37 @@ amdgpu_bo_sparse_create(struct amdgpu_winsys *ws, 
uint64_t size,
 * that exceed this limit. This is not really a restriction: we don't have
 * that much virtual address space anyway.
 */
if (size > (uint64_t)INT32_MAX * RADEON_SPARSE_PAGE_SIZE)
   return NULL;
 
bo = CALLOC_STRUCT(amdgpu_winsys_bo);
if (!bo)
   return NULL;
 
+   simple_mtx_init(>lock, mtx_plain);
pipe_reference_init(>base.reference, 1);
bo->base.alignment = RADEON_SPARSE_PAGE_SIZE;
bo->base.size = size;
bo->base.vtbl = _winsys_bo_sparse_vtbl;
bo->ws = ws;
bo->initial_domain = domain;
bo->unique_id =  __sync_fetch_and_add(>next_bo_unique_id, 1);
bo->sparse = true;

[Mesa-dev] [PATCH 2/2] winsys/amdgpu: explicitly declare whether buffer_map is permanent or not

[Nicolai Hähnle]

From: Nicolai Hähnle 

Introduce a new driver-private transfer flag RADEON_TRANSFER_TEMPORARY
that specifies whether the caller will use buffer_unmap or not. The
default behavior is set to permanent maps, because that's what drivers
do for Gallium buffer maps.

This should eliminate the need for hacks in libdrm. Assertions are added
to catch when the buffer_unmap calls don't match the (temporary)
buffer_map calls.

I did my best to update r600 and r300 as well for completeness (yes,
it's a no-op for r300 because it never calls buffer_unmap), even though
the radeon winsys ignores the new flag.

As an added bonus, this should actually improve the performance of
the normal fast path, because we no longer call into libdrm at all
after the first map, and there's one less atomic in the winsys itself
(there are now no atomics left in the UNSYNCHRONIZED fast path).

Cc: Leo Liu 
--
Leo, it'd be nice if you could confirm that all video buffer mappings
are temporary in this sense.
---
 src/gallium/drivers/r600/evergreen_compute.c |  4 +-
 src/gallium/drivers/r600/r600_asm.c  |  4 +-
 src/gallium/drivers/r600/r600_shader.c   |  4 +-
 src/gallium/drivers/r600/radeon_uvd.c|  8 +-
 src/gallium/drivers/r600/radeon_vce.c|  4 +-
 src/gallium/drivers/r600/radeon_video.c  |  6 +-
 src/gallium/drivers/radeon/radeon_uvd.c  | 10 ++-
 src/gallium/drivers/radeon/radeon_uvd_enc.c  |  6 +-
 src/gallium/drivers/radeon/radeon_vce.c  |  4 +-
 src/gallium/drivers/radeon/radeon_vcn_dec.c  | 18 ++--
 src/gallium/drivers/radeon/radeon_vcn_enc.c  |  4 +-
 src/gallium/drivers/radeon/radeon_video.c|  6 +-
 src/gallium/drivers/radeon/radeon_winsys.h   | 17 +++-
 src/gallium/drivers/radeonsi/si_shader.c |  3 +-
 src/gallium/include/pipe/p_defines.h |  8 +-
 src/gallium/winsys/amdgpu/drm/amdgpu_bo.c| 95 +---
 src/gallium/winsys/amdgpu/drm/amdgpu_bo.h|  3 +-
 17 files changed, 142 insertions(+), 62 deletions(-)

diff --git a/src/gallium/drivers/r600/evergreen_compute.c 
b/src/gallium/drivers/r600/evergreen_compute.c
index a77f58242e3..9085be4e2f3 100644
--- a/src/gallium/drivers/r600/evergreen_compute.c
+++ b/src/gallium/drivers/r600/evergreen_compute.c
@@ -431,21 +431,23 @@ static void *evergreen_create_compute_state(struct 
pipe_context *ctx,
COMPUTE_DBG(rctx->screen, "*** evergreen_create_compute_state\n");
header = cso->prog;
code = cso->prog + sizeof(struct pipe_llvm_program_header);
radeon_shader_binary_init(>binary);
r600_elf_read(code, header->num_bytes, >binary);
r600_create_shader(>bc, >binary, _kill);
 
/* Upload code + ROdata */
shader->code_bo = r600_compute_buffer_alloc_vram(rctx->screen,
shader->bc.ndw * 4);
-   p = r600_buffer_map_sync_with_rings(>b, shader->code_bo, 
PIPE_TRANSFER_WRITE);
+   p = r600_buffer_map_sync_with_rings(
+   >b, shader->code_bo,
+   PIPE_TRANSFER_WRITE | RADEON_TRANSFER_TEMPORARY);
//TODO: use util_memcpy_cpu_to_le32 ?
memcpy(p, shader->bc.bytecode, shader->bc.ndw * 4);
rctx->b.ws->buffer_unmap(shader->code_bo->buf);
 #endif
 
return shader;
 }
 
 static void evergreen_delete_compute_state(struct pipe_context *ctx, void 
*state)
 {
diff --git a/src/gallium/drivers/r600/r600_asm.c 
b/src/gallium/drivers/r600/r600_asm.c
index 7029be24f4b..4ba77c535f9 100644
--- a/src/gallium/drivers/r600/r600_asm.c
+++ b/src/gallium/drivers/r600/r600_asm.c
@@ -2765,21 +2765,23 @@ void *r600_create_vertex_fetch_shader(struct 
pipe_context *ctx,
 
u_suballocator_alloc(rctx->allocator_fetch_shader, fs_size, 256,
 >offset,
 (struct pipe_resource**)>buffer);
if (!shader->buffer) {
r600_bytecode_clear();
FREE(shader);
return NULL;
}
 
-   bytecode = r600_buffer_map_sync_with_rings(>b, shader->buffer, 
PIPE_TRANSFER_WRITE | PIPE_TRANSFER_UNSYNCHRONIZED);
+   bytecode = r600_buffer_map_sync_with_rings
+   (>b, shader->buffer,
+   PIPE_TRANSFER_WRITE | PIPE_TRANSFER_UNSYNCHRONIZED | 
RADEON_TRANSFER_TEMPORARY);
bytecode += shader->offset / 4;
 
if (R600_BIG_ENDIAN) {
for (i = 0; i < fs_size / 4; ++i) {
bytecode[i] = util_cpu_to_le32(bc.bytecode[i]);
}
} else {
memcpy(bytecode, bc.bytecode, fs_size);
}
rctx->b.ws->buffer_unmap(shader->buffer->buf);
diff --git a/src/gallium/drivers/r600/r600_shader.c 
b/src/gallium/drivers/r600/r600_shader.c
index 408939d1105..fc826470d69 100644
--- a/src/gallium/drivers/r600/r600_shader.c
+++ b/src/gallium/drivers/r600/r600_shader.c
@@ -134,21 +134,23 @@ static int store_shader(struct pipe_context *ctx,
 {
struct r600_context *rctx = (struct r600_context *)ctx;

[Mesa-dev] [Bug 108530] [Tracker] Mesa 18.3 Release Tracker

[bugzilla-daemon]

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

Clayton Craft  changed:

   What|Removed |Added

 Depends on||108456


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=108456
[Bug 108456] userptr deadlock in Vulkan CTS: mmu_notifier vs workers vs
struct_mutex
-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 12/18] meson: wire the new generator for es1 and es2

[Dylan Baker]

Quoting Emil Velikov (2018-11-21 04:04:09)
> From: Emil Velikov 
> 
> Signed-off-by: Emil Velikov 
> ---
>  src/mapi/es1api/meson.build| 6 +++---
>  src/mapi/es2api/meson.build| 6 +++---
>  src/mapi/glapi/gen/meson.build | 7 +++
>  src/mapi/meson.build   | 1 +
>  4 files changed, 14 insertions(+), 6 deletions(-)
> 
> diff --git a/src/mapi/es1api/meson.build b/src/mapi/es1api/meson.build
> index 53e894f091c..6c37dbb67bc 100644
> --- a/src/mapi/es1api/meson.build
> +++ b/src/mapi/es1api/meson.build
> @@ -20,10 +20,10 @@
>  
>  es1_glapi_mapi_tmp_h = custom_target(
>'es1_glapi_mapi_tmp.h',
> -  input : [mapi_abi_py, gl_and_es_api_files],
> +  input : [glapi_gen_mapi_script, glapi_gen_gl_xml],
>output : 'glapi_mapi_tmp.h',
> -  command : [prog_python, '@INPUT0@', '--printer', 'es1api', '@INPUT1@'],
> -  depend_files : api_xml_files,
> +  command : [prog_python, '@INPUT0@', 'glesv1', '@INPUT1@'],
> +  depend_files : glapi_gen_mapi_deps,
>capture : true,
>  )
>  
> diff --git a/src/mapi/es2api/meson.build b/src/mapi/es2api/meson.build
> index 1f397e2b752..3cb6a0cdeb3 100644
> --- a/src/mapi/es2api/meson.build
> +++ b/src/mapi/es2api/meson.build
> @@ -20,10 +20,10 @@
>  
>  es2_glapi_mapi_tmp_h = custom_target(
>'es2_glapi_mapi_tmp.h',
> -  input : [mapi_abi_py, gl_and_es_api_files],
> +  input : [glapi_gen_mapi_script, glapi_gen_gl_xml],
>output : 'glapi_mapi_tmp.h',
> -  command : [prog_python, '@INPUT0@', '--printer', 'es2api', '@INPUT1@'],
> -  depend_files : api_xml_files,
> +  command : [prog_python, '@INPUT0@', 'glesv2', '@INPUT1@'],
> +  depend_files : glapi_gen_mapi_deps,
>capture : true,
>  )
>  
> diff --git a/src/mapi/glapi/gen/meson.build b/src/mapi/glapi/gen/meson.build
> index f494e9707b6..fa06c7c5458 100644
> --- a/src/mapi/glapi/gen/meson.build
> +++ b/src/mapi/glapi/gen/meson.build
> @@ -18,6 +18,13 @@
>  # OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN 
> THE
>  # SOFTWARE.
>  
> +glapi_gen_gl_xml = files('../registry/gl.xml')

the gl_enum.py generate could use this as well.

> +glapi_gen_mapi_deps = [
> +  glapi_gen_gl_xml,
> +  files('../../new/genCommon.py'),
> +  glapi_gen_gl_xml,
> +]
> +
>  gl_and_es_api_files = files('gl_and_es_API.xml')
>  
>  api_xml_files = files(
> diff --git a/src/mapi/meson.build b/src/mapi/meson.build
> index 798586bfb0c..e7a6685576b 100644
> --- a/src/mapi/meson.build
> +++ b/src/mapi/meson.build
> @@ -25,6 +25,7 @@ files_mapi_util = files(
>'u_execmem.h',
>  )
>  
> +glapi_gen_mapi_script = files('new/gen_gldispatch_mapi.py')

All of the other generated scripts are "${foo}_py", can we continue to use that
format please?

>  mapi_abi_py = files('mapi_abi.py')
>  
>  subdir('glapi')
> -- 
> 2.19.1
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev


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

Re: [Mesa-dev] [PATCH 08/18] mapi/new: don't print info we don't need for ES1/ES2

[Dylan Baker]

Quoting Emil Velikov (2018-11-21 04:04:05)
> There is no need for the noop function, the public_stubs table or table
> size defines. Remove those.
> 
> Might what to look and merge this back to GLVND - from a quick look
> they don't need them either.
> 
> Signed-off-by: Emil Velikov 
> ---
>  src/mapi/new/gen_gldispatch_mapi.py | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/src/mapi/new/gen_gldispatch_mapi.py 
> b/src/mapi/new/gen_gldispatch_mapi.py
> index be7b7495909..b370559024d 100755
> --- a/src/mapi/new/gen_gldispatch_mapi.py
> +++ b/src/mapi/new/gen_gldispatch_mapi.py
> @@ -63,9 +63,10 @@ typedef void (APIENTRY  *GLDEBUGPROCKHR)(GLenum 
> source,GLenum type,GLuint id,GLe
>  """.lstrip("\n"))
>  
>  print(generate_defines(functions))
> -print(generate_table(functions, allFunctions))
> -print(generate_noop_array(functions))
> -print(generate_public_stubs(functions))
> +if (target not in ("glesv1", "glesv2")):

No parens around the condition, and use either a list or a set (not a tuple) for
the container:
if target not in {"glesv1", "glesv2"}:

tuples are for heterogenous data (that is, the position is important, and the
types are different), sets and lists are for homogenous data.

> +print(generate_table(functions, allFunctions))
> +print(generate_noop_array(functions))
> +print(generate_public_stubs(functions))
>  print(generate_public_entries(functions))
>  print(generate_stub_asm_gcc(functions))
>  
> -- 
> 2.19.1
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev


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

Re: [Mesa-dev] [PATCH 06/18] mapi/new: use the static_data offsets in the new generator

[Dylan Baker]

Quoting Emil Velikov (2018-11-21 04:04:03)
> From: Emil Velikov 
> 
> Otherwise the incorrect ones will be used, effecitvely breaking the ABI.
> 
> Note: some entries in static_data.py list a suffixed API, while (for ES*
> at least) we expect the one w/o suffix.
> 
> Signed-off-by: Emil Velikov 
> ---
>  src/mapi/new/genCommon.py | 30 +-
>  1 file changed, 29 insertions(+), 1 deletion(-)
> 
> diff --git a/src/mapi/new/genCommon.py b/src/mapi/new/genCommon.py
> index ee3c468479d..4152ccab3f4 100644
> --- a/src/mapi/new/genCommon.py
> +++ b/src/mapi/new/genCommon.py
> @@ -30,6 +30,11 @@ import collections
>  import re
>  import xml.etree.cElementTree as etree
>  
> +import os
> +GLAPI = os.path.join(os.path.dirname(sys.argv[0]), "..", "glapi/gen")

you should use __file__ instead of sys.argv[0], also don't hardcode '/' into
there, join 'glapi' and 'gen' for windows

> +sys.path.append(GLAPI)

also, use sys.path.insert(0, GLAPI), as python looks through paths in order, and
insert is always faster.

> +import static_data
> +
>  MAPI_TABLE_NUM_DYNAMIC = 4096
>  
>  _LIBRARY_FEATURE_NAMES = {
> @@ -71,8 +76,31 @@ def getFunctionsFromRoots(roots):
>  # Assign a slot number to each function. This isn't strictly necessary,
>  # since you can just look at the index in the list, but it makes it 
> easier
>  # to include the slot when formatting output.
> +
> +next_slot = 0
>  for i in range(len(functions)):
> -functions[i] = functions[i]._replace(slot=i)
> +name = functions[i].name[2:]
> +slot_set = False
> +
> +if name in static_data.offsets:
> +functions[i] = 
> functions[i]._replace(slot=static_data.offsets[name])
> +slot_set = True
> +
> +if slot_set == False and name[-3:] != "ARB":

use 'is' with singletons like True, False, and None instead '=='. You might also
consider using .startswith() and .endswith(), as they're clearer than random
subslice.

Dylan

> +lname = name + "ARB"
> +if lname in static_data.offsets:
> +functions[i] = 
> functions[i]._replace(slot=static_data.offsets[lname])
> +slot_set = True
> +
> +if slot_set == False and name[-3:] != "EXT":
> +lname = name + "EXT"
> +if lname in static_data.offsets:
> +functions[i] = 
> functions[i]._replace(slot=static_data.offsets[lname])
> +slot_set = True
> +
> +if slot_set == False:
> +functions[i] = functions[i]._replace(slot=next_slot)
> +next_slot += 1
>  
>  # Sort the function list by slot to simplify the diff
>  functions = sorted(functions, key=lambda f: f.slot)
> -- 
> 2.19.1
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev


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

Re: [Mesa-dev] [PATCH 1.5/2] ac/surface/gfx9: let addrlib choose the preferred swizzle kind

[Gustaw Smolarczyk]

śr., 21 lis 2018 o 16:21 Nicolai Hähnle  napisał(a):
>
> From: Nicolai Hähnle 
>
> Our choices here are simply redundant as long as sin.flags is set
> correctly.
> --
> This is the change I was talking about.
> ---
>  src/amd/common/ac_surface.c | 10 --
>  1 file changed, 10 deletions(-)
>
> diff --git a/src/amd/common/ac_surface.c b/src/amd/common/ac_surface.c
> index edd710a968c..ad2cb585c9d 100644
> --- a/src/amd/common/ac_surface.c
> +++ b/src/amd/common/ac_surface.c
> @@ -1057,30 +1057,20 @@ gfx9_get_preferred_swizzle_mode(ADDR_HANDLE addrlib,
> sin.forbiddenBlock.var = 1; /* don't allow the variable-sized swizzle 
> modes */
> sin.forbiddenBlock.linear = 1; /* don't allow linear swizzle modes */
> sin.bpp = in->bpp;
> sin.width = in->width;
> sin.height = in->height;
> sin.numSlices = in->numSlices;
> sin.numMipLevels = in->numMipLevels;
> sin.numSamples = in->numSamples;
> sin.numFrags = in->numFrags;
>
> -   if (flags & RADEON_SURF_SCANOUT) {

Isn't the `flags' function argument now unused?

Regards,
Gustaw Smolarczyk

> -   sin.preferredSwSet.sw_D = 1;
> -   /* Raven only allows S for displayable surfaces with < 64 
> bpp, so
> -* allow it as fallback */
> -   sin.preferredSwSet.sw_S = 1;
> -   } else if (in->flags.depth || in->flags.stencil || is_fmask)
> -   sin.preferredSwSet.sw_Z = 1;
> -   else
> -   sin.preferredSwSet.sw_S = 1;
> -
> if (is_fmask) {
> sin.flags.display = 0;
> sin.flags.color = 0;
> sin.flags.fmask = 1;
> }
>
> ret = Addr2GetPreferredSurfaceSetting(addrlib, , );
> if (ret != ADDR_OK)
> return ret;
>
> --
> 2.19.1
>
> ___
> 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 04/18] mapi/new: import mapi scripts from glvnd

[Emil Velikov]

On 2018/11/21, Kyle Brenneman wrote:
> On 11/21/2018 05:04 AM, Emil Velikov wrote:
> > From: Emil Velikov 
> > 
> > Currently we have over 20 scripts that generate the libGL* dispatch and
> > various other functionality. More importantly we're using local XML
> > files instead of the Khronos provides one(s). Resulting in an
> > increasing complexity of writing, maintaining and bugfixing.
> > 
> > One fairly annoying bug is handling of statically exported symbols.
> > Today, if we enable a GL extension for GLES1/2, we add a special tag to
> > the xml. Thus the ES dispatch gets generated, but also since we have no
> > separate notion of GL/ES1/ES2 static functions it also gets exported
> > statically.
> > 
> > This commit adds step one towards clearing and simplifying our setup.
> > It imports the mapi generator from GLVND.
> > 
> >012fe39 ("Remove a couple of duplicate typedefs.")
> > 
> > Signed-off-by: Emil Velikov 
> > ---
> >   src/mapi/Makefile.am|   2 +
> >   src/mapi/new/genCommon.py   | 223 
> >   src/mapi/new/gen_gldispatch_mapi.py | 180 ++
> >   3 files changed, 405 insertions(+)
> >   create mode 100644 src/mapi/new/genCommon.py
> >   create mode 100755 src/mapi/new/gen_gldispatch_mapi.py
> > 
> > diff --git a/src/mapi/Makefile.am b/src/mapi/Makefile.am
> > index 97ebdeb1d7f..5a619bf049b 100644
> > --- a/src/mapi/Makefile.am
> > +++ b/src/mapi/Makefile.am
> > @@ -31,6 +31,8 @@ pkgconfigdir = $(libdir)/pkgconfig
> >   pkgconfig_DATA =
> >   EXTRA_DIST = \
> > +   new/genCommon.py \
> > +   new/gen_gldispatch_mapi.py \
> > es1api/ABI-check \
> > es2api/ABI-check \
> > mapi_abi.py \
> > diff --git a/src/mapi/new/genCommon.py b/src/mapi/new/genCommon.py
> > new file mode 100644
> > index 000..5c721acbaca
> > --- /dev/null
> > +++ b/src/mapi/new/genCommon.py
> > @@ -0,0 +1,223 @@
> > +#!/usr/bin/env python
> > +
> > +# (C) Copyright 2015, NVIDIA CORPORATION.
> > +# All Rights Reserved.
> > +#
> > +# Permission is hereby granted, free of charge, to any person obtaining a
> > +# copy of this software and associated documentation files (the 
> > "Software"),
> > +# to deal in the Software without restriction, including without limitation
> > +# on the rights to use, copy, modify, merge, publish, distribute, sub
> > +# license, and/or sell copies of the Software, and to permit persons to 
> > whom
> > +# the Software is furnished to do so, subject to the following conditions:
> > +#
> > +# The above copyright notice and this permission notice (including the next
> > +# paragraph) shall be included in all copies or substantial portions of the
> > +# Software.
> > +#
> > +# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS 
> > OR
> > +# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> > +# FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT.  IN NO EVENT SHALL
> > +# IBM AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> > +# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> > +# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER 
> > DEALINGS
> > +# IN THE SOFTWARE.
> > +#
> > +# Authors:
> > +#Kyle Brenneman 
> > +
> > +import sys
> > +import collections
> > +import re
> > +import xml.etree.cElementTree as etree
> > +
> > +MAPI_TABLE_NUM_DYNAMIC = 4096
> > +
> > +_LIBRARY_FEATURE_NAMES = {
> > +# libGL and libGLdiapatch both include every function.
> > +"gl" : None,
> > +"gldispatch" : None,
> > +"opengl" : frozenset(( "GL_VERSION_1_0", "GL_VERSION_1_1",
> > +"GL_VERSION_1_2", "GL_VERSION_1_3", "GL_VERSION_1_4", 
> > "GL_VERSION_1_5",
> > +"GL_VERSION_2_0", "GL_VERSION_2_1", "GL_VERSION_3_0", 
> > "GL_VERSION_3_1",
> > +"GL_VERSION_3_2", "GL_VERSION_3_3", "GL_VERSION_4_0", 
> > "GL_VERSION_4_1",
> > +"GL_VERSION_4_2", "GL_VERSION_4_3", "GL_VERSION_4_4", 
> > "GL_VERSION_4_5",
> > +)),
> > +"glesv1" : frozenset(("GL_VERSION_ES_CM_1_0", 
> > "GL_OES_point_size_array")),
> > +"glesv2" : frozenset(("GL_ES_VERSION_2_0", "GL_ES_VERSION_3_0",
> > +"GL_ES_VERSION_3_1", "GL_ES_VERSION_3_2",
> > +)),
> > +}
> > +
> > +def getFunctions(xmlFiles):
> > +"""
> > +Reads an XML file and returns all of the functions defined in it.
> > +
> > +xmlFile should be the path to Khronos's gl.xml file. The return value 
> > is a
> > +sequence of FunctionDesc objects, ordered by slot number.
> > +"""
> > +roots = [ etree.parse(xmlFile).getroot() for xmlFile in xmlFiles ]
> > +return getFunctionsFromRoots(roots)
> > +
> > +def getFunctionsFromRoots(roots):
> > +functions = {}
> > +for root in roots:
> > +for func in _getFunctionList(root):
> > +functions[func.name] = func
> > +functions = functions.values()
> > +
> > +# Sort the function list by name.
> > +functions = sorted(functions, 

[Mesa-dev] [PATCH 1.5/2] ac/surface/gfx9: let addrlib choose the preferred swizzle kind

[Nicolai Hähnle]

From: Nicolai Hähnle 

Our choices here are simply redundant as long as sin.flags is set
correctly.
--
This is the change I was talking about.
---
 src/amd/common/ac_surface.c | 10 --
 1 file changed, 10 deletions(-)

diff --git a/src/amd/common/ac_surface.c b/src/amd/common/ac_surface.c
index edd710a968c..ad2cb585c9d 100644
--- a/src/amd/common/ac_surface.c
+++ b/src/amd/common/ac_surface.c
@@ -1057,30 +1057,20 @@ gfx9_get_preferred_swizzle_mode(ADDR_HANDLE addrlib,
sin.forbiddenBlock.var = 1; /* don't allow the variable-sized swizzle 
modes */
sin.forbiddenBlock.linear = 1; /* don't allow linear swizzle modes */
sin.bpp = in->bpp;
sin.width = in->width;
sin.height = in->height;
sin.numSlices = in->numSlices;
sin.numMipLevels = in->numMipLevels;
sin.numSamples = in->numSamples;
sin.numFrags = in->numFrags;
 
-   if (flags & RADEON_SURF_SCANOUT) {
-   sin.preferredSwSet.sw_D = 1;
-   /* Raven only allows S for displayable surfaces with < 64 bpp, 
so
-* allow it as fallback */
-   sin.preferredSwSet.sw_S = 1;
-   } else if (in->flags.depth || in->flags.stencil || is_fmask)
-   sin.preferredSwSet.sw_Z = 1;
-   else
-   sin.preferredSwSet.sw_S = 1;
-
if (is_fmask) {
sin.flags.display = 0;
sin.flags.color = 0;
sin.flags.fmask = 1;
}
 
ret = Addr2GetPreferredSurfaceSetting(addrlib, , );
if (ret != ADDR_OK)
return ret;
 
-- 
2.19.1

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

Re: [Mesa-dev] [PATCH 2/2] amd/addrlib: update Mesa's copy of addrlib

[Nicolai Hähnle]

On 20.11.18 07:46, Marek Olšák wrote:
On Tue, Nov 20, 2018 at 12:08 AM Dave Airlie > wrote:


On Tue, 20 Nov 2018 at 14:42, Marek Olšák mailto:mar...@gmail.com>> wrote:
 >
 > On Mon, Nov 19, 2018 at 7:15 PM Bas Nieuwenhuizen
mailto:b...@basnieuwenhuizen.nl>> wrote:
 >>
 >> So I tried to test this with radv and got a bunch of crashes in CTS,
 >> mostly around 3d image support:
 >>
 >> #3  0x771a9396 in __assert_fail () from /usr/lib/libc.so.6
 >> #4  0x769da3b4 in
 >> Addr::V2::Gfx9Lib::HwlGetPreferredSurfaceSetting
(this=0x57661b30,
 >> pIn=0x7fffd5f0, pOut=0x7fffd5d0)
 >>     at ../mesa/src/amd/addrlib/src/gfx9/gfx9addrlib.cpp:3684
 >> #5  0x769cf331 in
 >> Addr::V2::Lib::Addr2GetPreferredSurfaceSetting (this=0x57661b30,
 >> pIn=0x7fffd5f0, pOut=0x7fffd5d0)
 >>     at ../mesa/src/amd/addrlib/src/core/addrlib2.cpp:1742
 >> #6  0x769c4e87 in Addr2GetPreferredSurfaceSetting
 >> (hLib=0x57661b30, pIn=0x7fffd5f0, pOut=0x7fffd5d0)
 >>     at ../mesa/src/amd/addrlib/src/addrinterface.cpp:1697
 >> #7  0x769bf8d4 in gfx9_get_preferred_swizzle_mode
 >> (addrlib=0x57661b30, in=0x7fffd690, is_fmask=false,
 >> flags=33555202, swizzle_mode=0x7fffd698)
 >>
 >> It seems to be caused by the explicit swizzle mode override that
we do with
 >>
 >> commit b64b7125586ce48232658cd860f549a6139b6ddd
 >> Author: Marek Olšák mailto:marek.ol...@amd.com>>
 >> Date:   Mon Apr 2 12:54:52 2018 -0400
 >>
 >>     ac/surface/gfx9: request desired micro tile mode explicitly
 >>
 >>     Tested-by: Dieter Nützel mailto:die...@nuetzel-hh.de>>
 >>
 >>
 >> Since we never got a reason to have it (the commit message above is
 >> not descriptive and the patch not reviewed) and this is the second
 >> time already that this breaks stuff (The other was allowing S tiling
 >> for raven displayable surfaces, per 7eff8d7d3564), maybe revert
it and
 >> let addrlib make the decision?
 >
 >
 > Yes, my commits are mostly unreviewed. It's the norm now. Willing
reviewers don't exist anymore. I don't really mind that my patches
are not reviewed, but whoever complains that I push unreviewed
commits should ask himself why he didn't review them in their review
period. That applies to everybody. Either review regularly or accept
that unreviewed commits are normal.
 >
 > Secondly, past commits can't break future commits, so don't say
it breaks stuff again. It's illogical.
 >
 > There may be multiple reasons why the commit exists. As long as
reverting it doesn't break piglit / radeonsi, I'm OK with the reverting.

Marek,

There is no way anybody could review this commit, the commit log
contains 0 information on why or what the commit is doing or what it
fixes, there is nothing to say what the reviewer is looking out for.


It's something you could have mentioned on the review though. Instead 
you decided to be silent. I'm not blaming you. I understand that you 
probably had no time to review radv-related patches at that time. There 
however has to be some reviewer if you care about the long-term outcome 
whether you personally have time or not. 0 information is not an excuse 
not to review. Had there been any explanation in the commit, it wouldn't 
have made any difference on the current situation, other than perhaps 
preventing this pointless discussion that doesn't help anybody.


Well, the difference is that it might make it easier to figure out what 
the right fix (whatever you want to call it) is now given the addrlib 
change.


The funny thing is, I actually ran into exactly this issue while working 
on an internal branch, and my conclusion then was that it's probably the 
right thing to just get rid of the preferred set. I do need to put that 
through proper testing.


Cheers,
Nicolai





Marek


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

Re: [Mesa-dev] [PATCH 04/18] mapi/new: import mapi scripts from glvnd

[Kyle Brenneman]

On 11/21/2018 05:04 AM, Emil Velikov wrote:

From: Emil Velikov 

Currently we have over 20 scripts that generate the libGL* dispatch and
various other functionality. More importantly we're using local XML
files instead of the Khronos provides one(s). Resulting in an
increasing complexity of writing, maintaining and bugfixing.

One fairly annoying bug is handling of statically exported symbols.
Today, if we enable a GL extension for GLES1/2, we add a special tag to
the xml. Thus the ES dispatch gets generated, but also since we have no
separate notion of GL/ES1/ES2 static functions it also gets exported
statically.

This commit adds step one towards clearing and simplifying our setup.
It imports the mapi generator from GLVND.

   012fe39 ("Remove a couple of duplicate typedefs.")

Signed-off-by: Emil Velikov 
---
  src/mapi/Makefile.am|   2 +
  src/mapi/new/genCommon.py   | 223 
  src/mapi/new/gen_gldispatch_mapi.py | 180 ++
  3 files changed, 405 insertions(+)
  create mode 100644 src/mapi/new/genCommon.py
  create mode 100755 src/mapi/new/gen_gldispatch_mapi.py

diff --git a/src/mapi/Makefile.am b/src/mapi/Makefile.am
index 97ebdeb1d7f..5a619bf049b 100644
--- a/src/mapi/Makefile.am
+++ b/src/mapi/Makefile.am
@@ -31,6 +31,8 @@ pkgconfigdir = $(libdir)/pkgconfig
  pkgconfig_DATA =
  
  EXTRA_DIST = \

+   new/genCommon.py \
+   new/gen_gldispatch_mapi.py \
es1api/ABI-check \
es2api/ABI-check \
mapi_abi.py \
diff --git a/src/mapi/new/genCommon.py b/src/mapi/new/genCommon.py
new file mode 100644
index 000..5c721acbaca
--- /dev/null
+++ b/src/mapi/new/genCommon.py
@@ -0,0 +1,223 @@
+#!/usr/bin/env python
+
+# (C) Copyright 2015, NVIDIA CORPORATION.
+# All Rights Reserved.
+#
+# Permission is hereby granted, free of charge, to any person obtaining a
+# copy of this software and associated documentation files (the "Software"),
+# to deal in the Software without restriction, including without limitation
+# on the rights to use, copy, modify, merge, publish, distribute, sub
+# license, and/or sell copies of the Software, and to permit persons to whom
+# the Software is furnished to do so, subject to the following conditions:
+#
+# The above copyright notice and this permission notice (including the next
+# paragraph) shall be included in all copies or substantial portions of the
+# Software.
+#
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT.  IN NO EVENT SHALL
+# IBM AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+# IN THE SOFTWARE.
+#
+# Authors:
+#Kyle Brenneman 
+
+import sys
+import collections
+import re
+import xml.etree.cElementTree as etree
+
+MAPI_TABLE_NUM_DYNAMIC = 4096
+
+_LIBRARY_FEATURE_NAMES = {
+# libGL and libGLdiapatch both include every function.
+"gl" : None,
+"gldispatch" : None,
+"opengl" : frozenset(( "GL_VERSION_1_0", "GL_VERSION_1_1",
+"GL_VERSION_1_2", "GL_VERSION_1_3", "GL_VERSION_1_4", "GL_VERSION_1_5",
+"GL_VERSION_2_0", "GL_VERSION_2_1", "GL_VERSION_3_0", "GL_VERSION_3_1",
+"GL_VERSION_3_2", "GL_VERSION_3_3", "GL_VERSION_4_0", "GL_VERSION_4_1",
+"GL_VERSION_4_2", "GL_VERSION_4_3", "GL_VERSION_4_4", "GL_VERSION_4_5",
+)),
+"glesv1" : frozenset(("GL_VERSION_ES_CM_1_0", "GL_OES_point_size_array")),
+"glesv2" : frozenset(("GL_ES_VERSION_2_0", "GL_ES_VERSION_3_0",
+"GL_ES_VERSION_3_1", "GL_ES_VERSION_3_2",
+)),
+}
+
+def getFunctions(xmlFiles):
+"""
+Reads an XML file and returns all of the functions defined in it.
+
+xmlFile should be the path to Khronos's gl.xml file. The return value is a
+sequence of FunctionDesc objects, ordered by slot number.
+"""
+roots = [ etree.parse(xmlFile).getroot() for xmlFile in xmlFiles ]
+return getFunctionsFromRoots(roots)
+
+def getFunctionsFromRoots(roots):
+functions = {}
+for root in roots:
+for func in _getFunctionList(root):
+functions[func.name] = func
+functions = functions.values()
+
+# Sort the function list by name.
+functions = sorted(functions, key=lambda f: f.name)
+
+# Assign a slot number to each function. This isn't strictly necessary,
+# since you can just look at the index in the list, but it makes it easier
+# to include the slot when formatting output.
+for i in range(len(functions)):
+functions[i] = functions[i]._replace(slot=i)
+
+return functions
+
+def getExportNamesFromRoots(target, roots):
+"""
+Goes through the  tags from gl.xml and returns a set of OpenGL
+functions that a library should export.
+
+   

Re: [Mesa-dev] [PATCH mesa 00/13] Make standard function available on non-standard platforms

[Emil Velikov]

On 2018/11/20, Eric Engestrom wrote:
> ... instead of making standard platforms use non-standard functions.
> 
> This also reduces the likelihood of someone forgetting to use the
> non-standard function, and reduces the fix to a simple #include.
> 
Yes, please.

One could take thing a step further, as pointed in the individual
patches. Although that can be done at a later stage.

I take it that AppVeyor is happy with this series? If so, for the lot
Reviewed-by: Emil Velikov 

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

[Mesa-dev] [Bug 108823] [Bisected]. Autotools. Installing mesa fails with error "error: relink 'libEGL.la' with the above command before installing it"

[bugzilla-daemon]

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

Denis  changed:

   What|Removed |Added

Summary|[Bisected]. Installing mesa |[Bisected]. Autotools.
   |fails with error "error:|Installing mesa fails with
   |relink 'libEGL.la' with the |error "error: relink
   |above command before|'libEGL.la' with the above
   |installing it"  |command before installing
   ||it"

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

[Mesa-dev] [Bug 108823] [Bisected]. Installing mesa fails with error "error: relink 'libEGL.la' with the above command before installing it"

[bugzilla-daemon]

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

Bug ID: 108823
   Summary: [Bisected]. Installing mesa fails with error "error:
relink 'libEGL.la' with the above command before
installing it"
   Product: Mesa
   Version: git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Other
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: denys.kos...@globallogic.com
QA Contact: mesa-dev@lists.freedesktop.org

Hi. I remember that building via autotools is not a priority but I guess, it
still should work.
Here is a command for configuring:
>./autogen.sh --with-gallium-drivers="" --with-dri-drivers=i965 
>--prefix=/home/den/mesa64/mesa_19.0.0last/

For me it was broken after this commit:

den@den-HP-ZBook-14u-G4:~/repositories/mesa$ git bisect
bad621b0fa8922ade0a8122b868177308e65e6d3595 is the first bad commit
commit 621b0fa8922ade0a8122b868177308e65e6d3595
Author: Eric Anholt 
Date:   Mon Oct 29 09:28:00 2018 -0700

egl: Improve the debugging of gbm format matching in DRI configs.

Previously the debug would be:

libEGL debug: No DRI config supports native format 0x20203852
libEGL debug: No DRI config supports native format 0x38385247

but

libEGL debug: No DRI config supports native format R8
libEGL debug: No DRI config supports native format GR88

is a lot easier to understand.

Reviewed-by: Eric Engestrom 
Reviewed-by: Daniel Stone 

:04 04 50d5e1cbd57b488d0e24fd86787c611bf58bd588
38f4b556496b2f14dcd382f55cfc3eb5fabe18d1 M  src


Haven't any ideas, what went wrong with this commit, but after it I can build
mesa, but can't install (error below):


/home/den/repositories/mesa/src/egl/drivers/dri2/platform_drm.c:668: undefined
reference to `gbm_format_get_name'
collect2: error: ld returned 1 exit status
libtool:   error: error: relink 'libEGL.la' with the above command before
installing it
Makefile:1030: recipe for target 'install-libLTLIBRARIES' failed
make[5]: *** [install-libLTLIBRARIES] Error 1


upd - with meson build works fine.
uupd - my configuration:
ubuntu 16.04
gcc (Ubuntu 5.4.0-6ubuntu1~16.04.10) 5.4.0 20160609
GNU ld (GNU Binutils for Ubuntu) 2.26.1
kernel 4.17.0-041700-generic

Interesting that on another 16.04 ubuntu build/install works fine. Similar
issue was written in related bug (for vulkan).

Appreciate any help or suggestions.

-- 
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 mesa 13/13] util: use standard name for vsnprintf()

[Emil Velikov]

On 2018/11/20, Eric Engestrom wrote:

> @@ -65,6 +65,7 @@ util_strchrnul(const char *s, char c)
>  
>  #ifdef _WIN32
>  
> +#define vsnprintf util_vsnprintf
>  static inline int
>  util_vsnprintf(char *str, size_t size, const char *format, va_list ap)

Analogous to previous patch, MSVC seems to be compliant?

 "Beginning with the UCRT in Visual Studio 2015 and Windows 10,
  vsnprintf is no longer identical to _vsnprintf. The vsnprintf function
  complies with the C99 standard; "

HTH
Emil

[1] 
https://docs.microsoft.com/en-gb/cpp/c-runtime-library/reference/vsnprintf-vsnprintf-vsnprintf-l-vsnwprintf-vsnwprintf-l?view=vs-2017
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH mesa 12/13] util: use standard name for snprintf()

[Emil Velikov]

On 2018/11/20, Eric Engestrom wrote:

> +#define snprintf util_snprintf
>  static inline int
> PRINTFLIKE(3, 4)
>  util_snprintf(char *str, size_t size, const char *format, ...)

From the docs[1]:

 "Beginning with the UCRT in Visual Studio 2015 and Windows 10, snprintf is no 
longer
  identical to _snprintf. The snprintf function behavior is now C99 standard 
compliant."


We already require MSVC 2017, although not sure if how well we go for "and 
Windows 10"

HTH
Emil

[1] 
https://docs.microsoft.com/en-gb/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=vs-2017
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH mesa 09/13] util: use standard name for sprintf()

[Emil Velikov]

On 2018/11/20, Eric Engestrom wrote:

>  static inline void
> PRINTFLIKE(2, 3)
>  util_sprintf(char *str, const char *format, ...)


The docs [1] seem pretty clear that:
 a) overlap results in undefined behaviour, and
 b) the function returns the correct value

HTH
Emil

[1] 
https://docs.microsoft.com/en-gb/cpp/c-runtime-library/reference/sprintf-sprintf-l-swprintf-swprintf-l-swprintf-l?view=vs-2017

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

Re: [Mesa-dev] [PATCH mesa 08/13] util: use standard name for strchr()

[Emil Velikov]

On 2018/11/20, Eric Engestrom wrote:
> +++ b/src/util/u_string.h
> @@ -131,6 +131,7 @@ util_vasprintf(char **ret, const char *format, va_list ap)
> return util_vsnprintf(*ret, r + 1, format, ap);
>  }
>  
> +#define strchr util_strchr
>  static inline char *
>  util_strchr(const char *s, char c)
>  {
Drop the helper - MSVC seems ISO compliant.

HTH
Emil

[1] 
https://docs.microsoft.com/en-gb/cpp/c-runtime-library/reference/strchr-wcschr-mbschr-mbschr-l?view=vs-2017

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

Re: [Mesa-dev] [PATCH mesa 07/13] util: use standard name for strcmp()

[Emil Velikov]

On 2018/11/20, Eric Engestrom wrote:

> --- a/src/util/u_string.h
> +++ b/src/util/u_string.h
> @@ -154,6 +154,7 @@ util_strncat(char *dst, const char *src, size_t n)
> return dst;
>  }
>  
> +#define strcmp util_strcmp
>  static inline int
>  util_strcmp(const char *s1, const char *s2)
>  {
Drop the helper? API seems ISO conformant.

HTH
Emil

[1] 
https://docs.microsoft.com/en-gb/cpp/c-runtime-library/reference/strcmp-wcscmp-mbscmp?view=vs-2017

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

Re: [Mesa-dev] [PATCH mesa 06/13] util: use standard name for strncmp()

[Emil Velikov]

On 2018/11/20, Eric Engestrom wrote:
> Signed-off-by: Eric Engestrom 
> ---
>  src/gallium/auxiliary/hud/hud_context.c | 2 +-
>  src/util/u_string.h | 4 ++--
>  2 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/src/gallium/auxiliary/hud/hud_context.c 
> b/src/gallium/auxiliary/hud/hud_context.c
> index 9f9db850a71dbdbfe6eb..e7e99944993ad8ffaf32 100644
> --- a/src/gallium/auxiliary/hud/hud_context.c
> +++ b/src/gallium/auxiliary/hud/hud_context.c
> @@ -1195,7 +1195,7 @@ hud_parse_env_var(struct hud_context *hud, struct 
> pipe_screen *screen,
> boolean sort_items = false;
> const char *period_env;
>  
> -   if (util_strncmp(env, "simple,", 7) == 0) {
> +   if (strncmp(env, "simple,", 7) == 0) {
>hud->simple = true;
>env += 7;
> }
> diff --git a/src/util/u_string.h b/src/util/u_string.h
> index 82c340663b757fcfb3d8..d730412e3b287a38686f 100644
> --- a/src/util/u_string.h
> +++ b/src/util/u_string.h
> @@ -170,6 +170,7 @@ util_strcmp(const char *s1, const char *s2)
> return 0;
>  }
>  
> +#define strncmp util_strncmp
>  static inline int
>  util_strncmp(const char *s1, const char *s2, size_t n)
>  {
Analogous to the other comments - think we can drop the helper.

HTH
Emil

[1] 
https://docs.microsoft.com/en-gb/cpp/c-runtime-library/reference/strncmp-wcsncmp-mbsncmp-mbsncmp-l?view=vs-2017
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH mesa 05/13] util: use standard name for strncat()

[Emil Velikov]

On 2018/11/20, Eric Engestrom wrote:
> Signed-off-by: Eric Engestrom 
> ---
>  src/gallium/auxiliary/gallivm/lp_bld_printf.c | 6 +++---
>  src/util/u_debug.c| 8 
>  src/util/u_string.h   | 2 +-
>  3 files changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/src/gallium/auxiliary/gallivm/lp_bld_printf.c 
> b/src/gallium/auxiliary/gallivm/lp_bld_printf.c
> index 53c4d3cde41e4677abdb..cf58c3b1eaa8d6152c17 100644
> --- a/src/gallium/auxiliary/gallivm/lp_bld_printf.c
> +++ b/src/gallium/auxiliary/gallivm/lp_bld_printf.c
> @@ -126,12 +126,12 @@ lp_build_print_value(struct gallivm_state *gallivm,
>  
> params[1] = lp_build_const_string(gallivm, msg);
> if (length == 1) {
> -  util_strncat(format, type_fmt, sizeof(format) - strlen(format) - 1);
> +  strncat(format, type_fmt, sizeof(format) - strlen(format) - 1);
>params[2] = value;
> } else {
>for (i = 0; i < length; ++i) {
>   LLVMValueRef param;
> - util_strncat(format, type_fmt, sizeof(format) - strlen(format) - 1);
> + strncat(format, type_fmt, sizeof(format) - strlen(format) - 1);
>   param = LLVMBuildExtractElement(builder, value, 
> lp_build_const_int32(gallivm, i), "");
>   if (type_kind == LLVMIntegerTypeKind &&
>   LLVMGetIntTypeWidth(type_ref) < sizeof(int) * 8) {
> @@ -146,7 +146,7 @@ lp_build_print_value(struct gallivm_state *gallivm,
>}
> }
>  
> -   util_strncat(format, "\n", sizeof(format) - strlen(format) - 1);
> +   strncat(format, "\n", sizeof(format) - strlen(format) - 1);
>  
> params[0] = lp_build_const_string(gallivm, format);
> return lp_build_print_args(gallivm, 2 + length, params);
> diff --git a/src/util/u_debug.c b/src/util/u_debug.c
> index f6ed0138c1faf94ed399..787d6c255ebbd382d4c9 100644
> --- a/src/util/u_debug.c
> +++ b/src/util/u_debug.c
> @@ -371,10 +371,10 @@ debug_dump_flags(const struct debug_named_value *names, 
> unsigned long value)
> while (names->name) {
>if ((names->value & value) == names->value) {
>if (!first)
> - util_strncat(output, "|", sizeof(output) - strlen(output) - 1);
> + strncat(output, "|", sizeof(output) - strlen(output) - 1);
>else
>   first = 0;
> -  util_strncat(output, names->name, sizeof(output) - strlen(output) - 1);
> +  strncat(output, names->name, sizeof(output) - strlen(output) - 1);
>output[sizeof(output) - 1] = '\0';
>value &= ~names->value;
>}
> @@ -383,12 +383,12 @@ debug_dump_flags(const struct debug_named_value *names, 
> unsigned long value)
>  
> if (value) {
>if (!first)
> -  util_strncat(output, "|", sizeof(output) - strlen(output) - 1);
> +  strncat(output, "|", sizeof(output) - strlen(output) - 1);
>else
>first = 0;
>  
>util_snprintf(rest, sizeof(rest), "0x%08lx", value);
> -  util_strncat(output, rest, sizeof(output) - strlen(output) - 1);
> +  strncat(output, rest, sizeof(output) - strlen(output) - 1);
>output[sizeof(output) - 1] = '\0';
> }
>  
> diff --git a/src/util/u_string.h b/src/util/u_string.h
> index 94080e540d66b9fd8381..82c340663b757fcfb3d8 100644
> --- a/src/util/u_string.h
> +++ b/src/util/u_string.h
> @@ -139,6 +139,7 @@ util_strchr(const char *s, char c)
> return *p ? p : NULL;
>  }
>  
> +#define strncat util_strncat
>  static inline char*
>  util_strncat(char *dst, const char *src, size_t n)
>  {
AFAICT the MSVC 2017 strncat [1] is identical to the ISO one.
Perhaps we should drop this helper?

HTH
Emil
[1] https://msdn.microsoft.com/en-us/library/tbyd7s1y.aspx

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

Re: [Mesa-dev] [PATCH mesa 04/13] util: use standard name for strstr()

[Emil Velikov]

On 2018/11/20, Eric Engestrom wrote:
> Signed-off-by: Eric Engestrom 
> ---
>  src/util/u_string.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/util/u_string.h b/src/util/u_string.h
> index d74ce1db8537bda54e48..94080e540d66b9fd8381 100644
> --- a/src/util/u_string.h
> +++ b/src/util/u_string.h
> @@ -185,6 +185,7 @@ util_strncmp(const char *s1, const char *s2, size_t n)
> return 0;
>  }
>  
> +#define strstr util_strstr

strstr seems to be a thing for MSVC 2017 [1]. I think we can drop the
helper all together.

HTH
Emil

[1] https://msdn.microsoft.com/en-us/library/z9da80kz.aspx
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH mesa 02/13] util: use standard name for strcasecmp()

[Emil Velikov]

On 2018/11/20, Eric Engestrom wrote:
> Signed-off-by: Eric Engestrom 
> ---
>  src/util/u_string.h | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/src/util/u_string.h b/src/util/u_string.h
> index cb0895a71a3f50867327..5687fa8aed1ff98287e6 100644
> --- a/src/util/u_string.h
> +++ b/src/util/u_string.h
> @@ -200,7 +200,7 @@ util_strstr(const char *haystack, const char *needle)
>  }
>  
>  
> -#define util_strcasecmp stricmp
> +#define strcasecmp stricmp

The MSDN lists _stricmp (note the missing underscore) for MSVC 2017.

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

Re: [Mesa-dev] [PATCH mesa 2/2] meson: make passing an invalid pointer a hard error

[Emil Velikov]

On Tue, 20 Nov 2018 at 12:36, Eric Engestrom  wrote:
>
> Signed-off-by: Eric Engestrom 
Reviewed-by: Emil Velikov 

Just sent out a patch for autotools, scons and android. Since people
are likely to use them as well.
Feel free to squash if you'd like.

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

[Mesa-dev] [PATCH] build: enable -Werror=incompatible-pointer-types

[Emil Velikov]

From: Emil Velikov 

More or less any issue pointed out by the compiler is an error. Make
sure we flag and bail loudly.

Cc: Eric Engestrom 
Signed-off-by: Emil Velikov 
---
Eric, feel free to squash this with your patch.
---
 Android.common.mk | 1 +
 configure.ac  | 2 ++
 scons/gallium.py  | 1 +
 3 files changed, 4 insertions(+)

diff --git a/Android.common.mk b/Android.common.mk
index aa1b266a393..4bdbf70e30b 100644
--- a/Android.common.mk
+++ b/Android.common.mk
@@ -31,6 +31,7 @@ LOCAL_C_INCLUDES += \
 
 MESA_VERSION := $(shell cat $(MESA_TOP)/VERSION)
 LOCAL_CFLAGS += \
+   -Werror=incompatible-pointer-types \
-Wno-error \
-Wno-unused-parameter \
-Wno-pointer-arith \
diff --git a/configure.ac b/configure.ac
index 93a52475d50..2b632cda997 100644
--- a/configure.ac
+++ b/configure.ac
@@ -307,6 +307,7 @@ dnl
 AX_CHECK_COMPILE_FLAG([-Wall], 
[CFLAGS="$CFLAGS -Wall"])
 AX_CHECK_COMPILE_FLAG([-Werror=implicit-function-declaration], 
[CFLAGS="$CFLAGS -Werror=implicit-function-declaration"])
 AX_CHECK_COMPILE_FLAG([-Werror=missing-prototypes],
[CFLAGS="$CFLAGS -Werror=missing-prototypes"])
+AX_CHECK_COMPILE_FLAG([-Werror=incompatible-pointer-types],
[CFLAGS="$CFLAGS -Werror=incompatible-pointer-types"])
 AX_CHECK_COMPILE_FLAG([-Wmissing-prototypes],  
[CFLAGS="$CFLAGS -Wmissing-prototypes"])
 dnl Dylan Baker: gcc and clang always accepr -Wno-*, hence check for the 
original warning, then set the no-* flag
 AX_CHECK_COMPILE_FLAG([-Wmissing-field-initializers],  
[CFLAGS="$CFLAGS -Wno-missing-field-initializers"])
@@ -326,6 +327,7 @@ dnl Check C++ compiler flags
 dnl
 AC_LANG_PUSH([C++])
 AX_CHECK_COMPILE_FLAG([-Wall], 
[CXXFLAGS="$CXXFLAGS -Wall"])
+AX_CHECK_COMPILE_FLAG([-Werror=incompatible-pointer-types],
[CFXXLAGS="$CXXFLAGS -Werror=incompatible-pointer-types"])
 AX_CHECK_COMPILE_FLAG([-fno-math-errno],   
[CXXFLAGS="$CXXFLAGS -fno-math-errno"])
 AX_CHECK_COMPILE_FLAG([-fno-trapping-math],
[CXXFLAGS="$CXXFLAGS -fno-trapping-math"])
 AX_CHECK_COMPILE_FLAG([-fvisibility=hidden],   
[VISIBILITY_CXXFLAGS="-fvisibility=hidden"])
diff --git a/scons/gallium.py b/scons/gallium.py
index 963834a5fbc..36f542d0d64 100755
--- a/scons/gallium.py
+++ b/scons/gallium.py
@@ -451,6 +451,7 @@ def generate(env):
 # - http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
 ccflags += [
 '-Wall',
+'-Werror=incompatible-pointer-types'
 '-Wno-long-long',
 '-fmessage-length=0', # be nice to Eclipse
 ]
-- 
2.19.1

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

Re: [Mesa-dev] [PATCH v1] virgl: add assert and missing function parameter

[Emil Velikov]

On Tue, 20 Nov 2018 at 16:24, Robert Foss  wrote:
>
> Verify the pipe_fd_type to be of PIPE_FD_TYPE_NATIVE_SYNC.
>
> Suggested-by: Eric Engestrom 
> Signed-off-by: Robert Foss 

Fixes: d1a1c21e7621b5177feb "virgl: native fence fd support"
Reviewed-by: Emil Velikov 

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

Re: [Mesa-dev] [Mesa-stable] [PATCH 1/2] travis: drop unneeded x11proto-xf86vidmode-dev

[Emil Velikov]

On Wed, 21 Nov 2018 at 10:28, Juan A. Suarez Romero  wrote:
>m
> On Fri, 2018-11-16 at 13:59 +, Emil Velikov wrote:
> > From: Emil Velikov 
> >
> > The only place where the package is needed is for building the DRI
> > based libGL library.
> >
>
>
> This caused a conflict when applied to 18.2 branch.
>
> Resolved the (trivial) conflict as
>
>
> https://gitlab.freedesktop.org/mesa/mesa/commit/6ceeb848d5be06464cfaaf6735c38c6d167d0352
>
Thanks, it looks spot on.

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

[Mesa-dev] [PATCH 14/18] mapi/es*api: remove GL_OES_EGL_image entrypoints

[Emil Velikov]

From: Emil Velikov 

As some point in the past we fixed the scripts so, these are no longer
exported. Drop them from the list.

Signed-off-by: Emil Velikov 
---
 src/mapi/es1api/ABI-check | 3 ---
 src/mapi/es2api/ABI-check | 3 ---
 2 files changed, 6 deletions(-)

diff --git a/src/mapi/es1api/ABI-check b/src/mapi/es1api/ABI-check
index 11b4923dea2..d8501e5d8c5 100755
--- a/src/mapi/es1api/ABI-check
+++ b/src/mapi/es1api/ABI-check
@@ -4,7 +4,6 @@ set -eu
 # Print defined gl.* functions not in GL ES 1.1 or in
 # (FIXME, none of these should be part of the ABI)
 # GL_EXT_multi_draw_arrays
-# GL_OES_EGL_image
 
 # or in extensions that are part of the ES 1.1 extension pack.
 # (see 
http://www.khronos.org/registry/gles/specs/1.1/opengles_spec_1_1_extension_pack.pdf)
@@ -65,8 +64,6 @@ glDisable
 glDisableClientState
 glDrawArrays
 glDrawElements
-glEGLImageTargetRenderbufferStorageOES
-glEGLImageTargetTexture2DOES
 glEnable
 glEnableClientState
 glFinish
diff --git a/src/mapi/es2api/ABI-check b/src/mapi/es2api/ABI-check
index a04b03d7d60..2d92d1c0028 100755
--- a/src/mapi/es2api/ABI-check
+++ b/src/mapi/es2api/ABI-check
@@ -4,7 +4,6 @@ set -eu
 # Print defined gl.* functions not in GL ES 3.0 or in
 # (FIXME, none of these should be part of the ABI)
 # GL_EXT_multi_draw_arrays
-# GL_OES_EGL_image
 
 case "$(uname)" in
 Darwin)
@@ -118,8 +117,6 @@ glDrawElementsInstanced
 glDrawElementsInstancedBaseVertex
 glDrawRangeElements
 glDrawRangeElementsBaseVertex
-glEGLImageTargetRenderbufferStorageOES
-glEGLImageTargetTexture2DOES
 glEnable
 glEnableVertexAttribArray
 glEnablei
-- 
2.19.1

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

[Mesa-dev] [PATCH 16/18] mapi/es2api: remove no longer present entrypoints

[Emil Velikov]

From: Emil Velikov 

With the previous scripts API from the following was incorrectly
exported. Drop them from the list, since they're no longer around.

GL_EXT_blend_func_extended
GL_EXT_texture_integer

Signed-off-by: Emil Velikov 
---
 src/mapi/es2api/ABI-check | 5 -
 1 file changed, 5 deletions(-)

diff --git a/src/mapi/es2api/ABI-check b/src/mapi/es2api/ABI-check
index 594f9a2d6a4..e709c8c945c 100755
--- a/src/mapi/es2api/ABI-check
+++ b/src/mapi/es2api/ABI-check
@@ -31,7 +31,6 @@ glBindAttribLocation
 glBindBuffer
 glBindBufferBase
 glBindBufferRange
-glBindFragDataLocationEXT
 glBindFramebuffer
 glBindImageTexture
 glBindProgramPipeline
@@ -195,9 +194,7 @@ glGetSynciv
 glGetTexLevelParameterfv
 glGetTexLevelParameteriv
 glGetTexParameterIiv
-glGetTexParameterIivEXT
 glGetTexParameterIuiv
-glGetTexParameterIuivEXT
 glGetTexParameterfv
 glGetTexParameteriv
 glGetTransformFeedbackVarying
@@ -311,9 +308,7 @@ glTexBufferRange
 glTexImage2D
 glTexImage3D
 glTexParameterIiv
-glTexParameterIivEXT
 glTexParameterIuiv
-glTexParameterIuivEXT
 glTexParameterf
 glTexParameterfv
 glTexParameteri
-- 
2.19.1

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

[Mesa-dev] [PATCH 13/18] scons: wire the new generator for es1 and es2

[Emil Velikov]

From: Emil Velikov 

Signed-off-by: Emil Velikov 
---
 src/mapi/shared-glapi/SConscript | 28 +---
 1 file changed, 21 insertions(+), 7 deletions(-)

diff --git a/src/mapi/shared-glapi/SConscript b/src/mapi/shared-glapi/SConscript
index 060c61dadce..81aea74873d 100644
--- a/src/mapi/shared-glapi/SConscript
+++ b/src/mapi/shared-glapi/SConscript
@@ -27,13 +27,27 @@ def mapi_objects(env, printer, mode):
 
 # generate ABI header
 GLAPI = '../glapi/'
-header = env.CodeGenerate(
-target = header_name,
-script = '../mapi_abi.py',
-source = [GLAPI + 'gen/gl_and_es_API.xml'] + env.Glob(GLAPI + 
'gen/*.xml'),
-command = python_cmd + ' $SCRIPT ' + \
-'--printer %s $SOURCE > $TARGET' % (printer),
-)
+if printer != 'glapi':
+if printer == 'es1api':
+abi_tag = 'glesv1'
+else:
+abi_tag = 'glesv2'
+
+header = env.CodeGenerate(
+target = header_name,
+script = '../new/gen_gldispatch_mapi.py',
+source = GLAPI + 'registry/gl.xml'
+command = python_cmd + ' $SCRIPT ' + \
+'%s $SOURCE > $TARGET' % (abi_tag),
+)
+else:
+header = env.CodeGenerate(
+target = header_name,
+script = '../mapi_abi.py',
+source = [GLAPI + 'gen/gl_and_es_API.xml'] + env.Glob(GLAPI + 
'gen/*.xml'),
+command = python_cmd + ' $SCRIPT ' + \
+'--printer %s $SOURCE > $TARGET' % (printer),
+)
 
 cpppath = [
 header[0].dir,
-- 
2.19.1

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

[Mesa-dev] [PATCH 06/18] mapi/new: use the static_data offsets in the new generator

[Emil Velikov]

From: Emil Velikov 

Otherwise the incorrect ones will be used, effecitvely breaking the ABI.

Note: some entries in static_data.py list a suffixed API, while (for ES*
at least) we expect the one w/o suffix.

Signed-off-by: Emil Velikov 
---
 src/mapi/new/genCommon.py | 30 +-
 1 file changed, 29 insertions(+), 1 deletion(-)

diff --git a/src/mapi/new/genCommon.py b/src/mapi/new/genCommon.py
index ee3c468479d..4152ccab3f4 100644
--- a/src/mapi/new/genCommon.py
+++ b/src/mapi/new/genCommon.py
@@ -30,6 +30,11 @@ import collections
 import re
 import xml.etree.cElementTree as etree
 
+import os
+GLAPI = os.path.join(os.path.dirname(sys.argv[0]), "..", "glapi/gen")
+sys.path.append(GLAPI)
+import static_data
+
 MAPI_TABLE_NUM_DYNAMIC = 4096
 
 _LIBRARY_FEATURE_NAMES = {
@@ -71,8 +76,31 @@ def getFunctionsFromRoots(roots):
 # Assign a slot number to each function. This isn't strictly necessary,
 # since you can just look at the index in the list, but it makes it easier
 # to include the slot when formatting output.
+
+next_slot = 0
 for i in range(len(functions)):
-functions[i] = functions[i]._replace(slot=i)
+name = functions[i].name[2:]
+slot_set = False
+
+if name in static_data.offsets:
+functions[i] = 
functions[i]._replace(slot=static_data.offsets[name])
+slot_set = True
+
+if slot_set == False and name[-3:] != "ARB":
+lname = name + "ARB"
+if lname in static_data.offsets:
+functions[i] = 
functions[i]._replace(slot=static_data.offsets[lname])
+slot_set = True
+
+if slot_set == False and name[-3:] != "EXT":
+lname = name + "EXT"
+if lname in static_data.offsets:
+functions[i] = 
functions[i]._replace(slot=static_data.offsets[lname])
+slot_set = True
+
+if slot_set == False:
+functions[i] = functions[i]._replace(slot=next_slot)
+next_slot += 1
 
 # Sort the function list by slot to simplify the diff
 functions = sorted(functions, key=lambda f: f.slot)
-- 
2.19.1

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

[Mesa-dev] [PATCH 11/18] autotools: wire the new generator for es1 and es2

[Emil Velikov]

The output produced functionally identical, with the following changes:
 - A cosmetic: swapped ABI compatible types [ GLclampf -> GLfloat, etc ]
 - B cosmetic: renamed parameters [ zNear -> n, etc ]
 - C dropped gl_dispatch_stub declarations - unneeded
 - D dropped extension entrypoints - invalid/incorrect

To make things easier to validate, normalise both old/new headers run
the sed patterns A, B and C to both sets.

A
  s/\/GLfloat/g; s/\/GLfixed/g;
  s/\/void/g;

B
  s/\ \* / */g; s/\/target/g;
  s/\/p/g; s/\/d/g; s/\/modeA/g;
  s/\/program/g; s/\/shaders/g; s/\/eqn/g;
  s/\/data/g; s/\/data/g; s/\/buffer/g;
  s/\/mode/g; s/\/n/g; s/\/n/g; s/\/f/g;
  s/\/t/g; s/\/b/g; s/\/l/g; s/\/r/g;
  s/\/v0/g; s/\/v1/g; s/\/v2/g; s/\/v3/g;

C
  /gl_dispatch_stub/d

D
glMultiDrawArraysEXT
glMultiDrawElementsEXT

glBindFragDataLocationEXT

glGetTexParameterIivEXT
glGetTexParameterIuivEXT
glTexParameterIivEXT
glTexParameterIuivEXT

Signed-off-by: Emil Velikov 
---
 src/mapi/Makefile.am | 23 +++
 1 file changed, 15 insertions(+), 8 deletions(-)

diff --git a/src/mapi/Makefile.am b/src/mapi/Makefile.am
index 5a619bf049b..daaf46ddb23 100644
--- a/src/mapi/Makefile.am
+++ b/src/mapi/Makefile.am
@@ -63,11 +63,20 @@ include Makefile.sources
 MKDIR_GEN = $(AM_V_at)$(MKDIR_P) $(@D)
 PYTHON_GEN = $(AM_V_GEN)$(PYTHON) $(PYTHON_FLAGS)
 
-glapi_gen_mapi_deps := \
+shared_glapi_gen_mapi_deps := \
mapi_abi.py \
$(wildcard $(top_srcdir)/src/mapi/glapi/gen/*.xml) \
$(wildcard $(top_srcdir)/src/mapi/glapi/gen/*.py)
 
+glapi_gen_gl_xml := \
+   $(srcdir)/glapi/registry/gl.xml
+glapi_gen_mapi_script = $(srcdir)/new/gen_gldispatch_mapi.py
+glapi_gen_mapi_deps = \
+   $(glapi_gen_mapi_script) \
+   $(srcdir)/new/genCommon.py \
+   $(glapi_gen_gl_xml)
+glapi_gen_mapi = $(AM_V_GEN)$(PYTHON) $(PYTHON_FLAGS) $(glapi_gen_mapi_script)
+
 if HAVE_SHARED_GLAPI
 BUILT_SOURCES += shared-glapi/glapi_mapi_tmp.h
 
@@ -101,7 +110,7 @@ shared_glapi_test_LDADD = \
$(top_builddir)/src/gtest/libgtest.la
 endif
 
-shared-glapi/glapi_mapi_tmp.h : glapi/gen/gl_and_es_API.xml 
$(glapi_gen_mapi_deps)
+shared-glapi/glapi_mapi_tmp.h : glapi/gen/gl_and_es_API.xml 
$(shared_glapi_gen_mapi_deps)
$(MKDIR_GEN)
$(PYTHON_GEN) $(srcdir)/mapi_abi.py --printer shared-glapi \
$(srcdir)/glapi/gen/gl_and_es_API.xml > $@
@@ -200,10 +209,9 @@ es1api_libGLESv1_CM_la_LDFLAGS = \
 es1api_libGLESv1_CM_la_LIBADD += shared-glapi/libglapi.la
 endif
 
-es1api/glapi_mapi_tmp.h: glapi/gen/gl_and_es_API.xml $(glapi_gen_mapi_deps)
+es1api/glapi_mapi_tmp.h: $(glapi_gen_mapi_deps)
$(MKDIR_GEN)
-   $(PYTHON_GEN) $(srcdir)/mapi_abi.py --printer es1api \
-   $(srcdir)/glapi/gen/gl_and_es_API.xml > $@
+   $(glapi_gen_mapi) glesv1 $(glapi_gen_gl_xml) > $@
 
 if HAVE_OPENGL_ES2
 TESTS += es2api/ABI-check
@@ -245,10 +253,9 @@ es2api_libGLESv2_la_LDFLAGS = \
 es2api_libGLESv2_la_LIBADD += shared-glapi/libglapi.la
 endif
 
-es2api/glapi_mapi_tmp.h: glapi/gen/gl_and_es_API.xml $(glapi_gen_mapi_deps)
+es2api/glapi_mapi_tmp.h: $(glapi_gen_mapi_deps)
$(MKDIR_GEN)
-   $(PYTHON_GEN) $(srcdir)/mapi_abi.py --printer es2api \
-   $(srcdir)/glapi/gen/gl_and_es_API.xml > $@
+   $(glapi_gen_mapi) glesv2 $(glapi_gen_gl_xml) > $@
 
 include $(top_srcdir)/install-lib-links.mk
 
-- 
2.19.1

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

[Mesa-dev] [PATCH 00/18] En route towards Khronos gl.xml

[Emil Velikov]

Hi all,

Recently Erik enabled NV_conditional_render for GLES, which highlighted
an existing issue in our generator scripts.

Namely: today we have a single static_data list for all of GL/ES1/ES2.
Thus as we expose an extention (as above) we en up statically exporting
the functions, if they're part of the GL ABI.

Having a look shows that we have:
 - a number of hacks in the ABI-check scripts
 - another hack in the ES2 generator script

Since, our python scripts are based off the custom XML files, I've
borrowed a couple of straight-forward script from GLVND.

A tweaks were needed, some of which I'll send back upstream.

With those in place, I've manually verified that the generated files do
not differ in any [functionally] meaningful way and gave the series a
quick piglit run.

Note: the "HACK" patches are sent for to make verification easier.
We'll have to drop 02/18, although I'm ambivalent wrt 05/18.

As a finale, I've removed the obvious ES* specific code.

If time permits, I'm hoping to continue until we're using only the
upstream XML file. In particular the following bits need work:
 - glapi and shared-glapi
 - indirect gl/glx
 - glGet and friends; needs extra data - upstream to Khronos
 - marshalling/glthread code; needs extra data - likely to stay local 
 - enum to string
 - others?

Any testing and review is greatly appreciated.

Thanks
Emil

Cc: Ian Romanick 

Emil Velikov (18):
  mapi: sort static entrypoints numerically
  HACK: glapi: print _glapi_table offsets to a file
  mapi: add all _glapi_table entrypoints to static_data.py
  mapi/new: import mapi scripts from glvnd
  HACK: mapi/new: sort by slot number
  mapi/new: use the static_data offsets in the new generator
  mapi/new: reinstate _NO_HIDDEN suffixes in the new generator
  mapi/new: don't print info we don't need for ES1/ES2
  mapi/new: fixup the GLDEBUGPROCKHR typedef to the non KHR one
  mapi/new: remove duplicate GLvoid/void substitution
  autotools: wire the new generator for es1 and es2
  meson: wire the new generator for es1 and es2
  scons: wire the new generator for es1 and es2
  mapi/es*api: remove GL_OES_EGL_image entrypoints
  mapi/es*api: remove GL_EXT_multi_draw_arrays entrypoints
  mapi/es2api: remove no longer present entrypoints
  mapi: remove old, unused ES* generator code
  mapi: remove machinery handling CSV files

 src/mapi/Makefile.am|   25 +-
 src/mapi/es1api/ABI-check   |   10 +-
 src/mapi/es1api/meson.build |6 +-
 src/mapi/es2api/ABI-check   |   14 +-
 src/mapi/es2api/meson.build |6 +-
 src/mapi/glapi/gen/gl_XML.py|   56 +-
 src/mapi/glapi/gen/gl_table.py  |   10 +-
 src/mapi/glapi/gen/meson.build  |7 +
 src/mapi/glapi/gen/static_data.py   | 1029 ++-
 src/mapi/mapi_abi.py|  138 +---
 src/mapi/meson.build|1 +
 src/mapi/new/genCommon.py   |  254 +++
 src/mapi/new/gen_gldispatch_mapi.py |  180 +
 src/mapi/shared-glapi/SConscript|   28 +-
 14 files changed, 1521 insertions(+), 243 deletions(-)
 create mode 100644 src/mapi/new/genCommon.py
 create mode 100755 src/mapi/new/gen_gldispatch_mapi.py

-- 
2.19.1

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

[Mesa-dev] [PATCH 18/18] mapi: remove machinery handling CSV files

[Emil Velikov]

From: Emil Velikov 

We haven't have one in years, so just drop the code.

Signed-off-by: Emil Velikov 
---
 src/mapi/mapi_abi.py | 80 
 1 file changed, 6 insertions(+), 74 deletions(-)

diff --git a/src/mapi/mapi_abi.py b/src/mapi/mapi_abi.py
index 3cfede56880..846c69c8b70 100644
--- a/src/mapi/mapi_abi.py
+++ b/src/mapi/mapi_abi.py
@@ -184,75 +184,6 @@ def abi_parse_xml(xml):
 
 return entries
 
-def abi_parse_line(line):
-cols = [col.strip() for col in line.split(',')]
-
-attrs = {
-'slot': -1,
-'hidden': False,
-'alias': None,
-'handcode': None,
-}
-
-# extract attributes from the first column
-vals = cols[0].split(':')
-while len(vals) > 1:
-val = vals.pop(0)
-if val.startswith('slot='):
-attrs['slot'] = int(val[5:])
-elif val == 'hidden':
-attrs['hidden'] = True
-elif val.startswith('alias='):
-attrs['alias'] = val[6:]
-elif val.startswith('handcode='):
-attrs['handcode'] = val[9:]
-elif not val:
-pass
-else:
-raise Exception('unknown attribute %s' % val)
-cols[0] = vals[0]
-
-return (attrs, cols)
-
-def abi_parse(filename):
-"""Parse a CSV file for ABI entries."""
-fp = open(filename) if filename != '-' else sys.stdin
-lines = [line.strip() for line in fp.readlines()
-if not line.startswith('#') and line.strip()]
-
-entry_dict = {}
-next_slot = 0
-for line in lines:
-attrs, cols = abi_parse_line(line)
-
-# post-process attributes
-if attrs['alias']:
-try:
-alias = entry_dict[attrs['alias']]
-except KeyError:
-raise Exception('failed to alias %s' % attrs['alias'])
-if alias.alias:
-raise Exception('recursive alias %s' % ent.name)
-slot = alias.slot
-attrs['alias'] = alias
-else:
-slot = next_slot
-next_slot += 1
-
-if attrs['slot'] < 0:
-attrs['slot'] = slot
-elif attrs['slot'] != slot:
-raise Exception('invalid slot in %s' % (line))
-
-ent = ABIEntry(cols, attrs)
-if ent.name in entry_dict:
-raise Exception('%s is duplicated' % (ent.name))
-entry_dict[ent.name] = ent
-
-entries = sorted(entry_dict.values())
-
-return entries
-
 def abi_sanity_check(entries):
 if not entries:
 return
@@ -714,7 +645,7 @@ typedef int GLclampx;
 def parse_args():
 printers = ['glapi', 'es1api', 'es2api', 'shared-glapi']
 
-parser = OptionParser(usage='usage: %prog [options] ')
+parser = OptionParser(usage='usage: %prog [options] ')
 parser.add_option('-p', '--printer', dest='printer',
 help='printer to use: %s' % (", ".join(printers)))
 
@@ -723,6 +654,10 @@ def parse_args():
 parser.print_help()
 sys.exit(1)
 
+if not args[0].endswith('.xml'):
+parser.print_help()
+sys.exit(1)
+
 return (args[0], options)
 
 def main():
@@ -733,10 +668,7 @@ def main():
 
 filename, options = parse_args()
 
-if filename.endswith('.xml'):
-entries = abi_parse_xml(filename)
-else:
-entries = abi_parse(filename)
+entries = abi_parse_xml(filename)
 abi_sanity_check(entries)
 
 printer = printers[options.printer](entries)
-- 
2.19.1

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

[Mesa-dev] [PATCH 17/18] mapi: remove old, unused ES* generator code

[Emil Velikov]

From: Emil Velikov 

As of earlier commit, everyone has switched to the new script for the ES
dispatch.

Signed-off-by: Emil Velikov 
---
 src/mapi/glapi/gen/gl_XML.py | 56 +-
 src/mapi/mapi_abi.py | 58 
 2 files changed, 1 insertion(+), 113 deletions(-)

diff --git a/src/mapi/glapi/gen/gl_XML.py b/src/mapi/glapi/gen/gl_XML.py
index b4aa6be985e..259956a0df8 100644
--- a/src/mapi/glapi/gen/gl_XML.py
+++ b/src/mapi/glapi/gen/gl_XML.py
@@ -611,21 +611,11 @@ class gl_function( gl_item ):
 self.deprecated = None
 self.has_no_error_variant = False
 
-# self.entry_point_api_map[name][api] is a decimal value
-# indicating the earliest version of the given API in which
-# each entry point exists.  Every entry point is included in
-# the first level of the map; the second level of the map only
-# lists APIs which contain the entry point in at least one
-# version.  For example,
-# self.entry_point_api_map['ClipPlanex'] == { 'es1':
-# Decimal('1.1') }.
-self.entry_point_api_map = {}
-
 # self.api_map[api] is a decimal value indicating the earliest
 # version of the given API in which ANY alias for the function
 # exists.  The map only lists APIs which contain the function
 # in at least one version.  For example, for the ClipPlanex
-# function, self.entry_point_api_map == { 'es1':
+# function, self.api_map == { 'es1':
 # Decimal('1.1') }.
 self.api_map = {}
 
@@ -658,13 +648,11 @@ class gl_function( gl_item ):
 
 self.entry_points.append( name )
 
-self.entry_point_api_map[name] = {}
 for api in ('es1', 'es2'):
 version_str = element.get(api, 'none')
 assert version_str is not None
 if version_str != 'none':
 version_decimal = Decimal(version_str)
-self.entry_point_api_map[name][api] = version_decimal
 if api not in self.api_map or \
 version_decimal < self.api_map[api]:
 self.api_map[api] = version_decimal
@@ -826,23 +814,6 @@ class gl_function( gl_item ):
 else:
 return "_dispatch_stub_%u" % (self.offset)
 
-def entry_points_for_api_version(self, api, version = None):
-"""Return a list of the entry point names for this function
-which are supported in the given API (and optionally, version).
-
-Use the decimal.Decimal type to precisely express non-integer
-versions.
-"""
-result = []
-for entry_point, api_to_ver in self.entry_point_api_map.items():
-if api not in api_to_ver:
-continue
-if version is not None and version < api_to_ver[api]:
-continue
-result.append(entry_point)
-return result
-
-
 class gl_item_factory(object):
 """Factory to create objects derived from gl_item."""
 
@@ -878,31 +849,6 @@ class gl_api(object):
 typeexpr.create_initial_types()
 return
 
-def filter_functions(self, entry_point_list):
-"""Filter out entry points not in entry_point_list."""
-functions_by_name = {}
-for func in self.functions_by_name.values():
-entry_points = [ent for ent in func.entry_points if ent in 
entry_point_list]
-if entry_points:
-func.filter_entry_points(entry_points)
-functions_by_name[func.name] = func
-
-self.functions_by_name = functions_by_name
-
-def filter_functions_by_api(self, api, version = None):
-"""Filter out entry points not in the given API (or
-optionally, not in the given version of the given API).
-"""
-functions_by_name = {}
-for func in self.functions_by_name.values():
-entry_points = func.entry_points_for_api_version(api, version)
-if entry_points:
-func.filter_entry_points(entry_points)
-functions_by_name[func.name] = func
-
-self.functions_by_name = functions_by_name
-
-
 def parse_file(self, file_name):
 doc = ET.parse( file_name )
 self.process_element(file_name, doc)
diff --git a/src/mapi/mapi_abi.py b/src/mapi/mapi_abi.py
index dc48fa5935f..3cfede56880 100644
--- a/src/mapi/mapi_abi.py
+++ b/src/mapi/mapi_abi.py
@@ -679,62 +679,6 @@ class GLAPIPrinter(ABIPrinter):
 #define GLAPI_PREFIX_STR(func)  "gl"#func
 #endif /* USE_MGL_NAMESPACE */
 
-typedef int GLclampx;
-#endif /* _GLAPI_TMP_H_ */"""
-
-return header
-
-class ES1APIPrinter(GLAPIPrinter):
-"""OpenGL ES 1.x API Printer"""
-
-def __init__(self, entries):
-super(ES1APIPrinter, self).__init__(entries)
-self.prefix_lib = 'gl'
-self.prefix_warn = 'gl'
-
-def _override_for_api(self, ent):
-if ent.xml_data is None:
-

[Mesa-dev] [PATCH 10/18] mapi/new: remove duplicate GLvoid/void substitution

[Emil Velikov]

From: Emil Velikov 

We already do it a few lines above - drop the duplicate.

Note that for consistency sake, we keep the substitution since the GL
API is a mixed bad - some use GLvoid while others a normal void.

We might want to merge this back in GLVND.

Signed-off-by: Emil Velikov 
---
 src/mapi/new/genCommon.py | 1 -
 1 file changed, 1 deletion(-)

diff --git a/src/mapi/new/genCommon.py b/src/mapi/new/genCommon.py
index 29cede96939..5ada13759bb 100644
--- a/src/mapi/new/genCommon.py
+++ b/src/mapi/new/genCommon.py
@@ -236,7 +236,6 @@ def _fixupTypeName(typeName):
 # Remove the vendor suffixes from types that have a suffix-less version.
 rv = 
re.sub(r"\b(GLhalf|GLintptr|GLsizeiptr|GLint64|GLuint64)(?:ARB|EXT|NV|ATI)\b", 
r"\1", rv)
 
-rv = re.sub(r"\bGLvoid\b", "void", rv)
 rv = re.sub(r"\bGLDEBUGPROCKHR\b", "GLDEBUGPROC", rv)
 
 # Clear out any leading and trailing whitespace.
-- 
2.19.1

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

[Mesa-dev] [PATCH 04/18] mapi/new: import mapi scripts from glvnd

[Emil Velikov]

From: Emil Velikov 

Currently we have over 20 scripts that generate the libGL* dispatch and
various other functionality. More importantly we're using local XML
files instead of the Khronos provides one(s). Resulting in an
increasing complexity of writing, maintaining and bugfixing.

One fairly annoying bug is handling of statically exported symbols.
Today, if we enable a GL extension for GLES1/2, we add a special tag to
the xml. Thus the ES dispatch gets generated, but also since we have no
separate notion of GL/ES1/ES2 static functions it also gets exported
statically.

This commit adds step one towards clearing and simplifying our setup.
It imports the mapi generator from GLVND.

  012fe39 ("Remove a couple of duplicate typedefs.")

Signed-off-by: Emil Velikov 
---
 src/mapi/Makefile.am|   2 +
 src/mapi/new/genCommon.py   | 223 
 src/mapi/new/gen_gldispatch_mapi.py | 180 ++
 3 files changed, 405 insertions(+)
 create mode 100644 src/mapi/new/genCommon.py
 create mode 100755 src/mapi/new/gen_gldispatch_mapi.py

diff --git a/src/mapi/Makefile.am b/src/mapi/Makefile.am
index 97ebdeb1d7f..5a619bf049b 100644
--- a/src/mapi/Makefile.am
+++ b/src/mapi/Makefile.am
@@ -31,6 +31,8 @@ pkgconfigdir = $(libdir)/pkgconfig
 pkgconfig_DATA =
 
 EXTRA_DIST = \
+   new/genCommon.py \
+   new/gen_gldispatch_mapi.py \
es1api/ABI-check \
es2api/ABI-check \
mapi_abi.py \
diff --git a/src/mapi/new/genCommon.py b/src/mapi/new/genCommon.py
new file mode 100644
index 000..5c721acbaca
--- /dev/null
+++ b/src/mapi/new/genCommon.py
@@ -0,0 +1,223 @@
+#!/usr/bin/env python
+
+# (C) Copyright 2015, NVIDIA CORPORATION.
+# All Rights Reserved.
+#
+# Permission is hereby granted, free of charge, to any person obtaining a
+# copy of this software and associated documentation files (the "Software"),
+# to deal in the Software without restriction, including without limitation
+# on the rights to use, copy, modify, merge, publish, distribute, sub
+# license, and/or sell copies of the Software, and to permit persons to whom
+# the Software is furnished to do so, subject to the following conditions:
+#
+# The above copyright notice and this permission notice (including the next
+# paragraph) shall be included in all copies or substantial portions of the
+# Software.
+#
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT.  IN NO EVENT SHALL
+# IBM AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+# IN THE SOFTWARE.
+#
+# Authors:
+#Kyle Brenneman 
+
+import sys
+import collections
+import re
+import xml.etree.cElementTree as etree
+
+MAPI_TABLE_NUM_DYNAMIC = 4096
+
+_LIBRARY_FEATURE_NAMES = {
+# libGL and libGLdiapatch both include every function.
+"gl" : None,
+"gldispatch" : None,
+"opengl" : frozenset(( "GL_VERSION_1_0", "GL_VERSION_1_1",
+"GL_VERSION_1_2", "GL_VERSION_1_3", "GL_VERSION_1_4", "GL_VERSION_1_5",
+"GL_VERSION_2_0", "GL_VERSION_2_1", "GL_VERSION_3_0", "GL_VERSION_3_1",
+"GL_VERSION_3_2", "GL_VERSION_3_3", "GL_VERSION_4_0", "GL_VERSION_4_1",
+"GL_VERSION_4_2", "GL_VERSION_4_3", "GL_VERSION_4_4", "GL_VERSION_4_5",
+)),
+"glesv1" : frozenset(("GL_VERSION_ES_CM_1_0", "GL_OES_point_size_array")),
+"glesv2" : frozenset(("GL_ES_VERSION_2_0", "GL_ES_VERSION_3_0",
+"GL_ES_VERSION_3_1", "GL_ES_VERSION_3_2",
+)),
+}
+
+def getFunctions(xmlFiles):
+"""
+Reads an XML file and returns all of the functions defined in it.
+
+xmlFile should be the path to Khronos's gl.xml file. The return value is a
+sequence of FunctionDesc objects, ordered by slot number.
+"""
+roots = [ etree.parse(xmlFile).getroot() for xmlFile in xmlFiles ]
+return getFunctionsFromRoots(roots)
+
+def getFunctionsFromRoots(roots):
+functions = {}
+for root in roots:
+for func in _getFunctionList(root):
+functions[func.name] = func
+functions = functions.values()
+
+# Sort the function list by name.
+functions = sorted(functions, key=lambda f: f.name)
+
+# Assign a slot number to each function. This isn't strictly necessary,
+# since you can just look at the index in the list, but it makes it easier
+# to include the slot when formatting output.
+for i in range(len(functions)):
+functions[i] = functions[i]._replace(slot=i)
+
+return functions
+
+def getExportNamesFromRoots(target, roots):
+"""
+Goes through the  tags from gl.xml and returns a set of OpenGL
+functions that a library should export.
+
+target should be one of "gl", "gldispatch", "opengl", 

[Mesa-dev] [PATCH 02/18] HACK: glapi: print _glapi_table offsets to a file

[Emil Velikov]

From: Emil Velikov 

We'll need those in static_data.py
---
 src/mapi/glapi/gen/gl_table.py | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/src/mapi/glapi/gen/gl_table.py b/src/mapi/glapi/gen/gl_table.py
index 4b89ef8a856..72ad9426f95 100644
--- a/src/mapi/glapi/gen/gl_table.py
+++ b/src/mapi/glapi/gen/gl_table.py
@@ -45,10 +45,12 @@ class PrintGlTable(gl_XML.gl_print_base):
 return
 
 def printBody(self, api):
-for f in api.functionIterateByOffset():
-arg_string = f.get_parameter_string()
-print('   %s (GLAPIENTRYP %s)(%s); /* %d */' % (
-f.return_type, f.name, arg_string, f.offset))
+with open('/tmp/dispatch', 'w') as ff:
+for f in api.functionIterateByOffset():
+arg_string = f.get_parameter_string()
+print('"%s": %d,' % (f.name, f.offset), file=ff)
+print('   %s (GLAPIENTRYP %s)(%s); /* %d */' % (
+f.return_type, f.name, arg_string, f.offset))
 
 def printRealHeader(self):
 print('#ifndef GLAPIENTRYP')
-- 
2.19.1

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

[Mesa-dev] [PATCH 15/18] mapi/es*api: remove GL_EXT_multi_draw_arrays entrypoints

[Emil Velikov]

From: Emil Velikov 

Now we use the upstream XML file and a cleaner generator. Thus the
symbols are no longer exported and we can drop them from this list.

Signed-off-by: Emil Velikov 
---
 src/mapi/es1api/ABI-check | 7 +--
 src/mapi/es2api/ABI-check | 6 +-
 2 files changed, 2 insertions(+), 11 deletions(-)

diff --git a/src/mapi/es1api/ABI-check b/src/mapi/es1api/ABI-check
index d8501e5d8c5..e9a2cb2bde2 100755
--- a/src/mapi/es1api/ABI-check
+++ b/src/mapi/es1api/ABI-check
@@ -1,10 +1,7 @@
 #!/bin/sh
 set -eu
 
-# Print defined gl.* functions not in GL ES 1.1 or in
-# (FIXME, none of these should be part of the ABI)
-# GL_EXT_multi_draw_arrays
-
+# Print defined gl.* functions not in GL ES 1.1
 # or in extensions that are part of the ES 1.1 extension pack.
 # (see 
http://www.khronos.org/registry/gles/specs/1.1/opengles_spec_1_1_extension_pack.pdf)
 
@@ -120,8 +117,6 @@ glMaterialfv
 glMaterialx
 glMaterialxv
 glMatrixMode
-glMultiDrawArraysEXT
-glMultiDrawElementsEXT
 glMultiTexCoord4f
 glMultiTexCoord4x
 glMultMatrixf
diff --git a/src/mapi/es2api/ABI-check b/src/mapi/es2api/ABI-check
index 2d92d1c0028..594f9a2d6a4 100755
--- a/src/mapi/es2api/ABI-check
+++ b/src/mapi/es2api/ABI-check
@@ -1,9 +1,7 @@
 #!/bin/sh
 set -eu
 
-# Print defined gl.* functions not in GL ES 3.0 or in
-# (FIXME, none of these should be part of the ABI)
-# GL_EXT_multi_draw_arrays
+# Print defined gl.* functions not in GL ES 3.{0..2}
 
 case "$(uname)" in
 Darwin)
@@ -240,8 +238,6 @@ glMapBufferRange
 glMemoryBarrier
 glMemoryBarrierByRegion
 glMinSampleShading
-glMultiDrawArraysEXT
-glMultiDrawElementsEXT
 glObjectLabel
 glObjectPtrLabel
 glPatchParameteri
-- 
2.19.1

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

[Mesa-dev] [PATCH 12/18] meson: wire the new generator for es1 and es2

[Emil Velikov]

From: Emil Velikov 

Signed-off-by: Emil Velikov 
---
 src/mapi/es1api/meson.build| 6 +++---
 src/mapi/es2api/meson.build| 6 +++---
 src/mapi/glapi/gen/meson.build | 7 +++
 src/mapi/meson.build   | 1 +
 4 files changed, 14 insertions(+), 6 deletions(-)

diff --git a/src/mapi/es1api/meson.build b/src/mapi/es1api/meson.build
index 53e894f091c..6c37dbb67bc 100644
--- a/src/mapi/es1api/meson.build
+++ b/src/mapi/es1api/meson.build
@@ -20,10 +20,10 @@
 
 es1_glapi_mapi_tmp_h = custom_target(
   'es1_glapi_mapi_tmp.h',
-  input : [mapi_abi_py, gl_and_es_api_files],
+  input : [glapi_gen_mapi_script, glapi_gen_gl_xml],
   output : 'glapi_mapi_tmp.h',
-  command : [prog_python, '@INPUT0@', '--printer', 'es1api', '@INPUT1@'],
-  depend_files : api_xml_files,
+  command : [prog_python, '@INPUT0@', 'glesv1', '@INPUT1@'],
+  depend_files : glapi_gen_mapi_deps,
   capture : true,
 )
 
diff --git a/src/mapi/es2api/meson.build b/src/mapi/es2api/meson.build
index 1f397e2b752..3cb6a0cdeb3 100644
--- a/src/mapi/es2api/meson.build
+++ b/src/mapi/es2api/meson.build
@@ -20,10 +20,10 @@
 
 es2_glapi_mapi_tmp_h = custom_target(
   'es2_glapi_mapi_tmp.h',
-  input : [mapi_abi_py, gl_and_es_api_files],
+  input : [glapi_gen_mapi_script, glapi_gen_gl_xml],
   output : 'glapi_mapi_tmp.h',
-  command : [prog_python, '@INPUT0@', '--printer', 'es2api', '@INPUT1@'],
-  depend_files : api_xml_files,
+  command : [prog_python, '@INPUT0@', 'glesv2', '@INPUT1@'],
+  depend_files : glapi_gen_mapi_deps,
   capture : true,
 )
 
diff --git a/src/mapi/glapi/gen/meson.build b/src/mapi/glapi/gen/meson.build
index f494e9707b6..fa06c7c5458 100644
--- a/src/mapi/glapi/gen/meson.build
+++ b/src/mapi/glapi/gen/meson.build
@@ -18,6 +18,13 @@
 # OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
 # SOFTWARE.
 
+glapi_gen_gl_xml = files('../registry/gl.xml')
+glapi_gen_mapi_deps = [
+  glapi_gen_gl_xml,
+  files('../../new/genCommon.py'),
+  glapi_gen_gl_xml,
+]
+
 gl_and_es_api_files = files('gl_and_es_API.xml')
 
 api_xml_files = files(
diff --git a/src/mapi/meson.build b/src/mapi/meson.build
index 798586bfb0c..e7a6685576b 100644
--- a/src/mapi/meson.build
+++ b/src/mapi/meson.build
@@ -25,6 +25,7 @@ files_mapi_util = files(
   'u_execmem.h',
 )
 
+glapi_gen_mapi_script = files('new/gen_gldispatch_mapi.py')
 mapi_abi_py = files('mapi_abi.py')
 
 subdir('glapi')
-- 
2.19.1

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

[Mesa-dev] [PATCH 03/18] mapi: add all _glapi_table entrypoints to static_data.py

[Emil Velikov]

From: Emil Velikov 

Currently various parts of mesa use the glapi_table differently.

Some use _glapi_get_proc_offset() to get the offset, while others
directly reference the specific offset via _gloffset_Function.

Add all static entries, to ensure things don't break as we flip to the
upstream XML + new mapi generator.

Signed-off-by: Emil Velikov 
---
 src/mapi/glapi/gen/static_data.py | 1013 -
 1 file changed, 1012 insertions(+), 1 deletion(-)

diff --git a/src/mapi/glapi/gen/static_data.py 
b/src/mapi/glapi/gen/static_data.py
index 0596d2cd3bb..d5d6f626008 100644
--- a/src/mapi/glapi/gen/static_data.py
+++ b/src/mapi/glapi/gen/static_data.py
@@ -431,7 +431,1018 @@ offsets = {
 "MultiTexCoord4i": 404,
 "MultiTexCoord4iv": 405,
 "MultiTexCoord4s": 406,
-"MultiTexCoord4sv": 407
+"MultiTexCoord4sv": 407,
+"CompressedTexImage1D": 408,
+"CompressedTexImage2D": 409,
+"CompressedTexImage3D": 410,
+"CompressedTexSubImage1D": 411,
+"CompressedTexSubImage2D": 412,
+"CompressedTexSubImage3D": 413,
+"GetCompressedTexImage": 414,
+"LoadTransposeMatrixd": 415,
+"LoadTransposeMatrixf": 416,
+"MultTransposeMatrixd": 417,
+"MultTransposeMatrixf": 418,
+"SampleCoverage": 419,
+"BlendFuncSeparate": 420,
+"FogCoordPointer": 421,
+"FogCoordd": 422,
+"FogCoorddv": 423,
+"MultiDrawArrays": 424,
+"PointParameterf": 425,
+"PointParameterfv": 426,
+"PointParameteri": 427,
+"PointParameteriv": 428,
+"SecondaryColor3b": 429,
+"SecondaryColor3bv": 430,
+"SecondaryColor3d": 431,
+"SecondaryColor3dv": 432,
+"SecondaryColor3i": 433,
+"SecondaryColor3iv": 434,
+"SecondaryColor3s": 435,
+"SecondaryColor3sv": 436,
+"SecondaryColor3ub": 437,
+"SecondaryColor3ubv": 438,
+"SecondaryColor3ui": 439,
+"SecondaryColor3uiv": 440,
+"SecondaryColor3us": 441,
+"SecondaryColor3usv": 442,
+"SecondaryColorPointer": 443,
+"WindowPos2d": 444,
+"WindowPos2dv": 445,
+"WindowPos2f": 446,
+"WindowPos2fv": 447,
+"WindowPos2i": 448,
+"WindowPos2iv": 449,
+"WindowPos2s": 450,
+"WindowPos2sv": 451,
+"WindowPos3d": 452,
+"WindowPos3dv": 453,
+"WindowPos3f": 454,
+"WindowPos3fv": 455,
+"WindowPos3i": 456,
+"WindowPos3iv": 457,
+"WindowPos3s": 458,
+"WindowPos3sv": 459,
+"BeginQuery": 460,
+"BindBuffer": 461,
+"BufferData": 462,
+"BufferSubData": 463,
+"DeleteBuffers": 464,
+"DeleteQueries": 465,
+"EndQuery": 466,
+"GenBuffers": 467,
+"GenQueries": 468,
+"GetBufferParameteriv": 469,
+"GetBufferPointerv": 470,
+"GetBufferSubData": 471,
+"GetQueryObjectiv": 472,
+"GetQueryObjectuiv": 473,
+"GetQueryiv": 474,
+"IsBuffer": 475,
+"IsQuery": 476,
+"MapBuffer": 477,
+"UnmapBuffer": 478,
+"AttachShader": 479,
+"BindAttribLocation": 480,
+"BlendEquationSeparate": 481,
+"CompileShader": 482,
+"CreateProgram": 483,
+"CreateShader": 484,
+"DeleteProgram": 485,
+"DeleteShader": 486,
+"DetachShader": 487,
+"DisableVertexAttribArray": 488,
+"DrawBuffers": 489,
+"EnableVertexAttribArray": 490,
+"GetActiveAttrib": 491,
+"GetActiveUniform": 492,
+"GetAttachedShaders": 493,
+"GetAttribLocation": 494,
+"GetProgramInfoLog": 495,
+"GetProgramiv": 496,
+"GetShaderInfoLog": 497,
+"GetShaderSource": 498,
+"GetShaderiv": 499,
+"GetUniformLocation": 500,
+"GetUniformfv": 501,
+"GetUniformiv": 502,
+"GetVertexAttribPointerv": 503,
+"GetVertexAttribdv": 504,
+"GetVertexAttribfv": 505,
+"GetVertexAttribiv": 506,
+"IsProgram": 507,
+"IsShader": 508,
+"LinkProgram": 509,
+"ShaderSource": 510,
+"StencilFuncSeparate": 511,
+"StencilMaskSeparate": 512,
+"StencilOpSeparate": 513,
+"Uniform1f": 514,
+"Uniform1fv": 515,
+"Uniform1i": 516,
+"Uniform1iv": 517,
+"Uniform2f": 518,
+"Uniform2fv": 519,
+"Uniform2i": 520,
+"Uniform2iv": 521,
+"Uniform3f": 522,
+"Uniform3fv": 523,
+"Uniform3i": 524,
+"Uniform3iv": 525,
+"Uniform4f": 526,
+"Uniform4fv": 527,
+"Uniform4i": 528,
+"Uniform4iv": 529,
+"UniformMatrix2fv": 530,
+"UniformMatrix3fv": 531,
+"UniformMatrix4fv": 532,
+"UseProgram": 533,
+"ValidateProgram": 534,
+"VertexAttrib1d": 535,
+"VertexAttrib1dv": 536,
+"VertexAttrib1s": 537,
+"VertexAttrib1sv": 538,
+"VertexAttrib2d": 539,
+"VertexAttrib2dv": 540,
+"VertexAttrib2s": 541,
+"VertexAttrib2sv": 542,
+"VertexAttrib3d": 543,
+"VertexAttrib3dv": 544,
+"VertexAttrib3s": 545,
+"VertexAttrib3sv": 546,
+"VertexAttrib4Nbv": 547,
+"VertexAttrib4Niv": 548,
+"VertexAttrib4Nsv": 549,
+"VertexAttrib4Nub": 550,
+"VertexAttrib4Nubv": 551,
+"VertexAttrib4Nuiv": 552,
+"VertexAttrib4Nusv": 553,
+ 

[Mesa-dev] [PATCH 08/18] mapi/new: don't print info we don't need for ES1/ES2

[Emil Velikov]

There is no need for the noop function, the public_stubs table or table
size defines. Remove those.

Might what to look and merge this back to GLVND - from a quick look
they don't need them either.

Signed-off-by: Emil Velikov 
---
 src/mapi/new/gen_gldispatch_mapi.py | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/src/mapi/new/gen_gldispatch_mapi.py 
b/src/mapi/new/gen_gldispatch_mapi.py
index be7b7495909..b370559024d 100755
--- a/src/mapi/new/gen_gldispatch_mapi.py
+++ b/src/mapi/new/gen_gldispatch_mapi.py
@@ -63,9 +63,10 @@ typedef void (APIENTRY  *GLDEBUGPROCKHR)(GLenum 
source,GLenum type,GLuint id,GLe
 """.lstrip("\n"))
 
 print(generate_defines(functions))
-print(generate_table(functions, allFunctions))
-print(generate_noop_array(functions))
-print(generate_public_stubs(functions))
+if (target not in ("glesv1", "glesv2")):
+print(generate_table(functions, allFunctions))
+print(generate_noop_array(functions))
+print(generate_public_stubs(functions))
 print(generate_public_entries(functions))
 print(generate_stub_asm_gcc(functions))
 
-- 
2.19.1

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

[Mesa-dev] [PATCH 09/18] mapi/new: fixup the GLDEBUGPROCKHR typedef to the non KHR one

[Emil Velikov]

From: Emil Velikov 

This way we can reuse the latter, which is already present in the
headers that we use. Thus we can drop the manual typedef we generate.

We might want to merge this back in GLVND.

Signed-off-by: Emil Velikov 
---
 src/mapi/new/genCommon.py   | 1 +
 src/mapi/new/gen_gldispatch_mapi.py | 1 -
 2 files changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mapi/new/genCommon.py b/src/mapi/new/genCommon.py
index 4152ccab3f4..29cede96939 100644
--- a/src/mapi/new/genCommon.py
+++ b/src/mapi/new/genCommon.py
@@ -237,6 +237,7 @@ def _fixupTypeName(typeName):
 rv = 
re.sub(r"\b(GLhalf|GLintptr|GLsizeiptr|GLint64|GLuint64)(?:ARB|EXT|NV|ATI)\b", 
r"\1", rv)
 
 rv = re.sub(r"\bGLvoid\b", "void", rv)
+rv = re.sub(r"\bGLDEBUGPROCKHR\b", "GLDEBUGPROC", rv)
 
 # Clear out any leading and trailing whitespace.
 rv = rv.strip()
diff --git a/src/mapi/new/gen_gldispatch_mapi.py 
b/src/mapi/new/gen_gldispatch_mapi.py
index b370559024d..ac52388062c 100755
--- a/src/mapi/new/gen_gldispatch_mapi.py
+++ b/src/mapi/new/gen_gldispatch_mapi.py
@@ -58,7 +58,6 @@ def _main():
 #ifndef _GLAPI_TMP_H_
 #define _GLAPI_TMP_H_
 typedef int GLclampx;
-typedef void (APIENTRY  *GLDEBUGPROCKHR)(GLenum source,GLenum type,GLuint 
id,GLenum severity,GLsizei length,const GLchar *message,const void *userParam);
 #endif /* _GLAPI_TMP_H_ */
 """.lstrip("\n"))
 
-- 
2.19.1

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

[Mesa-dev] [PATCH 01/18] mapi: sort static entrypoints numerically

[Emil Velikov]

From: Emil Velikov 

A few of the entrypoints were incorrectly placed. Sort those to align
with the rest of the list.

Signed-off-by: Emil Velikov 
---
 src/mapi/glapi/gen/static_data.py | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/src/mapi/glapi/gen/static_data.py 
b/src/mapi/glapi/gen/static_data.py
index 7a8933b8d78..0596d2cd3bb 100644
--- a/src/mapi/glapi/gen/static_data.py
+++ b/src/mapi/glapi/gen/static_data.py
@@ -331,33 +331,33 @@ offsets = {
 "Translatef": 304,
 "Viewport": 305,
 "ArrayElement": 306,
+"BindTexture": 307,
 "ColorPointer": 308,
 "DisableClientState": 309,
 "DrawArrays": 310,
 "DrawElements": 311,
 "EdgeFlagPointer": 312,
 "EnableClientState": 313,
-"GetPointerv": 329,
 "IndexPointer": 314,
+"Indexub": 315,
+"Indexubv": 316,
 "InterleavedArrays": 317,
 "NormalPointer": 318,
+"PolygonOffset": 319,
 "TexCoordPointer": 320,
 "VertexPointer": 321,
-"PolygonOffset": 319,
+"AreTexturesResident": 322,
 "CopyTexImage1D": 323,
 "CopyTexImage2D": 324,
 "CopyTexSubImage1D": 325,
 "CopyTexSubImage2D": 326,
-"TexSubImage1D": 332,
-"TexSubImage2D": 333,
-"AreTexturesResident": 322,
-"BindTexture": 307,
 "DeleteTextures": 327,
 "GenTextures": 328,
+"GetPointerv": 329,
 "IsTexture": 330,
 "PrioritizeTextures": 331,
-"Indexub": 315,
-"Indexubv": 316,
+"TexSubImage1D": 332,
+"TexSubImage2D": 333,
 "PopClientAttrib": 334,
 "PushClientAttrib": 335,
 "BlendColor": 336,
-- 
2.19.1

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