Re: [Mesa-dev] [PATCH 6/6] radeonsi: always unmap texture CPU mappings on 32-bit CPU architectures

[Marek Olšák]

I don't plan to do anything else if this patch is enough to fix certain
32-bit games.

Marek

On Fri, Dec 14, 2018 at 6:10 PM Axel Davy  wrote:

> Hi Marek,
>
> That seems a good idea.
> Several 32bits games have virtual address space issues as well with both
> Nine and Wine (but Nine seems a bit more affected because more libs are
> loaded).
>
> Maybe the patch could go a little bit further by doing the same for
> buffers the first time they si_buffer_transfer_unmap is called for them ?
>
> I've seen several nine games use a few big buffers (in DEFAULT pool) to
> store quite a lot of vertices,
> in addition to the buffers frequently written to for rendering.
>
> Unmapping those big buffers, that we are never going to write to again,
> could save a bit of that precious virtual space.
>
> The safest test I believe, is to look only at buffers that are written
> to only once, thus always unmapping on first unmap.
> For the buffers often written to, the cost of the first unmap will be
> negligible.
>
> What do you think ?
>
> Axel
>
> On 14/12/2018 22:24, Marek Olšák wrote:
> > From: Marek Olšák 
> >
> > Team Fortress 2 32-bit version runs out of the CPU address space.
> > ---
> >   src/gallium/drivers/radeonsi/si_texture.c | 16 
> >   1 file changed, 16 insertions(+)
> >
> > diff --git a/src/gallium/drivers/radeonsi/si_texture.c
> b/src/gallium/drivers/radeonsi/si_texture.c
> > index 95f1e8c9693..39869445b0f 100644
> > --- a/src/gallium/drivers/radeonsi/si_texture.c
> > +++ b/src/gallium/drivers/radeonsi/si_texture.c
> > @@ -1791,20 +1791,26 @@ static void *si_texture_transfer_map(struct
> pipe_context *ctx,
> >
> >   buf = trans->staging;
> >   } else {
> >   /* the resource is mapped directly */
> >   offset = si_texture_get_offset(sctx->screen, tex, level,
> box,
> >>b.b.stride,
> >>b.b.layer_stride);
> >   buf = >buffer;
> >   }
> >
> > + /* Always unmap texture CPU mappings on 32-bit architectures, so
> that
> > +  * we don't run out of the CPU address space.
> > +  */
> > + if (sizeof(void*) == 4)
> > + usage |= RADEON_TRANSFER_TEMPORARY;
> > +
> >   if (!(map = si_buffer_map_sync_with_rings(sctx, buf, usage)))
> >   goto fail_trans;
> >
> >   *ptransfer = >b.b;
> >   return map + offset;
> >
> >   fail_trans:
> >   r600_resource_reference(>staging, NULL);
> >   pipe_resource_reference(>b.b.resource, NULL);
> >   FREE(trans);
> > @@ -1812,20 +1818,30 @@ fail_trans:
> >   }
> >
> >   static void si_texture_transfer_unmap(struct pipe_context *ctx,
> > struct pipe_transfer* transfer)
> >   {
> >   struct si_context *sctx = (struct si_context*)ctx;
> >   struct si_transfer *stransfer = (struct si_transfer*)transfer;
> >   struct pipe_resource *texture = transfer->resource;
> >   struct si_texture *tex = (struct si_texture*)texture;
> >
> > + /* Always unmap texture CPU mappings on 32-bit architectures, so
> that
> > +  * we don't run out of the CPU address space.
> > +  */
> > + if (sizeof(void*) == 4) {
> > + struct r600_resource *buf =
> > + stransfer->staging ? stransfer->staging :
> >buffer;
> > +
> > + sctx->ws->buffer_unmap(buf->buf);
> > + }
> > +
> >   if ((transfer->usage & PIPE_TRANSFER_WRITE) && stransfer->staging)
> {
> >   if (tex->is_depth && tex->buffer.b.b.nr_samples <= 1) {
> >   ctx->resource_copy_region(ctx, texture,
> transfer->level,
> > transfer->box.x,
> transfer->box.y, transfer->box.z,
> >
>  >staging->b.b, transfer->level,
> > >box);
> >   } else {
> >   si_copy_from_staging_texture(ctx, stransfer);
> >   }
> >   }
>
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 4/4] nir: link time opt duplicate varyings

[Marek Olšák]

On Fri, Dec 14, 2018 at 9:16 PM Timothy Arceri 
wrote:

> On 15/12/18 7:32 am, Marek Olšák wrote:
> > For patches 1-3:
> >
> > Reviewed-by: Marek Olšák  marek.ol...@amd.com>>
> >
>
> Thanks!
>
> > I'm not so knowledgeable to be able to comment on patch 4.
> >
> > Does it also merge varyings such as (x,y,undef,undef) and
> > (x,undef,undef,w)? There is a game which outputs (x,y,z,undef) and
> > (x,y,undef,undef) where the vertex shader is a SSO.
>
> No. All of the link-time optimisations in NIR are currently only applied
> at actual link-time. I've often thought about adding a way to apply
> these to SSO shaders but this is unlikely something I will end up
> working on since our main focus these days is on Vulkan and there we
> always link the entire pipeline so its not an issue.
>

RadeonSI can also always link entire pipelines. I have code that does it
using asynchronous compilation. However, the amount of time to compile
everything is crazy, and even though I don't get any stutters, all CPU
cores are at 100% for quite some time. I guess DXVK suffers from the same
problem and so DX10/11 would greatly benefit from a native DX11 driver
(e.g. gallium).

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

Re: [Mesa-dev] [PATCH 1/3] nv50/ir: clean up src2 in ConstantFolding

[Ilia Mirkin]

On Fri, Dec 14, 2018 at 6:12 PM Karol Herbst  wrote:
>
> no changes in shader-db
>
> Signed-off-by: Karol Herbst 
> ---
>  src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp 
> b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
> index 5d3b4aba9cc..a8bd4f868bf 100644
> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
> @@ -763,6 +763,7 @@ ConstantFolding::expr(Instruction *i,
>i->op = i->saturate ? OP_SAT : OP_MOV;
>if (i->saturate)
>   unary(i, *i->getSrc(0)->asImm());
> +  i->setSrc(2, NULL);

Please preface this with a

if (i->srcExists(2)) ...

Otherwise it'll grow the array everywhere for nothing. This is just
for SLCT right? I don't think any other 3-operand ops would fall
through to here... this also seems a bit dangerous if an instruction
coming here might be predicated (which they usually wouldn't be until
later, but I think there are some flows where this could happen).

So I'd rather be explicit about which ops this is done for.
Unfortunately we don't have a map that tells us how many "regular"
operands an instruction should have... Looking over the list, I think
it's just OP_SLCT.

  -ilia

>break;
> }
> i->subOp = 0;
> --
> 2.19.2
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 4/4] nir: link time opt duplicate varyings

[Timothy Arceri]

On 15/12/18 1:16 pm, Timothy Arceri wrote:

On 15/12/18 7:32 am, Marek Olšák wrote:

For patches 1-3:

Reviewed-by: Marek Olšák >




Thanks!


I'm not so knowledgeable to be able to comment on patch 4.

Does it also merge varyings such as (x,y,undef,undef) and 
(x,undef,undef,w)? There is a game which outputs (x,y,z,undef) and 
(x,y,undef,undef) where the vertex shader is a SSO.


No. All of the link-time optimisations in NIR are currently only applied 
at actual link-time. I've often thought about adding a way to apply 
these to SSO shaders but this is unlikely something I will end up 
working on since our main focus these days is on Vulkan and there we 
always link the entire pipeline so its not an issue.




Just to be clear. The exiting NIR link-time optimisations we have will 
already convert (x,y,undef,undef) and (x,undef,undef,w) to (x,y,x,w).


This pass just takes things further, eliminating components holding the 
same value if we can detect it.

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

Re: [Mesa-dev] [PATCH 4/4] nir: link time opt duplicate varyings

[Timothy Arceri]

On 15/12/18 7:32 am, Marek Olšák wrote:

For patches 1-3:

Reviewed-by: Marek Olšák mailto:marek.ol...@amd.com>>



Thanks!


I'm not so knowledgeable to be able to comment on patch 4.

Does it also merge varyings such as (x,y,undef,undef) and 
(x,undef,undef,w)? There is a game which outputs (x,y,z,undef) and 
(x,y,undef,undef) where the vertex shader is a SSO.


No. All of the link-time optimisations in NIR are currently only applied 
at actual link-time. I've often thought about adding a way to apply 
these to SSO shaders but this is unlikely something I will end up 
working on since our main focus these days is on Vulkan and there we 
always link the entire pipeline so its not an issue.




Marek

On Mon, Dec 10, 2018 at 11:28 PM Timothy Arceri > wrote:


If we are outputting the same value to more than one output
component rewrite the inputs to read from a single component.

This will allow the duplicate varying components to be optimised
away by the existing opts.

shader-db results i965 (SKL):

total instructions in shared programs: 12869230 -> 12860886 (-0.06%)
instructions in affected programs: 322601 -> 314257 (-2.59%)
helped: 3080
HURT: 8

total cycles in shared programs: 317792574 -> 317730593 (-0.02%)
cycles in affected programs: 2584925 -> 2522944 (-2.40%)
helped: 2975
HURT: 477

shader-db results radeonsi (VEGA):

Totals from affected shaders:
SGPRS: 30960 -> 31056 (0.31 %)
VGPRS: 17052 -> 16672 (-2.23 %)
Spilled SGPRs: 184 -> 167 (-9.24 %)
Spilled VGPRs: 0 -> 0 (0.00 %)
Private memory VGPRs: 0 -> 0 (0.00 %)
Scratch size: 0 -> 0 (0.00 %) dwords per thread
Code Size: 562532 -> 549404 (-2.33 %) bytes
LDS: 0 -> 0 (0.00 %) blocks
Max Waves: 6011 -> 6110 (1.65 %)
Wait states: 0 -> 0 (0.00 %)

vkpipeline-db results RADV (VEGA):

Totals from affected shaders:
SGPRS: 14880 -> 15080 (1.34 %)
VGPRS: 10872 -> 10888 (0.15 %)
Spilled SGPRs: 0 -> 0 (0.00 %)
Spilled VGPRs: 0 -> 0 (0.00 %)
Private memory VGPRs: 0 -> 0 (0.00 %)
Scratch size: 0 -> 0 (0.00 %) dwords per thread
Code Size: 674016 -> 668396 (-0.83 %) bytes
LDS: 0 -> 0 (0.00 %) blocks
Max Waves: 2708 -> 2704 (-0.15 %)
Wait states: 0 -> 0 (0.00 %
---
  src/compiler/nir/nir_linking_helpers.c | 95 ++
  1 file changed, 95 insertions(+)

diff --git a/src/compiler/nir/nir_linking_helpers.c
b/src/compiler/nir/nir_linking_helpers.c
index 37644d339f..bdfa7b8c4d 100644
--- a/src/compiler/nir/nir_linking_helpers.c
+++ b/src/compiler/nir/nir_linking_helpers.c
@@ -700,6 +700,27 @@ nir_link_xfb_varyings(nir_shader *producer,
nir_shader *consumer)
     }
  }

