Re: [Mesa-dev] [PATCH 3/3] mesa: skip validation of legality of size/type queries for format queries

[Alejandro Piñeiro]

On 30/01/18 01:24, Roland Scheidegger wrote:
> Am 29.01.2018 um 17:03 schrieb Alejandro Piñeiro:
>> On 29/01/18 16:38, Roland Scheidegger wrote:
>>> Am 29.01.2018 um 09:09 schrieb Alejandro Piñeiro:
 On 27/01/18 12:09, Roland Scheidegger wrote:
> Am 27.01.2018 um 09:52 schrieb Alejandro Piñeiro:
>> On 27/01/18 01:59, srol...@vmware.com wrote:
>>> From: Roland Scheidegger 
>>>
>>> The size/type query is always legal (if we made it that far).
>>> This causes a difference for GL_TEXTURE_BUFFER - the reason is that 
>>> these
>>> parameters are valid only with GetTexLevelParameter() if gl 3.1 is 
>>> supported,
>>> but not if only ARB_texture_buffer_object is supported.
>>> However, while the spec says that these queries return "the same 
>>> information
>>> as querying GetTexLevelParameter" I believe we're not expected to 
>>> return just
>>> zeros here. By definition, these pnames are always valid (unlike for the
>>> GetTexLevelParameter() function which would return an error without GL 
>>> 3.1),
>>> so returning 0 but no error makes no sense to me.
>> But in general, AFAIU, this is how GetInternalFormat works. The
>> extension only raises an error if their API is not used properly.  But
>> not if the combination being requested doesn't make sense.
>>
>> For example, the pname GET_TEXTURE_IMAGE_FORMAT, would return the same
>> value that using GetTexImage. But if the resource is not supported by
>> GetTextImage, it should return NONE, but not raising an error. So for
>> example, you could use as target GL_RENDERBUFFER for
>> GET_TEXTURE_IMAGE_FORMAT query, and  just get a GL_NONE, but no an
>> error. While that one would raise an error on GetTexImage.
> This is correct, but I don't think that's really comparable. The case
> you cited is if something isn't supported - this is not the case here at
> all, if some format with TEXTURE_BUFFER is supported, we're just lying
> about the size/type because ARB_tbo made these properties non-queryable.
 Are not queryable for specific GL versions, as you said. For me it would
 be inconsistent if you are able to query the tbo sizes with
 GetInternalformat, but not with gettexlevelparameter on a given opengl
 version. Raising or not an error should not be a reason to discard it,
 because as I said, ARB_internalformat_query2 in general avoid raising GL
 error for unsupported cases.

 What I'm trying to say is that the current implementation is not wrong,
 just more literal to the current spec wording. Yes, perhaps too literal
 in some cases. But I also have the feeling that your patch pushes too
 much on the supposed original intention of this query.

 Having said so, this is just my opinion. So if anyone else agrees with
 your interpretation of the desired behaviour on this query, I don't
 think that it is a big deal to include this patch.
>>> There's actually a specific bit in the internalformat_query2 which makes
>>> me think is a pretty good hint that "return the same information as
>>> querying GetTeXLevelParameter" should not be taken literally and is just
>>> informational: The part about GL_INTERNALFORMAT_STENCIL_TYPE - since the
>>> language applies to that as well, however an equivalent pname for
>>> GetTeXLevelParameter does not even exist.
>> Hmm, good point. And as the code is right now, it filters the target
>> based on being supported or not by GetTexLevelParameter, but then (if
>> the target is not filtered), returns a value for STENCIL_TYPE, even
>> although GetTexLevelParameter doesn't have a equivalent pname/query.
>>
>>> And imho even if you take it literally, it's ambiguos at best, since the
>>> same paragraph doesn't just mention the "return the same as..." part,
>>> but also explicitly says that 0/none is returned if the format is
>>> unsupported, which contradicts this part (well you can of course
>>> interpret it that this is not a sufficient condition to return 0, but I
>>> don't think that was the intention).
>> In general, this spec has a lot (too much?) of room for interpretation.
> Yes, I agree with that. (Of course it doesn't help that the dependency
> section is absolutely massive.)
>
>>> I agree though my interpretation is more in line what I think was
>>> probably the intention and can't directly be derived from the wording -
>>> in general however you can always use all pname/target bits and get
>>> valid answers iff the format/pname combination is supported, so this not
>>> working texture_buffer would be very awkward imho.
>>>
>>> But maybe someone more familiar with the spec could chime in...
>> I will open a spec issue for this. Meanwhile they reply:
>>
>> Reviewed-by: Alejandro Piñeiro 
>>
>> (Although I would appreciate some additional info on the commit message)
> Ok, thanks for reviewing, I added 

Re: [Mesa-dev] [PATCH v4] anv/blorp: multisample resolve all attachment layers

[Iago Toral]

On Wed, 2018-02-21 at 09:58 -0800, Nanley Chery wrote:
> On Wed, Feb 21, 2018 at 09:18:49AM +0100, Iago Toral Quiroga wrote:
> > We were only resolving the first.
> > 
> > v2:
> >   - Do not require that the number of layers on dst and src are an
> > exact match, it is okay if the dst has more layers so long as
> > it has at least the same that we are going to resolve.
> >   - Do not always resolve array_len layers, we should resolve
> > only from base_array_layer to array_len.
> > 
> > v3:
> >   - v2 was assuming that array_len represented the total number of
> > layers in the image, but it represents the number of layers
> > starting at the base array ayer.
> > 
> > v4:
> >  - The number of layers to resolve should be taken from the
> >framebuffer (Nanley).
> > 
> > Fixes new CTS tests for multisampled layered rendering:
> > dEQP-VK.renderpass.multisample_resolve.layers_*
> > ---
> >  src/intel/vulkan/anv_blorp.c | 31 ---
> >  1 file changed, 20 insertions(+), 11 deletions(-)
> > 
> > diff --git a/src/intel/vulkan/anv_blorp.c
> > b/src/intel/vulkan/anv_blorp.c
> > index bee51e0cdf..efa2ced7f2 100644
> > --- a/src/intel/vulkan/anv_blorp.c
> > +++ b/src/intel/vulkan/anv_blorp.c
> > @@ -1329,25 +1329,34 @@ anv_cmd_buffer_resolve_subpass(struct
> > anv_cmd_buffer *cmd_buffer)
> >VK_IMAGE_ASPECT_COLOR_BIT,
> >ANV_IMAGE_LAYOUT_EXPLICIT_AU
> > X,
> >dst_aux_usage, _surf);
> > +
> > + uint32_t base_src_layer = src_iview-
> > >planes[0].isl.base_array_layer;
> > + uint32_t base_dst_layer = dst_iview-
> > >planes[0].isl.base_array_layer;
> > +
> 
> I'm not sure we benefit from storing these fields in new variables,
> but
> it's not a big issue. 
> With or without the new variables, this patch is
> Reviewed-by: Nanley Chery 

Thanks Nanley.

I don't have a strong reason to keep the variables but I prefer to keep
them for two reasons: without them the call to 
anv_cmd_buffer_mark_image_written was stretching a bit over 80
characters long and I also find it easier to read something like
'base_dst_layer' than something like 'dst_iview-
>planes[0].isl.base_array_layer' when browsing the code.

> 
> > + assert(src_iview->planes[0].isl.array_len >= fb->layers);
> > + assert(dst_iview->planes[0].isl.array_len >= fb->layers);
> > +
> >   anv_cmd_buffer_mark_image_written(cmd_buffer, dst_iview-
> > >image,
> > VK_IMAGE_ASPECT_COLOR_B
> > IT,
> > dst_surf.aux_usage,
> > dst_iview-
> > >planes[0].isl.base_level,
> > -   dst_iview-
> > >planes[0].isl.base_array_layer, 1);
> > +   base_dst_layer, fb-
> > >layers);
> >  
> >   assert(!src_iview->image->format->can_ycbcr);
> >   assert(!dst_iview->image->format->can_ycbcr);
> >  
> > - resolve_surface(,
> > - _surf,
> > - src_iview->planes[0].isl.base_level,
> > - src_iview-
> > >planes[0].isl.base_array_layer,
> > - _surf,
> > - dst_iview->planes[0].isl.base_level,
> > - dst_iview-
> > >planes[0].isl.base_array_layer,
> > - render_area.offset.x,
> > render_area.offset.y,
> > - render_area.offset.x,
> > render_area.offset.y,
> > - render_area.extent.width,
> > render_area.extent.height);
> > + for (uint32_t i = 0; i < fb->layers; i++) {
> > +resolve_surface(,
> > +_surf,
> > +src_iview->planes[0].isl.base_level,
> > +base_src_layer + i,
> > +_surf,
> > +dst_iview->planes[0].isl.base_level,
> > +base_dst_layer + i,
> > +render_area.offset.x,
> > render_area.offset.y,
> > +render_area.offset.x,
> > render_area.offset.y,
> > +render_area.extent.width,
> > render_area.extent.height);
> > + }
> >}
> >  
> >blorp_batch_finish();
> > -- 
> > 2.14.1
> > 
> 
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v1 0/7] Implement commont gralloc_handle_t in libdrm

[Tomasz Figa]

On Thu, Feb 22, 2018 at 7:23 AM, Rob Herring  wrote:
>
> On Wed, Feb 21, 2018 at 1:22 PM, Emil Velikov  
> wrote:
> > On 21 February 2018 at 18:50, Rob Herring  wrote:
> >> On Wed, Feb 21, 2018 at 10:01 AM, Emil Velikov  
> >> wrote:
> >>> Hi all,
> >>>
> >>> Pardon for dropping in late. I think you've got nearly everything
> >>> settled down, just sharing a couple of ideas.
> >>>
> >>> On 21 February 2018 at 04:19, Tomasz Figa  wrote:
>  On Wed, Feb 21, 2018 at 4:03 AM, Rob Herring  wrote:
> > On Tue, Feb 20, 2018 at 4:26 AM, Tomasz Figa  wrote:
> >>>
>  It is actually incorrect to have the same device FD used for different
>  screens, if PRIME is used, due to GEM namespace issues, e.g.
>  - screen 0: drmPrimeFdToHandle(buffer A) -> 1,
>  - screen 1: drmPrimeFdToHandle(buffer A) -> 1 (same handle in same
>  namespace, due to semantics of PRIME import and same device FD used),
>  - screen 0: GEM_CLOSE(handle = 1),
>  - screen 1 still thinks handle 1 is valid...
> 
>  So this only works for control nodes using flink only. (Or if you
>  always use libdrm_* for BO management and your particular
>  implementation does its own GEM handle reference counting, but that's
>  not guaranted.)
> 
> >>> Had a sneaky feeling that that != 1 will be returned for screen 1's
> >>> drmPrimeFdToHandle call.
> >>> Regardless, moving to DRI3/dmabuf-only setups is the [really] long
> >>> term plan, I think.
> >>> I don't know if we can achieve it outside of CrOS - with all the
> >>> distros building and shipping things in subtly different manner.
> >>
> >> It's already possible for Android.
> >>
> > Great. Feel free to join me in pushing distributions forward ;-)
>
> I'll trade you Android for any thing else. :)
>
>
> > How would that work if you support different GPUs in one image?
> 
>  It wouldn't and that's why I prefer probing available devices.
> 
>  For Chrome OS, we don't include GPU bits in system image, but rather
>  have vendor images built separately for each board (although sharing
>  any possible contents across board family, chipset, GPU type and so
>  on), so we can have a custom .rc script (which sets a property) as
>  well. It would even be possible to have paths hardcoded, but that
>  would be prone to probe ordering issues which, with software fallback,
>  could be actually not obvious to notice, and so we'd rather not go
>  this route.
> 
>  So I'd agree here that we should revisit probing.
> 
> >>> As you pointed out the fallback is not a good idea.
> >>
> >> Software fallback is a desired feature. Basing it on the path is the bad 
> >> idea.
> >>
> > Even considering that a) the transition is not obvious and b) it will
> > cause serve performance degradation?
> > For development and prototyping purposes it's great. For production
> > ... very few users will like the abysmal performance :-\
>
> Better slow than not booting. There are also usecases such as running
> in the cloud for running tests where performance is not too important.
> AOSP has "devices" now that build images for GCE. CrOS does something
> similar from what Tomasz has said.
>
> Software rendering should be the easy case, but some reason is not.

I think software fallback can be done reasonably right. Perhaps it
could kick in by default only if there is no matching hardware driver?
If there is a matching driver, but initialization fails, perhaps it
could make sense to boil out.

>
> >>> Plus, as the drm
> >>> node vary, one can use an Android property and match it to the info.
> >>> from drmGetDevice2.
> >>> Say the HW bus location, (sub)device PCIID, other.
> >>
> >> That generally doesn't work for non-x86.
> >>
> > Errr... wrong. If PCI bus does not exist (some arm boards to have them
> > though), one can use usb, platform or host1x specifics.
> > If those are not enough, suggestions are welcome.
>
> How does this work across platforms? Feels like just punting the
> problem to someone else. Currently it's in gralloc, so let's move it
> to init to set a property? Also, I'm not sure that setting a property
> is going to work in the future with Treble.
>
> But suppose we do make it a property. Does it really matter that the
> property be a h/w device id and not be the device path? Whatever sets
> the property can figure out the path based on bus info or whatever
> logic it wants. And then for my simple uses, that logic can just be
> hardcoded (as we have today).

Well, we could have property that forces the probing logic to only
match requested driver or bus ID. If no property is set, it could use
the first one that matches any driver, which should cover 90% of the
systems.

Best regards,
Tomasz
___
mesa-dev mailing list

[Mesa-dev] [PATCH 05/13] vbo: Implement method to track the inputs array.

[Mathias . Froehlich]

From: Mathias Fröhlich 

Provided the _DrawVAO and the derived state that is maintained if we have
the _DrawVAO set, implement a method to incrementally update the array of
gl_vertex_array input pointers.

v2: Add some more comments.
Rename _vbo_array_init to _vbo_init_inputs.
Rename vbo_context::arrays to vbo_context::draw_arrays.

Signed-off-by: Mathias Fröhlich 
---
 src/mesa/vbo/vbo.h | 36 
 src/mesa/vbo/vbo_context.c |  1 +
 src/mesa/vbo/vbo_exec.c| 83 ++
 src/mesa/vbo/vbo_private.h |  2 ++
 4 files changed, 122 insertions(+)

diff --git a/src/mesa/vbo/vbo.h b/src/mesa/vbo/vbo.h
index d594ba8f6a..345aa6b0d2 100644
--- a/src/mesa/vbo/vbo.h
+++ b/src/mesa/vbo/vbo.h
@@ -254,6 +254,42 @@ vbo_sw_primitive_restart(struct gl_context *ctx,
  const struct _mesa_index_buffer *ib,
  struct gl_buffer_object *indirect);
 
+
+/**
+ * Utility that tracks and updates the current array entries.
+ */
+struct vbo_inputs
+{
+   /**
+* Array of inputs to be set to the _DrawArrays pointer.
+* The array contains pointers into the _DrawVAO and to the vbo modules
+* current values. The array of pointers is updated incrementally
+* based on the current and vertex_processing_mode values below.
+*/
+   const struct gl_vertex_array *inputs[VERT_ATTRIB_MAX];
+   /** Those VERT_BIT_'s where the inputs array point to current values. */
+   GLbitfield current;
+   /** Store which aliasing current values - generics or materials - are set. 
*/
+   gl_vertex_processing_mode vertex_processing_mode;
+};
+
+
+/**
+ * Initialize inputs.
+ */
+void
+_vbo_init_inputs(struct vbo_inputs *inputs);
+
+
+/**
+ * Update the gl_vertex_array array inside the vbo_inputs structure
+ * provided the current _VPMode, the provided vao and
+ * the vao's enabled arrays filtered by the filter bitmask.
+ */
+void
+_vbo_update_inputs(struct gl_context *ctx, struct vbo_inputs *inputs);
+
+
 void GLAPIENTRY
 _es_Color4f(GLfloat r, GLfloat g, GLfloat b, GLfloat a);
 
diff --git a/src/mesa/vbo/vbo_context.c b/src/mesa/vbo/vbo_context.c
index 5bc6bf0acd..7b1ebc68f1 100644
--- a/src/mesa/vbo/vbo_context.c
+++ b/src/mesa/vbo/vbo_context.c
@@ -234,6 +234,7 @@ _vbo_CreateContext(struct gl_context *ctx)
init_legacy_currval(ctx);
init_generic_currval(ctx);
init_mat_currval(ctx);
+   _vbo_init_inputs(>draw_arrays);
vbo_set_indirect_draw_func(ctx, vbo_draw_indirect_prims);
 
/* make sure all VBO_ATTRIB_ values can fit in an unsigned byte */
diff --git a/src/mesa/vbo/vbo_exec.c b/src/mesa/vbo/vbo_exec.c
index 372d0237aa..69a150c78b 100644
--- a/src/mesa/vbo/vbo_exec.c
+++ b/src/mesa/vbo/vbo_exec.c
@@ -27,6 +27,7 @@
 
 
 #include "main/glheader.h"
+#include "main/arrayobj.h"
 #include "main/mtypes.h"
 #include "main/api_arrayelt.h"
 #include "main/vtxfmt.h"
@@ -240,3 +241,85 @@ vbo_merge_prims(struct _mesa_prim *p0, const struct 
_mesa_prim *p1)
p0->count += p1->count;
p0->end = p1->end;
 }
