Re: [Mesa-dev] [PATCH 2/2] egl: add EGL_platform_device support

[Mathias Fröhlich]

Good Morning,

On Wednesday, 1 May 2019 21:43:08 CEST Marek Olšák wrote:
> BTW, swrast doesn't have to exist on the system. It's not uncommon for me
> to have no swrast on my development system.

Ok. I see. I use swrast regularly to test changes with different backend 
drivers.
Also especially classic swrast as something that is close to the good old swtnl
drivers - to catch bad interactions with those.

Anyhow, with a very old swrast I think you will get test failures.
But else if the system swrast is found in the hopefully not so distant future
the tests should even pass - well depends on what Emil now does to get a
better overall swrast behavior.
On a production system with a full set of driver packages I do expect to
find swrast, right? At least on a workstation grade linux distribution.

I start to see the actual problem for AMD there.
Not your test system at home, but the pro driver that needs to ship
and QA swrast then.

Anyhow, I do not actually understand the way how we walk all
installed egl driver implementations - including closed drivers - finally
and present all those devices. In a perfect world *for the customer*
I could enumerate all devices - including oss i965 and the closed nvidia
bumblebee device - on my laptop for example.

Means - if that works fine AMD could hook into that mechanism and
provide further devices. Well - in the long term.

Thinking ...

best

Mathias




> 
> Marek
> 
> On Wed, May 1, 2019 at 4:30 AM Mathias Fröhlich 
> wrote:
> 
> > Hi Marek, Emil,
> >
> > On Tuesday, 30 April 2019 15:36:08 CEST Emil Velikov wrote:
> > > On Mon, 29 Apr 2019 at 22:50, Marek Olšák  wrote:
> > > >
> > > > On Mon, Apr 29, 2019 at 4:00 AM Pekka Paalanen 
> > wrote:
> > > >>
> > > >> On Sat, 27 Apr 2019 09:38:27 -0400
> > > >> Marek Olšák  wrote:
> > > >>
> > > >> > Those are all valid reasons, but I don't wanna expose swrast for
> > AMD's
> > > >> > customers.
> > > >>
> > > >> Hi Marek,
> > > >>
> > > >> is you objection that you will never want to see any software renderer
> > > >> in the list, or that you don't want to see a software renderer only as
> > > >> long as it doesn't actually work?
> > > >>
> > > >> Why do you not "wanna expose swrast for AMD's customers"?
> > > >>
> > > >> Are you talking about swrast specifically or all the software
> > renderers
> > > >> in Mesa?
> > > >>
> > > >> I'm not an AMD customer if you mean someone paying for support rather
> > > >> than just buying their hardware, so I cannot speak for them. However,
> > I
> > > >> would be very happy to have a software renderer available to be picked
> > > >> the same way as any other hardware renderer, so that I can use it in
> > > >> graphical test suites (a point from Anholt) testing also the EGL glue
> > > >> in addition to the pixels produced.
> > > >>
> > > >> The thing will be run on boxes with AMD GPUs, and in those cases there
> > > >> must be a way to *not* use the AMD GPU, and use the software renderer
> > > >> instead when wanted. Not by environment variables or anything hacky
> > > >> like that, but by deliberately choosing the software renderer in the
> > > >> program. It will need an EGLSurface too.
> > > >>
> > > >> How would this be made to work in the future?
> > > >
> > > >
> > > > A software renderer could be exposed by adding a new EGL function on
> > top of EGL_EXT_device_base, for example:
> > > >
> > > > // EGL_MESA_device_software
> > > >
> > > > EGLBoolean eglQuerySoftwareDeviceMESA(EGLDeviceEXT *swdevice);
> > > >
> > > >
> > > > You would get the swrast device from that function instead of
> > eglQueryDevicesEXT. It clearly separates hw and sw devices but keeps
> > everything else the same.
> > > >
> > > IMHO the current EGL_MESA_device_software approach is perfectly valid.
> > > The Query API provides the devices and one can query their
> > > capabilities/device extensions.
> >
> > I agree with that. Well to repeat myself.
> >
> > For me there is also a basic consistency argument behind.
> > So, Marek, you propose that the swrast device should only show
> > up when there is no other device. That means swrast qualifies in
> > principle as a 'device'.
> > But if there is an other 'device' then swrast is not a 'device' anymore?
> > I can not quite understand that from the outside.
> > Means if swrast qualifies as a device in one configuration if should also
> > be a device in any other configuration.
> >
> > There is also a next problem. I can understand that AMD wants to avoid
> > for a customer to grab the swrast device by accident and get worse
> > performance.
> > But where do you draw the line then? Do you want to block out a drm device
> > that comes up as a administration console device in such a typical compute
> > cluster when there is an AMD device available? I mean for the same reason,
> > where you want to avoid an application to grab the matrox device on that
> > board
> > that is put there for some sort of framebuffer console? If does AMD then
> > negotiate with
> > the Int

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

[AppVeyor]

Build mesa 11014 failed


Commit 512a31a412 by Dave Airlie on 4/29/2019 3:17 AM:

util/bitset: fix bitset range mask calculations.\n\nThe MASK macro is used in the RANGE macro, and it should\nreturn the pre-bitset word mask for the (b) value.\n\ni.e.\nBITSET_MASK(0) should be undefined since it's meaningless.\nBITSET_MASK(31) should give 0x7fff\nBITSET_MASK(32) should give 0x\nBITSET_MASK(33) should give 0x0001\nBITSET_MASK(64) should give 0x\n\nHowever then BITSET_RANGE ends up broken for cases where\nit's (b) value is the 0,32,64 value as in that case the lower\nmask would be 0 not 0x.\n\nThis fixes the unit tests that I've added, and my code that\nuses bitsets.\n\nReviewed-by: Jason Ekstrand \nFixes: bb38cadb1c5f2 "More GLSL code"\nReviewed-by: Kristian H. Kristensen 


Configure your notification preferences

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

Re: [Mesa-dev] [PATCH 03/10] mesa: Implement _mesa_array_element by walking enabled arrays.

[Mathias Fröhlich]

Hi Brian,

On Friday, 3 May 2019 00:17:51 CEST Brian Paul wrote:
> On 05/02/2019 03:27 AM, mathias.froehl...@gmx.net wrote:
> > From: Mathias Fröhlich 
> > 
> > In glArrayElement, use the bitmask trick to just walk the enabled
> > vao arrays. This should be about equivalent in execution time to
> > walk the prepare aelt_context list. Finally this will allow us to
> > reduce the _mesa_update_state calls in a few patches.
> > 
> > Signed-off-by: Mathias Fröhlich 
> > ---
> >   src/mesa/main/api_arrayelt.c | 78 
> >   1 file changed, 61 insertions(+), 17 deletions(-)
> > 
> > diff --git a/src/mesa/main/api_arrayelt.c b/src/mesa/main/api_arrayelt.c
> > index d46c8d14b68..62f1e73ca4c 100644
> > --- a/src/mesa/main/api_arrayelt.c
> > +++ b/src/mesa/main/api_arrayelt.c
> > @@ -1541,32 +1541,76 @@ _ae_update_state(struct gl_context *ctx)
> >   }
> > 
> > 
> > +static inline attrib_func
> > +func_nv(const struct gl_vertex_format *vformat)
> > +{
> > +   return AttribFuncsNV[vformat->Normalized][vformat->Size-1]
> > +  [TYPE_IDX(vformat->Type)];
> > +}
> > +
> > +
> > +static inline attrib_func
> > +func_arb(const struct gl_vertex_format *vformat)
> > +{
> > +   return AttribFuncsARB[NORM_IDX(vformat)][vformat->Size-1]
> > +  [TYPE_IDX(vformat->Type)];
> > +}
> > +
> > +
> > +static inline const void *
> > +attrib_src(const struct gl_vertex_array_object *vao,
> > +   const struct gl_array_attributes *array, GLint elt)
> > +{
> > +   const struct gl_vertex_buffer_binding *binding =
> > +  &vao->BufferBinding[array->BufferBindingIndex];
> > +   const GLubyte *src
> > +  = ADD_POINTERS(binding->BufferObj->Mappings[MAP_INTERNAL].Pointer,
> > + _mesa_vertex_attrib_address(array, binding))
> > +  + elt * binding->Stride;
> > +   return src;
> > +}
> 
> Could you add some brief comments on those functions to explain what 
> they do?

Added brief comments:

/*
 * Return VertexAttrib*NV function pointer matching the provided vertex format.
 */
static inline attrib_func
func_nv(const struct gl_vertex_format *vformat)

[...]

/*
 * Return VertexAttrib*ARB function pointer matching the provided vertex format.
 */
static inline attrib_func
func_arb(const struct gl_vertex_format *vformat)

[...]

/*
 * Return the address of the array attribute array at elt in the
 * vertex array object vao.
 */
static inline const void *
attrib_src(const struct gl_vertex_array_object *vao,
   const struct gl_array_attributes *array, GLint elt)


> Otherwise, for the rest of the series,
> Reviewed-by: Brian Paul 
> 
> Nice work!!

Thanks for looking at the patches!

best

Mathias


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

Re: [Mesa-dev] [PATCH 02/10] mesa: Use glVertexAttrib*NV functions for fixed function attribs.

[Mathias Fröhlich]

On Friday, 3 May 2019 00:17:45 CEST Brian Paul wrote:
> On 05/02/2019 03:27 AM, mathias.froehl...@gmx.net wrote:
> > From: Mathias Fröhlich 
> > 
> > In the glArrayElement implementation, use glVertexAttrib*NV type
> > functions for fixed function attributes. We do the same in display
> > execution when the list is replayed using immediate mode attribute
> > functions. By that use a loop to walk the attributes.
> 
> I'm not sure I understand that last sentence.

So, how about:

mesa: Use glVertexAttrib*NV functions for fixed function attribs.

In the glArrayElement implementation, use glVertexAttrib*NV type
functions for fixed function attributes. We do the same in display
execution when the list is replayed using immediate mode attribute
functions. Using a single set of function pointers enables to
use a unified loop to walk the vertex array attributes.

best and Thanks!

Mathias