+static nir_variable *
+get_matching_input_var(nir_shader *consumer, nir_variable *out_var)
+{
+   nir_variable *input_var = NULL;
+   nir_foreach_variable(var, >inputs) {
+      if (var->data.location >= VARYING_SLOT_VAR0 &&
+          var->data.location - VARYING_SLOT_VAR0 < MAX_VARYING) {
+
+         if (var->data.location == out_var->data.location &&
+             var->data.location_frac == out_var->data.location_frac &&
+             var->data.interpolation == out_var->data.interpolation &&
+             get_interp_loc(var) == get_interp_loc(out_var)) {
+            input_var = var;
+            break;
+         }
+      }
+   }
+
+   return input_var;
+}
+
  static bool
  can_replace_varying(nir_variable *out_var, nir_intrinsic_instr
*store_intr)
  {
@@ -782,6 +803,57 @@ try_replace_constant_input(nir_shader *shader,
     return progress;
  }

+static bool
+try_replace_duplicate_input(nir_shader *shader, nir_variable
*input_var,
+                            nir_intrinsic_instr *dup_store_intr)
+{
+   assert(input_var);
+
+   nir_variable *dup_out_var =
+ 
nir_deref_instr_get_variable(nir_src_as_deref(dup_store_intr->src[0]));

+
+   if (!can_replace_varying(dup_out_var, dup_store_intr))
+      return false;
+
+   nir_function_impl *impl = nir_shader_get_entrypoint(shader);
+
+   nir_builder b;
+   nir_builder_init(, impl);
+
+   bool progress = false;
+   nir_foreach_block(block, impl) {
+      nir_foreach_instr(instr, block) {
+         if (instr->type != nir_instr_type_intrinsic)
+            continue;
+
+         nir_intrinsic_instr *intr = nir_instr_as_intrinsic(instr);
+         if (intr->intrinsic != nir_intrinsic_load_deref)
+            continue;
+
+         nir_variable *in_var =
+   
nir_deref_instr_get_variable(nir_src_as_deref(intr->src[0]));

+
+         if (in_var->data.mode != nir_var_shader_in)
+            continue;
+
+         if (in_var->data.location != 

[Mesa-dev] [PATCH] st/mesa: remove sampler associated with buffer texture in pbo logic

[Ilia Mirkin]

A long time ago, when this was first implemented, not having a sampler
bound would cause problems on Fermi. I didn't work out the reasons, but
the solution was simple -- just put the samplers back in.

Since then, regular texturing paths appear to have lost their associated
samplers which required a fuller investigation and fix in nouveau. Now
that this is done, this code should no longer need a sampler state for
fetching texels from a buffer texture.

Signed-off-by: Ilia Mirkin 
---

This was introduced in 2b938a390 which fixed a number of legitimate
issues, as well as this which ultimately was an issue in nouveau which
in turn were fixed in 153d3fc5f9.

At the time this was the only way for the condition to occur. However
now more bits have changed and a txf on a buffer could end up happening
without a sampler bound under "usual" circumstances, which necessitated
an investigation and proper fix.

 src/mesa/state_tracker/st_cb_texture.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/src/mesa/state_tracker/st_cb_texture.c 
b/src/mesa/state_tracker/st_cb_texture.c
index b8cc616d8f2..45918e425ac 100644
--- a/src/mesa/state_tracker/st_cb_texture.c
+++ b/src/mesa/state_tracker/st_cb_texture.c
@@ -1192,7 +1192,6 @@ try_pbo_upload_common(struct gl_context *ctx,
   return false;
 
cso_save_state(cso, (CSO_BIT_FRAGMENT_SAMPLER_VIEWS |
-CSO_BIT_FRAGMENT_SAMPLERS |
 CSO_BIT_VERTEX_ELEMENTS |
 CSO_BIT_AUX_VERTEX_BUFFER_SLOT |
 CSO_BIT_FRAMEBUFFER |
@@ -1216,8 +1215,6 @@ try_pbo_upload_common(struct gl_context *ctx,
{
   struct pipe_sampler_view templ;
   struct pipe_sampler_view *sampler_view;
-  struct pipe_sampler_state sampler = {0};
-  const struct pipe_sampler_state *samplers[1] = {};
 
   memset(, 0, sizeof(templ));
   templ.target = PIPE_BUFFER;
@@ -1237,8 +1234,6 @@ try_pbo_upload_common(struct gl_context *ctx,
   cso_set_sampler_views(cso, PIPE_SHADER_FRAGMENT, 1, _view);
 
   pipe_sampler_view_reference(_view, NULL);
-
-  cso_set_samplers(cso, PIPE_SHADER_FRAGMENT, 1, samplers);
}
 
/* Framebuffer_state */
-- 
2.18.1

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

[Mesa-dev] SPIR-V: Use NIR deref instructions for UBO/SSBO access

[Jason Ekstrand]

New MR: https://gitlab.freedesktop.org/mesa/mesa/merge_requests/17

This MR begins the process of being able to optimize external memory access
by first moving us over to using deref instructions for UBO/SSBO access.

Many of the patches are cleanups or fairly small refactors of NIR or
SPIR-V. More notable changes include:

Reworking some NIR variable modes to properly distinguish between UBOs
and other uniforms
Adding support to glsl_type for explicit strides/offsets on types.
Adding a new ptr-as-array deref type to NIR
Adding a new nir_opt_deref pass to optimize ptr-as-array derefs
Relaxing several NIR validation rules
Adding support for cast derefs to a couple of passes
Adding UBO/SSBO deref support to spirv_to_nir but hidden behind a flag
Enabling the new path in ANV.

All in all, I think I finally have a version of this that I'm actually
happy with. It took several iterations to figure out how I wanted to best
describe the type information coming out of SPIR-V. The glsl_type
modifications ended up being not nearly as bad as I expected so I went that
route.

Happy reviewing!

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

[Mesa-dev] [PATCH] i965: Don't override subslice count to 4 on Gen11.

[Kenneth Graunke]

Gen9-10 have fewer than 4 subslices per slice, so they need this to be
rounded up.  Gen11 isn't documented as needing this hack, and it can
also have more than 4 subslices, so the hack actually can break things.
---
 src/mesa/drivers/dri/i965/brw_program.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

I have not tested this patch.  I made the equivalent change to iris and
it fixed some geometry shader tests that were spilling (but don't spill
on i965 - that's a compiler quality regression I have yet to fix)

diff --git a/src/mesa/drivers/dri/i965/brw_program.c 
b/src/mesa/drivers/dri/i965/brw_program.c
index 96247f32f0f..730d6dc0d5a 100644
--- a/src/mesa/drivers/dri/i965/brw_program.c
+++ b/src/mesa/drivers/dri/i965/brw_program.c
@@ -407,7 +407,7 @@ brw_alloc_stage_scratch(struct brw_context *brw,
* and we wish to view that there are 4 subslices per slice
* instead of the actual number of subslices per slice.
*/
-  if (devinfo->gen >= 9)
+  if (devinfo->gen >= 9 && devinfo->gen < 11)
  subslices = 4 * brw->screen->devinfo.num_slices;
 
   unsigned scratch_ids_per_subslice;
-- 
2.19.1

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

Re: [Mesa-dev] last call for autotools

[Dylan Baker]

Quoting Dave Airlie (2018-12-14 12:27:35)
> On Fri, 14 Dec 2018 at 16:19, Ilia Mirkin  wrote:
> >
> > I have to say that the user experience for autotools is WAY better
> > than for meson. As a concrete example, I had a meson build. Then I
> > updated meson (0.48.1 to 0.48.2). Now ninja -C foo doesn't work. meson
> > --reconfigure (which presumably is what ninja would end up running)
> > doesn't work. http://paste.debian.net/hidden/cf777f3e/
> >
> > So now what? I don't remember how that config was done, except that it
> > was done the way I decided I needed it at the time. I have no way to
> > recover it. With autotools, in such cases (which are immensely rare),
> > you just run "head config.log" and it tells you what you did last
> > time. And by updating the build component, now I have to rebuild
> > EVERYTHING?
> >
> > meson is not at a point where it Just Works. It ... sometimes works.
> > The fact that everyone has scripts which wrap meson is a symptom of
> > that. I don't feel good about dumping the system that everyone (and I
> > don't just mean people on this list -- I mean the wider open source
> > community as well) knows how to use and has worked reliably for years
> > (decades, really) to be replaced by a system that everyone is having
> > problems with (it's not just me -- others are running into trouble too
> > -- just look at this thread). It's just not ready yet.
> >
> 
> I've kinda stayed out of this discussion as I wanted to see which way
> the wind was blowing, and I like to tune my workflows to the project
> not vice-versa as much as possible.
> 
> At this point I don't like using meson in my workflows for two main
> reasons: (mostly like Ilia)
> 
> a) meson upgrades crap out my builddirs. (0.49 will fix it? then yay
> when 0.49 lands in distros, I'll consider this done)

This is supposed to be fixed in 0.49.0.

> b) I can't extract either the original configuration line or even a
> give me a command line to reproduce the current state so I can cut and
> paste it.

The fix for a) stores the information to get the configuration back (it's in an
ini file, so not great for readability). I can write a patch to print the line
in a printable form.

Dylan


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

[Mesa-dev] [PATCH 3/3] nv50/ir: convert slct with boolean result to set

[Karol Herbst]

From: Karol Herbst 

helps mainly feral ported games

changes in shader-db:
total instructions in shared programs : 7565661 -> 7545812 (-0.26%)
total gprs used in shared programs: 797213 -> 797088 (-0.02%)
total shared used in shared programs  : 639636 -> 639636 (0.00%)
total local used in shared programs   : 24648 -> 24648 (0.00%)
total bytes used in shared programs   : 80806160 -> 80594056 (-0.26%)

local sharedgpr   inst  bytes
helped  0  0103   5049   5049
  hurt  0  0 29  0  0

Signed-off-by: Karol Herbst 
---
 .../nouveau/codegen/nv50_ir_peephole.cpp  | 50 +++
 1 file changed, 50 insertions(+)

diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
index 37e9edc49f4..b62dee675ce 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
@@ -372,6 +372,8 @@ private:
void expr(Instruction *, ImmediateValue&, ImmediateValue&, ImmediateValue&);
/* true if i was deleted */
bool opnd(Instruction *i, ImmediateValue&, int s);
+   /* 3 srcs where 1st and 2nd are immediates */
+   void opnd(Instruction *, ImmediateValue&, ImmediateValue&);
void opnd3(Instruction *, ImmediateValue&);
 
void unary(Instruction *, const ImmediateValue&);
@@ -432,6 +434,10 @@ ConstantFolding::visit(BasicBlock *bb)
   }
   if (i->srcExists(2) && i->src(2).getImmediate(src2))
  opnd3(i, src2);
+  else
+  if (i->srcExists(2) &&
+  i->src(0).getImmediate(src0) && i->src(1).getImmediate(src1))
+ opnd(i, src0, src1);
}
return true;
 }
@@ -935,6 +941,50 @@ ConstantFolding::tryCollapseChainedMULs(Instruction *mul2,
}
 }
 
+void
+ConstantFolding::opnd(Instruction *i, ImmediateValue , ImmediateValue 
)
+{
+   const Storage  = imm0.reg;
+   const Storage  = imm1.reg;
+
+   switch (i->op) {
+   case OP_SLCT: {
+  CmpInstruction *slct = i->asCmp();
+  if (a.data.u32 == 0x && b.data.u32 == 0x0) {
+ slct->setSrc(0, slct->getSrc(2));
+ slct->setSrc(2, NULL);
+ slct->dType = TYPE_U32;
+ slct->op = OP_SET;
+  }
+  else if (a.data.u32 == 0x3f80 && b.data.u32 == 0x0) {
+ slct->setSrc(0, slct->getSrc(2));
+ slct->setSrc(2, NULL);
+ slct->dType = TYPE_F32;
+ slct->op = OP_SET;
+  }
+  else if (a.data.u32 == 0x0 && b.data.u32 == 0x) {
+ slct->swapSources(0, 1);
+ slct->setSrc(0, slct->getSrc(2));
+ slct->setSrc(2, NULL);
+ slct->dType = TYPE_U32;
+ slct->setCondition(inverseCondCode(slct->getCondition()));
+ slct->op = OP_SET;
+  }
+  else if (a.data.u32 == 0x0 && b.data.u32 == 0x3f80) {
+ slct->swapSources(0, 1);
+ slct->setSrc(0, slct->getSrc(2));
+ slct->setSrc(2, NULL);
+ slct->dType = TYPE_F32;
+ slct->setCondition(inverseCondCode(slct->getCondition()));
+ slct->op = OP_SET;
+  }
+  break;
+   }
+   default:
+  break;
+   }
+}
+
 void
 ConstantFolding::opnd3(Instruction *i, ImmediateValue )
 {
-- 
2.19.2

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

[Mesa-dev] [PATCH 2/3] nv50/ir: optimize slct(b, c, set(a, 0)) to slct(b, c, a)

[Karol Herbst]

From: Karol Herbst 

helps mainly feral ported games

shader-db changes:
total instructions in shared programs : 7614782 -> 7565661 (-0.65%)
total gprs used in shared programs: 798045 -> 797213 (-0.10%)
total shared used in shared programs  : 639636 -> 639636 (0.00%)
total local used in shared programs   : 24648 -> 24648 (0.00%)
total bytes used in shared programs   : 81330696 -> 80806160 (-0.64%)

local sharedgpr   inst  bytes
helped  0  0701   7940   7940
  hurt  0  0 44  4  4

Signed-off-by: Karol Herbst 
---
 .../nouveau/codegen/nv50_ir_peephole.cpp  | 47 +--
 1 file changed, 44 insertions(+), 3 deletions(-)

diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
index a8bd4f868bf..37e9edc49f4 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
@@ -1763,7 +1763,8 @@ private:
bool tryADDToMADOrSAD(Instruction *, operation toOp);
void handleMINMAX(Instruction *);
void handleRCP(Instruction *);
-   void handleSLCT(Instruction *);
+   void handleSLCT(CmpInstruction *);
+   bool tryMergeSLCTSET(CmpInstruction *slct, CmpInstruction *set);
void handleLOGOP(Instruction *);
void handleCVT_NEG(Instruction *);
void handleCVT_CVT(Instruction *);
@@ -1956,8 +1957,12 @@ AlgebraicOpt::handleRCP(Instruction *rcp)
 }
 
 void
-AlgebraicOpt::handleSLCT(Instruction *slct)
+AlgebraicOpt::handleSLCT(CmpInstruction *slct)
 {
+   Instruction *insn = slct->getSrc(2)->getInsn();
+   while(insn && insn->op == OP_SET && tryMergeSLCTSET(slct, insn->asCmp())) {
+  insn = slct->getSrc(2)->getInsn();
+   }
if (slct->getSrc(2)->reg.file == FILE_IMMEDIATE) {
   if (slct->getSrc(2)->asImm()->compare(slct->asCmp()->setCond, 0.0f))
  slct->setSrc(0, slct->getSrc(1));
@@ -1970,6 +1975,42 @@ AlgebraicOpt::handleSLCT(Instruction *slct)
slct->setSrc(2, NULL);
 }
 
+bool
+AlgebraicOpt::tryMergeSLCTSET(CmpInstruction *slct, CmpInstruction *set)
+{
+   assert(slct->op == OP_SLCT && set->op == OP_SET);
+
+   if (typeSizeof(set->sType) != 4)
+  return false;
+
+   CondCode setCC = set->getCondition();
+   CondCode slctCC = slct->getCondition();
+   CondCode newCC = setCC;
+
+   if (slctCC != CC_NE && slctCC != CC_EQ)
+  return false;
+
+   ImmediateValue imm0;
+   int s;
+
+   if (set->src(0).getImmediate(imm0) && imm0.isInteger(0))
+  s = 1;
+   else if (set->src(1).getImmediate(imm0) && imm0.isInteger(0))
+  s = 0;
+   else
+  return false;
+
+   slct->setSrc(2, set->getSrc(s));
+   if (s)
+  newCC = reverseCondCode(newCC);
+   if (slctCC == CC_EQ)
+  newCC = inverseCondCode(newCC);
+
+   slct->sType = set->sType;
+   slct->setCondition(newCC);
+   return true;
+}
+
 void
 AlgebraicOpt::handleLOGOP(Instruction *logop)
 {
@@ -2340,7 +2381,7 @@ AlgebraicOpt::visit(BasicBlock *bb)
  handleMINMAX(i);
  break;
   case OP_SLCT:
- handleSLCT(i);
+ handleSLCT(i->asCmp());
  break;
   case OP_AND:
   case OP_OR:
-- 
2.19.2

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

[Mesa-dev] [PATCH 1/3] nv50/ir: clean up src2 in ConstantFolding

[Karol Herbst]

no changes in shader-db

Signed-off-by: Karol Herbst 
---
 src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
index 5d3b4aba9cc..a8bd4f868bf 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
@@ -763,6 +763,7 @@ ConstantFolding::expr(Instruction *i,
   i->op = i->saturate ? OP_SAT : OP_MOV;
   if (i->saturate)
  unary(i, *i->getSrc(0)->asImm());
+  i->setSrc(2, NULL);
   break;
}
i->subOp = 0;
-- 
2.19.2

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

Re: [Mesa-dev] [PATCH 6/6] radeonsi: always unmap texture CPU mappings on 32-bit CPU architectures

[Axel Davy]

Hi Marek,

That seems a good idea.
Several 32bits games have virtual address space issues as well with both 
Nine and Wine (but Nine seems a bit more affected because more libs are 
loaded).


Maybe the patch could go a little bit further by doing the same for 
buffers the first time they si_buffer_transfer_unmap is called for them ?


I've seen several nine games use a few big buffers (in DEFAULT pool) to 
store quite a lot of vertices,

in addition to the buffers frequently written to for rendering.

Unmapping those big buffers, that we are never going to write to again, 
could save a bit of that precious virtual space.


The safest test I believe, is to look only at buffers that are written 
to only once, thus always unmapping on first unmap.
For the buffers often written to, the cost of the first unmap will be 
negligible.


What do you think ?

Axel

On 14/12/2018 22:24, Marek Olšák wrote:

From: Marek Olšák 

Team Fortress 2 32-bit version runs out of the CPU address space.
---
  src/gallium/drivers/radeonsi/si_texture.c | 16 
  1 file changed, 16 insertions(+)

diff --git a/src/gallium/drivers/radeonsi/si_texture.c 
b/src/gallium/drivers/radeonsi/si_texture.c
index 95f1e8c9693..39869445b0f 100644
--- a/src/gallium/drivers/radeonsi/si_texture.c
+++ b/src/gallium/drivers/radeonsi/si_texture.c
@@ -1791,20 +1791,26 @@ static void *si_texture_transfer_map(struct 
pipe_context *ctx,
  
  		buf = trans->staging;

} else {
/* the resource is mapped directly */
offset = si_texture_get_offset(sctx->screen, tex, level, box,
 >b.b.stride,
 >b.b.layer_stride);
buf = >buffer;
}
  
+	/* Always unmap texture CPU mappings on 32-bit architectures, so that

+* we don't run out of the CPU address space.
+*/
+   if (sizeof(void*) == 4)
+   usage |= RADEON_TRANSFER_TEMPORARY;
+
if (!(map = si_buffer_map_sync_with_rings(sctx, buf, usage)))
goto fail_trans;
  
  	*ptransfer = >b.b;

return map + offset;
  
  fail_trans:

r600_resource_reference(>staging, NULL);
pipe_resource_reference(>b.b.resource, NULL);
FREE(trans);
@@ -1812,20 +1818,30 @@ fail_trans:
  }
  
  static void si_texture_transfer_unmap(struct pipe_context *ctx,

  struct pipe_transfer* transfer)
  {
struct si_context *sctx = (struct si_context*)ctx;
struct si_transfer *stransfer = (struct si_transfer*)transfer;
struct pipe_resource *texture = transfer->resource;
struct si_texture *tex = (struct si_texture*)texture;
  
+	/* Always unmap texture CPU mappings on 32-bit architectures, so that

+* we don't run out of the CPU address space.
+*/
+   if (sizeof(void*) == 4) {
+   struct r600_resource *buf =
+   stransfer->staging ? stransfer->staging : >buffer;
+
+   sctx->ws->buffer_unmap(buf->buf);
+   }
+
if ((transfer->usage & PIPE_TRANSFER_WRITE) && stransfer->staging) {
if (tex->is_depth && tex->buffer.b.b.nr_samples <= 1) {
ctx->resource_copy_region(ctx, texture, transfer->level,
  transfer->box.x, 
transfer->box.y, transfer->box.z,
  >staging->b.b, 
transfer->level,
  >box);
} else {
si_copy_from_staging_texture(ctx, stransfer);
}
}



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

Re: [Mesa-dev] [PATCH v2 07/24] mapi: move genCommon.py to src/mapi/new

[Emil Velikov]

On Fri, 14 Dec 2018 at 14:33, Erik Faye-Lund
 wrote:
>
> On Fri, 2018-12-14 at 14:04 +, Emil Velikov wrote:
> > From: Emil Velikov 
> >
> > The helper will also be used by the new Khronos gl.xml aware
> > generator.
> >
> > v2: Move existing one, instead of duplicating it.
> >
> > Suggested-by: Kyle Brenneman 
> > Signed-off-by: Emil Velikov 
> > ---
> >  src/egl/Makefile.am | 6 --
> >  src/egl/generate/gen_egl_dispatch.py| 3 +++
> >  src/egl/meson.build | 4 ++--
> >  src/mapi/Makefile.am| 1 +
> >  src/mapi/meson.build| 1 +
> >  src/{egl/generate => mapi/new}/genCommon.py | 0
> >  6 files changed, 11 insertions(+), 4 deletions(-)
> >  rename src/{egl/generate => mapi/new}/genCommon.py (100%)
> >
> > diff --git a/src/egl/Makefile.am b/src/egl/Makefile.am
> > index 7269912d96f..6ce51936b16 100644
> > --- a/src/egl/Makefile.am
> > +++ b/src/egl/Makefile.am
> > @@ -136,8 +136,10 @@ libEGL_common_la_LIBADD += \
> >   $(LIBDRM_LIBS) \
> >   $(CLOCK_LIB)
> >
> > -GLVND_GEN_DEPS = generate/gen_egl_dispatch.py \
> > - generate/egl.xml generate/eglFunctionList.py
> > generate/genCommon.py \
> > +GLVND_GEN_DEPS = $(top_scrdir)/src/mapi/new/generate/genCommon.py \
> > + generate/gen_egl_dispatch.py \
> > + generate/eglFunctionList.py \
> > + generate/egl.xml \
> >   generate/egl_other.xml
> >
> >  PYTHON_GEN = $(AM_V_GEN)$(PYTHON) $(PYTHON_FLAGS)
> > diff --git a/src/egl/generate/gen_egl_dispatch.py
> > b/src/egl/generate/gen_egl_dispatch.py
> > index eeb3f3f9a5a..728799e9754 100644
> > --- a/src/egl/generate/gen_egl_dispatch.py
> > +++ b/src/egl/generate/gen_egl_dispatch.py
> > @@ -38,6 +38,9 @@ import imp
> >  import sys
> >  import textwrap
> >
> > +import os
> > +NEWAPI = os.path.join(os.path.dirname(__file__), "..", "..", "mapi",
> > "new")
> > +sys.path.insert(0, NEWAPI)
> >  import genCommon
> >
> >  def main():
> > diff --git a/src/egl/meson.build b/src/egl/meson.build
> > index 89bac2cd633..33f24dec5e2 100644
> > --- a/src/egl/meson.build
> > +++ b/src/egl/meson.build
> > @@ -69,7 +69,7 @@ g_egldispatchstubs_c = custom_target(
> >command : [
> >  prog_python, '@INPUT0@', 'source', '@INPUT1@', '@INPUT2@',
> > '@INPUT3@'
> >],
> > -  depend_files : files('generate/genCommon.py'),
> > +  depend_files : glapi_gen_mapi_py,
> >capture : true,
> >  )
> >
> > @@ -83,7 +83,7 @@ g_egldispatchstubs_h = custom_target(
> >command : [
> >  prog_python, '@INPUT0@', 'header', '@INPUT1@', '@INPUT2@',
> > '@INPUT3@'
> >],
> > -  depend_files : files('generate/genCommon.py'),
> > +  depend_files : glapi_gen_mapi_py,
> >capture : true,
> >  )
> >
>
> I don't think I understand this change. Why does this script no longer
> depend on genCommon.py, just because it moved?
>
> I would expect something like this:
>
> ---8<---
> genCommon_py = files(join_paths('..', '..', 'mapi', 'new',
> 'genCommon.py'))
>
> 
>
>   depend_files : [glapi_gen_mapi_py, genCommon_py],
> ---8<---
>
> (It's probably cleaner to define genCommon_py in some other meson-file
> closer to the source, but this should illustrate my point)
>
Thanks for the review Erik - you're a star.
I've addressed the above - v3 of this patch and 17/24 are out.

> > diff --git a/src/mapi/Makefile.am b/src/mapi/Makefile.am
> > index 97ebdeb1d7f..b46ed814700 100644
> > --- a/src/mapi/Makefile.am
> > +++ b/src/mapi/Makefile.am
> > @@ -31,6 +31,7 @@ pkgconfigdir = $(libdir)/pkgconfig
> >  pkgconfig_DATA =
> >
> >  EXTRA_DIST = \
> > + new/genCommon.py \
> >   es1api/ABI-check \
> >   es2api/ABI-check \
> >   mapi_abi.py \
>
> If this is added to EXTRA_DIST, I kinda would have expected it to be
> removed from some EXTRA_DIST-variable in the old location... Why do we
> need to introduce distribution of this? Don't we just distribute the
> built API?
>
This is mostly for clarity sake.

Before this patch the script is used (by the makefile in the same
folder) and thus implicitly shipped. Now since is not used within this
file, it's not immediately clear that it will be shipped.
By default we want to ship the generators, for clarity and
reproducibility et al.

Autotools itself, tends to go the extra mile of shipping the generated
artefacts.
Idea is that one shouldn't need [too much] third party tools - ideally
only a compiler toolchain and dependencies (headers, libraries,
pkg-config files).

Whether autotools is going a wise thing (or not) is another topic.

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

[Mesa-dev] [PATCH v3 17/24] meson: wire the new generator for es1 and es2

[Emil Velikov]

From: Emil Velikov 

v2: use ${foo})_py naming (Dylan)
v3: use symbolic name for genCommon.py

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..b0416e705a1 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_py, 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..a7f0904b699 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_py, 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 8cc163b2989..ecfa1a7f77e 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,
+  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 24013c65542..3e79bbaa7aa 100644
--- a/src/mapi/meson.build
+++ b/src/mapi/meson.build
@@ -26,6 +26,7 @@ files_mapi_util = files(
 )
 
 genCommon_py = files('new/genCommon.py')
+glapi_gen_mapi_py = files('new/gen_gldispatch_mapi.py')
 mapi_abi_py = files('mapi_abi.py')
 
 subdir('glapi')
-- 
2.19.2

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

[Mesa-dev] [PATCH v3 07/24] mapi: move genCommon.py to src/mapi/new

[Emil Velikov]

From: Emil Velikov 

The helper will also be used by the new Khronos gl.xml aware generator.

v2: Move existing one, instead of duplicating it.
v3: Correct genCommon.py references in meson [Erik]

Suggested-by: Kyle Brenneman 
Signed-off-by: Emil Velikov 
---
 src/egl/Makefile.am | 6 --
 src/egl/generate/gen_egl_dispatch.py| 3 +++
 src/egl/meson.build | 4 ++--
 src/mapi/Makefile.am| 1 +
 src/mapi/meson.build| 1 +
 src/{egl/generate => mapi/new}/genCommon.py | 0
 6 files changed, 11 insertions(+), 4 deletions(-)
 rename src/{egl/generate => mapi/new}/genCommon.py (100%)

diff --git a/src/egl/Makefile.am b/src/egl/Makefile.am
index 7269912d96f..6ce51936b16 100644
--- a/src/egl/Makefile.am
+++ b/src/egl/Makefile.am
@@ -136,8 +136,10 @@ libEGL_common_la_LIBADD += \
$(LIBDRM_LIBS) \
$(CLOCK_LIB)
 
-GLVND_GEN_DEPS = generate/gen_egl_dispatch.py \
-   generate/egl.xml generate/eglFunctionList.py generate/genCommon.py \
+GLVND_GEN_DEPS = $(top_scrdir)/src/mapi/new/generate/genCommon.py \
+   generate/gen_egl_dispatch.py \
+   generate/eglFunctionList.py \
+   generate/egl.xml \
generate/egl_other.xml
 
 PYTHON_GEN = $(AM_V_GEN)$(PYTHON) $(PYTHON_FLAGS)
diff --git a/src/egl/generate/gen_egl_dispatch.py 
b/src/egl/generate/gen_egl_dispatch.py
index eeb3f3f9a5a..728799e9754 100644
--- a/src/egl/generate/gen_egl_dispatch.py
+++ b/src/egl/generate/gen_egl_dispatch.py
@@ -38,6 +38,9 @@ import imp
 import sys
 import textwrap
 
+import os
+NEWAPI = os.path.join(os.path.dirname(__file__), "..", "..", "mapi", "new")
+sys.path.insert(0, NEWAPI)
 import genCommon
 
 def main():
diff --git a/src/egl/meson.build b/src/egl/meson.build
index 89bac2cd633..6c8bb244e0a 100644
--- a/src/egl/meson.build
+++ b/src/egl/meson.build
@@ -69,7 +69,7 @@ g_egldispatchstubs_c = custom_target(
   command : [
 prog_python, '@INPUT0@', 'source', '@INPUT1@', '@INPUT2@', '@INPUT3@'
   ],
-  depend_files : files('generate/genCommon.py'),
+  depend_files : genCommon_py,
   capture : true,
 )
 
@@ -83,7 +83,7 @@ g_egldispatchstubs_h = custom_target(
   command : [
 prog_python, '@INPUT0@', 'header', '@INPUT1@', '@INPUT2@', '@INPUT3@'
   ],
-  depend_files : files('generate/genCommon.py'),
+  depend_files : genCommon_py,
   capture : true,
 )
 
diff --git a/src/mapi/Makefile.am b/src/mapi/Makefile.am
index 97ebdeb1d7f..b46ed814700 100644
--- a/src/mapi/Makefile.am
+++ b/src/mapi/Makefile.am
@@ -31,6 +31,7 @@ pkgconfigdir = $(libdir)/pkgconfig
 pkgconfig_DATA =
 
 EXTRA_DIST = \
+   new/genCommon.py \
es1api/ABI-check \
es2api/ABI-check \
mapi_abi.py \
diff --git a/src/mapi/meson.build b/src/mapi/meson.build
index 798586bfb0c..24013c65542 100644
--- a/src/mapi/meson.build
+++ b/src/mapi/meson.build
@@ -25,6 +25,7 @@ files_mapi_util = files(
   'u_execmem.h',
 )
 
+genCommon_py = files('new/genCommon.py')
 mapi_abi_py = files('mapi_abi.py')
 
 subdir('glapi')
diff --git a/src/egl/generate/genCommon.py b/src/mapi/new/genCommon.py
similarity index 100%
rename from src/egl/generate/genCommon.py
rename to src/mapi/new/genCommon.py
-- 
2.19.2

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

[Mesa-dev] [Bug 108946] High memory usage in Black Mesa

[bugzilla-daemon]

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

Andrew Keller  changed:

   What|Removed |Added

 CC||andrew@thekellers.email

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

[Mesa-dev] [PATCH 4/6] radeonsi: use u_decomposed_prims_for_vertices instead of u_prims_for_vertices

[Marek Olšák]

From: Marek Olšák 

It seems to be the same, but this doesn't use integer division with
a variable divisor.
---
 src/gallium/drivers/radeonsi/si_state_draw.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/radeonsi/si_state_draw.c 
b/src/gallium/drivers/radeonsi/si_state_draw.c
index c72c59b29d4..09dd4a7e098 100644
--- a/src/gallium/drivers/radeonsi/si_state_draw.c
+++ b/src/gallium/drivers/radeonsi/si_state_draw.c
@@ -308,24 +308,26 @@ static bool si_emit_derived_tess_state(struct si_context 
*sctx,
return true; /* true if the context rolls */
}
return false;
 }
 
 static unsigned si_num_prims_for_vertices(const struct pipe_draw_info *info)
 {
switch (info->mode) {
case PIPE_PRIM_PATCHES:
return info->count / info->vertices_per_patch;
+   case PIPE_PRIM_POLYGON:
+   return info->count >= 3;
case SI_PRIM_RECTANGLE_LIST:
return info->count / 3;
default:
-   return u_prims_for_vertices(info->mode, info->count);
+   return u_decomposed_prims_for_vertices(info->mode, info->count);
}
 }
 
 static unsigned
 si_get_init_multi_vgt_param(struct si_screen *sscreen,
union si_vgt_param_key *key)
 {
STATIC_ASSERT(sizeof(union si_vgt_param_key) == 4);
unsigned max_primgroup_in_wave = 2;
 
-- 
2.17.1

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

[Mesa-dev] [PATCH 6/6] radeonsi: always unmap texture CPU mappings on 32-bit CPU architectures

[Marek Olšák]

From: Marek Olšák 

Team Fortress 2 32-bit version runs out of the CPU address space.
---
 src/gallium/drivers/radeonsi/si_texture.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/src/gallium/drivers/radeonsi/si_texture.c 
b/src/gallium/drivers/radeonsi/si_texture.c
index 95f1e8c9693..39869445b0f 100644
--- a/src/gallium/drivers/radeonsi/si_texture.c
+++ b/src/gallium/drivers/radeonsi/si_texture.c
@@ -1791,20 +1791,26 @@ static void *si_texture_transfer_map(struct 
pipe_context *ctx,
 
buf = trans->staging;
} else {
/* the resource is mapped directly */
offset = si_texture_get_offset(sctx->screen, tex, level, box,
 >b.b.stride,
 >b.b.layer_stride);
buf = >buffer;
}
 
+   /* Always unmap texture CPU mappings on 32-bit architectures, so that
+* we don't run out of the CPU address space.
+*/
+   if (sizeof(void*) == 4)
+   usage |= RADEON_TRANSFER_TEMPORARY;
+
if (!(map = si_buffer_map_sync_with_rings(sctx, buf, usage)))
goto fail_trans;
 
*ptransfer = >b.b;
return map + offset;
 
 fail_trans:
r600_resource_reference(>staging, NULL);
pipe_resource_reference(>b.b.resource, NULL);
FREE(trans);
@@ -1812,20 +1818,30 @@ fail_trans:
 }
 
 static void si_texture_transfer_unmap(struct pipe_context *ctx,
  struct pipe_transfer* transfer)
 {
struct si_context *sctx = (struct si_context*)ctx;
struct si_transfer *stransfer = (struct si_transfer*)transfer;
struct pipe_resource *texture = transfer->resource;
struct si_texture *tex = (struct si_texture*)texture;
 
+   /* Always unmap texture CPU mappings on 32-bit architectures, so that
+* we don't run out of the CPU address space.
+*/
+   if (sizeof(void*) == 4) {
+   struct r600_resource *buf =
+   stransfer->staging ? stransfer->staging : >buffer;
+
+   sctx->ws->buffer_unmap(buf->buf);
+   }
+
if ((transfer->usage & PIPE_TRANSFER_WRITE) && stransfer->staging) {
if (tex->is_depth && tex->buffer.b.b.nr_samples <= 1) {
ctx->resource_copy_region(ctx, texture, transfer->level,
  transfer->box.x, 
transfer->box.y, transfer->box.z,
  >staging->b.b, 
transfer->level,
  >box);
} else {
si_copy_from_staging_texture(ctx, stransfer);
}
}
-- 
2.17.1

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

[Mesa-dev] [PATCH 2/6] radeonsi: call si_fix_resource_usage for the GS copy shader as well

[Marek Olšák]

From: Marek Olšák 

---
 src/gallium/drivers/radeonsi/si_shader.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/gallium/drivers/radeonsi/si_shader.c 
b/src/gallium/drivers/radeonsi/si_shader.c
index ee0c668431c..68afff449fd 100644
--- a/src/gallium/drivers/radeonsi/si_shader.c
+++ b/src/gallium/drivers/radeonsi/si_shader.c
@@ -79,20 +79,22 @@ static void si_dump_shader_key(unsigned processor, const 
struct si_shader *shade
   FILE *f);
 
 static void si_build_vs_prolog_function(struct si_shader_context *ctx,
union si_shader_part_key *key);
 static void si_build_tcs_epilog_function(struct si_shader_context *ctx,
 union si_shader_part_key *key);
 static void si_build_ps_prolog_function(struct si_shader_context *ctx,
union si_shader_part_key *key);
 static void si_build_ps_epilog_function(struct si_shader_context *ctx,
union si_shader_part_key *key);
+static void si_fix_resource_usage(struct si_screen *sscreen,
+ struct si_shader *shader);
 
 /* Ideally pass the sample mask input to the PS epilog as v14, which
  * is its usual location, so that the shader doesn't have to add v_mov.
  */
 #define PS_EPILOG_SAMPLEMASK_MIN_LOC 14
 
 static bool llvm_type_is_64bit(struct si_shader_context *ctx,
   LLVMTypeRef type)
 {
if (type == ctx->ac.i64 || type == ctx->ac.f64)
@@ -5769,20 +5771,22 @@ si_generate_gs_copy_shader(struct si_screen *sscreen,
si_shader_dump(sscreen, ctx.shader, debug,
   PIPE_SHADER_GEOMETRY, stderr, true);
r = si_shader_binary_upload(sscreen, ctx.shader);
}
 
si_llvm_dispose();
 
if (r != 0) {
FREE(shader);
shader = NULL;
+   } else {
+   si_fix_resource_usage(sscreen, shader);
}
return shader;
 }
 
 static void si_dump_shader_key_vs(const struct si_shader_key *key,
  const struct si_vs_prolog_bits *prolog,
  const char *prefix, FILE *f)
 {
fprintf(f, "  %s.instance_divisor_is_one = %u\n",
prefix, prolog->instance_divisor_is_one);
-- 
2.17.1

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

[Mesa-dev] [PATCH 5/6] radeonsi: remove unused variables in si_insert_input_ptr

[Marek Olšák]

From: Marek Olšák 

---
 src/gallium/drivers/radeonsi/si_shader.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_shader.c 
b/src/gallium/drivers/radeonsi/si_shader.c
index 68afff449fd..250e0cc5db4 100644
--- a/src/gallium/drivers/radeonsi/si_shader.c
+++ b/src/gallium/drivers/radeonsi/si_shader.c
@@ -3249,23 +3249,21 @@ si_insert_input_ret_float(struct si_shader_context 
*ctx, LLVMValueRef ret,
return LLVMBuildInsertValue(builder, ret,
ac_to_float(>ac, p),
return_index, "");
 }
 
 static LLVMValueRef
 si_insert_input_ptr(struct si_shader_context *ctx, LLVMValueRef ret,
unsigned param, unsigned return_index)
 {
LLVMBuilderRef builder = ctx->ac.builder;
-   LLVMValueRef ptr, lo, hi;
-
-   ptr = LLVMGetParam(ctx->main_fn, param);
+   LLVMValueRef ptr = LLVMGetParam(ctx->main_fn, param);
ptr = LLVMBuildPtrToInt(builder, ptr, ctx->i32, "");
return LLVMBuildInsertValue(builder, ret, ptr, return_index, "");
 }
 
 /* This only writes the tessellation factor levels. */
 static void si_llvm_emit_tcs_epilogue(struct ac_shader_abi *abi,
  unsigned max_outputs,
  LLVMValueRef *addrs)
 {
struct si_shader_context *ctx = si_shader_context_from_abi(abi);
-- 
2.17.1

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

[Mesa-dev] [PATCH 1/6] radeonsi: don't emit redundant PKT3_NUM_INSTANCES packets

[Marek Olšák]

From: Marek Olšák 

---
 src/gallium/drivers/radeonsi/si_pipe.h   | 3 +++
 src/gallium/drivers/radeonsi/si_state_draw.c | 9 +++--
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_pipe.h 
b/src/gallium/drivers/radeonsi/si_pipe.h
index 1d677d29e88..b3522b60752 100644
--- a/src/gallium/drivers/radeonsi/si_pipe.h
+++ b/src/gallium/drivers/radeonsi/si_pipe.h
@@ -40,20 +40,21 @@
 
 #define ATI_VENDOR_ID  0x1002
 
 #define SI_NOT_QUERY   0x
 
 /* The base vertex and primitive restart can be any number, but we must pick
  * one which will mean "unknown" for the purpose of state tracking and
  * the number shouldn't be a commonly-used one. */
 #define SI_BASE_VERTEX_UNKNOWN INT_MIN
 #define SI_RESTART_INDEX_UNKNOWN   INT_MIN
+#define SI_INSTANCE_COUNT_UNKNOWN  INT_MIN
 #define SI_NUM_SMOOTH_AA_SAMPLES   8
 #define SI_MAX_POINT_SIZE  2048
 #define SI_GS_PER_ES   128
 /* Alignment for optimal CP DMA performance. */
 #define SI_CPDMA_ALIGNMENT 32
 
 /* Tunables for compute-based clear_buffer and copy_buffer: */
 #define SI_COMPUTE_CLEAR_DW_PER_THREAD 4
 #define SI_COMPUTE_COPY_DW_PER_THREAD  4
 #define SI_COMPUTE_DST_CACHE_POLICYL2_STREAM
@@ -918,20 +919,21 @@ struct si_context {
booldb_stencil_disable_expclear:1;
boolocclusion_queries_disabled:1;
boolgenerate_mipmap_for_depth:1;
 
/* Emitted draw state. */
boolgs_tri_strip_adj_fix:1;
boolls_vgpr_fix:1;
int last_index_size;
int last_base_vertex;
int last_start_instance;
+   int last_instance_count;
int last_drawid;
int last_sh_base_reg;
int last_primitive_restart_en;
int last_restart_index;
int last_prim;
int last_multi_vgt_param;
int last_rast_prim;
unsignedlast_sc_line_stipple;
unsignedcurrent_vs_state;
unsignedlast_vs_state;
@@ -1369,20 +1371,21 @@ si_context_add_resource_size(struct si_context *sctx, 
struct pipe_resource *r)
/* Add memory usage for need_gfx_cs_space */
sctx->vram += r600_resource(r)->vram_usage;
sctx->gtt += r600_resource(r)->gart_usage;
}
 }
 
 static inline void
 si_invalidate_draw_sh_constants(struct si_context *sctx)
 {
sctx->last_base_vertex = SI_BASE_VERTEX_UNKNOWN;
+   sctx->last_instance_count = SI_INSTANCE_COUNT_UNKNOWN;
 }
 
 static inline unsigned
 si_get_atom_bit(struct si_context *sctx, struct si_atom *atom)
 {
return 1 << (atom - sctx->atoms.array);
 }
 
 static inline void
 si_set_atom_dirty(struct si_context *sctx, struct si_atom *atom, bool dirty)
diff --git a/src/gallium/drivers/radeonsi/si_state_draw.c 
b/src/gallium/drivers/radeonsi/si_state_draw.c
index 612ca910cb9..b707a6585c5 100644
--- a/src/gallium/drivers/radeonsi/si_state_draw.c
+++ b/src/gallium/drivers/radeonsi/si_state_draw.c
@@ -802,24 +802,29 @@ static void si_emit_draw_packets(struct si_context *sctx,
radeon_emit(cs, ((sh_base_reg + SI_SGPR_DRAWID * 4 - 
SI_SH_REG_OFFSET) >> 2) |
S_2C3_DRAW_INDEX_ENABLE(1) |

S_2C3_COUNT_INDIRECT_ENABLE(!!indirect->indirect_draw_count));
radeon_emit(cs, indirect->draw_count);
radeon_emit(cs, count_va);
radeon_emit(cs, count_va >> 32);
radeon_emit(cs, indirect->stride);
radeon_emit(cs, di_src_sel);
}
} else {
+   unsigned instance_count = info->instance_count;
int base_vertex;
 
-   radeon_emit(cs, PKT3(PKT3_NUM_INSTANCES, 0, 0));
-   radeon_emit(cs, info->instance_count);
+   if (sctx->last_instance_count == SI_INSTANCE_COUNT_UNKNOWN ||
+   sctx->last_instance_count != instance_count) {
+   radeon_emit(cs, PKT3(PKT3_NUM_INSTANCES, 0, 0));
+   radeon_emit(cs, instance_count);
+   sctx->last_instance_count = instance_count;
+   }
 
/* Base vertex and start instance. */
base_vertex = index_size ? info->index_bias : info->start;
 
if (sctx->num_vs_blit_sgprs) {
/* Re-emit draw constants after we leave u_blitter. */
si_invalidate_draw_sh_constants(sctx);
 
/* Blit VS doesn't use 

[Mesa-dev] [PATCH 3/6] radeonsi: make si_cp_wait_mem more configurable

[Marek Olšák]

From: Marek Olšák 

---
 src/gallium/drivers/radeonsi/si_fence.c   | 6 ++
 src/gallium/drivers/radeonsi/si_perfcounter.c | 2 +-
 src/gallium/drivers/radeonsi/si_pipe.h| 2 +-
 src/gallium/drivers/radeonsi/si_query.c   | 3 ++-
 src/gallium/drivers/radeonsi/si_state_draw.c  | 3 ++-
 5 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_fence.c 
b/src/gallium/drivers/radeonsi/si_fence.c
index d385f445774..b6920c95e34 100644
--- a/src/gallium/drivers/radeonsi/si_fence.c
+++ b/src/gallium/drivers/radeonsi/si_fence.c
@@ -153,27 +153,25 @@ unsigned si_cp_write_fence_dwords(struct si_screen 
*screen)
 {
unsigned dwords = 6;
 
if (screen->info.chip_class == CIK ||
screen->info.chip_class == VI)
dwords *= 2;
 
return dwords;
 }
 
-void si_cp_wait_mem(struct si_context *ctx,
+void si_cp_wait_mem(struct si_context *ctx, struct radeon_cmdbuf *cs,
uint64_t va, uint32_t ref, uint32_t mask, unsigned flags)
 {
-   struct radeon_cmdbuf *cs = ctx->gfx_cs;
-
radeon_emit(cs, PKT3(PKT3_WAIT_REG_MEM, 5, 0));
-   radeon_emit(cs, WAIT_REG_MEM_EQUAL | WAIT_REG_MEM_MEM_SPACE(1) | flags);
+   radeon_emit(cs, WAIT_REG_MEM_MEM_SPACE(1) | flags);
radeon_emit(cs, va);
radeon_emit(cs, va >> 32);
radeon_emit(cs, ref); /* reference value */
radeon_emit(cs, mask); /* mask */
radeon_emit(cs, 4); /* poll interval */
 }
 
 static void si_add_fence_dependency(struct si_context *sctx,
struct pipe_fence_handle *fence)
 {
diff --git a/src/gallium/drivers/radeonsi/si_perfcounter.c 
b/src/gallium/drivers/radeonsi/si_perfcounter.c
index cea7d57e518..f0d40e03982 100644
--- a/src/gallium/drivers/radeonsi/si_perfcounter.c
+++ b/src/gallium/drivers/radeonsi/si_perfcounter.c
@@ -577,21 +577,21 @@ static void si_pc_emit_start(struct si_context *sctx,
  * do it again in here. */
 static void si_pc_emit_stop(struct si_context *sctx,
struct r600_resource *buffer, uint64_t va)
 {
struct radeon_cmdbuf *cs = sctx->gfx_cs;
 
si_cp_release_mem(sctx, V_028A90_BOTTOM_OF_PIPE_TS, 0,
  EOP_DST_SEL_MEM, EOP_INT_SEL_NONE,
  EOP_DATA_SEL_VALUE_32BIT,
  buffer, va, 0, SI_NOT_QUERY);
-   si_cp_wait_mem(sctx, va, 0, 0x, 0);
+   si_cp_wait_mem(sctx, cs, va, 0, 0x, WAIT_REG_MEM_EQUAL);
 
radeon_emit(cs, PKT3(PKT3_EVENT_WRITE, 0, 0));
radeon_emit(cs, EVENT_TYPE(V_028A90_PERFCOUNTER_SAMPLE) | 
EVENT_INDEX(0));
radeon_emit(cs, PKT3(PKT3_EVENT_WRITE, 0, 0));
radeon_emit(cs, EVENT_TYPE(V_028A90_PERFCOUNTER_STOP) | EVENT_INDEX(0));
radeon_set_uconfig_reg(cs, R_036020_CP_PERFMON_CNTL,
   S_036020_PERFMON_STATE(V_036020_STOP_COUNTING) |
   S_036020_PERFMON_SAMPLE_ENABLE(1));
 }
 
diff --git a/src/gallium/drivers/radeonsi/si_pipe.h 
b/src/gallium/drivers/radeonsi/si_pipe.h
index b3522b60752..23f2089034d 100644
--- a/src/gallium/drivers/radeonsi/si_pipe.h
+++ b/src/gallium/drivers/radeonsi/si_pipe.h
@@ -1206,21 +1206,21 @@ void si_flush_dma_cs(struct si_context *ctx, unsigned 
flags,
 void si_screen_clear_buffer(struct si_screen *sscreen, struct pipe_resource 
*dst,
uint64_t offset, uint64_t size, unsigned value);
 
 /* si_fence.c */
 void si_cp_release_mem(struct si_context *ctx,
   unsigned event, unsigned event_flags,
   unsigned dst_sel, unsigned int_sel, unsigned data_sel,
   struct r600_resource *buf, uint64_t va,
   uint32_t new_fence, unsigned query_type);
 unsigned si_cp_write_fence_dwords(struct si_screen *screen);
-void si_cp_wait_mem(struct si_context *ctx,
+void si_cp_wait_mem(struct si_context *ctx, struct radeon_cmdbuf *cs,
  uint64_t va, uint32_t ref, uint32_t mask, unsigned flags);
 void si_init_fence_functions(struct si_context *ctx);
 void si_init_screen_fence_functions(struct si_screen *screen);
 struct pipe_fence_handle *si_create_fence(struct pipe_context *ctx,
  struct tc_unflushed_batch_token 
*tc_token);
 
 /* si_get.c */
 void si_init_screen_get_functions(struct si_screen *sscreen);
 
 /* si_gfx_cs.c */
diff --git a/src/gallium/drivers/radeonsi/si_query.c 
b/src/gallium/drivers/radeonsi/si_query.c
index aed3e1e80c1..3b55906a3cd 100644
--- a/src/gallium/drivers/radeonsi/si_query.c
+++ b/src/gallium/drivers/radeonsi/si_query.c
@@ -1564,21 +1564,22 @@ static void si_query_hw_get_result_resource(struct 
si_context *sctx,
if (wait && qbuf == >buffer) {
uint64_t va;
 
/* Wait for result availability. Wait only for readiness
 * of the last entry, since the 

[Mesa-dev] [PATCH v2] nvc0/ir: replace cvt instructions with add to improve shader performance

[Karol Herbst]

gives me an performance boost of 0.2% in pixmark_piano on my gk106, gm204 and
gp107.

changes in shader-db:

total instructions in shared programs : 7614782 -> 7614782 (0.00%)
total cvt instructions in shared programs : 139343 -> 95856 (-31.21%)
total gprs used in shared programs: 798045 -> 798045 (0.00%)
total shared used in shared programs  : 639636 -> 639636 (0.00%)
total local used in shared programs   : 24648 -> 24648 (0.00%)
total bytes used in shared programs   : 81330696 -> 81330696 (0.00%)

local sharedgpr   inst   cvts  bytes
helped  0  0  0  0  14037  0
  hurt  0  0  0  0  0  0

v2: only for 32 bit operations
move some common code out of the switch
handle OP_SAT with modifiers

Signed-off-by: Karol Herbst 
---
 .../nouveau/codegen/nv50_ir_lowering_nvc0.cpp | 53 +++
 .../nouveau/codegen/nv50_ir_lowering_nvc0.h   |  1 +
 2 files changed, 54 insertions(+)

diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
index 295497be2f9..24129ca4d64 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
@@ -719,6 +719,56 @@ NVC0LegalizePostRA::propagateJoin(BasicBlock *bb)
bb->remove(bb->getEntry());
 }
 
+// replaces instructions which would end up as f2f or i2i with faster
+// alternatives:
+//  - abs(a) -> add(0, abs a)
+//  - neg(a) -> add(0, neg a)
+//  - neg(abs a) -> add(0, neg abs a)
+//  - sat(a) -> sat add(0, a)
+void
+NVC0LegalizePostRA::replaceCvt(Instruction *cvt)
+{
+   if (typeSizeof(cvt->sType) != 4)
+  return;
+   if (cvt->sType != cvt->dType)
+  return;
+   // we could make it work, but in this case we have optimizations disabled
+   // and we don't really care either way.
+   if (cvt->src(0).getFile() == FILE_IMMEDIATE)
+  return;
+
+   Modifier mod;
+
+   switch (cvt->op) {
+   case OP_ABS:
+  if (cvt->src(0).mod)
+ return;
+  if (!isFloatType(cvt->sType))
+ return;
+  mod = NV50_IR_MOD_ABS;
+  break;
+   case OP_NEG:
+  if (cvt->src(0).mod && (cvt->src(0).mod.neg() || 
!isFloatType(cvt->sType)))
+ return;
+  mod = cvt->src(0).mod ? NV50_IR_MOD_NEG_ABS : NV50_IR_MOD_NEG;
+  break;
+   case OP_SAT:
+  if (!isFloatType(cvt->sType) && cvt->src(0).mod.abs())
+ return;
+  mod = cvt->src(0).mod;
+  cvt->saturate = true;
+  break;
+   default:
+  return;
+   }
+
+   cvt->op = OP_ADD;
+   cvt->moveSources(0, 1);
+   cvt->setSrc(0, rZero);
+   cvt->src(0).mod = 0;
+   cvt->src(1).mod = mod;
+}
+
 bool
 NVC0LegalizePostRA::visit(BasicBlock *bb)
 {
@@ -758,6 +808,9 @@ NVC0LegalizePostRA::visit(BasicBlock *bb)
next = hi;
  }
 
+ if (i->isCvt())
+replaceCvt(i);
+
  if (i->op != OP_MOV && i->op != OP_PFETCH)
 replaceZero(i);
   }
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.h 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.h
index e0f50ab0904..4679c56471b 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.h
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.h
@@ -81,6 +81,7 @@ private:
virtual bool visit(Function *);
virtual bool visit(BasicBlock *);
 
+   void replaceCvt(Instruction *);
void replaceZero(Instruction *);
bool tryReplaceContWithBra(BasicBlock *);
void propagateJoin(BasicBlock *);
-- 
2.19.2

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

Re: [Mesa-dev] [PATCH v2 3/6] gallium: add pipe->invalidate_surface()

[Marek Olšák]

The way I see it, pipe_surface is a render target view for
pipe_framebuffer_state. The fact that other functions also accept
pipe_surface is a historic artifact. resource_copy_region used to accept 2
pipe_surfaces before it was changed to 2 pipe_resources + parameters.
Somebody might decide to change invalidate_subresource to take
pipe_resource in the future.

It seems to me that you really want e.g. invalidate_framebuffer(ctx,
PIPE_FRAMEBUFFER_COLOR0 | PIPE_FRAMEBUFFER_COLOR1), not pipe_surface.

I'm not too crazy about this, just pointing out the way I understand the
conventions.

Marek

On Fri, Dec 14, 2018 at 3:51 PM Rob Clark  wrote:

> I don't mind renaming it to invalidate_subsurface() if you prefer
> that, but I really prefer that it takes a surface rather than a
> resource... pipe_resource is the wrong level to do this.
>
> Even though surfaces are transient, tracking the invalidate state in
> the surface works out much easier in the driver.  And I don't want to
> have to map resource+params back to a surface.  If another driver
> wants to track this at the resource level, it is easier for them to go
> from surface to resource+params, compared to the opposite direction.
>
> BR,
> -R
>
>
> On Fri, Dec 14, 2018 at 3:38 PM Marek Olšák  wrote:
> >
> > Can you please call it invalidate_subresource and inline relevant
> pipe_surface variables inside the parameters?
> >
> > Thanks,
> > Marek
> >
> > On Wed, Dec 12, 2018 at 10:48 AM Rob Clark  wrote:
> >>
> >> A new API to implement glInvalidateFramebuffer() and friends.  It is
> >> similar to invalidate_resource() but can be used to invalidate a
> >> specific layer/level, so it is suitable to use for user FBOs in addition
> >> to window system framebuffer.
> >>
> >> Signed-off-by: Rob Clark 
> >> ---
> >>  src/gallium/docs/source/context.rst  | 18 ++
> >>  src/gallium/include/pipe/p_context.h | 18 ++
> >>  2 files changed, 36 insertions(+)
> >>
> >> diff --git a/src/gallium/docs/source/context.rst
> b/src/gallium/docs/source/context.rst
> >> index 20d0df79312..9f3cd49ee31 100644
> >> --- a/src/gallium/docs/source/context.rst
> >> +++ b/src/gallium/docs/source/context.rst
> >> @@ -740,7 +740,25 @@ of the buffer is not a multiple of the page size,
> changing the commit state of
> >>  the last (partial) page requires a box that ends at the end of the
> buffer
> >>  (i.e., box->x + box->width == buffer->width0).
> >>
> >> +.. _invalidate_surface:
> >>
> >> +invalidate_surface
> >> +%%
> >> +
> >> +This optional function marks a surface, or a portion of a surface, as
> invalid,
> >> +for example to implement glInvalidateFramebuffer() (and friends).  It
> is
> >> +useful in particular for tiler GPUs, as a way to avoid unnecessary
> transfers
> >> +between system memory and tile buffer.
> >> +
> >> +For example, invalidating a surface after rendering, but before flush,
> can
> >> +be used to avoid tile to system memory transfer (for example, if zs
> can be
> >> +discarded).  And an invalidate after flush before rendering can be
> used to
> >> +avoid a system memory to tile buffer transfer.
> >> +
> >> +Invalidating a partial surface can also be used to avoid unnecessary
> transfer
> >> +from system memory to tile buffer in the case of a scissored clear
> (which is
> >> +implemented via ->draw_vbo() by the state tracker) by invalidating the
> >> +scissored region.
> >>
> >>  .. _pipe_transfer:
> >>
> >> diff --git a/src/gallium/include/pipe/p_context.h
> b/src/gallium/include/pipe/p_context.h
> >> index e07b76d4f03..4dfc87faff6 100644
> >> --- a/src/gallium/include/pipe/p_context.h
> >> +++ b/src/gallium/include/pipe/p_context.h
> >> @@ -803,6 +803,24 @@ struct pipe_context {
> >> void (*invalidate_resource)(struct pipe_context *ctx,
> >> struct pipe_resource *resource);
> >>
> >> +   /**
> >> +* Like ->invalidate_resource, but can invalidate a specific layer
> and level
> >> +* of a resource, and optionally a specific sub-region of the
> resource (if
> >> +* region is not NULL).
> >> +*
> >> +* If the backing surf->texture has just a single layer and level
> (like
> >> +* window system buffers), and region is NULL, it is equivalent to
> >> +* ->invalidate_resource().
> >> +*
> >> +* \param ctxpipe context
> >> +* \param surf   surface to invalidate
> >> +* \param region NULL to invalidate whole surface, otherwise
> specifies which
> >> +*   portion of the surface is invalidated
> >> +*/
> >> +   void (*invalidate_surface)(struct pipe_context *ctx,
> >> +  struct pipe_surface *surf,
> >> +  const struct pipe_box *region);
> >> +
> >> /**
> >>  * Return information about unexpected device resets.
> >>  */
> >> --
> >> 2.19.2
> >>
> >> ___
> >> mesa-dev mailing list
> >> mesa-dev@lists.freedesktop.org
> 

Re: [Mesa-dev] [PATCH v2 3/6] gallium: add pipe->invalidate_surface()

[Rob Clark]

I don't mind renaming it to invalidate_subsurface() if you prefer
that, but I really prefer that it takes a surface rather than a
resource... pipe_resource is the wrong level to do this.

Even though surfaces are transient, tracking the invalidate state in
the surface works out much easier in the driver.  And I don't want to
have to map resource+params back to a surface.  If another driver
wants to track this at the resource level, it is easier for them to go
from surface to resource+params, compared to the opposite direction.

BR,
-R


On Fri, Dec 14, 2018 at 3:38 PM Marek Olšák  wrote:
>
> Can you please call it invalidate_subresource and inline relevant 
> pipe_surface variables inside the parameters?
>
> Thanks,
> Marek
>
> On Wed, Dec 12, 2018 at 10:48 AM Rob Clark  wrote:
>>
>> A new API to implement glInvalidateFramebuffer() and friends.  It is
>> similar to invalidate_resource() but can be used to invalidate a
>> specific layer/level, so it is suitable to use for user FBOs in addition
>> to window system framebuffer.
>>
>> Signed-off-by: Rob Clark 
>> ---
>>  src/gallium/docs/source/context.rst  | 18 ++
>>  src/gallium/include/pipe/p_context.h | 18 ++
>>  2 files changed, 36 insertions(+)
>>
>> diff --git a/src/gallium/docs/source/context.rst 
>> b/src/gallium/docs/source/context.rst
>> index 20d0df79312..9f3cd49ee31 100644
>> --- a/src/gallium/docs/source/context.rst
>> +++ b/src/gallium/docs/source/context.rst
>> @@ -740,7 +740,25 @@ of the buffer is not a multiple of the page size, 
>> changing the commit state of
>>  the last (partial) page requires a box that ends at the end of the buffer
>>  (i.e., box->x + box->width == buffer->width0).
>>
>> +.. _invalidate_surface:
>>
>> +invalidate_surface
>> +%%
>> +
>> +This optional function marks a surface, or a portion of a surface, as 
>> invalid,
>> +for example to implement glInvalidateFramebuffer() (and friends).  It is
>> +useful in particular for tiler GPUs, as a way to avoid unnecessary transfers
>> +between system memory and tile buffer.
>> +
>> +For example, invalidating a surface after rendering, but before flush, can
>> +be used to avoid tile to system memory transfer (for example, if zs can be
>> +discarded).  And an invalidate after flush before rendering can be used to
>> +avoid a system memory to tile buffer transfer.
>> +
>> +Invalidating a partial surface can also be used to avoid unnecessary 
>> transfer
>> +from system memory to tile buffer in the case of a scissored clear (which is
>> +implemented via ->draw_vbo() by the state tracker) by invalidating the
>> +scissored region.
>>
>>  .. _pipe_transfer:
>>
>> diff --git a/src/gallium/include/pipe/p_context.h 
>> b/src/gallium/include/pipe/p_context.h
>> index e07b76d4f03..4dfc87faff6 100644
>> --- a/src/gallium/include/pipe/p_context.h
>> +++ b/src/gallium/include/pipe/p_context.h
>> @@ -803,6 +803,24 @@ struct pipe_context {
>> void (*invalidate_resource)(struct pipe_context *ctx,
>> struct pipe_resource *resource);
>>
>> +   /**
>> +* Like ->invalidate_resource, but can invalidate a specific layer and 
>> level
>> +* of a resource, and optionally a specific sub-region of the resource 
>> (if
>> +* region is not NULL).
>> +*
>> +* If the backing surf->texture has just a single layer and level (like
>> +* window system buffers), and region is NULL, it is equivalent to
>> +* ->invalidate_resource().
>> +*
>> +* \param ctxpipe context
>> +* \param surf   surface to invalidate
>> +* \param region NULL to invalidate whole surface, otherwise specifies 
>> which
>> +*   portion of the surface is invalidated
>> +*/
>> +   void (*invalidate_surface)(struct pipe_context *ctx,
>> +  struct pipe_surface *surf,
>> +  const struct pipe_box *region);
>> +
>> /**
>>  * Return information about unexpected device resets.
>>  */
>> --
>> 2.19.2
>>
>> ___
>> 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 v2 3/6] gallium: add pipe->invalidate_surface()

[Marek Olšák]

Can you please call it invalidate_subresource and inline relevant
pipe_surface variables inside the parameters?

Thanks,
Marek

On Wed, Dec 12, 2018 at 10:48 AM Rob Clark  wrote:

> A new API to implement glInvalidateFramebuffer() and friends.  It is
> similar to invalidate_resource() but can be used to invalidate a
> specific layer/level, so it is suitable to use for user FBOs in addition
> to window system framebuffer.
>
> Signed-off-by: Rob Clark 
> ---
>  src/gallium/docs/source/context.rst  | 18 ++
>  src/gallium/include/pipe/p_context.h | 18 ++
>  2 files changed, 36 insertions(+)
>
> diff --git a/src/gallium/docs/source/context.rst
> b/src/gallium/docs/source/context.rst
> index 20d0df79312..9f3cd49ee31 100644
> --- a/src/gallium/docs/source/context.rst
> +++ b/src/gallium/docs/source/context.rst
> @@ -740,7 +740,25 @@ of the buffer is not a multiple of the page size,
> changing the commit state of
>  the last (partial) page requires a box that ends at the end of the buffer
>  (i.e., box->x + box->width == buffer->width0).
>
> +.. _invalidate_surface:
>
> +invalidate_surface
> +%%
> +
> +This optional function marks a surface, or a portion of a surface, as
> invalid,
> +for example to implement glInvalidateFramebuffer() (and friends).  It is
> +useful in particular for tiler GPUs, as a way to avoid unnecessary
> transfers
> +between system memory and tile buffer.
> +
> +For example, invalidating a surface after rendering, but before flush, can
> +be used to avoid tile to system memory transfer (for example, if zs can be
> +discarded).  And an invalidate after flush before rendering can be used to
> +avoid a system memory to tile buffer transfer.
> +
> +Invalidating a partial surface can also be used to avoid unnecessary
> transfer
> +from system memory to tile buffer in the case of a scissored clear (which
> is
> +implemented via ->draw_vbo() by the state tracker) by invalidating the
> +scissored region.
>
>  .. _pipe_transfer:
>
> diff --git a/src/gallium/include/pipe/p_context.h
> b/src/gallium/include/pipe/p_context.h
> index e07b76d4f03..4dfc87faff6 100644
> --- a/src/gallium/include/pipe/p_context.h
> +++ b/src/gallium/include/pipe/p_context.h
> @@ -803,6 +803,24 @@ struct pipe_context {
> void (*invalidate_resource)(struct pipe_context *ctx,
> struct pipe_resource *resource);
>
> +   /**
> +* Like ->invalidate_resource, but can invalidate a specific layer and
> level
> +* of a resource, and optionally a specific sub-region of the resource
> (if
> +* region is not NULL).
> +*
> +* If the backing surf->texture has just a single layer and level (like
> +* window system buffers), and region is NULL, it is equivalent to
> +* ->invalidate_resource().
> +*
> +* \param ctxpipe context
> +* \param surf   surface to invalidate
> +* \param region NULL to invalidate whole surface, otherwise specifies
> which
> +*   portion of the surface is invalidated
> +*/
> +   void (*invalidate_surface)(struct pipe_context *ctx,
> +  struct pipe_surface *surf,
> +  const struct pipe_box *region);
> +
> /**
>  * Return information about unexpected device resets.
>  */
> --
> 2.19.2
>
> ___
> 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 4/4] nir: link time opt duplicate varyings

[Marek Olšák]

For patches 1-3:

Reviewed-by: Marek Olšák 

I'm not so knowledgeable to be able to comment on patch 4.

Does it also merge varyings such as (x,y,undef,undef) and
(x,undef,undef,w)? There is a game which outputs (x,y,z,undef) and
(x,y,undef,undef) where the vertex shader is a SSO.

Marek

On Mon, Dec 10, 2018 at 11:28 PM Timothy Arceri 
wrote:

> If we are outputting the same value to more than one output
> component rewrite the inputs to read from a single component.
>
> This will allow the duplicate varying components to be optimised
> away by the existing opts.
>
> shader-db results i965 (SKL):
>
> total instructions in shared programs: 12869230 -> 12860886 (-0.06%)
> instructions in affected programs: 322601 -> 314257 (-2.59%)
> helped: 3080
> HURT: 8
>
> total cycles in shared programs: 317792574 -> 317730593 (-0.02%)
> cycles in affected programs: 2584925 -> 2522944 (-2.40%)
> helped: 2975
> HURT: 477
>
> shader-db results radeonsi (VEGA):
>
> Totals from affected shaders:
> SGPRS: 30960 -> 31056 (0.31 %)
> VGPRS: 17052 -> 16672 (-2.23 %)
> Spilled SGPRs: 184 -> 167 (-9.24 %)
> Spilled VGPRs: 0 -> 0 (0.00 %)
> Private memory VGPRs: 0 -> 0 (0.00 %)
> Scratch size: 0 -> 0 (0.00 %) dwords per thread
> Code Size: 562532 -> 549404 (-2.33 %) bytes
> LDS: 0 -> 0 (0.00 %) blocks
> Max Waves: 6011 -> 6110 (1.65 %)
> Wait states: 0 -> 0 (0.00 %)
>
> vkpipeline-db results RADV (VEGA):
>
> Totals from affected shaders:
> SGPRS: 14880 -> 15080 (1.34 %)
> VGPRS: 10872 -> 10888 (0.15 %)
> Spilled SGPRs: 0 -> 0 (0.00 %)
> Spilled VGPRs: 0 -> 0 (0.00 %)
> Private memory VGPRs: 0 -> 0 (0.00 %)
> Scratch size: 0 -> 0 (0.00 %) dwords per thread
> Code Size: 674016 -> 668396 (-0.83 %) bytes
> LDS: 0 -> 0 (0.00 %) blocks
> Max Waves: 2708 -> 2704 (-0.15 %)
> Wait states: 0 -> 0 (0.00 %
> ---
>  src/compiler/nir/nir_linking_helpers.c | 95 ++
>  1 file changed, 95 insertions(+)
>
> diff --git a/src/compiler/nir/nir_linking_helpers.c
> b/src/compiler/nir/nir_linking_helpers.c
> index 37644d339f..bdfa7b8c4d 100644
> --- a/src/compiler/nir/nir_linking_helpers.c
> +++ b/src/compiler/nir/nir_linking_helpers.c
> @@ -700,6 +700,27 @@ nir_link_xfb_varyings(nir_shader *producer,
> nir_shader *consumer)
> }
>  }
>
> +static nir_variable *
> +get_matching_input_var(nir_shader *consumer, nir_variable *out_var)
> +{
> +   nir_variable *input_var = NULL;
> +   nir_foreach_variable(var, >inputs) {
> +  if (var->data.location >= VARYING_SLOT_VAR0 &&
> +  var->data.location - VARYING_SLOT_VAR0 < MAX_VARYING) {
> +
> + if (var->data.location == out_var->data.location &&
> + var->data.location_frac == out_var->data.location_frac &&
> + var->data.interpolation == out_var->data.interpolation &&
> + get_interp_loc(var) == get_interp_loc(out_var)) {
> +input_var = var;
> +break;
> + }
> +  }
> +   }
> +
> +   return input_var;
> +}
> +
>  static bool
>  can_replace_varying(nir_variable *out_var, nir_intrinsic_instr
> *store_intr)
>  {
> @@ -782,6 +803,57 @@ try_replace_constant_input(nir_shader *shader,
> return progress;
>  }
>
> +static bool
> +try_replace_duplicate_input(nir_shader *shader, nir_variable *input_var,
> +nir_intrinsic_instr *dup_store_intr)
> +{
> +   assert(input_var);
> +
> +   nir_variable *dup_out_var =
> +
> nir_deref_instr_get_variable(nir_src_as_deref(dup_store_intr->src[0]));
> +
> +   if (!can_replace_varying(dup_out_var, dup_store_intr))
> +  return false;
> +
> +   nir_function_impl *impl = nir_shader_get_entrypoint(shader);
> +
> +   nir_builder b;
> +   nir_builder_init(, impl);
> +
> +   bool progress = false;
> +   nir_foreach_block(block, impl) {
> +  nir_foreach_instr(instr, block) {
> + if (instr->type != nir_instr_type_intrinsic)
> +continue;
> +
> + nir_intrinsic_instr *intr = nir_instr_as_intrinsic(instr);
> + if (intr->intrinsic != nir_intrinsic_load_deref)
> +continue;
> +
> + nir_variable *in_var =
> +nir_deref_instr_get_variable(nir_src_as_deref(intr->src[0]));
> +
> + if (in_var->data.mode != nir_var_shader_in)
> +continue;
> +
> + if (in_var->data.location != dup_out_var->data.location ||
> + in_var->data.location_frac !=
> dup_out_var->data.location_frac ||
> + in_var->data.interpolation != input_var->data.interpolation
> ||
> + get_interp_loc(in_var) != get_interp_loc(input_var))
> +continue;
> +
> + b.cursor = nir_before_instr(instr);
> +
> + nir_ssa_def *load = nir_load_var(, input_var);
> + nir_ssa_def_rewrite_uses(>dest.ssa, nir_src_for_ssa(load));
> +
> + progress = true;
> +  }
> +   }
> +
> +   return progress;
> +}
> +
>  bool
>  nir_link_opt_varyings(nir_shader *producer, nir_shader *consumer)
>  {
> @@ -795,6 +867,10 @@ nir_link_opt_varyings(nir_shader 

Re: [Mesa-dev] last call for autotools

[Dave Airlie]

On Fri, 14 Dec 2018 at 16:19, Ilia Mirkin  wrote:
>
> I have to say that the user experience for autotools is WAY better
> than for meson. As a concrete example, I had a meson build. Then I
> updated meson (0.48.1 to 0.48.2). Now ninja -C foo doesn't work. meson
> --reconfigure (which presumably is what ninja would end up running)
> doesn't work. http://paste.debian.net/hidden/cf777f3e/
>
> So now what? I don't remember how that config was done, except that it
> was done the way I decided I needed it at the time. I have no way to
> recover it. With autotools, in such cases (which are immensely rare),
> you just run "head config.log" and it tells you what you did last
> time. And by updating the build component, now I have to rebuild
> EVERYTHING?
>
> meson is not at a point where it Just Works. It ... sometimes works.
> The fact that everyone has scripts which wrap meson is a symptom of
> that. I don't feel good about dumping the system that everyone (and I
> don't just mean people on this list -- I mean the wider open source
> community as well) knows how to use and has worked reliably for years
> (decades, really) to be replaced by a system that everyone is having
> problems with (it's not just me -- others are running into trouble too
> -- just look at this thread). It's just not ready yet.
>

I've kinda stayed out of this discussion as I wanted to see which way
the wind was blowing, and I like to tune my workflows to the project
not vice-versa as much as possible.

At this point I don't like using meson in my workflows for two main
reasons: (mostly like Ilia)

a) meson upgrades crap out my builddirs. (0.49 will fix it? then yay
when 0.49 lands in distros, I'll consider this done)
b) I can't extract either the original configuration line or even a
give me a command line to reproduce the current state so I can cut and
paste it.

The solution everyone is giving me is hacks using locally prepared
scripts, which doesn't scale for me at all. Why am I different you
ask?

Unlike most people I work on nearly every driver in the tree, in GL
and Vulkan, in gallium, in sw drivers, and I do it all the time and I
do it across lots of machines.

Currently in my eyeline I have 5 regular work machines (3 desktops, 2
laptops), in my RH office I have currently 2 workstations and another
2 laptops, I regularly bring new machines in on other distros (Fedora
29 vs RHEL7 vs RHEL8), I regularly image machines from scratch in RH
network.

On one workstation I have lots of main work trees currently (mesa
master, vulkan dev, zink dev, opencl dev, iris dev, virgl dev, radv
wip trees), nuking builds and having to remember what command line I
used to configure them is a losing battle for my memory.

I really don't want to have special scripts that I have to remember to
bring with me across installs, the extra scripts you have are a
workaround for meson not a fix for my problem. scripts work fine if
you are just building anv, i965, when you move around a lot they suck.

So personally I don't think meson is going to enhance my workflow
until those two things get sorted out in the project, if (a) is
already solved, then maybe we can get upstream to solve (b), and
revisit the removal of autotools.

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

Re: [Mesa-dev] [PATCH] st/nir: Use nir_src_as_uint for tokens

[Marek Olšák]

Reviewed-by: Marek Olšák 

Marek

On Fri, Dec 14, 2018 at 12:20 PM Jason Ekstrand 
wrote:

> ---
>  src/mesa/state_tracker/st_nir_lower_builtin.c | 6 +-
>  1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/src/mesa/state_tracker/st_nir_lower_builtin.c
> b/src/mesa/state_tracker/st_nir_lower_builtin.c
> index 195dc40b2ef..ab74d3183dc 100644
> --- a/src/mesa/state_tracker/st_nir_lower_builtin.c
> +++ b/src/mesa/state_tracker/st_nir_lower_builtin.c
> @@ -107,10 +107,6 @@ get_variable(lower_builtin_state *state,
> nir_deref_path *path,
> memcpy(tokens, element->tokens, sizeof(tokens));
>
> if (path->path[idx]->deref_type == nir_deref_type_array) {
> -  nir_const_value *c =
> nir_src_as_const_value(path->path[idx]->arr.index);
> -
> -  assert(c);
> -
>/* we need to fixup the array index slot: */
>switch (tokens[0]) {
>case STATE_MODELVIEW_MATRIX:
> @@ -123,7 +119,7 @@ get_variable(lower_builtin_state *state,
> nir_deref_path *path,
>case STATE_TEXGEN:
>case STATE_TEXENV_COLOR:
>case STATE_CLIPPLANE:
> - tokens[1] = c->u32[0];
> + tokens[1] = nir_src_as_uint(path->path[idx]->arr.index);
>   break;
>}
> }
> --
> 2.19.2
>
> ___
> 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] [Mesa-stable] [PATCH 1/2] pci_ids: add new vega10 pci ids

[Marek Olšák]

Reviewed-by: Marek Olšák 

Marek

On Fri, Dec 14, 2018 at 12:01 PM Alex Deucher  wrote:

> Ping?
>
> Alex
> On Fri, Dec 7, 2018 at 4:11 PM Alex Deucher  wrote:
> >
> > Signed-off-by: Alex Deucher 
> > Cc: mesa-sta...@lists.freedesktop.org
> > ---
> >  include/pci_ids/radeonsi_pci_ids.h | 8 +++-
> >  1 file changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/include/pci_ids/radeonsi_pci_ids.h
> b/include/pci_ids/radeonsi_pci_ids.h
> > index 35ea3559b02..f7defc4197a 100644
> > --- a/include/pci_ids/radeonsi_pci_ids.h
> > +++ b/include/pci_ids/radeonsi_pci_ids.h
> > @@ -227,8 +227,14 @@ CHIPSET(0x6863, VEGA10)
> >  CHIPSET(0x6864, VEGA10)
> >  CHIPSET(0x6867, VEGA10)
> >  CHIPSET(0x6868, VEGA10)
> > -CHIPSET(0x687F, VEGA10)
> > +CHIPSET(0x6869, VEGA10)
> > +CHIPSET(0x686A, VEGA10)
> > +CHIPSET(0x686B, VEGA10)
> >  CHIPSET(0x686C, VEGA10)
> > +CHIPSET(0x686D, VEGA10)
> > +CHIPSET(0x686E, VEGA10)
> > +CHIPSET(0x686F, VEGA10)
> > +CHIPSET(0x687F, VEGA10)
> >
> >  CHIPSET(0x69A0, VEGA12)
> >  CHIPSET(0x69A1, VEGA12)
> > --
> > 2.13.6
> >
> ___
> mesa-stable mailing list
> mesa-sta...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-stable
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] glx: Fix compilation with GLX_USE_WINDOWSGL

[Jon Turney]

On 14/12/2018 15:15, Emil Velikov wrote:

On Fri, 14 Dec 2018 at 14:56, Jon Turney  wrote:


Sadly, the GLX_USE_APPLEGL and GLX_USE_WINDOWSGL cases are not identical
(because GLX_USE_WINDOWSGL uses vtables rather than a maze of ifdefs)

Include  again, as functions prototyped by it are used in
the GLX_USE_WINDOWSGL path.

Make the include guard around the __glxGetMscRate() definition match the
one at it's declaration again, as it's referenced from dri_common.c
which is built for GLX_USE_WINDOWSGL.

Cc: Emil Velikov 
Fixes: a95ec138 ("glx: mandate xf86vidmode only for "drm" dri platforms")
Signed-off-by: Jon Turney 

Reviewed-by: Emil Velikov 

Jon, when you have some time, can you please write a Travis config for Cygwin.
This way we can do some basic checks a bit easier.


Yeah, that would be a good idea.

I've posted an updated version of my patchset to add a cygwin build for 
appveyor.


Doing this on travis will be challenging, especially to run the tests.


If/when we move to gitlab CI we can simply copy it over ;-)


(It is apparently now possible to use appveyor as a CI provider for a 
self-hosted gitlab instance (see [1]), but I've no idea how to set that up)


[1] https://github.com/appveyor/ci/issues/711
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2/2] appveyor: Add a Cygwin build script

[Jon Turney]

Signed-off-by: Jon Turney 
---
 appveyor.yml| 19 +-
 scripts/appveyor_cygwin.bat | 40 +
 2 files changed, 54 insertions(+), 5 deletions(-)
 create mode 100644 scripts/appveyor_cygwin.bat

diff --git a/appveyor.yml b/appveyor.yml
index 0ec3a1e7bfe..9c6e5acd370 100644
--- a/appveyor.yml
+++ b/appveyor.yml
@@ -38,6 +38,9 @@ cache:
 - '%LOCALAPPDATA%\pip\Cache -> appveyor.yml'
 - win_flex_bison-2.5.15.zip
 - llvm-5.0.1-msvc2017-mtd.7z
+- C:\pkgcache
+- 'C:\cygwin64\home\%USERNAME%\.ccache'
+- 'C:\cygwin\home\%USERNAME%\.ccache'
 
 os: Visual Studio 2017
 
@@ -47,17 +50,23 @@ init:
 - git config --global core.autocrlf true
 
 environment:
-  WINFLEXBISON_VERSION: 2.5.15
-  LLVM_ARCHIVE: llvm-5.0.1-msvc2017-mtd.7z
+  matrix:
+  - compiler: msvc
+WINFLEXBISON_VERSION: 2.5.15
+LLVM_ARCHIVE: llvm-5.0.1-msvc2017-mtd.7z
+  - compiler: cygwin
+arch: x64
 
 install:
-- call scripts\appveyor_msvc.bat install
+- call scripts\appveyor_%compiler%.bat install
 
 build_script:
-- call scripts\appveyor_msvc.bat build_script
+- call scripts\appveyor_%compiler%.bat build_script
 
 after_build:
-- call scripts\appveyor_msvc.bat after_build
+- call scripts\appveyor_%compiler%.bat after_build
+
+test: off
 
 # It's possible to setup notification here, as described in
 # http://www.appveyor.com/docs/notifications#appveyor-yml-configuration , but
diff --git a/scripts/appveyor_cygwin.bat b/scripts/appveyor_cygwin.bat
new file mode 100644
index 000..831270b8cd3
--- /dev/null
+++ b/scripts/appveyor_cygwin.bat
@@ -0,0 +1,40 @@
+set PKGCACHE=C:\pkgcache
+set CYGWIN_MIRROR=http://cygwin.mirror.constant.com
+
+if _%arch%_ == _x64_ set SETUP=setup-x86_64.exe && set CYGWIN_ROOT=C:\cygwin64
+if _%arch%_ == _x86_ set SETUP=setup-x86.exe && set CYGWIN_ROOT=C:\cygwin
+
+set PATH=%CYGWIN_ROOT%\bin;%SYSTEMROOT%\system32
+
+goto %1
+
+:install
+echo Updating Cygwin and installing build prerequsites
+%CYGWIN_ROOT%\%SETUP% -qnNdO -R "%CYGWIN_ROOT%" -s "%CYGWIN_MIRROR%" -l 
"%PKGCACHE%" -g -P ^
+bison,^
+ccache,^
+flex,^
+glproto,^
+libX11-devel,^
+libX11-xcb-devel,^
+libXdamage-devel,^
+libXext-devel,^
+libXfixes-devel,^
+libexpat-devel,^
+libllvm-devel,^
+libxcb-dri2-devel,^
+libxcb-glx-devel,^
+libxcb-xfixes-devel,^
+meson,^
+ninja,^
+python3-mako,^
+zlib-devel
+goto :eof
+
+:build_script
+bash -lc "cd $APPVEYOR_BUILD_FOLDER; meson _build -Degl=false 
--wrap-mode=nofallback && ninja -C _build"
+goto :eof
+
+:after_build
+bash -lc "cd $APPVEYOR_BUILD_FOLDER; ninja -C _build test"
+goto :eof
-- 
2.17.0

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

[Mesa-dev] [PATCH 1/2] appveyor: put build steps in a script, rather than inline in appveyor.yml

[Jon Turney]

Signed-off-by: Jon Turney 
---
 appveyor.yml  | 32 +++-
 scripts/appveyor_msvc.bat | 38 ++
 2 files changed, 41 insertions(+), 29 deletions(-)
 create mode 100644 scripts/appveyor_msvc.bat

diff --git a/appveyor.yml b/appveyor.yml
index ccb84fd3403..0ec3a1e7bfe 100644
--- a/appveyor.yml
+++ b/appveyor.yml
@@ -51,39 +51,13 @@ environment:
   LLVM_ARCHIVE: llvm-5.0.1-msvc2017-mtd.7z
 
 install:
-# Check git config
-- git config core.autocrlf
-# Check pip
-- python --version
-- python -m pip --version
-# Install Mako
-- python -m pip install Mako==1.0.7
-# Install pywin32 extensions, needed by SCons
-- python -m pip install pypiwin32
-# Install python wheels, necessary to install SCons via pip
-- python -m pip install wheel
-# Install SCons
-- python -m pip install scons==3.0.1
-- scons --version
-# Install flex/bison
-- set WINFLEXBISON_ARCHIVE=win_flex_bison-%WINFLEXBISON_VERSION%.zip
-- if not exist "%WINFLEXBISON_ARCHIVE%" appveyor DownloadFile 
"https://github.com/lexxmark/winflexbison/releases/download/v%WINFLEXBISON_VERSION%/%WINFLEXBISON_ARCHIVE%;
-- 7z x -y -owinflexbison\ "%WINFLEXBISON_ARCHIVE%" > nul
-- set Path=%CD%\winflexbison;%Path%
-- win_flex --version
-- win_bison --version
-# Download and extract LLVM
-- if not exist "%LLVM_ARCHIVE%" appveyor DownloadFile 
"https://people.freedesktop.org/~jrfonseca/llvm/%LLVM_ARCHIVE%;
-- 7z x -y "%LLVM_ARCHIVE%" > nul
-- mkdir llvm\bin
-- set LLVM=%CD%\llvm
+- call scripts\appveyor_msvc.bat install
 
 build_script:
-- scons -j%NUMBER_OF_PROCESSORS% MSVC_VERSION=14.1 llvm=1
+- call scripts\appveyor_msvc.bat build_script
 
 after_build:
-- scons -j%NUMBER_OF_PROCESSORS% MSVC_VERSION=14.1 llvm=1 check
-
+- call scripts\appveyor_msvc.bat after_build
 
 # It's possible to setup notification here, as described in
 # http://www.appveyor.com/docs/notifications#appveyor-yml-configuration , but
diff --git a/scripts/appveyor_msvc.bat b/scripts/appveyor_msvc.bat
new file mode 100644
index 000..6a85e830ec8
--- /dev/null
+++ b/scripts/appveyor_msvc.bat
@@ -0,0 +1,38 @@
+goto %1
+
+:install
+rem Check git config
+git config core.autocrlf
+rem Check pip
+python --version
+python -m pip --version
+rem Install Mako
+python -m pip install Mako==1.0.7
+rem Install pywin32 extensions, needed by SCons
+python -m pip install pypiwin32
+rem Install python wheels, necessary to install SCons via pip
+python -m pip install wheel
+rem Install SCons
+python -m pip install scons==3.0.1
+call scons --version
+rem Install flex/bison
+set WINFLEXBISON_ARCHIVE=win_flex_bison-%WINFLEXBISON_VERSION%.zip
+if not exist "%WINFLEXBISON_ARCHIVE%" appveyor DownloadFile 
"https://github.com/lexxmark/winflexbison/releases/download/v%WINFLEXBISON_VERSION%/%WINFLEXBISON_ARCHIVE%;
+7z x -y -owinflexbison\ "%WINFLEXBISON_ARCHIVE%" > nul
+set Path=%CD%\winflexbison;%Path%
+win_flex --version
+win_bison --version
+rem Download and extract LLVM
+if not exist "%LLVM_ARCHIVE%" appveyor DownloadFile 
"https://people.freedesktop.org/~jrfonseca/llvm/%LLVM_ARCHIVE%;
+7z x -y "%LLVM_ARCHIVE%" > nul
+mkdir llvm\bin
+set LLVM=%CD%\llvm
+goto :eof
+
+:build_script
+call scons -j%NUMBER_OF_PROCESSORS% MSVC_VERSION=14.1 llvm=1
+goto :eof
+
+:after_build
+call scons -j%NUMBER_OF_PROCESSORS% MSVC_VERSION=14.1 llvm=1 check
+goto :eof
-- 
2.17.0

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

[Mesa-dev] [PATCH 0/2] appveyor: add Cygwin

[Jon Turney]

This is a refresh of my patch set from [1], which I posted, and then kind of 
forgot about.

[1] https://lists.freedesktop.org/archives/mesa-dev/2018-February/185066.html

Jon Turney (2):
  appveyor: put build steps in a script, rather than inline in
appveyor.yml
  appveyor: Add a Cygwin build script

 appveyor.yml| 43 +++--
 scripts/appveyor_cygwin.bat | 40 ++
 scripts/appveyor_msvc.bat   | 38 
 3 files changed, 91 insertions(+), 30 deletions(-)
 create mode 100644 scripts/appveyor_cygwin.bat
 create mode 100644 scripts/appveyor_msvc.bat

-- 
2.17.0

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

Re: [Mesa-dev] [PATCH] meson: make it possible to build etnaviv's cmdline compiler

[Dylan Baker]

Quoting Christian Gmeiner (2018-12-13 12:07:23)
> Signed-off-by: Christian Gmeiner 
> ---
>  meson.build | 2 +-
>  meson_options.txt   | 2 +-
>  src/gallium/drivers/etnaviv/meson.build | 3 ++-
>  3 files changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/meson.build b/meson.build
> index fe647f682c..f516780115 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -57,7 +57,7 @@ with_osmesa = get_option('osmesa')
>  with_swr_arches = get_option('swr-arches')
>  with_tools = get_option('tools')
>  if with_tools.contains('all')
> -  with_tools = ['freedreno', 'glsl', 'intel', 'nir', 'nouveau', 'xvmc']
> +  with_tools = ['etnaviv', 'freedreno', 'glsl', 'intel', 'nir', 'nouveau', 
> 'xvmc']
>  endif
>  
>  dri_drivers_path = get_option('dri-drivers-path')
> diff --git a/meson_options.txt b/meson_options.txt
> index a1d5ab0e18..005356b14c 100644
> --- a/meson_options.txt
> +++ b/meson_options.txt
> @@ -301,7 +301,7 @@ option(
>'tools',
>type : 'array',
>value : [],
> -  choices : ['freedreno', 'glsl', 'intel', 'intel-ui', 'nir', 'nouveau', 
> 'xvmc', 'all'],
> +  choices : ['etnaviv', 'freedreno', 'glsl', 'intel', 'intel-ui', 'nir', 
> 'nouveau', 'xvmc', 'all'],
>description : 'List of tools to build. (Note: `intel-ui` selects `intel`)',
>  )
>  option(
> diff --git a/src/gallium/drivers/etnaviv/meson.build 
> b/src/gallium/drivers/etnaviv/meson.build
> index 1733024ac9..63553dec51 100644
> --- a/src/gallium/drivers/etnaviv/meson.build
> +++ b/src/gallium/drivers/etnaviv/meson.build
> @@ -101,7 +101,8 @@ etnaviv_compiler = executable(
>include_directories : [inc_include, inc_src, inc_gallium, inc_gallium_aux],
>link_with : [libmesa_util, libgallium, libetnaviv],
>dependencies : [dep_libdrm_etnaviv],
> -  build_by_default : false,
> +  build_by_default : with_tools.contains('etnaviv'),
> +  install : with_tools.contains('etnaviv'),
>  )
>  
>  driver_etnaviv = declare_dependency(
> -- 
> 2.19.2
> 

You technically can build it already, `ninja
src/gallium/drivers/etnaviv/etnaviv_compiler` should do the trick. This patch is
obviously simpler and easier to use, and is in line with how other tools in mesa
work, but can we change the commit message to something like:

meson: add etnaviv to the tools option

Or something similar.

with that:
Reviewed-by: Dylan Baker 


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

[Mesa-dev] [PATCH] radv: don't set surf_index for stencil-only images

[Rhys Perry]

Fixes: f8d5b377c8b ('radv: set cb base tile swizzles for MRT speedups (v4)')
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108116
Signed-off-by: Rhys Perry 
---
Unfortunately I was not able to test this patch on a Polaris due to hardware
issues. It fixed the deqp-vk tests mentioned in the bugzilla without regressions
on Vega though.

 src/amd/vulkan/radv_image.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/amd/vulkan/radv_image.c b/src/amd/vulkan/radv_image.c
index 2cff4d5283..2bd74e202f 100644
--- a/src/amd/vulkan/radv_image.c
+++ b/src/amd/vulkan/radv_image.c
@@ -986,7 +986,7 @@ radv_image_create(VkDevice _device,
 
image->shareable = vk_find_struct_const(pCreateInfo->pNext,

EXTERNAL_MEMORY_IMAGE_CREATE_INFO_KHR) != NULL;
-   if (!vk_format_is_depth(pCreateInfo->format) && !create_info->scanout 
&& !image->shareable) {
+   if (!vk_format_is_depth_or_stencil(pCreateInfo->format) && 
!create_info->scanout && !image->shareable) {
image->info.surf_index = >image_mrt_offset_counter;
}
 
-- 
2.19.2

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

Re: [Mesa-dev] last call for autotools

[Jason Ekstrand]

On Fri, Dec 14, 2018 at 11:25 AM Andre Heider  wrote:

> On 14/12/2018 17:53, Dylan Baker wrote:
> > Quoting Gert Wollny (2018-12-14 03:44:32)
> >> Am Montag, den 10.12.2018, 15:10 -0800 schrieb Dylan Baker:
> >> (2) It would be nice if Meson would distribute some default cross build
> >> files, currently everybody has to roll its own, and I guess in the end
> >> they all look mostly the same.
> >
> > Please ask your distro to write and distribute the cross files. It's
> simply
> > impossible for meson to distribute them for a huge number of reasons, but
> > basically it boils down to too many distros with too many differences. I
> have
> > done basically everything I can (personally) to make this easier,
> including
> > adding support for loading cross files from XDG paths
> (/usr/share/meson/cross,
> > etc)
> >
> >>
> >> (3) I also noted that with across build one has to set the library
> >> install directory manually, because it defaults to the directory used
> >> for the build machine - i.e. a i386 cross build on debian amd64 should
> >> set the lib install directory on Debian to "lib/i386-linux-gnu" but it
> >> sets it to "lib/x86_64-linux-gnu"
> >
> > There is this issue: https://github.com/mesonbuild/meson/issues/4008
> >
> > This is another case that is really hard to handle because of the way
> different
> > distros have handled installing x86 and x86_64 binaries on the same OS.
> To name
> > a few:
> > debian : lib/$gnu-tri/
> > arch   : lib/ + lib32/
> > fedora : lib64/ + lib32/
> >
> > I'm sure there are more, but getting that right all of the time is
> actually
> > pretty hard. I'll look into it.
>
> It's not just the libdir, there's no real way for a project to provide
> all the required cross settings so it works everywhere. Like the
> pkg-config binary name for e.g. cross-compiling 32bit binaries. I didn't
> find anything user friendly, so I worked around that on another project
> [0]. And I'm sure there's more.
>
> While all that is doable, it is annoying. Isn't there any way for meson
> to provide a standard set of cross files for distros? If it's the
> distro's responsibility to provide these without any guidelines it's
> just going to be another mess, because either a distro doesn't at all or
> they all do it differently.
>

I think it's very easy to mistake the way autotools handles things for
somehow being easier.  For quite some time now, Fedora has carried a
patched version of autools which has a special case to automatically
redirects you to lib64 if --prefix=/usr.  It's horrible because it means
that autotools behaves differently with every other possible prefix unless
you manually set libdir.  If they're going to carry patches against
autotools, they can carry a meson cross file.  Autotools is only "easier"
because distros have beat on it with a hammer until it mostly works.

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

Re: [Mesa-dev] [PATCH] WIP: meson: allow building DRI loaders without a DRI driver

[Dylan Baker]

Quoting Emil Velikov (2018-12-13 08:15:57)
> From: Emil Velikov 
> 
> Reasonably often people will want to build the loader w/o any drivers.
> Be that debugging an issue in the former, distribution bundle or other.
> 
> Currently there is an artificial restriction preventing people to build
> a config like the following:
> 
>  meson build/ -Dglx=dri -Ddri-drivers= -Dvulkan-drivers= -Dgallium-drivers=
> 
> Cc: Dylan Baker 
> Signed-off-by: Emil Velikov 
> ---
> This is a WIP, since it's obviously incomplete/wrong. Input or fix
> would be appreciated.
> 
> Thanks
> Emil
> ---
>  meson.build | 12 +---
>  1 file changed, 1 insertion(+), 11 deletions(-)
> 
> diff --git a/meson.build b/meson.build
> index 2aa2794f971..e1d6561c1a3 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -285,14 +285,6 @@ if with_glx == 'dri'
> endif
>  endif
>  
> -if not (with_dri or with_gallium or with_glx == 'xlib' or with_glx == 
> 'gallium-xlib')
> -  with_gles1 = false
> -  with_gles2 = false
> -  with_opengl = false
> -  with_any_opengl = false
> -  with_shared_glapi = false
> -endif
> -
>  _gbm = get_option('gbm')
>  if _gbm == 'auto'
>with_gbm = system_has_kms_drm and with_dri
> @@ -352,9 +344,7 @@ if with_glx != 'disabled'
>error('xlib conflicts with any dri driver')
>  endif
>elif with_glx == 'dri'
> -if not with_dri
> -  error('dri based GLX requires at least one DRI driver')
> -elif not with_shared_glapi
> +if not with_shared_glapi
>error('dri based GLX requires shared-glapi')
>  endif
>endif
> -- 
> 2.19.2
> 

I'll have to think about this some more, I'm still not exactly sure why you'd
want to build the loader without a driver (although I could see why you might
want the driver without the loader).

Dylan


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 01/18] meson: don't require glx/egl/gbm with gallium drivers

[Dylan Baker]

Quoting Emil Velikov (2018-12-13 08:05:50)
> From: Emil Velikov 
> 
> The gallium drivers do not require a DRI loader. Drop the artificial
> and unnecessary restriction.
> 
> Fixes: af9d276134d ("meson: build libmesa_gallium")
> Signed-off-by: Emil Velikov 
> ---
> There are a few use cases:
> 
>  - building a gallium state-tracker, say opencl in st/clover, without
> having to build the dri one (st/dri)
> Use case: shipping only a opencl/omx/va driver.
> 
>  - building dri loader without an actual DRI driver.
> Use case: working/updating libGL/libGLX_mesa and egl/gbm equivalents.
> 
> This patch should address the former, although the latter seems figgly
> to fix from a quick look. Input and patches will be appreciated.
> ---
>  meson.build | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/meson.build b/meson.build
> index db2d27d2459..2aa2794f971 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -387,9 +387,9 @@ endif
>  if with_any_vk and (with_platform_x11 and not with_dri3)
>error('Vulkan drivers require dri3 for X11 support')
>  endif
> -if with_dri or with_gallium
> -  if with_glx == 'disabled' and not with_egl and not with_platform_haiku
> -error('building dri or gallium drivers require at least one window 
> system')
> +if with_dri
> +  if with_glx == 'disabled' and not with_egl and not with_gbm
> +error('building dri drivers require at least one windowing system')
>endif
>  endif
>  
> -- 
> 2.19.2
> 

I'm not super convinced that building the loader and drivers separately is a
good idea, but building just clover (or media I guess) does seem like a real use
case.

Reviewed-by: Dylan Baker 


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 18/18] travis: meson: port gallium build combinations over

[Dylan Baker]

Quoting Emil Velikov (2018-12-13 08:06:07)
> From: Emil Velikov 
> 
> This commit adds a number of build combos:
> 
>  - Gallium Drivers {SWR, RadeonSI, Others)
> Each one has different LLVM requirements. Building SWR alone is twice
> as slow as all other drivers combined.
> 
>  - Gallium ST Clover LLVM {5,6,7}
> Because C++ API changes all the time. Analogous to above building
> Clover takes as much time as building all other ST combined.
> 
>  - Gallium ST Others
> Nouveau is used, instead of i915g since meson has explicit target
> tracking. Meaning that a configure error is throws if we use i915g
> with say va, vdpau or others.
> 
> Note: LLVM prior to 5.0 is intentionally dropped. If needed we can add
> that later.
> 
> Signed-off-by: Emil Velikov 
> ---
>  .travis.yml | 187 
>  1 file changed, 187 insertions(+)
> 
> diff --git a/.travis.yml b/.travis.yml
> index 125d6ce3c68..b70df99d67e 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -98,6 +98,193 @@ matrix:
>  - libxfixes-dev
>  - python3-pip
>  - python3-setuptools
> +- env:
> +# NOTE: Building SWR is 2x (yes two) times slower than all the other
> +# gallium drivers combined.
> +# Start this early so that it doesn't hunder the run time.
> +- LABEL="meson Gallium Drivers SWR"
> +- BUILD=meson
> +- UNWIND="true"
> +- DRI_LOADERS="-Dglx=disabled -Degl=false -Dgbm=false"
> +- GALLIUM_ST="-Ddri3=false -Dgallium-vdpau=false 
> -Dgallium-xvmc=false -Dgallium-omx=disabled -Dgallium-va=false 
> -Dgallium-xa=false -Dgallium-nine=false -Dgallium-opencl=disabled"
> +- GALLIUM_DRIVERS="swr"
> +- LLVM_VERSION=6.0
> +- LLVM_CONFIG="llvm-config-${LLVM_VERSION}"
> +  addons:
> +apt:
> +  packages:
> +- llvm-6.0-dev
> +# Common
> +- xz-utils
> +- libexpat1-dev
> +- libx11-xcb-dev
> +- libelf-dev
> +- libunwind8-dev
> +- python3.5
> +- python3-pip
> +- python3-setuptools
> +- env:
> +- LABEL="meson Gallium Drivers RadeonSI"
> +- BUILD=meson
> +- UNWIND="true"
> +- DRI_LOADERS="-Dglx=disabled -Degl=false -Dgbm=false"
> +- GALLIUM_ST="-Ddri3=false -Dgallium-vdpau=false 
> -Dgallium-xvmc=false -Dgallium-omx=disabled -Dgallium-va=false 
> -Dgallium-xa=false -Dgallium-nine=false -Dgallium-opencl=disabled"
> +- GALLIUM_DRIVERS="radeonsi"
> +- LLVM_VERSION=7
> +- LLVM_CONFIG="llvm-config-${LLVM_VERSION}"
> +  addons:
> +apt:
> +  sources:
> +- sourceline: 'deb http://apt.llvm.org/xenial/ 
> llvm-toolchain-xenial-7 main'
> +  key_url: https://apt.llvm.org/llvm-snapshot.gpg.key
> +  packages:
> +# From sources above
> +- llvm-7-dev
> +# Common
> +- xz-utils
> +- libexpat1-dev
> +- libx11-xcb-dev
> +- libelf-dev
> +- libunwind8-dev
> +- python3.5
> +- python3-pip
> +- python3-setuptools
> +- env:
> +- LABEL="meson Gallium Drivers Other"
> +- BUILD=meson
> +- UNWIND="true"
> +- DRI_LOADERS="-Dglx=disabled -Degl=false -Dgbm=false"
> +- GALLIUM_ST="-Ddri3=false -Dgallium-vdpau=false 
> -Dgallium-xvmc=false -Dgallium-omx=disabled -Dgallium-va=false 
> -Dgallium-xa=false -Dgallium-nine=false -Dgallium-opencl=disabled"
> +- 
> GALLIUM_DRIVERS="i915,nouveau,pl111,r300,r600,freedreno,svga,swrast,v3d,vc4,virgl,etnaviv,imx"
> +- LLVM_VERSION=5.0
> +- LLVM_CONFIG="llvm-config-${LLVM_VERSION}"
> +  addons:
> +apt:
> +  packages:
> +# LLVM packaging is broken and misses these dependencies
> +- libedit-dev
> +- llvm-5.0-dev
> +# Common
> +- xz-utils
> +- libexpat1-dev
> +- libx11-xcb-dev
> +- libelf-dev
> +- libunwind8-dev
> +- python3.5
> +- python3-pip
> +- python3-setuptools
> +- env:
> +- LABEL="meson Gallium ST Clover LLVM-5.0"
> +- BUILD=meson
> +- UNWIND="true"
> +- DRI_LOADERS="-Dglx=disabled -Degl=false -Dgbm=false"
> +- GALLIUM_ST="-Ddri3=false -Dgallium-vdpau=false 
> -Dgallium-xvmc=false -Dgallium-omx=disabled -Dgallium-va=false 
> -Dgallium-xa=false -Dgallium-nine=false -Dgallium-opencl=icd"
> +- GALLIUM_DRIVERS="r600"
> +- LLVM_VERSION=5.0
> +- LLVM_CONFIG="llvm-config-${LLVM_VERSION}"
> +  addons:
> +apt:
> +  packages:
> +- libclc-dev
> +# LLVM packaging is broken and misses these dependencies
> +- libedit-dev
> +- llvm-5.0-dev
> +- 

Re: [Mesa-dev] [PATCH 14/18] travis: meson: use FOO_DRIVERS directly

[Dylan Baker]

Quoting Emil Velikov (2018-12-13 08:06:03)
> From: Emil Velikov 
> 
> It makes for a shorter MESON_OPTIONS and cleaner handling.
> 
> Signed-off-by: Emil Velikov 
> ---
>  .travis.yml | 13 -
>  1 file changed, 4 insertions(+), 9 deletions(-)
> 
> diff --git a/.travis.yml b/.travis.yml
> index 8cb7f8b95c1..4966f7eb1bf 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -34,8 +34,6 @@ matrix:
>  - env:
>  - LABEL="meson Vulkan"
>  - BUILD=meson
> -- DRI_DRIVERS=""
> -- GALLIUM_DRIVERS=""
>  - VULKAN_DRIVERS="intel,amd"
>  - LLVM_VERSION=7
>  - LLVM_CONFIG="llvm-config-${LLVM_VERSION}"
> @@ -58,8 +56,6 @@ matrix:
>  - LABEL="meson loaders/classic DRI"
>  - BUILD=meson
>  - DRI_DRIVERS="i915,i965,r100,r200,swrast,nouveau"
> -- GALLIUM_DRIVERS=""
> -- VULKAN_DRIVERS=""
>addons:
>  apt:
>packages:
> @@ -636,10 +632,6 @@ script:
>  MESON_OPTIONS="-Degl=false"
>fi
>  
> -  if test "x$TRAVIS_OS_NAME" == xlinux; then
> -MESON_OPTIONS="-Ddri-drivers=${DRI_DRIVERS:-[]} 
> -Dgallium-drivers=${GALLIUM_DRIVERS:-[]} 
> -Dvulkan-drivers=${VULKAN_DRIVERS:-[]}"
> -  fi
> -
># We need to control the version of llvm-config we're using, so we'll
># generate a native file to do so. This requires meson >=0.49
>#
> @@ -650,7 +642,10 @@ script:
>export CFLAGS="$CFLAGS -isystem`pwd`"
>meson _build $MESON_OPTIONS \
> --native-file=native.file \
> -   -Dbuild-tests=true
> +   -Dbuild-tests=true \
> +   -Ddri-drivers=${DRI_DRIVERS:-[]} \
> +   -Dgallium-drivers=${GALLIUM_DRIVERS:-[]} \
> +   -Dvulkan-drivers=${VULKAN_DRIVERS:-[]}
>meson configure _build
>ninja -C _build
>ninja -C _build test
> -- 
> 2.19.2

Much cleaner :)
Reviewed-by: Dylan Baker 


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 11/18] travis: meson: use native files to override llvm-config

[Dylan Baker]

Quoting Emil Velikov (2018-12-13 08:06:00)
> From: Dylan Baker 
> 
> This is the supported way to do this, and should be more robust and
> reliable.
> 
> v2: [Emil]
>  - enable backslash escapes
>  - don't hardcode the path
>  - pass the argument directly to meson
> 
> Reviewed-by: Emil Velikov  (v1)
> Signed-off-by: Emil Velikov 
> ---
>  .travis.yml | 22 +-
>  1 file changed, 5 insertions(+), 17 deletions(-)
> 
> diff --git a/.travis.yml b/.travis.yml
> index c69f322d7b3..c398ebc748a 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -650,28 +650,16 @@ script:
>  MESON_OPTIONS="-Ddri-drivers=${DRI_DRIVERS:-[]} 
> -Dgallium-drivers=${GALLIUM_DRIVERS:-[]} 
> -Dvulkan-drivers=${VULKAN_DRIVERS:-[]}"
>fi
>  
> -  # Travis CI has moved to LLVM 5.0, and meson is detecting
> -  # automatically the available version in /usr/local/bin based on
> -  # the PATH env variable order preference.
> +  # We need to control the version of llvm-config we're using, so we'll
> +  # generate a native file to do so. This requires meson >=0.49
>#
> -  # As for 0.44.x, Meson cannot receive the path to the
> -  # llvm-config binary as a configuration parameter. See
> -  # https://github.com/mesonbuild/meson/issues/2887 and
> -  # 
> https://github.com/dcbaker/meson/commit/7c8b6ee3fa42f43c9ac7dcacc61a77eca3f1bcef
> -  #
> -  # We want to use the custom (APT) installed version. Therefore,
> -  # let's make Meson find our wanted version sooner than the one
> -  # at /usr/local/bin
> -  #
> -  # Once this is corrected, we would still need a patch similar
> -  # to:
> -  # 
> https://lists.freedesktop.org/archives/mesa-dev/2017-December/180217.html
> -  test -f /usr/bin/$LLVM_CONFIG && ln -s /usr/bin/$LLVM_CONFIG 
> $HOME/prefix/bin/llvm-config
> +  echo -e "[binaries]\nllvm-config = '`which $LLVM_CONFIG`'" > 
> native.file
>  
>$LLVM_CONFIG --version
>  
>export CFLAGS="$CFLAGS -isystem`pwd`"
> -  meson _build $MESON_OPTIONS
> +  meson _build $MESON_OPTIONS \
> +   --native-file=native.file
>meson configure _build
>ninja -C _build
>  fi
> -- 
> 2.19.2
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev

I feel weird reviewing my own patch, but for your changes:
Reviewed-by: Dylan Baker 


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 10/18] travis: printout llvm-config --version

[Dylan Baker]

Quoting Emil Velikov (2018-12-13 08:05:59)
> From: Emil Velikov 
> 
> Provides quick and easy feedback.
> 
> Signed-off-by: Emil Velikov 
> ---
>  .travis.yml | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/.travis.yml b/.travis.yml
> index 6fefe06617a..c69f322d7b3 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -668,6 +668,8 @@ script:
># 
> https://lists.freedesktop.org/archives/mesa-dev/2017-December/180217.html
>test -f /usr/bin/$LLVM_CONFIG && ln -s /usr/bin/$LLVM_CONFIG 
> $HOME/prefix/bin/llvm-config
>  
> +  $LLVM_CONFIG --version
> +
>export CFLAGS="$CFLAGS -isystem`pwd`"
>meson _build $MESON_OPTIONS
>meson configure _build
> -- 
> 2.19.2
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev

I mean, meson does print the version in the `found` statement, but I guess this
doesn't hurt anything.

Acked-by: Dylan Baker 


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] travis: flip to distro xenial, sudo true

[Dylan Baker]

Quoting Emil Velikov (2018-12-13 08:05:57)
> From: Emil Velikov 
> 
> The latter is the default these days and Travis will be removing sudo
> soonish.
> 
> Flipping to xenial, allows us to remove a bunch of hacks we have. Plus
> it prevents us from adding new ones, to workaround what seems like a
> gcc/binutils bug. For example (from the upcoming meson build):
> 
> FAILED: ccache c++  -o src/gallium/targets/pipe-loader/pipe_r600.so ...
>   ... src/util/libmesa_util.a ... /usr/lib/x86_64-linux-gnu/libz.so ...
> 
> src/util/libmesa_util.a(disk_cache.c.o): In function 
> `deflate_and_write_to_disk':
> _build/../src/util/disk_cache.c:746: undefined reference to `deflateInit_'
> _build/../src/util/disk_cache.c:765: undefined reference to `deflate'
> ...
> 
> As we can see, even though libz.so is explicitly passed after the
> object that requires it - the linker still fails to see the symbols.
> Avoid all those situations - flip the switch.
> 
> Signed-off-by: Emil Velikov 
> ---
>  .travis.yml | 99 +++--
>  1 file changed, 27 insertions(+), 72 deletions(-)
> 
> diff --git a/.travis.yml b/.travis.yml
> index 8eceb4e86f5..deec40cb135 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -1,7 +1,6 @@
>  language: c
>  
> -sudo: false
> -dist: trusty
> +dist: xenial
>  
>  cache:
>apt: true
> @@ -43,12 +42,9 @@ matrix:
>addons:
>  apt:
>sources:
> -- sourceline: 'deb http://apt.llvm.org/trusty/ 
> llvm-toolchain-trusty-7 main'
> +- sourceline: 'deb http://apt.llvm.org/xenial/ 
> llvm-toolchain-xenial-7 main'
>key_url: https://apt.llvm.org/llvm-snapshot.gpg.key
> -# llvm-7 requires libstdc++4.9 which is not in main repo
> -- ubuntu-toolchain-r-test
>packages:
> -# From sources above
>  - llvm-7-dev
>  # Common
>  - xz-utils
> @@ -57,6 +53,7 @@ matrix:
>  - libelf-dev
>  - python3.5
>  - python3-pip
> +- python3-setuptools
>  - env:
>  - LABEL="meson loaders/classic DRI"
>  - BUILD=meson
> @@ -68,12 +65,14 @@ matrix:
>packages:
>  - xz-utils
>  - x11proto-xf86vidmode-dev
> +- libxxf86vm-dev
>  - libexpat1-dev
>  - libx11-xcb-dev
>  - libxdamage-dev
>  - libxfixes-dev
>  - python3.5
>  - python3-pip
> +- python3-setuptools
>  - env:
>  - LABEL="make loaders/classic DRI"
>  - BUILD=make
> @@ -90,11 +89,13 @@ matrix:
>packages:
>  - xz-utils
>  - x11proto-xf86vidmode-dev
> +- libxxf86vm-dev
>  - libexpat1-dev
>  - libx11-xcb-dev
>  - libxdamage-dev
>  - libxfixes-dev
>  - python3-pip
> +- python3-setuptools
>  - env:
>  # NOTE: Building SWR is 2x (yes two) times slower than all the other
>  # gallium drivers combined.
> @@ -113,12 +114,7 @@ matrix:
>  - LIBUNWIND_FLAGS="--enable-libunwind"
>addons:
>  apt:
> -  sources:
> -- llvm-toolchain-trusty-6.0
> -# llvm-6 requires libstdc++4.9 which is not in main repo
> -- ubuntu-toolchain-r-test
>packages:
> -# From sources above
>  - llvm-6.0-dev
>  # Common
>  - xz-utils
> @@ -127,6 +123,7 @@ matrix:
>  - libelf-dev
>  - libunwind8-dev
>  - python3-pip
> +- python3-setuptools
>  - env:
>  - LABEL="make Gallium Drivers RadeonSI"
>  - BUILD=make
> @@ -143,10 +140,8 @@ matrix:
>addons:
>  apt:
>sources:
> -- sourceline: 'deb http://apt.llvm.org/trusty/ 
> llvm-toolchain-trusty-7 main'
> +- sourceline: 'deb http://apt.llvm.org/xenial/ 
> llvm-toolchain-xenial-7 main'
>key_url: https://apt.llvm.org/llvm-snapshot.gpg.key
> -# llvm-7 requires libstdc++4.9 which is not in main repo
> -- ubuntu-toolchain-r-test
>packages:
>  # From sources above
>  - llvm-7-dev
> @@ -157,6 +152,7 @@ matrix:
>  - libelf-dev
>  - libunwind8-dev
>  - python3-pip
> +- python3-setuptools
>  - env:
>  - LABEL="make Gallium Drivers Other"
>  - BUILD=make
> @@ -164,8 +160,6 @@ matrix:
>  - MAKE_CHECK_COMMAND="true"
>  - LLVM_VERSION=3.9
>  - LLVM_CONFIG="llvm-config-${LLVM_VERSION}"
> -# New binutils linker is required for llvm-3.9
> -- OVERRIDE_PATH=/usr/lib/binutils-2.26/bin
>  - DRI_LOADERS="--disable-glx --disable-gbm --disable-egl"
>  - DRI_DRIVERS=""
>  - GALLIUM_ST="--enable-dri --disable-opencl 

Re: [Mesa-dev] [PATCH 09/18] travis: meson: print the configured state

[Dylan Baker]

Quoting Emil Velikov (2018-12-13 08:05:58)
> From: Emil Velikov 
> 
> Signed-off-by: Emil Velikov 
> ---
>  .travis.yml | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/.travis.yml b/.travis.yml
> index deec40cb135..6fefe06617a 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -670,5 +670,6 @@ script:
>  
>export CFLAGS="$CFLAGS -isystem`pwd`"
>meson _build $MESON_OPTIONS
> +  meson configure _build
>ninja -C _build
>  fi
> -- 
> 2.19.2
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reviewed-by: Dylan Baker 


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 07/18] configure: add CXX11_CXXFLAGS to LLVM_CXXFLAGS

[Dylan Baker]

Quoting Emil Velikov (2018-12-13 08:05:56)
> From: Emil Velikov 
> 
> Seemingly with LLVM7 and GCC 5.0, the former won't properly advertise
> -std=c++11 and the latter will choke.
> 
> dd this temporary workaround, otherwise we'll get errors like:
> 
> In file included from /usr/include/c++/5/type_traits:35:0,
>  from /usr/lib/llvm-7/include/llvm/Support/type_traits.h:18,
>  from /usr/lib/llvm-7/include/llvm/ADT/Optional.h:22,
>  from /usr/lib/llvm-7/include/llvm/ADT/STLExtras.h:20,
>  from /usr/lib/llvm-7/include/llvm/ADT/StringRef.h:13,
>  from /usr/lib/llvm-7/include/llvm/Target/TargetMachine.h:17,
>  from ../../../src/amd/common/ac_llvm_helper.cpp:36:
> /usr/include/c++/5/bits/c++0x_warning.h:32:2: error: #error This file 
> requires compiler and library support for the ISO C++ 2011 standard. This 
> support must be enabled with the -std=c++11 or -std=gnu++11 compiler options.
> 
> Signed-off-by: Emil Velikov 
> ---
>  configure.ac | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/configure.ac b/configure.ac
> index 5d3da4b7c48..e5e95f12732 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -2903,6 +2903,7 @@ if test "x$enable_llvm" = xyes; then
>  LLVM_LDFLAGS=`$LLVM_CONFIG --ldflags`
>  LLVM_CFLAGS=$LLVM_CPPFLAGS   # CPPFLAGS seem to be sufficient
>  LLVM_CXXFLAGS=`strip_unwanted_llvm_flags "$LLVM_CONFIG --cxxflags"`
> +LLVM_CXXFLAGS="$CXX11_CXXFLAGS $LLVM_CXXFLAGS"
>  
>  dnl Set LLVM_LIBS - This is done after the driver configuration so
>  dnl that drivers can add additional components to LLVM_COMPONENTS.
> -- 
> 2.19.2
> 

This is why in meson I just assume C++11 all the time...

Reviewed-by: Dylan Baker 


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] glx/test: meson: assorted include fixes

[Dylan Baker]

Quoting Emil Velikov (2018-12-13 08:05:55)
> From: Emil Velikov 
> 
> Swap '..' with the symbolic inc_glx and add glproto as dependency. That
> will pull the correct include, effectively fixing the tests on macOS.
> 
> Fixes: a47c525f328 ("meson: build glx")
> Signed-off-by: Emil Velikov 
> ---
>  src/glx/tests/meson.build | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/src/glx/tests/meson.build b/src/glx/tests/meson.build
> index 2420c90c437..68e1ca59c22 100644
> --- a/src/glx/tests/meson.build
> +++ b/src/glx/tests/meson.build
> @@ -46,9 +46,9 @@ if with_shared_glapi
>link_with : [libglx, libglapi],
>include_directories : [
>  inc_src, inc_include, inc_mesa, inc_mapi, inc_gl_internal,
> -include_directories('..'),
> +inc_glx,
>],
> -  dependencies : [dep_libdrm, dep_thread, idep_gtest]
> +  dependencies : [dep_libdrm, dep_glproto, dep_thread, idep_gtest]
>  ),
>  suite : ['glx'],
>)
> -- 
> 2.19.2
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reviewed-by: Dylan Baker 


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 05/18] glx: meson: wire up the dispatch-index-check test

[Dylan Baker]

Quoting Emil Velikov (2018-12-13 08:05:54)
> From: Emil Velikov 
> 
> Accidentally dropped with earlier commit.!
> 
> Fixes: 4ccb9816737 ("meson: Use consistent style for tests")
> Signed-off-by: Emil Velikov 
> ---
>  src/glx/tests/meson.build | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/src/glx/tests/meson.build b/src/glx/tests/meson.build
> index fa3ca9db8cd..2420c90c437 100644
> --- a/src/glx/tests/meson.build
> +++ b/src/glx/tests/meson.build
> @@ -33,6 +33,11 @@ if with_shared_glapi
>  files_glx_test += files('query_renderer_implementation_unittest.cpp')
>endif
>  
> +  test(
> +'dispatch-index-check',
> +files('dispatch-index-check'),
> +suite : ['glx'],
> +  )
>test(
>  'glx-test',
>  executable(
> -- 
> 2.19.2

I would have thought you needed find_program, but this seems to work.

Reviewed-by: Dylan Baker 


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

Re: [Mesa-dev] Let's talk about -DDEBUG

[Dylan Baker]

Quoting Tapani Pälli (2018-12-14 05:03:06)
> 
> 
> On 12/14/18 12:53 PM, Erik Faye-Lund wrote:
> > On Thu, 2018-12-13 at 10:46 -0800, Eric Anholt wrote:
> >> Dylan Baker  writes:
> >>
> >>> [ Unknown signature status ]
> >>> In the autotools discussion I've come to realize that we also need
> >>> to talk about
> >>> the -DDEBUG guard. It seems that there are two different uses, and
> >>> thus two
> >>> different asks about it:
> >>>
> >>> - Nine (and RadeonSI?) use -DDEBUG to hide generic debugging
> >>> - NIR and Intel (at least) use -DDEBUG to hide really expensive
> >>> checks that are
> >>>useful, but necessarily tank performance.
> >>>
> >>> The first group would like -DDEBUG in debugoptimized builds, the
> >>> second
> >>> obviously doesn't.
> >>>
> >>> Is the right solution to move the first group being !NDEBUG, or
> >>> would it be
> >>> better to split DEBUG into two different defines such as
> >>> DEBUG_MESSAGES and
> >>> EXPENSIVE_VALIDATION (paint the bikeshed whatever color you like),
> >>> with the
> >>> first for both debug and debugoptimized and the second only in
> >>> debug builds?
> >>
> >> I would like to see NIR validation in debugoptimized builds (which is
> >> the build I use on a regular basis: "please catch all bugs you can at
> >> runtime with asserts, but don't waste CPU time by compiling with
> >> -O0");
> >>
> > 
> > I'm starting to think that we should add explicit options (with
> > reasonable defaults based on ) for things like nir validation. That way
> > it'd be easy for anyone to pimp their buildtype. Meddling directly with
> > CFLAGS feels kinda hacky for something as useful like this.
> > 
> > Something like this?
> 
> Looks nice and is easy to understand. IMO something like 
> 'ENABLE_ASSERTS' would be also much more easier/straightforward than 
> using "-Db_ndebug=false", here I'm thinking about the bug reporters.

I really wish meson wouldn't have called this -Db_ndebug and would have had
something like -Db_asserts, but historical artifacts live on...

Dylan


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

Re: [Mesa-dev] last call for autotools

[Dylan Baker]

Quoting Andre Heider (2018-12-14 09:24:56)
> On 14/12/2018 17:53, Dylan Baker wrote:
> > Quoting Gert Wollny (2018-12-14 03:44:32)
> >> Am Montag, den 10.12.2018, 15:10 -0800 schrieb Dylan Baker:
> >> (2) It would be nice if Meson would distribute some default cross build
> >> files, currently everybody has to roll its own, and I guess in the end
> >> they all look mostly the same.
> > 
> > Please ask your distro to write and distribute the cross files. It's simply
> > impossible for meson to distribute them for a huge number of reasons, but
> > basically it boils down to too many distros with too many differences. I 
> > have
> > done basically everything I can (personally) to make this easier, including
> > adding support for loading cross files from XDG paths 
> > (/usr/share/meson/cross,
> > etc)
> > 
> >>
> >> (3) I also noted that with across build one has to set the library
> >> install directory manually, because it defaults to the directory used
> >> for the build machine - i.e. a i386 cross build on debian amd64 should
> >> set the lib install directory on Debian to "lib/i386-linux-gnu" but it
> >> sets it to "lib/x86_64-linux-gnu"
> > 
> > There is this issue: https://github.com/mesonbuild/meson/issues/4008
> > 
> > This is another case that is really hard to handle because of the way 
> > different
> > distros have handled installing x86 and x86_64 binaries on the same OS. To 
> > name
> > a few:
> > debian : lib/$gnu-tri/
> > arch   : lib/ + lib32/
> > fedora : lib64/ + lib32/
> > 
> > I'm sure there are more, but getting that right all of the time is actually
> > pretty hard. I'll look into it.
> 
> It's not just the libdir, there's no real way for a project to provide 
> all the required cross settings so it works everywhere. Like the 
> pkg-config binary name for e.g. cross-compiling 32bit binaries. I didn't 
> find anything user friendly, so I worked around that on another project 
> [0]. And I'm sure there's more.
> 
> While all that is doable, it is annoying. Isn't there any way for meson 
> to provide a standard set of cross files for distros? If it's the 
> distro's responsibility to provide these without any guidelines it's 
> just going to be another mess, because either a distro doesn't at all or 
> they all do it differently.
> 
> [0] https://github.com/dhewg/nine/blob/master/bootstrap.sh
> 
> Thanks,
> Andre

We can provide some skeleton templates I guess, but most of what a cross file is
is just a list of binary locations and a name to pass to the --cross-file
option. This is just another pain point of there being mⁿ distros making subtly
different choices. We probably can ship cross files for MSVC or Apple's Clang
since we can make some pretty safe assumptions about how those are installed.

I can write some guidelines for distro cross files and add that to meson's
documentation if that's helpful.

Dylan


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

Re: [Mesa-dev] last call for autotools

[Andre Heider]

On 14/12/2018 17:53, Dylan Baker wrote:

Quoting Gert Wollny (2018-12-14 03:44:32)

Am Montag, den 10.12.2018, 15:10 -0800 schrieb Dylan Baker:
(2) It would be nice if Meson would distribute some default cross build
files, currently everybody has to roll its own, and I guess in the end
they all look mostly the same.


Please ask your distro to write and distribute the cross files. It's simply
impossible for meson to distribute them for a huge number of reasons, but
basically it boils down to too many distros with too many differences. I have
done basically everything I can (personally) to make this easier, including
adding support for loading cross files from XDG paths (/usr/share/meson/cross,
etc)



(3) I also noted that with across build one has to set the library
install directory manually, because it defaults to the directory used
for the build machine - i.e. a i386 cross build on debian amd64 should
set the lib install directory on Debian to "lib/i386-linux-gnu" but it
sets it to "lib/x86_64-linux-gnu"


There is this issue: https://github.com/mesonbuild/meson/issues/4008

This is another case that is really hard to handle because of the way different
distros have handled installing x86 and x86_64 binaries on the same OS. To name
a few:
debian : lib/$gnu-tri/
arch   : lib/ + lib32/
fedora : lib64/ + lib32/

I'm sure there are more, but getting that right all of the time is actually
pretty hard. I'll look into it.


It's not just the libdir, there's no real way for a project to provide 
all the required cross settings so it works everywhere. Like the 
pkg-config binary name for e.g. cross-compiling 32bit binaries. I didn't 
find anything user friendly, so I worked around that on another project 
[0]. And I'm sure there's more.


While all that is doable, it is annoying. Isn't there any way for meson 
to provide a standard set of cross files for distros? If it's the 
distro's responsibility to provide these without any guidelines it's 
just going to be another mess, because either a distro doesn't at all or 
they all do it differently.


[0] https://github.com/dhewg/nine/blob/master/bootstrap.sh

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

[Mesa-dev] [PATCH] st/nir: Use nir_src_as_uint for tokens

[Jason Ekstrand]

---
 src/mesa/state_tracker/st_nir_lower_builtin.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/src/mesa/state_tracker/st_nir_lower_builtin.c 
b/src/mesa/state_tracker/st_nir_lower_builtin.c
index 195dc40b2ef..ab74d3183dc 100644
--- a/src/mesa/state_tracker/st_nir_lower_builtin.c
+++ b/src/mesa/state_tracker/st_nir_lower_builtin.c
@@ -107,10 +107,6 @@ get_variable(lower_builtin_state *state, nir_deref_path 
*path,
memcpy(tokens, element->tokens, sizeof(tokens));
 
if (path->path[idx]->deref_type == nir_deref_type_array) {
-  nir_const_value *c = nir_src_as_const_value(path->path[idx]->arr.index);
-
-  assert(c);
-
   /* we need to fixup the array index slot: */
   switch (tokens[0]) {
   case STATE_MODELVIEW_MATRIX:
@@ -123,7 +119,7 @@ get_variable(lower_builtin_state *state, nir_deref_path 
*path,
   case STATE_TEXGEN:
   case STATE_TEXENV_COLOR:
   case STATE_CLIPPLANE:
- tokens[1] = c->u32[0];
+ tokens[1] = nir_src_as_uint(path->path[idx]->arr.index);
  break;
   }
}
-- 
2.19.2

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

Re: [Mesa-dev] [PATCH 04/18] glx: meson: drop includes from a link-only library

[Dylan Baker]

Quoting Emil Velikov (2018-12-13 08:05:53)
> From: Emil Velikov 
> 
> When producing the final libGL.so/libGLX_mesa.so we only link the local
> static helper lib (libglx). Thus there's no reason for the includes.
> 
> Fixes: a47c525f328 ("meson: build glx")
> Signed-off-by: Emil Velikov 
> ---
>  src/glx/meson.build | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/src/glx/meson.build b/src/glx/meson.build
> index 898ed1f5826..4eb2e0a21d2 100644
> --- a/src/glx/meson.build
> +++ b/src/glx/meson.build
> @@ -155,7 +155,6 @@ libglx = static_library(
>  libgl = shared_library(
>gl_lib_name,
>[],
> -  include_directories : [inc_common, inc_glapi, inc_loader, inc_gl_internal],
>link_with : [libglapi_static, libglapi],
>link_whole : libglx,
>link_args : [ld_args_bsymbolic, ld_args_gc_sections, extra_ld_args_libgl],
> -- 
> 2.19.2
> 

ah yes, this is an artifact from other refactors, good catch:
Reviewed-by: Dylan Baker 


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 03/18] glx: meson: build src/glx only with -Dglx=dri

[Dylan Baker]

Quoting Emil Velikov (2018-12-13 08:05:52)
> From: Emil Velikov 
> 
> The library is the dri capable one, push the check src/meson.build,
> instead of the current partial handling in src/glx/meson.build.
> 
> Fixes: a47c525f328 ("meson: build glx")

This is just a refactor, the Fixes: is unnecessary. More on that below

> Signed-off-by: Emil Velikov 
> ---
>  src/glx/meson.build | 32 +++-
>  src/meson.build |  2 +-
>  2 files changed, 16 insertions(+), 18 deletions(-)
> 
> diff --git a/src/glx/meson.build b/src/glx/meson.build
> index 3fd74439b11..898ed1f5826 100644
> --- a/src/glx/meson.build
> +++ b/src/glx/meson.build
> @@ -152,23 +152,21 @@ libglx = static_library(
>build_by_default : false,
>  )
>  
> -if with_glx == 'dri'
> -  libgl = shared_library(
> -gl_lib_name,
> -[],
> -include_directories : [inc_common, inc_glapi, inc_loader, 
> inc_gl_internal],
> -link_with : [libglapi_static, libglapi],
> -link_whole : libglx,
> -link_args : [ld_args_bsymbolic, ld_args_gc_sections, 
> extra_ld_args_libgl],
> -dependencies : [
> -  dep_libdrm, dep_dl, dep_m, dep_thread, dep_x11, dep_xcb_glx, dep_xcb,
> -  dep_x11_xcb, dep_xcb_dri2, dep_xext, dep_xfixes, dep_xdamage, 
> dep_xxf86vm,
> -  extra_deps_libgl,
> -],
> -version : gl_lib_version,
> -install : true,
> -  )
> -endif
> +libgl = shared_library(
> +  gl_lib_name,
> +  [],
> +  include_directories : [inc_common, inc_glapi, inc_loader, inc_gl_internal],
> +  link_with : [libglapi_static, libglapi],
> +  link_whole : libglx,
> +  link_args : [ld_args_bsymbolic, ld_args_gc_sections, extra_ld_args_libgl],
> +  dependencies : [
> +dep_libdrm, dep_dl, dep_m, dep_thread, dep_x11, dep_xcb_glx, dep_xcb,
> +dep_x11_xcb, dep_xcb_dri2, dep_xext, dep_xfixes, dep_xdamage, 
> dep_xxf86vm,
> +extra_deps_libgl,
> +  ],
> +  version : gl_lib_version,
> +  install : true,
> +)

All you're doing is refactoring out the build_by_default into an if statement.
If you're going to do this, please remove `build_by_default : false` from the
libglx in src/glx.

With those changes:
Reviewed-by: Dylan Baker 

>  
>  if with_tests
>subdir('tests')
> diff --git a/src/meson.build b/src/meson.build
> index 915441fb2ce..ae094fccf6c 100644
> --- a/src/meson.build
> +++ b/src/meson.build
> @@ -74,7 +74,7 @@ subdir('loader')
>  if with_platform_haiku
>subdir('hgl')
>  endif
> -if with_glx != 'disabled'
> +if with_glx == 'dri'
>subdir('glx')
>  endif
>  if with_gbm
> -- 
> 2.19.2
> 
> ___
> 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 02/18] pipe-loader: meson: reference correct library

[Dylan Baker]

Quoting Emil Velikov (2018-12-13 08:05:51)
> From: Emil Velikov 
> 
> The library is called libgalliumvl_stub - note singular.
> 
> Fixes: 42ea0631f10 ("meson: build clover")
> Signed-off-by: Emil Velikov 
> ---
>  src/gallium/targets/pipe-loader/meson.build | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/gallium/targets/pipe-loader/meson.build 
> b/src/gallium/targets/pipe-loader/meson.build
> index 5a44102a69d..e9454d5666a 100644
> --- a/src/gallium/targets/pipe-loader/meson.build
> +++ b/src/gallium/targets/pipe-loader/meson.build
> @@ -31,7 +31,7 @@ if (with_gallium_va or with_gallium_vdpau or 
> with_gallium_omx != 'disabled' or
>  with_gallium_xvmc or with_dri)
>pipe_loader_link_with += libgalliumvl
>  else
> -  pipe_loader_link_with += libgalliumvl_stubs
> +  pipe_loader_link_with += libgalliumvl_stub
>  endif
>  if (with_gallium_va or with_gallium_vdpau or with_gallium_omx != 'disabled' 
> or
>  with_gallium_xvmc)
> -- 
> 2.19.2
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reviewed-by: Dylan Baker 


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/2] pci_ids: add new vega10 pci ids

[Alex Deucher]

Ping?

Alex
On Fri, Dec 7, 2018 at 4:11 PM Alex Deucher  wrote:
>
> Signed-off-by: Alex Deucher 
> Cc: mesa-sta...@lists.freedesktop.org
> ---
>  include/pci_ids/radeonsi_pci_ids.h | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/include/pci_ids/radeonsi_pci_ids.h 
> b/include/pci_ids/radeonsi_pci_ids.h
> index 35ea3559b02..f7defc4197a 100644
> --- a/include/pci_ids/radeonsi_pci_ids.h
> +++ b/include/pci_ids/radeonsi_pci_ids.h
> @@ -227,8 +227,14 @@ CHIPSET(0x6863, VEGA10)
>  CHIPSET(0x6864, VEGA10)
>  CHIPSET(0x6867, VEGA10)
>  CHIPSET(0x6868, VEGA10)
> -CHIPSET(0x687F, VEGA10)
> +CHIPSET(0x6869, VEGA10)
> +CHIPSET(0x686A, VEGA10)
> +CHIPSET(0x686B, VEGA10)
>  CHIPSET(0x686C, VEGA10)
> +CHIPSET(0x686D, VEGA10)
> +CHIPSET(0x686E, VEGA10)
> +CHIPSET(0x686F, VEGA10)
> +CHIPSET(0x687F, VEGA10)
>
>  CHIPSET(0x69A0, VEGA12)
>  CHIPSET(0x69A1, VEGA12)
> --
> 2.13.6
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v6 0/8] Add and enable extension EXT_sRGB_write_control

[Gert Wollny]

Hi all, 

Since I like MRs I've pushed the new version to 
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/14

There is actually only one one-line change with respect to the series
as posted here, so using the MR also saves everyones band-width. 

So far it was tested on r600 with the GLES deqp 2,4,and 31 master
suites where no regressions were seen.

From the tests 

  dEQP-GLES31.functional.fbo.srgb_write_control.
  framebuffer_srgb_unsupported_enum 

switched to unsupported (as expected) and 

   dEQP-GLES31.functional.fbo.srgb_write_control.
framebuffer_srgb_enabled* 

pass (with MESA_GLES_VERSION_OVERRIDE=3.2). 

Best, 
Gert

Am Donnerstag, den 15.11.2018, 13:45 +0100 schrieb Gert Wollny:
> From: Gert Wollny 
> 
> Dear all, 
> 
> after the RFC and Ilias comments I reworked the series another
> time.  
> Changes with respect to the RFC are 
>   - renaming the new CAP 
>   - reordering of the patches that no double checking of 
> EXT_sRGB and EXT_framebuffer_sRGB is needed. 
> 
> thanks for reviewing, 
> Gert
> 
> Gert Wollny (8):
>   Gallium: Add new CAPS to indicate whether a driver can switch SRGB
> write
>   virgl: Set sRGB write control CAP based on host capabilities
>   mesa:main: Add flag for EXT_sRGB to gl_extensions
>   i965: Set flag for EXT_sRGB
>   mesa/st: rework support for sRGB framebuffer attachements
>   mesa/main: Use flag for EXT_sRGB instead of EXT_framebuffer_sRGB
> where
> possible
>   mesa/main/version: Lower the requirements for GLES 3.0
>   mesa/main: Expose EXT_sRGB_write_control
> 
>  src/gallium/auxiliary/util/u_screen.c|  3 ++
>  src/gallium/docs/source/screen.rst   |  3 ++
>  src/gallium/drivers/virgl/virgl_context.c| 10 ++
>  src/gallium/drivers/virgl/virgl_hw.h |  1 +
>  src/gallium/drivers/virgl/virgl_screen.c |  2 ++
>  src/gallium/include/pipe/p_defines.h |  1 +
>  src/mesa/drivers/dri/i965/intel_extensions.c |  1 +
>  src/mesa/main/enable.c   |  4 ---
>  src/mesa/main/extensions_table.h |  1 +
>  src/mesa/main/fbobject.c |  2 +-
>  src/mesa/main/formatquery.c  |  2 +-
>  src/mesa/main/framebuffer.c  |  2 +-
>  src/mesa/main/get_hash_params.py |  4 ++-
>  src/mesa/main/mtypes.h   |  1 +
>  src/mesa/main/teximage.c |  2 +-
>  src/mesa/main/version.c  |  4 +--
>  src/mesa/state_tracker/st_cb_fbo.c   |  4 +--
>  src/mesa/state_tracker/st_extensions.c   |  6 +++-
>  src/mesa/state_tracker/st_format.c   |  2 +-
>  src/mesa/state_tracker/st_manager.c  | 37 
> 
>  20 files changed, 63 insertions(+), 29 deletions(-)
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] last call for autotools

[Dylan Baker]

Quoting Gert Wollny (2018-12-14 03:44:32)
> Am Montag, den 10.12.2018, 15:10 -0800 schrieb Dylan Baker:
> > Meson 0.49.0 has been out for a couple of days now, and I'd like to
> > make the final call for autotools. My patch is so massive that it's a
> > huge pain to send to the list, the latest versions is here:
> > https://gitlab.freedesktop.org/dbaker/mesa/commits/delete-autotools
> 
> Well, 
> 
> (1) there is stil this Heisenbug that pops up there and then, and that
> I send a patch for some time ago [1]: 
> 
> [1088/1140] Linking target src/gallium/tests/trivial/quad-tex.
> FAILED: src/gallium/tests/trivial/quad-tex 
> g++  -o src/gallium/tests/trivial/quad-tex 'src/gallium/tests/trivial/s
> rc@gallium@tests@trivial@@quad-tex@exe/quad-tex.c.o' -Wl,--no-undefined 
> -Wl,--as-needed -Wl,--start-group src/util/libmesa_util.a
> src/gallium/auxiliary/libgallium.a src/gallium/auxiliary/pipe-
> loader/libpipe_loader_dynamic.a src/loader/libloader.a
> src/util/libxmlconfig.a /usr/lib64/libz.so -lm -Wl,--end-group
> /usr/lib64/libdrm.so -L/usr/lib64/llvm/6/lib64 -lLLVMAMDGPUDisassembler
> -lLLVMAMDGPUCodeGen -lLLVMAMDGPUAsmParser -lLLVMAMDGPUDesc
> -lLLVMAMDGPUInfo -lLLVMAMDGPUAsmPrinter -lLLVMAMDGPUUtils -lLLVMMCJIT
> -lLLVMExecutionEngine -lLLVMRuntimeDyld -lLLVMX86Disassembler
> -lLLVMX86AsmParser -lLLVMX86CodeGen -lLLVMGlobalISel -lLLVMSelectionDAG
> -lLLVMAsmPrinter -lLLVMDebugInfoCodeView -lLLVMDebugInfoMSF
> -lLLVMCodeGen -lLLVMTarget -lLLVMX86Desc -lLLVMMCDisassembler
> -lLLVMX86Info -lLLVMX86AsmPrinter -lLLVMX86Utils -lLLVMipo
> -lLLVMInstrumentation -lLLVMVectorize -lLLVMScalarOpts -lLLVMLinker
> -lLLVMIRReader -lLLVMAsmParser -lLLVMInstCombine -lLLVMTransformUtils
> -lLLVMBitWriter -lLLVMAnalysis -lLLVMProfileData -lLLVMObject
> -lLLVMMCParser -lLLVMMC -lLLVMBitReader -lLLVMCore -lLLVMBinaryFormat
> -lLLVMSupport -lLLVMDemangle /usr/lib64/libunwind.so -ldl -lm
> /usr/lib64/libsensors.so /usr/lib64/libexpat.so -lm  
> src/util/libmesa_util.a(u_cpu_detect.c.o): In function `call_once':
> /home/gerddie/src/Collabora/Qemu2/build/mesa-
> debug/../../samba/mesa/src/../include/c11/threads_posix.h:96: undefined
> reference to `pthread_once'
> collect2: error: ld returned 1 exit status
> 
> The bug popped up just now when I rebased a tree that was building fine
> before. I think it was related to rebasing a rather old branch that
> still had some files in gallium/util that are now in util, so some
> library is probably not rebuild correctly, but "ninja clean" doesn't
> help to get things right. Setting  up a build from scratch usually
> doesn't show the problem though.
> 
> (2) It would be nice if Meson would distribute some default cross build
> files, currently everybody has to roll its own, and I guess in the end
> they all look mostly the same.

Please ask your distro to write and distribute the cross files. It's simply
impossible for meson to distribute them for a huge number of reasons, but
basically it boils down to too many distros with too many differences. I have
done basically everything I can (personally) to make this easier, including
adding support for loading cross files from XDG paths (/usr/share/meson/cross,
etc)

> 
> (3) I also noted that with across build one has to set the library
> install directory manually, because it defaults to the directory used
> for the build machine - i.e. a i386 cross build on debian amd64 should
> set the lib install directory on Debian to "lib/i386-linux-gnu" but it
> sets it to "lib/x86_64-linux-gnu" 

There is this issue: https://github.com/mesonbuild/meson/issues/4008

This is another case that is really hard to handle because of the way different
distros have handled installing x86 and x86_64 binaries on the same OS. To name
a few:
debian : lib/$gnu-tri/
arch   : lib/ + lib32/
fedora : lib64/ + lib32/

I'm sure there are more, but getting that right all of the time is actually
pretty hard. I'll look into it.

Dylan

> 
> Best, 
> Gert
> 
> [1] https://patchwork.freedesktop.org/series/52749/
> 
> > 
> > Dylan
> > ___
> > 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

[Mesa-dev] [Bug 109062] meson incorrectly handles/reports libdrm_$foo

[bugzilla-daemon]

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

--- Comment #1 from Dylan Baker  ---
In meson we iterate through all of the libdrm versions required for each
enabled target, then select the hightest version and check only for that
version of libdrm and libdrm_*. We do this specifically to avoid picking up two
different versions of libdrm. A little above this in the meson output there is
a line similar to:

message: libdrm 2.4.95 needed because amdgpu has the highest requirement

I implemented this because Ilia had pointed out cases where pkg-config could
load the libdrm from his system directory, but the libdrm_nouveau from a custom
install directory because the version differences. Eric and I spent a lot of
time trying to figure out the best way to handle this, and the message right
before the version check was the best we could come up with. Ideas to make this
clearer are welcome.

-- 
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] last call for autotools

[Alex Deucher]

On Fri, Dec 14, 2018 at 11:32 AM Matt Turner  wrote:
>
> On Fri, Dec 14, 2018 at 4:12 AM Gert Wollny  wrote:
> > I second that, I voiced my concerns in a former thread, especially that
> > so far this upcoming change has not been officially announced in the
> > release notes or on mesa-user, and that I don't understand why it is so
> > urgent to drop autotools when there is still someone who offers to
> > maintain it and some who prefer to use it.
>
> It's because the objective is to have as few build systems as
> necessary. This is an obvious first step and has been a stated goal
> for more than a year. I'm surprised that you're surprised.

A laudable goal, but if it's not ready, it's not ready.

>
> Let's just make an external contrib repo and keep all the autotools
> files there. Then Emil and company can continue having fun maintaining
> autotools and all you'll need to do is rsync into the Mesa repo to use
> autotools.

Seems like a bigger turn off for casual developers that are having
trouble with meson.  At this point it seems like we have a few
enthusiastic supporters, and a bunch of people begrudgingly going
along with it despite having limitations to their work flow.  Every
conversion seems to go this way.  It's not like these are new
sentiments.

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

Re: [Mesa-dev] last call for autotools

[Ilia Mirkin]

On Fri, Dec 14, 2018 at 11:32 AM Matt Turner  wrote:
>
> On Fri, Dec 14, 2018 at 4:12 AM Gert Wollny  wrote:
> > I second that, I voiced my concerns in a former thread, especially that
> > so far this upcoming change has not been officially announced in the
> > release notes or on mesa-user, and that I don't understand why it is so
> > urgent to drop autotools when there is still someone who offers to
> > maintain it and some who prefer to use it.
>
> It's because the objective is to have as few build systems as
> necessary. This is an obvious first step and has been a stated goal
> for more than a year. I'm surprised that you're surprised.
>
> Let's just make an external contrib repo and keep all the autotools
> files there. Then Emil and company can continue having fun maintaining
> autotools and all you'll need to do is rsync into the Mesa repo to use
> autotools.

So ... not last call for autotools? More like "railroad notification
that the train is in motion"?

This kind of talk just causes everyone to entrench into their
positions, so I'd rather avoid it. I'm not opposed to switching build
systems in principle, but the current proposal is, in my and seemingly
some other people's views, inadequate. Let's make it adequate before
dropping the thing that works for everyone.

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

Re: [Mesa-dev] last call for autotools

[Matt Turner]

On Fri, Dec 14, 2018 at 4:12 AM Gert Wollny  wrote:
> I second that, I voiced my concerns in a former thread, especially that
> so far this upcoming change has not been officially announced in the
> release notes or on mesa-user, and that I don't understand why it is so
> urgent to drop autotools when there is still someone who offers to
> maintain it and some who prefer to use it.

It's because the objective is to have as few build systems as
necessary. This is an obvious first step and has been a stated goal
for more than a year. I'm surprised that you're surprised.

Let's just make an external contrib repo and keep all the autotools
files there. Then Emil and company can continue having fun maintaining
autotools and all you'll need to do is rsync into the Mesa repo to use
autotools.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] clover: Fix include of CodeGenOptions.h, upstream moved it in r348827

[Kai Wasserbäch]

Signed-off-by: Kai Wasserbäch 
---
 src/gallium/state_trackers/clover/llvm/compat.hpp | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/gallium/state_trackers/clover/llvm/compat.hpp 
b/src/gallium/state_trackers/clover/llvm/compat.hpp
index 975012cbda..9c5b9d8917 100644
--- a/src/gallium/state_trackers/clover/llvm/compat.hpp
+++ b/src/gallium/state_trackers/clover/llvm/compat.hpp
@@ -58,7 +58,11 @@
 #include 
 
 #include 
+#if HAVE_LLVM >= 0x0800
+#include 
+#else
 #include 
+#endif
 #include 
 
 namespace clover {
-- 
2.19.2

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

[Mesa-dev] [Bug 109062] meson incorrectly handles/reports libdrm_$foo

[bugzilla-daemon]

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

Emil Velikov  changed:

   What|Removed |Added

 CC||baker.dyla...@gmail.com,
   ||fdo-b...@engestrom.ch

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

[Mesa-dev] [Bug 109062] meson incorrectly handles/reports libdrm_$foo

[bugzilla-daemon]

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

Bug ID: 109062
   Summary: meson incorrectly handles/reports libdrm_$foo
   Product: Mesa
   Version: git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Other
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: emil.l.veli...@gmail.com
QA Contact: mesa-dev@lists.freedesktop.org

Running meson build/ with libdrm 2.4.93 results in the following:

 Dependency libdrm_intel found: NO found '2.4.93' but need: '>=2.4.95
 Dependency libdrm_intel found: NO

 meson.build:1143:4: ERROR:  Invalid version of dependency, need 'libdrm_intel'
['>=2.4.95'] found '2.4.93'.


While $ git grep -5 drm_amdgpu meson.build shows:


 meson.build:_drm_amdgpu_ver = '2.4.95'
 meson.build-_drm_radeon_ver = '2.4.71'
 meson.build-_drm_nouveau_ver = '2.4.66'
 meson.build-_drm_etnaviv_ver = '2.4.89'
 meson.build-_drm_intel_ver = '2.4.75'

-- 
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 109039] [CLOVER][CLANG-SVN] build failure CodeGenOptions.h: No such file or directory

[bugzilla-daemon]

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

network...@rkmail.ru changed:

   What|Removed |Added

 CC||network...@rkmail.ru

-- 
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] glx: Fix compilation with GLX_USE_WINDOWSGL

[Emil Velikov]

On Fri, 14 Dec 2018 at 14:56, Jon Turney  wrote:
>
> Sadly, the GLX_USE_APPLEGL and GLX_USE_WINDOWSGL cases are not identical
> (because GLX_USE_WINDOWSGL uses vtables rather than a maze of ifdefs)
>
> Include  again, as functions prototyped by it are used in
> the GLX_USE_WINDOWSGL path.
>
> Make the include guard around the __glxGetMscRate() definition match the
> one at it's declaration again, as it's referenced from dri_common.c
> which is built for GLX_USE_WINDOWSGL.
>
> Cc: Emil Velikov 
> Fixes: a95ec138 ("glx: mandate xf86vidmode only for "drm" dri platforms")
> Signed-off-by: Jon Turney 
Reviewed-by: Emil Velikov 

Jon, when you have some time, can you please write a Travis config for Cygwin.
This way we can do some basic checks a bit easier.

If/when we move to gitlab CI we can simply copy it over ;-)

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

[Mesa-dev] [PATCH] glx: Fix compilation with GLX_USE_WINDOWSGL

[Jon Turney]

Sadly, the GLX_USE_APPLEGL and GLX_USE_WINDOWSGL cases are not identical
(because GLX_USE_WINDOWSGL uses vtables rather than a maze of ifdefs)

Include  again, as functions prototyped by it are used in
the GLX_USE_WINDOWSGL path.

Make the include guard around the __glxGetMscRate() definition match the
one at it's declaration again, as it's referenced from dri_common.c
which is built for GLX_USE_WINDOWSGL.

Cc: Emil Velikov 
Fixes: a95ec138 ("glx: mandate xf86vidmode only for "drm" dri platforms")
Signed-off-by: Jon Turney 
---
 src/glx/glxcmds.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/glx/glxcmds.c b/src/glx/glxcmds.c
index d00c0d4816d..bde461b43a3 100644
--- a/src/glx/glxcmds.c
+++ b/src/glx/glxcmds.c
@@ -45,8 +45,8 @@
 #include "apple/apple_glx.h"
 #include "util/debug.h"
 #else
-#ifndef GLX_USE_WINDOWSGL
 #include 
+#ifndef GLX_USE_WINDOWSGL
 #include 
 #endif /* GLX_USE_WINDOWSGL */
 #endif
@@ -2083,11 +2083,12 @@ __glXGetSyncValuesOML(Display * dpy, GLXDrawable 
drawable,
return False;
 }
 
-#if defined(GLX_DIRECT_RENDERING) && !defined(GLX_USE_APPLEGL) && 
!defined(GLX_USE_WINDOWSGL)
+#if defined(GLX_DIRECT_RENDERING) && !defined(GLX_USE_APPLEGL)
 _X_HIDDEN GLboolean
 __glxGetMscRate(struct glx_screen *psc,
int32_t * numerator, int32_t * denominator)
 {
+#if !defined(GLX_USE_WINDOWSGL)
XF86VidModeModeLine mode_line;
int dot_clock;
int i;
@@ -2134,6 +2135,7 @@ __glxGetMscRate(struct glx_screen *psc,
 
   return True;
}
+#endif
 
return False;
 }
-- 
2.17.0

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

Re: [Mesa-dev] [PATCH v2 17/24] meson: wire the new generator for es1 and es2

[Erik Faye-Lund]

For 16 and 17:

Reviewed-by: Erik Faye-Lund 

On Fri, 2018-12-14 at 14:04 +, Emil Velikov wrote:
> From: Emil Velikov 
> 
> v2: use ${foo})_py naming (Dylan)
> 
> Cc: Dylan Baker 
> Cc: Eric Engestrom 
> Signed-off-by: Emil Velikov 
> ---
>  src/mapi/es1api/meson.build| 6 +++---
>  src/mapi/es2api/meson.build| 6 +++---
>  src/mapi/glapi/gen/meson.build | 7 +++
>  3 files changed, 13 insertions(+), 6 deletions(-)
> 
> diff --git a/src/mapi/es1api/meson.build
> b/src/mapi/es1api/meson.build
> index 53e894f091c..b0416e705a1 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_py, 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..a7f0904b699 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_py, 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 8cc163b2989..113e88aa99a 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(

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

Re: [Mesa-dev] [PATCH v2 14/24] mapi/new: fixup the GLDEBUGPROCKHR typedef to the non KHR one

[Erik Faye-Lund]

Reviewed-by: Erik Faye-Lund 

On Fri, 2018-12-14 at 14:04 +, Emil Velikov wrote:
> 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 bfcf6ed3eea..f4eb1728e95 100644
> --- a/src/mapi/new/genCommon.py
> +++ b/src/mapi/new/genCommon.py
> @@ -227,6 +227,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 cc0e286e221..65e42bd2a0d 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"))
>  

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

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

[Erik Faye-Lund]

Reviewed-by: Erik Faye-Lund 

On Fri, 2018-12-14 at 14:04 +, Emil Velikov wrote:
> There is no need for the noop functions, the public_stubs and
> public_entries table or table size defines. Remove those.
> 
> Pretty much all of this is applicable to GLVND, although it
> requires preparatory work.
> 
> v2:
>  - python style fixes (Dylan)
>  - use "gldispatch" instead of not "glesv1" "glesv2"
>  - remove the public_entries table/array (Erik)
> 
> Signed-off-by: Emil Velikov 
> ---
>  src/mapi/new/gen_gldispatch_mapi.py | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/src/mapi/new/gen_gldispatch_mapi.py
> b/src/mapi/new/gen_gldispatch_mapi.py
> index 959d8798f5c..cc0e286e221 100755
> --- a/src/mapi/new/gen_gldispatch_mapi.py
> +++ b/src/mapi/new/gen_gldispatch_mapi.py
> @@ -63,11 +63,13 @@ 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 in "gldispatch":
> +print(generate_table(functions, allFunctions))
> +print(generate_noop_array(functions))
> +print(generate_public_stubs(functions))
>  print(generate_public_entries(functions))
> -print(generate_public_entries_table(functions))
> +if target in "gldispatch":
> +print(generate_public_entries_table(functions))
>  print(generate_undef_public_entries())
>  print(generate_stub_asm_gcc(functions))
>  

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

Re: [Mesa-dev] [PATCH v2 11/24] mapi/new: reinstate _NO_HIDDEN suffixes in the new generator

[Erik Faye-Lund]

Reviewed-by: Erik Faye-Lund 

On Fri, 2018-12-14 at 14:04 +, Emil Velikov wrote:
> From: Emil Velikov 
> 
> Strictly speaking we can rework the rest of the code so we do not
> need
> those. That said, this will require a series on it's own so let's
> carry
> this local quirk for now.
> 
> Signed-off-by: Emil Velikov 
> ---
>  src/mapi/new/gen_gldispatch_mapi.py | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/src/mapi/new/gen_gldispatch_mapi.py
> b/src/mapi/new/gen_gldispatch_mapi.py
> index 03fb49a7a29..be7b7495909 100755
> --- a/src/mapi/new/gen_gldispatch_mapi.py
> +++ b/src/mapi/new/gen_gldispatch_mapi.py
> @@ -139,7 +139,7 @@ def generate_public_stubs(functions):
>  return text
>  
>  def generate_public_entries(functions):
> -text = "#ifdef MAPI_TMP_PUBLIC_ENTRIES\n"
> +text = "#ifdef MAPI_TMP_PUBLIC_ENTRIES_NO_HIDDEN\n"
>  
>  for func in functions:
>  retStr = ("return " if func.hasReturn() else "")
> @@ -158,12 +158,12 @@ GLAPI {f.rt} APIENTRY {f.name}({f.decArgs})
>  for func in functions:
>  text += "   (mapi_func) %s,\n" % (func.name,)
>  text += "};\n"
> -text += "#undef MAPI_TMP_PUBLIC_ENTRIES\n"
> -text += "#endif /* MAPI_TMP_PUBLIC_ENTRIES */\n"
> +text += "#undef MAPI_TMP_PUBLIC_ENTRIES_NO_HIDDEN\n"
> +text += "#endif /* MAPI_TMP_PUBLIC_ENTRIES_NO_HIDDEN */\n"
>  return text
>  
>  def generate_stub_asm_gcc(functions):
> -text = "#ifdef MAPI_TMP_STUB_ASM_GCC\n"
> +text = "#ifdef MAPI_TMP_STUB_ASM_GCC_NO_HIDDEN\n"
>  text += "__asm__(\n"
>  
>  for func in functions:
> @@ -171,8 +171,8 @@ def generate_stub_asm_gcc(functions):
>  text += '"\\t"STUB_ASM_CODE("%d")"\\n"\n\n' % (func.slot,)
>  
>  text += ");\n"
> -text += "#undef MAPI_TMP_STUB_ASM_GCC\n"
> -text += "#endif /* MAPI_TMP_STUB_ASM_GCC */\n"
> +text += "#undef MAPI_TMP_STUB_ASM_GCC_NO_HIDDEN\n"
> +text += "#endif /* MAPI_TMP_STUB_ASM_GCC_NO_HIDDEN */\n"
>  return text
>  
>  if (__name__ == "__main__"):

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

Re: [Mesa-dev] [PATCH v2 10/24] mapi/new: use the static_data offsets in the new generator

[Erik Faye-Lund]

Reviewed-by: Erik Faye-Lund 

On Fri, 2018-12-14 at 14:04 +, Emil Velikov wrote:
> From: Emil Velikov 
> 
> Otherwise the incorrect ones will be used, effectively 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.
> 
> v2:
>  - rework path handling (Dylan)
>  - use else if chain (Erik)
> 
> Signed-off-by: Emil Velikov 
> ---
>  src/mapi/new/genCommon.py | 20 +++-
>  1 file changed, 19 insertions(+), 1 deletion(-)
> 
> diff --git a/src/mapi/new/genCommon.py b/src/mapi/new/genCommon.py
> index ec48d522c05..bfcf6ed3eea 100644
> --- a/src/mapi/new/genCommon.py
> +++ b/src/mapi/new/genCommon.py
> @@ -30,6 +30,11 @@ import re
>  import sys
>  import xml.etree.cElementTree as etree
>  
> +import os
> +GLAPI = os.path.join(os.path.dirname(__file__), "..", "glapi",
> "gen")
> +sys.path.insert(0, GLAPI)
> +import static_data
> +
>  MAPI_TABLE_NUM_DYNAMIC = 4096
>  
>  _LIBRARY_FEATURE_NAMES = {
> @@ -68,11 +73,24 @@ def getFunctionsFromRoots(roots):
>  # Sort the function list by name.
>  functions = sorted(functions, key=lambda f: f.name)
>  
> +# Lookup for fixed offset/slot functions and use it if
> available.
>  # 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:]
> +
> +if name in static_data.offsets:
> +functions[i] =
> functions[i]._replace(slot=static_data.offsets[name])
> +elif not name.endswith("ARB") and name + "ARB" in
> static_data.offsets:
> +functions[i] =
> functions[i]._replace(slot=static_data.offsets[name + "ARB"])
> +elif not name.endswith("EXT") and name + "EXT" in
> static_data.offsets:
> +functions[i] =
> functions[i]._replace(slot=static_data.offsets[name + "EXT"])
> +else:
> +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)

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

Re: [Mesa-dev] [PATCH v2 09/24] mapi/new: sort by slot number

[Erik Faye-Lund]

I assume this will be kicked out of the branch before we merge? I mean,
either works, it just seems a bit pointless to keep patches to aid
comparisons in our tree.

On Fri, 2018-12-14 at 14:04 +, Emil Velikov wrote:
> From: Emil Velikov 
> 
> Makes it easier to compare the newly generated header against the old
> one. Will be reverted after the transition.
> ---
>  src/mapi/new/genCommon.py | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/src/mapi/new/genCommon.py b/src/mapi/new/genCommon.py
> index b0925d80151..ec48d522c05 100644
> --- a/src/mapi/new/genCommon.py
> +++ b/src/mapi/new/genCommon.py
> @@ -74,6 +74,9 @@ def getFunctionsFromRoots(roots):
>  for i in range(len(functions)):
>  functions[i] = functions[i]._replace(slot=i)
>  
> +# Sort the function list by slot to simplify the diff
> +functions = sorted(functions, key=lambda f: f.slot)
> +
>  return functions
>  
>  def getExportNamesFromRoots(target, roots):

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

Re: [Mesa-dev] [PATCH v2 08/24] mapi/new: import mapi scripts from glvnd

[Erik Faye-Lund]

On Fri, 2018-12-14 at 14:04 +, 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.")
> 
> v2: use local genCommon.py
> 
> Signed-off-by: Emil Velikov 
> ---
>  src/mapi/Makefile.am|   1 +
>  src/mapi/new/gen_gldispatch_mapi.py | 180
> 
>  2 files changed, 181 insertions(+)
>  create mode 100755 src/mapi/new/gen_gldispatch_mapi.py
> 
> diff --git a/src/mapi/Makefile.am b/src/mapi/Makefile.am
> index b46ed814700..5a619bf049b 100644
> --- a/src/mapi/Makefile.am
> +++ b/src/mapi/Makefile.am
> @@ -32,6 +32,7 @@ pkgconfig_DATA =
>  
>  EXTRA_DIST = \
>   new/genCommon.py \
> + new/gen_gldispatch_mapi.py \
>   es1api/ABI-check \
>   es2api/ABI-check \
>   mapi_abi.py \

Nit: I would add this in some later commit, when this actually becomes
used. Right now, I believe it's just cruft...

But regardless:

Reviewed-by: Erik Faye-Lund 

> diff --git a/src/mapi/new/gen_gldispatch_mapi.py
> b/src/mapi/new/gen_gldispatch_mapi.py
> new file mode 100755
> index 000..03fb49a7a29
> --- /dev/null
> +++ b/src/mapi/new/gen_gldispatch_mapi.py
> @@ -0,0 +1,180 @@
> +#!/usr/bin/env python
> +
> +# Copyright (C) 2010 LunarG Inc.
> +# (C) Copyright 2015, NVIDIA CORPORATION.
> +#
> +# Permission is hereby granted, free of charge, to any person
> obtaining a
> +# copy of this software and associated documentation files (the
> "Software"),
> +# to deal in the Software without restriction, including without
> limitation
> +# the rights to use, copy, modify, merge, publish, distribute,
> sublicense,
> +# and/or sell copies of the Software, and to permit persons to whom
> the
> +# Software is furnished to do so, subject to the following
> conditions:
> +#
> +# The above copyright notice and this permission notice shall be
> included
> +# in all copies or substantial portions of the Software.
> +#
> +# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> EXPRESS OR
> +# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> MERCHANTABILITY,
> +# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT
> SHALL
> +# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES
> OR OTHER
> +# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
> ARISING
> +# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> OTHER
> +# DEALINGS IN THE SOFTWARE.
> +#
> +# Authors:
> +#Kyle Brenneman 
> +#
> +# Based on code ogiginally by:
> +#Chia-I Wu 
> +
> +
> +"""
> +Generates the glapi_mapi_tmp.h header file from Khronos's XML file.
> +"""
> +
> +import sys
> +import xml.etree.cElementTree as etree
> +
> +import genCommon
> +
> +def _main():
> +target = sys.argv[1]
> +xmlFiles = sys.argv[2:]
> +
> +roots = [ etree.parse(filename).getroot() for filename in
> xmlFiles ]
> +allFunctions = genCommon.getFunctionsFromRoots(roots)
> +
> +names = genCommon.getExportNamesFromRoots(target, roots)
> +functions = [f for f in allFunctions if(f.name in names)]
> +
> +if (target in ("gl", "gldispatch")):
> +assert(len(functions) == len(allFunctions))
> +assert(all(functions[i] == allFunctions[i] for i in
> range(len(functions
> +assert(all(functions[i].slot == i for i in
> range(len(functions
> +
> +print(r"""
> +/* This file is automatically generated by mapi_abi.py.  Do not
> modify. */
> +
> +#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"))
> +
> +print(generate_defines(functions))
> +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))
> +
> +def generate_defines(functions):
> +text = r"""
> +#ifdef MAPI_TMP_DEFINES
> +#define GL_GLEXT_PROTOTYPES
> +#include "GL/gl.h"
> +#include "GL/glext.h"
> +
> +""".lstrip("\n")
> +for func in functions:
> +text += "GLAPI {f.rt} APIENTRY
> 

Re: [Mesa-dev] [PATCH v2 07/24] mapi: move genCommon.py to src/mapi/new

[Erik Faye-Lund]

On Fri, 2018-12-14 at 14:04 +, Emil Velikov wrote:
> From: Emil Velikov 
> 
> The helper will also be used by the new Khronos gl.xml aware
> generator.
> 
> v2: Move existing one, instead of duplicating it.
> 
> Suggested-by: Kyle Brenneman 
> Signed-off-by: Emil Velikov 
> ---
>  src/egl/Makefile.am | 6 --
>  src/egl/generate/gen_egl_dispatch.py| 3 +++
>  src/egl/meson.build | 4 ++--
>  src/mapi/Makefile.am| 1 +
>  src/mapi/meson.build| 1 +
>  src/{egl/generate => mapi/new}/genCommon.py | 0
>  6 files changed, 11 insertions(+), 4 deletions(-)
>  rename src/{egl/generate => mapi/new}/genCommon.py (100%)
> 
> diff --git a/src/egl/Makefile.am b/src/egl/Makefile.am
> index 7269912d96f..6ce51936b16 100644
> --- a/src/egl/Makefile.am
> +++ b/src/egl/Makefile.am
> @@ -136,8 +136,10 @@ libEGL_common_la_LIBADD += \
>   $(LIBDRM_LIBS) \
>   $(CLOCK_LIB)
>  
> -GLVND_GEN_DEPS = generate/gen_egl_dispatch.py \
> - generate/egl.xml generate/eglFunctionList.py
> generate/genCommon.py \
> +GLVND_GEN_DEPS = $(top_scrdir)/src/mapi/new/generate/genCommon.py \
> + generate/gen_egl_dispatch.py \
> + generate/eglFunctionList.py \
> + generate/egl.xml \
>   generate/egl_other.xml
>  
>  PYTHON_GEN = $(AM_V_GEN)$(PYTHON) $(PYTHON_FLAGS)
> diff --git a/src/egl/generate/gen_egl_dispatch.py
> b/src/egl/generate/gen_egl_dispatch.py
> index eeb3f3f9a5a..728799e9754 100644
> --- a/src/egl/generate/gen_egl_dispatch.py
> +++ b/src/egl/generate/gen_egl_dispatch.py
> @@ -38,6 +38,9 @@ import imp
>  import sys
>  import textwrap
>  
> +import os
> +NEWAPI = os.path.join(os.path.dirname(__file__), "..", "..", "mapi",
> "new")
> +sys.path.insert(0, NEWAPI)
>  import genCommon
>  
>  def main():
> diff --git a/src/egl/meson.build b/src/egl/meson.build
> index 89bac2cd633..33f24dec5e2 100644
> --- a/src/egl/meson.build
> +++ b/src/egl/meson.build
> @@ -69,7 +69,7 @@ g_egldispatchstubs_c = custom_target(
>command : [
>  prog_python, '@INPUT0@', 'source', '@INPUT1@', '@INPUT2@', 
> '@INPUT3@'
>],
> -  depend_files : files('generate/genCommon.py'),
> +  depend_files : glapi_gen_mapi_py,
>capture : true,
>  )
>  
> @@ -83,7 +83,7 @@ g_egldispatchstubs_h = custom_target(
>command : [
>  prog_python, '@INPUT0@', 'header', '@INPUT1@', '@INPUT2@', 
> '@INPUT3@'
>],
> -  depend_files : files('generate/genCommon.py'),
> +  depend_files : glapi_gen_mapi_py,
>capture : true,
>  )
>  

I don't think I understand this change. Why does this script no longer
depend on genCommon.py, just because it moved?

I would expect something like this:

---8<---
genCommon_py = files(join_paths('..', '..', 'mapi', 'new',
'genCommon.py'))



  depend_files : [glapi_gen_mapi_py, genCommon_py],
---8<---

(It's probably cleaner to define genCommon_py in some other meson-file
closer to the source, but this should illustrate my point)

> diff --git a/src/mapi/Makefile.am b/src/mapi/Makefile.am
> index 97ebdeb1d7f..b46ed814700 100644
> --- a/src/mapi/Makefile.am
> +++ b/src/mapi/Makefile.am
> @@ -31,6 +31,7 @@ pkgconfigdir = $(libdir)/pkgconfig
>  pkgconfig_DATA =
>  
>  EXTRA_DIST = \
> + new/genCommon.py \
>   es1api/ABI-check \
>   es2api/ABI-check \
>   mapi_abi.py \

If this is added to EXTRA_DIST, I kinda would have expected it to be
removed from some EXTRA_DIST-variable in the old location... Why do we
need to introduce distribution of this? Don't we just distribute the
built API?

> diff --git a/src/mapi/meson.build b/src/mapi/meson.build
> index 798586bfb0c..0b7fd42a633 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_py = files('new/gen_gldispatch_mapi.py')
>  mapi_abi_py = files('mapi_abi.py')
>  
>  subdir('glapi')
> diff --git a/src/egl/generate/genCommon.py
> b/src/mapi/new/genCommon.py
> similarity index 100%
> rename from src/egl/generate/genCommon.py
> rename to src/mapi/new/genCommon.py

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

Re: [Mesa-dev] [PATCH v2 05/24] mapi: add all _glapi_table entrypoints to static_data.py

[Erik Faye-Lund]

Reviewed-by: Erik Faye-Lund 

On Fri, 2018-12-14 at 14:04 +, Emil Velikov wrote:
> 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 
> ---
> Data extracted via the following patch:
> https://github.com/evelikov/Mesa/commit/458710eb85876d008faaccc7418042eb57234621
> ---
>  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,
> 

Re: [Mesa-dev] [PATCH v2 06/24] genCommon.py: Fix typo in _LIBRARY_FEATURE_NAMES.

[Erik Faye-Lund]

Reviewed-by: Erik Faye-Lund 

On Fri, 2018-12-14 at 14:04 +, Emil Velikov wrote:
> From: Emil Velikov 
> 
> Port glvnd commit 37fc6caa4b8 ("Fix typo in _LIBRARY_FEATURE_NAMES.")
> from Michal Srb.
> 
> Signed-off-by: Emil Velikov 
> ---
>  src/egl/generate/genCommon.py | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/egl/generate/genCommon.py
> b/src/egl/generate/genCommon.py
> index d493d7bf29a..b0925d80151 100644
> --- a/src/egl/generate/genCommon.py
> +++ b/src/egl/generate/genCommon.py
> @@ -44,7 +44,7 @@ _LIBRARY_FEATURE_NAMES = {
>  )),
>  "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",
> +"GL_ES_VERSION_3_1", "GL_ES_VERSION_3_2",
>  )),
>  }
>  

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

Re: [Mesa-dev] [PATCH v2 03/24] Revert "mesa/main: remove ARB suffix from glGetnTexImage"

[Erik Faye-Lund]

Acked-by: Erik Faye-Lund 

On Fri, 2018-12-14 at 14:04 +, Emil Velikov wrote:
> This reverts commit f1998e15ffccf260552bf559abe1a733a8ce990e.
> 
> This changes the ABI, such that glGetnTexImageARB entry-point from
> the
> GLAPI gets removed. Thus accessing many functions by offset (as we
> do)
> will result in getting the wrong one.
> 
> Follow-up work will swap the by-offset handling, but for now revert
> this patch.
> 
> Cc: Erik Faye-Lund 
> ---
>  src/mapi/glapi/gen/ARB_robustness.xml | 2 +-
>  src/mapi/glapi/gen/gl_API.xml | 9 -
>  src/mesa/main/texgetimage.c   | 6 +++---
>  src/mesa/main/texgetimage.h   | 4 ++--
>  4 files changed, 6 insertions(+), 15 deletions(-)
> 
> diff --git a/src/mapi/glapi/gen/ARB_robustness.xml
> b/src/mapi/glapi/gen/ARB_robustness.xml
> index 47c417390df..1f6ac4696b6 100644
> --- a/src/mapi/glapi/gen/ARB_robustness.xml
> +++ b/src/mapi/glapi/gen/ARB_robustness.xml
> @@ -73,7 +73,7 @@
>  
>  
>  
> -
> +
>  
>  
>  
> diff --git a/src/mapi/glapi/gen/gl_API.xml
> b/src/mapi/glapi/gen/gl_API.xml
> index f4d0808f13b..929e5f6b024 100644
> --- a/src/mapi/glapi/gen/gl_API.xml
> +++ b/src/mapi/glapi/gen/gl_API.xml
> @@ -2817,15 +2817,6 @@
>  
>  
>  
> -
> -
> -
> -
> -
> -
> -
> -
> -
>  
>  
>  
> diff --git a/src/mesa/main/texgetimage.c
> b/src/mesa/main/texgetimage.c
> index dabfcd06a52..bb4f7006618 100644
> --- a/src/mesa/main/texgetimage.c
> +++ b/src/mesa/main/texgetimage.c
> @@ -1440,11 +1440,11 @@ get_texture_image(struct gl_context *ctx,
>  
>  
>  void GLAPIENTRY
> -_mesa_GetnTexImage(GLenum target, GLint level, GLenum format, GLenum
> type,
> -   GLsizei bufSize, GLvoid *pixels)
> +_mesa_GetnTexImageARB(GLenum target, GLint level, GLenum format,
> GLenum type,
> +  GLsizei bufSize, GLvoid *pixels)
>  {
> GET_CURRENT_CONTEXT(ctx);
> -   static const char *caller = "glGetnTexImage";
> +   static const char *caller = "glGetnTexImageARB";
> GLsizei width, height, depth;
> struct gl_texture_object *texObj;
>  
> diff --git a/src/mesa/main/texgetimage.h
> b/src/mesa/main/texgetimage.h
> index 9a5874300e7..3928e7abb7b 100644
> --- a/src/mesa/main/texgetimage.h
> +++ b/src/mesa/main/texgetimage.h
> @@ -56,8 +56,8 @@ extern void GLAPIENTRY
>  _mesa_GetTexImage( GLenum target, GLint level,
> GLenum format, GLenum type, GLvoid *pixels );
>  extern void GLAPIENTRY
> -_mesa_GetnTexImage(GLenum target, GLint level, GLenum format,
> -   GLenum type, GLsizei bufSize, GLvoid *pixels);
> +_mesa_GetnTexImageARB( GLenum target, GLint level, GLenum format,
> +   GLenum type, GLsizei bufSize, GLvoid *pixels
> );
>  extern void GLAPIENTRY
>  _mesa_GetTextureImage(GLuint texture, GLint level, GLenum format,
>GLenum type, GLsizei bufSize, GLvoid *pixels);

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

Re: [Mesa-dev] [PATCH v2 01/24] mesa: correctly use os.path.join in our python scripts

[Erik Faye-Lund]

Reviewed-by: Erik Faye-Lund 

On Fri, 2018-12-14 at 14:04 +, Emil Velikov wrote:
> From: Emil Velikov 
> 
> With Windows in mind, using forward slash isn't the right thing to
> do.
> Even if it just works, we might want to fix it.
> 
> As here, use __file__ instead of argv[0] and sys.path.insert over
> sys.path.append. With the path tweak being reportedly faster.
> 
> Cc: Dylan Baker 
> Suggested-by: Dylan Baker 
> Signed-off-by: Emil Velikov 
> ---
>  src/mapi/mapi_abi.py| 4 ++--
>  src/mesa/main/get_hash_generator.py | 7 +++
>  2 files changed, 5 insertions(+), 6 deletions(-)
> 
> diff --git a/src/mapi/mapi_abi.py b/src/mapi/mapi_abi.py
> index dc48fa5935f..bb505561e7c 100644
> --- a/src/mapi/mapi_abi.py
> +++ b/src/mapi/mapi_abi.py
> @@ -29,8 +29,8 @@ from __future__ import print_function
>  import sys
>  # make it possible to import glapi
>  import os
> -GLAPI = os.path.join(".", os.path.dirname(sys.argv[0]), "glapi/gen")
> -sys.path.append(GLAPI)
> +GLAPI = os.path.join(".", os.path.dirname(__file__), "glapi", "gen")
> +sys.path.insert(0, GLAPI)
>  
>  from operator import attrgetter
>  import re
> diff --git a/src/mesa/main/get_hash_generator.py
> b/src/mesa/main/get_hash_generator.py
> index f742ebff4b8..3e9032bd4c8 100644
> --- a/src/mesa/main/get_hash_generator.py
> +++ b/src/mesa/main/get_hash_generator.py
> @@ -34,11 +34,10 @@ import os, sys, getopt
>  from collections import defaultdict
>  import get_hash_params
>  
> -cur_dir = os.path.dirname(sys.argv[0])
> -param_desc_file = "%s/get_hash_params.py" % cur_dir
> +param_desc_file = os.path.join(os.path.dirname(__file__),
> "get_hash_params.py")
>  
> -GLAPI = "%s/../../mapi/glapi/gen" % cur_dir
> -sys.path.append(GLAPI)
> +GLAPI = os.path.join(os.path.dirname(__file__), "..", "..", "mapi",
> "glapi", "gen")
> +sys.path.insert(0, GLAPI)
>  import gl_XML
>  
>  prime_factor = 89

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

[Mesa-dev] [PATCH v2 20/24] 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 
Reviewed-by: Erik Faye-Lund 
---
 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.2

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

[Mesa-dev] [PATCH v2 06/24] genCommon.py: Fix typo in _LIBRARY_FEATURE_NAMES.

[Emil Velikov]

From: Emil Velikov 

Port glvnd commit 37fc6caa4b8 ("Fix typo in _LIBRARY_FEATURE_NAMES.")
from Michal Srb.

Signed-off-by: Emil Velikov 
---
 src/egl/generate/genCommon.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/egl/generate/genCommon.py b/src/egl/generate/genCommon.py
index d493d7bf29a..b0925d80151 100644
--- a/src/egl/generate/genCommon.py
+++ b/src/egl/generate/genCommon.py
@@ -44,7 +44,7 @@ _LIBRARY_FEATURE_NAMES = {
 )),
 "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",
+"GL_ES_VERSION_3_1", "GL_ES_VERSION_3_2",
 )),
 }
 
-- 
2.19.2

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

[Mesa-dev] [PATCH v2 12/24] mapi/new: split out public_entries handling

[Emil Velikov]

From: Emil Velikov 

The only instance that requires the public_entries table is the
dispatch library - split that into another function.

We have to be careful with when undefining the guard, so split it out.

We might want to merge this back in GLVND.
Minor GLVND cleanup will be needed first.

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

diff --git a/src/mapi/new/gen_gldispatch_mapi.py 
b/src/mapi/new/gen_gldispatch_mapi.py
index be7b7495909..959d8798f5c 100755
--- a/src/mapi/new/gen_gldispatch_mapi.py
+++ b/src/mapi/new/gen_gldispatch_mapi.py
@@ -67,6 +67,8 @@ typedef void (APIENTRY  *GLDEBUGPROCKHR)(GLenum source,GLenum 
type,GLuint id,GLe
 print(generate_noop_array(functions))
 print(generate_public_stubs(functions))
 print(generate_public_entries(functions))
+print(generate_public_entries_table(functions))
+print(generate_undef_public_entries())
 print(generate_stub_asm_gcc(functions))
 
 def generate_defines(functions):
@@ -154,10 +156,20 @@ GLAPI {f.rt} APIENTRY {f.name}({f.decArgs})
 """.lstrip("\n").format(f=func, retStr=retStr)
 
 text += "\n"
+text += "#endif /* MAPI_TMP_PUBLIC_ENTRIES_NO_HIDDEN */\n"
+return text
+
+def generate_public_entries_table(functions):
+text = "#ifdef MAPI_TMP_PUBLIC_ENTRIES_NO_HIDDEN\n"
 text += "static const mapi_func public_entries[] = {\n"
 for func in functions:
 text += "   (mapi_func) %s,\n" % (func.name,)
 text += "};\n"
+text += "#endif /* MAPI_TMP_PUBLIC_ENTRIES_NO_HIDDEN */\n"
+return text
+
+def generate_undef_public_entries():
+text = "#ifdef MAPI_TMP_PUBLIC_ENTRIES_NO_HIDDEN\n"
 text += "#undef MAPI_TMP_PUBLIC_ENTRIES_NO_HIDDEN\n"
 text += "#endif /* MAPI_TMP_PUBLIC_ENTRIES_NO_HIDDEN */\n"
 return text
-- 
2.19.2

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

[Mesa-dev] [PATCH v2 21/24] 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 
Reviewed-by: Erik Faye-Lund 
---
 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.2

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

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

[Emil Velikov]

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

Pretty much all of this is applicable to GLVND, although it
requires preparatory work.

v2:
 - python style fixes (Dylan)
 - use "gldispatch" instead of not "glesv1" "glesv2"
 - remove the public_entries table/array (Erik)

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

diff --git a/src/mapi/new/gen_gldispatch_mapi.py 
b/src/mapi/new/gen_gldispatch_mapi.py
index 959d8798f5c..cc0e286e221 100755
--- a/src/mapi/new/gen_gldispatch_mapi.py
+++ b/src/mapi/new/gen_gldispatch_mapi.py
@@ -63,11 +63,13 @@ 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 in "gldispatch":
+print(generate_table(functions, allFunctions))
+print(generate_noop_array(functions))
+print(generate_public_stubs(functions))
 print(generate_public_entries(functions))
-print(generate_public_entries_table(functions))
+if target in "gldispatch":
+print(generate_public_entries_table(functions))
 print(generate_undef_public_entries())
 print(generate_stub_asm_gcc(functions))
 
-- 
2.19.2

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

[Mesa-dev] [PATCH v2 16/24] 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 extension entrypoints - invalid/incorrect

To make things easier to validate, normalise both old/new headers run
the sed patterns A and B 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/\/dpfail/g; s/\/dppass/g; s/\/index/g;
  s/\/target/g; s/\/target/g; s/\/index/g;
  s/\/sfactorRGB/g; s/\/dfactorRGB/g;
  s/\/sfactorAlpha/g; s/\/dfactorAlpha/g;
  s/\/mode/g; s/\/instancecount/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;
  s/\/mode/g; s/\/dst/g; 
s/\/bindingindex/g;
  s/\/internalformat/g; s/\/bufsize/g;

C
glMultiDrawArraysEXT
glMultiDrawElementsEXT

glBindFragDataLocationEXT

glGetTexParameterIivEXT
glGetTexParameterIuivEXT
glTexParameterIivEXT
glTexParameterIuivEXT

v2:
 - gl_dispatch_stub declarations are addressed with previous patch
 - the public_entries table is no longer generated.

Signed-off-by: Emil Velikov 
---
Actual diff can be found at
https://gist.github.com/evelikov/dfe302855331eb70f4619359685bf913
---
 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.2

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

[Mesa-dev] [PATCH v2 22/24] 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 
Reviewed-by: Erik Faye-Lund 
---
 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.2

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

[Mesa-dev] [PATCH v2 17/24] meson: wire the new generator for es1 and es2

[Emil Velikov]

From: Emil Velikov 

v2: use ${foo})_py naming (Dylan)

Cc: Dylan Baker 
Cc: Eric Engestrom 
Signed-off-by: Emil Velikov 
---
 src/mapi/es1api/meson.build| 6 +++---
 src/mapi/es2api/meson.build| 6 +++---
 src/mapi/glapi/gen/meson.build | 7 +++
 3 files changed, 13 insertions(+), 6 deletions(-)

diff --git a/src/mapi/es1api/meson.build b/src/mapi/es1api/meson.build
index 53e894f091c..b0416e705a1 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_py, 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..a7f0904b699 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_py, 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 8cc163b2989..113e88aa99a 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(
-- 
2.19.2

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

[Mesa-dev] [PATCH v2 14/24] 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 bfcf6ed3eea..f4eb1728e95 100644
--- a/src/mapi/new/genCommon.py
+++ b/src/mapi/new/genCommon.py
@@ -227,6 +227,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 cc0e286e221..65e42bd2a0d 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.2

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

[Mesa-dev] [PATCH v2 15/24] 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 
Reviewed-by: Erik Faye-Lund 
---
 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 f4eb1728e95..a9fdbcdc9ee 100644
--- a/src/mapi/new/genCommon.py
+++ b/src/mapi/new/genCommon.py
@@ -226,7 +226,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.2

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

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

[Emil Velikov]

From: Emil Velikov 

Signed-off-by: Emil Velikov 
Reviewed-by: Erik Faye-Lund 
---
 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.2

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

[Mesa-dev] [PATCH v2 23/24] 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 
Reviewed-by: Erik Faye-Lund 
---
 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 1ce3fd3f1e6..e4142a23f64 100644
--- a/src/mapi/mapi_abi.py
+++ b/src/mapi/mapi_abi.py
@@ -680,62 +680,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 

[Mesa-dev] [PATCH v2 24/24] 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 
Reviewed-by: Erik Faye-Lund 
---
 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 e4142a23f64..4293cc0c6c2 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
@@ -715,7 +646,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)))
 
@@ -724,6 +655,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():
@@ -734,10 +669,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.2

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

[Mesa-dev] [PATCH v2 10/24] mapi/new: use the static_data offsets in the new generator

[Emil Velikov]

From: Emil Velikov 

Otherwise the incorrect ones will be used, effectively 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.

v2:
 - rework path handling (Dylan)
 - use else if chain (Erik)

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

diff --git a/src/mapi/new/genCommon.py b/src/mapi/new/genCommon.py
index ec48d522c05..bfcf6ed3eea 100644
--- a/src/mapi/new/genCommon.py
+++ b/src/mapi/new/genCommon.py
@@ -30,6 +30,11 @@ import re
 import sys
 import xml.etree.cElementTree as etree
 
+import os
+GLAPI = os.path.join(os.path.dirname(__file__), "..", "glapi", "gen")
+sys.path.insert(0, GLAPI)
+import static_data
+
 MAPI_TABLE_NUM_DYNAMIC = 4096
 
 _LIBRARY_FEATURE_NAMES = {
@@ -68,11 +73,24 @@ def getFunctionsFromRoots(roots):
 # Sort the function list by name.
 functions = sorted(functions, key=lambda f: f.name)
 
+# Lookup for fixed offset/slot functions and use it if available.
 # 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:]
+
+if name in static_data.offsets:
+functions[i] = 
functions[i]._replace(slot=static_data.offsets[name])
+elif not name.endswith("ARB") and name + "ARB" in static_data.offsets:
+functions[i] = functions[i]._replace(slot=static_data.offsets[name 
+ "ARB"])
+elif not name.endswith("EXT") and name + "EXT" in static_data.offsets:
+functions[i] = functions[i]._replace(slot=static_data.offsets[name 
+ "EXT"])
+else:
+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.2

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

[Mesa-dev] [PATCH v2 04/24] 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 
Reviewed-by: Erik Faye-Lund 
---
 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.2

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

[Mesa-dev] [PATCH v2 19/24] Revert "mapi/new: sort by slot number"

[Emil Velikov]

This reverts commit a1f5d9412cf7cacb3534635f6c2409fafbe6574e.

We no longer needed to sort - it was meant only to ease compare against
the old generated files.
---
 src/mapi/new/genCommon.py | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/src/mapi/new/genCommon.py b/src/mapi/new/genCommon.py
index a9fdbcdc9ee..bf71de14891 100644
--- a/src/mapi/new/genCommon.py
+++ b/src/mapi/new/genCommon.py
@@ -92,9 +92,6 @@ def getFunctionsFromRoots(roots):
 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)
-
 return functions
 
 def getExportNamesFromRoots(target, roots):
-- 
2.19.2

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

[Mesa-dev] [PATCH v2 07/24] mapi: move genCommon.py to src/mapi/new

[Emil Velikov]

From: Emil Velikov 

The helper will also be used by the new Khronos gl.xml aware generator.

v2: Move existing one, instead of duplicating it.

Suggested-by: Kyle Brenneman 
Signed-off-by: Emil Velikov 
---
 src/egl/Makefile.am | 6 --
 src/egl/generate/gen_egl_dispatch.py| 3 +++
 src/egl/meson.build | 4 ++--
 src/mapi/Makefile.am| 1 +
 src/mapi/meson.build| 1 +
 src/{egl/generate => mapi/new}/genCommon.py | 0
 6 files changed, 11 insertions(+), 4 deletions(-)
 rename src/{egl/generate => mapi/new}/genCommon.py (100%)

diff --git a/src/egl/Makefile.am b/src/egl/Makefile.am
index 7269912d96f..6ce51936b16 100644
--- a/src/egl/Makefile.am
+++ b/src/egl/Makefile.am
@@ -136,8 +136,10 @@ libEGL_common_la_LIBADD += \
$(LIBDRM_LIBS) \
$(CLOCK_LIB)
 
-GLVND_GEN_DEPS = generate/gen_egl_dispatch.py \
-   generate/egl.xml generate/eglFunctionList.py generate/genCommon.py \
+GLVND_GEN_DEPS = $(top_scrdir)/src/mapi/new/generate/genCommon.py \
+   generate/gen_egl_dispatch.py \
+   generate/eglFunctionList.py \
+   generate/egl.xml \
generate/egl_other.xml
 
 PYTHON_GEN = $(AM_V_GEN)$(PYTHON) $(PYTHON_FLAGS)
diff --git a/src/egl/generate/gen_egl_dispatch.py 
b/src/egl/generate/gen_egl_dispatch.py
index eeb3f3f9a5a..728799e9754 100644
--- a/src/egl/generate/gen_egl_dispatch.py
+++ b/src/egl/generate/gen_egl_dispatch.py
@@ -38,6 +38,9 @@ import imp
 import sys
 import textwrap
 
+import os
+NEWAPI = os.path.join(os.path.dirname(__file__), "..", "..", "mapi", "new")
+sys.path.insert(0, NEWAPI)
 import genCommon
 
 def main():
diff --git a/src/egl/meson.build b/src/egl/meson.build
index 89bac2cd633..33f24dec5e2 100644
--- a/src/egl/meson.build
+++ b/src/egl/meson.build
@@ -69,7 +69,7 @@ g_egldispatchstubs_c = custom_target(
   command : [
 prog_python, '@INPUT0@', 'source', '@INPUT1@', '@INPUT2@', '@INPUT3@'
   ],
-  depend_files : files('generate/genCommon.py'),
+  depend_files : glapi_gen_mapi_py,
   capture : true,
 )
 
@@ -83,7 +83,7 @@ g_egldispatchstubs_h = custom_target(
   command : [
 prog_python, '@INPUT0@', 'header', '@INPUT1@', '@INPUT2@', '@INPUT3@'
   ],
-  depend_files : files('generate/genCommon.py'),
+  depend_files : glapi_gen_mapi_py,
   capture : true,
 )
 
diff --git a/src/mapi/Makefile.am b/src/mapi/Makefile.am
index 97ebdeb1d7f..b46ed814700 100644
--- a/src/mapi/Makefile.am
+++ b/src/mapi/Makefile.am
@@ -31,6 +31,7 @@ pkgconfigdir = $(libdir)/pkgconfig
 pkgconfig_DATA =
 
 EXTRA_DIST = \
+   new/genCommon.py \
es1api/ABI-check \
es2api/ABI-check \
mapi_abi.py \
diff --git a/src/mapi/meson.build b/src/mapi/meson.build
index 798586bfb0c..0b7fd42a633 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_py = files('new/gen_gldispatch_mapi.py')
 mapi_abi_py = files('mapi_abi.py')
 
 subdir('glapi')
diff --git a/src/egl/generate/genCommon.py b/src/mapi/new/genCommon.py
similarity index 100%
rename from src/egl/generate/genCommon.py
rename to src/mapi/new/genCommon.py
-- 
2.19.2

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

[Mesa-dev] [PATCH v2 11/24] mapi/new: reinstate _NO_HIDDEN suffixes in the new generator

[Emil Velikov]

From: Emil Velikov 

Strictly speaking we can rework the rest of the code so we do not need
those. That said, this will require a series on it's own so let's carry
this local quirk for now.

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

diff --git a/src/mapi/new/gen_gldispatch_mapi.py 
b/src/mapi/new/gen_gldispatch_mapi.py
index 03fb49a7a29..be7b7495909 100755
--- a/src/mapi/new/gen_gldispatch_mapi.py
+++ b/src/mapi/new/gen_gldispatch_mapi.py
@@ -139,7 +139,7 @@ def generate_public_stubs(functions):
 return text
 
 def generate_public_entries(functions):
-text = "#ifdef MAPI_TMP_PUBLIC_ENTRIES\n"
+text = "#ifdef MAPI_TMP_PUBLIC_ENTRIES_NO_HIDDEN\n"
 
 for func in functions:
 retStr = ("return " if func.hasReturn() else "")
@@ -158,12 +158,12 @@ GLAPI {f.rt} APIENTRY {f.name}({f.decArgs})
 for func in functions:
 text += "   (mapi_func) %s,\n" % (func.name,)
 text += "};\n"
-text += "#undef MAPI_TMP_PUBLIC_ENTRIES\n"
-text += "#endif /* MAPI_TMP_PUBLIC_ENTRIES */\n"
+text += "#undef MAPI_TMP_PUBLIC_ENTRIES_NO_HIDDEN\n"
+text += "#endif /* MAPI_TMP_PUBLIC_ENTRIES_NO_HIDDEN */\n"
 return text
 
 def generate_stub_asm_gcc(functions):
-text = "#ifdef MAPI_TMP_STUB_ASM_GCC\n"
+text = "#ifdef MAPI_TMP_STUB_ASM_GCC_NO_HIDDEN\n"
 text += "__asm__(\n"
 
 for func in functions:
@@ -171,8 +171,8 @@ def generate_stub_asm_gcc(functions):
 text += '"\\t"STUB_ASM_CODE("%d")"\\n"\n\n' % (func.slot,)
 
 text += ");\n"
-text += "#undef MAPI_TMP_STUB_ASM_GCC\n"
-text += "#endif /* MAPI_TMP_STUB_ASM_GCC */\n"
+text += "#undef MAPI_TMP_STUB_ASM_GCC_NO_HIDDEN\n"
+text += "#endif /* MAPI_TMP_STUB_ASM_GCC_NO_HIDDEN */\n"
 return text
 
 if (__name__ == "__main__"):
-- 
2.19.2

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

[Mesa-dev] [PATCH v2 05/24] 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 
---
Data extracted via the following patch:
https://github.com/evelikov/Mesa/commit/458710eb85876d008faaccc7418042eb57234621
---
 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,