date:20161124

[Mesa-dev] [Bug 98851] triangle clipping causes wrong interpolation of non-perspective corrected attributes

2016-11-24 Thread bugzilla-daemon

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

Ilia Mirkin  changed:

   What|Removed |Added

Summary|triangle clipping causes|triangle clipping causes
   |wrong ... something |wrong interpolation of
   ||non-perspective corrected
   ||attributes

--- Comment #2 from Ilia Mirkin  ---
Ah yeah, looks like that's exactly what's going on -

src/gallium/auxiliary/draw/draw_pipe_clip.c:interp has the following logic:

   /**
* Compute the t in screen-space instead of 3d space to use
* for noperspective interpolation.
*
* The points can be aligned with the X axis, so in that case try
* the Y.  When both points are at the same screen position, we can
* pick whatever value (the interpolated point won't be in front
* anyway), so just use the 3d t.
*/
   if (clip->num_linear_attribs) {
  int k;
  t_nopersp = t;
  /* find either in.x != out.x or in.y != out.y */
  for (k = 0; k < 2; k++) {
 if (in->clip_pos[k] != out->clip_pos[k]) {
/* do divide by W, then compute linear interpolation factor */
float in_coord = in->clip_pos[k] / in->clip_pos[3];
float out_coord = out->clip_pos[k] / out->clip_pos[3];
float dst_coord = dst->clip_pos[k] / dst->clip_pos[3];
t_nopersp = (dst_coord - out_coord) / (in_coord - out_coord);
break;
 }
  }
  for (j = 0; j < clip->num_linear_attribs; j++) {
 const unsigned attr = clip->linear_attribs[j];
 interp_attr(dst->data[attr], t_nopersp, in->data[attr],
out->data[attr]);
  }
   }

swr needs to grow a linear-interpolated attribute mask and incorporate the
above logic for those.

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

[Mesa-dev] [Bug 98851] triangle clipping causes wrong ... something

2016-11-24 Thread bugzilla-daemon

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

--- Comment #1 from Ilia Mirkin  ---
One thing I wonder about is whether the clipper needs to know that it's a
no-perspective attribute. There's an interpolation step done in
clip.h:intersect, and I'm not sure that's right for the
non-perspective-correcting case. (I'm also not sure that it's wrong...)

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

Re: [Mesa-dev] [PATCH] anv/state: if enabled, use anisotropic filtering also with VK_FILTER_NEAREST

2016-11-24 Thread Iago Toral

On Thu, 2016-11-24 at 16:28 -0800, Jason Ekstrand wrote:
> 
> On Nov 24, 2016 7:12 AM, "Iago Toral"  wrote:
> >
> > On Thu, 2016-11-24 at 14:33 +0100, Iago Toral wrote:
> > > Hi Lionel,
> > >
> > > On Thu, 2016-11-24 at 13:08 +, Lionel Landwerlin wrote:
> > > >
> > > > Hi Iago,
> > > >
> > > > Looking at the history, before
> > > > ed4fe3e9ba9018e68afe6fdd4f267218a537fdaa 
> > > > we seem to set min/mag filter to MAPFILTER_ANISOTROPIC if
> > > > maxAnisotropy 
> > > >  > 1. It seems your patch makes sense in using
> > > > MAPFILTER_ANISOTROPIC
> > > > in 
> > > > the NEAREST case, but I wonder whether we should also check
> for 
> > > > maxAnisotropy > 1.
> > > Right, good catch, although I think that if we do that it should
> be a
> > > separate change since we are not currently checking that for the
> > > linear
> > > filter either.
> In GL, there is no explicit enable.  It's just assumed that it's
> "always on" and the anisotropy value being 1.0 or > 1.0 enables and
> disables it.  Vulkan has an explicit bit so we should use that.
> > > It seems that we do check for this in OpenGL so I think we
> probably
> > > should do that here as well unless Jason dropped it for Vulkan on
> > > purpose for some reason in that commit.
> > >
> > > I'll send a separate patch for this after I confirm that it does
> not
> > > alter the results for the tests in CTS if we add that check.
> >
> > Actually, thinking about this a bit more, I don't think we need
>  That
> > commit is about honoring SamplerCreateInfo.anisotropyEnable to
> decide
> > whether to activate anisotropic filtering, so if that is true we
> want
> > to use that. Notice that since that commit we clamp the anisotropy
> > ratio to ensure it is in a valid range. If we pass a maxAnisotropy
> > value < 1, it will clamp it to the minimum value we can work with,
> so I
> > think Jason did that change on purpose.
> You overestimate the amount of thought I put into anisotropic
> filtering.  :-)
> I think this patch is probably correct.  At the very least, I don't
> think it's wrong.  I'm not sure that it makes sense to use
> anisotropic filtering with NEAREST.  I'm not even quite sure what
> that would mean.  The spec certainly doesn't say.  Anyway, I think
> I'm fine with this but a bit more digging to make sure we're actually
> doing it right might be in order.

If you're using anisotropic filtering to enhance texture quality it
would seem odd that someone would use it with a nearest filter, but I
have not seen any indication that this combination should not be
allowed. After all, anisotropic filtering is conceptually orthogonal to
nearest/linear filtering.

I did not find any references in the Vulkan docs, but at least in
OpenGL this is explained in EXT_texture_filter_anisotropic  and they
actually mention the combination of nearest+anisotropic filtering
explicitly: 

https://www.opengl.org/registry/specs/EXT/texture_filter_anisotropic.tx
t

   "A texture's maximum degree of anisotropy is specified independent
from the texture's minification and magnification filter (as
opposed to being supported as an entirely new filtering mode).
Implementations are free to use the specified minification and
magnification filter to select a particular anisotropic texture
filtering scheme.  For example, a NEAREST filter with a maximum
degree of anisotropy of two could be treated as a 2-tap filter that
accounts for the direction of anisotropy.  Implementations are also
permitted to ignore the minification or magnification filter and
    implement the highest quality of anisotropic filtering possible."

So basically, some drivers/hardware may have nearest + anisotropy work
slightly different than linear + anisotropy. Not sure when that is
helpful, but it seems that it should be possible to do it.

Iago

