Re: [Mesa-dev] [Intel-gfx] [RFC libdrm] intel: Add support for softpin

[Daniel Vetter]

On Mon, Dec 14, 2015 at 07:24:29AM +, Song, Ruiling wrote:
> 
> 
> > -Original Message-
> > From: hoegsb...@gmail.com [mailto:hoegsb...@gmail.com] On Behalf Of
> > Kristian H?gsberg
> > Sent: Monday, December 14, 2015 1:34 PM
> > To: Song, Ruiling 
> > Cc: Winiarski, Michal ; intel-
> > g...@lists.freedesktop.org; mesa-dev@lists.freedesktop.org; Ben Widawsky
> > ; dri-de...@lists.freedesktop.org
> > Subject: Re: [Intel-gfx] [RFC libdrm] intel: Add support for softpin
> > 
> > On Sun, Dec 13, 2015 at 7:17 PM, Song, Ruiling 
> > wrote:
> > >> -Original Message-
> > >> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On
> > Behalf
> > >> Of Micha? Winiarski
> > >> Sent: Wednesday, September 9, 2015 10:07 PM
> > >> To: intel-...@lists.freedesktop.org
> > >> Cc: Ben Widawsky ; dri-
> > de...@lists.freedesktop.org;
> > >> mesa-dev@lists.freedesktop.org
> > >> Subject: [Intel-gfx] [RFC libdrm] intel: Add support for softpin
> > >>
> > >> Softpin allows userspace to take greater control of GPU virtual address
> > >> space and eliminates the need of relocations. It can also be used to
> > >> mirror addresses between GPU and CPU (shared virtual memory).
> > >> Calls to drm_intel_bo_emit_reloc are still required to build the list of
> > >> drm_i915_gem_exec_objects at exec time, but no entries in relocs are
> > >> created. Self-relocs don't make any sense for softpinned objects and can
> > >> indicate a programming errors, thus are forbidden. Softpinned objects
> > >> are marked by asterisk in debug dumps.
> > >>
> > >> Cc: Thomas Daniel 
> > >> Cc: Kristian Høgsberg 
> > >> Cc: Zou Nanhai 
> > >> Cc: Michel Thierry 
> > >> Cc: Ben Widawsky 
> > >> Cc: Chris Wilson 
> > >> Signed-off-by: Michał Winiarski 
> > >> ---
> > >>  include/drm/i915_drm.h|   4 +-
> > >>  intel/intel_bufmgr.c  |   9 +++
> > >>  intel/intel_bufmgr.h  |   1 +
> > >>  intel/intel_bufmgr_gem.c  | 176
> > >> --
> > >>  intel/intel_bufmgr_priv.h |   7 ++
> > >>  5 files changed, 173 insertions(+), 24 deletions(-)
> > >
> > > Will anybody help to push the patch to libdrm? Beignet highly depend on
> > this to implement ocl2.0 svm.
> > 
> > Is the kernel patch upstream?
> 
> Yes, the kernel patch already merged, see:
> http://cgit.freedesktop.org/drm-intel/commit/?id=506a8e87d8d2746b9e9d2433503fe237c54e4750
> 
> I find below line of code in libdrm does not match the kernel version. The 
> kernel patch defined as:
> "#define EXEC_OBJECT_PINNED (1<<4)", but this patch defined it as (1<<3).

Please always regenerate the entire headers from the kernel sources using

$ make headers_install

Then copy the headers from the kernel's usr/include/drm to libdrm. Never
patch i915_drm.h manually.

Thanks, Daniel