+
+
+void
+_vbo_init_inputs(struct vbo_inputs *inputs)
+{
+   inputs->current = 0;
+   inputs->vertex_processing_mode = VP_MODE_FF;
+}
+
+
+/**
+ * Update the vbo_inputs's arrays to point to the vao->_VertexArray arrays
+ * according to the 'enable' bitmask.
+ * \param enable  bitfield of VERT_BIT_x flags.
+ */
+static inline void
+update_vao_inputs(struct gl_context *ctx,
+  struct vbo_inputs *inputs, GLbitfield enable)
+{
+   const struct gl_vertex_array_object *vao = ctx->Array._DrawVAO;
+
+   /* Make sure we process only arrays enabled in the VAO */
+   assert((enable & ~_mesa_get_vao_vp_inputs(vao)) == 0);
+
+   /* Fill in the client arrays from the VAO */
+   const GLubyte *const map = _mesa_vao_attribute_map[vao->_AttributeMapMode];
+   const struct gl_vertex_array *array = vao->_VertexArray;
+   const struct gl_vertex_array **iarray = >inputs[0];
+   while (enable) {
+  const int attr = u_bit_scan();
+  iarray[attr] = [map[attr]];
+   }
+}
+
+
+/**
+ * Update the vbo_inputs's arrays to point to the vbo->currval arrays
+ * according to the 'current' bitmask.
+ * \param current  bitfield of VERT_BIT_x flags.
+ */
+static inline void
+update_current_inputs(struct gl_context *ctx,
+  struct vbo_inputs *inputs, GLbitfield current)
+{
+   gl_vertex_processing_mode mode = ctx->VertexProgram._VPMode;
+
+   /* All previously non current array pointers need update. */
+   GLbitfield mask = current & ~inputs->current;
+   /* On mode change, the slots aliasing with materials need update too */
+   if (mode != inputs->vertex_processing_mode)
+  mask |= current & VERT_BIT_MAT_ALL;
+
+   struct vbo_context *vbo = vbo_context(ctx);
+   const struct gl_vertex_array *const currval = >currval[0];
+   const struct gl_vertex_array **iarray = >inputs[0];
+   const GLubyte *const map = _vbo_attribute_alias_map[mode];
+   while 

[Mesa-dev] [PATCH 06/13] vbo: Use _DrawVAO for array type draw commands.

[Mathias . Froehlich]

From: Mathias Fröhlich 

Switch over to use the _DrawVAO for all the array type draws.
The _DrawVAO needs to be set before we enter _mesa_update_state, so move
setting the draw method in front of the first call to _mesa_update_state
which is in turn called from the *validate*Draw* calls. Using the
gl_vertex_array_object::_Enabled bitmask, gl_vertex_program_state::_VPMode
and gl_vertex_array_object::_AttributeMapMode we can already set
varying_vp_inputs before we call _mesa_update_state the first time.
Thus remove duplicate state validation.

v2: Update comments.

Signed-off-by: Mathias Fröhlich 
---
 src/mesa/vbo/vbo_context.c|   8 ++-
 src/mesa/vbo/vbo_exec.h   |   6 --
 src/mesa/vbo/vbo_exec_array.c | 159 +-
 3 files changed, 100 insertions(+), 73 deletions(-)

diff --git a/src/mesa/vbo/vbo_context.c b/src/mesa/vbo/vbo_context.c
index 7b1ebc68f1..222bdcf1f2 100644
--- a/src/mesa/vbo/vbo_context.c
+++ b/src/mesa/vbo/vbo_context.c
@@ -206,11 +206,15 @@ vbo_exec_invalidate_state(struct gl_context *ctx)
struct vbo_exec_context *exec = >exec;
 
if (ctx->NewState & (_NEW_PROGRAM | _NEW_ARRAY)) {
-  if (!exec->validating)
- exec->array.recalculate_inputs = GL_TRUE;
+  exec->array.recalculate_inputs = GL_TRUE;
 
   _ae_invalidate_state(ctx);
}
+   /* If _mesa_update_state is called in a non draw code path,
+* changes in the VAO need to be captured.
+*/
+   if (ctx->Array.VAO->NewArrays)
+  exec->array.recalculate_inputs = GL_TRUE;
 
if (ctx->NewState & _NEW_EVAL)
   exec->eval.recalculate_maps = GL_TRUE;
diff --git a/src/mesa/vbo/vbo_exec.h b/src/mesa/vbo/vbo_exec.h
index 7e00d45de0..b00045c7c8 100644
--- a/src/mesa/vbo/vbo_exec.h
+++ b/src/mesa/vbo/vbo_exec.h
@@ -76,7 +76,6 @@ struct vbo_exec_context
struct gl_context *ctx;
GLvertexformat vtxfmt;
GLvertexformat vtxfmt_noop;
-   GLboolean validating; /**< if we're in the middle of state validation */
 
struct {
   struct gl_buffer_object *bufferobj;
@@ -119,11 +118,6 @@ struct vbo_exec_context
} eval;
 
struct {
-  /* Arrays and current values manipulated according to program
-   * mode, etc.  These are the attributes as seen by vertex
-   * programs:
-   */
-  const struct gl_vertex_array *inputs[VERT_ATTRIB_MAX];
   GLboolean recalculate_inputs;
} array;
 
diff --git a/src/mesa/vbo/vbo_exec_array.c b/src/mesa/vbo/vbo_exec_array.c
index 0c3c9017b1..5029937336 100644
--- a/src/mesa/vbo/vbo_exec_array.c
+++ b/src/mesa/vbo/vbo_exec_array.c
@@ -319,29 +319,14 @@ print_draw_arrays(struct gl_context *ctx,
 
 
 /**
- * Set the vbo->exec->inputs[] pointers to point to the enabled
- * vertex arrays.  This depends on the current vertex program/shader
- * being executed because of whether or not generic vertex arrays
- * alias the conventional vertex arrays.
- * For arrays that aren't enabled, we set the input[attrib] pointer
- * to point at a zero-stride current value "array".
+ * Return a filter mask for the net enabled vao arrays.
+ * This is to mask out arrays that would otherwise supersed required current
+ * values for the fixed function shaders for example.
  */
-static void
-recalculate_input_bindings(struct gl_context *ctx)
+static GLbitfield
+enabled_filter(const struct gl_context *ctx)
 {
-   struct vbo_context *vbo = vbo_context(ctx);
-   struct vbo_exec_context *exec = >exec;
-   const struct gl_vertex_array_object *vao = ctx->Array.VAO;
-   const struct gl_vertex_array *vertexAttrib = vao->_VertexArray;
-   const struct gl_vertex_array **inputs = >array.inputs[0];
-
-   /* May shuffle the position and generic0 bits around */
-   GLbitfield vp_inputs = _mesa_get_vao_vp_inputs(vao);
-
-   const gl_vertex_processing_mode processing_mode
-  = ctx->VertexProgram._VPMode;
-   const GLubyte * const map = _vbo_attribute_alias_map[processing_mode];
-   switch (processing_mode) {
+   switch (ctx->VertexProgram._VPMode) {
case VP_MODE_FF:
   /* When no vertex program is active (or the vertex program is generated
* from fixed-function state).  We put the material values into the
@@ -349,9 +334,7 @@ recalculate_input_bindings(struct gl_context *ctx)
* slots from the enabled arrays so that the current material values
* are pulled instead of the vao arrays.
*/
-  vp_inputs &= VERT_BIT_FF_ALL;
-
-  break;
+  return VERT_BIT_FF_ALL;
 
case VP_MODE_SHADER:
   /* There are no shaders in OpenGL ES 1.x, so this code path should be
@@ -360,40 +343,20 @@ recalculate_input_bindings(struct gl_context *ctx)
*/
   assert(ctx->API != API_OPENGLES);
 
-  /* In the compatibility profile of desktop OpenGL, the generic[0]
-   * attribute array aliases and overrides the legacy position array.
-   * Otherwise, legacy attributes available in the legacy slots,
-   * generic attributes in the 

[Mesa-dev] [PATCH 07/13] mesa: Add flush_vertices to _mesa_{enable, disable}_vertex_array_attrib.

[Mathias . Froehlich]

From: Mathias Fröhlich 

We will need the flush_vertices argument later in this series.

Signed-off-by: Mathias Fröhlich 
---
 src/mesa/drivers/common/meta.c | 18 +++---
 src/mesa/main/enable.c |  4 ++--
 src/mesa/main/varray.c | 30 +++---
 src/mesa/main/varray.h |  4 ++--
 4 files changed, 34 insertions(+), 22 deletions(-)

diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
index 0cb2ef450e..3d9833dabb 100644
--- a/src/mesa/drivers/common/meta.c
+++ b/src/mesa/drivers/common/meta.c
@@ -350,7 +350,7 @@ _mesa_meta_setup_vertex_objects(struct gl_context *ctx,
  _mesa_bind_vertex_buffer(ctx, array_obj, VERT_ATTRIB_GENERIC(0),
   *buf_obj, 0, sizeof(struct vertex));
  _mesa_enable_vertex_array_attrib(ctx, array_obj,
-  VERT_ATTRIB_GENERIC(0));
+  VERT_ATTRIB_GENERIC(0), true);
  if (texcoord_size > 0) {
 _mesa_update_array_format(ctx, array_obj, VERT_ATTRIB_GENERIC(1),
   texcoord_size, GL_FLOAT, GL_RGBA,
@@ -359,7 +359,7 @@ _mesa_meta_setup_vertex_objects(struct gl_context *ctx,
 _mesa_bind_vertex_buffer(ctx, array_obj, VERT_ATTRIB_GENERIC(1),
  *buf_obj, 0, sizeof(struct vertex));
 _mesa_enable_vertex_array_attrib(ctx, array_obj,
- VERT_ATTRIB_GENERIC(1));
+ VERT_ATTRIB_GENERIC(1), true);
  }
   } else {
  _mesa_update_array_format(ctx, array_obj, VERT_ATTRIB_POS,
@@ -368,7 +368,8 @@ _mesa_meta_setup_vertex_objects(struct gl_context *ctx,
offsetof(struct vertex, x));
  _mesa_bind_vertex_buffer(ctx, array_obj, VERT_ATTRIB_POS,
   *buf_obj, 0, sizeof(struct vertex));
- _mesa_enable_vertex_array_attrib(ctx, array_obj, VERT_ATTRIB_POS);
+ _mesa_enable_vertex_array_attrib(ctx, array_obj,
+  VERT_ATTRIB_POS, true);
 
  if (texcoord_size > 0) {
 _mesa_update_array_format(ctx, array_obj, VERT_ATTRIB_TEX(0),
@@ -377,7 +378,8 @@ _mesa_meta_setup_vertex_objects(struct gl_context *ctx,
   offsetof(struct vertex, tex));
 _mesa_bind_vertex_buffer(ctx, array_obj, VERT_ATTRIB_TEX(0),
  *buf_obj, 0, sizeof(struct vertex));
-_mesa_enable_vertex_array_attrib(ctx, array_obj, 
VERT_ATTRIB_TEX(0));
+_mesa_enable_vertex_array_attrib(ctx, array_obj,
+ VERT_ATTRIB_TEX(0), true);
  }
 
  if (color_size > 0) {
@@ -387,7 +389,8 @@ _mesa_meta_setup_vertex_objects(struct gl_context *ctx,
   offsetof(struct vertex, r));
 _mesa_bind_vertex_buffer(ctx, array_obj, VERT_ATTRIB_COLOR0,
  *buf_obj, 0, sizeof(struct vertex));
-_mesa_enable_vertex_array_attrib(ctx, array_obj, 
VERT_ATTRIB_COLOR0);
+_mesa_enable_vertex_array_attrib(ctx, array_obj,
+ VERT_ATTRIB_COLOR0, true);
  }
   }
} else {
@@ -3345,7 +3348,7 @@ _mesa_meta_DrawTex(struct gl_context *ctx, GLfloat x, 
GLfloat y, GLfloat z,
 offsetof(struct vertex, x));
   _mesa_bind_vertex_buffer(ctx, array_obj, VERT_ATTRIB_POS,
drawtex->buf_obj, 0, sizeof(struct vertex));
-  _mesa_enable_vertex_array_attrib(ctx, array_obj, VERT_ATTRIB_POS);
+  _mesa_enable_vertex_array_attrib(ctx, array_obj, VERT_ATTRIB_POS, true);
 
 
   for (i = 0; i < ctx->Const.MaxTextureUnits; i++) {
@@ -3356,7 +3359,8 @@ _mesa_meta_DrawTex(struct gl_context *ctx, GLfloat x, 
GLfloat y, GLfloat z,
offsetof(struct vertex, st[i]));
  _mesa_bind_vertex_buffer(ctx, array_obj, VERT_ATTRIB_TEX(i),
   drawtex->buf_obj, 0, sizeof(struct vertex));
- _mesa_enable_vertex_array_attrib(ctx, array_obj, VERT_ATTRIB_TEX(i));
+ _mesa_enable_vertex_array_attrib(ctx, array_obj,
+  VERT_ATTRIB_TEX(i), true);
   }
}
else {
diff --git a/src/mesa/main/enable.c b/src/mesa/main/enable.c
index 868b73ac68..7625a4c957 100644
--- a/src/mesa/main/enable.c
+++ b/src/mesa/main/enable.c
@@ -68,9 +68,9 @@ static void
 vao_state(struct gl_context *ctx, gl_vert_attrib attr, GLboolean state)
 {
if (state)
-  _mesa_enable_vertex_array_attrib(ctx, ctx->Array.VAO, attr);
+  _mesa_enable_vertex_array_attrib(ctx, ctx->Array.VAO, attr, true);
else
-  

[Mesa-dev] [PATCH 10/13] vbo: Implement tool functions for vbo specific VAO setup.

[Mathias . Froehlich]

From: Mathias Fröhlich 

Correct VBO_MATERIAL_SHIFT value.
The functions will be used next in this series.

Signed-off-by: Mathias Fröhlich 
---
 src/mesa/vbo/vbo_attrib.h  |  4 ++--
 src/mesa/vbo/vbo_private.h | 53 ++
 2 files changed, 55 insertions(+), 2 deletions(-)

diff --git a/src/mesa/vbo/vbo_attrib.h b/src/mesa/vbo/vbo_attrib.h
index fb178e17d6..0592d845ba 100644
--- a/src/mesa/vbo/vbo_attrib.h
+++ b/src/mesa/vbo/vbo_attrib.h
@@ -113,8 +113,8 @@ enum vbo_attrib {
  VBO_ATTRIB_LAST_MATERIAL - VBO_ATTRIB_FIRST_MATERIAL + 1)
 
 /** Shift to move legacy material attribs into generic slots */
-#define VBO_MATERIAL_SHIFT (VBO_ATTRIB_FIRST_MATERIAL - VBO_ATTRIB_GENERIC0)
-
+#define VBO_MATERIAL_SHIFT \
+   (VBO_ATTRIB_LAST_MATERIAL - VBO_ATTRIB_FIRST_MATERIAL + 1)
 
 
 
diff --git a/src/mesa/vbo/vbo_private.h b/src/mesa/vbo/vbo_private.h
index 2fda06dec6..2640f3e21f 100644
--- a/src/mesa/vbo/vbo_private.h
+++ b/src/mesa/vbo/vbo_private.h
@@ -36,6 +36,7 @@
 #include "vbo/vbo_exec.h"
 #include "vbo/vbo_save.h"
 #include "main/mtypes.h"
+#include "main/varray.h"
 
 
 struct _glapi_table;
@@ -172,4 +173,56 @@ void
 vbo_merge_prims(struct _mesa_prim *p0, const struct _mesa_prim *p1);
 
 
+/**
+ * Get the filter mask for vbo draws depending on the vertex_processing_mode.
+ */
+static inline GLbitfield
+_vbo_get_vao_filter(gl_vertex_processing_mode vertex_processing_mode)
+{
+   if (vertex_processing_mode == VP_MODE_FF) {
+  /* The materials mapped into the generic arrays */
+  return VERT_BIT_FF_ALL | VERT_BIT_MAT_ALL;
+   } else {
+  return VERT_BIT_ALL;
+   }
+}
+
+
+/**
+ * Translate the bitmask of VBO_ATTRIB_BITs to VERT_ATTRIB_BITS.
+ * Note that position/generic0 attribute aliasing is done
+ * generically in the VAO.
+ */
+static inline GLbitfield
+_vbo_get_vao_enabled_from_vbo(gl_vertex_processing_mode vertex_processing_mode,
+  GLbitfield64 enabled)
+{
+   if (vertex_processing_mode == VP_MODE_FF) {
+  /* The materials mapped into the generic arrays */
+  return (((GLbitfield)enabled) & VERT_BIT_FF_ALL)
+ | (((GLbitfield)(enabled >> VBO_MATERIAL_SHIFT)) & VERT_BIT_MAT_ALL);
+   } else {
+  return ((GLbitfield)enabled) & VERT_BIT_ALL;
+   }
+}
+
+
+/**
+ * Set the vertex attrib for vbo draw use.
+ */
+static inline void
+_vbo_set_attrib_format(struct gl_context *ctx,
+   struct gl_vertex_array_object *vao,
+   gl_vert_attrib attr, GLintptr buffer_offset,
+   GLubyte size, GLenum16 type, GLuint offset)
+{
+   const GLboolean integer = vbo_attrtype_to_integer_flag(type);
+   const GLboolean doubles = vbo_attrtype_to_double_flag(type);
+   _mesa_update_array_format(ctx, vao, attr, size, type, GL_RGBA,
+ GL_FALSE, integer, doubles, offset);
+   /* Ptr for userspace arrays */
+   vao->VertexAttrib[attr].Ptr = ADD_POINTERS(buffer_offset, offset);
+}
+
+
 #endif /* VBO_PRIVATE_H */
-- 
2.14.3

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

[Mesa-dev] [PATCH 13/13] vbo: Make use of _DrawVAO from the dlist code.

[Mathias . Froehlich]

From: Mathias Fröhlich 

Finally use an internal VAO to execute display list draws. Avoid
duplicate state validation for display list draws. Remove client arrays
previously used exclusively for display lists.

Signed-off-by: Mathias Fröhlich 
---
 src/mesa/vbo/vbo_save.c  |  37 ++--
 src/mesa/vbo/vbo_save.h  |   4 +-
 src/mesa/vbo/vbo_save_api.c  | 132 +--
 src/mesa/vbo/vbo_save_draw.c |  64 -
 4 files changed, 144 insertions(+), 93 deletions(-)

diff --git a/src/mesa/vbo/vbo_save.c b/src/mesa/vbo/vbo_save.c
index 19c40ec530..f106cf279a 100644
--- a/src/mesa/vbo/vbo_save.c
+++ b/src/mesa/vbo/vbo_save.c
@@ -27,6 +27,7 @@
 
 
 #include "main/mtypes.h"
+#include "main/arrayobj.h"
 #include "main/bufferobj.h"
 
 #include "vbo_private.h"
@@ -44,32 +45,8 @@ void vbo_save_init( struct gl_context *ctx )
 
vbo_save_api_init( save );
 
-   {
-  struct gl_vertex_array *arrays = save->arrays;
-  unsigned i;
-
-  memcpy(arrays, >currval[VBO_ATTRIB_POS],
- VERT_ATTRIB_FF_MAX * sizeof(arrays[0]));
-  for (i = 0; i < VERT_ATTRIB_FF_MAX; ++i) {
- struct gl_vertex_array *array;
- array = [VERT_ATTRIB_FF(i)];
- array->BufferObj = NULL;
- _mesa_reference_buffer_object(ctx, >BufferObj,
-   
vbo->currval[VBO_ATTRIB_POS+i].BufferObj);
-  }
-
-  memcpy(arrays + VERT_ATTRIB_GENERIC(0),
- >currval[VBO_ATTRIB_GENERIC0],
- VERT_ATTRIB_GENERIC_MAX * sizeof(arrays[0]));
-
-  for (i = 0; i < VERT_ATTRIB_GENERIC_MAX; ++i) {
- struct gl_vertex_array *array;
- array = [VERT_ATTRIB_GENERIC(i)];
- array->BufferObj = NULL;
- _mesa_reference_buffer_object(ctx, >BufferObj,
-   vbo->currval[VBO_ATTRIB_GENERIC0+i].BufferObj);
-  }
-   }
+   for (gl_vertex_processing_mode vpm = VP_MODE_FF; vpm < VP_MODE_MAX; ++vpm)
+  save->VAO[vpm] = NULL;
 
ctx->Driver.CurrentSavePrimitive = PRIM_OUTSIDE_BEGIN_END;
 }
@@ -79,7 +56,9 @@ void vbo_save_destroy( struct gl_context *ctx )
 {
struct vbo_context *vbo = vbo_context(ctx);
struct vbo_save_context *save = >save;
-   GLuint i;
+
+   for (gl_vertex_processing_mode vpm = VP_MODE_FF; vpm < VP_MODE_MAX; ++vpm)
+  _mesa_reference_vao(ctx, >VAO[vpm], NULL);
 
if (save->prim_store) {
   if ( --save->prim_store->refcount == 0 ) {
@@ -93,10 +72,6 @@ void vbo_save_destroy( struct gl_context *ctx )
  save->vertex_store = NULL;
   }
}
-
-   for (i = 0; i < VBO_ATTRIB_MAX; i++) {
-  _mesa_reference_buffer_object(ctx, >arrays[i].BufferObj, NULL);
-   }
 }
 
 
diff --git a/src/mesa/vbo/vbo_save.h b/src/mesa/vbo/vbo_save.h
index cb0bff2341..edbce3673d 100644
--- a/src/mesa/vbo/vbo_save.h
+++ b/src/mesa/vbo/vbo_save.h
@@ -66,6 +66,7 @@ struct vbo_save_vertex_list {
GLenum16 attrtype[VBO_ATTRIB_MAX];
GLuint offsets[VBO_ATTRIB_MAX];
GLuint vertex_size;  /**< size in GLfloats */
+   struct gl_vertex_array_object *VAO[VP_MODE_MAX];
 
/* Copy of the final vertex from node->vertex_store->bufferobj.
 * Keep this in regular (non-VBO) memory to avoid repeated
@@ -140,14 +141,13 @@ struct vbo_save_context {
struct gl_context *ctx;
GLvertexformat vtxfmt;
GLvertexformat vtxfmt_noop;  /**< Used if out_of_memory is true */
-   struct gl_vertex_array arrays[VBO_ATTRIB_MAX];
-   const struct gl_vertex_array *inputs[VBO_ATTRIB_MAX];
 
GLbitfield64 enabled; /**< mask of enabled vbo arrays. */
GLubyte attrsz[VBO_ATTRIB_MAX];  /**< 1, 2, 3 or 4 */
GLenum16 attrtype[VBO_ATTRIB_MAX];  /**< GL_FLOAT, GL_INT, etc */
GLubyte active_sz[VBO_ATTRIB_MAX];  /**< 1, 2, 3 or 4 */
GLuint vertex_size;  /**< size in GLfloats */
+   struct gl_vertex_array_object *VAO[VP_MODE_MAX];
 
GLboolean out_of_memory;  /**< True if last VBO allocation failed */
 
diff --git a/src/mesa/vbo/vbo_save_api.c b/src/mesa/vbo/vbo_save_api.c
index fb51bdb84e..1edf7b9dfa 100644
--- a/src/mesa/vbo/vbo_save_api.c
+++ b/src/mesa/vbo/vbo_save_api.c
@@ -68,6 +68,7 @@ USE OR OTHER DEALINGS IN THE SOFTWARE.
 
 
 #include "main/glheader.h"
+#include "main/arrayobj.h"
 #include "main/bufferobj.h"
 #include "main/context.h"
 #include "main/dlist.h"
@@ -79,6 +80,7 @@ USE OR OTHER DEALINGS IN THE SOFTWARE.
 #include "main/vtxfmt.h"
 #include "main/dispatch.h"
 #include "main/state.h"
+#include "main/varray.h"
 #include "util/bitscan.h"
 
 #include "vbo_noop.h"
@@ -411,6 +413,112 @@ convert_line_loop_to_strip(struct vbo_save_context *save,
 }
 
 
+/* Compare the present vao if it has the same setup. */
+static bool
+compare_vao(gl_vertex_processing_mode mode,
+const struct gl_vertex_array_object *vao,
+const struct gl_buffer_object *bo, GLintptr buffer_offset,
+GLuint stride, GLbitfield64 vao_enabled,
+const GLubyte 

[Mesa-dev] [PATCH 01/13] mesa: Provide an alternative to get_vp_mode()

[Mathias . Froehlich]

From: Mathias Fröhlich 

To get equivalent information than get_vp_mode(), track the vertex
processing mode in a per context variable at
gl_vertex_program_state::_VPMode.
This aims to replace get_vp_mode() as seen in the vbo module.
But instead of the get_vp_mode() implementation which only gives correct
answers past calling _mesa_update_state() this context variable is
immediately tracked when the vertex processing state is modified. The
correctness of this value is asserted on state validation.

With this in place we should be able to untangle the dependency with
varying_vp_inputs and state invalidation.

Signed-off-by: Mathias Fröhlich 
---
 src/mesa/drivers/common/meta.c |  2 ++
 src/mesa/main/arbprogram.c |  5 +
 src/mesa/main/context.c|  3 +++
 src/mesa/main/enable.c |  2 ++
 src/mesa/main/mtypes.h | 24 
 src/mesa/main/pipelineobj.c|  3 +++
 src/mesa/main/shaderapi.c  |  5 +
 src/mesa/main/state.c  | 23 +++
 src/mesa/main/state.h  |  7 +++
 src/mesa/program/program.c |  1 +
 10 files changed, 75 insertions(+)

diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
index cd898e26f6..0cb2ef450e 100644
--- a/src/mesa/drivers/common/meta.c
+++ b/src/mesa/drivers/common/meta.c
@@ -1012,6 +1012,8 @@ _mesa_meta_end(struct gl_context *ctx)
 
  _mesa_reference_pipeline_object(ctx, >Pipeline, NULL);
   }
+
+  _mesa_update_vertex_processing_mode(ctx);
}
 
if (state & MESA_META_STENCIL_TEST) {
diff --git a/src/mesa/main/arbprogram.c b/src/mesa/main/arbprogram.c
index 625dc667f8..b169bce0c5 100644
--- a/src/mesa/main/arbprogram.c
+++ b/src/mesa/main/arbprogram.c
@@ -37,6 +37,7 @@
 #include "main/mtypes.h"
 #include "main/arbprogram.h"
 #include "main/shaderapi.h"
+#include "main/state.h"
 #include "program/arbprogparse.h"
 #include "program/program.h"
 #include "program/prog_print.h"
@@ -133,6 +134,8 @@ _mesa_BindProgramARB(GLenum target, GLuint id)
   _mesa_reference_program(ctx, >FragmentProgram.Current, newProg);
}
 
+   _mesa_update_vertex_processing_mode(ctx);
+
/* Never null pointers */
assert(ctx->VertexProgram.Current);
assert(ctx->FragmentProgram.Current);
@@ -369,6 +372,8 @@ _mesa_ProgramStringARB(GLenum target, GLenum format, 
GLsizei len,
   }
}
 
+   _mesa_update_vertex_processing_mode(ctx);
+
if (ctx->_Shader->Flags & GLSL_DUMP) {
   const char *shader_type =
  target == GL_FRAGMENT_PROGRAM_ARB ? "fragment" : "vertex";
diff --git a/src/mesa/main/context.c b/src/mesa/main/context.c
index 79d3e39e92..0aa2e3639f 100644
--- a/src/mesa/main/context.c
+++ b/src/mesa/main/context.c
@@ -123,6 +123,7 @@
 #include "shared.h"
 #include "shaderobj.h"
 #include "shaderimage.h"
+#include "state.h"
 #include "util/debug.h"
 #include "util/disk_cache.h"
 #include "util/strtod.h"
@@ -1579,6 +1580,8 @@ handle_first_current(struct gl_context *ctx)
 
check_context_limits(ctx);
 
+   _mesa_update_vertex_processing_mode(ctx);
+
/* According to GL_MESA_configless_context the default value of
 * glDrawBuffers depends on the config of the first surface it is bound to.
 * For GLES it is always GL_BACK which has a magic interpretation.
diff --git a/src/mesa/main/enable.c b/src/mesa/main/enable.c
index f23673a6cd..868b73ac68 100644
--- a/src/mesa/main/enable.c
+++ b/src/mesa/main/enable.c
@@ -39,6 +39,7 @@
 #include "light.h"
 #include "mtypes.h"
 #include "enums.h"
+#include "state.h"
 #include "texstate.h"
 #include "varray.h"
 
@@ -919,6 +920,7 @@ _mesa_set_enable(struct gl_context *ctx, GLenum cap, 
GLboolean state)
 return;
  FLUSH_VERTICES(ctx, _NEW_PROGRAM);
  ctx->VertexProgram.Enabled = state;
+ _mesa_update_vertex_processing_mode(ctx);
  break;
   case GL_VERTEX_PROGRAM_POINT_SIZE_ARB:
  /* This was added with ARB_vertex_program, but it is also used with
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 7da3240da7..41df04d38d 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -2136,6 +2136,19 @@ typedef enum
 } gl_register_file;
 
 
+/**
+ * Current vertex processing mode: fixed function vs. shader.
+ * In reality, fixed function is probably implemented by a shader but that's
+ * not what we care about here.
+ */
+typedef enum
+{
+   VP_MODE_FF, /**< legacy / fixed function */
+   VP_MODE_SHADER, /**< ARB vertex program or GLSL vertex shader */
+   VP_MODE_MAX /**< for sizing arrays */
+} gl_vertex_processing_mode;
+
+
 /**
  * Base class for any kind of program object
  */
@@ -2362,6 +2375,17 @@ struct gl_vertex_program_state
struct gl_program_cache *Cache;
 
GLboolean _Overriden;
+
+   /**
+* If we have a vertex program, a TNL program or no program at all.
+* Note that this value should be kept up to date all the time,
+* 

[Mesa-dev] [PATCH 03/13] vbo: Remove get_vp_mode() and enum vp_mode.

[Mathias . Froehlich]

From: Mathias Fröhlich 

Is now unused.

Signed-off-by: Mathias Fröhlich 
---
 src/mesa/vbo/vbo_private.h | 27 ---
 1 file changed, 27 deletions(-)

diff --git a/src/mesa/vbo/vbo_private.h b/src/mesa/vbo/vbo_private.h
index e44a521b11..49922892e5 100644
--- a/src/mesa/vbo/vbo_private.h
+++ b/src/mesa/vbo/vbo_private.h
@@ -68,33 +68,6 @@ vbo_context(struct gl_context *ctx)
 }
 
 
-/**
- * Current vertex processing mode: fixed function vs. shader.
- * In reality, fixed function is probably implemented by a shader but that's
- * not what we care about here.
- */
-enum vp_mode {
-   VP_FF,/**< legacy / fixed function */
-   VP_SHADER, /**< ARB vertex program or GLSL vertex shader */
-   VP_MODE_MAX /**< for sizing arrays */
-};
-
-
-/**
- * Get current vertex processing mode (fixed function vs. shader).
- */
-static inline enum vp_mode
-get_vp_mode( struct gl_context *ctx )
-{
-   if (!ctx->VertexProgram._Current)
-  return VP_FF;
-   else if (ctx->VertexProgram._Current == ctx->VertexProgram._TnlProgram)
-  return VP_FF;
-   else
-  return VP_SHADER;
-}
-
-
 /**
  * Array to apply the fixed function material aliasing map to
  * an attribute value used in vbo processing inputs to an attribute
-- 
2.14.3

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

[Mesa-dev] [PATCH 04/13] mesa: Introduce a yet unused _DrawVAO.

[Mathias . Froehlich]

From: Mathias Fröhlich 

During the patch series this VAO gets populated with either the currently
bound VAO or an internal VAO that will be used for immediate mode and
dlist rendering.

v2: More comments about the _DrawVAO, filter and enabled mask.
Rename _DrawVAOEnabled to _DrawVAOEnabledAttribs.

Signed-off-by: Mathias Fröhlich 
---
 src/mesa/main/arrayobj.c |  4 
 src/mesa/main/attrib.c   |  2 ++
 src/mesa/main/context.c  |  2 ++
 src/mesa/main/mtypes.h   | 22 ++
 src/mesa/main/state.c| 21 +
 src/mesa/main/state.h| 13 +
 src/mesa/main/varray.c   |  2 ++
 7 files changed, 66 insertions(+)

diff --git a/src/mesa/main/arrayobj.c b/src/mesa/main/arrayobj.c
index a6fa33c82c..cf9c5d7ecc 100644
--- a/src/mesa/main/arrayobj.c
+++ b/src/mesa/main/arrayobj.c
@@ -49,6 +49,7 @@
 #include "arrayobj.h"
 #include "macros.h"
 #include "mtypes.h"
+#include "state.h"
 #include "varray.h"
 #include "main/dispatch.h"
 #include "util/bitscan.h"
@@ -578,6 +579,7 @@ bind_vertex_array(struct gl_context *ctx, GLuint id, bool 
no_error)
 * deleted.
 */
_mesa_set_drawing_arrays(ctx, NULL);
+   _mesa_set_draw_vao(ctx, ctx->Array._EmptyVAO, 0);
 
ctx->NewState |= _NEW_ARRAY;
_mesa_reference_vao(ctx, >Array.VAO, newObj);
@@ -629,6 +631,8 @@ delete_vertex_arrays(struct gl_context *ctx, GLsizei n, 
const GLuint *ids)
 
  if (ctx->Array.LastLookedUpVAO == obj)
 _mesa_reference_vao(ctx, >Array.LastLookedUpVAO, NULL);
+ if (ctx->Array._DrawVAO == obj)
+_mesa_set_draw_vao(ctx, ctx->Array._EmptyVAO, 0);
 
  /* Unreference the array object. 
   * If refcount hits zero, the object will be deleted.
diff --git a/src/mesa/main/attrib.c b/src/mesa/main/attrib.c
index 398ff653b7..dd6b98ce04 100644
--- a/src/mesa/main/attrib.c
+++ b/src/mesa/main/attrib.c
@@ -57,6 +57,7 @@
 #include "viewport.h"
 #include "mtypes.h"
 #include "main/dispatch.h"
+#include "state.h"
 #include "hash.h"
 #include 
 
@@ -1548,6 +1549,7 @@ copy_array_attrib(struct gl_context *ctx,
 
/* Invalidate array state. It will be updated during the next draw. */
_mesa_set_drawing_arrays(ctx, NULL);
+   _mesa_set_draw_vao(ctx, ctx->Array._EmptyVAO, 0);
 }
 
 /**
diff --git a/src/mesa/main/context.c b/src/mesa/main/context.c
index 0aa2e3639f..e13343b5e6 100644
--- a/src/mesa/main/context.c
+++ b/src/mesa/main/context.c
@@ -1335,6 +1335,8 @@ _mesa_free_context_data( struct gl_context *ctx )
 
_mesa_reference_vao(ctx, >Array.VAO, NULL);
_mesa_reference_vao(ctx, >Array.DefaultVAO, NULL);
+   _mesa_reference_vao(ctx, >Array._EmptyVAO, NULL);
+   _mesa_reference_vao(ctx, >Array._DrawVAO, NULL);
 
_mesa_free_attrib_data(ctx);
_mesa_free_buffer_objects(ctx);
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 41df04d38d..bdecd422a9 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -1691,6 +1691,28 @@ struct gl_array_attrib
/* GL_ARB_vertex_buffer_object */
struct gl_buffer_object *ArrayBufferObj;
 
+   /**
+* Vertex array object that is used with the currently active draw command.
+* The _DrawVAO is either set to the currently bound VAO for array type
+* draws or to internal VAO's set up by the vbo module to execute immediate
+* mode or display list draws.
+*/
+   struct gl_vertex_array_object *_DrawVAO;
+   /**
+* The VERT_BIT_* bits effectively enabled from the current _DrawVAO.
+* This is always a subset of _mesa_get_vao_vp_inputs(_DrawVAO)
+* but may omit those arrays that shall not be referenced by the current
+* gl_vertex_program_state::_VPMode. For example the generic attributes are
+* maked out form the _DrawVAO's enabled arrays when a fixed function
+* array draw is executed.
+*/
+   GLbitfield _DrawVAOEnabledAttribs;
+   /**
+* Initially or if the VAO referenced by _DrawVAO is deleted the _DrawVAO
+* pointer is set to the _EmptyVAO which is just an empty VAO all the time.
+*/
+   struct gl_vertex_array_object *_EmptyVAO;
+
/**
 * Vertex arrays as consumed by a driver.
 * The array pointer is set up only by the VBO module.
diff --git a/src/mesa/main/state.c b/src/mesa/main/state.c
index 2fd4fb9d32..5b1b3322e2 100644
--- a/src/mesa/main/state.c
+++ b/src/mesa/main/state.c
@@ -479,3 +479,24 @@ _mesa_update_vertex_processing_mode(struct gl_context *ctx)
else
   ctx->VertexProgram._VPMode = VP_MODE_FF;
 }
+
+
+void
+_mesa_set_draw_vao(struct gl_context *ctx, struct gl_vertex_array_object *vao,
+   GLbitfield filter)
+{
+   struct gl_vertex_array_object **ptr = >Array._DrawVAO;
+   if (*ptr != vao) {
+  _mesa_reference_vao_(ctx, ptr, vao);
+  ctx->NewDriverState |= ctx->DriverFlags.NewArray;
+   } else if (vao->NewArrays) {
+  ctx->NewDriverState |= ctx->DriverFlags.NewArray;
+   }
+
+   /* May shuffle the position and 

[Mesa-dev] [PATCH 09/13] mesa: Add flush_vertices to _mesa_bind_vertex_buffer.

[Mathias . Froehlich]

From: Mathias Fröhlich 

We will need the flush_vertices argument later in this series.

Signed-off-by: Mathias Fröhlich 
---
 src/mesa/drivers/common/meta.c | 16 +---
 src/mesa/main/bufferobj.c  |  2 +-
 src/mesa/main/varray.c | 15 ---
 src/mesa/main/varray.h |  2 +-
 4 files changed, 19 insertions(+), 16 deletions(-)

diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
index 3d9833dabb..830d82ad49 100644
--- a/src/mesa/drivers/common/meta.c
+++ b/src/mesa/drivers/common/meta.c
@@ -348,7 +348,7 @@ _mesa_meta_setup_vertex_objects(struct gl_context *ctx,
GL_FALSE, GL_FALSE,
offsetof(struct vertex, x));
  _mesa_bind_vertex_buffer(ctx, array_obj, VERT_ATTRIB_GENERIC(0),
-  *buf_obj, 0, sizeof(struct vertex));
+  *buf_obj, 0, sizeof(struct vertex), true);
  _mesa_enable_vertex_array_attrib(ctx, array_obj,
   VERT_ATTRIB_GENERIC(0), true);
  if (texcoord_size > 0) {
@@ -357,7 +357,7 @@ _mesa_meta_setup_vertex_objects(struct gl_context *ctx,
   GL_FALSE, GL_FALSE, GL_FALSE,
   offsetof(struct vertex, tex));
 _mesa_bind_vertex_buffer(ctx, array_obj, VERT_ATTRIB_GENERIC(1),
- *buf_obj, 0, sizeof(struct vertex));
+ *buf_obj, 0, sizeof(struct vertex), true);
 _mesa_enable_vertex_array_attrib(ctx, array_obj,
  VERT_ATTRIB_GENERIC(1), true);
  }
@@ -367,7 +367,7 @@ _mesa_meta_setup_vertex_objects(struct gl_context *ctx,
GL_FALSE, GL_FALSE,
offsetof(struct vertex, x));
  _mesa_bind_vertex_buffer(ctx, array_obj, VERT_ATTRIB_POS,
-  *buf_obj, 0, sizeof(struct vertex));
+  *buf_obj, 0, sizeof(struct vertex), true);
  _mesa_enable_vertex_array_attrib(ctx, array_obj,
   VERT_ATTRIB_POS, true);
 
@@ -377,7 +377,7 @@ _mesa_meta_setup_vertex_objects(struct gl_context *ctx,
   GL_FALSE, GL_FALSE,
   offsetof(struct vertex, tex));
 _mesa_bind_vertex_buffer(ctx, array_obj, VERT_ATTRIB_TEX(0),
- *buf_obj, 0, sizeof(struct vertex));
+ *buf_obj, 0, sizeof(struct vertex), true);
 _mesa_enable_vertex_array_attrib(ctx, array_obj,
  VERT_ATTRIB_TEX(0), true);
  }
@@ -388,7 +388,7 @@ _mesa_meta_setup_vertex_objects(struct gl_context *ctx,
   GL_FALSE, GL_FALSE,
   offsetof(struct vertex, r));
 _mesa_bind_vertex_buffer(ctx, array_obj, VERT_ATTRIB_COLOR0,
- *buf_obj, 0, sizeof(struct vertex));
+ *buf_obj, 0, sizeof(struct vertex), true);
 _mesa_enable_vertex_array_attrib(ctx, array_obj,
  VERT_ATTRIB_COLOR0, true);
  }
@@ -3347,7 +3347,8 @@ _mesa_meta_DrawTex(struct gl_context *ctx, GLfloat x, 
GLfloat y, GLfloat z,
 GL_FALSE, GL_FALSE,
 offsetof(struct vertex, x));
   _mesa_bind_vertex_buffer(ctx, array_obj, VERT_ATTRIB_POS,
-   drawtex->buf_obj, 0, sizeof(struct vertex));
+   drawtex->buf_obj, 0,
+   sizeof(struct vertex), true);
   _mesa_enable_vertex_array_attrib(ctx, array_obj, VERT_ATTRIB_POS, true);
 
 
@@ -3358,7 +3359,8 @@ _mesa_meta_DrawTex(struct gl_context *ctx, GLfloat x, 
GLfloat y, GLfloat z,
GL_FALSE, GL_FALSE,
offsetof(struct vertex, st[i]));
  _mesa_bind_vertex_buffer(ctx, array_obj, VERT_ATTRIB_TEX(i),
-  drawtex->buf_obj, 0, sizeof(struct vertex));
+  drawtex->buf_obj, 0,
+  sizeof(struct vertex), true);
  _mesa_enable_vertex_array_attrib(ctx, array_obj,
   VERT_ATTRIB_TEX(i), true);
   }
diff --git a/src/mesa/main/bufferobj.c b/src/mesa/main/bufferobj.c
index 67f9cd0a90..068c7dd434 100644
--- a/src/mesa/main/bufferobj.c
+++ b/src/mesa/main/bufferobj.c
@@ -1167,7 +1167,7 @@ unbind(struct gl_context *ctx,
if (vao->BufferBinding[index].BufferObj == obj) {
   

[Mesa-dev] [PATCH 08/13] mesa: Make _mesa_vertex_attrib_binding public.

[Mathias . Froehlich]

From: Mathias Fröhlich 

Change vertex_attrib_binding() to _mesa_vertex_attrib_binding(), add a
flush_vertices argument, and make it publically available.
The function will be needed later in the series.

Signed-off-by: Mathias Fröhlich 
---
 src/mesa/main/varray.c | 38 --
 src/mesa/main/varray.h |  7 +++
 2 files changed, 27 insertions(+), 18 deletions(-)

diff --git a/src/mesa/main/varray.c b/src/mesa/main/varray.c
index 90b874aa49..f7d32fdbef 100644
--- a/src/mesa/main/varray.c
+++ b/src/mesa/main/varray.c
@@ -155,11 +155,11 @@ update_attribute_map_mode(const struct gl_context *ctx,
  * Sets the BufferBindingIndex field for the vertex attribute given by
  * attribIndex.
  */
-static void
-vertex_attrib_binding(struct gl_context *ctx,
-  struct gl_vertex_array_object *vao,
-  gl_vert_attrib attribIndex,
-  GLuint bindingIndex)
+void
+_mesa_vertex_attrib_binding(struct gl_context *ctx,
+struct gl_vertex_array_object *vao,
+gl_vert_attrib attribIndex,
+GLuint bindingIndex, bool flush_vertices)
 {
struct gl_array_attributes *array = >VertexAttrib[attribIndex];
 
@@ -171,7 +171,9 @@ vertex_attrib_binding(struct gl_context *ctx,
   else
  vao->VertexAttribBufferMask &= ~array_bit;
 
-  FLUSH_VERTICES(ctx, _NEW_ARRAY);
+  if (flush_vertices) {
+ FLUSH_VERTICES(ctx, _NEW_ARRAY);
+  }
 
   vao->BufferBinding[array->BufferBindingIndex]._BoundArrays &= ~array_bit;
   vao->BufferBinding[bindingIndex]._BoundArrays |= array_bit;
@@ -592,7 +594,7 @@ update_array(struct gl_context *ctx,
  normalized, integer, doubles, 0);
 
/* Reset the vertex attrib binding */
-   vertex_attrib_binding(ctx, vao, attrib, attrib);
+   _mesa_vertex_attrib_binding(ctx, vao, attrib, attrib, true);
 
/* The Stride and Ptr fields are not set by update_array_format() */
struct gl_array_attributes *array = >VertexAttrib[attrib];
@@ -2030,7 +2032,7 @@ _mesa_VertexAttribDivisor_no_error(GLuint index, GLuint 
divisor)
 *   VertexAttribBinding(index, index);
 *   VertexBindingDivisor(index, divisor);"
 */
-   vertex_attrib_binding(ctx, vao, genericIndex, genericIndex);
+   _mesa_vertex_attrib_binding(ctx, vao, genericIndex, genericIndex, true);
vertex_binding_divisor(ctx, vao, genericIndex, divisor);
 }
 
@@ -2072,7 +2074,7 @@ _mesa_VertexAttribDivisor(GLuint index, GLuint divisor)
 *   VertexAttribBinding(index, index);
 *   VertexBindingDivisor(index, divisor);"
 */
-   vertex_attrib_binding(ctx, vao, genericIndex, genericIndex);
+   _mesa_vertex_attrib_binding(ctx, vao, genericIndex, genericIndex, true);
vertex_binding_divisor(ctx, vao, genericIndex, divisor);
 }
 
@@ -2674,9 +2676,9 @@ vertex_array_attrib_binding(struct gl_context *ctx,
 
assert(VERT_ATTRIB_GENERIC(attribIndex) < ARRAY_SIZE(vao->VertexAttrib));
 
-   vertex_attrib_binding(ctx, vao,
- VERT_ATTRIB_GENERIC(attribIndex),
- VERT_ATTRIB_GENERIC(bindingIndex));
+   _mesa_vertex_attrib_binding(ctx, vao,
+   VERT_ATTRIB_GENERIC(attribIndex),
+   VERT_ATTRIB_GENERIC(bindingIndex), true);
 }
 
 
@@ -2684,9 +2686,9 @@ void GLAPIENTRY
 _mesa_VertexAttribBinding_no_error(GLuint attribIndex, GLuint bindingIndex)
 {
GET_CURRENT_CONTEXT(ctx);
-   vertex_attrib_binding(ctx, ctx->Array.VAO,
- VERT_ATTRIB_GENERIC(attribIndex),
- VERT_ATTRIB_GENERIC(bindingIndex));
+   _mesa_vertex_attrib_binding(ctx, ctx->Array.VAO,
+   VERT_ATTRIB_GENERIC(attribIndex),
+   VERT_ATTRIB_GENERIC(bindingIndex), true);
 }
 
 
@@ -2720,9 +2722,9 @@ _mesa_VertexArrayAttribBinding_no_error(GLuint vaobj, 
GLuint attribIndex,
GET_CURRENT_CONTEXT(ctx);
 
struct gl_vertex_array_object *vao = _mesa_lookup_vao(ctx, vaobj);
-   vertex_attrib_binding(ctx, vao,
- VERT_ATTRIB_GENERIC(attribIndex),
- VERT_ATTRIB_GENERIC(bindingIndex));
+   _mesa_vertex_attrib_binding(ctx, vao,
+   VERT_ATTRIB_GENERIC(attribIndex),
+   VERT_ATTRIB_GENERIC(bindingIndex), true);
 }
 
 
diff --git a/src/mesa/main/varray.h b/src/mesa/main/varray.h
index 93ffb37a0d..6585355771 100644
--- a/src/mesa/main/varray.h
+++ b/src/mesa/main/varray.h
@@ -120,6 +120,13 @@ _mesa_disable_vertex_array_attrib(struct gl_context *ctx,
   gl_vert_attrib attrib, bool flush_vertices);
 
 
+extern void
+_mesa_vertex_attrib_binding(struct gl_context *ctx,
+struct gl_vertex_array_object *vao,
+

[Mesa-dev] [PATCH 02/13] vbo: Use _VPMode instead of get_vp_mode().

[Mathias . Froehlich]

From: Mathias Fröhlich 

At those places where we used get_vp_mode() use
gl_vertex_program_state::_VPMode instead.

Signed-off-by: Mathias Fröhlich 
---
 src/mesa/vbo/vbo_exec.c   |  4 ++--
 src/mesa/vbo/vbo_exec_array.c | 11 ++-
 src/mesa/vbo/vbo_exec_draw.c  |  5 +++--
 src/mesa/vbo/vbo_save_draw.c  |  5 +++--
 4 files changed, 14 insertions(+), 11 deletions(-)

diff --git a/src/mesa/vbo/vbo_exec.c b/src/mesa/vbo/vbo_exec.c
index fc06979dcb..372d0237aa 100644
--- a/src/mesa/vbo/vbo_exec.c
+++ b/src/mesa/vbo/vbo_exec.c
@@ -34,7 +34,7 @@
 
 const GLubyte
 _vbo_attribute_alias_map[VP_MODE_MAX][VERT_ATTRIB_MAX] = {
-   /* VP_FF: */
+   /* VP_MODE_FF: */
{
   VBO_ATTRIB_POS, /* VERT_ATTRIB_POS */
   VBO_ATTRIB_NORMAL,  /* VERT_ATTRIB_NORMAL */
@@ -70,7 +70,7 @@ _vbo_attribute_alias_map[VP_MODE_MAX][VERT_ATTRIB_MAX] = {
   VBO_ATTRIB_MAT_BACK_INDEXES /* VERT_ATTRIB_GENERIC15 */
},
 
-   /* VP_SHADER: */
+   /* VP_MODE_SHADER: */
{
   VBO_ATTRIB_POS, /* VERT_ATTRIB_POS */
   VBO_ATTRIB_NORMAL,  /* VERT_ATTRIB_NORMAL */
diff --git a/src/mesa/vbo/vbo_exec_array.c b/src/mesa/vbo/vbo_exec_array.c
index 25abe09559..0c3c9017b1 100644
--- a/src/mesa/vbo/vbo_exec_array.c
+++ b/src/mesa/vbo/vbo_exec_array.c
@@ -338,10 +338,11 @@ recalculate_input_bindings(struct gl_context *ctx)
/* May shuffle the position and generic0 bits around */
GLbitfield vp_inputs = _mesa_get_vao_vp_inputs(vao);
 
-   const enum vp_mode program_mode = get_vp_mode(ctx);
-   const GLubyte *const map = _vbo_attribute_alias_map[program_mode];
-   switch (program_mode) {
-   case VP_FF:
+   const gl_vertex_processing_mode processing_mode
+  = ctx->VertexProgram._VPMode;
+   const GLubyte * const map = _vbo_attribute_alias_map[processing_mode];
+   switch (processing_mode) {
+   case VP_MODE_FF:
   /* When no vertex program is active (or the vertex program is generated
* from fixed-function state).  We put the material values into the
* generic slots.  Since the vao has no material arrays, mute these
@@ -352,7 +353,7 @@ recalculate_input_bindings(struct gl_context *ctx)
 
   break;
 
-   case VP_SHADER:
+   case VP_MODE_SHADER:
   /* There are no shaders in OpenGL ES 1.x, so this code path should be
* impossible to reach.  The meta code is careful to not use shaders in
* ES1.
diff --git a/src/mesa/vbo/vbo_exec_draw.c b/src/mesa/vbo/vbo_exec_draw.c
index b0cc394642..4421496072 100644
--- a/src/mesa/vbo/vbo_exec_draw.c
+++ b/src/mesa/vbo/vbo_exec_draw.c
@@ -178,8 +178,9 @@ vbo_exec_bind_arrays(struct gl_context *ctx)
GLuint attr;
GLbitfield varying_inputs = 0x0;
 
-   const enum vp_mode program_mode = get_vp_mode(exec->ctx);
-   const GLubyte * const map = _vbo_attribute_alias_map[program_mode];
+   const gl_vertex_processing_mode processing_mode
+  = ctx->VertexProgram._VPMode;
+   const GLubyte * const map = _vbo_attribute_alias_map[processing_mode];
 
/* Grab VERT_ATTRIB_{POS,GENERIC0} from VBO_ATTRIB_POS */
const gl_attribute_map_mode mode = ATTRIBUTE_MAP_MODE_POSITION;
diff --git a/src/mesa/vbo/vbo_save_draw.c b/src/mesa/vbo/vbo_save_draw.c
index 96a9bab029..8c58fecf40 100644
--- a/src/mesa/vbo/vbo_save_draw.c
+++ b/src/mesa/vbo/vbo_save_draw.c
@@ -142,8 +142,9 @@ bind_vertex_list(struct gl_context *ctx,
GLuint attr;
GLbitfield varying_inputs = 0x0;
 
-   const enum vp_mode program_mode = get_vp_mode(ctx);
-   const GLubyte * const map = _vbo_attribute_alias_map[program_mode];
+   const gl_vertex_processing_mode processing_mode
+  = ctx->VertexProgram._VPMode;
+   const GLubyte * const map = _vbo_attribute_alias_map[processing_mode];
 
/* Grab VERT_ATTRIB_{POS,GENERIC0} from VBO_ATTRIB_POS */
const gl_attribute_map_mode mode = ATTRIBUTE_MAP_MODE_POSITION;
-- 
2.14.3

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

[Mesa-dev] [PATCH 11/13] vbo: Make use of _DrawVAO from immediate mode draw

[Mathias . Froehlich]

From: Mathias Fröhlich 

Finally use an internal VAO to execute immediate mode draws. Avoid
duplicate state validation for immediate mode draws. Remove client arrays
previously used exclusively for immediate mode draws.

Signed-off-by: Mathias Fröhlich 
---
 src/mesa/vbo/vbo_context.c   |   8 +++
 src/mesa/vbo/vbo_exec.h  |   8 ---
 src/mesa/vbo/vbo_exec_api.c  |  47 +
 src/mesa/vbo/vbo_exec_draw.c | 117 ---
 src/mesa/vbo/vbo_private.h   |   2 +
 5 files changed, 78 insertions(+), 104 deletions(-)

diff --git a/src/mesa/vbo/vbo_context.c b/src/mesa/vbo/vbo_context.c
index 222bdcf1f2..3dc3222c0d 100644
--- a/src/mesa/vbo/vbo_context.c
+++ b/src/mesa/vbo/vbo_context.c
@@ -30,6 +30,8 @@
 #include "math/m_eval.h"
 #include "main/vtxfmt.h"
 #include "main/api_arrayelt.h"
+#include "main/arrayobj.h"
+#include "main/varray.h"
 #include "vbo.h"
 #include "vbo_private.h"
 
@@ -252,6 +254,11 @@ _vbo_CreateContext(struct gl_context *ctx)
if (ctx->API == API_OPENGL_COMPAT)
   vbo_save_init(ctx);
 
+   vbo->VAO = _mesa_new_vao(ctx, ~((GLuint)0));
+   /* The exec VAO assumes to have all arributes bound to binding 0 */
+   for (unsigned i = 0; i < VERT_ATTRIB_MAX; ++i)
+  _mesa_vertex_attrib_binding(ctx, vbo->VAO, i, 0, false);
+
_math_init_eval();
 
return GL_TRUE;
@@ -278,6 +285,7 @@ _vbo_DestroyContext(struct gl_context *ctx)
   vbo_exec_destroy(ctx);
   if (ctx->API == API_OPENGL_COMPAT)
  vbo_save_destroy(ctx);
+  _mesa_reference_vao(ctx, >VAO, NULL);
   free(vbo);
   ctx->vbo_context = NULL;
}
diff --git a/src/mesa/vbo/vbo_exec.h b/src/mesa/vbo/vbo_exec.h
index b00045c7c8..07ab5cc837 100644
--- a/src/mesa/vbo/vbo_exec.h
+++ b/src/mesa/vbo/vbo_exec.h
@@ -101,14 +101,6 @@ struct vbo_exec_context
 
   /** pointers into the current 'vertex' array, declared above */
   fi_type *attrptr[VBO_ATTRIB_MAX];
-
-  struct gl_vertex_array arrays[VERT_ATTRIB_MAX];
-
-  /* According to program mode, the values above plus current
-   * values are squashed down to the 32 attributes passed to the
-   * vertex program below:
-   */
-  const struct gl_vertex_array *inputs[VERT_ATTRIB_MAX];
} vtx;
 
struct {
diff --git a/src/mesa/vbo/vbo_exec_api.c b/src/mesa/vbo/vbo_exec_api.c
index 64e792bfa2..317fc43d1c 100644
--- a/src/mesa/vbo/vbo_exec_api.c
+++ b/src/mesa/vbo/vbo_exec_api.c
@@ -758,7 +758,8 @@ static void GLAPIENTRY
 vbo_exec_Begin(GLenum mode)
 {
GET_CURRENT_CONTEXT(ctx);
-   struct vbo_exec_context *exec = _context(ctx)->exec;
+   struct vbo_context *vbo = vbo_context(ctx);
+   struct vbo_exec_context *exec = >exec;
int i;
 
if (_mesa_inside_begin_end(ctx)) {
@@ -770,8 +771,6 @@ vbo_exec_Begin(GLenum mode)
   return;
}
 
-   _mesa_set_drawing_arrays(ctx, exec->vtx.inputs);
-
if (ctx->NewState) {
   _mesa_update_state(ctx);
 
@@ -1162,7 +1161,6 @@ void
 vbo_exec_vtx_init(struct vbo_exec_context *exec)
 {
struct gl_context *ctx = exec->ctx;
-   struct vbo_context *vbo = vbo_context(ctx);
GLuint i;
 
/* Allocate a buffer object.  Will just reuse this object
@@ -1189,38 +1187,6 @@ vbo_exec_vtx_init(struct vbo_exec_context *exec)
   assert(i < ARRAY_SIZE(exec->vtx.active_sz));
   exec->vtx.active_sz[i] = 0;
}
-   for (i = 0 ; i < VERT_ATTRIB_MAX; i++) {
-  assert(i < ARRAY_SIZE(exec->vtx.inputs));
-  assert(i < ARRAY_SIZE(exec->vtx.arrays));
-  exec->vtx.inputs[i] = >vtx.arrays[i];
-   }
-
-   {
-  struct gl_vertex_array *arrays = exec->vtx.arrays;
-  unsigned i;
-
-  memcpy(arrays, >currval[VBO_ATTRIB_POS],
- VERT_ATTRIB_FF_MAX * sizeof(arrays[0]));
-  for (i = 0; i < VERT_ATTRIB_FF_MAX; ++i) {
- struct gl_vertex_array *array;
- array = [VERT_ATTRIB_FF(i)];
- array->BufferObj = NULL;
- _mesa_reference_buffer_object(ctx, >BufferObj,
-   
vbo->currval[VBO_ATTRIB_POS+i].BufferObj);
-  }
-
-  memcpy(arrays + VERT_ATTRIB_GENERIC(0),
- >currval[VBO_ATTRIB_GENERIC0],
- VERT_ATTRIB_GENERIC_MAX * sizeof(arrays[0]));
-
-  for (i = 0; i < VERT_ATTRIB_GENERIC_MAX; ++i) {
- struct gl_vertex_array *array;
- array = [VERT_ATTRIB_GENERIC(i)];
- array->BufferObj = NULL;
- _mesa_reference_buffer_object(ctx, >BufferObj,
-   vbo->currval[VBO_ATTRIB_GENERIC0+i].BufferObj);
-  }
-   }
 
exec->vtx.vertex_size = 0;
 
@@ -1233,7 +1199,6 @@ vbo_exec_vtx_destroy(struct vbo_exec_context *exec)
 {
/* using a real VBO for vertex data */
struct gl_context *ctx = exec->ctx;
-   unsigned i;
 
/* True VBOs should already be unmapped
 */
@@ -1247,14 +1212,6 @@ vbo_exec_vtx_destroy(struct vbo_exec_context *exec)
   }
}
 
-   /* Drop any outstanding reference to the vertex buffer
-*/
- 

[Mesa-dev] [PATCH 00/13] Switch over to use VAOs for drawing v2.

[Mathias . Froehlich]

From: Mathias Fröhlich 

Hi Brian,

Thanks for the review on v1!!

The following series moves over to draw via a VAO in all draw
paths. At the current stage this introduces an additional
indirection for the immediate mode and display list draws.
But in the mid term using a VAO should enable drivers to make
use of the binding information already present in the VAO
that gets lost when transforming VAO to a gl_vertex_array list.
In the mid term todays fast vbo_exec_array draw path should
move closer to the backend drivers. But the old style dlist
draw path does as well benefit from the preserved single
vbo binding information still visible in the VAO.
The changeset just cleans up the most obvious parts that are
directly involved with the changes done. For example the
duplicate _mesa_update_state call is no longer needed with the
series and cleaned up. But the series enables much more cleanup.

Version 2 tries to improve comments and explanastoins mostly.
It contains some renames and rebases to the current upstream
version.
I did leave the methods on the struct vbo_inputs in the public
api header as this struct is in the mid term expected to be pushed
into drivers that continue to work on the gl_vertex_array vector
and this will be referenced from outside the vbo module.

The series is tested without piglit regressions with my
available hardware that is i965, classic swrast and radeonsi and
on a recent piglit including the latest attribute aliasing tests.

Please review
Thanks!

Mathias


Mathias Fröhlich (13):
  mesa: Provide an alternative to get_vp_mode()
  vbo: Use _VPMode instead of get_vp_mode().
  vbo: Remove get_vp_mode() and enum vp_mode.
  mesa: Introduce a yet unused _DrawVAO.
  vbo: Implement method to track the inputs array.
  vbo: Use _DrawVAO for array type draw commands.
  mesa: Add flush_vertices to
_mesa_{enable,disable}_vertex_array_attrib.
  mesa: Make _mesa_vertex_attrib_binding public.
  mesa: Add flush_vertices to _mesa_bind_vertex_buffer.
  vbo: Implement tool functions for vbo specific VAO setup.
  vbo: Make use of _DrawVAO from immediate mode draw
  mesa: Use atomics for shared VAO reference counts.
  vbo: Make use of _DrawVAO from the dlist code.

 src/mesa/drivers/common/meta.c |  36 +
 src/mesa/main/arbprogram.c |   5 ++
 src/mesa/main/arrayobj.c   |  39 --
 src/mesa/main/arrayobj.h   |   9 +++
 src/mesa/main/attrib.c |   2 +
 src/mesa/main/bufferobj.c  |   2 +-
 src/mesa/main/context.c|   5 ++
 src/mesa/main/enable.c |   6 +-
 src/mesa/main/mtypes.h |  53 ++
 src/mesa/main/pipelineobj.c|   3 +
 src/mesa/main/shaderapi.c  |   5 ++
 src/mesa/main/state.c  |  44 +++
 src/mesa/main/state.h  |  20 +
 src/mesa/main/varray.c |  85 -
 src/mesa/main/varray.h |  13 +++-
 src/mesa/program/program.c |   1 +
 src/mesa/vbo/vbo.h |  36 +
 src/mesa/vbo/vbo_attrib.h  |   4 +-
 src/mesa/vbo/vbo_context.c |  17 -
 src/mesa/vbo/vbo_exec.c|  87 +-
 src/mesa/vbo/vbo_exec.h|  14 
 src/mesa/vbo/vbo_exec_api.c|  47 +---
 src/mesa/vbo/vbo_exec_array.c  | 162 -
 src/mesa/vbo/vbo_exec_draw.c   | 116 -
 src/mesa/vbo/vbo_private.h |  84 ++---
 src/mesa/vbo/vbo_save.c|  37 ++
 src/mesa/vbo/vbo_save.h|   4 +-
 src/mesa/vbo/vbo_save_api.c| 132 +++--
 src/mesa/vbo/vbo_save_draw.c   |  63 +++-
 29 files changed, 770 insertions(+), 361 deletions(-)

-- 
2.14.3

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

[Mesa-dev] [PATCH 12/13] mesa: Use atomics for shared VAO reference counts.

[Mathias . Froehlich]

From: Mathias Fröhlich 

VAOs will be used in the next change as immutable object across multiple
contexts. Only reference counting may write concurrently on the VAO. So,
make the reference count thread safe for those and only those VAO objects.

Signed-off-by: Mathias Fröhlich 
---
 src/mesa/main/arrayobj.c | 35 ++-
 src/mesa/main/arrayobj.h |  9 +
 src/mesa/main/mtypes.h   |  7 +++
 3 files changed, 46 insertions(+), 5 deletions(-)

diff --git a/src/mesa/main/arrayobj.c b/src/mesa/main/arrayobj.c
index cf9c5d7ecc..063856d984 100644
--- a/src/mesa/main/arrayobj.c
+++ b/src/mesa/main/arrayobj.c
@@ -53,6 +53,7 @@
 #include "varray.h"
 #include "main/dispatch.h"
 #include "util/bitscan.h"
+#include "util/u_atomic.h"
 
 
 const GLubyte
@@ -331,10 +332,16 @@ _mesa_reference_vao_(struct gl_context *ctx,
   /* Unreference the old array object */
   struct gl_vertex_array_object *oldObj = *ptr;
 
-  assert(oldObj->RefCount > 0);
-  oldObj->RefCount--;
+  bool deleteFlag;
+  if (oldObj->SharedAndImmutable) {
+ deleteFlag = p_atomic_dec_zero(>RefCount);
+  } else {
+ assert(oldObj->RefCount > 0);
+ oldObj->RefCount--;
+ deleteFlag = (oldObj->RefCount == 0);
+  }
 
-  if (oldObj->RefCount == 0)
+  if (deleteFlag)
  _mesa_delete_vao(ctx, oldObj);
 
   *ptr = NULL;
@@ -343,9 +350,13 @@ _mesa_reference_vao_(struct gl_context *ctx,
 
if (vao) {
   /* reference new array object */
-  assert(vao->RefCount > 0);
+  if (vao->SharedAndImmutable) {
+ p_atomic_inc(>RefCount);
+  } else {
+ assert(vao->RefCount > 0);
+ vao->RefCount++;
+  }
 
-  vao->RefCount++;
   *ptr = vao;
}
 }
@@ -407,6 +418,7 @@ _mesa_initialize_vao(struct gl_context *ctx,
vao->Name = name;
 
vao->RefCount = 1;
+   vao->SharedAndImmutable = GL_FALSE;
 
/* Init the individual arrays */
for (i = 0; i < ARRAY_SIZE(vao->VertexAttrib); i++) {
@@ -452,6 +464,9 @@ _mesa_update_vao_derived_arrays(struct gl_context *ctx,
 {
GLbitfield arrays = vao->NewArrays;
 
+   /* Make sure we do not run into problems with shared objects */
+   assert(!vao->SharedAndImmutable || vao->NewArrays == 0);
+
while (arrays) {
   const int attrib = u_bit_scan();
   struct gl_vertex_array *array = >_VertexArray[attrib];
@@ -465,6 +480,16 @@ _mesa_update_vao_derived_arrays(struct gl_context *ctx,
 }
 
 
+void
+_mesa_set_vao_immutable(struct gl_context *ctx,
+struct gl_vertex_array_object *vao)
+{
+   _mesa_update_vao_derived_arrays(ctx, vao);
+   vao->NewArrays = 0;
+   vao->SharedAndImmutable = GL_TRUE;
+}
+
+
 bool
 _mesa_all_varyings_in_vbos(const struct gl_vertex_array_object *vao)
 {
diff --git a/src/mesa/main/arrayobj.h b/src/mesa/main/arrayobj.h
index 5de74505bb..8da5c9ffe0 100644
--- a/src/mesa/main/arrayobj.h
+++ b/src/mesa/main/arrayobj.h
@@ -81,6 +81,15 @@ extern void
 _mesa_update_vao_derived_arrays(struct gl_context *ctx,
 struct gl_vertex_array_object *vao);
 
+
+/**
+ * Mark the vao as shared and immutable, do remaining updates.
+ */
+extern void
+_mesa_set_vao_immutable(struct gl_context *ctx,
+struct gl_vertex_array_object *vao);
+
+
 /* Returns true if all varying arrays reside in vbos */
 extern bool
 _mesa_all_varyings_in_vbos(const struct gl_vertex_array_object *vao);
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index bdecd422a9..9965cf8447 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -1607,6 +1607,13 @@ struct gl_vertex_array_object
 */
GLboolean EverBound;
 
+   /**
+* Marked to true if the object is shared between contexts and immutable.
+* Then reference counting is done using atomics and thread safe.
+* Is used for dlist VAOs.
+*/
+   GLboolean SharedAndImmutable;
+
/**
 * Derived vertex attribute arrays
 *
-- 
2.14.3

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

[Mesa-dev] [PATCH] nv50, nvc0: fix integer MS resolves using 2d engine

[Ilia Mirkin]

We don't want filtering for integer textures, same as depth/stencil.

Fixes: KHR-GL45.direct_state_access.renderbuffers_storage_multisample
Signed-off-by: Ilia Mirkin 
---
 src/gallium/drivers/nouveau/nv50/nv50_blit.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/nouveau/nv50/nv50_blit.h 
b/src/gallium/drivers/nouveau/nv50/nv50_blit.h
index 0ccec568d3a..10fe5274b10 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_blit.h
+++ b/src/gallium/drivers/nouveau/nv50/nv50_blit.h
@@ -85,7 +85,8 @@ static inline unsigned
 nv50_blit_get_filter(const struct pipe_blit_info *info)
 {
if (info->dst.resource->nr_samples < info->src.resource->nr_samples)
-  return util_format_is_depth_or_stencil(info->src.format) ? 0 : 1;
+  return (util_format_is_depth_or_stencil(info->src.format) ||
+  util_format_is_pure_integer(info->src.format)) ? 0 : 1;
 
if (info->filter != PIPE_TEX_FILTER_LINEAR)
   return 0;
-- 
2.16.1

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

Re: [Mesa-dev] [PATCH] glsl: Parse 'layout' as a token with advanced blending or bindless

[Marek Olšák]

On Tue, Feb 20, 2018 at 6:28 AM, Kenneth Graunke  wrote:
> Both KHR_blend_equation_advanced and ARB_bindless_texture provide
> layout qualifiers, and are exposed in compatibility contexts.  We
> need to parse the layout qualifier as a token in order for those
> to work, but forgot to extend this check.
>
> ARB_shader_image_load_store would need a similar treatment, but we
> don't expose that in legacy OpenGL contexts.

We do expose it in legacy contexts.

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

Re: [Mesa-dev] [PATCH v3 11/21] clover: Move platform extensions definitions to clover/platform.cpp

[Aaron Watry]

6 is Acked-By: Aaron Watry 
7-11 (regardless of my comment in 9) are Reviewed-By: Aaron Watry


--Aaron

On Wed, Feb 21, 2018 at 4:50 PM, Pierre Moreau  wrote:
> Reviewed-by: Francisco Jerez 
> Signed-off-by: Pierre Moreau 
> ---
>  src/gallium/state_trackers/clover/api/platform.cpp  | 4 ++--
>  src/gallium/state_trackers/clover/core/platform.cpp | 5 +
>  src/gallium/state_trackers/clover/core/platform.hpp | 2 ++
>  3 files changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/state_trackers/clover/api/platform.cpp 
> b/src/gallium/state_trackers/clover/api/platform.cpp
> index ed86163311..887dfd0a22 100644
> --- a/src/gallium/state_trackers/clover/api/platform.cpp
> +++ b/src/gallium/state_trackers/clover/api/platform.cpp
> @@ -50,7 +50,7 @@ clover::GetPlatformInfo(cl_platform_id d_platform, 
> cl_platform_info param,
>  size_t size, void *r_buf, size_t *r_size) try {
> property_buffer buf { r_buf, size, r_size };
>
> -   obj(d_platform);
> +   auto  = obj(d_platform);
>
> switch (param) {
> case CL_PLATFORM_PROFILE:
> @@ -74,7 +74,7 @@ clover::GetPlatformInfo(cl_platform_id d_platform, 
> cl_platform_info param,
>break;
>
> case CL_PLATFORM_EXTENSIONS:
> -  buf.as_string() = "cl_khr_icd";
> +  buf.as_string() = platform.supported_extensions();
>break;
>
> case CL_PLATFORM_ICD_SUFFIX_KHR:
> diff --git a/src/gallium/state_trackers/clover/core/platform.cpp 
> b/src/gallium/state_trackers/clover/core/platform.cpp
> index 489e8dc5a8..ddd63fc5a0 100644
> --- a/src/gallium/state_trackers/clover/core/platform.cpp
> +++ b/src/gallium/state_trackers/clover/core/platform.cpp
> @@ -39,3 +39,8 @@ platform::platform() : adaptor_range(evals(), devs) {
>}
> }
>  }
> +
> +std::string
> +platform::supported_extensions() const {
> +   return "cl_khr_icd";
> +}
> diff --git a/src/gallium/state_trackers/clover/core/platform.hpp 
> b/src/gallium/state_trackers/clover/core/platform.hpp
> index e849645bbe..b94434c983 100644
> --- a/src/gallium/state_trackers/clover/core/platform.hpp
> +++ b/src/gallium/state_trackers/clover/core/platform.hpp
> @@ -40,6 +40,8 @@ namespace clover {
>platform &
>operator=(const platform ) = delete;
>
> +  std::string supported_extensions() const;
> +
> protected:
>std::vector devs;
> };
> --
> 2.16.2
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] vulkan/wsi/wayland: Add support for zwp_dmabuf

[Dave Airlie]

On 22 February 2018 at 11:58, Dieter Nützel  wrote:
> Am 22.02.2018 02:35, schrieb Dave Airlie:
>>
>> 2018-02-22 10:57 GMT+10:00 Dieter Nützel :
>>>
>>> Making all in vulkan
>>> make[3]: Verzeichnis „/opt/mesa/src/vulkan“ wird betreten
>>> make[3]: *** Keine Regel vorhanden, um das Ziel
>>> „/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml“,
>>>   benötigt von „wsi/linux-dmabuf-unstable-v1-protocol.c“, zu erstellen.
>>> Schluss.
>>> make[3]: Verzeichnis „/opt/mesa/src/vulkan“ wird verlassen
>>> make[2]: *** [Makefile:862: all-recursive] Fehler 1
>>> make[2]: Verzeichnis „/opt/mesa/src“ wird verlassen
>>> make[1]: *** [Makefile:653: all] Fehler 2
>>> make[1]: Verzeichnis „/opt/mesa/src“ wird verlassen
>>> make: *** [Makefile:666: all-recursive] Fehler 1
>>>
>>> I do not have (do not know of) any wayland stuff running, here.
>>
>>
>> Rerunning autogen.sh fixed that for me.
>>
>> Dave.
>
>
> Thanks, Dave.
> With which options?
> I did it several times but to no avail.
>
> ./autogen.sh --prefix=/usr/local --with-dri-drivers=""
> --with-gallium-drivers=r600,radeonsi,swrast --with-platforms=drm,x11
> --enable-nine --enable-texture-float --enable-opencl --disable-opencl_icd
> --with-vulkan-drivers=radeon
>
> Even 'make distclean' etc. do not work for me.

Actually ignore me, I messed up my autogen.sh and it disabled vulkan drivers.

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

Re: [Mesa-dev] [PATCH v3 09/21] clover: Track flags per module section

[Aaron Watry]

On Wed, Feb 21, 2018 at 4:50 PM, Pierre Moreau  wrote:
> One flag that needs to be tracked is whether a library is allowed to
> received mathematics optimisations or not, as the authorisation is given
> when creating the library while the optimisations are specified when
> creating the executable.
>
> Signed-off-by: Pierre Moreau 
> ---
>  src/gallium/state_trackers/clover/core/module.cpp  |  1 +
>  src/gallium/state_trackers/clover/core/module.hpp  | 13 +
>  src/gallium/state_trackers/clover/llvm/codegen/bitcode.cpp |  3 ++-
>  src/gallium/state_trackers/clover/llvm/codegen/common.cpp  |  2 +-
>  src/gallium/state_trackers/clover/tgsi/compiler.cpp|  3 ++-
>  5 files changed, 15 insertions(+), 7 deletions(-)
>
> diff --git a/src/gallium/state_trackers/clover/core/module.cpp 
> b/src/gallium/state_trackers/clover/core/module.cpp
> index a6c5b98d8e..0e11506d0d 100644
> --- a/src/gallium/state_trackers/clover/core/module.cpp
> +++ b/src/gallium/state_trackers/clover/core/module.cpp
> @@ -163,6 +163,7 @@ namespace {
>proc(S , QT ) {
>   _proc(s, x.id);
>   _proc(s, x.type);
> + _proc(s, x.flags);
>   _proc(s, x.size);
>   _proc(s, x.data);
>}
> diff --git a/src/gallium/state_trackers/clover/core/module.hpp 
> b/src/gallium/state_trackers/clover/core/module.hpp
> index 2ddd26426f..ff7e9b6234 100644
> --- a/src/gallium/state_trackers/clover/core/module.hpp
> +++ b/src/gallium/state_trackers/clover/core/module.hpp
> @@ -41,14 +41,19 @@ namespace clover {
>  data_local,
>  data_private
>   };
> + enum class flags_t {
> +none,
> +allow_link_options
> + };
>
> - section(resource_id id, enum type type, size_t size,
> - const std::vector ) :
> - id(id), type(type), size(size), data(data) { }
> - section() : id(0), type(text_intermediate), size(0), data() { }
> + section(resource_id id, enum type type, flags_t flags,
> + size_t size, const std::vector ) :
> + id(id), type(type), flags(flags), size(size), data(data) { }
> + section() : id(0), type(text_intermediate), flags(flags_t::none), 
> size(0), data() { }
>
>   resource_id id;
>   type type;
> + flags_t flags;
>   size_t size;
>   std::vector data;
>};
> diff --git a/src/gallium/state_trackers/clover/llvm/codegen/bitcode.cpp 
> b/src/gallium/state_trackers/clover/llvm/codegen/bitcode.cpp
> index 40bb426218..8e9d4c7e85 100644
> --- a/src/gallium/state_trackers/clover/llvm/codegen/bitcode.cpp
> +++ b/src/gallium/state_trackers/clover/llvm/codegen/bitcode.cpp
> @@ -84,7 +84,8 @@ clover::llvm::build_module_library(const ::llvm::Module 
> ,
> enum module::section::type section_type) {
> module m;
> const auto code = emit_code(mod);
> -   m.secs.emplace_back(0, section_type, code.size(), code);
> +   m.secs.emplace_back(0, section_type, module::section::flags_t::none,
> +   code.size(), code);
> return m;
>  }
>
> diff --git a/src/gallium/state_trackers/clover/llvm/codegen/common.cpp 
> b/src/gallium/state_trackers/clover/llvm/codegen/common.cpp
> index ddf2083f37..3a08f11fcc 100644
> --- a/src/gallium/state_trackers/clover/llvm/codegen/common.cpp
> +++ b/src/gallium/state_trackers/clover/llvm/codegen/common.cpp
> @@ -179,7 +179,7 @@ namespace {
> make_text_section(const std::vector ) {
>const pipe_llvm_program_header header { uint32_t(code.size()) };
>module::section text { 0, module::section::text_executable,
> - header.num_bytes, {} };
> + module::section::flags_t::none, 
> header.num_bytes, {} };
>
>text.data.insert(text.data.end(), reinterpret_cast *>(),
> reinterpret_cast() + 
> sizeof(header));
> diff --git a/src/gallium/state_trackers/clover/tgsi/compiler.cpp 
> b/src/gallium/state_trackers/clover/tgsi/compiler.cpp
> index e165311fa4..46b8ca7a07 100644
> --- a/src/gallium/state_trackers/clover/tgsi/compiler.cpp
> +++ b/src/gallium/state_trackers/clover/tgsi/compiler.cpp
> @@ -91,7 +91,8 @@ namespace {
>
>unsigned sz = tgsi_num_tokens(prog) * sizeof(tgsi_token);
>std::vector data( (char *)prog, (char *)prog + sz );
> -  m.secs.push_back({ 0, module::section::text_executable, sz, data });
> +  m.secs.push_back({ 0, module::section::text_executable,
> + module::section::flags_t::none, sz, data });

If you re-order the TGSI-backend removal, this hunk becomes unnecessary.

Might be more trouble than it's worth.

Either way works for me.

> }
>  }
>
> --
> 2.16.2
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> 

Re: [Mesa-dev] vulkan/wsi/wayland: Add support for zwp_dmabuf

[Dieter Nützel]

Am 22.02.2018 02:35, schrieb Dave Airlie:

2018-02-22 10:57 GMT+10:00 Dieter Nützel :

Making all in vulkan
make[3]: Verzeichnis „/opt/mesa/src/vulkan“ wird betreten
make[3]: *** Keine Regel vorhanden, um das Ziel
„/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml“,
  benötigt von „wsi/linux-dmabuf-unstable-v1-protocol.c“, zu 
erstellen.

Schluss.
make[3]: Verzeichnis „/opt/mesa/src/vulkan“ wird verlassen
make[2]: *** [Makefile:862: all-recursive] Fehler 1
make[2]: Verzeichnis „/opt/mesa/src“ wird verlassen
make[1]: *** [Makefile:653: all] Fehler 2
make[1]: Verzeichnis „/opt/mesa/src“ wird verlassen
make: *** [Makefile:666: all-recursive] Fehler 1

I do not have (do not know of) any wayland stuff running, here.


Rerunning autogen.sh fixed that for me.

Dave.


Thanks, Dave.
With which options?
I did it several times but to no avail.

./autogen.sh --prefix=/usr/local --with-dri-drivers="" 
--with-gallium-drivers=r600,radeonsi,swrast --with-platforms=drm,x11 
--enable-nine --enable-texture-float --enable-opencl 
--disable-opencl_icd --with-vulkan-drivers=radeon


Even 'make distclean' etc. do not work for me.

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

[Mesa-dev] [Bug 105161] Validation of KHR_blend_equation_advanced stricter than NVidia

[bugzilla-daemon]

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

Kenneth Graunke  changed:

   What|Removed |Added

 Resolution|--- |NOTABUG
 Status|ASSIGNED|RESOLVED

--- Comment #7 from Kenneth Graunke  ---
layout qualifier parsing in legacy shaders should be fixed with:

commit 183ce5e629ee973d72a3e8b3361aa2de196cc203
Author: Kenneth Graunke 
Date:   Mon Feb 19 09:35:46 2018 -0800

glsl: Parse 'layout' as a token with advanced blending or bindless

Both KHR_blend_equation_advanced and ARB_bindless_texture provide
layout qualifiers, and are exposed in compatibility contexts.  We
need to parse the layout qualifier as a token in order for those
to work, but forgot to extend this check.

ARB_shader_image_load_store would need a similar treatment, but we
don't expose that in legacy OpenGL contexts.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105161
Reviewed-by: Iago Toral Quiroga 

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

Re: [Mesa-dev] [PATCH v3 05/21] clover/device: Replace usage of "1 << PIPE_SHADER_IR_*" with supports_ir

[Aaron Watry]

Patches 1-5:
Reviewed-By: Aaron Watry 

On Wed, Feb 21, 2018 at 4:50 PM, Pierre Moreau  wrote:
> Signed-off-by: Pierre Moreau 
> ---
>  src/gallium/state_trackers/clover/core/device.cpp | 6 +-
>  1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/src/gallium/state_trackers/clover/core/device.cpp 
> b/src/gallium/state_trackers/clover/core/device.cpp
> index dac03fccb9..9b15b30944 100644
> --- a/src/gallium/state_trackers/clover/core/device.cpp
> +++ b/src/gallium/state_trackers/clover/core/device.cpp
> @@ -243,11 +243,7 @@ device::vendor_name() const {
>
>  enum pipe_shader_ir
>  device::ir_format() const {
> -   int supported_irs =
> -  pipe->get_shader_param(pipe, PIPE_SHADER_COMPUTE,
> - PIPE_SHADER_CAP_SUPPORTED_IRS);
> -
> -   if (supported_irs & (1 << PIPE_SHADER_IR_NATIVE)) {
> +   if (supports_ir(PIPE_SHADER_IR_NATIVE)) {
>return PIPE_SHADER_IR_NATIVE;
> }
>
> --
> 2.16.2
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] vulkan/wsi/wayland: Add support for zwp_dmabuf

[Dave Airlie]

2018-02-22 10:57 GMT+10:00 Dieter Nützel :
> Making all in vulkan
> make[3]: Verzeichnis „/opt/mesa/src/vulkan“ wird betreten
> make[3]: *** Keine Regel vorhanden, um das Ziel
> „/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml“,
>   benötigt von „wsi/linux-dmabuf-unstable-v1-protocol.c“, zu erstellen.
> Schluss.
> make[3]: Verzeichnis „/opt/mesa/src/vulkan“ wird verlassen
> make[2]: *** [Makefile:862: all-recursive] Fehler 1
> make[2]: Verzeichnis „/opt/mesa/src“ wird verlassen
> make[1]: *** [Makefile:653: all] Fehler 2
> make[1]: Verzeichnis „/opt/mesa/src“ wird verlassen
> make: *** [Makefile:666: all-recursive] Fehler 1
>
> I do not have (do not know of) any wayland stuff running, here.

Rerunning autogen.sh fixed that for me.

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

Re: [Mesa-dev] vulkan/wsi/wayland: Add support for zwp_dmabuf

[Dieter Nützel]

Making all in vulkan
make[3]: Verzeichnis „/opt/mesa/src/vulkan“ wird betreten
make[3]: *** Keine Regel vorhanden, um das Ziel 
„/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml“,
  benötigt von „wsi/linux-dmabuf-unstable-v1-protocol.c“, zu erstellen.  
Schluss.

make[3]: Verzeichnis „/opt/mesa/src/vulkan“ wird verlassen
make[2]: *** [Makefile:862: all-recursive] Fehler 1
make[2]: Verzeichnis „/opt/mesa/src“ wird verlassen
make[1]: *** [Makefile:653: all] Fehler 2
make[1]: Verzeichnis „/opt/mesa/src“ wird verlassen
make: *** [Makefile:666: all-recursive] Fehler 1

I do not have (do not know of) any wayland stuff running, here.

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

Re: [Mesa-dev] Allocator Nouveau driver, Mesa EXT_external_objects, and DRM metadata import interfaces

[Alex Deucher]

On Wed, Feb 21, 2018 at 1:14 AM, Chad Versace  wrote:
> On Thu 21 Dec 2017, Daniel Vetter wrote:
>> On Thu, Dec 21, 2017 at 12:22 AM, Kristian Kristensen  
>> wrote:
>>> On Wed, Dec 20, 2017 at 12:41 PM, Miguel Angel Vico  
>>> wrote:
 On Wed, 20 Dec 2017 11:54:10 -0800 Kristian Høgsberg  
 wrote:
> I'd like to see concrete examples of actual display controllers
> supporting more format layouts than what can be specified with a 64
> bit modifier.

 The main problem is our tiling and other metadata parameters can't
 generally fit in a modifier, so we find passing a blob of metadata a
 more suitable mechanism.
>>>
>>> I understand that you may have n knobs with a total of more than a total of
>>> 56 bits that configure your tiling/swizzling for color buffers. What I don't
>>> buy is that you need all those combinations when passing buffers around
>>> between codecs, cameras and display controllers. Even if you're sharing
>>> between the same 3D drivers in different processes, I expect just locking
>>> down, say, 64 different combinations (you can add more over time) and
>>> assigning each a modifier would be sufficient. I doubt you'd extract
>>> meaningful performance gains from going all the way to a blob.
>
> I agree with Kristian above. In my opinion, choosing to encode in
> modifiers a precise description of every possible tiling/compression
> layout is not technically incorrect, but I believe it misses the point.
> The intention behind modifiers is not to exhaustively describe all
> possibilites.
>
> I summarized this opinion in VK_EXT_image_drm_format_modifier,
> where I wrote an "introdution to modifiers" section. Here's an excerpt:
>
> One goal of modifiers in the Linux ecosystem is to enumerate for each
> vendor a reasonably sized set of tiling formats that are appropriate for
> images shared across processes, APIs, and/or devices, where each
> participating component may possibly be from different vendors.
> A non-goal is to enumerate all tiling formats supported by all vendors.
> Some tiling formats used internally by vendors are inappropriate for
> sharing; no modifiers should be assigned to such tiling formats.

Where it gets tricky is how to select that subset?  Our tiling mode
are defined more by the asic specific constraints than the tiling mode
itself.  At a high level we have basically 3 tiling modes (out of 16
possible) that would be the minimum we'd want to expose for gfx6-8.
gfx9 uses a completely new scheme.
1. Linear (per asic stride requirements, not usable by many hw blocks)
2. 1D Thin (5 layouts, displayable, depth, thin, rotated, thick)
3. 2D Thin (1D tiling constraints, plus pipe config (18 possible),
tile split (7 possible), sample split (4 possible), num banks (4
possible), bank width (4 possible), bank height (4 possible), macro
tile aspect (4 possible) all of which are asic config specific)

I guess we could do something like:
AMD_GFX6_LINEAR_ALIGNED_64B
AMD_GFX6_LINEAR_ALIGNED_256B
AMD_GFX6_LINEAR_ALIGNED_512B
AMD_GFX6_1D_THIN_DISPLAY
AMD_GFX6_1D_THIN_DEPTH
AMD_GFX6_1D_THIN_ROTATED
AMD_GFX6_1D_THIN_THIN
AMD_GFX6_1D_THIN_THICK
AMD_GFX6_2D_1D_THIN_DISPLAY_PIPE_CONFIG_P2_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1
AMD_GFX6_2D_1D_THIN_DEPTH_PIPE_CONFIG_P2_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1
AMD_GFX6_2D_1D_THIN_ROTATED_PIPE_CONFIG_P2_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1
AMD_GFX6_2D_1D_THIN_THIN_PIPE_CONFIG_P2_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1
AMD_GFX6_2D_1D_THIN_THICK_PIPE_CONFIG_P2_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1
AMD_GFX6_2D_1D_THIN_DISPLAY_PIPE_CONFIG_P4_8x16_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1
AMD_GFX6_2D_1D_THIN_DEPTH_PIPE_CONFIG_P4_8x16_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1
AMD_GFX6_2D_1D_THIN_ROTATED_PIPE_CONFIG_P4_8x16_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1
AMD_GFX6_2D_1D_THIN_THIN_PIPE_CONFIG_P4_8x16_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1
AMD_GFX6_2D_1D_THIN_THICK_PIPE_CONFIG_P4_8x16_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1
etc.

We only probably need 40 bits to encode all of the tiling parameters
so we could do family, plus tiling encoding that still seems unwieldy
to deal with from an application perspective.  All of the parameters
affect the alignment requirements.

Alex
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org

Re: [Mesa-dev] Allocator Nouveau driver, Mesa EXT_external_objects, and DRM metadata import interfaces

[Chad Versace]

On Wed 21 Feb 2018, Daniel Vetter wrote:
> On Tue, Feb 20, 2018 at 10:14:47PM -0800, Chad Versace wrote:
> > On Thu 21 Dec 2017, Daniel Vetter wrote:
> > > On Thu, Dec 21, 2017 at 12:22 AM, Kristian Kristensen 
> > >  wrote:
> > >> On Wed, Dec 20, 2017 at 12:41 PM, Miguel Angel Vico 
> > >>  wrote:
> > >>> On Wed, 20 Dec 2017 11:54:10 -0800 Kristian Høgsberg 
> > >>>  wrote:
> >  I'd like to see concrete examples of actual display controllers
> >  supporting more format layouts than what can be specified with a 64
> >  bit modifier.
> > >>>
> > >>> The main problem is our tiling and other metadata parameters can't
> > >>> generally fit in a modifier, so we find passing a blob of metadata a
> > >>> more suitable mechanism.
> > >>
> > >> I understand that you may have n knobs with a total of more than a total 
> > >> of
> > >> 56 bits that configure your tiling/swizzling for color buffers. What I 
> > >> don't
> > >> buy is that you need all those combinations when passing buffers around
> > >> between codecs, cameras and display controllers. Even if you're sharing
> > >> between the same 3D drivers in different processes, I expect just locking
> > >> down, say, 64 different combinations (you can add more over time) and
> > >> assigning each a modifier would be sufficient. I doubt you'd extract
> > >> meaningful performance gains from going all the way to a blob.
> > 
> > I agree with Kristian above. In my opinion, choosing to encode in
> > modifiers a precise description of every possible tiling/compression
> > layout is not technically incorrect, but I believe it misses the point.
> > The intention behind modifiers is not to exhaustively describe all
> > possibilites.
> > 
> > I summarized this opinion in VK_EXT_image_drm_format_modifier,
> > where I wrote an "introdution to modifiers" section. Here's an excerpt:
> > 
> > One goal of modifiers in the Linux ecosystem is to enumerate for each
> > vendor a reasonably sized set of tiling formats that are appropriate for
> > images shared across processes, APIs, and/or devices, where each
> > participating component may possibly be from different vendors.
> > A non-goal is to enumerate all tiling formats supported by all vendors.
> > Some tiling formats used internally by vendors are inappropriate for
> > sharing; no modifiers should be assigned to such tiling formats.
> 
> fwiw (since the source of truth wrt modifiers is the kernel's uapi
> header):
> 
> Acked-by: Daniel Vetter 

Linux would eventually encounter big problems if the kernel and Vulkan
disagreed on the fundamental, unspoken Theory of Modifiers. So your
acked-by is definitely worth something here. Thanks for confirming.

> 
> I'm happy to merge modifier #define additions for pretty much anything
> where there's a need for sharing across devices/drivers/apis, explicitly
> including stuff that's only relevant for userspace and which the kernel
> nevers sees (in e.g. a kms addfb2 call). Trying to preemptively enumerate
> everything that's possible doesn't seem like a wise idea. But even then we
> can probably spare the oddball vendor prefix is a driver team really
> insists that this is what they want, best using some code that makes the
> case for them.

Yep. I believe Jason Ekstrand has tentative plans for such a modifier
that improves performance for interop in GL and Vulkan but the kernel
and Intel display hw wouldn't understand: a modifier for CCS_E images
that are fully compressed.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 6/6] intel/isl: Improve the documentation on get_default_aux_state

[Chad Versace]

On Wed 24 Jan 2018, Jason Ekstrand wrote:
> Cc: Chad Versace 
> ---
>  src/intel/isl/isl.h | 24 
>  1 file changed, 20 insertions(+), 4 deletions(-)
> 
> diff --git a/src/intel/isl/isl.h b/src/intel/isl/isl.h
> index e3acb0e..cf53b5a 100644
> --- a/src/intel/isl/isl.h
> +++ b/src/intel/isl/isl.h
> @@ -1565,10 +1565,25 @@ isl_drm_modifier_has_aux(uint64_t modifier)
>  
>  /** Returns the default isl_aux_state for the given modifier.
>   *
> - * All modified images are required to be kept out of the AUX_INVALID state
> - * but they may or may not actually be compressed and may or may not have
> - * clear color.  This function returns the worst case aux_state that we need
  

I was always uncomfortable with the phrase "worst case aux state".
I like the new, precise documentation much better.

Reviewed-by: Chad Versace 

/eom

> - * to assume when getting a surface from another process or API.
> + * If we have a modifier which supports compression, then the auxiliary data
> + * could be in state other than ISL_AUX_STATE_AUX_INVALID.  In particular, it
> + * can be in any of the following:
> + *
> + *  - ISL_AUX_STATE_CLEAR
> + *  - ISL_AUX_STATE_PARTIAL_CLEAR
> + *  - ISL_AUX_STATE_COMPRESSED_CLEAR
> + *  - ISL_AUX_STATE_COMPRESSED_NO_CLEAR
> + *  - ISL_AUX_STATE_RESOLVED
> + *  - ISL_AUX_STATE_PASS_THROUGH
> + *
> + * If the modifier does not support fast-clears, then we are guaranteed
> + * that the surface is at least partially resolved and the first three not
> + * possible.  We return ISL_AUX_STATE_COMPRESSED_CLEAR if the modifier
> + * supports fast clears and ISL_AUX_STATE_COMPRESSED_NO_CLEAR if it does not
> + * because they are the least common denominator of the set of possible aux
> + * states and will yield a valid interpretation of the aux data.
> + *
> + * For modifiers with no aux support, ISL_AUX_STATE_AUX_INVALID is returned.
>   */
>  static inline enum isl_aux_state
>  isl_drm_modifier_get_default_aux_state(uint64_t modifier)
> @@ -1579,6 +1594,7 @@ isl_drm_modifier_get_default_aux_state(uint64_t 
> modifier)
> if (!mod_info || mod_info->aux_usage == ISL_AUX_USAGE_NONE)
>return ISL_AUX_STATE_AUX_INVALID;
>  
> +   assert(mod_info->aux_usage == ISL_AUX_USAGE_CCS_E);
> return mod_info->supports_clear_color ? ISL_AUX_STATE_COMPRESSED_CLEAR :
> ISL_AUX_STATE_COMPRESSED_NO_CLEAR;
>  }
> -- 
> 2.5.0.400.gff86faf
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [ANNOUNCE] Mesa 17.3.4 release candidate

[Mark Janes]

Kenneth Graunke  writes:

> On Thursday, February 8, 2018 8:47:00 PM PST Emil Velikov wrote:
>> Rejected (9)
>> 
>> Jason Ekstrand (2):
>>   e52a9f18d69c94b7cb7f81361cdb9e2582c3d742 i965: Replace
>> draw_aux_buffer_disabled with draw_aux_usage
>>   20f70ae3858bc213e052a8434f0e637eb36203c4 i965/draw: Set
>> NEW_AUX_STATE when draw aux changes
>> Reason: Introduce multiple regressions in the piglit compute shader tests.
>
> Hi Emil,
>
> These are absolutely critical fixes.  These patches fix GPU hangs and
> crashes in Glamor which cause people's X session to die when doing
> exciting things like using their text editor, IDE, or desktop panel.
> It's responsible for a huge swath of our GPU hang bugs on i965.
>
> Did Jason or I miss an email from you about these being rejected,
> other than at the bottom of a large changelog in an RC announcement?
> Which Piglit tests are regressing?  My guess is that we just need to
> nominate another patch, as they aren't broken in master.
>
> At this point, we've done 5 point releases in the 17.3.x series, which
> have had DRI3 crashes when pageflipping (in all drivers), and X server
> hangs and crashes galore in i965/Gen9+.  Worse, we fixed those hangs a
> month ago and haven't managed to ship them yet.  We also managed to
> ship a radv that broke completely.
>
> At this point, 17.3.x is looking like the worst Mesa release in recent
> memory, and I'm about on the verge of advising people to just go back
> to 17.2 until 18.0 comes out.  It's pretty frustrating, and I feel bad
> for our users, who depend on our software for their computer to work.
>
> We have to do better, somehow - myself included.  Ideally, we'd find a
> way to avoid major bugs like this in the first place.  Barring that,
> do we need to have developers take a more active role in backporting
> fixes again?  It seems like our nomination process works for simple
> things, but for more complex series, it doesn't work as well.  Maybe
> we need to proactively put together (tested) pull requests for stable?

It seems to me that patches CCing stable or containing 'Fixes:' could be
automatically be applied to a branch for incremental test.  Anything
that doesn't apply (or generates regressions) could be bounced to the
committer for a manual backport.

The recent issues all stem from patches that do not apply cleanly to the
release branch.  Developers should be on the hook for resolving the
conflicts *and* testing the result.

Finding conflicts shortly before release means the developers have no
chance to fix them.  It also generates pressure on the release manager
to fix up other people's patches.  Personally, I wouldn't want to be in
a position where I could easily impact large numbers of users with a
simple typo.

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

Re: [Mesa-dev] [PATCH 1/6] i965/state: Ignore intel_obj->_Format for depth/stencil and ETC2

[Chad Versace]

On Tue 20 Feb 2018, Jason Ekstrand wrote:
> On Mon, Feb 19, 2018 at 10:01 AM, Chad Versace <[1]chadvers...@chromium.org>
> wrote:
> 
> On Wed 24 Jan 2018, Jason Ekstrand wrote:
> > We're about to start letting the intel_obj->_Format be the "real"
> > texture format.  For depth/stencil textures, this may be a combined
> > depth stencil format.  For ETC2 on gen7 and earlier, this will be the
> > actual ETC2 format.  This makes a bit more GL sense but means we have to
> > be careful in state upload.
> 
> What is the "real" format? It's not a rhetorical question. Throughout
> Mesa, I never know what's real and what's not. By "real", do you mean
> the untranslated user-specified glTextureView(internalformat) and
> glTexImage2D(internalformat)?  Or do you mean simply "more real than
> before" ;)
> 
> 
> By "real" format, I mean the one that the core mesa state tracking code thinks
> it is.  For texture views, that corresponds directly to an actual GL internal
> format.  For textures created through glTexImage2D (not TexStorage) with an
> internal format such as GL_RGB, it's something computed from the internal
> format and the format used for upload.

I understand now. Sounds good to me.

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

[Mesa-dev] [PATCH v3 21/21] clover: Use OpenCL 2.1 defines in place of cl_khr_il_program

[Pierre Moreau]

Signed-off-by: Pierre Moreau 
---
 src/gallium/state_trackers/clover/api/device.cpp  | 3 +--
 src/gallium/state_trackers/clover/api/program.cpp | 2 +-
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/src/gallium/state_trackers/clover/api/device.cpp 
b/src/gallium/state_trackers/clover/api/device.cpp
index 9132044b9c..9c19694c20 100644
--- a/src/gallium/state_trackers/clover/api/device.cpp
+++ b/src/gallium/state_trackers/clover/api/device.cpp
@@ -333,11 +333,10 @@ clGetDeviceInfo(cl_device_id d_dev, cl_device_info param,
   buf.as_string() = dev.supported_extensions();
   break;
 
-   case CL_DEVICE_IL_VERSION_KHR:
+   case CL_DEVICE_IL_VERSION:
   if (dev.supported_extensions().find("cl_khr_il_program") == 
std::string::npos)
  throw error(CL_INVALID_VALUE);
   buf.as_string() = std::string("SPIR-V_1.0");
-
   break;
 
case CL_DEVICE_PLATFORM:
diff --git a/src/gallium/state_trackers/clover/api/program.cpp 
b/src/gallium/state_trackers/clover/api/program.cpp
index c920168250..0dea2f81fa 100644
--- a/src/gallium/state_trackers/clover/api/program.cpp
+++ b/src/gallium/state_trackers/clover/api/program.cpp
@@ -460,7 +460,7 @@ clGetProgramInfo(cl_program d_prog, cl_program_info param,
   buf.as_string() = prog.source();
   break;
 
-   case CL_PROGRAM_IL_KHR:
+   case CL_PROGRAM_IL:
   if (prog.has_il)
  buf.as_vector() = prog.il();
   else if (r_size)
-- 
2.16.2

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

[Mesa-dev] [PATCH v3 20/21] clover: Implement clCreateProgramWithIL from OpenCL 2.1

[Pierre Moreau]

Signed-off-by: Pierre Moreau 
---

Notes:
v3: Remove the const from the length argument of clCreateProgramWithIL

 src/gallium/state_trackers/clover/api/dispatch.cpp | 2 +-
 src/gallium/state_trackers/clover/api/program.cpp  | 8 
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/src/gallium/state_trackers/clover/api/dispatch.cpp 
b/src/gallium/state_trackers/clover/api/dispatch.cpp
index 8be4d3cb26..f5f3248f26 100644
--- a/src/gallium/state_trackers/clover/api/dispatch.cpp
+++ b/src/gallium/state_trackers/clover/api/dispatch.cpp
@@ -162,7 +162,7 @@ namespace clover {
   NULL, // clSetKernelExecInfo
   NULL, // clGetKernelSubGroupInfoKHR
   NULL, // clCloneKernel
-  NULL, // clCreateProgramWithIL
+  clCreateProgramWithIL,
   NULL, // clEnqueueSVMMigrateMem
   NULL, // clGetDeviceAndHostTimer
   NULL, // clGetHostTimer
diff --git a/src/gallium/state_trackers/clover/api/program.cpp 
b/src/gallium/state_trackers/clover/api/program.cpp
index 81d6e7cf2a..c920168250 100644
--- a/src/gallium/state_trackers/clover/api/program.cpp
+++ b/src/gallium/state_trackers/clover/api/program.cpp
@@ -212,6 +212,14 @@ clover::CreateProgramWithILKHR(cl_context d_ctx, const 
void *il,
return NULL;
 }
 
+CLOVER_API cl_program
+clCreateProgramWithIL(cl_context d_ctx,
+  const void *il,
+  size_t length,
+  cl_int *r_errcode) {
+   return CreateProgramWithILKHR(d_ctx, il, length, r_errcode);
+}
+
 CLOVER_API cl_program
 clCreateProgramWithBuiltInKernels(cl_context d_ctx, cl_uint n,
   const cl_device_id *d_devs,
-- 
2.16.2

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

[Mesa-dev] [PATCH v3 16/21] clover: Implement clCreateProgramWithILKHR

[Pierre Moreau]

Signed-off-by: Pierre Moreau 
---

Notes:
v3:
* Remove the const on the length argument to CreateProgramWithILKHR 
(Francisco
  Jerez);
* Capitalize comment (Francisco Jerez);
* Store the IL as a std::vector instead of a pointer + size (Francisco 
Jerez);
* Remove the destructor, due to previous change;
* Remove endianness conversion, as already performed later on (Francisco 
Jerez);
* Introduce a free function for compile_program, which calls the right 
compile
  function based on the IR format (Francisco Jerez);
* Add dependency on SPIRV-Tools, as we validate the SPIR-V module fed to
  clCreateProgramWithILKHR;
* Introduce an enum for representing which IL is stored in program;
* Correctly initialise the devices associated to a program created from
  clCreateProgramWithILKHR;
* Introduce free functions for validating the SPIR-V binary, and detecting 
the
  IL used in the binary fed to clCreateProgramWithILKHR.

 src/gallium/state_trackers/clover/Makefile.am  |  6 +-
 src/gallium/state_trackers/clover/api/dispatch.hpp |  4 ++
 src/gallium/state_trackers/clover/api/program.cpp  | 81 +-
 src/gallium/state_trackers/clover/core/program.cpp | 46 +---
 src/gallium/state_trackers/clover/core/program.hpp | 12 
 src/gallium/state_trackers/clover/meson.build  |  1 +
 6 files changed, 139 insertions(+), 11 deletions(-)

diff --git a/src/gallium/state_trackers/clover/Makefile.am 
b/src/gallium/state_trackers/clover/Makefile.am
index 35ee092f3f..9ae053ac5e 100644
--- a/src/gallium/state_trackers/clover/Makefile.am
+++ b/src/gallium/state_trackers/clover/Makefile.am
@@ -46,11 +46,15 @@ libclllvm_la_SOURCES = $(LLVM_SOURCES)
 libclover_la_CXXFLAGS = \
$(CXX11_CXXFLAGS) \
$(CLOVER_STD_OVERRIDE) \
-   $(VISIBILITY_CXXFLAGS)
+   $(VISIBILITY_CXXFLAGS) \
+   $(SPIRV_TOOLS_CFLAGS)
 
 libclover_la_LIBADD = \
libclllvm.la
 
+libclover_la_LDFLAGS = \
+   $(SPIRV_TOOLS_LIBS)
+
 libclover_la_SOURCES = $(CPP_SOURCES)
 
 EXTRA_DIST = Doxyfile meson.build
diff --git a/src/gallium/state_trackers/clover/api/dispatch.hpp 
b/src/gallium/state_trackers/clover/api/dispatch.hpp
index 60fb75a146..3d5fc7bf47 100644
--- a/src/gallium/state_trackers/clover/api/dispatch.hpp
+++ b/src/gallium/state_trackers/clover/api/dispatch.hpp
@@ -974,6 +974,10 @@ namespace clover {
cl_int
IcdGetPlatformIDsKHR(cl_uint num_entries, cl_platform_id *rd_platforms,
 cl_uint *rnum_platforms);
+
+   cl_program
+   CreateProgramWithILKHR(cl_context d_ctx, const void *il,
+  size_t length, cl_int *r_errcode);
 }
 
 #endif
diff --git a/src/gallium/state_trackers/clover/api/program.cpp 
b/src/gallium/state_trackers/clover/api/program.cpp
index 022ddbdbcc..c618557adf 100644
--- a/src/gallium/state_trackers/clover/api/program.cpp
+++ b/src/gallium/state_trackers/clover/api/program.cpp
@@ -21,9 +21,13 @@
 //
 
 #include "api/util.hpp"
+#include "compiler/spirv/spirv.h"
 #include "core/program.hpp"
+#include "util/u_math.h"
 #include "util/u_debug.h"
 
+#include 
+
 #include 
 
 using namespace clover;
@@ -52,6 +56,56 @@ namespace {
 
   return devs;
}
+
+   bool
+   is_valid_spirv(const uint32_t *binary, size_t length,
+  const context::notify_action ) {
+  auto const validator_consumer = [](spv_message_level_t level,
+   const char * /* source */,
+   const spv_position_t ,
+   const char *message) {
+ if (!notify)
+return;
+
+ std::string str_level;
+ switch (level) {
+#define LVL2STR(lvl) case SPV_MSG_##lvl: str_level = std::string(#lvl)
+LVL2STR(FATAL);
+LVL2STR(INTERNAL_ERROR);
+LVL2STR(ERROR);
+LVL2STR(WARNING);
+LVL2STR(INFO);
+LVL2STR(DEBUG);
+#undef LVL2STR
+ }
+ const std::string log = "[" + str_level + "] At word No." +
+ std::to_string(position.index) + ": \"" +
+ message + "\"";
+ notify(log.c_str());
+  };
+
+  spvtools::SpirvTools spvTool(SPV_ENV_OPENCL_1_2);
+  spvTool.SetMessageConsumer(validator_consumer);
+
+  return spvTool.Validate(binary, length);
+   }
+
+   enum program::il_type
+   identify_and_validate_il(const void *il, size_t length,
+const context::notify_action ) {
+
+  enum program::il_type il_type = program::il_type::none;
+
+  const uint32_t *stream = reinterpret_cast(il);
+  if (stream[0] == SpvMagicNumber ||
+ util_bswap32(stream[0]) == SpvMagicNumber) {
+ if (!is_valid_spirv(stream, length / 4u, notify))
+throw error(CL_INVALID_VALUE);
+ il_type = program::il_type::spirv;
+ 

[Mesa-dev] [PATCH v3 19/21] clover: Advertise cl_khr_il_program

[Pierre Moreau]

Signed-off-by: Pierre Moreau 
---

Notes:
v3: Advertise cl_khr_il_program if if the device support NATIVE as IR

 src/gallium/state_trackers/clover/api/platform.cpp | 2 ++
 src/gallium/state_trackers/clover/core/device.cpp  | 4 +++-
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/src/gallium/state_trackers/clover/api/platform.cpp 
b/src/gallium/state_trackers/clover/api/platform.cpp
index 887dfd0a22..7f4c959abb 100644
--- a/src/gallium/state_trackers/clover/api/platform.cpp
+++ b/src/gallium/state_trackers/clover/api/platform.cpp
@@ -107,6 +107,8 @@ clover::GetExtensionFunctionAddress(const char *p_name) {
 
if (name == "clIcdGetPlatformIDsKHR")
   return reinterpret_cast(IcdGetPlatformIDsKHR);
+   else if (name == "clCreateProgramWithILKHR")
+  return reinterpret_cast(CreateProgramWithILKHR);
else
   return NULL;
 }
diff --git a/src/gallium/state_trackers/clover/core/device.cpp 
b/src/gallium/state_trackers/clover/core/device.cpp
index a6adfe0a77..93eaf6a812 100644
--- a/src/gallium/state_trackers/clover/core/device.cpp
+++ b/src/gallium/state_trackers/clover/core/device.cpp
@@ -280,6 +280,7 @@ device::supports_ir(enum pipe_shader_ir ir) const {
 
 std::string
 device::supported_extensions() const {
+   const bool supports_il_program = supports_ir(PIPE_SHADER_IR_NATIVE);
return
   "cl_khr_byte_addressable_store"
   " cl_khr_global_int32_base_atomics"
@@ -289,5 +290,6 @@ device::supported_extensions() const {
   + std::string(has_int64_atomics() ? " cl_khr_int64_base_atomics" : "")
   + std::string(has_int64_atomics() ? " cl_khr_int64_extended_atomics" : 
"")
   + std::string(has_doubles() ? " cl_khr_fp64" : "")
-  + std::string(has_halves() ? " cl_khr_fp16" : "");
+  + std::string(has_halves() ? " cl_khr_fp16" : "")
+  + std::string(supports_il_program ? " cl_khr_il_program" : "");
 }
-- 
2.16.2

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

[Mesa-dev] [PATCH v3 13/21] configure.ac, meson: Check for SPIRV-Tools and llvm-spirv

[Pierre Moreau]

Signed-off-by: Pierre Moreau 
---

Notes:
v3:
* Bump the required version of SPIRV-Tools to the latest release;
* Add a dependency on llvm-spirv.

 configure.ac | 10 ++
 meson.build  |  4 
 2 files changed, 14 insertions(+)

diff --git a/configure.ac b/configure.ac
index 8a9172690a..1d393a5234 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2386,6 +2386,16 @@ AM_CONDITIONAL(HAVE_CLOVER_ICD, test 
"x$enable_opencl_icd" = xyes)
 AC_SUBST([OPENCL_LIBNAME])
 AC_SUBST([CLANG_RESOURCE_DIR])
 
+AS_IF([test "x$enable_opencl" = xyes], [
+PKG_CHECK_MODULES([SPIRV_TOOLS], [SPIRV-Tools >= 2018.0])])
+AC_SUBST([SPIRV_TOOLS_CFLAGS])
+AC_SUBST([SPIRV_TOOLS_LIBS])
+
+AS_IF([test "x$enable_opencl" = xyes], [
+PKG_CHECK_MODULES([LLVM_SPIRV], [llvm-spirv])])
+AC_SUBST([LLVM_SPIRV_CFLAGS])
+AC_SUBST([LLVM_SPIRV_LIBS])
+
 dnl
 dnl Gallium configuration
 dnl
diff --git a/meson.build b/meson.build
index 8cf67b8171..c67bd32d0f 100644
--- a/meson.build
+++ b/meson.build
@@ -596,10 +596,14 @@ if _opencl != 'disabled'
 
   # TODO: alitvec?
   dep_clc = dependency('libclc')
+  dep_spirv_tools = dependency('SPIRV-Tools', version : '>= 2018.0')
+  dep_llvm_spirv = dependency('llvm-spirv')
   with_gallium_opencl = true
   with_opencl_icd = _opencl == 'icd'
 else
   dep_clc = []
+  dep_spirv_tools = []
+  dep_llvm_spirv = []
   with_gallium_opencl = false
   with_gallium_icd = false
 endif
-- 
2.16.2

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

[Mesa-dev] [PATCH v3 17/21] clover: Handle CL_PROGRAM_IL_KHR in clGetProgramInfo

[Pierre Moreau]

Signed-off-by: Pierre Moreau 
---

Notes:
v3: Switch from using a pointer attribute to a vector (Francisco Jerez)

 src/gallium/state_trackers/clover/api/program.cpp | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/src/gallium/state_trackers/clover/api/program.cpp 
b/src/gallium/state_trackers/clover/api/program.cpp
index c618557adf..81d6e7cf2a 100644
--- a/src/gallium/state_trackers/clover/api/program.cpp
+++ b/src/gallium/state_trackers/clover/api/program.cpp
@@ -452,6 +452,13 @@ clGetProgramInfo(cl_program d_prog, cl_program_info param,
   buf.as_string() = prog.source();
   break;
 
+   case CL_PROGRAM_IL_KHR:
+  if (prog.has_il)
+ buf.as_vector() = prog.il();
+  else if (r_size)
+ *r_size = 0u;
+  break;
+
case CL_PROGRAM_BINARY_SIZES:
   buf.as_vector() = map([&](const device ) {
 return prog.build(dev).binary.size();
-- 
2.16.2

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

[Mesa-dev] [PATCH v3 18/21] clover/api: Implement CL_DEVICE_IL_VERSION_KHR

[Pierre Moreau]

Signed-off-by: Pierre Moreau 
---

Notes:
v3: Throw an exception if the cl_khr_il_program extension is not supported
(Francisco Jerez)

 src/gallium/state_trackers/clover/api/device.cpp | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/src/gallium/state_trackers/clover/api/device.cpp 
b/src/gallium/state_trackers/clover/api/device.cpp
index 4e274c5005..9132044b9c 100644
--- a/src/gallium/state_trackers/clover/api/device.cpp
+++ b/src/gallium/state_trackers/clover/api/device.cpp
@@ -333,6 +333,13 @@ clGetDeviceInfo(cl_device_id d_dev, cl_device_info param,
   buf.as_string() = dev.supported_extensions();
   break;
 
+   case CL_DEVICE_IL_VERSION_KHR:
+  if (dev.supported_extensions().find("cl_khr_il_program") == 
std::string::npos)
+ throw error(CL_INVALID_VALUE);
+  buf.as_string() = std::string("SPIR-V_1.0");
+
+  break;
+
case CL_DEVICE_PLATFORM:
   buf.as_scalar() = desc(dev.platform);
   break;
-- 
2.16.2

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

[Mesa-dev] [PATCH v3 11/21] clover: Move platform extensions definitions to clover/platform.cpp

[Pierre Moreau]

Reviewed-by: Francisco Jerez 
Signed-off-by: Pierre Moreau 
---
 src/gallium/state_trackers/clover/api/platform.cpp  | 4 ++--
 src/gallium/state_trackers/clover/core/platform.cpp | 5 +
 src/gallium/state_trackers/clover/core/platform.hpp | 2 ++
 3 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/src/gallium/state_trackers/clover/api/platform.cpp 
b/src/gallium/state_trackers/clover/api/platform.cpp
index ed86163311..887dfd0a22 100644
--- a/src/gallium/state_trackers/clover/api/platform.cpp
+++ b/src/gallium/state_trackers/clover/api/platform.cpp
@@ -50,7 +50,7 @@ clover::GetPlatformInfo(cl_platform_id d_platform, 
cl_platform_info param,
 size_t size, void *r_buf, size_t *r_size) try {
property_buffer buf { r_buf, size, r_size };
 
-   obj(d_platform);
+   auto  = obj(d_platform);
 
switch (param) {
case CL_PLATFORM_PROFILE:
@@ -74,7 +74,7 @@ clover::GetPlatformInfo(cl_platform_id d_platform, 
cl_platform_info param,
   break;
 
case CL_PLATFORM_EXTENSIONS:
-  buf.as_string() = "cl_khr_icd";
+  buf.as_string() = platform.supported_extensions();
   break;
 
case CL_PLATFORM_ICD_SUFFIX_KHR:
diff --git a/src/gallium/state_trackers/clover/core/platform.cpp 
b/src/gallium/state_trackers/clover/core/platform.cpp
index 489e8dc5a8..ddd63fc5a0 100644
--- a/src/gallium/state_trackers/clover/core/platform.cpp
+++ b/src/gallium/state_trackers/clover/core/platform.cpp
@@ -39,3 +39,8 @@ platform::platform() : adaptor_range(evals(), devs) {
   }
}
 }
+
+std::string
+platform::supported_extensions() const {
+   return "cl_khr_icd";
+}
diff --git a/src/gallium/state_trackers/clover/core/platform.hpp 
b/src/gallium/state_trackers/clover/core/platform.hpp
index e849645bbe..b94434c983 100644
--- a/src/gallium/state_trackers/clover/core/platform.hpp
+++ b/src/gallium/state_trackers/clover/core/platform.hpp
@@ -40,6 +40,8 @@ namespace clover {
   platform &
   operator=(const platform ) = delete;
 
+  std::string supported_extensions() const;
+
protected:
   std::vector devs;
};
-- 
2.16.2

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

[Mesa-dev] [PATCH v3 15/21] include/CL: Add cl_khr_il_program

[Pierre Moreau]

Reviewed-by: Karol Herbst 
Signed-off-by: Pierre Moreau 
---
 include/CL/cl_ext.h | 37 +
 1 file changed, 37 insertions(+)

diff --git a/include/CL/cl_ext.h b/include/CL/cl_ext.h
index 5078e8f45f..5ea4968042 100644
--- a/include/CL/cl_ext.h
+++ b/include/CL/cl_ext.h
@@ -599,6 +599,43 @@ clSetKernelExecInfoARM(cl_kernel/* kernel */,
 
 #endif /* CL_VERSION_1_2 */
 
+/***
+ * cl_khr_il_program extension *
+ ***/
+
+#if defined(CL_VERSION_1_2) || defined(CL_VERSION_2_0)
+
+#ifndef cl_khr_il_program
+#define cl_khr_il_program 1
+
+/* New property to clGetDeviceInfo for retrieving supported intermediate
+ * languages
+ */
+#define CL_DEVICE_IL_VERSION_KHR0x105B
+
+/* New property to clGetProgramInfo for retrieving for retrieving the IL of a
+ * program
+ */
+#define CL_PROGRAM_IL_KHR   0x1169
+
+extern CL_API_ENTRY cl_program
+  CL_API_CALL clCreateProgramWithILKHR(
+  cl_context /* context */,
+  const void * /* il */,
+  size_t /* length */,
+  cl_int * /* errcode_ret */) CL_EXT_SUFFIX__VERSION_1_2;
+
+typedef CL_API_ENTRY cl_program
+  (CL_API_CALL *clCreateProgramWithILKHR_fn)(
+  cl_context /* context */,
+  const void * /* il */,
+  size_t /* length */,
+  cl_int * /* errcode_ret */) CL_EXT_SUFFIX__VERSION_1_2;
+
+#endif /* CL_VERSION_1_2 || CL_VERSION_2_0 */
+
+#endif /* cl_khr_il_program */
+
 #ifdef __cplusplus
 }
 #endif
-- 
2.16.2

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

[Mesa-dev] [PATCH v3 14/21] clover/llvm: Allow translating from SPIR-V to LLVM IR

[Pierre Moreau]

Signed-off-by: Pierre Moreau 
---
 .../state_trackers/clover/llvm/invocation.cpp  | 26 ++
 .../state_trackers/clover/llvm/invocation.hpp  |  4 
 src/gallium/state_trackers/clover/meson.build  |  2 +-
 3 files changed, 31 insertions(+), 1 deletion(-)

diff --git a/src/gallium/state_trackers/clover/llvm/invocation.cpp 
b/src/gallium/state_trackers/clover/llvm/invocation.cpp
index e4ca5fa444..8fcf93eefd 100644
--- a/src/gallium/state_trackers/clover/llvm/invocation.cpp
+++ b/src/gallium/state_trackers/clover/llvm/invocation.cpp
@@ -24,12 +24,15 @@
 // OTHER DEALINGS IN THE SOFTWARE.
 //
 
+#include 
+
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -301,3 +304,26 @@ clover::llvm::link_program(const std::vector 
,
   unreachable("Unsupported IR.");
}
 }
+
+module
+clover::llvm::compile_from_spirv(const std::vector ,
+ const device ,
+ std::string _log) {
+   auto ctx = create_context(r_log);
+
+   ::llvm::Module *unsafe_mod;
+   std::string error_msg;
+   std::stringstream input(std::ios_base::binary);
+   std::copy(binary.begin(), binary.end(), std::ostream_iterator(input, 
""));
+   if (!::llvm::ReadSPIRV(*ctx, input, unsafe_mod, error_msg)) {
+  r_log += "Failed to convert SPIR-V to LLVM IR: " + error_msg + ".\n";
+  throw error(CL_INVALID_VALUE);
+   }
+
+   std::unique_ptr<::llvm::Module> mod(unsafe_mod);
+
+   if (has_flag(debug::llvm))
+  debug::log(".ll", print_module_bitcode(*mod));
+
+   return build_module_library(*mod, module::section::text_intermediate);
+}
diff --git a/src/gallium/state_trackers/clover/llvm/invocation.hpp 
b/src/gallium/state_trackers/clover/llvm/invocation.hpp
index 5b3530c382..17fa416136 100644
--- a/src/gallium/state_trackers/clover/llvm/invocation.hpp
+++ b/src/gallium/state_trackers/clover/llvm/invocation.hpp
@@ -41,6 +41,10 @@ namespace clover {
   const std::string ,
   const std::string ,
   std::string _log);
+
+  module compile_from_spirv(const std::vector ,
+const device ,
+std::string _log);
}
 }
 
diff --git a/src/gallium/state_trackers/clover/meson.build 
b/src/gallium/state_trackers/clover/meson.build
index c52f0faa40..bffd0df11d 100644
--- a/src/gallium/state_trackers/clover/meson.build
+++ b/src/gallium/state_trackers/clover/meson.build
@@ -48,7 +48,7 @@ libclllvm = static_library(
   dep_llvm.get_configtool_variable('version'), 'include',
 )),
   ],
-  dependencies : [dep_llvm, dep_elf],
+  dependencies : [dep_llvm, dep_elf, dep_llvm_spirv],
 )
 
 clover_files = files(
-- 
2.16.2

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

[Mesa-dev] [PATCH v3 12/21] clover: Remove the TGSI backend as unused

[Pierre Moreau]

Signed-off-by: Pierre Moreau 
---
 src/gallium/state_trackers/clover/Makefile.am  |  11 +-
 src/gallium/state_trackers/clover/Makefile.sources |   4 -
 src/gallium/state_trackers/clover/core/program.cpp |  15 +--
 src/gallium/state_trackers/clover/meson.build  |   9 +-
 .../state_trackers/clover/tgsi/compiler.cpp| 121 -
 .../state_trackers/clover/tgsi/invocation.hpp  |  37 ---
 6 files changed, 9 insertions(+), 188 deletions(-)
 delete mode 100644 src/gallium/state_trackers/clover/tgsi/compiler.cpp
 delete mode 100644 src/gallium/state_trackers/clover/tgsi/invocation.hpp

diff --git a/src/gallium/state_trackers/clover/Makefile.am 
b/src/gallium/state_trackers/clover/Makefile.am
index a7befb4605..35ee092f3f 100644
--- a/src/gallium/state_trackers/clover/Makefile.am
+++ b/src/gallium/state_trackers/clover/Makefile.am
@@ -28,14 +28,7 @@ cl_HEADERS = \
$(top_srcdir)/include/CL/opencl.h
 endif
 
-noinst_LTLIBRARIES = libclover.la libcltgsi.la libclllvm.la
-
-libcltgsi_la_CXXFLAGS = \
-   $(CXX11_CXXFLAGS) \
-   $(CLOVER_STD_OVERRIDE) \
-   $(VISIBILITY_CXXFLAGS)
-
-libcltgsi_la_SOURCES = $(TGSI_SOURCES)
+noinst_LTLIBRARIES = libclover.la libclllvm.la
 
 libclllvm_la_CXXFLAGS = \
$(CXX11_CXXFLAGS) \
@@ -56,7 +49,7 @@ libclover_la_CXXFLAGS = \
$(VISIBILITY_CXXFLAGS)
 
 libclover_la_LIBADD = \
-   libcltgsi.la libclllvm.la
+   libclllvm.la
 
 libclover_la_SOURCES = $(CPP_SOURCES)
 
diff --git a/src/gallium/state_trackers/clover/Makefile.sources 
b/src/gallium/state_trackers/clover/Makefile.sources
index e9828b107b..5167ca75af 100644
--- a/src/gallium/state_trackers/clover/Makefile.sources
+++ b/src/gallium/state_trackers/clover/Makefile.sources
@@ -62,7 +62,3 @@ LLVM_SOURCES := \
llvm/invocation.hpp \
llvm/metadata.hpp \
llvm/util.hpp
-
-TGSI_SOURCES := \
-   tgsi/compiler.cpp \
-   tgsi/invocation.hpp
diff --git a/src/gallium/state_trackers/clover/core/program.cpp 
b/src/gallium/state_trackers/clover/core/program.cpp
index 1a4a75b961..1ad58c2be5 100644
--- a/src/gallium/state_trackers/clover/core/program.cpp
+++ b/src/gallium/state_trackers/clover/core/program.cpp
@@ -22,7 +22,6 @@
 
 #include "core/program.hpp"
 #include "llvm/invocation.hpp"
-#include "tgsi/invocation.hpp"
 
 using namespace clover;
 
@@ -52,10 +51,9 @@ program::compile(const ref_vector , const 
std::string ,
  std::string log;
 
  try {
-const module m = (dev.ir_format() == PIPE_SHADER_IR_TGSI ?
-  tgsi::compile_program(_source, log) :
-  llvm::compile_program(_source, headers,
-dev.ir_target(), opts, 
log));
+assert(dev.ir_format() == PIPE_SHADER_IR_NATIVE);
+const module m = llvm::compile_program(_source, headers,
+   dev.ir_target(), opts, log);
 _builds[] = { m, opts, log };
  } catch (...) {
 _builds[] = { module(), opts, log };
@@ -77,10 +75,9 @@ program::link(const ref_vector , const 
std::string ,
   std::string log = _builds[].log;
 
   try {
- const module m = (dev.ir_format() == PIPE_SHADER_IR_TGSI ?
-   tgsi::link_program(ms) :
-   llvm::link_program(ms, dev.ir_format(),
-  dev.ir_target(), opts, log));
+ assert(dev.ir_format() == PIPE_SHADER_IR_NATIVE);
+ const module m = llvm::link_program(ms, dev.ir_format(),
+ dev.ir_target(), opts, log);
  _builds[] = { m, opts, log };
   } catch (...) {
  _builds[] = { module(), opts, log };
diff --git a/src/gallium/state_trackers/clover/meson.build 
b/src/gallium/state_trackers/clover/meson.build
index d1497e657e..c52f0faa40 100644
--- a/src/gallium/state_trackers/clover/meson.build
+++ b/src/gallium/state_trackers/clover/meson.build
@@ -25,13 +25,6 @@ if with_opencl_icd
   clover_cpp_args += '-DHAVE_CLOVER_ICD'
 endif
 
-libcltgsi = static_library(
-  'cltgsi',
-  files('tgsi/compiler.cpp', 'tgsi/invocation.hpp'),
-  include_directories : clover_incs,
-  cpp_args : [cpp_vis_args],
-)
-
 libclllvm = static_library(
   'clllvm',
   files(
@@ -118,5 +111,5 @@ libclover = static_library(
   clover_files,
   include_directories : clover_incs,
   cpp_args : [clover_cpp_args, cpp_vis_args],
-  link_with : [libcltgsi, libclllvm],
+  link_with : [libclllvm],
 )
diff --git a/src/gallium/state_trackers/clover/tgsi/compiler.cpp 
b/src/gallium/state_trackers/clover/tgsi/compiler.cpp
deleted file mode 100644
index 46b8ca7a07..00
--- a/src/gallium/state_trackers/clover/tgsi/compiler.cpp
+++ /dev/null
@@ -1,121 +0,0 @@
-//
-// Copyright 2012 Francisco Jerez
-//
-// Permission is hereby granted, free of charge, to any person obtaining a

[Mesa-dev] [PATCH v3 06/21] clover/api: Rework the validation of devices for building

[Pierre Moreau]

Signed-off-by: Pierre Moreau 
---
 src/gallium/state_trackers/clover/api/program.cpp  | 39 +-
 src/gallium/state_trackers/clover/core/program.cpp |  3 +-
 2 files changed, 25 insertions(+), 17 deletions(-)

diff --git a/src/gallium/state_trackers/clover/api/program.cpp 
b/src/gallium/state_trackers/clover/api/program.cpp
index 9d59668f8f..babe45ccde 100644
--- a/src/gallium/state_trackers/clover/api/program.cpp
+++ b/src/gallium/state_trackers/clover/api/program.cpp
@@ -29,9 +29,10 @@
 using namespace clover;
 
 namespace {
-   void
+   ref_vector
validate_build_common(const program , cl_uint num_devs,
  const cl_device_id *d_devs,
+ ref_vector _devs,
  void (*pfn_notify)(cl_program, void *),
  void *user_data) {
   if (!pfn_notify && user_data)
@@ -40,10 +41,16 @@ namespace {
   if (prog.kernel_ref_count())
  throw error(CL_INVALID_OPERATION);
 
+  if ((!d_devs && num_devs > 0u) || (d_devs && num_devs == 0u))
+ throw error(CL_INVALID_VALUE);
+
+  auto devs = (d_devs ? objs(d_devs, num_devs) : valid_devs);
   if (any_of([&](const device ) {
-   return !count(dev, prog.context().devices());
-}, objs(d_devs, num_devs)))
+   return !count(dev, valid_devs);
+}, devs))
  throw error(CL_INVALID_DEVICE);
+
+  return devs;
}
 }
 
@@ -176,13 +183,12 @@ clBuildProgram(cl_program d_prog, cl_uint num_devs,
void (*pfn_notify)(cl_program, void *),
void *user_data) try {
auto  = obj(d_prog);
-   auto devs = (d_devs ? objs(d_devs, num_devs) :
-ref_vector(prog.context().devices()));
+   auto valid_devs = ref_vector(prog.devices());
+   auto devs = validate_build_common(prog, num_devs, d_devs, valid_devs,
+ pfn_notify, user_data);
const auto opts = std::string(p_opts ? p_opts : "") + " " +
  debug_get_option("CLOVER_EXTRA_BUILD_OPTIONS", "");
 
-   validate_build_common(prog, num_devs, d_devs, pfn_notify, user_data);
-
if (prog.has_source) {
   prog.compile(devs, opts);
   prog.link(devs, opts, { prog });
@@ -202,14 +208,13 @@ clCompileProgram(cl_program d_prog, cl_uint num_devs,
  void (*pfn_notify)(cl_program, void *),
  void *user_data) try {
auto  = obj(d_prog);
-   auto devs = (d_devs ? objs(d_devs, num_devs) :
-ref_vector(prog.context().devices()));
+   auto valid_devs = ref_vector(prog.devices());
+   auto devs = validate_build_common(prog, num_devs, d_devs, valid_devs,
+ pfn_notify, user_data);
const auto opts = std::string(p_opts ? p_opts : "") + " " +
  debug_get_option("CLOVER_EXTRA_COMPILE_OPTIONS", "");
header_map headers;
 
-   validate_build_common(prog, num_devs, d_devs, pfn_notify, user_data);
-
if (bool(num_headers) != bool(header_names))
   throw error(CL_INVALID_VALUE);
 
@@ -275,16 +280,18 @@ clLinkProgram(cl_context d_ctx, cl_uint num_devs, const 
cl_device_id *d_devs,
   const char *p_opts, cl_uint num_progs, const cl_program *d_progs,
   void (*pfn_notify) (cl_program, void *), void *user_data,
   cl_int *r_errcode) try {
+   if (num_progs == 0u || (num_progs != 0u && !d_progs))
+  throw error(CL_INVALID_VALUE);
+
auto  = obj(d_ctx);
const auto opts = std::string(p_opts ? p_opts : "") + " " +
  debug_get_option("CLOVER_EXTRA_LINK_OPTIONS", "");
auto progs = objs(d_progs, num_progs);
auto prog = create(ctx);
-   auto devs = validate_link_devices(progs,
- (d_devs ? objs(d_devs, num_devs) :
-  ref_vector(ctx.devices(;
-
-   validate_build_common(prog, num_devs, d_devs, pfn_notify, user_data);
+   auto valid_devs = ref_vector(ctx.devices());
+   auto devs = validate_build_common(prog, num_devs, d_devs, valid_devs,
+ pfn_notify, user_data);
+   devs = validate_link_devices(progs, devs);
 
try {
   prog().link(devs, opts, progs);
diff --git a/src/gallium/state_trackers/clover/core/program.cpp 
b/src/gallium/state_trackers/clover/core/program.cpp
index ae4b50a879..1a4a75b961 100644
--- a/src/gallium/state_trackers/clover/core/program.cpp
+++ b/src/gallium/state_trackers/clover/core/program.cpp
@@ -27,7 +27,8 @@
 using namespace clover;
 
 program::program(clover::context , const std::string ) :
-   has_source(true), context(ctx), _source(source), _kernel_ref_counter(0) {
+   has_source(true), context(ctx), _devices(ctx.devices()), _source(source),
+   _kernel_ref_counter(0) {
 }
 
 program::program(clover::context ,
-- 
2.16.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org

[Mesa-dev] [PATCH v3 05/21] clover/device: Replace usage of "1 << PIPE_SHADER_IR_*" with supports_ir

[Pierre Moreau]

Signed-off-by: Pierre Moreau 
---
 src/gallium/state_trackers/clover/core/device.cpp | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/src/gallium/state_trackers/clover/core/device.cpp 
b/src/gallium/state_trackers/clover/core/device.cpp
index dac03fccb9..9b15b30944 100644
--- a/src/gallium/state_trackers/clover/core/device.cpp
+++ b/src/gallium/state_trackers/clover/core/device.cpp
@@ -243,11 +243,7 @@ device::vendor_name() const {
 
 enum pipe_shader_ir
 device::ir_format() const {
-   int supported_irs =
-  pipe->get_shader_param(pipe, PIPE_SHADER_COMPUTE,
- PIPE_SHADER_CAP_SUPPORTED_IRS);
-
-   if (supported_irs & (1 << PIPE_SHADER_IR_NATIVE)) {
+   if (supports_ir(PIPE_SHADER_IR_NATIVE)) {
   return PIPE_SHADER_IR_NATIVE;
}
 
-- 
2.16.2

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

[Mesa-dev] [PATCH v3 04/21] clover: Add an helper for checking if an IR is supported

[Pierre Moreau]

Signed-off-by: Pierre Moreau 
---

Notes:
v3:
* Dropped supported_irs() (Francisco Jerez)
* Changed supports_ir() argument type to `enum pipe_shader_ir` (Francisco 
Jerez)

 src/gallium/state_trackers/clover/core/device.cpp | 6 ++
 src/gallium/state_trackers/clover/core/device.hpp | 1 +
 2 files changed, 7 insertions(+)

diff --git a/src/gallium/state_trackers/clover/core/device.cpp 
b/src/gallium/state_trackers/clover/core/device.cpp
index 71cf4bf60a..dac03fccb9 100644
--- a/src/gallium/state_trackers/clover/core/device.cpp
+++ b/src/gallium/state_trackers/clover/core/device.cpp
@@ -275,3 +275,9 @@ std::string
 device::device_clc_version() const {
 return "1.1";
 }
+
+bool
+device::supports_ir(enum pipe_shader_ir ir) const {
+   return pipe->get_shader_param(pipe, PIPE_SHADER_COMPUTE,
+ PIPE_SHADER_CAP_SUPPORTED_IRS) & (1 << ir);
+}
diff --git a/src/gallium/state_trackers/clover/core/device.hpp 
b/src/gallium/state_trackers/clover/core/device.hpp
index 85cd031676..ebe15f28e9 100644
--- a/src/gallium/state_trackers/clover/core/device.hpp
+++ b/src/gallium/state_trackers/clover/core/device.hpp
@@ -82,6 +82,7 @@ namespace clover {
   enum pipe_shader_ir ir_format() const;
   std::string ir_target() const;
   enum pipe_endian endianness() const;
+  bool supports_ir(enum pipe_shader_ir ir) const;
 
   friend class command_queue;
   friend class root_resource;
-- 
2.16.2

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

[Mesa-dev] [PATCH v3 10/21] clover: Move device extensions definitions to core/device.cpp

[Pierre Moreau]

Reviewed-by: Francisco Jerez 
Signed-off-by: Pierre Moreau 
---
 src/gallium/state_trackers/clover/api/device.cpp  | 11 +--
 src/gallium/state_trackers/clover/core/device.cpp | 14 ++
 src/gallium/state_trackers/clover/core/device.hpp |  1 +
 3 files changed, 16 insertions(+), 10 deletions(-)

diff --git a/src/gallium/state_trackers/clover/api/device.cpp 
b/src/gallium/state_trackers/clover/api/device.cpp
index 576555a9af..4e274c5005 100644
--- a/src/gallium/state_trackers/clover/api/device.cpp
+++ b/src/gallium/state_trackers/clover/api/device.cpp
@@ -330,16 +330,7 @@ clGetDeviceInfo(cl_device_id d_dev, cl_device_info param,
   break;
 
case CL_DEVICE_EXTENSIONS:
-  buf.as_string() =
- "cl_khr_byte_addressable_store"
- " cl_khr_global_int32_base_atomics"
- " cl_khr_global_int32_extended_atomics"
- " cl_khr_local_int32_base_atomics"
- " cl_khr_local_int32_extended_atomics"
- + std::string(dev.has_int64_atomics() ? " cl_khr_int64_base_atomics" 
: "")
- + std::string(dev.has_int64_atomics() ? " 
cl_khr_int64_extended_atomics" : "")
- + std::string(dev.has_doubles() ? " cl_khr_fp64" : "")
- + std::string(dev.has_halves() ? " cl_khr_fp16" : "");
+  buf.as_string() = dev.supported_extensions();
   break;
 
case CL_DEVICE_PLATFORM:
diff --git a/src/gallium/state_trackers/clover/core/device.cpp 
b/src/gallium/state_trackers/clover/core/device.cpp
index 9b15b30944..a6adfe0a77 100644
--- a/src/gallium/state_trackers/clover/core/device.cpp
+++ b/src/gallium/state_trackers/clover/core/device.cpp
@@ -277,3 +277,17 @@ device::supports_ir(enum pipe_shader_ir ir) const {
return pipe->get_shader_param(pipe, PIPE_SHADER_COMPUTE,
  PIPE_SHADER_CAP_SUPPORTED_IRS) & (1 << ir);
 }
+
+std::string
+device::supported_extensions() const {
+   return
+  "cl_khr_byte_addressable_store"
+  " cl_khr_global_int32_base_atomics"
+  " cl_khr_global_int32_extended_atomics"
+  " cl_khr_local_int32_base_atomics"
+  " cl_khr_local_int32_extended_atomics"
+  + std::string(has_int64_atomics() ? " cl_khr_int64_base_atomics" : "")
+  + std::string(has_int64_atomics() ? " cl_khr_int64_extended_atomics" : 
"")
+  + std::string(has_doubles() ? " cl_khr_fp64" : "")
+  + std::string(has_halves() ? " cl_khr_fp16" : "");
+}
diff --git a/src/gallium/state_trackers/clover/core/device.hpp 
b/src/gallium/state_trackers/clover/core/device.hpp
index ebe15f28e9..a7084e863f 100644
--- a/src/gallium/state_trackers/clover/core/device.hpp
+++ b/src/gallium/state_trackers/clover/core/device.hpp
@@ -83,6 +83,7 @@ namespace clover {
   std::string ir_target() const;
   enum pipe_endian endianness() const;
   bool supports_ir(enum pipe_shader_ir ir) const;
+  std::string supported_extensions() const;
 
   friend class command_queue;
   friend class root_resource;
-- 
2.16.2

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

[Mesa-dev] [PATCH v3 07/21] clover/api: Fail if trying to build a non-executable binary

[Pierre Moreau]

From the OpenCL 1.2 Specification, Section 5.6.2 (about clBuildProgram):

> If program is created with clCreateProgramWithBinary, then the
> program binary must be an executable binary (not a compiled binary or
> library).

Signed-off-by: Pierre Moreau 
---
 src/gallium/state_trackers/clover/api/program.cpp | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/src/gallium/state_trackers/clover/api/program.cpp 
b/src/gallium/state_trackers/clover/api/program.cpp
index babe45ccde..e3f1cdc2be 100644
--- a/src/gallium/state_trackers/clover/api/program.cpp
+++ b/src/gallium/state_trackers/clover/api/program.cpp
@@ -192,6 +192,13 @@ clBuildProgram(cl_program d_prog, cl_uint num_devs,
if (prog.has_source) {
   prog.compile(devs, opts);
   prog.link(devs, opts, { prog });
+   } else if (any_of([&](const device ){
+ return prog.build(dev).binary_type() != 
CL_PROGRAM_BINARY_TYPE_EXECUTABLE;
+ }, devs)) {
+  // According to the OpenCL 1.2 specification, “if program is created
+  // with clCreateProgramWithBinary, then the program binary must be an
+  // executable binary (not a compiled binary or library).”
+  throw error(CL_INVALID_BINARY);
}
 
return CL_SUCCESS;
-- 
2.16.2

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

[Mesa-dev] [PATCH v3 09/21] clover: Track flags per module section

[Pierre Moreau]

One flag that needs to be tracked is whether a library is allowed to
received mathematics optimisations or not, as the authorisation is given
when creating the library while the optimisations are specified when
creating the executable.

Signed-off-by: Pierre Moreau 
---
 src/gallium/state_trackers/clover/core/module.cpp  |  1 +
 src/gallium/state_trackers/clover/core/module.hpp  | 13 +
 src/gallium/state_trackers/clover/llvm/codegen/bitcode.cpp |  3 ++-
 src/gallium/state_trackers/clover/llvm/codegen/common.cpp  |  2 +-
 src/gallium/state_trackers/clover/tgsi/compiler.cpp|  3 ++-
 5 files changed, 15 insertions(+), 7 deletions(-)

diff --git a/src/gallium/state_trackers/clover/core/module.cpp 
b/src/gallium/state_trackers/clover/core/module.cpp
index a6c5b98d8e..0e11506d0d 100644
--- a/src/gallium/state_trackers/clover/core/module.cpp
+++ b/src/gallium/state_trackers/clover/core/module.cpp
@@ -163,6 +163,7 @@ namespace {
   proc(S , QT ) {
  _proc(s, x.id);
  _proc(s, x.type);
+ _proc(s, x.flags);
  _proc(s, x.size);
  _proc(s, x.data);
   }
diff --git a/src/gallium/state_trackers/clover/core/module.hpp 
b/src/gallium/state_trackers/clover/core/module.hpp
index 2ddd26426f..ff7e9b6234 100644
--- a/src/gallium/state_trackers/clover/core/module.hpp
+++ b/src/gallium/state_trackers/clover/core/module.hpp
@@ -41,14 +41,19 @@ namespace clover {
 data_local,
 data_private
  };
+ enum class flags_t {
+none,
+allow_link_options
+ };
 
- section(resource_id id, enum type type, size_t size,
- const std::vector ) :
- id(id), type(type), size(size), data(data) { }
- section() : id(0), type(text_intermediate), size(0), data() { }
+ section(resource_id id, enum type type, flags_t flags,
+ size_t size, const std::vector ) :
+ id(id), type(type), flags(flags), size(size), data(data) { }
+ section() : id(0), type(text_intermediate), flags(flags_t::none), 
size(0), data() { }
 
  resource_id id;
  type type;
+ flags_t flags;
  size_t size;
  std::vector data;
   };
diff --git a/src/gallium/state_trackers/clover/llvm/codegen/bitcode.cpp 
b/src/gallium/state_trackers/clover/llvm/codegen/bitcode.cpp
index 40bb426218..8e9d4c7e85 100644
--- a/src/gallium/state_trackers/clover/llvm/codegen/bitcode.cpp
+++ b/src/gallium/state_trackers/clover/llvm/codegen/bitcode.cpp
@@ -84,7 +84,8 @@ clover::llvm::build_module_library(const ::llvm::Module ,
enum module::section::type section_type) {
module m;
const auto code = emit_code(mod);
-   m.secs.emplace_back(0, section_type, code.size(), code);
+   m.secs.emplace_back(0, section_type, module::section::flags_t::none,
+   code.size(), code);
return m;
 }
 
diff --git a/src/gallium/state_trackers/clover/llvm/codegen/common.cpp 
b/src/gallium/state_trackers/clover/llvm/codegen/common.cpp
index ddf2083f37..3a08f11fcc 100644
--- a/src/gallium/state_trackers/clover/llvm/codegen/common.cpp
+++ b/src/gallium/state_trackers/clover/llvm/codegen/common.cpp
@@ -179,7 +179,7 @@ namespace {
make_text_section(const std::vector ) {
   const pipe_llvm_program_header header { uint32_t(code.size()) };
   module::section text { 0, module::section::text_executable,
- header.num_bytes, {} };
+ module::section::flags_t::none, header.num_bytes, 
{} };
 
   text.data.insert(text.data.end(), reinterpret_cast(),
reinterpret_cast() + 
sizeof(header));
diff --git a/src/gallium/state_trackers/clover/tgsi/compiler.cpp 
b/src/gallium/state_trackers/clover/tgsi/compiler.cpp
index e165311fa4..46b8ca7a07 100644
--- a/src/gallium/state_trackers/clover/tgsi/compiler.cpp
+++ b/src/gallium/state_trackers/clover/tgsi/compiler.cpp
@@ -91,7 +91,8 @@ namespace {
 
   unsigned sz = tgsi_num_tokens(prog) * sizeof(tgsi_token);
   std::vector data( (char *)prog, (char *)prog + sz );
-  m.secs.push_back({ 0, module::section::text_executable, sz, data });
+  m.secs.push_back({ 0, module::section::text_executable,
+ module::section::flags_t::none, sz, data });
}
 }
 
-- 
2.16.2

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

[Mesa-dev] [PATCH v3 03/21] clover/api: Fix tab indentation to spaces

[Pierre Moreau]

Acked-by: Francisco Jerez 
Reviewed-by: Karol Herbst 
Signed-off-by: Pierre Moreau 
---
 src/gallium/state_trackers/clover/api/device.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/state_trackers/clover/api/device.cpp 
b/src/gallium/state_trackers/clover/api/device.cpp
index 3572bb0c92..576555a9af 100644
--- a/src/gallium/state_trackers/clover/api/device.cpp
+++ b/src/gallium/state_trackers/clover/api/device.cpp
@@ -326,7 +326,7 @@ clGetDeviceInfo(cl_device_id d_dev, cl_device_info param,
 #ifdef MESA_GIT_SHA1
 " (" MESA_GIT_SHA1 ")"
 #endif
-   ;
+;
   break;
 
case CL_DEVICE_EXTENSIONS:
-- 
2.16.2

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

[Mesa-dev] [PATCH v3 02/21] clover: update ICD table to support everything up to 2.2

[Pierre Moreau]

From: Karol Herbst 

v2: add more prototypes

Signed-off-by: Karol Herbst 
Signed-off-by: Pierre Moreau 
---
 src/gallium/state_trackers/clover/api/dispatch.cpp |  29 +++-
 src/gallium/state_trackers/clover/api/dispatch.hpp | 190 +
 2 files changed, 218 insertions(+), 1 deletion(-)

diff --git a/src/gallium/state_trackers/clover/api/dispatch.cpp 
b/src/gallium/state_trackers/clover/api/dispatch.cpp
index 8f4cfdc7fb..8be4d3cb26 100644
--- a/src/gallium/state_trackers/clover/api/dispatch.cpp
+++ b/src/gallium/state_trackers/clover/api/dispatch.cpp
@@ -142,6 +142,33 @@ namespace clover {
   NULL, // clEnqueueReleaseD3D11ObjectsKHR
   NULL, // clGetDeviceIDsFromDX9MediaAdapterKHR
   NULL, // clEnqueueAcquireDX9MediaSurfacesKHR
-  NULL // clEnqueueReleaseDX9MediaSurfacesKHR
+  NULL, // clEnqueueReleaseDX9MediaSurfacesKHR
+  NULL, // clCreateFromEGLImageKHR
+  NULL, // clEnqueueAcquireEGLObjectsKHR
+  NULL, // clEnqueueReleaseEGLObjectsKHR
+  NULL, // clCreateEventFromEGLSyncKHR
+  NULL, // clCreateCommandQueueWithProperties
+  NULL, // clCreatePipe
+  NULL, // clGetPipeInfo
+  NULL, // clSVMAlloc
+  NULL, // clSVMFree
+  NULL, // clEnqueueSVMFree
+  NULL, // clEnqueueSVMMemcpy
+  NULL, // clEnqueueSVMMemFill
+  NULL, // clEnqueueSVMMap
+  NULL, // clEnqueueSVMUnmap
+  NULL, // clCreateSamplerWithProperties
+  NULL, // clSetKernelArgSVMPointer
+  NULL, // clSetKernelExecInfo
+  NULL, // clGetKernelSubGroupInfoKHR
+  NULL, // clCloneKernel
+  NULL, // clCreateProgramWithIL
+  NULL, // clEnqueueSVMMigrateMem
+  NULL, // clGetDeviceAndHostTimer
+  NULL, // clGetHostTimer
+  NULL, // clGetKernelSubGroupInfo
+  NULL, // clSetDefaultDeviceCommandQueue
+  NULL, // clSetProgramReleaseCallback
+  NULL, // clSetProgramSpecializationConstant
};
 }
diff --git a/src/gallium/state_trackers/clover/api/dispatch.hpp 
b/src/gallium/state_trackers/clover/api/dispatch.hpp
index 0ec1b51fa6..60fb75a146 100644
--- a/src/gallium/state_trackers/clover/api/dispatch.hpp
+++ b/src/gallium/state_trackers/clover/api/dispatch.hpp
@@ -27,6 +27,7 @@
 
 #include "CL/cl.h"
 #include "CL/cl_ext.h"
+#include "CL/cl_egl.h"
 #include "CL/cl_gl.h"
 
 ///
@@ -765,6 +766,195 @@ struct _cl_icd_dispatch {
void *clGetDeviceIDsFromDX9MediaAdapterKHR;
void *clEnqueueAcquireDX9MediaSurfacesKHR;
void *clEnqueueReleaseDX9MediaSurfacesKHR;
+
+   CL_API_ENTRY void (CL_API_CALL *clCreateFromEGLImageKHR)(
+  cl_context context,
+  CLeglDisplayKHR display,
+  CLeglImageKHR image,
+  cl_mem_flags flags,
+  const cl_egl_image_properties_khr *properties,
+  cl_int *errcode_ret);
+
+   CL_API_ENTRY void (CL_API_CALL *clEnqueueAcquireEGLObjectsKHR)(
+  cl_command_queue command_queue,
+  cl_uint num_objects,
+  const cl_mem *mem_objects,
+  cl_uint num_events_in_wait_list,
+  const cl_event *event_wait_list,
+  cl_event *event);
+
+   CL_API_ENTRY void (CL_API_CALL *clEnqueueReleaseEGLObjectsKHR)(
+  cl_command_queue command_queue,
+  cl_uint num_objects,
+  const cl_mem *mem_objects,
+  cl_uint num_events_in_wait_list,
+  const cl_event *event_wait_list,
+  cl_event *event);
+
+   CL_API_ENTRY void (CL_API_CALL *clCreateEventFromEGLSyncKHR)(
+  cl_context context,
+  CLeglSyncKHR sync,
+  CLeglDisplayKHR display,
+  cl_int *errcode_ret);
+
+   CL_API_ENTRY void (CL_API_CALL *clCreateCommandQueueWithProperties)(
+  cl_context context,
+  cl_device_id device,
+  const cl_queue_properties *properties,
+  cl_int *errcode_ret);
+
+   CL_API_ENTRY void (CL_API_CALL *clCreatePipe)(
+  cl_context context,
+  cl_mem_flags flags,
+  cl_uint pipe_packet_size,
+  cl_uint pipe_max_packets,
+  const cl_pipe_properties *properties,
+  cl_int *errcode_ret);
+
+   CL_API_ENTRY void (CL_API_CALL *clGetPipeInfo)(
+  cl_mem pipe,
+  cl_pipe_info param_name,
+  size_t param_value_size,
+  void *param_value,
+  size_t *param_value_size_ret);
+
+   CL_API_ENTRY void (CL_API_CALL *clSVMAlloc)(
+  cl_context context,
+  cl_svm_mem_flags flags,
+  size_t size,
+  unsigned int alignment);
+
+   CL_API_ENTRY void (CL_API_CALL *clSVMFree)(
+  cl_context context,
+  void *svm_pointer);
+
+   CL_API_ENTRY cl_int (CL_API_CALL *clEnqueueSVMFree)(
+  cl_command_queue command_queue,
+  cl_uint num_svm_pointers,
+  void **svm_pointers,
+  void (CL_CALLBACK *pfn_free_func)(cl_command_queue, cl_uint, void **, 
void *),
+  void *user_data,
+  cl_uint num_events_in_wait_list,
+  const cl_event *event_wait_list,
+  cl_event *event);
+
+   CL_API_ENTRY cl_int (CL_API_CALL *clEnqueueSVMMemcpy)(
+  cl_command_queue command_queue,
+  cl_bool blocking_copy,
+  void *dst_ptr,
+ 

[Mesa-dev] [PATCH v3 08/21] clover: Disallow creating libraries from other libraries

[Pierre Moreau]

If creating a library, do not allow non-compiled object in it, as
executables are not allowed, and libraries would make it really hard to
enforce the "-enable-link-options" flag.

Reviewed-by: Francisco Jerez 
Signed-off-by: Pierre Moreau 
---

Notes:
v3: Re-write the explanation as to why libraries can’t be created from other
libraries (Francisco Jerez)

 src/gallium/state_trackers/clover/api/program.cpp | 21 ++---
 1 file changed, 18 insertions(+), 3 deletions(-)

diff --git a/src/gallium/state_trackers/clover/api/program.cpp 
b/src/gallium/state_trackers/clover/api/program.cpp
index e3f1cdc2be..022ddbdbcc 100644
--- a/src/gallium/state_trackers/clover/api/program.cpp
+++ b/src/gallium/state_trackers/clover/api/program.cpp
@@ -255,8 +255,11 @@ clCompileProgram(cl_program d_prog, cl_uint num_devs,
 namespace {
ref_vector
validate_link_devices(const ref_vector ,
- const ref_vector _devs) {
+ const ref_vector _devs,
+ const std::string ) {
   std::vector devs;
+  const bool create_library =
+ opts.find("-create-library") != std::string::npos;
 
   for (auto  : all_devs) {
  const auto has_binary = [&](const program ) {
@@ -265,10 +268,22 @@ namespace {
t == CL_PROGRAM_BINARY_TYPE_LIBRARY;
  };
 
+ // According to the OpenCL 1.2 specification, a library is made of
+ // “compiled binaries specified in input_programs argument to
+ // clLinkProgram“; compiled binaries does not refer to libraries:
+ // “input_programs is an array of program objects that are compiled
+ // binaries or libraries that are to be linked to create the program
+ // executable”.
+ if (create_library && any_of([&](const program ) {
+  const auto t = prog.build(dev).binary_type();
+  return t != CL_PROGRAM_BINARY_TYPE_COMPILED_OBJECT;
+   }, progs))
+throw error(CL_INVALID_OPERATION);
+
  // According to the CL 1.2 spec, when "all programs specified [..]
  // contain a compiled binary or library for the device [..] a link is
  // performed",
- if (all_of(has_binary, progs))
+ else if (all_of(has_binary, progs))
 devs.push_back();
 
  // otherwise if "none of the programs contain a compiled binary or
@@ -298,7 +313,7 @@ clLinkProgram(cl_context d_ctx, cl_uint num_devs, const 
cl_device_id *d_devs,
auto valid_devs = ref_vector(ctx.devices());
auto devs = validate_build_common(prog, num_devs, d_devs, valid_devs,
  pfn_notify, user_data);
-   devs = validate_link_devices(progs, devs);
+   devs = validate_link_devices(progs, devs, opts);
 
try {
   prog().link(devs, opts, progs);
-- 
2.16.2

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

[Mesa-dev] [PATCH v3 00/21] Introducing SPIR-V support to clover

[Pierre Moreau]

Hello,

This updated series contains some additional fixes to clover, updates to the
OpenCL headers shipped with Mesa, the removal of the TGSI backend in clover (as
unused), the introduction of a new dependency, llvm-spirv, and some more
changes summarised further down.

llvm-spirv can be currently grabbed from
https://github.com/pierremoreau/llvm-spirv, on the branch integrate_with_mesa.
It seems this will be the current “master” repository, until it gets accepted
as an external tool in LLVM. As an out-of-tree LLVM consumer, it should be
relatively easy to package (especially compared to Khronos’ SPIRV_LLVM
repository).

The SPIR-V clover backend, that was previously part of this series, has been
dropped out for now, and will instead be submitted in a separate series along
with a consumer. So, what this series enable (besides fixing bugs), is to
accept SPIR-V binaries for drivers that accept LLVM (or NATIVE) as IR format,
so all drivers currently supported by clover.

The series is also accessible at https://github.com/pierremoreau/mesa, on the
branch clover_spirv_series_v3.

Thanks in advance for the reviews and comments,
Pierre


Changes since v2:
* Included an updated version of Karol Herbst’s patch
  “clover: update ICD table to support everything up to 2.2”: new commit, patch
  02;
* Renamed “clover: Add additional functions to query supported IRs” to
  “clover: Add an helper for checking if an IR is supported”;
* Added a new commit (patch 05) modifying existing code to use the helper
  introduced in the previous patch;
* Reworked the validation of devices when building programs: new commit, patch
  06;
* Added a new commit (patch 12) removing the TGSI backend in clover, as unused;
* Added llvm-spirv as a dependency;
* Added a new commit (patch 14) for translating SPIR-V to LLVM IR;

* Dropped commit adding PIPE_IR_SPIRV (previously, patch 08);
* Dropped commit refusing to build from source if the preferred IR was
  PIPE_IR_SPIRV (previously, patch 12);
* Dropped commit adding a pointer property (previously, patch 14);
* Dropped commit adding OpenCL 2.1 tokens related to SPIR-V, in favour of
  updating all OpenCL headers to 2.2 (previously, patch 20, new patch 01);

* Dropped commits related to adding a SPIR-V backend to clover (previously,
  patches 10, 11) as they will be submitted later on, along with an actual
  SPIR-V consumer.


Unchanged patches:
* 03: “clover/api: Fix tab indentation to spaces”
* 07: “clover/api: Fail if trying to build a non-executable binary”
* 09: “clover: Track flags per module section”
* 10: “clover: Move device extensions definitions to core/device.cpp”
* 11: “clover: Move platform extensions definitions to clover/platform.cpp”
* 15: “include/CL: Add cl_khr_il_program”
* 21: “clover: Use OpenCL 2.1 defines in place of cl_khr_il_program”


Karol Herbst (1):
  clover: update ICD table to support everything up to 2.2

Pierre Moreau (20):
  include/CL: Update to the latest OpenCL 2.2 headers
  clover/api: Fix tab indentation to spaces
  clover: Add an helper for checking if an IR is supported
  clover/device: Replace usage of "1 << PIPE_SHADER_IR_*" with
supports_ir
  clover/api: Rework the validation of devices for building
  clover/api: Fail if trying to build a non-executable binary
  clover: Disallow creating libraries from other libraries
  clover: Track flags per module section
  clover: Move device extensions definitions to core/device.cpp
  clover: Move platform extensions definitions to clover/platform.cpp
  clover: Remove the TGSI backend as unused
  configure.ac,meson: Check for SPIRV-Tools and llvm-spirv
  clover/llvm: Allow translating from SPIR-V to LLVM IR
  include/CL: Add cl_khr_il_program
  clover: Implement clCreateProgramWithILKHR
  clover: Handle CL_PROGRAM_IL_KHR in clGetProgramInfo
  clover/api: Implement CL_DEVICE_IL_VERSION_KHR
  clover: Advertise cl_khr_il_program
  clover: Implement clCreateProgramWithIL from OpenCL 2.1
  clover: Use OpenCL 2.1 defines in place of cl_khr_il_program

 configure.ac   |  10 +
 include/CL/cl.h| 472 -
 include/CL/cl_d3d10.h  |   7 +-
 include/CL/cl_d3d11.h  |   7 +-
 include/CL/cl_dx9_media_sharing.h  |   9 +-
 include/CL/cl_dx9_media_sharing_intel.h| 182 
 include/CL/cl_egl.h|   9 +-
 include/CL/cl_ext.h| 338 ++-
 include/CL/cl_ext_intel.h  | 429 +++
 include/CL/cl_gl.h |   7 +-
 include/CL/cl_gl_ext.h |   7 +-
 include/CL/cl_platform.h   | 328 ++
 include/CL/cl_va_api_media_sharing_intel.h | 172 
 include/CL/opencl.h|   7 +-
 meson.build

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

[AppVeyor]

Build mesa 6986 completed



Commit c7e22483fe by Daniel Stone on 2/20/2018 8:56 PM:

vulkan/wsi/x11: Consistently update and return swapchain status\n\nUse a helper function for updating the swapchain status. This will be\nused later to handle VK_SUBOPTIMAL_KHR, where we need to make a\nnon-error status stick to the swapchain until recreation.  Instead of\ndirect comparisons to VK_SUCCESS to check for error, test for negative\nnumbers meaning an error status, and positive numbers indicating\nnon-error statuses.\n\nv2 (Jason Ekstrand):\n - Use a pattern of "return x11_swapchain_result(chain, VK_WHATEVER)"\n - Handle wsi_queue_pull returning VK_TIMEOUT\n - Call x11_swapchain_result in x11_present_to_x11\n\nSigned-off-by: Daniel Stone \nReviewed-by: Jason Ekstrand 


Configure your notification preferences

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

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

[AppVeyor]

Build mesa 6985 failed


Commit cdeac00267 by Timothy Arceri on 2/21/2018 3:36 AM:

nir: remove old assert\n\nThis was originally intended to make sure the remap location\nwas not -1. However the code has changed alot since then,\nthe location is now never set to -1 and we also handle\ncomponents meaning this old assert has been doing comparisions\nwith the pointer to the array of component data.\n\nReviewed-by: Ian Romanick \nReviewed-by: Iago Toral Quiroga \nBugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105183


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 v11 00/15] Modifiers for X11 EGL/Vulkan, WL/VK

[Jason Ekstrand]

Assuming you're ok with the squash-in and modifications in my branch, the
whole lot is

Reviewed-by: Jason Ekstrand 

except, of course, for the ones written by me.  Let's make this happen!

--Jason

On Wed, Feb 21, 2018 at 6:05 AM, Daniel Stone  wrote:

> Hi,
> This series adds support for buffer modifiers through ANV and the common
> WSI infrastructure (AMD has no defined modifiers), as well as
> specifically for X11 and Wayland. It also adds support for the X11 DRI3
> v1.1 and Present v1.2 protocols to EGL and GLX, which does not require
> changes to the DRIimage infrastructure as it already supports modifiers.
>
> The core WSI modifiers support has been revised to be very very clear
> when modifiers are and are not available/used. It is the responsibility
> of the individual WSI to never attempt anything with modifiers at all if
> the underlying driver does not support it.
>
> The X11 DRI3 v1.1 support in the Vulkan WSI has been substantially
> reworked in order to be more clear, with various commits split out,
> swapchain status handling fixed to be vaguely consistent, and the
> suboptimal tracking rewritten. It now tracks the previous present status
> and only attempts reallocations on the first transition into a
> suboptimal mode, or when going from flip back to blit.
>
> The EGL/GLX DRI3 v1.1 support has been similarly reworked.
>
> Cheers,
> Daniel
>
> ___
> 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 v1 0/7] Implement commont gralloc_handle_t in libdrm

[Rob Herring]

On Wed, Feb 21, 2018 at 1:22 PM, Emil Velikov  wrote:
> On 21 February 2018 at 18:50, Rob Herring  wrote:
>> On Wed, Feb 21, 2018 at 10:01 AM, Emil Velikov  
>> wrote:
>>> Hi all,
>>>
>>> Pardon for dropping in late. I think you've got nearly everything
>>> settled down, just sharing a couple of ideas.
>>>
>>> On 21 February 2018 at 04:19, Tomasz Figa  wrote:
 On Wed, Feb 21, 2018 at 4:03 AM, Rob Herring  wrote:
> On Tue, Feb 20, 2018 at 4:26 AM, Tomasz Figa  wrote:
>>>
 It is actually incorrect to have the same device FD used for different
 screens, if PRIME is used, due to GEM namespace issues, e.g.
 - screen 0: drmPrimeFdToHandle(buffer A) -> 1,
 - screen 1: drmPrimeFdToHandle(buffer A) -> 1 (same handle in same
 namespace, due to semantics of PRIME import and same device FD used),
 - screen 0: GEM_CLOSE(handle = 1),
 - screen 1 still thinks handle 1 is valid...

 So this only works for control nodes using flink only. (Or if you
 always use libdrm_* for BO management and your particular
 implementation does its own GEM handle reference counting, but that's
 not guaranted.)

>>> Had a sneaky feeling that that != 1 will be returned for screen 1's
>>> drmPrimeFdToHandle call.
>>> Regardless, moving to DRI3/dmabuf-only setups is the [really] long
>>> term plan, I think.
>>> I don't know if we can achieve it outside of CrOS - with all the
>>> distros building and shipping things in subtly different manner.
>>
>> It's already possible for Android.
>>
> Great. Feel free to join me in pushing distributions forward ;-)

I'll trade you Android for any thing else. :)


> How would that work if you support different GPUs in one image?

 It wouldn't and that's why I prefer probing available devices.

 For Chrome OS, we don't include GPU bits in system image, but rather
 have vendor images built separately for each board (although sharing
 any possible contents across board family, chipset, GPU type and so
 on), so we can have a custom .rc script (which sets a property) as
 well. It would even be possible to have paths hardcoded, but that
 would be prone to probe ordering issues which, with software fallback,
 could be actually not obvious to notice, and so we'd rather not go
 this route.

 So I'd agree here that we should revisit probing.

>>> As you pointed out the fallback is not a good idea.
>>
>> Software fallback is a desired feature. Basing it on the path is the bad 
>> idea.
>>
> Even considering that a) the transition is not obvious and b) it will
> cause serve performance degradation?
> For development and prototyping purposes it's great. For production
> ... very few users will like the abysmal performance :-\

Better slow than not booting. There are also usecases such as running
in the cloud for running tests where performance is not too important.
AOSP has "devices" now that build images for GCE. CrOS does something
similar from what Tomasz has said.

Software rendering should be the easy case, but some reason is not.

>>> Plus, as the drm
>>> node vary, one can use an Android property and match it to the info.
>>> from drmGetDevice2.
>>> Say the HW bus location, (sub)device PCIID, other.
>>
>> That generally doesn't work for non-x86.
>>
> Errr... wrong. If PCI bus does not exist (some arm boards to have them
> though), one can use usb, platform or host1x specifics.
> If those are not enough, suggestions are welcome.

How does this work across platforms? Feels like just punting the
problem to someone else. Currently it's in gralloc, so let's move it
to init to set a property? Also, I'm not sure that setting a property
is going to work in the future with Treble.

But suppose we do make it a property. Does it really matter that the
property be a h/w device id and not be the device path? Whatever sets
the property can figure out the path based on bus info or whatever
logic it wants. And then for my simple uses, that logic can just be
hardcoded (as we have today).

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

Re: [Mesa-dev] [PATCH v11 14/15] egl/x11: Support DRI3 v1.1

[Jason Ekstrand]

On Wed, Feb 21, 2018 at 6:05 AM, Daniel Stone  wrote:

> From: Louis-Francis Ratté-Boulianne 
>
> Add support for DRI3 v1.1, which allows pixmaps to be backed by
> multi-planar buffers, or those with format modifiers. This is both
> for allocating render buffers, as well as EGLImage imports from a
> native pixmap (EGL_NATIVE_PIXMAP_KHR).
>
> Signed-off-by: Louis-Francis Ratté-Boulianne 
> Reviewed-by: Eric Engestrom 
> Reviewed-by: Emil Velikov 
> Reviewed-by: Daniel Stone 
> Signed-off-by: Daniel Stone 
> ---
>  src/egl/drivers/dri2/egl_dri2.c  |   7 +
>  src/egl/drivers/dri2/egl_dri2.h  |   3 +
>  src/egl/drivers/dri2/platform_x11_dri3.c | 105 --
>  src/glx/dri3_glx.c   |  10 +-
>  src/loader/loader_dri3_helper.c  | 319
> ++-
>  src/loader/loader_dri3_helper.h  |  17 +-
>  src/loader/meson.build   |   2 +-
>  7 files changed, 400 insertions(+), 63 deletions(-)
>
> diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_
> dri2.c
> index 17b646e7ede..9a7e43bafb6 100644
> --- a/src/egl/drivers/dri2/egl_dri2.c
> +++ b/src/egl/drivers/dri2/egl_dri2.c
> @@ -881,6 +881,13 @@ dri2_setup_extensions(_EGLDisplay *disp)
> if (!dri2_bind_extensions(dri2_dpy, mandatory_core_extensions,
> extensions, false))
>return EGL_FALSE;
>
> +#ifdef HAVE_DRI3
> +   dri2_dpy->multibuffers_available =
> +  (dri2_dpy->dri3_major_version > 1 || (dri2_dpy->dri3_major_version
> == 1 &&
> +dri2_dpy->dri3_minor_version
> >= 1)) &&
> +  (dri2_dpy->image && dri2_dpy->image->base.version >= 15);
> +#endif
> +
> dri2_bind_extensions(dri2_dpy, optional_core_extensions, extensions,
> true);
> return EGL_TRUE;
>  }
> diff --git a/src/egl/drivers/dri2/egl_dri2.h b/src/egl/drivers/dri2/egl_
> dri2.h
> index d36d02c3c49..00c4768d421 100644
> --- a/src/egl/drivers/dri2/egl_dri2.h
> +++ b/src/egl/drivers/dri2/egl_dri2.h
> @@ -199,6 +199,9 @@ struct dri2_egl_display
> xcb_screen_t *screen;
> bool swap_available;
>  #ifdef HAVE_DRI3
> +   bool multibuffers_available;
> +   int  dri3_major_version;
> +   int  dri3_minor_version;
> struct loader_dri3_extensions loader_dri3_ext;
>  #endif
>  #endif
> diff --git a/src/egl/drivers/dri2/platform_x11_dri3.c
> b/src/egl/drivers/dri2/platform_x11_dri3.c
> index 2073c592dc9..aee6b0cfdcc 100644
> --- a/src/egl/drivers/dri2/platform_x11_dri3.c
> +++ b/src/egl/drivers/dri2/platform_x11_dri3.c
> @@ -39,6 +39,23 @@
>  #include "loader.h"
>  #include "loader_dri3_helper.h"
>
> +static uint32_t
> +dri3_format_for_depth(uint32_t depth)
> +{
> +   switch (depth) {
> +   case 16:
> +  return __DRI_IMAGE_FORMAT_RGB565;
> +   case 24:
> +  return __DRI_IMAGE_FORMAT_XRGB;
> +   case 30:
> +  return __DRI_IMAGE_FORMAT_XRGB2101010;
> +   case 32:
> +  return __DRI_IMAGE_FORMAT_ARGB;
> +   default:
> +  return __DRI_IMAGE_FORMAT_NONE;
> +   }
> +}
> +
>  static struct dri3_egl_surface *
>  loader_drawable_to_egl_surface(struct loader_dri3_drawable *draw) {
> size_t offset = offsetof(struct dri3_egl_surface, loader_drawable);
> @@ -168,7 +185,9 @@ dri3_create_surface(_EGLDriver *drv, _EGLDisplay
> *disp, EGLint type,
>
> if (loader_dri3_drawable_init(dri2_dpy->conn, drawable,
>   dri2_dpy->dri_screen,
> - dri2_dpy->is_different_gpu, dri_config,
> + dri2_dpy->is_different_gpu,
> + dri2_dpy->multibuffers_available,
> + dri_config,
>   _dpy->loader_dri3_ext,
>   _dri3_vtable,
>   _surf->loader_drawable)) {
> @@ -274,20 +293,8 @@ dri3_create_image_khr_pixmap(_EGLDisplay *disp,
> _EGLContext *ctx,
>return NULL;
> }
>
> -   switch (bp_reply->depth) {
> -   case 16:
> -  format = __DRI_IMAGE_FORMAT_RGB565;
> -  break;
> -   case 24:
> -  format = __DRI_IMAGE_FORMAT_XRGB;
> -  break;
> -   case 30:
> -  format = __DRI_IMAGE_FORMAT_XRGB2101010;
> -  break;
> -   case 32:
> -  format = __DRI_IMAGE_FORMAT_ARGB;
> -  break;
> -   default:
> +   format = dri3_format_for_depth(bp_reply->depth);
> +   if (format == __DRI_IMAGE_FORMAT_NONE) {
>_eglError(EGL_BAD_PARAMETER,
>  "dri3_create_image_khr: unsupported pixmap depth");
>free(bp_reply);
> @@ -315,13 +322,78 @@ dri3_create_image_khr_pixmap(_EGLDisplay *disp,
> _EGLContext *ctx,
> return _img->base;
>  }
>
> +#if XCB_DRI3_MAJOR_VERSION > 1 || 

Re: [Mesa-dev] [PATCH 01/17] intel: Add a preliminary device for Ice Lake

[Anuj Phogat]

On Wed, Feb 21, 2018 at 11:04 AM, Matt Turner  wrote:
> On Wed, Feb 21, 2018 at 10:37 AM, Anuj Phogat  wrote:
>> On Wed, Feb 21, 2018 at 9:22 AM, Rafael Antognolli
>>  wrote:
>>> My understanding is that this commit is enough to make the driver try to
>>> initialize, at least for i965. If that's the case, how about we add
>>> something like what was removed by commit
>>> bf1577fe0972ae910c071743dc89d261a46c2926 for CNL?
>>>
>>> It could be either in this commit, or in a commit that precedes this
>>> one. Anv has an extra check for gen <= 10, so we don't need to worry
>>> there yet.
>> Yes, It'll be great to add a similar patch before this one. Also, I
>> think this patch should be the last patch in this series. Otherwise we'll
>> have a commit with ICL PCI IDs but missing compiler changes. Almost
>> nothing will work without the compiler patches.
>
> Good point. The reason I moved it here was because a few of my patches
> add new fields to GEN11_FEATURES. How about I split the patch in two:
> one that modifies gen_device_info.c and another for later that
> actually adds the PCI IDs?
Sounds good to me.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] anv: Don't assert that stencil HiZ clears are single-slice

[Nanley Chery]

On Wed, Feb 21, 2018 at 01:08:26PM -0800, Jason Ekstrand wrote:
> It's true for depth HiZ clears because we only have HiZ on single-slice
> images right now.  However, for stencil-only clears there is no such
> restriction.
> ---
>  src/intel/vulkan/genX_cmd_buffer.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 

This patch is
Reviewed-by: Nanley Chery 

> diff --git a/src/intel/vulkan/genX_cmd_buffer.c 
> b/src/intel/vulkan/genX_cmd_buffer.c
> index 8015a42..ce54624 100644
> --- a/src/intel/vulkan/genX_cmd_buffer.c
> +++ b/src/intel/vulkan/genX_cmd_buffer.c
> @@ -3438,9 +3438,12 @@ cmd_buffer_begin_subpass(struct anv_cmd_buffer 
> *cmd_buffer,
>   
> VK_IMAGE_ASPECT_STENCIL_BIT)) {
>   if (att_state->fast_clear) {
>  /* We currently only support HiZ for single-layer images */
> -assert(iview->planes[0].isl.base_level == 0);
> -assert(iview->planes[0].isl.base_array_layer == 0);
> -assert(fb->layers == 1);
> +if (att_state->pending_clear_aspects & 
> VK_IMAGE_ASPECT_DEPTH_BIT) {
> +   assert(iview->image->planes[0].aux_usage == 
> ISL_AUX_USAGE_HIZ);
> +   assert(iview->planes[0].isl.base_level == 0);
> +   assert(iview->planes[0].isl.base_array_layer == 0);
> +   assert(fb->layers == 1);
> +}
>  
>  anv_image_hiz_clear(cmd_buffer, image,
>  att_state->pending_clear_aspects,
> -- 
> 2.5.0.400.gff86faf
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v3 08/13] i965/miptree: Add space to store the clear value in the aux surface.

[Rafael Antognolli]

Similarly to vulkan where we store the clear value in the aux surface,
we can do the same in GL.

v2: Remove unneeded extra function.
v3: Use clear_value_state_size instead of clear_value_size.

Signed-off-by: Rafael Antognolli 
---
 src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c 
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
index 6d35c9d3928..7bdd4d89ccc 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
@@ -1676,6 +1676,16 @@ intel_alloc_aux_buffer(struct brw_context *brw,
   return false;
 
buf->size = aux_surf->size;
+
+   const struct gen_device_info *devinfo = >screen->devinfo;
+   if (devinfo->gen >= 10) {
+  /* On CNL, instead of setting the clear color in the SURFACE_STATE, we
+   * will set a pointer to a dword somewhere that contains the color. So,
+   * allocate the space for the clear color value here on the aux buffer.
+   */
+  buf->size += brw->isl_dev.ss.clear_value_state_size;
+   }
+
buf->pitch = aux_surf->row_pitch;
buf->qpitch = isl_surf_get_array_pitch_sa_rows(aux_surf);
 
-- 
2.14.3

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

[Mesa-dev] [PATCH v3 11/13] i965/surface_state: Silence warning.

[Rafael Antognolli]

This warning showed up after aux_bo started being used inside

if (use_clear_address) {...

But use_clear_address depends on aux_surf being not null, in which case
aux_bo would also be set. Make the compiler happy anyway.

Signed-off-by: Rafael Antognolli 
Reviewed-by: Nanley Chery 
---
 src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c 
b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
index b1f94f181b6..f69984e6f6d 100644
--- a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
+++ b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
@@ -150,7 +150,7 @@ brw_emit_surface_state(struct brw_context *brw,
 
union isl_color_value clear_color = { .u32 = { 0, 0, 0, 0 } };
 
-   struct brw_bo *aux_bo;
+   struct brw_bo *aux_bo = NULL;
struct isl_surf *aux_surf = NULL;
uint64_t aux_offset = 0;
switch (aux_usage) {
-- 
2.14.3

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

[Mesa-dev] [PATCH v3 09/13] i965/blorp: Update the fast clear color entry buffer.

[Rafael Antognolli]

On Gen10, whenever the fast clear color changes, update it on the clear
color entry buffer. This allow us to use it directly when emitting the
surface state.

Signed-off-by: Rafael Antognolli 
---
 src/mesa/drivers/dri/i965/brw_blorp.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/brw_blorp.c 
b/src/mesa/drivers/dri/i965/brw_blorp.c
index 1d586e5ef38..25bfd118e7e 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp.c
+++ b/src/mesa/drivers/dri/i965/brw_blorp.c
@@ -1142,6 +1142,27 @@ set_write_disables(const struct intel_renderbuffer *irb,
return disables;
 }
 
+static void
+update_fast_clear_color(struct brw_context *brw,
+struct blorp_surf *surf,
+const union isl_color_value clear_color)
+{
+   assert(surf);
+   /* Clear values are stored at the same bo as the aux surface, right
+* after the surface.
+*/
+   uint32_t clear_offset = surf->aux_addr.offset + surf->aux_surf->size;
+   for (int i = 0; i < brw->isl_dev.ss.clear_value_size / 4; i++) {
+  brw_store_data_imm32(brw, surf->aux_addr.buffer,
+   clear_offset + i * 4, clear_color.u32[i]);
+   }
+
+   surf->clear_color_addr = (struct blorp_address) {
+  .buffer = surf->aux_addr.buffer,
+  .offset = clear_offset,
+   };
+}
+
 static void
 do_single_blorp_clear(struct brw_context *brw, struct gl_framebuffer *fb,
   struct gl_renderbuffer *rb, unsigned buf,
@@ -1238,6 +1259,11 @@ do_single_blorp_clear(struct brw_context *brw, struct 
gl_framebuffer *fb,
   blorp_surf_for_miptree(brw, , irb->mt, irb->mt->aux_usage, true,
  , irb->mt_layer, num_layers, isl_tmp);
 
+  /* update clear color */
+  const struct gen_device_info *devinfo = >screen->devinfo;
+  if (devinfo->gen >= 10 && !same_clear_color)
+ update_fast_clear_color(brw, , clear_color);
+
   /* Ivybrigde PRM Vol 2, Part 1, "11.7 MCS Buffer for Render Target(s)":
*
*"Any transition from any value in {Clear, Render, Resolve} to a
-- 
2.14.3

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

[Mesa-dev] [PATCH v3 12/13] anv: Emit the fast clear color address, instead of value.

[Rafael Antognolli]

On Gen10+, instead of copying the clear color from the state buffer to
the surface state, just use the address of the state buffer in the
surface state directly. This way we can avoid the copy from state buffer
to surface state.

Signed-off-by: Rafael Antognolli 
---
 src/intel/vulkan/anv_image.c   | 19 ++
 src/intel/vulkan/anv_private.h |  5 
 src/intel/vulkan/genX_cmd_buffer.c | 52 +++---
 3 files changed, 72 insertions(+), 4 deletions(-)

diff --git a/src/intel/vulkan/anv_image.c b/src/intel/vulkan/anv_image.c
index 0dafe03442d..6b7ea32cbb3 100644
--- a/src/intel/vulkan/anv_image.c
+++ b/src/intel/vulkan/anv_image.c
@@ -1023,6 +1023,15 @@ anv_image_fill_surface_state(struct anv_device *device,
const uint64_t aux_address = aux_usage == ISL_AUX_USAGE_NONE ?
   0 : (image->planes[plane].bo_offset + aux_surface->offset);
 
+   bool use_clear_address = false;
+   struct anv_address clear_address = { .bo = NULL };
+   state_inout->clear_address = 0;
+   if (device->info.gen >= 10 && aux_usage != ISL_AUX_USAGE_NONE &&
+   aux_usage != ISL_AUX_USAGE_HIZ) {
+  clear_address = anv_image_get_clear_color_addr(device, image, aspect);
+  use_clear_address = true;
+   }
+
if (view_usage == ISL_SURF_USAGE_STORAGE_BIT &&
!(flags & ANV_IMAGE_VIEW_STATE_STORAGE_WRITE_ONLY) &&
!isl_has_matching_typed_storage_image_format(>info,
@@ -1040,6 +1049,7 @@ anv_image_fill_surface_state(struct anv_device *device,
 .mocs = device->default_mocs);
   state_inout->address = address,
   state_inout->aux_address = 0;
+  state_inout->clear_address = 0;
} else {
   if (view_usage == ISL_SURF_USAGE_STORAGE_BIT &&
   !(flags & ANV_IMAGE_VIEW_STATE_STORAGE_WRITE_ONLY)) {
@@ -1113,6 +1123,8 @@ anv_image_fill_surface_state(struct anv_device *device,
   .aux_surf = _surface->isl,
   .aux_usage = aux_usage,
   .aux_address = aux_address,
+  .clear_address = clear_address.offset,
+  .use_clear_address = use_clear_address,
   .mocs = device->default_mocs,
   .x_offset_sa = tile_x_sa,
   .y_offset_sa = tile_y_sa);
@@ -1134,6 +1146,13 @@ anv_image_fill_surface_state(struct anv_device *device,
   assert((aux_address & 0xfff) == 0);
   assert(aux_address == (*aux_addr_dw & 0xf000));
   state_inout->aux_address = *aux_addr_dw;
+
+  if (device->info.gen >= 10 && clear_address.bo) {
+ uint32_t *clear_addr_dw = state_inout->state.map +
+   device->isl_dev.ss.clear_value_offset;
+ assert((clear_address.offset & 0x3f) == 0);
+ state_inout->clear_address = *clear_addr_dw;
+  }
}
 
anv_state_flush(device, state_inout->state);
diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_private.h
index b8c381d2665..5c077987cef 100644
--- a/src/intel/vulkan/anv_private.h
+++ b/src/intel/vulkan/anv_private.h
@@ -1674,6 +1674,11 @@ struct anv_surface_state {
 * bits of this address include extra aux information.
 */
uint64_t aux_address;
+   /* Address of the clear color, if any
+*
+* This address is relative to the start of the BO.
+*/
+   uint64_t clear_address;
 };
 
 /**
diff --git a/src/intel/vulkan/genX_cmd_buffer.c 
b/src/intel/vulkan/genX_cmd_buffer.c
index 939a795c2b1..b9e1d50cbe3 100644
--- a/src/intel/vulkan/genX_cmd_buffer.c
+++ b/src/intel/vulkan/genX_cmd_buffer.c
@@ -200,6 +200,16 @@ add_image_view_relocs(struct anv_cmd_buffer *cmd_buffer,
   if (result != VK_SUCCESS)
  anv_batch_set_error(_buffer->batch, result);
}
+
+   if (state.clear_address) {
+  VkResult result =
+ anv_reloc_list_add(_buffer->surface_relocs,
+_buffer->pool->alloc,
+state.state.offset + 
isl_dev->ss.clear_value_offset,
+image->planes[image_plane].bo, 
state.clear_address);
+  if (result != VK_SUCCESS)
+ anv_batch_set_error(_buffer->batch, result);
+   }
 }
 
 static void
@@ -1056,6 +1066,35 @@ transition_color_buffer(struct anv_cmd_buffer 
*cmd_buffer,
   ANV_PIPE_RENDER_TARGET_CACHE_FLUSH_BIT | ANV_PIPE_CS_STALL_BIT;
 }
 
+static void
+update_fast_clear_color(struct anv_cmd_buffer *cmd_buffer,
+const struct anv_attachment_state *att_state,
+const struct anv_image *image)
+{
+   assert(GEN_GEN >= 10);
+   assert(image->aspects == VK_IMAGE_ASPECT_COLOR_BIT);
+
+   struct anv_address clear_address =
+  anv_image_get_clear_color_addr(cmd_buffer->device, image,
+ VK_IMAGE_ASPECT_COLOR_BIT);
+   union isl_color_value fast_clear_value;
+   memcpy(fast_clear_value.u32, 

[Mesa-dev] [PATCH v3 13/13] anv: Use clear address for HiZ fast clears too.

[Rafael Antognolli]

Store the default clear address for HiZ fast clears on a global bo, and
point to it when needed.

Signed-off-by: Rafael Antognolli 
---
 src/intel/vulkan/anv_device.c  | 19 +++
 src/intel/vulkan/anv_image.c   | 10 +++---
 src/intel/vulkan/anv_private.h |  1 +
 3 files changed, 27 insertions(+), 3 deletions(-)

diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index 00b0b65..68003d0168f 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -1316,6 +1316,20 @@ anv_device_init_dispatch(struct anv_device *device)
}
 }
 
+static void
+anv_device_init_hiz_clear_batch(struct anv_device *device)
+{
+   anv_bo_init_new(>hiz_clear_bo, device, 4096);
+   uint32_t *map = anv_gem_mmap(device, device->hiz_clear_bo.gem_handle,
+0, 4096, 0);
+
+   union isl_color_value hiz_clear = { .u32 = { 0, } };
+   hiz_clear.f32[0] = ANV_HZ_FC_VAL;
+
+   memcpy(map, hiz_clear.u32, sizeof(hiz_clear.u32));
+   anv_gem_munmap(map, device->hiz_clear_bo.size);
+}
+
 VkResult anv_CreateDevice(
 VkPhysicalDevicephysicalDevice,
 const VkDeviceCreateInfo*   pCreateInfo,
@@ -1462,6 +1476,9 @@ VkResult anv_CreateDevice(
 
anv_device_init_trivial_batch(device);
 
+   if (device->info.gen >= 10)
+  anv_device_init_hiz_clear_batch(device);
+
anv_scratch_pool_init(device, >scratch_pool);
 
anv_queue_init(device, >queue);
@@ -1555,6 +1572,8 @@ void anv_DestroyDevice(
anv_gem_close(device, device->workaround_bo.gem_handle);
 
anv_gem_close(device, device->trivial_batch_bo.gem_handle);
+   if (device->info.gen >= 10)
+  anv_gem_close(device, device->hiz_clear_bo.gem_handle);
 
anv_state_pool_finish(>surface_state_pool);
anv_state_pool_finish(>instruction_state_pool);
diff --git a/src/intel/vulkan/anv_image.c b/src/intel/vulkan/anv_image.c
index 6b7ea32cbb3..95950f60315 100644
--- a/src/intel/vulkan/anv_image.c
+++ b/src/intel/vulkan/anv_image.c
@@ -1026,10 +1026,14 @@ anv_image_fill_surface_state(struct anv_device *device,
bool use_clear_address = false;
struct anv_address clear_address = { .bo = NULL };
state_inout->clear_address = 0;
-   if (device->info.gen >= 10 && aux_usage != ISL_AUX_USAGE_NONE &&
-   aux_usage != ISL_AUX_USAGE_HIZ) {
-  clear_address = anv_image_get_clear_color_addr(device, image, aspect);
+
+   if (device->info.gen >= 10 && aux_usage != ISL_AUX_USAGE_NONE) {
   use_clear_address = true;
+  if (aux_usage == ISL_AUX_USAGE_HIZ) {
+ clear_address = (struct anv_address) { .bo = >hiz_clear_bo };
+  } else {
+ clear_address = anv_image_get_clear_color_addr(device, image, aspect);
+  }
}
 
if (view_usage == ISL_SURF_USAGE_STORAGE_BIT &&
diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_private.h
index 5c077987cef..2fe0c2c5960 100644
--- a/src/intel/vulkan/anv_private.h
+++ b/src/intel/vulkan/anv_private.h
@@ -871,6 +871,7 @@ struct anv_device {
 
 struct anv_bo   workaround_bo;
 struct anv_bo   trivial_batch_bo;
+struct anv_bo   hiz_clear_bo;
 
 struct anv_pipeline_cache   blorp_shader_cache;
 struct blorp_contextblorp;
-- 
2.14.3

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

[Mesa-dev] [PATCH v3 10/13] i965/surface_state: Emit the clear color address instead of value.

[Rafael Antognolli]

On Gen10, when emitting the surface state, use the value stored in the
clear color entry buffer by using a clear color address in the surface
state.

Signed-off-by: Rafael Antognolli 
---
 src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c 
b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
index a5424ae3201..b1f94f181b6 100644
--- a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
+++ b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
@@ -184,6 +184,10 @@ brw_emit_surface_state(struct brw_context *brw,
  brw->isl_dev.ss.align,
  surf_offset);
 
+   bool use_clear_address = devinfo->gen >= 10 && aux_surf;
+   uint32_t clear_offset =
+  use_clear_address ? aux_offset + aux_surf->size : 0;
+
isl_surf_fill_state(>isl_dev, state, .surf = >surf, .view = ,
.address = brw_state_reloc(>batch,
   *surf_offset + 
brw->isl_dev.ss.addr_offset,
@@ -192,6 +196,8 @@ brw_emit_surface_state(struct brw_context *brw,
.aux_address = aux_offset,
.mocs = brw_get_bo_mocs(devinfo, mt->bo),
.clear_color = clear_color,
+   .use_clear_address = use_clear_address,
+   .clear_address = clear_offset,
.x_offset_sa = tile_x, .y_offset_sa = tile_y);
if (aux_surf) {
   /* On gen7 and prior, the upper 20 bits of surface state DWORD 6 are the
@@ -210,6 +216,16 @@ brw_emit_surface_state(struct brw_context *brw,
   aux_bo, *aux_addr,
   reloc_flags);
}
+
+   if (use_clear_address) {
+  /* Make sure the offset is aligned with a cacheline. */
+  assert((clear_offset & 0x3f) == 0);
+  uint32_t *clear_address = state + brw->isl_dev.ss.clear_value_offset;
+  *clear_address = brw_state_reloc(>batch,
+   *surf_offset +
+   brw->isl_dev.ss.clear_value_offset,
+   aux_bo, *clear_address, reloc_flags);
+   }
 }
 
 static uint32_t
-- 
2.14.3

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

[Mesa-dev] [PATCH v3 07/13] intel/blorp: Add suport for fast clear address.

[Rafael Antognolli]

On gen10+, if surface->clear_color_addr is present, use it directly
intead of copying it to the surface state.

Signed-off-by: Rafael Antognolli 
---
 src/intel/blorp/blorp_genX_exec.h | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/src/intel/blorp/blorp_genX_exec.h 
b/src/intel/blorp/blorp_genX_exec.h
index 737720a70c9..122dccd7ca1 100644
--- a/src/intel/blorp/blorp_genX_exec.h
+++ b/src/intel/blorp/blorp_genX_exec.h
@@ -1281,11 +1281,15 @@ blorp_emit_surface_state(struct blorp_batch *batch,
  write_disable_mask |= ISL_CHANNEL_ALPHA_BIT;
}
 
+   const bool use_clear_address =
+  GEN_GEN >= 10 && (surface->clear_color_addr.buffer != NULL);
+
isl_surf_fill_state(batch->blorp->isl_dev, state,
.surf = , .view = >view,
.aux_surf = >aux_surf, .aux_usage = aux_usage,
.mocs = surface->addr.mocs,
.clear_color = surface->clear_color,
+   .use_clear_address = use_clear_address,
.write_disables = write_disable_mask);
 
blorp_surface_reloc(batch, state_offset + isl_dev->ss.addr_offset,
@@ -1305,9 +1309,11 @@ blorp_emit_surface_state(struct blorp_batch *batch,
blorp_flush_range(batch, state, GENX(RENDER_SURFACE_STATE_length) * 4);
 
if (surface->clear_color_addr.buffer) {
-#if GEN_GEN > 10
-  unreachable("Implement indirect clear support on gen11+");
-#elif GEN_GEN >= 7 && GEN_GEN <= 10
+#if GEN_GEN >= 10
+  assert((surface->clear_color_addr.offset & 0x3f) == 0);
+  blorp_surface_reloc(batch, state_offset + isl_dev->ss.clear_value_offset,
+  surface->clear_color_addr, 0);
+#elif GEN_GEN >= 7 && GEN_GEN < 10
   struct blorp_address dst_addr = blorp_get_surface_base_address(batch);
   dst_addr.offset += state_offset + isl_dev->ss.clear_value_offset;
   blorp_emit_memcpy(batch, dst_addr, surface->clear_color_addr,
-- 
2.14.3

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

[Mesa-dev] [PATCH v3 04/13] intel/isl: Update size of clear color value.

[Rafael Antognolli]

On gen10 and newer, there's a struct describing how to use the indirect
clear color buffer, and it seems to be 8 dwords long - 4 for the clear
color and the last 4 used by the hardware, apparently depending on the
generation. So just set aside space for them since gen10.

Optionally we can later add the struct to the genxml, though it wouldn't
really be used for anything else other than calculating this size.

[jordan.l.jus...@intel.com: isl_device_init changes]
Signed-off-by: Rafael Antognolli 
Signed-off-by: Jordan Justen 
---
 src/intel/isl/isl.c | 27 ++-
 1 file changed, 18 insertions(+), 9 deletions(-)

diff --git a/src/intel/isl/isl.c b/src/intel/isl/isl.c
index 1a32c028183..77641a89f86 100644
--- a/src/intel/isl/isl.c
+++ b/src/intel/isl/isl.c
@@ -73,15 +73,24 @@ isl_device_init(struct isl_device *dev,
dev->ss.size = RENDER_SURFACE_STATE_length(info) * 4;
dev->ss.align = isl_align(dev->ss.size, 32);
 
-   dev->ss.clear_value_size =
-  isl_align(RENDER_SURFACE_STATE_RedClearColor_bits(info) +
-RENDER_SURFACE_STATE_GreenClearColor_bits(info) +
-RENDER_SURFACE_STATE_BlueClearColor_bits(info) +
-RENDER_SURFACE_STATE_AlphaClearColor_bits(info), 32) / 8;
-
-   dev->ss.clear_value_offset =
-  RENDER_SURFACE_STATE_RedClearColor_start(info) / 32 * 4;
-
+   if (ISL_DEV_GEN(dev) >= 10) {
+  /* Clear Color structure
+   * - 4 dwords for the clear color
+   * - 2 dwords that can be used by the hardware for converted clear color
+   *   + some extra bits.
+   */
+  dev->ss.clear_value_size = 8 * 4;
+  dev->ss.clear_value_offset =
+ RENDER_SURFACE_STATE_ClearValueAddress_start(info) / 32 * 4;
+   } else {
+  dev->ss.clear_value_size =
+ isl_align(RENDER_SURFACE_STATE_RedClearColor_bits(info) +
+   RENDER_SURFACE_STATE_GreenClearColor_bits(info) +
+   RENDER_SURFACE_STATE_BlueClearColor_bits(info) +
+   RENDER_SURFACE_STATE_AlphaClearColor_bits(info), 32) / 8;
+  dev->ss.clear_value_offset =
+ RENDER_SURFACE_STATE_RedClearColor_start(info) / 32 * 4;
+   }
assert(RENDER_SURFACE_STATE_SurfaceBaseAddress_start(info) % 8 == 0);
dev->ss.addr_offset =
   RENDER_SURFACE_STATE_SurfaceBaseAddress_start(info) / 8;
-- 
2.14.3

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

[Mesa-dev] [PATCH v3 00/13] Use clear color address in surface state.

[Rafael Antognolli]

Rebase of this series after lots of aux surface changes on anv.

Cc: Jason Ekstrand 
Cc: Jordan Justen 
Cc: Topi Pohjolainen 

Rafael Antognolli (13):
  anv/image: Do not override lower bits of dword.
  genxml: Preserve fields that share dword space with addresses.
  intel/genxml: Use a single field for clear color address on gen10.
  intel/isl: Update size of clear color value.
  intel/genxml: Add Clear Color struct.
  intel/isl: Add support to emit clear value address.
  intel/blorp: Add suport for fast clear address.
  i965/miptree: Add space to store the clear value in the aux surface.
  i965/blorp: Update the fast clear color entry buffer.
  i965/surface_state: Emit the clear color address instead of value.
  i965/surface_state: Silence warning.
  anv: Emit the fast clear color address, instead of value.
  anv: Use clear address for HiZ fast clears too.

 src/intel/blorp/blorp_genX_exec.h| 12 --
 src/intel/genxml/gen10.xml   | 15 +--
 src/intel/genxml/gen11.xml   |  7 ++--
 src/intel/genxml/gen_pack_header.py  |  9 +++-
 src/intel/isl/isl.c  | 29 +
 src/intel/isl/isl.h  | 14 +++
 src/intel/isl/isl_surface_state.c| 18 ++--
 src/intel/vulkan/anv_device.c| 19 +
 src/intel/vulkan/anv_image.c | 53 ++--
 src/intel/vulkan/anv_private.h   |  8 +++-
 src/intel/vulkan/genX_cmd_buffer.c   | 52 +--
 src/mesa/drivers/dri/i965/brw_blorp.c| 26 
 src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 18 +++-
 src/mesa/drivers/dri/i965/intel_mipmap_tree.c| 10 +
 14 files changed, 245 insertions(+), 45 deletions(-)

-- 
2.14.3

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

[Mesa-dev] [PATCH v3 02/13] genxml: Preserve fields that share dword space with addresses.

[Rafael Antognolli]

Some instructions contain fields that are either an address or a value
of some type based on the content of other fields, such as clear color
values vs address. That works fine if these fields are in the less
significant dword, the lower 32 bits of the address, because they get
OR'ed with the address. But if they are in the higher 32 bits, they get
discarded.

On Gen10 we have fields that share space with the higher 16 bits of the
address too. This commit makes sure those fields don't get discarded.

Signed-off-by: Rafael Antognolli 
---
 src/intel/genxml/gen_pack_header.py | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/src/intel/genxml/gen_pack_header.py 
b/src/intel/genxml/gen_pack_header.py
index e6cea8646ff..e81695e2aea 100644
--- a/src/intel/genxml/gen_pack_header.py
+++ b/src/intel/genxml/gen_pack_header.py
@@ -486,11 +486,16 @@ class Group(object):
 v_address = "v%d_address" % index
 print("   const uint64_t %s =\n  
__gen_combine_address(data, [%d], values->%s, %s);" %
   (v_address, index, dw.address.name + field.dim, v))
-v = v_address
-
+if len(dw.fields) > address_count:
+print("   dw[%d] = %s;" % (index, v_address))
+print("   dw[%d] = (%s >> 32) | (%s >> 32);" % (index + 1, 
v_address, v))
+continue
+else:
+v = v_address
 print("   dw[%d] = %s;" % (index, v))
 print("   dw[%d] = %s >> 32;" % (index + 1, v))
 
+
 class Value(object):
 def __init__(self, attrs):
 self.name = safe_name(attrs["name"])
-- 
2.14.3

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

[Mesa-dev] [PATCH v3 03/13] intel/genxml: Use a single field for clear color address on gen10.

[Rafael Antognolli]

genxml does not support having two address fields with different names
but same position in the state struct. Both "Clear Color Address"
and "Clear Depth Address Low" mean the same thing, only for different
surface types.

To workaround this genxml limitation, rename "Clear Color Address"
to "Clear Value Address" and use it for both color and depth. Do the
same for the high bits.

TODO: add support for multiple addresses at the same position in the
xml.

v2: Combine high and low order bits into a single address field.

Signed-off-by: Rafael Antognolli 
---
 src/intel/genxml/gen10.xml | 7 +++
 src/intel/genxml/gen11.xml | 7 +++
 2 files changed, 6 insertions(+), 8 deletions(-)

diff --git a/src/intel/genxml/gen10.xml b/src/intel/genxml/gen10.xml
index 47c679a3fa9..b434d1b0f66 100644
--- a/src/intel/genxml/gen10.xml
+++ b/src/intel/genxml/gen10.xml
@@ -800,12 +800,11 @@
 
 
 
+
+
 
-
-
 
-
-
 
 
   
diff --git a/src/intel/genxml/gen11.xml b/src/intel/genxml/gen11.xml
index 9a8a2fe21e3..d8019e7390d 100644
--- a/src/intel/genxml/gen11.xml
+++ b/src/intel/genxml/gen11.xml
@@ -801,13 +801,12 @@
 
 
 
+
+
 
-
-
 
 
-
-
 
 
   
-- 
2.14.3

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

[Mesa-dev] [PATCH v3 05/13] intel/genxml: Add Clear Color struct.

[Rafael Antognolli]

The size of the clear color struct (expected by the hardware) is 8
dwords (isl_dev.ss.clear_value_state_size here). But we still need to
track the size of the clear color, used when memcopying it to/from the
state buffer. For that we keep isl_dev.ss.clear_value_size.

Signed-off-by: Rafael Antognolli 
---
 src/intel/genxml/gen10.xml | 8 
 src/intel/isl/isl.c| 4 +++-
 src/intel/isl/isl.h| 5 +
 src/intel/vulkan/anv_image.c   | 2 +-
 src/intel/vulkan/anv_private.h | 2 +-
 5 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/src/intel/genxml/gen10.xml b/src/intel/genxml/gen10.xml
index b434d1b0f66..58b83954c4c 100644
--- a/src/intel/genxml/gen10.xml
+++ b/src/intel/genxml/gen10.xml
@@ -809,6 +809,14 @@
 
   
 
+  
+
+
+
+
+
+  
+
   
 
 
diff --git a/src/intel/isl/isl.c b/src/intel/isl/isl.c
index 77641a89f86..e94470362e2 100644
--- a/src/intel/isl/isl.c
+++ b/src/intel/isl/isl.c
@@ -79,9 +79,10 @@ isl_device_init(struct isl_device *dev,
* - 2 dwords that can be used by the hardware for converted clear color
*   + some extra bits.
*/
-  dev->ss.clear_value_size = 8 * 4;
+  dev->ss.clear_value_size = 4 * 4;
   dev->ss.clear_value_offset =
  RENDER_SURFACE_STATE_ClearValueAddress_start(info) / 32 * 4;
+  dev->ss.clear_value_state_size = CLEAR_COLOR_length(info) * 4;
} else {
   dev->ss.clear_value_size =
  isl_align(RENDER_SURFACE_STATE_RedClearColor_bits(info) +
@@ -90,6 +91,7 @@ isl_device_init(struct isl_device *dev,
RENDER_SURFACE_STATE_AlphaClearColor_bits(info), 32) / 8;
   dev->ss.clear_value_offset =
  RENDER_SURFACE_STATE_RedClearColor_start(info) / 32 * 4;
+  dev->ss.clear_value_state_size = dev->ss.clear_value_size;
}
assert(RENDER_SURFACE_STATE_SurfaceBaseAddress_start(info) % 8 == 0);
dev->ss.addr_offset =
diff --git a/src/intel/isl/isl.h b/src/intel/isl/isl.h
index 209769a9a99..f1b38efed44 100644
--- a/src/intel/isl/isl.h
+++ b/src/intel/isl/isl.h
@@ -963,6 +963,11 @@ struct isl_device {
   uint8_t aux_addr_offset;
 
   /* Rounded up to the nearest dword to simplify GPU memcpy operations. */
+
+  /* size of the state buffer used to store the clear value + extra
+   * additional space used by the hardware */
+  uint8_t clear_value_state_size;
+  /* size of the clear color itself - used to copy it to/from a BO */
   uint8_t clear_value_size;
   uint8_t clear_value_offset;
} ss;
diff --git a/src/intel/vulkan/anv_image.c b/src/intel/vulkan/anv_image.c
index a0aee43bd21..0dafe03442d 100644
--- a/src/intel/vulkan/anv_image.c
+++ b/src/intel/vulkan/anv_image.c
@@ -264,7 +264,7 @@ add_aux_state_tracking_buffer(struct anv_image *image,
}
 
/* Clear color and fast clear type */
-   unsigned state_size = device->isl_dev.ss.clear_value_size + 4;
+   unsigned state_size = device->isl_dev.ss.clear_value_state_size + 4;
 
/* We only need to track compression on CCS_E surfaces. */
if (image->planes[plane].aux_usage == ISL_AUX_USAGE_CCS_E) {
diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_private.h
index 37e63f56aa0..b8c381d2665 100644
--- a/src/intel/vulkan/anv_private.h
+++ b/src/intel/vulkan/anv_private.h
@@ -2566,7 +2566,7 @@ anv_image_get_fast_clear_type_addr(const struct 
anv_device *device,
 {
struct anv_address addr =
   anv_image_get_clear_color_addr(device, image, aspect);
-   addr.offset += device->isl_dev.ss.clear_value_size;
+   addr.offset += device->isl_dev.ss.clear_value_state_size;
return addr;
 }
 
-- 
2.14.3

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

[Mesa-dev] [PATCH v3 01/13] anv/image: Do not override lower bits of dword.

[Rafael Antognolli]

The lower bits seem to have extra fields in every platform but gen8
(even though we don't use them in gen9). So just go ahead and avoid
using them for the address.

Signed-off-by: Rafael Antognolli 
Reviewed-by: Topi Pohjolainen 
---
 src/intel/vulkan/anv_image.c | 30 +-
 1 file changed, 17 insertions(+), 13 deletions(-)

diff --git a/src/intel/vulkan/anv_image.c b/src/intel/vulkan/anv_image.c
index a297cc47320..a0aee43bd21 100644
--- a/src/intel/vulkan/anv_image.c
+++ b/src/intel/vulkan/anv_image.c
@@ -1117,19 +1117,23 @@ anv_image_fill_surface_state(struct anv_device *device,
   .x_offset_sa = tile_x_sa,
   .y_offset_sa = tile_y_sa);
   state_inout->address = address + offset_B;
-  if (device->info.gen >= 8) {
- state_inout->aux_address = aux_address;
-  } else {
- /* On gen7 and prior, the bottom 12 bits of the MCS base address are
-  * used to store other information.  This should be ok, however,
-  * because surface buffer addresses are always 4K page alinged.
-  */
- uint32_t *aux_addr_dw = state_inout->state.map +
- device->isl_dev.ss.aux_addr_offset;
- assert((aux_address & 0xfff) == 0);
- assert(aux_address == (*aux_addr_dw & 0xf000));
- state_inout->aux_address = *aux_addr_dw;
-  }
+
+  /* On gen7 and prior, the bottom 12 bits of the MCS base address are
+   * used to store other information.  This should be ok, however,
+   * because surface buffer addresses are always 4K page alinged.
+   *
+   * On gen9, the bottom 10 bits can be used, but we don't use them. On
+   * gen10 the bit 10 needs to be used.
+   *
+   * Since the trend seems to be that we might end up using them anyway
+   * (gen8 being the only exception), just always make sure they don't get
+   * overriden by the address.
+   */
+  uint32_t *aux_addr_dw = state_inout->state.map +
+ device->isl_dev.ss.aux_addr_offset;
+  assert((aux_address & 0xfff) == 0);
+  assert(aux_address == (*aux_addr_dw & 0xf000));
+  state_inout->aux_address = *aux_addr_dw;
}
 
anv_state_flush(device, state_inout->state);
-- 
2.14.3

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

[Mesa-dev] [PATCH v3 06/13] intel/isl: Add support to emit clear value address.

[Rafael Antognolli]

gen10 can emit the clear color by setting it on a buffer somewhere, and
then adding only the address to the surface state.

This commit add support for that on isl_surf_fill_state, and if that is
requested, skip setting the clear value itself.

v2: Add assert to make sure we are at least on gen10.

Signed-off-by: Rafael Antognolli 
---
 src/intel/isl/isl.h   |  9 +
 src/intel/isl/isl_surface_state.c | 18 ++
 2 files changed, 23 insertions(+), 4 deletions(-)

diff --git a/src/intel/isl/isl.h b/src/intel/isl/isl.h
index f1b38efed44..bab0ad3d544 100644
--- a/src/intel/isl/isl.h
+++ b/src/intel/isl/isl.h
@@ -1306,6 +1306,15 @@ struct isl_surf_fill_state_info {
 */
union isl_color_value clear_color;
 
+   /**
+* Send only the clear value address
+*
+* If set, we only pass the clear address to the GPU and it will fetch it
+* from wherever it is.
+*/
+   bool use_clear_address;
+   uint64_t clear_address;
+
/**
 * Surface write disables for gen4-5
 */
diff --git a/src/intel/isl/isl_surface_state.c 
b/src/intel/isl/isl_surface_state.c
index bfb27fa4a44..e7c489df912 100644
--- a/src/intel/isl/isl_surface_state.c
+++ b/src/intel/isl/isl_surface_state.c
@@ -635,11 +635,21 @@ isl_genX(surf_fill_state_s)(const struct isl_device *dev, 
void *state,
 #endif
 
if (info->aux_usage != ISL_AUX_USAGE_NONE) {
+  if (info->use_clear_address) {
+#if GEN_GEN >= 10
+ s.ClearValueAddressEnable = true;
+ s.ClearValueAddress = info->clear_address;
+#else
+ unreachable("Gen9 and earlier do not support indirect clear colors");
+#endif
+  }
 #if GEN_GEN >= 9
-  s.RedClearColor = info->clear_color.u32[0];
-  s.GreenClearColor = info->clear_color.u32[1];
-  s.BlueClearColor = info->clear_color.u32[2];
-  s.AlphaClearColor = info->clear_color.u32[3];
+  if (!info->use_clear_address) {
+ s.RedClearColor = info->clear_color.u32[0];
+ s.GreenClearColor = info->clear_color.u32[1];
+ s.BlueClearColor = info->clear_color.u32[2];
+ s.AlphaClearColor = info->clear_color.u32[3];
+  }
 #elif GEN_GEN >= 7
   /* Prior to Sky Lake, we only have one bit for the clear color which
* gives us 0 or 1 in whatever the surface's format happens to be.
-- 
2.14.3

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

Re: [Mesa-dev] [PATCH] radeonsi/nir: disable GLSL IR loop unrolling

[Timothy Arceri]

On 22/02/18 06:09, Ilia Mirkin wrote:

On Tue, Feb 20, 2018 at 8:35 PM, Timothy Arceri  wrote:

Delaying unrolling and allowing NIR to do it instead has been shown
to result in better code in drivers such as i965. shader-db results
appear to should the same is true for radeonsi.

The other advantage is that using NIR unrolling improves compile
times significantly.

Totals from affected shaders:
SGPRS: 9624 -> 10016 (4.07 %)
VGPRS: 6800 -> 6464 (-4.94 %)
Spilled SGPRs: 0 -> 2 (0.00 %)
Spilled VGPRs: 0 -> 0 (0.00 %)
Private memory VGPRs: 0 -> 0 (0.00 %)
Scratch size: 0 -> 0 (0.00 %) dwords per thread
Code Size: 359176 -> 332264 (-7.49 %) bytes


This basically means that fewer loops were unrolled.


No that is just one of the possibilities, as the commit message says 
unrolling with NIR has been shown in the past to result in better code.


The large drop seems to be largely a result of better loop unrolling in 
the dolphin uber shaders. For example 
shaders/dolphin/ubershaders/228.shader_test when using GLSL IR to unroll 
results in a final NIR representation with 39 loop (I'm actually not 
sure where they all come from as the raw shader seems to contain far 
fewer), but when unrolling in nir we end up with only 14 that could not 
be unrolled. The end result is a reduction in code size of 55%.



I don't know if
this is the right metric to look at when comparing loop unroll
efficacy.

IOW, you might want to look at actual perf of some of the affected
games. (For all I know it really does improve. My point is that this
isn't a good measure of that.)


If this were simply a case of less loops being unrolled one would also 
expect Max Waves to drop but instead they increased. There was a bunch 
of testing done when i965 switched to using NIR only for unrolling and 
once a couple of regressions were fixed doing it in NIR was shown to be 
much better. The fact is GLSL IR opts can end up doing more harm than 
good, eventually I'd still like to be able to do a a NIR packing pass 
like we have in GLSL IR and move various parts of the linker to NIR so 
that we can try disabling even more GLSL IR opts.






LDS: 0 -> 0 (0.00 %) blocks
Max Waves: 1355 -> 1432 (5.68 %)
Wait states: 0 -> 0 (0.00 %)
---
  src/gallium/drivers/radeonsi/si_get.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/src/gallium/drivers/radeonsi/si_get.c 
b/src/gallium/drivers/radeonsi/si_get.c
index ef03a962d1..18d9cec414 100644
--- a/src/gallium/drivers/radeonsi/si_get.c
+++ b/src/gallium/drivers/radeonsi/si_get.c
@@ -437,6 +437,8 @@ static int si_get_shader_param(struct pipe_screen* pscreen,
 case PIPE_SHADER_CAP_MAX_SHADER_IMAGES:
 return SI_NUM_IMAGES;
 case PIPE_SHADER_CAP_MAX_UNROLL_ITERATIONS_HINT:
+   if (sscreen->debug_flags & DBG(NIR))
+   return 0;
 return 32;
 case PIPE_SHADER_CAP_PREFERRED_IR:
 if (sscreen->debug_flags & DBG(NIR))
--
2.14.3

___
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 v11 09/15] vulkan/wsi/x11: Cleanly handle shutdowns in FIFO thread

[Jason Ekstrand]

On Wed, Feb 21, 2018 at 1:32 PM, Daniel Stone  wrote:

> Hi,
>
> On 21 February 2018 at 20:50, Jason Ekstrand  wrote:
> > On Wed, Feb 21, 2018 at 6:05 AM, Daniel Stone 
> wrote:
> >> @@ -832,7 +832,7 @@ x11_acquire_next_image_from_queue(struct
> x11_swapchain
> >> *chain,
> >> VkResult result = wsi_queue_pull(>acquire_queue,
> >>  _index, timeout);
> >> /* On error, the thread has shut down, so safe to update
> chain->status
> >> */
> >> -   if (result < 0)
> >> +   if (result < 0 || image_index == UINT32_MAX)
> >
> > This only fixes an issue created by the previous patch.
> >
> >>
> >>return x11_swapchain_result(chain, result);
> >>
> >> assert(image_index < chain->base.image_count);
> >> @@ -938,7 +938,7 @@ x11_manage_fifo_queues(void *state)
> >>result = wsi_queue_pull(>present_queue, _index,
> >> INT64_MAX);
> >>if (result < 0) {
> >>   goto fail;
> >> -  } else if (chain->status < 0) {
> >> +  } else if (chain->status < 0 || image_index == UINT32_MAX) {
> >
> > The one time UINT32_MAX is pushed onto the queue, chain->status is set to
> > VK_ERROR_OUT_OF_DATE_KHR.
>
> Right you are; oops. Should it just be squashed in?
>

Just a second.  Let me send patches.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v11 10/15] vulkan/wsi/x11: Add support for DRI3 v1.1

[Daniel Stone]

Hi,

On 21 February 2018 at 21:24, Jason Ekstrand  wrote:
> On Wed, Feb 21, 2018 at 1:22 PM, Jason Ekstrand 
> wrote:
>>> +   uint32_t n = 0;
>>> +   uint32_t counts[2];
>>> +   uint64_t *modifiers[2];
>>> +
>>> +   if (mod_reply->num_drawable_modifiers) {
>>> +  counts[n] = mod_reply->num_drawable_modifiers;
>>> +  modifiers[n] = vk_alloc(pAllocator,
>>> +  counts[n] * sizeof(uint64_t),
>>> +  8, VK_SYSTEM_ALLOCATION_SCOPE_OBJECT);
>>> +  if (!modifiers[n]) {
>>> + free(mod_reply);
>>> + goto out;
>>> +  }
>>> +
>>> +  memcpy(modifiers[n],
>>> +
>>> xcb_dri3_get_supported_modifiers_drawable_modifiers(mod_reply),
>>
>> Did we ever get a solid answer on whether or not this memcpy is really
>> needed?  I doubt it is.
>
> I'm an idiot.  It is needed because we free mod_reply at the end of the
> function.  We could probably restructure so it isn't needed but I doubt it's
> really worth it.

Yeah, I couldn't see a way to cleanly plumb it through.

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

Re: [Mesa-dev] [PATCH v11 09/15] vulkan/wsi/x11: Cleanly handle shutdowns in FIFO thread

[Daniel Stone]

Hi,

On 21 February 2018 at 20:50, Jason Ekstrand  wrote:
> On Wed, Feb 21, 2018 at 6:05 AM, Daniel Stone  wrote:
>> @@ -832,7 +832,7 @@ x11_acquire_next_image_from_queue(struct x11_swapchain
>> *chain,
>> VkResult result = wsi_queue_pull(>acquire_queue,
>>  _index, timeout);
>> /* On error, the thread has shut down, so safe to update chain->status
>> */
>> -   if (result < 0)
>> +   if (result < 0 || image_index == UINT32_MAX)
>
> This only fixes an issue created by the previous patch.
>
>>
>>return x11_swapchain_result(chain, result);
>>
>> assert(image_index < chain->base.image_count);
>> @@ -938,7 +938,7 @@ x11_manage_fifo_queues(void *state)
>>result = wsi_queue_pull(>present_queue, _index,
>> INT64_MAX);
>>if (result < 0) {
>>   goto fail;
>> -  } else if (chain->status < 0) {
>> +  } else if (chain->status < 0 || image_index == UINT32_MAX) {
>
> The one time UINT32_MAX is pushed onto the queue, chain->status is set to
> VK_ERROR_OUT_OF_DATE_KHR.

Right you are; oops. Should it just be squashed in?

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

Re: [Mesa-dev] [PATCH v11 10/15] vulkan/wsi/x11: Add support for DRI3 v1.1

[Jason Ekstrand]

On Wed, Feb 21, 2018 at 1:22 PM, Jason Ekstrand 
wrote:

> On Wed, Feb 21, 2018 at 6:05 AM, Daniel Stone 
> wrote:
>
>> Adds support for multiple planes and buffer modifiers.
>>
>> v4: Rename "has_dri3_v1_1" to "has_dri3_modifiers"
>> Signed-off-by: Daniel Stone 
>> ---
>>  src/vulkan/wsi/wsi_common_x11.c | 185 ++
>> ++
>>  1 file changed, 168 insertions(+), 17 deletions(-)
>>
>> diff --git a/src/vulkan/wsi/wsi_common_x11.c
>> b/src/vulkan/wsi/wsi_common_x11.c
>> index dadada82ef1..213a597a430 100644
>> --- a/src/vulkan/wsi/wsi_common_x11.c
>> +++ b/src/vulkan/wsi/wsi_common_x11.c
>> @@ -36,6 +36,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include "util/hash_table.h"
>>
>>  #include "vk_util.h"
>> @@ -50,6 +51,7 @@
>>
>>  struct wsi_x11_connection {
>> bool has_dri3;
>> +   bool has_dri3_modifiers;
>> bool has_present;
>> bool is_proprietary_x11;
>>  };
>> @@ -164,6 +166,19 @@ wsi_x11_connection_create(const
>> VkAllocationCallbacks *alloc,
>> }
>>
>> wsi_conn->has_dri3 = dri3_reply->present != 0;
>> +#if XCB_DRI3_MAJOR_VERSION > 1 || XCB_DRI3_MINOR_VERSION >= 1
>> +   if (wsi_conn->has_dri3) {
>> +  xcb_dri3_query_version_cookie_t ver_cookie;
>> +  xcb_dri3_query_version_reply_t *ver_reply;
>> +
>> +  ver_cookie = xcb_dri3_query_version(conn, 1, 1);
>> +  ver_reply = xcb_dri3_query_version_reply(conn, ver_cookie, NULL);
>> +  wsi_conn->has_dri3_modifiers =
>> + (ver_reply->major_version > 1 || ver_reply->minor_version >= 1);
>> +  free(ver_reply);
>> +   }
>> +#endif
>> +
>> wsi_conn->has_present = pres_reply->present != 0;
>> wsi_conn->is_proprietary_x11 = false;
>> if (amd_reply && amd_reply->present)
>> @@ -620,6 +635,8 @@ struct x11_image {
>>  struct x11_swapchain {
>> struct wsi_swapchainbase;
>>
>> +   bool has_dri3_modifiers;
>> +
>> xcb_connection_t *   conn;
>> xcb_window_t window;
>> xcb_gc_t gc;
>> @@ -974,7 +991,9 @@ static VkResult
>>  x11_image_init(VkDevice device_h, struct x11_swapchain *chain,
>> const VkSwapchainCreateInfoKHR *pCreateInfo,
>> const VkAllocationCallbacks* pAllocator,
>> -   struct x11_image *image)
>> +   const uint64_t *const *modifiers,
>> +   const uint32_t *num_modifiers,
>> +   int num_tranches, struct x11_image *image)
>>  {
>> xcb_void_cookie_t cookie;
>> VkResult result;
>> @@ -984,28 +1003,60 @@ x11_image_init(VkDevice device_h, struct
>> x11_swapchain *chain,
>>result = wsi_create_prime_image(>base, pCreateInfo,
>> >base);
>> } else {
>>result = wsi_create_native_image(>base, pCreateInfo,
>> -   0, NULL, NULL, >base);
>> +   num_tranches, num_modifiers,
>> modifiers,
>> +   >base);
>> }
>> if (result < 0)
>>return result;
>>
>> image->pixmap = xcb_generate_id(chain->conn);
>>
>> -   /* Without passing modifiers, we can't have multi-plane RGB images. */
>> -   assert(image->base.num_planes == 1);
>> -
>> -   cookie =
>> -  xcb_dri3_pixmap_from_buffer_checked(chain->conn,
>> -  image->pixmap,
>> -  chain->window,
>> -  image->base.sizes[0],
>> -  pCreateInfo->imageExtent.width
>> ,
>> -  pCreateInfo->imageExtent.heigh
>> t,
>> -  image->base.row_pitches[0],
>> -  chain->depth, bpp,
>> -  image->base.fds[0]);
>> +#if XCB_DRI3_MAJOR_VERSION > 1 || XCB_DRI3_MINOR_VERSION >= 1
>> +   if (image->base.drm_modifier != DRM_FORMAT_MOD_INVALID) {
>> +  /* If the image has a modifier, we must have DRI3 v1.1. */
>> +  assert(chain->has_dri3_modifiers);
>> +
>> +  cookie =
>> + xcb_dri3_pixmap_from_buffers_checked(chain->conn,
>> +  image->pixmap,
>> +  chain->window,
>> +  image->base.num_planes,
>> +
>> pCreateInfo->imageExtent.width,
>> +
>> pCreateInfo->imageExtent.height,
>> +  image->base.row_pitches[0],
>> +  image->base.offsets[0],
>> +  image->base.row_pitches[1],
>> +  image->base.offsets[1],
>> +

Re: [Mesa-dev] [PATCH] anv: Don't assert that stencil HiZ clears are single-slice

[Rafael Antognolli]

Tested-by: Rafael Antognolli 

On Wed, Feb 21, 2018 at 01:08:26PM -0800, Jason Ekstrand wrote:
> It's true for depth HiZ clears because we only have HiZ on single-slice
> images right now.  However, for stencil-only clears there is no such
> restriction.
> ---
>  src/intel/vulkan/genX_cmd_buffer.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/src/intel/vulkan/genX_cmd_buffer.c 
> b/src/intel/vulkan/genX_cmd_buffer.c
> index 8015a42..ce54624 100644
> --- a/src/intel/vulkan/genX_cmd_buffer.c
> +++ b/src/intel/vulkan/genX_cmd_buffer.c
> @@ -3438,9 +3438,12 @@ cmd_buffer_begin_subpass(struct anv_cmd_buffer 
> *cmd_buffer,
>   
> VK_IMAGE_ASPECT_STENCIL_BIT)) {
>   if (att_state->fast_clear) {
>  /* We currently only support HiZ for single-layer images */
> -assert(iview->planes[0].isl.base_level == 0);
> -assert(iview->planes[0].isl.base_array_layer == 0);
> -assert(fb->layers == 1);
> +if (att_state->pending_clear_aspects & 
> VK_IMAGE_ASPECT_DEPTH_BIT) {
> +   assert(iview->image->planes[0].aux_usage == 
> ISL_AUX_USAGE_HIZ);
> +   assert(iview->planes[0].isl.base_level == 0);
> +   assert(iview->planes[0].isl.base_array_layer == 0);
> +   assert(fb->layers == 1);
> +}
>  
>  anv_image_hiz_clear(cmd_buffer, image,
>  att_state->pending_clear_aspects,
> -- 
> 2.5.0.400.gff86faf
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v11 10/15] vulkan/wsi/x11: Add support for DRI3 v1.1

[Jason Ekstrand]

On Wed, Feb 21, 2018 at 6:05 AM, Daniel Stone  wrote:

> Adds support for multiple planes and buffer modifiers.
>
> v4: Rename "has_dri3_v1_1" to "has_dri3_modifiers"
> Signed-off-by: Daniel Stone 
> ---
>  src/vulkan/wsi/wsi_common_x11.c | 185 ++
> ++
>  1 file changed, 168 insertions(+), 17 deletions(-)
>
> diff --git a/src/vulkan/wsi/wsi_common_x11.c b/src/vulkan/wsi/wsi_common_
> x11.c
> index dadada82ef1..213a597a430 100644
> --- a/src/vulkan/wsi/wsi_common_x11.c
> +++ b/src/vulkan/wsi/wsi_common_x11.c
> @@ -36,6 +36,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include "util/hash_table.h"
>
>  #include "vk_util.h"
> @@ -50,6 +51,7 @@
>
>  struct wsi_x11_connection {
> bool has_dri3;
> +   bool has_dri3_modifiers;
> bool has_present;
> bool is_proprietary_x11;
>  };
> @@ -164,6 +166,19 @@ wsi_x11_connection_create(const
> VkAllocationCallbacks *alloc,
> }
>
> wsi_conn->has_dri3 = dri3_reply->present != 0;
> +#if XCB_DRI3_MAJOR_VERSION > 1 || XCB_DRI3_MINOR_VERSION >= 1
> +   if (wsi_conn->has_dri3) {
> +  xcb_dri3_query_version_cookie_t ver_cookie;
> +  xcb_dri3_query_version_reply_t *ver_reply;
> +
> +  ver_cookie = xcb_dri3_query_version(conn, 1, 1);
> +  ver_reply = xcb_dri3_query_version_reply(conn, ver_cookie, NULL);
> +  wsi_conn->has_dri3_modifiers =
> + (ver_reply->major_version > 1 || ver_reply->minor_version >= 1);
> +  free(ver_reply);
> +   }
> +#endif
> +
> wsi_conn->has_present = pres_reply->present != 0;
> wsi_conn->is_proprietary_x11 = false;
> if (amd_reply && amd_reply->present)
> @@ -620,6 +635,8 @@ struct x11_image {
>  struct x11_swapchain {
> struct wsi_swapchainbase;
>
> +   bool has_dri3_modifiers;
> +
> xcb_connection_t *   conn;
> xcb_window_t window;
> xcb_gc_t gc;
> @@ -974,7 +991,9 @@ static VkResult
>  x11_image_init(VkDevice device_h, struct x11_swapchain *chain,
> const VkSwapchainCreateInfoKHR *pCreateInfo,
> const VkAllocationCallbacks* pAllocator,
> -   struct x11_image *image)
> +   const uint64_t *const *modifiers,
> +   const uint32_t *num_modifiers,
> +   int num_tranches, struct x11_image *image)
>  {
> xcb_void_cookie_t cookie;
> VkResult result;
> @@ -984,28 +1003,60 @@ x11_image_init(VkDevice device_h, struct
> x11_swapchain *chain,
>result = wsi_create_prime_image(>base, pCreateInfo,
> >base);
> } else {
>result = wsi_create_native_image(>base, pCreateInfo,
> -   0, NULL, NULL, >base);
> +   num_tranches, num_modifiers,
> modifiers,
> +   >base);
> }
> if (result < 0)
>return result;
>
> image->pixmap = xcb_generate_id(chain->conn);
>
> -   /* Without passing modifiers, we can't have multi-plane RGB images. */
> -   assert(image->base.num_planes == 1);
> -
> -   cookie =
> -  xcb_dri3_pixmap_from_buffer_checked(chain->conn,
> -  image->pixmap,
> -  chain->window,
> -  image->base.sizes[0],
> -  pCreateInfo->imageExtent.width,
> -  pCreateInfo->imageExtent.
> height,
> -  image->base.row_pitches[0],
> -  chain->depth, bpp,
> -  image->base.fds[0]);
> +#if XCB_DRI3_MAJOR_VERSION > 1 || XCB_DRI3_MINOR_VERSION >= 1
> +   if (image->base.drm_modifier != DRM_FORMAT_MOD_INVALID) {
> +  /* If the image has a modifier, we must have DRI3 v1.1. */
> +  assert(chain->has_dri3_modifiers);
> +
> +  cookie =
> + xcb_dri3_pixmap_from_buffers_checked(chain->conn,
> +  image->pixmap,
> +  chain->window,
> +  image->base.num_planes,
> +  pCreateInfo->imageExtent.
> width,
> +  pCreateInfo->imageExtent.
> height,
> +  image->base.row_pitches[0],
> +  image->base.offsets[0],
> +  image->base.row_pitches[1],
> +  image->base.offsets[1],
> +  image->base.row_pitches[2],
> +  image->base.offsets[2],
> + 

Re: [Mesa-dev] [PATCH v2 2/2] radv: implement AMD_gcn_shader extension

[Connor Abbott]

On Wed, Feb 21, 2018 at 3:03 PM, Daniel Schürmann
 wrote:
>
>> On Wed, Feb 21, 2018 at 1:00 PM,  
>> wrote:
>>>
>>> From: Dave Airlie 
>>>
>>> Co-authored-by: Daniel Schürmann 
>>> Signed-off-by: Daniel Schürmann 
>>> ---
>>>   src/amd/common/ac_llvm_build.c|  3 +-
>>>   src/amd/common/ac_nir_to_llvm.c   | 39 ++
>>>   src/amd/vulkan/radv_extensions.py |  1 +
>>>   src/compiler/nir/meson.build  |  1 +
>>>   src/compiler/nir/nir_intrinsics.h |  4 +++
>>>   src/compiler/spirv/spirv_to_nir.c |  2 ++
>>>   src/compiler/spirv/vtn_amd.c  | 68
>>> +++
>>>   src/compiler/spirv/vtn_private.h  |  3 ++
>>>   8 files changed, 120 insertions(+), 1 deletion(-)
>>>   create mode 100644 src/compiler/spirv/vtn_amd.c
>>>
>>> diff --git a/src/amd/common/ac_llvm_build.c
>>> b/src/amd/common/ac_llvm_build.c
>>> index 15144addb9..3bb74c2b0b 100644
>>> --- a/src/amd/common/ac_llvm_build.c
>>> +++ b/src/amd/common/ac_llvm_build.c
>>> @@ -370,7 +370,8 @@ LLVMValueRef
>>>   ac_build_shader_clock(struct ac_llvm_context *ctx)
>>>   {
>>>  LLVMValueRef tmp = ac_build_intrinsic(ctx,
>>> "llvm.readcyclecounter",
>>> - ctx->i64, NULL, 0, 0);
>>> + ctx->i64, NULL, 0,
>>> AC_FUNC_ATTR_READONLY);
>>> +   ac_build_optimization_barrier(ctx, );
>>
>> ac_build_optimization_barrier() creates an empty inline asm statement,
>> which actually doesn't do much to prevent code motion beyond the
>> attributes already added to llvm.readcyclecounter by llvm. It prevents
>> duplicating it, but that's about it, and not useful anyways. We only
>> use it to work around some problems with cross-wavefront intrinsics,
>> which don't exist here. You can just drop this hunk.
>
> It also prevents LLVM from eliminating multiple calls to the same function,
> which is the purpose in this case. (And also functions as "kind of" code
> motion barrier)

I think we can fix this by removing the "readonly" parameter from
ac_build_intrinsic(). LLVM doesn't really give you many extra
guarantees with an inline asm block, compared to an intrinsic with no
flags set. The only difference, I think, is that noduplicate is
implied for asm calls with the sideeffect bit set, but that's not
useful here.

>
>>
>>>  return LLVMBuildBitCast(ctx->builder, tmp, ctx->v2i32, "");
>>>   }
>>>
>>> diff --git a/src/amd/common/ac_nir_to_llvm.c
>>> b/src/amd/common/ac_nir_to_llvm.c
>>> index 2460e105f7..05f28b26a2 100644
>>> --- a/src/amd/common/ac_nir_to_llvm.c
>>> +++ b/src/amd/common/ac_nir_to_llvm.c
>>> @@ -4328,6 +4328,38 @@ load_patch_vertices_in(struct ac_shader_abi *abi)
>>>  return LLVMConstInt(ctx->ac.i32,
>>> ctx->options->key.tcs.input_vertices, false);
>>>   }
>>>
>>> +static LLVMValueRef
>>> +visit_cube_face_index(struct ac_nir_context *ctx,
>>> + nir_intrinsic_instr *instr)
>>> +{
>>> +   LLVMValueRef result;
>>> +   LLVMValueRef in[3];
>>> +   LLVMValueRef src0 = ac_to_float(>ac, get_src(ctx,
>>> instr->src[0]));
>>> +   for (unsigned chan = 0; chan < 3; chan++)
>>> +   in[chan] = ac_llvm_extract_elem(>ac, src0, chan);
>>> +
>>> +   result = ac_build_intrinsic(>ac,  "llvm.amdgcn.cubeid",
>>> +   ctx->ac.f32, in, 3,
>>> AC_FUNC_ATTR_READNONE);
>>> +   return result;
>>> +}
>>> +
>>> +static LLVMValueRef
>>> +visit_cube_face_coord(struct ac_nir_context *ctx,
>>> + nir_intrinsic_instr *instr)
>>> +{
>>> +   LLVMValueRef results[2];
>>> +   LLVMValueRef in[3];
>>> +   LLVMValueRef src0 = ac_to_float(>ac, get_src(ctx,
>>> instr->src[0]));
>>> +   for (unsigned chan = 0; chan < 3; chan++)
>>> +   in[chan] = ac_llvm_extract_elem(>ac, src0, chan);
>>> +
>>> +   results[0] = ac_build_intrinsic(>ac, "llvm.amdgcn.cubetc",
>>> +   ctx->ac.f32, in, 3,
>>> AC_FUNC_ATTR_READNONE);
>>> +   results[1] = ac_build_intrinsic(>ac, "llvm.amdgcn.cubesc",
>>> +   ctx->ac.f32, in, 3,
>>> AC_FUNC_ATTR_READNONE);
>>> +   return ac_build_gather_values(>ac, results, 2);
>>> +}
>>> +
>>>   static void visit_intrinsic(struct ac_nir_context *ctx,
>>>   nir_intrinsic_instr *instr)
>>>   {
>>> @@ -4613,6 +4645,13 @@ static void visit_intrinsic(struct ac_nir_context
>>> *ctx,
>>>  result = LLVMBuildSExt(ctx->ac.builder, tmp,
>>> ctx->ac.i32, "");
>>>  break;
>>>  }
>>> +   case nir_intrinsic_cube_face_index:
>>> +   result = visit_cube_face_index(ctx, instr);
>>> +   break;
>>> +   case nir_intrinsic_cube_face_coord:
>>> +   result = 

Re: [Mesa-dev] [Mesa-stable] [PATCH] glx: Properly handle cases where screen creation fails

[Emil Velikov]

On 21 February 2018 at 15:10, Chuck Atkins  wrote:
>> Something doesn't look quite right - it seems that xmesa_init_display
>> should be fixed instead.
>>
>> Currently it returns non-NULL when either of the following fail:
>>  - driver.create_pipe_screen()
>>  - CALLOC_STRUCT
>>
>> I would add an explicit check after those + goto err_path.
>> The latter of which doing some proper teardown. Note: that there's a
>> leak in there - one should walk, detach & free the new entry from the
>> MesaExtInfo list.
>
>
> Rather than deal with the list cleanup after the fact, I can postpone the
> list insertion until the end when info is in a known good state.  That way
> when the error conditions are hit, the only cleanup that needs to be done is
> localized to screen and smapi.
>
That will also work - the DRI based GLX does it already. For details
see the __glXInitialize in src/glx/glxext.c.

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

[Mesa-dev] [PATCH] anv: Don't assert that stencil HiZ clears are single-slice

[Jason Ekstrand]

It's true for depth HiZ clears because we only have HiZ on single-slice
images right now.  However, for stencil-only clears there is no such
restriction.
---
 src/intel/vulkan/genX_cmd_buffer.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/src/intel/vulkan/genX_cmd_buffer.c 
b/src/intel/vulkan/genX_cmd_buffer.c
index 8015a42..ce54624 100644
--- a/src/intel/vulkan/genX_cmd_buffer.c
+++ b/src/intel/vulkan/genX_cmd_buffer.c
@@ -3438,9 +3438,12 @@ cmd_buffer_begin_subpass(struct anv_cmd_buffer 
*cmd_buffer,
  
VK_IMAGE_ASPECT_STENCIL_BIT)) {
  if (att_state->fast_clear) {
 /* We currently only support HiZ for single-layer images */
-assert(iview->planes[0].isl.base_level == 0);
-assert(iview->planes[0].isl.base_array_layer == 0);
-assert(fb->layers == 1);
+if (att_state->pending_clear_aspects & VK_IMAGE_ASPECT_DEPTH_BIT) {
+   assert(iview->image->planes[0].aux_usage == ISL_AUX_USAGE_HIZ);
+   assert(iview->planes[0].isl.base_level == 0);
+   assert(iview->planes[0].isl.base_array_layer == 0);
+   assert(fb->layers == 1);
+}
 
 anv_image_hiz_clear(cmd_buffer, image,
 att_state->pending_clear_aspects,
-- 
2.5.0.400.gff86faf

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

Re: [Mesa-dev] [PATCH 2/2] radeonsi/nir: fix tess varying loads for doubles

[Marek Olšák]

For the series:

Reviewed-by: Marek Olšák 

Marek

On Wed, Feb 21, 2018 at 12:42 AM, Timothy Arceri  wrote:
> Fixes the following piglit tests:
>
> tests/spec/arb_tessellation_shader/execution/double-array-vs-tcs-tes.shader_test
> tests/spec/arb_tessellation_shader/execution/double-vs-tcs-tes.shader_test
> ---
>  src/gallium/drivers/radeonsi/si_shader.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/drivers/radeonsi/si_shader.c 
> b/src/gallium/drivers/radeonsi/si_shader.c
> index 33319b249c..9ccae9f18d 100644
> --- a/src/gallium/drivers/radeonsi/si_shader.c
> +++ b/src/gallium/drivers/radeonsi/si_shader.c
> @@ -1273,7 +1273,7 @@ static LLVMValueRef si_nir_load_tcs_varyings(struct 
> ac_shader_abi *abi,
>
> LLVMValueRef value[4];
> for (unsigned i = 0; i < num_components + component; i++) {
> -   value[i] = lds_load(bld_base, ctx->i32, i, dw_addr);
> +   value[i] = lds_load(bld_base, type, i, dw_addr);
> }
>
> return ac_build_varying_gather_values(>ac, value, 
> num_components, component);
> @@ -1360,7 +1360,7 @@ LLVMValueRef si_nir_load_input_tes(struct ac_shader_abi 
> *abi,
>  */
> LLVMValueRef value[4];
> for (unsigned i = component; i < num_components + component; i++) {
> -   value[i] = buffer_load(>bld_base, ctx->i32, i, buffer, 
> base, addr, true);
> +   value[i] = buffer_load(>bld_base, type, i, buffer, base, 
> addr, true);
> }
>
> return ac_build_varying_gather_values(>ac, value, 
> num_components, component);
> --
> 2.14.3
>
> ___
> 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 v11 09/15] vulkan/wsi/x11: Cleanly handle shutdowns in FIFO thread

[Jason Ekstrand]

On Wed, Feb 21, 2018 at 6:05 AM, Daniel Stone  wrote:

> The FIFO thread signals shutdown by pushing UINT32_MAX into the acquire
> queue, and shutdown is signaled to it by pushing UINT32_MAX into the
> present queue.
>
> Explicitly catch a push of UINT32_MAX in either direction and treat this
> as error.
>
> Signed-off-by: Daniel Stone 
> ---
>  src/vulkan/wsi/wsi_common_x11.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/vulkan/wsi/wsi_common_x11.c b/src/vulkan/wsi/wsi_common_
> x11.c
> index e84572810d3..dadada82ef1 100644
> --- a/src/vulkan/wsi/wsi_common_x11.c
> +++ b/src/vulkan/wsi/wsi_common_x11.c
> @@ -832,7 +832,7 @@ x11_acquire_next_image_from_queue(struct
> x11_swapchain *chain,
> VkResult result = wsi_queue_pull(>acquire_queue,
>  _index, timeout);
> /* On error, the thread has shut down, so safe to update chain->status
> */
> -   if (result < 0)
> +   if (result < 0 || image_index == UINT32_MAX)
>

This only fixes an issue created by the previous patch.


>return x11_swapchain_result(chain, result);
>
> assert(image_index < chain->base.image_count);
> @@ -938,7 +938,7 @@ x11_manage_fifo_queues(void *state)
>result = wsi_queue_pull(>present_queue, _index,
> INT64_MAX);
>if (result < 0) {
>   goto fail;
> -  } else if (chain->status < 0) {
> +  } else if (chain->status < 0 || image_index == UINT32_MAX) {
>

The one time UINT32_MAX is pushed onto the queue, chain->status is set to
VK_ERROR_OUT_OF_DATE_KHR.


>   /* The status can change underneath us if the swapchain is
> destroyed
>* from another thread.
>*/
> --
> 2.14.3
>
> ___
> 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] radeonsi/nir: collect more accurate output_usagemask

[Marek Olšák]

Reviewed-by: Marek Olšák 

Marek

On Wed, Feb 21, 2018 at 7:03 AM, Timothy Arceri  wrote:
> Fixes assert in glsl-1.50-gs-max-output-components piglit test.
>
> Note that the double handling will only work for doubles that
> don't take up multiple slots i.e. double and dvec2. However
> dual slot double handling is an existing bug which is made no
> worse by this patch.
> ---
>  src/gallium/drivers/radeonsi/si_shader_nir.c | 56 
> +---
>  1 file changed, 43 insertions(+), 13 deletions(-)
>
> diff --git a/src/gallium/drivers/radeonsi/si_shader_nir.c 
> b/src/gallium/drivers/radeonsi/si_shader_nir.c
> index 3294019cea..7b10410dd7 100644
> --- a/src/gallium/drivers/radeonsi/si_shader_nir.c
> +++ b/src/gallium/drivers/radeonsi/si_shader_nir.c
> @@ -462,21 +462,35 @@ void si_nir_scan_shader(const struct nir_shader *nir,
> }
>
> i = variable->data.driver_location;
> -   if (processed_outputs & ((uint64_t)1 << i))
> -   continue;
> -
> -   processed_outputs |= ((uint64_t)1 << i);
> -   num_outputs++;
> -
> -   info->output_semantic_name[i] = semantic_name;
> -   info->output_semantic_index[i] = semantic_index;
> -   info->output_usagemask[i] = TGSI_WRITEMASK_XYZW;
>
> unsigned num_components = 4;
> unsigned vector_elements = 
> glsl_get_vector_elements(glsl_without_array(variable->type));
> if (vector_elements)
> num_components = vector_elements;
>
> +   if (glsl_type_is_64bit(glsl_without_array(variable->type)))
> +   num_components = MIN2(num_components * 2, 4);
> +
> +   ubyte usagemask = 0;
> +   for (unsigned j = 0; j < num_components; j++) {
> +   switch (j + variable->data.location_frac) {
> +   case 0:
> +   usagemask |= TGSI_WRITEMASK_X;
> +   break;
> +   case 1:
> +   usagemask |= TGSI_WRITEMASK_Y;
> +   break;
> +   case 2:
> +   usagemask |= TGSI_WRITEMASK_Z;
> +   break;
> +   case 3:
> +   usagemask |= TGSI_WRITEMASK_W;
> +   break;
> +   default:
> +   unreachable("error calculating 
> component index");
> +   }
> +   }
> +
> unsigned gs_out_streams;
> if (variable->data.stream & (1u << 31)) {
> gs_out_streams = variable->data.stream & ~(1u << 31);
> @@ -492,23 +506,39 @@ void si_nir_scan_shader(const struct nir_shader *nir,
> unsigned streamz = (gs_out_streams >> 4) & 3;
> unsigned streamw = (gs_out_streams >> 6) & 3;
>
> -   if (info->output_usagemask[i] & TGSI_WRITEMASK_X) {
> +   if (usagemask & TGSI_WRITEMASK_X) {
> +   info->output_usagemask[i] |= TGSI_WRITEMASK_X;
> info->output_streams[i] |= streamx;
> info->num_stream_output_components[streamx]++;
> }
> -   if (info->output_usagemask[i] & TGSI_WRITEMASK_Y) {
> +   if (usagemask & TGSI_WRITEMASK_Y) {
> +   info->output_usagemask[i] |= TGSI_WRITEMASK_Y;
> info->output_streams[i] |= streamy << 2;
> info->num_stream_output_components[streamy]++;
> }
> -   if (info->output_usagemask[i] & TGSI_WRITEMASK_Z) {
> +   if (usagemask & TGSI_WRITEMASK_Z) {
> +   info->output_usagemask[i] |= TGSI_WRITEMASK_Z;
> info->output_streams[i] |= streamz << 4;
> info->num_stream_output_components[streamz]++;
> }
> -   if (info->output_usagemask[i] & TGSI_WRITEMASK_W) {
> +   if (usagemask & TGSI_WRITEMASK_W) {
> +   info->output_usagemask[i] |= TGSI_WRITEMASK_W;
> info->output_streams[i] |= streamw << 6;
> info->num_stream_output_components[streamw]++;
> }
>
> +   /* make sure we only count this location once against the
> +* num_outputs counter.
> +*/
> +   if (processed_outputs & ((uint64_t)1 << i))
> +   continue;
> +
> +   processed_outputs |= ((uint64_t)1 << i);
> +   num_outputs++;
> +
> +   

Re: [Mesa-dev] [PATCH 01/17] intel: Add a preliminary device for Ice Lake

[Anuj Phogat]

On Wed, Feb 21, 2018 at 9:22 AM, Rafael Antognolli
 wrote:
> My understanding is that this commit is enough to make the driver try to
> initialize, at least for i965. If that's the case, how about we add
> something like what was removed by commit
> bf1577fe0972ae910c071743dc89d261a46c2926 for CNL?
>
> It could be either in this commit, or in a commit that precedes this
> one. Anv has an extra check for gen <= 10, so we don't need to worry
> there yet.
Yes, It'll be great to add a similar patch before this one. Also, I
think this patch should be the last patch in this series. Otherwise we'll
have a commit with ICL PCI IDs but missing compiler changes. Almost
nothing will work without the compiler patches.

>
> Rafael
>
> On Tue, Feb 20, 2018 at 09:15:08PM -0800, Matt Turner wrote:
>> From: Anuj Phogat 
>>
>> Signed-off-by: Anuj Phogat 
>> ---
>>  include/pci_ids/i965_pci_ids.h |  9 ++
>>  src/intel/common/gen_device_info.c | 56 
>> +-
>>  2 files changed, 64 insertions(+), 1 deletion(-)
>>
>> diff --git a/include/pci_ids/i965_pci_ids.h b/include/pci_ids/i965_pci_ids.h
>> index feb9c582b19..81c9a5f13fb 100644
>> --- a/include/pci_ids/i965_pci_ids.h
>> +++ b/include/pci_ids/i965_pci_ids.h
>> @@ -196,3 +196,12 @@ CHIPSET(0x5A50, cnl_5x8, "Intel(R) HD Graphics 
>> (Cannonlake 5x8 GT2)")
>>  CHIPSET(0x5A51, cnl_5x8, "Intel(R) HD Graphics (Cannonlake 5x8 GT2)")
>>  CHIPSET(0x5A52, cnl_5x8, "Intel(R) HD Graphics (Cannonlake 5x8 GT2)")
>>  CHIPSET(0x5A54, cnl_5x8, "Intel(R) HD Graphics (Cannonlake 5x8 GT2)")
>> +CHIPSET(0x8A50, icl_8x8, "Intel(R) HD Graphics (Ice Lake 8x8 GT2)")
>> +CHIPSET(0x8A51, icl_8x8, "Intel(R) HD Graphics (Ice Lake 8x8 GT2)")
>> +CHIPSET(0x8A52, icl_8x8, "Intel(R) HD Graphics (Ice Lake 8x8 GT2)")
>> +CHIPSET(0x8A5A, icl_6x8, "Intel(R) HD Graphics (Ice Lake 6x8 GT1.5)")
>> +CHIPSET(0x8A5B, icl_4x8, "Intel(R) HD Graphics (Ice Lake 4x8 GT1)")
>> +CHIPSET(0x8A5C, icl_6x8, "Intel(R) HD Graphics (Ice Lake 6x8 GT1.5)")
>> +CHIPSET(0x8A5D, icl_4x8, "Intel(R) HD Graphics (Ice Lake 4x8 GT1)")
>> +CHIPSET(0x8A71, icl_1x8, "Intel(R) HD Graphics (Ice Lake 1x8 GT0.5)")
>> +CHIPSET(0xFF05, icl_8x8, "Intel(R) HD Graphics (Ice Lake Simulation)")
>> diff --git a/src/intel/common/gen_device_info.c 
>> b/src/intel/common/gen_device_info.c
>> index a08a13a32a4..8bf4b6b9bb0 100644
>> --- a/src/intel/common/gen_device_info.c
>> +++ b/src/intel/common/gen_device_info.c
>> @@ -731,6 +731,49 @@ static const struct gen_device_info 
>> gen_device_info_cnl_5x8 = {
>> .is_cannonlake = true,
>>  };
>>
>> +#define GEN11_HW_INFO   \
>> +   .gen = 11,   \
>> +   .has_pln = false,\
>> +   .max_vs_threads = 364,   \
>> +   .max_gs_threads = 224,   \
>> +   .max_tcs_threads = 224,  \
>> +   .max_tes_threads = 364,  \
>> +   .max_cs_threads = 56,\
>> +   .urb = { \
>> +  .size = 1024, \
>> +  .min_entries = {  \
>> + [MESA_SHADER_VERTEX]= 64,  \
>> + [MESA_SHADER_TESS_EVAL] = 34,  \
>> +  },\
>> +  .max_entries = {  \
>> + [MESA_SHADER_VERTEX]= 2384,\
>> + [MESA_SHADER_TESS_CTRL] = 1032,\
>> + [MESA_SHADER_TESS_EVAL] = 2384,\
>> + [MESA_SHADER_GEOMETRY]  = 1032,\
>> +  },\
>> +   }
>> +
>> +#define GEN11_FEATURES(_gt, _slices, _l3)   \
>> +   GEN8_FEATURES,   \
>> +   GEN11_HW_INFO,   \
>> +   .gt = _gt, .num_slices = _slices, .l3_banks = _l3
>> +
>> +static const struct gen_device_info gen_device_info_icl_8x8 = {
>> +   GEN11_FEATURES(2, 1, 8),
>> +};
>> +
>> +static const struct gen_device_info gen_device_info_icl_6x8 = {
>> +   GEN11_FEATURES(1, 1, 6),
>> +};
>> +
>> +static const struct gen_device_info gen_device_info_icl_4x8 = {
>> +   GEN11_FEATURES(1, 1, 6),
>> +};
>> +
>> +static const struct gen_device_info gen_device_info_icl_1x8 = {
>> +   GEN11_FEATURES(1, 1, 6),
>> +};
>> +
>>  bool
>>  gen_get_device_info(int devid, struct gen_device_info *devinfo)
>>  {
>> @@ -757,10 +800,21 @@ gen_get_device_info(int devid, struct gen_device_info 
>> *devinfo)
>>  * Extra padding can be necessary depending how the thread IDs are
>>  * calculated for a particular shader stage.
>>  */
>> -   if (devinfo->gen >= 9) {
>> +
>> +   switch(devinfo->gen) {
>> +   case 9:
>> +   case 10:
>>devinfo->max_wm_threads = 64 /* threads-per-PSD */
>>

Re: [Mesa-dev] [PATCH 01/17] intel: Add a preliminary device for Ice Lake

[Matt Turner]

On Wed, Feb 21, 2018 at 10:37 AM, Anuj Phogat  wrote:
> On Wed, Feb 21, 2018 at 9:22 AM, Rafael Antognolli
>  wrote:
>> My understanding is that this commit is enough to make the driver try to
>> initialize, at least for i965. If that's the case, how about we add
>> something like what was removed by commit
>> bf1577fe0972ae910c071743dc89d261a46c2926 for CNL?
>>
>> It could be either in this commit, or in a commit that precedes this
>> one. Anv has an extra check for gen <= 10, so we don't need to worry
>> there yet.
> Yes, It'll be great to add a similar patch before this one. Also, I
> think this patch should be the last patch in this series. Otherwise we'll
> have a commit with ICL PCI IDs but missing compiler changes. Almost
> nothing will work without the compiler patches.

Good point. The reason I moved it here was because a few of my patches
add new fields to GEN11_FEATURES. How about I split the patch in two:
one that modifies gen_device_info.c and another for later that
actually adds the PCI IDs?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v11 07+08/15] vulkan/wsi/x11: Consistently update and return swapchain status

[Jason Ekstrand]

For this one, I'm making live edits to see if I like the suggested
changes.  I'll send out the v2 with the comments incorporated when I'm done.

On Wed, Feb 21, 2018 at 11:32 AM, Jason Ekstrand 
wrote:

> From: Daniel Stone 
>
> Use a helper function for updating the swapchain status. This will be
> used later to handle VK_SUBOPTIMAL_KHR, where we need to make a
> non-error status stick to the swapchain until recreation.  Instead of
> direct comparisons to VK_SUCCESS to check for error, test for negative
> numbers meaning an error status, and positive numbers indicating
> non-error statuses.
>
> Signed-off-by: Daniel Stone 
> ---
>  src/vulkan/wsi/wsi_common_x11.c | 104 ++
> --
>  1 file changed, 79 insertions(+), 25 deletions(-)
>
> diff --git a/src/vulkan/wsi/wsi_common_x11.c
> b/src/vulkan/wsi/wsi_common_x11.c
> index 2cc7a67..e845728 100644
> --- a/src/vulkan/wsi/wsi_common_x11.c
> +++ b/src/vulkan/wsi/wsi_common_x11.c
> @@ -641,6 +641,36 @@ struct x11_swapchain {
> struct x11_image images[0];
>  };
>
> +/**
> + * Update the swapchain status with the result of an operation, and return
> + * the combined status. The chain status will eventually be returned from
> + * AcquireNextImage and QueuePresent.
> + *
> + * We make sure to 'stick' more pessimistic statuses: an out-of-date error
> + * is permanent once seen, and every subsequent call will return this. If
> + * this has not been seen, success will be returned.
> + */
> +static VkResult
> +x11_swapchain_result(struct x11_swapchain *chain, VkResult result)
> +{
> +   /* Prioritise returning existing errors for consistency. */
> +   if (chain->status < 0)
> +  return chain->status;
> +
> +   /* If we have a new error, mark it as permanent on the chain and
> return. */
> +   if (result < 0) {
> +  chain->status = result;
> +  return result;
> +   }
> +
> +   /* Return temporary errors, but don't persist them. */
> +   if (result == VK_TIMEOUT || result == VK_NOT_READY)
> +  return result;
> +
> +   /* No changes, so return the last status. */
> +   return chain->status;
> +}
> +
>  static struct wsi_image *
>  x11_get_wsi_image(struct wsi_swapchain *wsi_chain, uint32_t image_index)
>  {
> @@ -648,6 +678,9 @@ x11_get_wsi_image(struct wsi_swapchain *wsi_chain,
> uint32_t image_index)
> return >images[image_index].base;
>  }
>
> +/**
> + * Process an X11 Present event. Does not update chain->status.
> + */
>  static VkResult
>  x11_handle_dri3_present_event(struct x11_swapchain *chain,
>xcb_present_generic_event_t *event)
> @@ -719,6 +752,8 @@ x11_acquire_next_image_poll_x11(struct x11_swapchain
> *chain,
> xcb_generic_event_t *event;
> struct pollfd pfds;
> uint64_t atimeout;
> +   VkResult result = VK_SUCCESS;
> +
> while (1) {
>for (uint32_t i = 0; i < chain->base.image_count; i++) {
>   if (!chain->images[i].busy) {
> @@ -726,7 +761,8 @@ x11_acquire_next_image_poll_x11(struct x11_swapchain
> *chain,
>  xshmfence_await(chain->images[i].shm_fence);
>  *image_index = i;
>  chain->images[i].busy = true;
> -return VK_SUCCESS;
> +result = VK_SUCCESS;
>

Since our neat little helper returns the accumulated result, these can all
be

- return VK_WHATEVER;
+ return x11_swapchain_result(chain, VK_WHATEVER);

That makes things quite a bit cleaner.


> +   goto out;
>   }
>}
>
> @@ -734,24 +770,31 @@ x11_acquire_next_image_poll_x11(struct
> x11_swapchain *chain,
>
>if (timeout == UINT64_MAX) {
>   event = xcb_wait_for_special_event(chain->conn,
> chain->special_event);
> - if (!event)
> -return VK_ERROR_OUT_OF_DATE_KHR;
> + if (!event) {
> +result = VK_ERROR_OUT_OF_DATE_KHR;
> +goto out;
> + }
>} else {
>   event = xcb_poll_for_special_event(chain->conn,
> chain->special_event);
>   if (!event) {
>  int ret;
> -if (timeout == 0)
> -   return VK_NOT_READY;
> +if (timeout == 0) {
> +   result = VK_NOT_READY;
> +   goto out;
> +}
>
>  atimeout = wsi_get_absolute_timeout(timeout);
>
>  pfds.fd = xcb_get_file_descriptor(chain->conn);
>  pfds.events = POLLIN;
>  ret = poll(, 1, timeout / 1000 / 1000);
> -if (ret == 0)
> -   return VK_TIMEOUT;
> -if (ret == -1)
> -   return VK_ERROR_OUT_OF_DATE_KHR;
> +if (ret == 0) {
> +   result = VK_TIMEOUT;
> +   goto out;
> +} else if (ret == -1) {
> +   result = VK_ERROR_OUT_OF_DATE_KHR;
> +   goto out;
> +}
>
>  /* If a non-special event happens, the fd will still

Re: [Mesa-dev] [PATCH v1 0/7] Implement commont gralloc_handle_t in libdrm

[Emil Velikov]

On 21 February 2018 at 18:50, Rob Herring  wrote:
> On Wed, Feb 21, 2018 at 10:01 AM, Emil Velikov  
> wrote:
>> Hi all,
>>
>> Pardon for dropping in late. I think you've got nearly everything
>> settled down, just sharing a couple of ideas.
>>
>> On 21 February 2018 at 04:19, Tomasz Figa  wrote:
>>> On Wed, Feb 21, 2018 at 4:03 AM, Rob Herring  wrote:
 On Tue, Feb 20, 2018 at 4:26 AM, Tomasz Figa  wrote:
>>
>>> It is actually incorrect to have the same device FD used for different
>>> screens, if PRIME is used, due to GEM namespace issues, e.g.
>>> - screen 0: drmPrimeFdToHandle(buffer A) -> 1,
>>> - screen 1: drmPrimeFdToHandle(buffer A) -> 1 (same handle in same
>>> namespace, due to semantics of PRIME import and same device FD used),
>>> - screen 0: GEM_CLOSE(handle = 1),
>>> - screen 1 still thinks handle 1 is valid...
>>>
>>> So this only works for control nodes using flink only. (Or if you
>>> always use libdrm_* for BO management and your particular
>>> implementation does its own GEM handle reference counting, but that's
>>> not guaranted.)
>>>
>> Had a sneaky feeling that that != 1 will be returned for screen 1's
>> drmPrimeFdToHandle call.
>> Regardless, moving to DRI3/dmabuf-only setups is the [really] long
>> term plan, I think.
>> I don't know if we can achieve it outside of CrOS - with all the
>> distros building and shipping things in subtly different manner.
>
> It's already possible for Android.
>
Great. Feel free to join me in pushing distributions forward ;-)

 How would that work if you support different GPUs in one image?
>>>
>>> It wouldn't and that's why I prefer probing available devices.
>>>
>>> For Chrome OS, we don't include GPU bits in system image, but rather
>>> have vendor images built separately for each board (although sharing
>>> any possible contents across board family, chipset, GPU type and so
>>> on), so we can have a custom .rc script (which sets a property) as
>>> well. It would even be possible to have paths hardcoded, but that
>>> would be prone to probe ordering issues which, with software fallback,
>>> could be actually not obvious to notice, and so we'd rather not go
>>> this route.
>>>
>>> So I'd agree here that we should revisit probing.
>>>
>> As you pointed out the fallback is not a good idea.
>
> Software fallback is a desired feature. Basing it on the path is the bad idea.
>
Even considering that a) the transition is not obvious and b) it will
cause serve performance degradation?
For development and prototyping purposes it's great. For production
... very few users will like the abysmal performance :-\

>> Plus, as the drm
>> node vary, one can use an Android property and match it to the info.
>> from drmGetDevice2.
>> Say the HW bus location, (sub)device PCIID, other.
>
> That generally doesn't work for non-x86.
>
Errr... wrong. If PCI bus does not exist (some arm boards to have them
though), one can use usb, platform or host1x specifics.
If those are not enough, suggestions are welcome.

https://cgit.freedesktop.org/mesa/drm/tree/xf86drm.h#n836

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

Re: [Mesa-dev] [PATCH v2 2/2] radv: implement AMD_gcn_shader extension

[Connor Abbott]

On Wed, Feb 21, 2018 at 3:13 PM, Connor Abbott  wrote:
> On Wed, Feb 21, 2018 at 3:03 PM, Daniel Schürmann
>  wrote:
>>
>>> On Wed, Feb 21, 2018 at 1:00 PM,  
>>> wrote:

 From: Dave Airlie 

 Co-authored-by: Daniel Schürmann 
 Signed-off-by: Daniel Schürmann 
 ---
   src/amd/common/ac_llvm_build.c|  3 +-
   src/amd/common/ac_nir_to_llvm.c   | 39 ++
   src/amd/vulkan/radv_extensions.py |  1 +
   src/compiler/nir/meson.build  |  1 +
   src/compiler/nir/nir_intrinsics.h |  4 +++
   src/compiler/spirv/spirv_to_nir.c |  2 ++
   src/compiler/spirv/vtn_amd.c  | 68
 +++
   src/compiler/spirv/vtn_private.h  |  3 ++
   8 files changed, 120 insertions(+), 1 deletion(-)
   create mode 100644 src/compiler/spirv/vtn_amd.c

 diff --git a/src/amd/common/ac_llvm_build.c
 b/src/amd/common/ac_llvm_build.c
 index 15144addb9..3bb74c2b0b 100644
 --- a/src/amd/common/ac_llvm_build.c
 +++ b/src/amd/common/ac_llvm_build.c
 @@ -370,7 +370,8 @@ LLVMValueRef
   ac_build_shader_clock(struct ac_llvm_context *ctx)
   {
  LLVMValueRef tmp = ac_build_intrinsic(ctx,
 "llvm.readcyclecounter",
 - ctx->i64, NULL, 0, 0);
 + ctx->i64, NULL, 0,
 AC_FUNC_ATTR_READONLY);
 +   ac_build_optimization_barrier(ctx, );
>>>
>>> ac_build_optimization_barrier() creates an empty inline asm statement,
>>> which actually doesn't do much to prevent code motion beyond the
>>> attributes already added to llvm.readcyclecounter by llvm. It prevents
>>> duplicating it, but that's about it, and not useful anyways. We only
>>> use it to work around some problems with cross-wavefront intrinsics,
>>> which don't exist here. You can just drop this hunk.
>>
>> It also prevents LLVM from eliminating multiple calls to the same function,
>> which is the purpose in this case. (And also functions as "kind of" code
>> motion barrier)
>
> I think we can fix this by removing the "readonly" parameter from
> ac_build_intrinsic(). LLVM doesn't really give you many extra
> guarantees with an inline asm block, compared to an intrinsic with no
> flags set. The only difference, I think, is that noduplicate is
> implied for asm calls with the sideeffect bit set, but that's not
> useful here.

(Also, I forgot to mention, but this should be a separate change,
since it impacts radeonsi NIR as well.)

>
>>
>>>
  return LLVMBuildBitCast(ctx->builder, tmp, ctx->v2i32, "");
   }

 diff --git a/src/amd/common/ac_nir_to_llvm.c
 b/src/amd/common/ac_nir_to_llvm.c
 index 2460e105f7..05f28b26a2 100644
 --- a/src/amd/common/ac_nir_to_llvm.c
 +++ b/src/amd/common/ac_nir_to_llvm.c
 @@ -4328,6 +4328,38 @@ load_patch_vertices_in(struct ac_shader_abi *abi)
  return LLVMConstInt(ctx->ac.i32,
 ctx->options->key.tcs.input_vertices, false);
   }

 +static LLVMValueRef
 +visit_cube_face_index(struct ac_nir_context *ctx,
 + nir_intrinsic_instr *instr)
 +{
 +   LLVMValueRef result;
 +   LLVMValueRef in[3];
 +   LLVMValueRef src0 = ac_to_float(>ac, get_src(ctx,
 instr->src[0]));
 +   for (unsigned chan = 0; chan < 3; chan++)
 +   in[chan] = ac_llvm_extract_elem(>ac, src0, chan);
 +
 +   result = ac_build_intrinsic(>ac,  "llvm.amdgcn.cubeid",
 +   ctx->ac.f32, in, 3,
 AC_FUNC_ATTR_READNONE);
 +   return result;
 +}
 +
 +static LLVMValueRef
 +visit_cube_face_coord(struct ac_nir_context *ctx,
 + nir_intrinsic_instr *instr)
 +{
 +   LLVMValueRef results[2];
 +   LLVMValueRef in[3];
 +   LLVMValueRef src0 = ac_to_float(>ac, get_src(ctx,
 instr->src[0]));
 +   for (unsigned chan = 0; chan < 3; chan++)
 +   in[chan] = ac_llvm_extract_elem(>ac, src0, chan);
 +
 +   results[0] = ac_build_intrinsic(>ac, "llvm.amdgcn.cubetc",
 +   ctx->ac.f32, in, 3,
 AC_FUNC_ATTR_READNONE);
 +   results[1] = ac_build_intrinsic(>ac, "llvm.amdgcn.cubesc",
 +   ctx->ac.f32, in, 3,
 AC_FUNC_ATTR_READNONE);
 +   return ac_build_gather_values(>ac, results, 2);
 +}
 +
   static void visit_intrinsic(struct ac_nir_context *ctx,
   nir_intrinsic_instr *instr)
   {
 @@ -4613,6 +4645,13 @@ static void visit_intrinsic(struct ac_nir_context
 *ctx,
  result = 

Re: [Mesa-dev] [PATCH v1 0/7] Implement commont gralloc_handle_t in libdrm

[Rob Herring]

On Wed, Feb 21, 2018 at 10:01 AM, Emil Velikov  wrote:
> Hi all,
>
> Pardon for dropping in late. I think you've got nearly everything
> settled down, just sharing a couple of ideas.
>
> On 21 February 2018 at 04:19, Tomasz Figa  wrote:
>> On Wed, Feb 21, 2018 at 4:03 AM, Rob Herring  wrote:
>>> On Tue, Feb 20, 2018 at 4:26 AM, Tomasz Figa  wrote:
>
>> It is actually incorrect to have the same device FD used for different
>> screens, if PRIME is used, due to GEM namespace issues, e.g.
>> - screen 0: drmPrimeFdToHandle(buffer A) -> 1,
>> - screen 1: drmPrimeFdToHandle(buffer A) -> 1 (same handle in same
>> namespace, due to semantics of PRIME import and same device FD used),
>> - screen 0: GEM_CLOSE(handle = 1),
>> - screen 1 still thinks handle 1 is valid...
>>
>> So this only works for control nodes using flink only. (Or if you
>> always use libdrm_* for BO management and your particular
>> implementation does its own GEM handle reference counting, but that's
>> not guaranted.)
>>
> Had a sneaky feeling that that != 1 will be returned for screen 1's
> drmPrimeFdToHandle call.
> Regardless, moving to DRI3/dmabuf-only setups is the [really] long
> term plan, I think.
> I don't know if we can achieve it outside of CrOS - with all the
> distros building and shipping things in subtly different manner.

It's already possible for Android.

>>> How would that work if you support different GPUs in one image?
>>
>> It wouldn't and that's why I prefer probing available devices.
>>
>> For Chrome OS, we don't include GPU bits in system image, but rather
>> have vendor images built separately for each board (although sharing
>> any possible contents across board family, chipset, GPU type and so
>> on), so we can have a custom .rc script (which sets a property) as
>> well. It would even be possible to have paths hardcoded, but that
>> would be prone to probe ordering issues which, with software fallback,
>> could be actually not obvious to notice, and so we'd rather not go
>> this route.
>>
>> So I'd agree here that we should revisit probing.
>>
> As you pointed out the fallback is not a good idea.

Software fallback is a desired feature. Basing it on the path is the bad idea.

> Plus, as the drm
> node vary, one can use an Android property and match it to the info.
> from drmGetDevice2.
> Say the HW bus location, (sub)device PCIID, other.

That generally doesn't work for non-x86.

>
> It should also help as one starts shipping devices with multiple GPUs,
> at some point in the future ;-)

Can we solve the simple cases first?

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

Re: [Mesa-dev] [PATCH 01/17] intel: Add a preliminary device for Ice Lake

[Anuj Phogat]

On Wed, Feb 21, 2018 at 11:09 AM, Scott D Phillips
 wrote:
> Anuj Phogat  writes:
>
>> On Wed, Feb 21, 2018 at 10:00 AM, Scott D Phillips
>>  wrote:
>>> Matt Turner  writes:
>>>
 From: Anuj Phogat 

 Signed-off-by: Anuj Phogat 
 ---
  include/pci_ids/i965_pci_ids.h |  9 ++
  src/intel/common/gen_device_info.c | 56 
 +-
  2 files changed, 64 insertions(+), 1 deletion(-)

 diff --git a/include/pci_ids/i965_pci_ids.h 
 b/include/pci_ids/i965_pci_ids.h
 index feb9c582b19..81c9a5f13fb 100644
 --- a/include/pci_ids/i965_pci_ids.h
 +++ b/include/pci_ids/i965_pci_ids.h
 @@ -196,3 +196,12 @@ CHIPSET(0x5A50, cnl_5x8, "Intel(R) HD Graphics 
 (Cannonlake 5x8 GT2)")
  CHIPSET(0x5A51, cnl_5x8, "Intel(R) HD Graphics (Cannonlake 5x8 GT2)")
  CHIPSET(0x5A52, cnl_5x8, "Intel(R) HD Graphics (Cannonlake 5x8 GT2)")
  CHIPSET(0x5A54, cnl_5x8, "Intel(R) HD Graphics (Cannonlake 5x8 GT2)")
 +CHIPSET(0x8A50, icl_8x8, "Intel(R) HD Graphics (Ice Lake 8x8 GT2)")
 +CHIPSET(0x8A51, icl_8x8, "Intel(R) HD Graphics (Ice Lake 8x8 GT2)")
 +CHIPSET(0x8A52, icl_8x8, "Intel(R) HD Graphics (Ice Lake 8x8 GT2)")
 +CHIPSET(0x8A5A, icl_6x8, "Intel(R) HD Graphics (Ice Lake 6x8 GT1.5)")
 +CHIPSET(0x8A5B, icl_4x8, "Intel(R) HD Graphics (Ice Lake 4x8 GT1)")
 +CHIPSET(0x8A5C, icl_6x8, "Intel(R) HD Graphics (Ice Lake 6x8 GT1.5)")
 +CHIPSET(0x8A5D, icl_4x8, "Intel(R) HD Graphics (Ice Lake 4x8 GT1)")
 +CHIPSET(0x8A71, icl_1x8, "Intel(R) HD Graphics (Ice Lake 1x8 GT0.5)")
 +CHIPSET(0xFF05, icl_8x8, "Intel(R) HD Graphics (Ice Lake Simulation)")
>>>
>>> Simulation should be removed.
>>>
 diff --git a/src/intel/common/gen_device_info.c 
 b/src/intel/common/gen_device_info.c
 index a08a13a32a4..8bf4b6b9bb0 100644
 --- a/src/intel/common/gen_device_info.c
 +++ b/src/intel/common/gen_device_info.c
 @@ -731,6 +731,49 @@ static const struct gen_device_info 
 gen_device_info_cnl_5x8 = {
 .is_cannonlake = true,
  };

 +#define GEN11_HW_INFO   \
 +   .gen = 11,   \
 +   .has_pln = false,\
 +   .max_vs_threads = 364,   \
 +   .max_gs_threads = 224,   \
 +   .max_tcs_threads = 224,  \
 +   .max_tes_threads = 364,  \
 +   .max_cs_threads = 56,\
 +   .urb = { \
 +  .size = 1024, \
 +  .min_entries = {  \
 + [MESA_SHADER_VERTEX]= 64,  \
 + [MESA_SHADER_TESS_EVAL] = 34,  \
 +  },\
 +  .max_entries = {  \
 + [MESA_SHADER_VERTEX]= 2384,\
 + [MESA_SHADER_TESS_CTRL] = 1032,\
 + [MESA_SHADER_TESS_EVAL] = 2384,\
 + [MESA_SHADER_GEOMETRY]  = 1032,\
 +  },\
 +   }
 +
 +#define GEN11_FEATURES(_gt, _slices, _l3)   \
 +   GEN8_FEATURES,   \
 +   GEN11_HW_INFO,   \
 +   .gt = _gt, .num_slices = _slices, .l3_banks = _l3
 +
 +static const struct gen_device_info gen_device_info_icl_8x8 = {
 +   GEN11_FEATURES(2, 1, 8),
 +};
 +
 +static const struct gen_device_info gen_device_info_icl_6x8 = {
 +   GEN11_FEATURES(1, 1, 6),
 +};
 +
 +static const struct gen_device_info gen_device_info_icl_4x8 = {
 +   GEN11_FEATURES(1, 1, 6),
>>>
>>> Should be 1, 1, 4 right?
>>>
>>
>> We don't have device attributes listed in the docs for this SKU :(. But,
>> as I have understood number of subslices don't affect the number
>> of banks. L3 banks are part of Slice common. e.g. 1x4x8 and
>> 1x6x8 have the same number of L3 banks.
>
> Right you are, my mistake, the l3_banks look right. What I meant to note
> was that the num_subslices isn't being set by this (the way we do for
> gen10). Shouldn't it be like:
>
right. I missed it because subslices param was added after I originally
created the icl branch.

> #define GEN11_FEATURES(_gt, _slices, _subslices, _l3) \
>GEN8_FEATURES, \
>GEN11_HW_INFO, \
>.gt = _gt, .num_slices = _slices, .l3_banks = _l3, \
>.num_subslices = _subslices
>
> static const struct gen_device_info gen_device_info_icl_8x8 = {
>GEN11_FEATURES(2, 1, subslices(8), 8),
> };
>
> 

Re: [Mesa-dev] [PATCH v2 2/2] radv: implement AMD_gcn_shader extension

[Bas Nieuwenhuizen]

Please split this up into 4 patches: 1 for the core nir part, 1 for
the spirv part, 1 for the ac part and finally 1 for the radv.

On Wed, Feb 21, 2018 at 7:00 PM,   wrote:
> From: Dave Airlie 
>
> Co-authored-by: Daniel Schürmann 
> Signed-off-by: Daniel Schürmann 
> ---
>  src/amd/common/ac_llvm_build.c|  3 +-
>  src/amd/common/ac_nir_to_llvm.c   | 39 ++
>  src/amd/vulkan/radv_extensions.py |  1 +
>  src/compiler/nir/meson.build  |  1 +
>  src/compiler/nir/nir_intrinsics.h |  4 +++
>  src/compiler/spirv/spirv_to_nir.c |  2 ++
>  src/compiler/spirv/vtn_amd.c  | 68 
> +++
>  src/compiler/spirv/vtn_private.h  |  3 ++
>  8 files changed, 120 insertions(+), 1 deletion(-)
>  create mode 100644 src/compiler/spirv/vtn_amd.c
>
> diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c
> index 15144addb9..3bb74c2b0b 100644
> --- a/src/amd/common/ac_llvm_build.c
> +++ b/src/amd/common/ac_llvm_build.c
> @@ -370,7 +370,8 @@ LLVMValueRef
>  ac_build_shader_clock(struct ac_llvm_context *ctx)
>  {
> LLVMValueRef tmp = ac_build_intrinsic(ctx, "llvm.readcyclecounter",
> - ctx->i64, NULL, 0, 0);
> + ctx->i64, NULL, 0, AC_FUNC_ATTR_READONLY);
> +   ac_build_optimization_barrier(ctx, );
> return LLVMBuildBitCast(ctx->builder, tmp, ctx->v2i32, "");
>  }
>
> diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
> index 2460e105f7..05f28b26a2 100644
> --- a/src/amd/common/ac_nir_to_llvm.c
> +++ b/src/amd/common/ac_nir_to_llvm.c
> @@ -4328,6 +4328,38 @@ load_patch_vertices_in(struct ac_shader_abi *abi)
> return LLVMConstInt(ctx->ac.i32, 
> ctx->options->key.tcs.input_vertices, false);
>  }
>
> +static LLVMValueRef
> +visit_cube_face_index(struct ac_nir_context *ctx,
> + nir_intrinsic_instr *instr)
> +{
> +   LLVMValueRef result;
> +   LLVMValueRef in[3];
> +   LLVMValueRef src0 = ac_to_float(>ac, get_src(ctx, 
> instr->src[0]));
> +   for (unsigned chan = 0; chan < 3; chan++)
> +   in[chan] = ac_llvm_extract_elem(>ac, src0, chan);
> +
> +   result = ac_build_intrinsic(>ac,  "llvm.amdgcn.cubeid",
> +   ctx->ac.f32, in, 3, 
> AC_FUNC_ATTR_READNONE);
> +   return result;
> +}
> +
> +static LLVMValueRef
> +visit_cube_face_coord(struct ac_nir_context *ctx,
> + nir_intrinsic_instr *instr)
> +{
> +   LLVMValueRef results[2];
> +   LLVMValueRef in[3];
> +   LLVMValueRef src0 = ac_to_float(>ac, get_src(ctx, 
> instr->src[0]));
> +   for (unsigned chan = 0; chan < 3; chan++)
> +   in[chan] = ac_llvm_extract_elem(>ac, src0, chan);
> +
> +   results[0] = ac_build_intrinsic(>ac, "llvm.amdgcn.cubetc",
> +   ctx->ac.f32, in, 3, 
> AC_FUNC_ATTR_READNONE);
> +   results[1] = ac_build_intrinsic(>ac, "llvm.amdgcn.cubesc",
> +   ctx->ac.f32, in, 3, 
> AC_FUNC_ATTR_READNONE);
> +   return ac_build_gather_values(>ac, results, 2);
> +}
> +
>  static void visit_intrinsic(struct ac_nir_context *ctx,
>  nir_intrinsic_instr *instr)
>  {
> @@ -4613,6 +4645,13 @@ static void visit_intrinsic(struct ac_nir_context *ctx,
> result = LLVMBuildSExt(ctx->ac.builder, tmp, ctx->ac.i32, "");
> break;
> }
> +   case nir_intrinsic_cube_face_index:
> +   result = visit_cube_face_index(ctx, instr);
> +   break;
> +   case nir_intrinsic_cube_face_coord:
> +   result = visit_cube_face_coord(ctx, instr);
> +   break;
> +
> default:
> fprintf(stderr, "Unknown intrinsic: ");
> nir_print_instr(>instr, stderr);
> diff --git a/src/amd/vulkan/radv_extensions.py 
> b/src/amd/vulkan/radv_extensions.py
> index d761895d3a..a63e01faae 100644
> --- a/src/amd/vulkan/radv_extensions.py
> +++ b/src/amd/vulkan/radv_extensions.py
> @@ -88,6 +88,7 @@ EXTENSIONS = [
>  Extension('VK_EXT_external_memory_host',  1, 
> 'device->rad_info.has_userptr'),
>  Extension('VK_EXT_global_priority',   1, 
> 'device->rad_info.has_ctx_priority'),
>  Extension('VK_AMD_draw_indirect_count',   1, True),
> +Extension('VK_AMD_gcn_shader',1, True),

What LLVM version were these intrinsics introduced?

>  Extension('VK_AMD_rasterization_order',   1, 
> 'device->rad_info.chip_class >= VI && device->rad_info.max_se >= 2'),
>  Extension('VK_AMD_shader_info',   1, True),
>  ]
> diff --git a/src/compiler/nir/meson.build b/src/compiler/nir/meson.build
> index 

Re: [Mesa-dev] Allocator Nouveau driver, Mesa EXT_external_objects, and DRM metadata import interfaces

[Daniel Vetter]

On Tue, Feb 20, 2018 at 10:14:47PM -0800, Chad Versace wrote:
> On Thu 21 Dec 2017, Daniel Vetter wrote:
> > On Thu, Dec 21, 2017 at 12:22 AM, Kristian Kristensen 
> >  wrote:
> >> On Wed, Dec 20, 2017 at 12:41 PM, Miguel Angel Vico  
> >> wrote:
> >>> On Wed, 20 Dec 2017 11:54:10 -0800 Kristian Høgsberg 
> >>>  wrote:
>  I'd like to see concrete examples of actual display controllers
>  supporting more format layouts than what can be specified with a 64
>  bit modifier.
> >>>
> >>> The main problem is our tiling and other metadata parameters can't
> >>> generally fit in a modifier, so we find passing a blob of metadata a
> >>> more suitable mechanism.
> >>
> >> I understand that you may have n knobs with a total of more than a total of
> >> 56 bits that configure your tiling/swizzling for color buffers. What I 
> >> don't
> >> buy is that you need all those combinations when passing buffers around
> >> between codecs, cameras and display controllers. Even if you're sharing
> >> between the same 3D drivers in different processes, I expect just locking
> >> down, say, 64 different combinations (you can add more over time) and
> >> assigning each a modifier would be sufficient. I doubt you'd extract
> >> meaningful performance gains from going all the way to a blob.
> 
> I agree with Kristian above. In my opinion, choosing to encode in
> modifiers a precise description of every possible tiling/compression
> layout is not technically incorrect, but I believe it misses the point.
> The intention behind modifiers is not to exhaustively describe all
> possibilites.
> 
> I summarized this opinion in VK_EXT_image_drm_format_modifier,
> where I wrote an "introdution to modifiers" section. Here's an excerpt:
> 
> One goal of modifiers in the Linux ecosystem is to enumerate for each
> vendor a reasonably sized set of tiling formats that are appropriate for
> images shared across processes, APIs, and/or devices, where each
> participating component may possibly be from different vendors.
> A non-goal is to enumerate all tiling formats supported by all vendors.
> Some tiling formats used internally by vendors are inappropriate for
> sharing; no modifiers should be assigned to such tiling formats.

fwiw (since the source of truth wrt modifiers is the kernel's uapi
header):

Acked-by: Daniel Vetter 

I'm happy to merge modifier #define additions for pretty much anything
where there's a need for sharing across devices/drivers/apis, explicitly
including stuff that's only relevant for userspace and which the kernel
nevers sees (in e.g. a kms addfb2 call). Trying to preemptively enumerate
everything that's possible doesn't seem like a wise idea. But even then we
can probably spare the oddball vendor prefix is a driver team really
insists that this is what they want, best using some code that makes the
case for them.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] glx: Properly handle cases where screen creation fails

[Chuck Atkins]

Hi George,

This first showed up on one of our older dashboard machines without AVX
(Nehalem processor).   You can easily reproduce it by building with
--with-swr-archs=knl,skx when the machine you're trying to use it on is
neither.  Note that dri-glx seems to handle this case just fine but
xlib-glx segfaults.

- Chuck


On Wed, Feb 21, 2018 at 12:36 PM, Kyriazis, George <
george.kyria...@intel.com> wrote:

> Chuck,
>
> In which cases do you hit this?  When an architecture is not supported,
> then swr_create_screen() falls back to a different (older) architecture.
>
> Thanks,
>
> George
>
> > On Feb 21, 2018, at 8:26 AM, Chuck Atkins 
> wrote:
> >
> > This fixes a segfault exposed by a29d63ecf7 which occurs when swr is
> > used on an unsupported architecture.
> >
> > Signed-off-by: Chuck Atkins 
> > Cc: mesa-sta...@lists.freedesktop.org
> > Cc: George Kyriazis 
> > Cc: Bruce Cherniak 
> > ---
> > src/gallium/state_trackers/glx/xlib/xm_api.c | 11 +++
> > 1 file changed, 7 insertions(+), 4 deletions(-)
> >
> > diff --git a/src/gallium/state_trackers/glx/xlib/xm_api.c
> b/src/gallium/state_trackers/glx/xlib/xm_api.c
> > index 934c0aba11..3aec57e85d 100644
> > --- a/src/gallium/state_trackers/glx/xlib/xm_api.c
> > +++ b/src/gallium/state_trackers/glx/xlib/xm_api.c
> > @@ -182,9 +182,12 @@ xmesa_close_display(Display *display)
> > * }
> > */
> >
> > -   if (xmdpy->smapi->destroy)
> > -  xmdpy->smapi->destroy(xmdpy->smapi);
> > -   free(xmdpy->smapi);
> > +   if (xmdpy->smapi)
> > +   {
> > +  if (xmdpy->smapi->destroy)
> > + xmdpy->smapi->destroy(xmdpy->smapi);
> > +  free(xmdpy->smapi);
> > +   }
> >
> >XFree((char *) info);
> > }
> > @@ -767,7 +770,7 @@ XMesaVisual XMesaCreateVisual( Display *display,
> >XMesaVisual v;
> >GLint red_bits, green_bits, blue_bits, alpha_bits;
> >
> > -   if (!xmdpy)
> > +   if (!xmdpy || !xmdpy->screen)
> >   return NULL;
> >
> >/* For debugging only */
> > --
> > 2.14.3
> >
> > ___
> > 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] glx: Properly handle cases where screen creation fails

[Kyriazis, George]

I believed I created the same failure by deleting libswr*.so, however in my 
case (running glxgears) I hit a SEGV in XMesaCreateVisual (calling 
xmdpy->screen->is_format_supported()), because xmesa_init_display() created an 
xmdpy with a NULL screen.  I never get to the xmesa_close_display().

Were you just testing with vtk, and maybe hitting a localized issue?  Looks 
like the failure needs to be taken care of when the screen is initialized the 
first time.

George

On Feb 21, 2018, at 12:13 PM, Chuck Atkins 
> wrote:

Hi George,

This first showed up on one of our older dashboard machines without AVX 
(Nehalem processor).   You can easily reproduce it by building with 
--with-swr-archs=knl,skx when the machine you're trying to use it on is 
neither.  Note that dri-glx seems to handle this case just fine but xlib-glx 
segfaults.

- Chuck


On Wed, Feb 21, 2018 at 12:36 PM, Kyriazis, George 
> wrote:
Chuck,

In which cases do you hit this?  When an architecture is not supported, then 
swr_create_screen() falls back to a different (older) architecture.

Thanks,

George

> On Feb 21, 2018, at 8:26 AM, Chuck Atkins 
> > wrote:
>
> This fixes a segfault exposed by a29d63ecf7 which occurs when swr is
> used on an unsupported architecture.
>
> Signed-off-by: Chuck Atkins 
> >
> Cc: 
> mesa-sta...@lists.freedesktop.org
> Cc: George Kyriazis 
> >
> Cc: Bruce Cherniak >
> ---
> src/gallium/state_trackers/glx/xlib/xm_api.c | 11 +++
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/src/gallium/state_trackers/glx/xlib/xm_api.c 
> b/src/gallium/state_trackers/glx/xlib/xm_api.c
> index 934c0aba11..3aec57e85d 100644
> --- a/src/gallium/state_trackers/glx/xlib/xm_api.c
> +++ b/src/gallium/state_trackers/glx/xlib/xm_api.c
> @@ -182,9 +182,12 @@ xmesa_close_display(Display *display)
> * }
> */
>
> -   if (xmdpy->smapi->destroy)
> -  xmdpy->smapi->destroy(xmdpy->smapi);
> -   free(xmdpy->smapi);
> +   if (xmdpy->smapi)
> +   {
> +  if (xmdpy->smapi->destroy)
> + xmdpy->smapi->destroy(xmdpy->smapi);
> +  free(xmdpy->smapi);
> +   }
>
>XFree((char *) info);
> }
> @@ -767,7 +770,7 @@ XMesaVisual XMesaCreateVisual( Display *display,
>XMesaVisual v;
>GLint red_bits, green_bits, blue_bits, alpha_bits;
>
> -   if (!xmdpy)
> +   if (!xmdpy || !xmdpy->screen)
>   return NULL;
>
>/* For debugging only */
> --
> 2.14.3
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev


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

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

[Mesa-dev] [Bug 105161] Validation of KHR_blend_equation_advanced stricter than NVidia

[bugzilla-daemon]

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

--- Comment #6 from Allan Sandfeld Jensen  ---
Right. I think NVidia can get away with it because this requirement is new in
the KHR version, they also implement the original NV version which doesnt have
it (and like is OpenGL norm, they share the same GL defines).

Anyway since you are actually using the declaration and it has significant
impact in compile time of the shader, I withdraw my complaint and suggestion.

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

[Mesa-dev] [PATCH 2/2] glxinfo/wglinfo: print list of 4.3 shading language versions

[Brian Paul]

v2: fix indentation, prefix with "4.3:" like other sections.
---
 src/xdemos/glinfo_common.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/src/xdemos/glinfo_common.c b/src/xdemos/glinfo_common.c
index efa96e6..3668026 100644
--- a/src/xdemos/glinfo_common.c
+++ b/src/xdemos/glinfo_common.c
@@ -795,6 +795,20 @@ print_limits(const char *extensions, const char 
*oglstring, int version,
   }
   free(formats);
}
+
+#if defined(GL_VERSION_4_3)
+   if (version >= 43) {
+  GLint i, n = 0;
+  printf("  4.3:\n");
+  glGetIntegerv(GL_NUM_SHADING_LANGUAGE_VERSIONS, );
+  printf("GL_NUM_SHADING_LANGUAGE_VERSIONS = %d\n", n);
+  for (i = 0; i < n; i++) {
+ printf("  %s\n", (const char *)
+extfuncs->GetStringi(GL_SHADING_LANGUAGE_VERSION, i));
+  }
+   }
+#endif
+
 #if defined(GL_ARB_vertex_program)
if (extension_supported("GL_ARB_vertex_program", extensions)) {
   print_program_limits(GL_VERTEX_PROGRAM_ARB, extfuncs);
-- 
2.7.4

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