Re: [Mesa-dev] [PATCH] ac: fix build error in si_shader

[Timothy Arceri]

Pushed. Thanks!

On 13/01/18 01:47, Mauro Rossi wrote:

assert() is replaced by unreachable(), to avoid following building error:

external/mesa/src/gallium/drivers/radeonsi/si_shader.c:1967:1:
error: control may reach end of non-void function [-Werror,-Wreturn-type]
}
^
1 error generated.

Fixes: c797cd6 ("ac: add load_patch_vertices_in() to the abi")
---
  src/gallium/drivers/radeonsi/si_shader.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/radeonsi/si_shader.c 
b/src/gallium/drivers/radeonsi/si_shader.c
index dd635ae203..8439d09ffc 100644
--- a/src/gallium/drivers/radeonsi/si_shader.c
+++ b/src/gallium/drivers/radeonsi/si_shader.c
@@ -1963,7 +1963,7 @@ static LLVMValueRef si_load_patch_vertices_in(struct 
ac_shader_abi *abi)
else if (ctx->type == PIPE_SHADER_TESS_EVAL)
return get_num_tcs_out_vertices(ctx);
else
-   assert(!"invalid shader stage for TGSI_SEMANTIC_VERTICESIN");
+   unreachable(!"invalid shader stage for 
TGSI_SEMANTIC_VERTICESIN");
  }
  
  void si_load_system_value(struct si_shader_context *ctx,



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

[Mesa-dev] [Bug 104214] Dota crashes when switching from game to desktop

[bugzilla-daemon]

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

robsmit...@yandex.com changed:

   What|Removed |Added

 CC||robsmit...@yandex.com

--- Comment #52 from robsmit...@yandex.com ---
*** Bug 104583 has been marked as a duplicate of this bug. ***

-- 
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 06/29] anv/image: Add a helper for determining when fast clears are supported

[Jason Ekstrand]

I made a table to help visualize all the different cases:

Layout  | compression | zero clear | non-zero clear
+=++
GENERAL |  N  |  N |   N
+-++
COLOR_ATTACHMENT|  Y  |  Y |   Y
+-++
SHADER_READ_ONLY|  Y  |  Y |   N
+-++
GENERAL (RT/tex/blit only)  |  Y  |  Y |   N
+-++
PRESENT_SRC (Y_TILED)   |  N  |  N |   N
+-++
PRESENT_SRC (Y_TILED_CCS)   |  Y  |  N |   N
+-++

We will need to think about what to do with this.  Having non-zero clears
be different from zero clears is tricky.  We may need to have even more
bits in our aux tracking. :-/

On January 12, 2018 16:05:12 Jason Ekstrand  wrote:

> On Wed, Dec 13, 2017 at 11:26 AM, Nanley Chery 
> wrote:
>
>> On Mon, Nov 27, 2017 at 07:05:56PM -0800, Jason Ekstrand wrote:
>> > ---
>> >  src/intel/vulkan/anv_image.c   | 58 ++
>> 
>> >  src/intel/vulkan/anv_private.h |  5 
>> >  2 files changed, 63 insertions(+)
>> >
>> > diff --git a/src/intel/vulkan/anv_image.c b/src/intel/vulkan/anv_image..
>> c
>> > index a872149..561da28 100644
>> > --- a/src/intel/vulkan/anv_image.c
>> > +++ b/src/intel/vulkan/anv_image.c
>> > @@ -837,6 +837,64 @@ anv_layout_to_aux_usage(const struct
>> gen_device_info * const devinfo,
>> > unreachable("layout is not a VkImageLayout enumeration member.");
>> >  }
>> >
>> > +/**
>> > + * This function returns true if the given image in the given
>> VkImageLayout
>> > + * supports unresolved fast-clears.
>> > + *
>> > + * @param devinfo The device information of the Intel GPU.
>> > + * @param image The image that may contain a collection of buffers.
>> > + * @param aspect The aspect of the image to be accessed.
>> > + * @param layout The current layout of the image aspect(s).
>> > + */
>> > +bool
>> > +anv_layout_supports_fast_clear(const struct gen_device_info * const
>> devinfo,
>> > +   const struct anv_image * const image,
>> > +   const VkImageAspectFlagBits aspect,
>> > +   const VkImageLayout layout)
>> > +{
>> > +   /* The aspect must be exactly one of the image aspects. */
>> > +   assert(_mesa_bitcount(aspect) == 1 && (aspect & image->aspects));
>> > +
>> > +   uint32_t plane = anv_image_aspect_to_plane(image->aspects, aspect);
>> > +
>> > +   /* If there is no auxiliary surface allocated, there are no
>> fast-clears */
>> > +   if (image->planes[plane].aux_surface.isl.size == 0)
>> > +  return false;
>> > +
>> > +   /* All images that use an auxiliary surface are required to be
>> tiled. */
>> > +   assert(image->tiling == VK_IMAGE_TILING_OPTIMAL);
>> > +
>> > +   /* Stencil has no aux */
>> > +   assert(aspect != VK_IMAGE_ASPECT_STENCIL_BIT);
>> > +
>> > +   if (aspect == VK_IMAGE_ASPECT_DEPTH_BIT) {
>> > +  /* For depth images (with HiZ), the layout supports fast-clears
>> if and
>> > +   * only if it supports HiZ.
>> > +   */
>> > +  enum isl_aux_usage aux_usage =
>> > + anv_layout_to_aux_usage(devinfo, image, aspect, layout);
>> > +  return aux_usage == ISL_AUX_USAGE_HIZ;
>> > +   }
>> > +
>> > +   assert(image->aspects & VK_IMAGE_ASPECT_ANY_COLOR_BIT_ANV);
>> > +
>> > +   /* Multisample fast-clear is not yet supported. */
>> > +   if (image->samples > 1)
>> > +  return false;
>> > +
>> > +   /* The only layout which actually supports fast-clears today is
>> > +* VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL.  Some day in the
>> future
>> > +* this may change if our ability to track clear colors improves.
>> > +*/
>> > +   switch (layout) {
>> > +   case VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL:
>> > +  return true;
>> > +
>>
>> This is kind of tricky. We actually allow fast-clears for CCS_E textures
>> in the GENERAL layout if the clear color is all zeros. When this
>> happens, we set the needs_resolve predicate to false. This means that
>> unresolved fast-clears is potentially in use for CCS_E images in any
>> layout.
>>
>
> Hrm...  This is going to get interesting.  This works but only if we
> assume that the thing using it in the general layout is rendering or
> texturing.  If it's storage, this doesn't work.  That said, storage images
> are CCS_D-only so that's not a problem now.  The bigger problem is that
> this means the resolve won't happen for 

[Mesa-dev] [Bug 104214] Dota crashes when switching from game to desktop

[bugzilla-daemon]

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

--- Comment #51 from Jason Ekstrand  ---
Can we write a piglit test or two that reproduces this bug?  It would be very
good if had a nice self-contained test that we can run in CI and avoid these
types of issues in the future.

-- 
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 09/29] anv/cmd_buffer: Generalize transition_color_buffer

[Jason Ekstrand]

On Wed, Dec 13, 2017 at 11:00 AM, Nanley Chery 
wrote:

> On Mon, Nov 27, 2017 at 07:05:59PM -0800, Jason Ekstrand wrote:
> > This moves it to being based on layout_to_aux_usage instead of being
> > hard-coded based on bits of a priori knowledge of how transitions
> > interact with layouts.  This conceptually simplifies things because
> > we're now using layout_to_aux_usage and layout_supports_fast_clear to
> > make resolve decisions so changes to those functions will do what one
> > expects.
> >
> > This fixes a potential bug with window system integration on gen9+ where
> > we wouldn't do a resolve when transitioning to the PRESENT_SRC layout
> > because we just assume that everything that handles CCS_E can handle it
> > all the time.  When handing a CCS_E image off to the window system, we
> > may need to do a full resolve if the window system does not support the
> > CCS_E modifier.  The only reason why this hasn't been a problem yet is
> > because we don't support modifiers in Vulkan WSI and so we always get X
> > tiling which implies no CCS on gen9+.
> > ---
> >  src/intel/vulkan/genX_cmd_buffer.c | 53 +-
> 
> >  1 file changed, 41 insertions(+), 12 deletions(-)
> >
> > diff --git a/src/intel/vulkan/genX_cmd_buffer.c
> b/src/intel/vulkan/genX_cmd_buffer.c
> > index be717eb..65cc85d 100644
> > --- a/src/intel/vulkan/genX_cmd_buffer.c
> > +++ b/src/intel/vulkan/genX_cmd_buffer.c
> > @@ -593,6 +593,7 @@ transition_color_buffer(struct anv_cmd_buffer
> *cmd_buffer,
> >  VkImageLayout initial_layout,
> >  VkImageLayout final_layout)
> >  {
> > +   const struct gen_device_info *devinfo = _buffer->device->info;
> > /* Validate the inputs. */
> > assert(cmd_buffer);
> > assert(image && image->aspects & VK_IMAGE_ASPECT_ANY_COLOR_BIT_ANV);
> > @@ -733,17 +734,48 @@ transition_color_buffer(struct anv_cmd_buffer
> *cmd_buffer,
> >   VK_IMAGE_LAYOUT_COLOR_
> ATTACHMENT_OPTIMAL,
> >   final_layout);
> >}
> > -   } else if (initial_layout != VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL)
> {
> > -  /* Resolves are only necessary if the subresource may contain
> blocks
> > -   * fast-cleared to values unsupported in other layouts. This only
> occurs
> > -   * if the initial layout is COLOR_ATTACHMENT_OPTIMAL.
> > -   */
> > -  return;
> > -   } else if (image->samples > 1) {
> > -  /* MCS buffers don't need resolving. */
> >return;
> > }
> >
> > +   /* If initial aux usage is NONE, there is nothing to resolve */
> > +   enum isl_aux_usage initial_aux_usage =
> > +  anv_layout_to_aux_usage(devinfo, image, aspect, initial_layout);
> > +   if (initial_aux_usage == ISL_AUX_USAGE_NONE)
> > +  return;
> > +
> > +   enum isl_aux_op resolve_op = ISL_AUX_OP_NONE;
> > +
> > +   /* If the initial layout supports fast clear but the final one does
> not,
> > +* then we need at least a partial resolve.
> > +*/
> > +   if (anv_layout_supports_fast_clear(devinfo, image, aspect,
> initial_layout) &&
> > +   !anv_layout_supports_fast_clear(devinfo, image, aspect,
> final_layout))
> > +  resolve_op = ISL_AUX_OP_PARTIAL_RESOLVE;
>
> I find this hunk more readable, when resolve_op is modified less. How
> about the following?
>   if (anv_layout_supports_fast_clear(devinfo, image, aspect,
> initial_layout) &&
>   !anv_layout_supports_fast_clear(devinfo, image, aspect,
> final_layout)) {
>  /* CCS_D only supports full resolves and BLORP will assert on
>   * us if we try to do a partial resolve on a CCS_D surface.
>   */
>  if (initial_aux_usage == ISL_AUX_USAGE_CCS_D) {
> resolve_op = ISL_AUX_OP_FULL_RESOLVE;
>  } else {
> resolve_op = ISL_AUX_OP_PARTIAL_RESOLVE;
>  }
>   }
>
> It may even be more readable to have most of these changes in a function
> called something like color_transition_to_aux_op(). We shouldn't even
> need a resolve_op variable in that case. Just a thought.
>

That only handles two of the three cases, unfortunately.  I completely
agree with you that an if-ladder tends to be easier to read than iterative
assignment but it's tricky to get this one right.  Maybe something like
this:

if (initial_aux_usage == ISL_AUX_USAGE_CCS_E &&
final_aux_usage != ISL_AUX_USAGE_CCS_E) {
   resolve_op = ISL_AUX_OP_FULL_RESOLVE;
} else if (anv_layout_supports_fast_clear(devinfo, image, aspect,
initial_layout) &&
   !anv_layout_supports_fast_clear(devinfo, image, aspect,
final_layout)) {
   if (initial_aux_usage == ISL_AUX_USAGE_CCS_D) {
  resolve_op = ISL_AUX_OP_FULL_RESOLVE;
   } else {
  resolve_op = ISL_AUX_OP_PARTIAL_RESOLVE;
   }
} else {
   resolve_op = ISL_AUX_OP_NONE;
}

Though even that's confusing because it's weird that we can get into the
second case with CCS_E.  If I were 

Re: [Mesa-dev] [PATCH 08/29] anv/cmd_buffer: Recurse in transition_color_buffer instead of falling through

[Jason Ekstrand]

On Mon, Dec 11, 2017 at 3:57 PM, Nanley Chery  wrote:

> On Mon, Nov 27, 2017 at 07:05:58PM -0800, Jason Ekstrand wrote:
> > ---
> >  src/intel/vulkan/genX_cmd_buffer.c | 17 -
> >  1 file changed, 8 insertions(+), 9 deletions(-)
> >
> > diff --git a/src/intel/vulkan/genX_cmd_buffer.c
> b/src/intel/vulkan/genX_cmd_buffer.c
> > index 0c1ae83..be717eb 100644
> > --- a/src/intel/vulkan/genX_cmd_buffer.c
> > +++ b/src/intel/vulkan/genX_cmd_buffer.c
> > @@ -719,20 +719,19 @@ transition_color_buffer(struct anv_cmd_buffer
> *cmd_buffer,
> >if (image->samples == 1 &&
> >image->planes[plane].aux_usage != ISL_AUX_USAGE_CCS_E &&
> >final_layout != VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL) {
> > - /* The CCS_D buffer may not be enabled in the final layout.
> Continue
> > -  * executing this function to perform a resolve.
> > + /* The CCS_D buffer may not be enabled in the final layout.
> Call this
> > +  * function again with a initial layout of
> COLOR_ATTACHMENT_OPTIMAL
> > +  * to perform a resolve.
> >*/
> >anv_perf_warn(cmd_buffer->device->instance, image,
> >  "Performing an additional resolve for CCS_D
> layout "
> >  "transition. Consider always leaving it on or "
> >  "performing an ambiguation pass.");
> > -  } else {
> > - /* Writes in the final layout will be aware of the auxiliary
> buffer.
> > -  * In addition, the clear buffer entries and the auxiliary
> buffers
> > -  * have been populated with values that will result in correct
> > -  * rendering.
> > -  */
> > - return;
>
> By deleting this else, we have to build the command buffer for a no-op
> resolve if the image has a CCS_E buffer. Perhaps this would fit better
> in the next patch?
>

As per Topi's comment, this is supposed to be

if (...) {
   anv_perf_warn()
   transition_color_buffer()
}
return;

I've fixed it locally.


> -Nanley
>
> > + transition_color_buffer(cmd_buffer, image, aspect,
> > + base_level, level_count,
> > + base_layer, layer_count,
> > + VK_IMAGE_LAYOUT_COLOR_
> ATTACHMENT_OPTIMAL,
> > + final_layout);
> >}
> > } else if (initial_layout != VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL)
> {
> >/* Resolves are only necessary if the subresource may contain
> blocks
> > --
> > 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 06/29] anv/image: Add a helper for determining when fast clears are supported

[Jason Ekstrand]

On Wed, Dec 13, 2017 at 11:26 AM, Nanley Chery 
wrote:

> On Mon, Nov 27, 2017 at 07:05:56PM -0800, Jason Ekstrand wrote:
> > ---
> >  src/intel/vulkan/anv_image.c   | 58 ++
> 
> >  src/intel/vulkan/anv_private.h |  5 
> >  2 files changed, 63 insertions(+)
> >
> > diff --git a/src/intel/vulkan/anv_image.c b/src/intel/vulkan/anv_image.c
> > index a872149..561da28 100644
> > --- a/src/intel/vulkan/anv_image.c
> > +++ b/src/intel/vulkan/anv_image.c
> > @@ -837,6 +837,64 @@ anv_layout_to_aux_usage(const struct
> gen_device_info * const devinfo,
> > unreachable("layout is not a VkImageLayout enumeration member.");
> >  }
> >
> > +/**
> > + * This function returns true if the given image in the given
> VkImageLayout
> > + * supports unresolved fast-clears.
> > + *
> > + * @param devinfo The device information of the Intel GPU.
> > + * @param image The image that may contain a collection of buffers.
> > + * @param aspect The aspect of the image to be accessed.
> > + * @param layout The current layout of the image aspect(s).
> > + */
> > +bool
> > +anv_layout_supports_fast_clear(const struct gen_device_info * const
> devinfo,
> > +   const struct anv_image * const image,
> > +   const VkImageAspectFlagBits aspect,
> > +   const VkImageLayout layout)
> > +{
> > +   /* The aspect must be exactly one of the image aspects. */
> > +   assert(_mesa_bitcount(aspect) == 1 && (aspect & image->aspects));
> > +
> > +   uint32_t plane = anv_image_aspect_to_plane(image->aspects, aspect);
> > +
> > +   /* If there is no auxiliary surface allocated, there are no
> fast-clears */
> > +   if (image->planes[plane].aux_surface.isl.size == 0)
> > +  return false;
> > +
> > +   /* All images that use an auxiliary surface are required to be
> tiled. */
> > +   assert(image->tiling == VK_IMAGE_TILING_OPTIMAL);
> > +
> > +   /* Stencil has no aux */
> > +   assert(aspect != VK_IMAGE_ASPECT_STENCIL_BIT);
> > +
> > +   if (aspect == VK_IMAGE_ASPECT_DEPTH_BIT) {
> > +  /* For depth images (with HiZ), the layout supports fast-clears
> if and
> > +   * only if it supports HiZ.
> > +   */
> > +  enum isl_aux_usage aux_usage =
> > + anv_layout_to_aux_usage(devinfo, image, aspect, layout);
> > +  return aux_usage == ISL_AUX_USAGE_HIZ;
> > +   }
> > +
> > +   assert(image->aspects & VK_IMAGE_ASPECT_ANY_COLOR_BIT_ANV);
> > +
> > +   /* Multisample fast-clear is not yet supported. */
> > +   if (image->samples > 1)
> > +  return false;
> > +
> > +   /* The only layout which actually supports fast-clears today is
> > +* VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL.  Some day in the future
> > +* this may change if our ability to track clear colors improves.
> > +*/
> > +   switch (layout) {
> > +   case VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL:
> > +  return true;
> > +
>
> This is kind of tricky. We actually allow fast-clears for CCS_E textures
> in the GENERAL layout if the clear color is all zeros. When this
> happens, we set the needs_resolve predicate to false. This means that
> unresolved fast-clears is potentially in use for CCS_E images in any
> layout.
>

Hrm...  This is going to get interesting.  This works but only if we assume
that the thing using it in the general layout is rendering or texturing.
If it's storage, this doesn't work.  That said, storage images are
CCS_D-only so that's not a problem now.  The bigger problem is that this
means the resolve won't happen for window-system images and that's bad.
I'm not sure what the right path forward is; I'll have to think on it.

Do we have any benchmark numbers to justify this clever trick?


> -Nanley
>
> > +   default:
> > +  return false;
> > +   }
> > +}
> > +
> >
> >  static struct anv_state
> >  alloc_surface_state(struct anv_device *device)
> > diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_
> private.h
> > index 5dd95a3..461bfed 100644
> > --- a/src/intel/vulkan/anv_private.h
> > +++ b/src/intel/vulkan/anv_private.h
> > @@ -2559,6 +2559,11 @@ anv_layout_to_aux_usage(const struct
> gen_device_info * const devinfo,
> >  const struct anv_image *image,
> >  const VkImageAspectFlagBits aspect,
> >  const VkImageLayout layout);
> > +bool
> > +anv_layout_supports_fast_clear(const struct gen_device_info * const
> devinfo,
> > +   const struct anv_image * const image,
> > +   const VkImageAspectFlagBits aspect,
> > +   const VkImageLayout layout);
> >
> >  /* This is defined as a macro so that it works for both
> >   * VkImageSubresourceRange and VkImageSubresourceLayers
> > --
> > 2.5.0.400.gff86faf
> >
> > ___
> > mesa-dev mailing list
> > 

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

[Gurchetan Singh]

>
> We can define accessor functions too (not ptrs), then the struct is opaque
> and you can do your own accessor implementation if aligning is not possible
> or desired.
>

Accessor functions in libdrm sound good to me.

On Fri, Jan 12, 2018 at 11:44 AM, Rob Herring  wrote:

> On Fri, Jan 12, 2018 at 2:29 AM, Tomasz Figa  wrote:
> > Hi Rob,
> >
> > On Fri, Jan 12, 2018 at 5:26 AM, Robert Foss 
> wrote:
> >> Heya,
> >>
> >>
> >> On 12/22/17 1:09 PM, Tomasz Figa wrote:
> >>>
> >>> On Fri, Dec 22, 2017 at 10:09 AM, Gurchetan Singh
> >>>  wrote:
> 
>  So the plan is for alloc_handle_t to not be sub-classed by the
>  implementations, but have all necessary information that an
>  implementation
>  would need?
> 
>  If so, how do we reconcile the implementation specific information
> that
>  is
>  often in the handle:
> 
> 
>  https://github.com/intel/minigbm/blob/master/cros_
> gralloc/cros_gralloc_handle.h
>  [consumer_usage, producer_usage, yuv_color_range, is_updated etc.]
> 
> 
>  https://chromium.googlesource.com/chromiumos/platform/
> minigbm/+/master/cros_gralloc/cros_gralloc_handle.h
>  [use_flags, pixel_stride]
> 
>  In our case, removing our minigbm specific use flags from the handle
>  would
>  add complexity to our (*registerBuffer) path.
> 
>  On Thu, Dec 21, 2017 at 10:14 AM, Rob Herring 
> wrote:
> >
> >
> > On Wed, Dec 13, 2017 at 5:02 PM, Gurchetan Singh
> >  wrote:
> >>
> >> Hi Robert,
> >>
> >> Thanks for looking into this!  We need to decide if we want:
> >>
> >> (1) A common struct that implementations can subclass, i.e:
> >>
> >> struct blah_gralloc_handle {
> >>  alloc_handle_t alloc_handle;
> >>  int x, y, z;
> >>  
> >> }
> >>
> >> (2) An accessor library that vendors can implement, i.e:
> >>
> >> struct drmAndroidHandleInfo {
> >> uint32_t (*get_fourcc)(buffer_handle_t handle);
> >> uint32_t (*get_stride)(buffer_handle_t handle, uint32_t plane);
> >> uint32_t (*get_offsets)(buffer_handle_t handle, uint32_t plane);
> >> uint64_t (*get_modifier)(buffer_handle_t handle);
> >> };
> >>
> >>  From my perspective as someone who has to maintain the minigbm
> gralloc
> >> implementation, (2) is preferable since:
> >
> >
> > Yeah, I'd prefer not to encourage 1 as the default.
> >
> >>
> >> So I had a look into implementing this,
> >
> > Thanks!
> >
> >> and using function pointers is
> >> problematic due to this struct being passed between processes which
> would
> >> prevent mesa calling a function assigned in gbm_gralloc for example.
> >
> > Why would be this struct passed between processes?
> >
> > The only data being exchanged between processes using gralloc is the
> > handle and it isn't actually exchanged directly, but the exporting
> > process will flatten it and send through Binder, while the importing
> > one will have it unflattened and then the gralloc implementation
> > called on it (the register buffer operation), which could update any
> > per-process data in the handle. (But still, why would we need to
> > include the function pointers there?)
> >
> >>
> >> It could be used to provide runtime support for multiple gralloc
> >> implementations, but that seems to about the only advantage to adding
> FPs.
> >>
> >> Am I missing a good usecase for FPs? If not I think the added
> >> complexity/cruft is more problematic than good.
> >>
> >> Any thoughts?
> >>
> >
> > I guess it might not be a big deal whether FPs or structs are used, as
> > long as they are not directly embedded in the handle, which we don't
> > want constraints on.
>
> Why no constraints? Is converging on a common handle really that hard?
> It is mostly all the same data. Some of the differences are just
> because a particular implementation hasn't addressed some feature
> (e.g. planar formats). There's other things like the pid and data ptr
> in drm_gralloc and gbm_gralloc that really should be removed (it's
> just for tracking imports). If we have some fields that are unused by
> some implementations, that seems fine to me.
>
> We're really only talking about what is the interface to mesa and
> drm_hwc for handles (and mostly drm_hwc because mesa just needs the
> dma-buf fd(s)). Today it is simply accessing the raw handle. Moving
> that to libdrm doesn't change that and is no worse. It's at least
> better in that drm_gralloc and gbm_gralloc can share it. Making it
> work with cros_gralloc doesn't seem hard. We can define accessor
> functions too (not ptrs), then the struct is opaque and you can do
> your own accessor implementation if aligning is not possible or
> desired. Or you can do your own importer within drm_hwc too.
>
> Rob
>

Re: [Mesa-dev] [PATCH 04/29] anv/blorp: Rework HiZ ops to look like MCS and CCS

[Jason Ekstrand]

On Tue, Dec 5, 2017 at 4:48 PM, Nanley Chery  wrote:

> On Mon, Nov 27, 2017 at 07:05:54PM -0800, Jason Ekstrand wrote:
> > ---
> >  src/intel/vulkan/anv_blorp.c   | 38 ++
> 
> >  src/intel/vulkan/anv_private.h |  9 +
> >  src/intel/vulkan/genX_cmd_buffer.c | 11 ++-
> >  3 files changed, 33 insertions(+), 25 deletions(-)
> >
> > diff --git a/src/intel/vulkan/anv_blorp.c b/src/intel/vulkan/anv_blorp.c
> > index f10adf0..da273d6 100644
> > --- a/src/intel/vulkan/anv_blorp.c
> > +++ b/src/intel/vulkan/anv_blorp.c
> > @@ -1568,26 +1568,30 @@ anv_image_copy_to_shadow(struct anv_cmd_buffer
> *cmd_buffer,
> > blorp_batch_finish();
> >  }
> >
> > -void
> > -anv_gen8_hiz_op_resolve(struct anv_cmd_buffer *cmd_buffer,
> > -const struct anv_image *image,
> > -enum blorp_hiz_op op)
> > +static enum blorp_hiz_op
> > +isl_to_blorp_hiz_op(enum isl_aux_op isl_op)
> >  {
> > -   assert(image);
> > +   switch (isl_op) {
>
> Is the NONE case missing?
>

Nope.  calling anv_image_hiz_op with none is considered invalid.


> > +   case ISL_AUX_OP_FAST_CLEAR:   return BLORP_HIZ_OP_DEPTH_CLEAR;
> > +   case ISL_AUX_OP_FULL_RESOLVE: return BLORP_HIZ_OP_DEPTH_RESOLVE;
> > +   case ISL_AUX_OP_AMBIGUATE:return BLORP_HIZ_OP_HIZ_RESOLVE;
> > +   default:
> > +  unreachable("Unsupported HiZ aux op");
> > +   }
> > +}
> >
> > +void
> > +anv_image_hiz_op(struct anv_cmd_buffer *cmd_buffer,
> > + const struct anv_image *image,
> > + VkImageAspectFlagBits aspect, uint32_t level,
> > + uint32_t base_layer, uint32_t layer_count,
> > + enum isl_aux_op hiz_op)
> > +{
> > +   assert(aspect == VK_IMAGE_ASPECT_DEPTH_BIT);
>
> Assuming this will handle fast depth/stencil clears, do we want to
> future-proof this assert by replacing `==` with `&`?
>

I ended up adding a second function for fast depth/stencil clears because
it needs to take an extent.  It's a bit unfortunate but it seemed cleaner
than making callers of anv_image_hiz_op have to worry about extents.


> > +   assert(base_layer + layer_count <= anv_image_aux_layers(image,
> aspect, 0));
>
>^
> I think we should replace `0` with `level`.
>

Sure.  Fixed locally.


> -Nanley
>
> > assert(anv_image_aspect_to_plane(image->aspects,
> >  VK_IMAGE_ASPECT_DEPTH_BIT) == 0);
> >
> > -   /* Don't resolve depth buffers without an auxiliary HiZ buffer and
> > -* don't perform such a resolve on gens that don't support it.
> > -*/
> > -   if (cmd_buffer->device->info.gen < 8 ||
> > -   image->planes[0].aux_usage != ISL_AUX_USAGE_HIZ)
> > -  return;
> > -
> > -   assert(op == BLORP_HIZ_OP_HIZ_RESOLVE ||
> > -  op == BLORP_HIZ_OP_DEPTH_RESOLVE);
> > -
> > struct blorp_batch batch;
> > blorp_batch_init(_buffer->device->blorp, , cmd_buffer, 0);
> >
> > @@ -1597,7 +1601,9 @@ anv_gen8_hiz_op_resolve(struct anv_cmd_buffer
> *cmd_buffer,
> >  ISL_AUX_USAGE_HIZ, );
> > surf.clear_color.f32[0] = ANV_HZ_FC_VAL;
> >
> > -   blorp_hiz_op(, , 0, 0, 1, op);
> > +   blorp_hiz_op(, , level, base_layer, layer_count,
> > +isl_to_blorp_hiz_op(hiz_op));
> > +
> > blorp_batch_finish();
> >  }
> >
> > diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_
> private.h
> > index dc44ab6..5dd95a3 100644
> > --- a/src/intel/vulkan/anv_private.h
> > +++ b/src/intel/vulkan/anv_private.h
> > @@ -2530,10 +2530,11 @@ anv_can_sample_with_hiz(const struct
> gen_device_info * const devinfo,
> >  }
> >
> >  void
> > -anv_gen8_hiz_op_resolve(struct anv_cmd_buffer *cmd_buffer,
> > -const struct anv_image *image,
> > -enum blorp_hiz_op op);
> > -
> > +anv_image_hiz_op(struct anv_cmd_buffer *cmd_buffer,
> > + const struct anv_image *image,
> > + VkImageAspectFlagBits aspect, uint32_t level,
> > + uint32_t base_layer, uint32_t layer_count,
> > + enum isl_aux_op hiz_op);
> >  void
> >  anv_image_mcs_op(struct anv_cmd_buffer *cmd_buffer,
> >   const struct anv_image *image,
> > diff --git a/src/intel/vulkan/genX_cmd_buffer.c
> b/src/intel/vulkan/genX_cmd_buffer.c
> > index 2e7a2cc..0c1ae83 100644
> > --- a/src/intel/vulkan/genX_cmd_buffer.c
> > +++ b/src/intel/vulkan/genX_cmd_buffer.c
> > @@ -388,19 +388,20 @@ transition_depth_buffer(struct anv_cmd_buffer
> *cmd_buffer,
> >anv_layout_to_aux_usage(_buffer->device->info, image,
> >VK_IMAGE_ASPECT_DEPTH_BIT, final_layout);
> >
> > -   enum blorp_hiz_op hiz_op;
> > +   enum isl_aux_op hiz_op;
> > if (hiz_enabled && !enable_hiz) {
> > -  hiz_op = BLORP_HIZ_OP_DEPTH_RESOLVE;
> > +  hiz_op = ISL_AUX_OP_FULL_RESOLVE;
> > } else if (!hiz_enabled && enable_hiz) {
> > -  

Re: [Mesa-dev] [PATCH 03/29] anv/blorp: Support ISL_AUX_USAGE_HIZ in surf_for_anv_image

[Jason Ekstrand]

On Tue, Dec 5, 2017 at 4:11 PM, Nanley Chery  wrote:

> On Mon, Nov 27, 2017 at 07:05:53PM -0800, Jason Ekstrand wrote:
> > If the function gets passed ANV_AUX_USAGE_DEFAULT, it still has the old
> > behavior of setting ISL_AUX_USAGE_NONE for depth/stencil which is what
> > we want for blits/copies.
> > ---
> >  src/intel/vulkan/anv_blorp.c | 22 ++
> >  1 file changed, 6 insertions(+), 16 deletions(-)
> >
> > diff --git a/src/intel/vulkan/anv_blorp.c b/src/intel/vulkan/anv_blorp.c
> > index 7c8a673..f10adf0 100644
> > --- a/src/intel/vulkan/anv_blorp.c
> > +++ b/src/intel/vulkan/anv_blorp.c
> > @@ -193,12 +193,13 @@ get_blorp_surf_for_anv_image(const struct
> anv_device *device,
> >  {
> > uint32_t plane = anv_image_aspect_to_plane(image->aspects, aspect);
> >
> > -   if (aux_usage == ANV_AUX_USAGE_DEFAULT)
> > +   if (aux_usage == ANV_AUX_USAGE_DEFAULT) {
> >aux_usage = image->planes[plane].aux_usage;
> >
> > -   if (aspect == VK_IMAGE_ASPECT_STENCIL_BIT ||
> > -   aux_usage == ISL_AUX_USAGE_HIZ)
> > -  aux_usage = ISL_AUX_USAGE_NONE;
> > +  if (aspect == VK_IMAGE_ASPECT_STENCIL_BIT ||
> > +  aux_usage == ISL_AUX_USAGE_HIZ)
>
> I think the predicate no longer needs a check on the aspect. If the
> aspect is stencil the aux_usage will either be NONE or HIZ. If the
> aux_usage HIZ it'll be caught by the aux_usage check. If it's NONE
> there's no work to be done.


Done.  I've also added a comment:

  /* Blorp copies and blits can't handle HiZ so disable it by default */

Either way, this patch is
> Reviewed-by: Nanley Chery 
>

Thanks!


>
> > + aux_usage = ISL_AUX_USAGE_NONE;
> > +   }
> >
> > const struct anv_surface *surface = >planes[plane].surface;
> > *blorp_surf = (struct blorp_surf) {
> > @@ -1593,18 +1594,7 @@ anv_gen8_hiz_op_resolve(struct anv_cmd_buffer
> *cmd_buffer,
> > struct blorp_surf surf;
> > get_blorp_surf_for_anv_image(cmd_buffer->device,
> >  image, VK_IMAGE_ASPECT_DEPTH_BIT,
> > -ISL_AUX_USAGE_NONE, );
> > -
> > -   /* Manually add the aux HiZ surf */
> > -   surf.aux_surf = >planes[0].aux_surface.isl,
> > -   surf.aux_addr = (struct blorp_address) {
> > -  .buffer = image->planes[0].bo,
> > -  .offset = image->planes[0].bo_offset +
> > -image->planes[0].aux_surface.offset,
> > -  .mocs = cmd_buffer->device->default_mocs,
> > -   };
> > -   surf.aux_usage = ISL_AUX_USAGE_HIZ;
> > -
>
> Thanks for getting rid of that!
>
> > +ISL_AUX_USAGE_HIZ, );
> > surf.clear_color.f32[0] = ANV_HZ_FC_VAL;
> >
> > blorp_hiz_op(, , 0, 0, 1, op);
> > --
> > 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 02/29] anv/blorp: Rework image clear/resolve helpers

[Jason Ekstrand]

On Wed, Dec 6, 2017 at 9:56 AM, Nanley Chery  wrote:

> On Wed, Dec 06, 2017 at 09:40:25AM -0800, Nanley Chery wrote:
> > On Tue, Dec 05, 2017 at 03:48:45PM -0800, Nanley Chery wrote:
> > > On Mon, Nov 27, 2017 at 07:05:52PM -0800, Jason Ekstrand wrote:
> > > > This replaces image_fast_clear and ccs_resolve with two new helpers
> that
> > > > simply perform an isl_aux_op whatever that may be on CCS or MCS.
> This
> > > > is a bit cleaner as it separates performing the aux operation from
> which
> > > > blorp helper we have to call to do it.
> > > > ---
> > > >  src/intel/vulkan/anv_blorp.c   | 218
> ++---
> > > >  src/intel/vulkan/anv_private.h |  23 ++--
> > > >  src/intel/vulkan/genX_cmd_buffer.c |  28 +++--
> > > >  3 files changed, 165 insertions(+), 104 deletions(-)
> > > >
> > > > diff --git a/src/intel/vulkan/anv_blorp.c
> b/src/intel/vulkan/anv_blorp.c
> > > > index e244468..7c8a673 100644
> > > > --- a/src/intel/vulkan/anv_blorp.c
> > > > +++ b/src/intel/vulkan/anv_blorp.c
> > > > @@ -1439,75 +1439,6 @@ fast_clear_aux_usage(const struct anv_image
> *image,
> > > >  }
> > > >
> > > >  void
> > > > -anv_image_fast_clear(struct anv_cmd_buffer *cmd_buffer,
> > > > - const struct anv_image *image,
> > > > - VkImageAspectFlagBits aspect,
> > > > - const uint32_t base_level, const uint32_t
> level_count,
> > > > - const uint32_t base_layer, uint32_t
> layer_count)
> > > > -{
> > > > -   assert(image->type == VK_IMAGE_TYPE_3D || image->extent.depth ==
> 1);
> > > > -
> > > > -   if (image->type == VK_IMAGE_TYPE_3D) {
> > > > -  assert(base_layer == 0);
> > > > -  assert(layer_count == anv_minify(image->extent.depth,
> base_level));
> > > > -   }
> > > > -
> > > > -   struct blorp_batch batch;
> > > > -   blorp_batch_init(_buffer->device->blorp, ,
> cmd_buffer, 0);
> > > > -
> > > > -   struct blorp_surf surf;
> > > > -   get_blorp_surf_for_anv_image(cmd_buffer->device, image, aspect,
> > > > -fast_clear_aux_usage(image, aspect),
> > > > -);
> > > > -
> > > > -   /* From the Sky Lake PRM Vol. 7, "Render Target Fast Clear":
> > > > -*
> > > > -*"After Render target fast clear, pipe-control with color
> cache
> > > > -*write-flush must be issued before sending any DRAW
> commands on
> > > > -*that render target."
> > > > -*
> > > > -* This comment is a bit cryptic and doesn't really tell you
> what's going
> > > > -* or what's really needed.  It appears that fast clear ops are
> not
> > > > -* properly synchronized with other drawing.  This means that we
> cannot
> > > > -* have a fast clear operation in the pipe at the same time as
> other
> > > > -* regular drawing operations.  We need to use a PIPE_CONTROL to
> ensure
> > > > -* that the contents of the previous draw hit the render target
> before we
> > > > -* resolve and then use a second PIPE_CONTROL after the resolve
> to ensure
> > > > -* that it is completed before any additional drawing occurs.
> > > > -*/
> > > > -   cmd_buffer->state.pending_pipe_bits |=
> > > > -  ANV_PIPE_RENDER_TARGET_CACHE_FLUSH_BIT |
> ANV_PIPE_CS_STALL_BIT;
> > > > -
> > > > -   uint32_t plane = anv_image_aspect_to_plane(image->aspects,
> aspect);
> > > > -   uint32_t width_div = image->format->planes[plane].
> denominator_scales[0];
> > > > -   uint32_t height_div = image->format->planes[plane].
> denominator_scales[1];
> > > > -
> > > > -   for (uint32_t l = 0; l < level_count; l++) {
> > > > -  const uint32_t level = base_level + l;
> > > > -
> > > > -  const VkExtent3D extent = {
> > > > - .width = anv_minify(image->extent.width, level),
> > > > - .height = anv_minify(image->extent.height, level),
> > > > - .depth = anv_minify(image->extent.depth, level),
> > > > -  };
> > > > -
> > > > -  if (image->type == VK_IMAGE_TYPE_3D)
> > > > - layer_count = extent.depth;
> > > > -
> > > > -  assert(level < anv_image_aux_levels(image, aspect));
> > > > -  assert(base_layer + layer_count <=
> anv_image_aux_layers(image, aspect, level));
> > > > -  blorp_fast_clear(, , surf.surf->format,
> > > > -   level, base_layer, layer_count,
> > > > -   0, 0,
> > > > -   extent.width / width_div,
> > > > -   extent.height / height_div);
> > > > -   }
> > > > -
> > > > -   cmd_buffer->state.pending_pipe_bits |=
> > > > -  ANV_PIPE_RENDER_TARGET_CACHE_FLUSH_BIT |
> ANV_PIPE_CS_STALL_BIT;
> > > > -}
> > > > -
> > > > -void
> > > >  anv_cmd_buffer_resolve_subpass(struct anv_cmd_buffer *cmd_buffer)
> > > >  {
> > > > struct anv_framebuffer *fb = cmd_buffer->state.framebuffer;
> > > > @@ -1681,36 +1612,153 @@ anv_gen8_hiz_op_resolve(struct
> anv_cmd_buffer *cmd_buffer,

Re: [Mesa-dev] [PATCH 02/29] anv/blorp: Rework image clear/resolve helpers

[Jason Ekstrand]

On Tue, Dec 5, 2017 at 4:16 PM, Nanley Chery  wrote:

> On Mon, Nov 27, 2017 at 07:05:52PM -0800, Jason Ekstrand wrote:
> > This replaces image_fast_clear and ccs_resolve with two new helpers that
> > simply perform an isl_aux_op whatever that may be on CCS or MCS.  This
> > is a bit cleaner as it separates performing the aux operation from which
> > blorp helper we have to call to do it.
> > ---
> >  src/intel/vulkan/anv_blorp.c   | 218 ++
> ---
> >  src/intel/vulkan/anv_private.h |  23 ++--
> >  src/intel/vulkan/genX_cmd_buffer.c |  28 +++--
> >  3 files changed, 165 insertions(+), 104 deletions(-)
> >
> > diff --git a/src/intel/vulkan/anv_blorp.c b/src/intel/vulkan/anv_blorp.c
> > index e244468..7c8a673 100644
> > --- a/src/intel/vulkan/anv_blorp.c
> > +++ b/src/intel/vulkan/anv_blorp.c
> > @@ -1439,75 +1439,6 @@ fast_clear_aux_usage(const struct anv_image
> *image,
> >  }
> >
> >  void
> > -anv_image_fast_clear(struct anv_cmd_buffer *cmd_buffer,
> > - const struct anv_image *image,
> > - VkImageAspectFlagBits aspect,
> > - const uint32_t base_level, const uint32_t
> level_count,
> > - const uint32_t base_layer, uint32_t layer_count)
> > -{
> > -   assert(image->type == VK_IMAGE_TYPE_3D || image->extent.depth == 1);
> > -
> > -   if (image->type == VK_IMAGE_TYPE_3D) {
> > -  assert(base_layer == 0);
> > -  assert(layer_count == anv_minify(image->extent.depth,
> base_level));
> > -   }
> > -
> > -   struct blorp_batch batch;
> > -   blorp_batch_init(_buffer->device->blorp, , cmd_buffer, 0);
> > -
> > -   struct blorp_surf surf;
> > -   get_blorp_surf_for_anv_image(cmd_buffer->device, image, aspect,
> > -fast_clear_aux_usage(image, aspect),
> > -);
> > -
> > -   /* From the Sky Lake PRM Vol. 7, "Render Target Fast Clear":
> > -*
> > -*"After Render target fast clear, pipe-control with color cache
> > -*write-flush must be issued before sending any DRAW commands on
> > -*that render target."
> > -*
> > -* This comment is a bit cryptic and doesn't really tell you what's
> going
> > -* or what's really needed.  It appears that fast clear ops are not
> > -* properly synchronized with other drawing.  This means that we
> cannot
> > -* have a fast clear operation in the pipe at the same time as other
> > -* regular drawing operations.  We need to use a PIPE_CONTROL to
> ensure
> > -* that the contents of the previous draw hit the render target
> before we
> > -* resolve and then use a second PIPE_CONTROL after the resolve to
> ensure
> > -* that it is completed before any additional drawing occurs.
> > -*/
> > -   cmd_buffer->state.pending_pipe_bits |=
> > -  ANV_PIPE_RENDER_TARGET_CACHE_FLUSH_BIT | ANV_PIPE_CS_STALL_BIT;
> > -
> > -   uint32_t plane = anv_image_aspect_to_plane(image->aspects, aspect);
> > -   uint32_t width_div = image->format->planes[plane].
> denominator_scales[0];
> > -   uint32_t height_div = image->format->planes[plane].
> denominator_scales[1];
> > -
> > -   for (uint32_t l = 0; l < level_count; l++) {
> > -  const uint32_t level = base_level + l;
> > -
> > -  const VkExtent3D extent = {
> > - .width = anv_minify(image->extent.width, level),
> > - .height = anv_minify(image->extent.height, level),
> > - .depth = anv_minify(image->extent.depth, level),
> > -  };
> > -
> > -  if (image->type == VK_IMAGE_TYPE_3D)
> > - layer_count = extent.depth;
> > -
> > -  assert(level < anv_image_aux_levels(image, aspect));
> > -  assert(base_layer + layer_count <= anv_image_aux_layers(image,
> aspect, level));
> > -  blorp_fast_clear(, , surf.surf->format,
> > -   level, base_layer, layer_count,
> > -   0, 0,
> > -   extent.width / width_div,
> > -   extent.height / height_div);
> > -   }
> > -
> > -   cmd_buffer->state.pending_pipe_bits |=
> > -  ANV_PIPE_RENDER_TARGET_CACHE_FLUSH_BIT | ANV_PIPE_CS_STALL_BIT;
> > -}
> > -
> > -void
> >  anv_cmd_buffer_resolve_subpass(struct anv_cmd_buffer *cmd_buffer)
> >  {
> > struct anv_framebuffer *fb = cmd_buffer->state.framebuffer;
> > @@ -1681,36 +1612,153 @@ anv_gen8_hiz_op_resolve(struct anv_cmd_buffer
> *cmd_buffer,
> >  }
> >
> >  void
> > -anv_ccs_resolve(struct anv_cmd_buffer * const cmd_buffer,
> > -const struct anv_image * const image,
> > -VkImageAspectFlagBits aspect,
> > -const uint8_t level,
> > -const uint32_t start_layer, const uint32_t layer_count,
> > -const enum blorp_fast_clear_op op)
> > +anv_image_mcs_op(struct anv_cmd_buffer *cmd_buffer,
> > + const struct anv_image *image,
> > + VkImageAspectFlagBits 

[Mesa-dev] [PATCH 05/10] i965: Use enum color_logic_ops for blits

[Ian Romanick]

From: Ian Romanick 

Signed-off-by: Ian Romanick 
---
 src/mesa/drivers/dri/i965/intel_blit.c | 36 +++---
 src/mesa/drivers/dri/i965/intel_blit.h |  6 ++---
 src/mesa/drivers/dri/i965/intel_fbo.c  |  3 ++-
 src/mesa/drivers/dri/i965/intel_mipmap_tree.c  |  2 +-
 src/mesa/drivers/dri/i965/intel_pixel_bitmap.c |  4 +--
 src/mesa/drivers/dri/i965/intel_pixel_copy.c   |  2 +-
 src/mesa/drivers/dri/i965/intel_pixel_draw.c   |  2 +-
 src/mesa/drivers/dri/i965/intel_tex_copy.c |  2 +-
 8 files changed, 20 insertions(+), 37 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/intel_blit.c 
b/src/mesa/drivers/dri/i965/intel_blit.c
index 46945b2..99a3a4c 100644
--- a/src/mesa/drivers/dri/i965/intel_blit.c
+++ b/src/mesa/drivers/dri/i965/intel_blit.c
@@ -44,27 +44,9 @@ intel_miptree_set_alpha_to_one(struct brw_context *brw,
struct intel_mipmap_tree *mt,
int x, int y, int width, int height);
 
-static GLuint translate_raster_op(GLenum logicop)
+static GLuint translate_raster_op(enum color_logic_ops logicop)
 {
-   switch(logicop) {
-   case GL_CLEAR: return 0x00;
-   case GL_AND: return 0x88;
-   case GL_AND_REVERSE: return 0x44;
-   case GL_COPY: return 0xCC;
-   case GL_AND_INVERTED: return 0x22;
-   case GL_NOOP: return 0xAA;
-   case GL_XOR: return 0x66;
-   case GL_OR: return 0xEE;
-   case GL_NOR: return 0x11;
-   case GL_EQUIV: return 0x99;
-   case GL_INVERT: return 0x55;
-   case GL_OR_REVERSE: return 0xDD;
-   case GL_COPY_INVERTED: return 0x33;
-   case GL_OR_INVERTED: return 0xBB;
-   case GL_NAND: return 0x77;
-   case GL_SET: return 0xFF;
-   default: return 0;
-   }
+   return logicop | (logicop << 4);
 }
 
 static uint32_t
@@ -227,7 +209,7 @@ emit_miptree_blit(struct brw_context *brw,
   struct intel_mipmap_tree *dst_mt,
   uint32_t dst_x, uint32_t dst_y,
   uint32_t width, uint32_t height,
-  bool reverse, GLenum logicop)
+  bool reverse, enum color_logic_ops logicop)
 {
/* According to the Ivy Bridge PRM, Vol1 Part4, section 1.2.1.2 (Graphics
 * Data Size Limitations):
@@ -319,7 +301,7 @@ intel_miptree_blit(struct brw_context *brw,
int dst_level, int dst_slice,
uint32_t dst_x, uint32_t dst_y, bool dst_flip,
uint32_t width, uint32_t height,
-   GLenum logicop)
+   enum color_logic_ops logicop)
 {
/* The blitter doesn't understand multisampling at all. */
if (src_mt->surf.samples > 1 || dst_mt->surf.samples > 1)
@@ -463,7 +445,7 @@ intel_miptree_copy(struct brw_context *brw,
 
return emit_miptree_blit(brw, src_mt, src_x, src_y,
 dst_mt, dst_x, dst_y,
-src_width, src_height, false, GL_COPY);
+src_width, src_height, false, COLOR_LOGICOP_COPY);
 }
 
 static bool
@@ -527,7 +509,7 @@ intelEmitCopyBlit(struct brw_context *brw,
  GLshort src_x, GLshort src_y,
  GLshort dst_x, GLshort dst_y,
  GLshort w, GLshort h,
- GLenum logic_op)
+ enum color_logic_ops logic_op)
 {
const struct gen_device_info *devinfo = >screen->devinfo;
GLuint CMD, BR13;
@@ -654,7 +636,7 @@ intelEmitImmediateColorExpandBlit(struct brw_context *brw,
  enum isl_tiling dst_tiling,
  GLshort x, GLshort y,
  GLshort w, GLshort h,
- GLenum logic_op)
+ enum color_logic_ops logic_op)
 {
const struct gen_device_info *devinfo = >screen->devinfo;
int dwords = ALIGN(src_size, 8) / 4;
@@ -667,7 +649,7 @@ intelEmitImmediateColorExpandBlit(struct brw_context *brw,
 return false;
}
 
-   assert((logic_op >= GL_CLEAR) && (logic_op <= (GL_CLEAR + 0x0f)));
+   assert((unsigned) logic_op <= 0x0f);
assert(dst_pitch > 0);
 
if (w < 0 || h < 0)
@@ -763,7 +745,7 @@ intel_emit_linear_blit(struct brw_context *brw,
  src_x, 0, /* src x/y */
  dst_x, 0, /* dst x/y */
  MIN2(size, pitch), height, /* w, h */
- GL_COPY);
+ COLOR_LOGICOP_COPY);
   if (!ok) {
  _mesa_problem(ctx, "Failed to linear blit %dx%d\n",
MIN2(size, pitch), height);
diff --git a/src/mesa/drivers/dri/i965/intel_blit.h 
b/src/mesa/drivers/dri/i965/intel_blit.h
index 0a0c57d..29af4f4 100644
--- a/src/mesa/drivers/dri/i965/intel_blit.h
+++ b/src/mesa/drivers/dri/i965/intel_blit.h
@@ -42,7 +42,7 @@ intelEmitCopyBlit(struct brw_context *brw,
   GLshort srcx, GLshort srcy,
   GLshort dstx, 

[Mesa-dev] [PATCH 04/10] mesa: Pass the translated color logic op dd_function_table::LogicOpcode

[Ian Romanick]

From: Ian Romanick 

And delete the resulting dead code.  This has only been compile-tested.

Signed-off-by: Ian Romanick 
---
 src/mesa/drivers/common/driverfuncs.c|  2 +-
 src/mesa/drivers/dri/i915/i830_state.c   |  8 +++---
 src/mesa/drivers/dri/i915/i915_state.c   |  8 +++---
 src/mesa/drivers/dri/i915/intel_context.h|  1 -
 src/mesa/drivers/dri/i915/intel_screen.h |  1 -
 src/mesa/drivers/dri/i915/intel_state.c  | 41 
 src/mesa/drivers/dri/nouveau/nouveau_state.c |  2 +-
 src/mesa/drivers/dri/r200/r200_state.c   |  7 ++---
 src/mesa/drivers/dri/radeon/radeon_state.c   | 27 ++
 src/mesa/main/blend.c|  2 +-
 src/mesa/main/dd.h   |  2 +-
 11 files changed, 18 insertions(+), 83 deletions(-)

diff --git a/src/mesa/drivers/common/driverfuncs.c 
b/src/mesa/drivers/common/driverfuncs.c
index 94dc0e6..99c1520 100644
--- a/src/mesa/drivers/common/driverfuncs.c
+++ b/src/mesa/drivers/common/driverfuncs.c
@@ -277,7 +277,7 @@ _mesa_init_driver_state(struct gl_context *ctx)
}
 
ctx->Driver.LineWidth(ctx, ctx->Line.Width);
-   ctx->Driver.LogicOpcode(ctx, ctx->Color.LogicOp);
+   ctx->Driver.LogicOpcode(ctx, ctx->Color._LogicOp);
ctx->Driver.PointSize(ctx, ctx->Point.Size);
ctx->Driver.PolygonStipple(ctx, (const GLubyte *) ctx->PolygonStipple);
ctx->Driver.Scissor(ctx);
diff --git a/src/mesa/drivers/dri/i915/i830_state.c 
b/src/mesa/drivers/dri/i915/i830_state.c
index 7ce5ef7..2bd4985 100644
--- a/src/mesa/drivers/dri/i915/i830_state.c
+++ b/src/mesa/drivers/dri/i915/i830_state.c
@@ -573,16 +573,16 @@ i830Scissor(struct gl_context * ctx)
 }
 
 static void
-i830LogicOp(struct gl_context * ctx, GLenum opcode)
+i830LogicOp(struct gl_context * ctx, enum color_logic_ops opcode)
 {
struct i830_context *i830 = i830_context(ctx);
-   int tmp = intel_translate_logic_op(opcode);
 
DBG("%s\n", __func__);
-   
+
+   assert((unsigned)opcode <= 15);
I830_STATECHANGE(i830, I830_UPLOAD_CTX);
i830->state.Ctx[I830_CTXREG_STATE4] &= ~LOGICOP_MASK;
-   i830->state.Ctx[I830_CTXREG_STATE4] |= LOGIC_OP_FUNC(tmp);
+   i830->state.Ctx[I830_CTXREG_STATE4] |= opcode;
 }
 
 
diff --git a/src/mesa/drivers/dri/i915/i915_state.c 
b/src/mesa/drivers/dri/i915/i915_state.c
index 685af04..50489e4 100644
--- a/src/mesa/drivers/dri/i915/i915_state.c
+++ b/src/mesa/drivers/dri/i915/i915_state.c
@@ -539,16 +539,16 @@ i915Scissor(struct gl_context * ctx)
 }
 
 static void
-i915LogicOp(struct gl_context * ctx, GLenum opcode)
+i915LogicOp(struct gl_context * ctx, enum color_logic_ops opcode)
 {
struct i915_context *i915 = I915_CONTEXT(ctx);
-   int tmp = intel_translate_logic_op(opcode);
 
DBG("%s\n", __func__);
-   
+
+   assert((unsigned)opcode <= 15);
I915_STATECHANGE(i915, I915_UPLOAD_CTX);
i915->state.Ctx[I915_CTXREG_STATE4] &= ~LOGICOP_MASK;
-   i915->state.Ctx[I915_CTXREG_STATE4] |= LOGIC_OP_FUNC(tmp);
+   i915->state.Ctx[I915_CTXREG_STATE4] |= LOGIC_OP_FUNC(opcode);
 }
 
 
diff --git a/src/mesa/drivers/dri/i915/intel_context.h 
b/src/mesa/drivers/dri/i915/intel_context.h
index c59436a..5361dcf 100644
--- a/src/mesa/drivers/dri/i915/intel_context.h
+++ b/src/mesa/drivers/dri/i915/intel_context.h
@@ -421,7 +421,6 @@ extern int intel_translate_shadow_compare_func(GLenum func);
 extern int intel_translate_compare_func(GLenum func);
 extern int intel_translate_stencil_op(GLenum op);
 extern int intel_translate_blend_factor(GLenum factor);
-extern int intel_translate_logic_op(GLenum opcode);
 
 void intel_update_renderbuffers(__DRIcontext *context,
__DRIdrawable *drawable);
diff --git a/src/mesa/drivers/dri/i915/intel_screen.h 
b/src/mesa/drivers/dri/i915/intel_screen.h
index a22888b..ec4592d 100644
--- a/src/mesa/drivers/dri/i915/intel_screen.h
+++ b/src/mesa/drivers/dri/i915/intel_screen.h
@@ -139,7 +139,6 @@ struct intel_screen
 #define get_timeold_get_time
 #define intel_translate_blend_factorold_intel_translate_blend_factor
 #define intel_translate_compare_funcold_intel_translate_compare_func
-#define intel_translate_logic_opold_intel_translate_logic_op
 #define intel_translate_shadow_compare_func 
old_intel_translate_shadow_compare_func
 #define intel_translate_stencil_op  old_intel_translate_stencil_op
 #define intel_init_syncobj_functionsold_intel_init_syncobj_functions
diff --git a/src/mesa/drivers/dri/i915/intel_state.c 
b/src/mesa/drivers/dri/i915/intel_state.c
index 3de9d50..4f47013 100644
--- a/src/mesa/drivers/dri/i915/intel_state.c
+++ b/src/mesa/drivers/dri/i915/intel_state.c
@@ -151,44 +151,3 @@ intel_translate_blend_factor(GLenum factor)
fprintf(stderr, "Unknown value in %s: %x\n", __func__, factor);
return BLENDFACT_ZERO;
 }
-
-int
-intel_translate_logic_op(GLenum opcode)
-{
-   switch (opcode) {
-   

[Mesa-dev] [PATCH 08/10] i915: Make intelEmitCopyBlit static

[Ian Romanick]

From: Ian Romanick 

And rename to emit_copy_blit.

Signed-off-by: Ian Romanick 
---
 src/mesa/drivers/dri/i915/intel_blit.c   | 299 +++
 src/mesa/drivers/dri/i915/intel_blit.h   |  16 --
 src/mesa/drivers/dri/i915/intel_screen.h |   1 -
 3 files changed, 149 insertions(+), 167 deletions(-)

diff --git a/src/mesa/drivers/dri/i915/intel_blit.c 
b/src/mesa/drivers/dri/i915/intel_blit.c
index 7e65197..77e6a61 100644
--- a/src/mesa/drivers/dri/i915/intel_blit.c
+++ b/src/mesa/drivers/dri/i915/intel_blit.c
@@ -72,144 +72,23 @@ br13_for_cpp(int cpp)
}
 }
 
-/**
- * Implements a rectangular block transfer (blit) of pixels between two
- * miptrees.
- *
- * Our blitter can operate on 1, 2, or 4-byte-per-pixel data, with generous,
- * but limited, pitches and sizes allowed.
- *
- * The src/dst coordinates are relative to the given level/slice of the
- * miptree.
- *
- * If @src_flip or @dst_flip is set, then the rectangle within that miptree
- * will be inverted (including scanline order) when copying.  This is common
- * in GL when copying between window system and user-created
- * renderbuffers/textures.
- */
-bool
-intel_miptree_blit(struct intel_context *intel,
-   struct intel_mipmap_tree *src_mt,
-   int src_level, int src_slice,
-   uint32_t src_x, uint32_t src_y, bool src_flip,
-   struct intel_mipmap_tree *dst_mt,
-   int dst_level, int dst_slice,
-   uint32_t dst_x, uint32_t dst_y, bool dst_flip,
-   uint32_t width, uint32_t height,
-   enum color_logic_ops logicop)
-{
-   /* No sRGB decode or encode is done by the hardware blitter, which is
-* consistent with what we want in the callers (glCopyTexSubImage(),
-* glBlitFramebuffer(), texture validation, etc.).
-*/
-   mesa_format src_format = _mesa_get_srgb_format_linear(src_mt->format);
-   mesa_format dst_format = _mesa_get_srgb_format_linear(dst_mt->format);
-
-   /* The blitter doesn't support doing any format conversions.  We do also
-* support blitting ARGB to XRGB (trivial, the values dropped into
-* the X channel don't matter), and XRGB to ARGB by setting the A
-* channel to 1.0 at the end.
-*/
-   if (src_format != dst_format &&
-  ((src_format != MESA_FORMAT_B8G8R8A8_UNORM &&
-src_format != MESA_FORMAT_B8G8R8X8_UNORM) ||
-   (dst_format != MESA_FORMAT_B8G8R8A8_UNORM &&
-dst_format != MESA_FORMAT_B8G8R8X8_UNORM))) {
-  perf_debug("%s: Can't use hardware blitter from %s to %s, "
- "falling back.\n", __func__,
- _mesa_get_format_name(src_format),
- _mesa_get_format_name(dst_format));
-  return false;
-   }
-
-   /* According to the Ivy Bridge PRM, Vol1 Part4, section 1.2.1.2 (Graphics
-* Data Size Limitations):
-*
-*The BLT engine is capable of transferring very large quantities of
-*graphics data. Any graphics data read from and written to the
-*destination is permitted to represent a number of pixels that
-*occupies up to 65,536 scan lines and up to 32,768 bytes per scan line
-*at the destination. The maximum number of pixels that may be
-*represented per scan line’s worth of graphics data depends on the
-*color depth.
-*
-* Furthermore, intelEmitCopyBlit (which is called below) uses a signed
-* 16-bit integer to represent buffer pitch, so it can only handle buffer
-* pitches < 32k.
-*
-* As a result of these two limitations, we can only use the blitter to do
-* this copy when the region's pitch is less than 32k.
-*/
-   if (src_mt->region->pitch > 32768 ||
-   dst_mt->region->pitch > 32768) {
-  perf_debug("Falling back due to >32k pitch\n");
-  return false;
-   }
-
-   if (src_flip)
-  src_y = src_mt->level[src_level].height - src_y - height;
-
-   if (dst_flip)
-  dst_y = dst_mt->level[dst_level].height - dst_y - height;
-
-   int src_pitch = src_mt->region->pitch;
-   if (src_flip != dst_flip)
-  src_pitch = -src_pitch;
-
-   uint32_t src_image_x, src_image_y;
-   intel_miptree_get_image_offset(src_mt, src_level, src_slice,
-  _image_x, _image_y);
-   src_x += src_image_x;
-   src_y += src_image_y;
-
-   uint32_t dst_image_x, dst_image_y;
-   intel_miptree_get_image_offset(dst_mt, dst_level, dst_slice,
-  _image_x, _image_y);
-   dst_x += dst_image_x;
-   dst_y += dst_image_y;
-
-   if (!intelEmitCopyBlit(intel,
-  src_mt->cpp,
-  src_pitch,
-  src_mt->region->bo, src_mt->offset,
-  src_mt->region->tiling,
-  dst_mt->region->pitch,
-  dst_mt->region->bo, dst_mt->offset,
- 

[Mesa-dev] [PATCH 03/10] st/mesa: Use the translated color logic op from the context

[Ian Romanick]

From: Ian Romanick 

And delete the resulting dead code.

Signed-off-by: Ian Romanick 
---
 src/mesa/state_tracker/st_atom_blend.c | 48 +-
 1 file changed, 1 insertion(+), 47 deletions(-)

diff --git a/src/mesa/state_tracker/st_atom_blend.c 
b/src/mesa/state_tracker/st_atom_blend.c
index 103c500..8bc5a5f 100644
--- a/src/mesa/state_tracker/st_atom_blend.c
+++ b/src/mesa/state_tracker/st_atom_blend.c
@@ -107,52 +107,6 @@ translate_blend(GLenum blend)
}
 }
 
-
-/**
- * Convert GLenum logicop tokens to pipe tokens.
- */
-static GLuint
-translate_logicop(GLenum logicop)
-{
-   switch (logicop) {
-   case GL_CLEAR:
-  return PIPE_LOGICOP_CLEAR;
-   case GL_NOR:
-  return PIPE_LOGICOP_NOR;
-   case GL_AND_INVERTED:
-  return PIPE_LOGICOP_AND_INVERTED;
-   case GL_COPY_INVERTED:
-  return PIPE_LOGICOP_COPY_INVERTED;
-   case GL_AND_REVERSE:
-  return PIPE_LOGICOP_AND_REVERSE;
-   case GL_INVERT:
-  return PIPE_LOGICOP_INVERT;
-   case GL_XOR:
-  return PIPE_LOGICOP_XOR;
-   case GL_NAND:
-  return PIPE_LOGICOP_NAND;
-   case GL_AND:
-  return PIPE_LOGICOP_AND;
-   case GL_EQUIV:
-  return PIPE_LOGICOP_EQUIV;
-   case GL_NOOP:
-  return PIPE_LOGICOP_NOOP;
-   case GL_OR_INVERTED:
-  return PIPE_LOGICOP_OR_INVERTED;
-   case GL_COPY:
-  return PIPE_LOGICOP_COPY;
-   case GL_OR_REVERSE:
-  return PIPE_LOGICOP_OR_REVERSE;
-   case GL_OR:
-  return PIPE_LOGICOP_OR;
-   case GL_SET:
-  return PIPE_LOGICOP_SET;
-   default:
-  assert("invalid GL token in translate_logicop()" == NULL);
-  return 0;
-   }
-}
-
 /**
  * Figure out if colormasks are different per rt.
  */
@@ -204,7 +158,7 @@ st_update_blend( struct st_context *st )
if (ctx->Color.ColorLogicOpEnabled) {
   /* logicop enabled */
   blend->logicop_enable = 1;
-  blend->logicop_func = translate_logicop(ctx->Color.LogicOp);
+  blend->logicop_func = ctx->Color._LogicOp;
}
else if (ctx->Color.BlendEnabled && !ctx->Color._AdvancedBlendMode) {
   /* blending enabled */
-- 
2.9.5

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

[Mesa-dev] [PATCH 07/10] i965: Make intelEmitCopyBlit static

[Ian Romanick]

From: Ian Romanick 

And rename to emit_copy_blit.

Signed-off-by: Ian Romanick 
---
 src/mesa/drivers/dri/i965/intel_blit.c | 398 -
 src/mesa/drivers/dri/i965/intel_blit.h |  16 --
 2 files changed, 199 insertions(+), 215 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/intel_blit.c 
b/src/mesa/drivers/dri/i965/intel_blit.c
index 99a3a4c..726d3e3 100644
--- a/src/mesa/drivers/dri/i965/intel_blit.c
+++ b/src/mesa/drivers/dri/i965/intel_blit.c
@@ -203,6 +203,183 @@ get_blit_intratile_offset_el(const struct brw_context 
*brw,
 }
 
 static bool
+alignment_valid(struct brw_context *brw, unsigned offset,
+enum isl_tiling tiling)
+{
+   const struct gen_device_info *devinfo = >screen->devinfo;
+
+   /* Tiled buffers must be page-aligned (4K). */
+   if (tiling != ISL_TILING_LINEAR)
+  return (offset & 4095) == 0;
+
+   /* On Gen8+, linear buffers must be cacheline-aligned. */
+   if (devinfo->gen >= 8)
+  return (offset & 63) == 0;
+
+   return true;
+}
+
+static uint32_t
+xy_blit_cmd(enum isl_tiling src_tiling, enum isl_tiling dst_tiling,
+uint32_t cpp)
+{
+   uint32_t CMD = 0;
+
+   assert(cpp <= 4);
+   switch (cpp) {
+   case 1:
+   case 2:
+  CMD = XY_SRC_COPY_BLT_CMD;
+  break;
+   case 4:
+  CMD = XY_SRC_COPY_BLT_CMD | XY_BLT_WRITE_ALPHA | XY_BLT_WRITE_RGB;
+  break;
+   default:
+  unreachable("not reached");
+   }
+
+   if (dst_tiling != ISL_TILING_LINEAR)
+  CMD |= XY_DST_TILED;
+
+   if (src_tiling != ISL_TILING_LINEAR)
+  CMD |= XY_SRC_TILED;
+
+   return CMD;
+}
+
+/* Copy BitBlt
+ */
+static bool
+emit_copy_blit(struct brw_context *brw,
+   GLuint cpp,
+   int32_t src_pitch,
+   struct brw_bo *src_buffer,
+   GLuint src_offset,
+   enum isl_tiling src_tiling,
+   int32_t dst_pitch,
+   struct brw_bo *dst_buffer,
+   GLuint dst_offset,
+   enum isl_tiling dst_tiling,
+   GLshort src_x, GLshort src_y,
+   GLshort dst_x, GLshort dst_y,
+   GLshort w, GLshort h,
+   enum color_logic_ops logic_op)
+{
+   const struct gen_device_info *devinfo = >screen->devinfo;
+   GLuint CMD, BR13;
+   int dst_y2 = dst_y + h;
+   int dst_x2 = dst_x + w;
+   bool dst_y_tiled = dst_tiling == ISL_TILING_Y0;
+   bool src_y_tiled = src_tiling == ISL_TILING_Y0;
+   uint32_t src_tile_w, src_tile_h;
+   uint32_t dst_tile_w, dst_tile_h;
+
+   if ((dst_y_tiled || src_y_tiled) && devinfo->gen < 6)
+  return false;
+
+   const unsigned bo_sizes = dst_buffer->size + src_buffer->size;
+
+   /* do space check before going any further */
+   if (!brw_batch_has_aperture_space(brw, bo_sizes))
+  intel_batchbuffer_flush(brw);
+
+   if (!brw_batch_has_aperture_space(brw, bo_sizes))
+  return false;
+
+   unsigned length = devinfo->gen >= 8 ? 10 : 8;
+
+   intel_batchbuffer_require_space(brw, length * 4, BLT_RING);
+   DBG("%s src:buf(%p)/%d+%d %d,%d dst:buf(%p)/%d+%d %d,%d sz:%dx%d\n",
+   __func__,
+   src_buffer, src_pitch, src_offset, src_x, src_y,
+   dst_buffer, dst_pitch, dst_offset, dst_x, dst_y, w, h);
+
+   intel_get_tile_dims(src_tiling, cpp, _tile_w, _tile_h);
+   intel_get_tile_dims(dst_tiling, cpp, _tile_w, _tile_h);
+
+   /* For Tiled surfaces, the pitch has to be a multiple of the Tile width
+* (X direction width of the Tile). This is ensured while allocating the
+* buffer object.
+*/
+   assert(src_tiling == ISL_TILING_LINEAR || (src_pitch % src_tile_w) == 0);
+   assert(dst_tiling == ISL_TILING_LINEAR || (dst_pitch % dst_tile_w) == 0);
+
+   /* For big formats (such as floating point), do the copy using 16 or
+* 32bpp and multiply the coordinates.
+*/
+   if (cpp > 4) {
+  if (cpp % 4 == 2) {
+ dst_x *= cpp / 2;
+ dst_x2 *= cpp / 2;
+ src_x *= cpp / 2;
+ cpp = 2;
+  } else {
+ assert(cpp % 4 == 0);
+ dst_x *= cpp / 4;
+ dst_x2 *= cpp / 4;
+ src_x *= cpp / 4;
+ cpp = 4;
+  }
+   }
+
+   if (!alignment_valid(brw, dst_offset, dst_tiling))
+  return false;
+   if (!alignment_valid(brw, src_offset, src_tiling))
+  return false;
+
+   /* Blit pitch must be dword-aligned.  Otherwise, the hardware appears to 
drop
+* the low bits.  Offsets must be naturally aligned.
+*/
+   if (src_pitch % 4 != 0 || src_offset % cpp != 0 ||
+   dst_pitch % 4 != 0 || dst_offset % cpp != 0)
+  return false;
+
+   assert(cpp <= 4);
+   BR13 = br13_for_cpp(cpp) | translate_raster_op(logic_op) << 16;
+
+   CMD = xy_blit_cmd(src_tiling, dst_tiling, cpp);
+
+   /* For tiled source and destination, pitch value should be specified
+* as a number of Dwords.
+*/
+   if (dst_tiling != ISL_TILING_LINEAR)
+  dst_pitch /= 4;
+
+   if (src_tiling != ISL_TILING_LINEAR)
+  src_pitch /= 4;
+
+   

[Mesa-dev] [PATCH 02/10] i965: Use the translated color logic op from the context

[Ian Romanick]

From: Ian Romanick 

And delete the resulting dead code.

Signed-off-by: Ian Romanick 
---
 src/mesa/drivers/dri/i965/brw_context.h   |  1 -
 src/mesa/drivers/dri/i965/genX_state_upload.c |  3 +-
 src/mesa/drivers/dri/i965/intel_state.c   | 41 ---
 3 files changed, 1 insertion(+), 44 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_context.h 
b/src/mesa/drivers/dri/i965/brw_context.h
index 0f0aad8..afea537 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -1465,7 +1465,6 @@ extern void intelInitExtensions(struct gl_context *ctx);
 extern int intel_translate_shadow_compare_func(GLenum func);
 extern int intel_translate_compare_func(GLenum func);
 extern int intel_translate_stencil_op(GLenum op);
-extern int intel_translate_logic_op(GLenum opcode);
 
 /* brw_sync.c */
 void brw_init_syncobj_functions(struct dd_function_table *functions);
diff --git a/src/mesa/drivers/dri/i965/genX_state_upload.c 
b/src/mesa/drivers/dri/i965/genX_state_upload.c
index 50ac5bc..aa4d64d 100644
--- a/src/mesa/drivers/dri/i965/genX_state_upload.c
+++ b/src/mesa/drivers/dri/i965/genX_state_upload.c
@@ -2819,8 +2819,7 @@ set_blend_entry_bits(struct brw_context *brw, 
BLEND_ENTRY_GENXML *entry, int i,
 _mesa_enum_to_string(rb_type));
   if (GEN_GEN >= 8 || rb_type == GL_UNSIGNED_NORMALIZED) {
  entry->LogicOpEnable = true;
- entry->LogicOpFunction =
-intel_translate_logic_op(ctx->Color.LogicOp);
+ entry->LogicOpFunction = ctx->Color._LogicOp;
   }
} else if (blend_enabled && !ctx->Color._AdvancedBlendMode
   && (GEN_GEN <= 5 || !integer)) {
diff --git a/src/mesa/drivers/dri/i965/intel_state.c 
b/src/mesa/drivers/dri/i965/intel_state.c
index 5001a49..3d477df 100644
--- a/src/mesa/drivers/dri/i965/intel_state.c
+++ b/src/mesa/drivers/dri/i965/intel_state.c
@@ -117,44 +117,3 @@ intel_translate_stencil_op(GLenum op)
   return BRW_STENCILOP_ZERO;
}
 }
-
-int
-intel_translate_logic_op(GLenum opcode)
-{
-   switch (opcode) {
-   case GL_CLEAR:
-  return BRW_LOGICOPFUNCTION_CLEAR;
-   case GL_AND:
-  return BRW_LOGICOPFUNCTION_AND;
-   case GL_AND_REVERSE:
-  return BRW_LOGICOPFUNCTION_AND_REVERSE;
-   case GL_COPY:
-  return BRW_LOGICOPFUNCTION_COPY;
-   case GL_COPY_INVERTED:
-  return BRW_LOGICOPFUNCTION_COPY_INVERTED;
-   case GL_AND_INVERTED:
-  return BRW_LOGICOPFUNCTION_AND_INVERTED;
-   case GL_NOOP:
-  return BRW_LOGICOPFUNCTION_NOOP;
-   case GL_XOR:
-  return BRW_LOGICOPFUNCTION_XOR;
-   case GL_OR:
-  return BRW_LOGICOPFUNCTION_OR;
-   case GL_OR_INVERTED:
-  return BRW_LOGICOPFUNCTION_OR_INVERTED;
-   case GL_NOR:
-  return BRW_LOGICOPFUNCTION_NOR;
-   case GL_EQUIV:
-  return BRW_LOGICOPFUNCTION_EQUIV;
-   case GL_INVERT:
-  return BRW_LOGICOPFUNCTION_INVERT;
-   case GL_OR_REVERSE:
-  return BRW_LOGICOPFUNCTION_OR_REVERSE;
-   case GL_NAND:
-  return BRW_LOGICOPFUNCTION_NAND;
-   case GL_SET:
-  return BRW_LOGICOPFUNCTION_SET;
-   default:
-  return BRW_LOGICOPFUNCTION_SET;
-   }
-}
-- 
2.9.5

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

Re: [Mesa-dev] [PATCH 02/29] anv/blorp: Rework image clear/resolve helpers

[Jason Ekstrand]

On Tue, Dec 5, 2017 at 3:48 PM, Nanley Chery  wrote:

> On Mon, Nov 27, 2017 at 07:05:52PM -0800, Jason Ekstrand wrote:
> > This replaces image_fast_clear and ccs_resolve with two new helpers that
> > simply perform an isl_aux_op whatever that may be on CCS or MCS.  This
> > is a bit cleaner as it separates performing the aux operation from which
> > blorp helper we have to call to do it.
> > ---
> >  src/intel/vulkan/anv_blorp.c   | 218 ++
> ---
> >  src/intel/vulkan/anv_private.h |  23 ++--
> >  src/intel/vulkan/genX_cmd_buffer.c |  28 +++--
> >  3 files changed, 165 insertions(+), 104 deletions(-)
> >
> > diff --git a/src/intel/vulkan/anv_blorp.c b/src/intel/vulkan/anv_blorp.c
> > index e244468..7c8a673 100644
> > --- a/src/intel/vulkan/anv_blorp.c
> > +++ b/src/intel/vulkan/anv_blorp.c
> > @@ -1439,75 +1439,6 @@ fast_clear_aux_usage(const struct anv_image
> *image,
> >  }
> >
> >  void
> > -anv_image_fast_clear(struct anv_cmd_buffer *cmd_buffer,
> > - const struct anv_image *image,
> > - VkImageAspectFlagBits aspect,
> > - const uint32_t base_level, const uint32_t
> level_count,
> > - const uint32_t base_layer, uint32_t layer_count)
> > -{
> > -   assert(image->type == VK_IMAGE_TYPE_3D || image->extent.depth == 1);
> > -
> > -   if (image->type == VK_IMAGE_TYPE_3D) {
> > -  assert(base_layer == 0);
> > -  assert(layer_count == anv_minify(image->extent.depth,
> base_level));
> > -   }
> > -
> > -   struct blorp_batch batch;
> > -   blorp_batch_init(_buffer->device->blorp, , cmd_buffer, 0);
> > -
> > -   struct blorp_surf surf;
> > -   get_blorp_surf_for_anv_image(cmd_buffer->device, image, aspect,
> > -fast_clear_aux_usage(image, aspect),
> > -);
> > -
> > -   /* From the Sky Lake PRM Vol. 7, "Render Target Fast Clear":
> > -*
> > -*"After Render target fast clear, pipe-control with color cache
> > -*write-flush must be issued before sending any DRAW commands on
> > -*that render target."
> > -*
> > -* This comment is a bit cryptic and doesn't really tell you what's
> going
> > -* or what's really needed.  It appears that fast clear ops are not
> > -* properly synchronized with other drawing.  This means that we
> cannot
> > -* have a fast clear operation in the pipe at the same time as other
> > -* regular drawing operations.  We need to use a PIPE_CONTROL to
> ensure
> > -* that the contents of the previous draw hit the render target
> before we
> > -* resolve and then use a second PIPE_CONTROL after the resolve to
> ensure
> > -* that it is completed before any additional drawing occurs.
> > -*/
> > -   cmd_buffer->state.pending_pipe_bits |=
> > -  ANV_PIPE_RENDER_TARGET_CACHE_FLUSH_BIT | ANV_PIPE_CS_STALL_BIT;
> > -
> > -   uint32_t plane = anv_image_aspect_to_plane(image->aspects, aspect);
> > -   uint32_t width_div = image->format->planes[plane].
> denominator_scales[0];
> > -   uint32_t height_div = image->format->planes[plane].
> denominator_scales[1];
> > -
> > -   for (uint32_t l = 0; l < level_count; l++) {
> > -  const uint32_t level = base_level + l;
> > -
> > -  const VkExtent3D extent = {
> > - .width = anv_minify(image->extent.width, level),
> > - .height = anv_minify(image->extent.height, level),
> > - .depth = anv_minify(image->extent.depth, level),
> > -  };
> > -
> > -  if (image->type == VK_IMAGE_TYPE_3D)
> > - layer_count = extent.depth;
> > -
> > -  assert(level < anv_image_aux_levels(image, aspect));
> > -  assert(base_layer + layer_count <= anv_image_aux_layers(image,
> aspect, level));
> > -  blorp_fast_clear(, , surf.surf->format,
> > -   level, base_layer, layer_count,
> > -   0, 0,
> > -   extent.width / width_div,
> > -   extent.height / height_div);
> > -   }
> > -
> > -   cmd_buffer->state.pending_pipe_bits |=
> > -  ANV_PIPE_RENDER_TARGET_CACHE_FLUSH_BIT | ANV_PIPE_CS_STALL_BIT;
> > -}
> > -
> > -void
> >  anv_cmd_buffer_resolve_subpass(struct anv_cmd_buffer *cmd_buffer)
> >  {
> > struct anv_framebuffer *fb = cmd_buffer->state.framebuffer;
> > @@ -1681,36 +1612,153 @@ anv_gen8_hiz_op_resolve(struct anv_cmd_buffer
> *cmd_buffer,
> >  }
> >
> >  void
> > -anv_ccs_resolve(struct anv_cmd_buffer * const cmd_buffer,
> > -const struct anv_image * const image,
> > -VkImageAspectFlagBits aspect,
> > -const uint8_t level,
> > -const uint32_t start_layer, const uint32_t layer_count,
> > -const enum blorp_fast_clear_op op)
> > +anv_image_mcs_op(struct anv_cmd_buffer *cmd_buffer,
> > + const struct anv_image *image,
> > + VkImageAspectFlagBits 

[Mesa-dev] [PATCH 06/10] i915: Use enum color_logic_ops for blits

[Ian Romanick]

From: Ian Romanick 

Signed-off-by: Ian Romanick 
---
 src/mesa/drivers/dri/i915/intel_blit.c | 34 ++
 src/mesa/drivers/dri/i915/intel_blit.h |  6 ++---
 src/mesa/drivers/dri/i915/intel_fbo.c  |  2 +-
 src/mesa/drivers/dri/i915/intel_mipmap_tree.c  |  6 ++---
 src/mesa/drivers/dri/i915/intel_pixel_bitmap.c |  4 +--
 src/mesa/drivers/dri/i915/intel_pixel_copy.c   |  2 +-
 src/mesa/drivers/dri/i915/intel_pixel_read.c   |  2 +-
 src/mesa/drivers/dri/i915/intel_tex_copy.c |  2 +-
 src/mesa/drivers/dri/i915/intel_tex_image.c|  2 +-
 src/mesa/drivers/dri/i915/intel_tex_subimage.c |  2 +-
 10 files changed, 22 insertions(+), 40 deletions(-)

diff --git a/src/mesa/drivers/dri/i915/intel_blit.c 
b/src/mesa/drivers/dri/i915/intel_blit.c
index 279db28..7e65197 100644
--- a/src/mesa/drivers/dri/i915/intel_blit.c
+++ b/src/mesa/drivers/dri/i915/intel_blit.c
@@ -48,27 +48,9 @@ intel_miptree_set_alpha_to_one(struct intel_context *intel,
struct intel_mipmap_tree *mt,
int x, int y, int width, int height);
 
-static GLuint translate_raster_op(GLenum logicop)
+static GLuint translate_raster_op(enum color_logic_ops logicop)
 {
-   switch(logicop) {
-   case GL_CLEAR: return 0x00;
-   case GL_AND: return 0x88;
-   case GL_AND_REVERSE: return 0x44;
-   case GL_COPY: return 0xCC;
-   case GL_AND_INVERTED: return 0x22;
-   case GL_NOOP: return 0xAA;
-   case GL_XOR: return 0x66;
-   case GL_OR: return 0xEE;
-   case GL_NOR: return 0x11;
-   case GL_EQUIV: return 0x99;
-   case GL_INVERT: return 0x55;
-   case GL_OR_REVERSE: return 0xDD;
-   case GL_COPY_INVERTED: return 0x33;
-   case GL_OR_INVERTED: return 0xBB;
-   case GL_NAND: return 0x77;
-   case GL_SET: return 0xFF;
-   default: return 0;
-   }
+   return logicop | (logicop << 4);
 }
 
 static uint32_t
@@ -114,7 +96,7 @@ intel_miptree_blit(struct intel_context *intel,
int dst_level, int dst_slice,
uint32_t dst_x, uint32_t dst_y, bool dst_flip,
uint32_t width, uint32_t height,
-   GLenum logicop)
+   enum color_logic_ops logicop)
 {
/* No sRGB decode or encode is done by the hardware blitter, which is
 * consistent with what we want in the callers (glCopyTexSubImage(),
@@ -227,7 +209,7 @@ intelEmitCopyBlit(struct intel_context *intel,
  GLshort src_x, GLshort src_y,
  GLshort dst_x, GLshort dst_y,
  GLshort w, GLshort h,
- GLenum logic_op)
+ enum color_logic_ops logic_op)
 {
GLuint CMD, BR13, pass = 0;
int dst_y2 = dst_y + h;
@@ -523,7 +505,7 @@ intelEmitImmediateColorExpandBlit(struct intel_context 
*intel,
  uint32_t dst_tiling,
  GLshort x, GLshort y,
  GLshort w, GLshort h,
- GLenum logic_op)
+ enum color_logic_ops logic_op)
 {
int dwords = ALIGN(src_size, 8) / 4;
uint32_t opcode, br13, blit_cmd;
@@ -535,7 +517,7 @@ intelEmitImmediateColorExpandBlit(struct intel_context 
*intel,
 return false;
}
 
-   assert((logic_op >= GL_CLEAR) && (logic_op <= (GL_CLEAR + 0x0f)));
+   assert((unsigned)logic_op <= 0x0f);
assert(dst_pitch > 0);
 
if (w < 0 || h < 0)
@@ -613,7 +595,7 @@ intel_emit_linear_blit(struct intel_context *intel,
  0, 0, /* src x/y */
  0, 0, /* dst x/y */
  pitch, height, /* w, h */
- GL_COPY);
+ COLOR_LOGICOP_COPY);
if (!ok)
   _mesa_problem(ctx, "Failed to linear blit %dx%d\n", pitch, height);
 
@@ -629,7 +611,7 @@ intel_emit_linear_blit(struct intel_context *intel,
 0, 0, /* src x/y */
 0, 0, /* dst x/y */
 size, 1, /* w, h */
-GL_COPY);
+COLOR_LOGICOP_COPY);
   if (!ok)
  _mesa_problem(ctx, "Failed to linear blit %dx%d\n", size, 1);
}
diff --git a/src/mesa/drivers/dri/i915/intel_blit.h 
b/src/mesa/drivers/dri/i915/intel_blit.h
index 1e76126..3144541 100644
--- a/src/mesa/drivers/dri/i915/intel_blit.h
+++ b/src/mesa/drivers/dri/i915/intel_blit.h
@@ -49,7 +49,7 @@ intelEmitCopyBlit(struct intel_context *intel,
   GLshort srcx, GLshort srcy,
   GLshort dstx, GLshort dsty,
   GLshort w, GLshort h,
- GLenum logicop );
+  enum color_logic_ops logicop);
 
 bool intel_miptree_blit(struct intel_context *intel,
 struct intel_mipmap_tree *src_mt,
@@ -59,7 +59,7 @@ bool 

[Mesa-dev] [PATCH 09/10] i915: Silence unused parameter warnings

[Ian Romanick]

From: Ian Romanick 

../../SOURCE/master/src/mesa/drivers/dri/i915/intel_fbo.c: In function 
‘intel_alloc_window_storage’:
../../SOURCE/master/src/mesa/drivers/dri/i915/intel_fbo.c:290:48: warning: 
unused parameter ‘ctx’ [-Wunused-parameter]
 intel_alloc_window_storage(struct gl_context * ctx, struct gl_renderbuffer *rb,
^~~
../../SOURCE/master/src/mesa/drivers/dri/i915/intel_fbo.c: In function 
‘intel_nop_alloc_storage’:
../../SOURCE/master/src/mesa/drivers/dri/i915/intel_fbo.c:303:74: warning: 
unused parameter ‘rb’ [-Wunused-parameter]
 intel_nop_alloc_storage(struct gl_context * ctx, struct gl_renderbuffer *rb,
  ^~
../../SOURCE/master/src/mesa/drivers/dri/i915/intel_fbo.c:304:32: warning: 
unused parameter ‘internalFormat’ [-Wunused-parameter]
 GLenum internalFormat, GLuint width, GLuint height)
^~
../../SOURCE/master/src/mesa/drivers/dri/i915/intel_fbo.c:304:55: warning: 
unused parameter ‘width’ [-Wunused-parameter]
 GLenum internalFormat, GLuint width, GLuint height)
   ^
../../SOURCE/master/src/mesa/drivers/dri/i915/intel_fbo.c:304:69: warning: 
unused parameter ‘height’ [-Wunused-parameter]
 GLenum internalFormat, GLuint width, GLuint height)
 ^~
../../SOURCE/master/src/mesa/drivers/dri/i915/intel_fbo.c: In function 
‘intel_bind_framebuffer’:
../../SOURCE/master/src/mesa/drivers/dri/i915/intel_fbo.c:396:47: warning: 
unused parameter ‘fb’ [-Wunused-parameter]
struct gl_framebuffer *fb, struct gl_framebuffer 
*fbread)
   ^~
../../SOURCE/master/src/mesa/drivers/dri/i915/intel_fbo.c:396:74: warning: 
unused parameter ‘fbread’ [-Wunused-parameter]
struct gl_framebuffer *fb, struct gl_framebuffer 
*fbread)
  ^~
../../SOURCE/master/src/mesa/drivers/dri/i915/intel_fbo.c: In function 
‘intel_renderbuffer_update_wrapper’:
../../SOURCE/master/src/mesa/drivers/dri/i915/intel_fbo.c:422:57: warning: 
unused parameter ‘intel’ [-Wunused-parameter]
 intel_renderbuffer_update_wrapper(struct intel_context *intel,
 ^
../../SOURCE/master/src/mesa/drivers/dri/i915/intel_fbo.c: In function 
‘intel_blit_framebuffer_with_blitter’:
../../SOURCE/master/src/mesa/drivers/dri/i915/intel_fbo.c:644:61: warning: 
unused parameter ‘filter’ [-Wunused-parameter]
 GLbitfield mask, GLenum filter)
 ^~

Signed-off-by: Ian Romanick 
---
 src/mesa/drivers/dri/i915/intel_fbo.c | 21 +++--
 1 file changed, 11 insertions(+), 10 deletions(-)

diff --git a/src/mesa/drivers/dri/i915/intel_fbo.c 
b/src/mesa/drivers/dri/i915/intel_fbo.c
index 0fb2fcd..827a77f 100644
--- a/src/mesa/drivers/dri/i915/intel_fbo.c
+++ b/src/mesa/drivers/dri/i915/intel_fbo.c
@@ -287,7 +287,7 @@ intel_image_target_renderbuffer_storage(struct gl_context 
*ctx,
  * intel_process_dri2_buffer().
  */
 static GLboolean
-intel_alloc_window_storage(struct gl_context * ctx, struct gl_renderbuffer *rb,
+intel_alloc_window_storage(UNUSED struct gl_context *ctx, struct 
gl_renderbuffer *rb,
GLenum internalFormat, GLuint width, GLuint height)
 {
assert(rb->Name == 0);
@@ -300,8 +300,10 @@ intel_alloc_window_storage(struct gl_context * ctx, struct 
gl_renderbuffer *rb,
 
 /** Dummy function for gl_renderbuffer::AllocStorage() */
 static GLboolean
-intel_nop_alloc_storage(struct gl_context * ctx, struct gl_renderbuffer *rb,
-GLenum internalFormat, GLuint width, GLuint height)
+intel_nop_alloc_storage(UNUSED struct gl_context *ctx,
+UNUSED struct gl_renderbuffer *rb,
+UNUSED GLenum internalFormat,
+UNUSED GLuint width, UNUSED GLuint height)
 {
_mesa_problem(ctx, "intel_op_alloc_storage should never be called.");
return false;
@@ -393,7 +395,8 @@ intel_new_renderbuffer(struct gl_context * ctx, GLuint name)
  */
 static void
 intel_bind_framebuffer(struct gl_context * ctx, GLenum target,
-   struct gl_framebuffer *fb, struct gl_framebuffer 
*fbread)
+   UNUSED struct gl_framebuffer *fb,
+   UNUSED struct gl_framebuffer *fbread)
 {
if (target == GL_FRAMEBUFFER_EXT || target == GL_DRAW_FRAMEBUFFER_EXT) {
   intel_draw_buffer(ctx);
@@ -419,8 +422,7 @@ intel_framebuffer_renderbuffer(struct gl_context * ctx,
 }
 
 static bool

[Mesa-dev] [PATCH 01/10] mesa: Also track a remapped version of the color logic op

[Ian Romanick]

From: Ian Romanick 

With the exception of NVIDIA hardware, these are is the values that all
hardware and Gallium want.  The remapping is currently implemented in at
least 6 places.  This starts the process of consolidating to a single
place.

Signed-off-by: Ian Romanick 
---
 src/mesa/main/blend.c  | 22 ++
 src/mesa/main/mtypes.h | 29 +
 2 files changed, 51 insertions(+)

diff --git a/src/mesa/main/blend.c b/src/mesa/main/blend.c
index 01721ab..f47b102 100644
--- a/src/mesa/main/blend.c
+++ b/src/mesa/main/blend.c
@@ -849,6 +849,26 @@ _mesa_AlphaFunc( GLenum func, GLclampf ref )
}
 }
 
+static const enum color_logic_ops color_logicop_mapping[16] = {
+   COLOR_LOGICOP_CLEAR,
+   COLOR_LOGICOP_AND,
+   COLOR_LOGICOP_AND_REVERSE,
+   COLOR_LOGICOP_COPY,
+   COLOR_LOGICOP_AND_INVERTED,
+   COLOR_LOGICOP_NOOP,
+   COLOR_LOGICOP_XOR,
+   COLOR_LOGICOP_OR,
+   COLOR_LOGICOP_NOR,
+   COLOR_LOGICOP_EQUIV,
+   COLOR_LOGICOP_INVERT,
+   COLOR_LOGICOP_OR_REVERSE,
+   COLOR_LOGICOP_COPY_INVERTED,
+   COLOR_LOGICOP_OR_INVERTED,
+   COLOR_LOGICOP_NAND,
+   COLOR_LOGICOP_SET
+};
+
+#define GLenum_to_color_logicop(x) color_logicop_mapping[x & 0x0f]
 
 static ALWAYS_INLINE void
 logic_op(struct gl_context *ctx, GLenum opcode, bool no_error)
@@ -884,6 +904,7 @@ logic_op(struct gl_context *ctx, GLenum opcode, bool 
no_error)
FLUSH_VERTICES(ctx, ctx->DriverFlags.NewLogicOp ? 0 : _NEW_COLOR);
ctx->NewDriverState |= ctx->DriverFlags.NewLogicOp;
ctx->Color.LogicOp = opcode;
+   ctx->Color._LogicOp = GLenum_to_color_logicop(opcode);
 
if (ctx->Driver.LogicOpcode)
   ctx->Driver.LogicOpcode(ctx, opcode);
@@ -1189,6 +1210,7 @@ void _mesa_init_color( struct gl_context * ctx )
ctx->Color.IndexLogicOpEnabled = GL_FALSE;
ctx->Color.ColorLogicOpEnabled = GL_FALSE;
ctx->Color.LogicOp = GL_COPY;
+   ctx->Color._LogicOp = COLOR_LOGICOP_COPY;
ctx->Color.DitherFlag = GL_TRUE;
 
/* GL_FRONT is not possible on GLES. Instead GL_BACK will render to either
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 226eb94..2fbfd27 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -418,6 +418,34 @@ union gl_color_union
GLuint ui[4];
 };
 
+/**
+ * Remapped color logical operations
+ *
+ * With the exception of NVIDIA hardware, which consumes the OpenGL enumerants
+ * directly, everything wants this mapping of color logical operations.
+ *
+ * Fun fact: These values are just the bit-reverse of the low-nibble of the GL
+ * enumerant values (i.e., `GL_NOOP & 0x0f` is `b0101' while
+ * \c COLOR_LOGICOP_NOOP is `b1010`).
+ */
+enum PACKED color_logic_ops {
+   COLOR_LOGICOP_CLEAR = 0,
+   COLOR_LOGICOP_NOR = 1,
+   COLOR_LOGICOP_AND_INVERTED = 2,
+   COLOR_LOGICOP_COPY_INVERTED = 3,
+   COLOR_LOGICOP_AND_REVERSE = 4,
+   COLOR_LOGICOP_INVERT = 5,
+   COLOR_LOGICOP_XOR = 6,
+   COLOR_LOGICOP_NAND = 7,
+   COLOR_LOGICOP_AND = 8,
+   COLOR_LOGICOP_EQUIV = 9,
+   COLOR_LOGICOP_NOOP = 10,
+   COLOR_LOGICOP_OR_INVERTED = 11,
+   COLOR_LOGICOP_COPY = 12,
+   COLOR_LOGICOP_OR_REVERSE = 13,
+   COLOR_LOGICOP_OR = 14,
+   COLOR_LOGICOP_SET = 15
+};
 
 /**
  * Color buffer attribute group (GL_COLOR_BUFFER_BIT).
@@ -493,6 +521,7 @@ struct gl_colorbuffer_attrib
GLboolean IndexLogicOpEnabled;  /**< Color index logic op enabled flag 
*/
GLboolean ColorLogicOpEnabled;  /**< RGBA logic op enabled flag */
GLenum LogicOp; /**< Logic operator */
+   enum color_logic_ops _LogicOp;
 
/*@}*/
 
-- 
2.9.5

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

[Mesa-dev] [PATCH 10/10] nouveau: Remove no-op nvgl_logicop_func function

[Ian Romanick]

From: Ian Romanick 

The values that this function returned were always the values passed
in.  The only thing that happened was either an assertion or undefined
results when an unknown value was passed in.  This doesn't seem that
useful.  Most of nouveau_gldefs.h could be removed in this manner.

Signed-off-by: Ian Romanick 
---
 src/mesa/drivers/dri/nouveau/nouveau_gldefs.h| 41 
 src/mesa/drivers/dri/nouveau/nv10_state_raster.c |  2 +-
 src/mesa/drivers/dri/nouveau/nv20_state_raster.c |  2 +-
 3 files changed, 2 insertions(+), 43 deletions(-)

diff --git a/src/mesa/drivers/dri/nouveau/nouveau_gldefs.h 
b/src/mesa/drivers/dri/nouveau/nouveau_gldefs.h
index 7df04c1..11c3dbd 100644
--- a/src/mesa/drivers/dri/nouveau/nouveau_gldefs.h
+++ b/src/mesa/drivers/dri/nouveau/nouveau_gldefs.h
@@ -86,47 +86,6 @@ nvgl_blend_eqn(unsigned eqn)
 }
 
 static inline unsigned
-nvgl_logicop_func(unsigned func)
-{
-   switch (func) {
-   case GL_CLEAR:
-   return 0x1500;
-   case GL_NOR:
-   return 0x1508;
-   case GL_AND_INVERTED:
-   return 0x1504;
-   case GL_COPY_INVERTED:
-   return 0x150c;
-   case GL_AND_REVERSE:
-   return 0x1502;
-   case GL_INVERT:
-   return 0x150a;
-   case GL_XOR:
-   return 0x1506;
-   case GL_NAND:
-   return 0x150e;
-   case GL_AND:
-   return 0x1501;
-   case GL_EQUIV:
-   return 0x1509;
-   case GL_NOOP:
-   return 0x1505;
-   case GL_OR_INVERTED:
-   return 0x150d;
-   case GL_COPY:
-   return 0x1503;
-   case GL_OR_REVERSE:
-   return 0x150b;
-   case GL_OR:
-   return 0x1507;
-   case GL_SET:
-   return 0x150f;
-   default:
-   assert(0);
-   }
-}
-
-static inline unsigned
 nvgl_comparison_op(unsigned op)
 {
switch (op) {
diff --git a/src/mesa/drivers/dri/nouveau/nv10_state_raster.c 
b/src/mesa/drivers/dri/nouveau/nv10_state_raster.c
index d537f7b..047f539 100644
--- a/src/mesa/drivers/dri/nouveau/nv10_state_raster.c
+++ b/src/mesa/drivers/dri/nouveau/nv10_state_raster.c
@@ -126,7 +126,7 @@ nv10_emit_logic_opcode(struct gl_context *ctx, int emit)
 
BEGIN_NV04(push, NV11_3D(COLOR_LOGIC_OP_ENABLE), 2);
PUSH_DATAb(push, ctx->Color.ColorLogicOpEnabled);
-   PUSH_DATA (push, nvgl_logicop_func(ctx->Color.LogicOp));
+   PUSH_DATA (push, ctx->Color.LogicOp);
 }
 
 void
diff --git a/src/mesa/drivers/dri/nouveau/nv20_state_raster.c 
b/src/mesa/drivers/dri/nouveau/nv20_state_raster.c
index 4856053..c24c5bb 100644
--- a/src/mesa/drivers/dri/nouveau/nv20_state_raster.c
+++ b/src/mesa/drivers/dri/nouveau/nv20_state_raster.c
@@ -38,5 +38,5 @@ nv20_emit_logic_opcode(struct gl_context *ctx, int emit)
 
BEGIN_NV04(push, NV20_3D(COLOR_LOGIC_OP_ENABLE), 2);
PUSH_DATAb(push, ctx->Color.ColorLogicOpEnabled);
-   PUSH_DATA (push, nvgl_logicop_func(ctx->Color.LogicOp));
+   PUSH_DATA (push, ctx->Color.LogicOp);
 }
-- 
2.9.5

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

Re: [Mesa-dev] [PATCH 17/17] vbo: optimize some display list drawing

[Ian Romanick]

On 01/12/2018 02:23 PM, Brian Paul wrote:
> The vbo_save_vertex_list structure records one or more glBegin/End
> primitives which all have the same vertex format.
> 
> To draw these primitives, we setup the vertex array state, then
> issue the drawing command.  Before, the 'start' vertex was typically
> zero and we used the vertex array pointer to indicate where the
> vertex data starts.
> 
> This patch checks if the vertex buffer offset is an exact multiple of
> the vertex size.  If so, that means we can use zero-based vertex array
> pointers and use the draw's start value to indicate where the vertex
> data starts.
> 
> This means a series of display list drawing commands may have
> identical vertex array state.  This will get filtered out by the
> Gallium CSO module so we can issue a tight series of drawing commands
> without state changes to the device.
> 
> Note that this also works for a series of glCallList commands (not
> just one list that contains multiple glBegin/End pairs).
> 
> No Piglit or conform changes.

Do you know if any of these tests actually hit these paths?  I always
worry about changes to display list handing because there is so little
testing. :(

A few nits below.

> ---
>  src/mesa/vbo/vbo_save.h  | 17 +
>  src/mesa/vbo/vbo_save_api.c  | 15 +++
>  src/mesa/vbo/vbo_save_draw.c | 12 
>  3 files changed, 44 insertions(+)
> 
> diff --git a/src/mesa/vbo/vbo_save.h b/src/mesa/vbo/vbo_save.h
> index 9d13e0a..468a04a 100644
> --- a/src/mesa/vbo/vbo_save.h
> +++ b/src/mesa/vbo/vbo_save.h
> @@ -86,6 +86,23 @@ struct vbo_save_vertex_list {
> struct vbo_save_primitive_store *prim_store;
>  };
>  
> +
> +/**
> + * Is the vertex lists's buffer offset an exact multiple of the
> + * vertex size (in bytes)?  This is used to check for a vertex array /
> + * drawing optimization.
> + */
> +static inline bool
> +aligned_vertex_buffer_offset(const struct vbo_save_vertex_list *node)
> +{
> +   unsigned vertex_size = node->vertex_size * sizeof(GLfloat); /* in bytes */
> +   if (vertex_size)
> +  return node->buffer_offset % vertex_size == 0;
> +   else
> +  return false;

I think this would be more clear as

   return vertex_size != 0 && node->buffer_offset % vertex_size == 0;

> +}
> +
> +
>  /* These buffers should be a reasonable size to support upload to
>   * hardware.  Current vbo implementation will re-upload on any
>   * changes, so don't make too big or apps which dynamically create
> diff --git a/src/mesa/vbo/vbo_save_api.c b/src/mesa/vbo/vbo_save_api.c
> index 42d883f..b9d382a 100644
> --- a/src/mesa/vbo/vbo_save_api.c
> +++ b/src/mesa/vbo/vbo_save_api.c
> @@ -546,6 +546,21 @@ compile_vertex_list(struct gl_context *ctx)
>save->prim_store = alloc_prim_store();
> }
>  
> +   /**

The Doxygen /** start marker doesn't do anything useful here.

> +* If the vertex buffer offset is a multiple of the vertex size,
> +* we can use the _mesa_prim::start value to indicate where the
> +* vertices starts, instead of the buffer offset.  Also see the
> +* bind_vertex_list() function.
> +*/
> +   if (aligned_vertex_buffer_offset(node)) {
> +  const unsigned start_offset =
> + node->buffer_offset / (node->vertex_size * sizeof(GLfloat));
> +  unsigned i;
> +  for (i = 0; i < save->prim_count; i++) {
> + save->prims[i].start += start_offset;
> +  }

I believe the currently common style is:

  for (unsigned i = 0; i < save->prim_count; i++)
 save->prims[i].start += start_offset;

> +   }
> +
> /* Reset our structures for the next run of vertices:
>  */
> reset_counters(ctx);
> diff --git a/src/mesa/vbo/vbo_save_draw.c b/src/mesa/vbo/vbo_save_draw.c
> index 1694a04..b63a9a8 100644
> --- a/src/mesa/vbo/vbo_save_draw.c
> +++ b/src/mesa/vbo/vbo_save_draw.c
> @@ -146,6 +146,18 @@ bind_vertex_list(struct gl_context *ctx,
> memcpy(node_attrsz, node->attrsz, sizeof(node->attrsz));
> memcpy(node_attrtype, node->attrtype, sizeof(node->attrtype));
>  
> +   if (aligned_vertex_buffer_offset(node)) {
> +  /* The vertex size is an exact multiple of the buffer offset.
> +   * This means that we can use zero-based vertex attribute pointers
> +   * and specify the start of the primitive with the _mesa_prim::start
> +   * field.  This results in issuing several draw calls with identical
> +   * vertex attribute information.  This can result in fewer state
> +   * changes in drivers.  In particular, the Gallium CSO module will
> +   * filter out redundant vertex buffer changes.
> +   */
> +  buffer_offset = 0;
> +   }
> +
> /* Install the default (ie Current) attributes first, then overlay
>  * all active ones.
>  */
> 

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

Re: [Mesa-dev] [PATCH 01/17] vbo: whitespace fixes in vbo_save_draw.c

[Ian Romanick]

Patches 1 - 16 are

Reviewed-by: Ian Romanick 

I sent some comments / questions on patch 17.

On 01/12/2018 02:23 PM, Brian Paul wrote:
> ---
>  src/mesa/vbo/vbo_save_draw.c | 61 
> ++--
>  1 file changed, 31 insertions(+), 30 deletions(-)
> 
> diff --git a/src/mesa/vbo/vbo_save_draw.c b/src/mesa/vbo/vbo_save_draw.c
> index 2a20bb8..17eff9b 100644
> --- a/src/mesa/vbo/vbo_save_draw.c
> +++ b/src/mesa/vbo/vbo_save_draw.c
> @@ -63,14 +63,14 @@ _playback_copy_to_current(struct gl_context *ctx,
>data = vertex;
>  
>if (node->count)
> - offset = (node->buffer_offset + 
> -   (node->count-1) * node->vertex_size * sizeof(GLfloat));
> + offset = (node->buffer_offset +
> +   (node->count - 1) * node->vertex_size * sizeof(GLfloat));
>else
>   offset = node->buffer_offset;
>  
> -  ctx->Driver.GetBufferSubData( ctx, offset,
> -node->vertex_size * sizeof(GLfloat), 
> -data, node->vertex_store->bufferobj );
> +  ctx->Driver.GetBufferSubData(ctx, offset,
> +   node->vertex_size * sizeof(GLfloat),
> +   data, node->vertex_store->bufferobj);
>  
>data += node->attrsz[0]; /* skip vertex position */
> }
> @@ -90,7 +90,7 @@ _playback_copy_to_current(struct gl_context *ctx,
>if (node->attrtype[i] != vbo->currval[i].Type ||
>memcmp(current, tmp, 4 * sizeof(GLfloat)) != 0) {
>   memcpy(current, tmp, 4 * sizeof(GLfloat));
> - 
> +
>   vbo->currval[i].Size = node->attrsz[i];
>   vbo->currval[i]._ElementSize = vbo->currval[i].Size * 
> sizeof(GLfloat);
>   vbo->currval[i].Type = node->attrtype[i];
> @@ -118,9 +118,9 @@ _playback_copy_to_current(struct gl_context *ctx,
> if (node->prim_count) {
>const struct _mesa_prim *prim = >prim[node->prim_count - 1];
>if (prim->end)
> -  ctx->Driver.CurrentExecPrimitive = PRIM_OUTSIDE_BEGIN_END;
> + ctx->Driver.CurrentExecPrimitive = PRIM_OUTSIDE_BEGIN_END;
>else
> -  ctx->Driver.CurrentExecPrimitive = prim->mode;
> + ctx->Driver.CurrentExecPrimitive = prim->mode;
> }
>  }
>  
> @@ -130,8 +130,9 @@ _playback_copy_to_current(struct gl_context *ctx,
>   * Treat the vertex storage as a VBO, define vertex arrays pointing
>   * into it:
>   */
> -static void vbo_bind_vertex_list(struct gl_context *ctx,
> - const struct vbo_save_vertex_list *node)
> +static void
> +vbo_bind_vertex_list(struct gl_context *ctx,
> + const struct vbo_save_vertex_list *node)
>  {
> struct vbo_context *vbo = vbo_context(ctx);
> struct vbo_save_context *save = >save;
> @@ -195,9 +196,9 @@ static void vbo_bind_vertex_list(struct gl_context *ctx,
>   /* override the default array set above */
>   save->inputs[attr] = [attr];
>  
> -  arrays[attr].Ptr = (const GLubyte *) NULL + buffer_offset;
> -  arrays[attr].Size = node_attrsz[src];
> -  arrays[attr].StrideB = node->vertex_size * sizeof(GLfloat);
> + arrays[attr].Ptr = (const GLubyte *) NULL + buffer_offset;
> + arrays[attr].Size = node_attrsz[src];
> + arrays[attr].StrideB = node->vertex_size * sizeof(GLfloat);
>   arrays[attr].Type = node_attrtype[src];
>   arrays[attr].Integer =
> vbo_attrtype_to_integer_flag(node_attrtype[src]);
> @@ -206,15 +207,15 @@ static void vbo_bind_vertex_list(struct gl_context *ctx,
>   _mesa_reference_buffer_object(ctx,
> [attr].BufferObj,
> node->vertex_store->bufferobj);
> -  
> -  assert(arrays[attr].BufferObj->Name);
>  
> -  buffer_offset += node_attrsz[src] * sizeof(GLfloat);
> + assert(arrays[attr].BufferObj->Name);
> +
> + buffer_offset += node_attrsz[src] * sizeof(GLfloat);
>   varying_inputs |= VERT_BIT(attr);
>}
> }
>  
> -   _mesa_set_varying_vp_inputs( ctx, varying_inputs );
> +   _mesa_set_varying_vp_inputs(ctx, varying_inputs);
> ctx->NewDriverState |= ctx->DriverFlags.NewArray;
>  }
>  
> @@ -225,9 +226,9 @@ vbo_save_loopback_vertex_list(struct gl_context *ctx,
>  {
> const char *buffer =
>ctx->Driver.MapBufferRange(ctx, 0,
> -  list->vertex_store->bufferobj->Size,
> -  GL_MAP_READ_BIT, /* ? */
> -  list->vertex_store->bufferobj,
> + list->vertex_store->bufferobj->Size,
> + GL_MAP_READ_BIT, /* ? */
> + list->vertex_store->bufferobj,
>   MAP_INTERNAL);
>  
> vbo_loopback_vertex_list(ctx,
> @@ -281,16 +282,16 @@ 

Re: [Mesa-dev] [PATCH 19/29] anv/cmd_buffer: Move the rest of clear_subpass into begin_subpass

[Nanley Chery]

On Mon, Nov 27, 2017 at 07:06:09PM -0800, Jason Ekstrand wrote:
> ---
>  src/intel/vulkan/anv_blorp.c   | 243 
> -
>  src/intel/vulkan/anv_private.h |  17 ++-
>  src/intel/vulkan/genX_cmd_buffer.c |  68 ++-
>  3 files changed, 188 insertions(+), 140 deletions(-)
> 
> diff --git a/src/intel/vulkan/anv_blorp.c b/src/intel/vulkan/anv_blorp.c
> index 7401234..45d7b12 100644
> --- a/src/intel/vulkan/anv_blorp.c
> +++ b/src/intel/vulkan/anv_blorp.c
> @@ -1132,143 +1132,6 @@ enum subpass_stage {
> SUBPASS_STAGE_RESOLVE,
>  };
>  
> -static bool
> -subpass_needs_clear(const struct anv_cmd_buffer *cmd_buffer)
> -{
> -   const struct anv_cmd_state *cmd_state = _buffer->state;
> -   uint32_t ds = cmd_state->subpass->depth_stencil_attachment.attachment;
> -
> -   if (ds != VK_ATTACHMENT_UNUSED) {
> -  assert(ds < cmd_state->pass->attachment_count);
> -  if (cmd_state->attachments[ds].pending_clear_aspects)
> - return true;
> -   }
> -
> -   return false;
> -}
> -
> -void
> -anv_cmd_buffer_clear_subpass(struct anv_cmd_buffer *cmd_buffer)
> -{
> -   const struct anv_cmd_state *cmd_state = _buffer->state;
> -   const VkRect2D render_area = cmd_buffer->state.render_area;
> -
> -
> -   if (!subpass_needs_clear(cmd_buffer))
> -  return;
> -
> -   /* Because this gets called within a render pass, we tell blorp not to
> -* trash our depth and stencil buffers.
> -*/
> -   struct blorp_batch batch;
> -   blorp_batch_init(_buffer->device->blorp, , cmd_buffer,
> -BLORP_BATCH_NO_EMIT_DEPTH_STENCIL);
> -
> -   VkClearRect clear_rect = {
> -  .rect = cmd_buffer->state.render_area,
> -  .baseArrayLayer = 0,
> -  .layerCount = cmd_buffer->state.framebuffer->layers,
> -   };
> -
> -   struct anv_framebuffer *fb = cmd_buffer->state.framebuffer;
> -
> -   const uint32_t ds = 
> cmd_state->subpass->depth_stencil_attachment.attachment;
> -   assert(ds == VK_ATTACHMENT_UNUSED || ds < 
> cmd_state->pass->attachment_count);
> -
> -   if (ds != VK_ATTACHMENT_UNUSED &&
> -   cmd_state->attachments[ds].pending_clear_aspects) {
> -
> -  VkClearAttachment clear_att = {
> - .aspectMask = cmd_state->attachments[ds].pending_clear_aspects,
> - .clearValue = cmd_state->attachments[ds].clear_value,
> -  };
> -
> -
> -  const uint8_t gen = cmd_buffer->device->info.gen;
> -  bool clear_with_hiz = gen >= 8 && cmd_state->attachments[ds].aux_usage 
> ==
> -ISL_AUX_USAGE_HIZ;
> -  const struct anv_image_view *iview = fb->attachments[ds];
> -
> -  if (clear_with_hiz) {
> - const bool clear_depth = clear_att.aspectMask &
> -  VK_IMAGE_ASPECT_DEPTH_BIT;
> - const bool clear_stencil = clear_att.aspectMask &
> -VK_IMAGE_ASPECT_STENCIL_BIT;
> -
> - /* Check against restrictions for depth buffer clearing. A great GPU
> -  * performance benefit isn't expected when using the HZ sequence for
> -  * stencil-only clears. Therefore, we don't emit a HZ op sequence 
> for
> -  * a stencil clear in addition to using the BLORP-fallback for 
> depth.
> -  */
> - if (clear_depth) {
> -if (!blorp_can_hiz_clear_depth(gen, iview->planes[0].isl.format,
> -   iview->image->samples,
> -   render_area.offset.x,
> -   render_area.offset.y,
> -   render_area.offset.x +
> -   render_area.extent.width,
> -   render_area.offset.y +
> -   render_area.extent.height)) {
> -   clear_with_hiz = false;
> -} else if (clear_att.clearValue.depthStencil.depth !=
> -   ANV_HZ_FC_VAL) {
> -   /* Don't enable fast depth clears for any color not equal to
> -* ANV_HZ_FC_VAL.
> -*/
> -   clear_with_hiz = false;
> -} else if (gen == 8 &&
> -   anv_can_sample_with_hiz(_buffer->device->info,
> -   iview->image)) {
> -   /* Only gen9+ supports returning ANV_HZ_FC_VAL when sampling a
> -* fast-cleared portion of a HiZ buffer. Testing has revealed
> -* that Gen8 only supports returning 0.0f. Gens prior to gen8 
> do
> -* not support this feature at all.
> -*/
> -   clear_with_hiz = false;
> -}
> - }
> -
> - if (clear_with_hiz) {
> -blorp_gen8_hiz_clear_attachments(, iview->image->samples,
> - render_area.offset.x,
> - 

[Mesa-dev] [PATCH 14/17] vbo: rename some functions in vbo_save_api.c

[Brian Paul]

---
 src/mesa/vbo/vbo_save_api.c | 74 ++---
 1 file changed, 37 insertions(+), 37 deletions(-)

diff --git a/src/mesa/vbo/vbo_save_api.c b/src/mesa/vbo/vbo_save_api.c
index cb48cb8..8eb3846 100644
--- a/src/mesa/vbo/vbo_save_api.c
+++ b/src/mesa/vbo/vbo_save_api.c
@@ -99,9 +99,9 @@ USE OR OTHER DEALINGS IN THE SOFTWARE.
  * wrong-footed on replay.
  */
 static GLuint
-_save_copy_vertices(struct gl_context *ctx,
-const struct vbo_save_vertex_list *node,
-const fi_type * src_buffer)
+copy_vertices(struct gl_context *ctx,
+  const struct vbo_save_vertex_list *node,
+  const fi_type * src_buffer)
 {
struct vbo_save_context *save = _context(ctx)->save;
const struct _mesa_prim *prim = >prims[node->prim_count - 1];
@@ -305,7 +305,7 @@ alloc_prim_store(void)
 
 
 static void
-_save_reset_counters(struct gl_context *ctx)
+reset_counters(struct gl_context *ctx)
 {
struct vbo_save_context *save = _context(ctx)->save;
 
@@ -411,7 +411,7 @@ convert_line_loop_to_strip(struct vbo_save_context *save,
  * being built.
  */
 static void
-_save_compile_vertex_list(struct gl_context *ctx)
+compile_vertex_list(struct gl_context *ctx)
 {
struct vbo_save_context *save = _context(ctx)->save;
struct vbo_save_vertex_list *node;
@@ -486,7 +486,7 @@ _save_compile_vertex_list(struct gl_context *ctx)
 
/* Copy duplicated vertices
 */
-   save->copied.nr = _save_copy_vertices(ctx, node, save->buffer_map);
+   save->copied.nr = copy_vertices(ctx, node, save->buffer_map);
 
if (node->prims[node->prim_count - 1].mode == GL_LINE_LOOP) {
   convert_line_loop_to_strip(save, node);
@@ -548,7 +548,7 @@ _save_compile_vertex_list(struct gl_context *ctx)
 
/* Reset our structures for the next run of vertices:
 */
-   _save_reset_counters(ctx);
+   reset_counters(ctx);
 }
 
 
@@ -558,7 +558,7 @@ _save_compile_vertex_list(struct gl_context *ctx)
  * TODO -- If no new vertices have been stored, don't bother saving it.
  */
 static void
-_save_wrap_buffers(struct gl_context *ctx)
+wrap_buffers(struct gl_context *ctx)
 {
struct vbo_save_context *save = _context(ctx)->save;
GLint i = save->prim_count - 1;
@@ -578,7 +578,7 @@ _save_wrap_buffers(struct gl_context *ctx)
 
/* store the copied vertices, and allocate a new list.
 */
-   _save_compile_vertex_list(ctx);
+   compile_vertex_list(ctx);
 
/* Restart interrupted primitive
 */
@@ -602,14 +602,14 @@ _save_wrap_buffers(struct gl_context *ctx)
  * vertex_store struct.
  */
 static void
-_save_wrap_filled_vertex(struct gl_context *ctx)
+wrap_filled_vertex(struct gl_context *ctx)
 {
struct vbo_save_context *save = _context(ctx)->save;
unsigned numComponents;
 
/* Emit a glEnd to close off the last vertex list.
 */
-   _save_wrap_buffers(ctx);
+   wrap_buffers(ctx);
 
/* Copy stored stored vertices to start of new list.
 */
@@ -625,7 +625,7 @@ _save_wrap_filled_vertex(struct gl_context *ctx)
 
 
 static void
-_save_copy_to_current(struct gl_context *ctx)
+copy_to_current(struct gl_context *ctx)
 {
struct vbo_save_context *save = _context(ctx)->save;
GLbitfield64 enabled = save->enabled & (~BITFIELD64_BIT(VBO_ATTRIB_POS));
@@ -642,7 +642,7 @@ _save_copy_to_current(struct gl_context *ctx)
 
 
 static void
-_save_copy_from_current(struct gl_context *ctx)
+copy_from_current(struct gl_context *ctx)
 {
struct vbo_save_context *save = _context(ctx)->save;
GLbitfield64 enabled = save->enabled & (~BITFIELD64_BIT(VBO_ATTRIB_POS));
@@ -675,7 +675,7 @@ _save_copy_from_current(struct gl_context *ctx)
  * Flush existing data, set new attrib size, replay copied vertices.
  */
 static void
-_save_upgrade_vertex(struct gl_context *ctx, GLuint attr, GLuint newsz)
+upgrade_vertex(struct gl_context *ctx, GLuint attr, GLuint newsz)
 {
struct vbo_save_context *save = _context(ctx)->save;
GLuint oldsz;
@@ -686,7 +686,7 @@ _save_upgrade_vertex(struct gl_context *ctx, GLuint attr, 
GLuint newsz)
 * BEGIN in the new buffer.
 */
if (save->vert_count)
-  _save_wrap_buffers(ctx);
+  wrap_buffers(ctx);
else
   assert(save->copied.nr == 0);
 
@@ -694,7 +694,7 @@ _save_upgrade_vertex(struct gl_context *ctx, GLuint attr, 
GLuint newsz)
 * when the attribute already exists in the vertex and is having
 * its size increased.
 */
-   _save_copy_to_current(ctx);
+   copy_to_current(ctx);
 
/* Fix up sizes:
 */
@@ -722,7 +722,7 @@ _save_upgrade_vertex(struct gl_context *ctx, GLuint attr, 
GLuint newsz)
 
/* Copy from current to repopulate the vertex with correct values.
 */
-   _save_copy_from_current(ctx);
+   copy_from_current(ctx);
 
/* Replay stored vertices to translate them to new format here.
 *
@@ -779,7 +779,7 @@ _save_upgrade_vertex(struct gl_context *ctx, GLuint attr, 
GLuint newsz)
  * get a glTexCoord4f() or glTexCoord1f() call.
  */
 static void

[Mesa-dev] [Bug 103078] MATLAB broken with mesa software rendering

[bugzilla-daemon]

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

--- Comment #13 from Roland Scheidegger  ---
(In reply to Timo Aaltonen from comment #12)
> this is a bug in jogl, and apparently changing it to detect current Mesa
> makes it work again:
> 
> https://jogamp.org/bugzilla/show_bug.cgi?id=1357

They really should fix whatever it's doing wrong, rather than trying to avoid
doing the wrong stuff when detecting a mesa-based driver... (I suspect it might
be related to mesa not supporting compat profiles higher than 3.3 and jogl not
handling this correctly, but really no idea. Doing hacks such as renderer
detection might be ok as quick workarounds, but really the root cause should be
fixed wherever it is.)

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

[Mesa-dev] [PATCH 17/17] vbo: optimize some display list drawing

[Brian Paul]

The vbo_save_vertex_list structure records one or more glBegin/End
primitives which all have the same vertex format.

To draw these primitives, we setup the vertex array state, then
issue the drawing command.  Before, the 'start' vertex was typically
zero and we used the vertex array pointer to indicate where the
vertex data starts.

This patch checks if the vertex buffer offset is an exact multiple of
the vertex size.  If so, that means we can use zero-based vertex array
pointers and use the draw's start value to indicate where the vertex
data starts.

This means a series of display list drawing commands may have
identical vertex array state.  This will get filtered out by the
Gallium CSO module so we can issue a tight series of drawing commands
without state changes to the device.

Note that this also works for a series of glCallList commands (not
just one list that contains multiple glBegin/End pairs).

No Piglit or conform changes.
---
 src/mesa/vbo/vbo_save.h  | 17 +
 src/mesa/vbo/vbo_save_api.c  | 15 +++
 src/mesa/vbo/vbo_save_draw.c | 12 
 3 files changed, 44 insertions(+)

diff --git a/src/mesa/vbo/vbo_save.h b/src/mesa/vbo/vbo_save.h
index 9d13e0a..468a04a 100644
--- a/src/mesa/vbo/vbo_save.h
+++ b/src/mesa/vbo/vbo_save.h
@@ -86,6 +86,23 @@ struct vbo_save_vertex_list {
struct vbo_save_primitive_store *prim_store;
 };
 
+
+/**
+ * Is the vertex lists's buffer offset an exact multiple of the
+ * vertex size (in bytes)?  This is used to check for a vertex array /
+ * drawing optimization.
+ */
+static inline bool
+aligned_vertex_buffer_offset(const struct vbo_save_vertex_list *node)
+{
+   unsigned vertex_size = node->vertex_size * sizeof(GLfloat); /* in bytes */
+   if (vertex_size)
+  return node->buffer_offset % vertex_size == 0;
+   else
+  return false;
+}
+
+
 /* These buffers should be a reasonable size to support upload to
  * hardware.  Current vbo implementation will re-upload on any
  * changes, so don't make too big or apps which dynamically create
diff --git a/src/mesa/vbo/vbo_save_api.c b/src/mesa/vbo/vbo_save_api.c
index 42d883f..b9d382a 100644
--- a/src/mesa/vbo/vbo_save_api.c
+++ b/src/mesa/vbo/vbo_save_api.c
@@ -546,6 +546,21 @@ compile_vertex_list(struct gl_context *ctx)
   save->prim_store = alloc_prim_store();
}
 
+   /**
+* If the vertex buffer offset is a multiple of the vertex size,
+* we can use the _mesa_prim::start value to indicate where the
+* vertices starts, instead of the buffer offset.  Also see the
+* bind_vertex_list() function.
+*/
+   if (aligned_vertex_buffer_offset(node)) {
+  const unsigned start_offset =
+ node->buffer_offset / (node->vertex_size * sizeof(GLfloat));
+  unsigned i;
+  for (i = 0; i < save->prim_count; i++) {
+ save->prims[i].start += start_offset;
+  }
+   }
+
/* Reset our structures for the next run of vertices:
 */
reset_counters(ctx);
diff --git a/src/mesa/vbo/vbo_save_draw.c b/src/mesa/vbo/vbo_save_draw.c
index 1694a04..b63a9a8 100644
--- a/src/mesa/vbo/vbo_save_draw.c
+++ b/src/mesa/vbo/vbo_save_draw.c
@@ -146,6 +146,18 @@ bind_vertex_list(struct gl_context *ctx,
memcpy(node_attrsz, node->attrsz, sizeof(node->attrsz));
memcpy(node_attrtype, node->attrtype, sizeof(node->attrtype));
 
+   if (aligned_vertex_buffer_offset(node)) {
+  /* The vertex size is an exact multiple of the buffer offset.
+   * This means that we can use zero-based vertex attribute pointers
+   * and specify the start of the primitive with the _mesa_prim::start
+   * field.  This results in issuing several draw calls with identical
+   * vertex attribute information.  This can result in fewer state
+   * changes in drivers.  In particular, the Gallium CSO module will
+   * filter out redundant vertex buffer changes.
+   */
+  buffer_offset = 0;
+   }
+
/* Install the default (ie Current) attributes first, then overlay
 * all active ones.
 */
-- 
2.7.4

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

[Mesa-dev] [PATCH 13/17] vbo: rename some functions in vbo_save_draw.c

[Brian Paul]

---
 src/mesa/vbo/vbo_save_draw.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/src/mesa/vbo/vbo_save_draw.c b/src/mesa/vbo/vbo_save_draw.c
index d10d2dd..ee7f509 100644
--- a/src/mesa/vbo/vbo_save_draw.c
+++ b/src/mesa/vbo/vbo_save_draw.c
@@ -44,8 +44,8 @@
  * last vertex to the saved state
  */
 static void
-_playback_copy_to_current(struct gl_context *ctx,
-  const struct vbo_save_vertex_list *node)
+playback_copy_to_current(struct gl_context *ctx,
+ const struct vbo_save_vertex_list *node)
 {
struct vbo_context *vbo = vbo_context(ctx);
fi_type vertex[VBO_ATTRIB_MAX * 4];
@@ -132,8 +132,8 @@ _playback_copy_to_current(struct gl_context *ctx,
  * into it:
  */
 static void
-vbo_bind_vertex_list(struct gl_context *ctx,
- const struct vbo_save_vertex_list *node)
+bind_vertex_list(struct gl_context *ctx,
+ const struct vbo_save_vertex_list *node)
 {
struct vbo_context *vbo = vbo_context(ctx);
struct vbo_save_context *save = >save;
@@ -222,8 +222,8 @@ vbo_bind_vertex_list(struct gl_context *ctx,
 
 
 static void
-vbo_save_loopback_vertex_list(struct gl_context *ctx,
-  const struct vbo_save_vertex_list *list)
+loopback_vertex_list(struct gl_context *ctx,
+ const struct vbo_save_vertex_list *list)
 {
const char *buffer =
   ctx->Driver.MapBufferRange(ctx, 0,
@@ -286,7 +286,7 @@ vbo_save_playback_vertex_list(struct gl_context *ctx, void 
*data)
  /* Various degenerate cases: translate into immediate mode
   * calls rather than trying to execute in place.
   */
- vbo_save_loopback_vertex_list(ctx, node);
+ loopback_vertex_list(ctx, node);
 
  goto end;
   }
@@ -304,7 +304,7 @@ vbo_save_playback_vertex_list(struct gl_context *ctx, void 
*data)
  return;
   }
 
-  vbo_bind_vertex_list(ctx, node);
+  bind_vertex_list(ctx, node);
 
   vbo_draw_method(vbo_context(ctx), DRAW_DISPLAY_LIST);
 
@@ -327,7 +327,7 @@ vbo_save_playback_vertex_list(struct gl_context *ctx, void 
*data)
 
/* Copy to current?
 */
-   _playback_copy_to_current(ctx, node);
+   playback_copy_to_current(ctx, node);
 
 end:
if (remap_vertex_store) {
-- 
2.7.4

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

[Mesa-dev] [PATCH 12/17] vbo: add comment that vbo_save_vertex_list::buffer_offset is in bytes

[Brian Paul]

---
 src/mesa/vbo/vbo_save.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/vbo/vbo_save.h b/src/mesa/vbo/vbo_save.h
index 32782b13e..9d13e0a 100644
--- a/src/mesa/vbo/vbo_save.h
+++ b/src/mesa/vbo/vbo_save.h
@@ -73,7 +73,7 @@ struct vbo_save_vertex_list {
fi_type *current_data;
GLuint current_size;
 
-   GLuint buffer_offset;
+   GLuint buffer_offset;/**< in bytes */
GLuint vertex_count;
GLuint wrap_count;  /* number of copied vertices at start */
GLboolean dangling_attr_ref;/* current attr implicitly referenced
-- 
2.7.4

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

[Mesa-dev] [PATCH 06/17] vbo: s/GLuint/GLbitfield/ for vbo_save_context::replay_flags

[Brian Paul]

---
 src/mesa/vbo/vbo_save.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/vbo/vbo_save.h b/src/mesa/vbo/vbo_save.h
index 2720d13..74ff07e 100644
--- a/src/mesa/vbo/vbo_save.h
+++ b/src/mesa/vbo/vbo_save.h
@@ -138,7 +138,7 @@ struct vbo_save_context {
fi_type *buffer;
GLuint count;
GLuint wrap_count;
-   GLuint replay_flags;
+   GLbitfield replay_flags;
 
struct _mesa_prim *prim;
GLuint prim_count, prim_max;
-- 
2.7.4

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

[Mesa-dev] [PATCH 03/17] vbo: rename vbo_save_primitive_store::buffer to prims

[Brian Paul]

A little easier to understand.
---
 src/mesa/vbo/vbo_save.h | 2 +-
 src/mesa/vbo/vbo_save_api.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/mesa/vbo/vbo_save.h b/src/mesa/vbo/vbo_save.h
index 2eec87a..8240261 100644
--- a/src/mesa/vbo/vbo_save.h
+++ b/src/mesa/vbo/vbo_save.h
@@ -114,7 +114,7 @@ struct vbo_save_vertex_store {
 };
 
 struct vbo_save_primitive_store {
-   struct _mesa_prim buffer[VBO_SAVE_PRIM_SIZE];
+   struct _mesa_prim prims[VBO_SAVE_PRIM_SIZE];
GLuint used;
GLuint refcount;
 };
diff --git a/src/mesa/vbo/vbo_save_api.c b/src/mesa/vbo/vbo_save_api.c
index aab5f54..ae5ee03 100644
--- a/src/mesa/vbo/vbo_save_api.c
+++ b/src/mesa/vbo/vbo_save_api.c
@@ -310,7 +310,7 @@ _save_reset_counters(struct gl_context *ctx)
 {
struct vbo_save_context *save = _context(ctx)->save;
 
-   save->prim = save->prim_store->buffer + save->prim_store->used;
+   save->prim = save->prim_store->prims + save->prim_store->used;
save->buffer = save->vertex_store->buffer + save->vertex_store->used;
 
assert(save->buffer == save->buffer_ptr);
-- 
2.7.4

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

[Mesa-dev] [PATCH 10/17] vbo: rename prim to prims

[Brian Paul]

Using a plural name makes it easier to see that this is an array and
not a pointer to a single object.
---
 src/mesa/vbo/vbo_save.h  |  4 +--
 src/mesa/vbo/vbo_save_api.c  | 82 ++--
 src/mesa/vbo/vbo_save_draw.c |  8 ++---
 3 files changed, 47 insertions(+), 47 deletions(-)

diff --git a/src/mesa/vbo/vbo_save.h b/src/mesa/vbo/vbo_save.h
index e9f3cae..32782b13e 100644
--- a/src/mesa/vbo/vbo_save.h
+++ b/src/mesa/vbo/vbo_save.h
@@ -79,7 +79,7 @@ struct vbo_save_vertex_list {
GLboolean dangling_attr_ref;/* current attr implicitly referenced
outside the list */
 
-   struct _mesa_prim *prim;
+   struct _mesa_prim *prims;
GLuint prim_count;
 
struct vbo_save_vertex_store *vertex_store;
@@ -138,7 +138,7 @@ struct vbo_save_context {
GLuint wrap_count;
GLbitfield replay_flags;
 
-   struct _mesa_prim *prim;
+   struct _mesa_prim *prims;
GLuint prim_count, prim_max;
 
struct vbo_save_vertex_store *vertex_store;
diff --git a/src/mesa/vbo/vbo_save_api.c b/src/mesa/vbo/vbo_save_api.c
index fefe420..84d8d1e 100644
--- a/src/mesa/vbo/vbo_save_api.c
+++ b/src/mesa/vbo/vbo_save_api.c
@@ -104,7 +104,7 @@ _save_copy_vertices(struct gl_context *ctx,
 const fi_type * src_buffer)
 {
struct vbo_save_context *save = _context(ctx)->save;
-   const struct _mesa_prim *prim = >prim[node->prim_count - 1];
+   const struct _mesa_prim *prim = >prims[node->prim_count - 1];
GLuint nr = prim->count;
GLuint sz = save->vertex_size;
const fi_type *src = src_buffer + prim->start * sz;
@@ -309,7 +309,7 @@ _save_reset_counters(struct gl_context *ctx)
 {
struct vbo_save_context *save = _context(ctx)->save;
 
-   save->prim = save->prim_store->prims + save->prim_store->used;
+   save->prims = save->prim_store->prims + save->prim_store->used;
save->buffer_map = save->vertex_store->buffer_map + 
save->vertex_store->used;
 
assert(save->buffer_map == save->buffer_ptr);
@@ -371,7 +371,7 @@ static void
 convert_line_loop_to_strip(struct vbo_save_context *save,
struct vbo_save_vertex_list *node)
 {
-   struct _mesa_prim *prim = >prim[node->prim_count - 1];
+   struct _mesa_prim *prim = >prims[node->prim_count - 1];
 
assert(prim->mode == GL_LINE_LOOP);
 
@@ -439,7 +439,7 @@ _save_compile_vertex_list(struct gl_context *ctx)
node->vertex_count = save->vert_count;
node->wrap_count = save->copied.nr;
node->dangling_attr_ref = save->dangling_attr_ref;
-   node->prim = save->prim;
+   node->prims = save->prims;
node->prim_count = save->prim_count;
node->vertex_store = save->vertex_store;
node->prim_store = save->prim_store;
@@ -447,7 +447,7 @@ _save_compile_vertex_list(struct gl_context *ctx)
node->vertex_store->refcount++;
node->prim_store->refcount++;
 
-   if (node->prim[0].no_current_update) {
+   if (node->prims[0].no_current_update) {
   node->current_size = 0;
   node->current_data = NULL;
}
@@ -488,11 +488,11 @@ _save_compile_vertex_list(struct gl_context *ctx)
 */
save->copied.nr = _save_copy_vertices(ctx, node, save->buffer_map);
 
-   if (node->prim[node->prim_count - 1].mode == GL_LINE_LOOP) {
+   if (node->prims[node->prim_count - 1].mode == GL_LINE_LOOP) {
   convert_line_loop_to_strip(save, node);
}
 
-   merge_prims(node->prim, >prim_count);
+   merge_prims(node->prims, >prim_count);
 
/* Deal with GL_COMPILE_AND_EXECUTE:
 */
@@ -505,7 +505,7 @@ _save_compile_vertex_list(struct gl_context *ctx)
(const GLfloat *) ((const char *) save->
   vertex_store->buffer_map +
   node->buffer_offset),
-   node->attrsz, node->prim, node->prim_count,
+   node->attrsz, node->prims, node->prim_count,
node->wrap_count, node->vertex_size);
 
   _glapi_set_dispatch(dispatch);
@@ -570,10 +570,10 @@ _save_wrap_buffers(struct gl_context *ctx)
 
/* Close off in-progress primitive.
 */
-   save->prim[i].count = (save->vert_count - save->prim[i].start);
-   mode = save->prim[i].mode;
-   weak = save->prim[i].weak;
-   no_current_update = save->prim[i].no_current_update;
+   save->prims[i].count = (save->vert_count - save->prims[i].start);
+   mode = save->prims[i].mode;
+   weak = save->prims[i].weak;
+   no_current_update = save->prims[i].no_current_update;
 
/* store the copied vertices, and allocate a new list.
 */
@@ -581,17 +581,17 @@ _save_wrap_buffers(struct gl_context *ctx)
 
/* Restart interrupted primitive
 */
-   save->prim[0].mode = mode;
-   save->prim[0].weak = weak;
-   save->prim[0].no_current_update = no_current_update;
-   save->prim[0].begin = 0;
-   save->prim[0].end = 0;
-   save->prim[0].pad = 0;
-   save->prim[0].start = 0;
-   

[Mesa-dev] [PATCH 11/17] vbo: minor code simplification in _save_compile_vertex_list()

[Brian Paul]

---
 src/mesa/vbo/vbo_save_api.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/src/mesa/vbo/vbo_save_api.c b/src/mesa/vbo/vbo_save_api.c
index 84d8d1e..cb48cb8 100644
--- a/src/mesa/vbo/vbo_save_api.c
+++ b/src/mesa/vbo/vbo_save_api.c
@@ -501,10 +501,11 @@ _save_compile_vertex_list(struct gl_context *ctx)
 
   _glapi_set_dispatch(ctx->Exec);
 
-  vbo_loopback_vertex_list(ctx,
-   (const GLfloat *) ((const char *) save->
-  vertex_store->buffer_map +
-  node->buffer_offset),
+  const GLfloat *buffer = (const GLfloat *)
+ ((const char *) save->vertex_store->buffer_map +
+  node->buffer_offset);
+
+  vbo_loopback_vertex_list(ctx, buffer,
node->attrsz, node->prims, node->prim_count,
node->wrap_count, node->vertex_size);
 
-- 
2.7.4

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

[Mesa-dev] [PATCH 15/17] vbo: add some comments in vbo_save_api.c

[Brian Paul]

---
 src/mesa/vbo/vbo_save_api.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/src/mesa/vbo/vbo_save_api.c b/src/mesa/vbo/vbo_save_api.c
index 8eb3846..42d883f 100644
--- a/src/mesa/vbo/vbo_save_api.c
+++ b/src/mesa/vbo/vbo_save_api.c
@@ -1559,6 +1559,9 @@ vbo_save_SaveFlushVertices(struct gl_context *ctx)
 }
 
 
+/**
+ * Called from glNewList when we're starting to compile a display list.
+ */
 void
 vbo_save_NewList(struct gl_context *ctx, GLuint list, GLenum mode)
 {
@@ -1581,6 +1584,9 @@ vbo_save_NewList(struct gl_context *ctx, GLuint list, 
GLenum mode)
 }
 
 
+/**
+ * Called from glEndList when we're finished compiling a display list.
+ */
 void
 vbo_save_EndList(struct gl_context *ctx)
 {
@@ -1615,6 +1621,10 @@ vbo_save_EndList(struct gl_context *ctx)
 }
 
 
+/**
+ * Called from the display list code when we're about to execute a
+ * display list.
+ */
 void
 vbo_save_BeginCallList(struct gl_context *ctx, struct gl_display_list *dlist)
 {
@@ -1623,6 +1633,10 @@ vbo_save_BeginCallList(struct gl_context *ctx, struct 
gl_display_list *dlist)
 }
 
 
+/**
+ * Called from the display list code when we're finished executing a
+ * display list.
+ */
 void
 vbo_save_EndCallList(struct gl_context *ctx)
 {
@@ -1637,6 +1651,9 @@ vbo_save_EndCallList(struct gl_context *ctx)
 }
 
 
+/**
+ * Called by display list code when a display list is being deleted.
+ */
 static void
 vbo_destroy_vertex_list(struct gl_context *ctx, void *data)
 {
-- 
2.7.4

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

[Mesa-dev] [PATCH 16/17] vbo: rewrite some code in playback_copy_to_current()

[Brian Paul]

I think this is a little easier to understand.
---
 src/mesa/vbo/vbo_save_draw.c | 14 ++
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/src/mesa/vbo/vbo_save_draw.c b/src/mesa/vbo/vbo_save_draw.c
index ee7f509..1694a04 100644
--- a/src/mesa/vbo/vbo_save_draw.c
+++ b/src/mesa/vbo/vbo_save_draw.c
@@ -51,7 +51,6 @@ playback_copy_to_current(struct gl_context *ctx,
fi_type vertex[VBO_ATTRIB_MAX * 4];
fi_type *data;
GLbitfield64 mask;
-   GLuint offset;
 
if (node->current_size == 0)
   return;
@@ -60,14 +59,13 @@ playback_copy_to_current(struct gl_context *ctx,
   data = node->current_data;
}
else {
-  data = vertex;
+  /* Position of last vertex */
+  const GLuint pos = node->vertex_count > 0 ? node->vertex_count - 1 : 0;
+  /* Offset to last vertex in the vertex buffer */
+  const GLuint offset = node->buffer_offset
+ + pos * node->vertex_size * sizeof(GLfloat);
 
-  if (node->vertex_count)
- offset = (node->buffer_offset +
-   (node->vertex_count - 1)
-   * node->vertex_size * sizeof(GLfloat));
-  else
- offset = node->buffer_offset;
+  data = vertex;
 
   ctx->Driver.GetBufferSubData(ctx, offset,
node->vertex_size * sizeof(GLfloat),
-- 
2.7.4

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

[Mesa-dev] [PATCH 09/17] vbo: removed unused ctx parameter for alloc_prim_store()

[Brian Paul]

---
 src/mesa/vbo/vbo_save_api.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/src/mesa/vbo/vbo_save_api.c b/src/mesa/vbo/vbo_save_api.c
index 8312969..fefe420 100644
--- a/src/mesa/vbo/vbo_save_api.c
+++ b/src/mesa/vbo/vbo_save_api.c
@@ -294,11 +294,10 @@ vbo_save_unmap_vertex_store(struct gl_context *ctx,
 
 
 static struct vbo_save_primitive_store *
-alloc_prim_store(struct gl_context *ctx)
+alloc_prim_store(void)
 {
struct vbo_save_primitive_store *store =
   CALLOC_STRUCT(vbo_save_primitive_store);
-   (void) ctx;
store->used = 0;
store->refcount = 1;
return store;
@@ -543,7 +542,7 @@ _save_compile_vertex_list(struct gl_context *ctx)
if (save->prim_store->used > VBO_SAVE_PRIM_SIZE - 6) {
   save->prim_store->refcount--;
   assert(save->prim_store->refcount != 0);
-  save->prim_store = alloc_prim_store(ctx);
+  save->prim_store = alloc_prim_store();
}
 
/* Reset our structures for the next run of vertices:
@@ -1568,7 +1567,7 @@ vbo_save_NewList(struct gl_context *ctx, GLuint list, 
GLenum mode)
(void) mode;
 
if (!save->prim_store)
-  save->prim_store = alloc_prim_store(ctx);
+  save->prim_store = alloc_prim_store();
 
if (!save->vertex_store)
   save->vertex_store = alloc_vertex_store(ctx);
-- 
2.7.4

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

[Mesa-dev] [PATCH 07/17] vbo: remove unused vbo_save_context::count field

[Brian Paul]

---
 src/mesa/vbo/vbo_save.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/src/mesa/vbo/vbo_save.h b/src/mesa/vbo/vbo_save.h
index 74ff07e..34a7588 100644
--- a/src/mesa/vbo/vbo_save.h
+++ b/src/mesa/vbo/vbo_save.h
@@ -136,7 +136,6 @@ struct vbo_save_context {
GLboolean out_of_memory;  /**< True if last VBO allocation failed */
 
fi_type *buffer;
-   GLuint count;
GLuint wrap_count;
GLbitfield replay_flags;
 
-- 
2.7.4

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

[Mesa-dev] [PATCH 05/17] vbo: rename vbo_save_vertex_list::count to vertex_count

[Brian Paul]

---
 src/mesa/vbo/vbo_save.h  |  2 +-
 src/mesa/vbo/vbo_save_api.c  | 14 +++---
 src/mesa/vbo/vbo_save_draw.c |  9 +
 3 files changed, 13 insertions(+), 12 deletions(-)

diff --git a/src/mesa/vbo/vbo_save.h b/src/mesa/vbo/vbo_save.h
index 5eed3ae..2720d13 100644
--- a/src/mesa/vbo/vbo_save.h
+++ b/src/mesa/vbo/vbo_save.h
@@ -74,7 +74,7 @@ struct vbo_save_vertex_list {
GLuint current_size;
 
GLuint buffer_offset;
-   GLuint count;/**< vertex count */
+   GLuint vertex_count;
GLuint wrap_count;  /* number of copied vertices at start */
GLboolean dangling_attr_ref;/* current attr implicitly referenced
outside the list */
diff --git a/src/mesa/vbo/vbo_save_api.c b/src/mesa/vbo/vbo_save_api.c
index 05ccb41..98ced2b 100644
--- a/src/mesa/vbo/vbo_save_api.c
+++ b/src/mesa/vbo/vbo_save_api.c
@@ -389,7 +389,7 @@ convert_line_loop_to_strip(struct vbo_save_context *save,
   memcpy(dst, src, sz * sizeof(float));
 
   prim->count++;
-  node->count++;
+  node->vertex_count++;
   save->vert_count++;
   save->buffer_ptr += sz;
   save->vertex_store->used += sz;
@@ -437,7 +437,7 @@ _save_compile_vertex_list(struct gl_context *ctx)
node->vertex_size = save->vertex_size;
node->buffer_offset =
   (save->buffer - save->vertex_store->buffer_map) * sizeof(GLfloat);
-   node->count = save->vert_count;
+   node->vertex_count = save->vert_count;
node->wrap_count = save->copied.nr;
node->dangling_attr_ref = save->dangling_attr_ref;
node->prim = save->prim;
@@ -466,9 +466,9 @@ _save_compile_vertex_list(struct gl_context *ctx)
 unsigned attr_offset = node->attrsz[0] * sizeof(GLfloat);
 unsigned vertex_offset = 0;
 
-if (node->count)
+if (node->vertex_count)
vertex_offset =
-  (node->count - 1) * node->vertex_size * sizeof(GLfloat);
+  (node->vertex_count - 1) * node->vertex_size * 
sizeof(GLfloat);
 
 memcpy(node->current_data,
buffer + node->buffer_offset + vertex_offset + attr_offset,
@@ -477,12 +477,12 @@ _save_compile_vertex_list(struct gl_context *ctx)
   }
}
 
-   assert(node->attrsz[VBO_ATTRIB_POS] != 0 || node->count == 0);
+   assert(node->attrsz[VBO_ATTRIB_POS] != 0 || node->vertex_count == 0);
 
if (save->dangling_attr_ref)
   ctx->ListState.CurrentList->Flags |= DLIST_DANGLING_REFS;
 
-   save->vertex_store->used += save->vertex_size * node->count;
+   save->vertex_store->used += save->vertex_size * node->vertex_count;
save->prim_store->used += node->prim_count;
 
/* Copy duplicated vertices
@@ -1665,7 +1665,7 @@ vbo_print_vertex_list(struct gl_context *ctx, void *data, 
FILE *f)
 
fprintf(f, "VBO-VERTEX-LIST, %u vertices, %d primitives, %d vertsize, "
"buffer %p\n",
-   node->count, node->prim_count, node->vertex_size,
+   node->vertex_count, node->prim_count, node->vertex_size,
buffer);
 
for (i = 0; i < node->prim_count; i++) {
diff --git a/src/mesa/vbo/vbo_save_draw.c b/src/mesa/vbo/vbo_save_draw.c
index 4b79e9c..e7e4e94 100644
--- a/src/mesa/vbo/vbo_save_draw.c
+++ b/src/mesa/vbo/vbo_save_draw.c
@@ -62,9 +62,10 @@ _playback_copy_to_current(struct gl_context *ctx,
else {
   data = vertex;
 
-  if (node->count)
+  if (node->vertex_count)
  offset = (node->buffer_offset +
-   (node->count - 1) * node->vertex_size * sizeof(GLfloat));
+   (node->vertex_count - 1)
+   * node->vertex_size * sizeof(GLfloat));
   else
  offset = node->buffer_offset;
 
@@ -312,14 +313,14 @@ vbo_save_playback_vertex_list(struct gl_context *ctx, 
void *data)
   if (ctx->NewState)
  _mesa_update_state(ctx);
 
-  if (node->count > 0) {
+  if (node->vertex_count > 0) {
  vbo_context(ctx)->draw_prims(ctx,
   node->prim,
   node->prim_count,
   NULL,
   GL_TRUE,
   0,/* Node is a VBO, so this is ok */
-  node->count - 1,
+  node->vertex_count - 1,
   NULL, 0, NULL);
   }
}
-- 
2.7.4

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

[Mesa-dev] [PATCH 08/17] vbo: rename vbo_save_context::buffer to buffer_map

[Brian Paul]

And move the field and improve comments.
---
 src/mesa/vbo/vbo_save.h |  4 ++--
 src/mesa/vbo/vbo_save_api.c | 14 +++---
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/src/mesa/vbo/vbo_save.h b/src/mesa/vbo/vbo_save.h
index 34a7588..e9f3cae 100644
--- a/src/mesa/vbo/vbo_save.h
+++ b/src/mesa/vbo/vbo_save.h
@@ -135,7 +135,6 @@ struct vbo_save_context {
 
GLboolean out_of_memory;  /**< True if last VBO allocation failed */
 
-   fi_type *buffer;
GLuint wrap_count;
GLbitfield replay_flags;
 
@@ -145,7 +144,8 @@ struct vbo_save_context {
struct vbo_save_vertex_store *vertex_store;
struct vbo_save_primitive_store *prim_store;
 
-   fi_type *buffer_ptr;   /* cursor, points into buffer */
+   fi_type *buffer_map;/**< Mapping of vertex_store's buffer */
+   fi_type *buffer_ptr;   /**< cursor, points into buffer_map 
*/
fi_type vertex[VBO_ATTRIB_MAX*4];  /* current values */
fi_type *attrptr[VBO_ATTRIB_MAX];
GLuint vert_count;
diff --git a/src/mesa/vbo/vbo_save_api.c b/src/mesa/vbo/vbo_save_api.c
index 98ced2b..8312969 100644
--- a/src/mesa/vbo/vbo_save_api.c
+++ b/src/mesa/vbo/vbo_save_api.c
@@ -311,9 +311,9 @@ _save_reset_counters(struct gl_context *ctx)
struct vbo_save_context *save = _context(ctx)->save;
 
save->prim = save->prim_store->prims + save->prim_store->used;
-   save->buffer = save->vertex_store->buffer_map + save->vertex_store->used;
+   save->buffer_map = save->vertex_store->buffer_map + 
save->vertex_store->used;
 
-   assert(save->buffer == save->buffer_ptr);
+   assert(save->buffer_map == save->buffer_ptr);
 
if (save->vertex_size)
   save->max_vert = (VBO_SAVE_BUFFER_SIZE - save->vertex_store->used) /
@@ -382,9 +382,9 @@ convert_line_loop_to_strip(struct vbo_save_context *save,
*/
   const GLuint sz = save->vertex_size;
   /* 0th vertex: */
-  const fi_type *src = save->buffer + prim->start * sz;
+  const fi_type *src = save->buffer_map + prim->start * sz;
   /* end of buffer: */
-  fi_type *dst = save->buffer + (prim->start + prim->count) * sz;
+  fi_type *dst = save->buffer_map + (prim->start + prim->count) * sz;
 
   memcpy(dst, src, sz * sizeof(float));
 
@@ -436,7 +436,7 @@ _save_compile_vertex_list(struct gl_context *ctx)
memcpy(node->attrtype, save->attrtype, sizeof(node->attrtype));
node->vertex_size = save->vertex_size;
node->buffer_offset =
-  (save->buffer - save->vertex_store->buffer_map) * sizeof(GLfloat);
+  (save->buffer_map - save->vertex_store->buffer_map) * sizeof(GLfloat);
node->vertex_count = save->vert_count;
node->wrap_count = save->copied.nr;
node->dangling_attr_ref = save->dangling_attr_ref;
@@ -487,7 +487,7 @@ _save_compile_vertex_list(struct gl_context *ctx)
 
/* Copy duplicated vertices
 */
-   save->copied.nr = _save_copy_vertices(ctx, node, save->buffer);
+   save->copied.nr = _save_copy_vertices(ctx, node, save->buffer_map);
 
if (node->prim[node->prim_count - 1].mode == GL_LINE_LOOP) {
   convert_line_loop_to_strip(save, node);
@@ -732,7 +732,7 @@ _save_upgrade_vertex(struct gl_context *ctx, GLuint attr, 
GLuint newsz)
 */
if (save->copied.nr) {
   const fi_type *data = save->copied.buffer;
-  fi_type *dest = save->buffer;
+  fi_type *dest = save->buffer_map;
 
   /* Need to note this and fix up at runtime (or loopback):
*/
-- 
2.7.4

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

[Mesa-dev] [PATCH 01/17] vbo: whitespace fixes in vbo_save_draw.c

[Brian Paul]

---
 src/mesa/vbo/vbo_save_draw.c | 61 ++--
 1 file changed, 31 insertions(+), 30 deletions(-)

diff --git a/src/mesa/vbo/vbo_save_draw.c b/src/mesa/vbo/vbo_save_draw.c
index 2a20bb8..17eff9b 100644
--- a/src/mesa/vbo/vbo_save_draw.c
+++ b/src/mesa/vbo/vbo_save_draw.c
@@ -63,14 +63,14 @@ _playback_copy_to_current(struct gl_context *ctx,
   data = vertex;
 
   if (node->count)
- offset = (node->buffer_offset + 
-   (node->count-1) * node->vertex_size * sizeof(GLfloat));
+ offset = (node->buffer_offset +
+   (node->count - 1) * node->vertex_size * sizeof(GLfloat));
   else
  offset = node->buffer_offset;
 
-  ctx->Driver.GetBufferSubData( ctx, offset,
-node->vertex_size * sizeof(GLfloat), 
-data, node->vertex_store->bufferobj );
+  ctx->Driver.GetBufferSubData(ctx, offset,
+   node->vertex_size * sizeof(GLfloat),
+   data, node->vertex_store->bufferobj);
 
   data += node->attrsz[0]; /* skip vertex position */
}
@@ -90,7 +90,7 @@ _playback_copy_to_current(struct gl_context *ctx,
   if (node->attrtype[i] != vbo->currval[i].Type ||
   memcmp(current, tmp, 4 * sizeof(GLfloat)) != 0) {
  memcpy(current, tmp, 4 * sizeof(GLfloat));
- 
+
  vbo->currval[i].Size = node->attrsz[i];
  vbo->currval[i]._ElementSize = vbo->currval[i].Size * sizeof(GLfloat);
  vbo->currval[i].Type = node->attrtype[i];
@@ -118,9 +118,9 @@ _playback_copy_to_current(struct gl_context *ctx,
if (node->prim_count) {
   const struct _mesa_prim *prim = >prim[node->prim_count - 1];
   if (prim->end)
-ctx->Driver.CurrentExecPrimitive = PRIM_OUTSIDE_BEGIN_END;
+ ctx->Driver.CurrentExecPrimitive = PRIM_OUTSIDE_BEGIN_END;
   else
-ctx->Driver.CurrentExecPrimitive = prim->mode;
+ ctx->Driver.CurrentExecPrimitive = prim->mode;
}
 }
 
@@ -130,8 +130,9 @@ _playback_copy_to_current(struct gl_context *ctx,
  * Treat the vertex storage as a VBO, define vertex arrays pointing
  * into it:
  */
-static void vbo_bind_vertex_list(struct gl_context *ctx,
- const struct vbo_save_vertex_list *node)
+static void
+vbo_bind_vertex_list(struct gl_context *ctx,
+ const struct vbo_save_vertex_list *node)
 {
struct vbo_context *vbo = vbo_context(ctx);
struct vbo_save_context *save = >save;
@@ -195,9 +196,9 @@ static void vbo_bind_vertex_list(struct gl_context *ctx,
  /* override the default array set above */
  save->inputs[attr] = [attr];
 
-arrays[attr].Ptr = (const GLubyte *) NULL + buffer_offset;
-arrays[attr].Size = node_attrsz[src];
-arrays[attr].StrideB = node->vertex_size * sizeof(GLfloat);
+ arrays[attr].Ptr = (const GLubyte *) NULL + buffer_offset;
+ arrays[attr].Size = node_attrsz[src];
+ arrays[attr].StrideB = node->vertex_size * sizeof(GLfloat);
  arrays[attr].Type = node_attrtype[src];
  arrays[attr].Integer =
vbo_attrtype_to_integer_flag(node_attrtype[src]);
@@ -206,15 +207,15 @@ static void vbo_bind_vertex_list(struct gl_context *ctx,
  _mesa_reference_buffer_object(ctx,
[attr].BufferObj,
node->vertex_store->bufferobj);
-
-assert(arrays[attr].BufferObj->Name);
 
-buffer_offset += node_attrsz[src] * sizeof(GLfloat);
+ assert(arrays[attr].BufferObj->Name);
+
+ buffer_offset += node_attrsz[src] * sizeof(GLfloat);
  varying_inputs |= VERT_BIT(attr);
   }
}
 
-   _mesa_set_varying_vp_inputs( ctx, varying_inputs );
+   _mesa_set_varying_vp_inputs(ctx, varying_inputs);
ctx->NewDriverState |= ctx->DriverFlags.NewArray;
 }
 
@@ -225,9 +226,9 @@ vbo_save_loopback_vertex_list(struct gl_context *ctx,
 {
const char *buffer =
   ctx->Driver.MapBufferRange(ctx, 0,
-list->vertex_store->bufferobj->Size,
-GL_MAP_READ_BIT, /* ? */
-list->vertex_store->bufferobj,
+ list->vertex_store->bufferobj->Size,
+ GL_MAP_READ_BIT, /* ? */
+ list->vertex_store->bufferobj,
  MAP_INTERNAL);
 
vbo_loopback_vertex_list(ctx,
@@ -281,16 +282,16 @@ vbo_save_playback_vertex_list(struct gl_context *ctx, 
void *data)
  goto end;
   }
   else if (save->replay_flags) {
-/* Various degenerate cases: translate into immediate mode
- * calls rather than trying to execute in place.
- */
-vbo_save_loopback_vertex_list( ctx, node );
+ /* Various degenerate cases: 

[Mesa-dev] [PATCH 02/17] vbo: whitespace fixes in vbo_save.h

[Brian Paul]

---
 src/mesa/vbo/vbo_save.h | 32 +---
 1 file changed, 17 insertions(+), 15 deletions(-)

diff --git a/src/mesa/vbo/vbo_save.h b/src/mesa/vbo/vbo_save.h
index 485b7b1..2eec87a 100644
--- a/src/mesa/vbo/vbo_save.h
+++ b/src/mesa/vbo/vbo_save.h
@@ -76,8 +76,8 @@ struct vbo_save_vertex_list {
GLuint buffer_offset;
GLuint count;/**< vertex count */
GLuint wrap_count;  /* number of copied vertices at start */
-   GLboolean dangling_attr_ref;/* current attr implicitly referenced 
-  outside the list */
+   GLboolean dangling_attr_ref;/* current attr implicitly referenced
+   outside the list */
 
struct _mesa_prim *prim;
GLuint prim_count;
@@ -156,30 +156,32 @@ struct vbo_save_context {
GLuint opcode_vertex_list;
 
struct vbo_save_copied_vtx copied;
-   
+
fi_type *current[VBO_ATTRIB_MAX]; /* points into ctx->ListState */
GLubyte *currentsz[VBO_ATTRIB_MAX];
 };
 
-void vbo_save_init( struct gl_context *ctx );
-void vbo_save_destroy( struct gl_context *ctx );
-void vbo_save_fallback( struct gl_context *ctx, GLboolean fallback );
+void vbo_save_init(struct gl_context *ctx);
+void vbo_save_destroy(struct gl_context *ctx);
+void vbo_save_fallback(struct gl_context *ctx, GLboolean fallback);
 
 /* save_loopback.c:
  */
-void vbo_loopback_vertex_list( struct gl_context *ctx,
-  const GLfloat *buffer,
-  const GLubyte *attrsz,
-  const struct _mesa_prim *prim,
-  GLuint prim_count,
-  GLuint wrap_count,
-  GLuint vertex_size);
+void vbo_loopback_vertex_list(struct gl_context *ctx,
+  const GLfloat *buffer,
+  const GLubyte *attrsz,
+  const struct _mesa_prim *prim,
+  GLuint prim_count,
+  GLuint wrap_count,
+  GLuint vertex_size);
 
 /* Callbacks:
  */
-void vbo_save_playback_vertex_list( struct gl_context *ctx, void *data );
+void
+vbo_save_playback_vertex_list(struct gl_context *ctx, void *data);
 
-void vbo_save_api_init( struct vbo_save_context *save );
+void
+vbo_save_api_init(struct vbo_save_context *save);
 
 fi_type *
 vbo_save_map_vertex_store(struct gl_context *ctx,
-- 
2.7.4

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

[Mesa-dev] [PATCH 04/17] vbo: rename vbo_save_vertex_store::buffer to buffer_map

[Brian Paul]

To match other parts of the VBO code and make things easier to understand.
---
 src/mesa/vbo/vbo_save.h  |  2 +-
 src/mesa/vbo/vbo_save_api.c  | 25 +
 src/mesa/vbo/vbo_save_draw.c |  2 +-
 3 files changed, 15 insertions(+), 14 deletions(-)

diff --git a/src/mesa/vbo/vbo_save.h b/src/mesa/vbo/vbo_save.h
index 8240261..5eed3ae 100644
--- a/src/mesa/vbo/vbo_save.h
+++ b/src/mesa/vbo/vbo_save.h
@@ -108,7 +108,7 @@ struct vbo_save_vertex_list {
  */
 struct vbo_save_vertex_store {
struct gl_buffer_object *bufferobj;
-   fi_type *buffer;
+   fi_type *buffer_map;
GLuint used;
GLuint refcount;
 };
diff --git a/src/mesa/vbo/vbo_save_api.c b/src/mesa/vbo/vbo_save_api.c
index ae5ee03..05ccb41 100644
--- a/src/mesa/vbo/vbo_save_api.c
+++ b/src/mesa/vbo/vbo_save_api.c
@@ -213,7 +213,7 @@ alloc_vertex_store(struct gl_context *ctx)
   _mesa_install_save_vtxfmt(ctx, >vtxfmt_noop);
}
 
-   vertex_store->buffer = NULL;
+   vertex_store->buffer_map = NULL;
vertex_store->used = 0;
vertex_store->refcount = 1;
 
@@ -225,7 +225,7 @@ static void
 free_vertex_store(struct gl_context *ctx,
   struct vbo_save_vertex_store *vertex_store)
 {
-   assert(!vertex_store->buffer);
+   assert(!vertex_store->buffer_map);
 
if (vertex_store->bufferobj) {
   _mesa_reference_buffer_object(ctx, _store->bufferobj, NULL);
@@ -245,7 +245,7 @@ vbo_save_map_vertex_store(struct gl_context *ctx,
   GL_MAP_FLUSH_EXPLICIT_BIT);
 
assert(vertex_store->bufferobj);
-   assert(!vertex_store->buffer);  /* the buffer should not be mapped */
+   assert(!vertex_store->buffer_map);  /* the buffer should not be mapped */
 
if (vertex_store->bufferobj->Size > 0) {
   /* Map the remaining free space in the VBO */
@@ -257,12 +257,12 @@ vbo_save_map_vertex_store(struct gl_context *ctx,
 MAP_INTERNAL);
   if (range) {
  /* compute address of start of whole buffer (needed elsewhere) */
- vertex_store->buffer = range - vertex_store->used;
- assert(vertex_store->buffer);
+ vertex_store->buffer_map = range - vertex_store->used;
+ assert(vertex_store->buffer_map);
  return range;
   }
   else {
- vertex_store->buffer = NULL;
+ vertex_store->buffer_map = NULL;
  return NULL;
   }
}
@@ -289,7 +289,7 @@ vbo_save_unmap_vertex_store(struct gl_context *ctx,
 
   ctx->Driver.UnmapBuffer(ctx, vertex_store->bufferobj, MAP_INTERNAL);
}
-   vertex_store->buffer = NULL;
+   vertex_store->buffer_map = NULL;
 }
 
 
@@ -311,7 +311,7 @@ _save_reset_counters(struct gl_context *ctx)
struct vbo_save_context *save = _context(ctx)->save;
 
save->prim = save->prim_store->prims + save->prim_store->used;
-   save->buffer = save->vertex_store->buffer + save->vertex_store->used;
+   save->buffer = save->vertex_store->buffer_map + save->vertex_store->used;
 
assert(save->buffer == save->buffer_ptr);
 
@@ -436,7 +436,7 @@ _save_compile_vertex_list(struct gl_context *ctx)
memcpy(node->attrtype, save->attrtype, sizeof(node->attrtype));
node->vertex_size = save->vertex_size;
node->buffer_offset =
-  (save->buffer - save->vertex_store->buffer) * sizeof(GLfloat);
+  (save->buffer - save->vertex_store->buffer_map) * sizeof(GLfloat);
node->count = save->vert_count;
node->wrap_count = save->copied.nr;
node->dangling_attr_ref = save->dangling_attr_ref;
@@ -462,7 +462,7 @@ _save_compile_vertex_list(struct gl_context *ctx)
   */
  node->current_data = malloc(node->current_size * sizeof(GLfloat));
  if (node->current_data) {
-const char *buffer = (const char *) save->vertex_store->buffer;
+const char *buffer = (const char *) save->vertex_store->buffer_map;
 unsigned attr_offset = node->attrsz[0] * sizeof(GLfloat);
 unsigned vertex_offset = 0;
 
@@ -504,7 +504,7 @@ _save_compile_vertex_list(struct gl_context *ctx)
 
   vbo_loopback_vertex_list(ctx,
(const GLfloat *) ((const char *) save->
-  vertex_store->buffer +
+  vertex_store->buffer_map +
   node->buffer_offset),
node->attrsz, node->prim, node->prim_count,
node->wrap_count, node->vertex_size);
@@ -536,7 +536,8 @@ _save_compile_vertex_list(struct gl_context *ctx)
}
else {
   /* update buffer_ptr for next vertex */
-  save->buffer_ptr = save->vertex_store->buffer + save->vertex_store->used;
+  save->buffer_ptr = save->vertex_store->buffer_map
+ + save->vertex_store->used;
}
 
if (save->prim_store->used > VBO_SAVE_PRIM_SIZE - 6) {
diff --git a/src/mesa/vbo/vbo_save_draw.c b/src/mesa/vbo/vbo_save_draw.c
index 

[Mesa-dev] [PATCH] svga: add num-commands-per-draw HUD query

[Brian Paul]

This query shows the ratio of total commands vs. drawing commands sent
to the vgpu device.  This gives some idea of how many state changes
are sent per draw call.  The closer the ratio is to 1.0, the better.
---
 src/gallium/drivers/svga/svga_cmd.c| 4 
 src/gallium/drivers/svga/svga_cmd_vgpu10.c | 5 +
 src/gallium/drivers/svga/svga_context.h| 1 +
 src/gallium/drivers/svga/svga_pipe_query.c | 8 
 src/gallium/drivers/svga/svga_screen.c | 2 ++
 src/gallium/drivers/svga/svga_winsys.h | 4 
 6 files changed, 24 insertions(+)

diff --git a/src/gallium/drivers/svga/svga_cmd.c 
b/src/gallium/drivers/svga/svga_cmd.c
index 7b78cb7..2bd1cc2 100644
--- a/src/gallium/drivers/svga/svga_cmd.c
+++ b/src/gallium/drivers/svga/svga_cmd.c
@@ -121,6 +121,8 @@ SVGA3D_FIFOReserve(struct svga_winsys_context *swc,
 
swc->last_command = cmd;
 
+   swc->num_commands++;
+
return [1];
 }
 
@@ -1022,6 +1024,8 @@ SVGA3D_BeginDrawPrimitives(struct svga_winsys_context 
*swc,
 
swc->hints |= SVGA_HINT_FLAG_CAN_PRE_FLUSH;
 
+   swc->num_draw_commands++;
+
return PIPE_OK;
 }
 
diff --git a/src/gallium/drivers/svga/svga_cmd_vgpu10.c 
b/src/gallium/drivers/svga/svga_cmd_vgpu10.c
index 55465f5..bed1403 100644
--- a/src/gallium/drivers/svga/svga_cmd_vgpu10.c
+++ b/src/gallium/drivers/svga/svga_cmd_vgpu10.c
@@ -537,6 +537,7 @@ SVGA3D_vgpu10_Draw(struct svga_winsys_context *swc,
 
swc->hints |= SVGA_HINT_FLAG_CAN_PRE_FLUSH;
swc->commit(swc);
+   swc->num_draw_commands++;
return PIPE_OK;
 }
 
@@ -553,6 +554,7 @@ SVGA3D_vgpu10_DrawIndexed(struct svga_winsys_context *swc,
 
swc->hints |= SVGA_HINT_FLAG_CAN_PRE_FLUSH;
swc->commit(swc);
+   swc->num_draw_commands++;
return PIPE_OK;
 }
 
@@ -570,6 +572,7 @@ SVGA3D_vgpu10_DrawInstanced(struct svga_winsys_context *swc,
 
swc->hints |= SVGA_HINT_FLAG_CAN_PRE_FLUSH;
swc->commit(swc);
+   swc->num_draw_commands++;
return PIPE_OK;
 }
 
@@ -590,6 +593,7 @@ SVGA3D_vgpu10_DrawIndexedInstanced(struct 
svga_winsys_context *swc,
 
swc->hints |= SVGA_HINT_FLAG_CAN_PRE_FLUSH;
swc->commit(swc);
+   swc->num_draw_commands++;
return PIPE_OK;
 }
 
@@ -600,6 +604,7 @@ SVGA3D_vgpu10_DrawAuto(struct svga_winsys_context *swc)
 
swc->hints |= SVGA_HINT_FLAG_CAN_PRE_FLUSH;
swc->commit(swc);
+   swc->num_draw_commands++;
return PIPE_OK;
 }
 
diff --git a/src/gallium/drivers/svga/svga_context.h 
b/src/gallium/drivers/svga/svga_context.h
index fd0c312..bc881c9 100644
--- a/src/gallium/drivers/svga/svga_context.h
+++ b/src/gallium/drivers/svga/svga_context.h
@@ -73,6 +73,7 @@ enum svga_hud {
SVGA_QUERY_NUM_SURFACE_VIEWS,
SVGA_QUERY_NUM_GENERATE_MIPMAP,
SVGA_QUERY_NUM_FAILED_ALLOCATIONS,
+   SVGA_QUERY_NUM_COMMANDS_PER_DRAW,
 
 /*SVGA_QUERY_MAX has to be last because it is size of an array*/
SVGA_QUERY_MAX
diff --git a/src/gallium/drivers/svga/svga_pipe_query.c 
b/src/gallium/drivers/svga/svga_pipe_query.c
index 2692452..cec95ed 100644
--- a/src/gallium/drivers/svga/svga_pipe_query.c
+++ b/src/gallium/drivers/svga/svga_pipe_query.c
@@ -751,6 +751,7 @@ svga_create_query(struct pipe_context *pipe,
case SVGA_QUERY_NUM_CONST_BUF_UPDATES:
case SVGA_QUERY_NUM_CONST_UPDATES:
case SVGA_QUERY_NUM_FAILED_ALLOCATIONS:
+   case SVGA_QUERY_NUM_COMMANDS_PER_DRAW:
   break;
case SVGA_QUERY_FLUSH_TIME:
case SVGA_QUERY_MAP_BUFFER_TIME:
@@ -832,6 +833,7 @@ svga_destroy_query(struct pipe_context *pipe, struct 
pipe_query *q)
case SVGA_QUERY_NUM_CONST_BUF_UPDATES:
case SVGA_QUERY_NUM_CONST_UPDATES:
case SVGA_QUERY_NUM_FAILED_ALLOCATIONS:
+   case SVGA_QUERY_NUM_COMMANDS_PER_DRAW:
   /* nothing */
   break;
default:
@@ -945,6 +947,7 @@ svga_begin_query(struct pipe_context *pipe, struct 
pipe_query *q)
case SVGA_QUERY_NUM_SURFACE_VIEWS:
case SVGA_QUERY_NUM_GENERATE_MIPMAP:
case SVGA_QUERY_NUM_FAILED_ALLOCATIONS:
+   case SVGA_QUERY_NUM_COMMANDS_PER_DRAW:
   /* nothing */
   break;
default:
@@ -1059,6 +1062,7 @@ svga_end_query(struct pipe_context *pipe, struct 
pipe_query *q)
case SVGA_QUERY_NUM_SURFACE_VIEWS:
case SVGA_QUERY_NUM_GENERATE_MIPMAP:
case SVGA_QUERY_NUM_FAILED_ALLOCATIONS:
+   case SVGA_QUERY_NUM_COMMANDS_PER_DRAW:
   /* nothing */
   break;
default:
@@ -1196,6 +1200,10 @@ svga_get_query_result(struct pipe_context *pipe,
case SVGA_QUERY_NUM_FAILED_ALLOCATIONS:
   vresult->u64 = svgascreen->hud.num_failed_allocations;
   break;
+   case SVGA_QUERY_NUM_COMMANDS_PER_DRAW:
+  vresult->f = (float) svga->swc->num_commands
+ / (float) svga->swc->num_draw_commands;
+  break;
default:
   assert(!"unexpected query type in svga_get_query_result");
}
diff --git a/src/gallium/drivers/svga/svga_screen.c 
b/src/gallium/drivers/svga/svga_screen.c
index 534e94a..5d9d024 100644
--- a/src/gallium/drivers/svga/svga_screen.c
+++ b/src/gallium/drivers/svga/svga_screen.c
@@ -845,6 +845,8 @@ 

[Mesa-dev] [PATCH 1/4] gallium/hud: s/unsigned/enum pipe_query_type/

[Brian Paul]

---
 src/gallium/auxiliary/hud/hud_driver_query.c | 5 +++--
 src/gallium/auxiliary/hud/hud_private.h  | 3 ++-
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/src/gallium/auxiliary/hud/hud_driver_query.c 
b/src/gallium/auxiliary/hud/hud_driver_query.c
index 085bc62..630aae0 100644
--- a/src/gallium/auxiliary/hud/hud_driver_query.c
+++ b/src/gallium/auxiliary/hud/hud_driver_query.c
@@ -194,7 +194,7 @@ hud_batch_query_cleanup(struct hud_batch_query_context 
**pbq,
 
 struct query_info {
struct hud_batch_query_context *batch;
-   unsigned query_type;
+   enum pipe_query_type query_type;
unsigned result_index; /* unit depends on query_type */
enum pipe_driver_query_result_type result_type;
 
@@ -349,7 +349,8 @@ free_query_info(void *ptr, struct pipe_context *pipe)
 void
 hud_pipe_query_install(struct hud_batch_query_context **pbq,
struct hud_pane *pane,
-   const char *name, unsigned query_type,
+   const char *name,
+   enum pipe_query_type query_type,
unsigned result_index,
uint64_t max_value, enum pipe_driver_query_type type,
enum pipe_driver_query_result_type result_type,
diff --git a/src/gallium/auxiliary/hud/hud_private.h 
b/src/gallium/auxiliary/hud/hud_private.h
index 9e8d74c..a51436f 100644
--- a/src/gallium/auxiliary/hud/hud_private.h
+++ b/src/gallium/auxiliary/hud/hud_private.h
@@ -162,7 +162,8 @@ void hud_thread_counter_install(struct hud_pane *pane, 
const char *name,
 enum hud_counter counter);
 void hud_pipe_query_install(struct hud_batch_query_context **pbq,
 struct hud_pane *pane,
-const char *name, unsigned query_type,
+const char *name,
+enum pipe_query_type query_type,
 unsigned result_index,
 uint64_t max_value,
 enum pipe_driver_query_type type,
-- 
2.7.4

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

[Mesa-dev] [PATCH 3/4] gallium/hud: remove uint64_t casts in sensor query_sti_load() function

[Brian Paul]

The hud_graph_add_value() function takes a double value, so just pass
the current/critical values as-is since they're doubles.
---
 src/gallium/auxiliary/hud/hud_sensors_temp.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/src/gallium/auxiliary/hud/hud_sensors_temp.c 
b/src/gallium/auxiliary/hud/hud_sensors_temp.c
index b912a4e..4d3a11b 100644
--- a/src/gallium/auxiliary/hud/hud_sensors_temp.c
+++ b/src/gallium/auxiliary/hud/hud_sensors_temp.c
@@ -165,19 +165,19 @@ query_sti_load(struct hud_graph *gr)
 
  switch (sti->mode) {
  case SENSORS_TEMP_CURRENT:
-hud_graph_add_value(gr, (uint64_t) sti->current);
+hud_graph_add_value(gr, sti->current);
 break;
  case SENSORS_TEMP_CRITICAL:
-hud_graph_add_value(gr, (uint64_t) sti->critical);
+hud_graph_add_value(gr, sti->critical);
 break;
  case SENSORS_VOLTAGE_CURRENT:
-hud_graph_add_value(gr, (uint64_t)(sti->current * 1000));
+hud_graph_add_value(gr, sti->current * 1000);
 break;
  case SENSORS_CURRENT_CURRENT:
-hud_graph_add_value(gr, (uint64_t) sti->current);
+hud_graph_add_value(gr, sti->current);
 break;
  case SENSORS_POWER_CURRENT:
-hud_graph_add_value(gr, (uint64_t) sti->current);
+hud_graph_add_value(gr, sti->current);
 break;
  }
 
-- 
2.7.4

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

[Mesa-dev] [PATCH 2/4] gallium/hud: compute cpu load, percent with doubles

[Brian Paul]

The hud_graph_add_value() function takes a double precision value,
so compute it that way.
---
 src/gallium/auxiliary/hud/hud_cpu.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/src/gallium/auxiliary/hud/hud_cpu.c 
b/src/gallium/auxiliary/hud/hud_cpu.c
index 259bb83..b7a5243 100644
--- a/src/gallium/auxiliary/hud/hud_cpu.c
+++ b/src/gallium/auxiliary/hud/hud_cpu.c
@@ -151,7 +151,8 @@ query_cpu_load(struct hud_graph *gr, struct pipe_context 
*pipe)
 
if (info->last_time) {
   if (info->last_time + gr->pane->period <= now) {
- uint64_t cpu_busy, cpu_total, cpu_load;
+ uint64_t cpu_busy, cpu_total;
+ double cpu_load;
 
  get_cpu_stats(info->cpu_index, _busy, _total);
 
@@ -258,15 +259,15 @@ query_api_thread_busy_status(struct hud_graph *gr, struct 
pipe_context *pipe)
thread_now = 0;
  }
 
- unsigned percent = (thread_now - info->last_thread_time) * 100 /
+ double percent = (thread_now - info->last_thread_time) * 100.0 /
 (now - info->last_time);
 
  /* Check if the context changed a thread, so that we don't show
   * a random value. When a thread is changed, the new thread clock
   * is different, which can result in "percent" being very high.
   */
- if (percent > 100)
-percent = 0;
+ if (percent > 100.0)
+percent = 0.0;
  hud_graph_add_value(gr, percent);
 
  info->last_thread_time = thread_now;
-- 
2.7.4

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

[Mesa-dev] [PATCH 4/4] gallium/hud: Fix support for PIPE_DRIVER_QUERY_TYPE_FLOAT

[Brian Paul]

Evidently, nobody has used PIPE_DRIVER_QUERY_TYPE_FLOAT up to this
point.  Adding a driver query of this type which returns the query
value in pipe_query_result::f resulted in garbage output in the HUD.

The problem is the pipe_query_result::f field was being accessed as
through the u64 field and being added to the query_info::results_cumulative
field.  This patch checks for PIPE_DRIVER_QUERY_TYPE_FLOAT in a few
places and scales the float by 1000 before converting to uint64_t.

Also, add some comments to explain the query_info::result_index field.
---
 src/gallium/auxiliary/hud/hud_context.c  |  5 +
 src/gallium/auxiliary/hud/hud_driver_query.c | 27 ---
 2 files changed, 29 insertions(+), 3 deletions(-)

diff --git a/src/gallium/auxiliary/hud/hud_context.c 
b/src/gallium/auxiliary/hud/hud_context.c
index 64e5579..4d2458e 100644
--- a/src/gallium/auxiliary/hud/hud_context.c
+++ b/src/gallium/auxiliary/hud/hud_context.c
@@ -224,6 +224,7 @@ number_to_human_readable(double num, enum 
pipe_driver_query_type type,
static const char *volt_units[] = {" mV", " V"};
static const char *amp_units[] = {" mA", " A"};
static const char *watt_units[] = {" mW", " W"};
+   static const char *float_units[] = {""};
 
const char **units;
unsigned max_unit;
@@ -252,6 +253,10 @@ number_to_human_readable(double num, enum 
pipe_driver_query_type type,
   max_unit = ARRAY_SIZE(temperature_units)-1;
   units = temperature_units;
   break;
+   case PIPE_DRIVER_QUERY_TYPE_FLOAT:
+  max_unit = ARRAY_SIZE(float_units)-1;
+  units = float_units;
+  break;
case PIPE_DRIVER_QUERY_TYPE_PERCENTAGE:
   max_unit = ARRAY_SIZE(percent_units)-1;
   units = percent_units;
diff --git a/src/gallium/auxiliary/hud/hud_driver_query.c 
b/src/gallium/auxiliary/hud/hud_driver_query.c
index 630aae0..382de1a 100644
--- a/src/gallium/auxiliary/hud/hud_driver_query.c
+++ b/src/gallium/auxiliary/hud/hud_driver_query.c
@@ -195,8 +195,13 @@ hud_batch_query_cleanup(struct hud_batch_query_context 
**pbq,
 struct query_info {
struct hud_batch_query_context *batch;
enum pipe_query_type query_type;
-   unsigned result_index; /* unit depends on query_type */
+
+   /** index to choose fields in pipe_query_data_pipeline_statistics,
+* for example.
+*/
+   unsigned result_index;
enum pipe_driver_query_result_type result_type;
+   enum pipe_driver_query_type type;
 
/* Ring of queries. If a query is busy, we use another slot. */
struct pipe_query *query[NUM_QUERIES];
@@ -238,7 +243,13 @@ query_new_value_normal(struct query_info *info, struct 
pipe_context *pipe)
  uint64_t *res64 = (uint64_t *)
 
  if (query && pipe->get_query_result(pipe, query, FALSE, )) {
-info->results_cumulative += res64[info->result_index];
+if (info->type == PIPE_DRIVER_QUERY_TYPE_FLOAT) {
+   assert(info->result_index == 0);
+   info->results_cumulative += (uint64_t) (result.f * 1000.0f);
+}
+else {
+   info->results_cumulative += res64[info->result_index];
+}
 info->num_results++;
 
 if (info->tail == info->head)
@@ -307,7 +318,7 @@ query_new_value(struct hud_graph *gr, struct pipe_context 
*pipe)
}
 
if (info->num_results && info->last_time + gr->pane->period <= now) {
-  uint64_t value;
+  double value;
 
   switch (info->result_type) {
   default:
@@ -319,6 +330,10 @@ query_new_value(struct hud_graph *gr, struct pipe_context 
*pipe)
  break;
   }
 
+  if (info->type == PIPE_DRIVER_QUERY_TYPE_FLOAT) {
+ value /= 1000.0;
+  }
+
   hud_graph_add_value(gr, value);
 
   info->last_time = now;
@@ -346,6 +361,11 @@ free_query_info(void *ptr, struct pipe_context *pipe)
FREE(info);
 }
 
+
+/**
+ * \param result_index  to select fields of 
pipe_query_data_pipeline_statistics,
+ *  for example.
+ */
 void
 hud_pipe_query_install(struct hud_batch_query_context **pbq,
struct hud_pane *pane,
@@ -374,6 +394,7 @@ hud_pipe_query_install(struct hud_batch_query_context **pbq,
 
info = gr->query_data;
info->result_type = result_type;
+   info->type = type;
 
if (flags & PIPE_DRIVER_QUERY_FLAG_BATCH) {
   if (!batch_query_add(pbq, query_type, >result_index))
-- 
2.7.4

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

[Mesa-dev] [Bug 103078] MATLAB broken with mesa software rendering

[bugzilla-daemon]

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

--- Comment #12 from Timo Aaltonen  ---
this is a bug in jogl, and apparently changing it to detect current Mesa makes
it work again:

https://jogamp.org/bugzilla/show_bug.cgi?id=1357

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

[Mesa-dev] [Bug 103078] MATLAB broken with mesa software rendering

[bugzilla-daemon]

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

--- Comment #11 from Timo Aaltonen  ---
*** Bug 103217 has been marked as a duplicate of this bug. ***

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

[Mesa-dev] [Bug 103078] MATLAB broken with mesa software rendering

[bugzilla-daemon]

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

Timo Aaltonen  changed:

   What|Removed |Added

 CC||azari4...@gmail.com

--- Comment #10 from Timo Aaltonen  ---
*** Bug 103976 has been marked as a duplicate of this bug. ***

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

[Mesa-dev] [PATCH 7/7 RFC] report.py: Gather and log some statistics about the helped / hurt data

[Ian Romanick]

From: Ian Romanick 

Also perform a T-test on the helped and hurt, and provide a
recommendation based on the result of the T-test.  I have seen several
instances where the result of the T-test is the opposite of what you
would expect by looking at the other logged data, so I'm not sure how
useful / correct this is.

Signed-off-by: Ian Romanick 
---
 report.py | 85 ++-
 1 file changed, 84 insertions(+), 1 deletion(-)

diff --git a/report.py b/report.py
index 175a953..d10cb84 100755
--- a/report.py
+++ b/report.py
@@ -2,6 +2,9 @@
 
 import re
 import argparse
+import statistics
+from scipy import stats
+import numpy
 
 
 def get_results(filename):
@@ -63,6 +66,27 @@ def get_result_string(p, b, a):
 def split_list(string):
 return string.split(",")
 
+
+def gather_statistics(changes, before, after, m):
+stats = (0.0, 0, 0.0, 0, 0, 0.0, 0.0, 0.0, 0.0, 0.0)
+
+num = len(changes)
+if num > 0:
+absolute = [abs(before[p][m] - after[p][m]) for p in changes]
+relative = [0 if before[p][m] == 0 else abs(before[p][m] - 
after[p][m]) / before[p][m] for p in changes]
+
+stats = (statistics.mean(absolute),
+ statistics.median(absolute),
+ min(absolute),
+ max(absolute),
+ statistics.mean(relative),
+ statistics.median(relative),
+ min(relative),
+ max(relative))
+
+return stats
+
+
 def main():
 parser = argparse.ArgumentParser()
 parser.add_argument("--measurements", "-m", type=split_list,
@@ -82,6 +106,9 @@ def main():
 affected_after = {}
 num_hurt = {}
 num_helped = {}
+helped_statistics = {}
+hurt_statistics = {}
+t_test = {}
 
 for m in args.measurements:
 total_before[m] = 0
@@ -135,9 +162,18 @@ def main():
 if len(hurt) > 0:
 print("")
 
+helped_statistics[m] = gather_statistics(helped, args.before, 
args.after, m)
+hurt_statistics[m] = gather_statistics(hurt, args.before, args.after, 
m)
+
 num_helped[m] = len(helped)
 num_hurt[m] = len(hurt)
 
+if num_hurt[m] >= 2 and num_helped[m] >= 2:
+A = [abs(args.before[p][m] - args.after[p][m]) for p in helped]
+B = [abs(args.before[p][m] - args.after[p][m]) for p in hurt]
+C = [0 if args.before[p][m] == 0 else abs(args.before[p][m] - 
args.after[p][m]) / args.before[p][m] for p in helped]
+D = [0 if args.before[p][m] == 0 else abs(args.before[p][m] - 
args.after[p][m]) / args.before[p][m] for p in hurt]
+t_test[m] = stats.ttest_ind(A, B) + stats.ttest_ind(C, D)
 
 lost = []
 gained = []
@@ -172,13 +208,60 @@ def main():
 print("total {0} in shared programs: {1}\n"
   "{0} in affected programs: {2}\n"
   "helped: {3}\n"
-  "HURT: {4}\n".format(
+  "HURT: {4}".format(
  m,
  change(total_before[m], total_after[m]),
  change(affected_before[m], affected_after[m]),
  num_helped[m],
  num_hurt[m]))
 
+# Statistics for spills and fills is usually meaningless.
+if m in ["spills", "fills"]:
+print()
+continue
+
+if num_helped[m] > 2 or (num_helped[m] > 0 and num_hurt[m] > 0):
+(avg_abs, med_abs, lo_abs, hi_abs, avg_rel, med_rel, lo_rel, 
hi_rel) = helped_statistics[m]
+
+print("helped stats (abs) min: {} max: {} x\u0304: {:.2f} 
x\u0303: {}".format(
+lo_abs, hi_abs, avg_abs, int(med_abs)))
+print("helped stats (rel) min: {} max: {} x\u0304: {} x\u0303: 
{}".format(
+format_percent(lo_rel),
+format_percent(hi_rel),
+format_percent(avg_rel),
+format_percent(med_rel)))
+
+if num_hurt[m] > 2 or (num_hurt[m] > 0 and num_helped[m] > 0):
+(avg_abs, med_abs, lo_abs, hi_abs, avg_rel, med_rel, lo_rel, 
hi_rel) = hurt_statistics[m]
+
+print("HURT stats (abs)   min: {} max: {} x\u0304: {:.2f} 
x\u0303: {}".format(
+lo_abs, hi_abs, avg_abs, int(med_abs)))
+print("HURT stats (rel)   min: {} max: {} x\u0304: {} x\u0303: 
{}".format(
+format_percent(lo_rel),
+format_percent(hi_rel),
+format_percent(avg_rel),
+format_percent(med_rel)))
+
+if m in t_test:
+print("abs t: {}, p: {}".format(t_test[m][0], t_test[m][1]))
+print("rel t: {}, p: {}".format(t_test[m][2], t_test[m][3]))
+
+# Be very, very conservative about applying results of the
+

[Mesa-dev] [PATCH 3/7] intel_run: Fix typo in LD_PRELOAD handling

[Ian Romanick]

From: Ian Romanick 

Signed-off-by: Ian Romanick 
---
 intel_run | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/intel_run b/intel_run
index 10114ff..5a162f8 100755
--- a/intel_run
+++ b/intel_run
@@ -1,5 +1,5 @@
 #!/bin/bash
 # -*- mode: sh -*-
 
-LD_PRELOAD=${PWD}/intel_stub.so${LD_PPRELOAD:+:${LD_PRELOAD}} \
+LD_PRELOAD=${PWD}/intel_stub.so${LD_PRELOAD:+:${LD_PRELOAD}} \
  exec ./run $@
-- 
2.9.5

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

[Mesa-dev] [PATCH 4/7] report.py: Add option to only display the final summary

[Ian Romanick]

From: Ian Romanick 

This is useful for preparing data to go in a Mesa commit message.

Signed-off-by: Ian Romanick 
---
 report.py | 60 
 1 file changed, 32 insertions(+), 28 deletions(-)

diff --git a/report.py b/report.py
index 003a1ee..e0068bc 100755
--- a/report.py
+++ b/report.py
@@ -60,6 +60,8 @@ def main():
 parser.add_argument("--measurements", "-m", type=split_list,
 default=["instructions", "cycles", "loops", "spills", 
"fills"],
 help="comma-separated list of measurements to report")
+parser.add_argument("--summary-only", "-s", action="store_true", 
default=False,
+help="do not show the per-shader helped / hurt data")
 parser.add_argument("before", type=get_results, help="the output of the 
original code")
 parser.add_argument("after", type=get_results, help="the output of the new 
code")
 args = parser.parse_args()
@@ -104,23 +106,24 @@ def main():
 else:
 helped.append(p)
 
-helped.sort(
-key=lambda k: args.after[k][m] if args.before[k][m] == 0 else 
float(args.before[k][m] - args.after[k][m]) / args.before[k][m])
-for p in helped:
-namestr = p[0] + " " + p[1]
-print(m + " helped:   " + get_result_string(
-namestr, args.before[p][m], args.after[p][m]))
-if len(helped) > 0:
-print("")
-
-hurt.sort(
-key=lambda k: args.after[k][m] if args.before[k][m] == 0 else 
float(args.after[k][m] - args.before[k][m]) / args.before[k][m])
-for p in hurt:
-namestr = p[0] + " " + p[1]
-print(m + " HURT:   " + get_result_string(
-namestr, args.before[p][m], args.after[p][m]))
-if len(hurt) > 0:
-print("")
+if not args.summary_only:
+helped.sort(
+key=lambda k: args.after[k][m] if args.before[k][m] == 0 else 
float(args.before[k][m] - args.after[k][m]) / args.before[k][m])
+for p in helped:
+namestr = p[0] + " " + p[1]
+print(m + " helped:   " + get_result_string(
+namestr, args.before[p][m], args.after[p][m]))
+if len(helped) > 0:
+print("")
+
+hurt.sort(
+key=lambda k: args.after[k][m] if args.before[k][m] == 0 
else float(args.after[k][m] - args.before[k][m]) / args.before[k][m])
+for p in hurt:
+namestr = p[0] + " " + p[1]
+print(m + " HURT:   " + get_result_string(
+namestr, args.before[p][m], args.after[p][m]))
+if len(hurt) > 0:
+print("")
 
 num_helped[m] = len(helped)
 num_hurt[m] = len(hurt)
@@ -137,17 +140,18 @@ def main():
 if args.before.get(p) is None:
 gained.append(p[0] + " " + p[1])
 
-lost.sort()
-for p in lost:
-print("LOST:   " + p)
-if len(lost) > 0:
-print("")
-
-gained.sort()
-for p in gained:
-print("GAINED: " + p)
-if len(gained) > 0:
-print("")
+if not args.summary_only:
+lost.sort()
+for p in lost:
+print("LOST:   " + p)
+if len(lost) > 0:
+print("")
+
+gained.sort()
+for p in gained:
+print("GAINED: " + p)
+if len(gained) > 0:
+print("")
 
 for m in args.measurements:
 print("total {0} in shared programs: {1}\n"
-- 
2.9.5

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

[Mesa-dev] [PATCH 6/7] report.py: Print small percentages as <.01%

[Ian Romanick]

From: Ian Romanick 

Previously an absolute value less than 0.0001 would be printed as 0.00%.

Signed-off-by: Ian Romanick 
---
 report.py | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/report.py b/report.py
index 72752c1..175a953 100755
--- a/report.py
+++ b/report.py
@@ -34,10 +34,18 @@ def get_results(filename):
 return results
 
 
+def format_percent(frac):
+"""Converts a factional value (typically 0.0 to 1.0) to a string as a 
percentage"""
+if abs(frac) > 0.0 and abs(frac) < 0.0001:
+return "<.01%"
+else:
+return "{:.2f}%".format(frac * 100)
+
+
 def get_delta(b, a):
 if b != 0 and a != 0:
 frac = float(a) / float(b) - 1.0
-return ' ({:.2f}%)'.format(frac * 100.0)
+return ' ({})'.format(format_percent(frac))
 else:
 return ''
 
-- 
2.9.5

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

[Mesa-dev] [PATCH 5/7] report.py: Add option to only display measurements that have changes

[Ian Romanick]

From: Ian Romanick 

This is useful for preparing data to go in a Mesa commit message.

Signed-off-by: Ian Romanick 
---
 report.py | 53 +++--
 1 file changed, 31 insertions(+), 22 deletions(-)

diff --git a/report.py b/report.py
index e0068bc..72752c1 100755
--- a/report.py
+++ b/report.py
@@ -62,6 +62,8 @@ def main():
 help="comma-separated list of measurements to report")
 parser.add_argument("--summary-only", "-s", action="store_true", 
default=False,
 help="do not show the per-shader helped / hurt data")
+parser.add_argument("--changes-only", "-c", action="store_true", 
default=False,
+help="only show measurements that have changes")
 parser.add_argument("before", type=get_results, help="the output of the 
original code")
 parser.add_argument("after", type=get_results, help="the output of the new 
code")
 args = parser.parse_args()
@@ -116,14 +118,14 @@ def main():
 if len(helped) > 0:
 print("")
 
-hurt.sort(
-key=lambda k: args.after[k][m] if args.before[k][m] == 0 
else float(args.after[k][m] - args.before[k][m]) / args.before[k][m])
-for p in hurt:
-namestr = p[0] + " " + p[1]
-print(m + " HURT:   " + get_result_string(
-namestr, args.before[p][m], args.after[p][m]))
-if len(hurt) > 0:
-print("")
+hurt.sort(
+key=lambda k: args.after[k][m] if args.before[k][m] == 0 else 
float(args.after[k][m] - args.before[k][m]) / args.before[k][m])
+for p in hurt:
+namestr = p[0] + " " + p[1]
+print(m + " HURT:   " + get_result_string(
+namestr, args.before[p][m], args.after[p][m]))
+if len(hurt) > 0:
+print("")
 
 num_helped[m] = len(helped)
 num_hurt[m] = len(hurt)
@@ -153,21 +155,28 @@ def main():
 if len(gained) > 0:
 print("")
 
+any_helped_or_hurt = False
 for m in args.measurements:
-print("total {0} in shared programs: {1}\n"
-  "{0} in affected programs: {2}\n"
-  "helped: {3}\n"
-  "HURT: {4}\n".format(
-   m,
-   change(total_before[m], total_after[m]),
-   change(affected_before[m], affected_after[m]),
-   num_helped[m],
-   num_hurt[m]))
-
-
-print("LOST:   " + str(len(lost)))
-print("GAINED: " + str(len(gained)))
-
+if num_helped[m] > 0 or num_hurt[m] > 0:
+any_helped_or_hurt = True
+
+if num_helped[m] > 0 or num_hurt[m] > 0 or not args.changes_only:
+print("total {0} in shared programs: {1}\n"
+  "{0} in affected programs: {2}\n"
+  "helped: {3}\n"
+  "HURT: {4}\n".format(
+ m,
+ change(total_before[m], total_after[m]),
+ change(affected_before[m], affected_after[m]),
+ num_helped[m],
+ num_hurt[m]))
+
+if len(lost) > 0 or len(gained) > 0 or not args.changes_only:
+print("LOST:   " + str(len(lost)))
+print("GAINED: " + str(len(gained)))
+
+if args.changes_only and len(lost) == 0 and len(gained) == 0 and not 
any_helped_or_hurt:
+print("No changes.")
 
 if __name__ == "__main__":
 main()
-- 
2.9.5

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

[Mesa-dev] [PATCH 2/7] run: Use case independent matching for platform names

[Ian Romanick]

From: Ian Romanick 

All my scripts use uppercase names to generate names for results files.

Signed-off-by: Ian Romanick 
---
 run.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/run.c b/run.c
index 69fe23d..aa26946 100644
--- a/run.c
+++ b/run.c
@@ -395,7 +395,7 @@ main(int argc, char **argv)
 case 'p': {
 const struct platform *platform = NULL;
 for (unsigned i = 0; i < ARRAY_SIZE(platforms); i++) {
-if (strcmp(optarg, platforms[i].name) == 0) {
+if (strcasecmp(optarg, platforms[i].name) == 0) {
 platform = platforms + i;
 break;
 }
-- 
2.9.5

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

[Mesa-dev] [PATCH 1/7] Allow warsow 85.shader_test to build on GLSL 1.20

[Ian Romanick]

From: Ian Romanick 

Nothing in the shader actually requires 1.30.  This allows it to build
on GM45 and Iron Lake... and other platforms stuck at GLSL 1.20.

Signed-off-by: Ian Romanick 
---
 shaders/warsow/85.shader_test | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/shaders/warsow/85.shader_test b/shaders/warsow/85.shader_test
index 7082f77..2b73434 100644
--- a/shaders/warsow/85.shader_test
+++ b/shaders/warsow/85.shader_test
@@ -1,10 +1,10 @@
 [require]
-GLSL >= 1.30
+GLSL >= 1.20
 
 [vertex shader]
-#version 130
+#version 120
 #extension GL_ARB_draw_instanced : enable
-#define QF_GLSL_VERSION 130
+#define QF_GLSL_VERSION 120
 #define VERTEX_SHADER
 #if !defined(myhalf)
 //#if !defined(__GLSL_CG_DATA_TYPES)
@@ -1030,9 +1030,9 @@ color = color * diffuse;
 #endif // FRAGMENT_SHADER
 
 [fragment shader]
-#version 130
+#version 120
 
-#define QF_GLSL_VERSION 130
+#define QF_GLSL_VERSION 120
 #define FRAGMENT_SHADER
 #if !defined(myhalf)
 //#if !defined(__GLSL_CG_DATA_TYPES)
-- 
2.9.5

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

Re: [Mesa-dev] [PATCH 18/29] intel/blorp: Add a blorp_hiz_clear_depth_stencil helper

[Nanley Chery]

On Mon, Nov 27, 2017 at 07:06:08PM -0800, Jason Ekstrand wrote:
> This is similar to blorp_gen8_hiz_clear_attachments except that it takes
> actual images instead of trusting in the already set depth state.
> ---
>  src/intel/blorp/blorp.h   | 11 ++
>  src/intel/blorp/blorp_clear.c | 50 
> +++
>  2 files changed, 61 insertions(+)
> 
> diff --git a/src/intel/blorp/blorp.h b/src/intel/blorp/blorp.h
> index a1dd571..208b2db 100644
> --- a/src/intel/blorp/blorp.h
> +++ b/src/intel/blorp/blorp.h
> @@ -170,6 +170,17 @@ blorp_can_hiz_clear_depth(uint8_t gen, enum isl_format 
> format,
>uint32_t num_samples,
>uint32_t x0, uint32_t y0,
>uint32_t x1, uint32_t y1);
> +void
> +blorp_hiz_clear_depth_stencil(struct blorp_batch *batch,
> +  const struct blorp_surf *depth,
> +  const struct blorp_surf *stencil,
> +  uint32_t level,
> +  uint32_t start_layer, uint32_t num_layers,
> +  uint32_t x0, uint32_t y0,
> +  uint32_t x1, uint32_t y1,
> +  bool clear_depth, float depth_value,
> +  bool clear_stencil, uint8_t stencil_value);
> +
>  
>  void
>  blorp_gen8_hiz_clear_attachments(struct blorp_batch *batch,
> diff --git a/src/intel/blorp/blorp_clear.c b/src/intel/blorp/blorp_clear.c
> index 8e7bc9f..ec859c2 100644
> --- a/src/intel/blorp/blorp_clear.c
> +++ b/src/intel/blorp/blorp_clear.c
> @@ -612,6 +612,56 @@ blorp_can_hiz_clear_depth(uint8_t gen, enum isl_format 
> format,
> return true;
>  }
>  
> +void
> +blorp_hiz_clear_depth_stencil(struct blorp_batch *batch,
> +  const struct blorp_surf *depth,
> +  const struct blorp_surf *stencil,
> +  uint32_t level,
> +  uint32_t start_layer, uint32_t num_layers,
> +  uint32_t x0, uint32_t y0,
> +  uint32_t x1, uint32_t y1,
> +  bool clear_depth, float depth_value,
> +  bool clear_stencil, uint8_t stencil_value)
> +{
> +   struct blorp_params params;
> +   blorp_params_init();
> +
> +   /* This requires WM_HZ_OP which only exists on gen8+ */
> +   assert(ISL_DEV_GEN(batch->blorp->isl_dev) >= 8);
> +
> +   params.hiz_op = BLORP_HIZ_OP_DEPTH_CLEAR;
> +   params.num_layers = 1;
> +
> +   params.x0 = x0;
> +   params.y0 = y0;
> +   params.x1 = x1;
> +   params.y1 = y1;
> +
> +   for (uint32_t l = 0; l < num_layers; l++) {
> +  const uint32_t layer = start_layer + l;
> +  if (clear_stencil) {
> + brw_blorp_surface_info_init(batch->blorp, , stencil,
> + level, layer,
> + ISL_FORMAT_UNSUPPORTED, true);

How does this stencil surface and the depth surface below get used? Once
params.hiz_op is set to anything other than BLORP_HIZ_OP_NONE, we call
blorp_emit_gen8_hiz_op and return early from blorp_exec().

> + params.stencil_mask = 0xff;
> + params.stencil_ref = stencil_value;
> + params.num_samples = params.stencil.surf.samples;
> +  }
> +
> +  if (clear_depth) {
> + brw_blorp_surface_info_init(batch->blorp, , depth,
> + level, layer,
> + ISL_FORMAT_UNSUPPORTED, true);
> + params.depth.clear_color.f32[0] = depth_value;
> + params.depth_format =
> +isl_format_get_depth_format(depth->surf->format, false);
> + params.num_samples = params.depth.surf.samples;
> +  }
> +
> +  batch->blorp->exec(batch, );
> +   }
> +}
> +
>  /* Given a depth stencil attachment, this function performs a fast depth 
> clear
>   * on a depth portion and a regular clear on the stencil portion. When
>   * performing a fast depth clear on the depth portion, the HiZ buffer is 
> simply
> -- 
> 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] [RFC libdrm 0/5] Move alloc_handle_t from gralloc impls.

[Rob Herring]

On Fri, Jan 12, 2018 at 2:29 AM, Tomasz Figa  wrote:
> Hi Rob,
>
> On Fri, Jan 12, 2018 at 5:26 AM, Robert Foss  
> wrote:
>> Heya,
>>
>>
>> On 12/22/17 1:09 PM, Tomasz Figa wrote:
>>>
>>> On Fri, Dec 22, 2017 at 10:09 AM, Gurchetan Singh
>>>  wrote:

 So the plan is for alloc_handle_t to not be sub-classed by the
 implementations, but have all necessary information that an
 implementation
 would need?

 If so, how do we reconcile the implementation specific information that
 is
 often in the handle:


 https://github.com/intel/minigbm/blob/master/cros_gralloc/cros_gralloc_handle.h
 [consumer_usage, producer_usage, yuv_color_range, is_updated etc.]


 https://chromium.googlesource.com/chromiumos/platform/minigbm/+/master/cros_gralloc/cros_gralloc_handle.h
 [use_flags, pixel_stride]

 In our case, removing our minigbm specific use flags from the handle
 would
 add complexity to our (*registerBuffer) path.

 On Thu, Dec 21, 2017 at 10:14 AM, Rob Herring  wrote:
>
>
> On Wed, Dec 13, 2017 at 5:02 PM, Gurchetan Singh
>  wrote:
>>
>> Hi Robert,
>>
>> Thanks for looking into this!  We need to decide if we want:
>>
>> (1) A common struct that implementations can subclass, i.e:
>>
>> struct blah_gralloc_handle {
>>  alloc_handle_t alloc_handle;
>>  int x, y, z;
>>  
>> }
>>
>> (2) An accessor library that vendors can implement, i.e:
>>
>> struct drmAndroidHandleInfo {
>> uint32_t (*get_fourcc)(buffer_handle_t handle);
>> uint32_t (*get_stride)(buffer_handle_t handle, uint32_t plane);
>> uint32_t (*get_offsets)(buffer_handle_t handle, uint32_t plane);
>> uint64_t (*get_modifier)(buffer_handle_t handle);
>> };
>>
>>  From my perspective as someone who has to maintain the minigbm gralloc
>> implementation, (2) is preferable since:
>
>
> Yeah, I'd prefer not to encourage 1 as the default.
>
>>
>> So I had a look into implementing this,
>
> Thanks!
>
>> and using function pointers is
>> problematic due to this struct being passed between processes which would
>> prevent mesa calling a function assigned in gbm_gralloc for example.
>
> Why would be this struct passed between processes?
>
> The only data being exchanged between processes using gralloc is the
> handle and it isn't actually exchanged directly, but the exporting
> process will flatten it and send through Binder, while the importing
> one will have it unflattened and then the gralloc implementation
> called on it (the register buffer operation), which could update any
> per-process data in the handle. (But still, why would we need to
> include the function pointers there?)
>
>>
>> It could be used to provide runtime support for multiple gralloc
>> implementations, but that seems to about the only advantage to adding FPs.
>>
>> Am I missing a good usecase for FPs? If not I think the added
>> complexity/cruft is more problematic than good.
>>
>> Any thoughts?
>>
>
> I guess it might not be a big deal whether FPs or structs are used, as
> long as they are not directly embedded in the handle, which we don't
> want constraints on.

Why no constraints? Is converging on a common handle really that hard?
It is mostly all the same data. Some of the differences are just
because a particular implementation hasn't addressed some feature
(e.g. planar formats). There's other things like the pid and data ptr
in drm_gralloc and gbm_gralloc that really should be removed (it's
just for tracking imports). If we have some fields that are unused by
some implementations, that seems fine to me.

We're really only talking about what is the interface to mesa and
drm_hwc for handles (and mostly drm_hwc because mesa just needs the
dma-buf fd(s)). Today it is simply accessing the raw handle. Moving
that to libdrm doesn't change that and is no worse. It's at least
better in that drm_gralloc and gbm_gralloc can share it. Making it
work with cros_gralloc doesn't seem hard. We can define accessor
functions too (not ptrs), then the struct is opaque and you can do
your own accessor implementation if aligning is not possible or
desired. Or you can do your own importer within drm_hwc too.

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

Re: [Mesa-dev] [PATCH 3/4] i965/bufmgr: Add a set_tiling helper

[Jason Ekstrand]

On Fri, Jan 12, 2018 at 1:28 AM, Chris Wilson 
wrote:

> Quoting Jason Ekstrand (2018-01-12 01:40:52)
> > This helper should be used carefully as setting tiling is a racy
> > operation since it potentially interacts with other processes.  Still,
> > it is a useful thing to be able to do.
> >
> > Cc: mesa-sta...@lists.freedesktop.org
> > ---
> >  src/mesa/drivers/dri/i965/brw_bufmgr.c | 27 +++
> >  src/mesa/drivers/dri/i965/brw_bufmgr.h | 10 ++
> >  2 files changed, 37 insertions(+)
> >
> > diff --git a/src/mesa/drivers/dri/i965/brw_bufmgr.c
> b/src/mesa/drivers/dri/i965/brw_bufmgr.c
> > index 469895e..dbd13dd 100644
> > --- a/src/mesa/drivers/dri/i965/brw_bufmgr.c
> > +++ b/src/mesa/drivers/dri/i965/brw_bufmgr.c
> > @@ -1133,6 +1133,33 @@ brw_bo_get_tiling(struct brw_bo *bo, uint32_t
> *tiling_mode,
> > return 0;
> >  }
> >
> > +int
> > +brw_bo_set_tiling(struct brw_bo *bo, uint32_t tiling_mode,
> > +  uint32_t stride)
> > +{
> > +   struct brw_bufmgr *bufmgr = bo->bufmgr;
> > +
> > +   mtx_lock(>lock);
>
> This mutex protects the buffer cache, which should not be containing
> this bo. Changing the tiling of a shared active bo also should not
> happen because the other parties will have already derived state from
> the older tiling. So I don't see the purpose of this mutex here.
>

It can, in theory, if we have simultaneous imports on two different
contexts.  That's a bit of a crazy case, I'll agree, but it can happen and
I don't want there to be any chance of corruption of the internal state of
the BO.  Setting tiling from two different contexts simultaneously is racy,
I'll grant, but there are many other reasons why BO tilings are racy and/or
problematic so I don't really want to get hung up on it.

Also, FYI, I expect this patch (and 4/4) to live in 17.3 only and in master
for about a week or two before Scott gets rid of GTT maps and we stop
setting tiling on any BOs except legacy (non-modifiers) window-system ones.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 17/29] anv/cmd_buffer: Move the color portion of clear_subpass into begin_subpass

[Nanley Chery]

On Mon, Nov 27, 2017 at 07:06:07PM -0800, Jason Ekstrand wrote:
> This doesn't really change much now but it will give us more/better
> control over clears in the future.  The one interesting functional
> change here is that we are now re-emitting 3DSTATE_DEPTH_BUFFERS and
> friends for each clear.  However, this only happens at begin_subpass
> time so it shouldn't be substantially more expensive.
> ---
>  src/intel/vulkan/anv_blorp.c   | 115 
> +++--
>  src/intel/vulkan/anv_private.h |   8 +++
>  src/intel/vulkan/genX_cmd_buffer.c |  46 ++-
>  3 files changed, 86 insertions(+), 83 deletions(-)
> 

This patch is
Reviewed-by: Nanley Chery 

> diff --git a/src/intel/vulkan/anv_blorp.c b/src/intel/vulkan/anv_blorp.c
> index 46e2eb0..7401234 100644
> --- a/src/intel/vulkan/anv_blorp.c
> +++ b/src/intel/vulkan/anv_blorp.c
> @@ -1138,17 +1138,6 @@ subpass_needs_clear(const struct anv_cmd_buffer 
> *cmd_buffer)
> const struct anv_cmd_state *cmd_state = _buffer->state;
> uint32_t ds = cmd_state->subpass->depth_stencil_attachment.attachment;
>  
> -   for (uint32_t i = 0; i < cmd_state->subpass->color_count; ++i) {
> -  uint32_t a = cmd_state->subpass->color_attachments[i].attachment;
> -  if (a == VK_ATTACHMENT_UNUSED)
> - continue;
> -
> -  assert(a < cmd_state->pass->attachment_count);
> -  if (cmd_state->attachments[a].pending_clear_aspects) {
> - return true;
> -  }
> -   }
> -
> if (ds != VK_ATTACHMENT_UNUSED) {
>assert(ds < cmd_state->pass->attachment_count);
>if (cmd_state->attachments[ds].pending_clear_aspects)
> @@ -1182,77 +1171,6 @@ anv_cmd_buffer_clear_subpass(struct anv_cmd_buffer 
> *cmd_buffer)
> };
>  
> struct anv_framebuffer *fb = cmd_buffer->state.framebuffer;
> -   for (uint32_t i = 0; i < cmd_state->subpass->color_count; ++i) {
> -  const uint32_t a = cmd_state->subpass->color_attachments[i].attachment;
> -  if (a == VK_ATTACHMENT_UNUSED)
> - continue;
> -
> -  assert(a < cmd_state->pass->attachment_count);
> -  struct anv_attachment_state *att_state = _state->attachments[a];
> -
> -  if (!att_state->pending_clear_aspects)
> - continue;
> -
> -  assert(att_state->pending_clear_aspects == VK_IMAGE_ASPECT_COLOR_BIT);
> -
> -  struct anv_image_view *iview = fb->attachments[a];
> -  const struct anv_image *image = iview->image;
> -  struct blorp_surf surf;
> -  get_blorp_surf_for_anv_image(cmd_buffer->device,
> -   image, VK_IMAGE_ASPECT_COLOR_BIT,
> -   att_state->aux_usage, );
> -
> -  if (att_state->fast_clear) {
> - surf.clear_color = vk_to_isl_color(att_state->clear_value.color);
> -
> - /* From the Sky Lake PRM Vol. 7, "Render Target Fast Clear":
> -  *
> -  *"After Render target fast clear, pipe-control with color cache
> -  *write-flush must be issued before sending any DRAW commands on
> -  *that render target."
> -  *
> -  * This comment is a bit cryptic and doesn't really tell you what's
> -  * going or what's really needed.  It appears that fast clear ops 
> are
> -  * not properly synchronized with other drawing.  This means that we
> -  * cannot have a fast clear operation in the pipe at the same time 
> as
> -  * other regular drawing operations.  We need to use a PIPE_CONTROL
> -  * to ensure that the contents of the previous draw hit the render
> -  * target before we resolve and then use a second PIPE_CONTROL after
> -  * the resolve to ensure that it is completed before any additional
> -  * drawing occurs.
> -  */
> - cmd_buffer->state.pending_pipe_bits |=
> -ANV_PIPE_RENDER_TARGET_CACHE_FLUSH_BIT | ANV_PIPE_CS_STALL_BIT;
> -
> - assert(image->n_planes == 1);
> - blorp_fast_clear(, , iview->planes[0].isl.format,
> -  iview->planes[0].isl.base_level,
> -  iview->planes[0].isl.base_array_layer, fb->layers,
> -  render_area.offset.x, render_area.offset.y,
> -  render_area.offset.x + render_area.extent.width,
> -  render_area.offset.y + render_area.extent.height);
> -
> - cmd_buffer->state.pending_pipe_bits |=
> -ANV_PIPE_RENDER_TARGET_CACHE_FLUSH_BIT | ANV_PIPE_CS_STALL_BIT;
> -  } else {
> - assert(image->n_planes == 1);
> - anv_cmd_buffer_mark_image_written(cmd_buffer, image,
> -   VK_IMAGE_ASPECT_COLOR_BIT,
> -   att_state->aux_usage,
> -   iview->planes[0].isl.base_level);
> -
> - blorp_clear(, , iview->planes[0].isl.format,
> - 

Re: [Mesa-dev] [PATCH 17/29] anv/cmd_buffer: Move the color portion of clear_subpass into begin_subpass

[Pohjolainen, Topi]

On Thu, Jan 11, 2018 at 01:50:41PM -0800, Nanley Chery wrote:
> On Fri, Dec 08, 2017 at 04:16:04PM +0200, Pohjolainen, Topi wrote:
> > On Mon, Nov 27, 2017 at 07:06:07PM -0800, Jason Ekstrand wrote:
> > > This doesn't really change much now but it will give us more/better
> > > control over clears in the future.  The one interesting functional
> > > change here is that we are now re-emitting 3DSTATE_DEPTH_BUFFERS and
> > > friends for each clear.  However, this only happens at begin_subpass
> > > time so it shouldn't be substantially more expensive.
> > > ---
> > >  src/intel/vulkan/anv_blorp.c   | 115 
> > > +++--
> > >  src/intel/vulkan/anv_private.h |   8 +++
> > >  src/intel/vulkan/genX_cmd_buffer.c |  46 ++-
> > >  3 files changed, 86 insertions(+), 83 deletions(-)
> > > 
> > > diff --git a/src/intel/vulkan/anv_blorp.c b/src/intel/vulkan/anv_blorp.c
> > > index 46e2eb0..7401234 100644
> > > --- a/src/intel/vulkan/anv_blorp.c
> > > +++ b/src/intel/vulkan/anv_blorp.c
> > > @@ -1138,17 +1138,6 @@ subpass_needs_clear(const struct anv_cmd_buffer 
> > > *cmd_buffer)
> > > const struct anv_cmd_state *cmd_state = _buffer->state;
> > > uint32_t ds = cmd_state->subpass->depth_stencil_attachment.attachment;
> > >  
> > > -   for (uint32_t i = 0; i < cmd_state->subpass->color_count; ++i) {
> > > -  uint32_t a = cmd_state->subpass->color_attachments[i].attachment;
> > > -  if (a == VK_ATTACHMENT_UNUSED)
> > > - continue;
> > > -
> > > -  assert(a < cmd_state->pass->attachment_count);
> > > -  if (cmd_state->attachments[a].pending_clear_aspects) {
> > > - return true;
> > > -  }
> > > -   }
> > > -
> > > if (ds != VK_ATTACHMENT_UNUSED) {
> > >assert(ds < cmd_state->pass->attachment_count);
> > >if (cmd_state->attachments[ds].pending_clear_aspects)
> > > @@ -1182,77 +1171,6 @@ anv_cmd_buffer_clear_subpass(struct anv_cmd_buffer 
> > > *cmd_buffer)
> > > };
> > >  
> > > struct anv_framebuffer *fb = cmd_buffer->state.framebuffer;
> > > -   for (uint32_t i = 0; i < cmd_state->subpass->color_count; ++i) {
> > > -  const uint32_t a = 
> > > cmd_state->subpass->color_attachments[i].attachment;
> > > -  if (a == VK_ATTACHMENT_UNUSED)
> > > - continue;
> > > -
> > > -  assert(a < cmd_state->pass->attachment_count);
> > > -  struct anv_attachment_state *att_state = 
> > > _state->attachments[a];
> > > -
> > > -  if (!att_state->pending_clear_aspects)
> > > - continue;
> > > -
> > > -  assert(att_state->pending_clear_aspects == 
> > > VK_IMAGE_ASPECT_COLOR_BIT);
> > > -
> > > -  struct anv_image_view *iview = fb->attachments[a];
> > > -  const struct anv_image *image = iview->image;
> > > -  struct blorp_surf surf;
> > > -  get_blorp_surf_for_anv_image(cmd_buffer->device,
> > > -   image, VK_IMAGE_ASPECT_COLOR_BIT,
> > > -   att_state->aux_usage, );
> > > -
> > > -  if (att_state->fast_clear) {
> > > - surf.clear_color = 
> > > vk_to_isl_color(att_state->clear_value.color);
> > > -
> > > - /* From the Sky Lake PRM Vol. 7, "Render Target Fast Clear":
> > > -  *
> > > -  *"After Render target fast clear, pipe-control with color 
> > > cache
> > > -  *write-flush must be issued before sending any DRAW 
> > > commands on
> > > -  *that render target."
> > > -  *
> > > -  * This comment is a bit cryptic and doesn't really tell you 
> > > what's
> > > -  * going or what's really needed.  It appears that fast clear 
> > > ops are
> > > -  * not properly synchronized with other drawing.  This means 
> > > that we
> > > -  * cannot have a fast clear operation in the pipe at the same 
> > > time as
> > > -  * other regular drawing operations.  We need to use a 
> > > PIPE_CONTROL
> > > -  * to ensure that the contents of the previous draw hit the 
> > > render
> > > -  * target before we resolve and then use a second PIPE_CONTROL 
> > > after
> > > -  * the resolve to ensure that it is completed before any 
> > > additional
> > > -  * drawing occurs.
> > > -  */
> > > - cmd_buffer->state.pending_pipe_bits |=
> > > -ANV_PIPE_RENDER_TARGET_CACHE_FLUSH_BIT | 
> > > ANV_PIPE_CS_STALL_BIT;
> > > -
> > > - assert(image->n_planes == 1);
> > > - blorp_fast_clear(, , iview->planes[0].isl.format,
> > > -  iview->planes[0].isl.base_level,
> > > -  iview->planes[0].isl.base_array_layer, 
> > > fb->layers,
> > > -  render_area.offset.x, render_area.offset.y,
> > > -  render_area.offset.x + 
> > > render_area.extent.width,
> > > -  render_area.offset.y + 
> > > render_area.extent.height);
> > > -
> > > -

Re: [Mesa-dev] [PATCH 28/29] anv/cmd_buffer: Re-arrange the logic around UNDEFINED fast-clears

[Pohjolainen, Topi]

On Mon, Nov 27, 2017 at 07:06:18PM -0800, Jason Ekstrand wrote:
> ---
>  src/intel/vulkan/genX_cmd_buffer.c | 31 ++-
>  1 file changed, 14 insertions(+), 17 deletions(-)

Reviewed-by: Topi Pohjolainen 

> 
> diff --git a/src/intel/vulkan/genX_cmd_buffer.c 
> b/src/intel/vulkan/genX_cmd_buffer.c
> index 9e584c1..dcd5a8f 100644
> --- a/src/intel/vulkan/genX_cmd_buffer.c
> +++ b/src/intel/vulkan/genX_cmd_buffer.c
> @@ -823,29 +823,26 @@ transition_color_buffer(struct anv_cmd_buffer 
> *cmd_buffer,
> * We don't have any data to show that this is a problem, but we want 
> to
> * avoid causing difficult-to-debug problems.
> */
> -  if ((GEN_GEN >= 9 && image->samples == 1) || image->samples > 1) {
> +  if (GEN_GEN >= 9 && image->samples == 1) {
> + for (uint32_t l = 0; l < level_count; l++) {
> +const uint32_t level = base_level + l;
> +const uint32_t level_layer_count =
> +   MIN2(layer_count, anv_image_aux_layers(image, aspect, level));
> +anv_image_ccs_op(cmd_buffer, image, aspect, level,
> + base_layer, level_layer_count,
> + ISL_AUX_OP_FAST_CLEAR, false);
> + }
> +  } else if (image->samples > 1) {
>   if (image->samples == 4 || image->samples == 16) {
>  anv_perf_warn(cmd_buffer->device->instance, image,
>"Doing a potentially unnecessary fast-clear to "
>"define an MCS buffer.");
>   }
>  
> - if (image->samples == 1) {
> -for (uint32_t l = 0; l < level_count; l++) {
> -   const uint32_t level = base_level + l;
> -   const uint32_t level_layer_count =
> -  MIN2(layer_count, anv_image_aux_layers(image, aspect, 
> level));
> -   anv_image_ccs_op(cmd_buffer, image, aspect, level,
> -base_layer, level_layer_count,
> -ISL_AUX_OP_FAST_CLEAR, false);
> -}
> - } else {
> -assert(image->samples > 1);
> -assert(base_level == 0 && level_count == 1);
> -anv_image_mcs_op(cmd_buffer, image, aspect,
> - base_layer, layer_count,
> - ISL_AUX_OP_FAST_CLEAR, false);
> - }
> + assert(base_level == 0 && level_count == 1);
> + anv_image_mcs_op(cmd_buffer, image, aspect,
> +  base_layer, layer_count,
> +  ISL_AUX_OP_FAST_CLEAR, false);
>}
>/* At this point, some elements of the CCS buffer may have the 
> fast-clear
> * bit-arrangement. As the user writes to a subresource, we need to 
> have
> -- 
> 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 27/29] anv/cmd_buffer: Pull the undefined layout condition into the if

[Pohjolainen, Topi]

On Mon, Nov 27, 2017 at 07:06:17PM -0800, Jason Ekstrand wrote:
> Now that this isn't a multi-case if and it's just the one case, it's a
> bit clearer if the condition is just part of the if instead of being
> pulled out into a boolean variable.

Reviewed-by: Topi Pohjolainen 

> ---
>  src/intel/vulkan/genX_cmd_buffer.c | 13 -
>  1 file changed, 4 insertions(+), 9 deletions(-)
> 
> diff --git a/src/intel/vulkan/genX_cmd_buffer.c 
> b/src/intel/vulkan/genX_cmd_buffer.c
> index 3473fdd..9e584c1 100644
> --- a/src/intel/vulkan/genX_cmd_buffer.c
> +++ b/src/intel/vulkan/genX_cmd_buffer.c
> @@ -793,20 +793,15 @@ transition_color_buffer(struct anv_cmd_buffer 
> *cmd_buffer,
>anv_image_aux_layers(image, aspect, base_level) - 
> base_layer);
> last_level_num = base_level + level_count;
>  
> -   /* Record whether or not the layout is undefined. Pre-initialized images
> -* with auxiliary buffers have a non-linear layout and are thus undefined.
> -*/
> assert(image->tiling == VK_IMAGE_TILING_OPTIMAL);
> -   const bool undef_layout = initial_layout == VK_IMAGE_LAYOUT_UNDEFINED ||
> - initial_layout == 
> VK_IMAGE_LAYOUT_PREINITIALIZED;
>  
> -   /* Do preparatory work before the resolve operation or return early if no
> -* resolve is actually needed.
> -*/
> -   if (undef_layout) {
> +   if (initial_layout == VK_IMAGE_LAYOUT_UNDEFINED ||
> +   initial_layout == VK_IMAGE_LAYOUT_PREINITIALIZED) {
>/* A subresource in the undefined layout may have been aliased and
> * populated with any arrangement of bits. Therefore, we must 
> initialize
> * the related aux buffer and clear buffer entry with desirable values.
> +   * An initial layout of PREINITIALIZED is the same as UNDEFINED for
> +   * images with VK_IMAGE_TILING_OPTIMAL.
> *
> * Initialize the relevant clear buffer entries.
> */
> -- 
> 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 26/29] intel/blorp: Add a CCS ambiguation pass

[Pohjolainen, Topi]

On Mon, Nov 27, 2017 at 07:06:16PM -0800, Jason Ekstrand wrote:
> ---
>  src/intel/blorp/blorp.h   |   5 ++
>  src/intel/blorp/blorp_clear.c | 106 
> ++
>  2 files changed, 111 insertions(+)

Reviewed-by: Topi Pohjolainen 

> 
> diff --git a/src/intel/blorp/blorp.h b/src/intel/blorp/blorp.h
> index 208b2db..dda0bf9 100644
> --- a/src/intel/blorp/blorp.h
> +++ b/src/intel/blorp/blorp.h
> @@ -215,6 +215,11 @@ blorp_ccs_resolve(struct blorp_batch *batch,
>enum blorp_fast_clear_op resolve_op);
>  
>  void
> +blorp_ccs_ambiguate(struct blorp_batch *batch,
> +struct blorp_surf *surf,
> +uint32_t level, uint32_t layer);
> +
> +void
>  blorp_mcs_partial_resolve(struct blorp_batch *batch,
>struct blorp_surf *surf,
>enum isl_format format,
> diff --git a/src/intel/blorp/blorp_clear.c b/src/intel/blorp/blorp_clear.c
> index ec859c2..af4d1c7 100644
> --- a/src/intel/blorp/blorp_clear.c
> +++ b/src/intel/blorp/blorp_clear.c
> @@ -931,3 +931,109 @@ blorp_mcs_partial_resolve(struct blorp_batch *batch,
>  
> batch->blorp->exec(batch, );
>  }
> +
> +/** Clear a CCS to the "uncompressed" state
> + *
> + * This pass is the CCS equivalent of a "HiZ resolve".  It sets the CCS 
> values
> + * for a given layer/level of a surface to 0x0 which is the "uncompressed"
> + * state which tells the sampler to go look at the main surface.
> + */
> +void
> +blorp_ccs_ambiguate(struct blorp_batch *batch,
> +struct blorp_surf *surf,
> +uint32_t level, uint32_t layer)
> +{
> +   struct blorp_params params;
> +   blorp_params_init();
> +
> +   assert(ISL_DEV_GEN(batch->blorp->isl_dev) >= 9);
> +
> +   const struct isl_format_layout *aux_fmtl =
> +  isl_format_get_layout(surf->aux_surf->format);
> +   assert(aux_fmtl->txc == ISL_TXC_CCS);
> +
> +   params.dst = (struct brw_blorp_surface_info) {
> +  .enabled = true,
> +  .addr = surf->aux_addr,
> +  .view = {
> + .usage = ISL_SURF_USAGE_RENDER_TARGET_BIT,
> + .format = ISL_FORMAT_R32G32B32A32_UINT,
> + .base_level = 0,
> + .base_array_layer = 0,
> + .levels = 1,
> + .array_len = 1,
> + .swizzle = ISL_SWIZZLE_IDENTITY,
> +  },
> +   };
> +
> +   uint32_t z = 0;
> +   if (surf->surf->dim == ISL_SURF_DIM_3D) {
> +  z = layer;
> +  layer = 0;
> +   }
> +
> +   uint32_t offset_B, x_offset_el, y_offset_el;
> +   isl_surf_get_image_offset_el(surf->aux_surf, level, layer, z,
> +_offset_el, _offset_el);
> +   isl_tiling_get_intratile_offset_el(surf->aux_surf->tiling, aux_fmtl->bpb,
> +  surf->aux_surf->row_pitch,
> +  x_offset_el, y_offset_el,
> +  _B, _offset_el, _offset_el);
> +   params.dst.addr.offset += offset_B;
> +
> +   const uint32_t width_px = minify(surf->surf->logical_level0_px.width, 
> level);
> +   const uint32_t height_px = minify(surf->surf->logical_level0_px.height, 
> level);
> +   const uint32_t width_el = DIV_ROUND_UP(width_px, aux_fmtl->bw);
> +   const uint32_t height_el = DIV_ROUND_UP(height_px, aux_fmtl->bh);
> +
> +   /* We're going to map it as a regular RGBA32_UINT surface.  We need to
> +* downscale a good deal.  From the Sky Lake PRM Vol. 12 in the section on
> +* planes:
> +*
> +*"The Color Control Surface (CCS) contains the compression status
> +*of the cache-line pairs. The compression state of the cache-line
> +*pair is specified by 2 bits in the CCS.  Each CCS cache-line
> +*represents an area on the main surface of 16x16 sets of 128 byte
> +*Y-tiled cache-line-pairs. CCS is always Y tiled."
> +*
> +* Each 2-bit surface element in the CCS corresponds to a single 
> cache-line
> +* pair in the main surface.  This means that 16x16 el block in the CCS
> +* maps to a Y-tiled cache line.  Fortunately, CCS layouts are calculated
> +* with a very large alignment so we can round up without worrying about
> +* overdraw.
> +*/
> +   assert(x_offset_el % 16 == 0 && y_offset_el % 4 == 0);
> +   const uint32_t x_offset_rgba_px = x_offset_el / 16;
> +   const uint32_t y_offset_rgba_px = y_offset_el / 4;
> +   const uint32_t width_rgba_px = DIV_ROUND_UP(width_el, 16);
> +   const uint32_t height_rgba_px = DIV_ROUND_UP(height_el, 4);
> +
> +   MAYBE_UNUSED bool ok =
> +  isl_surf_init(batch->blorp->isl_dev, ,
> +.dim = ISL_SURF_DIM_2D,
> +.format = ISL_FORMAT_R32G32B32A32_UINT,
> +.width = width_rgba_px + x_offset_rgba_px,
> +.height = height_rgba_px + y_offset_rgba_px,
> +.depth = 1,
> +.levels = 1,
> +.array_len 

Re: [Mesa-dev] [PATCH 3/3] README: Add note about meson

[Eric Engestrom]

On Friday, 2018-01-05 12:01:00 -0800, Dylan Baker wrote:
> Signed-off-by: Dylan Baker 

Reviewed-by: Eric Engestrom 

> ---
>  README | 24 +---
>  1 file changed, 21 insertions(+), 3 deletions(-)
> 
> diff --git a/README b/README
> index 26cab9d..f3df9ac 100644
> --- a/README
> +++ b/README
> @@ -15,9 +15,27 @@ with an older kernel.
>  Compiling
>  -
>  
> -libdrm  is  a  standard  autotools  package and  follows  the  normal
> -configure, build  and install steps.   The first step is  to configure
> -the package, which is done by running the configure shell script:
> +libdrm has two build systems, a legacy autotools build system, and a newer
> +meson build system. The meson build system is much faster, and offers a
> +slightly different interface, but otherwise provides an equivalent feature 
> set.
> +
> +To use it:
> +
> +meson builddir/
> +
> +By default this will install into /usr/local, you can change your prefix
> +with --prefix=/usr (or `meson configure builddir/ -Dprefix=/usr` after 
> +the initial meson setup).
> +
> +Then use ninja to build and install:
> +
> +ninja -C builddir/ install
> +
> +If you are installing into a system location you will need to run install
> +separately, and as root.
> +
> +
> +Alternatively you can invoke autotools configure:
>  
>   ./configure
>  
> -- 
> git-series 0.9.1
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/3] autotools: Include meson.build files in tarball

[Eric Engestrom]

On Friday, 2018-01-05 12:00:59 -0800, Dylan Baker wrote:
> Signed-off-by: Dylan Baker 
> ---
>  Makefile.am | 30 +-
>  1 file changed, 29 insertions(+), 1 deletion(-)
> 
> diff --git a/Makefile.am b/Makefile.am
> index 7b86214..66f70ca 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -135,7 +135,35 @@ if HAVE_VMWGFX
>  klibdrminclude_HEADERS += $(LIBDRM_INCLUDE_VMWGFX_H_FILES)
>  endif
>  
> -EXTRA_DIST = include/drm/README
> +EXTRA_DIST = \
> + include/drm/README \
> + amdgpu/meson.build \
> + etnaviv/meson.build \
> + exynos/meson.build \
> + freedreno/meson.build \
> + intel/meson.build \
> + libkms/meson.build \
> + man/meson.build \
> + nouveau/meson.build \
> + omap/meson.build \
> + radeon/meson.build \
> + tests/amdgpu/meson.build \
> + tests/etnaviv/meson.build \
> + tests/exynos/meson.build \
> + tests/kms/meson.build \
> + tests/kmstest/meson.build \
> + tests/modeprint/meson.build \
> + tests/nouveau/meson.build \
> + tests/proptest/meson.build \
> + tests/radeon/meson.build \
> + tests/tegra/meson.build \
> + tests/util/meson.build \
> + tests/vbltest/meson.build \
> + tests/meson.build \
> + vc4/meson.build \
> + data/meson.build \
> + meson.build \
> + meson_options.txt

You're missing a couple meson.builds:
tegra/meson.build
tests/modetest/meson.build

with those two added:
Reviewed-by: Eric Engestrom 

>  
>  copy-headers :
>   cp -r $(kernel_source)/include/uapi/drm/*.h $(top_srcdir)/include/drm/
> -- 
> git-series 0.9.1
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] Add meson build system

[Eric Engestrom]

On Friday, 2018-01-05 12:00:58 -0800, Dylan Baker wrote:
> This patch adds a complete meson build system, including tests and
> install. It has the necessary hooks to allow it be used as a subproject
> for other meson based builds such as mesa.
> 
> Signed-off-by: Dylan Baker 
> Reviewed-and-tested-by: Igor Gnatenko 
> ---
>  .editorconfig   |   4 +-
>  amdgpu/.editorconfig|   4 +-
>  amdgpu/meson.build  |  65 +++-
>  data/meson.build|  27 +++-
>  etnaviv/meson.build |  59 ++-
>  exynos/meson.build  |  53 +-
>  freedreno/meson.build   |  76 -
>  intel/meson.build   | 105 +++-
>  libkms/meson.build  |  74 -
>  man/meson.build |  67 +++-
>  meson.build | 364 +-
>  meson_options.txt   | 143 +++-
>  nouveau/meson.build |  58 ++-
>  omap/meson.build|  53 +-
>  radeon/meson.build  |  63 ++-
>  tegra/meson.build   |  52 +-
>  tests/amdgpu/meson.build|  34 +++-
>  tests/etnaviv/meson.build   |  45 +-
>  tests/exynos/meson.build|  54 +-
>  tests/kms/meson.build   |  49 +-
>  tests/kmstest/meson.build   |  30 +++-
>  tests/meson.build   |  86 +-
>  tests/modeprint/meson.build |  29 +++-
>  tests/modetest/meson.build  |  29 +++-
>  tests/nouveau/meson.build   |  30 +++-
>  tests/proptest/meson.build  |  28 +++-
>  tests/radeon/meson.build|  27 +++-
>  tests/tegra/meson.build |  27 +++-
>  tests/util/meson.build  |  28 +++-
>  tests/vbltest/meson.build   |  28 +++-
>  vc4/meson.build |  28 +++-
>  31 files changed, 1819 insertions(+)
>  create mode 100644 amdgpu/meson.build
>  create mode 100644 data/meson.build
>  create mode 100644 etnaviv/meson.build
>  create mode 100644 exynos/meson.build
>  create mode 100644 freedreno/meson.build
>  create mode 100644 intel/meson.build
>  create mode 100644 libkms/meson.build
>  create mode 100644 man/meson.build
>  create mode 100644 meson.build
>  create mode 100644 meson_options.txt
>  create mode 100644 nouveau/meson.build
>  create mode 100644 omap/meson.build
>  create mode 100644 radeon/meson.build
>  create mode 100644 tegra/meson.build
>  create mode 100644 tests/amdgpu/meson.build
>  create mode 100644 tests/etnaviv/meson.build
>  create mode 100644 tests/exynos/meson.build
>  create mode 100644 tests/kms/meson.build
>  create mode 100644 tests/kmstest/meson.build
>  create mode 100644 tests/meson.build
>  create mode 100644 tests/modeprint/meson.build
>  create mode 100644 tests/modetest/meson.build
>  create mode 100644 tests/nouveau/meson.build
>  create mode 100644 tests/proptest/meson.build
>  create mode 100644 tests/radeon/meson.build
>  create mode 100644 tests/tegra/meson.build
>  create mode 100644 tests/util/meson.build
>  create mode 100644 tests/vbltest/meson.build
>  create mode 100644 vc4/meson.build
> 
> diff --git a/.editorconfig b/.editorconfig
> index 893b7be..29b4f39 100644
> --- a/.editorconfig
> +++ b/.editorconfig
> @@ -17,3 +17,7 @@ indent_style = tab
>  [*.m4]
>  indent_style = space
>  indent_size = 2
> +
> +[{meson.build,meson_options.txt}]
> +indent_style = space
> +indent_size = 2
> diff --git a/amdgpu/.editorconfig b/amdgpu/.editorconfig
> index 2528d67..426273f 100644
> --- a/amdgpu/.editorconfig
> +++ b/amdgpu/.editorconfig
> @@ -7,3 +7,7 @@ indent_style = tab
>  indent_size = 8
>  tab_width = 8
>  insert_final_newline = true
> +
> +[meson.build]
> +indent_style = space
> +indent_size = 2
> diff --git a/amdgpu/meson.build b/amdgpu/meson.build
> new file mode 100644
> index 000..55ab9d1
> --- /dev/null
> +++ b/amdgpu/meson.build
> @@ -0,0 +1,65 @@
> +# Copyright © 2017-2018 Intel Corporation
> +
> +# Permission is hereby granted, free of charge, to any person obtaining a 
> copy
> +# of this software and associated documentation files (the "Software"), to 
> deal
> +# in the Software without restriction, including without limitation the 
> rights
> +# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
> +# copies of the Software, and to permit persons to whom the Software is
> +# furnished to do so, subject to the following conditions:
> +
> +# The above copyright notice and this permission notice shall be included in
> +# all copies or substantial portions of the Software.
> +
> +# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> +# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> +# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
> +# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> +# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
> FROM,
> +# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN 

Re: [Mesa-dev] meson: vdpau broken on r600

[Dylan Baker]

Thanks Ilia, I figured there must be some GL_DRIVERS_PATH equivalent but
couldn't find it with google, I never think to run strace. That's probably the
information I need to check on my nouveau machine.

Dylan

Quoting Ilia Mirkin (2018-01-11 15:30:23)
> It looks at the vdpau provider sent down down via the X DRI2 protocol.
> You can also force it to load any particular driver with
> VDPAU_DRIVER=foo, which would load
> $vdpau_dir_that_libvdpau_is_built_with/vdpau/libfoo_vdpau.so.1. You
> can also override the directory with VDPAU_DRIVER_PATH or
> VDPAU_DRIVERS_PATH (I can never remember). Running with 'strace -f'
> can help figure this stuff out.
> 
>   -ilia
> 
> On Thu, Jan 11, 2018 at 12:21 PM, Dylan Baker  wrote:
> > I couldn't reproduce with nouveau, vdpauinfo seems hardcoded to look for
> > vdpau_nvidia, and just ignores vdpau_nouveau.
> >
> > I have a patch that adds the symbol, but it feels ugly. I'm sending it and 
> > we
> > can test it, if it does fix it I guess we should figure out why we need to 
> > keep
> > adding --Wl,-whole-archive where autotools doesn't.
> >
> > Quoting Eric Engestrom (2018-01-11 08:58:32)
> >> On Tuesday, 2018-01-09 10:09:16 -0800, Dylan Baker wrote:
> >> > I'm not sure off the top of my head. I don't have an r600 anymore, but I 
> >> > have an
> >> > SI and a nouveau machine, so I'll see if I can reproduce the problem 
> >> > there and
> >> > fix it.
> >>
> >> I can confirm, the symbol is missing when building with meson:
> >>
> >> $ ninja src/gallium/targets/vdpau/libvdpau_gallium.so
> >> $ nm -D --defined-only src/gallium/targets/vdpau/libvdpau_gallium.so | 
> >> grep -c vdp_imp_device_create_x11
> >> 0
> >>
> >> I can't figure out why either, though.
> >>
> >> >
> >> > Dylan
> >> >
> >> > Quoting Marc Dietrich (2018-01-09 02:38:33)
> >> > > Hi Dylan,
> >> > >
> >> > > just found that vdpau does not work on r600 with meson build. Some 
> >> > > missing
> >> > > symbol, but I cannot figure out why:
> >> > >
> >> > > # vdpauinfo
> >> > > display: :0   screen: 0
> >> > > /usr/lib64/vdpau/libvdpau_r600.so.1: undefined symbol:
> >> > > vdp_imp_device_create_x11
> >> > > Error creating VDPAU device: 1
> >> > >
> >> > > The size of the library differs significant:
> >> > > autotools: 2417768 libvdpau_r600.so.1.0.0
> >> > > meson:  717368 libvdpau_r600.so.1.0.0
> >>
> >> With all the default options (except buildtype=release for meson),
> >> I'm getting these sizes:
> >> 5320936   meson/usr/lib/vdpau/libvdpau_r600.so.1.0.0
> >> 25190032  autotools/usr/lib/vdpau/libvdpau_r600.so.1.0.0
> >>
> >> but if I strip them, the autotools one shrinks to about a tenth of
> >> its size, and now the meson one actually looks bigger:
> >> 4722192   meson/usr/lib/vdpau/libvdpau_r600.so.1.0.0.stripped
> >> 2788936   autotools/usr/lib/vdpau/libvdpau_r600.so.1.0.0.stripped
> >>
> >> I'm not sure how much you can guess from the size of the binary though,
> >> too much is different between the two builds.
> >> Whether the symbols are exposed (see above) is a better metric IMO.
> >>
> >> > >
> >> > > Any idea?
> >> > >
> >> > > Marc
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> >


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

Re: [Mesa-dev] [PATCH 0/3] Meson build system

[Eric Engestrom]

On Monday, 2018-01-08 16:14:43 -0800, Dylan Baker wrote:
> I forgot to CC you on this like you asked,

Thanks for the ping :)

I noticed a couple issues on patches 1 & 2, but those are easy to fix,
and with that the series is r-b me.

Thanks for the effort of writing the whole thing!
I'll be glad to ditch autotools once this lands :P

> 
> Dylan
> 
> Quoting Dylan Baker (2018-01-05 12:00:57)
> > This is a fifth iteration of the meson build system for libdrm. This
> > version is significantly cleaned up from the last version and uses a
> > style more like the build system in mesa.
> > 
> > It builds all of the drivers and tests, and the tests can be run via
> > `ninja test`.
> > 
> > It has support for being used as a wrapped dependency with ext_foo
> > variables (I have a branch of mesa that will build this code as a wrap,
> > which has also been useful for testing). This means it can be used to
> > build a mesa that requires a newer libdrm than the system provides
> > (which can be especially useful if you can't install packages on that
> > system), or to build libdrm support that your distro doesn't ship (like
> > arm only drivers on x86), cross compiling, and for testing.
> > 
> > This has been build tested and mesa has been compiled against it, but
> > only minimal functional testing has been done, since I only have i965
> > machines, and i965 only uses libdrm lightly.
> > 
> > Some reviewers of the previous versions have done some additional
> > testing.
> > 
> > Changes since v3:
> >   - Fix freedreno kgsl check
> >   - Fix kgls -> kgsl typo
> >   - standardize meson options to use only `-` and not `_`
> >   - fix typo radoen -> radeon
> >   - add help messages to options
> >   - fix typo in kms-universal-planes binary
> >   - build and install modetest (this was missed in the first version for
> > some reason)
> >   - install amdgpu.ids as 644 instead of 444
> > 
> > Changes since v4:
> >   - Fix minor nits in options descriptions (Igor)
> >   - Fix editorconfig settings
> >   - Fix amdgpu.ids searh path
> >   - Style nits for Eric E.
> >   - Remove more tabs
> >   - Ensure that 1/0 defines are always defined, instead of only when
> > their value is 1
> >   - Don't add header files into file lists. (Meson figures out header
> > dependencies automatically using graphs that the compiler generates
> > during compilation)
> >   - Don't assign file lists to variables when possible. In a few cases
> > files need to be conditionally added, but if we're not in one of
> > those cases just put the lists directly in the exectuable or library
> > declaration.
> > 
> > Dylan Baker (3):
> >   Add meson build system
> >   autotools: Include meson.build files in tarball
> >   README: Add note about meson
> > 
> >  .editorconfig   |   4 +-
> >  Makefile.am |  30 ++-
> >  README  |  24 +-
> >  amdgpu/.editorconfig|   4 +-
> >  amdgpu/meson.build  |  65 +++-
> >  data/meson.build|  27 +++-
> >  etnaviv/meson.build |  59 ++-
> >  exynos/meson.build  |  53 +-
> >  freedreno/meson.build   |  76 -
> >  intel/meson.build   | 105 +++-
> >  libkms/meson.build  |  74 -
> >  man/meson.build |  67 +++-
> >  meson.build | 364 +-
> >  meson_options.txt   | 143 +++-
> >  nouveau/meson.build |  58 ++-
> >  omap/meson.build|  53 +-
> >  radeon/meson.build  |  63 ++-
> >  tegra/meson.build   |  52 +-
> >  tests/amdgpu/meson.build|  34 +++-
> >  tests/etnaviv/meson.build   |  45 +-
> >  tests/exynos/meson.build|  54 +-
> >  tests/kms/meson.build   |  49 +-
> >  tests/kmstest/meson.build   |  30 +++-
> >  tests/meson.build   |  86 +-
> >  tests/modeprint/meson.build |  29 +++-
> >  tests/modetest/meson.build  |  29 +++-
> >  tests/nouveau/meson.build   |  30 +++-
> >  tests/proptest/meson.build  |  28 +++-
> >  tests/radeon/meson.build|  27 +++-
> >  tests/tegra/meson.build |  27 +++-
> >  tests/util/meson.build  |  28 +++-
> >  tests/vbltest/meson.build   |  28 +++-
> >  vc4/meson.build |  28 +++-
> >  33 files changed, 1869 insertions(+), 4 deletions(-)
> >  create mode 100644 amdgpu/meson.build
> >  create mode 100644 data/meson.build
> >  create mode 100644 etnaviv/meson.build
> >  create mode 100644 exynos/meson.build
> >  create mode 100644 freedreno/meson.build
> >  create mode 100644 intel/meson.build
> >  create mode 100644 libkms/meson.build
> >  create mode 100644 man/meson.build
> >  create mode 100644 meson.build
> >  create mode 100644 meson_options.txt
> >  create mode 100644 nouveau/meson.build
> >  create mode 100644 omap/meson.build
> >  create mode 100644 radeon/meson.build
> >  create mode 100644 tegra/meson.build
> >  create mode 100644 

Re: [Mesa-dev] meson: vdpau broken on r600

[Ilia Mirkin]

BTW, that should have said 'strace -f -e open', otherwise you get
_way_ too much junk.

On Thu, Jan 11, 2018 at 6:35 PM, Dylan Baker  wrote:
> Thanks Ilia, I figured there must be some GL_DRIVERS_PATH equivalent but
> couldn't find it with google, I never think to run strace. That's probably the
> information I need to check on my nouveau machine.
>
> Dylan
>
> Quoting Ilia Mirkin (2018-01-11 15:30:23)
>> It looks at the vdpau provider sent down down via the X DRI2 protocol.
>> You can also force it to load any particular driver with
>> VDPAU_DRIVER=foo, which would load
>> $vdpau_dir_that_libvdpau_is_built_with/vdpau/libfoo_vdpau.so.1. You
>> can also override the directory with VDPAU_DRIVER_PATH or
>> VDPAU_DRIVERS_PATH (I can never remember). Running with 'strace -f'
>> can help figure this stuff out.
>>
>>   -ilia
>>
>> On Thu, Jan 11, 2018 at 12:21 PM, Dylan Baker  wrote:
>> > I couldn't reproduce with nouveau, vdpauinfo seems hardcoded to look for
>> > vdpau_nvidia, and just ignores vdpau_nouveau.
>> >
>> > I have a patch that adds the symbol, but it feels ugly. I'm sending it and 
>> > we
>> > can test it, if it does fix it I guess we should figure out why we need to 
>> > keep
>> > adding --Wl,-whole-archive where autotools doesn't.
>> >
>> > Quoting Eric Engestrom (2018-01-11 08:58:32)
>> >> On Tuesday, 2018-01-09 10:09:16 -0800, Dylan Baker wrote:
>> >> > I'm not sure off the top of my head. I don't have an r600 anymore, but 
>> >> > I have an
>> >> > SI and a nouveau machine, so I'll see if I can reproduce the problem 
>> >> > there and
>> >> > fix it.
>> >>
>> >> I can confirm, the symbol is missing when building with meson:
>> >>
>> >> $ ninja src/gallium/targets/vdpau/libvdpau_gallium.so
>> >> $ nm -D --defined-only src/gallium/targets/vdpau/libvdpau_gallium.so | 
>> >> grep -c vdp_imp_device_create_x11
>> >> 0
>> >>
>> >> I can't figure out why either, though.
>> >>
>> >> >
>> >> > Dylan
>> >> >
>> >> > Quoting Marc Dietrich (2018-01-09 02:38:33)
>> >> > > Hi Dylan,
>> >> > >
>> >> > > just found that vdpau does not work on r600 with meson build. Some 
>> >> > > missing
>> >> > > symbol, but I cannot figure out why:
>> >> > >
>> >> > > # vdpauinfo
>> >> > > display: :0   screen: 0
>> >> > > /usr/lib64/vdpau/libvdpau_r600.so.1: undefined symbol:
>> >> > > vdp_imp_device_create_x11
>> >> > > Error creating VDPAU device: 1
>> >> > >
>> >> > > The size of the library differs significant:
>> >> > > autotools: 2417768 libvdpau_r600.so.1.0.0
>> >> > > meson:  717368 libvdpau_r600.so.1.0.0
>> >>
>> >> With all the default options (except buildtype=release for meson),
>> >> I'm getting these sizes:
>> >> 5320936   meson/usr/lib/vdpau/libvdpau_r600.so.1.0.0
>> >> 25190032  autotools/usr/lib/vdpau/libvdpau_r600.so.1.0.0
>> >>
>> >> but if I strip them, the autotools one shrinks to about a tenth of
>> >> its size, and now the meson one actually looks bigger:
>> >> 4722192   meson/usr/lib/vdpau/libvdpau_r600.so.1.0.0.stripped
>> >> 2788936   autotools/usr/lib/vdpau/libvdpau_r600.so.1.0.0.stripped
>> >>
>> >> I'm not sure how much you can guess from the size of the binary though,
>> >> too much is different between the two builds.
>> >> Whether the symbols are exposed (see above) is a better metric IMO.
>> >>
>> >> > >
>> >> > > Any idea?
>> >> > >
>> >> > > Marc
>> >
>> > ___
>> > 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/2] meson: Fix configuring dri glx with only gallium drivers

[Adam Jackson]

On Fri, 2018-01-12 at 13:18 +, Jon Turney wrote:
> 'meson -Ddri-drivers= -Dgallium-drivers=swrast -Dglx=dri' fails with 'dri
> based GLX requires at least one DRI driver'
> 
> Signed-off-by: Jon Turney 
> ---
>  meson.build | 2 +-
>  src/glx/meson.build | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/meson.build b/meson.build
> index 77e4e894b23..dd8e6145edb 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -323,7 +323,7 @@ if with_glx != 'disabled'
>  if with_dri
>error('xlib conflicts with any dri driver')
>  endif
> -  elif with_glx == 'dri' and not with_dri
> +  elif with_glx == 'dri' and not (with_dri or with_gallium)
>  error('dri based GLX requires at least one DRI driver')

We should just remove this check. libGL doesn't actually require a DRI
driver, and at least on OSX there's no DRI driver you could possibly
build.

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

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

[Gurchetan Singh]

>
> Alright, so if I understand this correctly importing process would always
> call gralloc registerBuffer(), which means that the FPs would always be
> correct and usable by the importing process?


Yes, the Android framework calls registerBuffer() when importing the buffer
to a different process.  The FPs would introduce a dependency on libdrm on
whichever piece of code would want to use the handle access functions,
though [so would subclassing and sharing a handle].


> So if I'm understanding this correctly, something like this should work:
> https://gitlab.collabora.com/robertfoss/libdrm/commits/gralloc_handle_v1


Not quite.  It looks like you're defining another handle (since you
subclass native_handle_t) to store the function pointers.  If I understand
the logic correctly, this would require the gralloc implementation to point
to the relevant functions in (*registerBuffer()) and when allocating.

The idea was more to take the handle as an input to the accessor library:

// header file

struct drmAndroidHandleInfo {
   uint32_t (*get_fourcc)(buffer_handle_t handle);
...
}

extern const struct drmAndroidHandleInfo my_info;

// blah_gralloc_implementation.c
#ifdef blah_GRALLOC
#include "blah_gralloc_handle.h"

static uint32_t blah_gralloc_get_fourcc(buffer_handle_t handle)
{
struct blah_gralloc_handle *blah_handle = (struct blah_gralloc_handle
*) handle;
return blah_handle->fourcc_format;
}

struct drmAndroidHandleInfo my_info = {
   .get_fourcc = blah_gralloc_get_fourcc,
...


}

#endif

Then Mesa can just call my_info.get_fourcc(handle).

On Fri, Jan 12, 2018 at 5:10 AM, Robert Foss 
wrote:

>
>
> On 1/12/18 9:29 AM, Tomasz Figa wrote:
>
>> Hi Rob,
>>
>> On Fri, Jan 12, 2018 at 5:26 AM, Robert Foss 
>> wrote:
>>
>>> Heya,
>>>
>>>
>>> On 12/22/17 1:09 PM, Tomasz Figa wrote:
>>>

 On Fri, Dec 22, 2017 at 10:09 AM, Gurchetan Singh
  wrote:

>
> So the plan is for alloc_handle_t to not be sub-classed by the
> implementations, but have all necessary information that an
> implementation
> would need?
>
> If so, how do we reconcile the implementation specific information that
> is
> often in the handle:
>
>
> https://github.com/intel/minigbm/blob/master/cros_gralloc/
> cros_gralloc_handle.h
> [consumer_usage, producer_usage, yuv_color_range, is_updated etc.]
>
>
> https://chromium.googlesource.com/chromiumos/platform/minigb
> m/+/master/cros_gralloc/cros_gralloc_handle.h
> [use_flags, pixel_stride]
>
> In our case, removing our minigbm specific use flags from the handle
> would
> add complexity to our (*registerBuffer) path.
>
> On Thu, Dec 21, 2017 at 10:14 AM, Rob Herring  wrote:
>
>>
>>
>> On Wed, Dec 13, 2017 at 5:02 PM, Gurchetan Singh
>>  wrote:
>>
>>>
>>> Hi Robert,
>>>
>>> Thanks for looking into this!  We need to decide if we want:
>>>
>>> (1) A common struct that implementations can subclass, i.e:
>>>
>>> struct blah_gralloc_handle {
>>>   alloc_handle_t alloc_handle;
>>>   int x, y, z;
>>>   
>>> }
>>>
>>> (2) An accessor library that vendors can implement, i.e:
>>>
>>> struct drmAndroidHandleInfo {
>>>  uint32_t (*get_fourcc)(buffer_handle_t handle);
>>>  uint32_t (*get_stride)(buffer_handle_t handle, uint32_t plane);
>>>  uint32_t (*get_offsets)(buffer_handle_t handle, uint32_t plane);
>>>  uint64_t (*get_modifier)(buffer_handle_t handle);
>>> };
>>>
>>>   From my perspective as someone who has to maintain the minigbm
>>> gralloc
>>> implementation, (2) is preferable since:
>>>
>>
>>
>> Yeah, I'd prefer not to encourage 1 as the default.
>>
>>
>>> So I had a look into implementing this,
>>>
>>
>> Thanks!
>>
>> and using function pointers is
>>> problematic due to this struct being passed between processes which would
>>> prevent mesa calling a function assigned in gbm_gralloc for example.
>>>
>>
>> Why would be this struct passed between processes?
>>
>> The only data being exchanged between processes using gralloc is the
>> handle and it isn't actually exchanged directly, but the exporting
>> process will flatten it and send through Binder, while the importing
>> one will have it unflattened and then the gralloc implementation
>> called on it (the register buffer operation), which could update any
>> per-process data in the handle. (But still, why would we need to
>> include the function pointers there?)
>>
>
> Alright, so if I understand this correctly importing process would always
> call gralloc registerBuffer(), which means that the FPs would always be
> correct and usable by the importing process.
>
> I'm not entirely familiar with which the 

[Mesa-dev] [PATCH libdrm 1/2] drm/fourcc: Fix fourcc_mod_code() definition

[Thierry Reding]

From: Thierry Reding 

Avoid compiler warnings when the val parameter is an expression.

Signed-off-by: Thierry Reding 
---
 include/drm/drm_fourcc.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
index 3ad838d3f93f..a76ed8f9e383 100644
--- a/include/drm/drm_fourcc.h
+++ b/include/drm/drm_fourcc.h
@@ -188,7 +188,7 @@ extern "C" {
 #define DRM_FORMAT_RESERVED  ((1ULL << 56) - 1)
 
 #define fourcc_mod_code(vendor, val) \
-   __u64)DRM_FORMAT_MOD_VENDOR_## vendor) << 56) | (val & 
0x00ffULL))
+   __u64)DRM_FORMAT_MOD_VENDOR_## vendor) << 56) | ((val) & 
0x00ffULL))
 
 /*
  * Format Modifier tokens:
-- 
2.15.1

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

[Mesa-dev] [PATCH libdrm 0/2] drm/tegra: Sanitize format modifiers

[Thierry Reding]

From: Thierry Reding 

These UABI changes have now been merged into drm-next, so synchronize
the libdrm headers and fixup the format modifiers in modetest.

Thierry

Thierry Reding (2):
  drm/fourcc: Fix fourcc_mod_code() definition
  drm/tegra: Sanitize format modifiers

 include/drm/drm_fourcc.h  | 38 --
 tests/modetest/modetest.c | 28 ++--
 2 files changed, 34 insertions(+), 32 deletions(-)

-- 
2.15.1

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

[Mesa-dev] [PATCH libdrm 2/2] drm/tegra: Sanitize format modifiers

[Thierry Reding]

From: Thierry Reding 

The existing format modifier definitions were merged prematurely, and
recent work has unveiled that the definitions are suboptimal in several
ways:

  - The format specifiers, except for one, are not Tegra specific, but
the names don't reflect that.
  - The number space is split into two, reserving 32 bits for some
"parameter" which most of the modifiers are not going to have.
  - Symbolic names for the modifiers are not using the standard
DRM_FORMAT_MOD_* prefix, which makes them awkward to use.
  - The vendor prefix NV is somewhat ambiguous.

Fortunately, nobody's started using these modifiers, so we can still fix
the above issues. Do so by using the standard prefix. Also, remove TEGRA
from the name of those modifiers that exist on NVIDIA GPUs as well. In
case of the block linear modifiers, make the "parameter" smaller (4
bits, though only 6 values are valid) and don't let that leak into any
of the other modifiers.

Finally, also use the more canonical NVIDIA instead of the ambiguous NV
prefix.

Signed-off-by: Thierry Reding 
---
 include/drm/drm_fourcc.h  | 36 +++-
 tests/modetest/modetest.c | 28 ++--
 2 files changed, 33 insertions(+), 31 deletions(-)

diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
index a76ed8f9e383..e04613d30a13 100644
--- a/include/drm/drm_fourcc.h
+++ b/include/drm/drm_fourcc.h
@@ -178,7 +178,7 @@ extern "C" {
 #define DRM_FORMAT_MOD_VENDOR_NONE0
 #define DRM_FORMAT_MOD_VENDOR_INTEL   0x01
 #define DRM_FORMAT_MOD_VENDOR_AMD 0x02
-#define DRM_FORMAT_MOD_VENDOR_NV  0x03
+#define DRM_FORMAT_MOD_VENDOR_NVIDIA  0x03
 #define DRM_FORMAT_MOD_VENDOR_SAMSUNG 0x04
 #define DRM_FORMAT_MOD_VENDOR_QCOM0x05
 #define DRM_FORMAT_MOD_VENDOR_VIVANTE 0x06
@@ -338,29 +338,17 @@ extern "C" {
  */
 #define DRM_FORMAT_MOD_VIVANTE_SPLIT_SUPER_TILED fourcc_mod_code(VIVANTE, 4)
 
-/* NVIDIA Tegra frame buffer modifiers */
-
-/*
- * Some modifiers take parameters, for example the number of vertical GOBs in
- * a block. Reserve the lower 32 bits for parameters
- */
-#define __fourcc_mod_tegra_mode_shift 32
-#define fourcc_mod_tegra_code(val, params) \
-   fourcc_mod_code(NV, __u64)val) << __fourcc_mod_tegra_mode_shift) | 
params))
-#define fourcc_mod_tegra_mod(m) \
-   (m & ~((1ULL << __fourcc_mod_tegra_mode_shift) - 1))
-#define fourcc_mod_tegra_param(m) \
-   (m & ((1ULL << __fourcc_mod_tegra_mode_shift) - 1))
+/* NVIDIA frame buffer modifiers */
 
 /*
  * Tegra Tiled Layout, used by Tegra 2, 3 and 4.
  *
  * Pixels are arranged in simple tiles of 16 x 16 bytes.
  */
-#define NV_FORMAT_MOD_TEGRA_TILED fourcc_mod_tegra_code(1, 0)
+#define DRM_FORMAT_MOD_NVIDIA_TEGRA_TILED fourcc_mod_code(NVIDIA, 1)
 
 /*
- * Tegra 16Bx2 Block Linear layout, used by TK1/TX1
+ * 16Bx2 Block Linear layout, used by desktop GPUs, and Tegra K1 and later
  *
  * Pixels are arranged in 64x8 Groups Of Bytes (GOBs). GOBs are then stacked
  * vertically by a power of 2 (1 to 32 GOBs) to form a block.
@@ -380,7 +368,21 @@ extern "C" {
  * Chapter 20 "Pixel Memory Formats" of the Tegra X1 TRM describes this format
  * in full detail.
  */
-#define NV_FORMAT_MOD_TEGRA_16BX2_BLOCK(v) fourcc_mod_tegra_code(2, v)
+#define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(v) \
+   fourcc_mod_code(NVIDIA, 0x10 | ((v) & 0xf))
+
+#define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_ONE_GOB \
+   fourcc_mod_code(NVIDIA, 0x10)
+#define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_TWO_GOB \
+   fourcc_mod_code(NVIDIA, 0x11)
+#define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_FOUR_GOB \
+   fourcc_mod_code(NVIDIA, 0x12)
+#define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_EIGHT_GOB \
+   fourcc_mod_code(NVIDIA, 0x13)
+#define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_SIXTEEN_GOB \
+   fourcc_mod_code(NVIDIA, 0x14)
+#define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_THIRTYTWO_GOB \
+   fourcc_mod_code(NVIDIA, 0x15)
 
 /*
  * Broadcom VC4 "T" format
diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index 62d933272423..701547f4b648 100644
--- a/tests/modetest/modetest.c
+++ b/tests/modetest/modetest.c
@@ -278,20 +278,20 @@ static const char *modifier_to_string(uint64_t modifier)
return "VIVANTE_SPLIT_TILED";
case DRM_FORMAT_MOD_VIVANTE_SPLIT_SUPER_TILED:
return "VIVANTE_SPLIT_SUPER_TILED";
-   case NV_FORMAT_MOD_TEGRA_TILED:
-   return "MOD_TEGRA_TILED";
-   case NV_FORMAT_MOD_TEGRA_16BX2_BLOCK(0):
-   return "MOD_TEGRA_16BX2_BLOCK(0)";
-   case NV_FORMAT_MOD_TEGRA_16BX2_BLOCK(1):
-   return "MOD_TEGRA_16BX2_BLOCK(1)";
-   case NV_FORMAT_MOD_TEGRA_16BX2_BLOCK(2):
-   return "MOD_TEGRA_16BX2_BLOCK(2)";
-   case NV_FORMAT_MOD_TEGRA_16BX2_BLOCK(3):
-   return "MOD_TEGRA_16BX2_BLOCK(3)";
-   case NV_FORMAT_MOD_TEGRA_16BX2_BLOCK(4):
-   return "MOD_TEGRA_16BX2_BLOCK(4)";
-  

Re: [Mesa-dev] [PATCH 25/29] anv/cmd_buffer: Avoid unnecessary transitions before fast clears

[Pohjolainen, Topi]

On Mon, Nov 27, 2017 at 07:06:15PM -0800, Jason Ekstrand wrote:
> Previously, we would always apply the layout transition at the beginning
> of the subpass and then do the clear whether fast or slow.  This meant
> that there were some cases, specifically when the initial layout is
> VK_IMAGE_LAYOUT_UNDEFINED, where we would end up doing a fast-clear or
> ambiguate followed immediately by a fast-clear.  This probably isn't
> terribly expensive, but it is a waste that we can avoid easily enough
> now that we're doing everything at the same time in begin_subpass.

Had to read it thru a few times but couldn't spot anything amiss:

Reviewed-by: Topi Pohjolainen 

> ---
>  src/intel/vulkan/genX_cmd_buffer.c | 146 
> +++--
>  1 file changed, 106 insertions(+), 40 deletions(-)
> 
> diff --git a/src/intel/vulkan/genX_cmd_buffer.c 
> b/src/intel/vulkan/genX_cmd_buffer.c
> index 2c4ab38..3473fdd 100644
> --- a/src/intel/vulkan/genX_cmd_buffer.c
> +++ b/src/intel/vulkan/genX_cmd_buffer.c
> @@ -3009,6 +3009,101 @@ cmd_buffer_begin_subpass(struct anv_cmd_buffer 
> *cmd_buffer,
> VkRect2D render_area = cmd_buffer->state.render_area;
> struct anv_framebuffer *fb = cmd_buffer->state.framebuffer;
>  
> +   /* First, walk through the attachments and handle any full-surface
> +* fast-clears.  These are special because they do an implicit layout
> +* transition and allow us to potentially avoid a resolve later.
> +*/
> +   for (uint32_t i = 0; i < subpass->attachment_count; ++i) {
> +  const uint32_t a = subpass->attachments[i].attachment;
> +  if (a == VK_ATTACHMENT_UNUSED)
> + continue;
> +
> +  assert(a < cmd_state->pass->attachment_count);
> +  struct anv_attachment_state *att_state = _state->attachments[a];
> +
> +  struct anv_image_view *iview = fb->attachments[a];
> +  const struct anv_image *image = iview->image;
> +
> +  if (!att_state->pending_clear_aspects)
> + continue;
> +
> +  if (!att_state->fast_clear)
> + continue;
> +
> +  if (render_area.offset.x != 0 ||
> +  render_area.offset.y != 0 ||
> +  render_area.extent.width != iview->extent.width ||
> +  render_area.extent.height != iview->extent.height)
> + continue;
> +
> +  if (att_state->pending_clear_aspects & VK_IMAGE_ASPECT_COLOR_BIT) {
> + assert(att_state->pending_clear_aspects == 
> VK_IMAGE_ASPECT_COLOR_BIT);
> +
> + /* Multi-planar images are not supported as attachments */
> + assert(image->aspects == VK_IMAGE_ASPECT_COLOR_BIT);
> + assert(image->n_planes == 1);
> +
> + anv_image_ccs_op(cmd_buffer, image, VK_IMAGE_ASPECT_COLOR_BIT,
> +  iview->planes[0].isl.base_level,
> +  iview->planes[0].isl.base_array_layer,
> +  fb->layers,
> +  ISL_AUX_OP_FAST_CLEAR, false);
> +
> + genX(copy_fast_clear_dwords)(cmd_buffer, att_state->color.state,
> +  image, VK_IMAGE_ASPECT_COLOR_BIT,
> +  iview->planes[0].isl.base_level,
> +  true /* copy from ss */);
> +
> + /* Fast-clears impact whether or not a resolve will be necessary. */
> + if (image->planes[0].aux_usage == ISL_AUX_USAGE_CCS_E &&
> + att_state->clear_color_is_zero) {
> +/* This image always has the auxiliary buffer enabled. We can
> + * mark the subresource as not needing a resolve because the
> + * clear color will match what's in every RENDER_SURFACE_STATE
> + * object when it's being used for sampling.
> + */
> +clear_image_needs_resolve_bits(cmd_buffer, iview->image,
> +   VK_IMAGE_ASPECT_COLOR_BIT,
> +   iview->planes[0].isl.base_level,
> +   ANV_IMAGE_HAS_FAST_CLEAR_BIT);
> + } else {
> +set_image_needs_resolve_bits(cmd_buffer, iview->image,
> + VK_IMAGE_ASPECT_COLOR_BIT,
> + iview->planes[0].isl.base_level,
> + ANV_IMAGE_HAS_FAST_CLEAR_BIT);
> + }
> +
> + att_state->pending_clear_aspects = 0;
> + att_state->current_layout = 
> VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL;
> +  }
> +
> +  /* We only key the HiZ clear off of DEPTH_BIT because a fast stencil
> +   * clear doesn't reset the HiZ buffer contents the way we want.
> +   */
> +  if (att_state->pending_clear_aspects & VK_IMAGE_ASPECT_DEPTH_BIT) {
> + /* We currently only support HiZ for single-layer images */
> + assert(iview->planes[0].isl.base_level == 0);
> + 

[Mesa-dev] [PATCH mesa] docs/submittingpatches: document when to push patches

[Eric Engestrom]

Suggested-by: Emil Velikov 
Signed-off-by: Eric Engestrom 
---
 docs/submittingpatches.html | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/docs/submittingpatches.html b/docs/submittingpatches.html
index ba09aa4ad7329327e760..34c375cdaa44fe4fc197 100644
--- a/docs/submittingpatches.html
+++ b/docs/submittingpatches.html
@@ -23,6 +23,7 @@ Submitting patches
 Testing Patches
 Mailing Patches
 Reviewing Patches
+Pushing Patches
 Nominating a commit for a stable branch
 Criteria for accepting patches to the stable branch
 Sending backports for the stable branch
@@ -230,6 +231,31 @@ Reviewing Patches
 
 
 
+Pushing patches
+
+
+Patches should remain available for review for a certain period,
+depending on the severity of what they change.
+Patches that fix serious regressions (fails to build, most of piglit/CTS
+fails, etc.) are likely to be pushed on a shorter notice.
+
+
+
+Reviewed patches are pushed to the upstream 
repository
+by developers with commit access.
+If you do not have access, clearly state so (normally after the
+--- line) as part of the patch submission, and a reviewer
+will push it for you.
+
+
+
+If you notice your patch hasn't been pushed after having been reviewed,
+don't hesitate to poke developers (preferably by replying to the review
+email). Emails do fall through the cracks sometimes, nothing personal
+about it :)
+
+
+
 Nominating a commit for a stable branch
 
 
-- 
Cheers,
  Eric

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

[Mesa-dev] [PATCH mesa] docs: ask for backport nominations to cc: the author

[Eric Engestrom]

Signed-off-by: Eric Engestrom 
---
 docs/submittingpatches.html | 4 
 1 file changed, 4 insertions(+)

diff --git a/docs/submittingpatches.html b/docs/submittingpatches.html
index 0581391b2958253b8f4d..ba09aa4ad7329327e760 100644
--- a/docs/submittingpatches.html
+++ b/docs/submittingpatches.html
@@ -246,6 +246,10 @@ Nominating a commit for a stable 
branch
 Note: resending patch identical to one on mesa-dev@ or one that differs only
 by the extra mesa-stable@ tag is not recommended.
 
+
+If you are not the author of the original patch, please Cc: them in your
+nomination request.
+
 
 
 The stable tag
-- 
Cheers,
  Eric

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

Re: [Mesa-dev] [PATCH 1/2] st/va: remove TODO line for JPEG data buffer handling

[Christian König]

Am 12.01.2018 um 16:30 schrieb Leo Liu:

Nothing to do

Signed-off-by: Leo Liu 


Reviewed-by: Christian König 


---
  src/gallium/state_trackers/va/picture.c | 1 -
  1 file changed, 1 deletion(-)

diff --git a/src/gallium/state_trackers/va/picture.c 
b/src/gallium/state_trackers/va/picture.c
index 895157375a..9adbe48f43 100644
--- a/src/gallium/state_trackers/va/picture.c
+++ b/src/gallium/state_trackers/va/picture.c
@@ -327,7 +327,6 @@ handleVASliceDataBufferType(vlVaContext *context, 
vlVaBuffer *buf)
buffers[num_buffers] = (void *)context->mpeg4.start_code;
sizes[num_buffers++] = context->mpeg4.start_code_size;
 case PIPE_VIDEO_FORMAT_JPEG:
-  /* TODO */
break;
 default:
break;


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

Re: [Mesa-dev] Update radeon/uvd and radeon/vcn mpeg2 quantiser matrices only when required and modify the st/va accordingly

[Leo Liu]

On 01/12/2018 04:18 AM, Christian König wrote:

A bit text in the actual mail would have been nice.

E.g. that this is to fix VA-API issues with GStreamer and MPEG2.

Anyway patches are Reviewed-by: Christian König 
.

Please use `git send-email` instead of attachment.

Also please add RB and a bit commit message like Christian said to your 
patches, then send them to me , I will commit them for you.


Thanks,
Leo





Regards,
Christian.
___
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] ac: fix build error in si_shader

[Bas Nieuwenhuizen]

On Fri, Jan 12, 2018 at 3:47 PM, Mauro Rossi  wrote:
> assert() is replaced by unreachable(), to avoid following building error:
>
> external/mesa/src/gallium/drivers/radeonsi/si_shader.c:1967:1:
> error: control may reach end of non-void function [-Werror,-Wreturn-type]
> }
> ^
> 1 error generated.
>
> Fixes: c797cd6 ("ac: add load_patch_vertices_in() to the abi")
> ---
>  src/gallium/drivers/radeonsi/si_shader.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/radeonsi/si_shader.c 
> b/src/gallium/drivers/radeonsi/si_shader.c
> index dd635ae203..8439d09ffc 100644
> --- a/src/gallium/drivers/radeonsi/si_shader.c
> +++ b/src/gallium/drivers/radeonsi/si_shader.c
> @@ -1963,7 +1963,7 @@ static LLVMValueRef si_load_patch_vertices_in(struct 
> ac_shader_abi *abi)
> else if (ctx->type == PIPE_SHADER_TESS_EVAL)
> return get_num_tcs_out_vertices(ctx);
> else
> -   assert(!"invalid shader stage for TGSI_SEMANTIC_VERTICESIN");
> +   unreachable(!"invalid shader stage for 
> TGSI_SEMANTIC_VERTICESIN");

You don't need the negation anymore with unreachable. With that fixed,

Reviewed-by: Bas Nieuwenhuizen 

>  }
>
>  void si_load_system_value(struct si_shader_context *ctx,
> --
> 2.14.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] ac/nir: fix translation of nir_op_b2i for doubles

[Bas Nieuwenhuizen]

Maybe just zero-extend the 32-bit value? (or truncate for 16-bit?) I
don't know what generates better machinecode.

On Fri, Jan 12, 2018 at 2:34 AM, Timothy Arceri  wrote:
> ---
>
>  Open to suggestions for better ways to do this.
>
>  src/amd/common/ac_nir_to_llvm.c | 13 ++---
>  1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
> index b0a8a94a2d..f013b4b387 100644
> --- a/src/amd/common/ac_nir_to_llvm.c
> +++ b/src/amd/common/ac_nir_to_llvm.c
> @@ -1422,9 +1422,16 @@ static LLVMValueRef emit_f2b(struct ac_llvm_context 
> *ctx,
>  }
>
>  static LLVMValueRef emit_b2i(struct ac_llvm_context *ctx,
> -LLVMValueRef src0)
> +LLVMValueRef src0,
> +unsigned bitsize)
>  {
> -   return LLVMBuildAnd(ctx->builder, src0, ctx->i32_1, "");
> +   LLVMValueRef result = LLVMBuildAnd(ctx->builder, src0, ctx->i32_1, 
> "");
> +
> +   if (bitsize == 32)
> +   return result;
> +
> +   LLVMValueRef icond = LLVMBuildICmp(ctx->builder, LLVMIntEQ, result, 
> ctx->i32_1, "");
> +   return LLVMBuildSelect(ctx->builder, icond, ctx->i64_1, ctx->i64_0, 
> "");
>  }
>
>  static LLVMValueRef emit_i2b(struct ac_llvm_context *ctx,
> @@ -1979,7 +1986,7 @@ static void visit_alu(struct ac_nir_context *ctx, const 
> nir_alu_instr *instr)
> result = emit_f2b(>ac, src[0]);
> break;
> case nir_op_b2i:
> -   result = emit_b2i(>ac, src[0]);
> +   result = emit_b2i(>ac, src[0], 
> instr->dest.dest.ssa.bit_size);
> break;
> case nir_op_i2b:
> src[0] = ac_to_integer(>ac, src[0]);
> --
> 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] radv/radeonsi/nir: lower 64bit flrp

[Bas Nieuwenhuizen]

Reviewed-by: Bas Nieuwenhuizen 

On Fri, Jan 12, 2018 at 1:13 AM, Timothy Arceri  wrote:
> Fixes a bunch of arb_gpu_shader_fp64 piglit tests for example:
>
> generated_tests/spec/arb_gpu_shader_fp64/execution/built-in-functions/fs-mix-double-double-double.shader_test
> ---
>  src/amd/vulkan/radv_shader.c  | 1 +
>  src/gallium/drivers/radeonsi/si_get.c | 1 +
>  2 files changed, 2 insertions(+)
>
> diff --git a/src/amd/vulkan/radv_shader.c b/src/amd/vulkan/radv_shader.c
> index 4d38d867ca..9c54172661 100644
> --- a/src/amd/vulkan/radv_shader.c
> +++ b/src/amd/vulkan/radv_shader.c
> @@ -52,6 +52,7 @@ static const struct nir_shader_compiler_options nir_options 
> = {
> .vertex_id_zero_based = true,
> .lower_scmp = true,
> .lower_flrp32 = true,
> +   .lower_flrp64 = true,
> .lower_fsat = true,
> .lower_fdiv = true,
> .lower_sub = true,
> diff --git a/src/gallium/drivers/radeonsi/si_get.c 
> b/src/gallium/drivers/radeonsi/si_get.c
> index 9b5a03edaf..caf6e9d19f 100644
> --- a/src/gallium/drivers/radeonsi/si_get.c
> +++ b/src/gallium/drivers/radeonsi/si_get.c
> @@ -504,6 +504,7 @@ static const struct nir_shader_compiler_options 
> nir_options = {
> .vertex_id_zero_based = true,
> .lower_scmp = true,
> .lower_flrp32 = true,
> +   .lower_flrp64 = true,
> .lower_fsat = true,
> .lower_fdiv = true,
> .lower_sub = true,
> --
> 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] amd/common: fix loading InstanceID for tess on < GFX9

[Bas Nieuwenhuizen]

On Thu, Jan 11, 2018 at 2:58 PM, Samuel Pitoiset
 wrote:
>
>
> On 01/11/2018 02:56 PM, Samuel Pitoiset wrote:
>>
>> InstanceID is in VGPR2, not 1.
>>
>> One more failure that CTS didn't catch up...
>>
>> Reported-by: Alex Smith 
>> Signed-off-by: Samuel Pitoiset 
>> ---
>>   src/amd/common/ac_nir_to_llvm.c | 5 +++--
>>   1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/amd/common/ac_nir_to_llvm.c
>> b/src/amd/common/ac_nir_to_llvm.c
>> index 7153c9708d..d1247a7a60 100644
>> --- a/src/amd/common/ac_nir_to_llvm.c
>> +++ b/src/amd/common/ac_nir_to_llvm.c
>> @@ -6714,8 +6714,9 @@ LLVMModuleRef
>> ac_translate_nir_to_llvm(LLVMTargetMachineRef tm,
>> ctx.abi.load_patch_vertices_in =
>> load_patch_vertices_in;
>> } else if (shaders[i]->info.stage == MESA_SHADER_VERTEX) {
>> if (shader_info->info.vs.needs_instance_id) {
>> -   if (ctx.ac.chip_class == GFX9 &&
>> -   shaders[shader_count - 1]->info.stage
>> == MESA_SHADER_TESS_CTRL) {
>> +   if (ctx.options->key.vs.as_ls ||
>> +   (ctx.ac.chip_class == GFX9 &&
>> +shaders[shader_count - 1]->info.stage
>> == MESA_SHADER_TESS_CTRL)) {
>
>
> This could actually be simplified to "if (ctx->options->key.vs.as_ls) { ...
> }"

With that,

Reviewed-by: Bas Nieuwenhuizen 

>
>> ctx.shader_info->vs.vgpr_comp_cnt
>> =
>> MAX2(2,
>> ctx.shader_info->vs.vgpr_comp_cnt);
>> } else {
>>
> ___
> 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 2/2] st/va: add break for MPEG4 data buffer handling case

[Leo Liu]

Signed-off-by: Leo Liu 
---
 src/gallium/state_trackers/va/picture.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/gallium/state_trackers/va/picture.c 
b/src/gallium/state_trackers/va/picture.c
index 9adbe48f43..67177c783a 100644
--- a/src/gallium/state_trackers/va/picture.c
+++ b/src/gallium/state_trackers/va/picture.c
@@ -326,6 +326,7 @@ handleVASliceDataBufferType(vlVaContext *context, 
vlVaBuffer *buf)
   vlVaDecoderFixMPEG4Startcode(context);
   buffers[num_buffers] = (void *)context->mpeg4.start_code;
   sizes[num_buffers++] = context->mpeg4.start_code_size;
+  break;
case PIPE_VIDEO_FORMAT_JPEG:
   break;
default:
-- 
2.14.1

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

[Mesa-dev] [PATCH 1/2] st/va: remove TODO line for JPEG data buffer handling

[Leo Liu]

Nothing to do

Signed-off-by: Leo Liu 
---
 src/gallium/state_trackers/va/picture.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/src/gallium/state_trackers/va/picture.c 
b/src/gallium/state_trackers/va/picture.c
index 895157375a..9adbe48f43 100644
--- a/src/gallium/state_trackers/va/picture.c
+++ b/src/gallium/state_trackers/va/picture.c
@@ -327,7 +327,6 @@ handleVASliceDataBufferType(vlVaContext *context, 
vlVaBuffer *buf)
   buffers[num_buffers] = (void *)context->mpeg4.start_code;
   sizes[num_buffers++] = context->mpeg4.start_code_size;
case PIPE_VIDEO_FORMAT_JPEG:
-  /* TODO */
   break;
default:
   break;
-- 
2.14.1

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

Re: [Mesa-dev] [PATCH v2] isl: don't crash when creating a huge image

[Samuel Iglesias Gonsálvez]

On 11/01/18 23:27, Jason Ekstrand wrote:
> Sorry.  It's taken a bit of time but the WG has a decision and that is
> that we are supposed to throw VK_ERROR_OUT_OF_DEVICE_MEMORY in this
> case.  I believe you had an alternate version of the patch that did
> something like that.  If so, we should revive it.
>

Thanks for the info!

I am thinking on keep this patch and add the following one on top like this:

diff --git a/src/intel/vulkan/anv_image.c b/src/intel/vulkan/anv_image.c
index ba932ba47c3..652f28460d9 100644
--- a/src/intel/vulkan/anv_image.c
+++ b/src/intel/vulkan/anv_image.c
@@ -335,6 +335,9 @@ make_surface(const struct anv_device *dev,
 */
    assert(ok);
 
+   if (anv_surf->isl.size == UINT64_MAX)
+  return VK_ERROR_OUT_OF_DEVICE_MEMORY;
+
    image->planes[plane].aux_usage = ISL_AUX_USAGE_NONE;
 
    add_surface(image, anv_surf, plane);

Hence, we fail in vkCreateImage() with VK_ERROR_OUT_OF_DEVICE_MEMORY as
the suggested change to the spec, with zero changes to other users of
isl_surf_init() . If you agree, I will send both patches again for review.

Sam

> On Thu, Jan 11, 2018 at 5:04 AM, Samuel Iglesias Gonsálvez
> > wrote:
>
> This patch is still unreviewed.
>
> Sam
>
>
> On 14/11/17 09:45, Samuel Iglesias Gonsálvez wrote:
> > The HW has some limits but, according to the spec, we can create
> > the image as it has not yet any memory backing it. This patch
> > logs a debug error and set the size to the UINT64_MAX in order to
> > avoid allocating actual memory later.
> >
> > Fixes the crashes on BDW for the following tests:
> >
> > dEQP-VK.pipeline.render_to_image.core.2d_array.huge.*
> > dEQP-VK.pipeline.render_to_image.core.cube_array.huge.*
> >
> > Signed-off-by: Samuel Iglesias Gonsálvez  >
> > ---
> >  src/intel/isl/isl.c | 13 +
> >  1 file changed, 9 insertions(+), 4 deletions(-)
> >
> > diff --git a/src/intel/isl/isl.c b/src/intel/isl/isl.c
> > index 59f512fc050..cd7f2fcd4cb 100644
> > --- a/src/intel/isl/isl.c
> > +++ b/src/intel/isl/isl.c
> > @@ -26,6 +26,7 @@
> >  #include 
> >
> >  #include "genxml/genX_bits.h"
> > +#include "common/intel_log.h"
> >
> >  #include "isl.h"
> >  #include "isl_gen4.h"
> > @@ -1481,8 +1482,10 @@ isl_surf_init_s(const struct isl_device *dev,
> >         *
> >         * This comment is applicable to all Pre-gen9 platforms.
> >         */
> > -      if (size > (uint64_t) 1 << 31)
> > -         return false;
> > +      if (size > (uint64_t) 1 << 31) {
> > +         intel_logd("%s: Surface size is bigger than the
> supported by the HW: %ld > (1 << 31)", __func__, size);
> > +         size = UINT64_MAX;
> > +      }
> >     } else {
> >        /* From the Skylake PRM Vol 5, Maximum Surface Size in Bytes:
> >         *    "In addition to restrictions on maximum height,
> width, and depth,
> > @@ -1490,8 +1493,10 @@ isl_surf_init_s(const struct isl_device *dev,
> >         *     All pixels within the surface must be contained
> within 2^38 bytes
> >         *     of the base address."
> >         */
> > -      if (size > (uint64_t) 1 << 38)
> > -         return false;
> > +      if (size > (uint64_t) 1 << 38) {
> > +         intel_logd("%s: Surface size is bigger than the
> supported by the HW: %ld > (1 << 38)", __func__, size);
> > +         size = UINT64_MAX;
> > +      }
> >     }
> >
> >     *surf = (struct isl_surf) {
>
>
>



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

Re: [Mesa-dev] [PATCH 5/6] i965/draw: Do resolves properly for textures used by TXF

[Iago Toral]

On Thu, 2018-01-11 at 07:38 -0800, Jason Ekstrand wrote:
> On Thu, Jan 11, 2018 at 1:48 AM, Iago Toral 
> wrote:
> > On Wed, 2018-01-10 at 11:22 -0800, Jason Ekstrand wrote:
> > 
> > > ---
> > 
> > >  src/mesa/drivers/dri/i965/brw_draw.c | 41
> > 
> > > 
> > 
> > >  1 file changed, 41 insertions(+)
> > 
> > >
> > 
> > > diff --git a/src/mesa/drivers/dri/i965/brw_draw.c
> > 
> > > b/src/mesa/drivers/dri/i965/brw_draw.c
> > 
> > > index 4945dec..9fd44e4 100644
> > 
> > > --- a/src/mesa/drivers/dri/i965/brw_draw.c
> > 
> > > +++ b/src/mesa/drivers/dri/i965/brw_draw.c
> > 
> > > @@ -40,6 +40,7 @@
> > 
> > >  #include "swrast_setup/swrast_setup.h"
> > 
> > >  #include "drivers/common/meta.h"
> > 
> > >  #include "util/bitscan.h"
> > 
> > > +#include "util/bitset.h"
> > 
> > >  
> > 
> > >  #include "brw_blorp.h"
> > 
> > >  #include "brw_draw.h"
> > 
> > > @@ -371,6 +372,20 @@ intel_disable_rb_aux_buffer(struct
> > brw_context
> > 
> > > *brw,
> > 
> > > return found;
> > 
> > >  }
> > 
> > >  
> > 
> > > +static void
> > 
> > > +mark_textures_used_for_txf(BITSET_WORD *used_for_txf,
> > 
> > > +   const struct gl_program *prog)
> > 
> > > +{
> > 
> > > +   if (!prog)
> > 
> > > +  return;
> > 
> > > +
> > 
> > > +   unsigned mask = prog->SamplersUsed & prog-
> > 
> > > >info.textures_used_by_txf;
> > 
> > > +   while (mask) {
> > 
> > > +  int s = u_bit_scan();
> > 
> > > +  BITSET_SET(used_for_txf, prog->SamplerUnits[s]);
> > 
> > > +   }
> > 
> > > +}
> > 
> > > +
> > 
> > >  /**
> > 
> > >   * \brief Resolve buffers before drawing.
> > 
> > >   *
> > 
> > > @@ -386,6 +401,18 @@ brw_predraw_resolve_inputs(struct
> > brw_context
> > 
> > > *brw, bool rendering)
> > 
> > > memset(brw->draw_aux_buffer_disabled, 0,
> > 
> > >    sizeof(brw->draw_aux_buffer_disabled));
> > 
> > >  
> > 
> > > +   BITSET_DECLARE(used_for_txf,
> > MAX_COMBINED_TEXTURE_IMAGE_UNITS);
> > 
> > > +   memset(used_for_txf, 0, sizeof(used_for_txf));
> > 
> > > +   if (rendering) {
> > 
> > > +  mark_textures_used_for_txf(used_for_txf, ctx-
> > 
> > > >VertexProgram._Current);
> > 
> > > +  mark_textures_used_for_txf(used_for_txf, ctx-
> > 
> > > >TessCtrlProgram._Current);
> > 
> > > +  mark_textures_used_for_txf(used_for_txf, ctx-
> > 
> > > >TessEvalProgram._Current);
> > 
> > > +  mark_textures_used_for_txf(used_for_txf, ctx-
> > 
> > > >GeometryProgram._Current);
> > 
> > > +  mark_textures_used_for_txf(used_for_txf, ctx-
> > 
> > > >FragmentProgram._Current);
> > 
> > > +   } else {
> > 
> > > +  mark_textures_used_for_txf(used_for_txf, ctx-
> > 
> > > >ComputeProgram._Current);
> > 
> > > +   }
> > 
> > > +
> > 
> > > /* Resolve depth buffer and render cache of each enabled
> > texture.
> > 
> > > */
> > 
> > > int maxEnabledUnit = ctx->Texture._MaxEnabledTexImageUnit;
> > 
> > > for (int i = 0; i <= maxEnabledUnit; i++) {
> > 
> > > @@ -422,6 +449,20 @@ brw_predraw_resolve_inputs(struct
> > brw_context
> > 
> > > *brw, bool rendering)
> > 
> > >  min_layer, num_layers,
> > 
> > >  disable_aux);
> > 
> > >  
> > 
> > > +  /* If any programs are using it with texelFetch, we may
> > need
> > 
> > > to also do
> > 
> > > +   * a prepare with an sRGB format to ensure texelFetch
> > works
> > 
> > > "properly".
> > 
> > > +   */
> > 
> > 
> > 
> > I am not sure I understand this. The only way that txf_format and
> > 
> > view_format can be different is if the texture format is sRGB and
> > the
> > 
> > user has selected GL_SKIP_DECODE_EXT, right? If the user selected
> > that,
> > 
> > it would mean that they do not want sRGB decoded data when
> > sampling,
> > 
> > but I understand that is what they would get, since we are
> > preparing
> > 
> > the MT with the sRGB format in this case. What am I missing?
> > 
> 
> The utterly insane rules around texelFetch in
> EXT_texture_sRGB_decode. :-)  I'd quote them here but it involves a
> table so that may not come out well in e-mail.  The short version is
> that, if you use texelFetch, GL_SKIP_DECODE_EXT is ignored because
> it's part of the sampler and texelFetch doesn't use a sampler.  It's
> utterly insane but somehow that's where "design by committee" got
> us.  The fallout is that if we see a texelFetch, we need to do
> intel_miptree_prepare_texture with both sRGB and UNORM formats.

Ugh, just read the table, yeah, that not very obvious... So, the second
call to intel_miptree_prepare_texture has basically two purposes:
1. Actually ignore GL_SKIP_DECODE_EXT for texelFetch operations2. And
trigger a resolve operation if needed
Ok, that makes sense now. Thanks for the explanation.
Patches 5-6 are:Reviewed-by: Iago Toral Quiroga 

> > > +  if (BITSET_TEST(used_for_txf, i)) {
> > 
> > > + enum isl_format txf_format =
> > 
> > > +

[Mesa-dev] [PATCH] ac: fix build error in si_shader

[Mauro Rossi]

assert() is replaced by unreachable(), to avoid following building error:

external/mesa/src/gallium/drivers/radeonsi/si_shader.c:1967:1:
error: control may reach end of non-void function [-Werror,-Wreturn-type]
}
^
1 error generated.

Fixes: c797cd6 ("ac: add load_patch_vertices_in() to the abi")
---
 src/gallium/drivers/radeonsi/si_shader.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/radeonsi/si_shader.c 
b/src/gallium/drivers/radeonsi/si_shader.c
index dd635ae203..8439d09ffc 100644
--- a/src/gallium/drivers/radeonsi/si_shader.c
+++ b/src/gallium/drivers/radeonsi/si_shader.c
@@ -1963,7 +1963,7 @@ static LLVMValueRef si_load_patch_vertices_in(struct 
ac_shader_abi *abi)
else if (ctx->type == PIPE_SHADER_TESS_EVAL)
return get_num_tcs_out_vertices(ctx);
else
-   assert(!"invalid shader stage for TGSI_SEMANTIC_VERTICESIN");
+   unreachable(!"invalid shader stage for 
TGSI_SEMANTIC_VERTICESIN");
 }
 
 void si_load_system_value(struct si_shader_context *ctx,
-- 
2.14.1

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

Re: [Mesa-dev] [PATCH] st/mesa: enable ARB_enhanced_layouts on nir drivers

[Rob Clark]

On Fri, Jan 12, 2018 at 12:52 AM, Timothy Arceri  wrote:
> I'm guessing this may have been disable because of missing
> component packing support. However recent nir linking changes
> required nir based gallium drivers to support component packing
> so this should now be ok to enable.
>
> Cc: Rob Clark 

It looks like Nicolai added this, including the check for TGSI, but I
guess you are right about the reason.

freedreno/vc4/vc5 don't enable PIPE_CAP_TGSI_ARRAY_COMPONENTS so I
guess this change shouldn't harm anyone.  Although I guess from a
quick look maybe we can turn it on for freedreno.  (I'm not 100% sure
what "declaring arrays with overlapping ranges" translates to in
nir..)

BR,
-R

> ---
>  src/mesa/state_tracker/st_extensions.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/src/mesa/state_tracker/st_extensions.c 
> b/src/mesa/state_tracker/st_extensions.c
> index 9ef0df1e92..c8411a6995 100644
> --- a/src/mesa/state_tracker/st_extensions.c
> +++ b/src/mesa/state_tracker/st_extensions.c
> @@ -956,9 +956,7 @@ void st_init_extensions(struct pipe_screen *screen,
> }
>
> if (consts->GLSLVersion >= 140) {
> -  if (screen->get_param(screen, PIPE_CAP_TGSI_ARRAY_COMPONENTS) &&
> - screen->get_shader_param(screen, PIPE_SHADER_FRAGMENT,
> -   PIPE_SHADER_CAP_PREFERRED_IR) == 
> PIPE_SHADER_IR_TGSI)
> +  if (screen->get_param(screen, PIPE_CAP_TGSI_ARRAY_COMPONENTS))
>   extensions->ARB_enhanced_layouts = GL_TRUE;
> }
>
> --
> 2.14.3
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 104214] Dota crashes when switching from game to desktop

[bugzilla-daemon]

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

--- Comment #50 from Martin Peres  ---
(In reply to Tapani Pälli from comment #49)
> (In reply to Thomas Hellström from comment #47)
> > (In reply to Mark Janes from comment #45)
> > > Thomas:  do you have any ideas on how we could catch this category of bug 
> > > in
> > > automated testing?  We have comprehensive automated tests for GL/Vulkan
> > > apis, but not much for dri3.
> > 
> > When enabling dri3 in our Xorg driver we caught a number of viewport bugs in
> > mesa core dri3 using glretrace with various game traces. We currently do not
> > support page-flipping in our xorg driver, which might be why this wasn't
> > caught, but that would otherwise be a good candidate for automated testing:
> > 
> > Generate apitraces with frequent window resizing, and automate glretraces
> > with image capture and image comparisons, and in addition find a way to
> > trigger transition to- and from page-flipping.
> > 
> > /Thomas
> 
> I think Martin has/had some plans to add these kind of tests to his ezbench
> system, FYI Martin.

This is already implemented, however the error reporting in case the image does
not get generated is not correct (just to clean up the trainee's code that
landed in ezbench to be more resistant against that).

And by the way, Eero also added support for doing the same with vulkan traces
(through vkreplay).

-- 
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 v2 2/2] broadcom/vc4: Add support for HW perfmon

[Boris Brezillon]

On Thu, 11 Jan 2018 16:42:45 -0800
Eric Anholt  wrote:

> Boris Brezillon  writes:
> 
> > The V3D engine provides several perf counters.
> > Implement ->get_driver_query_[group_]info() so that these counters are
> > exposed through the GL_AMD_performance_monitor extension.  
> 
> This all looks good to me!  I'm looking forward to the piglit tests,

I'm working on that.

> but
> this patch is:
> 
> Reviewed-by: Eric Anholt 

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

Re: [Mesa-dev] [PATCH 2/2] [rfc] radv: inline push constants where possible. (v2)

[Alex Smith]

Looks like it's working fine here now. One comment inline below.

On 12 January 2018 at 02:43, Dave Airlie  wrote:

> From: Dave Airlie 
>
> Instead of putting the push constants into the upload buffer,
> if we have space in the sgprs we can upload the per-stage
> constants into the shaders directly.
>
> This saves a few reads from memory in the meta shaders,
> we should also be able to inline other objects like
> descriptors.
>
> v2: fixup 16->available_sgprs (Samuel)
> fixup dynamic offsets. (Alex)
> bump to 12.
> handle push consts > 32 better, avoid F1 2017 crash
>
> TODO: proper vega support (Samuel)
>
> Signed-off-by: Dave Airlie 
> ---
>  src/amd/common/ac_nir_to_llvm.c  | 102 ++
> +
>  src/amd/common/ac_nir_to_llvm.h  |   5 ++
>  src/amd/common/ac_shader_info.c  |   5 +-
>  src/amd/common/ac_shader_info.h  |   1 +
>  src/amd/vulkan/radv_cmd_buffer.c |  75 +---
>  5 files changed, 159 insertions(+), 29 deletions(-)
>
> diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_
> llvm.c
> index 6c578de3aca..00ad76a82f7 100644
> --- a/src/amd/common/ac_nir_to_llvm.c
> +++ b/src/amd/common/ac_nir_to_llvm.c
> @@ -92,6 +92,7 @@ struct nir_to_llvm_context {
> LLVMValueRef descriptor_sets[AC_UD_MAX_SETS];
> LLVMValueRef ring_offsets;
> LLVMValueRef push_constants;
> +   LLVMValueRef inline_push_consts[AC_UD_MAX_INLINE_PUSH_CONST];
> LLVMValueRef view_index;
> LLVMValueRef num_work_groups;
> LLVMValueRef workgroup_ids[3];
> @@ -243,7 +244,7 @@ static void set_llvm_calling_convention(LLVMValueRef
> func,
> LLVMSetFunctionCallConv(func, calling_conv);
>  }
>
> -#define MAX_ARGS 23
> +#define MAX_ARGS 32
>  struct arg_info {
> LLVMTypeRef types[MAX_ARGS];
> LLVMValueRef *assign[MAX_ARGS];
> @@ -538,6 +539,8 @@ struct user_sgpr_info {
> bool need_ring_offsets;
> uint8_t sgpr_count;
> bool indirect_all_descriptor_sets;
> +   uint8_t base_inline_push_consts;
> +   uint8_t num_inline_push_consts;
>  };
>
>  static void allocate_user_sgprs(struct nir_to_llvm_context *ctx,
> @@ -609,8 +612,49 @@ static void allocate_user_sgprs(struct
> nir_to_llvm_context *ctx,
> } else {
> user_sgpr_info->sgpr_count += 
> util_bitcount(ctx->shader_info->info.desc_set_used_mask)
> * 2;
> }
> +
> +   if (ctx->shader_info->info.loads_push_constants) {
> +   uint32_t remaining_sgprs = available_sgprs -
> user_sgpr_info->sgpr_count;
> +   if (!ctx->shader_info->info.has_indirect_push_constants &&
> +   !ctx->shader_info->info.loads_dynamic_offsets)
> +   remaining_sgprs += 2;
> +
> +   if (ctx->options->layout->push_constant_size) {
> +   uint8_t num_32bit_push_consts =
> (ctx->shader_info->info.max_push_constant_used -
> +
> ctx->shader_info->info.min_push_constant_used) / 4;
> +
> +   if ((ctx->shader_info->info.min_push_constant_used
> / 4) <= 63 &&
> +   (ctx->shader_info->info.max_push_constant_used
> / 4) <= 63) {
> +   user_sgpr_info->base_inline_push_consts =
> ctx->shader_info->info.min_push_constant_used / 4;
> +
> +   if (num_32bit_push_consts <
> remaining_sgprs) {
> +   user_sgpr_info->num_inline_push_consts
> = num_32bit_push_consts;
> +   if (!ctx->shader_info->info.has_
> indirect_push_constants)
> +
>  ctx->shader_info->info.loads_push_constants = false;
> +   } else {
> +   user_sgpr_info->num_inline_push_consts
> = remaining_sgprs;
> +   }
> +
> +   if (user_sgpr_info->num_inline_push_consts
> > AC_UD_MAX_INLINE_PUSH_CONST)
> +   user_sgpr_info->num_inline_push_consts
> = AC_UD_MAX_INLINE_PUSH_CONST;
>

This is done after possibly setting loads_push_constants to false, if this
happens shouldn't that still be true?

With that fixed, for the series:

Reviewed-by: Alex Smith 

Thanks,
Alex


> +   }
> +   }
> +   }
>  }
>
> +static void
> +declare_inline_push_consts(struct nir_to_llvm_context *ctx,
> +  gl_shader_stage stage,
> +  const struct user_sgpr_info *user_sgpr_info,
> +  struct arg_info *args)
> +{
> +   ctx->shader_info->inline_push_const_mask = (1ULL <<
> user_sgpr_info->num_inline_push_consts) - 1;
> +   ctx->shader_info->inline_push_const_base =
> user_sgpr_info->base_inline_push_consts;
> +
> +   for (unsigned i = 0; i < user_sgpr_info->num_inline_push_consts;
> i++)
> +   

[Mesa-dev] [Bug 104214] Dota crashes when switching from game to desktop

[bugzilla-daemon]

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

ubitux  changed:

   What|Removed |Added

 CC||freedesk...@pkh.me

--- Comment #48 from ubitux  ---
*** Bug 104579 has been marked as a duplicate of this bug. ***

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

[Mesa-dev] [Bug 104214] Dota crashes when switching from game to desktop

[bugzilla-daemon]

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

Tapani Pälli  changed:

   What|Removed |Added

 CC||martin.pe...@free.fr

--- Comment #49 from Tapani Pälli  ---
(In reply to Thomas Hellström from comment #47)
> (In reply to Mark Janes from comment #45)
> > Thomas:  do you have any ideas on how we could catch this category of bug in
> > automated testing?  We have comprehensive automated tests for GL/Vulkan
> > apis, but not much for dri3.
> 
> When enabling dri3 in our Xorg driver we caught a number of viewport bugs in
> mesa core dri3 using glretrace with various game traces. We currently do not
> support page-flipping in our xorg driver, which might be why this wasn't
> caught, but that would otherwise be a good candidate for automated testing:
> 
> Generate apitraces with frequent window resizing, and automate glretraces
> with image capture and image comparisons, and in addition find a way to
> trigger transition to- and from page-flipping.
> 
> /Thomas

I think Martin has/had some plans to add these kind of tests to his ezbench
system, FYI Martin.

-- 
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] [RFC libdrm 0/5] Move alloc_handle_t from gralloc impls.

[Tomasz Figa]

Hi Rob,

On Fri, Jan 12, 2018 at 5:26 AM, Robert Foss  wrote:
> Heya,
>
>
> On 12/22/17 1:09 PM, Tomasz Figa wrote:
>>
>> On Fri, Dec 22, 2017 at 10:09 AM, Gurchetan Singh
>>  wrote:
>>>
>>> So the plan is for alloc_handle_t to not be sub-classed by the
>>> implementations, but have all necessary information that an
>>> implementation
>>> would need?
>>>
>>> If so, how do we reconcile the implementation specific information that
>>> is
>>> often in the handle:
>>>
>>>
>>> https://github.com/intel/minigbm/blob/master/cros_gralloc/cros_gralloc_handle.h
>>> [consumer_usage, producer_usage, yuv_color_range, is_updated etc.]
>>>
>>>
>>> https://chromium.googlesource.com/chromiumos/platform/minigbm/+/master/cros_gralloc/cros_gralloc_handle.h
>>> [use_flags, pixel_stride]
>>>
>>> In our case, removing our minigbm specific use flags from the handle
>>> would
>>> add complexity to our (*registerBuffer) path.
>>>
>>> On Thu, Dec 21, 2017 at 10:14 AM, Rob Herring  wrote:


 On Wed, Dec 13, 2017 at 5:02 PM, Gurchetan Singh
  wrote:
>
> Hi Robert,
>
> Thanks for looking into this!  We need to decide if we want:
>
> (1) A common struct that implementations can subclass, i.e:
>
> struct blah_gralloc_handle {
>  alloc_handle_t alloc_handle;
>  int x, y, z;
>  
> }
>
> (2) An accessor library that vendors can implement, i.e:
>
> struct drmAndroidHandleInfo {
> uint32_t (*get_fourcc)(buffer_handle_t handle);
> uint32_t (*get_stride)(buffer_handle_t handle, uint32_t plane);
> uint32_t (*get_offsets)(buffer_handle_t handle, uint32_t plane);
> uint64_t (*get_modifier)(buffer_handle_t handle);
> };
>
>  From my perspective as someone who has to maintain the minigbm gralloc
> implementation, (2) is preferable since:


 Yeah, I'd prefer not to encourage 1 as the default.

>
> So I had a look into implementing this,

Thanks!

> and using function pointers is
> problematic due to this struct being passed between processes which would
> prevent mesa calling a function assigned in gbm_gralloc for example.

Why would be this struct passed between processes?

The only data being exchanged between processes using gralloc is the
handle and it isn't actually exchanged directly, but the exporting
process will flatten it and send through Binder, while the importing
one will have it unflattened and then the gralloc implementation
called on it (the register buffer operation), which could update any
per-process data in the handle. (But still, why would we need to
include the function pointers there?)

>
> It could be used to provide runtime support for multiple gralloc
> implementations, but that seems to about the only advantage to adding FPs.
>
> Am I missing a good usecase for FPs? If not I think the added
> complexity/cruft is more problematic than good.
>
> Any thoughts?
>

I guess it might not be a big deal whether FPs or structs are used, as
long as they are not directly embedded in the handle, which we don't
want constraints on.

Best regards,
Tomasz

>
> Rob.
>
>
> a) We really don't have a need for fields like data_owner, void *data,
> etc.


 We should be able to get rid of this. It's just for tracking imports.

> Also, minigbm puts per plane fds, strides, offsets into the handle.
> Separating the information for the first plane (for the alloc_handle_t)
> and
> then rest of the planes would be annoying.


 The plan is to add those to alloc_handle_t.

> b) we can avoid the struct within a struct that happens when we
> subclass,
> since alignment/padding issues often pop up during
> serialization/de-serialization.  Using __attribute__((aligned(xx))) is
> less
> portable than maintaining a POD struct.


 Yes. Even just between 32 and 64 bit it's problematic.


> c) IMO creating the handle should be left to the gralloc
> implementation.
> Having accessor functions clearly defines what we need from libdrm --
> to
> make up for shortcomings of the gralloc API for DRM/KMS use cases.
>
>>
>> I think there might be also d). Define a standard struct in libdrm
>> headers and add a custom call to gralloc that would fill in such
>> struct for given buffer. This would keep the libdrm handle independent
>> of gralloc's internal handle.
>>
>> P.S. Top-posting is bad.
>>
>> Best regards,
>> Tomasz
>>
>
> On Wed, Dec 13, 2017 at 9:30 AM, Robert Foss
> 
> wrote:
>>
>>
>> This series moves {gbm,drm,cros}_gralloc_handle_t struct to libdrm,
>> since at least 4 implementations exist, and share a lot of contents.
>> The idea is to keep the common stuff defined in one place, and libdrm
>> is the common codebase 

Re: [Mesa-dev] [PATCH 24/29] anv/cmd_buffer: Do subpass image transitions in begin/end_subpass

[Pohjolainen, Topi]

On Tue, Nov 28, 2017 at 10:13:52AM -0800, Jason Ekstrand wrote:
> On Tue, Nov 28, 2017 at 10:07 AM, Jason Ekstrand 
> wrote:
> 
> > This patch causes a perf drop in sascha gears.  I'm investigating.
> >
> 
> Found it!  Read below.
> 
> 
> > On Mon, Nov 27, 2017 at 7:06 PM, Jason Ekstrand 
> > wrote:
> >
> >> ---
> >>  src/intel/vulkan/genX_cmd_buffer.c | 187 +-
> >> ---
> >>  1 file changed, 65 insertions(+), 122 deletions(-)
> >>
> >> diff --git a/src/intel/vulkan/genX_cmd_buffer.c
> >> b/src/intel/vulkan/genX_cmd_buffer.c
> >> index 7901b0c..2c4ab38 100644
> >> --- a/src/intel/vulkan/genX_cmd_buffer.c
> >> +++ b/src/intel/vulkan/genX_cmd_buffer.c
> >> @@ -2982,120 +2982,6 @@ cmd_buffer_emit_depth_stencil(struct
> >> anv_cmd_buffer *cmd_buffer)
> >> cmd_buffer->state.hiz_enabled = info.hiz_usage == ISL_AUX_USAGE_HIZ;
> >>  }
> >>
> >> -
> >> -/**
> >> - * @brief Perform any layout transitions required at the beginning
> >> and/or end
> >> - *of the current subpass for depth buffers.
> >> - *
> >> - * TODO: Consider preprocessing the attachment reference array at render
> >> pass
> >> - *   create time to determine if no layout transition is needed at
> >> the
> >> - *   beginning and/or end of each subpass.
> >> - *
> >> - * @param cmd_buffer The command buffer the transition is happening
> >> within.
> >> - * @param subpass_end If true, marks that the transition is happening at
> >> the
> >> - *end of the subpass.
> >> - */
> >> -static void
> >> -cmd_buffer_subpass_transition_layouts(struct anv_cmd_buffer * const
> >> cmd_buffer,
> >> -  const bool subpass_end)
> >> -{
> >> -   /* We need a non-NULL command buffer. */
> >> -   assert(cmd_buffer);
> >> -
> >> -   const struct anv_cmd_state * const cmd_state = _buffer->state;
> >> -   const struct anv_subpass * const subpass = cmd_state->subpass;
> >> -
> >> -   /* This function must be called within a subpass. */
> >> -   assert(subpass);
> >> -
> >> -   /* If there are attachment references, the array shouldn't be NULL.
> >> -*/
> >> -   if (subpass->attachment_count > 0)
> >> -  assert(subpass->attachments);
> >> -
> >> -   /* Iterate over the array of attachment references. */
> >> -   for (const VkAttachmentReference *att_ref = subpass->attachments;
> >> -att_ref < subpass->attachments + subpass->attachment_count;
> >> att_ref++) {
> >> -
> >> -  /* If the attachment is unused, we can't perform a layout
> >> transition. */
> >> -  if (att_ref->attachment == VK_ATTACHMENT_UNUSED)
> >> - continue;
> >> -
> >> -  /* This attachment index shouldn't go out of bounds. */
> >> -  assert(att_ref->attachment < cmd_state->pass->attachment_count);
> >> -
> >> -  const struct anv_render_pass_attachment * const att_desc =
> >> - _state->pass->attachments[att_ref->attachment];
> >> -  struct anv_attachment_state * const att_state =
> >> - _buffer->state.attachments[att_ref->attachment];
> >> -
> >> -  /* The attachment should not be used in a subpass after its last.
> >> */
> >> -  assert(att_desc->last_subpass_idx >=
> >> anv_get_subpass_id(cmd_state));
> >> -
> >> -  if (subpass_end && anv_get_subpass_id(cmd_state) <
> >> -  att_desc->last_subpass_idx) {
> >> - /* We're calling this function on a buffer twice in one subpass
> >> and
> >> -  * this is not the last use of the buffer. The layout should
> >> not have
> >> -  * changed from the first call and no transition is necessary.
> >> -  */
> >> - assert(att_state->current_layout == att_ref->layout ||
> >> -att_state->current_layout ==
> >> -VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL);
> >> - continue;
> >> -  }
> >> -
> >> -  /* The attachment index must be less than the number of attachments
> >> -   * within the framebuffer.
> >> -   */
> >> -  assert(att_ref->attachment < cmd_state->framebuffer->attach
> >> ment_count);
> >> -
> >> -  const struct anv_image_view * const iview =
> >> - cmd_state->framebuffer->attachments[att_ref->attachment];
> >> -  const struct anv_image * const image = iview->image;
> >> -
> >> -  /* Get the appropriate target layout for this attachment. */
> >> -  VkImageLayout target_layout;
> >> -
> >> -  /* A resolve is necessary before use as an input attachment if the
> >> clear
> >> -   * color or auxiliary buffer usage isn't supported by the sampler.
> >> -   */
> >> -  const bool input_needs_resolve =
> >> -(att_state->fast_clear && !att_state->clear_color_is_zero_one)
> >> ||
> >> -att_state->input_aux_usage != att_state->aux_usage;
> >> -  if (subpass_end) {
> >> - target_layout = att_desc->final_layout;
> >> -  } else if (iview->aspect_mask &