> 
> The code looks fine.
> 
> Reviewed-by: Brian Paul 
> 
> 
> > 
> > Signed-off-by: Mathias Fröhlich 
> > ---
> >   src/mesa/main/api_arrayelt.c | 185 ++-
> >   1 file changed, 28 insertions(+), 157 deletions(-)
> > 
> > diff --git a/src/mesa/main/api_arrayelt.c b/src/mesa/main/api_arrayelt.c
> > index 3f16e18b44d..d46c8d14b68 100644
> > --- a/src/mesa/main/api_arrayelt.c
> > +++ b/src/mesa/main/api_arrayelt.c
> > @@ -117,89 +117,6 @@ _ae_is_state_dirty(struct gl_context *ctx)
> >   #define NUM_TYPES 8
> > 
> > 
> > -static const int ColorFuncs[2][NUM_TYPES] = {
> > -   {
> > -  _gloffset_Color3bv,
> > -  _gloffset_Color3ubv,
> > -  _gloffset_Color3sv,
> > -  _gloffset_Color3usv,
> > -  _gloffset_Color3iv,
> > -  _gloffset_Color3uiv,
> > -  _gloffset_Color3fv,
> > -  _gloffset_Color3dv,
> > -   },
> > -   {
> > -  _gloffset_Color4bv,
> > -  _gloffset_Color4ubv,
> > -  _gloffset_Color4sv,
> > -  _gloffset_Color4usv,
> > -  _gloffset_Color4iv,
> > -  _gloffset_Color4uiv,
> > -  _gloffset_Color4fv,
> > -  _gloffset_Color4dv,
> > -   },
> > -};
> > -
> > -static const int VertexFuncs[3][NUM_TYPES] = {
> > -   {
> > -  -1,
> > -  -1,
> > -  _gloffset_Vertex2sv,
> > -  -1,
> > -  _gloffset_Vertex2iv,
> > -  -1,
> > -  _gloffset_Vertex2fv,
> > -  _gloffset_Vertex2dv,
> > -   },
> > -   {
> > -  -1,
> > -  -1,
> > -  _gloffset_Vertex3sv,
> > -  -1,
> > -  _gloffset_Vertex3iv,
> > -  -1,
> > -  _gloffset_Vertex3fv,
> > -  _gloffset_Vertex3dv,
> > -   },
> > -   {
> > -  -1,
> > -  -1,
> > -  _gloffset_Vertex4sv,
> > -  -1,
> > -  _gloffset_Vertex4iv,
> > -  -1,
> > -  _gloffset_Vertex4fv,
> > -  _gloffset_Vertex4dv,
> > -   },
> > -};
> > -
> > -static const int IndexFuncs[NUM_TYPES] = {
> > -   -1,
> > -   _gloffset_Indexubv,
> > -   _gloffset_Indexsv,
> > -   -1,
> > -   _gloffset_Indexiv,
> > -   -1,
> > -   _gloffset_Indexfv,
> > -   _gloffset_Indexdv,
> > -};
> > -
> > -static const int NormalFuncs[NUM_TYPES] = {
> > -   _gloffset_Normal3bv,
> > -   -1,
> > -   _gloffset_Normal3sv,
> > -   -1,
> > -   _gloffset_Normal3iv,
> > -   -1,
> > -   _gloffset_Normal3fv,
> > -   _gloffset_Normal3dv,
> > -};
> > -
> > -/* Note: _gloffset_* for these may not be a compile-time constant. */
> > -static int SecondaryColorFuncs[NUM_TYPES];
> > -static int FogCoordFuncs[NUM_TYPES];
> > -
> > -
> >   /**
> >** GL_NV_vertex_program
> >**/
> > @@ -1508,25 +1425,6 @@ _ae_create_context(struct gl_context *ctx)
> >  if (ctx->aelt_context)
> > return GL_TRUE;
> > 
> > -   /* These _gloffset_* values may not be compile-time constants */
> > -   SecondaryColorFuncs[0] = _gloffset_SecondaryColor3bv;
> > -   SecondaryColorFuncs[1] = _gloffset_SecondaryColor3ubv;
> > -   SecondaryColorFuncs[2] = _gloffset_SecondaryColor3sv;
> > -   SecondaryColorFuncs[3] = _gloffset_SecondaryColor3usv;
> > -   SecondaryColorFuncs[4] = _gloffset_SecondaryColor3iv;
> > -   SecondaryColorFuncs[5] = _gloffset_SecondaryColor3uiv;
> > -   SecondaryColorFuncs[6] = _gloffset_SecondaryColor3fvEXT;
> > -   SecondaryColorFuncs[7] = _gloffset_SecondaryColor3dv;
> > -
> > -   FogCoordFuncs[0] = -1;
> > -   FogCoordFuncs[1] = -1;
> > -   FogCoordFuncs[2] = -1;
> > -   FogCoordFuncs[3] = -1;
> > -   FogCoordFuncs[4] = -1;
> > -   FogCoordFuncs[5] = -1;
> > -   FogCoordFuncs[6] = _gloffset_FogCoordfvEXT;
> > -   FogCoordFuncs[7] = _gloffset_FogCoorddv;
> > -
> >  ctx->aelt_context = calloc(1, sizeof(AEcontext));
> >  if (!ctx->aelt_context)
> > return GL_FALSE;
> > @@ -1562,52 +1460,10 @@ _ae_update_state(struct gl_context *ctx)
> >  struct gl_vertex_array_object *vao = ctx->Array.VAO;
> > 
> >  /* conventional vertex arrays */
> > -   if (vao->Enabled & VERT_BIT_COLOR_INDEX) {
> > -  aa->array = &vao->VertexAttrib[VERT_ATTRIB_COLOR_INDEX];
> > -  aa->binding = &vao->BufferBinding[aa->array->BufferBindingIndex];
> > -  aa->offset = IndexFuncs[

Re: [Mesa-dev] [PATCH 01/10] mesa: Factor out index function that will have multiple use.

[Mathias Fröhlich]

Good Morning,

On Friday, 3 May 2019 00:17:38 CEST Brian Paul wrote:
> On 05/02/2019 03:27 AM, mathias.froehl...@gmx.net wrote:
> > From: Mathias Fröhlich 
> > 
> > For access to glArrayElement methods factor out a function to
> > get the table lookup index for normalized/integer/double access.
> > The function will be used in the next patch at least twice.
> > 
> > Signed-off-by: Mathias Fröhlich 
> > ---
> >   src/mesa/main/api_arrayelt.c | 29 ++---
> >   1 file changed, 18 insertions(+), 11 deletions(-)
> > 
> > diff --git a/src/mesa/main/api_arrayelt.c b/src/mesa/main/api_arrayelt.c
> > index 1c086bbcda4..3f16e18b44d 100644
> > --- a/src/mesa/main/api_arrayelt.c
> > +++ b/src/mesa/main/api_arrayelt.c
> > @@ -90,6 +90,23 @@ TYPE_IDX(GLenum t)
> >   }
> > 
> > 
> > +/*
> > + * Convert normalized/integer/double to the range [0, 3].
> > + */
> > +static inline int
> > +NORM_IDX(const struct gl_vertex_format *vformat)
> 
> Maybe we could find a better name.  How about vertex_format_to_index()?

Sure! Changed that to your suggestion!
Thanks!

best

Mathias

> 
> -Brian
> 
> 
> > +{
> > +   if (vformat->Doubles)
> > +  return 3;
> > +   else if (vformat->Integer)
> > +  return 2;
> > +   else if (vformat->Normalized)
> > +  return 1;
> > +   else
> > +  return 0;
> > +}
> > +
> > +
> >   bool
> >   _ae_is_state_dirty(struct gl_context *ctx)
> >   {
> > @@ -1610,7 +1627,6 @@ _ae_update_state(struct gl_context *ctx)
> > if (vao->Enabled & VERT_BIT_GENERIC(i)) {
> >struct gl_array_attributes *attribArray =
> >   &vao->VertexAttrib[VERT_ATTRIB_GENERIC(i)];
> > - GLint intOrNorm;
> >at->array = attribArray;
> >at->binding = 
> > &vao->BufferBinding[attribArray->BufferBindingIndex];
> >/* Note: we can't grab the _glapi_Dispatch->VertexAttrib1fvNV
> > @@ -1618,16 +1634,7 @@ _ae_update_state(struct gl_context *ctx)
> > * change from one execution of _ae_ArrayElement() to
> > * the next.  Doing so caused UT to break.
> > */
> > - if (at->array->Format.Doubles)
> > -intOrNorm = 3;
> > - else if (at->array->Format.Integer)
> > -intOrNorm = 2;
> > - else if (at->array->Format.Normalized)
> > -intOrNorm = 1;
> > - else
> > -intOrNorm = 0;
> > -
> > - at->func = AttribFuncsARB[intOrNorm]
> > + at->func = AttribFuncsARB[NORM_IDX(&at->array->Format)]
> >   [at->array->Format.Size-1]
> >   [TYPE_IDX(at->array->Format.Type)];
> > 
> > --
> > 2.20.1
> > 
> 
> 




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

[Mesa-dev] [PATCH] util/drirc: add workarounds for bugs in Doom 3: BFG

[Timothy Arceri]

This makes the game playable on radeonsi.

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

Cc: "19.0" "19.1" 
---
 src/util/00-mesa-defaults.conf | 5 +
 1 file changed, 5 insertions(+)

diff --git a/src/util/00-mesa-defaults.conf b/src/util/00-mesa-defaults.conf
index f62315498b2..c704a1756ae 100644
--- a/src/util/00-mesa-defaults.conf
+++ b/src/util/00-mesa-defaults.conf
@@ -111,6 +111,11 @@ TODO: document the other workarounds.
 
 
 
+
+
+
+
+
 
 
 
-- 
2.20.1

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

Re: [Mesa-dev] [PATCH] nir: fix lower vars to ssa for larger vector sizes.

[Jason Ekstrand]

Reviewed-by: Jason Ekstrand 

On Thu, May 2, 2019 at 10:25 PM Dave Airlie  wrote:

> From: Dave Airlie 
>
> This has a couple of hardcoded vec4 limits in it, change them
> to the proper sizing to avoid future issues.
> ---
>  src/compiler/nir/nir_lower_vars_to_ssa.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/src/compiler/nir/nir_lower_vars_to_ssa.c
> b/src/compiler/nir/nir_lower_vars_to_ssa.c
> index 1e7dc8d3579..a5f4ca53cf9 100644
> --- a/src/compiler/nir/nir_lower_vars_to_ssa.c
> +++ b/src/compiler/nir/nir_lower_vars_to_ssa.c
> @@ -534,7 +534,7 @@ rename_variables(struct lower_variables_state *state)
>nir_op_imov);
>  mov->src[0].src = nir_src_for_ssa(
> nir_phi_builder_value_get_block_def(node->pb_value,
> block));
> -for (unsigned i = intrin->num_components; i < 4; i++)
> +for (unsigned i = intrin->num_components; i <
> NIR_MAX_VEC_COMPONENTS; i++)
> mov->src[0].swizzle[i] = 0;
>
>  assert(intrin->dest.is_ssa);
> @@ -584,8 +584,8 @@ rename_variables(struct lower_variables_state *state)
>  * intrin->num_components and value->num_components
>  * may differ.
>  */
> -   unsigned swiz[4];
> -   for (unsigned i = 0; i < 4; i++)
> +   unsigned swiz[NIR_MAX_VEC_COMPONENTS];
> +   for (unsigned i = 0; i < NIR_MAX_VEC_COMPONENTS; i++)
>swiz[i] = i < intrin->num_components ? i : 0;
>
> new_def = nir_swizzle(&b, value, swiz,
> @@ -597,7 +597,7 @@ rename_variables(struct lower_variables_state *state)
>  * written values with the existing contents of unwritten
>  * channels, creating a new SSA value for the whole vector.
>  */
> -   nir_ssa_def *srcs[4];
> +   nir_ssa_def *srcs[NIR_MAX_VEC_COMPONENTS];
> for (unsigned i = 0; i < intrin->num_components; i++) {
>if (wrmask & (1 << i)) {
>   srcs[i] = nir_channel(&b, value, i);
> --
> 2.21.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] spirv: fix SpvOpBitSize return value.

[Jason Ekstrand]

Drp...

Reviewed-by: Jason Ekstrand 

On Thu, May 2, 2019 at 10:25 PM Dave Airlie  wrote:

> From: Dave Airlie 
>
> The spir-v spec says this returns a bool.
> ---
>  src/compiler/spirv/vtn_alu.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/src/compiler/spirv/vtn_alu.c b/src/compiler/spirv/vtn_alu.c
> index d8ffc18d495..6d4347887cd 100644
> --- a/src/compiler/spirv/vtn_alu.c
> +++ b/src/compiler/spirv/vtn_alu.c
> @@ -646,9 +646,7 @@ vtn_handle_alu(struct vtn_builder *b, SpvOp opcode,
>   val->ssa->def =
>  nir_ishr(&b->nb, src[0], nir_imm_int(&b->nb, src_bit_size -
> 1));
>
> -  if (src_bit_size != 32)
> - val->ssa->def = nir_u2u32(&b->nb, val->ssa->def);
> -
> +  val->ssa->def = nir_i2b(&b->nb, val->ssa->def);
>break;
> }
>
> --
> 2.21.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] nir: fix lower vars to ssa for larger vector sizes.

[Dave Airlie]

From: Dave Airlie 

This has a couple of hardcoded vec4 limits in it, change them
to the proper sizing to avoid future issues.
---
 src/compiler/nir/nir_lower_vars_to_ssa.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/compiler/nir/nir_lower_vars_to_ssa.c 
b/src/compiler/nir/nir_lower_vars_to_ssa.c
index 1e7dc8d3579..a5f4ca53cf9 100644
--- a/src/compiler/nir/nir_lower_vars_to_ssa.c
+++ b/src/compiler/nir/nir_lower_vars_to_ssa.c
@@ -534,7 +534,7 @@ rename_variables(struct lower_variables_state *state)
   nir_op_imov);
 mov->src[0].src = nir_src_for_ssa(
nir_phi_builder_value_get_block_def(node->pb_value, block));
-for (unsigned i = intrin->num_components; i < 4; i++)
+for (unsigned i = intrin->num_components; i < 
NIR_MAX_VEC_COMPONENTS; i++)
mov->src[0].swizzle[i] = 0;
 
 assert(intrin->dest.is_ssa);
@@ -584,8 +584,8 @@ rename_variables(struct lower_variables_state *state)
 * intrin->num_components and value->num_components
 * may differ.
 */
-   unsigned swiz[4];
-   for (unsigned i = 0; i < 4; i++)
+   unsigned swiz[NIR_MAX_VEC_COMPONENTS];
+   for (unsigned i = 0; i < NIR_MAX_VEC_COMPONENTS; i++)
   swiz[i] = i < intrin->num_components ? i : 0;
 
new_def = nir_swizzle(&b, value, swiz,
@@ -597,7 +597,7 @@ rename_variables(struct lower_variables_state *state)
 * written values with the existing contents of unwritten
 * channels, creating a new SSA value for the whole vector.
 */
-   nir_ssa_def *srcs[4];
+   nir_ssa_def *srcs[NIR_MAX_VEC_COMPONENTS];
for (unsigned i = 0; i < intrin->num_components; i++) {
   if (wrmask & (1 << i)) {
  srcs[i] = nir_channel(&b, value, i);
-- 
2.21.0

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

[Mesa-dev] [PATCH] spirv: fix SpvOpBitSize return value.

[Dave Airlie]

From: Dave Airlie 

The spir-v spec says this returns a bool.
---
 src/compiler/spirv/vtn_alu.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/src/compiler/spirv/vtn_alu.c b/src/compiler/spirv/vtn_alu.c
index d8ffc18d495..6d4347887cd 100644
--- a/src/compiler/spirv/vtn_alu.c
+++ b/src/compiler/spirv/vtn_alu.c
@@ -646,9 +646,7 @@ vtn_handle_alu(struct vtn_builder *b, SpvOp opcode,
  val->ssa->def =
 nir_ishr(&b->nb, src[0], nir_imm_int(&b->nb, src_bit_size - 1));
 
-  if (src_bit_size != 32)
- val->ssa->def = nir_u2u32(&b->nb, val->ssa->def);
-
+  val->ssa->def = nir_i2b(&b->nb, val->ssa->def);
   break;
}
 
-- 
2.21.0

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

[Mesa-dev] [Bug 110590] [Regression][Bisected] GTAⅣ under wine fails with GLXBadFBConfig

[bugzilla-daemon]

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

Hi-Angel  changed:

   What|Removed |Added

 CC||zegen...@protonmail.com

-- 
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 110590] [Regression][Bisected] GTAⅣ under wine fails with GLXBadFBConfig

[bugzilla-daemon]

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

Bug ID: 110590
   Summary: [Regression][Bisected] GTAⅣ under wine fails with
GLXBadFBConfig
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: GLX
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: hi-an...@yandex.ru
QA Contact: mesa-dev@lists.freedesktop.org

When running `wine LaunchGTAIV.exe` with latest mesa, it blinks once, and then
disappears with:

X Error of failed request:  GLXBadFBConfig
Major opcode of failed request:  153 (GLX)
Minor opcode of failed request:  34 ()
Serial number of failed request:  325
Current serial number in output stream:  330

Bisection got me to the commit below. Reverting it locally fixes the problem.

commit e91ee763c378d03883eb88cf0eadd8aa916f7878
Author: Hal Gentz 
Date:   Sun Mar 24 16:52:39 2019 -0600

glx: Fix synthetic error generation in __glXSendError

To quote Uli Schlachter, who understands this stuff more than I do:

>   The function __glXSendError() in mesa's src/glx/glx_error.c invents
an X11
> protocol error out of thin air. For the sequence number it uses
dpy->request.
> This is the sequence number of the last request that was sent.
_XError() will
> then update dpy->last_request_read based on the sequence number of
the error
> that just "came in".
>
>   If now another something comes in with a sequence number less than
> dpy->last_request_read, since sequence numbers are monotonically
increasing,
> widen() will incorrectly add 1<<32 to the sequence number and things
might go
> downhill afterwards.

`__glXSendErrorForXcb` was also patched, as that's the function that
`glXCreateContextAttribsARB` actually uses.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99781
Cc: mesa-sta...@lists.freedesktop.org
Fixes: ad503c41 'apple: Initial import of libGL for OSX from AppleSGLX
svn repository'
Reviewed-by: Adam Jackson 
Reviewed-by: Ian Romanick 
Signed-off-by: Hal Gentz 

Note: I couldn't reproduce it with other games with or without wine, but I only
have a few of them though.

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

Re: [Mesa-dev] [PATCH 03/10] mesa: Implement _mesa_array_element by walking enabled arrays.

[Brian Paul]

On 05/02/2019 03:27 AM, mathias.froehl...@gmx.net wrote:

From: Mathias Fröhlich 

In glArrayElement, use the bitmask trick to just walk the enabled
vao arrays. This should be about equivalent in execution time to
walk the prepare aelt_context list. Finally this will allow us to
reduce the _mesa_update_state calls in a few patches.

Signed-off-by: Mathias Fröhlich 
---
  src/mesa/main/api_arrayelt.c | 78 
  1 file changed, 61 insertions(+), 17 deletions(-)

diff --git a/src/mesa/main/api_arrayelt.c b/src/mesa/main/api_arrayelt.c
index d46c8d14b68..62f1e73ca4c 100644
--- a/src/mesa/main/api_arrayelt.c
+++ b/src/mesa/main/api_arrayelt.c
@@ -1541,32 +1541,76 @@ _ae_update_state(struct gl_context *ctx)
  }


+static inline attrib_func
+func_nv(const struct gl_vertex_format *vformat)
+{
+   return AttribFuncsNV[vformat->Normalized][vformat->Size-1]
+  [TYPE_IDX(vformat->Type)];
+}
+
+
+static inline attrib_func
+func_arb(const struct gl_vertex_format *vformat)
+{
+   return AttribFuncsARB[NORM_IDX(vformat)][vformat->Size-1]
+  [TYPE_IDX(vformat->Type)];
+}
+
+
+static inline const void *
+attrib_src(const struct gl_vertex_array_object *vao,
+   const struct gl_array_attributes *array, GLint elt)
+{
+   const struct gl_vertex_buffer_binding *binding =
+  &vao->BufferBinding[array->BufferBindingIndex];
+   const GLubyte *src
+  = ADD_POINTERS(binding->BufferObj->Mappings[MAP_INTERNAL].Pointer,
+ _mesa_vertex_attrib_address(array, binding))
+  + elt * binding->Stride;
+   return src;
+}


Could you add some brief comments on those functions to explain what 
they do?


Otherwise, for the rest of the series,
Reviewed-by: Brian Paul 

Nice work!!

-Brian



+
+
  void
  _mesa_array_element(struct gl_context *ctx,
  struct _glapi_table *disp, GLint elt)
  {
-   const AEcontext *actx = AE_CONTEXT(ctx);
+   const struct gl_vertex_array_object *vao = ctx->Array.VAO;
+   GLbitfield mask;

-   if (actx->dirty_state)
-  _ae_update_state(ctx);
+   /* emit conventional arrays elements */
+   mask = (VERT_BIT_FF_ALL & ~VERT_BIT_POS) & vao->Enabled;
+   while (mask) {
+  const gl_vert_attrib attrib = u_bit_scan(&mask);
+  const struct gl_array_attributes *array = &vao->VertexAttrib[attrib];
+  const void *src = attrib_src(vao, array, elt);
+  func_nv(&array->Format)(attrib, src);
+   }

 /* emit generic attribute elements */
-   for (const AEattrib *at = actx->attribs; at->func; at++) {
-  const GLubyte *src
- = ADD_POINTERS(at->binding->BufferObj->Mappings[MAP_INTERNAL].Pointer,
-_mesa_vertex_attrib_address(at->array, at->binding))
- + elt * at->binding->Stride;
-  at->func(at->index, src);
+   mask = (VERT_BIT_GENERIC_ALL & ~VERT_BIT_GENERIC0) & vao->Enabled;
+   while (mask) {
+  const gl_vert_attrib attrib = u_bit_scan(&mask);
+  const struct gl_array_attributes *array = &vao->VertexAttrib[attrib];
+  const void *src = attrib_src(vao, array, elt);
+  func_arb(&array->Format)(attrib - VERT_ATTRIB_GENERIC0, src);
 }

-   /* emit conventional arrays elements */
-   for (const AEarray *aa = actx->arrays; aa->offset != -1 ; aa++) {
-  const GLubyte *src
- = ADD_POINTERS(aa->binding->BufferObj->Mappings[MAP_INTERNAL].Pointer,
-_mesa_vertex_attrib_address(aa->array, aa->binding))
- + elt * aa->binding->Stride;
-  CALL_by_offset(disp, (array_func), aa->offset, ((const void *) src));
-   }
+   /* finally, vertex position */
+   if (vao->Enabled & VERT_BIT_GENERIC0) {
+  const gl_vert_attrib attrib = VERT_ATTRIB_GENERIC0;
+  const struct gl_array_attributes *array = &vao->VertexAttrib[attrib];
+  const void *src = attrib_src(vao, array, elt);
+  /* Use glVertex(v) instead of glVertexAttrib(0, v) to be sure it's
+   * issued as the last (provoking) attribute).
+   */
+  func_nv(&array->Format)(0, src);
+   } else if (vao->Enabled & VERT_BIT_POS) {
+  const gl_vert_attrib attrib = VERT_ATTRIB_POS;
+  const struct gl_array_attributes *array = &vao->VertexAttrib[attrib];
+  const void *src = attrib_src(vao, array, elt);
+  func_nv(&array->Format)(0, src);
+}
  }


--
2.20.1



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

Re: [Mesa-dev] [PATCH 01/10] mesa: Factor out index function that will have multiple use.

[Brian Paul]

On 05/02/2019 03:27 AM, mathias.froehl...@gmx.net wrote:

From: Mathias Fröhlich 

For access to glArrayElement methods factor out a function to
get the table lookup index for normalized/integer/double access.
The function will be used in the next patch at least twice.

Signed-off-by: Mathias Fröhlich 
---
  src/mesa/main/api_arrayelt.c | 29 ++---
  1 file changed, 18 insertions(+), 11 deletions(-)

diff --git a/src/mesa/main/api_arrayelt.c b/src/mesa/main/api_arrayelt.c
index 1c086bbcda4..3f16e18b44d 100644
--- a/src/mesa/main/api_arrayelt.c
+++ b/src/mesa/main/api_arrayelt.c
@@ -90,6 +90,23 @@ TYPE_IDX(GLenum t)
  }


+/*
+ * Convert normalized/integer/double to the range [0, 3].
+ */
+static inline int
+NORM_IDX(const struct gl_vertex_format *vformat)


Maybe we could find a better name.  How about vertex_format_to_index()?

-Brian



+{
+   if (vformat->Doubles)
+  return 3;
+   else if (vformat->Integer)
+  return 2;
+   else if (vformat->Normalized)
+  return 1;
+   else
+  return 0;
+}
+
+
  bool
  _ae_is_state_dirty(struct gl_context *ctx)
  {
@@ -1610,7 +1627,6 @@ _ae_update_state(struct gl_context *ctx)
if (vao->Enabled & VERT_BIT_GENERIC(i)) {
   struct gl_array_attributes *attribArray =
  &vao->VertexAttrib[VERT_ATTRIB_GENERIC(i)];
- GLint intOrNorm;
   at->array = attribArray;
   at->binding = &vao->BufferBinding[attribArray->BufferBindingIndex];
   /* Note: we can't grab the _glapi_Dispatch->VertexAttrib1fvNV
@@ -1618,16 +1634,7 @@ _ae_update_state(struct gl_context *ctx)
* change from one execution of _ae_ArrayElement() to
* the next.  Doing so caused UT to break.
*/
- if (at->array->Format.Doubles)
-intOrNorm = 3;
- else if (at->array->Format.Integer)
-intOrNorm = 2;
- else if (at->array->Format.Normalized)
-intOrNorm = 1;
- else
-intOrNorm = 0;
-
- at->func = AttribFuncsARB[intOrNorm]
+ at->func = AttribFuncsARB[NORM_IDX(&at->array->Format)]
  [at->array->Format.Size-1]
  [TYPE_IDX(at->array->Format.Type)];

--
2.20.1



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

Re: [Mesa-dev] [PATCH 02/10] mesa: Use glVertexAttrib*NV functions for fixed function attribs.

[Brian Paul]

On 05/02/2019 03:27 AM, mathias.froehl...@gmx.net wrote:

From: Mathias Fröhlich 

In the glArrayElement implementation, use glVertexAttrib*NV type
functions for fixed function attributes. We do the same in display
execution when the list is replayed using immediate mode attribute
functions. By that use a loop to walk the attributes.


I'm not sure I understand that last sentence.

The code looks fine.

Reviewed-by: Brian Paul 




Signed-off-by: Mathias Fröhlich 
---
  src/mesa/main/api_arrayelt.c | 185 ++-
  1 file changed, 28 insertions(+), 157 deletions(-)

diff --git a/src/mesa/main/api_arrayelt.c b/src/mesa/main/api_arrayelt.c
index 3f16e18b44d..d46c8d14b68 100644
--- a/src/mesa/main/api_arrayelt.c
+++ b/src/mesa/main/api_arrayelt.c
@@ -117,89 +117,6 @@ _ae_is_state_dirty(struct gl_context *ctx)
  #define NUM_TYPES 8


-static const int ColorFuncs[2][NUM_TYPES] = {
-   {
-  _gloffset_Color3bv,
-  _gloffset_Color3ubv,
-  _gloffset_Color3sv,
-  _gloffset_Color3usv,
-  _gloffset_Color3iv,
-  _gloffset_Color3uiv,
-  _gloffset_Color3fv,
-  _gloffset_Color3dv,
-   },
-   {
-  _gloffset_Color4bv,
-  _gloffset_Color4ubv,
-  _gloffset_Color4sv,
-  _gloffset_Color4usv,
-  _gloffset_Color4iv,
-  _gloffset_Color4uiv,
-  _gloffset_Color4fv,
-  _gloffset_Color4dv,
-   },
-};
-
-static const int VertexFuncs[3][NUM_TYPES] = {
-   {
-  -1,
-  -1,
-  _gloffset_Vertex2sv,
-  -1,
-  _gloffset_Vertex2iv,
-  -1,
-  _gloffset_Vertex2fv,
-  _gloffset_Vertex2dv,
-   },
-   {
-  -1,
-  -1,
-  _gloffset_Vertex3sv,
-  -1,
-  _gloffset_Vertex3iv,
-  -1,
-  _gloffset_Vertex3fv,
-  _gloffset_Vertex3dv,
-   },
-   {
-  -1,
-  -1,
-  _gloffset_Vertex4sv,
-  -1,
-  _gloffset_Vertex4iv,
-  -1,
-  _gloffset_Vertex4fv,
-  _gloffset_Vertex4dv,
-   },
-};
-
-static const int IndexFuncs[NUM_TYPES] = {
-   -1,
-   _gloffset_Indexubv,
-   _gloffset_Indexsv,
-   -1,
-   _gloffset_Indexiv,
-   -1,
-   _gloffset_Indexfv,
-   _gloffset_Indexdv,
-};
-
-static const int NormalFuncs[NUM_TYPES] = {
-   _gloffset_Normal3bv,
-   -1,
-   _gloffset_Normal3sv,
-   -1,
-   _gloffset_Normal3iv,
-   -1,
-   _gloffset_Normal3fv,
-   _gloffset_Normal3dv,
-};
-
-/* Note: _gloffset_* for these may not be a compile-time constant. */
-static int SecondaryColorFuncs[NUM_TYPES];
-static int FogCoordFuncs[NUM_TYPES];
-
-
  /**
   ** GL_NV_vertex_program
   **/
@@ -1508,25 +1425,6 @@ _ae_create_context(struct gl_context *ctx)
 if (ctx->aelt_context)
return GL_TRUE;

-   /* These _gloffset_* values may not be compile-time constants */
-   SecondaryColorFuncs[0] = _gloffset_SecondaryColor3bv;
-   SecondaryColorFuncs[1] = _gloffset_SecondaryColor3ubv;
-   SecondaryColorFuncs[2] = _gloffset_SecondaryColor3sv;
-   SecondaryColorFuncs[3] = _gloffset_SecondaryColor3usv;
-   SecondaryColorFuncs[4] = _gloffset_SecondaryColor3iv;
-   SecondaryColorFuncs[5] = _gloffset_SecondaryColor3uiv;
-   SecondaryColorFuncs[6] = _gloffset_SecondaryColor3fvEXT;
-   SecondaryColorFuncs[7] = _gloffset_SecondaryColor3dv;
-
-   FogCoordFuncs[0] = -1;
-   FogCoordFuncs[1] = -1;
-   FogCoordFuncs[2] = -1;
-   FogCoordFuncs[3] = -1;
-   FogCoordFuncs[4] = -1;
-   FogCoordFuncs[5] = -1;
-   FogCoordFuncs[6] = _gloffset_FogCoordfvEXT;
-   FogCoordFuncs[7] = _gloffset_FogCoorddv;
-
 ctx->aelt_context = calloc(1, sizeof(AEcontext));
 if (!ctx->aelt_context)
return GL_FALSE;
@@ -1562,52 +1460,10 @@ _ae_update_state(struct gl_context *ctx)
 struct gl_vertex_array_object *vao = ctx->Array.VAO;

 /* conventional vertex arrays */
-   if (vao->Enabled & VERT_BIT_COLOR_INDEX) {
-  aa->array = &vao->VertexAttrib[VERT_ATTRIB_COLOR_INDEX];
-  aa->binding = &vao->BufferBinding[aa->array->BufferBindingIndex];
-  aa->offset = IndexFuncs[TYPE_IDX(aa->array->Format.Type)];
-  aa++;
-   }
-
-   if (vao->Enabled & VERT_BIT_EDGEFLAG) {
-  aa->array = &vao->VertexAttrib[VERT_ATTRIB_EDGEFLAG];
-  aa->binding = &vao->BufferBinding[aa->array->BufferBindingIndex];
-  aa->offset = _gloffset_EdgeFlagv;
-  aa++;
-   }
-
-   if (vao->Enabled & VERT_BIT_NORMAL) {
-  aa->array = &vao->VertexAttrib[VERT_ATTRIB_NORMAL];
-  aa->binding = &vao->BufferBinding[aa->array->BufferBindingIndex];
-  aa->offset = NormalFuncs[TYPE_IDX(aa->array->Format.Type)];
-  aa++;
-   }
-
-   if (vao->Enabled & VERT_BIT_COLOR0) {
-  aa->array = &vao->VertexAttrib[VERT_ATTRIB_COLOR0];
-  aa->binding = &vao->BufferBinding[aa->array->BufferBindingIndex];
-  aa->offset = 
ColorFuncs[aa->array->Format.Size-3][TYPE_IDX(aa->array->Format.Type)];
-  aa++;
-   }
-
-   if (vao->Enabled & VERT_BIT_COLOR1) {
-  aa->array = &vao->VertexAttrib[VERT_ATTRIB_COLOR1];
-  aa->binding = &vao->BufferBinding[aa->array->BufferBindingIndex];
-  aa->offset = SecondaryColorFuncs[T

Re: [Mesa-dev] [PATCH] nir/algebraic: Don't emit empty initializers for MSVC

[Brian Paul]

On 05/02/2019 02:34 PM, Connor Abbott wrote:

Just don't emit the transform array at all if there are no transforms
for a state, and avoid trying to walk over it.
---
Brian, does this build on Windows? I tested it on my shader-db
on radeonsi.


Yes, it compiles.  Thanks!

Tested-by: Brian Paul 

Though it looks like Dylan had some suggestions.

-Brian



---
  src/compiler/nir/nir_algebraic.py | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/src/compiler/nir/nir_algebraic.py 
b/src/compiler/nir/nir_algebraic.py
index 6db749e9248..7af80a4f92e 100644
--- a/src/compiler/nir/nir_algebraic.py
+++ b/src/compiler/nir/nir_algebraic.py
@@ -993,11 +993,13 @@ static const uint16_t CONST_STATE = 1;
  % endfor
  
  % for state_id, state_xforms in enumerate(automaton.state_patterns):

+% if len(state_xforms) > 0: # avoid emitting a 0-length array for MSVC
  static const struct transform ${pass_name}_state${state_id}_xforms[] = {
  % for i in state_xforms:
{ ${xforms[i].search.c_ptr(cache)}, 
${xforms[i].replace.c_value_ptr(cache)}, ${xforms[i].condition_index} },
  % endfor
  };
+% endif
  % endfor
  
  static const struct per_op_table ${pass_name}_table[nir_num_search_ops] = {

@@ -1080,7 +1082,8 @@ ${pass_name}_block(nir_builder *build, nir_block *block,
switch (states[alu->dest.dest.ssa.index]) {
  % for i in range(len(automaton.state_patterns)):
case ${i}:
- for (unsigned i = 0; i < ARRAY_SIZE(${pass_name}_state${i}_xforms); 
i++) {
+ % if len(automaton.state_patterns[i]) > 0:
+ for (unsigned i = 0; i < ${len(automaton.state_patterns[i])}; i++) {
  const struct transform *xform = &${pass_name}_state${i}_xforms[i];
  if (condition_flags[xform->condition_offset] &&
  nir_replace_instr(build, alu, xform->search, xform->replace)) 
{
@@ -1088,6 +1091,7 @@ ${pass_name}_block(nir_builder *build, nir_block *block,
 break;
  }
   }
+ % endif
   break;
  % endfor
default: assert(0);



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

[Mesa-dev] [Bug 110540] [AMD TAHITI XT] valve artifact broken

[bugzilla-daemon]

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

--- Comment #11 from Sylvain BERTRAND  ---
I did report the regression ages ago: since there is a year in time lag, could
be anywhere, even in linux drm or worse, in llvm:
https://bugs.freedesktop.org/show_bug.cgi?id=110540

-- 
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 110540] [AMD TAHITI XT] valve artifact broken

[bugzilla-daemon]

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

--- Comment #10 from Samuel Pitoiset  ---
Okay thanks!
Can you fill a new bug report for RoTR?

-- 
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 110540] [AMD TAHITI XT] valve artifact broken

[bugzilla-daemon]

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

--- Comment #9 from Sylvain BERTRAND  ---
sorry, it fixed valve artifact only

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

[Mesa-dev] [Bug 110540] [AMD TAHITI XT] valve artifact broken

[bugzilla-daemon]

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

--- Comment #8 from Samuel Pitoiset  ---
It fixed what? The original report or/and Rise Of The Tomb Raider as well?

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

[Mesa-dev] [Bug 110540] [AMD TAHITI XT] valve artifact broken

[bugzilla-daemon]

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

--- Comment #7 from Sylvain BERTRAND  ---
yep, this patch fixed it

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

Re: [Mesa-dev] [PATCH] nir/algebraic: Don't emit empty initializers for MSVC

[Dylan Baker]

Quoting Connor Abbott (2019-05-02 13:34:07)
> Just don't emit the transform array at all if there are no transforms
> for a state, and avoid trying to walk over it.
> ---
> Brian, does this build on Windows? I tested it on my shader-db
> on radeonsi.
> 
> ---
>  src/compiler/nir/nir_algebraic.py | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/src/compiler/nir/nir_algebraic.py 
> b/src/compiler/nir/nir_algebraic.py
> index 6db749e9248..7af80a4f92e 100644
> --- a/src/compiler/nir/nir_algebraic.py
> +++ b/src/compiler/nir/nir_algebraic.py
> @@ -993,11 +993,13 @@ static const uint16_t CONST_STATE = 1;
>  % endfor
>  
>  % for state_id, state_xforms in enumerate(automaton.state_patterns):
> +% if len(state_xforms) > 0: # avoid emitting a 0-length array for MSVC

if not state_xforms:

Using len() to test container emptiness is an anti-pattern in python, is is
roughly 10x slower  than this.

>  static const struct transform ${pass_name}_state${state_id}_xforms[] = {
>  % for i in state_xforms:
>{ ${xforms[i].search.c_ptr(cache)}, 
> ${xforms[i].replace.c_value_ptr(cache)}, ${xforms[i].condition_index} },
>  % endfor
>  };
> +% endif
>  % endfor
>  
>  static const struct per_op_table ${pass_name}_table[nir_num_search_ops] = {
> @@ -1080,7 +1082,8 @@ ${pass_name}_block(nir_builder *build, nir_block *block,
>switch (states[alu->dest.dest.ssa.index]) {
>  % for i in range(len(automaton.state_patterns)):
>case ${i}:
> - for (unsigned i = 0; i < ARRAY_SIZE(${pass_name}_state${i}_xforms); 
> i++) {
> + % if len(automaton.state_patterns[i]) > 0:

same here

Dylan

> + for (unsigned i = 0; i < ${len(automaton.state_patterns[i])}; i++) {
>  const struct transform *xform = 
> &${pass_name}_state${i}_xforms[i];
>  if (condition_flags[xform->condition_offset] &&
>  nir_replace_instr(build, alu, xform->search, 
> xform->replace)) {
> @@ -1088,6 +1091,7 @@ ${pass_name}_block(nir_builder *build, nir_block *block,
> break;
>  }
>   }
> + % endif
>   break;
>  % endfor
>default: assert(0);
> -- 
> 2.17.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

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

[AppVeyor]

Build mesa 11007 failed


Commit 1291c68c9c by Eric Engestrom on 4/16/2019 4:06 PM:

gitlab-ci: merge meson-glvnd into meson-swr\n\nThere's no need to have a whole build just for that flag, we can add it\nto any build.\n\nv2: Add a note about why we put glvnd where we did (by anholt).\n\nSigned-off-by: Eric Engestrom \nReviewed-by: Eric Anholt \nReviewed-by: Michel Dänzer \nReviewed-by: Eric Engestrom  (v2)\nAcked-by: Dylan Baker 


Configure your notification preferences

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

[Mesa-dev] [PATCH] nir/algebraic: Don't emit empty initializers for MSVC

[Connor Abbott]

Just don't emit the transform array at all if there are no transforms
for a state, and avoid trying to walk over it.
---
Brian, does this build on Windows? I tested it on my shader-db
on radeonsi.

---
 src/compiler/nir/nir_algebraic.py | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/src/compiler/nir/nir_algebraic.py 
b/src/compiler/nir/nir_algebraic.py
index 6db749e9248..7af80a4f92e 100644
--- a/src/compiler/nir/nir_algebraic.py
+++ b/src/compiler/nir/nir_algebraic.py
@@ -993,11 +993,13 @@ static const uint16_t CONST_STATE = 1;
 % endfor
 
 % for state_id, state_xforms in enumerate(automaton.state_patterns):
+% if len(state_xforms) > 0: # avoid emitting a 0-length array for MSVC
 static const struct transform ${pass_name}_state${state_id}_xforms[] = {
 % for i in state_xforms:
   { ${xforms[i].search.c_ptr(cache)}, ${xforms[i].replace.c_value_ptr(cache)}, 
${xforms[i].condition_index} },
 % endfor
 };
+% endif
 % endfor
 
 static const struct per_op_table ${pass_name}_table[nir_num_search_ops] = {
@@ -1080,7 +1082,8 @@ ${pass_name}_block(nir_builder *build, nir_block *block,
   switch (states[alu->dest.dest.ssa.index]) {
 % for i in range(len(automaton.state_patterns)):
   case ${i}:
- for (unsigned i = 0; i < ARRAY_SIZE(${pass_name}_state${i}_xforms); 
i++) {
+ % if len(automaton.state_patterns[i]) > 0:
+ for (unsigned i = 0; i < ${len(automaton.state_patterns[i])}; i++) {
 const struct transform *xform = &${pass_name}_state${i}_xforms[i];
 if (condition_flags[xform->condition_offset] &&
 nir_replace_instr(build, alu, xform->search, xform->replace)) {
@@ -1088,6 +1091,7 @@ ${pass_name}_block(nir_builder *build, nir_block *block,
break;
 }
  }
+ % endif
  break;
 % endfor
   default: assert(0);
-- 
2.17.2

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

Re: [Mesa-dev] [PATCH] nir: don't emit empty initializers for MSVC

[Brian Paul]

On 05/02/2019 01:35 PM, Connor Abbott wrote:
This will crash at runtime, since it'll construct a "struct transform" 
with all NULL pointers, and then the loop below in ${pass_name}_block() 
will see that there's one transform in the array since it uses 
ARRAY_SIZE and then crash trying to access it.


Hmm, any ideas for how to fix this?

-Brian


Running piglit with i965, or radeonsi will reproduce the crash.

On Thu, May 2, 2019 at 7:52 PM Brian Paul > wrote:


This fixes a build failure with MSVC.

---

I've compiled tested this, but not sure how to runtime test it.
---
  src/compiler/nir/nir_algebraic.py | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/src/compiler/nir/nir_algebraic.py
b/src/compiler/nir/nir_algebraic.py
index 6db749e..dc25421 100644
--- a/src/compiler/nir/nir_algebraic.py
+++ b/src/compiler/nir/nir_algebraic.py
@@ -997,6 +997,9 @@ static const struct transform
${pass_name}_state${state_id}_xforms[] = {
  % for i in state_xforms:
    { ${xforms[i].search.c_ptr(cache)},
${xforms[i].replace.c_value_ptr(cache)}, ${xforms[i].condition_index} },
  % endfor
+% if state_xforms == []: # avoid empty initializers for MSVC
+  0
+% endif
  };
  % endfor

-- 
2.7.4


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





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

[Mesa-dev] [Bug 110540] [AMD TAHITI XT] valve artifact broken

[bugzilla-daemon]

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

--- Comment #6 from Samuel Pitoiset  ---
Actually, can you try with https://patchwork.freedesktop.org/series/60220/ ?

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

[Mesa-dev] [Bug 110540] [AMD TAHITI XT] valve artifact broken

[bugzilla-daemon]

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

--- Comment #5 from Sylvain BERTRAND  ---
no luck, crashing the same way on git c14b13d0ff0d04a2aec239734621fcfa79c629cc

(I also have a nasty regression on "rise of the tomb raider", unfortunately, no
way to reasonably bisect, this has to be debugged)

-- 
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 110573] Mesa vulkan-radeon 19.0.3 system freeze and visual artifacts (RADV)

[bugzilla-daemon]

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

--- Comment #11 from Samuel Pitoiset  ---
What you can do is to try to record a renderdoc capture with 19.0.2 and see if
you can reproduce the problem by replaying it with 19.0.3. You probably need to
be a bit lucky to record the right frame. :)

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

Re: [Mesa-dev] [PATCH] nir: don't emit empty initializers for MSVC

[Connor Abbott]

Whoops, that should be "radeonsi with radeonsi_enable_nir=true" since NIR
isn't enabled by default yet.

On Thu, May 2, 2019 at 9:35 PM Connor Abbott  wrote:

> This will crash at runtime, since it'll construct a "struct transform"
> with all NULL pointers, and then the loop below in ${pass_name}_block()
> will see that there's one transform in the array since it uses ARRAY_SIZE
> and then crash trying to access it.
>
> Running piglit with i965, or radeonsi will reproduce the crash.
>
> On Thu, May 2, 2019 at 7:52 PM Brian Paul  wrote:
>
>> This fixes a build failure with MSVC.
>>
>> ---
>>
>> I've compiled tested this, but not sure how to runtime test it.
>> ---
>>  src/compiler/nir/nir_algebraic.py | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/src/compiler/nir/nir_algebraic.py
>> b/src/compiler/nir/nir_algebraic.py
>> index 6db749e..dc25421 100644
>> --- a/src/compiler/nir/nir_algebraic.py
>> +++ b/src/compiler/nir/nir_algebraic.py
>> @@ -997,6 +997,9 @@ static const struct transform
>> ${pass_name}_state${state_id}_xforms[] = {
>>  % for i in state_xforms:
>>{ ${xforms[i].search.c_ptr(cache)},
>> ${xforms[i].replace.c_value_ptr(cache)}, ${xforms[i].condition_index} },
>>  % endfor
>> +% if state_xforms == []: # avoid empty initializers for MSVC
>> +  0
>> +% endif
>>  };
>>  % endfor
>>
>> --
>> 2.7.4
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] nir: don't emit empty initializers for MSVC

[Connor Abbott]

This will crash at runtime, since it'll construct a "struct transform" with
all NULL pointers, and then the loop below in ${pass_name}_block() will see
that there's one transform in the array since it uses ARRAY_SIZE and then
crash trying to access it.

Running piglit with i965, or radeonsi will reproduce the crash.

On Thu, May 2, 2019 at 7:52 PM Brian Paul  wrote:

> This fixes a build failure with MSVC.
>
> ---
>
> I've compiled tested this, but not sure how to runtime test it.
> ---
>  src/compiler/nir/nir_algebraic.py | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/src/compiler/nir/nir_algebraic.py
> b/src/compiler/nir/nir_algebraic.py
> index 6db749e..dc25421 100644
> --- a/src/compiler/nir/nir_algebraic.py
> +++ b/src/compiler/nir/nir_algebraic.py
> @@ -997,6 +997,9 @@ static const struct transform
> ${pass_name}_state${state_id}_xforms[] = {
>  % for i in state_xforms:
>{ ${xforms[i].search.c_ptr(cache)},
> ${xforms[i].replace.c_value_ptr(cache)}, ${xforms[i].condition_index} },
>  % endfor
> +% if state_xforms == []: # avoid empty initializers for MSVC
> +  0
> +% endif
>  };
>  % endfor
>
> --
> 2.7.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[AppVeyor]

Build mesa 11001 failed


Commit ff4168c418 by Lionel Landwerlin on 2/28/2019 1:02 PM:

vulkan/overlay: add TODO list\n\nKeen on having other people contribute.\n\nSigned-off-by: Lionel Landwerlin \nReviewed-by: Eric Engestrom 


Configure your notification preferences

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

Re: [Mesa-dev] [Mesa-stable] [PATCH 2/5] intel/fs: Lower integer multiply correctly when destination stride equals 4.

[Dylan Baker]

Quoting Francisco Jerez (2019-04-29 16:04:19)
> Francisco Jerez  writes:
> 
> > Because the "low" temporary needs to be accessed with word type and
> > twice the original stride, attempting to preserve the alignment of the
> > original destination can potentially lead to instructions with illegal
> > destination stride greater than four.  Because the CHV/BXT alignment
> > restrictions are now being enforced by the regioning lowering pass run
> > after lower_integer_multiplication(), there is no real need to
> > preserve the original strides anymore.
> >
> > Note that this bug can be reproduced on stable branches, but
> > back-porting would be non-trivial, because the fix relies on the
> > regioning lowering pass recently introduced.
> 
> This and PATCH 3 of this series should have landed with a:
> 
> Cc: 19.0 
> 
> The paragraph above recommending against their inclusion in stable
> branches was referring to the *then* stable branches when the patch was
> written, a couple of weeks before the 19.0 branch point.  Unfortunately
> the series landed after the branchpoint and patches 2 and 3 missed the
> 19.0 branch they were intended for.  Any chance we could get these into
> the next 19.0 stable release?
> 
> Thanks to Tapani for realizing the problem!
> 

I've pulled these into the staging/19.0 branch, they'll be in the release next
week.

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] nir: don't emit empty initializers for MSVC

[Brian Paul]

This fixes a build failure with MSVC.

---

I've compiled tested this, but not sure how to runtime test it.
---
 src/compiler/nir/nir_algebraic.py | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/compiler/nir/nir_algebraic.py 
b/src/compiler/nir/nir_algebraic.py
index 6db749e..dc25421 100644
--- a/src/compiler/nir/nir_algebraic.py
+++ b/src/compiler/nir/nir_algebraic.py
@@ -997,6 +997,9 @@ static const struct transform 
${pass_name}_state${state_id}_xforms[] = {
 % for i in state_xforms:
   { ${xforms[i].search.c_ptr(cache)}, ${xforms[i].replace.c_value_ptr(cache)}, 
${xforms[i].condition_index} },
 % endfor
+% if state_xforms == []: # avoid empty initializers for MSVC
+  0
+% endif
 };
 % endfor
 
-- 
2.7.4

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

[Mesa-dev] [Bug 110291] Vega 64 GPU hang running Space Engineers

[bugzilla-daemon]

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

--- Comment #7 from Peter  ---
I can't reproduce the hang anymore with latest Mesa. Thanks for your help.

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

[Mesa-dev] [Bug 110573] Mesa vulkan-radeon 19.0.3 system freeze and visual artifacts (RADV)

[bugzilla-daemon]

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

--- Comment #10 from ant...@gmx.de ---
Is there any other trace I can provide for debugging purposes?

-- 
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] [AppVeyor] mesa staging/19.0 #11000 completed

[AppVeyor]

Build mesa 11000 completed



Commit b1e4884285 by Samuel Pitoiset on 5/2/2019 12:56 PM:

radv: set WD_SWITCH_ON_EOP=1 when drawing primitives from a stream output buffer\n\nAccording to RadeonSI, this seems to be required by the hardware\nto avoid GPU hangs. I think I just forgot to set that bit when I\nimplemented VK_EXT_transform_feedback.\n\nThis fixes a GPU hang with Space Engineers and DXVK.\n\nBugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110291\nFixes: b4eb029062a ("radv: implement VK_EXT_transform_feedback")\nSigned-off-by: Samuel Pitoiset \nReviewed-by: Bas Nieuwenhuizen \n(cherry picked from commit 08be23bfdec9fb447c58ae48bf9cc1b91ecba128)


Configure your notification preferences

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

Re: [Mesa-dev] [PATCH] docs: link to the meson_options.txt file gitlab.freedesktop.org

[Eric Engestrom]

On Monday, 2019-03-11 19:58:42 -0600, Brian Paul wrote:
> ---
>  docs/meson.html | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/docs/meson.html b/docs/meson.html
> index 09b45be..08e4d1a 100644
> --- a/docs/meson.html
> +++ b/docs/meson.html
> @@ -103,7 +103,8 @@ running "meson build/" but this feature is being 
> discussed upstream.
>  For now, we have a bin/meson-options.py script that prints
>  the options for you.
>  If that script doesn't work for some reason, you can always look in the
> -meson_options.txt file at the root of the project.
> + href="https://gitlab.freedesktop.org/mesa/mesa/blob/master/meson_options.txt";>
> +meson_options.txt file at the root of the project.

Reviewed-by: Eric Engestrom 

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

Re: [Mesa-dev] [PATCH] docs: separate information for compiler selection and compiler options

[Eric Engestrom]

On Monday, 2019-03-11 19:52:47 -0600, Brian Paul wrote:
> Split up the "Environment Variables" section into "Compiler Options"
> and "Compiler Specification".  I think this makes the information
> easier to find and understand.

Reviewed-by: Eric Engestrom 

> ---
>  docs/meson.html | 58 
> ++---
>  1 file changed, 39 insertions(+), 19 deletions(-)
> 
> diff --git a/docs/meson.html b/docs/meson.html
> index 7ffef81..09b45be 100644
> --- a/docs/meson.html
> +++ b/docs/meson.html
> @@ -169,47 +169,67 @@ Developers will often want to install Mesa to a testing 
> directory rather
>  than the system library directory.
>  This can be done with the --prefix option.  For example:
>  
> -
> +
>  meson --prefix="${PWD}/build/install" build/
> -
> +
>  
>  will put the final libraries and drivers into the build/install/
>  directory.
>  Then you can set LD_LIBRARY_PATH and LIBGL_DRIVERS_PATH to that location
>  to run/test the driver.
>  
> +
> +Meson also honors DESTDIR for installs.
> +
>  
>  
> -Environment Variables
> -Meson supports the standard CC and CXX environment variables for
> -changing the default compiler. Meson does support CFLAGS, CXXFLAGS, etc. But
> -their use is discouraged because of the many caveats in using them. Instead 
> it
> -is recomended to use -D${lang}_args and
> --D${lang}_link_args instead. Among the benefits of these options
> +Compiler Options
> +
> +Meson supports the common CFLAGS, CXXFLAGS, etc. environment
> +variables but their use is discouraged because of the many caveats
> +in using them.
> +
> +Instead, it is recomended to use -D${lang}_args and
> +-D${lang}_link_args. Among the benefits of these options
>  is that they are guaranteed to persist across rebuilds and reconfigurations.
> +
> +This example sets -fmax-errors for compiling C sources and -DMAGIC=123
> +for C++ sources:
> +
> +
> +
> +meson builddir/ -Dc_args=-fmax-errors=10 -Dcpp_args=-DMAGIC=123
> +
> +
> +
> +
>  
> -Meson does not allow changing compiler in a configured builddir, you will 
> need
> +Compiler Specification
> +
> +
> +Meson supports the standard CC and CXX environment variables for
> +changing the default compiler.  Note that Meson does not allow
> +changing the compilers in a configured builddir so you will need
>  to create a new build dir for a different compiler.
>  
> -
> +
> +This is an example of specifying the clang compilers and cleaning
> +the build directory before reconfiguring with an extra C option:
> +
>  
> -CC=clang CXX=clang++ meson build-clang
> -ninja -C build-clang
> -ninja -C build-clang clean
> -meson configure build -Dc_args="-Wno-typedef-redefinition"
> -ninja -C build-clang
> +CC=clang CXX=clang++ meson build-clang
> +ninja -C build-clang
> +ninja -C build-clang clean
> +meson configure build -Dc_args="-Wno-typedef-redefinition"
> +ninja -C build-clang
>  
> -
>  
>  The default compilers depends on your operating system. Meson supports most 
> of
>  the popular compilers, a complete list is available
>  http://mesonbuild.com/Reference-tables.html#compiler-ids";>here.
>  
> -
> -Meson also honors DESTDIR for installs
>  
>  
> -
>  LLVM
>  Meson includes upstream logic to wrap llvm-config using its standard
>  dependency interface.
> -- 
> 1.8.5.6
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] llvmpipe: init some vars to NULL to silence MinGW compiler warnings

[Roland Scheidegger]

Reviewed-by: Roland Scheidegger 

Am 01.05.19 um 18:48 schrieb Brian Paul:
> ---
>  src/gallium/auxiliary/gallivm/lp_bld_format_s3tc.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/src/gallium/auxiliary/gallivm/lp_bld_format_s3tc.c 
> b/src/gallium/auxiliary/gallivm/lp_bld_format_s3tc.c
> index 9561c34..90b2be9 100644
> --- a/src/gallium/auxiliary/gallivm/lp_bld_format_s3tc.c
> +++ b/src/gallium/auxiliary/gallivm/lp_bld_format_s3tc.c
> @@ -2191,7 +2191,7 @@ lp_build_fetch_s3tc_rgba_aos(struct gallivm_state 
> *gallivm,
>rgba = LLVMGetUndef(i128_vectype);
>  
>for (count = 0; count < n / 4; count++) {
> - LLVMValueRef colors, codewords, alpha_lo, alpha_hi;
> + LLVMValueRef colors, codewords, alpha_lo = NULL, alpha_hi = NULL;
>  
>   i4 = lp_build_extract_range(gallivm, i, count * 4, 4);
>   j4 = lp_build_extract_range(gallivm, j, count * 4, 4);
> @@ -2230,7 +2230,7 @@ lp_build_fetch_s3tc_rgba_aos(struct gallivm_state 
> *gallivm,
>rgba = LLVMBuildBitCast(builder, rgba, i8_vectype, "");
> }
> else {
> -  LLVMValueRef colors, codewords, alpha_lo, alpha_hi;
> +  LLVMValueRef colors, codewords, alpha_lo = NULL, alpha_hi = NULL;
>  
>lp_build_gather_s3tc(gallivm, n, format_desc, &colors, &codewords,
> &alpha_lo, &alpha_hi, base_ptr, offset);
> 

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

Re: [Mesa-dev] [PATCH] docs: document MESA_GLSL=errors keyword

[Eric Engestrom]

On Thursday, 2019-04-18 15:58:35 +0200, Alejandro Piñeiro wrote:
> Added with commit 0161691f3518, still checked on shaderapi.c
> _mesa_get_shader_flag method.

Fixes: 0161691f3518db310411 "mesa: add GLSL_REPORT_ERRORS debug flag"
Reviewed-by: Eric Engestrom 

and pushed, thanks!

> ---
>  docs/shading.html | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/docs/shading.html b/docs/shading.html
> index 9e3c7218e31..76f25316f86 100644
> --- a/docs/shading.html
> +++ b/docs/shading.html
> @@ -59,6 +59,7 @@ execution.  These are generally used for debugging.
>  nopfrag - force fragment shader to be a simple shader that passes
>  through the color attribute.
>  useprog - log glUseProgram calls to stderr
> +errors - GLSL compilation and link errors will be reported to 
> stderr.
>  
>  
>  Example:  export MESA_GLSL=dump,nopt
> -- 
> 2.19.1
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH mesa] meson: expose glapi through osmesa

[Eric Engestrom]

Suggested-by: Pierre Guillou 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109659
Cc: Brian Paul 
Cc: Dylan Baker 
Signed-off-by: Eric Engestrom 
---
 src/gallium/targets/osmesa/meson.build | 4 ++--
 src/mesa/drivers/osmesa/meson.build| 3 ++-
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/src/gallium/targets/osmesa/meson.build 
b/src/gallium/targets/osmesa/meson.build
index b4ae8f4b6ec8c5a8f29b..e873e311aa04d0b05865 100644
--- a/src/gallium/targets/osmesa/meson.build
+++ b/src/gallium/targets/osmesa/meson.build
@@ -43,9 +43,9 @@ libosmesa = shared_library(
 inc_gallium_drivers,
   ],
   link_depends : osmesa_link_deps,
-  link_whole : [libosmesa_st],
+  link_whole : [libosmesa_st, libglapi_static],
   link_with : [
-libmesa_gallium, libgallium, libglapi_static, libws_null, osmesa_link_with,
+libmesa_gallium, libgallium, libws_null, osmesa_link_with,
   ],
   dependencies : [
 dep_selinux, dep_thread, dep_clock, dep_unwind,
diff --git a/src/mesa/drivers/osmesa/meson.build 
b/src/mesa/drivers/osmesa/meson.build
index a406bb3c2100b9994034..c479b7401316a5dced60 100644
--- a/src/mesa/drivers/osmesa/meson.build
+++ b/src/mesa/drivers/osmesa/meson.build
@@ -33,7 +33,8 @@ libosmesa = shared_library(
   include_directories : [
 inc_include, inc_src, inc_mapi, inc_mesa, inc_gallium, inc_gallium_aux,
   ],
-  link_with : [libmesa_classic, libglapi_static, osmesa_link_with],
+  link_whole : libglapi_static,
+  link_with : [libmesa_classic, osmesa_link_with],
   dependencies : [dep_thread, dep_selinux],
   version : '8.0.0',
   install : true,
-- 
Cheers,
  Eric

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

[Mesa-dev] [PATCH] radv: fix radv_get_aspect_format() for D+S formats

[Samuel Pitoiset]

This restores the previous behaviour before YCBCR landed. For D+S
formats, it returns the depth format.

This fixes an assertion with Thrones of Britannia.

Fixes: 66507cc6563 ("radv: Add single plane image views & meta operations")
Signed-off-by: Samuel Pitoiset 
---
 src/amd/vulkan/radv_image.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/amd/vulkan/radv_image.c b/src/amd/vulkan/radv_image.c
index a487a5576a6..92409d147f1 100644
--- a/src/amd/vulkan/radv_image.c
+++ b/src/amd/vulkan/radv_image.c
@@ -1189,6 +1189,8 @@ radv_get_aspect_format(struct radv_image *image, 
VkImageAspectFlags mask)
return vk_format_stencil_only(image->vk_format);
case VK_IMAGE_ASPECT_DEPTH_BIT:
return vk_format_depth_only(image->vk_format);
+   case VK_IMAGE_ASPECT_DEPTH_BIT | VK_IMAGE_ASPECT_STENCIL_BIT:
+   return vk_format_depth_only(image->vk_format);
default:
return image->vk_format;
}
-- 
2.21.0

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

[Mesa-dev] [PATCH] radv: only need to force emit the TCS regs on Vega10 and Ravenv1

[Samuel Pitoiset]

Other GFX9 chips aren't affected.

Cc: "19.0" "19.1" 
Signed-off-by: Samuel Pitoiset 
---
 src/amd/vulkan/radv_nir_to_llvm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/amd/vulkan/radv_nir_to_llvm.c 
b/src/amd/vulkan/radv_nir_to_llvm.c
index b4a19aa2e5d..796d78e34f4 100644
--- a/src/amd/vulkan/radv_nir_to_llvm.c
+++ b/src/amd/vulkan/radv_nir_to_llvm.c
@@ -3690,8 +3690,8 @@ LLVMModuleRef ac_translate_nir_to_llvm(struct 
ac_llvm_compiler *ac_llvm,
if (shader_count >= 2)
ac_init_exec_full_mask(&ctx.ac);
 
-   if (ctx.ac.chip_class == GFX9 &&
-   ctx.ac.family != CHIP_VEGA20 &&
+   if ((ctx.ac.family == CHIP_VEGA10 ||
+ctx.ac.family == CHIP_RAVEN) &&
shaders[shader_count - 1]->info.stage == MESA_SHADER_TESS_CTRL)
ac_nir_fixup_ls_hs_input_vgprs(&ctx);
 
-- 
2.21.0

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

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

[AppVeyor]

Build mesa 10999 failed


Commit ad7c9ba0ec by Tomeu Vizoso on 4/22/2019 3:06 PM:

panfrost/midgard: Skip liveness analysis for instructions without dest\n\n[Alyssa: Add comment explanation]\n\nSigned-off-by: Tomeu Vizoso \nReviewed-by: Alyssa Rosenzweig 


Configure your notification preferences

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

Re: [Mesa-dev] [PATCH] radv: do not need to force emit the TCS regs on Vega20

[Samuel Pitoiset]

On 5/2/19 5:35 PM, Marek Olšák wrote:

This bug is only on Vega10 and Raven1.


Yep, I figured after pushing...

I will update the workaround.

Thanks Marek!



Marek

On Wed, May 1, 2019 at 10:10 AM Samuel Pitoiset 
mailto:samuel.pitoi...@gmail.com>> wrote:


This chip doesn't need the fixup. This fixes a bunch of
dEQP-VK.tessellation tests and avoid random GPU hangs.

Cc: "19.0" mailto:mesa-sta...@lists.freedesktop.org>>
Signed-off-by: Samuel Pitoiset mailto:samuel.pitoi...@gmail.com>>
---
 src/amd/vulkan/radv_nir_to_llvm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/amd/vulkan/radv_nir_to_llvm.c
b/src/amd/vulkan/radv_nir_to_llvm.c
index adf158e30e1..b4a19aa2e5d 100644
--- a/src/amd/vulkan/radv_nir_to_llvm.c
+++ b/src/amd/vulkan/radv_nir_to_llvm.c
@@ -3691,6 +3691,7 @@ LLVMModuleRef
ac_translate_nir_to_llvm(struct ac_llvm_compiler *ac_llvm,
                ac_init_exec_full_mask(&ctx.ac );

        if (ctx.ac.chip_class == GFX9 &&
+           ctx.ac.family != CHIP_VEGA20 &&
            shaders[shader_count - 1]->info.stage ==
MESA_SHADER_TESS_CTRL)
                ac_nir_fixup_ls_hs_input_vgprs(&ctx);

-- 
2.21.0


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

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

Re: [Mesa-dev] [PATCH] radv: do not need to force emit the TCS regs on Vega20

[Marek Olšák]

This bug is only on Vega10 and Raven1.

Marek

On Wed, May 1, 2019 at 10:10 AM Samuel Pitoiset 
wrote:

> This chip doesn't need the fixup. This fixes a bunch of
> dEQP-VK.tessellation tests and avoid random GPU hangs.
>
> Cc: "19.0" 
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/amd/vulkan/radv_nir_to_llvm.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/src/amd/vulkan/radv_nir_to_llvm.c
> b/src/amd/vulkan/radv_nir_to_llvm.c
> index adf158e30e1..b4a19aa2e5d 100644
> --- a/src/amd/vulkan/radv_nir_to_llvm.c
> +++ b/src/amd/vulkan/radv_nir_to_llvm.c
> @@ -3691,6 +3691,7 @@ LLVMModuleRef ac_translate_nir_to_llvm(struct
> ac_llvm_compiler *ac_llvm,
> ac_init_exec_full_mask(&ctx.ac);
>
> if (ctx.ac.chip_class == GFX9 &&
> +   ctx.ac.family != CHIP_VEGA20 &&
> shaders[shader_count - 1]->info.stage == MESA_SHADER_TESS_CTRL)
> ac_nir_fixup_ls_hs_input_vgprs(&ctx);
>
> --
> 2.21.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 109929] tgsi_to_nir.c:2111: undefined reference to `gl_nir_lower_samplers_as_deref'

[bugzilla-daemon]

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

--- Comment #19 from Jan Vesely  ---
(In reply to Eric Engestrom from comment #18)
> (In reply to Jan Vesely from comment #17)
> > Ideally, meson would use '-Wl,--no-undefined' by default to catch this kind
> > of errors.
> 
> It does; it's controlled by `b_lundef`, which is `true` by default, and
> mesa's `meson.build` doesn't touch it, so the only way it gets disabled is
> if you do that yourself.

figured as much when I looked into it. It doesn't matter what I set, meson
didn't detect this bug for anyone.

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

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

[AppVeyor]

Build mesa 10997 failed


Commit a34ee4dec7 by Eric Engestrom on 4/12/2019 4:47 PM:

egl: hard-code destroy function instead of passing it around as a pointer\n\nSigned-off-by: Eric Engestrom \nReviewed-by: Tapani Pälli \nReviewed-by: Emil Velikov 


Configure your notification preferences

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

Re: [Mesa-dev] [PATCH v1] panfrost/midgard: Skip register allocation if there's no work to do

[Alyssa Rosenzweig]

As I mentioned over IRC, I'm not sure how this case would be possible to
hit under normal circumstances. Do you have a sample affected shader?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v1] panfrost/midgard: Skip liveness analysis for instructions without dest

[Alyssa Rosenzweig]

Just for future reader's reference, could you add a comment above this
line:

/* This skips store_vary instructions, which are not yet SSA */

> +if (ins->ssa_args.dest < 0) continue;

With that small change, Reviewed-by AR :)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v3] ac, radv: remove the vec3 restriction with LLVM 9+

[Samuel Pitoiset]

This changes requires LLVM r356755.

32706 shaders in 16744 tests
Totals:
SGPRS: 1448848 -> 1455984 (0.49 %)
VGPRS: 1016684 -> 1016220 (-0.05 %)
Spilled SGPRs: 25871 -> 25815 (-0.22 %)
Spilled VGPRs: 122 -> 122 (0.00 %)
Scratch size: 11964 -> 11956 (-0.07 %) dwords per thread
Code Size: 55324500 -> 55301152 (-0.04 %) bytes
Max Waves: 235660 -> 235586 (-0.03 %)

Totals from affected shaders:
SGPRS: 293704 -> 300840 (2.43 %)
VGPRS: 246716 -> 246252 (-0.19 %)
Spilled SGPRs: 159 -> 103 (-35.22 %)
Scratch size: 188 -> 180 (-4.26 %) dwords per thread
Code Size: 8653664 -> 8630316 (-0.27 %) bytes
Max Waves: 60811 -> 60737 (-0.12 %)

v3: - rebase on top of master
- remove the restriction for SSBO stores as well
v2: - fix llvm 8

Signed-off-by: Samuel Pitoiset 
---

I plan to run benchmarks with that change.

 src/amd/common/ac_llvm_build.c| 15 ---
 src/amd/common/ac_llvm_build.h|  1 +
 src/amd/common/ac_nir_to_llvm.c   |  9 ++---
 src/amd/vulkan/radv_nir_to_llvm.c |  4 +++-
 4 files changed, 18 insertions(+), 11 deletions(-)

diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c
index 22b771db774..e191a64310f 100644
--- a/src/amd/common/ac_llvm_build.c
+++ b/src/amd/common/ac_llvm_build.c
@@ -84,6 +84,7 @@ ac_llvm_context_init(struct ac_llvm_context *ctx,
ctx->v3i32 = LLVMVectorType(ctx->i32, 3);
ctx->v4i32 = LLVMVectorType(ctx->i32, 4);
ctx->v2f32 = LLVMVectorType(ctx->f32, 2);
+   ctx->v3f32 = LLVMVectorType(ctx->f32, 3);
ctx->v4f32 = LLVMVectorType(ctx->f32, 4);
ctx->v8i32 = LLVMVectorType(ctx->i32, 8);
 
@@ -1167,7 +1168,7 @@ ac_build_llvm8_buffer_store_common(struct ac_llvm_context 
*ctx,
args[idx++] = voffset ? voffset : ctx->i32_0;
args[idx++] = soffset ? soffset : ctx->i32_0;
args[idx++] = LLVMConstInt(ctx->i32, (glc ? 1 : 0) + (slc ? 2 : 0), 0);
-   unsigned func = num_channels == 3 ? 4 : num_channels;
+   unsigned func = HAVE_LLVM < 0x900 && num_channels == 3 ? 4 : 
num_channels;
const char *indexing_kind = structurized ? "struct" : "raw";
char name[256], type_name[8];
 
@@ -1225,9 +1226,9 @@ ac_build_buffer_store_dword(struct ac_llvm_context *ctx,
bool writeonly_memory,
bool swizzle_enable_hint)
 {
-   /* Split 3 channel stores, becase LLVM doesn't support 3-channel
+   /* Split 3 channel stores, because only LLVM 9+ support 3-channel
 * intrinsics. */
-   if (num_channels == 3) {
+   if (num_channels == 3 && HAVE_LLVM < 0x900) {
LLVMValueRef v[3], v01;
 
for (int i = 0; i < 3; i++) {
@@ -1354,7 +1355,7 @@ ac_build_llvm8_buffer_load_common(struct ac_llvm_context 
*ctx,
args[idx++] = voffset ? voffset : ctx->i32_0;
args[idx++] = soffset ? soffset : ctx->i32_0;
args[idx++] = LLVMConstInt(ctx->i32, (glc ? 1 : 0) + (slc ? 2 : 0), 0);
-   unsigned func = num_channels == 3 ? 4 : num_channels;
+   unsigned func = HAVE_LLVM < 0x900 && num_channels == 3 ? 4 : 
num_channels;
const char *indexing_kind = structurized ? "struct" : "raw";
char name[256], type_name[8];
 
@@ -1420,7 +1421,7 @@ ac_build_buffer_load(struct ac_llvm_context *ctx,
if (num_channels == 1)
return result[0];
 
-   if (num_channels == 3)
+   if (num_channels == 3 && HAVE_LLVM < 0x900)
result[num_channels++] = LLVMGetUndef(ctx->f32);
return ac_build_gather_values(ctx, result, num_channels);
}
@@ -1512,7 +1513,7 @@ ac_build_llvm8_tbuffer_load(struct ac_llvm_context *ctx,
args[idx++] = soffset ? soffset : ctx->i32_0;
args[idx++] = LLVMConstInt(ctx->i32, dfmt | (nfmt << 4), 0);
args[idx++] = LLVMConstInt(ctx->i32, (glc ? 1 : 0) + (slc ? 2 : 0), 0);
-   unsigned func = num_channels == 3 ? 4 : num_channels;
+   unsigned func = HAVE_LLVM < 0x900 && num_channels == 3 ? 4 : 
num_channels;
const char *indexing_kind = structurized ? "struct" : "raw";
char name[256], type_name[8];
 
@@ -1698,7 +1699,7 @@ ac_build_llvm8_tbuffer_store(struct ac_llvm_context *ctx,
args[idx++] = soffset ? soffset : ctx->i32_0;
args[idx++] = LLVMConstInt(ctx->i32, dfmt | (nfmt << 4), 0);
args[idx++] = LLVMConstInt(ctx->i32, (glc ? 1 : 0) + (slc ? 2 : 0), 0);
-   unsigned func = num_channels == 3 ? 4 : num_channels;
+   unsigned func = HAVE_LLVM < 0x900 && num_channels == 3 ? 4 : 
num_channels;
const char *indexing_kind = structurized ? "struct" : "raw";
char name[256], type_name[8];
 
diff --git a/src/amd/common/ac_llvm_build.h b/src/amd/common/ac_llvm_build.h
index 98f856106d6..19db808a9a8 100644
--- a/src/amd/common/ac_llvm_build.h
+++ b/src/amd/common/ac_llvm_build.h
@@ -71,6 +71,7 @@ struct ac_llvm_context {
LLVMTypeRef v3i32;
LLVMTypeRef v4i32;
LLVM

Re: [Mesa-dev] [PATCH v2] anv: fix alphaToCoverage when there is no color attachment

[Jason Ekstrand]

On Thu, May 2, 2019 at 5:46 AM Iago Toral Quiroga  wrote:

> From: Samuel Iglesias Gonsálvez 
>
> There tests in CTS for for alpha to coverage without a color attachment.
> First the test draws a primitive with alpha 0 and a subpass with only
> a depth buffer. No writes to a depth buffer are expected. Then a
> second draw with a color buffer and the same depth buffer is done to
> verify the depth buffer still has the original clear values.
>
> This behavior is not explicitly forbidden by the Vulkan spec, so
> it seems it is allowed.
>
> When there is no color attachment for a given output, we discard it
> so at the end we have an FS assembly like:
>
> Native code for unnamed fragment shader (null)
> SIMD16 shader: 1 instructions. 0 loops. 4 cycles. 0:0 spills:fills.
> Promoted 0 constants. Compacted 16 to 16 bytes (0%)
>   START B0 (4 cycles)
> sendc(16)   null<1>UW   g120<0,1,0>F0x90031000
>
> render MsgDesc: RT write SIMD16 LastRT Surface = 0 mlen 8 rlen 0 {
> align1 1H EOT };
>
> As g120 is not initialized, we see random writes to the depth buffer
> due to the alphaToCoverage enablement. This patch fixes that by
> keeping the output in that case.
>
> v2:
>  - No need to create a null render target, the driver is already
>doing that (Jason)
>  - Simplified code a bit (Iago)
>
> Fixes the following CTS tests:
> dEQP-VK.pipeline.multisample.alpha_to_coverage_no_color_attachment.*
>
> Signed-off-by: Samuel Iglesias Gonsálvez 
> Signed-off-by: Iago Toral Quiroga 
> ---
>  src/intel/vulkan/anv_pipeline.c | 25 ++---
>  1 file changed, 18 insertions(+), 7 deletions(-)
>
> diff --git a/src/intel/vulkan/anv_pipeline.c
> b/src/intel/vulkan/anv_pipeline.c
> index b9c9bfd7598..07f1a939e43 100644
> --- a/src/intel/vulkan/anv_pipeline.c
> +++ b/src/intel/vulkan/anv_pipeline.c
> @@ -808,7 +808,9 @@ anv_pipeline_compile_gs(const struct brw_compiler
> *compiler,
>
>  static void
>  anv_pipeline_link_fs(const struct brw_compiler *compiler,
> - struct anv_pipeline_stage *stage)
> + struct anv_pipeline_stage *stage,
> + bool has_depth_stencil_att,
> + bool has_alpha_to_coverage)
>  {
> unsigned num_rts = 0;
> const int max_rt = FRAG_RESULT_DATA7 - FRAG_RESULT_DATA0 + 1;
> @@ -859,11 +861,17 @@ anv_pipeline_link_fs(const struct brw_compiler
> *compiler,
>const unsigned rt = var->data.location - FRAG_RESULT_DATA0;
>if (rt >= MAX_RTS ||
>!(stage->key.wm.color_outputs_valid & (1 << rt))) {
> - /* Unused or out-of-bounds, throw it away */
> - deleted_output = true;
> - var->data.mode = nir_var_function_temp;
> - exec_node_remove(&var->node);
> - exec_list_push_tail(&impl->locals, &var->node);
> + /* Unused or out-of-bounds, throw it away. The exception is
> depth-only
> +  * rendering with alphaToCoverage, as in this case we need to
> keep the
> +  * fragment output in location 0, which we will bind later to a
> null
> +  * render target.
> +  */
> + if (rt != 0 || !has_alpha_to_coverage || !has_depth_stencil_att)
> {
> +deleted_output = true;
> +var->data.mode = nir_var_function_temp;
> +exec_node_remove(&var->node);
> +exec_list_push_tail(&impl->locals, &var->node);
> + }
>   continue;
>}
>
> @@ -1120,7 +1128,10 @@ anv_pipeline_compile_graphics(struct anv_pipeline
> *pipeline,
>   anv_pipeline_link_gs(compiler, &stages[s], next_stage);
>   break;
>case MESA_SHADER_FRAGMENT:
> - anv_pipeline_link_fs(compiler, &stages[s]);
> + anv_pipeline_link_fs(compiler, &stages[s],
> +  pipeline->subpass->depth_stencil_attachment,
> +  info->pMultisampleState &&
> +
> info->pMultisampleState->alphaToCoverageEnable);
>

You don't need to pass alphaToCoverageEnable through because it's already
in the key.  For pipeline->subpass->depth_stencil_attachment, I'm inclined
to just not have that in the calculation.  It's not in the key, so we'd
have to add it, and the calculation should be correct regardless of whether
we take depth stencil attachments into account.  If they have no
attachments whatsoever, then why are they setting alphaToCoverage?  Also, I
think you could similar issues if someone had no attacyment to rt 0 but did
have an attachment at rt 1 which they wrote with a color value.

--Jason


>   break;
>default:
>   unreachable("Invalid graphics shader stage");
> --
> 2.17.1
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 110291] Vega 64 GPU hang running Space Engineers

[bugzilla-daemon]

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

Samuel Pitoiset  changed:

   What|Removed |Added

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

--- Comment #6 from Samuel Pitoiset  ---
Should be fixed with
https://cgit.freedesktop.org/mesa/mesa/commit/?id=08be23bfdec9fb447c58ae48bf9cc1b91ecba128

Thanks for the great report.

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

[Mesa-dev] [Bug 110540] [AMD TAHITI XT] valve artifact broken

[bugzilla-daemon]

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

--- Comment #4 from Sylvain BERTRAND  ---
Sure, tonight (UTC+2). I have not started the bisection anyway.

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

[Mesa-dev] [Bug 110291] Vega 64 GPU hang running Space Engineers

[bugzilla-daemon]

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

--- Comment #5 from Samuel Pitoiset  ---
Actually, the correct fix should be
https://patchwork.freedesktop.org/series/60204/

It fixes the GPU hang on my Vega20.

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

[Mesa-dev] [PATCH] radv: set WD_SWITCH_ON_EOP=1 when drawing primitives from a stream output buffer

[Samuel Pitoiset]

According to RadeonSI, this seems to be required by the hardware
to avoid GPU hangs. I think I just forgot to set that bit when I
implemented VK_EXT_transform_feedback.

This fixes a GPU hang with Space Engineers and DXVK.

Cc: "19.0" "19.1" 
Signed-off-by: Samuel Pitoiset 
---
 src/amd/vulkan/radv_cmd_buffer.c | 1 +
 src/amd/vulkan/radv_private.h| 1 +
 src/amd/vulkan/si_cmd_buffer.c   | 7 +++
 3 files changed, 9 insertions(+)

diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index 963118215fa..b04c998fac2 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -2202,6 +2202,7 @@ radv_emit_draw_registers(struct radv_cmd_buffer 
*cmd_buffer,
ia_multi_vgt_param =
si_get_ia_multi_vgt_param(cmd_buffer, draw_info->instance_count 
> 1,
  draw_info->indirect,
+ !!draw_info->strmout_buffer,
  draw_info->indirect ? 0 : 
draw_info->count);
 
if (state->last_ia_multi_vgt_param != ia_multi_vgt_param) {
diff --git a/src/amd/vulkan/radv_private.h b/src/amd/vulkan/radv_private.h
index 352072f8ff3..df85d0cf889 100644
--- a/src/amd/vulkan/radv_private.h
+++ b/src/amd/vulkan/radv_private.h
@@ -1160,6 +1160,7 @@ void si_write_scissors(struct radeon_cmdbuf *cs, int 
first,
   const VkViewport *viewports, bool can_use_guardband);
 uint32_t si_get_ia_multi_vgt_param(struct radv_cmd_buffer *cmd_buffer,
   bool instanced_draw, bool indirect_draw,
+  bool count_from_stream_output,
   uint32_t draw_vertex_count);
 void si_cs_emit_write_event_eop(struct radeon_cmdbuf *cs,
enum chip_class chip_class,
diff --git a/src/amd/vulkan/si_cmd_buffer.c b/src/amd/vulkan/si_cmd_buffer.c
index e75c6d127d6..e73c13762e5 100644
--- a/src/amd/vulkan/si_cmd_buffer.c
+++ b/src/amd/vulkan/si_cmd_buffer.c
@@ -561,6 +561,7 @@ radv_prims_for_vertices(struct radv_prim_vertex_count 
*info, unsigned num)
 uint32_t
 si_get_ia_multi_vgt_param(struct radv_cmd_buffer *cmd_buffer,
  bool instanced_draw, bool indirect_draw,
+ bool count_from_stream_output,
  uint32_t draw_vertex_count)
 {
enum chip_class chip_class = 
cmd_buffer->device->physical_device->rad_info.chip_class;
@@ -622,6 +623,12 @@ si_get_ia_multi_vgt_param(struct radv_cmd_buffer 
*cmd_buffer,
(instanced_draw || indirect_draw))
partial_vs_wave = true;
 
+   /* Hardware requirement when drawing primitives from a stream
+* output buffer.
+*/
+   if (count_from_stream_output)
+   wd_switch_on_eop = true;
+
/* If the WD switch is false, the IA switch must be false too. 
*/
assert(wd_switch_on_eop || !ia_switch_on_eop);
}
-- 
2.21.0

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

[Mesa-dev] [Bug 110291] Vega 64 GPU hang running Space Engineers

[bugzilla-daemon]

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

--- Comment #4 from Samuel Pitoiset  ---
Created attachment 144128
  --> https://bugs.freedesktop.org/attachment.cgi?id=144128&action=edit
hack

Does the attached hack fix the hang for you?

-- 
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 110573] Mesa vulkan-radeon 19.0.3 system freeze and visual artifacts (RADV)

[bugzilla-daemon]

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

--- Comment #9 from Samuel Pitoiset  ---
Yeah, the trace crashes and doesn't expose the problem for me.

-- 
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 109929] tgsi_to_nir.c:2111: undefined reference to `gl_nir_lower_samplers_as_deref'

[bugzilla-daemon]

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

--- Comment #18 from Eric Engestrom  ---
(In reply to Jan Vesely from comment #17)
> Ideally, meson would use '-Wl,--no-undefined' by default to catch this kind
> of errors.

It does; it's controlled by `b_lundef`, which is `true` by default, and mesa's
`meson.build` doesn't touch it, so the only way it gets disabled is if you do
that yourself.

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

[Mesa-dev] [Bug 109202] nv50_ir.cpp:749:19: error: cannot use typeid with -fno-rtti

[bugzilla-daemon]

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

Eric Engestrom  changed:

   What|Removed |Added

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

--- Comment #4 from Eric Engestrom  ---
Marking as FIXED since Dylan made it a meson error to do this:

commit a2596450ac7330c8965c819491038fb1ad454333
Author: Dylan Baker 
Date:   Mon Dec 31 19:23:52 2018 -0800

meson: Error out if building nouveau and using LLVM without rtti

Nouveau requires rtti. Often LLVM is configured without rtti, and code
with and without cannot be linked safely. Lets just error out if nouveau
is requested and llvm is built without rtti.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109202
Fixes: c5a97d658ec19cc02719d7f86c1b0715e3d9ffc4
   ("meson: fix builds against LLVM built without rtti")
Reviewed-by: Bas Nieuwenhuizen 

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

Re: [Mesa-dev] [PATCH 1/8] etnaviv: create optional 2d pipe in screen

[Christian Gmeiner]

Hi Lucas,


Am Fr., 12. Apr. 2019 um 19:38 Uhr schrieb Lucas Stach :
>
> The 2D pipe is useful to implement fast planar and interleaved YUV buffer
> imports. Not all systems have a 2D capable core, so this is strictly
> optional.
>

do you have planed to send out a new version of this patch-set?

-- 
greets
--
Christian Gmeiner, MSc

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

[Mesa-dev] [PATCH v2] anv: fix alphaToCoverage when there is no color attachment

[Iago Toral Quiroga]

From: Samuel Iglesias Gonsálvez 

There tests in CTS for for alpha to coverage without a color attachment.
First the test draws a primitive with alpha 0 and a subpass with only
a depth buffer. No writes to a depth buffer are expected. Then a
second draw with a color buffer and the same depth buffer is done to
verify the depth buffer still has the original clear values.

This behavior is not explicitly forbidden by the Vulkan spec, so
it seems it is allowed.

When there is no color attachment for a given output, we discard it
so at the end we have an FS assembly like:

Native code for unnamed fragment shader (null)
SIMD16 shader: 1 instructions. 0 loops. 4 cycles. 0:0 spills:fills.
Promoted 0 constants. Compacted 16 to 16 bytes (0%)
  START B0 (4 cycles)
sendc(16)   null<1>UW   g120<0,1,0>F0x90031000

render MsgDesc: RT write SIMD16 LastRT Surface = 0 mlen 8 rlen 0 {
align1 1H EOT };

As g120 is not initialized, we see random writes to the depth buffer
due to the alphaToCoverage enablement. This patch fixes that by
keeping the output in that case.

v2:
 - No need to create a null render target, the driver is already
   doing that (Jason)
 - Simplified code a bit (Iago)

Fixes the following CTS tests:
dEQP-VK.pipeline.multisample.alpha_to_coverage_no_color_attachment.*

Signed-off-by: Samuel Iglesias Gonsálvez 
Signed-off-by: Iago Toral Quiroga 
---
 src/intel/vulkan/anv_pipeline.c | 25 ++---
 1 file changed, 18 insertions(+), 7 deletions(-)

diff --git a/src/intel/vulkan/anv_pipeline.c b/src/intel/vulkan/anv_pipeline.c
index b9c9bfd7598..07f1a939e43 100644
--- a/src/intel/vulkan/anv_pipeline.c
+++ b/src/intel/vulkan/anv_pipeline.c
@@ -808,7 +808,9 @@ anv_pipeline_compile_gs(const struct brw_compiler *compiler,
 
 static void
 anv_pipeline_link_fs(const struct brw_compiler *compiler,
- struct anv_pipeline_stage *stage)
+ struct anv_pipeline_stage *stage,
+ bool has_depth_stencil_att,
+ bool has_alpha_to_coverage)
 {
unsigned num_rts = 0;
const int max_rt = FRAG_RESULT_DATA7 - FRAG_RESULT_DATA0 + 1;
@@ -859,11 +861,17 @@ anv_pipeline_link_fs(const struct brw_compiler *compiler,
   const unsigned rt = var->data.location - FRAG_RESULT_DATA0;
   if (rt >= MAX_RTS ||
   !(stage->key.wm.color_outputs_valid & (1 << rt))) {
- /* Unused or out-of-bounds, throw it away */
- deleted_output = true;
- var->data.mode = nir_var_function_temp;
- exec_node_remove(&var->node);
- exec_list_push_tail(&impl->locals, &var->node);
+ /* Unused or out-of-bounds, throw it away. The exception is depth-only
+  * rendering with alphaToCoverage, as in this case we need to keep the
+  * fragment output in location 0, which we will bind later to a null
+  * render target.
+  */
+ if (rt != 0 || !has_alpha_to_coverage || !has_depth_stencil_att) {
+deleted_output = true;
+var->data.mode = nir_var_function_temp;
+exec_node_remove(&var->node);
+exec_list_push_tail(&impl->locals, &var->node);
+ }
  continue;
   }
 
@@ -1120,7 +1128,10 @@ anv_pipeline_compile_graphics(struct anv_pipeline 
*pipeline,
  anv_pipeline_link_gs(compiler, &stages[s], next_stage);
  break;
   case MESA_SHADER_FRAGMENT:
- anv_pipeline_link_fs(compiler, &stages[s]);
+ anv_pipeline_link_fs(compiler, &stages[s],
+  pipeline->subpass->depth_stencil_attachment,
+  info->pMultisampleState &&
+  info->pMultisampleState->alphaToCoverageEnable);
  break;
   default:
  unreachable("Invalid graphics shader stage");
-- 
2.17.1

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

[Mesa-dev] [Bug 110573] Mesa vulkan-radeon 19.0.3 system freeze and visual artifacts (RADV)

[bugzilla-daemon]

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

--- Comment #8 from osch...@web.de ---
I recorded an apitrace of AC:O back in october to help debug a dxvk issue, but
at least back then it crashed with apitrace before you could load a savegame,
so it might not be possible to reproduce this issue with apitrace.
Anyways, here is the old trace:
https://drive.google.com/open?id=1vFyghPpwZ_M5K16-xv1Vp97jauL4Ma9l

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

[Mesa-dev] [Bug 110573] Mesa vulkan-radeon 19.0.3 system freeze and visual artifacts (RADV)

[bugzilla-daemon]

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

--- Comment #7 from Samuel Pitoiset  ---
apitrace will catch D3D11 and then we can replay the trace through
Wine/DXVK/RADV.

See the DXVK wiki for more info about that.

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

[Mesa-dev] [Bug 110573] Mesa vulkan-radeon 19.0.3 system freeze and visual artifacts (RADV)

[bugzilla-daemon]

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

--- Comment #6 from james.dut...@gmail.com ---
apitrace will not help us here.
Use case:
ACO (Windows Game)  -> Wine -> DXVK -> vulkan

apitrace cannot catch vulkan stuff.

Is there a better tool to trace the vulkan api ?

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

[Mesa-dev] [PATCH v1] panfrost/midgard: Skip register allocation if there's no work to do

[Tomeu Vizoso]

Signed-off-by: Tomeu Vizoso 
---
 src/gallium/drivers/panfrost/midgard/midgard_compile.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/gallium/drivers/panfrost/midgard/midgard_compile.c 
b/src/gallium/drivers/panfrost/midgard/midgard_compile.c
index 348ec861404a..d4d26b9a25e9 100644
--- a/src/gallium/drivers/panfrost/midgard/midgard_compile.c
+++ b/src/gallium/drivers/panfrost/midgard/midgard_compile.c
@@ -2058,6 +2058,9 @@ allocate_registers(compiler_context *ctx)
print_mir_block(block);
 }
 
+if (!ctx->temp_count)
+return;
+
 /* Let's actually do register allocation */
 int nodes = ctx->temp_count;
 struct ra_graph *g = ra_alloc_interference_graph(regs, nodes);
-- 
2.20.1

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

[Mesa-dev] [PATCH v1] panfrost/midgard: Skip liveness analysis for instructions without dest

[Tomeu Vizoso]

Signed-off-by: Tomeu Vizoso 
---
 src/gallium/drivers/panfrost/midgard/midgard_compile.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/gallium/drivers/panfrost/midgard/midgard_compile.c 
b/src/gallium/drivers/panfrost/midgard/midgard_compile.c
index d4d26b9a25e9..f5d8c3e0f2c1 100644
--- a/src/gallium/drivers/panfrost/midgard/midgard_compile.c
+++ b/src/gallium/drivers/panfrost/midgard/midgard_compile.c
@@ -2108,6 +2108,7 @@ allocate_registers(compiler_context *ctx)
 mir_foreach_block(ctx, block) {
 mir_foreach_instr_in_block(block, ins) {
 if (ins->compact_branch) continue;
+if (ins->ssa_args.dest < 0) continue;
 
 if (ins->ssa_args.dest < SSA_FIXED_MINIMUM) {
 /* If this destination is not yet live, it is 
now since we just wrote it */
-- 
2.20.1

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

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

[AppVeyor]

Build mesa 10991 completed



Commit 13c423629e by Rhys Perry on 4/26/2019 2:39 PM:

radv: fix set_output_usage_mask() with composite and 64-bit types\n\nIt previously used var->type instead of deref_instr->type and didn't\nhandle 64-bit outputs.\n\nThis fixes lots of transform feedback CTS tests involving transform\nfeedback and geometry shaders (mostly\ndEQP-VK.transform_feedback.fuzz.random_geometry.*)\n\nv2: fix writemask widening when comp != 0\nv3: fix 64-bit variables when comp != 0, again\n\nSigned-off-by: Rhys Perry \nCc: 19.0 19.1 \nReviewed-by: Samuel Pitoiset 


Configure your notification preferences

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

[Mesa-dev] [Bug 110573] Mesa vulkan-radeon 19.0.3 system freeze and visual artifacts (RADV)

[bugzilla-daemon]

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

--- Comment #5 from Samuel Pitoiset  ---
Can you record an apitrace of the problem?
I would like to understand it before doing a revert eventually.

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

[Mesa-dev] [PATCH 03/10] mesa: Implement _mesa_array_element by walking enabled arrays.

[Mathias . Froehlich]

From: Mathias Fröhlich 

In glArrayElement, use the bitmask trick to just walk the enabled
vao arrays. This should be about equivalent in execution time to
walk the prepare aelt_context list. Finally this will allow us to
reduce the _mesa_update_state calls in a few patches.

Signed-off-by: Mathias Fröhlich 
---
 src/mesa/main/api_arrayelt.c | 78 
 1 file changed, 61 insertions(+), 17 deletions(-)

diff --git a/src/mesa/main/api_arrayelt.c b/src/mesa/main/api_arrayelt.c
index d46c8d14b68..62f1e73ca4c 100644
--- a/src/mesa/main/api_arrayelt.c
+++ b/src/mesa/main/api_arrayelt.c
@@ -1541,32 +1541,76 @@ _ae_update_state(struct gl_context *ctx)
 }


+static inline attrib_func
+func_nv(const struct gl_vertex_format *vformat)
+{
+   return AttribFuncsNV[vformat->Normalized][vformat->Size-1]
+  [TYPE_IDX(vformat->Type)];
+}
+
+
+static inline attrib_func
+func_arb(const struct gl_vertex_format *vformat)
+{
+   return AttribFuncsARB[NORM_IDX(vformat)][vformat->Size-1]
+  [TYPE_IDX(vformat->Type)];
+}
+
+
+static inline const void *
+attrib_src(const struct gl_vertex_array_object *vao,
+   const struct gl_array_attributes *array, GLint elt)
+{
+   const struct gl_vertex_buffer_binding *binding =
+  &vao->BufferBinding[array->BufferBindingIndex];
+   const GLubyte *src
+  = ADD_POINTERS(binding->BufferObj->Mappings[MAP_INTERNAL].Pointer,
+ _mesa_vertex_attrib_address(array, binding))
+  + elt * binding->Stride;
+   return src;
+}
+
+
 void
 _mesa_array_element(struct gl_context *ctx,
 struct _glapi_table *disp, GLint elt)
 {
-   const AEcontext *actx = AE_CONTEXT(ctx);
+   const struct gl_vertex_array_object *vao = ctx->Array.VAO;
+   GLbitfield mask;

-   if (actx->dirty_state)
-  _ae_update_state(ctx);
+   /* emit conventional arrays elements */
+   mask = (VERT_BIT_FF_ALL & ~VERT_BIT_POS) & vao->Enabled;
+   while (mask) {
+  const gl_vert_attrib attrib = u_bit_scan(&mask);
+  const struct gl_array_attributes *array = &vao->VertexAttrib[attrib];
+  const void *src = attrib_src(vao, array, elt);
+  func_nv(&array->Format)(attrib, src);
+   }

/* emit generic attribute elements */
-   for (const AEattrib *at = actx->attribs; at->func; at++) {
-  const GLubyte *src
- = ADD_POINTERS(at->binding->BufferObj->Mappings[MAP_INTERNAL].Pointer,
-_mesa_vertex_attrib_address(at->array, at->binding))
- + elt * at->binding->Stride;
-  at->func(at->index, src);
+   mask = (VERT_BIT_GENERIC_ALL & ~VERT_BIT_GENERIC0) & vao->Enabled;
+   while (mask) {
+  const gl_vert_attrib attrib = u_bit_scan(&mask);
+  const struct gl_array_attributes *array = &vao->VertexAttrib[attrib];
+  const void *src = attrib_src(vao, array, elt);
+  func_arb(&array->Format)(attrib - VERT_ATTRIB_GENERIC0, src);
}

-   /* emit conventional arrays elements */
-   for (const AEarray *aa = actx->arrays; aa->offset != -1 ; aa++) {
-  const GLubyte *src
- = ADD_POINTERS(aa->binding->BufferObj->Mappings[MAP_INTERNAL].Pointer,
-_mesa_vertex_attrib_address(aa->array, aa->binding))
- + elt * aa->binding->Stride;
-  CALL_by_offset(disp, (array_func), aa->offset, ((const void *) src));
-   }
+   /* finally, vertex position */
+   if (vao->Enabled & VERT_BIT_GENERIC0) {
+  const gl_vert_attrib attrib = VERT_ATTRIB_GENERIC0;
+  const struct gl_array_attributes *array = &vao->VertexAttrib[attrib];
+  const void *src = attrib_src(vao, array, elt);
+  /* Use glVertex(v) instead of glVertexAttrib(0, v) to be sure it's
+   * issued as the last (provoking) attribute).
+   */
+  func_nv(&array->Format)(0, src);
+   } else if (vao->Enabled & VERT_BIT_POS) {
+  const gl_vert_attrib attrib = VERT_ATTRIB_POS;
+  const struct gl_array_attributes *array = &vao->VertexAttrib[attrib];
+  const void *src = attrib_src(vao, array, elt);
+  func_nv(&array->Format)(0, src);
+}
 }


--
2.20.1

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

[Mesa-dev] [PATCH 04/10] mesa: Rip out now unused gl_context::aelt_context.

[Mathias . Froehlich]

From: Mathias Fröhlich 

Now this part of gl_context state is unused and can be removed.

Signed-off-by: Mathias Fröhlich 
---
 src/mesa/drivers/dri/r200/r200_context.c |   1 -
 src/mesa/drivers/dri/radeon/radeon_context.c |   1 -
 src/mesa/main/api_arrayelt.c | 180 ---
 src/mesa/main/api_arrayelt.h |   4 -
 src/mesa/main/mtypes.h   |   1 -
 src/mesa/vbo/vbo_context.c   |  15 --
 src/mesa/vbo/vbo_exec.c  |  11 --
 7 files changed, 213 deletions(-)

diff --git a/src/mesa/drivers/dri/r200/r200_context.c 
b/src/mesa/drivers/dri/r200/r200_context.c
index 392c10fb74d..c97eaa56db1 100644
--- a/src/mesa/drivers/dri/r200/r200_context.c
+++ b/src/mesa/drivers/dri/r200/r200_context.c
@@ -256,7 +256,6 @@ GLboolean r200CreateContext( gl_api api,
_vbo_CreateContext( ctx );
_tnl_CreateContext( ctx );
_swsetup_CreateContext( ctx );
-   _ae_create_context( ctx );

ctx->Const.MaxTextureUnits = driQueryOptioni (&rmesa->radeon.optionCache,
 "texture_units");
diff --git a/src/mesa/drivers/dri/radeon/radeon_context.c 
b/src/mesa/drivers/dri/radeon/radeon_context.c
index db1cc7274db..415810f8bd8 100644
--- a/src/mesa/drivers/dri/radeon/radeon_context.c
+++ b/src/mesa/drivers/dri/radeon/radeon_context.c
@@ -219,7 +219,6 @@ r100CreateContext( gl_api api,
_vbo_CreateContext( ctx );
_tnl_CreateContext( ctx );
_swsetup_CreateContext( ctx );
-   _ae_create_context( ctx );

ctx->Const.MaxTextureUnits = driQueryOptioni (&rmesa->radeon.optionCache,
 "texture_units");
diff --git a/src/mesa/main/api_arrayelt.c b/src/mesa/main/api_arrayelt.c
index 62f1e73ca4c..6d4e548e7bd 100644
--- a/src/mesa/main/api_arrayelt.c
+++ b/src/mesa/main/api_arrayelt.c
@@ -45,39 +45,8 @@
 #include "main/dispatch.h"
 #include "varray.h"

-typedef void (GLAPIENTRY *array_func)( const void * );
-
-typedef struct {
-   const struct gl_array_attributes *array;
-   const struct gl_vertex_buffer_binding *binding;
-   int offset;
-} AEarray;
-
 typedef void (GLAPIENTRY *attrib_func)( GLuint indx, const void *data );

-typedef struct {
-   const struct gl_array_attributes *array;
-   const struct gl_vertex_buffer_binding *binding;
-   attrib_func func;
-   GLuint index;
-} AEattrib;
-
-typedef struct {
-   AEarray arrays[32];
-   AEattrib attribs[VERT_ATTRIB_MAX + 1];
-
-   bool dirty_state;
-} AEcontext;
-
-
-/** Cast wrapper */
-static inline AEcontext *
-AE_CONTEXT(struct gl_context *ctx)
-{
-   return (AEcontext *) ctx->aelt_context;
-}
-
-
 /*
  * Convert GL_BYTE, GL_UNSIGNED_BYTE, .. GL_DOUBLE into an integer
  * in the range [0, 7].  Luckily these type tokens are sequentially
@@ -107,13 +76,6 @@ NORM_IDX(const struct gl_vertex_format *vformat)
 }


-bool
-_ae_is_state_dirty(struct gl_context *ctx)
-{
-   return AE_CONTEXT(ctx)->dirty_state;
-}
-
-
 #define NUM_TYPES 8


@@ -1419,128 +1381,6 @@ static const attrib_func 
AttribFuncsARB[4][4][NUM_TYPES] = {
 };


-GLboolean
-_ae_create_context(struct gl_context *ctx)
-{
-   if (ctx->aelt_context)
-  return GL_TRUE;
-
-   ctx->aelt_context = calloc(1, sizeof(AEcontext));
-   if (!ctx->aelt_context)
-  return GL_FALSE;
-
-   AE_CONTEXT(ctx)->dirty_state = true;
-   return GL_TRUE;
-}
-
-
-void
-_ae_destroy_context(struct gl_context *ctx)
-{
-   if (AE_CONTEXT(ctx)) {
-  free(ctx->aelt_context);
-  ctx->aelt_context = NULL;
-   }
-}
-
-
-/**
- * Make a list of per-vertex functions to call for each glArrayElement call.
- * These functions access the array data (i.e. glVertex, glColor, glNormal,
- * etc).
- * Note: this may be called during display list construction.
- */
-static void
-_ae_update_state(struct gl_context *ctx)
-{
-   AEcontext *actx = AE_CONTEXT(ctx);
-   AEarray *aa = actx->arrays;  /* non-indexed arrays (ex: glNormal) */
-   AEattrib *at = actx->attribs;  /* indexed arrays (ex: glMultiTexCoord) */
-   GLuint i;
-   struct gl_vertex_array_object *vao = ctx->Array.VAO;
-
-   /* conventional vertex arrays */
-  for (i = 1; i < VERT_ATTRIB_FF_MAX; i++) {  /* skip zero! */
-  if (vao->Enabled & VERT_BIT_FF(i)) {
- struct gl_array_attributes *attribArray =
-&vao->VertexAttrib[VERT_ATTRIB_FF(i)];
- /* NOTE: we use generic glVertexAttribNV functions here.
-  * If we ever remove GL_NV_vertex_program this will have to change.
-  */
- at->array = attribArray;
- at->binding = &vao->BufferBinding[attribArray->BufferBindingIndex];
- assert(!at->array->Format.Normalized);
- at->func = AttribFuncsNV[at->array->Format.Normalized]
- [at->array->Format.Size-1]
- [TYPE_IDX(at->array->Format.Type)];
- at->index = VERT_ATTRIB_FF(i);
- at++;
-  }
-   }
-
-   /* generic vertex attribute arrays */
-   for (i = 1; i < VE

[Mesa-dev] [PATCH 06/10] mesa: Constify static const array in api_arrayelt.c

[Mathias . Froehlich]

From: Mathias Fröhlich 

Signed-off-by: Mathias Fröhlich 
---
 src/mesa/main/api_arrayelt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/main/api_arrayelt.c b/src/mesa/main/api_arrayelt.c
index 6d4e548e7bd..48b2d9b2357 100644
--- a/src/mesa/main/api_arrayelt.c
+++ b/src/mesa/main/api_arrayelt.c
@@ -486,7 +486,7 @@ VertexAttrib4dvNV(GLuint index, const GLdouble *v)
 /*
  * Array [size][type] of VertexAttrib functions
  */
-static attrib_func AttribFuncsNV[2][4][NUM_TYPES] = {
+static const attrib_func AttribFuncsNV[2][4][NUM_TYPES] = {
{
   /* non-normalized */
   {
--
2.20.1

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

[Mesa-dev] [PATCH 08/10] mesa: Set CurrentSavePrimitive in vbo_save_NotifyBegin.

[Mathias . Froehlich]

From: Mathias Fröhlich 

That seems to be lost somewhere. Is needed for correct outside begin/end
detection in display list compilation. And is needed for correct aliasing
in dlists restablished in the next changes.

Signed-off-by: Mathias Fröhlich 
---
 src/mesa/vbo/vbo_save_api.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/mesa/vbo/vbo_save_api.c b/src/mesa/vbo/vbo_save_api.c
index f9f0e641a5d..b33dfa5fd8e 100644
--- a/src/mesa/vbo/vbo_save_api.c
+++ b/src/mesa/vbo/vbo_save_api.c
@@ -1198,6 +1198,8 @@ vbo_save_NotifyBegin(struct gl_context *ctx, GLenum mode,
struct vbo_save_context *save = &vbo_context(ctx)->save;
const GLuint i = save->prim_count++;

+   ctx->Driver.CurrentSavePrimitive = mode;
+
assert(i < save->prim_max);
save->prims[i].mode = mode & VBO_SAVE_PRIM_MODE_MASK;
save->prims[i].begin = 1;
--
2.20.1

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

[Mesa-dev] [PATCH 05/10] mesa: Remove the now unused _NEW_ARRAY state change flag.

[Mathias . Froehlich]

From: Mathias Fröhlich 

Is no longer used, so we have less occasions where NewState is non zero.

Signed-off-by: Mathias Fröhlich 
---
 src/mesa/drivers/dri/i965/brw_state_upload.c |  1 -
 src/mesa/main/arrayobj.c |  1 -
 src/mesa/main/attrib.c   |  1 -
 src/mesa/main/debug.c|  3 +--
 src/mesa/main/mtypes.h   |  2 +-
 src/mesa/main/varray.c   | 17 -
 6 files changed, 2 insertions(+), 23 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_state_upload.c 
b/src/mesa/drivers/dri/i965/brw_state_upload.c
index 5743fd5b8ae..938b9defeda 100644
--- a/src/mesa/drivers/dri/i965/brw_state_upload.c
+++ b/src/mesa/drivers/dri/i965/brw_state_upload.c
@@ -355,7 +355,6 @@ static struct dirty_bit_map mesa_bits[] = {
DEFINE_BIT(_NEW_TRANSFORM),
DEFINE_BIT(_NEW_VIEWPORT),
DEFINE_BIT(_NEW_TEXTURE_STATE),
-   DEFINE_BIT(_NEW_ARRAY),
DEFINE_BIT(_NEW_RENDERMODE),
DEFINE_BIT(_NEW_BUFFERS),
DEFINE_BIT(_NEW_CURRENT_ATTRIB),
diff --git a/src/mesa/main/arrayobj.c b/src/mesa/main/arrayobj.c
index 63138096da6..a6d48f5ffed 100644
--- a/src/mesa/main/arrayobj.c
+++ b/src/mesa/main/arrayobj.c
@@ -1049,7 +1049,6 @@ bind_vertex_array(struct gl_context *ctx, GLuint id, bool 
no_error)
 */
_mesa_set_draw_vao(ctx, ctx->Array._EmptyVAO, 0);

-   ctx->NewState |= _NEW_ARRAY;
_mesa_reference_vao(ctx, &ctx->Array.VAO, newObj);
 }

diff --git a/src/mesa/main/attrib.c b/src/mesa/main/attrib.c
index fd130857179..fe6c5a00460 100644
--- a/src/mesa/main/attrib.c
+++ b/src/mesa/main/attrib.c
@@ -1839,7 +1839,6 @@ _mesa_PopClientAttrib(void)
(struct gl_array_attrib *) node->data;
 restore_array_attrib(ctx, &ctx->Array, attr);
 free_array_attrib_data(ctx, attr);
-ctx->NewState |= _NEW_ARRAY;
 break;
  }
  default:
diff --git a/src/mesa/main/debug.c b/src/mesa/main/debug.c
index b1fa1f067ff..db11ae35a25 100644
--- a/src/mesa/main/debug.c
+++ b/src/mesa/main/debug.c
@@ -73,7 +73,7 @@ void
 _mesa_print_state( const char *msg, GLuint state )
 {
_mesa_debug(NULL,
-  "%s: (0x%x) %s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s\n",
+  "%s: (0x%x) %s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s\n",
   msg,
   state,
   (state & _NEW_MODELVIEW)   ? "ctx->ModelView, " : "",
@@ -96,7 +96,6 @@ _mesa_print_state( const char *msg, GLuint state )
   (state & _NEW_TRANSFORM)   ? "ctx->Transform, " : "",
   (state & _NEW_VIEWPORT)? "ctx->Viewport, " : "",
(state & _NEW_TEXTURE_STATE)   ? "ctx->Texture(State), " : "",
-  (state & _NEW_ARRAY)   ? "ctx->Array, " : "",
   (state & _NEW_RENDERMODE)  ? "ctx->RenderMode, " : "",
   (state & _NEW_BUFFERS) ? "ctx->Visual, ctx->DrawBuffer,, " : 
"");
 }
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index abe91699a81..0ca87561f05 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -,7 +,7 @@ struct gl_matrix_stack
 #define _NEW_TRANSFORM (1u << 17)  /**< gl_context::Transform */
 #define _NEW_VIEWPORT  (1u << 18)  /**< gl_context::Viewport */
 #define _NEW_TEXTURE_STATE (1u << 19)  /**< gl_context::Texture (states 
only) */
-#define _NEW_ARRAY (1u << 20)  /**< gl_context::Array */
+/* gap */
 #define _NEW_RENDERMODE(1u << 21)  /**< gl_context::RenderMode, etc */
 #define _NEW_BUFFERS   (1u << 22)  /**< gl_context::Visual, 
DrawBuffer, */
 #define _NEW_CURRENT_ATTRIB(1u << 23)  /**< gl_context::Current */
diff --git a/src/mesa/main/varray.c b/src/mesa/main/varray.c
index e6057c7f881..fad0c227d49 100644
--- a/src/mesa/main/varray.c
+++ b/src/mesa/main/varray.c
@@ -179,8 +179,6 @@ _mesa_vertex_attrib_binding(struct gl_context *ctx,
   array->BufferBindingIndex = bindingIndex;

   vao->NewArrays |= vao->Enabled & array_bit;
-  if (vao == ctx->Array.VAO)
- ctx->NewState |= _NEW_ARRAY;
}
 }

@@ -217,8 +215,6 @@ _mesa_bind_vertex_buffer(struct gl_context *ctx,
   }

   vao->NewArrays |= vao->Enabled & binding->_BoundArrays;
-  if (vao == ctx->Array.VAO)
- ctx->NewState |= _NEW_ARRAY;
}
 }

@@ -240,8 +236,6 @@ vertex_binding_divisor(struct gl_context *ctx,
if (binding->InstanceDivisor != divisor) {
   binding->InstanceDivisor = divisor;
   vao->NewArrays |= vao->Enabled & binding->_BoundArrays;
-  if (vao == ctx->Array.VAO)
- ctx->NewState |= _NEW_ARRAY;
}
 }

@@ -360,8 +354,6 @@ _mesa_update_array_format(struct gl_context *ctx,
normalized, integer, doubles);

vao->NewArrays |= vao->Enabled & VERT_BIT(attrib);
-   if (vao == ctx->Array.VAO)
-  ctx->NewState |= _NEW_ARRAY;
 }

 /**
@@ -1098,9 +1090,6 @@ _mesa_enable_vertex_array_attribs(struct gl_context *ctx,
   vao->Enabled |

[Mesa-dev] [PATCH 10/10] mesa: Leave aliasing of vertex and generic0 attribute to the dlist code.

[Mathias . Froehlich]

From: Mathias Fröhlich 

Now that dlist compilation again knows if it is inside glBegin/glEnd,
we can leave the decision if aliasing should occur to the vertex attribute
setter functions instead of doing that at glArrayElement time.

Signed-off-by: Mathias Fröhlich 
---
 src/mesa/main/api_arrayelt.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/src/mesa/main/api_arrayelt.c b/src/mesa/main/api_arrayelt.c
index 31184657399..7b540c92efd 100644
--- a/src/mesa/main/api_arrayelt.c
+++ b/src/mesa/main/api_arrayelt.c
@@ -1440,10 +1440,7 @@ _mesa_array_element(struct gl_context *ctx, GLint elt)
   const gl_vert_attrib attrib = VERT_ATTRIB_GENERIC0;
   const struct gl_array_attributes *array = &vao->VertexAttrib[attrib];
   const void *src = attrib_src(vao, array, elt);
-  /* Use glVertex(v) instead of glVertexAttrib(0, v) to be sure it's
-   * issued as the last (provoking) attribute).
-   */
-  func_nv(&array->Format)(0, src);
+  func_arb(&array->Format)(0, src);
} else if (vao->Enabled & VERT_BIT_POS) {
   const gl_vert_attrib attrib = VERT_ATTRIB_POS;
   const struct gl_array_attributes *array = &vao->VertexAttrib[attrib];
--
2.20.1

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

[Mesa-dev] [PATCH 01/10] mesa: Factor out index function that will have multiple use.

[Mathias . Froehlich]

From: Mathias Fröhlich 

For access to glArrayElement methods factor out a function to
get the table lookup index for normalized/integer/double access.
The function will be used in the next patch at least twice.

Signed-off-by: Mathias Fröhlich 
---
 src/mesa/main/api_arrayelt.c | 29 ++---
 1 file changed, 18 insertions(+), 11 deletions(-)

diff --git a/src/mesa/main/api_arrayelt.c b/src/mesa/main/api_arrayelt.c
index 1c086bbcda4..3f16e18b44d 100644
--- a/src/mesa/main/api_arrayelt.c
+++ b/src/mesa/main/api_arrayelt.c
@@ -90,6 +90,23 @@ TYPE_IDX(GLenum t)
 }


+/*
+ * Convert normalized/integer/double to the range [0, 3].
+ */
+static inline int
+NORM_IDX(const struct gl_vertex_format *vformat)
+{
+   if (vformat->Doubles)
+  return 3;
+   else if (vformat->Integer)
+  return 2;
+   else if (vformat->Normalized)
+  return 1;
+   else
+  return 0;
+}
+
+
 bool
 _ae_is_state_dirty(struct gl_context *ctx)
 {
@@ -1610,7 +1627,6 @@ _ae_update_state(struct gl_context *ctx)
   if (vao->Enabled & VERT_BIT_GENERIC(i)) {
  struct gl_array_attributes *attribArray =
 &vao->VertexAttrib[VERT_ATTRIB_GENERIC(i)];
- GLint intOrNorm;
  at->array = attribArray;
  at->binding = &vao->BufferBinding[attribArray->BufferBindingIndex];
  /* Note: we can't grab the _glapi_Dispatch->VertexAttrib1fvNV
@@ -1618,16 +1634,7 @@ _ae_update_state(struct gl_context *ctx)
   * change from one execution of _ae_ArrayElement() to
   * the next.  Doing so caused UT to break.
   */
- if (at->array->Format.Doubles)
-intOrNorm = 3;
- else if (at->array->Format.Integer)
-intOrNorm = 2;
- else if (at->array->Format.Normalized)
-intOrNorm = 1;
- else
-intOrNorm = 0;
-
- at->func = AttribFuncsARB[intOrNorm]
+ at->func = AttribFuncsARB[NORM_IDX(&at->array->Format)]
 [at->array->Format.Size-1]
 [TYPE_IDX(at->array->Format.Type)];

--
2.20.1

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

[Mesa-dev] [PATCH 09/10] mesa: Correct the is_vertex_position decision for dlists.

[Mathias . Froehlich]

From: Mathias Fröhlich 

We have to use _mesa_inside_dlist_begin_end instead of
_mesa_inside_begin_end to see if we are inside a glBegin/glEnd block in
case of display lists.
So split the is_vertex_position function used in vertex attribute processing
into a imm and dlist variant and use the appropriate _mesa_inside_begin_end
variant.

Signed-off-by: Mathias Fröhlich 
---
 src/mesa/vbo/vbo_attrib_tmp.h | 14 --
 src/mesa/vbo/vbo_exec_api.c   | 14 ++
 src/mesa/vbo/vbo_save_api.c   | 14 ++
 3 files changed, 28 insertions(+), 14 deletions(-)

diff --git a/src/mesa/vbo/vbo_attrib_tmp.h b/src/mesa/vbo/vbo_attrib_tmp.h
index 796b3883633..5c4beb540bf 100644
--- a/src/mesa/vbo/vbo_attrib_tmp.h
+++ b/src/mesa/vbo/vbo_attrib_tmp.h
@@ -522,20 +522,6 @@ TAG(MultiTexCoord4fv)(GLenum target, const GLfloat * v)
 }


-/**
- * If index=0, does glVertexAttrib*() alias glVertex() to emit a vertex?
- * It depends on a few things, including whether we're inside or outside
- * of glBegin/glEnd.
- */
-static inline bool
-is_vertex_position(const struct gl_context *ctx, GLuint index)
-{
-   return (index == 0 &&
-   _mesa_attr_zero_aliases_vertex(ctx) &&
-   _mesa_inside_begin_end(ctx));
-}
-
-
 static void GLAPIENTRY
 TAG(VertexAttrib1fARB)(GLuint index, GLfloat x)
 {
diff --git a/src/mesa/vbo/vbo_exec_api.c b/src/mesa/vbo/vbo_exec_api.c
index 749a5ebe65a..5b1549d96de 100644
--- a/src/mesa/vbo/vbo_exec_api.c
+++ b/src/mesa/vbo/vbo_exec_api.c
@@ -457,6 +457,20 @@ vbo_exec_begin_vertices(struct gl_context *ctx)
 }


+/**
+ * If index=0, does glVertexAttrib*() alias glVertex() to emit a vertex?
+ * It depends on a few things, including whether we're inside or outside
+ * of glBegin/glEnd.
+ */
+static inline bool
+is_vertex_position(const struct gl_context *ctx, GLuint index)
+{
+   return (index == 0 &&
+   _mesa_attr_zero_aliases_vertex(ctx) &&
+   _mesa_inside_begin_end(ctx));
+}
+
+
 /**
  * This macro is used to implement all the glVertex, glColor, glTexCoord,
  * glVertexAttrib, etc functions.
diff --git a/src/mesa/vbo/vbo_save_api.c b/src/mesa/vbo/vbo_save_api.c
index b33dfa5fd8e..d378bdb058d 100644
--- a/src/mesa/vbo/vbo_save_api.c
+++ b/src/mesa/vbo/vbo_save_api.c
@@ -979,6 +979,20 @@ reset_vertex(struct gl_context *ctx)
 }


+/**
+ * If index=0, does glVertexAttrib*() alias glVertex() to emit a vertex?
+ * It depends on a few things, including whether we're inside or outside
+ * of glBegin/glEnd.
+ */
+static inline bool
+is_vertex_position(const struct gl_context *ctx, GLuint index)
+{
+   return (index == 0 &&
+   _mesa_attr_zero_aliases_vertex(ctx) &&
+   _mesa_inside_dlist_begin_end(ctx));
+}
+
+

 #define ERROR(err)   _mesa_compile_error(ctx, err, __func__);

--
2.20.1

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

[Mesa-dev] [PATCH 07/10] mesa: Remove the _glapi_table argument from _mesa_array_element.

[Mathias . Froehlich]

From: Mathias Fröhlich 

The value is now unused.

Signed-off-by: Mathias Fröhlich 
---
 src/mesa/main/api_arrayelt.c |  8 +++-
 src/mesa/main/api_arrayelt.h |  3 +--
 src/mesa/vbo/vbo_save_api.c  | 17 +++--
 3 files changed, 11 insertions(+), 17 deletions(-)

diff --git a/src/mesa/main/api_arrayelt.c b/src/mesa/main/api_arrayelt.c
index 48b2d9b2357..31184657399 100644
--- a/src/mesa/main/api_arrayelt.c
+++ b/src/mesa/main/api_arrayelt.c
@@ -1412,8 +1412,7 @@ attrib_src(const struct gl_vertex_array_object *vao,


 void
-_mesa_array_element(struct gl_context *ctx,
-struct _glapi_table *disp, GLint elt)
+_mesa_array_element(struct gl_context *ctx, GLint elt)
 {
const struct gl_vertex_array_object *vao = ctx->Array.VAO;
GLbitfield mask;
@@ -1464,21 +1463,20 @@ void GLAPIENTRY
 _ae_ArrayElement(GLint elt)
 {
GET_CURRENT_CONTEXT(ctx);
-   const struct _glapi_table * const disp = GET_DISPATCH();
struct gl_vertex_array_object *vao;

/* If PrimitiveRestart is enabled and the index is the RestartIndex
 * then we call PrimitiveRestartNV and return.
 */
if (ctx->Array.PrimitiveRestart && (elt == ctx->Array.RestartIndex)) {
-  CALL_PrimitiveRestartNV((struct _glapi_table *)disp, ());
+  CALL_PrimitiveRestartNV(GET_DISPATCH(), ());
   return;
}

vao = ctx->Array.VAO;
_mesa_vao_map_arrays(ctx, vao, GL_MAP_READ_BIT);

-   _mesa_array_element(ctx, (struct _glapi_table *)disp, elt);
+   _mesa_array_element(ctx, elt);

_mesa_vao_unmap_arrays(ctx, vao);
 }
diff --git a/src/mesa/main/api_arrayelt.h b/src/mesa/main/api_arrayelt.h
index eea229f0487..6c2ece81134 100644
--- a/src/mesa/main/api_arrayelt.h
+++ b/src/mesa/main/api_arrayelt.h
@@ -32,8 +32,7 @@

 struct _glapi_table;

-extern void _mesa_array_element(struct gl_context *ctx,
-struct _glapi_table *disp, GLint elt);
+extern void _mesa_array_element(struct gl_context *ctx, GLint elt);
 extern void GLAPIENTRY _ae_ArrayElement( GLint elt );

 extern void
diff --git a/src/mesa/vbo/vbo_save_api.c b/src/mesa/vbo/vbo_save_api.c
index de0be4e3324..f9f0e641a5d 100644
--- a/src/mesa/vbo/vbo_save_api.c
+++ b/src/mesa/vbo/vbo_save_api.c
@@ -1331,7 +1331,7 @@ _save_OBE_DrawArrays(GLenum mode, GLint start, GLsizei 
count)
vbo_save_NotifyBegin(ctx, mode, true);

for (i = 0; i < count; i++)
-  _mesa_array_element(ctx, GET_DISPATCH(), start + i);
+  _mesa_array_element(ctx, start + i);
CALL_End(GET_DISPATCH(), ());

_mesa_vao_unmap_arrays(ctx, vao);
@@ -1373,7 +1373,7 @@ _save_OBE_MultiDrawArrays(GLenum mode, const GLint *first,


 static void
-array_element(struct gl_context *ctx, struct _glapi_table *disp,
+array_element(struct gl_context *ctx,
   GLint basevertex, GLuint elt, unsigned index_size)
 {
/* Section 10.3.5 Primitive Restart:
@@ -1387,11 +1387,11 @@ array_element(struct gl_context *ctx, struct 
_glapi_table *disp,
 */
if (ctx->Array._PrimitiveRestart &&
elt == _mesa_primitive_restart_index(ctx, index_size)) {
-  CALL_PrimitiveRestartNV(disp, ());
+  CALL_PrimitiveRestartNV(GET_DISPATCH(), ());
   return;
}

-   _mesa_array_element(ctx, disp, basevertex + elt);
+   _mesa_array_element(ctx, basevertex + elt);
 }


@@ -1440,18 +1440,15 @@ _save_OBE_DrawElementsBaseVertex(GLenum mode, GLsizei 
count, GLenum type,
switch (type) {
case GL_UNSIGNED_BYTE:
   for (i = 0; i < count; i++)
- array_element(ctx, GET_DISPATCH(), basevertex,
-   ((GLubyte *) indices)[i], 1);
+ array_element(ctx, basevertex, ((GLubyte *) indices)[i], 1);
   break;
case GL_UNSIGNED_SHORT:
   for (i = 0; i < count; i++)
- array_element(ctx, GET_DISPATCH(), basevertex,
-   ((GLushort *) indices)[i], 2);
+ array_element(ctx, basevertex, ((GLushort *) indices)[i], 2);
   break;
case GL_UNSIGNED_INT:
   for (i = 0; i < count; i++)
- array_element(ctx, GET_DISPATCH(), basevertex,
-   ((GLuint *) indices)[i], 4);
+ array_element(ctx, basevertex, ((GLuint *) indices)[i], 4);
   break;
default:
   _mesa_error(ctx, GL_INVALID_ENUM, "glDrawElements(type)");
--
2.20.1

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

[Mesa-dev] [PATCH 00/10] Get rid of _NEW_ARRAY finally.

[Mathias . Froehlich]

From: Mathias Fröhlich 

Hi,

This is the second part of the _NEW_ARRAY mesa state bit removal.
The code basically unifies the _mesa_array_element implementation
by using a cheap to compute vertex attribute setter selection together
with the bitmask iteration trick. Once this is in place we can remove
gl_context::aelt_context and wipe behind that removal.
Then there is a bug in dlist compilation that I found during the changes.
Fixing that enables even a bit further cleanup and better separation
between dlist compilation and the glArrayElement implementation.

The series went through intels CI system and did not flag any unexpected
failures.

Please review

thanks and best

Mathias


Mathias Fröhlich (10):
  mesa: Factor out index function that will have multiple use.
  mesa: Use glVertexAttrib*NV functions for fixed function attribs.
  mesa: Implement _mesa_array_element by walking enabled arrays.
  mesa: Rip out now unused gl_context::aelt_context.
  mesa: Remove the now unused _NEW_ARRAY state change flag.
  mesa: Constify static const array in api_arrayelt.c
  mesa: Remove the _glapi_table argument from _mesa_array_element.
  mesa: Set CurrentSavePrimitive in vbo_save_NotifyBegin.
  mesa: Correct the is_vertex_position decision for dlists.
  mesa: Leave aliasing of vertex and generic0 attribute to the dlist
code.

 src/mesa/drivers/dri/i965/brw_state_upload.c |   1 -
 src/mesa/drivers/dri/r200/r200_context.c |   1 -
 src/mesa/drivers/dri/radeon/radeon_context.c |   1 -
 src/mesa/main/api_arrayelt.c | 391 +++
 src/mesa/main/api_arrayelt.h |   7 +-
 src/mesa/main/arrayobj.c |   1 -
 src/mesa/main/attrib.c   |   1 -
 src/mesa/main/debug.c|   3 +-
 src/mesa/main/mtypes.h   |   3 +-
 src/mesa/main/varray.c   |  17 -
 src/mesa/vbo/vbo_attrib_tmp.h|  14 -
 src/mesa/vbo/vbo_context.c   |  15 -
 src/mesa/vbo/vbo_exec.c  |  11 -
 src/mesa/vbo/vbo_exec_api.c  |  14 +
 src/mesa/vbo/vbo_save_api.c  |  33 +-
 15 files changed, 104 insertions(+), 409 deletions(-)

--
2.20.1

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

[Mesa-dev] [PATCH 02/10] mesa: Use glVertexAttrib*NV functions for fixed function attribs.

[Mathias . Froehlich]

From: Mathias Fröhlich 

In the glArrayElement implementation, use glVertexAttrib*NV type
functions for fixed function attributes. We do the same in display
execution when the list is replayed using immediate mode attribute
functions. By that use a loop to walk the attributes.

Signed-off-by: Mathias Fröhlich 
---
 src/mesa/main/api_arrayelt.c | 185 ++-
 1 file changed, 28 insertions(+), 157 deletions(-)

diff --git a/src/mesa/main/api_arrayelt.c b/src/mesa/main/api_arrayelt.c
index 3f16e18b44d..d46c8d14b68 100644
--- a/src/mesa/main/api_arrayelt.c
+++ b/src/mesa/main/api_arrayelt.c
@@ -117,89 +117,6 @@ _ae_is_state_dirty(struct gl_context *ctx)
 #define NUM_TYPES 8


-static const int ColorFuncs[2][NUM_TYPES] = {
-   {
-  _gloffset_Color3bv,
-  _gloffset_Color3ubv,
-  _gloffset_Color3sv,
-  _gloffset_Color3usv,
-  _gloffset_Color3iv,
-  _gloffset_Color3uiv,
-  _gloffset_Color3fv,
-  _gloffset_Color3dv,
-   },
-   {
-  _gloffset_Color4bv,
-  _gloffset_Color4ubv,
-  _gloffset_Color4sv,
-  _gloffset_Color4usv,
-  _gloffset_Color4iv,
-  _gloffset_Color4uiv,
-  _gloffset_Color4fv,
-  _gloffset_Color4dv,
-   },
-};
-
-static const int VertexFuncs[3][NUM_TYPES] = {
-   {
-  -1,
-  -1,
-  _gloffset_Vertex2sv,
-  -1,
-  _gloffset_Vertex2iv,
-  -1,
-  _gloffset_Vertex2fv,
-  _gloffset_Vertex2dv,
-   },
-   {
-  -1,
-  -1,
-  _gloffset_Vertex3sv,
-  -1,
-  _gloffset_Vertex3iv,
-  -1,
-  _gloffset_Vertex3fv,
-  _gloffset_Vertex3dv,
-   },
-   {
-  -1,
-  -1,
-  _gloffset_Vertex4sv,
-  -1,
-  _gloffset_Vertex4iv,
-  -1,
-  _gloffset_Vertex4fv,
-  _gloffset_Vertex4dv,
-   },
-};
-
-static const int IndexFuncs[NUM_TYPES] = {
-   -1,
-   _gloffset_Indexubv,
-   _gloffset_Indexsv,
-   -1,
-   _gloffset_Indexiv,
-   -1,
-   _gloffset_Indexfv,
-   _gloffset_Indexdv,
-};
-
-static const int NormalFuncs[NUM_TYPES] = {
-   _gloffset_Normal3bv,
-   -1,
-   _gloffset_Normal3sv,
-   -1,
-   _gloffset_Normal3iv,
-   -1,
-   _gloffset_Normal3fv,
-   _gloffset_Normal3dv,
-};
-
-/* Note: _gloffset_* for these may not be a compile-time constant. */
-static int SecondaryColorFuncs[NUM_TYPES];
-static int FogCoordFuncs[NUM_TYPES];
-
-
 /**
  ** GL_NV_vertex_program
  **/
@@ -1508,25 +1425,6 @@ _ae_create_context(struct gl_context *ctx)
if (ctx->aelt_context)
   return GL_TRUE;

-   /* These _gloffset_* values may not be compile-time constants */
-   SecondaryColorFuncs[0] = _gloffset_SecondaryColor3bv;
-   SecondaryColorFuncs[1] = _gloffset_SecondaryColor3ubv;
-   SecondaryColorFuncs[2] = _gloffset_SecondaryColor3sv;
-   SecondaryColorFuncs[3] = _gloffset_SecondaryColor3usv;
-   SecondaryColorFuncs[4] = _gloffset_SecondaryColor3iv;
-   SecondaryColorFuncs[5] = _gloffset_SecondaryColor3uiv;
-   SecondaryColorFuncs[6] = _gloffset_SecondaryColor3fvEXT;
-   SecondaryColorFuncs[7] = _gloffset_SecondaryColor3dv;
-
-   FogCoordFuncs[0] = -1;
-   FogCoordFuncs[1] = -1;
-   FogCoordFuncs[2] = -1;
-   FogCoordFuncs[3] = -1;
-   FogCoordFuncs[4] = -1;
-   FogCoordFuncs[5] = -1;
-   FogCoordFuncs[6] = _gloffset_FogCoordfvEXT;
-   FogCoordFuncs[7] = _gloffset_FogCoorddv;
-
ctx->aelt_context = calloc(1, sizeof(AEcontext));
if (!ctx->aelt_context)
   return GL_FALSE;
@@ -1562,52 +1460,10 @@ _ae_update_state(struct gl_context *ctx)
struct gl_vertex_array_object *vao = ctx->Array.VAO;

/* conventional vertex arrays */
-   if (vao->Enabled & VERT_BIT_COLOR_INDEX) {
-  aa->array = &vao->VertexAttrib[VERT_ATTRIB_COLOR_INDEX];
-  aa->binding = &vao->BufferBinding[aa->array->BufferBindingIndex];
-  aa->offset = IndexFuncs[TYPE_IDX(aa->array->Format.Type)];
-  aa++;
-   }
-
-   if (vao->Enabled & VERT_BIT_EDGEFLAG) {
-  aa->array = &vao->VertexAttrib[VERT_ATTRIB_EDGEFLAG];
-  aa->binding = &vao->BufferBinding[aa->array->BufferBindingIndex];
-  aa->offset = _gloffset_EdgeFlagv;
-  aa++;
-   }
-
-   if (vao->Enabled & VERT_BIT_NORMAL) {
-  aa->array = &vao->VertexAttrib[VERT_ATTRIB_NORMAL];
-  aa->binding = &vao->BufferBinding[aa->array->BufferBindingIndex];
-  aa->offset = NormalFuncs[TYPE_IDX(aa->array->Format.Type)];
-  aa++;
-   }
-
-   if (vao->Enabled & VERT_BIT_COLOR0) {
-  aa->array = &vao->VertexAttrib[VERT_ATTRIB_COLOR0];
-  aa->binding = &vao->BufferBinding[aa->array->BufferBindingIndex];
-  aa->offset = 
ColorFuncs[aa->array->Format.Size-3][TYPE_IDX(aa->array->Format.Type)];
-  aa++;
-   }
-
-   if (vao->Enabled & VERT_BIT_COLOR1) {
-  aa->array = &vao->VertexAttrib[VERT_ATTRIB_COLOR1];
-  aa->binding = &vao->BufferBinding[aa->array->BufferBindingIndex];
-  aa->offset = SecondaryColorFuncs[TYPE_IDX(aa->array->Format.Type)];
-  aa++;
-   }
-
-   if (vao->Enabled & VERT_BIT_FOG) {
-  aa->array = &vao->VertexAttrib[VERT_ATTRIB_FOG];
-  aa->binding = 

[Mesa-dev] [AppVeyor] mesa staging/19.1 #10990 failed

[AppVeyor]

Build mesa 10990 failed


Commit 492e828848 by Samuel Pitoiset on 4/26/2019 10:49 AM:

ac: tidy up ac_build_llvm8_tbuffer_{load,store}\n\nFor consistency with ac_build_llvm8_buffer_{load,store}_common\nhelpers and that will help a bit for removing the vec3 restriction.\n\nSigned-off-by: Samuel Pitoiset \nReviewed-by: Bas Nieuwenhuizen 


Configure your notification preferences

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

[Mesa-dev] [Bug 110530] [CTS] dEQP-VK.ycbcr.format.g8_b8_r8_3plane_420* reports VM faults on Vega10

[bugzilla-daemon]

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

Samuel Pitoiset  changed:

   What|Removed |Added

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

--- Comment #1 from Samuel Pitoiset  ---
Fixed with
https://cgit.freedesktop.org/mesa/mesa/commit/?id=aab201635e85c3cb374638f806a79c977921d72d

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

[Mesa-dev] [Bug 110540] [AMD TAHITI XT] valve artifact broken

[bugzilla-daemon]

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

--- Comment #3 from Samuel Pitoiset  ---
Can you try with latest master? We fixed some ycbcr failures lately.

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

Re: [Mesa-dev] [PATCH] glsl: work around MinGW 7.x compiler bug

[Eric Engestrom]

On 2019-05-01 at 21:35, Brian Paul  wrote:
> I'm not sure what triggered this, but building with
> scons platform=windows toolchain=crossmingw machine=x86 build=profile
> with MinGW g++ 7.3 or 7.4 causes an internal compiler error.
> 
> We can work around it by forcing -O1 optimization.
> ---
>  src/compiler/glsl/builtin_variables.cpp | 15 +++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/src/compiler/glsl/builtin_variables.cpp 
> b/src/compiler/glsl/builtin_variables.cpp
> index 17ee80c..1b9963a 100644
> --- a/src/compiler/glsl/builtin_variables.cpp
> +++ b/src/compiler/glsl/builtin_variables.cpp
> @@ -21,6 +21,21 @@
>   * DEALINGS IN THE SOFTWARE.
>   */
>  
> +
> +/**
> + * Building this file with MinGW g++ 7.3 or 7.4 with:
> + *   scons platform=windows toolchain=crossmingw machine=x86 
> build=profile
> + * triggers an internal compiler error.
> + * Overriding the optimization level to -O1 works around the issue.
> + * MinGW 5.3.1 does not seem to have the bug, neither does 8.3.  So 
> for now
> + * we're simply testing for version 7.x here.
> + */
> +#if defined(__MINGW32__) && __GNUC__ == 7
> +#warning "disabling optimizations for this file to work around 
> compiler bug in MiGW gcc 7.x"

Typo: s/MiGW/MinGW/

> +#pragma GCC optimize("O1")
> +#endif
> +
> +
>  #include "ir.h"
>  #include "ir_builder.h"
>  #include "linker.h"
> -- 
> 1.8.5.6
> 
> ___
> 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] anv: fix alphaToCoverage when there is no color attachment

[Iago Toral]

On Tue, 2019-04-30 at 17:29 -0500, Jason Ekstrand wrote:
> On Tue, Apr 30, 2019 at 4:36 AM Iago Toral  wrote:
> > Hi Jason,
> > 
> > it seems that this was never addressed so I'll try to take it from
> > here. A couple of comments regarding your feedback:
> > 
> > We always setup a null render target if we don't have any, so I
> > think that part of the patch is not necessary. I checked that
> > simply making sure that we don't remove the output when we are in
> > this situation is enough to make the tests pass.
> > 
> > However, you make another suggestion below  about only writing the
> > Alpha channel in that case. I understand that you meant this as an
> > optimization for this particular scenario since it is not really a
> > functional requirement for this to work, since we are using a null
> > render target in this case. Anyway, I have been looking  into it
> > and  I believe that implementing this would be slightly trickier
> > since we'd also need to make sure that we compile a different
> > version of the shader when it is used with a valid color attachment
> > (since in that case we do need to emit the RGB writes). Therefore,
> > it would require that we include a bit for this sceneario
> > in  brw_wm_prog_key. We could do that very easily at the same
> > moment we make the decision that we need a null render target
> > in anv_pipeline_link_fs() (where we are already editing
> > nr_color_regions and  color_outputs_valid in the key). If we do it
> > like this, then we can implement the optimization trivially when we
> > handle implement nir_intrinsic_store_output in brw_fs_nir.cpp by
> > simply skipping the MOVs for the RGB components when this key flag
> > is set. Does this sound good to you?
> 
> Yeah, it may not be worth it.  It was just a thought.  Let's focus on
> plugging the current hole.  The optimization can come later.

Makes sense to me, I'll send the patch as soon as it comes back from
Jenkins.
> I'm not sure that we would actually need a bit.  This would be an
> implicit combination of the color_outputs_valid and dual-src blending
> which is already part of the shader.  That might need a big fat
> comment though. :)

I think that might not be enough because when we setup the null render
target for this case we also set the bit for RT 0 in
color_outputs_valid, so we end up with the same color_outputs_valid as
in the case where we actually have a valid RT and we want the RGB
writes.
> --Jason
>  
> > Iago
> > On Fri, 2019-03-22 at 10:06 -0500, Jason Ekstrand wrote:
> > > I'm confused.  Don't we always have a NULL render target at
> > > location 0?  Is the problem really that we need the NULL render
> > > target or is it that we can't throw away the alpha component of
> > > the RT write in the shader?  If it's that we can't throw away the
> > > alpha component of the RT write, then I'd suggest a slightly
> > > different workaround which does just that. We can rewrite the
> > > store_output intrinsic (or store_var; not sure which it is at
> > > that point) so that it writes vec4(undef, undef, undef, alpha) to
> > > help with linking but then keep the one output var so it we still
> > > get the write in the shader.
> > > 
> > > 
> > > 
> > > On Mon, Mar 4, 2019 at 4:56 AM Samuel Iglesias Gonsálvez <
> > > sigles...@igalia.com> wrote:
> > > > Still unreviewed.
> > > > 
> > > > 
> > > > 
> > > > Sam
> > > > 
> > > > 
> > > > 
> > > > On Thu, 2019-02-21 at 12:08 +0100, Samuel Iglesias Gonsálvez
> > > > wrote:
> > > > 
> > > > > CL#3532 added a test for alpha to coverage without a color
> > > > 
> > > > > attachment.
> > > > 
> > > > > First the test draws a primitive with alpha 0 and a subpass
> > > > with only
> > > > 
> > > > > a depth buffer. No writes to a depth buffer are expected.
> > > > Then a
> > > > 
> > > > > second draw with a color buffer and the same depth buffer is
> > > > done to
> > > > 
> > > > > verify the depth buffer still has the original clear values.
> > > > 
> > > > > 
> > > > 
> > > > > This behavior is not explicitly forbidden by the Vulkan spec,
> > > > so
> > > > 
> > > > > it seems it is allowed.
> > > > 
> > > > > 
> > > > 
> > > > > When there is no color attachment for a given output, we
> > > > discard it
> > > > 
> > > > > so at the end we have an FS assembly like:
> > > > 
> > > > > 
> > > > 
> > > > > Native code for unnamed fragment shader (null)
> > > > 
> > > > > SIMD16 shader: 1 instructions. 0 loops. 4 cycles. 0:0
> > > > spills:fills.
> > > > 
> > > > > Promoted 0 constants. Compacted 16 to 16 bytes (0%)
> > > > 
> > > > >START B0 (4 cycles)
> > > > 
> > > > > sendc(16)   null<1>UW   g120<0,1,0>F0x90031000
> > > > 
> > > > > 
> > > > 
> > > > > render MsgDesc: RT write SIMD16 LastRT Surface = 0 mlen 8
> > > > rlen 0 {
> > > > 
> > > > > align1 1H EOT };
> > > > 
> > > > > 
> > > > 
> > > > > As g120 is not initialized, we see random writes to the depth
> > > > buffer
> > > > 
> > > > > due to the alphaToCoverage enablement. This commi

[Mesa-dev] [Bug 110573] Mesa vulkan-radeon 19.0.3 system freeze and visual artifacts (RADV)

[bugzilla-daemon]

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

--- Comment #4 from Samuel Pitoiset  ---
This is really weird, the fix is actually for LLVM 8 and it just breaks...

-- 
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] Mesa (staging/19.0): radv: enable descriptor indexing capabilities

[Samuel Pitoiset]

On 5/2/19 2:27 AM, Bas Nieuwenhuizen wrote:

Well, kinda a fix.  Jason noticed that there were parts of the ext I
disabled but apparently implementations are required to enable them
(see 028ce527395642b68612d10c6030be5d4706a65e).

Though, I think this was backported under the assumption that
028ce527395642b68612d10c6030be5d4706a65e also was, and it looks like I
did not CC that to 19.0, partially because of a lot of dependencies.
Might make more sense to disable the ext on the 19.0 branch.

Yes, that seems better to disable it. Can you send a patch?



On Wed, May 1, 2019 at 9:56 PM Samuel Pitoiset
 wrote:

wait what? Are we backporting a new feature into a stable branch? Do we
really need that?

On 5/1/19 6:35 PM, GitLab Mirror wrote:

Module: Mesa
Branch: staging/19.0
Commit: a1cdab7bd4ecad7c1c518fb8430613a7559d4f9d
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=a1cdab7bd4ecad7c1c518fb8430613a7559d4f9d

Author: Juan A. Suarez Romero 
Date:   Mon Apr 29 17:05:13 2019 +0200

radv: enable descriptor indexing capabilities

This enables the remaining capabilities in SPV_EXT_descriptor_indexing.

Fixes: 0e10790558b "radv: Enable VK_EXT_descriptor_indexing."

Reviewed-by: Jason Ekstrand 
Reviewed-by: Bas Nieuwenhuizen 
(cherry picked from commit 06c9d7f9f94d9ab44a2b6148d9b5ec3f76c8d3db)

---

   src/amd/vulkan/radv_shader.c | 2 ++
   1 file changed, 2 insertions(+)

diff --git a/src/amd/vulkan/radv_shader.c b/src/amd/vulkan/radv_shader.c
index 2b45576bd41..7dd2fa2105c 100644
--- a/src/amd/vulkan/radv_shader.c
+++ b/src/amd/vulkan/radv_shader.c
@@ -222,6 +222,8 @@ radv_shader_compile_to_nir(struct radv_device *device,
   .lower_ubo_ssbo_access_to_offsets = true,
   .caps = {
   .descriptor_array_dynamic_indexing = true,
+ .descriptor_array_non_uniform_indexing = true,
+ .descriptor_indexing = true,
   .device_group = true,
   .draw_parameters = true,
   .float64 = true,

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

___
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