> 
> Hello Michal,
> 
> Could you help to rebase the patch against:
> [Intel-gfx] [PATCH libdrm v4 0/2] 48-bit virtual address support in   i915
> I think we need both 48bit & softpin in libdrm.
> 
> diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
> index ded43b1..2b99fc6 100644
> --- a/include/drm/i915_drm.h
> +++ b/include/drm/i915_drm.h
> @@ -350,6 +350,7 @@ typedef struct drm_i915_irq_wait {
>  #define I915_PARAM_REVISION  32
>  #define I915_PARAM_SUBSLICE_TOTAL 33
>  #define I915_PARAM_EU_TOTAL   34
> +#define I915_PARAM_HAS_EXEC_SOFTPIN   37
>  
>  typedef struct drm_i915_getparam {
>   int param;
> @@ -680,7 +681,8 @@ struct drm_i915_gem_exec_object2 {
>  #define EXEC_OBJECT_NEEDS_FENCE (1<<0)
>  #define EXEC_OBJECT_NEEDS_GTT(1<<1)
>  #define EXEC_OBJECT_WRITE(1<<2)
> -#define __EXEC_OBJECT_UNKNOWN_FLAGS -(EXEC_OBJECT_WRITE<<1)
> +#define EXEC_OBJECT_PINNED   (1<<3)
> +#define __EXEC_OBJECT_UNKNOWN_FLAGS -(EXEC_OBJECT_PINNED<<1)
>   __u64 flags;
>  
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v2] mesa: fix interface matching done in validate_io

[Tapani Pälli]

Patch makes following changes for interface matching:

   - do not try to match builtin variables
   - handle swizzle in input name, as example 'a.z' should
 match with 'a'
   - check that amount of inputs and outputs matches

These changes make interface matching tests to work in:
   ES31-CTS.sepshaderobjs.StateInteraction

Test does not still pass completely due to errors in rendering
output. IMO this is unrelated to interface matching.

v2: add spec reference, return true on desktop since we do not
have failing cases for it, inputs and outputs amount do not
need to match on desktop.

Signed-off-by: Tapani Pälli 
---
 src/mesa/main/shader_query.cpp | 54 ++
 1 file changed, 50 insertions(+), 4 deletions(-)

diff --git a/src/mesa/main/shader_query.cpp b/src/mesa/main/shader_query.cpp
index ced10a9..bc01b97 100644
--- a/src/mesa/main/shader_query.cpp
+++ b/src/mesa/main/shader_query.cpp
@@ -1377,19 +1377,38 @@ validate_io(const struct gl_shader *input_stage,
 const struct gl_shader *output_stage, bool isES)
 {
assert(input_stage && output_stage);
+   unsigned inputs = 0, outputs = 0;
+
+   /* Currently no matching done for desktop. */
+   if (!isES)
+  return true;
 
/* For each output in a, find input in b and do any required checks. */
foreach_in_list(ir_instruction, out, input_stage->ir) {
   ir_variable *out_var = out->as_variable();
-  if (!out_var || out_var->data.mode != ir_var_shader_out)
+  if (!out_var || out_var->data.mode != ir_var_shader_out ||
+  is_gl_identifier(out_var->name))
  continue;
 
+  outputs++;
+
+  inputs = 0;
   foreach_in_list(ir_instruction, in, output_stage->ir) {
  ir_variable *in_var = in->as_variable();
- if (!in_var || in_var->data.mode != ir_var_shader_in)
+ if (!in_var || in_var->data.mode != ir_var_shader_in ||
+ is_gl_identifier(in_var->name))
 continue;
 
- if (strcmp(in_var->name, out_var->name) == 0) {
+ inputs++;
+
+ unsigned len = strlen(in_var->name);
+
+ /* Handle input swizzle in variable name. */
+ const char *dot = strchr(in_var->name, '.');
+ if (dot)
+len = dot - in_var->name;
+
+ if (strncmp(in_var->name, out_var->name, len) == 0) {
 /* Since we now only validate precision, we can skip this step for
  * desktop GLSL shaders, there precision qualifier is ignored.
  *
@@ -1412,7 +1431,34 @@ validate_io(const struct gl_shader *input_stage,
  }
   }
}
-   return true;
+
+   /* Amount of inputs vs outputs should match when using OpenGL ES.
+*
+* From OpenGL ES 3.1 spec (Interface matching):
+*
+*"At an interface between program objects, the set of inputs and 
outputs
+*are considered to match exactly if and only if:
+*
+*- Every declared input variable has a matching output, as described
+*above.
+*
+*- There are no user-defined output variables declared without a
+*matching input variable declaration.
+*
+*- All matched input and output variables have identical precision
+*qualification.
+*
+*When the set of inputs and outputs on an interface between programs
+*matches exactly, all inputs are well-defined except when the
+*corresponding outputs were not written in the previous shader. 
However,
+*any mismatch between inputs and outputs will result in a validation
+*failure."
+*
+* OpenGL Core 4.5 spec includes same paragraph as above but without last
+* precision or the last 'validation failure' clause. Therefore behaviour is
+* more relaxed, input and output amount does not need to match on desktop.
+*/
+   return isES ? inputs == outputs : true;
 }
 
 /**
-- 
2.5.0

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

[Mesa-dev] gallium r300 driver for PowerPC

[Herminio Hernandez, Jr.]

Hello,

I am new to this list. I have been trying to see if I can fix or at least pin 
point an issue with Radeon r300 driver failing on PowerPC systems. This has 
been a problem for a while and I would like to help to get this fixed. I have 
done some debugging with valgrind and I think I may see where the issue is but 
I would to have someone double check what I am doing. So when I set my Default 
Depth to 16 I do get 3D acceleration but when I set to the default of 24 it 
breaks. Valgrind reports memory leaks when I run glxgears with a Default Depth 
of 24 but shows no definite memory leaks with a Depth of 16. I then got the 
source code and created a dev environment andnran glxgears through valgrind 
with my default depth of 24 and saw similar memory leaks. Here is a sample of 
what I am seeing.

==25273== 108 (12 direct, 96 indirect) bytes in 1 blocks are definitely lost in 
loss record 54 of 78
==25273==at 0xFFB2868: malloc (vg_replace_malloc.c:299)
==25273==by 0xED0457B: ???
==25273==by 0xEEC6F3B: ???
==25273==by 0xE95A78B: ???
==25273==by 0xED7DF7F: ???
==25273==by 0xED7D5DB: ???
==25273==by 0xEC5B377: ???
==25273==by 0xEC567EB: ???
==25273==by 0xFDEDFD3: dri2CreateScreen (dri2_glx.c:1235)
==25273==by 0xFDB866F: AllocAndFetchScreenConfigs (glxext.c:799)
==25273==by 0xFDB866F: __glXInitialize (glxext.c:910)
==25273==by 0xFDB36F3: GetGLXPrivScreenConfig.part.2 (glxcmds.c:172)
==25273==by 0xFDB396B: GetGLXPrivScreenConfig (glxcmds.c:168)
==25273==by 0xFDB396B: glXChooseVisual (glxcmds.c:1249)

It looks like the files in the src/glx branch is where the issue is. I am 
attaching the summary portion of the output I got from valgrind. Am I heading 
in the right direction?

Herminio









 ==20991== LEAK SUMMARY:
==20991==definitely lost: 0 bytes in 0 blocks
==20991==indirectly lost: 0 bytes in 0 blocks
==20991==  possibly lost: 592,952 bytes in 2,927 blocks
==20991==still reachable: 1,359,273 bytes in 1,538 blocks
==20991== suppressed: 0 bytes in 0 blocks
==20991== Reachable blocks (those to which a pointer was found) are not shown.
==20991== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==20991== 
==20991== ERROR SUMMARY: 672 errors from 672 contexts (suppressed: 0 from 0)
==20991== ERROR SUMMARY: 672 errors from 672 contexts (suppressed: 0 from 0)
==21922== HEAP SUMMARY:
==21922== in use at exit: 96,554 bytes in 192 blocks
==21922==   total heap usage: 1,312 allocs, 1,120 frees, 413,711 bytes allocated
==21922== 
==21922== Searching for pointers to 192 not-freed blocks
==21922== Checked 356,496 bytes
==21922== 
==21922== 5 bytes in 1 blocks are definitely lost in loss record 7 of 81
==21922==at 0xFFB2868: malloc (vg_replace_malloc.c:299)
==21922==by 0xFA073FB: strdup (in /lib/powerpc-linux-gnu/libc-2.21.so)
==21922==by 0xED1DA37: ???
==21922==by 0xE93B313: ???
==21922==by 0xEC12C6B: ???
==21922==by 0xEC0EAFB: ???
==21922==by 0xFDFB1D3: dri2CreateScreen (in 
/usr/lib/powerpc-linux-gnu/libGL.so.1.2.0)
==21922==by 0xFDC61AF: __glXInitialize (in 
/usr/lib/powerpc-linux-gnu/libGL.so.1.2.0)
==21922==by 0xFDC10A3: GetGLXPrivScreenConfig.part.2 (in 
/usr/lib/powerpc-linux-gnu/libGL.so.1.2.0)
==21922==by 0xFDC1303: glXChooseVisual (in 
/usr/lib/powerpc-linux-gnu/libGL.so.1.2.0)
==21922==by 0x10002A33: ??? (in /usr/bin/glxgears)
==21922==by 0x100010A3: ??? (in /usr/bin/glxgears)
==21922== 
==21922== 108 (12 direct, 96 indirect) bytes in 1 blocks are definitely lost in 
loss record 55 of 81
==21922==at 0xFFB2868: malloc (vg_replace_malloc.c:299)
==21922==by 0xECAD53B: ???
==21922==by 0xEF1F3CB: ???
==21922==by 0xE93B44B: ???
==21922==by 0xEC12C6B: ???
==21922==by 0xEC0EAFB: ???
==21922==by 0xFDFB1D3: dri2CreateScreen (in 
/usr/lib/powerpc-linux-gnu/libGL.so.1.2.0)
==21922==by 0xFDC61AF: __glXInitialize (in 
/usr/lib/powerpc-linux-gnu/libGL.so.1.2.0)
==21922==by 0xFDC10A3: GetGLXPrivScreenConfig.part.2 (in 
/usr/lib/powerpc-linux-gnu/libGL.so.1.2.0)
==21922==by 0xFDC1303: glXChooseVisual (in 
/usr/lib/powerpc-linux-gnu/libGL.so.1.2.0)
==21922==by 0x10002A33: ??? (in /usr/bin/glxgears)
==21922==by 0x100010A3: ??? (in /usr/bin/glxgears)
==21922== 
==21922== 3,172 (76 direct, 3,096 indirect) bytes in 1 blocks are definitely 
lost in loss record 75 of 81
==21922==at 0xFFB50A4: calloc (vg_replace_malloc.c:711)
==21922==by 0xEC0DA53: ???
==21922==by 0xEC1168F: ???
==21922==by 0xEC12CFF: ???
==21922==by 0xEC0EAFB: ???
==21922==by 0xFDFB1D3: dri2CreateScreen (in 
/usr/lib/powerpc-linux-gnu/libGL.so.1.2.0)
==21922==by 0xFDC61AF: __glXInitialize (in 
/usr/lib/powerpc-linux-gnu/libGL.so.1.2.0)
==21922==by 0xFDC10A3: GetGLXPrivScreenConfig.part.2 (in 
/usr/lib/powerpc-linux-gnu/libGL.so.1.2.0)
==21922==by 0xFDC1303: glXChooseVisual (in 
/usr/lib/powerpc-linux-gnu/libGL.so.1.2.0)
==21922==b

Re: [Mesa-dev] [PATCH 1/8] st/va: remove nonesense HEVC picture id handling

[Julien Isorce]

Hi, shouldn't the check be the following condition instead:
hevc->ReferenceFrames[i].flags & VA_PICTURE_HEVC_INVALID ||
hevc->ReferenceFrames[i].picture_id == VA_INVALID_SURFACE
?

On 11 December 2015 at 12:33, Christian König 
wrote:

> From: Christian König 
>
> The picture id in this case is a VA-API surface handle, checking
> for a certain value can't be correct.
>
> Signed-off-by: Christian König 
> ---
>  src/gallium/state_trackers/va/picture_hevc.c | 5 -
>  1 file changed, 5 deletions(-)
>
> diff --git a/src/gallium/state_trackers/va/picture_hevc.c
> b/src/gallium/state_trackers/va/picture_hevc.c
> index dc66b0f..28743ee 100644
> --- a/src/gallium/state_trackers/va/picture_hevc.c
> +++ b/src/gallium/state_trackers/va/picture_hevc.c
> @@ -159,11 +159,6 @@ void vlVaHandlePictureParameterBufferHEVC(vlVaDriver
> *drv, vlVaContext *context,
> for (i = 0 ; i < 15 ; i++) {
>context->desc.h265.PicOrderCntVal[i] =
> hevc->ReferenceFrames[i].pic_order_cnt;
>
> -  unsigned int index = hevc->ReferenceFrames[i].picture_id & 0x7F;
> -
> -  if (index == 0x7F)
> - continue;
> -
>vlVaGetReferenceFrame(drv, hevc->ReferenceFrames[i].picture_id,
> &context->desc.h265.ref[i]);
>
>if ((hevc->ReferenceFrames[i].flags &
> VA_PICTURE_HEVC_RPS_ST_CURR_BEFORE) && (iBefore < 8)) {
> --
> 2.5.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] gallium r300 driver for PowerPC

[Eero Tamminen]

Hi,

On 12/14/2015 10:44 AM, Herminio Hernandez, Jr. wrote:

I am new to this list. I have been trying to see if I can fix or at least pin 
point an issue with Radeon r300 driver failing on PowerPC systems. This has 
been a problem for a while and I would like to help to get this fixed. I have 
done some debugging with valgrind and I think I may see where the issue is but 
I would to have someone double check what I am doing. So when I set my Default 
Depth to 16 I do get 3D acceleration but when I set to the default of 24 it 
breaks. Valgrind reports memory leaks when I run glxgears with a Default Depth 
of 24 but shows no definite memory leaks with a Depth of 16. I then got the 
source code and created a dev environment andnran glxgears through valgrind 
with my default depth of 24 and saw similar memory leaks. Here is a sample of 
what I am seeing.

==25273== 108 (12 direct, 96 indirect) bytes in 1 blocks are definitely lost in 
loss record 54 of 78
==25273==at 0xFFB2868: malloc (vg_replace_malloc.c:299)
==25273==by 0xED0457B: ???
==25273==by 0xEEC6F3B: ???
==25273==by 0xE95A78B: ???
==25273==by 0xED7DF7F: ???
==25273==by 0xED7D5DB: ???
==25273==by 0xEC5B377: ???
==25273==by 0xEC567EB: ???
==25273==by 0xFDEDFD3: dri2CreateScreen (dri2_glx.c:1235)
==25273==by 0xFDB866F: AllocAndFetchScreenConfigs (glxext.c:799)
==25273==by 0xFDB866F: __glXInitialize (glxext.c:910)
==25273==by 0xFDB36F3: GetGLXPrivScreenConfig.part.2 (glxcmds.c:172)
==25273==by 0xFDB396B: GetGLXPrivScreenConfig (glxcmds.c:168)
==25273==by 0xFDB396B: glXChooseVisual (glxcmds.c:1249)

It looks like the files in the src/glx branch is where the issue is. I am 
attaching the summary portion of the output I got from valgrind. Am I heading 
in the right direction?


Install debug symbols for the libraries that Valgrind is complaining 
about, to see what actually leaks.  Because they all come from through 
GetGLXPrivScreenConfig(), I think this is something (inconsequential) in 
your X libraries, not Mesa.


If you want to track run time memory leaks, quit the program with a 
signal that the application doesn't catch, but which Valgrind can catch 
(e.g. SIGHUP could be such).  That way you avoid seeing memory leaks 
that happen only when the application quits normally (those are also 
good to fix, but not relevant for run-time memory usage).



- Eero

PS.  Do have you libdrm version that is compiled with Valgrind support?

(If not, Valgrind gives bogus errors because it doesn't know where gfx 
memory comes from & what memory areas are valid to access.)


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

Re: [Mesa-dev] [Intel-gfx] [RFC libdrm] intel: Add support for softpin

[Daniel Vetter]

On Mon, Dec 14, 2015 at 08:41:05AM +, Song, Ruiling wrote:
> 
> 
> > -Original Message-
> > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> > Vetter
> > Sent: Monday, December 14, 2015 4:28 PM
> > To: Song, Ruiling 
> > Cc: k...@bitplanet.net; Winiarski, Michal ;
> > mesa-dev@lists.freedesktop.org; intel-...@lists.freedesktop.org; Ben
> > Widawsky ; dri-de...@lists.freedesktop.org
> > Subject: Re: [Intel-gfx] [RFC libdrm] intel: Add support for softpin
> > 
> > On Mon, Dec 14, 2015 at 07:24:29AM +, Song, Ruiling wrote:
> > >
> > >
> > > > -Original Message-
> > > > From: hoegsb...@gmail.com [mailto:hoegsb...@gmail.com] On Behalf
> > Of
> > > > Kristian H?gsberg
> > > > Sent: Monday, December 14, 2015 1:34 PM
> > > > To: Song, Ruiling 
> > > > Cc: Winiarski, Michal ; intel-
> > > > g...@lists.freedesktop.org; mesa-dev@lists.freedesktop.org; Ben
> > Widawsky
> > > > ; dri-de...@lists.freedesktop.org
> > > > Subject: Re: [Intel-gfx] [RFC libdrm] intel: Add support for softpin
> > > >
> > > > On Sun, Dec 13, 2015 at 7:17 PM, Song, Ruiling 
> > > > wrote:
> > > > >> -Original Message-
> > > > >> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On
> > > > Behalf
> > > > >> Of Micha? Winiarski
> > > > >> Sent: Wednesday, September 9, 2015 10:07 PM
> > > > >> To: intel-...@lists.freedesktop.org
> > > > >> Cc: Ben Widawsky ; dri-
> > > > de...@lists.freedesktop.org;
> > > > >> mesa-dev@lists.freedesktop.org
> > > > >> Subject: [Intel-gfx] [RFC libdrm] intel: Add support for softpin
> > > > >>
> > > > >> Softpin allows userspace to take greater control of GPU virtual 
> > > > >> address
> > > > >> space and eliminates the need of relocations. It can also be used to
> > > > >> mirror addresses between GPU and CPU (shared virtual memory).
> > > > >> Calls to drm_intel_bo_emit_reloc are still required to build the 
> > > > >> list of
> > > > >> drm_i915_gem_exec_objects at exec time, but no entries in relocs are
> > > > >> created. Self-relocs don't make any sense for softpinned objects and
> > can
> > > > >> indicate a programming errors, thus are forbidden. Softpinned objects
> > > > >> are marked by asterisk in debug dumps.
> > > > >>
> > > > >> Cc: Thomas Daniel 
> > > > >> Cc: Kristian Høgsberg 
> > > > >> Cc: Zou Nanhai 
> > > > >> Cc: Michel Thierry 
> > > > >> Cc: Ben Widawsky 
> > > > >> Cc: Chris Wilson 
> > > > >> Signed-off-by: Michał Winiarski 
> > > > >> ---
> > > > >>  include/drm/i915_drm.h|   4 +-
> > > > >>  intel/intel_bufmgr.c  |   9 +++
> > > > >>  intel/intel_bufmgr.h  |   1 +
> > > > >>  intel/intel_bufmgr_gem.c  | 176
> > > > >> --
> > > > >>  intel/intel_bufmgr_priv.h |   7 ++
> > > > >>  5 files changed, 173 insertions(+), 24 deletions(-)
> > > > >
> > > > > Will anybody help to push the patch to libdrm? Beignet highly depend
> > on
> > > > this to implement ocl2.0 svm.
> > > >
> > > > Is the kernel patch upstream?
> > >
> > > Yes, the kernel patch already merged, see:
> > > http://cgit.freedesktop.org/drm-
> > intel/commit/?id=506a8e87d8d2746b9e9d2433503fe237c54e4750
> > >
> > > I find below line of code in libdrm does not match the kernel version. The
> > kernel patch defined as:
> > > "#define EXEC_OBJECT_PINNED (1<<4)", but this patch defined it as (1<<3).
> > 
> > Please always regenerate the entire headers from the kernel sources using
> > 
> > $ make headers_install
> > 
> > Then copy the headers from the kernel's usr/include/drm to libdrm. Never
> > patch i915_drm.h manually.
> 
> Thanks for the info. But the problem is libdrm still tracks such kind of 
> header files.
> Should this kind of header file be removed from libdrm? Or any document in 
> libdrm to make this explicit?

All other kernel headers are extracted from the kernel directly, but
generally those packages only get update when a new kernel comes out.
Usually it's called linux-headers or similar. And only updating headers
when the release is out is _way_ too slow for drm/gfx. That's why we have
drm headers in libdrm.

But yeah we should document this, maybe even script it. Perhaps even just
upgrade headers automatically as soon as the upstream drm-next branch
changes.
-Daniel

> 
> Thanks!
> Ruiling
>  
> > Thanks, Daniel
> > 
> > >
> > > Hello Michal,
> > >
> > > Could you help to rebase the patch against:
> > > [Intel-gfx] [PATCH libdrm v4 0/2] 48-bit virtual address support in   
> > > i915
> > > I think we need both 48bit & softpin in libdrm.
> > >
> > > diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
> > > index ded43b1..2b99fc6 100644
> > > --- a/include/drm/i915_drm.h
> > > +++ b/include/drm/i915_drm.h
> > > @@ -350,6 +350,7 @@ typedef struct drm_i915_irq_wait {
> > >  #define I915_PARAM_REVISION  32
> > >  #define I915_PARAM_SUBSLICE_TOTAL 33
> > >  #define I915_PARAM_EU_TOTAL   34
> > > +#define I915_PARAM_HAS_EXEC_SOFTPIN   37
> > >

Re: [Mesa-dev] [PATCH 6/8] st/va: remove fence handling

[Julien Isorce]

Hi Christian,

I have tested this patch but then the displayed video is garbage (mostly
white and sometimes just garbage). It also stall the nouveau driver which
requires to reboot but I guess this is another issue.
I tested with:
GST_GL_WINDOW=x11 GST_GL_PLATFORM=egl GST_GL_API=gles2 GST_DEBUG=2
LIBVA_DRIVER_NAME=gallium gst-launch-1.0 filesrc location=simpson.mp4 !
qtdemux ! vaapidecodebin ! glimagesink

(to test that you need my gstreamer-vaapi and gstgl branches on my github
but I would not waste time to try them since they should be merged upstream
at some point)

Also note that in this pipeline, HW decoding is done with nouveau driver
and rendering is done with intel. dmabuf in between.

Maybe the idea of the patch is good but something is still wrong.
I can test any update if it helps.

Cheers
Julien




On 11 December 2015 at 12:33, Christian König 
wrote:

> From: Christian König 
>
> It's nonsense to drain the pipeline like this.
>
> Signed-off-by: Christian König 
> ---
>  src/gallium/state_trackers/va/buffer.c |  5 -
>  src/gallium/state_trackers/va/image.c  |  1 -
>  src/gallium/state_trackers/va/postproc.c   |  6 --
>  src/gallium/state_trackers/va/surface.c| 10 +-
>  src/gallium/state_trackers/va/va_private.h |  2 --
>  5 files changed, 1 insertion(+), 23 deletions(-)
>
> diff --git a/src/gallium/state_trackers/va/buffer.c
> b/src/gallium/state_trackers/va/buffer.c
> index 769305e..2ec187c 100644
> --- a/src/gallium/state_trackers/va/buffer.c
> +++ b/src/gallium/state_trackers/va/buffer.c
> @@ -257,11 +257,6 @@ vlVaAcquireBufferHandle(VADriverContextP ctx,
> VABufferID buf_id,
>
> screen = VL_VA_PSCREEN(ctx);
>
> -   if (buf->derived_surface.fence) {
> -  screen->fence_finish(screen, buf->derived_surface.fence,
> PIPE_TIMEOUT_INFINITE);
> -  screen->fence_reference(screen, &buf->derived_surface.fence, NULL);
> -   }
> -
> if (buf->export_refcount > 0) {
>if (buf->export_state.mem_type != mem_type)
>   return VA_STATUS_ERROR_INVALID_PARAMETER;
> diff --git a/src/gallium/state_trackers/va/image.c
> b/src/gallium/state_trackers/va/image.c
> index ae07da8..58c9ff7 100644
> --- a/src/gallium/state_trackers/va/image.c
> +++ b/src/gallium/state_trackers/va/image.c
> @@ -266,7 +266,6 @@ vlVaDeriveImage(VADriverContextP ctx, VASurfaceID
> surface, VAImage *image)
> img_buf->type = VAImageBufferType;
> img_buf->size = image->data_size;
> img_buf->num_elements = 1;
> -   img_buf->derived_surface.fence = surf->fence;
>
> pipe_resource_reference(&img_buf->derived_surface.resource,
> surfaces[0]->texture);
>
> diff --git a/src/gallium/state_trackers/va/postproc.c
> b/src/gallium/state_trackers/va/postproc.c
> index 105f251..1ee3587 100644
> --- a/src/gallium/state_trackers/va/postproc.c
> +++ b/src/gallium/state_trackers/va/postproc.c
> @@ -54,7 +54,6 @@ vlVaHandleVAProcPipelineParameterBufferType(vlVaDriver
> *drv, vlVaContext *contex
> vlVaSurface *src_surface;
> VAProcPipelineParameterBuffer *pipeline_param;
> struct pipe_surface **surfaces;
> -   struct pipe_screen *screen;
> struct pipe_surface *psurf;
>
> if (!drv || !context)
> @@ -77,8 +76,6 @@ vlVaHandleVAProcPipelineParameterBufferType(vlVaDriver
> *drv, vlVaContext *contex
> if (!surfaces || !surfaces[0])
>return VA_STATUS_ERROR_INVALID_SURFACE;
>
> -   screen = drv->pipe->screen;
> -
> psurf = surfaces[0];
>
> src_region = vlVaRegionDefault(pipeline_param->surface_region,
> src_surface->buffer, &def_src_region);
> @@ -99,9 +96,6 @@ vlVaHandleVAProcPipelineParameterBufferType(vlVaDriver
> *drv, vlVaContext *contex
> vl_compositor_set_layer_dst_area(&drv->cstate, 0, &dst_rect);
> vl_compositor_render(&drv->cstate, &drv->compositor, psurf, NULL,
> false);
>
> -   screen->fence_reference(screen, &src_surface->fence, NULL);
> -   drv->pipe->flush(drv->pipe, &src_surface->fence, 0);
> -
> return VA_STATUS_SUCCESS;
>  }
>
> diff --git a/src/gallium/state_trackers/va/surface.c
> b/src/gallium/state_trackers/va/surface.c
> index 4a18a6f..5ddaf04 100644
> --- a/src/gallium/state_trackers/va/surface.c
> +++ b/src/gallium/state_trackers/va/surface.c
> @@ -72,8 +72,6 @@ vlVaDestroySurfaces(VADriverContextP ctx, VASurfaceID
> *surface_list, int num_sur
>vlVaSurface *surf = handle_table_get(drv->htab, surface_list[i]);
>if (surf->buffer)
>   surf->buffer->destroy(surf->buffer);
> -  if(surf->fence)
> - drv->pipe->screen->fence_reference(drv->pipe->screen,
> &surf->fence, NULL);
>util_dynarray_fini(&surf->subpics);
>FREE(surf);
>handle_table_remove(drv->htab, surface_list[i]);
> @@ -245,11 +243,6 @@ vlVaPutSurface(VADriverContextP ctx, VASurfaceID
> surface_id, void* draw, short s
> screen = drv->pipe->screen;
> vscreen = drv->vscreen;
>
> -   if(surf->fence) {
> -  screen->fence_finish(screen, surf->fence, PIPE_TIMEOUT_INFINITE);
> -  screen->fence_reference

Re: [Mesa-dev] [PATCH 3/8] st/va: clean up post process includes

[Julien Isorce]

This patch is:
Reviewed-by: Julien Isorce 
Tested-by: Julien Isorce 

On 11 December 2015 at 12:33, Christian König 
wrote:

> From: Christian König 
>
> Signed-off-by: Christian König 
> ---
>  src/gallium/state_trackers/va/postproc.c | 6 --
>  1 file changed, 6 deletions(-)
>
> diff --git a/src/gallium/state_trackers/va/postproc.c
> b/src/gallium/state_trackers/va/postproc.c
> index 1fdb4e7..2d17694 100644
> --- a/src/gallium/state_trackers/va/postproc.c
> +++ b/src/gallium/state_trackers/va/postproc.c
> @@ -25,13 +25,7 @@
>   *
>
> **/
>
> -//#include "pipe/p_video_codec.h"
> -
>  #include "util/u_handle_table.h"
> -//#include "util/u_video.h"
> -
> -//#include "vl/vl_vlc.h"
> -//#include "vl/vl_winsys.h"
>
>  #include "va_private.h"
>
> --
> 2.5.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/8] st/va: cleanup filter color standard handling

[Julien Isorce]

This patch is:
Reviewed-by: Julien Isorce 
Tested-by: ulien Isorce 

On 11 December 2015 at 12:33, Christian König 
wrote:

> From: Christian König 
>
> Signed-off-by: Christian König 
> ---
>  src/gallium/state_trackers/va/surface.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/src/gallium/state_trackers/va/surface.c
> b/src/gallium/state_trackers/va/surface.c
> index c052c8f..4a18a6f 100644
> --- a/src/gallium/state_trackers/va/surface.c
> +++ b/src/gallium/state_trackers/va/surface.c
> @@ -697,11 +697,11 @@ vlVaQueryVideoProcFilterCaps(VADriverContextP ctx,
> VAContextID context,
> return VA_STATUS_SUCCESS;
>  }
>
> -static VAProcColorStandardType
> vpp_input_color_standards[VAProcColorStandardCount] = {
> +static VAProcColorStandardType vpp_input_color_standards[] = {
> VAProcColorStandardBT601
>  };
>
> -static VAProcColorStandardType
> vpp_output_color_standards[VAProcColorStandardCount] = {
> +static VAProcColorStandardType vpp_output_color_standards[] = {
> VAProcColorStandardBT601
>  };
>
> @@ -725,9 +725,9 @@ vlVaQueryVideoProcPipelineCaps(VADriverContextP ctx,
> VAContextID context,
> pipeline_cap->filter_flags = 0;
> pipeline_cap->num_forward_references = 0;
> pipeline_cap->num_backward_references = 0;
> -   pipeline_cap->num_input_color_standards = 1;
> +   pipeline_cap->num_input_color_standards =
> Elements(vpp_input_color_standards);
> pipeline_cap->input_color_standards = vpp_input_color_standards;
> -   pipeline_cap->num_output_color_standards = 1;
> +   pipeline_cap->num_output_color_standards =
> Elements(vpp_output_color_standards);
> pipeline_cap->output_color_standards = vpp_output_color_standards;
>
> for (i = 0; i < num_filters; i++) {
> --
> 2.5.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 4/8] st/va: fix unused variable warning

[Julien Isorce]

This patch is:
Reviewed-by: Julien Isorce 

On 11 December 2015 at 12:33, Christian König 
wrote:

> From: Christian König 
>
> Signed-off-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 8623139..7b30bf8 100644
> --- a/src/gallium/state_trackers/va/picture.c
> +++ b/src/gallium/state_trackers/va/picture.c
> @@ -92,7 +92,6 @@ vlVaGetReferenceFrame(vlVaDriver *drv, VASurfaceID
> surface_id,
>  static VAStatus
>  handlePictureParameterBuffer(vlVaDriver *drv, vlVaContext *context,
> vlVaBuffer *buf)
>  {
> -   unsigned int i;
> VAStatus vaStatus = VA_STATUS_SUCCESS;
>
> switch (u_reduce_video_profile(context->templat.profile)) {
> --
> 2.5.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 5/8] st/va: handle default post process regions

[Julien Isorce]

This patch is:
Reviewed-by: Julien Isorce 
Tested-by: Julien Isorce 

On 11 December 2015 at 12:33, Christian König 
wrote:

> From: Christian König 
>
> Avoid referencing NULL pointers.
>
> Signed-off-by: Christian König 
> ---
>  src/gallium/state_trackers/va/postproc.c | 36
> +---
>  1 file changed, 28 insertions(+), 8 deletions(-)
>
> diff --git a/src/gallium/state_trackers/va/postproc.c
> b/src/gallium/state_trackers/va/postproc.c
> index 2d17694..105f251 100644
> --- a/src/gallium/state_trackers/va/postproc.c
> +++ b/src/gallium/state_trackers/va/postproc.c
> @@ -29,9 +29,26 @@
>
>  #include "va_private.h"
>
> +static const VARectangle *
> +vlVaRegionDefault(const VARectangle *region, struct pipe_video_buffer
> *buf,
> + VARectangle *def)
> +{
> +   if (region)
> +  return region;
> +
> +   def->x = 0;
> +   def->y = 0;
> +   def->width = buf->width;
> +   def->height = buf->height;
> +
> +   return def;
> +}
> +
>  VAStatus
>  vlVaHandleVAProcPipelineParameterBufferType(vlVaDriver *drv, vlVaContext
> *context, vlVaBuffer *buf)
>  {
> +   VARectangle def_src_region, def_dst_region;
> +   const VARectangle *src_region, *dst_region;
> struct u_rect src_rect;
> struct u_rect dst_rect;
> vlVaSurface *src_surface;
> @@ -64,15 +81,18 @@ vlVaHandleVAProcPipelineParameterBufferType(vlVaDriver
> *drv, vlVaContext *contex
>
> psurf = surfaces[0];
>
> -   src_rect.x0 = pipeline_param->surface_region->x;
> -   src_rect.y0 = pipeline_param->surface_region->y;
> -   src_rect.x1 = pipeline_param->surface_region->x +
> pipeline_param->surface_region->width;
> -   src_rect.y1 = pipeline_param->surface_region->y +
> pipeline_param->surface_region->height;
> +   src_region = vlVaRegionDefault(pipeline_param->surface_region,
> src_surface->buffer, &def_src_region);
> +   dst_region = vlVaRegionDefault(pipeline_param->output_region,
> context->target, &def_dst_region);
> +
> +   src_rect.x0 = src_region->x;
> +   src_rect.y0 = src_region->y;
> +   src_rect.x1 = src_region->x + src_region->width;
> +   src_rect.y1 = src_region->y + src_region->height;
>
> -   dst_rect.x0 = pipeline_param->output_region->x;
> -   dst_rect.y0 = pipeline_param->output_region->y;
> -   dst_rect.x1 = pipeline_param->output_region->x +
> pipeline_param->output_region->width;
> -   dst_rect.y1 = pipeline_param->output_region->y +
> pipeline_param->output_region->height;
> +   dst_rect.x0 = dst_region->x;
> +   dst_rect.y0 = dst_region->y;
> +   dst_rect.x1 = dst_region->x + dst_region->width;
> +   dst_rect.y1 = dst_region->y + dst_region->height;
>
> vl_compositor_clear_layers(&drv->cstate);
> vl_compositor_set_buffer_layer(&drv->cstate, &drv->compositor, 0,
> src_surface->buffer, &src_rect, NULL, VL_COMPOSITOR_WEAVE);
> --
> 2.5.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 7/8] st/va: add NV12 -> NV12 post processing

[Julien Isorce]

This patch is:
Reviewed-by: Julien Isorce 
Tested-by: Julien Isorce 

On 11 December 2015 at 12:33, Christian König 
wrote:

> From: Christian König 
>
> Usefull for mpv and GStreamer.
>
> Signed-off-by: Indrajit-kumar Das 
> Signed-off-by: Christian König 
> ---
>  src/gallium/state_trackers/va/picture.c  |  10 +-
>  src/gallium/state_trackers/va/postproc.c | 152
> ---
>  2 files changed, 125 insertions(+), 37 deletions(-)
>
> diff --git a/src/gallium/state_trackers/va/picture.c
> b/src/gallium/state_trackers/va/picture.c
> index 7b30bf8..b5e1ebc 100644
> --- a/src/gallium/state_trackers/va/picture.c
> +++ b/src/gallium/state_trackers/va/picture.c
> @@ -63,11 +63,11 @@ vlVaBeginPicture(VADriverContextP ctx, VAContextID
> context_id, VASurfaceID rende
> if (!context->decoder) {
>/* VPP */
>if (context->templat.profile == PIPE_VIDEO_PROFILE_UNKNOWN &&
> - ((context->target->buffer_format != PIPE_FORMAT_B8G8R8A8_UNORM
> &&
> -   context->target->buffer_format != PIPE_FORMAT_R8G8B8A8_UNORM
> &&
> -   context->target->buffer_format != PIPE_FORMAT_B8G8R8X8_UNORM
> &&
> -   context->target->buffer_format != PIPE_FORMAT_R8G8B8X8_UNORM)
> ||
> -   context->target->interlaced))
> +  context->target->buffer_format != PIPE_FORMAT_B8G8R8A8_UNORM &&
> +  context->target->buffer_format != PIPE_FORMAT_R8G8B8A8_UNORM &&
> +  context->target->buffer_format != PIPE_FORMAT_B8G8R8X8_UNORM &&
> +  context->target->buffer_format != PIPE_FORMAT_R8G8B8X8_UNORM &&
> +  context->target->buffer_format != PIPE_FORMAT_NV12)
>   return VA_STATUS_ERROR_UNIMPLEMENTED;
>
>return VA_STATUS_SUCCESS;
> diff --git a/src/gallium/state_trackers/va/postproc.c
> b/src/gallium/state_trackers/va/postproc.c
> index 1ee3587..c6cfd3a 100644
> --- a/src/gallium/state_trackers/va/postproc.c
> +++ b/src/gallium/state_trackers/va/postproc.c
> @@ -27,6 +27,8 @@
>
>  #include "util/u_handle_table.h"
>
> +#include "vl/vl_defines.h"
> +
>  #include "va_private.h"
>
>  static const VARectangle *
> @@ -44,43 +46,21 @@ vlVaRegionDefault(const VARectangle *region, struct
> pipe_video_buffer *buf,
> return def;
>  }
>
> -VAStatus
> -vlVaHandleVAProcPipelineParameterBufferType(vlVaDriver *drv, vlVaContext
> *context, vlVaBuffer *buf)
> +static VAStatus
> +vlVaPostProcCompositor(vlVaDriver *drv, vlVaContext *context,
> +   const VARectangle *src_region,
> +   const VARectangle *dst_region,
> +   struct pipe_video_buffer *src,
> +   struct pipe_video_buffer *dst)
>  {
> -   VARectangle def_src_region, def_dst_region;
> -   const VARectangle *src_region, *dst_region;
> +   struct pipe_surface **surfaces;
> struct u_rect src_rect;
> struct u_rect dst_rect;
> -   vlVaSurface *src_surface;
> -   VAProcPipelineParameterBuffer *pipeline_param;
> -   struct pipe_surface **surfaces;
> -   struct pipe_surface *psurf;
> -
> -   if (!drv || !context)
> -  return VA_STATUS_ERROR_INVALID_CONTEXT;
> -
> -   if (!buf || !buf->data)
> -  return VA_STATUS_ERROR_INVALID_BUFFER;
> -
> -   if (!context->target)
> -  return VA_STATUS_ERROR_INVALID_SURFACE;
> -
> -   pipeline_param = (VAProcPipelineParameterBuffer *)buf->data;
> -
> -   src_surface = handle_table_get(drv->htab, pipeline_param->surface);
> -   if (!src_surface || !src_surface->buffer)
> -  return VA_STATUS_ERROR_INVALID_SURFACE;
> -
> -   surfaces = context->target->get_surfaces(context->target);
>
> +   surfaces = dst->get_surfaces(dst);
> if (!surfaces || !surfaces[0])
>return VA_STATUS_ERROR_INVALID_SURFACE;
>
> -   psurf = surfaces[0];
> -
> -   src_region = vlVaRegionDefault(pipeline_param->surface_region,
> src_surface->buffer, &def_src_region);
> -   dst_region = vlVaRegionDefault(pipeline_param->output_region,
> context->target, &def_dst_region);
> -
> src_rect.x0 = src_region->x;
> src_rect.y0 = src_region->y;
> src_rect.x1 = src_region->x + src_region->width;
> @@ -92,11 +72,119 @@
> vlVaHandleVAProcPipelineParameterBufferType(vlVaDriver *drv, vlVaContext
> *contex
> dst_rect.y1 = dst_region->y + dst_region->height;
>
> vl_compositor_clear_layers(&drv->cstate);
> -   vl_compositor_set_buffer_layer(&drv->cstate, &drv->compositor, 0,
> src_surface->buffer, &src_rect, NULL, VL_COMPOSITOR_WEAVE);
> +   vl_compositor_set_buffer_layer(&drv->cstate, &drv->compositor, 0, src,
> + &src_rect, NULL, VL_COMPOSITOR_WEAVE);
> vl_compositor_set_layer_dst_area(&drv->cstate, 0, &dst_rect);
> -   vl_compositor_render(&drv->cstate, &drv->compositor, psurf, NULL,
> false);
> +   vl_compositor_render(&drv->cstate, &drv->compositor, surfaces[0],
> NULL, false);
> +
> +   return VA_STATUS_SUCCESS;
> +}
> +
> +static void vlVaBoxAdjust(struct pipe_video_buffer *buf, unsigned idx,
> +  struct pipe_bo

Re: [Mesa-dev] [PATCH 8/8] st/va: add BOB/WEAVE deinterlacing

[Julien Isorce]

This patch is:
Reviewed-by: Julien Isorce 
Tested-by: Julien Isorce 

(tested with gstvaapipostproc from gstreamer-vaapi)

On 11 December 2015 at 12:33, Christian König 
wrote:

> From: Christian König 
>
> Tested with MPV.
>
> Signed-off-by: Christian König 
> ---
>  src/gallium/state_trackers/va/postproc.c | 72
> 
>  src/gallium/state_trackers/va/surface.c  | 16 ++-
>  2 files changed, 78 insertions(+), 10 deletions(-)
>
> diff --git a/src/gallium/state_trackers/va/postproc.c
> b/src/gallium/state_trackers/va/postproc.c
> index c6cfd3a..bcac66a 100644
> --- a/src/gallium/state_trackers/va/postproc.c
> +++ b/src/gallium/state_trackers/va/postproc.c
> @@ -51,7 +51,8 @@ vlVaPostProcCompositor(vlVaDriver *drv, vlVaContext
> *context,
> const VARectangle *src_region,
> const VARectangle *dst_region,
> struct pipe_video_buffer *src,
> -   struct pipe_video_buffer *dst)
> +   struct pipe_video_buffer *dst,
> +   enum vl_compositor_deinterlace deinterlace)
>  {
> struct pipe_surface **surfaces;
> struct u_rect src_rect;
> @@ -100,7 +101,8 @@ static VAStatus vlVaPostProcBlit(vlVaDriver *drv,
> vlVaContext *context,
>   const VARectangle *src_region,
>   const VARectangle *dst_region,
>   struct pipe_video_buffer *src,
> - struct pipe_video_buffer *dst)
> + struct pipe_video_buffer *dst,
> + enum vl_compositor_deinterlace
> deinterlace)
>  {
> struct pipe_surface **src_surfaces;
> struct pipe_surface **dst_surfaces;
> @@ -118,18 +120,33 @@ static VAStatus vlVaPostProcBlit(vlVaDriver *drv,
> vlVaContext *context,
>return VA_STATUS_ERROR_INVALID_SURFACE;
>
> for (i = 0; i < VL_MAX_SURFACES; ++i) {
> +  struct pipe_surface *from = src_surfaces[i];
>struct pipe_blit_info blit;
>
> -  if (!src_surfaces[i] || !dst_surfaces[i])
> +  if (src->interlaced) {
> + /* Not 100% accurate, but close enough */
> + switch (deinterlace) {
> + case VL_COMPOSITOR_BOB_TOP:
> +from = src_surfaces[i & ~1];
> +break;
> + case VL_COMPOSITOR_BOB_BOTTOM:
> +from = src_surfaces[(i & ~1) + 1];
> +break;
> + default:
> +break;
> + }
> +  }
> +
> +  if (!from || !dst_surfaces[i])
>   continue;
>
>memset(&blit, 0, sizeof(blit));
> -  blit.src.resource = src_surfaces[i]->texture;
> -  blit.src.format = src_surfaces[i]->format;
> +  blit.src.resource = from->texture;
> +  blit.src.format = from->format;
>blit.src.level = 0;
>blit.src.box.x = src_region->x;
>blit.src.box.y = src_region->y;
> -  blit.src.box.z = src_surfaces[i]->u.tex.first_layer;
> +  blit.src.box.z = from->u.tex.first_layer;
>blit.src.box.width = src_region->width;
>blit.src.box.height = src_region->height;
>blit.src.box.depth = 1;
> @@ -158,10 +175,12 @@ static VAStatus vlVaPostProcBlit(vlVaDriver *drv,
> vlVaContext *context,
>  VAStatus
>  vlVaHandleVAProcPipelineParameterBufferType(vlVaDriver *drv, vlVaContext
> *context, vlVaBuffer *buf)
>  {
> +   enum vl_compositor_deinterlace deinterlace = VL_COMPOSITOR_WEAVE;
> VARectangle def_src_region, def_dst_region;
> const VARectangle *src_region, *dst_region;
> VAProcPipelineParameterBuffer *param;
> vlVaSurface *src_surface;
> +   unsigned i;
>
> if (!drv || !context)
>return VA_STATUS_ERROR_INVALID_CONTEXT;
> @@ -178,13 +197,50 @@
> vlVaHandleVAProcPipelineParameterBufferType(vlVaDriver *drv, vlVaContext
> *contex
> if (!src_surface || !src_surface->buffer)
>return VA_STATUS_ERROR_INVALID_SURFACE;
>
> +   for (i = 0; i < param->num_filters; i++) {
> +  vlVaBuffer *buf = handle_table_get(drv->htab, param->filters[i]);
> +  VAProcFilterParameterBufferBase *filter;
> +
> +  if (!buf || buf->type != VAProcFilterParameterBufferType)
> + return VA_STATUS_ERROR_INVALID_BUFFER;
> +
> +  filter = buf->data;
> +  switch (filter->type) {
> +  case VAProcFilterDeinterlacing: {
> + VAProcFilterParameterBufferDeinterlacing *deint = buf->data;
> + switch (deint->algorithm) {
> + case VAProcDeinterlacingBob:
> +if (deint->flags & VA_DEINTERLACING_BOTTOM_FIELD)
> +   deinterlace = VL_COMPOSITOR_BOB_BOTTOM;
> +else
> +   deinterlace = VL_COMPOSITOR_BOB_TOP;
> +break;
> +
> + case VAProcDeinterlacingWeave:
> +deinterlace = VL_COMPOSITOR_WEAVE;
> +break;
> +
> + default:
> +return VA_STATUS_ERROR_UNIMPLEMENTED;
> + }
> +
> + break

Re: [Mesa-dev] [PATCH v2 11/13] i965: Add tessellation evaluation shaders

[Jordan Justen]

Whew... I probably would have split this one into 5 or so. Then krh
would have grumbled at me. ;)

On 2015-12-11 13:24:00, Kenneth Graunke wrote:
> The TES is essentially a post-tessellator VS, which has access to the
> entire TCS output patch, and a special gl_TessCoord input.  Otherwise,
> they're very straightforward.
> 
> This patch implements SIMD8 tessellation evaluation shaders for Gen8+.
> The tessellator can generate a lot of geometry, so operating in SIMD8
> mode (8 vertices per thread) is more efficient than SIMD4x2 mode (only
> 2 vertices per thread).  I have another patch which implements SIMD4x2
> mode for older hardware (or via an environment variable override).
> 
> We currently handle all inputs via the pull model.
> 
> Signed-off-by: Kenneth Graunke 
> ---
>  src/mesa/drivers/dri/i965/Makefile.sources   |   1 +
>  src/mesa/drivers/dri/i965/brw_compiler.h |  24 +++
>  src/mesa/drivers/dri/i965/brw_context.h  |   6 +
>  src/mesa/drivers/dri/i965/brw_fs.cpp |  48 +
>  src/mesa/drivers/dri/i965/brw_fs.h   |  10 +-
>  src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 121 +++
>  src/mesa/drivers/dri/i965/brw_fs_visitor.cpp |  12 +-
>  src/mesa/drivers/dri/i965/brw_link.cpp   |   4 +
>  src/mesa/drivers/dri/i965/brw_program.h  |   2 +
>  src/mesa/drivers/dri/i965/brw_shader.cpp |  94 +
>  src/mesa/drivers/dri/i965/brw_shader.h   |   3 +
>  src/mesa/drivers/dri/i965/brw_state_upload.c |   3 +
>  src/mesa/drivers/dri/i965/brw_tes.c  | 300 
> +++
>  13 files changed, 625 insertions(+), 3 deletions(-)
>  create mode 100644 src/mesa/drivers/dri/i965/brw_tes.c
> 
> diff --git a/src/mesa/drivers/dri/i965/Makefile.sources 
> b/src/mesa/drivers/dri/i965/Makefile.sources
> index d147a73..7354aaf 100644
> --- a/src/mesa/drivers/dri/i965/Makefile.sources
> +++ b/src/mesa/drivers/dri/i965/Makefile.sources
> @@ -151,6 +151,7 @@ i965_FILES = \
> brw_state_upload.c \
> brw_structs.h \
> brw_tcs_surface_state.c \
> +   brw_tes.c \
> brw_tes_surface_state.c \
> brw_tex.c \
> brw_tex_layout.c \
> diff --git a/src/mesa/drivers/dri/i965/brw_compiler.h 
> b/src/mesa/drivers/dri/i965/brw_compiler.h
> index c9e0317..64d831d 100644
> --- a/src/mesa/drivers/dri/i965/brw_compiler.h
> +++ b/src/mesa/drivers/dri/i965/brw_compiler.h
> @@ -191,6 +191,14 @@ struct brw_vs_prog_key {
> struct brw_sampler_prog_key_data tex;
>  };
>  
> +/** The program key for Tessellation Evaluation Shaders. */
> +struct brw_tes_prog_key
> +{
> +   unsigned program_string_id;
> +
> +   struct brw_sampler_prog_key_data tex;
> +};
> +
>  /** The program key for Geometry Shaders. */
>  struct brw_gs_prog_key
>  {
> @@ -669,6 +677,22 @@ brw_compile_vs(const struct brw_compiler *compiler, void 
> *log_data,
> char **error_str);
>  
>  /**
> + * Compile a tessellation evaluation shader.
> + *
> + * Returns the final assembly and the program's size.
> + */
> +const unsigned *
> +brw_compile_tes(const struct brw_compiler *compiler, void *log_data,
> +void *mem_ctx,
> +const struct brw_tes_prog_key *key,
> +struct brw_tes_prog_data *prog_data,
> +const struct nir_shader *shader,
> +struct gl_shader_program *shader_prog,
> +int shader_time_index,
> +unsigned *final_assembly_size,
> +char **error_str);
> +
> +/**
>   * Compile a vertex shader.
>   *
>   * Returns the final assembly and the program's size.
> diff --git a/src/mesa/drivers/dri/i965/brw_context.h 
> b/src/mesa/drivers/dri/i965/brw_context.h
> index 69bc04c..5e840d1 100644
> --- a/src/mesa/drivers/dri/i965/brw_context.h
> +++ b/src/mesa/drivers/dri/i965/brw_context.h
> @@ -1704,6 +1704,12 @@ brw_vertex_program_const(const struct 
> gl_vertex_program *p)
> return (const struct brw_vertex_program *) p;
>  }
>  
> +static inline struct brw_tess_eval_program *
> +brw_tess_eval_program(struct gl_tess_eval_program *p)
> +{
> +   return (struct brw_tess_eval_program *) p;
> +}
> +
>  static inline struct brw_geometry_program *
>  brw_geometry_program(struct gl_geometry_program *p)
>  {
> diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp 
> b/src/mesa/drivers/dri/i965/brw_fs.cpp
> index c833ef0..de584e4 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
> @@ -1686,6 +1686,21 @@ fs_visitor::assign_vs_urb_setup()
>  }
>  
>  void
> +fs_visitor::assign_tes_urb_setup()
> +{
> +   assert(stage == MESA_SHADER_TESS_EVAL);
> +
> +   brw_vue_prog_data *vue_prog_data = (brw_vue_prog_data *) prog_data;
> +
> +   first_non_payload_grf += 8 * vue_prog_data->urb_read_length;
> +
> +   /* Rewrite all ATTR file references to HW_REGs. */
> +   foreach_block_and_inst(block, fs_inst, inst, cfg) {
> +  convert_attr_sources_to_hw_regs(inst);
> +   }
> +}
> +
> +void
>  fs_visitor::assig

Re: [Mesa-dev] [PATCH 1/8] st/va: remove nonesense HEVC picture id handling

[Christian König]

Yeah, at least that looks sane, but I don't think just continuing with 
the loop is the right things to do here.


E.g. if we just continue h265.ref[i] will never be initialized to 
something. It's either NULL, a value from the last decode or some random 
data.


vlVaGetReferenceFrame() can handle VA_INVALID_SURFACE, so that isn't 
much of a problem. I'm just not sure what to do with 
VA_PICTURE_HEVC_INVALID.


Regards,
Christian.

On 14.12.2015 09:46, Julien Isorce wrote:

Hi, shouldn't the check be the following condition instead:
hevc->ReferenceFrames[i].flags & VA_PICTURE_HEVC_INVALID ||
hevc->ReferenceFrames[i].picture_id == VA_INVALID_SURFACE
?

On 11 December 2015 at 12:33, Christian König > wrote:


From: Christian König mailto:christian.koe...@amd.com>>

The picture id in this case is a VA-API surface handle, checking
for a certain value can't be correct.

Signed-off-by: Christian König mailto:christian.koe...@amd.com>>
---
 src/gallium/state_trackers/va/picture_hevc.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/src/gallium/state_trackers/va/picture_hevc.c
b/src/gallium/state_trackers/va/picture_hevc.c
index dc66b0f..28743ee 100644
--- a/src/gallium/state_trackers/va/picture_hevc.c
+++ b/src/gallium/state_trackers/va/picture_hevc.c
@@ -159,11 +159,6 @@ void
vlVaHandlePictureParameterBufferHEVC(vlVaDriver *drv, vlVaContext
*context,
for (i = 0 ; i < 15 ; i++) {
   context->desc.h265.PicOrderCntVal[i] =
hevc->ReferenceFrames[i].pic_order_cnt;

-  unsigned int index = hevc->ReferenceFrames[i].picture_id &
0x7F;
-
-  if (index == 0x7F)
- continue;
-
   vlVaGetReferenceFrame(drv,
hevc->ReferenceFrames[i].picture_id, &context->desc.h265.ref[i]);

   if ((hevc->ReferenceFrames[i].flags &
VA_PICTURE_HEVC_RPS_ST_CURR_BEFORE) && (iBefore < 8)) {
--
2.5.0

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




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

Re: [Mesa-dev] [PATCH v2 08/13] i965: Handle TCS outputs and TES inputs.

[Kenneth Graunke]

On Saturday, December 12, 2015 10:21:19 PM Jordan Justen wrote:
> On 2015-12-11 13:23:57, Kenneth Graunke wrote:
> > TCS outputs and TES inputs both refer to a common "patch URB entry"
> > shared across all invocations.  First, there are some number of
> > per-patch entries.  Then, there are per-vertex entries accessed via
> > an offset for the variable and a stride times the vertex index.
> > 
> > Because these calculations need to be done in both the vec4 and scalar
> > backends, it's simpler to just compute the offset calculations in NIR.
> > It doesn't necessarily make much sense to use per-vertex intrinsics
> > afterwards, but that at least means we don't lose the per-patch vs.
> > per-vertex information.
> > 
> > Signed-off-by: Kenneth Graunke 
> > ---
> >  src/mesa/drivers/dri/i965/brw_nir.c | 122 
> > +++-
> >  1 file changed, 120 insertions(+), 2 deletions(-)
> > 
> > diff --git a/src/mesa/drivers/dri/i965/brw_nir.c 
> > b/src/mesa/drivers/dri/i965/brw_nir.c
> > index 9cf4944..e46e177 100644
> > --- a/src/mesa/drivers/dri/i965/brw_nir.c
> > +++ b/src/mesa/drivers/dri/i965/brw_nir.c
> > @@ -133,6 +133,69 @@ remap_inputs_with_vue_map(nir_block *block, void 
> > *closure)
> > return true;
> >  }
> >  
> > +struct remap_patch_urb_offsets_state {
> > +   nir_builder b;
> > +   struct brw_vue_map vue_map;
> > +};
> > +
> > +static bool
> > +remap_patch_urb_offsets(nir_block *block, void *closure)
> > +{
> > +   struct remap_patch_urb_offsets_state *state = closure;
> > +
> > +   nir_foreach_instr_safe(block, instr) {
> > +  if (instr->type != nir_instr_type_intrinsic)
> > + continue;
> > +
> > +  nir_intrinsic_instr *intrin = nir_instr_as_intrinsic(instr);
> > +
> > +  bool is_input =
> > + intrin->intrinsic == nir_intrinsic_load_input ||
> > + intrin->intrinsic == nir_intrinsic_load_per_vertex_input;
> > +
> > +  bool is_output =
> > + intrin->intrinsic == nir_intrinsic_load_output ||
> > + intrin->intrinsic == nir_intrinsic_load_per_vertex_output ||
> > + intrin->intrinsic == nir_intrinsic_store_output ||
> > + intrin->intrinsic == nir_intrinsic_store_per_vertex_output;
> 
> Can you call the functions you added previously? (i965: Separate base
> offset/constant offset combining from remapping.)
> 
> 7 & 8 Reviewed-by: Jordan Justen 

Oh, good call - I wrote this patch first, even though it came later in
the series.  That makes a ton of sense.  I've changed it to:

+  gl_shader_stage stage = state->b.shader->stage;
+
+  if ((stage == MESA_SHADER_TESS_CTRL && is_output(intrin)) ||
+  (stage == MESA_SHADER_TESS_EVAL && is_input(intrin))) {


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

Re: [Mesa-dev] [PATCH 6/8] st/va: remove fence handling

[Christian König]

Also note that in this pipeline, HW decoding is done with nouveau 
driver and rendering is done with intel. dmabuf in between.
Yeah, I already thought that somebody is using it like this. I'm not 
sure if this is actually supposed to work because we don't have proper 
synchronization between kernel drivers with DMA-buf jet.



Maybe the idea of the patch is good but something is still wrong.
While it is not the proper solution I would say let's keep the pipeline 
draining during exporting the handle for now if that's really necessary 
for your use case. Please test the attached patch.


Coding the patch I've just noticed that there wasn't a pipe->flush() 
before exporting the handle. Does it work as well if you just flush the 
pipeline without waiting for the commands to be finished?


Regards,
Christian.

On 14.12.2015 10:14, Julien Isorce wrote:

Hi Christian,

I have tested this patch but then the displayed video is garbage 
(mostly white and sometimes just garbage). It also stall the nouveau 
driver which requires to reboot but I guess this is another issue.

I tested with:
GST_GL_WINDOW=x11 GST_GL_PLATFORM=egl GST_GL_API=gles2 GST_DEBUG=2 
LIBVA_DRIVER_NAME=gallium gst-launch-1.0 filesrc location=simpson.mp4 
! qtdemux ! vaapidecodebin ! glimagesink


(to test that you need my gstreamer-vaapi and gstgl branches on my 
github but I would not waste time to try them since they should be 
merged upstream at some point)


Also note that in this pipeline, HW decoding is done with nouveau 
driver and rendering is done with intel. dmabuf in between.


Maybe the idea of the patch is good but something is still wrong.
I can test any update if it helps.

Cheers
Julien




On 11 December 2015 at 12:33, Christian König > wrote:


From: Christian König mailto:christian.koe...@amd.com>>

It's nonsense to drain the pipeline like this.

Signed-off-by: Christian König mailto:christian.koe...@amd.com>>
---
 src/gallium/state_trackers/va/buffer.c |  5 -
 src/gallium/state_trackers/va/image.c  |  1 -
 src/gallium/state_trackers/va/postproc.c   |  6 --
 src/gallium/state_trackers/va/surface.c| 10 +-
 src/gallium/state_trackers/va/va_private.h |  2 --
 5 files changed, 1 insertion(+), 23 deletions(-)

diff --git a/src/gallium/state_trackers/va/buffer.c
b/src/gallium/state_trackers/va/buffer.c
index 769305e..2ec187c 100644
--- a/src/gallium/state_trackers/va/buffer.c
+++ b/src/gallium/state_trackers/va/buffer.c
@@ -257,11 +257,6 @@ vlVaAcquireBufferHandle(VADriverContextP ctx,
VABufferID buf_id,

screen = VL_VA_PSCREEN(ctx);

-   if (buf->derived_surface.fence) {
-  screen->fence_finish(screen, buf->derived_surface.fence,
PIPE_TIMEOUT_INFINITE);
-  screen->fence_reference(screen,
&buf->derived_surface.fence, NULL);
-   }
-
if (buf->export_refcount > 0) {
   if (buf->export_state.mem_type != mem_type)
  return VA_STATUS_ERROR_INVALID_PARAMETER;
diff --git a/src/gallium/state_trackers/va/image.c
b/src/gallium/state_trackers/va/image.c
index ae07da8..58c9ff7 100644
--- a/src/gallium/state_trackers/va/image.c
+++ b/src/gallium/state_trackers/va/image.c
@@ -266,7 +266,6 @@ vlVaDeriveImage(VADriverContextP ctx,
VASurfaceID surface, VAImage *image)
img_buf->type = VAImageBufferType;
img_buf->size = image->data_size;
img_buf->num_elements = 1;
-   img_buf->derived_surface.fence = surf->fence;

pipe_resource_reference(&img_buf->derived_surface.resource,
surfaces[0]->texture);

diff --git a/src/gallium/state_trackers/va/postproc.c
b/src/gallium/state_trackers/va/postproc.c
index 105f251..1ee3587 100644
--- a/src/gallium/state_trackers/va/postproc.c
+++ b/src/gallium/state_trackers/va/postproc.c
@@ -54,7 +54,6 @@
vlVaHandleVAProcPipelineParameterBufferType(vlVaDriver *drv,
vlVaContext *contex
vlVaSurface *src_surface;
VAProcPipelineParameterBuffer *pipeline_param;
struct pipe_surface **surfaces;
-   struct pipe_screen *screen;
struct pipe_surface *psurf;

if (!drv || !context)
@@ -77,8 +76,6 @@
vlVaHandleVAProcPipelineParameterBufferType(vlVaDriver *drv,
vlVaContext *contex
if (!surfaces || !surfaces[0])
   return VA_STATUS_ERROR_INVALID_SURFACE;

-   screen = drv->pipe->screen;
-
psurf = surfaces[0];

src_region = vlVaRegionDefault(pipeline_param->surface_region,
src_surface->buffer, &def_src_region);
@@ -99,9 +96,6 @@
vlVaHandleVAProcPipelineParameterBufferType(vlVaDriver *drv,
vlVaContext *contex
vl_compositor_set_layer_dst_area(&drv->cstate, 0, &dst_rect);
vl_compositor_render(&drv->cstate, &drv->compositor, psurf,
NULL, false);

-   screen->fence_reference(screen, &src_surface->fence, NULL);
-   drv->pi

[Mesa-dev] [PATCH 4/5] nv50: check return value of nouveau_object_new()

[Samuel Pitoiset]

Spotted by Coverity.

Signed-off-by: Samuel Pitoiset 
---
 src/gallium/drivers/nouveau/nv50/nv84_video.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/gallium/drivers/nouveau/nv50/nv84_video.c 
b/src/gallium/drivers/nouveau/nv50/nv84_video.c
index 7a4670f..5e2489a 100644
--- a/src/gallium/drivers/nouveau/nv50/nv84_video.c
+++ b/src/gallium/drivers/nouveau/nv50/nv84_video.c
@@ -756,8 +756,8 @@ firmware_present(struct pipe_screen *pscreen, enum 
pipe_video_format codec)
int present, ret;
 
if (!FIRMWARE_PRESENT(checked, VP_KERN)) {
-  nouveau_object_new(screen->channel, 0, 0x7476, NULL, 0, &obj);
-  if (obj)
+  ret = nouveau_object_new(screen->channel, 0, 0x7476, NULL, 0, &obj);
+  if (!ret && obj)
  screen->firmware_info.profiles_present |= FIRMWARE_VP_KERN;
   nouveau_object_del(&obj);
   screen->firmware_info.profiles_checked |= FIRMWARE_VP_KERN;
@@ -765,8 +765,8 @@ firmware_present(struct pipe_screen *pscreen, enum 
pipe_video_format codec)
 
if (codec == PIPE_VIDEO_FORMAT_MPEG4_AVC) {
   if (!FIRMWARE_PRESENT(checked, BSP_KERN)) {
- nouveau_object_new(screen->channel, 0, 0x74b0, NULL, 0, &obj);
- if (obj)
+ ret = nouveau_object_new(screen->channel, 0, 0x74b0, NULL, 0, &obj);
+ if (!ret && obj)
 screen->firmware_info.profiles_present |= FIRMWARE_BSP_KERN;
  nouveau_object_del(&obj);
  screen->firmware_info.profiles_checked |= FIRMWARE_BSP_KERN;
-- 
2.6.4

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

[Mesa-dev] [PATCH 5/5] nouveau: remove logically dead code in nouveau_vpe_mb_mv_header()

[Samuel Pitoiset]

frame cannot be NULL in that branch. Spotted by Coverity.

Signed-off-by: Samuel Pitoiset 
---
 src/gallium/drivers/nouveau/nouveau_video.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/src/gallium/drivers/nouveau/nouveau_video.c 
b/src/gallium/drivers/nouveau/nouveau_video.c
index 8bb12b2..fe19bce 100644
--- a/src/gallium/drivers/nouveau/nouveau_video.c
+++ b/src/gallium/drivers/nouveau/nouveau_video.c
@@ -317,8 +317,6 @@ nouveau_vpe_mb_mv_header(struct nouveau_decoder *dec,
   case PIPE_MPEG12_MO_TYPE_16x8: goto mv2;
   case PIPE_MPEG12_MO_TYPE_DUAL_PRIME: {
   base = NV17_MPEG_CMD_CHROMA_MV_HEADER_MV_SPLIT_HALF_MB;
- if (frame)
-base |= NV17_MPEG_CMD_CHROMA_MV_HEADER_TYPE_FRAME;
  if (forward)
 nouveau_vpe_mb_mv(dec, base, luma, frame, true,
   dec->picture_structure != 
PIPE_MPEG12_PICTURE_STRUCTURE_FIELD_TOP,
-- 
2.6.4

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

[Mesa-dev] [PATCH 3/5] nvc0: make sure gmt programs are correctly validated

[Samuel Pitoiset]

Spotted by Coverity.

Signed-off-by: Samuel Pitoiset 
---
 src/gallium/drivers/nouveau/nvc0/nvc0_shader_state.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_shader_state.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_shader_state.c
index 7e2e999..5e69e29 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_shader_state.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_shader_state.c
@@ -236,8 +236,10 @@ nvc0_gmtyprog_validate(struct nvc0_context *nvc0)
struct nouveau_pushbuf *push = nvc0->base.pushbuf;
struct nvc0_program *gp = nvc0->gmtyprog;
 
-   if (gp)
-  nvc0_program_validate(nvc0, gp);
+   if (gp) {
+  if (!nvc0_program_validate(nvc0, gp))
+ return;
+   }
 
/* we allow GPs with no code for specifying stream output state only */
if (gp && gp->code_size) {
-- 
2.6.4

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

[Mesa-dev] [PATCH 1/5] nv50, nvc0: fix using uninitialized value 'templ.texture' in nvXX_blit_set_src()

[Samuel Pitoiset]

Field 'templ.texture' is used uninitialized when calling
nvXX_create_texture_view(). Spotted by Coverity.

Signed-off-by: Samuel Pitoiset 
---
 src/gallium/drivers/nouveau/nv50/nv50_surface.c | 1 +
 src/gallium/drivers/nouveau/nvc0/nvc0_surface.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/src/gallium/drivers/nouveau/nv50/nv50_surface.c 
b/src/gallium/drivers/nouveau/nv50/nv50_surface.c
index 86be1b4..b03e893 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_surface.c
+++ b/src/gallium/drivers/nouveau/nv50/nv50_surface.c
@@ -1031,6 +1031,7 @@ nv50_blit_set_src(struct nv50_blitctx *blit,
 
target = nv50_blit_reinterpret_pipe_texture_target(res->target);
 
+   templ.texture = NULL;
templ.format = format;
templ.u.tex.first_level = templ.u.tex.last_level = level;
templ.u.tex.first_layer = templ.u.tex.last_layer = layer;
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_surface.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_surface.c
index f8e1efb..41fb82a 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_surface.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_surface.c
@@ -841,6 +841,7 @@ nvc0_blit_set_src(struct nvc0_blitctx *ctx,
 
target = nv50_blit_reinterpret_pipe_texture_target(res->target);
 
+   templ.texture = NULL;
templ.format = format;
templ.u.tex.first_layer = templ.u.tex.last_layer = layer;
templ.u.tex.first_level = templ.u.tex.last_level = level;
-- 
2.6.4

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

[Mesa-dev] [PATCH 2/5] nv50, nvc0: fix potential resource leak in nvXX_create_texture_view()

[Samuel Pitoiset]

Spotted by Coverity.

Signed-off-by: Samuel Pitoiset 
---
 src/gallium/drivers/nouveau/nv50/nv50_tex.c | 3 ++-
 src/gallium/drivers/nouveau/nvc0/nvc0_tex.c | 3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/gallium/drivers/nouveau/nv50/nv50_tex.c 
b/src/gallium/drivers/nouveau/nv50/nv50_tex.c
index 6083ea9..9fb9dcf 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_tex.c
+++ b/src/gallium/drivers/nouveau/nv50/nv50_tex.c
@@ -193,7 +193,8 @@ nv50_create_texture_view(struct pipe_context *pipe,
   break;
default:
   NOUVEAU_ERR("invalid texture target: %d\n", mt->base.base.target);
-  return false;
+  FREE(view);
+  return NULL;
}
 
tic[3] = (flags & NV50_TEXVIEW_FILTER_MSAA8) ? 0x2000 : 0x0030;
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_tex.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_tex.c
index 2dd100f..2503ee1 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_tex.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_tex.c
@@ -195,7 +195,8 @@ nvc0_create_texture_view(struct pipe_context *pipe,
default:
   NOUVEAU_ERR("unexpected/invalid texture target: %d\n",
   mt->base.base.target);
-  return false;
+  FREE(view);
+  return NULL;
}
 
tic[3] = (flags & NV50_TEXVIEW_FILTER_MSAA8) ? 0x2000 : 0x0030;
-- 
2.6.4

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

[Mesa-dev] [PATCH 0/5] nouveau: fix some Coverity issues

[Samuel Pitoiset]

Hi,

This series fixes some issues spotted by Coverity.

Feel free to review,
Thanks.

Samuel.

Samuel Pitoiset (5):
  nv50,nvc0: fix using uninitialized value 'templ.texture' in 
nvXX_blit_set_src()
  nv50,nvc0: fix potential resource leak in nvXX_create_texture_view()
  nvc0: make sure gmt programs are correctly validated
  nv50: check return value of nouveau_object_new()
  nouveau: remove logically dead code in nouveau_vpe_mb_mv_header()

 src/gallium/drivers/nouveau/nouveau_video.c  | 2 --
 src/gallium/drivers/nouveau/nv50/nv50_surface.c  | 1 +
 src/gallium/drivers/nouveau/nv50/nv50_tex.c  | 3 ++-
 src/gallium/drivers/nouveau/nv50/nv84_video.c| 8 
 src/gallium/drivers/nouveau/nvc0/nvc0_shader_state.c | 6 --
 src/gallium/drivers/nouveau/nvc0/nvc0_surface.c  | 1 +
 src/gallium/drivers/nouveau/nvc0/nvc0_tex.c  | 3 ++-
 7 files changed, 14 insertions(+), 10 deletions(-)

-- 
2.6.4

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

Re: [Mesa-dev] [PATCH v2 11/13] i965: Add tessellation evaluation shaders

[Kenneth Graunke]

On Monday, December 14, 2015 01:24:37 AM Jordan Justen wrote:
> Whew... I probably would have split this one into 5 or so. Then krh
> would have grumbled at me. ;)

Sorry!  These are pretty huge.  I wasn't sure how best to split it up,
or how much time to spend on that.

> On 2015-12-11 13:24:00, Kenneth Graunke wrote:
> > The TES is essentially a post-tessellator VS, which has access to the
> > entire TCS output patch, and a special gl_TessCoord input.  Otherwise,
> > they're very straightforward.
> > 
> > This patch implements SIMD8 tessellation evaluation shaders for Gen8+.
> > The tessellator can generate a lot of geometry, so operating in SIMD8
> > mode (8 vertices per thread) is more efficient than SIMD4x2 mode (only
> > 2 vertices per thread).  I have another patch which implements SIMD4x2
> > mode for older hardware (or via an environment variable override).
> > 
> > We currently handle all inputs via the pull model.
> > 
> > Signed-off-by: Kenneth Graunke 
> > ---
> >  src/mesa/drivers/dri/i965/Makefile.sources   |   1 +
> >  src/mesa/drivers/dri/i965/brw_compiler.h |  24 +++
> >  src/mesa/drivers/dri/i965/brw_context.h  |   6 +
> >  src/mesa/drivers/dri/i965/brw_fs.cpp |  48 +
> >  src/mesa/drivers/dri/i965/brw_fs.h   |  10 +-
> >  src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 121 +++
> >  src/mesa/drivers/dri/i965/brw_fs_visitor.cpp |  12 +-
> >  src/mesa/drivers/dri/i965/brw_link.cpp   |   4 +
> >  src/mesa/drivers/dri/i965/brw_program.h  |   2 +
> >  src/mesa/drivers/dri/i965/brw_shader.cpp |  94 +
> >  src/mesa/drivers/dri/i965/brw_shader.h   |   3 +
> >  src/mesa/drivers/dri/i965/brw_state_upload.c |   3 +
> >  src/mesa/drivers/dri/i965/brw_tes.c  | 300 
> > +++
> >  13 files changed, 625 insertions(+), 3 deletions(-)
> >  create mode 100644 src/mesa/drivers/dri/i965/brw_tes.c
> > 
> > diff --git a/src/mesa/drivers/dri/i965/Makefile.sources 
> > b/src/mesa/drivers/dri/i965/Makefile.sources
> > index d147a73..7354aaf 100644
> > --- a/src/mesa/drivers/dri/i965/Makefile.sources
> > +++ b/src/mesa/drivers/dri/i965/Makefile.sources
> > @@ -151,6 +151,7 @@ i965_FILES = \
> > brw_state_upload.c \
> > brw_structs.h \
> > brw_tcs_surface_state.c \
> > +   brw_tes.c \
> > brw_tes_surface_state.c \
> > brw_tex.c \
> > brw_tex_layout.c \
> > diff --git a/src/mesa/drivers/dri/i965/brw_compiler.h 
> > b/src/mesa/drivers/dri/i965/brw_compiler.h
> > index c9e0317..64d831d 100644
> > --- a/src/mesa/drivers/dri/i965/brw_compiler.h
> > +++ b/src/mesa/drivers/dri/i965/brw_compiler.h
> > @@ -191,6 +191,14 @@ struct brw_vs_prog_key {
> > struct brw_sampler_prog_key_data tex;
> >  };
> >  
> > +/** The program key for Tessellation Evaluation Shaders. */
> > +struct brw_tes_prog_key
> > +{
> > +   unsigned program_string_id;
> > +
> > +   struct brw_sampler_prog_key_data tex;
> > +};
> > +
> >  /** The program key for Geometry Shaders. */
> >  struct brw_gs_prog_key
> >  {
> > @@ -669,6 +677,22 @@ brw_compile_vs(const struct brw_compiler *compiler, 
> > void *log_data,
> > char **error_str);
> >  
> >  /**
> > + * Compile a tessellation evaluation shader.
> > + *
> > + * Returns the final assembly and the program's size.
> > + */
> > +const unsigned *
> > +brw_compile_tes(const struct brw_compiler *compiler, void *log_data,
> > +void *mem_ctx,
> > +const struct brw_tes_prog_key *key,
> > +struct brw_tes_prog_data *prog_data,
> > +const struct nir_shader *shader,
> > +struct gl_shader_program *shader_prog,
> > +int shader_time_index,
> > +unsigned *final_assembly_size,
> > +char **error_str);
> > +
> > +/**
> >   * Compile a vertex shader.
> >   *
> >   * Returns the final assembly and the program's size.
> > diff --git a/src/mesa/drivers/dri/i965/brw_context.h 
> > b/src/mesa/drivers/dri/i965/brw_context.h
> > index 69bc04c..5e840d1 100644
> > --- a/src/mesa/drivers/dri/i965/brw_context.h
> > +++ b/src/mesa/drivers/dri/i965/brw_context.h
> > @@ -1704,6 +1704,12 @@ brw_vertex_program_const(const struct 
> > gl_vertex_program *p)
> > return (const struct brw_vertex_program *) p;
> >  }
> >  
> > +static inline struct brw_tess_eval_program *
> > +brw_tess_eval_program(struct gl_tess_eval_program *p)
> > +{
> > +   return (struct brw_tess_eval_program *) p;
> > +}
> > +
> >  static inline struct brw_geometry_program *
> >  brw_geometry_program(struct gl_geometry_program *p)
> >  {
> > diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp 
> > b/src/mesa/drivers/dri/i965/brw_fs.cpp
> > index c833ef0..de584e4 100644
> > --- a/src/mesa/drivers/dri/i965/brw_fs.cpp
> > +++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
> > @@ -1686,6 +1686,21 @@ fs_visitor::assign_vs_urb_setup()
> >  }
> >  
> >  void
> > +fs_visitor::assign_tes_urb_setup()
> >

Re: [Mesa-dev] [PATCH v2 05/13] i965: Allocate URB space for HS and DS stages when required.

[Kenneth Graunke]

On Saturday, December 12, 2015 10:39:13 AM Jordan Justen wrote:
> On 2015-12-11 13:23:54, Kenneth Graunke wrote:
> > From: Chris Forbes 
> > 
> > v2: Rewrite the push constant allocation code to be clearer.
> > Only apply the minimum VS entries workaround on Gen 8.
> > 
> > Signed-off-by: Chris Forbes 
> > Signed-off-by: Kenneth Graunke 
> > ---
> >  src/mesa/drivers/dri/i965/brw_context.h  |  21 +++-
> >  src/mesa/drivers/dri/i965/gen7_blorp.cpp |   8 ++
> >  src/mesa/drivers/dri/i965/gen7_urb.c | 174 
> > ---
> >  3 files changed, 166 insertions(+), 37 deletions(-)
> > 
> > diff --git a/src/mesa/drivers/dri/i965/brw_context.h 
> > b/src/mesa/drivers/dri/i965/brw_context.h
> > index 1cc4c7b..69bc04c 100644
> > --- a/src/mesa/drivers/dri/i965/brw_context.h
> > +++ b/src/mesa/drivers/dri/i965/brw_context.h
> > @@ -1008,6 +1008,8 @@ struct brw_context
> > struct {
> >GLuint vsize;/* vertex size plus header in urb registers 
> > */
> >GLuint gsize;/* GS output size in urb registers */
> > +  GLuint hsize; /* Tessellation control output size in urb 
> > registers */
> > +  GLuint dsize; /* Tessellation evaluation output size in 
> > urb registers */
> >GLuint csize;/* constant buffer size in urb registers */
> >GLuint sfsize;   /* setup data size in urb registers */
> >  
> > @@ -1020,12 +1022,16 @@ struct brw_context
> >GLuint max_gs_entries;   /* Maximum number of GS entries */
> >  
> >GLuint nr_vs_entries;
> > +  GLuint nr_hs_entries;
> > +  GLuint nr_ds_entries;
> >GLuint nr_gs_entries;
> >GLuint nr_clip_entries;
> >GLuint nr_sf_entries;
> >GLuint nr_cs_entries;
> >  
> >GLuint vs_start;
> > +  GLuint hs_start;
> > +  GLuint ds_start;
> >GLuint gs_start;
> >GLuint clip_start;
> >GLuint sf_start;
> > @@ -1042,6 +1048,11 @@ struct brw_context
> > * URB space for the GS.
> > */
> >bool gs_present;
> > +
> > +  /* True if the most recently sent _3DSTATE_URB message allocated
> > +   * URB space for the HS and DS.
> > +   */
> > +  bool tess_present;
> > } urb;
> >  
> >  
> > @@ -1648,12 +1659,18 @@ void gen8_emit_3dstate_sample_pattern(struct 
> > brw_context *brw);
> >  /* gen7_urb.c */
> >  void
> >  gen7_emit_push_constant_state(struct brw_context *brw, unsigned vs_size,
> > +  unsigned hs_size, unsigned ds_size,
> >unsigned gs_size, unsigned fs_size);
> >  
> >  void
> >  gen7_emit_urb_state(struct brw_context *brw,
> > -unsigned nr_vs_entries, unsigned vs_size,
> > -unsigned vs_start, unsigned nr_gs_entries,
> > +unsigned nr_vs_entries,
> > +unsigned vs_size, unsigned vs_start,
> > +unsigned nr_hs_entries,
> > +unsigned hs_size, unsigned hs_start,
> > +unsigned nr_ds_entries,
> > +unsigned ds_size, unsigned ds_start,
> > +unsigned nr_gs_entries,
> >  unsigned gs_size, unsigned gs_start);
> >  
> >  
> > diff --git a/src/mesa/drivers/dri/i965/gen7_blorp.cpp 
> > b/src/mesa/drivers/dri/i965/gen7_blorp.cpp
> > index e87b9d1..89b73ca 100644
> > --- a/src/mesa/drivers/dri/i965/gen7_blorp.cpp
> > +++ b/src/mesa/drivers/dri/i965/gen7_blorp.cpp
> > @@ -50,6 +50,8 @@ gen7_blorp_emit_urb_config(struct brw_context *brw)
> > unsigned urb_size = (brw->is_haswell && brw->gt == 3) ? 32 : 16;
> > gen7_emit_push_constant_state(brw,
> >   urb_size / 2 /* vs_size */,
> > + 0 /* hs_size */,
> > + 0 /* ds_size */,
> >   0 /* gs_size */,
> >   urb_size / 2 /* fs_size */);
> >  
> > @@ -60,6 +62,12 @@ gen7_blorp_emit_urb_config(struct brw_context *brw)
> > 32 /* num_vs_entries */,
> > 2 /* vs_size */,
> > 2 /* vs_start */,
> > +   0 /* num_hs_entries */,
> > +   1 /* hs_size */,
> > +   2 /* hs_start */,
> > +   0 /* num_ds_entries */,
> > +   1 /* ds_size */,
> > +   2 /* ds_start */,
> > 0 /* num_gs_entries */,
> > 1 /* gs_size */,
> > 2 /* gs_start */);
> > diff --git a/src/mesa/drivers/dri/i965/gen7_urb.c 
> > b/src/mesa/drivers/dri/i965/gen7_urb.c
> > index 99a9d3c..a598c89 100644
> > --- a/src/mesa/drivers/dri/i965/gen7_urb.c
> > +++ b/src/mesa/drivers/dri/i965/gen7_urb.c
> > @@ -34,7 +34,7 @@
> >   *   __-__   _-__

Re: [Mesa-dev] [PATCH v2 05/13] i965: Allocate URB space for HS and DS stages when required.

[Kenneth Graunke]

On Friday, December 11, 2015 01:23:54 PM Kenneth Graunke wrote:
> From: Chris Forbes 
> 
> v2: Rewrite the push constant allocation code to be clearer.
> Only apply the minimum VS entries workaround on Gen 8.
> 
> Signed-off-by: Chris Forbes 
> Signed-off-by: Kenneth Graunke 
> ---
>  src/mesa/drivers/dri/i965/brw_context.h  |  21 +++-
>  src/mesa/drivers/dri/i965/gen7_blorp.cpp |   8 ++
>  src/mesa/drivers/dri/i965/gen7_urb.c | 174 
> ---
>  3 files changed, 166 insertions(+), 37 deletions(-)
> 
> diff --git a/src/mesa/drivers/dri/i965/brw_context.h 
> b/src/mesa/drivers/dri/i965/brw_context.h
> index 1cc4c7b..69bc04c 100644
> --- a/src/mesa/drivers/dri/i965/brw_context.h
> +++ b/src/mesa/drivers/dri/i965/brw_context.h
> @@ -1008,6 +1008,8 @@ struct brw_context
> struct {
>GLuint vsize;  /* vertex size plus header in urb registers */
>GLuint gsize;  /* GS output size in urb registers */
> +  GLuint hsize; /* Tessellation control output size in urb 
> registers */
> +  GLuint dsize; /* Tessellation evaluation output size in 
> urb registers */
>GLuint csize;  /* constant buffer size in urb registers */
>GLuint sfsize; /* setup data size in urb registers */
>  
> @@ -1020,12 +1022,16 @@ struct brw_context
>GLuint max_gs_entries; /* Maximum number of GS entries */
>  
>GLuint nr_vs_entries;
> +  GLuint nr_hs_entries;
> +  GLuint nr_ds_entries;
>GLuint nr_gs_entries;
>GLuint nr_clip_entries;
>GLuint nr_sf_entries;
>GLuint nr_cs_entries;
>  
>GLuint vs_start;
> +  GLuint hs_start;
> +  GLuint ds_start;
>GLuint gs_start;
>GLuint clip_start;
>GLuint sf_start;
> @@ -1042,6 +1048,11 @@ struct brw_context
> * URB space for the GS.
> */
>bool gs_present;
> +
> +  /* True if the most recently sent _3DSTATE_URB message allocated
> +   * URB space for the HS and DS.
> +   */
> +  bool tess_present;
> } urb;
>  
>  
> @@ -1648,12 +1659,18 @@ void gen8_emit_3dstate_sample_pattern(struct 
> brw_context *brw);
>  /* gen7_urb.c */
>  void
>  gen7_emit_push_constant_state(struct brw_context *brw, unsigned vs_size,
> +  unsigned hs_size, unsigned ds_size,
>unsigned gs_size, unsigned fs_size);
>  
>  void
>  gen7_emit_urb_state(struct brw_context *brw,
> -unsigned nr_vs_entries, unsigned vs_size,
> -unsigned vs_start, unsigned nr_gs_entries,
> +unsigned nr_vs_entries,
> +unsigned vs_size, unsigned vs_start,
> +unsigned nr_hs_entries,
> +unsigned hs_size, unsigned hs_start,
> +unsigned nr_ds_entries,
> +unsigned ds_size, unsigned ds_start,
> +unsigned nr_gs_entries,
>  unsigned gs_size, unsigned gs_start);
>  
>  
> diff --git a/src/mesa/drivers/dri/i965/gen7_blorp.cpp 
> b/src/mesa/drivers/dri/i965/gen7_blorp.cpp
> index e87b9d1..89b73ca 100644
> --- a/src/mesa/drivers/dri/i965/gen7_blorp.cpp
> +++ b/src/mesa/drivers/dri/i965/gen7_blorp.cpp
> @@ -50,6 +50,8 @@ gen7_blorp_emit_urb_config(struct brw_context *brw)
> unsigned urb_size = (brw->is_haswell && brw->gt == 3) ? 32 : 16;
> gen7_emit_push_constant_state(brw,
>   urb_size / 2 /* vs_size */,
> + 0 /* hs_size */,
> + 0 /* ds_size */,
>   0 /* gs_size */,
>   urb_size / 2 /* fs_size */);
>  
> @@ -60,6 +62,12 @@ gen7_blorp_emit_urb_config(struct brw_context *brw)
> 32 /* num_vs_entries */,
> 2 /* vs_size */,
> 2 /* vs_start */,
> +   0 /* num_hs_entries */,
> +   1 /* hs_size */,
> +   2 /* hs_start */,
> +   0 /* num_ds_entries */,
> +   1 /* ds_size */,
> +   2 /* ds_start */,
> 0 /* num_gs_entries */,
> 1 /* gs_size */,
> 2 /* gs_start */);
> diff --git a/src/mesa/drivers/dri/i965/gen7_urb.c 
> b/src/mesa/drivers/dri/i965/gen7_urb.c
> index 99a9d3c..a598c89 100644
> --- a/src/mesa/drivers/dri/i965/gen7_urb.c
> +++ b/src/mesa/drivers/dri/i965/gen7_urb.c
> @@ -34,7 +34,7 @@
>   *   __-__   _-_
>   *  / \ /   \
>   * +-+
> - * | VS/FS/GS Push |  VS/GS URB  |
> + * |  VS/HS/DS/GS/FS Push  |   VS/HS/DS/GS URB   |
>   * |

[Mesa-dev] [PATCH] nir: Fix number of indices on shared variable store intrinsics.

[Kenneth Graunke]

Shared variables and input reworks landed around the same time.
Presumably, this was some sort of mistake in rebase conflict resolution.

Found by inspection.

Signed-off-by: Kenneth Graunke 
---
 src/glsl/nir/nir_intrinsics.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

No effect in Jenkins, oddly.

diff --git a/src/glsl/nir/nir_intrinsics.h b/src/glsl/nir/nir_intrinsics.h
index 9811fb3..ec9e845 100644
--- a/src/glsl/nir/nir_intrinsics.h
+++ b/src/glsl/nir/nir_intrinsics.h
@@ -309,6 +309,6 @@ STORE(per_vertex_output, 3, 1, 0)
 /* src[] = { value, block_index, offset }. const_index[] = { write_mask } */
 STORE(ssbo, 3, 1, 0)
 /* src[] = { value, offset }. const_index[] = { base, write_mask } */
-STORE(shared, 2, 1, 0)
+STORE(shared, 2, 2, 0)
 
 LAST_INTRINSIC(store_shared)
-- 
2.6.3

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

Re: [Mesa-dev] [Intel-gfx] [RFC libdrm] intel: Add support for softpin

[Emil Velikov]

On 14 December 2015 at 09:04, Daniel Vetter  wrote:
> On Mon, Dec 14, 2015 at 08:41:05AM +, Song, Ruiling wrote:
>>
>>
>> > -Original Message-
>> > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
>> > Vetter
>> > Sent: Monday, December 14, 2015 4:28 PM
>> > To: Song, Ruiling 
>> > Cc: k...@bitplanet.net; Winiarski, Michal ;
>> > mesa-dev@lists.freedesktop.org; intel-...@lists.freedesktop.org; Ben
>> > Widawsky ; dri-de...@lists.freedesktop.org
>> > Subject: Re: [Intel-gfx] [RFC libdrm] intel: Add support for softpin
>> >
>> > On Mon, Dec 14, 2015 at 07:24:29AM +, Song, Ruiling wrote:
>> > >
>> > >
>> > > > -Original Message-
>> > > > From: hoegsb...@gmail.com [mailto:hoegsb...@gmail.com] On Behalf
>> > Of
>> > > > Kristian H?gsberg
>> > > > Sent: Monday, December 14, 2015 1:34 PM
>> > > > To: Song, Ruiling 
>> > > > Cc: Winiarski, Michal ; intel-
>> > > > g...@lists.freedesktop.org; mesa-dev@lists.freedesktop.org; Ben
>> > Widawsky
>> > > > ; dri-de...@lists.freedesktop.org
>> > > > Subject: Re: [Intel-gfx] [RFC libdrm] intel: Add support for softpin
>> > > >
>> > > > On Sun, Dec 13, 2015 at 7:17 PM, Song, Ruiling 
>> > > > wrote:
>> > > > >> -Original Message-
>> > > > >> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On
>> > > > Behalf
>> > > > >> Of Micha? Winiarski
>> > > > >> Sent: Wednesday, September 9, 2015 10:07 PM
>> > > > >> To: intel-...@lists.freedesktop.org
>> > > > >> Cc: Ben Widawsky ; dri-
>> > > > de...@lists.freedesktop.org;
>> > > > >> mesa-dev@lists.freedesktop.org
>> > > > >> Subject: [Intel-gfx] [RFC libdrm] intel: Add support for softpin
>> > > > >>
>> > > > >> Softpin allows userspace to take greater control of GPU virtual 
>> > > > >> address
>> > > > >> space and eliminates the need of relocations. It can also be used to
>> > > > >> mirror addresses between GPU and CPU (shared virtual memory).
>> > > > >> Calls to drm_intel_bo_emit_reloc are still required to build the 
>> > > > >> list of
>> > > > >> drm_i915_gem_exec_objects at exec time, but no entries in relocs are
>> > > > >> created. Self-relocs don't make any sense for softpinned objects and
>> > can
>> > > > >> indicate a programming errors, thus are forbidden. Softpinned 
>> > > > >> objects
>> > > > >> are marked by asterisk in debug dumps.
>> > > > >>
>> > > > >> Cc: Thomas Daniel 
>> > > > >> Cc: Kristian Høgsberg 
>> > > > >> Cc: Zou Nanhai 
>> > > > >> Cc: Michel Thierry 
>> > > > >> Cc: Ben Widawsky 
>> > > > >> Cc: Chris Wilson 
>> > > > >> Signed-off-by: Michał Winiarski 
>> > > > >> ---
>> > > > >>  include/drm/i915_drm.h|   4 +-
>> > > > >>  intel/intel_bufmgr.c  |   9 +++
>> > > > >>  intel/intel_bufmgr.h  |   1 +
>> > > > >>  intel/intel_bufmgr_gem.c  | 176
>> > > > >> --
>> > > > >>  intel/intel_bufmgr_priv.h |   7 ++
>> > > > >>  5 files changed, 173 insertions(+), 24 deletions(-)
>> > > > >
>> > > > > Will anybody help to push the patch to libdrm? Beignet highly depend
>> > on
>> > > > this to implement ocl2.0 svm.
>> > > >
>> > > > Is the kernel patch upstream?
>> > >
>> > > Yes, the kernel patch already merged, see:
>> > > http://cgit.freedesktop.org/drm-
>> > intel/commit/?id=506a8e87d8d2746b9e9d2433503fe237c54e4750
>> > >
>> > > I find below line of code in libdrm does not match the kernel version. 
>> > > The
>> > kernel patch defined as:
>> > > "#define EXEC_OBJECT_PINNED (1<<4)", but this patch defined it as (1<<3).
>> >
>> > Please always regenerate the entire headers from the kernel sources using
>> >
>> > $ make headers_install
>> >
>> > Then copy the headers from the kernel's usr/include/drm to libdrm. Never
>> > patch i915_drm.h manually.
>>
>> Thanks for the info. But the problem is libdrm still tracks such kind of 
>> header files.
>> Should this kind of header file be removed from libdrm? Or any document in 
>> libdrm to make this explicit?
>
> All other kernel headers are extracted from the kernel directly, but
> generally those packages only get update when a new kernel comes out.
> Usually it's called linux-headers or similar. And only updating headers
> when the release is out is _way_ too slow for drm/gfx. That's why we have
> drm headers in libdrm.
>
That plus hysterical raisins, from when drm was part of userspace ;-)

> But yeah we should document this, maybe even script it. Perhaps even just
> upgrade headers automatically as soon as the upstream drm-next branch
> changes.
I'm all for tweaking the make target, although automating to the point
of zero developer interaction might not be ideal. Plus we do have the
occasional revert in -next and even -rcX :-\

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

[Mesa-dev] [PATCH 1/2] i965: Use DIV_ROUND_UP() in gen7_urb.c code.

[Kenneth Graunke]

This is a newer convention, which we prefer over ALIGN(x, n) / n.

Signed-off-by: Kenneth Graunke 
---
 src/mesa/drivers/dri/i965/gen7_urb.c | 17 -
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/gen7_urb.c 
b/src/mesa/drivers/dri/i965/gen7_urb.c
index 99a9d3c..421512b 100644
--- a/src/mesa/drivers/dri/i965/gen7_urb.c
+++ b/src/mesa/drivers/dri/i965/gen7_urb.c
@@ -193,11 +193,11 @@ gen7_upload_urb(struct brw_context *brw)
 
/* VS has a lower limit on the number of URB entries */
unsigned vs_chunks =
-  ALIGN(brw->urb.min_vs_entries * vs_entry_size_bytes, chunk_size_bytes) /
-  chunk_size_bytes;
+  DIV_ROUND_UP(brw->urb.min_vs_entries * vs_entry_size_bytes,
+   chunk_size_bytes);
unsigned vs_wants =
-  ALIGN(brw->urb.max_vs_entries * vs_entry_size_bytes,
-chunk_size_bytes) / chunk_size_bytes - vs_chunks;
+  DIV_ROUND_UP(brw->urb.max_vs_entries * vs_entry_size_bytes,
+   chunk_size_bytes) - vs_chunks;
 
unsigned gs_chunks = 0;
unsigned gs_wants = 0;
@@ -210,11 +210,10 @@ gen7_upload_urb(struct brw_context *brw)
*
* (2) We can't allocate less than nr_gs_entries_granularity.
*/
-  gs_chunks = ALIGN(MAX2(gs_granularity, 2) * gs_entry_size_bytes,
-chunk_size_bytes) / chunk_size_bytes;
-  gs_wants =
- ALIGN(brw->urb.max_gs_entries * gs_entry_size_bytes,
-   chunk_size_bytes) / chunk_size_bytes - gs_chunks;
+  gs_chunks = DIV_ROUND_UP(MAX2(gs_granularity, 2) * gs_entry_size_bytes,
+   chunk_size_bytes);
+  gs_wants = DIV_ROUND_UP(brw->urb.max_gs_entries * gs_entry_size_bytes,
+  chunk_size_bytes) - gs_chunks;
}
 
/* There should always be enough URB space to satisfy the minimum
-- 
2.6.3

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

[Mesa-dev] [PATCH 2/2] i965: Allocate URB space for HS and DS stages when required.

[Kenneth Graunke]

From: Chris Forbes 

v2: (by Ken, incorporating feedback from Matt Turner):
- Rewrite the push constant allocation code to be clearer.
- Only apply the minimum VS entries workaround on Gen 8.

v3: (by Ken)
- Fix a bug in v2 where we failed to allocate the full push constant
  space when the number of enabled stages didn't divide the available
  push constant space evenly.  (Any left over space is now allocated
  to the PS, as it was in v1.)
- Fix an off-by-one error in v2's number of enabled stages calculation.
- Use DIV_ROUND_UP for nicer formatting.
- Line wrapping fixes.

Signed-off-by: Chris Forbes 
Signed-off-by: Kenneth Graunke 
---
 src/mesa/drivers/dri/i965/brw_context.h  |  21 +++-
 src/mesa/drivers/dri/i965/gen7_blorp.cpp |   8 ++
 src/mesa/drivers/dri/i965/gen7_urb.c | 177 +--
 3 files changed, 170 insertions(+), 36 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_context.h 
b/src/mesa/drivers/dri/i965/brw_context.h
index 1cc4c7b..69bc04c 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -1008,6 +1008,8 @@ struct brw_context
struct {
   GLuint vsize;/* vertex size plus header in urb registers */
   GLuint gsize;/* GS output size in urb registers */
+  GLuint hsize; /* Tessellation control output size in urb 
registers */
+  GLuint dsize; /* Tessellation evaluation output size in urb 
registers */
   GLuint csize;/* constant buffer size in urb registers */
   GLuint sfsize;   /* setup data size in urb registers */
 
@@ -1020,12 +1022,16 @@ struct brw_context
   GLuint max_gs_entries;   /* Maximum number of GS entries */
 
   GLuint nr_vs_entries;
+  GLuint nr_hs_entries;
+  GLuint nr_ds_entries;
   GLuint nr_gs_entries;
   GLuint nr_clip_entries;
   GLuint nr_sf_entries;
   GLuint nr_cs_entries;
 
   GLuint vs_start;
+  GLuint hs_start;
+  GLuint ds_start;
   GLuint gs_start;
   GLuint clip_start;
   GLuint sf_start;
@@ -1042,6 +1048,11 @@ struct brw_context
* URB space for the GS.
*/
   bool gs_present;
+
+  /* True if the most recently sent _3DSTATE_URB message allocated
+   * URB space for the HS and DS.
+   */
+  bool tess_present;
} urb;
 
 
@@ -1648,12 +1659,18 @@ void gen8_emit_3dstate_sample_pattern(struct 
brw_context *brw);
 /* gen7_urb.c */
 void
 gen7_emit_push_constant_state(struct brw_context *brw, unsigned vs_size,
+  unsigned hs_size, unsigned ds_size,
   unsigned gs_size, unsigned fs_size);
 
 void
 gen7_emit_urb_state(struct brw_context *brw,
-unsigned nr_vs_entries, unsigned vs_size,
-unsigned vs_start, unsigned nr_gs_entries,
+unsigned nr_vs_entries,
+unsigned vs_size, unsigned vs_start,
+unsigned nr_hs_entries,
+unsigned hs_size, unsigned hs_start,
+unsigned nr_ds_entries,
+unsigned ds_size, unsigned ds_start,
+unsigned nr_gs_entries,
 unsigned gs_size, unsigned gs_start);
 
 
diff --git a/src/mesa/drivers/dri/i965/gen7_blorp.cpp 
b/src/mesa/drivers/dri/i965/gen7_blorp.cpp
index e87b9d1..89b73ca 100644
--- a/src/mesa/drivers/dri/i965/gen7_blorp.cpp
+++ b/src/mesa/drivers/dri/i965/gen7_blorp.cpp
@@ -50,6 +50,8 @@ gen7_blorp_emit_urb_config(struct brw_context *brw)
unsigned urb_size = (brw->is_haswell && brw->gt == 3) ? 32 : 16;
gen7_emit_push_constant_state(brw,
  urb_size / 2 /* vs_size */,
+ 0 /* hs_size */,
+ 0 /* ds_size */,
  0 /* gs_size */,
  urb_size / 2 /* fs_size */);
 
@@ -60,6 +62,12 @@ gen7_blorp_emit_urb_config(struct brw_context *brw)
32 /* num_vs_entries */,
2 /* vs_size */,
2 /* vs_start */,
+   0 /* num_hs_entries */,
+   1 /* hs_size */,
+   2 /* hs_start */,
+   0 /* num_ds_entries */,
+   1 /* ds_size */,
+   2 /* ds_start */,
0 /* num_gs_entries */,
1 /* gs_size */,
2 /* gs_start */);
diff --git a/src/mesa/drivers/dri/i965/gen7_urb.c 
b/src/mesa/drivers/dri/i965/gen7_urb.c
index 421512b..f2b6ec3 100644
--- a/src/mesa/drivers/dri/i965/gen7_urb.c
+++ b/src/mesa/drivers/dri/i965/gen7_urb.c
@@ -34,7 +34,7 @@
  *   __-__   _-_
  *  / \ /   \
  * +-+

[Mesa-dev] [Bug 86326] clEnqueueNDRangeKernel global_work_offset ignored

[bugzilla-daemon]

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

Vedran Miletić  changed:

   What|Removed |Added

 CC||riva...@gmail.com

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

Re: [Mesa-dev] [PATCH 04/15] i965/fs: Get rid of reladdr

[Francisco Jerez]

Jason Ekstrand  writes:

> On Dec 11, 2015 5:44 AM, "Francisco Jerez"  wrote:
>>
>> Jason Ekstrand  writes:
>>
>> > On Dec 10, 2015 6:58 AM, "Francisco Jerez" 
> wrote:
>> >>
>> >> Jason Ekstrand  writes:
>> >>
>> >> > We aren't using it anymore.
>> >>
>> >> It seems useful to me to be able to represent indirect access as part
> of
>> >> any instruction source or destination register.
>> >>
>> >> The following:
>> >>
>> >> | mov_indirect g0, g1, a0
>> >> | foo g2, g0
>> >>
>> >> and the converse case with indirect destination offset (which you don't
>> >> seem to represent currently) can be implemented by the hardware more
>> >> efficiently using a single instruction in certain cases.  The current
> IR
>> >> is able to represent what the hardware can do, but supporting the
>> >> MOV_INDIRECT instruction only would force us to keep the indirection
>> >> separate from the instruction that uses it, so it seems like a less
>> >> expressive representation to me than the current approach, unless
> you're
>> >> willing to add _INDIRECT variants of most hardware opcodes.
>> >
>> > Yes and, mostly, no.  Yes, you can put an indirect on almost anything
> but
>> > it has substantial restrictions:
>> >
>> Yes, I'm aware of the restrictions of indirect addressing on Gen
>> hardware.  The fact that reladdr can represent addressing modes which
>> aren't directly implemented in the hardware doesn't invalidate the
>> abstraction, nor implies that optimization and translation passes must
>> be made aware of such restrictions.  It just means that our abstraction
>> is a superset of the hardware indirect addressing scheme, which is fine
>> given a lowering pass to convert indirect addressing into a legal form.
>>
>> Your proposal instead goes the opposite direction and replaces the
>> preexisting abstraction with a new abstraction which can only represent
>> a tiny subset of the functionality of hardware instructions, which I
>> don't think is acceptable for a low-level IR.
>>
>> > 1) Destination indirects must be uniform (I'm only 95% sure this is the
>> > case)
>> >
>> > 2) We only have 8 address subregisters on HSW and prior and 16 on BDW
> which
>> > means:
>> >
>>
>> That's the kind of thing that SIMD lowering would be able to take care
>> of easily.
>
> Yes, and we use it for MOV_INDIRECT.
>
Right, and there's no reason why it couldn't be used for reladdr in the
same way to handle the above restrictions.

>> > a) All indirects must be uniform OR
>> >
>> > b) We must be on Broadwell, have only two indirects, and split the
>> > instruction OR
>> >
>> > c) We can only have one indirect (and still split the instruction on
>> > HSW)
>> >
>> > So, yes, "everthing can be uniform", but not in real life.
>>
>> > The reladdr abstraction, while maybe ok for a high-level IR, doesn't
>> > accurately represent the hardware at all because it can't represent
>> > any of the restrictions without piles of helper functions and checks.
>>
>> The reladdr abstraction can represent the full flexibility of the
>> hardware, while MOV_INDIRECT cannot, that makes reladdr a more accurate
>> low-level representation of the program.  For that reason I'd argue the
>> exact opposite: MOV_INDIRECT would be a great abstraction and a welcome
>> simplification for a high-level IR (e.g. NIR), in which nothing is lost
>> by sacrificing the expressiveness of individual instructions in favour
>> of instruction composition, because the back-end can always combine
>> multiple high-level instructions into a single low-level instruction
>> where the hardware ISA allows, as long as the low-level IR is able to
>> represent the full functionality of hardware instructions (IOW the
>> mapping between low-level IR instructions and hardware instructions is
>> surjective), which is further from being the case after this series.
>
> Flexibility and expressiveness isn't always a good thing.

Expressiveness is a good thing as long as it's required to represent the
capabilities of the hardware.

> Yes, reladdr is more "expressive", but it's not getting used because
> that expressiveness makes it a pain.

AFAIK nobody has bothered to implement it completely down to the
back-end generator so it's not a wonder that it's not extensively used.
I'd like to see some evidence that it would actually be a pain
(e.g. some proof of concept implementation) before we give up and commit
to an inherently more limited model.  If you already have such a proof
of concept, please share it.  If you don't and are fully convinced that
it will be a pain I suggest you hold up this series for a while and let
me write the proof of concept -- Doing something with the expectation
that it's going to be a pain is the best way to make sure it actually
becomes a pain.  Worst-case scenario you're right and it does become a
pain, at which point I come back and review this series.  Best-case
scenario you're wrong and we don't give up useful functionality of the
IR based on an expectation.

> You cou

Re: [Mesa-dev] [Bug 93352] GRID Autosport crashes on start of race

[Ilia Mirkin]

Hi Edwin,

Thanks for reaching out to the mesa community! See my comments inline.

On Mon, Dec 14, 2015 at 5:13 AM,   wrote:
> Comment # 20 on bug 93352 from Edwin Smith
> My name is Edwin Smith and I work for Feral Interactive who make the Linux
> version of the game. Thank you for fixing the issue in the latest drivers, I
> am
> sure people playing the game on AMD machines will be very happy!
>
> We tested the game using 11.0.2 and apart from missing features for the
> higher
> end effects meaning they had to be disabled we did not see any major
> rendering
> issues.

Odd... this bug should have been visible with radeonsi and nouveau
when enabling tessellation. Perhaps only on debug builds though (on
opt builds it would still have been an issue, just no crash).

> Please let us know if we can assist by providing people working on driver
> issues a copy of the title or other information to help with your driver
> work.

The most straight-forward way would be to do the same thing Valve did
-- basically they provide a (free) package on Steam that includes all
of their games to people who are active mesa contributors. You can see
the details of their program here:
http://lists.freedesktop.org/archives/dri-devel/2015-April/081045.html
.

Cheers,

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

Re: [Mesa-dev] [Intel-gfx] [RFC libdrm] intel: Add support for softpin

[Song, Ruiling]

> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> Vetter
> Sent: Monday, December 14, 2015 4:28 PM
> To: Song, Ruiling 
> Cc: k...@bitplanet.net; Winiarski, Michal ;
> mesa-dev@lists.freedesktop.org; intel-...@lists.freedesktop.org; Ben
> Widawsky ; dri-de...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [RFC libdrm] intel: Add support for softpin
> 
> On Mon, Dec 14, 2015 at 07:24:29AM +, Song, Ruiling wrote:
> >
> >
> > > -Original Message-
> > > From: hoegsb...@gmail.com [mailto:hoegsb...@gmail.com] On Behalf
> Of
> > > Kristian H?gsberg
> > > Sent: Monday, December 14, 2015 1:34 PM
> > > To: Song, Ruiling 
> > > Cc: Winiarski, Michal ; intel-
> > > g...@lists.freedesktop.org; mesa-dev@lists.freedesktop.org; Ben
> Widawsky
> > > ; dri-de...@lists.freedesktop.org
> > > Subject: Re: [Intel-gfx] [RFC libdrm] intel: Add support for softpin
> > >
> > > On Sun, Dec 13, 2015 at 7:17 PM, Song, Ruiling 
> > > wrote:
> > > >> -Original Message-
> > > >> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On
> > > Behalf
> > > >> Of Micha? Winiarski
> > > >> Sent: Wednesday, September 9, 2015 10:07 PM
> > > >> To: intel-...@lists.freedesktop.org
> > > >> Cc: Ben Widawsky ; dri-
> > > de...@lists.freedesktop.org;
> > > >> mesa-dev@lists.freedesktop.org
> > > >> Subject: [Intel-gfx] [RFC libdrm] intel: Add support for softpin
> > > >>
> > > >> Softpin allows userspace to take greater control of GPU virtual address
> > > >> space and eliminates the need of relocations. It can also be used to
> > > >> mirror addresses between GPU and CPU (shared virtual memory).
> > > >> Calls to drm_intel_bo_emit_reloc are still required to build the list 
> > > >> of
> > > >> drm_i915_gem_exec_objects at exec time, but no entries in relocs are
> > > >> created. Self-relocs don't make any sense for softpinned objects and
> can
> > > >> indicate a programming errors, thus are forbidden. Softpinned objects
> > > >> are marked by asterisk in debug dumps.
> > > >>
> > > >> Cc: Thomas Daniel 
> > > >> Cc: Kristian Høgsberg 
> > > >> Cc: Zou Nanhai 
> > > >> Cc: Michel Thierry 
> > > >> Cc: Ben Widawsky 
> > > >> Cc: Chris Wilson 
> > > >> Signed-off-by: Michał Winiarski 
> > > >> ---
> > > >>  include/drm/i915_drm.h|   4 +-
> > > >>  intel/intel_bufmgr.c  |   9 +++
> > > >>  intel/intel_bufmgr.h  |   1 +
> > > >>  intel/intel_bufmgr_gem.c  | 176
> > > >> --
> > > >>  intel/intel_bufmgr_priv.h |   7 ++
> > > >>  5 files changed, 173 insertions(+), 24 deletions(-)
> > > >
> > > > Will anybody help to push the patch to libdrm? Beignet highly depend
> on
> > > this to implement ocl2.0 svm.
> > >
> > > Is the kernel patch upstream?
> >
> > Yes, the kernel patch already merged, see:
> > http://cgit.freedesktop.org/drm-
> intel/commit/?id=506a8e87d8d2746b9e9d2433503fe237c54e4750
> >
> > I find below line of code in libdrm does not match the kernel version. The
> kernel patch defined as:
> > "#define EXEC_OBJECT_PINNED (1<<4)", but this patch defined it as (1<<3).
> 
> Please always regenerate the entire headers from the kernel sources using
> 
> $ make headers_install
> 
> Then copy the headers from the kernel's usr/include/drm to libdrm. Never
> patch i915_drm.h manually.

Thanks for the info. But the problem is libdrm still tracks such kind of header 
files.
Should this kind of header file be removed from libdrm? Or any document in 
libdrm to make this explicit?

Thanks!
Ruiling
 
> Thanks, Daniel
> 
> >
> > Hello Michal,
> >
> > Could you help to rebase the patch against:
> > [Intel-gfx] [PATCH libdrm v4 0/2] 48-bit virtual address support in i915
> > I think we need both 48bit & softpin in libdrm.
> >
> > diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
> > index ded43b1..2b99fc6 100644
> > --- a/include/drm/i915_drm.h
> > +++ b/include/drm/i915_drm.h
> > @@ -350,6 +350,7 @@ typedef struct drm_i915_irq_wait {
> >  #define I915_PARAM_REVISION  32
> >  #define I915_PARAM_SUBSLICE_TOTAL   33
> >  #define I915_PARAM_EU_TOTAL 34
> > +#define I915_PARAM_HAS_EXEC_SOFTPIN 37
> >
> >  typedef struct drm_i915_getparam {
> > int param;
> > @@ -680,7 +681,8 @@ struct drm_i915_gem_exec_object2 {
> >  #define EXEC_OBJECT_NEEDS_FENCE (1<<0)
> >  #define EXEC_OBJECT_NEEDS_GTT  (1<<1)
> >  #define EXEC_OBJECT_WRITE  (1<<2)
> > -#define __EXEC_OBJECT_UNKNOWN_FLAGS -(EXEC_OBJECT_WRITE<<1)
> > +#define EXEC_OBJECT_PINNED (1<<3)
> > +#define __EXEC_OBJECT_UNKNOWN_FLAGS -(EXEC_OBJECT_PINNED<<1)
> > __u64 flags;
> >
> > ___
> > Intel-gfx mailing list
> > intel-...@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
___
mesa-dev mailing list
mesa-dev@lists.fre

Re: [Mesa-dev] [Intel-gfx] [RFC libdrm] intel: Add support for softpin

[Song, Ruiling]

> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Micha? Winiarski
> Sent: Wednesday, September 9, 2015 10:07 PM
> To: intel-...@lists.freedesktop.org
> Cc: Ben Widawsky ; dri-de...@lists.freedesktop.org;
> mesa-dev@lists.freedesktop.org
> Subject: [Intel-gfx] [RFC libdrm] intel: Add support for softpin
> 
> Softpin allows userspace to take greater control of GPU virtual address
> space and eliminates the need of relocations. It can also be used to
> mirror addresses between GPU and CPU (shared virtual memory).
> Calls to drm_intel_bo_emit_reloc are still required to build the list of
> drm_i915_gem_exec_objects at exec time, but no entries in relocs are
> created. Self-relocs don't make any sense for softpinned objects and can
> indicate a programming errors, thus are forbidden. Softpinned objects
> are marked by asterisk in debug dumps.
> 
> Cc: Thomas Daniel 
> Cc: Kristian Høgsberg 
> Cc: Zou Nanhai 
> Cc: Michel Thierry 
> Cc: Ben Widawsky 
> Cc: Chris Wilson 
> Signed-off-by: Michał Winiarski 
> ---
>  include/drm/i915_drm.h|   4 +-
>  intel/intel_bufmgr.c  |   9 +++
>  intel/intel_bufmgr.h  |   1 +
>  intel/intel_bufmgr_gem.c  | 176
> --
>  intel/intel_bufmgr_priv.h |   7 ++
>  5 files changed, 173 insertions(+), 24 deletions(-)

Will anybody help to push the patch to libdrm? Beignet highly depend on this to 
implement ocl2.0 svm.

Thanks!
Ruiling

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

Re: [Mesa-dev] [Intel-gfx] [RFC libdrm] intel: Add support for softpin

[Song, Ruiling]

> -Original Message-
> From: hoegsb...@gmail.com [mailto:hoegsb...@gmail.com] On Behalf Of
> Kristian H?gsberg
> Sent: Monday, December 14, 2015 1:34 PM
> To: Song, Ruiling 
> Cc: Winiarski, Michal ; intel-
> g...@lists.freedesktop.org; mesa-dev@lists.freedesktop.org; Ben Widawsky
> ; dri-de...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [RFC libdrm] intel: Add support for softpin
> 
> On Sun, Dec 13, 2015 at 7:17 PM, Song, Ruiling 
> wrote:
> >> -Original Message-
> >> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On
> Behalf
> >> Of Micha? Winiarski
> >> Sent: Wednesday, September 9, 2015 10:07 PM
> >> To: intel-...@lists.freedesktop.org
> >> Cc: Ben Widawsky ; dri-
> de...@lists.freedesktop.org;
> >> mesa-dev@lists.freedesktop.org
> >> Subject: [Intel-gfx] [RFC libdrm] intel: Add support for softpin
> >>
> >> Softpin allows userspace to take greater control of GPU virtual address
> >> space and eliminates the need of relocations. It can also be used to
> >> mirror addresses between GPU and CPU (shared virtual memory).
> >> Calls to drm_intel_bo_emit_reloc are still required to build the list of
> >> drm_i915_gem_exec_objects at exec time, but no entries in relocs are
> >> created. Self-relocs don't make any sense for softpinned objects and can
> >> indicate a programming errors, thus are forbidden. Softpinned objects
> >> are marked by asterisk in debug dumps.
> >>
> >> Cc: Thomas Daniel 
> >> Cc: Kristian Høgsberg 
> >> Cc: Zou Nanhai 
> >> Cc: Michel Thierry 
> >> Cc: Ben Widawsky 
> >> Cc: Chris Wilson 
> >> Signed-off-by: Michał Winiarski 
> >> ---
> >>  include/drm/i915_drm.h|   4 +-
> >>  intel/intel_bufmgr.c  |   9 +++
> >>  intel/intel_bufmgr.h  |   1 +
> >>  intel/intel_bufmgr_gem.c  | 176
> >> --
> >>  intel/intel_bufmgr_priv.h |   7 ++
> >>  5 files changed, 173 insertions(+), 24 deletions(-)
> >
> > Will anybody help to push the patch to libdrm? Beignet highly depend on
> this to implement ocl2.0 svm.
> 
> Is the kernel patch upstream?

Yes, the kernel patch already merged, see:
http://cgit.freedesktop.org/drm-intel/commit/?id=506a8e87d8d2746b9e9d2433503fe237c54e4750

I find below line of code in libdrm does not match the kernel version. The 
kernel patch defined as:
"#define EXEC_OBJECT_PINNED (1<<4)", but this patch defined it as (1<<3).

Hello Michal,

Could you help to rebase the patch against:
[Intel-gfx] [PATCH libdrm v4 0/2] 48-bit virtual address support in i915
I think we need both 48bit & softpin in libdrm.

diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index ded43b1..2b99fc6 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -350,6 +350,7 @@ typedef struct drm_i915_irq_wait {
 #define I915_PARAM_REVISION  32
 #define I915_PARAM_SUBSLICE_TOTAL   33
 #define I915_PARAM_EU_TOTAL 34
+#define I915_PARAM_HAS_EXEC_SOFTPIN 37
 
 typedef struct drm_i915_getparam {
int param;
@@ -680,7 +681,8 @@ struct drm_i915_gem_exec_object2 {
 #define EXEC_OBJECT_NEEDS_FENCE (1<<0)
 #define EXEC_OBJECT_NEEDS_GTT  (1<<1)
 #define EXEC_OBJECT_WRITE  (1<<2)
-#define __EXEC_OBJECT_UNKNOWN_FLAGS -(EXEC_OBJECT_WRITE<<1)
+#define EXEC_OBJECT_PINNED (1<<3)
+#define __EXEC_OBJECT_UNKNOWN_FLAGS -(EXEC_OBJECT_PINNED<<1)
__u64 flags;
 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/5] nv50, nvc0: fix using uninitialized value 'templ.texture' in nvXX_blit_set_src()

[Ilia Mirkin]

While true, this isn't a real issue.

   view->pipe = *templ;
   view->pipe.reference.count = 1;
   view->pipe.texture = NULL;

texture can be uninitialized in the template. I know that your first
impulse might be "just make Coverity happy", but I don't pander to
broken tools. If the report is bogus, mark it bogus, don't add
bogosity to the code.

  -ilia


On Mon, Dec 14, 2015 at 5:14 AM, Samuel Pitoiset
 wrote:
> Field 'templ.texture' is used uninitialized when calling
> nvXX_create_texture_view(). Spotted by Coverity.
>
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/gallium/drivers/nouveau/nv50/nv50_surface.c | 1 +
>  src/gallium/drivers/nouveau/nvc0/nvc0_surface.c | 1 +
>  2 files changed, 2 insertions(+)
>
> diff --git a/src/gallium/drivers/nouveau/nv50/nv50_surface.c 
> b/src/gallium/drivers/nouveau/nv50/nv50_surface.c
> index 86be1b4..b03e893 100644
> --- a/src/gallium/drivers/nouveau/nv50/nv50_surface.c
> +++ b/src/gallium/drivers/nouveau/nv50/nv50_surface.c
> @@ -1031,6 +1031,7 @@ nv50_blit_set_src(struct nv50_blitctx *blit,
>
> target = nv50_blit_reinterpret_pipe_texture_target(res->target);
>
> +   templ.texture = NULL;
> templ.format = format;
> templ.u.tex.first_level = templ.u.tex.last_level = level;
> templ.u.tex.first_layer = templ.u.tex.last_layer = layer;
> diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_surface.c 
> b/src/gallium/drivers/nouveau/nvc0/nvc0_surface.c
> index f8e1efb..41fb82a 100644
> --- a/src/gallium/drivers/nouveau/nvc0/nvc0_surface.c
> +++ b/src/gallium/drivers/nouveau/nvc0/nvc0_surface.c
> @@ -841,6 +841,7 @@ nvc0_blit_set_src(struct nvc0_blitctx *ctx,
>
> target = nv50_blit_reinterpret_pipe_texture_target(res->target);
>
> +   templ.texture = NULL;
> templ.format = format;
> templ.u.tex.first_layer = templ.u.tex.last_layer = layer;
> templ.u.tex.first_level = templ.u.tex.last_level = level;
> --
> 2.6.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/5] nv50, nvc0: fix potential resource leak in nvXX_create_texture_view()

[Ilia Mirkin]

Again, bogus. Can't get there. I'd take a patch that asserts though,
or marks it unreachable, or just drops the default case entirely.

On Mon, Dec 14, 2015 at 5:14 AM, Samuel Pitoiset
 wrote:
> Spotted by Coverity.
>
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/gallium/drivers/nouveau/nv50/nv50_tex.c | 3 ++-
>  src/gallium/drivers/nouveau/nvc0/nvc0_tex.c | 3 ++-
>  2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/drivers/nouveau/nv50/nv50_tex.c 
> b/src/gallium/drivers/nouveau/nv50/nv50_tex.c
> index 6083ea9..9fb9dcf 100644
> --- a/src/gallium/drivers/nouveau/nv50/nv50_tex.c
> +++ b/src/gallium/drivers/nouveau/nv50/nv50_tex.c
> @@ -193,7 +193,8 @@ nv50_create_texture_view(struct pipe_context *pipe,
>break;
> default:
>NOUVEAU_ERR("invalid texture target: %d\n", mt->base.base.target);
> -  return false;
> +  FREE(view);
> +  return NULL;
> }
>
> tic[3] = (flags & NV50_TEXVIEW_FILTER_MSAA8) ? 0x2000 : 0x0030;
> diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_tex.c 
> b/src/gallium/drivers/nouveau/nvc0/nvc0_tex.c
> index 2dd100f..2503ee1 100644
> --- a/src/gallium/drivers/nouveau/nvc0/nvc0_tex.c
> +++ b/src/gallium/drivers/nouveau/nvc0/nvc0_tex.c
> @@ -195,7 +195,8 @@ nvc0_create_texture_view(struct pipe_context *pipe,
> default:
>NOUVEAU_ERR("unexpected/invalid texture target: %d\n",
>mt->base.base.target);
> -  return false;
> +  FREE(view);
> +  return NULL;
> }
>
> tic[3] = (flags & NV50_TEXVIEW_FILTER_MSAA8) ? 0x2000 : 0x0030;
> --
> 2.6.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 4/5] nv50: check return value of nouveau_object_new()

[Ilia Mirkin]

Bogus. obj will be null on failure.

On Mon, Dec 14, 2015 at 5:14 AM, Samuel Pitoiset
 wrote:
> Spotted by Coverity.
>
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/gallium/drivers/nouveau/nv50/nv84_video.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/src/gallium/drivers/nouveau/nv50/nv84_video.c 
> b/src/gallium/drivers/nouveau/nv50/nv84_video.c
> index 7a4670f..5e2489a 100644
> --- a/src/gallium/drivers/nouveau/nv50/nv84_video.c
> +++ b/src/gallium/drivers/nouveau/nv50/nv84_video.c
> @@ -756,8 +756,8 @@ firmware_present(struct pipe_screen *pscreen, enum 
> pipe_video_format codec)
> int present, ret;
>
> if (!FIRMWARE_PRESENT(checked, VP_KERN)) {
> -  nouveau_object_new(screen->channel, 0, 0x7476, NULL, 0, &obj);
> -  if (obj)
> +  ret = nouveau_object_new(screen->channel, 0, 0x7476, NULL, 0, &obj);
> +  if (!ret && obj)
>   screen->firmware_info.profiles_present |= FIRMWARE_VP_KERN;
>nouveau_object_del(&obj);
>screen->firmware_info.profiles_checked |= FIRMWARE_VP_KERN;
> @@ -765,8 +765,8 @@ firmware_present(struct pipe_screen *pscreen, enum 
> pipe_video_format codec)
>
> if (codec == PIPE_VIDEO_FORMAT_MPEG4_AVC) {
>if (!FIRMWARE_PRESENT(checked, BSP_KERN)) {
> - nouveau_object_new(screen->channel, 0, 0x74b0, NULL, 0, &obj);
> - if (obj)
> + ret = nouveau_object_new(screen->channel, 0, 0x74b0, NULL, 0, &obj);
> + if (!ret && obj)
>  screen->firmware_info.profiles_present |= FIRMWARE_BSP_KERN;
>   nouveau_object_del(&obj);
>   screen->firmware_info.profiles_checked |= FIRMWARE_BSP_KERN;
> --
> 2.6.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 86326] clEnqueueNDRangeKernel global_work_offset ignored

[bugzilla-daemon]

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

--- Comment #14 from Vedran Miletić  ---
Ronie, was this fixed?

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

Re: [Mesa-dev] [PATCH 5/5] nouveau: remove logically dead code in nouveau_vpe_mb_mv_header()

[Ilia Mirkin]

This code is old, crusty and subtle. Clearly this can't happen,
however I'd rather not remove it... if you really hate it how about a

#if 0 /* XXX */
...
#endif

I have no idea what DUAL_PRIME is, or whether it appears for frame or
field stuff. Or what that PMPEG command does for that matter.

On Mon, Dec 14, 2015 at 5:14 AM, Samuel Pitoiset
 wrote:
> frame cannot be NULL in that branch. Spotted by Coverity.
>
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/gallium/drivers/nouveau/nouveau_video.c | 2 --
>  1 file changed, 2 deletions(-)
>
> diff --git a/src/gallium/drivers/nouveau/nouveau_video.c 
> b/src/gallium/drivers/nouveau/nouveau_video.c
> index 8bb12b2..fe19bce 100644
> --- a/src/gallium/drivers/nouveau/nouveau_video.c
> +++ b/src/gallium/drivers/nouveau/nouveau_video.c
> @@ -317,8 +317,6 @@ nouveau_vpe_mb_mv_header(struct nouveau_decoder *dec,
>case PIPE_MPEG12_MO_TYPE_16x8: goto mv2;
>case PIPE_MPEG12_MO_TYPE_DUAL_PRIME: {
>base = NV17_MPEG_CMD_CHROMA_MV_HEADER_MV_SPLIT_HALF_MB;
> - if (frame)
> -base |= NV17_MPEG_CMD_CHROMA_MV_HEADER_TYPE_FRAME;
>   if (forward)
>  nouveau_vpe_mb_mv(dec, base, luma, frame, true,
>dec->picture_structure != 
> PIPE_MPEG12_PICTURE_STRUCTURE_FIELD_TOP,
> --
> 2.6.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 5/5] draw: remove clip_vertex from vertex header

[Brian Paul]

The series looks good to me.  Thanks for digging into this.

Reviewed-by: Brian Paul 



On 12/11/2015 07:31 PM, srol...@vmware.com wrote:

From: Roland Scheidegger 

vertex header had both clip_pos and clip_vertex.
We only really need one (clip_pos) because the draw llvm shader would
overwrite the position output from the vs with the viewport transformed.
However, we don't really need the second one, which was only really used
for gl_ClipVertex - if the shader didn't have that the values were just
duplicated to both clip_pos and clip_vertex. So, just use this from the vs
output instead when we actually need it.
Also change clip debug to output both the data from clip_pos and the
clipVertex output (if available).
Makes some things more complex, some things less complex, but seems more
easy to understand what clipping actually does (and what values it uses
to do its magic).
---
  src/gallium/auxiliary/draw/draw_cliptest_tmp.h |  1 -
  src/gallium/auxiliary/draw/draw_llvm.c | 21 ++--
  src/gallium/auxiliary/draw/draw_llvm.h |  4 --
  src/gallium/auxiliary/draw/draw_pipe_clip.c| 67 +++---
  src/gallium/auxiliary/draw/draw_private.h  |  1 -
  5 files changed, 54 insertions(+), 40 deletions(-)

diff --git a/src/gallium/auxiliary/draw/draw_cliptest_tmp.h 
b/src/gallium/auxiliary/draw/draw_cliptest_tmp.h
index 06c82c3..c57e5f4 100644
--- a/src/gallium/auxiliary/draw/draw_cliptest_tmp.h
+++ b/src/gallium/auxiliary/draw/draw_cliptest_tmp.h
@@ -91,7 +91,6 @@ static boolean TAG(do_cliptest)( struct pt_post_vs *pvs,
   }

   for (i = 0; i < 4; i++) {
-out->clip_vertex[i] = clipvertex[i];
  out->clip_pos[i] = position[i];
   }

diff --git a/src/gallium/auxiliary/draw/draw_llvm.c 
b/src/gallium/auxiliary/draw/draw_llvm.c
index 934f452..a966e45 100644
--- a/src/gallium/auxiliary/draw/draw_llvm.c
+++ b/src/gallium/auxiliary/draw/draw_llvm.c
@@ -378,14 +378,13 @@ static LLVMTypeRef
  create_jit_vertex_header(struct gallivm_state *gallivm, int data_elems)
  {
 LLVMTargetDataRef target = gallivm->target;
-   LLVMTypeRef elem_types[4];
+   LLVMTypeRef elem_types[3];
 LLVMTypeRef vertex_header;
 char struct_name[24];

 util_snprintf(struct_name, 23, "vertex_header%d", data_elems);

 elem_types[DRAW_JIT_VERTEX_VERTEX_ID]  = 
LLVMIntTypeInContext(gallivm->context, 32);
-   elem_types[DRAW_JIT_VERTEX_CLIP_VERTEX]  = 
LLVMArrayType(LLVMFloatTypeInContext(gallivm->context), 4);
 elem_types[DRAW_JIT_VERTEX_CLIP_POS]  = 
LLVMArrayType(LLVMFloatTypeInContext(gallivm->context), 4);
 elem_types[DRAW_JIT_VERTEX_DATA]  = LLVMArrayType(elem_types[1], 
data_elems);

@@ -407,9 +406,6 @@ create_jit_vertex_header(struct gallivm_state *gallivm, int 
data_elems)
DRAW_JIT_VERTEX_VERTEX_ID);
 */
 (void) target; /* silence unused var warning for non-debug build */
-   LP_CHECK_MEMBER_OFFSET(struct vertex_header, clip_vertex,
-  target, vertex_header,
-  DRAW_JIT_VERTEX_CLIP_VERTEX);
 LP_CHECK_MEMBER_OFFSET(struct vertex_header, clip_pos,
target, vertex_header,
DRAW_JIT_VERTEX_CLIP_POS);
@@ -1019,7 +1015,7 @@ store_clip(struct gallivm_state *gallivm,
 const struct lp_type vs_type,
 LLVMValueRef io_ptr,
 LLVMValueRef (*outputs)[TGSI_NUM_CHANNELS],
-   boolean clip_vertex, int idx)
+   int idx)
  {
 LLVMBuilderRef builder = gallivm->builder;
 LLVMValueRef soa[4];
@@ -1046,14 +1042,8 @@ store_clip(struct gallivm_state *gallivm,
 soa[2] = LLVMBuildLoad(builder, outputs[idx][2], ""); /*z0 z1 .. zn*/
 soa[3] = LLVMBuildLoad(builder, outputs[idx][3], ""); /*w0 w1 .. wn*/

-   if (clip_vertex) {
-  for (i = 0; i < vs_type.length; i++) {
- clip_ptrs[i] = draw_jit_header_clip_vertex(gallivm, io_ptrs[i]);
-  }
-   } else {
-  for (i = 0; i < vs_type.length; i++) {
- clip_ptrs[i] = draw_jit_header_clip_pos(gallivm, io_ptrs[i]);
-  }
+   for (i = 0; i < vs_type.length; i++) {
+  clip_ptrs[i] = draw_jit_header_clip_pos(gallivm, io_ptrs[i]);
 }

 lp_build_transpose_aos(gallivm, vs_type, soa, soa);
@@ -1771,8 +1761,7 @@ draw_llvm_generate(struct draw_llvm *llvm, struct 
draw_llvm_variant *variant,

if (pos != -1 && cv != -1) {
   /* store original positions in clip before further manipulation */
- store_clip(gallivm, vs_type, io, outputs, TRUE, key->clip_user ? cv : 
pos);
- store_clip(gallivm, vs_type, io, outputs, FALSE, pos);
+ store_clip(gallivm, vs_type, io, outputs, pos);

   /* do cliptest */
   if (enable_cliptest) {
diff --git a/src/gallium/auxiliary/draw/draw_llvm.h 
b/src/gallium/auxiliary/draw/draw_llvm.h
index c40df1c..f617a29 100644
--- a/src/gallium/auxiliary/draw/draw_llvm.h
+++ b/src/gallium/auxiliary/draw/draw_llvm.h
@@ -104,7 +104,6 @@ e

Re: [Mesa-dev] [PATCH 3/5] nvc0: make sure gmt programs are correctly validated

[Ilia Mirkin]

Instead take the return value and stick it into the if below.
Returning early from these functions isn't something we generally want
to do.

On Mon, Dec 14, 2015 at 5:14 AM, Samuel Pitoiset
 wrote:
> Spotted by Coverity.
>
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/gallium/drivers/nouveau/nvc0/nvc0_shader_state.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_shader_state.c 
> b/src/gallium/drivers/nouveau/nvc0/nvc0_shader_state.c
> index 7e2e999..5e69e29 100644
> --- a/src/gallium/drivers/nouveau/nvc0/nvc0_shader_state.c
> +++ b/src/gallium/drivers/nouveau/nvc0/nvc0_shader_state.c
> @@ -236,8 +236,10 @@ nvc0_gmtyprog_validate(struct nvc0_context *nvc0)
> struct nouveau_pushbuf *push = nvc0->base.pushbuf;
> struct nvc0_program *gp = nvc0->gmtyprog;
>
> -   if (gp)
> -  nvc0_program_validate(nvc0, gp);
> +   if (gp) {
> +  if (!nvc0_program_validate(nvc0, gp))
> + return;
> +   }
>
> /* we allow GPs with no code for specifying stream output state only */
> if (gp && gp->code_size) {
> --
> 2.6.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 5/5] draw: remove clip_vertex from vertex header

[Jose Fonseca]

On 12/12/15 02:31, srol...@vmware.com wrote:

From: Roland Scheidegger 

vertex header had both clip_pos and clip_vertex.
We only really need one (clip_pos) because the draw llvm shader would
overwrite the position output from the vs with the viewport transformed.
However, we don't really need the second one, which was only really used
for gl_ClipVertex - if the shader didn't have that the values were just
duplicated to both clip_pos and clip_vertex. So, just use this from the vs
output instead when we actually need it.
Also change clip debug to output both the data from clip_pos and the
clipVertex output (if available).
Makes some things more complex, some things less complex, but seems more
easy to understand what clipping actually does (and what values it uses
to do its magic).
---
  src/gallium/auxiliary/draw/draw_cliptest_tmp.h |  1 -
  src/gallium/auxiliary/draw/draw_llvm.c | 21 ++--
  src/gallium/auxiliary/draw/draw_llvm.h |  4 --
  src/gallium/auxiliary/draw/draw_pipe_clip.c| 67 +++---
  src/gallium/auxiliary/draw/draw_private.h  |  1 -
  5 files changed, 54 insertions(+), 40 deletions(-)

diff --git a/src/gallium/auxiliary/draw/draw_cliptest_tmp.h 
b/src/gallium/auxiliary/draw/draw_cliptest_tmp.h
index 06c82c3..c57e5f4 100644
--- a/src/gallium/auxiliary/draw/draw_cliptest_tmp.h
+++ b/src/gallium/auxiliary/draw/draw_cliptest_tmp.h
@@ -91,7 +91,6 @@ static boolean TAG(do_cliptest)( struct pt_post_vs *pvs,
   }

   for (i = 0; i < 4; i++) {
-out->clip_vertex[i] = clipvertex[i];
  out->clip_pos[i] = position[i];
   }

diff --git a/src/gallium/auxiliary/draw/draw_llvm.c 
b/src/gallium/auxiliary/draw/draw_llvm.c
index 934f452..a966e45 100644
--- a/src/gallium/auxiliary/draw/draw_llvm.c
+++ b/src/gallium/auxiliary/draw/draw_llvm.c
@@ -378,14 +378,13 @@ static LLVMTypeRef
  create_jit_vertex_header(struct gallivm_state *gallivm, int data_elems)
  {
 LLVMTargetDataRef target = gallivm->target;
-   LLVMTypeRef elem_types[4];
+   LLVMTypeRef elem_types[3];
 LLVMTypeRef vertex_header;
 char struct_name[24];

 util_snprintf(struct_name, 23, "vertex_header%d", data_elems);

 elem_types[DRAW_JIT_VERTEX_VERTEX_ID]  = 
LLVMIntTypeInContext(gallivm->context, 32);
-   elem_types[DRAW_JIT_VERTEX_CLIP_VERTEX]  = 
LLVMArrayType(LLVMFloatTypeInContext(gallivm->context), 4);
 elem_types[DRAW_JIT_VERTEX_CLIP_POS]  = 
LLVMArrayType(LLVMFloatTypeInContext(gallivm->context), 4);
 elem_types[DRAW_JIT_VERTEX_DATA]  = LLVMArrayType(elem_types[1], 
data_elems);

@@ -407,9 +406,6 @@ create_jit_vertex_header(struct gallivm_state *gallivm, int 
data_elems)
DRAW_JIT_VERTEX_VERTEX_ID);
 */
 (void) target; /* silence unused var warning for non-debug build */
-   LP_CHECK_MEMBER_OFFSET(struct vertex_header, clip_vertex,
-  target, vertex_header,
-  DRAW_JIT_VERTEX_CLIP_VERTEX);
 LP_CHECK_MEMBER_OFFSET(struct vertex_header, clip_pos,
target, vertex_header,
DRAW_JIT_VERTEX_CLIP_POS);
@@ -1019,7 +1015,7 @@ store_clip(struct gallivm_state *gallivm,
 const struct lp_type vs_type,
 LLVMValueRef io_ptr,
 LLVMValueRef (*outputs)[TGSI_NUM_CHANNELS],
-   boolean clip_vertex, int idx)
+   int idx)
  {
 LLVMBuilderRef builder = gallivm->builder;
 LLVMValueRef soa[4];
@@ -1046,14 +1042,8 @@ store_clip(struct gallivm_state *gallivm,
 soa[2] = LLVMBuildLoad(builder, outputs[idx][2], ""); /*z0 z1 .. zn*/
 soa[3] = LLVMBuildLoad(builder, outputs[idx][3], ""); /*w0 w1 .. wn*/

-   if (clip_vertex) {
-  for (i = 0; i < vs_type.length; i++) {
- clip_ptrs[i] = draw_jit_header_clip_vertex(gallivm, io_ptrs[i]);
-  }
-   } else {
-  for (i = 0; i < vs_type.length; i++) {
- clip_ptrs[i] = draw_jit_header_clip_pos(gallivm, io_ptrs[i]);
-  }
+   for (i = 0; i < vs_type.length; i++) {
+  clip_ptrs[i] = draw_jit_header_clip_pos(gallivm, io_ptrs[i]);
 }

 lp_build_transpose_aos(gallivm, vs_type, soa, soa);
@@ -1771,8 +1761,7 @@ draw_llvm_generate(struct draw_llvm *llvm, struct 
draw_llvm_variant *variant,

if (pos != -1 && cv != -1) {
   /* store original positions in clip before further manipulation */
- store_clip(gallivm, vs_type, io, outputs, TRUE, key->clip_user ? cv : 
pos);
- store_clip(gallivm, vs_type, io, outputs, FALSE, pos);
+ store_clip(gallivm, vs_type, io, outputs, pos);

   /* do cliptest */
   if (enable_cliptest) {
diff --git a/src/gallium/auxiliary/draw/draw_llvm.h 
b/src/gallium/auxiliary/draw/draw_llvm.h
index c40df1c..f617a29 100644
--- a/src/gallium/auxiliary/draw/draw_llvm.h
+++ b/src/gallium/auxiliary/draw/draw_llvm.h
@@ -104,7 +104,6 @@ enum {

  enum {
 DRAW_JIT_VERTEX_VERTEX_ID = 0,
-   DRAW_JIT_VERTEX_CLIP_VERTEX,
 DRAW

Re: [Mesa-dev] [PATCH 5/5] nouveau: remove logically dead code in nouveau_vpe_mb_mv_header()

[Pierre Moreau]

On 11:14 AM - Dec 14 2015, Samuel Pitoiset wrote:
> frame cannot be NULL in that branch. Spotted by Coverity.
> 
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/gallium/drivers/nouveau/nouveau_video.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/src/gallium/drivers/nouveau/nouveau_video.c 
> b/src/gallium/drivers/nouveau/nouveau_video.c
> index 8bb12b2..fe19bce 100644
> --- a/src/gallium/drivers/nouveau/nouveau_video.c
> +++ b/src/gallium/drivers/nouveau/nouveau_video.c
> @@ -317,8 +317,6 @@ nouveau_vpe_mb_mv_header(struct nouveau_decoder *dec,
>case PIPE_MPEG12_MO_TYPE_16x8: goto mv2;
>case PIPE_MPEG12_MO_TYPE_DUAL_PRIME: {
>base = NV17_MPEG_CMD_CHROMA_MV_HEADER_MV_SPLIT_HALF_MB;
> - if (frame)
> -base |= NV17_MPEG_CMD_CHROMA_MV_HEADER_TYPE_FRAME;

If frame can't be NULL, shouldn't you only remove the `if` statement as you're
otherwise removing used code as well?


Pierre


>   if (forward)
>  nouveau_vpe_mb_mv(dec, base, luma, frame, true,
>dec->picture_structure != 
> PIPE_MPEG12_PICTURE_STRUCTURE_FIELD_TOP,
> -- 
> 2.6.4
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] docs: Replace sourceforge logo with a text link

[Andreas Boll]

Fixes the following Lintian (Debian package checker) error:

privacy-breach-logo

  usr/share/doc/mesa-common-dev/contents.html
(http://sourceforge.net/sflogo.php?group_id=3&type=1)
  usr/share/doc/mesa-common-dev/thanks.html
(http://sourceforge.net/sflogo.php?group_id=3&type=1)

The extended description of this tag is:

This package creates a potential privacy breach by fetching a logo
at runtime.

Before using a local copy you should check that the logo is suitable
for main. You can get help with determining this by posting a link to
the logo and a copy of, or a link to, the logo copyright and license
information to the debian-legal mailing list.

Please replace any scripts, images, or other remote resources with
non-remote resources. It is preferable to replace them with text and
links but local copies of the remote resources are also acceptable as
long as they don't also make calls to remote services. Please ensure
that the remote resources are suitable for Debian main before making
local copies of them.

Severity: serious, Certainty: possible

Check: files, Type: binary, udeb

Signed-off-by: Andreas Boll 
---
 docs/contents.html | 3 +--
 docs/thanks.html   | 4 +---
 2 files changed, 2 insertions(+), 5 deletions(-)

diff --git a/docs/contents.html b/docs/contents.html
index 6612cbe..5e0f514 100644
--- a/docs/contents.html
+++ b/docs/contents.html
@@ -96,8 +96,7 @@
 
 
 http://sourceforge.net";
-target="_parent">http://sourceforge.net/sflogo.php?group_id=3&type=1";
-width="88" height="31" align="bottom" alt="Sourceforge.net" border="0">
+target="_parent">sourceforge.net
 
 
 
diff --git a/docs/thanks.html b/docs/thanks.html
index 29a41e4..685cb31 100644
--- a/docs/thanks.html
+++ b/docs/thanks.html
@@ -42,9 +42,7 @@ Tungsten Graphics, Inc. have supported the ongoing 
development of Mesa.
 The
 http://www.mesa3d.org";>Mesa
 website is hosted by
-http://sourceforge.net";>
-http://sourceforge.net/sflogo.php?group_id=3&type=1";
-width="88" height="31" align="bottom" alt="Sourceforge.net" border="0">
+http://sourceforge.net";>sourceforge.net.
 
 
 
-- 
2.1.4

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

Re: [Mesa-dev] [PATCH 2/5] nv50, nvc0: fix potential resource leak in nvXX_create_texture_view()

[Samuel Pitoiset]

On 12/14/2015 04:01 PM, Ilia Mirkin wrote:

Again, bogus. Can't get there. I'd take a patch that asserts though,
or marks it unreachable, or just drops the default case entirely.


Make it unreachable is fine by me.



On Mon, Dec 14, 2015 at 5:14 AM, Samuel Pitoiset
 wrote:

Spotted by Coverity.

Signed-off-by: Samuel Pitoiset 
---
  src/gallium/drivers/nouveau/nv50/nv50_tex.c | 3 ++-
  src/gallium/drivers/nouveau/nvc0/nvc0_tex.c | 3 ++-
  2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/gallium/drivers/nouveau/nv50/nv50_tex.c 
b/src/gallium/drivers/nouveau/nv50/nv50_tex.c
index 6083ea9..9fb9dcf 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_tex.c
+++ b/src/gallium/drivers/nouveau/nv50/nv50_tex.c
@@ -193,7 +193,8 @@ nv50_create_texture_view(struct pipe_context *pipe,
break;
 default:
NOUVEAU_ERR("invalid texture target: %d\n", mt->base.base.target);
-  return false;
+  FREE(view);
+  return NULL;
 }

 tic[3] = (flags & NV50_TEXVIEW_FILTER_MSAA8) ? 0x2000 : 0x0030;
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_tex.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_tex.c
index 2dd100f..2503ee1 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_tex.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_tex.c
@@ -195,7 +195,8 @@ nvc0_create_texture_view(struct pipe_context *pipe,
 default:
NOUVEAU_ERR("unexpected/invalid texture target: %d\n",
mt->base.base.target);
-  return false;
+  FREE(view);
+  return NULL;
 }

 tic[3] = (flags & NV50_TEXVIEW_FILTER_MSAA8) ? 0x2000 : 0x0030;
--
2.6.4

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


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

Re: [Mesa-dev] [PATCH 3/5] nvc0: make sure gmt programs are correctly validated

[Samuel Pitoiset]

On 12/14/2015 04:04 PM, Ilia Mirkin wrote:

Instead take the return value and stick it into the if below.
Returning early from these functions isn't something we generally want
to do.


We already return at the same point for vertex programs, but I can 
definitely move this below.




On Mon, Dec 14, 2015 at 5:14 AM, Samuel Pitoiset
 wrote:

Spotted by Coverity.

Signed-off-by: Samuel Pitoiset 
---
  src/gallium/drivers/nouveau/nvc0/nvc0_shader_state.c | 6 --
  1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_shader_state.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_shader_state.c
index 7e2e999..5e69e29 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_shader_state.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_shader_state.c
@@ -236,8 +236,10 @@ nvc0_gmtyprog_validate(struct nvc0_context *nvc0)
 struct nouveau_pushbuf *push = nvc0->base.pushbuf;
 struct nvc0_program *gp = nvc0->gmtyprog;

-   if (gp)
-  nvc0_program_validate(nvc0, gp);
+   if (gp) {
+  if (!nvc0_program_validate(nvc0, gp))
+ return;
+   }

 /* we allow GPs with no code for specifying stream output state only */
 if (gp && gp->code_size) {
--
2.6.4

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


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

Re: [Mesa-dev] [PATCH 4/5] nv50: check return value of nouveau_object_new()

[Samuel Pitoiset]

On 12/14/2015 04:05 PM, Ilia Mirkin wrote:

Bogus. obj will be null on failure.


Well, checking the return value instead of obj seems better tbh, because 
we do that in the rest of the code.




On Mon, Dec 14, 2015 at 5:14 AM, Samuel Pitoiset
 wrote:

Spotted by Coverity.

Signed-off-by: Samuel Pitoiset 
---
  src/gallium/drivers/nouveau/nv50/nv84_video.c | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/gallium/drivers/nouveau/nv50/nv84_video.c 
b/src/gallium/drivers/nouveau/nv50/nv84_video.c
index 7a4670f..5e2489a 100644
--- a/src/gallium/drivers/nouveau/nv50/nv84_video.c
+++ b/src/gallium/drivers/nouveau/nv50/nv84_video.c
@@ -756,8 +756,8 @@ firmware_present(struct pipe_screen *pscreen, enum 
pipe_video_format codec)
 int present, ret;

 if (!FIRMWARE_PRESENT(checked, VP_KERN)) {
-  nouveau_object_new(screen->channel, 0, 0x7476, NULL, 0, &obj);
-  if (obj)
+  ret = nouveau_object_new(screen->channel, 0, 0x7476, NULL, 0, &obj);
+  if (!ret && obj)
   screen->firmware_info.profiles_present |= FIRMWARE_VP_KERN;
nouveau_object_del(&obj);
screen->firmware_info.profiles_checked |= FIRMWARE_VP_KERN;
@@ -765,8 +765,8 @@ firmware_present(struct pipe_screen *pscreen, enum 
pipe_video_format codec)

 if (codec == PIPE_VIDEO_FORMAT_MPEG4_AVC) {
if (!FIRMWARE_PRESENT(checked, BSP_KERN)) {
- nouveau_object_new(screen->channel, 0, 0x74b0, NULL, 0, &obj);
- if (obj)
+ ret = nouveau_object_new(screen->channel, 0, 0x74b0, NULL, 0, &obj);
+ if (!ret && obj)
  screen->firmware_info.profiles_present |= FIRMWARE_BSP_KERN;
   nouveau_object_del(&obj);
   screen->firmware_info.profiles_checked |= FIRMWARE_BSP_KERN;
--
2.6.4

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


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

Re: [Mesa-dev] [PATCH 3/5] nvc0: make sure gmt programs are correctly validated

[Ilia Mirkin]

On Mon, Dec 14, 2015 at 11:02 AM, Samuel Pitoiset
 wrote:
>
>
> On 12/14/2015 04:04 PM, Ilia Mirkin wrote:
>>
>> Instead take the return value and stick it into the if below.
>> Returning early from these functions isn't something we generally want
>> to do.
>
>
> We already return at the same point for vertex programs, but I can
> definitely move this below.

If you return, whatever was set before stays. That's not great.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 4/5] nv50: check return value of nouveau_object_new()

[Ilia Mirkin]

On Mon, Dec 14, 2015 at 11:04 AM, Samuel Pitoiset
 wrote:
>
>
> On 12/14/2015 04:05 PM, Ilia Mirkin wrote:
>>
>> Bogus. obj will be null on failure.
>
>
> Well, checking the return value instead of obj seems better tbh, because we
> do that in the rest of the code.

Can ret = 0 but obj still be null? If not, feel free to flip it.

>
>
>>
>> On Mon, Dec 14, 2015 at 5:14 AM, Samuel Pitoiset
>>  wrote:
>>>
>>> Spotted by Coverity.
>>>
>>> Signed-off-by: Samuel Pitoiset 
>>> ---
>>>   src/gallium/drivers/nouveau/nv50/nv84_video.c | 8 
>>>   1 file changed, 4 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/src/gallium/drivers/nouveau/nv50/nv84_video.c
>>> b/src/gallium/drivers/nouveau/nv50/nv84_video.c
>>> index 7a4670f..5e2489a 100644
>>> --- a/src/gallium/drivers/nouveau/nv50/nv84_video.c
>>> +++ b/src/gallium/drivers/nouveau/nv50/nv84_video.c
>>> @@ -756,8 +756,8 @@ firmware_present(struct pipe_screen *pscreen, enum
>>> pipe_video_format codec)
>>>  int present, ret;
>>>
>>>  if (!FIRMWARE_PRESENT(checked, VP_KERN)) {
>>> -  nouveau_object_new(screen->channel, 0, 0x7476, NULL, 0, &obj);
>>> -  if (obj)
>>> +  ret = nouveau_object_new(screen->channel, 0, 0x7476, NULL, 0,
>>> &obj);
>>> +  if (!ret && obj)
>>>screen->firmware_info.profiles_present |= FIRMWARE_VP_KERN;
>>> nouveau_object_del(&obj);
>>> screen->firmware_info.profiles_checked |= FIRMWARE_VP_KERN;
>>> @@ -765,8 +765,8 @@ firmware_present(struct pipe_screen *pscreen, enum
>>> pipe_video_format codec)
>>>
>>>  if (codec == PIPE_VIDEO_FORMAT_MPEG4_AVC) {
>>> if (!FIRMWARE_PRESENT(checked, BSP_KERN)) {
>>> - nouveau_object_new(screen->channel, 0, 0x74b0, NULL, 0, &obj);
>>> - if (obj)
>>> + ret = nouveau_object_new(screen->channel, 0, 0x74b0, NULL, 0,
>>> &obj);
>>> + if (!ret && obj)
>>>   screen->firmware_info.profiles_present |=
>>> FIRMWARE_BSP_KERN;
>>>nouveau_object_del(&obj);
>>>screen->firmware_info.profiles_checked |= FIRMWARE_BSP_KERN;
>>> --
>>> 2.6.4
>>>
>>> ___
>>> mesa-dev mailing list
>>> mesa-dev@lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>
> --
> -Samuel
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 5/5] nouveau: remove logically dead code in nouveau_vpe_mb_mv_header()

[Samuel Pitoiset]

On 12/14/2015 04:48 PM, Pierre Moreau wrote:

On 11:14 AM - Dec 14 2015, Samuel Pitoiset wrote:

frame cannot be NULL in that branch. Spotted by Coverity.

Signed-off-by: Samuel Pitoiset 
---
  src/gallium/drivers/nouveau/nouveau_video.c | 2 --
  1 file changed, 2 deletions(-)

diff --git a/src/gallium/drivers/nouveau/nouveau_video.c 
b/src/gallium/drivers/nouveau/nouveau_video.c
index 8bb12b2..fe19bce 100644
--- a/src/gallium/drivers/nouveau/nouveau_video.c
+++ b/src/gallium/drivers/nouveau/nouveau_video.c
@@ -317,8 +317,6 @@ nouveau_vpe_mb_mv_header(struct nouveau_decoder *dec,
case PIPE_MPEG12_MO_TYPE_16x8: goto mv2;
case PIPE_MPEG12_MO_TYPE_DUAL_PRIME: {
base = NV17_MPEG_CMD_CHROMA_MV_HEADER_MV_SPLIT_HALF_MB;
- if (frame)
-base |= NV17_MPEG_CMD_CHROMA_MV_HEADER_TYPE_FRAME;


If frame can't be NULL, shouldn't you only remove the `if` statement as you're
otherwise removing used code as well?


Wrong commit message... frame is *always* NULL in that branch...




Pierre



   if (forward)
  nouveau_vpe_mb_mv(dec, base, luma, frame, true,
dec->picture_structure != 
PIPE_MPEG12_PICTURE_STRUCTURE_FIELD_TOP,
--
2.6.4

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


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

[Mesa-dev] [PATCH 4/6] gallium/drivers/ilo: Use unsigned for loop index

[Edward O'Callaghan]

Found-by: Coccinelle
Signed-off-by: Edward O'Callaghan 
---
 src/gallium/drivers/ilo/core/ilo_builder.c   |  8 
 src/gallium/drivers/ilo/shader/ilo_shader_fs.c   | 16 
 src/gallium/drivers/ilo/shader/ilo_shader_vs.c   |  4 ++--
 src/gallium/drivers/ilo/shader/toy_legalize_ra.c |  4 ++--
 4 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/src/gallium/drivers/ilo/core/ilo_builder.c 
b/src/gallium/drivers/ilo/core/ilo_builder.c
index 9d51951..629f239 100644
--- a/src/gallium/drivers/ilo/core/ilo_builder.c
+++ b/src/gallium/drivers/ilo/core/ilo_builder.c
@@ -333,7 +333,7 @@ ilo_builder_init(struct ilo_builder *builder,
  const struct ilo_dev *dev,
  struct intel_winsys *winsys)
 {
-   int i;
+   unsigned int i;
 
assert(ilo_is_zeroed(builder, sizeof(*builder)));
 
@@ -366,7 +366,7 @@ ilo_builder_init(struct ilo_builder *builder,
 void
 ilo_builder_reset(struct ilo_builder *builder)
 {
-   int i;
+   unsigned int i;
 
for (i = 0; i < ILO_BUILDER_WRITER_COUNT; i++)
   ilo_builder_writer_reset(builder, i);
@@ -382,7 +382,7 @@ ilo_builder_reset(struct ilo_builder *builder)
 bool
 ilo_builder_begin(struct ilo_builder *builder)
 {
-   int i;
+   unsigned int i;
 
for (i = 0; i < ILO_BUILDER_WRITER_COUNT; i++) {
   if (!ilo_builder_writer_alloc_and_map(builder, i)) {
@@ -407,7 +407,7 @@ struct intel_bo *
 ilo_builder_end(struct ilo_builder *builder, unsigned *used)
 {
struct ilo_builder_writer *bat;
-   int i;
+   unsigned int i;
 
ilo_builder_batch_patch_sba(builder);
 
diff --git a/src/gallium/drivers/ilo/shader/ilo_shader_fs.c 
b/src/gallium/drivers/ilo/shader/ilo_shader_fs.c
index 5250115..9a43514 100644
--- a/src/gallium/drivers/ilo/shader/ilo_shader_fs.c
+++ b/src/gallium/drivers/ilo/shader/ilo_shader_fs.c
@@ -266,7 +266,7 @@ fs_lower_opcode_tgsi_indirect_const(struct 
fs_compile_context *fcc,
struct toy_inst *inst;
struct toy_src desc, real_src[4];
struct toy_dst tmp, real_dst[4];
-   int i;
+   unsigned int i;
 
tsrc_transpose(idx, real_src);
 
@@ -319,7 +319,7 @@ fs_lower_opcode_tgsi_const_pcb(struct fs_compile_context 
*fcc,
const int grf_subreg = (idx.val32 & 1) * 16;
struct toy_src src;
struct toy_dst real_dst[4];
-   int i;
+   unsigned int i;
 
if (!fcc->variant->use_pcb || dim != 0 || idx.file != TOY_FILE_IMM ||
grf >= fcc->first_attr_grf)
@@ -350,7 +350,7 @@ fs_lower_opcode_tgsi_const_gen6(struct fs_compile_context 
*fcc,
struct toy_inst *inst;
struct toy_src desc;
struct toy_dst tmp, real_dst[4];
-   int i;
+   unsigned int i;
 
if (fs_lower_opcode_tgsi_const_pcb(fcc, dst, dim, idx))
   return;
@@ -396,7 +396,7 @@ fs_lower_opcode_tgsi_const_gen7(struct fs_compile_context 
*fcc,
struct toy_src desc;
struct toy_inst *inst;
struct toy_dst tmp, real_dst[4];
-   int i;
+   unsigned int i;
 
if (fs_lower_opcode_tgsi_const_pcb(fcc, dst, dim, idx))
   return;
@@ -1168,7 +1168,7 @@ fs_lower_opcode_derivative(struct toy_compiler *tc, 
struct toy_inst *inst)
 {
struct toy_dst dst[4];
struct toy_src src[4];
-   int i;
+   unsigned int i;
 
tdst_transpose(inst->dst, dst);
tsrc_transpose(inst->src[0], src);
@@ -1257,7 +1257,7 @@ fs_lower_opcode_kil(struct toy_compiler *tc, struct 
toy_inst *inst)
}
else {
   struct toy_src src[4];
-  int i;
+  unsigned int i;
 
   tsrc_transpose(inst->src[0], src);
   /* mask out killed pixels */
@@ -1583,7 +1583,7 @@ fs_write_fb(struct fs_compile_context *fcc)
 static void
 fs_setup_shader_out(struct ilo_shader *sh, const struct toy_tgsi *tgsi)
 {
-   int i;
+   unsigned int i;
 
sh->out.count = tgsi->num_outputs;
for (i = 0; i < tgsi->num_outputs; i++) {
@@ -1603,7 +1603,7 @@ static void
 fs_setup_shader_in(struct ilo_shader *sh, const struct toy_tgsi *tgsi,
bool flatshade)
 {
-   int i;
+   unsigned int i;
 
sh->in.count = tgsi->num_inputs;
for (i = 0; i < tgsi->num_inputs; i++) {
diff --git a/src/gallium/drivers/ilo/shader/ilo_shader_vs.c 
b/src/gallium/drivers/ilo/shader/ilo_shader_vs.c
index 46a7e6f..73cccb2 100644
--- a/src/gallium/drivers/ilo/shader/ilo_shader_vs.c
+++ b/src/gallium/drivers/ilo/shader/ilo_shader_vs.c
@@ -522,7 +522,7 @@ vs_prepare_tgsi_sampling(struct vs_compile_context *vcc,
   if (num_coords >= 3) {
  struct toy_dst tmp, max;
  struct toy_src abs_coords[3];
- int i;
+ unsigned int i;
 
  tmp = tc_alloc_tmp(tc);
  max = tdst_writemask(tmp, TOY_WRITEMASK_W);
@@ -804,7 +804,7 @@ static int
 vs_collect_outputs(struct vs_compile_context *vcc, struct toy_src *outs)
 {
const struct toy_tgsi *tgsi = &vcc->tgsi;
-   int i;
+   unsigned int i;
 
for (i = 0; i < vcc->shader->out.count; i++) {
   const int slot = vcc->output_map[i];
diff --git a/src/gallium/drivers/ilo/shader/toy_legalize_ra.c 
b/src/gallium/drivers/ilo/shader/toy_legalize_ra.c
i

[Mesa-dev] [PATCH 1/6] gallium: Remove unnecessary semicolons

[Edward O'Callaghan]

Found-by: Coccinelle
Signed-off-by: Edward O'Callaghan 
---
 src/gallium/auxiliary/draw/draw_pipe_aaline.c  | 2 +-
 src/gallium/auxiliary/gallivm/lp_bld_swizzle.c | 2 +-
 src/gallium/auxiliary/nir/tgsi_to_nir.c| 2 +-
 src/gallium/auxiliary/util/u_surface.c | 2 +-
 src/gallium/auxiliary/vl/vl_mpeg12_decoder.c   | 2 +-
 src/gallium/state_trackers/nine/swapchain9.c   | 2 +-
 src/gallium/state_trackers/omx/entrypoint.c| 2 +-
 src/gallium/state_trackers/vdpau/mixer.c   | 2 +-
 8 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/src/gallium/auxiliary/draw/draw_pipe_aaline.c 
b/src/gallium/auxiliary/draw/draw_pipe_aaline.c
index 877db59..4a676b7 100644
--- a/src/gallium/auxiliary/draw/draw_pipe_aaline.c
+++ b/src/gallium/auxiliary/draw/draw_pipe_aaline.c
@@ -937,7 +937,7 @@ draw_aaline_prepare_outputs(struct draw_context *draw,
const struct pipe_rasterizer_state *rast = draw->rasterizer;
 
/* update vertex attrib info */
-   aaline->pos_slot = draw_current_shader_position_output(draw);;
+   aaline->pos_slot = draw_current_shader_position_output(draw);
 
if (!rast->line_smooth)
   return;
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_swizzle.c 
b/src/gallium/auxiliary/gallivm/lp_bld_swizzle.c
index b1aef71..f571838 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_swizzle.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_swizzle.c
@@ -720,7 +720,7 @@ lp_build_transpose_aos_n(struct gallivm_state *gallivm,
 
   default:
  assert(0);
-   };
+   }
 }
 
 
diff --git a/src/gallium/auxiliary/nir/tgsi_to_nir.c 
b/src/gallium/auxiliary/nir/tgsi_to_nir.c
index 5def6d3..5cbe8e9 100644
--- a/src/gallium/auxiliary/nir/tgsi_to_nir.c
+++ b/src/gallium/auxiliary/nir/tgsi_to_nir.c
@@ -1951,7 +1951,7 @@ tgsi_processor_to_shader_stage(unsigned processor)
case TGSI_PROCESSOR_COMPUTE:   return MESA_SHADER_COMPUTE;
default:
   unreachable("invalid TGSI processor");
-   };
+   }
 }
 
 struct nir_shader *
diff --git a/src/gallium/auxiliary/util/u_surface.c 
b/src/gallium/auxiliary/util/u_surface.c
index 6aa44f9..67da59f 100644
--- a/src/gallium/auxiliary/util/u_surface.c
+++ b/src/gallium/auxiliary/util/u_surface.c
@@ -600,7 +600,7 @@ is_box_inside_resource(const struct pipe_resource *res,
   depth = res->array_size;
   assert(res->array_size % 6 == 0);
   break;
-   case PIPE_MAX_TEXTURE_TYPES:;
+   case PIPE_MAX_TEXTURE_TYPES:
}
 
return box->x >= 0 &&
diff --git a/src/gallium/auxiliary/vl/vl_mpeg12_decoder.c 
b/src/gallium/auxiliary/vl/vl_mpeg12_decoder.c
index f5bb3a0..b5c7045 100644
--- a/src/gallium/auxiliary/vl/vl_mpeg12_decoder.c
+++ b/src/gallium/auxiliary/vl/vl_mpeg12_decoder.c
@@ -792,7 +792,7 @@ vl_mpeg12_end_frame(struct pipe_video_codec *decoder,
   for (j = 0; j < VL_MAX_REF_FRAMES; ++j) {
  if (!ref_frames[j] || !ref_frames[j][i]) continue;
 
- vb[2] = vl_vb_get_mv(&buf->vertex_stream, j);;
+ vb[2] = vl_vb_get_mv(&buf->vertex_stream, j);
  dec->context->set_vertex_buffers(dec->context, 0, 3, vb);
 
  vl_mc_render_ref(i ? &dec->mc_c : &dec->mc_y, &buf->mc[i], 
ref_frames[j][i]);
diff --git a/src/gallium/state_trackers/nine/swapchain9.c 
b/src/gallium/state_trackers/nine/swapchain9.c
index 3f5be26..3b1a7a4 100644
--- a/src/gallium/state_trackers/nine/swapchain9.c
+++ b/src/gallium/state_trackers/nine/swapchain9.c
@@ -790,7 +790,7 @@ NineSwapChain9_Present( struct NineSwapChain9 *This,
 case D3DSWAPEFFECT_FLIP:
 UNTESTED(4);
 case D3DSWAPEFFECT_DISCARD:
-/* rotate the queue */;
+/* rotate the queue */
 pipe_resource_reference(&res, This->buffers[0]->base.resource);
 for (i = 1; i <= This->params.BackBufferCount; i++) {
 NineSurface9_SetResourceResize(This->buffers[i - 1],
diff --git a/src/gallium/state_trackers/omx/entrypoint.c 
b/src/gallium/state_trackers/omx/entrypoint.c
index da9ca10..afcbd97 100644
--- a/src/gallium/state_trackers/omx/entrypoint.c
+++ b/src/gallium/state_trackers/omx/entrypoint.c
@@ -137,7 +137,7 @@ OMX_ERRORTYPE omx_workaround_Destructor(OMX_COMPONENTTYPE 
*comp)
priv->state = OMX_StateInvalid;
tsem_up(priv->messageSem);
 
-   /* wait for thread to exit */;
+   /* wait for thread to exit */
pthread_join(priv->messageHandlerThread, NULL);
 
return omx_base_component_Destructor(comp);
diff --git a/src/gallium/state_trackers/vdpau/mixer.c 
b/src/gallium/state_trackers/vdpau/mixer.c
index c0b1ecc..dec79ff 100644
--- a/src/gallium/state_trackers/vdpau/mixer.c
+++ b/src/gallium/state_trackers/vdpau/mixer.c
@@ -294,7 +294,7 @@ VdpStatus vlVdpVideoMixerRender(VdpVideoMixer mixer,
default:
   pipe_mutex_unlock(vmixer->device->mutex);
   return VDP_STATUS_INVALID_VIDEO_MIXER_PICTURE_STRUCTURE;
-   };
+   }
 
if (deinterlace != VL_COMPOSITOR_WEAVE && vmixer->deint.enabled &&
video_surface_past_count > 1 && video_surface_future_count > 0) {
-- 
2.5

[Mesa-dev] [PATCH 5/6] gallium/drivers/r600: Use unsigned for loop index

[Edward O'Callaghan]

Found-by: Coccinelle
Signed-off-by: Edward O'Callaghan 
---
 src/gallium/drivers/r600/r600_shader.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/src/gallium/drivers/r600/r600_shader.c 
b/src/gallium/drivers/r600/r600_shader.c
index db53eb4..e7932bf 100644
--- a/src/gallium/drivers/r600/r600_shader.c
+++ b/src/gallium/drivers/r600/r600_shader.c
@@ -394,7 +394,7 @@ static int tgsi_last_instruction(unsigned writemask)
 static int tgsi_is_supported(struct r600_shader_ctx *ctx)
 {
struct tgsi_full_instruction *i = &ctx->parse.FullToken.FullInstruction;
-   int j;
+   unsigned int j;
 
if (i->Instruction.NumDstRegs > 1 && i->Instruction.Opcode != 
TGSI_OPCODE_DFRACEXP) {
R600_ERR("too many dst (%d)\n", i->Instruction.NumDstRegs);
@@ -1166,7 +1166,7 @@ static int allocate_system_value_inputs(struct 
r600_shader_ctx *ctx, int gpr_off
 */
 static int evergreen_gpr_count(struct r600_shader_ctx *ctx)
 {
-   int i;
+   unsigned int i;
int num_baryc;
struct tgsi_parse_context parse;
 
@@ -1585,7 +1585,7 @@ static int fetch_gs_input(struct r600_shader_ctx *ctx, 
struct tgsi_full_src_regi
 static int tgsi_split_gs_inputs(struct r600_shader_ctx *ctx)
 {
struct tgsi_full_instruction *inst = 
&ctx->parse.FullToken.FullInstruction;
-   int i;
+   unsigned int i;
 
for (i = 0; i < inst->Instruction.NumSrcRegs; i++) {
struct tgsi_full_src_register *src = &inst->Src[i];
@@ -1854,7 +1854,7 @@ static int fetch_tcs_output(struct r600_shader_ctx *ctx, 
struct tgsi_full_src_re
 static int tgsi_split_lds_inputs(struct r600_shader_ctx *ctx)
 {
struct tgsi_full_instruction *inst = 
&ctx->parse.FullToken.FullInstruction;
-   int i;
+   unsigned int i;
 
for (i = 0; i < inst->Instruction.NumSrcRegs; i++) {
struct tgsi_full_src_register *src = &inst->Src[i];
@@ -2784,7 +2784,7 @@ static int r600_tess_factor_read(struct r600_shader_ctx 
*ctx,
 
 static int r600_emit_tess_factor(struct r600_shader_ctx *ctx)
 {
-   int i;
+   unsigned int i;
int stride, outer_comps, inner_comps;
int tessinner_idx = -1, tessouter_idx = -1;
int r;
@@ -4791,7 +4791,7 @@ static int tgsi_lit(struct r600_shader_ctx *ctx)
{
int chan;
int sel;
-   int i;
+   unsigned int i;
 
if (ctx->bc->chip_class == CAYMAN) {
for (i = 0; i < 3; i++) {
@@ -7925,7 +7925,7 @@ static int tgsi_exp(struct r600_shader_ctx *ctx)
struct tgsi_full_instruction *inst = 
&ctx->parse.FullToken.FullInstruction;
struct r600_bytecode_alu alu;
int r;
-   int i;
+   unsigned int i;
 
/* result.x = 2^floor(src); */
if (inst->Dst[0].Register.WriteMask & 1) {
@@ -8054,7 +8054,7 @@ static int tgsi_log(struct r600_shader_ctx *ctx)
struct tgsi_full_instruction *inst = 
&ctx->parse.FullToken.FullInstruction;
struct r600_bytecode_alu alu;
int r;
-   int i;
+   unsigned int i;
 
/* result.x = floor(log2(|src|)); */
if (inst->Dst[0].Register.WriteMask & 1) {
@@ -8781,7 +8781,7 @@ static int tgsi_bgnloop(struct r600_shader_ctx *ctx)
 
 static int tgsi_endloop(struct r600_shader_ctx *ctx)
 {
-   int i;
+   unsigned int i;
 
r600_bytecode_add_cfinst(ctx->bc, CF_OP_LOOP_END);
 
-- 
2.5.0

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

[Mesa-dev] [PATCH 2/6] gallium/drivers: Remove unnecessary semicolons

[Edward O'Callaghan]

Found-by: Coccinelle
Signed-off-by: Edward O'Callaghan 
---
 src/gallium/drivers/i915/i915_state.c | 2 +-
 src/gallium/drivers/ilo/shader/ilo_shader_vs.c| 2 +-
 src/gallium/drivers/llvmpipe/lp_test_blend.c  | 2 +-
 src/gallium/drivers/llvmpipe/lp_test_conv.c   | 2 +-
 src/gallium/drivers/r300/compiler/r500_fragprog.c | 2 +-
 src/gallium/drivers/r600/r600_shader.c| 2 +-
 src/gallium/drivers/radeonsi/cik_sdma.c   | 2 +-
 src/gallium/drivers/softpipe/sp_query.c   | 2 +-
 src/gallium/drivers/svga/svga_cmd.c   | 4 ++--
 src/gallium/drivers/vc4/vc4_program.c | 2 +-
 10 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/src/gallium/drivers/i915/i915_state.c 
b/src/gallium/drivers/i915/i915_state.c
index 6ba9646..d1661fe 100644
--- a/src/gallium/drivers/i915/i915_state.c
+++ b/src/gallium/drivers/i915/i915_state.c
@@ -423,7 +423,7 @@ i915_prepare_vertex_sampling(struct i915_context *i915)
  for (j = view->u.tex.first_level; j <= tex->last_level; j++) {
 mip_offsets[j] = i915_texture_offset(i915_tex, j , 0 /* FIXME 
depth */);
 row_stride[j] = i915_tex->stride;
-img_stride[j] = 0; /* FIXME */;
+img_stride[j] = 0; /* FIXME */
  }
 
  draw_set_mapped_texture(i915->draw,
diff --git a/src/gallium/drivers/ilo/shader/ilo_shader_vs.c 
b/src/gallium/drivers/ilo/shader/ilo_shader_vs.c
index a29baab..46a7e6f 100644
--- a/src/gallium/drivers/ilo/shader/ilo_shader_vs.c
+++ b/src/gallium/drivers/ilo/shader/ilo_shader_vs.c
@@ -126,7 +126,7 @@ vs_lower_opcode_tgsi_const_gen6(struct vs_compile_context 
*vcc,
tc_MOV(tc, block_offsets, idx);
 
msg_type = GEN6_MSG_DP_OWORD_DUAL_BLOCK_READ;
-   msg_ctrl = GEN6_MSG_DP_OWORD_DUAL_BLOCK_SIZE_1;;
+   msg_ctrl = GEN6_MSG_DP_OWORD_DUAL_BLOCK_SIZE_1;
msg_len = 2;
 
desc = tsrc_imm_mdesc_data_port(tc, false, msg_len, 1, true, false,
diff --git a/src/gallium/drivers/llvmpipe/lp_test_blend.c 
b/src/gallium/drivers/llvmpipe/lp_test_blend.c
index 7b19174..9139b83 100644
--- a/src/gallium/drivers/llvmpipe/lp_test_blend.c
+++ b/src/gallium/drivers/llvmpipe/lp_test_blend.c
@@ -184,7 +184,7 @@ add_blend_test(struct gallivm_state *gallivm,
 
LLVMBuildStore(builder, res, res_ptr);
 
-   LLVMBuildRetVoid(builder);;
+   LLVMBuildRetVoid(builder);
 
gallivm_verify_function(gallivm, func);
 
diff --git a/src/gallium/drivers/llvmpipe/lp_test_conv.c 
b/src/gallium/drivers/llvmpipe/lp_test_conv.c
index a30f35c..02a6319 100644
--- a/src/gallium/drivers/llvmpipe/lp_test_conv.c
+++ b/src/gallium/drivers/llvmpipe/lp_test_conv.c
@@ -140,7 +140,7 @@ add_conv_test(struct gallivm_state *gallivm,
   LLVMBuildStore(builder, dst[i], ptr);
}
 
-   LLVMBuildRetVoid(builder);;
+   LLVMBuildRetVoid(builder);
 
gallivm_verify_function(gallivm, func);
 
diff --git a/src/gallium/drivers/r300/compiler/r500_fragprog.c 
b/src/gallium/drivers/r300/compiler/r500_fragprog.c
index 88aad8a..4c415af 100644
--- a/src/gallium/drivers/r300/compiler/r500_fragprog.c
+++ b/src/gallium/drivers/r300/compiler/r500_fragprog.c
@@ -384,7 +384,7 @@ void r500FragmentProgramDump(struct radeon_compiler *c, 
void *user)
 case R500_INST_TYPE_OUT: str = "OUT"; break;
 case R500_INST_TYPE_FC: str = "FC"; break;
 case R500_INST_TYPE_TEX: str = "TEX"; break;
-};
+}
 fprintf(stderr,"%s %s %s %s %s ", str,
inst & R500_INST_TEX_SEM_WAIT ? "TEX_WAIT" : "",
inst & R500_INST_LAST ? "LAST" : "",
diff --git a/src/gallium/drivers/r600/r600_shader.c 
b/src/gallium/drivers/r600/r600_shader.c
index d411b0b..db53eb4 100644
--- a/src/gallium/drivers/r600/r600_shader.c
+++ b/src/gallium/drivers/r600/r600_shader.c
@@ -4424,7 +4424,7 @@ static int cayman_mul_double_instr(struct r600_shader_ctx 
*ctx)
memset(&alu, 0, sizeof(struct r600_bytecode_alu));
alu.op = ctx->inst_info->op;
for (j = 0; j < inst->Instruction.NumSrcRegs; j++) {
-   r600_bytecode_src(&alu.src[j], &ctx->src[j], k 
* 2 + ((i == 3) ? 0 : 1));;
+   r600_bytecode_src(&alu.src[j], &ctx->src[j], k 
* 2 + ((i == 3) ? 0 : 1));
}
alu.dst.sel = t1;
alu.dst.chan = i;
diff --git a/src/gallium/drivers/radeonsi/cik_sdma.c 
b/src/gallium/drivers/radeonsi/cik_sdma.c
index 2de237b..105a1b2 100644
--- a/src/gallium/drivers/radeonsi/cik_sdma.c
+++ b/src/gallium/drivers/radeonsi/cik_sdma.c
@@ -196,7 +196,7 @@ static void cik_sdma_copy_tile(struct si_context *ctx,
(tile_split << 11) | (mt << 8) | (array_mode << 3) |
lbpe;
cs->buf[cs->cdw++] = y << 16; /* | x */
-   cs->buf[cs->cdw++] = 0; /* z */;
+   cs->buf[cs->cdw++] = 0; /* z */
cs->buf[cs->cdw++] = addr & 0xfffc;
c

[Mesa-dev] [PATCH 3/6] gallium: Use unsigned for loop index

[Edward O'Callaghan]

Found-by: Coccinelle
Signed-off-by: Edward O'Callaghan 
---
 src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c 
b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
index 09c1b37..f070ce7 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
@@ -1197,7 +1197,7 @@ get_soa_array_offsets(struct lp_build_context *uint_bld,
 
if (need_perelement_offset) {
   LLVMValueRef pixel_offsets;
-  int i;
+  unsigned int i;
  /* build pixel offset vector: {0, 1, 2, 3, ...} */
   pixel_offsets = uint_bld->undef;
   for (i = 0; i < uint_bld->type.length; i++) {
@@ -1809,7 +1809,7 @@ emit_store_double_chan(struct lp_build_tgsi_context 
*bld_base,
struct gallivm_state *gallivm = bld_base->base.gallivm;
LLVMBuilderRef builder = gallivm->builder;
struct lp_build_context *float_bld = &bld_base->base;
-   int i;
+   unsigned int i;
LLVMValueRef temp, temp2;
LLVMValueRef shuffles[8];
LLVMValueRef shuffles2[8];
@@ -2713,7 +2713,7 @@ static boolean
 near_end_of_shader(struct lp_build_tgsi_soa_context *bld,
int pc)
 {
-   int i;
+   unsigned int i;
 
for (i = 0; i < 5; i++) {
   unsigned opcode;
-- 
2.5.0

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

[Mesa-dev] [PATCH 6/6] gallium/drivers/svga: Use unsigned for loop index

[Edward O'Callaghan]

Found-by: Coccinelle
Signed-off-by: Edward O'Callaghan 
---
 src/gallium/drivers/svga/svga_tgsi_insn.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/src/gallium/drivers/svga/svga_tgsi_insn.c 
b/src/gallium/drivers/svga/svga_tgsi_insn.c
index dbb90f7..1c7097f 100644
--- a/src/gallium/drivers/svga/svga_tgsi_insn.c
+++ b/src/gallium/drivers/svga/svga_tgsi_insn.c
@@ -166,7 +166,7 @@ scalar(struct src_register src, unsigned comp)
 static boolean
 svga_arl_needs_adjustment( const struct svga_shader_emitter *emit )
 {
-   int i;
+   unsigned int i;
 
for (i = 0; i < emit->num_arl_consts; ++i) {
   if (emit->arl_consts[i].arl_num == emit->current_arl)
@@ -179,7 +179,7 @@ svga_arl_needs_adjustment( const struct svga_shader_emitter 
*emit )
 static int
 svga_arl_adjustment( const struct svga_shader_emitter *emit )
 {
-   int i;
+   unsigned int i;
 
for (i = 0; i < emit->num_arl_consts; ++i) {
   if (emit->arl_consts[i].arl_num == emit->current_arl)
@@ -1175,7 +1175,7 @@ emit_div(struct svga_shader_emitter *emit,
const struct src_register src1 =
   translate_src_register(emit, &insn->Src[1] );
SVGA3dShaderDestToken temp = get_temp( emit );
-   int i;
+   unsigned int i;
 
/* For each enabled element, perform a RCP instruction.  Note that
 * RCP is scalar in SVGA3D:
@@ -1822,7 +1822,7 @@ emit_tex_swizzle(struct svga_shader_emitter *emit,
const unsigned swizzleIn[4] = {swizzle_x, swizzle_y, swizzle_z, swizzle_w};
unsigned srcSwizzle[4];
unsigned srcWritemask = 0x0, zeroWritemask = 0x0, oneWritemask = 0x0;
-   int i;
+   unsigned int i;
 
/* build writemasks and srcSwizzle terms */
for (i = 0; i < 4; i++) {
@@ -3371,7 +3371,7 @@ emit_light_twoside(struct svga_shader_emitter *emit)
struct src_register back[2];
SVGA3dShaderDestToken color[2];
int count = emit->internal_color_count;
-   int i;
+   unsigned int i;
SVGA3dShaderInstToken if_token;
 
if (count == 0)
@@ -3698,7 +3698,7 @@ static boolean
 pre_parse_add_indirect( struct svga_shader_emitter *emit,
 int num, int current_arl)
 {
-   int i;
+   unsigned int i;
assert(num < 0);
 
for (i = 0; i < emit->num_arl_consts; ++i) {
-- 
2.5.0

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

[Mesa-dev] Further Coccinelle inspired cleanups

[Edward O'Callaghan]

The following patch series continues on what can be done with
Coccinelle to clean up Mesa3D house keeping duties. On a good
note we have a pretty clean tree for the fairly trivial runs
so far.

 [PATCH 1/6] gallium: Remove unnecessary semicolons
 [PATCH 2/6] gallium/drivers: Remove unnecessary semicolons
 [PATCH 3/6] gallium: Use unsigned for loop index
 [PATCH 4/6] gallium/drivers/ilo: Use unsigned for loop index
 [PATCH 5/6] gallium/drivers/r600: Use unsigned for loop index
 [PATCH 6/6] gallium/drivers/svga: Use unsigned for loop index
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 4/5] nv50: check return value of nouveau_object_new()

[Samuel Pitoiset]

On 12/14/2015 05:07 PM, Ilia Mirkin wrote:

On Mon, Dec 14, 2015 at 11:04 AM, Samuel Pitoiset
 wrote:



On 12/14/2015 04:05 PM, Ilia Mirkin wrote:


Bogus. obj will be null on failure.



Well, checking the return value instead of obj seems better tbh, because we
do that in the rest of the code.


Can ret = 0 but obj still be null? If not, feel free to flip it.


No, when ret == 0, object is not NULL. I'll flip that.








On Mon, Dec 14, 2015 at 5:14 AM, Samuel Pitoiset
 wrote:


Spotted by Coverity.

Signed-off-by: Samuel Pitoiset 
---
   src/gallium/drivers/nouveau/nv50/nv84_video.c | 8 
   1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/gallium/drivers/nouveau/nv50/nv84_video.c
b/src/gallium/drivers/nouveau/nv50/nv84_video.c
index 7a4670f..5e2489a 100644
--- a/src/gallium/drivers/nouveau/nv50/nv84_video.c
+++ b/src/gallium/drivers/nouveau/nv50/nv84_video.c
@@ -756,8 +756,8 @@ firmware_present(struct pipe_screen *pscreen, enum
pipe_video_format codec)
  int present, ret;

  if (!FIRMWARE_PRESENT(checked, VP_KERN)) {
-  nouveau_object_new(screen->channel, 0, 0x7476, NULL, 0, &obj);
-  if (obj)
+  ret = nouveau_object_new(screen->channel, 0, 0x7476, NULL, 0,
&obj);
+  if (!ret && obj)
screen->firmware_info.profiles_present |= FIRMWARE_VP_KERN;
 nouveau_object_del(&obj);
 screen->firmware_info.profiles_checked |= FIRMWARE_VP_KERN;
@@ -765,8 +765,8 @@ firmware_present(struct pipe_screen *pscreen, enum
pipe_video_format codec)

  if (codec == PIPE_VIDEO_FORMAT_MPEG4_AVC) {
 if (!FIRMWARE_PRESENT(checked, BSP_KERN)) {
- nouveau_object_new(screen->channel, 0, 0x74b0, NULL, 0, &obj);
- if (obj)
+ ret = nouveau_object_new(screen->channel, 0, 0x74b0, NULL, 0,
&obj);
+ if (!ret && obj)
   screen->firmware_info.profiles_present |=
FIRMWARE_BSP_KERN;
nouveau_object_del(&obj);
screen->firmware_info.profiles_checked |= FIRMWARE_BSP_KERN;
--
2.6.4

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



--
-Samuel


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

[Mesa-dev] [PATCH v2 1/3] nv50, nvc0: make use of unreachable() when invalid texture target happens

[Samuel Pitoiset]

Spotted by Coverity.

Signed-off-by: Samuel Pitoiset 
---
 src/gallium/drivers/nouveau/nv50/nv50_tex.c | 3 +--
 src/gallium/drivers/nouveau/nvc0/nvc0_tex.c | 4 +---
 2 files changed, 2 insertions(+), 5 deletions(-)

diff --git a/src/gallium/drivers/nouveau/nv50/nv50_tex.c 
b/src/gallium/drivers/nouveau/nv50/nv50_tex.c
index 6083ea9..c3f4336 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_tex.c
+++ b/src/gallium/drivers/nouveau/nv50/nv50_tex.c
@@ -192,8 +192,7 @@ nv50_create_texture_view(struct pipe_context *pipe,
   tic[2] |= NV50_TIC_2_TARGET_BUFFER | NV50_TIC_2_LINEAR;
   break;
default:
-  NOUVEAU_ERR("invalid texture target: %d\n", mt->base.base.target);
-  return false;
+  unreachable("unexpected/invalid texture target");
}
 
tic[3] = (flags & NV50_TEXVIEW_FILTER_MSAA8) ? 0x2000 : 0x0030;
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_tex.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_tex.c
index 2dd100f..74090ce 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_tex.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_tex.c
@@ -193,9 +193,7 @@ nvc0_create_texture_view(struct pipe_context *pipe,
   tic[2] |= NV50_TIC_2_TARGET_CUBE_ARRAY;
   break;
default:
-  NOUVEAU_ERR("unexpected/invalid texture target: %d\n",
-  mt->base.base.target);
-  return false;
+  unreachable("unexpected/invalid texture target");
}
 
tic[3] = (flags & NV50_TEXVIEW_FILTER_MSAA8) ? 0x2000 : 0x0030;
-- 
2.6.4

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

[Mesa-dev] [PATCH v2 2/3] nvc0: check return value of nvc0_program_validate()

[Samuel Pitoiset]

Spotted by Coverity.

Signed-off-by: Samuel Pitoiset 
---
 src/gallium/drivers/nouveau/nvc0/nvc0_shader_state.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_shader_state.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_shader_state.c
index 7e2e999..7c3d03e 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_shader_state.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_shader_state.c
@@ -236,11 +236,8 @@ nvc0_gmtyprog_validate(struct nvc0_context *nvc0)
struct nouveau_pushbuf *push = nvc0->base.pushbuf;
struct nvc0_program *gp = nvc0->gmtyprog;
 
-   if (gp)
-  nvc0_program_validate(nvc0, gp);
-
/* we allow GPs with no code for specifying stream output state only */
-   if (gp && gp->code_size) {
+   if (gp && gp->code_size && nvc0_program_validate(nvc0, gp)) {
   const bool gp_selects_layer = !!(gp->hdr[13] & (1 << 9));
 
   BEGIN_NVC0(push, NVC0_3D(MACRO_GP_SELECT), 1);
-- 
2.6.4

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

[Mesa-dev] [PATCH v2 3/3] nv50: check return value of nouveau_object_new()

[Samuel Pitoiset]

When ret == 0, obj is not NULL. Spotted by Coverity.

Signed-off-by: Samuel Pitoiset 
---
 src/gallium/drivers/nouveau/nv50/nv84_video.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/gallium/drivers/nouveau/nv50/nv84_video.c 
b/src/gallium/drivers/nouveau/nv50/nv84_video.c
index 7a4670f..88655db 100644
--- a/src/gallium/drivers/nouveau/nv50/nv84_video.c
+++ b/src/gallium/drivers/nouveau/nv50/nv84_video.c
@@ -756,8 +756,8 @@ firmware_present(struct pipe_screen *pscreen, enum 
pipe_video_format codec)
int present, ret;
 
if (!FIRMWARE_PRESENT(checked, VP_KERN)) {
-  nouveau_object_new(screen->channel, 0, 0x7476, NULL, 0, &obj);
-  if (obj)
+  ret = nouveau_object_new(screen->channel, 0, 0x7476, NULL, 0, &obj);
+  if (!ret)
  screen->firmware_info.profiles_present |= FIRMWARE_VP_KERN;
   nouveau_object_del(&obj);
   screen->firmware_info.profiles_checked |= FIRMWARE_VP_KERN;
@@ -765,8 +765,8 @@ firmware_present(struct pipe_screen *pscreen, enum 
pipe_video_format codec)
 
if (codec == PIPE_VIDEO_FORMAT_MPEG4_AVC) {
   if (!FIRMWARE_PRESENT(checked, BSP_KERN)) {
- nouveau_object_new(screen->channel, 0, 0x74b0, NULL, 0, &obj);
- if (obj)
+ ret = nouveau_object_new(screen->channel, 0, 0x74b0, NULL, 0, &obj);
+ if (!ret)
 screen->firmware_info.profiles_present |= FIRMWARE_BSP_KERN;
  nouveau_object_del(&obj);
  screen->firmware_info.profiles_checked |= FIRMWARE_BSP_KERN;
-- 
2.6.4

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

Re: [Mesa-dev] [PATCH v2 2/3] nvc0: check return value of nvc0_program_validate()

[Ilia Mirkin]

No, gp->code_size is set by the validation. You need to put that last.

On Mon, Dec 14, 2015 at 11:51 AM, Samuel Pitoiset
 wrote:
> Spotted by Coverity.
>
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/gallium/drivers/nouveau/nvc0/nvc0_shader_state.c | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_shader_state.c 
> b/src/gallium/drivers/nouveau/nvc0/nvc0_shader_state.c
> index 7e2e999..7c3d03e 100644
> --- a/src/gallium/drivers/nouveau/nvc0/nvc0_shader_state.c
> +++ b/src/gallium/drivers/nouveau/nvc0/nvc0_shader_state.c
> @@ -236,11 +236,8 @@ nvc0_gmtyprog_validate(struct nvc0_context *nvc0)
> struct nouveau_pushbuf *push = nvc0->base.pushbuf;
> struct nvc0_program *gp = nvc0->gmtyprog;
>
> -   if (gp)
> -  nvc0_program_validate(nvc0, gp);
> -
> /* we allow GPs with no code for specifying stream output state only */
> -   if (gp && gp->code_size) {
> +   if (gp && gp->code_size && nvc0_program_validate(nvc0, gp)) {
>const bool gp_selects_layer = !!(gp->hdr[13] & (1 << 9));
>
>BEGIN_NVC0(push, NVC0_3D(MACRO_GP_SELECT), 1);
> --
> 2.6.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2 3/3] nv50: check return value of nouveau_object_new()

[Ilia Mirkin]

Reviewed-by: Ilia Mirkin 

On Mon, Dec 14, 2015 at 11:51 AM, Samuel Pitoiset
 wrote:
> When ret == 0, obj is not NULL. Spotted by Coverity.
>
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/gallium/drivers/nouveau/nv50/nv84_video.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/src/gallium/drivers/nouveau/nv50/nv84_video.c 
> b/src/gallium/drivers/nouveau/nv50/nv84_video.c
> index 7a4670f..88655db 100644
> --- a/src/gallium/drivers/nouveau/nv50/nv84_video.c
> +++ b/src/gallium/drivers/nouveau/nv50/nv84_video.c
> @@ -756,8 +756,8 @@ firmware_present(struct pipe_screen *pscreen, enum 
> pipe_video_format codec)
> int present, ret;
>
> if (!FIRMWARE_PRESENT(checked, VP_KERN)) {
> -  nouveau_object_new(screen->channel, 0, 0x7476, NULL, 0, &obj);
> -  if (obj)
> +  ret = nouveau_object_new(screen->channel, 0, 0x7476, NULL, 0, &obj);
> +  if (!ret)
>   screen->firmware_info.profiles_present |= FIRMWARE_VP_KERN;
>nouveau_object_del(&obj);
>screen->firmware_info.profiles_checked |= FIRMWARE_VP_KERN;
> @@ -765,8 +765,8 @@ firmware_present(struct pipe_screen *pscreen, enum 
> pipe_video_format codec)
>
> if (codec == PIPE_VIDEO_FORMAT_MPEG4_AVC) {
>if (!FIRMWARE_PRESENT(checked, BSP_KERN)) {
> - nouveau_object_new(screen->channel, 0, 0x74b0, NULL, 0, &obj);
> - if (obj)
> + ret = nouveau_object_new(screen->channel, 0, 0x74b0, NULL, 0, &obj);
> + if (!ret)
>  screen->firmware_info.profiles_present |= FIRMWARE_BSP_KERN;
>   nouveau_object_del(&obj);
>   screen->firmware_info.profiles_checked |= FIRMWARE_BSP_KERN;
> --
> 2.6.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2 1/3] nv50, nvc0: make use of unreachable() when invalid texture target happens

[Ilia Mirkin]

Reviewed-by: Ilia Mirkin 

On Mon, Dec 14, 2015 at 11:51 AM, Samuel Pitoiset
 wrote:
> Spotted by Coverity.
>
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/gallium/drivers/nouveau/nv50/nv50_tex.c | 3 +--
>  src/gallium/drivers/nouveau/nvc0/nvc0_tex.c | 4 +---
>  2 files changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/src/gallium/drivers/nouveau/nv50/nv50_tex.c 
> b/src/gallium/drivers/nouveau/nv50/nv50_tex.c
> index 6083ea9..c3f4336 100644
> --- a/src/gallium/drivers/nouveau/nv50/nv50_tex.c
> +++ b/src/gallium/drivers/nouveau/nv50/nv50_tex.c
> @@ -192,8 +192,7 @@ nv50_create_texture_view(struct pipe_context *pipe,
>tic[2] |= NV50_TIC_2_TARGET_BUFFER | NV50_TIC_2_LINEAR;
>break;
> default:
> -  NOUVEAU_ERR("invalid texture target: %d\n", mt->base.base.target);
> -  return false;
> +  unreachable("unexpected/invalid texture target");
> }
>
> tic[3] = (flags & NV50_TEXVIEW_FILTER_MSAA8) ? 0x2000 : 0x0030;
> diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_tex.c 
> b/src/gallium/drivers/nouveau/nvc0/nvc0_tex.c
> index 2dd100f..74090ce 100644
> --- a/src/gallium/drivers/nouveau/nvc0/nvc0_tex.c
> +++ b/src/gallium/drivers/nouveau/nvc0/nvc0_tex.c
> @@ -193,9 +193,7 @@ nvc0_create_texture_view(struct pipe_context *pipe,
>tic[2] |= NV50_TIC_2_TARGET_CUBE_ARRAY;
>break;
> default:
> -  NOUVEAU_ERR("unexpected/invalid texture target: %d\n",
> -  mt->base.base.target);
> -  return false;
> +  unreachable("unexpected/invalid texture target");
> }
>
> tic[3] = (flags & NV50_TEXVIEW_FILTER_MSAA8) ? 0x2000 : 0x0030;
> --
> 2.6.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2 2/3] nvc0: check return value of nvc0_program_validate()

[Pierre Moreau]

On 11:56 AM - Dec 14 2015, Ilia Mirkin wrote:
> No, gp->code_size is set by the validation. You need to put that last.

IIRC, you can't assume in which order the compiler will decide to evaluate the
different expressions being AND'ed.

> 
> On Mon, Dec 14, 2015 at 11:51 AM, Samuel Pitoiset
>  wrote:
> > Spotted by Coverity.
> >
> > Signed-off-by: Samuel Pitoiset 
> > ---
> >  src/gallium/drivers/nouveau/nvc0/nvc0_shader_state.c | 5 +
> >  1 file changed, 1 insertion(+), 4 deletions(-)
> >
> > diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_shader_state.c 
> > b/src/gallium/drivers/nouveau/nvc0/nvc0_shader_state.c
> > index 7e2e999..7c3d03e 100644
> > --- a/src/gallium/drivers/nouveau/nvc0/nvc0_shader_state.c
> > +++ b/src/gallium/drivers/nouveau/nvc0/nvc0_shader_state.c
> > @@ -236,11 +236,8 @@ nvc0_gmtyprog_validate(struct nvc0_context *nvc0)
> > struct nouveau_pushbuf *push = nvc0->base.pushbuf;
> > struct nvc0_program *gp = nvc0->gmtyprog;
> >
> > -   if (gp)
> > -  nvc0_program_validate(nvc0, gp);
> > -
> > /* we allow GPs with no code for specifying stream output state only */
> > -   if (gp && gp->code_size) {
> > +   if (gp && gp->code_size && nvc0_program_validate(nvc0, gp)) {
> >const bool gp_selects_layer = !!(gp->hdr[13] & (1 << 9));
> >
> >BEGIN_NVC0(push, NVC0_3D(MACRO_GP_SELECT), 1);
> > --
> > 2.6.4
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/mesa-dev
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2 2/3] nvc0: check return value of nvc0_program_validate()

[Ilia Mirkin]

On Mon, Dec 14, 2015 at 11:59 AM, Pierre Moreau  wrote:
> On 11:56 AM - Dec 14 2015, Ilia Mirkin wrote:
>> No, gp->code_size is set by the validation. You need to put that last.
>
> IIRC, you can't assume in which order the compiler will decide to evaluate the
> different expressions being AND'ed.

Actually you can. It's known as "short-circuiting".

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

[Mesa-dev] [PATCH 1/3] mesa/main: use BITSET_FOREACH_SET in perf_monitor_result_size

[Nicolai Hähnle]

From: Nicolai Hähnle 

This should make the code both faster and slightly clearer.
---
 src/mesa/main/performance_monitor.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/src/mesa/main/performance_monitor.c 
b/src/mesa/main/performance_monitor.c
index 98dfbea..43529b2 100644
--- a/src/mesa/main/performance_monitor.c
+++ b/src/mesa/main/performance_monitor.c
@@ -591,11 +591,10 @@ perf_monitor_result_size(const struct gl_context *ctx,
 
for (group = 0; group < ctx->PerfMonitor.NumGroups; group++) {
   const struct gl_perf_monitor_group *g = &ctx->PerfMonitor.Groups[group];
-  for (counter = 0; counter < g->NumCounters; counter++) {
- const struct gl_perf_monitor_counter *c = &g->Counters[counter];
+  BITSET_WORD tmp;
 
- if (!BITSET_TEST(m->ActiveCounters[group], counter))
-continue;
+  BITSET_FOREACH_SET(counter, tmp, m->ActiveCounters[group], 
g->NumCounters) {
+ const struct gl_perf_monitor_counter *c = &g->Counters[counter];
 
  size += sizeof(uint32_t); /* Group ID */
  size += sizeof(uint32_t); /* Counter ID */
-- 
2.5.0

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

[Mesa-dev] [PATCH 3/3] radeonsi: fix perfcounter selection for SI_PC_MULTI_BLOCK layouts

[Nicolai Hähnle]

From: Nicolai Hähnle 

The incorrectly computed register count caused lockups.
---
 src/gallium/drivers/radeonsi/si_perfcounter.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/radeonsi/si_perfcounter.c 
b/src/gallium/drivers/radeonsi/si_perfcounter.c
index a0ddff6..7ee1dae 100644
--- a/src/gallium/drivers/radeonsi/si_perfcounter.c
+++ b/src/gallium/drivers/radeonsi/si_perfcounter.c
@@ -436,7 +436,7 @@ static void si_pc_emit_select(struct r600_common_context 
*ctx,
 
dw = count + regs->num_prelude;
if (count >= regs->num_multi)
-   count += regs->num_multi;
+   dw += regs->num_multi;
radeon_set_uconfig_reg_seq(cs, regs->select0, dw);
for (idx = 0; idx < regs->num_prelude; ++idx)
radeon_emit(cs, 0);
-- 
2.5.0

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

Re: [Mesa-dev] [PATCH v2 2/3] nvc0: check return value of nvc0_program_validate()

[Samuel Pitoiset]

On 12/14/2015 05:56 PM, Ilia Mirkin wrote:

No, gp->code_size is set by the validation. You need to put that last.


Right, it's set by nvc0_program_translate().



On Mon, Dec 14, 2015 at 11:51 AM, Samuel Pitoiset
 wrote:

Spotted by Coverity.

Signed-off-by: Samuel Pitoiset 
---
  src/gallium/drivers/nouveau/nvc0/nvc0_shader_state.c | 5 +
  1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_shader_state.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_shader_state.c
index 7e2e999..7c3d03e 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_shader_state.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_shader_state.c
@@ -236,11 +236,8 @@ nvc0_gmtyprog_validate(struct nvc0_context *nvc0)
 struct nouveau_pushbuf *push = nvc0->base.pushbuf;
 struct nvc0_program *gp = nvc0->gmtyprog;

-   if (gp)
-  nvc0_program_validate(nvc0, gp);
-
 /* we allow GPs with no code for specifying stream output state only */
-   if (gp && gp->code_size) {
+   if (gp && gp->code_size && nvc0_program_validate(nvc0, gp)) {
const bool gp_selects_layer = !!(gp->hdr[13] & (1 << 9));

BEGIN_NVC0(push, NVC0_3D(MACRO_GP_SELECT), 1);
--
2.6.4

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


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

[Mesa-dev] [PATCH 2/3] gallium/radeon: remove unnecessary test in r600_pc_query_add_result

[Nicolai Hähnle]

From: Nicolai Hähnle 

This test is a left-over of the initial development. It is unneeded and
misleading, so let's get rid of it.
---
 src/gallium/drivers/radeon/r600_perfcounter.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/src/gallium/drivers/radeon/r600_perfcounter.c 
b/src/gallium/drivers/radeon/r600_perfcounter.c
index a835aee..fad7bde 100644
--- a/src/gallium/drivers/radeon/r600_perfcounter.c
+++ b/src/gallium/drivers/radeon/r600_perfcounter.c
@@ -202,9 +202,6 @@ static void r600_pc_query_add_result(struct 
r600_common_context *ctx,
for (i = 0; i < query->num_counters; ++i) {
struct r600_pc_counter *counter = &query->counters[i];
 
-   if (counter->base == ~0)
-   continue;
-
for (j = 0; j < counter->dwords; ++j) {
uint32_t value = results[counter->base + j * 
counter->stride];
result->batch[i].u32 += value;
-- 
2.5.0

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

[Mesa-dev] [PATCH v3] nvc0: check return value of nvc0_program_validate()

[Samuel Pitoiset]

Spotted by Coverity.

Signed-off-by: Samuel Pitoiset 
---
 src/gallium/drivers/nouveau/nvc0/nvc0_shader_state.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_shader_state.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_shader_state.c
index 7e2e999..5e84ca9 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_shader_state.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_shader_state.c
@@ -236,11 +236,8 @@ nvc0_gmtyprog_validate(struct nvc0_context *nvc0)
struct nouveau_pushbuf *push = nvc0->base.pushbuf;
struct nvc0_program *gp = nvc0->gmtyprog;
 
-   if (gp)
-  nvc0_program_validate(nvc0, gp);
-
/* we allow GPs with no code for specifying stream output state only */
-   if (gp && gp->code_size) {
+   if (gp && nvc0_program_validate(nvc0, gp) && gp->code_size) {
   const bool gp_selects_layer = !!(gp->hdr[13] & (1 << 9));
 
   BEGIN_NVC0(push, NVC0_3D(MACRO_GP_SELECT), 1);
-- 
2.6.4

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

Re: [Mesa-dev] [PATCH v3] nvc0: check return value of nvc0_program_validate()

[Ilia Mirkin]

Reviewed-by: Ilia Mirkin 

On Mon, Dec 14, 2015 at 12:07 PM, Samuel Pitoiset
 wrote:
> Spotted by Coverity.
>
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/gallium/drivers/nouveau/nvc0/nvc0_shader_state.c | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_shader_state.c 
> b/src/gallium/drivers/nouveau/nvc0/nvc0_shader_state.c
> index 7e2e999..5e84ca9 100644
> --- a/src/gallium/drivers/nouveau/nvc0/nvc0_shader_state.c
> +++ b/src/gallium/drivers/nouveau/nvc0/nvc0_shader_state.c
> @@ -236,11 +236,8 @@ nvc0_gmtyprog_validate(struct nvc0_context *nvc0)
> struct nouveau_pushbuf *push = nvc0->base.pushbuf;
> struct nvc0_program *gp = nvc0->gmtyprog;
>
> -   if (gp)
> -  nvc0_program_validate(nvc0, gp);
> -
> /* we allow GPs with no code for specifying stream output state only */
> -   if (gp && gp->code_size) {
> +   if (gp && nvc0_program_validate(nvc0, gp) && gp->code_size) {
>const bool gp_selects_layer = !!(gp->hdr[13] & (1 << 9));
>
>BEGIN_NVC0(push, NVC0_3D(MACRO_GP_SELECT), 1);
> --
> 2.6.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] gallium r300 driver for PowerPC

[Nicolai Hähnle]

On 14.12.2015 04:10, Eero Tamminen wrote:

On 12/14/2015 10:44 AM, Herminio Hernandez, Jr. wrote:

I am new to this list. I have been trying to see if I can fix or at
least pin point an issue with Radeon r300 driver failing on PowerPC
systems. This has been a problem for a while and I would like to help
to get this fixed. I have done some debugging with valgrind and I
think I may see where the issue is but I would to have someone double
check what I am doing. So when I set my Default Depth to 16 I do get
3D acceleration but when I set to the default of 24 it breaks.
Valgrind reports memory leaks when I run glxgears with a Default Depth
of 24 but shows no definite memory leaks with a Depth of 16. I then
got the source code and created a dev environment andnran glxgears
through valgrind with my default depth of 24 and saw similar memory
leaks. Here is a sample of what I am seeing.

==25273== 108 (12 direct, 96 indirect) bytes in 1 blocks are
definitely lost in loss record 54 of 78
==25273==at 0xFFB2868: malloc (vg_replace_malloc.c:299)
==25273==by 0xED0457B: ???
==25273==by 0xEEC6F3B: ???
==25273==by 0xE95A78B: ???
==25273==by 0xED7DF7F: ???
==25273==by 0xED7D5DB: ???
==25273==by 0xEC5B377: ???
==25273==by 0xEC567EB: ???
==25273==by 0xFDEDFD3: dri2CreateScreen (dri2_glx.c:1235)
==25273==by 0xFDB866F: AllocAndFetchScreenConfigs (glxext.c:799)
==25273==by 0xFDB866F: __glXInitialize (glxext.c:910)
==25273==by 0xFDB36F3: GetGLXPrivScreenConfig.part.2 (glxcmds.c:172)
==25273==by 0xFDB396B: GetGLXPrivScreenConfig (glxcmds.c:168)
==25273==by 0xFDB396B: glXChooseVisual (glxcmds.c:1249)

It looks like the files in the src/glx branch is where the issue is. I
am attaching the summary portion of the output I got from valgrind. Am
I heading in the right direction?


Install debug symbols for the libraries that Valgrind is complaining
about, to see what actually leaks.  Because they all come from through
GetGLXPrivScreenConfig(), I think this is something (inconsequential) in
your X libraries, not Mesa.


This is below dri2CreateScreen in the call stack, so it's actually quite 
plausible that it's in the driver. Make sure you have those debug symbols.


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

Re: [Mesa-dev] [PATCH 3/3] radeonsi: fix perfcounter selection for SI_PC_MULTI_BLOCK layouts

[eocallaghan]

On 2015-12-15 04:06, Nicolai Hähnle wrote:

From: Nicolai Hähnle 

The incorrectly computed register count caused lockups.
---
 src/gallium/drivers/radeonsi/si_perfcounter.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/radeonsi/si_perfcounter.c
b/src/gallium/drivers/radeonsi/si_perfcounter.c
index a0ddff6..7ee1dae 100644
--- a/src/gallium/drivers/radeonsi/si_perfcounter.c
+++ b/src/gallium/drivers/radeonsi/si_perfcounter.c
@@ -436,7 +436,7 @@ static void si_pc_emit_select(struct
r600_common_context *ctx,

dw = count + regs->num_prelude;
if (count >= regs->num_multi)
-   count += regs->num_multi;
+   dw += regs->num_multi;
radeon_set_uconfig_reg_seq(cs, regs->select0, dw);
for (idx = 0; idx < regs->num_prelude; ++idx)
radeon_emit(cs, 0);


This series is,

Reviewed-by: Edward O'Callaghan 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 6/6] gallium/drivers/svga: Use unsigned for loop index

[Brian Paul]

Instead of "unsigned int" you can just use "unsigned", but this is OK.

With addressing the patch 1 issue, this series is:
Reviewed-by: Brian Paul 


On 12/14/2015 09:27 AM, Edward O'Callaghan wrote:

Found-by: Coccinelle
Signed-off-by: Edward O'Callaghan 
---
  src/gallium/drivers/svga/svga_tgsi_insn.c | 12 ++--
  1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/src/gallium/drivers/svga/svga_tgsi_insn.c 
b/src/gallium/drivers/svga/svga_tgsi_insn.c
index dbb90f7..1c7097f 100644
--- a/src/gallium/drivers/svga/svga_tgsi_insn.c
+++ b/src/gallium/drivers/svga/svga_tgsi_insn.c
@@ -166,7 +166,7 @@ scalar(struct src_register src, unsigned comp)
  static boolean
  svga_arl_needs_adjustment( const struct svga_shader_emitter *emit )
  {
-   int i;
+   unsigned int i;

 for (i = 0; i < emit->num_arl_consts; ++i) {
if (emit->arl_consts[i].arl_num == emit->current_arl)
@@ -179,7 +179,7 @@ svga_arl_needs_adjustment( const struct svga_shader_emitter 
*emit )
  static int
  svga_arl_adjustment( const struct svga_shader_emitter *emit )
  {
-   int i;
+   unsigned int i;

 for (i = 0; i < emit->num_arl_consts; ++i) {
if (emit->arl_consts[i].arl_num == emit->current_arl)
@@ -1175,7 +1175,7 @@ emit_div(struct svga_shader_emitter *emit,
 const struct src_register src1 =
translate_src_register(emit, &insn->Src[1] );
 SVGA3dShaderDestToken temp = get_temp( emit );
-   int i;
+   unsigned int i;

 /* For each enabled element, perform a RCP instruction.  Note that
  * RCP is scalar in SVGA3D:
@@ -1822,7 +1822,7 @@ emit_tex_swizzle(struct svga_shader_emitter *emit,
 const unsigned swizzleIn[4] = {swizzle_x, swizzle_y, swizzle_z, swizzle_w};
 unsigned srcSwizzle[4];
 unsigned srcWritemask = 0x0, zeroWritemask = 0x0, oneWritemask = 0x0;
-   int i;
+   unsigned int i;

 /* build writemasks and srcSwizzle terms */
 for (i = 0; i < 4; i++) {
@@ -3371,7 +3371,7 @@ emit_light_twoside(struct svga_shader_emitter *emit)
 struct src_register back[2];
 SVGA3dShaderDestToken color[2];
 int count = emit->internal_color_count;
-   int i;
+   unsigned int i;
 SVGA3dShaderInstToken if_token;

 if (count == 0)
@@ -3698,7 +3698,7 @@ static boolean
  pre_parse_add_indirect( struct svga_shader_emitter *emit,
  int num, int current_arl)
  {
-   int i;
+   unsigned int i;
 assert(num < 0);

 for (i = 0; i < emit->num_arl_consts; ++i) {



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

Re: [Mesa-dev] [PATCH 1/3] mesa/main: use BITSET_FOREACH_SET in perf_monitor_result_size

[Samuel Pitoiset]

Reviewed-by: Samuel Pitoiset 

On 12/14/2015 06:06 PM, Nicolai Hähnle wrote:

From: Nicolai Hähnle 

This should make the code both faster and slightly clearer.
---
  src/mesa/main/performance_monitor.c | 7 +++
  1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/src/mesa/main/performance_monitor.c 
b/src/mesa/main/performance_monitor.c
index 98dfbea..43529b2 100644
--- a/src/mesa/main/performance_monitor.c
+++ b/src/mesa/main/performance_monitor.c
@@ -591,11 +591,10 @@ perf_monitor_result_size(const struct gl_context *ctx,

 for (group = 0; group < ctx->PerfMonitor.NumGroups; group++) {
const struct gl_perf_monitor_group *g = &ctx->PerfMonitor.Groups[group];
-  for (counter = 0; counter < g->NumCounters; counter++) {
- const struct gl_perf_monitor_counter *c = &g->Counters[counter];
+  BITSET_WORD tmp;

- if (!BITSET_TEST(m->ActiveCounters[group], counter))
-continue;
+  BITSET_FOREACH_SET(counter, tmp, m->ActiveCounters[group], 
g->NumCounters) {
+ const struct gl_perf_monitor_counter *c = &g->Counters[counter];

   size += sizeof(uint32_t); /* Group ID */
   size += sizeof(uint32_t); /* Counter ID */


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

Re: [Mesa-dev] [PATCH 1/6] gallium: Remove unnecessary semicolons

[Brian Paul]

On 12/14/2015 09:27 AM, Edward O'Callaghan wrote:

Found-by: Coccinelle
Signed-off-by: Edward O'Callaghan 
---
  src/gallium/auxiliary/draw/draw_pipe_aaline.c  | 2 +-
  src/gallium/auxiliary/gallivm/lp_bld_swizzle.c | 2 +-
  src/gallium/auxiliary/nir/tgsi_to_nir.c| 2 +-
  src/gallium/auxiliary/util/u_surface.c | 2 +-
  src/gallium/auxiliary/vl/vl_mpeg12_decoder.c   | 2 +-
  src/gallium/state_trackers/nine/swapchain9.c   | 2 +-
  src/gallium/state_trackers/omx/entrypoint.c| 2 +-
  src/gallium/state_trackers/vdpau/mixer.c   | 2 +-
  8 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/src/gallium/auxiliary/draw/draw_pipe_aaline.c 
b/src/gallium/auxiliary/draw/draw_pipe_aaline.c
index 877db59..4a676b7 100644
--- a/src/gallium/auxiliary/draw/draw_pipe_aaline.c
+++ b/src/gallium/auxiliary/draw/draw_pipe_aaline.c
@@ -937,7 +937,7 @@ draw_aaline_prepare_outputs(struct draw_context *draw,
 const struct pipe_rasterizer_state *rast = draw->rasterizer;

 /* update vertex attrib info */
-   aaline->pos_slot = draw_current_shader_position_output(draw);;
+   aaline->pos_slot = draw_current_shader_position_output(draw);

 if (!rast->line_smooth)
return;
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_swizzle.c 
b/src/gallium/auxiliary/gallivm/lp_bld_swizzle.c
index b1aef71..f571838 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_swizzle.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_swizzle.c
@@ -720,7 +720,7 @@ lp_build_transpose_aos_n(struct gallivm_state *gallivm,

default:
   assert(0);
-   };
+   }
  }


diff --git a/src/gallium/auxiliary/nir/tgsi_to_nir.c 
b/src/gallium/auxiliary/nir/tgsi_to_nir.c
index 5def6d3..5cbe8e9 100644
--- a/src/gallium/auxiliary/nir/tgsi_to_nir.c
+++ b/src/gallium/auxiliary/nir/tgsi_to_nir.c
@@ -1951,7 +1951,7 @@ tgsi_processor_to_shader_stage(unsigned processor)
 case TGSI_PROCESSOR_COMPUTE:   return MESA_SHADER_COMPUTE;
 default:
unreachable("invalid TGSI processor");
-   };
+   }
  }

  struct nir_shader *
diff --git a/src/gallium/auxiliary/util/u_surface.c 
b/src/gallium/auxiliary/util/u_surface.c
index 6aa44f9..67da59f 100644
--- a/src/gallium/auxiliary/util/u_surface.c
+++ b/src/gallium/auxiliary/util/u_surface.c
@@ -600,7 +600,7 @@ is_box_inside_resource(const struct pipe_resource *res,
depth = res->array_size;
assert(res->array_size % 6 == 0);
break;
-   case PIPE_MAX_TEXTURE_TYPES:;
+   case PIPE_MAX_TEXTURE_TYPES:
 }

 return box->x >= 0 &&


That semicolon is needed for MSVC (at least).  You'll get a "syntax 
error: missing ';' before '}'" error otherwise.


-Brian



diff --git a/src/gallium/auxiliary/vl/vl_mpeg12_decoder.c 
b/src/gallium/auxiliary/vl/vl_mpeg12_decoder.c
index f5bb3a0..b5c7045 100644
--- a/src/gallium/auxiliary/vl/vl_mpeg12_decoder.c
+++ b/src/gallium/auxiliary/vl/vl_mpeg12_decoder.c
@@ -792,7 +792,7 @@ vl_mpeg12_end_frame(struct pipe_video_codec *decoder,
for (j = 0; j < VL_MAX_REF_FRAMES; ++j) {
   if (!ref_frames[j] || !ref_frames[j][i]) continue;

- vb[2] = vl_vb_get_mv(&buf->vertex_stream, j);;
+ vb[2] = vl_vb_get_mv(&buf->vertex_stream, j);
   dec->context->set_vertex_buffers(dec->context, 0, 3, vb);

   vl_mc_render_ref(i ? &dec->mc_c : &dec->mc_y, &buf->mc[i], 
ref_frames[j][i]);
diff --git a/src/gallium/state_trackers/nine/swapchain9.c 
b/src/gallium/state_trackers/nine/swapchain9.c
index 3f5be26..3b1a7a4 100644
--- a/src/gallium/state_trackers/nine/swapchain9.c
+++ b/src/gallium/state_trackers/nine/swapchain9.c
@@ -790,7 +790,7 @@ NineSwapChain9_Present( struct NineSwapChain9 *This,
  case D3DSWAPEFFECT_FLIP:
  UNTESTED(4);
  case D3DSWAPEFFECT_DISCARD:
-/* rotate the queue */;
+/* rotate the queue */
  pipe_resource_reference(&res, This->buffers[0]->base.resource);
  for (i = 1; i <= This->params.BackBufferCount; i++) {
  NineSurface9_SetResourceResize(This->buffers[i - 1],
diff --git a/src/gallium/state_trackers/omx/entrypoint.c 
b/src/gallium/state_trackers/omx/entrypoint.c
index da9ca10..afcbd97 100644
--- a/src/gallium/state_trackers/omx/entrypoint.c
+++ b/src/gallium/state_trackers/omx/entrypoint.c
@@ -137,7 +137,7 @@ OMX_ERRORTYPE omx_workaround_Destructor(OMX_COMPONENTTYPE 
*comp)
 priv->state = OMX_StateInvalid;
 tsem_up(priv->messageSem);

-   /* wait for thread to exit */;
+   /* wait for thread to exit */
 pthread_join(priv->messageHandlerThread, NULL);

 return omx_base_component_Destructor(comp);
diff --git a/src/gallium/state_trackers/vdpau/mixer.c 
b/src/gallium/state_trackers/vdpau/mixer.c
index c0b1ecc..dec79ff 100644
--- a/src/gallium/state_trackers/vdpau/mixer.c
+++ b/src/gallium/state_trackers/vdpau/mixer.c
@@ -294,7 +294,7 @@ VdpStatus vlVdpVideoMixerRender(VdpVideoMixer mixer,
 default:
pipe_mutex_unlock(vmixer->device->mutex);
return VD

Re: [Mesa-dev] [Intel-gfx] [RFC libdrm] intel: Add support for softpin

[Kristian Høgsberg]

"Song, Ruiling"  writes:

>> -Original Message-
>> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
>> Vetter
>> Sent: Monday, December 14, 2015 4:28 PM
>> To: Song, Ruiling 
>> Cc: k...@bitplanet.net; Winiarski, Michal ;
>> mesa-dev@lists.freedesktop.org; intel-...@lists.freedesktop.org; Ben
>> Widawsky ; dri-de...@lists.freedesktop.org
>> Subject: Re: [Intel-gfx] [RFC libdrm] intel: Add support for softpin
>> 
>> On Mon, Dec 14, 2015 at 07:24:29AM +, Song, Ruiling wrote:
>> >
>> >
>> > > -Original Message-
>> > > From: hoegsb...@gmail.com [mailto:hoegsb...@gmail.com] On Behalf
>> Of
>> > > Kristian H?gsberg
>> > > Sent: Monday, December 14, 2015 1:34 PM
>> > > To: Song, Ruiling 
>> > > Cc: Winiarski, Michal ; intel-
>> > > g...@lists.freedesktop.org; mesa-dev@lists.freedesktop.org; Ben
>> Widawsky
>> > > ; dri-de...@lists.freedesktop.org
>> > > Subject: Re: [Intel-gfx] [RFC libdrm] intel: Add support for softpin
>> > >
>> > > On Sun, Dec 13, 2015 at 7:17 PM, Song, Ruiling 
>> > > wrote:
>> > > >> -Original Message-
>> > > >> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On
>> > > Behalf
>> > > >> Of Micha? Winiarski
>> > > >> Sent: Wednesday, September 9, 2015 10:07 PM
>> > > >> To: intel-...@lists.freedesktop.org
>> > > >> Cc: Ben Widawsky ; dri-
>> > > de...@lists.freedesktop.org;
>> > > >> mesa-dev@lists.freedesktop.org
>> > > >> Subject: [Intel-gfx] [RFC libdrm] intel: Add support for softpin
>> > > >>
>> > > >> Softpin allows userspace to take greater control of GPU virtual 
>> > > >> address
>> > > >> space and eliminates the need of relocations. It can also be used to
>> > > >> mirror addresses between GPU and CPU (shared virtual memory).
>> > > >> Calls to drm_intel_bo_emit_reloc are still required to build the list 
>> > > >> of
>> > > >> drm_i915_gem_exec_objects at exec time, but no entries in relocs are
>> > > >> created. Self-relocs don't make any sense for softpinned objects and
>> can
>> > > >> indicate a programming errors, thus are forbidden. Softpinned objects
>> > > >> are marked by asterisk in debug dumps.
>> > > >>
>> > > >> Cc: Thomas Daniel 
>> > > >> Cc: Kristian Høgsberg 
>> > > >> Cc: Zou Nanhai 
>> > > >> Cc: Michel Thierry 
>> > > >> Cc: Ben Widawsky 
>> > > >> Cc: Chris Wilson 
>> > > >> Signed-off-by: Michał Winiarski 
>> > > >> ---
>> > > >>  include/drm/i915_drm.h|   4 +-
>> > > >>  intel/intel_bufmgr.c  |   9 +++
>> > > >>  intel/intel_bufmgr.h  |   1 +
>> > > >>  intel/intel_bufmgr_gem.c  | 176
>> > > >> --
>> > > >>  intel/intel_bufmgr_priv.h |   7 ++
>> > > >>  5 files changed, 173 insertions(+), 24 deletions(-)
>> > > >
>> > > > Will anybody help to push the patch to libdrm? Beignet highly depend
>> on
>> > > this to implement ocl2.0 svm.
>> > >
>> > > Is the kernel patch upstream?
>> >
>> > Yes, the kernel patch already merged, see:
>> > http://cgit.freedesktop.org/drm-
>> intel/commit/?id=506a8e87d8d2746b9e9d2433503fe237c54e4750
>> >
>> > I find below line of code in libdrm does not match the kernel version. The
>> kernel patch defined as:
>> > "#define EXEC_OBJECT_PINNED (1<<4)", but this patch defined it as (1<<3).
>> 
>> Please always regenerate the entire headers from the kernel sources using
>> 
>> $ make headers_install
>> 
>> Then copy the headers from the kernel's usr/include/drm to libdrm. Never
>> patch i915_drm.h manually.
>
> Thanks for the info. But the problem is libdrm still tracks such kind of 
> header files.
> Should this kind of header file be removed from libdrm? Or any document in 
> libdrm to make this explicit?

The motivation is that compiling libdrm should be independent of
kernel headers on the system. You could probably get away with requiring
some recent enough linux-headers pkg or something, but in the end this
seemed more pragmatic.

Kristian

> Thanks!
> Ruiling
>  
>> Thanks, Daniel
>> 
>> >
>> > Hello Michal,
>> >
>> > Could you help to rebase the patch against:
>> > [Intel-gfx] [PATCH libdrm v4 0/2] 48-bit virtual address support in
>> > i915
>> > I think we need both 48bit & softpin in libdrm.
>> >
>> > diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
>> > index ded43b1..2b99fc6 100644
>> > --- a/include/drm/i915_drm.h
>> > +++ b/include/drm/i915_drm.h
>> > @@ -350,6 +350,7 @@ typedef struct drm_i915_irq_wait {
>> >  #define I915_PARAM_REVISION  32
>> >  #define I915_PARAM_SUBSLICE_TOTAL  33
>> >  #define I915_PARAM_EU_TOTAL34
>> > +#define I915_PARAM_HAS_EXEC_SOFTPIN37
>> >
>> >  typedef struct drm_i915_getparam {
>> >int param;
>> > @@ -680,7 +681,8 @@ struct drm_i915_gem_exec_object2 {
>> >  #define EXEC_OBJECT_NEEDS_FENCE (1<<0)
>> >  #define EXEC_OBJECT_NEEDS_GTT (1<<1)
>> >  #define EXEC_OBJECT_WRITE (1<<2)
>> > -#define __EXEC_OBJECT_UNKNOWN_FLAGS -(EXEC_OBJECT_WRITE<<1)
>> > +#define EXEC_OBJECT_PINNED(1<<3)
>> > +#define __EXEC_

Re: [Mesa-dev] [Intel-gfx] [RFC libdrm] intel: Add support for softpin

[Kristian Høgsberg]

"Song, Ruiling"  writes:

>> -Original Message-
>> From: hoegsb...@gmail.com [mailto:hoegsb...@gmail.com] On Behalf Of
>> Kristian H?gsberg
>> Sent: Monday, December 14, 2015 1:34 PM
>> To: Song, Ruiling 
>> Cc: Winiarski, Michal ; intel-
>> g...@lists.freedesktop.org; mesa-dev@lists.freedesktop.org; Ben Widawsky
>> ; dri-de...@lists.freedesktop.org
>> Subject: Re: [Intel-gfx] [RFC libdrm] intel: Add support for softpin
>> 
>> On Sun, Dec 13, 2015 at 7:17 PM, Song, Ruiling 
>> wrote:
>> >> -Original Message-
>> >> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On
>> Behalf
>> >> Of Micha? Winiarski
>> >> Sent: Wednesday, September 9, 2015 10:07 PM
>> >> To: intel-...@lists.freedesktop.org
>> >> Cc: Ben Widawsky ; dri-
>> de...@lists.freedesktop.org;
>> >> mesa-dev@lists.freedesktop.org
>> >> Subject: [Intel-gfx] [RFC libdrm] intel: Add support for softpin
>> >>
>> >> Softpin allows userspace to take greater control of GPU virtual address
>> >> space and eliminates the need of relocations. It can also be used to
>> >> mirror addresses between GPU and CPU (shared virtual memory).
>> >> Calls to drm_intel_bo_emit_reloc are still required to build the list of
>> >> drm_i915_gem_exec_objects at exec time, but no entries in relocs are
>> >> created. Self-relocs don't make any sense for softpinned objects and can
>> >> indicate a programming errors, thus are forbidden. Softpinned objects
>> >> are marked by asterisk in debug dumps.
>> >>
>> >> Cc: Thomas Daniel 
>> >> Cc: Kristian Høgsberg 
>> >> Cc: Zou Nanhai 
>> >> Cc: Michel Thierry 
>> >> Cc: Ben Widawsky 
>> >> Cc: Chris Wilson 
>> >> Signed-off-by: Michał Winiarski 
>> >> ---
>> >>  include/drm/i915_drm.h|   4 +-
>> >>  intel/intel_bufmgr.c  |   9 +++
>> >>  intel/intel_bufmgr.h  |   1 +
>> >>  intel/intel_bufmgr_gem.c  | 176
>> >> --
>> >>  intel/intel_bufmgr_priv.h |   7 ++
>> >>  5 files changed, 173 insertions(+), 24 deletions(-)
>> >
>> > Will anybody help to push the patch to libdrm? Beignet highly depend on
>> this to implement ocl2.0 svm.
>> 
>> Is the kernel patch upstream?
>
> Yes, the kernel patch already merged, see:
> http://cgit.freedesktop.org/drm-intel/commit/?id=506a8e87d8d2746b9e9d2433503fe237c54e4750
>
> I find below line of code in libdrm does not match the kernel version. The 
> kernel patch defined as:
> "#define EXEC_OBJECT_PINNED (1<<4)", but this patch defined it as (1<<3).

I have the two 48 bit patches merge here. I'll pull in Michał's patch,
update the kernel header and  then push it all.

Kristian

> Hello Michal,
>
> Could you help to rebase the patch against:
> [Intel-gfx] [PATCH libdrm v4 0/2] 48-bit virtual address support in   i915
> I think we need both 48bit & softpin in libdrm.
>
> diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
> index ded43b1..2b99fc6 100644
> --- a/include/drm/i915_drm.h
> +++ b/include/drm/i915_drm.h
> @@ -350,6 +350,7 @@ typedef struct drm_i915_irq_wait {
>  #define I915_PARAM_REVISION  32
>  #define I915_PARAM_SUBSLICE_TOTAL 33
>  #define I915_PARAM_EU_TOTAL   34
> +#define I915_PARAM_HAS_EXEC_SOFTPIN   37
>  
>  typedef struct drm_i915_getparam {
>   int param;
> @@ -680,7 +681,8 @@ struct drm_i915_gem_exec_object2 {
>  #define EXEC_OBJECT_NEEDS_FENCE (1<<0)
>  #define EXEC_OBJECT_NEEDS_GTT(1<<1)
>  #define EXEC_OBJECT_WRITE(1<<2)
> -#define __EXEC_OBJECT_UNKNOWN_FLAGS -(EXEC_OBJECT_WRITE<<1)
> +#define EXEC_OBJECT_PINNED   (1<<3)
> +#define __EXEC_OBJECT_UNKNOWN_FLAGS -(EXEC_OBJECT_PINNED<<1)
>   __u64 flags;
>  
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] docs: Replace sourceforge logo with a text link

[Brian Paul]

Reviewed-by: Brian Paul 


On 12/14/2015 08:55 AM, Andreas Boll wrote:

Fixes the following Lintian (Debian package checker) error:

privacy-breach-logo

   usr/share/doc/mesa-common-dev/contents.html
 (http://sourceforge.net/sflogo.php?group_id=3&type=1)
   usr/share/doc/mesa-common-dev/thanks.html
 (http://sourceforge.net/sflogo.php?group_id=3&type=1)

The extended description of this tag is:

 This package creates a potential privacy breach by fetching a logo
at runtime.

 Before using a local copy you should check that the logo is suitable
for main. You can get help with determining this by posting a link to
the logo and a copy of, or a link to, the logo copyright and license
information to the debian-legal mailing list.

 Please replace any scripts, images, or other remote resources with
non-remote resources. It is preferable to replace them with text and
links but local copies of the remote resources are also acceptable as
long as they don't also make calls to remote services. Please ensure
that the remote resources are suitable for Debian main before making
local copies of them.

 Severity: serious, Certainty: possible

 Check: files, Type: binary, udeb

Signed-off-by: Andreas Boll 
---
  docs/contents.html | 3 +--
  docs/thanks.html   | 4 +---
  2 files changed, 2 insertions(+), 5 deletions(-)

diff --git a/docs/contents.html b/docs/contents.html
index 6612cbe..5e0f514 100644
--- a/docs/contents.html
+++ b/docs/contents.html
@@ -96,8 +96,7 @@
  
  
  http://sourceforge.net";
-target="_parent">http://sourceforge.net/sflogo.php?group_id=3&type=1";
-width="88" height="31" align="bottom" alt="Sourceforge.net" border="0">
+target="_parent">sourceforge.net
  

  
diff --git a/docs/thanks.html b/docs/thanks.html
index 29a41e4..685cb31 100644
--- a/docs/thanks.html
+++ b/docs/thanks.html
@@ -42,9 +42,7 @@ Tungsten Graphics, Inc. have supported the ongoing 
development of Mesa.
  The
  http://www.mesa3d.org";>Mesa
  website is hosted by
-http://sourceforge.net";>
-http://sourceforge.net/sflogo.php?group_id=3&type=1";
-width="88" height="31" align="bottom" alt="Sourceforge.net" border="0">
+http://sourceforge.net";>sourceforge.net.
  
  




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

Re: [Mesa-dev] [PATCH 1/6] gallium: Remove unnecessary semicolons

[Emil Velikov]

On 14 December 2015 at 18:11, Brian Paul  wrote:
> On 12/14/2015 09:27 AM, Edward O'Callaghan wrote:

>> --- a/src/gallium/auxiliary/util/u_surface.c
>> +++ b/src/gallium/auxiliary/util/u_surface.c
>> @@ -600,7 +600,7 @@ is_box_inside_resource(const struct pipe_resource
>> *res,
>> depth = res->array_size;
>> assert(res->array_size % 6 == 0);
>> break;
>> -   case PIPE_MAX_TEXTURE_TYPES:;
>> +   case PIPE_MAX_TEXTURE_TYPES:
>>  }
>>
>>  return box->x >= 0 &&
>
>
> That semicolon is needed for MSVC (at least).  You'll get a "syntax error:
> missing ';' before '}'" error otherwise.
>
Just a drive-by comment, feel free to discard :-)

One could even throw in a "break;" to make static analysis tools happy
(haven't checked if they complain as is).

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

[Mesa-dev] [Bug 93375] unsupported call to function erf when running GROMACS with OpenCL

[bugzilla-daemon]

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

Bug ID: 93375
   Summary: unsupported call to function erf when running GROMACS
with OpenCL
   Product: Mesa
   Version: git
  Hardware: All
OS: All
Status: NEW
  Severity: major
  Priority: medium
 Component: Mesa core
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: riva...@gmail.com
QA Contact: mesa-dev@lists.freedesktop.org

Created attachment 120502
  --> https://bugs.freedesktop.org/attachment.cgi?id=120502&action=edit
GMX comment out atomics

I'm running GROMACS [1] compiled with OpenCL support enabled and the attached
patch applied. Running gives the following error:

Compilation of source file failed! 
-- Used build options: -DWARP_SIZE_TEST=64 -D_AMD_SOURCE_
-DGMX_OCL_FASTGEN_ADD_TWINCUT -DEL_EWALD_ANA -DEELNAME=_ElecEw -DVDWNAME=_VdwLJ
-DCENTRAL=22 -DNBNXN_GPU_NCLUSTER_PER_SUPERCLUSTER=8 -DNBNXN_GPU_CLUSTER_SIZE=8
-DNBNXN_GPU_JGROUP_SIZE=4 -DNBNXN_AVOID_SING_R2_INC=1.0e-12f
-I"/usr/local/gromacs/share/gromacs/opencl" 
--LOG START---
unsupported call to function erf in
nbnxn_kernel_ElecEw_VdwLJ_VF_opencl---LOG END

[1] http://www.gromacs.org/

-- 
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
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] i965: Use DIV_ROUND_UP() in gen7_urb.c code.

[Kristian Høgsberg]

Kenneth Graunke  writes:

> This is a newer convention, which we prefer over ALIGN(x, n) / n.
>
> Signed-off-by: Kenneth Graunke 

Reviewed-by: Kristian Høgsberg 

> ---
>  src/mesa/drivers/dri/i965/gen7_urb.c | 17 -
>  1 file changed, 8 insertions(+), 9 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/gen7_urb.c 
> b/src/mesa/drivers/dri/i965/gen7_urb.c
> index 99a9d3c..421512b 100644
> --- a/src/mesa/drivers/dri/i965/gen7_urb.c
> +++ b/src/mesa/drivers/dri/i965/gen7_urb.c
> @@ -193,11 +193,11 @@ gen7_upload_urb(struct brw_context *brw)
>  
> /* VS has a lower limit on the number of URB entries */
> unsigned vs_chunks =
> -  ALIGN(brw->urb.min_vs_entries * vs_entry_size_bytes, chunk_size_bytes) 
> /
> -  chunk_size_bytes;
> +  DIV_ROUND_UP(brw->urb.min_vs_entries * vs_entry_size_bytes,
> +   chunk_size_bytes);
> unsigned vs_wants =
> -  ALIGN(brw->urb.max_vs_entries * vs_entry_size_bytes,
> -chunk_size_bytes) / chunk_size_bytes - vs_chunks;
> +  DIV_ROUND_UP(brw->urb.max_vs_entries * vs_entry_size_bytes,
> +   chunk_size_bytes) - vs_chunks;
>  
> unsigned gs_chunks = 0;
> unsigned gs_wants = 0;
> @@ -210,11 +210,10 @@ gen7_upload_urb(struct brw_context *brw)
> *
> * (2) We can't allocate less than nr_gs_entries_granularity.
> */
> -  gs_chunks = ALIGN(MAX2(gs_granularity, 2) * gs_entry_size_bytes,
> -chunk_size_bytes) / chunk_size_bytes;
> -  gs_wants =
> - ALIGN(brw->urb.max_gs_entries * gs_entry_size_bytes,
> -   chunk_size_bytes) / chunk_size_bytes - gs_chunks;
> +  gs_chunks = DIV_ROUND_UP(MAX2(gs_granularity, 2) * gs_entry_size_bytes,
> +   chunk_size_bytes);
> +  gs_wants = DIV_ROUND_UP(brw->urb.max_gs_entries * gs_entry_size_bytes,
> +  chunk_size_bytes) - gs_chunks;
> }
>  
> /* There should always be enough URB space to satisfy the minimum
> -- 
> 2.6.3
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [Intel-gfx] [RFC libdrm] intel: Add support for softpin

[Kristian Høgsberg]

Kristian Høgsberg  writes:

> "Song, Ruiling"  writes:
>
>>> -Original Message-
>>> From: hoegsb...@gmail.com [mailto:hoegsb...@gmail.com] On Behalf Of
>>> Kristian H?gsberg
>>> Sent: Monday, December 14, 2015 1:34 PM
>>> To: Song, Ruiling 
>>> Cc: Winiarski, Michal ; intel-
>>> g...@lists.freedesktop.org; mesa-dev@lists.freedesktop.org; Ben Widawsky
>>> ; dri-de...@lists.freedesktop.org
>>> Subject: Re: [Intel-gfx] [RFC libdrm] intel: Add support for softpin
>>> 
>>> On Sun, Dec 13, 2015 at 7:17 PM, Song, Ruiling 
>>> wrote:
>>> >> -Original Message-
>>> >> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On
>>> Behalf
>>> >> Of Micha? Winiarski
>>> >> Sent: Wednesday, September 9, 2015 10:07 PM
>>> >> To: intel-...@lists.freedesktop.org
>>> >> Cc: Ben Widawsky ; dri-
>>> de...@lists.freedesktop.org;
>>> >> mesa-dev@lists.freedesktop.org
>>> >> Subject: [Intel-gfx] [RFC libdrm] intel: Add support for softpin
>>> >>
>>> >> Softpin allows userspace to take greater control of GPU virtual address
>>> >> space and eliminates the need of relocations. It can also be used to
>>> >> mirror addresses between GPU and CPU (shared virtual memory).
>>> >> Calls to drm_intel_bo_emit_reloc are still required to build the list of
>>> >> drm_i915_gem_exec_objects at exec time, but no entries in relocs are
>>> >> created. Self-relocs don't make any sense for softpinned objects and can
>>> >> indicate a programming errors, thus are forbidden. Softpinned objects
>>> >> are marked by asterisk in debug dumps.
>>> >>
>>> >> Cc: Thomas Daniel 
>>> >> Cc: Kristian Høgsberg 
>>> >> Cc: Zou Nanhai 
>>> >> Cc: Michel Thierry 
>>> >> Cc: Ben Widawsky 
>>> >> Cc: Chris Wilson 
>>> >> Signed-off-by: Michał Winiarski 
>>> >> ---
>>> >>  include/drm/i915_drm.h|   4 +-
>>> >>  intel/intel_bufmgr.c  |   9 +++
>>> >>  intel/intel_bufmgr.h  |   1 +
>>> >>  intel/intel_bufmgr_gem.c  | 176
>>> >> --
>>> >>  intel/intel_bufmgr_priv.h |   7 ++
>>> >>  5 files changed, 173 insertions(+), 24 deletions(-)
>>> >
>>> > Will anybody help to push the patch to libdrm? Beignet highly depend on
>>> this to implement ocl2.0 svm.
>>> 
>>> Is the kernel patch upstream?
>>
>> Yes, the kernel patch already merged, see:
>> http://cgit.freedesktop.org/drm-intel/commit/?id=506a8e87d8d2746b9e9d2433503fe237c54e4750
>>
>> I find below line of code in libdrm does not match the kernel version. The 
>> kernel patch defined as:
>> "#define EXEC_OBJECT_PINNED (1<<4)", but this patch defined it as (1<<3).
>
> I have the two 48 bit patches merge here. I'll pull in Michał's patch,
> update the kernel header and  then push it all.

All pushed now.

Kristian

>> Hello Michal,
>>
>> Could you help to rebase the patch against:
>> [Intel-gfx] [PATCH libdrm v4 0/2] 48-bit virtual address support in  i915
>> I think we need both 48bit & softpin in libdrm.
>>
>> diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
>> index ded43b1..2b99fc6 100644
>> --- a/include/drm/i915_drm.h
>> +++ b/include/drm/i915_drm.h
>> @@ -350,6 +350,7 @@ typedef struct drm_i915_irq_wait {
>>  #define I915_PARAM_REVISION  32
>>  #define I915_PARAM_SUBSLICE_TOTAL33
>>  #define I915_PARAM_EU_TOTAL  34
>> +#define I915_PARAM_HAS_EXEC_SOFTPIN  37
>>  
>>  typedef struct drm_i915_getparam {
>>  int param;
>> @@ -680,7 +681,8 @@ struct drm_i915_gem_exec_object2 {
>>  #define EXEC_OBJECT_NEEDS_FENCE (1<<0)
>>  #define EXEC_OBJECT_NEEDS_GTT   (1<<1)
>>  #define EXEC_OBJECT_WRITE   (1<<2)
>> -#define __EXEC_OBJECT_UNKNOWN_FLAGS -(EXEC_OBJECT_WRITE<<1)
>> +#define EXEC_OBJECT_PINNED  (1<<3)
>> +#define __EXEC_OBJECT_UNKNOWN_FLAGS -(EXEC_OBJECT_PINNED<<1)
>>  __u64 flags;
>>  
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [Mesa-stable] [PATCH] meta/generate_mipmap: Work-around GLES 1.x problem with GL_DRAW_FRAMEBUFFER

[Ian Romanick]

On 12/12/2015 10:50 AM, Emil Velikov wrote:
> On 3 December 2015 at 23:52, Anuj Phogat  wrote:
>> On Thu, Dec 3, 2015 at 2:43 PM, Ian Romanick  wrote:
>>> From: Ian Romanick 
>>>
>>> GL_DRAW_FRAMEBUFFER does not exist in OpenGL ES 1.x, and since
>>> _mesa_meta_begin hasn't been called yet, we have to work-around API
>>> difficulties.  The whole reason that GL_DRAW_FRAMEBUFFER is used instead
>>> of GL_FRAMEBUFFER is that the read framebuffer may be different.  This
>>> is moot in OpenGL ES 1.x.
>>>
>>> I have another patch series that would also fix this (by removing the
>>> calls to _mesa_BindFramebuffer and friends), but it's not quite ready
>>> yet... and I think it may be a bit heavy for some stable branches.
>>> Consider this a stop-gap fix.
>>>
>>> Signed-off-by: Ian Romanick 
>>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93215
>>> Cc: "11.0 11.1" 
>>> ---
>>>  src/mesa/drivers/common/meta_generate_mipmap.c | 17 +
>>>  1 file changed, 13 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/src/mesa/drivers/common/meta_generate_mipmap.c 
>>> b/src/mesa/drivers/common/meta_generate_mipmap.c
>>> index d38e6b8..2b942d6 100644
>>> --- a/src/mesa/drivers/common/meta_generate_mipmap.c
>>> +++ b/src/mesa/drivers/common/meta_generate_mipmap.c
>>> @@ -62,6 +62,15 @@ fallback_required(struct gl_context *ctx, GLenum target,
>>> GLuint srcLevel;
>>> GLenum status;
>>>
>>> +   /* GL_DRAW_FRAMEBUFFER does not exist in OpenGL ES 1.x, and since
>>> +* _mesa_meta_begin hasn't been called yet, we have to work-around API
>>> +* difficulties.  The whole reason that GL_DRAW_FRAMEBUFFER is used 
>>> instead
>>> +* of GL_FRAMEBUFFER is that the read framebuffer may be different.  
>>> This
>>> +* is moot in OpenGL ES 1.x.
>>> +*/
>>> +   const GLenum fbo_target = ctx->API == API_OPENGLES
>>> +  ? GL_FRAMEBUFFER : GL_DRAW_FRAMEBUFFER;
>>> +
>>> /* check for fallbacks */
>>> if (target == GL_TEXTURE_3D) {
>>>_mesa_perf_debug(ctx, MESA_DEBUG_SEVERITY_HIGH,
>>> @@ -102,13 +111,13 @@ fallback_required(struct gl_context *ctx, GLenum 
>>> target,
>>>  */
>>> if (!mipmap->FBO)
>>>_mesa_GenFramebuffers(1, &mipmap->FBO);
>>> -   _mesa_BindFramebuffer(GL_DRAW_FRAMEBUFFER, mipmap->FBO);
>>> +   _mesa_BindFramebuffer(fbo_target, mipmap->FBO);
>>>
>>> -   _mesa_meta_bind_fbo_image(GL_DRAW_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, 
>>> baseImage, 0);
>>> +   _mesa_meta_bind_fbo_image(fbo_target, GL_COLOR_ATTACHMENT0, baseImage, 
>>> 0);
>>>
>>> -   status = _mesa_CheckFramebufferStatus(GL_DRAW_FRAMEBUFFER);
>>> +   status = _mesa_CheckFramebufferStatus(fbo_target);
>>>
>>> -   _mesa_BindFramebuffer(GL_DRAW_FRAMEBUFFER, fboSave);
>>> +   _mesa_BindFramebuffer(fbo_target, fboSave);
>>>
>>> if (status != GL_FRAMEBUFFER_COMPLETE_EXT) {
>>>_mesa_perf_debug(ctx, MESA_DEBUG_SEVERITY_HIGH,
>>> --
>>> 2.5.0
>>>
>>> ___
>>> mesa-dev mailing list
>>> mesa-dev@lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>
>>
>> Reviewed-by: Anuj Phogat 
> Am I missing something or this patch hasn't landed in master ? Is
> there another work that makes it obsolete or anything ?

Aw crap... thanks for the reminder.  Pushing it right now.

> Thanks
> Emil
> ___
> mesa-stable mailing list
> mesa-sta...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-stable

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

Re: [Mesa-dev] Mesa 11.1.0 release candidate 3

[Ian Romanick]

On 12/11/2015 07:08 PM, Eric Anholt wrote:
> Emil Velikov  writes:
> 
>> The third release candidate for Mesa 11.1.0 is now available.
> 
> With the kernel stuff now looking ready to merge upstream, I'd like to
> merge support for vc4 based on the headed-upstream kernel ABI to the
> 11.1 branch.  I've prepared a series at:

Congrats!

> https://github.com/anholt/mesa.git 11.1-vc4
> 
> How do we feel about merging this in so that 11.1 can be the first
> release as an ABI-stable, non-experimental vc4 driver?

I think this meets all of our classic criteria for even a late merge.
As long as it doesn't break the build, I'm in favor.  FWIW.

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

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

Re: [Mesa-dev] [PATCH] nir: Fix number of indices on shared variable store intrinsics.

[Jason Ekstrand]

Reviewed-by: Jason Ekstrand 

On Mon, Dec 14, 2015 at 3:32 AM, Kenneth Graunke  wrote:
> Shared variables and input reworks landed around the same time.
> Presumably, this was some sort of mistake in rebase conflict resolution.
>
> Found by inspection.
>
> Signed-off-by: Kenneth Graunke 
> ---
>  src/glsl/nir/nir_intrinsics.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> No effect in Jenkins, oddly.
>
> diff --git a/src/glsl/nir/nir_intrinsics.h b/src/glsl/nir/nir_intrinsics.h
> index 9811fb3..ec9e845 100644
> --- a/src/glsl/nir/nir_intrinsics.h
> +++ b/src/glsl/nir/nir_intrinsics.h
> @@ -309,6 +309,6 @@ STORE(per_vertex_output, 3, 1, 0)
>  /* src[] = { value, block_index, offset }. const_index[] = { write_mask } */
>  STORE(ssbo, 3, 1, 0)
>  /* src[] = { value, offset }. const_index[] = { base, write_mask } */
> -STORE(shared, 2, 1, 0)
> +STORE(shared, 2, 2, 0)
>
>  LAST_INTRINSIC(store_shared)
> --
> 2.6.3
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 86326] clEnqueueNDRangeKernel global_work_offset ignored

[bugzilla-daemon]

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

--- Comment #15 from Ronie Salgado  ---
>
> Ronie, was this fixed?
>
> I did not fix my patch. Sorry, but I do not have time to work on this.

Best regards,
Ronie

2015-12-14 12:06 GMT-03:00 :

> *Comment # 14  on
> bug 86326  from Vedran
> Miletić  *
>
> Ronie, was this fixed?
>
> --
> You are receiving this mail because:
>
>- You are on the CC list for the bug.
>
>

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

Re: [Mesa-dev] [PATCH v2 06/13] i965: Add tessellation shader VUE map code.

[Kenneth Graunke]

On Saturday, December 12, 2015 12:16:33 PM Jordan Justen wrote:
> On 2015-12-11 13:23:55, Kenneth Graunke wrote:
> > Based on a patch by Chris Forbes, but largely rewritten by Ken.
> > 
> > Signed-off-by: Kenneth Graunke 
> > ---
> >  src/mesa/drivers/dri/i965/brw_compiler.h | 20 ++-
> >  src/mesa/drivers/dri/i965/brw_vue_map.c  | 98 
> > ++--
> >  2 files changed, 111 insertions(+), 7 deletions(-)
> > 
> > diff --git a/src/mesa/drivers/dri/i965/brw_compiler.h 
> > b/src/mesa/drivers/dri/i965/brw_compiler.h
> > index 514788c..c9e0317 100644
> > --- a/src/mesa/drivers/dri/i965/brw_compiler.h
> > +++ b/src/mesa/drivers/dri/i965/brw_compiler.h
> > @@ -442,7 +442,7 @@ struct brw_vue_map {
> >  * additional processing is applied before storing them in the VUE), the
> >  * value is -1.
> >  */
> > -   signed char varying_to_slot[BRW_VARYING_SLOT_COUNT];
> > +   signed char varying_to_slot[VARYING_SLOT_TESS_MAX];
> >  
> > /**
> >  * Map from VUE slot to gl_varying_slot value.  For slots that do not
> > @@ -451,12 +451,24 @@ struct brw_vue_map {
> >  *
> >  * For slots that are not in use, the value is BRW_VARYING_SLOT_PAD.
> 
> This comment doesn't apply to tess, right?
> 
> >  */
> > -   signed char slot_to_varying[BRW_VARYING_SLOT_COUNT];
> > +   signed char slot_to_varying[VARYING_SLOT_TESS_MAX];
> 
> So, for VS, the brw_varying_slot enum is used, and for tess
> VARYING_SLOT_TESS_MAX will be used?

Yeah.  gl_varying_slot (0..VARYING_SLOT_MAX) is the core Mesa enum.
i965 extends it as brw_varying_slot by adding a few extra fields,
which other than PAD are only used on Gen4-5 IIRC.  Tessellation also
extends the core Mesa enum with VARYING_SLOT_PATCH0...TESS_MAX.

This is really ugly: both enums overlap.  But, we don't actually use
any of the brw_varying_slot values for tessellation, so it works out.

Ultimately, I'd like to clean up the core Mesa enums in a future patch.
0..VARYING_SLOT_MAX and VARYING_SLOT_PATCH0..VARYING_SLOT_TESS_MAX are
used to index different bitfields, and aren't really that related.  In
fact, there are so many bits that a single GLbitfield64 can't address
them all, which is ugly.  I'd like to separate them.

> Looking at VARYING_SLOT_TESS_MAX vs. BRW_VARYING_SLOT_COUNT, it seems
> pretty clear that VARYING_SLOT_TESS_MAX is >= BRW_VARYING_SLOT_COUNT.
> I was going to suggest a STATIC_ASSERT, but it doesn't really seem
> required.

Yep.

> >  
> > /**
> >  * Total number of VUE slots in use
> >  */
> > int num_slots;
> > +
> > +   /**
> > +* Number of per-patch VUE slots. Only valid for tessellation control
> > +* shader outputs and tessellation evaluation shader inputs.
> > +*/
> > +   int num_per_patch_slots;
> > +
> > +   /**
> > +* Number of per-vertex VUE slots. Only valid for tessellation control
> > +* shader outputs and tessellation evaluation shader inputs.
> > +*/
> > +   int num_per_vertex_slots;
> >  };
> >  
> >  void brw_print_vue_map(FILE *fp, const struct brw_vue_map *vue_map);
> > @@ -484,6 +496,10 @@ void brw_compute_vue_map(const struct brw_device_info 
> > *devinfo,
> >   GLbitfield64 slots_valid,
> >   bool separate_shader);
> >  
> > +void brw_compute_tess_vue_map(struct brw_vue_map *const vue_map,
> > +  const GLbitfield64 slots_valid,
> > +  const GLbitfield is_patch);
> > +
> >  enum shader_dispatch_mode {
> > DISPATCH_MODE_4X1_SINGLE = 0,
> > DISPATCH_MODE_4X2_DUAL_INSTANCE = 1,
> > diff --git a/src/mesa/drivers/dri/i965/brw_vue_map.c 
> > b/src/mesa/drivers/dri/i965/brw_vue_map.c
> > index 6cb3da4..469538b 100644
> > --- a/src/mesa/drivers/dri/i965/brw_vue_map.c
> > +++ b/src/mesa/drivers/dri/i965/brw_vue_map.c
> > @@ -176,6 +176,77 @@ brw_compute_vue_map(const struct brw_device_info 
> > *devinfo,
> > }
> >  
> > vue_map->num_slots = separate ? slot + 1 : slot;
> > +   vue_map->num_per_vertex_slots = 0;
> > +   vue_map->num_per_patch_slots = 0;
> > +}
> > +
> > +/**
> > + * Compute the VUE map for tessellation control shader outputs and
> > + * tessellation evaluation shader inputs.
> > + */
> > +void
> > +brw_compute_tess_vue_map(struct brw_vue_map *vue_map,
> > + GLbitfield64 vertex_slots,
> > + GLbitfield patch_slots)
> > +{
> > +   /* I don't think anything actually uses this... */
> > +   vue_map->slots_valid = vertex_slots;
> > +
> > +   vertex_slots &= ~(VARYING_BIT_TESS_LEVEL_OUTER |
> > + VARYING_BIT_TESS_LEVEL_INNER);
> > +
> > +   /* Make sure that the values we store in vue_map->varying_to_slot and
> > +* vue_map->slot_to_varying won't overflow the signed chars that are 
> > used
> > +* to store them.  Note that since vue_map->slot_to_varying sometimes 
> > holds
> > +* values equal to VARYING_SLOT_TESS_MAX , we need to ensure that
> > +* VARYNIG_

[Mesa-dev] [Bug 93375] unsupported call to function erf when running GROMACS with OpenCL

[bugzilla-daemon]

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

--- Comment #1 from Aaron Watry  ---
Looks like libclc does not yet implement the erf function.

erfc is implemented, but not plain erf.

The amd-builtins branch in libclc looks like there's an erf implementation that
can be ported over:
https://llvm.org/svn/llvm-project/libclc/branches/amd-builtins/amd-builtins/math32/erfF.cl

The double implementation will need to be ported as well.

Note that it looks like the AMD implementation of erf requires doubles if
subnormals are NOT supported... If that's an issue for someone, we'll need a
workaround for that.

-- 
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
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [Mesa-stable] [PATCH] i965: Fix crash when calling glViewport with no surface bound

[Nanley Chery]

On Thu, Dec 10, 2015 at 01:08:37PM -0800, Nanley Chery wrote:
> On Tue, Dec 08, 2015 at 04:35:57PM +, Neil Roberts wrote:
> > If EGL_KHR_surfaceless_context is used then glViewport can be called
> > with NULL for the draw and read surfaces. This was previously causing
> > a crash because the i965 driver tries to use this point to invalidate
> > the surfaces and it was derferencing the NULL pointer.
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93257
> > Cc: Nanley Chery 
> > Cc: "11.1" 
> > ---
> 
> Thanks for the fix! I'll be able to give this a better look next week, so
> feel free to push if you receive an Rb before then.
> 
> Tested-by: Nanley Chery 


While I can't say that I know all the interactions with framebuffers,
I can't see a use-case for segfaulting on a NULL surface.

Reviewed-by: Nanley Chery 

> 
> >
> > I've also posted a Piglit test for this here:
> >
> > http://patchwork.freedesktop.org/patch/67356/
> >
> > src/mesa/drivers/dri/i965/brw_context.c | 6 --
> > 1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/src/mesa/drivers/dri/i965/brw_context.c
> b/src/mesa/drivers/dri/i965/brw_context.c
> > index 7d7643c..5374bad 100644
> > --- a/src/mesa/drivers/dri/i965/brw_context.c
> > +++ b/src/mesa/drivers/dri/i965/brw_context.c
> > @@ -159,8 +159,10 @@ intel_viewport(struct gl_context *ctx)
> > __DRIcontext *driContext = brw->driContext;
> >
> > if (_mesa_is_winsys_fbo(ctx->DrawBuffer)) {
> > - dri2InvalidateDrawable(driContext->driDrawablePriv);
> > - dri2InvalidateDrawable(driContext->driReadablePriv);
> > + if (driContext->driDrawablePriv)
> > + dri2InvalidateDrawable(driContext->driDrawablePriv);
> > + if (driContext->driReadablePriv)
> > + dri2InvalidateDrawable(driContext->driReadablePriv);
> > }
> > }
> >
> > --
> > 1.9.3
> >
> > ___
> > mesa-stable mailing list
> > mesa-sta...@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/mesa-stable
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] i965: Allocate URB space for HS and DS stages when required.

[Kristian Høgsberg]

Kenneth Graunke  writes:

> From: Chris Forbes 
>
> v2: (by Ken, incorporating feedback from Matt Turner):
> - Rewrite the push constant allocation code to be clearer.
> - Only apply the minimum VS entries workaround on Gen 8.
>
> v3: (by Ken)
> - Fix a bug in v2 where we failed to allocate the full push constant
>   space when the number of enabled stages didn't divide the available
>   push constant space evenly.  (Any left over space is now allocated
>   to the PS, as it was in v1.)
> - Fix an off-by-one error in v2's number of enabled stages calculation.
> - Use DIV_ROUND_UP for nicer formatting.
> - Line wrapping fixes.
>
> Signed-off-by: Chris Forbes 
> Signed-off-by: Kenneth Graunke 
> ---
>  src/mesa/drivers/dri/i965/brw_context.h  |  21 +++-
>  src/mesa/drivers/dri/i965/gen7_blorp.cpp |   8 ++
>  src/mesa/drivers/dri/i965/gen7_urb.c | 177 
> +--
>  3 files changed, 170 insertions(+), 36 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_context.h 
> b/src/mesa/drivers/dri/i965/brw_context.h
> index 1cc4c7b..69bc04c 100644
> --- a/src/mesa/drivers/dri/i965/brw_context.h
> +++ b/src/mesa/drivers/dri/i965/brw_context.h
> @@ -1008,6 +1008,8 @@ struct brw_context
> struct {
>GLuint vsize;  /* vertex size plus header in urb registers */
>GLuint gsize;  /* GS output size in urb registers */
> +  GLuint hsize; /* Tessellation control output size in urb 
> registers */
> +  GLuint dsize; /* Tessellation evaluation output size in 
> urb registers */
>GLuint csize;  /* constant buffer size in urb registers */
>GLuint sfsize; /* setup data size in urb registers */
>  
> @@ -1020,12 +1022,16 @@ struct brw_context
>GLuint max_gs_entries; /* Maximum number of GS entries */
>  
>GLuint nr_vs_entries;
> +  GLuint nr_hs_entries;
> +  GLuint nr_ds_entries;
>GLuint nr_gs_entries;
>GLuint nr_clip_entries;
>GLuint nr_sf_entries;
>GLuint nr_cs_entries;
>  
>GLuint vs_start;
> +  GLuint hs_start;
> +  GLuint ds_start;
>GLuint gs_start;
>GLuint clip_start;
>GLuint sf_start;
> @@ -1042,6 +1048,11 @@ struct brw_context
> * URB space for the GS.
> */
>bool gs_present;
> +
> +  /* True if the most recently sent _3DSTATE_URB message allocated
> +   * URB space for the HS and DS.
> +   */
> +  bool tess_present;
> } urb;
>  
>  
> @@ -1648,12 +1659,18 @@ void gen8_emit_3dstate_sample_pattern(struct 
> brw_context *brw);
>  /* gen7_urb.c */
>  void
>  gen7_emit_push_constant_state(struct brw_context *brw, unsigned vs_size,
> +  unsigned hs_size, unsigned ds_size,
>unsigned gs_size, unsigned fs_size);
>  
>  void
>  gen7_emit_urb_state(struct brw_context *brw,
> -unsigned nr_vs_entries, unsigned vs_size,
> -unsigned vs_start, unsigned nr_gs_entries,
> +unsigned nr_vs_entries,
> +unsigned vs_size, unsigned vs_start,
> +unsigned nr_hs_entries,
> +unsigned hs_size, unsigned hs_start,
> +unsigned nr_ds_entries,
> +unsigned ds_size, unsigned ds_start,
> +unsigned nr_gs_entries,
>  unsigned gs_size, unsigned gs_start);
>  
>  
> diff --git a/src/mesa/drivers/dri/i965/gen7_blorp.cpp 
> b/src/mesa/drivers/dri/i965/gen7_blorp.cpp
> index e87b9d1..89b73ca 100644
> --- a/src/mesa/drivers/dri/i965/gen7_blorp.cpp
> +++ b/src/mesa/drivers/dri/i965/gen7_blorp.cpp
> @@ -50,6 +50,8 @@ gen7_blorp_emit_urb_config(struct brw_context *brw)
> unsigned urb_size = (brw->is_haswell && brw->gt == 3) ? 32 : 16;
> gen7_emit_push_constant_state(brw,
>   urb_size / 2 /* vs_size */,
> + 0 /* hs_size */,
> + 0 /* ds_size */,
>   0 /* gs_size */,
>   urb_size / 2 /* fs_size */);
>  
> @@ -60,6 +62,12 @@ gen7_blorp_emit_urb_config(struct brw_context *brw)
> 32 /* num_vs_entries */,
> 2 /* vs_size */,
> 2 /* vs_start */,
> +   0 /* num_hs_entries */,
> +   1 /* hs_size */,
> +   2 /* hs_start */,
> +   0 /* num_ds_entries */,
> +   1 /* ds_size */,
> +   2 /* ds_start */,
> 0 /* num_gs_entries */,
> 1 /* gs_size */,
> 2 /* gs_start */);
> diff --git a/src/mesa/drivers/dri/i965/gen7_urb.c 
> b/src/mesa/drivers/dri/i965/gen7_urb.c
> index 421512b..f2b6ec3 100644
> --- a/src/mesa/drivers/dri/i965/gen7_urb.c
> +++

[Mesa-dev] [Bug 86326] clEnqueueNDRangeKernel global_work_offset ignored

[bugzilla-daemon]

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

--- Comment #16 from Vedran Miletić  ---
(In reply to Ronie Salgado from comment #15)
> I did not fix my patch. Sorry, but I do not have time to work on this.

In case this turns out to be necessary to make GROMACS OpenCL work, do you mind
if I finish your patch and make it suitable for merging (with proper credit, of
course)?

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

Re: [Mesa-dev] [PATCH] nir: Fix number of indices on shared variable store intrinsics.

[Kristian Høgsberg]

Kenneth Graunke  writes:

> Shared variables and input reworks landed around the same time.
> Presumably, this was some sort of mistake in rebase conflict resolution.
>
> Found by inspection.
>
> Signed-off-by: Kenneth Graunke 

Reviewed-by: Kristian Høgsberg 

> ---
>  src/glsl/nir/nir_intrinsics.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> No effect in Jenkins, oddly.
>
> diff --git a/src/glsl/nir/nir_intrinsics.h b/src/glsl/nir/nir_intrinsics.h
> index 9811fb3..ec9e845 100644
> --- a/src/glsl/nir/nir_intrinsics.h
> +++ b/src/glsl/nir/nir_intrinsics.h
> @@ -309,6 +309,6 @@ STORE(per_vertex_output, 3, 1, 0)
>  /* src[] = { value, block_index, offset }. const_index[] = { write_mask } */
>  STORE(ssbo, 3, 1, 0)
>  /* src[] = { value, offset }. const_index[] = { base, write_mask } */
> -STORE(shared, 2, 1, 0)
> +STORE(shared, 2, 2, 0)
>  
>  LAST_INTRINSIC(store_shared)
> -- 
> 2.6.3
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [Bug 93352] GRID Autosport crashes on start of race

[Timothy Arceri]

On Mon, 2015-12-14 at 09:46 -0500, Ilia Mirkin wrote:
> Hi Edwin,
> 
> Thanks for reaching out to the mesa community! See my comments
> inline.
> 
> On Mon, Dec 14, 2015 at 5:13 AM,  
> wrote:
> > Comment # 20 on bug 93352 from Edwin Smith
> > My name is Edwin Smith and I work for Feral Interactive who make
> > the Linux
> > version of the game. Thank you for fixing the issue in the latest
> > drivers, I
> > am
> > sure people playing the game on AMD machines will be very happy!
> > 
> > We tested the game using 11.0.2 and apart from missing features for
> > the
> > higher
> > end effects meaning they had to be disabled we did not see any
> > major
> > rendering
> > issues.
> 
> Odd... this bug should have been visible with radeonsi and nouveau
> when enabling tessellation. Perhaps only on debug builds though (on
> opt builds it would still have been an issue, just no crash).
> 
> > Please let us know if we can assist by providing people working on
> > driver
> > issues a copy of the title or other information to help with your
> > driver
> > work.

Hi Edwin,

A couple of other things to consider. 

1. I believe a number of the games you guys have ported have benchmark
modes but there is no way to run them via the command line (or possibly
no easy way to discover what the switches are) providing this
information would be useful for automated benchmarking. It's been
reported that GRID Autosport may be CPU limited so would be an
interesting case for benchmarking.

2. Mesa developers use a tool called shader-db to test compiler
optimisations, shader compile time etc. You guys might consider
providing some of your shaders for use in this database. Note that they
would need to be provided under an appropriate licence.
Please see the thread from January when the Unity guys did this for
more information [1].

As Ilia mentioned the best solution for providing games to developers
would be a solution similair to the way Value did it where access is
given to an individual for a collection of games. It is useful to
providie access to individuals rather than a single company due to the
open source nature of Mesa, developers are made up of volunteers,
contractors and employees from companies like Redhat as well as
obviously AMD and Intel.

I wanted to make this point for a couple of reasons, firstly the bug
was fixed by Ilia who is a volunteer and does a great job fixing many
bugs for games often without access to the game itself, secondly due to
the sharing of code in Mesa this would have also been an issue in the
Intel driver once the tessellation support lands and Intel employs a
number of contractors such as myself who won't necessarily have access
to everything they do.

Thanks again for reaching out to the mesa community.

Tim

[1] 
http://lists.freedesktop.org/archives/mesa-dev/2015-January/073589.html

> 
> The most straight-forward way would be to do the same thing Valve did
> -- basically they provide a (free) package on Steam that includes all
> of their games to people who are active mesa contributors. You can
> see
> the details of their program here:
> http://lists.freedesktop.org/archives/dri-devel/2015-April/081045.htm
> l
> .
> 
> Cheers,
> 
>   -ilia
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 93375] unsupported call to function erf when running GROMACS with OpenCL

[bugzilla-daemon]

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

--- Comment #2 from Vedran Miletić  ---
(In reply to Aaron Watry from comment #1)
> Looks like libclc does not yet implement the erf function.

Neat, the approach you suggest seems to be simpler than the one I had in mind,
analogous to ldexp http://reviews.llvm.org/D14990

> Note that it looks like the AMD implementation of erf requires doubles if
> subnormals are NOT supported... If that's an issue for someone, we'll need a
> workaround for that.

erff() from GROMACS works without doubles:
https://github.com/gromacs/gromacs/blob/fab0108c88e441d891d838bb81ca879ff9708317/src/gromacs/math/utilities.cpp

Not sure if it's usable in this form, I would have to look.

-- 
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
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 86326] clEnqueueNDRangeKernel global_work_offset ignored

[bugzilla-daemon]

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

--- Comment #17 from Ronie Salgado  ---
>
> In case this turns out to be necessary to make GROMACS OpenCL work, do you 
> mind
> if I finish your patch and make it suitable for merging (with proper credit, 
> of
> course)?
>
> I don't mind. Just go ahead. You should only need to split the patch so
that it can be accepted by the different projects that it affects.

Best regards,
Ronie

2015-12-14 20:06 GMT-03:00 :

> *Comment # 16  on
> bug 86326  from Vedran
> Miletić  *
>
> (In reply to Ronie Salgado from comment #15 
> )> I did not fix my 
> patch. Sorry, but I do not have time to work on this.
>
> In case this turns out to be necessary to make GROMACS OpenCL work, do you 
> mind
> if I finish your patch and make it suitable for merging (with proper credit, 
> of
> course)?
>
> --
> You are receiving this mail because:
>
>- You are on the CC list for the bug.
>
>

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

Re: [Mesa-dev] [PATCH] mesa: remove validation of shaders that should be done elsewhere

[Timothy Arceri]

On Wed, 2015-12-09 at 00:17 +1100, Timothy Arceri wrote:
> In core profile even if re-linking fails rendering shouldn't fail as
> the
> previous succesfully linked program will still be available. It also
> shouldn't be possible to have an unlinked program as part of the
> current rendering state.

Hey guys,

Any thoughts on this change?

Thinking about this some more we should probably rework the compat code
also and only do the check for link status if there is an assembly
shader right?

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