[Mesa-dev] [PATCH] glsl: use linked shaders rather than compiled shaders

2016-07-10 Thread Timothy Arceri 
At this point there is no reason not to be using the linked shaders,
using the linked shaders should be faster and will make things simpler
for upcoming shader cache work.

The previous variable name suggests the linked shaders were intended
to be used here anyway.
---
 src/compiler/glsl/linker.cpp | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/compiler/glsl/linker.cpp b/src/compiler/glsl/linker.cpp
index 527b636..5719c87 100644
--- a/src/compiler/glsl/linker.cpp
+++ b/src/compiler/glsl/linker.cpp
@@ -4116,12 +4116,12 @@ calculate_array_size_and_stride(struct 
gl_shader_program *shProg,
   }
}
 
-   for (unsigned i = 0; i < shProg->NumShaders; i++) {
-  if (shProg->Shaders[i] == NULL)
+   for (unsigned i = 0; i < MESA_SHADER_STAGES; i++) {
+  const gl_linked_shader *sh = shProg->_LinkedShaders[i];
+  if (sh == NULL)
  continue;
 
-  const gl_shader *stage = shProg->Shaders[i];
-  foreach_in_list(ir_instruction, node, stage->ir) {
+  foreach_in_list(ir_instruction, node, sh->ir) {
  ir_variable *var = node->as_variable();
  if (!var || !var->get_interface_type() ||
  var->data.mode != ir_var_shader_storage)
-- 
2.7.4

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

Re: [Mesa-dev] mesa from git fails to compile

2016-07-10 Thread Jason Ekstrand 
This smells like strange Python problems.  Ccing the resident Python expert.
Hello, compiling mesa from git is failing on this error:

Making all in isl
make[5]: Entering directory `/«PKGBUILDDIR»/build/dri/src/intel/isl'
python2.7  ../../../../../src/intel/isl/gen_format_layout.py \
--csv ../../../../../src/intel/isl/isl_format_layout.csv --out
isl_format_layout.c
Traceback (most recent call last):
  File "../../../../../src/intel/isl/gen_format_layout.py", line 92, in

output_encoding='utf-8')
TypeError: __init__() got an unexpected keyword argument 'future_imports'
make[5]: *** [isl_format_layout.c] Error 1
make[5]: Leaving directory `/«PKGBUILDDIR»/build/dri/src/intel/isl'
make[4]: *** [all-recursive] Error 1
make[4]: Leaving directory `/«PKGBUILDDIR»/build/dri/src/intel'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/«PKGBUILDDIR»/build/dri/src'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/«PKGBUILDDIR»/build/dri/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/«PKGBUILDDIR»/build/dri'
make: *** [debian/stamp/x86_64-linux-gnu-build-dri] Error 2

Any idea where is problem and how to fix it?

Full build log is available at:

https://launchpad.net/~pali/+archive/ubuntu/graphics-drivers/+build/10446196/+files/buildlog_ubuntu-precise-amd64.mesa-lts-trusty_11.3.0-git201607100358.5c17fb2~ubuntu12.04.1_BUILDING.txt.gz

--
Pali Rohár
pali.ro...@gmail.com

___
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] mesa from git fails to compile

2016-07-10 Thread Pali Rohár 
Hello, compiling mesa from git is failing on this error:

Making all in isl
make[5]: Entering directory `/«PKGBUILDDIR»/build/dri/src/intel/isl'
python2.7  ../../../../../src/intel/isl/gen_format_layout.py \
--csv ../../../../../src/intel/isl/isl_format_layout.csv --out 
isl_format_layout.c
Traceback (most recent call last):
  File "../../../../../src/intel/isl/gen_format_layout.py", line 92, in 
output_encoding='utf-8')
TypeError: __init__() got an unexpected keyword argument 'future_imports'
make[5]: *** [isl_format_layout.c] Error 1
make[5]: Leaving directory `/«PKGBUILDDIR»/build/dri/src/intel/isl'
make[4]: *** [all-recursive] Error 1
make[4]: Leaving directory `/«PKGBUILDDIR»/build/dri/src/intel'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/«PKGBUILDDIR»/build/dri/src'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/«PKGBUILDDIR»/build/dri/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/«PKGBUILDDIR»/build/dri'
make: *** [debian/stamp/x86_64-linux-gnu-build-dri] Error 2

Any idea where is problem and how to fix it?

Full build log is available at:

https://launchpad.net/~pali/+archive/ubuntu/graphics-drivers/+build/10446196/+files/buildlog_ubuntu-precise-amd64.mesa-lts-trusty_11.3.0-git201607100358.5c17fb2~ubuntu12.04.1_BUILDING.txt.gz

-- 
Pali Rohár
pali.ro...@gmail.com


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

[Mesa-dev] [PATCH Mesa] egl/wayland: check drmGetMagic for failure

2016-07-10 Thread Eric Engestrom 
Coverity (CovID 1255672) noticed that all the other calls to drmGetMagic were
checked for failure, but not this one. Fix this, and return before an invalid
magic token is used to authenticate the device.

Signed-off-by: Eric Engestrom 
---
 src/egl/drivers/dri2/platform_wayland.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/src/egl/drivers/dri2/platform_wayland.c 
b/src/egl/drivers/dri2/platform_wayland.c
index e714e44..9de75f2 100644
--- a/src/egl/drivers/dri2/platform_wayland.c
+++ b/src/egl/drivers/dri2/platform_wayland.c
@@ -918,7 +918,10 @@ drm_handle_device(void *data, struct wl_drm *drm, const 
char *device)
if (drmGetNodeTypeFromFd(dri2_dpy->fd) == DRM_NODE_RENDER) {
   dri2_dpy->authenticated = 1;
} else {
-  drmGetMagic(dri2_dpy->fd, );
+  if (drmGetMagic(dri2_dpy->fd, )) {
+ _eglLog(_EGL_WARNING, "wayland-egl: failed to get drm magic");
+ return;
+  }
   wl_drm_authenticate(dri2_dpy->wl_drm, magic);
}
 }
-- 
2.9.0

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

Re: [Mesa-dev] [PATCH] glsl: look for frag data bindings with [0] tacked onto the end for arrays

2016-07-10 Thread Corentin Wallez 
Not sure how reviews work in Mesa, but this patch LGTM. I also tested that
it fixes the relevant tests failures it is supposed to address.

On Wed, Jul 6, 2016 at 7:40 PM, Ilia Mirkin  wrote:

> The GL spec is very unclear on this point. Apparently this is discussed
> without resolution in the closed Khronos bugtracker at
> https://cvs.khronos.org/bugzilla/show_bug.cgi?id=7829 . The
> recommendation is to allow dropping the [0] for looking up the bindings.
>
> The approach taken in this patch is to instead tack on [0]'s for each
> arrayness level of the output's type, and doing the lookup again. That
> way, for
>
> out vec4 foo[2][2][2]
>
> we will end up looking for bindings for foo, foo[0], foo[0][0], and
> foo[0][0][0], in that order of preference.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96765
> Signed-off-by: Ilia Mirkin 
> ---
>  src/compiler/glsl/linker.cpp | 39 ---
>  1 file changed, 28 insertions(+), 11 deletions(-)
>
> diff --git a/src/compiler/glsl/linker.cpp b/src/compiler/glsl/linker.cpp
> index d963f54..9d54c2f 100644
> --- a/src/compiler/glsl/linker.cpp
> +++ b/src/compiler/glsl/linker.cpp
> @@ -2566,6 +2566,7 @@ find_available_slots(unsigned used_mask, unsigned
> needed_count)
>  /**
>   * Assign locations for either VS inputs or FS outputs
>   *
> + * \param mem_ctx   Temporary ralloc context used for linking
>   * \param prog  Shader program whose variables need locations
> assigned
>   * \param constants Driver specific constant values for the program.
>   * \param target_index  Selector for the program target to receive
> location
> @@ -2577,7 +2578,8 @@ find_available_slots(unsigned used_mask, unsigned
> needed_count)
>   * error is emitted to the shader link log and false is returned.
>   */
>  bool
> -assign_attribute_or_color_locations(gl_shader_program *prog,
> +assign_attribute_or_color_locations(void *mem_ctx,
> +gl_shader_program *prog,
>  struct gl_constants *constants,
>  unsigned target_index)
>  {
> @@ -2680,16 +2682,31 @@
> assign_attribute_or_color_locations(gl_shader_program *prog,
>} else if (target_index == MESA_SHADER_FRAGMENT) {
>  unsigned binding;
>  unsigned index;
> + const char *name = var->name;
> + const glsl_type *type = var->type;
> +
> + while (type) {
> +/* Check if there's a binding for the variable name */
> +if (prog->FragDataBindings->get(binding, name)) {
> +   assert(binding >= FRAG_RESULT_DATA0);
> +   var->data.location = binding;
> +   var->data.is_unmatched_generic_inout = 0;
> +
> +   if (prog->FragDataIndexBindings->get(index, name)) {
> +  var->data.index = index;
> +   }
> +   break;
> +}
>
> -if (prog->FragDataBindings->get(binding, var->name)) {
> -   assert(binding >= FRAG_RESULT_DATA0);
> -   var->data.location = binding;
> -var->data.is_unmatched_generic_inout = 0;
> +/* If not, but it's an array type, look for name[0] */
> +if (type->is_array()) {
> +   name = ralloc_asprintf(mem_ctx, "%s[0]", name);
> +   type = type->fields.array;
> +   continue;
> +}
>
> -   if (prog->FragDataIndexBindings->get(index, var->name)) {
> -  var->data.index = index;
> -   }
> -}
> +break;
> + }
>}
>
>/* From GL4.5 core spec, section 15.2 (Shader Execution):
> @@ -4816,12 +4833,12 @@ link_shaders(struct gl_context *ctx, struct
> gl_shader_program *prog)
>prev = i;
> }
>
> -   if (!assign_attribute_or_color_locations(prog, >Const,
> +   if (!assign_attribute_or_color_locations(mem_ctx, prog, >Const,
>  MESA_SHADER_VERTEX)) {
>goto done;
> }
>
> -   if (!assign_attribute_or_color_locations(prog, >Const,
> +   if (!assign_attribute_or_color_locations(mem_ctx, prog, >Const,
>  MESA_SHADER_FRAGMENT)) {
>goto done;
> }
> --
> 2.7.3
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 20/47] clover/llvm: Clean up codestyle of get_kernel_args().

2016-07-10 Thread Jan Vesely 
On Sat, 2016-07-09 at 14:32 -0700, Francisco Jerez wrote:
> Jan Vesely  writes:
> 
> > On Mon, 2016-07-04 at 12:31 -0700, Francisco Jerez wrote:
> > > Jan Vesely  writes:
> > > 
> > > > On Sun, 2016-07-03 at 17:51 -0700, Francisco Jerez wrote:
> > > > > Reviewed-by: Serge Martin 
> > > > > ---
> > > > >  .../state_trackers/clover/llvm/invocation.cpp  | 223
> > > > > ++---
> > > > >  1 file changed, 103 insertions(+), 120 deletions(-)
> > > > > 
> > > > > diff --git
> > > > > a/src/gallium/state_trackers/clover/llvm/invocation.cpp
> > > > > b/src/gallium/state_trackers/clover/llvm/invocation.cpp
> > > > > index 754e477..0fc6190 100644
> > > > > --- a/src/gallium/state_trackers/clover/llvm/invocation.cpp
> > > > > +++ b/src/gallium/state_trackers/clover/llvm/invocation.cpp
> > > > > @@ -77,7 +77,10 @@
> > > > >  using namespace clover;
> > > > >  using namespace clover::llvm;
> > > > >  
> > > > > +using ::llvm::cast;
> > > > > +using ::llvm::dyn_cast;
> > > > >  using ::llvm::Function;
> > > > > +using ::llvm::isa;
> > > > >  using ::llvm::LLVMContext;
> > > > >  using ::llvm::Module;
> > > > >  using ::llvm::raw_string_ostream;
> > > > > @@ -362,147 +365,127 @@ namespace {
> > > > > }
> > > > >  #endif
> > > > >  
> > > > > +   enum module::argument::type
> > > > > +   get_image_type(const std::string ,
> > > > > +  const std::string ) {
> > > > > +  if (type == "image2d_t" && qual == "read_only")
> > > > > + return module::argument::image2d_rd;
> > > > > +  else if (type == "image2d_t" && qual == "write_only")
> > > > > + return module::argument::image2d_wr;
> > > > > +  else if (type == "image3d_t" && qual == "read_only")
> > > > > + return module::argument::image3d_rd;
> > > > > +  else if (type == "image3d_t" && qual == "write_only")
> > > > > + return module::argument::image3d_wr;
> > > > > +  else
> > > > > + unreachable("Unknown image type");
> > > > > +   }
> > > > 
> > > > maybe add support for image1d_t?
> > > > 
> > > It shouldn't be difficult but it will take an amount of
> > > boilerplate
> > > that
> > > likely belongs in a different patch [for starters there are no
> > > module::argument::image1d_* enums ;)].
> > 
> > OK. FWIW, I tested the series and it works OK on my Turks setup (no
> > piglit regressions).
> > 
> Tested-by? :)

Sure.
Tested-by: Jan Vesely 

Jan

> 
> > Jan
> > 
> > > 
> > > > > +
> > > > > std::vector
> > > > > -   get_kernel_args(const llvm::Module *mod, const
> > > > > std::string
> > > > > _name,
> > > > > -   const clang::CompilerInstance ) {
> > > > > +   make_kernel_args(const Module , const std::string
> > > > > _name,
> > > > > +const clang::CompilerInstance ) {
> > > > >    std::vector args;
> > > > >    const auto address_spaces =
> > > > > c.getTarget().getAddressSpaceMap();
> > > > > -  llvm::Function *kernel_func = mod-
> > > > > > getFunction(kernel_name);
> > > > > -  assert(kernel_func && "Kernel name not found in
> > > > > module.");
> > > > > -  auto arg_md = get_kernel_arg_md(kernel_func);
> > > > > -
> > > > > -  llvm::DataLayout TD(mod);
> > > > > -  llvm::Type *size_type =
> > > > > - TD.getSmallestLegalIntType(mod->getContext(),
> > > > > sizeof(cl_uint) * 8);
> > > > > -
> > > > > -  for (const auto : kernel_func->args()) {
> > > > > +  const Function  = *mod.getFunction(kernel_name);
> > > > > +  const auto arg_md = get_kernel_arg_md();
> > > > > +  ::llvm::DataLayout dl();
> > > > > +  const auto size_type =
> > > > > + dl.getSmallestLegalIntType(mod.getContext(),
> > > > > sizeof(cl_uint) * 8);
> > > > >  
> > > > > - llvm::Type *arg_type = arg.getType();
> > > > > - const unsigned arg_store_size =
> > > > > TD.getTypeStoreSize(arg_type);
> > > > > +  for (const auto  : f.args()) {
> > > > > + const auto arg_type = arg.getType();
> > > > >  
> > > > >   // OpenCL 1.2 specification, Ch. 6.1.5: "A built-in
> > > > > data
> > > > >   // type that is not a power of two bytes in size
> > > > > must
> > > > > be
> > > > >   // aligned to the next larger power of two".  We
> > > > > need
> > > > > this
> > > > >   // alignment for three element vectors, which have
> > > > >   // non-power-of-2 store size.
> > > > > + const unsigned arg_store_size =
> > > > > dl.getTypeStoreSize(arg_type);
> > > > >   const unsigned arg_api_size =
> > > > > util_next_power_of_two(arg_store_size);
> > > > >  
> > > > > - llvm::Type *target_type = arg_type->isIntegerTy() ?
> > > > > -   TD.getSmallestLegalIntType(mod->getContext(),
> > > > > arg_store_size * 8)
> > > > > -   : arg_type;
> > > > > - unsigned target_size =
> > > > >

[Mesa-dev] glxinfo page - you too can now update it

2016-07-10 Thread Ilia Mirkin 
Hi everyone,

As many of you are no doubt aware, I've been maintaining my glxinfo
page which shows, by hardware group, which extensions are supported.
If you haven't seen it already, this is available at
https://people.freedesktop.org/~imirkin/glxinfo/ . The hope is that
this information can be useful to application developers, who would
know which extensions/GL versions are safe to target, across Mesa
versions. [And it also has a "Vendor" driver version for easy
comparison to other driver providers.]

I've recently set up a git repository to house all of the data. You
can see it here: https://cgit.freedesktop.org/~imirkin/glxinfo . I've
set up the permissions so that anyone in the mesa group can push to
it. Furthermore, I've set up ~imirkin/public_html/glxinfo as a clone
of that repo, and anyone in the mesa group can do a "git pull" there
as well.

The idea is that individual hw driver developers can now add their
hardware to this page without going through me. The process is
outlined at https://cgit.freedesktop.org/~imirkin/glxinfo/tree/README
. Some operations aren't covered here, like how to add new hw groups,
and probably other bits. If you have any questions, happy to answer.

While I won't be policing anything, please try to make sure that
what's shown is a reflection of what actual end-users of the released
software will end up seeing, not what you can see when you have a ton
of patches to the kernel, llvm, or whatever else.

Cheers,

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

Re: [Mesa-dev] [PATCH 04/13] todo! dri: Questions about fence fd ownership

2016-07-10 Thread Rob Clark 
On Fri, Jul 8, 2016 at 8:00 PM, Chad Versace  wrote:
> See the comments.
> ---
>  include/GL/internal/dri_interface.h | 9 +
>  1 file changed, 9 insertions(+)
>
> diff --git a/include/GL/internal/dri_interface.h 
> b/include/GL/internal/dri_interface.h
> index 99c83ec..051ddb4 100644
> --- a/include/GL/internal/dri_interface.h
> +++ b/include/GL/internal/dri_interface.h
> @@ -418,6 +418,12 @@ struct __DRI2fenceExtensionRec {
>  *
>  * \param ctx the context associated with the fence
>  * \param fd  the fence fd or -1
> +*
> +* TODO(chadv): Who owns the fence fd when the caller imports it (when
> +* fd != 1)? Does EGL or the driver own it?
> +*
> +* TODO(chadv): Who owns the fence fd when the driver creates it (when
> +* fd == -1)? Does EGL or the driver own it?

btw, thanks for picking up this patchset.. it was on my TODO list for
a while, but never quite bubbled up to the top..

When the caller creates an egl fence from an fd, the driver takes
ownership (and the caller must dup() if it wants to hold on to the fd
itself).  When caller calls eglDupNativeFenceFD() the caller takes
ownership of the returned fd (so the driver must dup()).

As far as internal ownership, I don't 100% remember what my plan was..
I guess the driver needs to dup(), since at the egl api level the
fence can be destroyed while the internal dri2_egl_sync is still live
due to driver holding a ref.

BR,
-R

>  */
> void *(*create_fence_fd)(__DRIcontext *ctx, int fd);
>
> @@ -430,6 +436,9 @@ struct __DRI2fenceExtensionRec {
>  *
>  * \param screen  the screen associated with the fence
>  * \param fence   the fence
> +*
> +* TODO(chadv): Should the driver return its actual fence fd? Or should it
> +* return a dup'd fd?
>  */
> int (*get_fence_fd)(__DRIscreen *screen, void *fence);
>  };
> --
> 2.9.0.rc2
>
> ___
> 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] nvc0/ir: fix images indirect access on Fermi

2016-07-10 Thread Samuel Pitoiset 



On 07/10/2016 04:23 PM, Ilia Mirkin wrote:

Do you also need to zero out su->tex.r ?


Nope, because it's only used when rIndirectSrc < 0 (ie. no indirection).




On Jul 10, 2016 10:19 AM, "Samuel Pitoiset" > wrote:

This fixes the following piglits:

arb_arrays_of_arrays-basic-imagestore-mixed-const-non-const-uniform-index
arb_arrays_of_arrays-basic-imagestore-mixed-const-non-const-uniform-index2

Signed-off-by: Samuel Pitoiset >
Cc: 12.0 >
---

Expect minor conflicts because I did refactor that logic but the
patch has not
been backported.

 src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp | 7
+++
 1 file changed, 7 insertions(+)

diff --git
a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
index 9735773..18955eb 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
@@ -2008,6 +2008,13 @@
NVC0LoweringPass::processSurfaceCoordsNVC0(TexInstruction *su)

adjustCoordinatesMS(su);

+   if (ind) {
+  Value *ptr;
+  ptr = bld.mkOp2v(OP_ADD, TYPE_U32, bld.getSSA(), ind,
bld.mkImm(su->tex.r));
+  ptr = bld.mkOp2v(OP_AND, TYPE_U32, bld.getSSA(), ptr,
bld.mkImm(7));
+  su->setIndirectR(ptr);
+   }
+
// get surface coordinates
for (c = 0; c < arg; ++c)
   src[c] = su->getSrc(c);
--
2.9.0

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


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

Re: [Mesa-dev] [PATCH] nvc0/ir: fix images indirect access on Fermi

2016-07-10 Thread Ilia Mirkin 
Do you also need to zero out su->tex.r ?

On Jul 10, 2016 10:19 AM, "Samuel Pitoiset" 
wrote:

> This fixes the following piglits:
>
> arb_arrays_of_arrays-basic-imagestore-mixed-const-non-const-uniform-index
> arb_arrays_of_arrays-basic-imagestore-mixed-const-non-const-uniform-index2
>
> Signed-off-by: Samuel Pitoiset 
> Cc: 12.0 
> ---
>
> Expect minor conflicts because I did refactor that logic but the patch has
> not
> been backported.
>
>  src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp | 7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
> b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
> index 9735773..18955eb 100644
> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
> @@ -2008,6 +2008,13 @@
> NVC0LoweringPass::processSurfaceCoordsNVC0(TexInstruction *su)
>
> adjustCoordinatesMS(su);
>
> +   if (ind) {
> +  Value *ptr;
> +  ptr = bld.mkOp2v(OP_ADD, TYPE_U32, bld.getSSA(), ind,
> bld.mkImm(su->tex.r));
> +  ptr = bld.mkOp2v(OP_AND, TYPE_U32, bld.getSSA(), ptr, bld.mkImm(7));
> +  su->setIndirectR(ptr);
> +   }
> +
> // get surface coordinates
> for (c = 0; c < arg; ++c)
>src[c] = su->getSrc(c);
> --
> 2.9.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] radeonsi: silence Coverity warning

2016-07-10 Thread Nicolai Hähnle 
From: Nicolai Hähnle 

Coverity's analysis is too weak to understand that
r600_init_flushed_depth(_, _, NULL) only returns true when
flushed_depth_texture was assigned a non-NULL value.
---
 src/gallium/drivers/radeonsi/si_blit.c  | 2 ++
 src/gallium/drivers/radeonsi/si_state.c | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/src/gallium/drivers/radeonsi/si_blit.c 
b/src/gallium/drivers/radeonsi/si_blit.c
index 84567f0..38a19d5 100644
--- a/src/gallium/drivers/radeonsi/si_blit.c
+++ b/src/gallium/drivers/radeonsi/si_blit.c
@@ -342,6 +342,8 @@ si_flush_depth_texture(struct si_context *sctx,
unsigned fully_copied_levels;
unsigned levels = 0;
 
+   assert(tex->flushed_depth_texture);
+
if (util_format_is_depth_and_stencil(dst->resource.b.b.format))
copy_planes = PIPE_MASK_Z | PIPE_MASK_S;
 
diff --git a/src/gallium/drivers/radeonsi/si_state.c 
b/src/gallium/drivers/radeonsi/si_state.c
index bdd7ef4..f801ca5 100644
--- a/src/gallium/drivers/radeonsi/si_state.c
+++ b/src/gallium/drivers/radeonsi/si_state.c
@@ -3001,6 +3001,8 @@ si_create_sampler_view_custom(struct pipe_context *ctx,
return NULL;
}
 
+   assert(tmp->flushed_depth_texture);
+
/* Override format for the case where the flushed texture
 * contains only Z or only S.
 */
-- 
2.7.4

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

[Mesa-dev] [PATCH] nvc0/ir: fix images indirect access on Fermi

2016-07-10 Thread Samuel Pitoiset 
This fixes the following piglits:

arb_arrays_of_arrays-basic-imagestore-mixed-const-non-const-uniform-index
arb_arrays_of_arrays-basic-imagestore-mixed-const-non-const-uniform-index2

Signed-off-by: Samuel Pitoiset 
Cc: 12.0 
---

Expect minor conflicts because I did refactor that logic but the patch has not
been backported.

 src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
index 9735773..18955eb 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
@@ -2008,6 +2008,13 @@ 
NVC0LoweringPass::processSurfaceCoordsNVC0(TexInstruction *su)
 
adjustCoordinatesMS(su);
 
+   if (ind) {
+  Value *ptr;
+  ptr = bld.mkOp2v(OP_ADD, TYPE_U32, bld.getSSA(), ind, 
bld.mkImm(su->tex.r));
+  ptr = bld.mkOp2v(OP_AND, TYPE_U32, bld.getSSA(), ptr, bld.mkImm(7));
+  su->setIndirectR(ptr);
+   }
+
// get surface coordinates
for (c = 0; c < arg; ++c)
   src[c] = su->getSrc(c);
-- 
2.9.0

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