> Reviewed-by: Jason Ekstrand 
> > Sounds reasonable?
> >
> > > Iago
> > >
> > > >
> > > > On 24/11/16 11:30, Iago Toral Quiroga wrote:
> > > > >
> > > > >
> > > > > Fixes multiple Vulkan CTS tests that combine anisotropy and
> > > > > VK_FILTER_NEAREST
> > > > > in dEQP-VK.texture.filtering_anisotropy.*
> > > > > ---
> > > > >   src/intel/vulkan/genX_state.c | 2 +-
> > > > >   1 file changed, 1 insertion(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/src/intel/vulkan/genX_state.c
> > > > > b/src/intel/vulkan/genX_state.c
> > > > > index 4122395..0f621f9 100644
> > > > > --- a/src/intel/vulkan/genX_state.c
> > > > > +++ b/src/intel/vulkan/genX_state.c
> > > > > @@ -101,7 +101,7 @@ vk_to_gen_tex_filter(VkFilter filter,
> bool
> > > > > anisotropyEnable)
> > > > >  default:
> > > > > assert(!"Invalid filter");
> > > > >  case VK_FILTER_NEAREST:
> > > > > -  return MAPFILTER_NEAREST;
> > > > > +  return anisotropyEnable ? MAPFILTER_ANISOTROPIC :
> > > > > MAPFILTER_NEAREST;
> > > > >  case VK_FILTER_LINEAR:
> > > > > return anisotropyEnable ? MAPFILTER_ANISOTROPIC :

[Mesa-dev] [Bug 98851] triangle clipping causes wrong ... something

2016-11-24 Thread bugzilla-daemon

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

Bug ID: 98851
Summary: triangle clipping causes wrong ... something
Product: Mesa
Version: git
Hardware: Other
OS: All
Status: NEW
Severity: normal
Priority: medium
Component: Drivers/Gallium/swr
Assignee: mesa-dev@lists.freedesktop.org
Reporter: imir...@alum.mit.edu
QA Contact: mesa-dev@lists.freedesktop.org

Sorry for the non-descript subject. I'm just not sure what's wrong. The
following test fails:

generated_tests/spec/glsl-1.30/execution/interpolation/interpolation-noperspective-gl_FrontColor-flat-fixed.shader_test

as do many of its friends. Note that the color is meant to be
non-perspective-interpolated. Also note that the flat-none.shader_test variant
of this works as expected. As does the flat-vertex.shader_test variant after my
perspective-interpolation for clip distances fix is applied. So it's something
wrong with the clipper.

Comparing to
generated_tests/spec/glsl-1.30/execution/interpolation/interpolation-smooth-gl_FrontColor-flat-fixed.shader_test,
it looks different (which smoothly-interpolates the color). And there's no
reason to think that color is being perspective-interpolated, as that is
decided in the user frag shader. However I'm not sure what's going on - 1/w is
getting messed up perhaps? Not sure.

Furthermore, note that
generated_tests/spec/glsl-1.30/execution/interpolation/interpolation-smooth-gl_FrontColor-flat-fixed.shader_test
does pass with swr, and the only difference is that the color is
perspective-interpolated vs no-perspective-interpolated.

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

[Mesa-dev] [Bug 98846] triangle clipping causes wrong vertex's attribute to be broadcasted for flat interpolation

2016-11-24 Thread bugzilla-daemon

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

--- Comment #1 from Ilia Mirkin  ---
Actually I tracked it down to this little bit in clip.h:

void ClipSimd(const simdscalar& vPrimMask, const simdscalar& vClipMask,
PA_STATE& pa, const simdscalari& vPrimId, const simdscalari& vViewportIdx)
{
...
uint32_t provokingVertex = 0;
if(pa.binTopology == TOP_TRIANGLE_FAN)
{
provokingVertex = this->state.frontendState.provokingVertex.triFan;
}
///@todo: line topology for wireframe?

Which is ... obviously wrong. That said, I'm not sure what the right thing is,
esp in light of how the topologyProvokingVertex is selected in the FE. I leave
it to the pro's.

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

Re: [Mesa-dev] clover: OpenCL image support

2016-11-24 Thread Francisco Jerez

Edward O'Callaghan  writes:

> The following series implements what is needed on clover's
> side for OpenCL image support. This seems to work with some
> basic applications with radeonsi. Although, I have not yet
> included the patch to enable by default until the LLVM bugs
> this can potentially trigger with more complex kernels are
> resolved.
>
> Please kindly review,
>
> Edward O'Callaghan (4):
>  [PATCH 1/4] clover: Implement 'CL_MEM_OBJECT_IMAGE2D_ARRAY'
>  [PATCH 2/4] clover: Implement 'CL_MEM_OBJECT_IMAGE1D'
>  [PATCH 3/4] clover: Implement 'CL_MEM_OBJECT_IMAGE1D_BUFFER'
>  [PATCH 4/4] clover: Implement 'CL_MEM_OBJECT_IMAGE1D_ARRAY'

I don't think this is sufficient to get the CL 1.2+ image formats fully
working, at least you're going to need to add support for array and
buffer images to the memory transfer commands from api/transfer.cpp,
implement several missing image-related queries from CL 1.2, fix the
gallium pipe_resource and transfer glue code to work with the new memory
object types, and fix the LLVM interfacing code and compute kernel
handling to accept the new image types as kernel argument.  Still a
bunch of work to do, but this seems like a good start... :)

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

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

Re: [Mesa-dev] [PATCH 4/4] clover: Implement 'CL_MEM_OBJECT_IMAGE1D_ARRAY'

2016-11-24 Thread Francisco Jerez

Edward O'Callaghan  writes:

> Signed-off-by: Edward O'Callaghan 
> ---
>  src/gallium/state_trackers/clover/api/memory.cpp  | 13 +
>  src/gallium/state_trackers/clover/core/memory.cpp | 14 ++
>  src/gallium/state_trackers/clover/core/memory.hpp | 11 +++
>  3 files changed, 34 insertions(+), 4 deletions(-)
>
> diff --git a/src/gallium/state_trackers/clover/api/memory.cpp 
> b/src/gallium/state_trackers/clover/api/memory.cpp
> index 7aee417..9b3b70e 100644
> --- a/src/gallium/state_trackers/clover/api/memory.cpp
> +++ b/src/gallium/state_trackers/clover/api/memory.cpp
> @@ -182,6 +182,15 @@ clCreateImage(cl_context d_ctx, cl_mem_flags d_flags,
>  desc->image_width,
>  desc->image_row_pitch, host_ptr);
>  
> +   case CL_MEM_OBJECT_IMAGE1D_ARRAY:
> +  if (!desc->image_width)
> + throw error(CL_INVALID_IMAGE_SIZE);
> +

Missing width and array size checking.

> +  return new image1d_array(ctx, flags, format,
> +   desc->image_width,
> +   desc->image_array_size, 
> desc->image_slice_pitch,
> +   host_ptr);
> +
> case CL_MEM_OBJECT_IMAGE2D:
>if (!desc->image_width || !desc->image_height)
>   throw error(CL_INVALID_IMAGE_SIZE);
> @@ -230,10 +239,6 @@ clCreateImage(cl_context d_ctx, cl_mem_flags d_flags,
>   desc->image_depth, desc->image_row_pitch,
>   desc->image_slice_pitch, host_ptr);
>  
> -   case CL_MEM_OBJECT_IMAGE1D_ARRAY:
> -  // XXX - Not implemented.
> -  throw error(CL_IMAGE_FORMAT_NOT_SUPPORTED);
> -
> default:
>throw error(CL_INVALID_IMAGE_DESCRIPTOR);
> }
> diff --git a/src/gallium/state_trackers/clover/core/memory.cpp 
> b/src/gallium/state_trackers/clover/core/memory.cpp
> index 94b1273..517d53f 100644
> --- a/src/gallium/state_trackers/clover/core/memory.cpp
> +++ b/src/gallium/state_trackers/clover/core/memory.cpp
> @@ -211,6 +211,20 @@ image1d_buffer::type() const {
> return CL_MEM_OBJECT_IMAGE1D_BUFFER;
>  }
>  
> +image1d_array::image1d_array(clover::context , cl_mem_flags flags,
> + const cl_image_format *format,
> + size_t width,
> + size_t array_size, size_t slice_pitch,
> + void *host_ptr) :
> +   image(ctx, flags, format, width, 0, 1,
> + 0, slice_pitch, slice_pitch * array_size, host_ptr) {

Set unused height argument to one, and make sure we don't lose track of
the array size of the image.

> +}
> +
> +cl_mem_object_type
> +image1d_array::type() const {
> +   return CL_MEM_OBJECT_IMAGE1D_ARRAY;
> +}
> +
>  image2d::image2d(clover::context , cl_mem_flags flags,
>   const cl_image_format *format, size_t width,
>   size_t height, size_t row_pitch,
> diff --git a/src/gallium/state_trackers/clover/core/memory.hpp 
> b/src/gallium/state_trackers/clover/core/memory.hpp
> index 1394fe6..a54db83 100644
> --- a/src/gallium/state_trackers/clover/core/memory.hpp
> +++ b/src/gallium/state_trackers/clover/core/memory.hpp
> @@ -154,6 +154,17 @@ namespace clover {
>virtual cl_mem_object_type type() const;
> };
>  
> +   class image1d_array : public image {
> +   public:
> +  image1d_array(clover::context , cl_mem_flags flags,
> +const cl_image_format *format,
> +size_t width,
> +size_t array_size, size_t slice_pitch,
> +void *host_ptr);
> +
> +  virtual cl_mem_object_type type() const;
> +   };
> +
> class image2d : public image {
> public:
>image2d(clover::context , cl_mem_flags flags,
> -- 
> 2.7.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev


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

Re: [Mesa-dev] [PATCH 3/4] clover: Implement 'CL_MEM_OBJECT_IMAGE1D_BUFFER'

2016-11-24 Thread Francisco Jerez

Edward O'Callaghan  writes:

> Signed-off-by: Edward O'Callaghan 
> ---
>  src/gallium/state_trackers/clover/api/memory.cpp  |  9 -
>  src/gallium/state_trackers/clover/core/memory.cpp | 13 +
>  src/gallium/state_trackers/clover/core/memory.hpp | 10 ++
>  3 files changed, 31 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/state_trackers/clover/api/memory.cpp 
> b/src/gallium/state_trackers/clover/api/memory.cpp
> index 41e344e..7aee417 100644
> --- a/src/gallium/state_trackers/clover/api/memory.cpp
> +++ b/src/gallium/state_trackers/clover/api/memory.cpp
> @@ -174,6 +174,14 @@ clCreateImage(cl_context d_ctx, cl_mem_flags d_flags,
>   desc->image_width,
>   desc->image_row_pitch, host_ptr);
>  
> +   case CL_MEM_OBJECT_IMAGE1D_BUFFER:
> +  if (!desc->image_width)
> + throw error(CL_INVALID_IMAGE_SIZE);
> +
> +  return new image1d_buffer(ctx, flags, format,
> +desc->image_width,
> +desc->image_row_pitch, host_ptr);
> +
> case CL_MEM_OBJECT_IMAGE2D:
>if (!desc->image_width || !desc->image_height)
>   throw error(CL_INVALID_IMAGE_SIZE);
> @@ -223,7 +231,6 @@ clCreateImage(cl_context d_ctx, cl_mem_flags d_flags,
>   desc->image_slice_pitch, host_ptr);
>  
> case CL_MEM_OBJECT_IMAGE1D_ARRAY:
> -   case CL_MEM_OBJECT_IMAGE1D_BUFFER:
>// XXX - Not implemented.
>throw error(CL_IMAGE_FORMAT_NOT_SUPPORTED);
>  
> diff --git a/src/gallium/state_trackers/clover/core/memory.cpp 
> b/src/gallium/state_trackers/clover/core/memory.cpp
> index 246bd2d..94b1273 100644
> --- a/src/gallium/state_trackers/clover/core/memory.cpp
> +++ b/src/gallium/state_trackers/clover/core/memory.cpp
> @@ -198,6 +198,19 @@ image1d::type() const {
> return CL_MEM_OBJECT_IMAGE1D;
>  }
>  
> +image1d_buffer::image1d_buffer(clover::context , cl_mem_flags flags,
> +   const cl_image_format *format,
> +   size_t width, size_t row_pitch,
> +   void *host_ptr) :
> +   image(ctx, flags, format, width, 0, 1,
> + row_pitch, 0, row_pitch, host_ptr) {
> +}
> +
> +cl_mem_object_type
> +image1d_buffer::type() const {
> +   return CL_MEM_OBJECT_IMAGE1D_BUFFER;
> +}
> +
>  image2d::image2d(clover::context , cl_mem_flags flags,
>   const cl_image_format *format, size_t width,
>   size_t height, size_t row_pitch,
> diff --git a/src/gallium/state_trackers/clover/core/memory.hpp 
> b/src/gallium/state_trackers/clover/core/memory.hpp
> index ad9052b..1394fe6 100644
> --- a/src/gallium/state_trackers/clover/core/memory.hpp
> +++ b/src/gallium/state_trackers/clover/core/memory.hpp
> @@ -144,6 +144,16 @@ namespace clover {
>virtual cl_mem_object_type type() const;
> };
>  
> +   class image1d_buffer : public image {
> +   public:
> +  image1d_buffer(clover::context , cl_mem_flags flags,
> + const cl_image_format *format,
> + size_t width, size_t row_pitch,
> + void *host_ptr);
> +
> +  virtual cl_mem_object_type type() const;
> +   };
> +
> class image2d : public image {
> public:
>image2d(clover::context , cl_mem_flags flags,

AFAICT my comments to your previous patch apply here as well.

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


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

Re: [Mesa-dev] [PATCH 2/4] clover: Implement 'CL_MEM_OBJECT_IMAGE1D'

2016-11-24 Thread Francisco Jerez

Edward O'Callaghan  writes:

> Signed-off-by: Edward O'Callaghan 
> ---
>  src/gallium/state_trackers/clover/api/memory.cpp  |  9 -
>  src/gallium/state_trackers/clover/core/memory.cpp | 13 +
>  src/gallium/state_trackers/clover/core/memory.hpp | 10 ++
>  3 files changed, 31 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/state_trackers/clover/api/memory.cpp 
> b/src/gallium/state_trackers/clover/api/memory.cpp
> index 58f56d1..41e344e 100644
> --- a/src/gallium/state_trackers/clover/api/memory.cpp
> +++ b/src/gallium/state_trackers/clover/api/memory.cpp
> @@ -166,6 +166,14 @@ clCreateImage(cl_context d_ctx, cl_mem_flags d_flags,
> ret_error(r_errcode, CL_SUCCESS);
>  
> switch (desc->image_type) {
> +   case CL_MEM_OBJECT_IMAGE1D:
> +  if (!desc->image_width)
> + throw error(CL_INVALID_IMAGE_SIZE);
> +

We probably need to check that the specified image width is within the
device limits -- There's no device::max_image_levels_1d() query but
max_image_levels_2d() should work as well.

> +  return new image1d(ctx, flags, format,
> + desc->image_width,
> + desc->image_row_pitch, host_ptr);
> +
> case CL_MEM_OBJECT_IMAGE2D:
>if (!desc->image_width || !desc->image_height)
>   throw error(CL_INVALID_IMAGE_SIZE);
> @@ -214,7 +222,6 @@ clCreateImage(cl_context d_ctx, cl_mem_flags d_flags,
>   desc->image_depth, desc->image_row_pitch,
>   desc->image_slice_pitch, host_ptr);
>  
> -   case CL_MEM_OBJECT_IMAGE1D:
> case CL_MEM_OBJECT_IMAGE1D_ARRAY:
> case CL_MEM_OBJECT_IMAGE1D_BUFFER:
>// XXX - Not implemented.
> diff --git a/src/gallium/state_trackers/clover/core/memory.cpp 
> b/src/gallium/state_trackers/clover/core/memory.cpp
> index de1862b..246bd2d 100644
> --- a/src/gallium/state_trackers/clover/core/memory.cpp
> +++ b/src/gallium/state_trackers/clover/core/memory.cpp
> @@ -185,6 +185,19 @@ image::slice_pitch() const {
> return _slice_pitch;
>  }
>  
> +image1d::image1d(clover::context , cl_mem_flags flags,
> + const cl_image_format *format,
> + size_t width, size_t row_pitch,
> + void *host_ptr) :
> +   image(ctx, flags, format, width, 0, 1,

All surface dimension fields (width, height, depth) of a clover::image
object are considered valid regardless of the image type, so we should
set unused dimensions to 1 in order to avoid unexpected results while
doing arithmetic or various error checking with them.

> + row_pitch, 0, row_pitch, host_ptr) {

I don't think you can rely on the row pitch to be meaningful for 1D
images, it's probably necessary to pass it as argument to the
constructor, we're probably better off calculating the size by hand.

> +}
> +
> +cl_mem_object_type
> +image1d::type() const {
> +   return CL_MEM_OBJECT_IMAGE1D;
> +}
> +
>  image2d::image2d(clover::context , cl_mem_flags flags,
>   const cl_image_format *format, size_t width,
>   size_t height, size_t row_pitch,
> diff --git a/src/gallium/state_trackers/clover/core/memory.hpp 
> b/src/gallium/state_trackers/clover/core/memory.hpp
> index 1a3e8c9..ad9052b 100644
> --- a/src/gallium/state_trackers/clover/core/memory.hpp
> +++ b/src/gallium/state_trackers/clover/core/memory.hpp
> @@ -134,6 +134,16 @@ namespace clover {
> std::unique_ptr> resources;
> };
>  
> +   class image1d : public image {
> +   public:
> +  image1d(clover::context , cl_mem_flags flags,
> +  const cl_image_format *format,
> +  size_t width, size_t row_pitch,
> +  void *host_ptr);
> +
> +  virtual cl_mem_object_type type() const;
> +   };
> +
> class image2d : public image {
> public:
>image2d(clover::context , cl_mem_flags flags,
> -- 
> 2.7.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev


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

Re: [Mesa-dev] [PATCH 1/4] clover: Implement 'CL_MEM_OBJECT_IMAGE2D_ARRAY'

2016-11-24 Thread Francisco Jerez

Edward O'Callaghan  writes:

> Signed-off-by: Edward O'Callaghan 
> ---
>  src/gallium/state_trackers/clover/api/memory.cpp  | 17 -
>  src/gallium/state_trackers/clover/core/memory.cpp | 14 ++
>  src/gallium/state_trackers/clover/core/memory.hpp | 11 +++
>  3 files changed, 41 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/state_trackers/clover/api/memory.cpp 
> b/src/gallium/state_trackers/clover/api/memory.cpp
> index 9b3cd8b..58f56d1 100644
> --- a/src/gallium/state_trackers/clover/api/memory.cpp
> +++ b/src/gallium/state_trackers/clover/api/memory.cpp
> @@ -181,6 +181,22 @@ clCreateImage(cl_context d_ctx, cl_mem_flags d_flags,
>   desc->image_width, desc->image_height,
>   desc->image_row_pitch, host_ptr);
>  
> +   case CL_MEM_OBJECT_IMAGE2D_ARRAY:
> +  if (!desc->image_width || !desc->image_height)
> + throw error(CL_INVALID_IMAGE_SIZE);
> +
> +  if (all_of([=](const device ) {
> +   const size_t max = 1 << dev.max_image_levels_2d();
> +   return (desc->image_width > max ||
> +   desc->image_height > max);
> +}, ctx.devices()))
> + throw error(CL_INVALID_IMAGE_SIZE);
> +
> +  return new image2d_array(ctx, flags, format,
> +   desc->image_width, desc->image_height,
> +   desc->image_array_size, 
> desc->image_slice_pitch,
> +   host_ptr);
> +
> case CL_MEM_OBJECT_IMAGE3D:
>if (!desc->image_width || !desc->image_height || !desc->image_depth)
>   throw error(CL_INVALID_IMAGE_SIZE);
> @@ -201,7 +217,6 @@ clCreateImage(cl_context d_ctx, cl_mem_flags d_flags,
> case CL_MEM_OBJECT_IMAGE1D:
> case CL_MEM_OBJECT_IMAGE1D_ARRAY:
> case CL_MEM_OBJECT_IMAGE1D_BUFFER:
> -   case CL_MEM_OBJECT_IMAGE2D_ARRAY:
>// XXX - Not implemented.
>throw error(CL_IMAGE_FORMAT_NOT_SUPPORTED);
>  
> diff --git a/src/gallium/state_trackers/clover/core/memory.cpp 
> b/src/gallium/state_trackers/clover/core/memory.cpp
> index b852e68..de1862b 100644
> --- a/src/gallium/state_trackers/clover/core/memory.cpp
> +++ b/src/gallium/state_trackers/clover/core/memory.cpp
> @@ -198,6 +198,20 @@ image2d::type() const {
> return CL_MEM_OBJECT_IMAGE2D;
>  }
>  
> +image2d_array::image2d_array(clover::context , cl_mem_flags flags,
> + const cl_image_format *format,
> + size_t width, size_t height,
> + size_t array_size, size_t slice_pitch,
> + void *host_ptr) :
> +   image(ctx, flags, format, width, height, 1,
> + 0, slice_pitch, slice_pitch * array_size, host_ptr) {
> +}

Seems like you aren't passing the row pitch as argument, and the array
size is getting lost so you won't be able to recover it in order to
implement memory transfer functions and CL image queries.

> +
> +cl_mem_object_type
> +image2d_array::type() const {
> +   return CL_MEM_OBJECT_IMAGE2D_ARRAY;
> +}
> +
>  image3d::image3d(clover::context , cl_mem_flags flags,
>   const cl_image_format *format,
>   size_t width, size_t height, size_t depth,
> diff --git a/src/gallium/state_trackers/clover/core/memory.hpp 
> b/src/gallium/state_trackers/clover/core/memory.hpp
> index bd6da6b..1a3e8c9 100644
> --- a/src/gallium/state_trackers/clover/core/memory.hpp
> +++ b/src/gallium/state_trackers/clover/core/memory.hpp
> @@ -144,6 +144,17 @@ namespace clover {
>virtual cl_mem_object_type type() const;
> };
>  
> +   class image2d_array : public image {
> +   public:
> +  image2d_array(clover::context , cl_mem_flags flags,
> +const cl_image_format *format,
> +size_t width, size_t height,
> +size_t array_size, size_t slice_pitch,
> +void *host_ptr);
> +
> +  virtual cl_mem_object_type type() const;
> +   };
> +
> class image3d : public image {
> public:
>image3d(clover::context , cl_mem_flags flags,
> -- 
> 2.7.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev


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

[Mesa-dev] [PATCH] EGL/android: Enhance pbuffer implementation

2016-11-24 Thread Liu Zhiquan

Some dri drivers will pass multiple bits in buffer_mask parameter
to droid_image_get_buffer(), more than the actual supported buffer
type combination. For such case, will go through all the bits, and
will not return error when unsupported buffer is requested, only
return error when the allocation for supported buffer failed.

Signed-off-by: Liu Zhiquan 
Signed-off-by: Long, Zhifang 
---
 src/egl/drivers/dri2/platform_android.c | 209 +++-
 1 file changed, 126 insertions(+), 83 deletions(-)

diff --git a/src/egl/drivers/dri2/platform_android.c 
b/src/egl/drivers/dri2/platform_android.c
index 373e2c0..c70423d 100644
--- a/src/egl/drivers/dri2/platform_android.c
+++ b/src/egl/drivers/dri2/platform_android.c
@@ -392,13 +392,13 @@ droid_destroy_surface(_EGLDriver *drv, _EGLDisplay *disp, 
_EGLSurface *surf)
}
 
if (dri2_surf->dri_image_back) {
-  _eglLog(_EGL_DEBUG, "%s : %d : destroy dri_image_back", __func__, 
__LINE__);
+  _eglLog(_EGL_DEBUG, "destroy dri_image_back");
   dri2_dpy->image->destroyImage(dri2_surf->dri_image_back);
   dri2_surf->dri_image_back = NULL;
}
 
if (dri2_surf->dri_image_front) {
-  _eglLog(_EGL_DEBUG, "%s : %d : destroy dri_image_front", __func__, 
__LINE__);
+  _eglLog(_EGL_DEBUG, "destroy dri_image_front");
   dri2_dpy->image->destroyImage(dri2_surf->dri_image_front);
   dri2_surf->dri_image_front = NULL;
}
@@ -434,81 +434,98 @@ update_buffers(struct dri2_egl_surface *dri2_surf)
 }
 
 static int
-get_back_bo(struct dri2_egl_surface *dri2_surf)
+get_front_bo(struct dri2_egl_surface *dri2_surf, unsigned int format)
 {
struct dri2_egl_display *dri2_dpy =
   dri2_egl_display(dri2_surf->base.Resource.Display);
-   int fourcc, pitch;
-   int offset = 0, fd;
 
-   if (dri2_surf->dri_image_back)
+   if (dri2_surf->dri_image_front)
+   {
+  _eglLog(_EGL_WARNING, "dri2_image_front allocated !");
   return 0;
-
-   if (!dri2_surf->buffer)
-  return -1;
-
-   fd = get_native_buffer_fd(dri2_surf->buffer);
-   if (fd < 0) {
-  _eglLog(_EGL_WARNING, "Could not get native buffer FD");
-  return -1;
}
 
-   fourcc = get_fourcc(dri2_surf->buffer->format);
-
-   pitch = dri2_surf->buffer->stride *
-  get_format_bpp(dri2_surf->buffer->format);
-
-   if (fourcc == -1 || pitch == 0) {
-  _eglLog(_EGL_WARNING, "Invalid buffer fourcc(%x) or pitch(%d)",
-  fourcc, pitch);
-  return -1;
+   if (dri2_surf->base.Type == EGL_WINDOW_BIT) {
+  /* According current EGL spec, front buffer rendering
+   * for window surface is not supported now.
+   * and mesa doesn't have the implemetation of this case.
+   * Add warnning message, but not treat it as error.
+   */
+   _eglLog(_EGL_DEBUG, "front buffer for window surface is not supported 
now !");
+
+   } else if (dri2_surf->base.Type == EGL_PBUFFER_BIT) {
+
+   dri2_surf->dri_image_front =
+  dri2_dpy->image->createImage(dri2_dpy->dri_screen,
+  dri2_surf->base.Width,
+  dri2_surf->base.Height,
+  format,
+  0,
+  dri2_surf);
+  if (!dri2_surf->dri_image_front)
+  {
+ _eglLog(_EGL_WARNING, "dri2_image_front allocation failed !");
+ return -1;
+  }
+   } else {
+  _eglLog(_EGL_WARNING, "pixmap is not supported now !");
}
 
-   dri2_surf->dri_image_back =
-  dri2_dpy->image->createImageFromFds(dri2_dpy->dri_screen,
-  dri2_surf->base.Width,
-  dri2_surf->base.Height,
-  fourcc,
-  ,
-  1,
-  ,
-  ,
-  dri2_surf);
-   if (!dri2_surf->dri_image_back)
-  return -1;
-
return 0;
 }
 
 static int
-droid_image_get_buffers(__DRIdrawable *driDrawable,
-  unsigned int format,
-  uint32_t *stamp,
-  void *loaderPrivate,
-  uint32_t buffer_mask,
-  struct __DRIimageList *images)
+get_back_bo(struct dri2_egl_surface *dri2_surf, unsigned int format)
 {
-   struct dri2_egl_surface *dri2_surf = loaderPrivate;
struct dri2_egl_display *dri2_dpy =
   dri2_egl_display(dri2_surf->base.Resource.Display);
+   int fourcc, pitch;
+   int offset = 0, fd;
 
-   images->image_mask = 0;
-   images->front = NULL;
-   images->back = NULL;
-
-   if (update_buffers(dri2_surf) < 0)
+   if (dri2_surf->dri_image_back) {
+  _eglLog(_EGL_WARNING, "dri_image_back allocated !");
   return 0;
+   }
 
-   if (buffer_mask &

Re: [Mesa-dev] loader: Add amdgpu code to loader.c

2016-11-24 Thread Albert Freeman

A different patch to that code has been applied that does the same
thing in a different (better) way.

On 24 November 2016 at 05:25, Albert Freeman  wrote:
> I wrote this code in response to a issue someone on mesa-users had
> (https://lists.freedesktop.org/archives/mesa-users/2016-October/001231.html).
> They didn't reply so I don't know if the patch resolved the issue. Can
> someone please determine its usefulness. Also please check if
> drmCommandWrite() is the correct function to use. I can't test the
> code, I don't have amdgpu.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] loader: Add amdgpu code to loader.c

2016-11-24 Thread Albert Freeman

I wrote this code in response to a issue someone on mesa-users had
(https://lists.freedesktop.org/archives/mesa-users/2016-October/001231.html).
They didn't reply so I don't know if the patch resolved the issue. Can
someone please determine its usefulness. Also please check if
drmCommandWrite() is the correct function to use. I can't test the
code, I don't have amdgpu.
diff --git a/mesa/src/loader/loader.c b/mesa2/src/loader/loader.c
index 3e60e4c..4a89ba4 100644
--- a/mesa/src/loader/loader.c
+++ b/mesa2/src/loader/loader.c
@@ -515,6 +515,8 @@ sysfs_get_pci_id_for_fd(int fd, int *vendor_id, int 
*chip_id)
 #include 
 /* for radeon */
 #include 
+/* for amdgpu */
+#include 
 
 static int
 drm_get_pci_id_for_fd(int fd, int *vendor_id, int *chip_id)
@@ -564,6 +566,26 @@ drm_get_pci_id_for_fd(int fd, int *vendor_id, int *chip_id)
 *chip_id = -1;
   }
}
+   else if (strcmp(version->name, "amdgpu") == 0) {
+  struct drm_amdgpu_info info;
+  struct drm_amdgpu_info_device info_device;
+  int ret;
+
+  *vendor_id = 0x1002;
+
+  memset(, 0, sizeof(info));
+  memset(_device, 0, sizeof(info_device));
+  info.query = AMDGPU_INFO_DEV_INFO;
+  info.return_pointer = (uint64_t) _device;
+  info.return_size = sizeof(struct drm_amdgpu_info_device);
+  ret = drmCommandWrite(fd, DRM_AMDGPU_INFO, , sizeof(info));
+  if (ret) {
+ log_(_LOADER_WARNING, "MESA-LOADER: failed to get info for amdgpu\n");
+ *chip_id = -1;
+  } else {
+ *chip_id = info_device.device_id;
+  }
+   }
else if (strcmp(version->name, "nouveau") == 0) {
   *vendor_id = 0x10de;
   /* not used */
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Mesa 13.0.2 release candidate

2016-11-24 Thread Jonathan Gray

On Thu, Nov 24, 2016 at 05:25:26PM +, Emil Velikov wrote:
> Hello list,
> 
> The candidate for the Mesa 13.0.2 is now available. Currently we have:
>  - 49 queued
>  - 4 nominated (outstanding)
>  - and 1 rejected patch(es)
> 
> 
> With this series we have - fixes for vc4, i965 and radeon drivers. In addition
> to that PCI IDs for Geminilake have been added to the i965 driver,
> 
> The respective Vulkan drivers have seen multiple improvements some of which
> include improved smoketesting and addressed memory leaks.
> 
> Races during _mesa_HashWalk() (while using glDeleteFramebuffers alongside
> glTexImage2D) and "#version 0" in GLSL programs have been addressed.
> 
> BSD and Hurd users should be above to build the latest code as we no longer
> use PATH_MAX.

You seem to be confusing things there.

BSD has had PATH_MAX since 1989.

commit dcc36b4d161e5d44274cc4bd6d375d04b758b61e
Author: Keith Bostic 
Date:   Thu Feb 16 14:11:48 1989 -0800

system limits for POSIX 1003.1; included by include/limits.h

SCCS-vsn: 7.1

diff --git a/sys/sys/syslimits.h b/sys/sys/syslimits.h
new file mode 100644
index 000..c60f25d
--- /dev/null
+++ b/sys/sys/syslimits.h
@@ -0,0 +1,29 @@
+/*
+ * Copyright (c) 1988 The Regents of the University of California.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms are permitted
+ * provided that the above copyright notice and this paragraph are
+ * duplicated in all such forms and that any documentation,
+ * advertising materials, and other materials related to such
+ * distribution and use acknowledge that the software was developed
+ * by the University of California, Berkeley.  The name of the
+ * University may not be used to endorse or promote products derived
+ * from this software without specific prior written permission.
+ * THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
+ * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
+ *
+ * @(#)syslimits.h 7.1 (Berkeley) 02/16/89
+ */
+
+#defineARG_MAX 20480   /* max bytes for an exec function */
+#defineCHILD_MAX   40  /* max simultaneous processes */
+#defineLINK_MAX8   /* max file link count */
+#defineMAX_CANON   255 /* max bytes in terminal canonical 
input line */
+#defineMAX_INPUT   255 /* max bytes in terminal input */
+#defineNAME_MAX255 /* max number of bytes in a file name */
+#defineNGROUPS_MAX 16  /* max number of supplemental group 
id's */
+#defineOPEN_MAX64  /* max open files per process */
+#definePATH_MAX1024/* max number of bytes in pathname */
+#definePIPE_BUF512 /* max number of bytes for atomic pipe 
writes */

> 
> 
> Take a look at section "Mesa stable queue" for more information.
> 
> 
> Testing reports/general approval
> 
> Any testing reports (or general approval of the state of the branch) will be
> greatly appreciated.
> 
> The plan is to have 13.0.2 this Saturday (25th of November), around or
> shortly after 17:00 GMT.
> 
> If you have any questions or suggestions - be that about the current patch
> queue or otherwise, please go ahead.
> 
> 
> Trivial merge conflicts
> ---
> commit 9d5c3fc12b05d944508ef4e3b1f2ddc4f23c0a82
> Author: Jason Ekstrand 
> 
> i965/gs: Allow primitive id to be a system value
> 
> (cherry picked from commit a5e88e66e633aaeb587b274d80e21cd46c8ee2cb)
> 
> 
> commit 8dbdbc21910a6d37c381535186f9e728fff8690d
> Author: Jason Ekstrand 
> 
> anv: Handle null in all destructors
> 
> (cherry picked from commit 49f08ad77f51cc344e4bfe60ba9f8d9fccfbd753)
> 
> 
> commit 1809f17bda56d4f9d6385f63a9c4a5df890e3cad
> Author: Kenneth Graunke 
> 
> mesa: Drop PATH_MAX usage.
> 
> (cherry picked from commit 9bfee7047b70cb0aa026ca9536465762f96cb2b1)
> 
> Cheers,
> Emil
> 
> 
> Mesa stable queue
> -
> 
> Nominated (4)
> =
> 
> Dave Airlie (1):
>   2de85eb radv: fix texturesamples to handle single sample case
> 
> Jason Ekstrand (2):
>   e73d136 vulkan/wsi/x11: Implement FIFO mode.
> 
> Note: temporary on hold.
> Commit seems to be a feature and provides no clear indication about the bugs
> it addresses. Jason, is this really applicable for stable ?
> 
>   054e48e anv/cmd_buffer: Re-emit MEDIA_CURBE_LOAD when CS push
> constants are dirty
> 
> Note: temporary on hold.
> Depends on the refactoring d33e2ad67c3 (anv: Move INTERFACE_DESCRIPTOR_DATA
> setup to the pipeline) which in itself depends on another refactoring 
> (cleanup)
> commit 623e1e06d8c and likely others. Jason, any input ?
> 
> Kevin Strasser (1):
>   932bb3f vulkan/wsi: Add a thread-safe queue implementation
>

Re: [Mesa-dev] [PATCH v5] clover: restore support for LLVM <= 3.9

2016-11-24 Thread Francisco Jerez

Jan Vesely  writes:

> On Tue, 2016-11-22 at 20:25 +0100, Vedran Miletić wrote:
>> The commit 8e430ff8b060b4e8e922bae24b3c57837da6ea77 support for LLVM
>> 3.9 and older versionsin  Clover. This patch restores it and refactors
>> the support using Clover compatibility layer for LLVM.
>> 
>> v2: merged #ifdef blocks
>> v3: added support for LLVM 3.6-3.8
>> v4: add missing #ifdef around 
>> v5: simplify using templates and lambda
>> 
>> Signed-off-by: Vedran Miletić 
>> Reviewed-by[v2]: Jan Vesely 
>> Tested-by[v4]: Vinson Lee 
>> Tested-by[v4]: Pierre Moreau 
>> Reviewed-by: Francisco Jerez 
>> ---
>>  .../state_trackers/clover/llvm/codegen/bitcode.cpp |  9 +++--
>>  src/gallium/state_trackers/clover/llvm/compat.hpp  | 18 
>> ++
>>  2 files changed, 21 insertions(+), 6 deletions(-)
>> 
>> diff --git a/src/gallium/state_trackers/clover/llvm/codegen/bitcode.cpp 
>> b/src/gallium/state_trackers/clover/llvm/codegen/bitcode.cpp
>> index 5dcc4f8..d09207b 100644
>> --- a/src/gallium/state_trackers/clover/llvm/codegen/bitcode.cpp
>> +++ b/src/gallium/state_trackers/clover/llvm/codegen/bitcode.cpp
>> @@ -32,6 +32,7 @@
>>  ///
>>  
>>  #include "llvm/codegen.hpp"
>> +#include "llvm/compat.hpp"
>>  #include "llvm/metadata.hpp"
>>  #include "core/error.hpp"
>>  #include "util/algorithm.hpp"
>> @@ -99,13 +100,9 @@ clover::llvm::parse_module_library(const module , 
>> ::llvm::LLVMContext ,
>> auto mod = ::llvm::parseBitcodeFile(::llvm::MemoryBufferRef(
>>  as_string(m.secs[0].data), " "), 
>> ctx);
>>  
>> -   if (::llvm::Error err = mod.takeError()) {
>> -  std::string msg;
>> -  ::llvm::handleAllErrors(std::move(err), [&](::llvm::ErrorInfoBase 
>> ) {
>> - msg = EIB.message();
>> - fail(r_log, error(CL_INVALID_PROGRAM), msg.c_str());
>
> interesting that this used to pass char * and now switched to
> std::string. was that a leftover from the times of compat::string?

I don't think so, it was 8e430ff8b060b4e8e922bae24b3c57837da6ea77 that
changed the argument to be a char * for some reason.

> you can add my RB to v5.
>
> Reviewed-by: Jan Vesely 
>
> Jan
>
>> +   compat::handle_module_error(mod, [&](const std::string ) {
>> + fail(r_log, error(CL_INVALID_PROGRAM), s);
>>});
>> -   }
>>  
>> return std::unique_ptr<::llvm::Module>(std::move(*mod));
>>  }
>> diff --git a/src/gallium/state_trackers/clover/llvm/compat.hpp 
>> b/src/gallium/state_trackers/clover/llvm/compat.hpp
>> index a963cff..fc257ec 100644
>> --- a/src/gallium/state_trackers/clover/llvm/compat.hpp
>> +++ b/src/gallium/state_trackers/clover/llvm/compat.hpp
>> @@ -39,6 +39,11 @@
>>  #include 
>>  #include 
>>  #include 
>> +#if HAVE_LLVM >= 0x0400
>> +#include 
>> +#else
>> +#include 
>> +#endif
>>  
>>  #if HAVE_LLVM >= 0x0307
>>  #include 
>> @@ -158,6 +163,19 @@ namespace clover {
>>  #else
>>   const auto default_reloc_model = ::llvm::Reloc::Default;
>>  #endif
>> +
>> + template inline void
>> + handle_module_error(M , const F ) {
>> +#if HAVE_LLVM >= 0x0400
>> +if (::llvm::Error err = mod.takeError())
>> +   ::llvm::handleAllErrors(std::move(err), 
>> [&](::llvm::ErrorInfoBase ) {
>> + f(eib.message());
>> +  });
>> +#else
>> +if (!mod)
>> +   f(mod.getError().message());
>> +#endif
>> + }
>>}
>> }
>>  }
>
> -- 
> Jan Vesely 


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

Re: [Mesa-dev] [PATCH v5] clover: restore support for LLVM <= 3.9

2016-11-24 Thread Francisco Jerez

Vedran Miletić  writes:

> The commit 8e430ff8b060b4e8e922bae24b3c57837da6ea77 support for LLVM
> 3.9 and older versionsin  Clover. This patch restores it and refactors
> the support using Clover compatibility layer for LLVM.
>
> v2: merged #ifdef blocks
> v3: added support for LLVM 3.6-3.8
> v4: add missing #ifdef around 
> v5: simplify using templates and lambda
>
> Signed-off-by: Vedran Miletić 
> Reviewed-by[v2]: Jan Vesely 
> Tested-by[v4]: Vinson Lee 
> Tested-by[v4]: Pierre Moreau 
> Reviewed-by: Francisco Jerez 
> ---
>  .../state_trackers/clover/llvm/codegen/bitcode.cpp |  9 +++--
>  src/gallium/state_trackers/clover/llvm/compat.hpp  | 18 
> ++
>  2 files changed, 21 insertions(+), 6 deletions(-)
>
> diff --git a/src/gallium/state_trackers/clover/llvm/codegen/bitcode.cpp 
> b/src/gallium/state_trackers/clover/llvm/codegen/bitcode.cpp
> index 5dcc4f8..d09207b 100644
> --- a/src/gallium/state_trackers/clover/llvm/codegen/bitcode.cpp
> +++ b/src/gallium/state_trackers/clover/llvm/codegen/bitcode.cpp
> @@ -32,6 +32,7 @@
>  ///
>  
>  #include "llvm/codegen.hpp"
> +#include "llvm/compat.hpp"
>  #include "llvm/metadata.hpp"
>  #include "core/error.hpp"
>  #include "util/algorithm.hpp"
> @@ -99,13 +100,9 @@ clover::llvm::parse_module_library(const module , 
> ::llvm::LLVMContext ,
> auto mod = ::llvm::parseBitcodeFile(::llvm::MemoryBufferRef(
>  as_string(m.secs[0].data), " "), 
> ctx);
>  
> -   if (::llvm::Error err = mod.takeError()) {
> -  std::string msg;
> -  ::llvm::handleAllErrors(std::move(err), [&](::llvm::ErrorInfoBase 
> ) {
> - msg = EIB.message();
> - fail(r_log, error(CL_INVALID_PROGRAM), msg.c_str());
> +   compat::handle_module_error(mod, [&](const std::string ) {
> + fail(r_log, error(CL_INVALID_PROGRAM), s);
>});
> -   }
>  
> return std::unique_ptr<::llvm::Module>(std::move(*mod));
>  }
> diff --git a/src/gallium/state_trackers/clover/llvm/compat.hpp 
> b/src/gallium/state_trackers/clover/llvm/compat.hpp
> index a963cff..fc257ec 100644
> --- a/src/gallium/state_trackers/clover/llvm/compat.hpp
> +++ b/src/gallium/state_trackers/clover/llvm/compat.hpp
> @@ -39,6 +39,11 @@
>  #include 
>  #include 
>  #include 
> +#if HAVE_LLVM >= 0x0400
> +#include 
> +#else
> +#include 
> +#endif
>  
>  #if HAVE_LLVM >= 0x0307
>  #include 
> @@ -158,6 +163,19 @@ namespace clover {
>  #else
>   const auto default_reloc_model = ::llvm::Reloc::Default;
>  #endif
> +
> + template inline void

I've dropped the 'inline' keyword (template functions implicitly have
inline linkage in C++), fixed some minor spelling issues in the commit
message and landed the patch.  Thanks!

> + handle_module_error(M , const F ) {
> +#if HAVE_LLVM >= 0x0400
> +if (::llvm::Error err = mod.takeError())
> +   ::llvm::handleAllErrors(std::move(err), 
> [&](::llvm::ErrorInfoBase ) {
> + f(eib.message());
> +  });
> +#else
> +if (!mod)
> +   f(mod.getError().message());
> +#endif
> + }
>}
> }
>  }
> -- 
> 2.7.4


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

Re: [Mesa-dev] [PATCH v2] clover: restore support for LLVM <= 3.9

2016-11-24 Thread Francisco Jerez

Emil Velikov  writes:

> On 17 November 2016 at 17:27, Emil Velikov  wrote:
>
>> Admittedly not a huge C++ expert, but what's wrong with having a
>> simple 5 line patch that adds the original code in a if guard ?
>> If then the LLVM <= 3.9 codepath is (somewhat) wrong, let's tackle
>> that separately.
>>
> Anyone ?
>
Hi Emil, that's basically what v5 of Vedran's patch does, but the macro
magic is factored into a separate function to keep the running code free
of compatibility clutter, otherwise his patch should behave identically
to the pre-existing code (prior to
8e430ff8b060b4e8e922bae24b3c57837da6ea77) on LLVM v3.9 and older.

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


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

Re: [Mesa-dev] [PATCH] anv/state: if enabled, use anisotropic filtering also with VK_FILTER_NEAREST

2016-11-24 Thread Jason Ekstrand

On Nov 24, 2016 7:12 AM, "Iago Toral"  wrote:
>
> On Thu, 2016-11-24 at 14:33 +0100, Iago Toral wrote:
> > Hi Lionel,
> >
> > On Thu, 2016-11-24 at 13:08 +, Lionel Landwerlin wrote:
> > >
> > > Hi Iago,
> > >
> > > Looking at the history, before
> > > ed4fe3e9ba9018e68afe6fdd4f267218a537fdaa
> > > we seem to set min/mag filter to MAPFILTER_ANISOTROPIC if
> > > maxAnisotropy
> > >  > 1. It seems your patch makes sense in using
> > > MAPFILTER_ANISOTROPIC
> > > in
> > > the NEAREST case, but I wonder whether we should also check for
> > > maxAnisotropy > 1.
> > Right, good catch, although I think that if we do that it should be a
> > separate change since we are not currently checking that for the
> > linear
> > filter either.

In GL, there is no explicit enable.  It's just assumed that it's "always
on" and the anisotropy value being 1.0 or > 1.0 enables and disables it.
Vulkan has an explicit bit so we should use that.

> > It seems that we do check for this in OpenGL so I think we probably
> > should do that here as well unless Jason dropped it for Vulkan on
> > purpose for some reason in that commit.
> >
> > I'll send a separate patch for this after I confirm that it does not
> > alter the results for the tests in CTS if we add that check.
>
> Actually, thinking about this a bit more, I don't think we need  That
> commit is about honoring SamplerCreateInfo.anisotropyEnable to decide
> whether to activate anisotropic filtering, so if that is true we want
> to use that. Notice that since that commit we clamp the anisotropy
> ratio to ensure it is in a valid range. If we pass a maxAnisotropy
> value < 1, it will clamp it to the minimum value we can work with, so I
> think Jason did that change on purpose.

You overestimate the amount of thought I put into anisotropic filtering.
:-)

I think this patch is probably correct.  At the very least, I don't think
it's wrong.  I'm not sure that it makes sense to use anisotropic filtering
with NEAREST.  I'm not even quite sure what that would mean.  The spec
certainly doesn't say.  Anyway, I think I'm fine with this but a bit more
digging to make sure we're actually doing it right might be in order.

Reviewed-by: Jason Ekstrand 

> Sounds reasonable?
>
> > Iago
> >
> > >
> > > On 24/11/16 11:30, Iago Toral Quiroga wrote:
> > > >
> > > >
> > > > Fixes multiple Vulkan CTS tests that combine anisotropy and
> > > > VK_FILTER_NEAREST
> > > > in dEQP-VK.texture.filtering_anisotropy.*
> > > > ---
> > > >   src/intel/vulkan/genX_state.c | 2 +-
> > > >   1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/src/intel/vulkan/genX_state.c
> > > > b/src/intel/vulkan/genX_state.c
> > > > index 4122395..0f621f9 100644
> > > > --- a/src/intel/vulkan/genX_state.c
> > > > +++ b/src/intel/vulkan/genX_state.c
> > > > @@ -101,7 +101,7 @@ vk_to_gen_tex_filter(VkFilter filter, bool
> > > > anisotropyEnable)
> > > >  default:
> > > > assert(!"Invalid filter");
> > > >  case VK_FILTER_NEAREST:
> > > > -  return MAPFILTER_NEAREST;
> > > > +  return anisotropyEnable ? MAPFILTER_ANISOTROPIC :
> > > > MAPFILTER_NEAREST;
> > > >  case VK_FILTER_LINEAR:
> > > > return anisotropyEnable ? MAPFILTER_ANISOTROPIC :
> > > > MAPFILTER_LINEAR;
> > > >  }
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2] clover: restore support for LLVM <= 3.9

2016-11-24 Thread Jan Vesely

On Fri, 2016-11-25 at 00:00 +, Emil Velikov wrote:
> On 17 November 2016 at 17:27, Emil Velikov  wrote:
> 
> > Admittedly not a huge C++ expert, but what's wrong with having a
> > simple 5 line patch that adds the original code in a if guard ?
> > If then the LLVM <= 3.9 codepath is (somewhat) wrong, let's tackle
> > that separately.
> > 
> 
> Anyone ?

you might get a more complete answer from someone else (curro), but
given the volatility of LLVM's C++ interface and the range of versions
supported by mesa, all the ifdef mess is concentrated in the compat
layer (llvm/compat.h).
Vedran's v5 took that approach.

Jan

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

-- 
Jan Vesely 

signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v5] clover: restore support for LLVM <= 3.9

2016-11-24 Thread Jan Vesely

On Tue, 2016-11-22 at 20:25 +0100, Vedran Miletić wrote:
> The commit 8e430ff8b060b4e8e922bae24b3c57837da6ea77 support for LLVM
> 3.9 and older versionsin  Clover. This patch restores it and refactors
> the support using Clover compatibility layer for LLVM.
> 
> v2: merged #ifdef blocks
> v3: added support for LLVM 3.6-3.8
> v4: add missing #ifdef around 
> v5: simplify using templates and lambda
> 
> Signed-off-by: Vedran Miletić 
> Reviewed-by[v2]: Jan Vesely 
> Tested-by[v4]: Vinson Lee 
> Tested-by[v4]: Pierre Moreau 
> Reviewed-by: Francisco Jerez 
> ---
>  .../state_trackers/clover/llvm/codegen/bitcode.cpp |  9 +++--
>  src/gallium/state_trackers/clover/llvm/compat.hpp  | 18 
> ++
>  2 files changed, 21 insertions(+), 6 deletions(-)
> 
> diff --git a/src/gallium/state_trackers/clover/llvm/codegen/bitcode.cpp 
> b/src/gallium/state_trackers/clover/llvm/codegen/bitcode.cpp
> index 5dcc4f8..d09207b 100644
> --- a/src/gallium/state_trackers/clover/llvm/codegen/bitcode.cpp
> +++ b/src/gallium/state_trackers/clover/llvm/codegen/bitcode.cpp
> @@ -32,6 +32,7 @@
>  ///
>  
>  #include "llvm/codegen.hpp"
> +#include "llvm/compat.hpp"
>  #include "llvm/metadata.hpp"
>  #include "core/error.hpp"
>  #include "util/algorithm.hpp"
> @@ -99,13 +100,9 @@ clover::llvm::parse_module_library(const module , 
> ::llvm::LLVMContext ,
> auto mod = ::llvm::parseBitcodeFile(::llvm::MemoryBufferRef(
>  as_string(m.secs[0].data), " "), 
> ctx);
>  
> -   if (::llvm::Error err = mod.takeError()) {
> -  std::string msg;
> -  ::llvm::handleAllErrors(std::move(err), [&](::llvm::ErrorInfoBase 
> ) {
> - msg = EIB.message();
> - fail(r_log, error(CL_INVALID_PROGRAM), msg.c_str());

interesting that this used to pass char * and now switched to
std::string. was that a leftover from the times of compat::string?
you can add my RB to v5.

Reviewed-by: Jan Vesely 

Jan

> +   compat::handle_module_error(mod, [&](const std::string ) {
> + fail(r_log, error(CL_INVALID_PROGRAM), s);
>});
> -   }
>  
> return std::unique_ptr<::llvm::Module>(std::move(*mod));
>  }
> diff --git a/src/gallium/state_trackers/clover/llvm/compat.hpp 
> b/src/gallium/state_trackers/clover/llvm/compat.hpp
> index a963cff..fc257ec 100644
> --- a/src/gallium/state_trackers/clover/llvm/compat.hpp
> +++ b/src/gallium/state_trackers/clover/llvm/compat.hpp
> @@ -39,6 +39,11 @@
>  #include 
>  #include 
>  #include 
> +#if HAVE_LLVM >= 0x0400
> +#include 
> +#else
> +#include 
> +#endif
>  
>  #if HAVE_LLVM >= 0x0307
>  #include 
> @@ -158,6 +163,19 @@ namespace clover {
>  #else
>   const auto default_reloc_model = ::llvm::Reloc::Default;
>  #endif
> +
> + template inline void
> + handle_module_error(M , const F ) {
> +#if HAVE_LLVM >= 0x0400
> +if (::llvm::Error err = mod.takeError())
> +   ::llvm::handleAllErrors(std::move(err), 
> [&](::llvm::ErrorInfoBase ) {
> + f(eib.message());
> +  });
> +#else
> +if (!mod)
> +   f(mod.getError().message());
> +#endif
> + }
>}
> }
>  }

-- 
Jan Vesely 

signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 08/14] glsl: refactor duplicated validations between 2 layout-qualifiers

2016-11-24 Thread Timothy Arceri

Thanks.

Patches 7 & 8 are:

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

1 2 >

1 - 100 of 110 matches

Mail list logo