Re: [Mesa-dev] [PATCH 4/5] i965/miptree: Rename align_w, align_h -> halign, valign

[Kenneth Graunke]

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

Re: [Mesa-dev] [PATCH 5/5] i965/miptree: Add PRM references for most struct members

[Kenneth Graunke]

On Sep 25, 2015 12:05 PM, Chad Versace  wrote:
>
> Add comments that link the driver's miptree structures to the hardware
> structures documented in the PRM.  This provides sorely needed
> orientation to developers new to the miptree code. And for miptree
> veterans, this clarifies some of the more obscure miptree data.
>
> For each driver struct field that closely corresponds to a
> hardware struct field, add a PRM reference to that hardware field's
> name. For example,
>
>     struct intel_mipmap_tree {
>    ...
>    /**
>     * @brief One of GL_TEXTURE_2D, GL_TEXTURE_2D_ARRAY, etc.
>     *
>     * @see RENDER_SURFACE_STATE.SurfaceType
>     * @see RENDER_SURFACE_STATE.SurfaceArray
>     * @see 3DSTATE_DEPTH_BUFFER.SurfaceType
>     */
>    GLenum target;
>    ...
>     };
>
> Also annotate the INTEL_MSAA_LAYOUT_* enums with the name of the PRM
> sections that documents the layout.
> ---
> src/mesa/drivers/dri/i965/intel_mipmap_tree.h | 167 ++
> 1 file changed, 146 insertions(+), 21 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.h 
> b/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
> index bfcecea..671065d 100644
> --- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
> +++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
> @@ -144,6 +144,9 @@ struct intel_mipmap_level
>     * \code
>     * x = mt->level[l].slice[s].x_offset
>     * y = mt->level[l].slice[s].y_offset
> +   *
> +   * On some hardware generations, we program these offsets into

On G45 and Ironlake we program...

> +   * RENDER_SURFACE_STATE.XOffset and RENDER_SURFACE_STATE.YOffset.
>     */
>    GLuint x_offset;
>    GLuint y_offset;
> @@ -172,12 +175,16 @@ enum intel_msaa_layout
>  * accommodated by scaling up the width and the height of the surface so
>  * that all the samples corresponding to a pixel are located at nearby
>  * memory locations.
> +    *
> +    * @see PRM section "Interleaved Multisampled Surfaces"
>  */
>     INTEL_MSAA_LAYOUT_IMS,
>
>     /**
>  * Uncompressed Multisample Surface.  The surface is stored as a 2D array,
>  * with array slice n containing all pixel data for sample n.
> +    *
> +    * @see PRM section "Uncompressed Multisampled Surfaces"
>  */
>     INTEL_MSAA_LAYOUT_UMS,
>
> @@ -189,6 +196,8 @@ enum intel_msaa_layout
>  * the common case (where all samples constituting a pixel have the same
>  * color value) to be stored efficiently by just using a single array
>  * slice.
> +    *
> +    * @see PRM section "Compressed Multisampled Surfaces"
>  */
>     INTEL_MSAA_LAYOUT_CMS,
> };
> @@ -322,14 +331,34 @@ enum miptree_array_layout {
>   */
> struct intel_miptree_aux_buffer
> {
> -   /** Buffer object containing the pixel data. */
> +   /**
> +    * Buffer object containing the pixel data.
> +    *
> +    * @see RENDER_SURFACE_STATE.AuxiliarySurfaceBaseAddress
> +    * @see 3DSTATE_HIER_DEPTH_BUFFER.AuxiliarySurfaceBaseAddress

Is it worth noting that this is HiZ or MCS before Gen8, when the auxiliary term 
was introduced?

> +    */
>     drm_intel_bo *bo;
>
> -   uint32_t pitch; /**< pitch in bytes. */
> +   /**
> +    * Pitch in bytes.
> +    *
> +    * @see RENDER_SURFACE_STATE.AuxiliarySurfacePitch
> +    * @see 3DSTATE_HIER_DEPTH_BUFFER.SurfacePitch
> +    */
> +   uint32_t pitch;
>
> -   uint32_t qpitch; /**< The distance in rows between array slices. */
> +   /**
> +    * The distance in rows between array slices.
> +    *
> +    * @see RENDER_SURFACE_STATE.AuxiliarySurfaceQPitch
> +    * @see 3DSTATE_HIER_DEPTH_BUFFER.SurfaceQPitch
> +    */
> +   uint32_t qpitch;
>
> -   struct intel_mipmap_tree *mt; /**< hiz miptree used with Gen6 */
> +   /**
> +    * Hiz miptree. Used only by Gen6.
> +    */
> +   struct intel_mipmap_tree *mt;
> };
>
> /* Tile resource modes */
> @@ -341,15 +370,49 @@ enum intel_miptree_tr_mode {
>
> struct intel_mipmap_tree
> {
> -   /** Buffer object containing the pixel data. */
> +   /**
> +    * Buffer object containing the surface.
> +    *
> +    * @see intel_mipmap_tree::offset
> +    * @see RENDER_SURFACE_STATE.SurfaceBaseAddress
> +    * @see RENDER_SURFACE_STATE.AuxiliarySurfaceBaseAddress
> +    * @see 3DSTATE_DEPTH_BUFFER.SurfaceBaseAddress
> +    * @see 3DSTATE_HIER_DEPTH_BUFFER.SurfaceBaseAddress
> +    * @see 3DSTATE_STENCIL_BUFFER.SurfaceBaseAddress
> +    */
>     drm_intel_bo *bo;
>
> -   uint32_t pitch; /**< pitch in bytes. */
> +   /**
> +    * Pitch in bytes.
> +    *
> +    * @see RENDER_SURFACE_STATE.SurfacePitch
> +    * @see RENDER_SURFACE_STATE.AuxiliarySurfacePitch
> +    * @see 3DSTATE_DEPTH_BUFFER.SurfacePitch
> +    * @see 3DSTATE_HIER_DEPTH_BUFFER.SurfacePitch
> +    * @see 3DSTATE_STENCIL_BUFFER.SurfacePitch
> +    */
> +   uint32_t pitch;
>
> -   uint32_t tiling; /**< One of the I915_TILING_* flags */
> +   /**
> +    * One of the I915_TILING_* flags.
> +    *
> +    * @

[Mesa-dev] [Bug 93103] llvm symbols leak through, cause trouble with software rendering in llvm-linked software

[bugzilla-daemon]

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

--- Comment #14 from Michel Dänzer  ---
FWIW, IME LLVM's symbol versioning seems to only help if all LLVM libraries
involved have versioned symbols. I did verify at one point with gambas that
radeonsi using a different LLVM library from gambas worked if both LLVM
libraries had versioned symbols but broke if the LLVM library used by gambas
didn't have versioned symbols.

BTW, the LLVM symbol versioning was introduced by
http://www.llvm.org/viewvc/llvm-project?view=revision&revision=214418 , but I'm
not sure if that's already active with a cmake build as well or if something
needs to be done 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

[Mesa-dev] [Bug 93114] No water rendered in CoR

[bugzilla-daemon]

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

--- Comment #7 from Michel Dänzer  ---
BTW, how about Wine without nine?

-- 
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 23/24] i965/vec4: Replace src_reg(imm) constructors with brw_imm_*().

[Matt Turner]

On Thu, Nov 26, 2015 at 9:22 AM, Emil Velikov  wrote:
> On 25 November 2015 at 22:48, Matt Turner  wrote:
>
>> I can't see it, but that might be because I can't stop thinking like I
>> was when I wrote the code.
>>
> Understandable, we've all been there.
>
>> Yeah, we skip any instruction that has a full writemask -- because if
>> it has a full writemask, we can just load the immediate as-is and we
>> don't need to turn it into 4x restricted floats. But that doesn't seem
>> to be related to the warning.
>>
>> The code seems fine to me. Here's what I see:
>>
>> We start with remaining_channels = WRITEMASK_XYZW.
> Actually we start with WRITEMASK_NONE (0). Based on your knowledge you
> can establish that on the first iteration(?) remaining_channels will
> be set to WRITEMASK_XYZW, although the compiler cannot determine that.
>
>> We initialize an
>> element of imm[] for each enabled bit of inst->dst.writemask, and then
>> we disable those bits from remaining_channels.
> If all channels are set we bail out just before that. Thus as we hit
> the imm[x] assignments of at least one channel is not set. Be that
> left uninitialized or storing data from a previous instruction. I take
> that this is by design ?
>
>> When remaining_channels
>> is zero (should be if and only if all elements of imm[] are
>> initialized), we read imm[].
>>
> Barring your existing knowledge, remaining_channels can be zero on the
> first, second,  N'th iteration, albeit extremely unlikely. Thus
> regardless of what data we have in imm[], we'll proceed to use it.
>
>> Do you see anything wrong or anything I've missed?
>>
>> FWIW, Clang does not warn about this and doesn't warn if I remove the
>> useless initializations of remaining_channels = 0 and inst_count = 0.
>> I think this is gcc and Coverity just being stupid.
> I think the whole things is that you know who it will run, whereas the
> code makes is a bit ambiguous.
>
> To fix (?) and make things a lot more obvious I'd suggest initializing
> (upon declaration) remaining_channels with WRITEMASK_XYZW. If
> gcc/coverity/other complains with that in place then it's definitely a
> defect on their end.

The initialization of remaining_writemask is *dead* -- the first block
inside the for loop initializes it upon seeing the first instruction.
Initializing it to WRITEMASK_XYZW doesn't fix the warning in any case.

> Out of curiosity: what is the input from gcc devs, do you have the bug
> number handy ?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68548

They think it's a deficiency in gcc.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] mesa/main: TexImage2DMultisample needs to pass OpenGL3.3 conformance test.

[Timothy Arceri]

On Thu, 2015-11-26 at 11:00 +, Predut, Marius wrote:
> > -Original Message-
> > From: mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org] On
> > Behalf Of
> > Timothy Arceri
> > Sent: Wednesday, November 25, 2015 6:02 PM
> > To: Palli, Tapani; Predut, Marius; mesa-dev@lists.freedesktop.org
> > Subject: Re: [Mesa-dev] [PATCH] mesa/main: TexImage2DMultisample
> > needs to pass
> > OpenGL3.3 conformance test.
> > 
> > On Wed, 2015-11-25 at 17:13 +0200, Tapani Pälli wrote:
> > > On 11/25/2015 04:00 PM, Predut, Marius wrote:
> > > > > -Original Message-
> > > > > From: mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org
> > > > > ] On
> > > > > Behalf Of Timothy Arceri
> > > > > Sent: Wednesday, November 25, 2015 1:12 PM
> > > > > To: Palli, Tapani; Predut, Marius; 
> > > > > mesa-dev@lists.freedesktop.org
> > > > > Subject: Re: [Mesa-dev] [PATCH] mesa/main:
> > > > > TexImage2DMultisample
> > > > > needs to pass
> > > > > OpenGL3.3 conformance test.
> > > > > 
> > > > > On Wed, 2015-11-25 at 12:47 +0200, Tapani Pälli wrote:
> > > > > > Hi;
> > > > > > 
> > > > > > On 11/25/2015 01:15 PM, Marius Predut wrote:
> > > > > > > Open GL 3.3 reference document says:
> > > > > > > samples must be in the range zero to GL_MAX_TEXTURE_SIZE 
> > > > > > > - 1.
> > > > > > > Open GL.4 clearly states:
> > > > > > > An INVALID_VALUE error is generated if samples is zero.
> > > > > See my comment in bugzilla [1] I believe this is just a bug
> > > > > in the
> > > > > reference pages, we implement things in Mesa going by what
> > > > > the
> > > > > spec says and the spec says nothing about samples being 0 in
> > > > > the
> > > > > 3.2 spec in fact it doen't even say anything in the 4.0 spec
> > > > > which
> > > > > you have changed the check to.
> > > > > 
> > > > > Also the 4.5 reference pages also conflict with the spec so
> > > > > this
> > > > > is even more reason I think this change is wrong.
> > > > > 
> > > > > [1] https://bugs.freedesktop.org/show_bug.cgi?id=91670
> > > > > 
> > > > I don't think it is a bug in specs because in this case also
> > > > the CTS
> > > > and the piglit test is wrong:
> > > > 
> > > > With this patch 2 things are fixed:
> > > > 1.Khronos CTS conformance tests for OpenGL 3.3 2. The piglit
> > > > test
> > > > https://bugs.freedesktop.org/show_bug.cgi?id=93100 (Or
> > > > https://bugs.freedesktop.org/show_bug.cgi?id=91670)
> > > > 
> > > > The patch is based on this spec:
> > > > https://www.opengl.org/sdk/docs/man3/xhtml/glTexImage3DMultisam
> > > > ple.
> > > > xml
> > > > 
> > > > We can't believe or "suppose" something here, the specs need to
> > > > be
> > > > as an axioma.
> > > > Can someone confirm that this reference includes the wrong
> > > > specs?
> > > 
> > > That's not a specification but a manual page. Timothy is pointing
> > > to
> > > OpenGL specifications (available at www.opengl.org/registry). It
> > > is
> > > true that for example 3.3 Core does not mention this error case
> > > which
> > > means using 0 was allowed there. IMO either we should allow to
> > > use 0
> > > (and bump it to 1?) when running on 3.x context since it's not
> > > forbidden or maybe just locally patch this whenever running 3.x
> > > conformance.
> > 
> > Hi Marius,
> > 
> > Please provide the test CTS test that you are trying to fix so that
> > we can
> > take a look at what the CTS is trying to test.
> > 
> > While the OpenGL 3.2 -> 4.2 specs seem to allow zero due simple to
> > not
> > mentioning it seems odd to me that the CTS would specificly test
> > for this. As
> > far as I understand it a value of 0 would result in undefined
> > behaviour, so it
> > doesn't seem right to allow this for these versions of OpenGL. IMO
> > we should
> > be going with the later specs that fix this oversight for all
> > versions of GL.
> > 
> > One thing I can see the CTS doing in various tests is querying the
> > GL
> > implementation for values, its possible we are passing a value of 0
> > back to
> > the tests somewhere and its trying to used this with the
> > multisample
> > functions. The only way to know whats going on is if you tell us
> > which test
> > you are trying to fix.
> > 
> > Tim
> 
> 
> Hi Tim
> 
> On my case, in file otc_gen_graphics-khronos
> -glconform/framework/opengl/gluStateReset.cpp
> I have something like :
> 
> if (type >= CONTEXTTYPE_GL32_CORE)
> {
> // Reset 2D multisample texture.
> gl.bindTexture 
>  (GL_TEXTURE_2D_MULTISAMPLE, 0);
> gl.texImage2DMultisample   
>  (GL_TEXTURE_2D_MULTISAMPLE, 0, GL_RGBA8, 0, 0, GL_TRUE);
> // Reset 2D multisample array texture.
> gl.bindTexture 
>  (GL_TEXTURE_2D_MULTISAMPLE_ARRAY, 0);
> gl.texImage3DMultisample   
>  (GL_TEXTURE_2D_MULTISAMPLE_ARRAY, 0, GL_RGBA8, 0, 0, 0, GL_TRUE);
> }

Hi Marius,

It may be time for an update of your git repo mine is up to date and

Re: [Mesa-dev] [PATCH] docs: Update GL3.txt to add ARB_internalformat_query2

[Timothy Arceri]

On Thu, 2015-11-26 at 21:11 +0100, Eduardo Lima Mitev wrote:
> Added to OpenGL 4.2 section, tagged as 'in progress'. See
> https://bugs.freedesktop.org/show_bug.cgi?id=92687.
> 
> Thanks to Thomas H.P. Andersen for remainding me about this.
> ---
>  docs/GL3.txt | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/docs/GL3.txt b/docs/GL3.txt
> index ad6b95e..3758b06 100644
> --- a/docs/GL3.txt
> +++ b/docs/GL3.txt
> @@ -145,6 +145,7 @@ GL 4.2, GLSL 4.20:
>GL_ARB_shading_language_packing  DONE (all
> drivers)
>GL_ARB_internalformat_query  DONE (i965,
> nv50, nvc0, r600, radeonsi, llvmpipe, softpipe)
>GL_ARB_map_buffer_alignment  DONE (all
> drivers)
> +  GL_ARB_internalformat_query2 in progress

Are you sure GL_ARB_internalformat_query2 is not part of 4.3? Its
already in the 4.3 section.

>  
>  
>  GL 4.3, GLSL 4.30:
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2] docs: Update GL3.txt to add ARB_internalformat_query2

[Ilia Mirkin]

On Thu, Nov 26, 2015 at 3:57 PM, Eduardo Lima Mitev  wrote:
> Added to OpenGL 4.3 section, tagged as 'in progress (elima)'. See
> https://bugs.freedesktop.org/show_bug.cgi?id=92687.
>
> Thanks to Thomas H.P. Andersen for remainding me about this.
>
> v1: - Update the already existing entry in section 4.3
>   instead (Ilia Mirkin).
> - Added my BZ nickname as contact person (Felix Schwarz).
> ---
>  docs/GL3.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/docs/GL3.txt b/docs/GL3.txt
> index ad6b95e..acf1166 100644
> --- a/docs/GL3.txt
> +++ b/docs/GL3.txt
> @@ -158,7 +158,7 @@ GL 4.3, GLSL 4.30:
>GL_ARB_explicit_uniform_location DONE (all drivers 
> that support GLSL)
>GL_ARB_fragment_layer_viewport   DONE (i965, nv50, 
> nvc0, r600, radeonsi, llvmpipe)
>GL_ARB_framebuffer_no_attachmentsDONE (i965)
> -  GL_ARB_internalformat_query2 not started
> +  GL_ARB_internalformat_query2 in progress (elima)

Good luck! I see lots of typing in your future :)

Reviewed-by: Ilia Mirkin 

>GL_ARB_invalidate_subdataDONE (all drivers)
>GL_ARB_multi_draw_indirect   DONE (i965, nvc0, 
> r600, radeonsi, llvmpipe, softpipe)
>GL_ARB_program_interface_query   DONE (all drivers)
> --
> 2.5.3
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v2] docs: Update GL3.txt to add ARB_internalformat_query2

[Eduardo Lima Mitev]

Added to OpenGL 4.3 section, tagged as 'in progress (elima)'. See
https://bugs.freedesktop.org/show_bug.cgi?id=92687.

Thanks to Thomas H.P. Andersen for remainding me about this.

v1: - Update the already existing entry in section 4.3
  instead (Ilia Mirkin).
- Added my BZ nickname as contact person (Felix Schwarz).
---
 docs/GL3.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/GL3.txt b/docs/GL3.txt
index ad6b95e..acf1166 100644
--- a/docs/GL3.txt
+++ b/docs/GL3.txt
@@ -158,7 +158,7 @@ GL 4.3, GLSL 4.30:
   GL_ARB_explicit_uniform_location DONE (all drivers that 
support GLSL)
   GL_ARB_fragment_layer_viewport   DONE (i965, nv50, nvc0, 
r600, radeonsi, llvmpipe)
   GL_ARB_framebuffer_no_attachmentsDONE (i965)
-  GL_ARB_internalformat_query2 not started
+  GL_ARB_internalformat_query2 in progress (elima)
   GL_ARB_invalidate_subdataDONE (all drivers)
   GL_ARB_multi_draw_indirect   DONE (i965, nvc0, r600, 
radeonsi, llvmpipe, softpipe)
   GL_ARB_program_interface_query   DONE (all drivers)
-- 
2.5.3

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

Re: [Mesa-dev] [PATCH] docs: Update GL3.txt to add ARB_internalformat_query2

[Eduardo Lima Mitev]

On 11/26/2015 09:43 PM, Ilia Mirkin wrote:
> On Thu, Nov 26, 2015 at 3:11 PM, Eduardo Lima Mitev  wrote:
>> Added to OpenGL 4.2 section, tagged as 'in progress'. See
>> https://bugs.freedesktop.org/show_bug.cgi?id=92687.
>>
>> Thanks to Thomas H.P. Andersen for remainding me about this.
>> ---
>>  docs/GL3.txt | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/docs/GL3.txt b/docs/GL3.txt
>> index ad6b95e..3758b06 100644
>> --- a/docs/GL3.txt
>> +++ b/docs/GL3.txt
>> @@ -145,6 +145,7 @@ GL 4.2, GLSL 4.20:
>>GL_ARB_shading_language_packing  DONE (all drivers)
>>GL_ARB_internalformat_query  DONE (i965, nv50, 
>> nvc0, r600, radeonsi, llvmpipe, softpipe)
>>GL_ARB_map_buffer_alignment  DONE (all drivers)
>> +  GL_ARB_internalformat_query2 in progress
> 
> Isn't it already part of the GL 4.3 section (and isn't it core in 4.3?
> it says it's written against the 4.2 profile, so it def can't be part
> of 4.2...)
> 

Oh! True, I completely overlooked that and went straight to 4.2. Fixing
it now.

Thanks,
Eduardo

>>
>>
>>  GL 4.3, GLSL 4.30:
>> --
>> 2.5.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] [PATCH] docs: Update GL3.txt to add ARB_internalformat_query2

[Ilia Mirkin]

On Thu, Nov 26, 2015 at 3:11 PM, Eduardo Lima Mitev  wrote:
> Added to OpenGL 4.2 section, tagged as 'in progress'. See
> https://bugs.freedesktop.org/show_bug.cgi?id=92687.
>
> Thanks to Thomas H.P. Andersen for remainding me about this.
> ---
>  docs/GL3.txt | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/docs/GL3.txt b/docs/GL3.txt
> index ad6b95e..3758b06 100644
> --- a/docs/GL3.txt
> +++ b/docs/GL3.txt
> @@ -145,6 +145,7 @@ GL 4.2, GLSL 4.20:
>GL_ARB_shading_language_packing  DONE (all drivers)
>GL_ARB_internalformat_query  DONE (i965, nv50, 
> nvc0, r600, radeonsi, llvmpipe, softpipe)
>GL_ARB_map_buffer_alignment  DONE (all drivers)
> +  GL_ARB_internalformat_query2 in progress

Isn't it already part of the GL 4.3 section (and isn't it core in 4.3?
it says it's written against the 4.2 profile, so it def can't be part
of 4.2...)

>
>
>  GL 4.3, GLSL 4.30:
> --
> 2.5.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] [PATCH] util: Tiny optimisation for the linear→srgb conversion

[Jason Ekstrand]

Sure. R-B
On Nov 26, 2015 8:58 AM, "Neil Roberts"  wrote:

> When converting 0.0 it would be nice if it didn't do any arithmetic.
> ---
>  src/util/format_srgb.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/util/format_srgb.h b/src/util/format_srgb.h
> index 4a8d73f..34b50af 100644
> --- a/src/util/format_srgb.h
> +++ b/src/util/format_srgb.h
> @@ -57,7 +57,7 @@ util_format_linear_to_srgb_helper_table[104];
>  static inline float
>  util_format_linear_to_srgb_float(float cl)
>  {
> -   if (cl < 0.0f)
> +   if (cl <= 0.0f)
>return 0.0f;
> else if (cl < 0.0031308f)
>return 12.92f * cl;
> --
> 1.9.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 93114] No water rendered in CoR

[bugzilla-daemon]

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

Jason Ekstrand  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO

--- Comment #6 from Jason Ekstrand  ---
Could you get an API trace and them verify that the trace renders correctly on
fglrx.  That will a) verify that it's a driver bug and not a game bug and b)
make it easier to debug for devs who don't play CoR.

https://github.com/apitrace/apitrace

-- 
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 v2 1/1] i965: Do not overwrite optimizer dumps

[Jason Ekstrand]

On Nov 26, 2015 6:02 AM, "Juan A. Suarez Romero" 
wrote:
>
> When using INTEL_DEBUG=optimizer, each optimizing step is dump to disk,
> in a separate file.
>
> But as fs_visitor::optimize() and vec4_visitor::run() are called more
> than once, it ends up overwriting the files already on disk, loosing
> then previous optimizer steps.
>
> To avoid this, add a new static variable that tracks the global
> iteration across the entire life of the program running.
>
> v2: use atomic_inc() for the static variable (Jason).
>
> Signed-off-by: Juan A. Suarez Romero 
> ---
>  src/mesa/drivers/dri/i965/brw_fs.cpp   | 15 +++
>  src/mesa/drivers/dri/i965/brw_vec4.cpp | 13 +
>  2 files changed, 20 insertions(+), 8 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
> index 7904f4d..72ee5cc 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
> @@ -39,6 +39,7 @@
>  #include "brw_program.h"
>  #include "brw_dead_control_flow.h"
>  #include "glsl/nir/glsl_types.h"
> +#include "util/u_atomic.h"
>
>  using namespace brw;
>
> @@ -4948,6 +4949,9 @@ fs_visitor::calculate_register_pressure()
>  void
>  fs_visitor::optimize()
>  {
> +   static int global_iteration_atomic = 0;
> +   int global_iteration;

Of you did the increment here, you could make this const.

> +
> /* Start by validating the shader we currently have. */
> validate();
>
> @@ -4978,8 +4982,9 @@ fs_visitor::optimize()
>  \
>if (unlikely(INTEL_DEBUG & DEBUG_OPTIMIZER) && this_progress) {   \
>   char filename[64]; \
> - snprintf(filename, 64, "%s%d-%s-%02d-%02d-" #pass,
\
> -  stage_abbrev, dispatch_width, nir->info.name,
iteration, pass_num); \
> + snprintf(filename, 64, "%s%d-%s-%02d-%02d-%02d-" #pass,\
> +  stage_abbrev, dispatch_width, nir->info.name, \
> +  global_iteration, iteration, pass_num);   \
>  \
>   backend_shader::dump_instructions(filename);   \
>} \
> @@ -4990,10 +4995,12 @@ fs_visitor::optimize()
>this_progress;\
> })
>
> +   global_iteration = p_atomic_inc_return(&global_iteration_atomic);

It would make things more clear of you out this above the macro definition.
The macro isn't used until after this, but that would be more clear if the
increment were higher up.

> +
> if (unlikely(INTEL_DEBUG & DEBUG_OPTIMIZER)) {
>char filename[64];
> -  snprintf(filename, 64, "%s%d-%s-00-start",
> -   stage_abbrev, dispatch_width, nir->info.name);
> +  snprintf(filename, 64, "%s%d-%s-%02d-00-00-start",
> +   stage_abbrev, dispatch_width, nir->info.name,
global_iteration);
>
>backend_shader::dump_instructions(filename);
> }
> diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp
b/src/mesa/drivers/dri/i965/brw_vec4.cpp
> index 9a79d67..dd44b32 100644
> --- a/src/mesa/drivers/dri/i965/brw_vec4.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_vec4.cpp
> @@ -29,6 +29,7 @@
>  #include "brw_vec4_live_variables.h"
>  #include "brw_dead_control_flow.h"
>  #include "program/prog_parameter.h"
> +#include "util/u_atomic.h"
>
>  #define MAX_INSTRUCTION (1 << 30)
>
> @@ -1779,6 +1780,9 @@ vec4_visitor::convert_to_hw_regs()
>  bool
>  vec4_visitor::run()
>  {
> +   static int global_iteration_atomic = 0;
> +   int global_iteration;
> +
> if (shader_time_index >= 0)
>emit_shader_time_begin();
>
> @@ -1812,8 +1816,8 @@ vec4_visitor::run()
> \
>if (unlikely(INTEL_DEBUG & DEBUG_OPTIMIZER) && this_progress) {  \
>   char filename[64];\
> - snprintf(filename, 64, "%s-%s-%02d-%02d-" #pass,  \
> -  stage_abbrev, nir->info.name, iteration, pass_num);  \
> + snprintf(filename, 64, "%s-%s-%02d-%02d-%02d-" #pass, \
> +  stage_abbrev, nir->info.name, global_iteration,
iteration, pass_num); \
> \
>   backend_shader::dump_instructions(filename);  \
>}\
> @@ -1822,11 +1826,12 @@ vec4_visitor::run()
>this_progress;   \
> })
>
> +   global_iteration = p_atomic_inc_return(&global_iteration_atomic);

Same comment.

> if (unlikely(INTEL_DEBUG & DEBUG_OPTIMIZER)) {
>char filename[64];
> -  snprintf(filename, 64, "%s-%s-00-start

[Mesa-dev] [PATCH] docs: Update GL3.txt to add ARB_internalformat_query2

[Eduardo Lima Mitev]

Added to OpenGL 4.2 section, tagged as 'in progress'. See
https://bugs.freedesktop.org/show_bug.cgi?id=92687.

Thanks to Thomas H.P. Andersen for remainding me about this.
---
 docs/GL3.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/docs/GL3.txt b/docs/GL3.txt
index ad6b95e..3758b06 100644
--- a/docs/GL3.txt
+++ b/docs/GL3.txt
@@ -145,6 +145,7 @@ GL 4.2, GLSL 4.20:
   GL_ARB_shading_language_packing  DONE (all drivers)
   GL_ARB_internalformat_query  DONE (i965, nv50, nvc0, 
r600, radeonsi, llvmpipe, softpipe)
   GL_ARB_map_buffer_alignment  DONE (all drivers)
+  GL_ARB_internalformat_query2 in progress
 
 
 GL 4.3, GLSL 4.30:
-- 
2.5.3

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

Re: [Mesa-dev] [PATCH 1/2] gallium: Make pipe_query_result::batch array length non-zero.

[Roland Scheidegger]

Am 26.11.2015 um 15:31 schrieb Jose Fonseca:
> Zero length arrays are non standard:
> 
>warning C4200: nonstandard extension used : zero-sized array in 
> struct/union
>Cannot generate copy-ctor or copy-assignment operator when UDT contains a 
> zero-sized array
> 
> And all code does `N * sizeof query_result->batch[0]`, so it should work
> exactly the same.
> ---
>  src/gallium/include/pipe/p_defines.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/src/gallium/include/pipe/p_defines.h 
> b/src/gallium/include/pipe/p_defines.h
> index b18eedd..cbf0ba6 100644
> --- a/src/gallium/include/pipe/p_defines.h
> +++ b/src/gallium/include/pipe/p_defines.h
> @@ -822,8 +822,8 @@ union pipe_query_result
> /* PIPE_QUERY_PIPELINE_STATISTICS */
> struct pipe_query_data_pipeline_statistics pipeline_statistics;
>  
> -   /* batch queries */
> -   union pipe_numeric_type_union batch[0];
> +   /* batch queries (variable length) */
> +   union pipe_numeric_type_union batch[1];
>  };
>  
>  union pipe_color_union
> 

I guess the nice thing about using zero-sized arrays is that it makes it
really obvious that the length is variable, whereas with size one
someone might assume it's fixed. But you added the comment so I can't
see a better solution.

For the series:
Reviewed-by: Roland Scheidegger 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 23/24] i965/vec4: Replace src_reg(imm) constructors with brw_imm_*().

[Emil Velikov]

On 25 November 2015 at 22:48, Matt Turner  wrote:

> I can't see it, but that might be because I can't stop thinking like I
> was when I wrote the code.
>
Understandable, we've all been there.

> Yeah, we skip any instruction that has a full writemask -- because if
> it has a full writemask, we can just load the immediate as-is and we
> don't need to turn it into 4x restricted floats. But that doesn't seem
> to be related to the warning.
>
> The code seems fine to me. Here's what I see:
>
> We start with remaining_channels = WRITEMASK_XYZW.
Actually we start with WRITEMASK_NONE (0). Based on your knowledge you
can establish that on the first iteration(?) remaining_channels will
be set to WRITEMASK_XYZW, although the compiler cannot determine that.

> We initialize an
> element of imm[] for each enabled bit of inst->dst.writemask, and then
> we disable those bits from remaining_channels.
If all channels are set we bail out just before that. Thus as we hit
the imm[x] assignments of at least one channel is not set. Be that
left uninitialized or storing data from a previous instruction. I take
that this is by design ?

> When remaining_channels
> is zero (should be if and only if all elements of imm[] are
> initialized), we read imm[].
>
Barring your existing knowledge, remaining_channels can be zero on the
first, second,  N'th iteration, albeit extremely unlikely. Thus
regardless of what data we have in imm[], we'll proceed to use it.

> Do you see anything wrong or anything I've missed?
>
> FWIW, Clang does not warn about this and doesn't warn if I remove the
> useless initializations of remaining_channels = 0 and inst_count = 0.
> I think this is gcc and Coverity just being stupid.
I think the whole things is that you know who it will run, whereas the
code makes is a bit ambiguous.

To fix (?) and make things a lot more obvious I'd suggest initializing
(upon declaration) remaining_channels with WRITEMASK_XYZW. If
gcc/coverity/other complains with that in place then it's definitely a
defect on their end.

Out of curiosity: what is the input from gcc devs, do you have the bug
number handy ?

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

[Mesa-dev] [PATCH] util: Tiny optimisation for the linear→srgb conversion

[Neil Roberts]

When converting 0.0 it would be nice if it didn't do any arithmetic.
---
 src/util/format_srgb.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/util/format_srgb.h b/src/util/format_srgb.h
index 4a8d73f..34b50af 100644
--- a/src/util/format_srgb.h
+++ b/src/util/format_srgb.h
@@ -57,7 +57,7 @@ util_format_linear_to_srgb_helper_table[104];
 static inline float
 util_format_linear_to_srgb_float(float cl)
 {
-   if (cl < 0.0f)
+   if (cl <= 0.0f)
   return 0.0f;
else if (cl < 0.0031308f)
   return 12.92f * cl;
-- 
1.9.3

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

Re: [Mesa-dev] [PATCH 1/2] gallium: Make pipe_query_result::batch array length non-zero.

[Nicolai Hähnle]

On 26.11.2015 15:31, Jose Fonseca wrote:

Zero length arrays are non standard:

warning C4200: nonstandard extension used : zero-sized array in struct/union
Cannot generate copy-ctor or copy-assignment operator when UDT contains a 
zero-sized array

And all code does `N * sizeof query_result->batch[0]`, so it should work
exactly the same.
---
  src/gallium/include/pipe/p_defines.h | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)


Sorry about that.

Reviewed-by: Nicolai Hähnle 


diff --git a/src/gallium/include/pipe/p_defines.h 
b/src/gallium/include/pipe/p_defines.h
index b18eedd..cbf0ba6 100644
--- a/src/gallium/include/pipe/p_defines.h
+++ b/src/gallium/include/pipe/p_defines.h
@@ -822,8 +822,8 @@ union pipe_query_result
 /* PIPE_QUERY_PIPELINE_STATISTICS */
 struct pipe_query_data_pipeline_statistics pipeline_statistics;

-   /* batch queries */
-   union pipe_numeric_type_union batch[0];
+   /* batch queries (variable length) */
+   union pipe_numeric_type_union batch[1];
  };

  union pipe_color_union



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

[Mesa-dev] [Bug 93103] llvm symbols leak through, cause trouble with software rendering in llvm-linked software

[bugzilla-daemon]

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

--- Comment #13 from Tobias Schlüter  ---
(In reply to Emil Velikov from comment #12)
> (In reply to Tobias Schlüter from comment #10)
> > I have pointed the ROOT people to this bug report, I hope they can draw
> > their conclusions from this.  We're currently setting up mesa 11 and the
> > latest version of ROOT, and I will report back.
> Great, good luck (in an honest, non sarcastic way).

Thanks, they seem to work together, at least the simple crash-provoking
mechanism fails there.

-- 
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] [PATCH] mesa: support GL_RED/GL_RG in ES2 contexts when driver support exists

[Ilia Mirkin]

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93126
Signed-off-by: Ilia Mirkin 
Cc: "11.0 11.1" 
---
 src/mesa/main/glformats.c | 8 +++-
 src/mesa/main/glformats.h | 3 ++-
 src/mesa/main/readpix.c   | 2 +-
 src/mesa/main/teximage.c  | 2 +-
 4 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/src/mesa/main/glformats.c b/src/mesa/main/glformats.c
index 2ed42ea..7b264eb 100644
--- a/src/mesa/main/glformats.c
+++ b/src/mesa/main/glformats.c
@@ -2077,12 +2077,18 @@ _mesa_error_check_format_and_type(const struct 
gl_context *ctx,
  * \return error code, or GL_NO_ERROR.
  */
 GLenum
-_mesa_es_error_check_format_and_type(GLenum format, GLenum type,
+_mesa_es_error_check_format_and_type(const struct gl_context *ctx,
+ GLenum format, GLenum type,
  unsigned dimensions)
 {
GLboolean type_valid = GL_TRUE;
 
switch (format) {
+   case GL_RED:
+   case GL_RG:
+  if (!ctx->Extensions.ARB_texture_rg)
+ return GL_INVALID_VALUE;
+  /* fallthrough */
case GL_ALPHA:
case GL_LUMINANCE:
case GL_LUMINANCE_ALPHA:
diff --git a/src/mesa/main/glformats.h b/src/mesa/main/glformats.h
index 92f4bc6..b366855 100644
--- a/src/mesa/main/glformats.h
+++ b/src/mesa/main/glformats.h
@@ -127,7 +127,8 @@ _mesa_error_check_format_and_type(const struct gl_context 
*ctx,
   GLenum format, GLenum type);
 
 extern GLenum
-_mesa_es_error_check_format_and_type(GLenum format, GLenum type,
+_mesa_es_error_check_format_and_type(const struct gl_context *ctx,
+ GLenum format, GLenum type,
  unsigned dimensions);
 
 extern GLenum
diff --git a/src/mesa/main/readpix.c b/src/mesa/main/readpix.c
index 81bb912..8cdc9fe 100644
--- a/src/mesa/main/readpix.c
+++ b/src/mesa/main/readpix.c
@@ -1043,7 +1043,7 @@ _mesa_ReadnPixelsARB( GLint x, GLint y, GLsizei width, 
GLsizei height,
   _mesa_get_color_read_type(ctx) == type) {
  err = GL_NO_ERROR;
   } else if (ctx->Version < 30) {
- err = _mesa_es_error_check_format_and_type(format, type, 2);
+ err = _mesa_es_error_check_format_and_type(ctx, format, type, 2);
  if (err == GL_NO_ERROR) {
 if (type == GL_FLOAT || type == GL_HALF_FLOAT_OES) {
err = GL_INVALID_OPERATION;
diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index ac7599f..37dbe26 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -1699,7 +1699,7 @@ texture_format_error_check_gles(struct gl_context *ctx, 
GLenum format,
   }
}
else {
-  err = _mesa_es_error_check_format_and_type(format, type, dimensions);
+  err = _mesa_es_error_check_format_and_type(ctx, format, type, 
dimensions);
   if (err != GL_NO_ERROR) {
  _mesa_error(ctx, err, "%s(format = %s, type = %s)",
  callerName, _mesa_enum_to_string(format),
-- 
2.4.10

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

Re: [Mesa-dev] [PATCH 2/2] i965: run brw_vec4 optimizations in loop

[Juan A. Suarez Romero]

On Wed, 2015-11-25 at 16:16 -0800, Matt Turner wrote:
> In the piglit test you cited, opt_vector_float() does this to the
> relevant code:
> 
>  cmp.nz.f0.0 null:F, vgrf6.xyzz:F, vgrf14.xyzz:F
> -mov vgrf2.0.x:D, 0D
>  (+f0.0.any4h) mov vgrf2.0.x:D, -1D
> -mov vgrf2.0.yzw:D, 0D
> +mov vgrf2.0:F, [0F, 0F, 0F, 0F]
>  cmp.nz.f0.0 null:D, vgrf2.xyzw:D, 0D
> 


Now that you point to this change, is it correct?

Before the change, vgrf2.0.x is initialized to 0, and if the previous
cmp success then assigned -1.


But after the change, the value is initialized to 0 *after* the
conditional check, so it ends up always with 0 (-1D is never assigned).

So seems opt_vector_float() is doing something wrong (probably not
checking if the component can be assigned in a conditional).

Am I missing something?


J.A.

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

[Mesa-dev] [Bug 93126] wrongly claim supporting GL_EXT_texture_rg

[bugzilla-daemon]

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

--- Comment #2 from Julien Isorce  ---
I confirm your patch fixes the problem. (tested with glTexImage2D(...,
GL_RED_EXT) + glCheckFramebufferStatusEXT). Thx Ilia :)

-- 
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 93126] wrongly claim supporting GL_EXT_texture_rg

[bugzilla-daemon]

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

--- Comment #1 from Ilia Mirkin  ---
Created attachment 120147
  --> https://bugs.freedesktop.org/attachment.cgi?id=120147&action=edit
fix rg support on es2

Does the attached patch fix it? Not sure how you're ending up with ES2
though... I thought it'd automatically get upgraded to ES3.0... Perhaps you
built without float texture support? But that should still not be required for
ES3...

-- 
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 93126] wrongly claim supporting GL_EXT_texture_rg

[bugzilla-daemon]

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

Bug ID: 93126
   Summary: wrongly claim supporting GL_EXT_texture_rg
   Product: Mesa
   Version: git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Mesa core
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: julien.iso...@gmail.com
QA Contact: mesa-dev@lists.freedesktop.org

es2_info prints:

GL_VERSION: OpenGL ES 2.0 Mesa 11.2.0-devel
GL_RENDERER: Gallium 0.4 on NVC1
GL_EXTENSIONS contains GL_EXT_texture_rg

But glTexImage2D(..., GL_RED_EXT, GL_UNSIGNED_BYTE, data) fails.

Indeed  if GLES2.0 then
http://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/main/glformats.c#n2079 .
There is no case for GL_RED_EXT in the switch so it defaults to
GL_INVALID_VALUE.

I can see EXT(EXT_texture_rg, ARB_texture_rg,  x ,  x ,  x , ES2, 2011) in
extensions_table.h

Hardware: NVIDIA Corporation GF108 [GeForce GT 430] (rev a1)

Could it be that when querying dri2 for the gl version it returns 20 instead of
30 ?

-- 
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] [PATCH] scons: Use LD version script for libgl-xlib.

[Jose Fonseca]

---
 src/gallium/targets/libgl-xlib/SConscript | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/src/gallium/targets/libgl-xlib/SConscript 
b/src/gallium/targets/libgl-xlib/SConscript
index df5a220..687a8b9d 100644
--- a/src/gallium/targets/libgl-xlib/SConscript
+++ b/src/gallium/targets/libgl-xlib/SConscript
@@ -46,9 +46,13 @@ if env['llvm']:
 env.Append(CPPDEFINES = ['GALLIUM_LLVMPIPE'])
 env.Prepend(LIBS = [llvmpipe])
 
-# Disallow undefined symbols
 if env['platform'] != 'darwin':
-env.Append(SHLINKFLAGS = ['-Wl,-z,defs'])
+env.Append(SHLINKFLAGS = [
+   # Disallow undefined symbols
+   '-Wl,-z,defs',
+   # Restrict exported symbols
+   '-Wl,--version-script=%s' % File("libgl-xlib.sym").srcnode().path,
+])
 
 # libGL.so.1.5
 libgl_1_5 = env.SharedLibrary(
-- 
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 08/42] i965/hsw: Enable L3 atomics.

[Samuel Iglesias Gonsálvez]

On 26/11/15 16:14, Samuel Iglesias Gonsálvez wrote:
> On 26/11/15 15:44, Francisco Jerez wrote:
>> Samuel Iglesias Gonsálvez  writes:
>>
>>> On 18/11/15 06:54, Jordan Justen wrote:
 From: Francisco Jerez 

 Improves performance of the arb_shader_image_load_store-atomicity
 piglit test by over 25x (which isn't a real benchmark it's just heavy
 on atomics -- the improvement in a microbenchmark I wrote a while ago
 seemed to be even greater).  The drawback is one needs to be
 extra-careful not to hang the GPU (in fact the whole system).  A DC
 partition must have been allocated on L3, the "convert L3 cycle for DC
 to UC" bit may not be set, the MOCS L3 cacheability bit must be set
 for all surfaces accessed using DC atomics, and the SCRATCH1 and
 ROW_CHICKEN3 bits must be kept in sync.

 A fairly recent kernel is required for the command parser to allow
 writes to these registers.
 ---
  src/mesa/drivers/dri/i965/gen7_l3_state.c | 14 ++
  1 file changed, 14 insertions(+)

 diff --git a/src/mesa/drivers/dri/i965/gen7_l3_state.c 
 b/src/mesa/drivers/dri/i965/gen7_l3_state.c
 index 48bca29..c863b7f 100644
 --- a/src/mesa/drivers/dri/i965/gen7_l3_state.c
 +++ b/src/mesa/drivers/dri/i965/gen7_l3_state.c
 @@ -254,5 +254,19 @@ setup_l3_config(struct brw_context *brw, const struct 
 brw_l3_config *cfg)
  SET_FIELD(cfg->n[L3P_T], GEN7_L3CNTLREG3_T_ALLOC));
  
ADVANCE_BATCH();
 +
 +  if (brw->is_haswell && brw->intelScreen->cmd_parser_version >= 4) {
 + /* Enable L3 atomics on HSW if we have a DC partition, otherwise 
 keep
 +  * them disabled to avoid crashing the system hard.
 +  */
 + BEGIN_BATCH(5);
 + OUT_BATCH(MI_LOAD_REGISTER_IMM | (5 - 2));
 + OUT_BATCH(HSW_SCRATCH1);
 + OUT_BATCH(has_dc ? 0 : HSW_SCRATCH1_L3_ATOMIC_DISABLE);
 + OUT_BATCH(HSW_ROW_CHICKEN3);
 + OUT_BATCH(HSW_ROW_CHICKEN3_L3_ATOMIC_DISABLE << 16 |
 +   (has_dc ? 0 : HSW_ROW_CHICKEN3_L3_ATOMIC_DISABLE));
>>>
>>>
>>> I have not found references to ROW_CHICKEN3 nor register with 0xe49c
>>> address offset in HSW PRMs, so these could be stupid questions:
>>>
>>
>> Yeah, these chicken registers are not part of the public PRMs.
>>
>>> Why you need to set the L3 atomic disable flag in two different places
>>> in ROW_CHICKEN3 register? Also, why the first flag is set
>>> unconditionally while the second one only if we don't have a DC
>>> partition? This is what you want?
>>
>> It's a masked register as many other MMIO registers on Gen hardware: the
>> upper 16 bits control which of the lower 16 bits are modified in the
>> register.
>>
>>>
>>>
>>> Also, if the "HSW_ROW_CHICKEN3_L3_ATOMIC_DISABLE << 16" is really
>>> needed, it could be defined as a constant in the first patch of the series.
>>>
>> If you think that would be more readable I guess we could define a
>> REG_MASK() macro and use it wherever we write a masked register.  See
>> attachment (applies on top of this patch).
>>
> 

Forgot to say my R-b to this patch is with the REG_MASK() macro change.

> OK, thanks for the explanation. Please add my R-b to this patch and to
> the attached one:
> 
> Reviewed-by: Samuel Iglesias Gonsálvez 
> 
> Sam
> 
>>> Sam
>>>
 + ADVANCE_BATCH();
 +  }
 }
  }

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

Re: [Mesa-dev] [PATCH v2 08/42] i965/hsw: Enable L3 atomics.

[Samuel Iglesias Gonsálvez]

On 26/11/15 15:44, Francisco Jerez wrote:
> Samuel Iglesias Gonsálvez  writes:
> 
>> On 18/11/15 06:54, Jordan Justen wrote:
>>> From: Francisco Jerez 
>>>
>>> Improves performance of the arb_shader_image_load_store-atomicity
>>> piglit test by over 25x (which isn't a real benchmark it's just heavy
>>> on atomics -- the improvement in a microbenchmark I wrote a while ago
>>> seemed to be even greater).  The drawback is one needs to be
>>> extra-careful not to hang the GPU (in fact the whole system).  A DC
>>> partition must have been allocated on L3, the "convert L3 cycle for DC
>>> to UC" bit may not be set, the MOCS L3 cacheability bit must be set
>>> for all surfaces accessed using DC atomics, and the SCRATCH1 and
>>> ROW_CHICKEN3 bits must be kept in sync.
>>>
>>> A fairly recent kernel is required for the command parser to allow
>>> writes to these registers.
>>> ---
>>>  src/mesa/drivers/dri/i965/gen7_l3_state.c | 14 ++
>>>  1 file changed, 14 insertions(+)
>>>
>>> diff --git a/src/mesa/drivers/dri/i965/gen7_l3_state.c 
>>> b/src/mesa/drivers/dri/i965/gen7_l3_state.c
>>> index 48bca29..c863b7f 100644
>>> --- a/src/mesa/drivers/dri/i965/gen7_l3_state.c
>>> +++ b/src/mesa/drivers/dri/i965/gen7_l3_state.c
>>> @@ -254,5 +254,19 @@ setup_l3_config(struct brw_context *brw, const struct 
>>> brw_l3_config *cfg)
>>>  SET_FIELD(cfg->n[L3P_T], GEN7_L3CNTLREG3_T_ALLOC));
>>>  
>>>ADVANCE_BATCH();
>>> +
>>> +  if (brw->is_haswell && brw->intelScreen->cmd_parser_version >= 4) {
>>> + /* Enable L3 atomics on HSW if we have a DC partition, otherwise 
>>> keep
>>> +  * them disabled to avoid crashing the system hard.
>>> +  */
>>> + BEGIN_BATCH(5);
>>> + OUT_BATCH(MI_LOAD_REGISTER_IMM | (5 - 2));
>>> + OUT_BATCH(HSW_SCRATCH1);
>>> + OUT_BATCH(has_dc ? 0 : HSW_SCRATCH1_L3_ATOMIC_DISABLE);
>>> + OUT_BATCH(HSW_ROW_CHICKEN3);
>>> + OUT_BATCH(HSW_ROW_CHICKEN3_L3_ATOMIC_DISABLE << 16 |
>>> +   (has_dc ? 0 : HSW_ROW_CHICKEN3_L3_ATOMIC_DISABLE));
>>
>>
>> I have not found references to ROW_CHICKEN3 nor register with 0xe49c
>> address offset in HSW PRMs, so these could be stupid questions:
>>
> 
> Yeah, these chicken registers are not part of the public PRMs.
> 
>> Why you need to set the L3 atomic disable flag in two different places
>> in ROW_CHICKEN3 register? Also, why the first flag is set
>> unconditionally while the second one only if we don't have a DC
>> partition? This is what you want?
> 
> It's a masked register as many other MMIO registers on Gen hardware: the
> upper 16 bits control which of the lower 16 bits are modified in the
> register.
> 
>>
>>
>> Also, if the "HSW_ROW_CHICKEN3_L3_ATOMIC_DISABLE << 16" is really
>> needed, it could be defined as a constant in the first patch of the series.
>>
> If you think that would be more readable I guess we could define a
> REG_MASK() macro and use it wherever we write a masked register.  See
> attachment (applies on top of this patch).
> 

OK, thanks for the explanation. Please add my R-b to this patch and to
the attached one:

Reviewed-by: Samuel Iglesias Gonsálvez 

Sam

>> Sam
>>
>>> + ADVANCE_BATCH();
>>> +  }
>>> }
>>>  }
>>>
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 93091] [opencl] segfault when running any opencl programs (like clinfo)

[bugzilla-daemon]

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

Emil Velikov  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #11 from Emil Velikov  ---
As per comment 10, I'm closing this bug.

Samuel, can you please open another bug (or catch me on IRC) with the requested
information ? If you have some changes on top of master, please point me to a
branch where I can skim through. Thanks

-- 
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 93103] llvm symbols leak through, cause trouble with software rendering in llvm-linked software

[bugzilla-daemon]

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

--- Comment #12 from Emil Velikov  ---
(In reply to Tobias Schlüter from comment #10)
> Probably no longer relevant per #8, and I don't know how to tell different
> libGL.so.1 apart with certainty, but I guess you can do this based on ldd
> output, so here goes (DRI appears, Xlib doesn't):
> $ ldd /usr/lib/x86_64-linux-gnu/mesa/libGL.so

>   libglapi.so.0 => /usr/lib/x86_64-linux-gnu/libglapi.so.0
Based on this I'd say 

> (0x7f118cf53000)
>   libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 
> (0x7f118cd41000)
>   libXdamage.so.1 => /usr/lib/x86_64-linux-gnu/libXdamage.so.1
> (0x7f118cb3e000)
>   libXfixes.so.3 => /usr/lib/x86_64-linux-gnu/libXfixes.so.3
> (0x7f118c938000)
>   libX11-xcb.so.1 => /usr/lib/x86_64-linux-gnu/libX11-xcb.so.1
> (0x7f118c736000)
>   libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 
> (0x7f118c401000)
>   libxcb-glx.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-glx.so.0
> (0x7f118c1ea000)
>   libxcb-dri2.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-dri2.so.0
> (0x7f118bfe5000)
>   libxcb-dri3.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-dri3.so.0
> (0x7f118bde2000)
>   libxcb-present.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-present.so.0
> (0x7f118bbdf000)
>   libxcb-sync.so.1 => /usr/lib/x86_64-linux-gnu/libxcb-sync.so.1
> (0x7f118b9d9000)
>   libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 
> (0x7f118b7ba000)
>   libxshmfence.so.1 => /usr/lib/x86_64-linux-gnu/libxshmfence.so.1
> (0x7f118b5b8000)
>   libXxf86vm.so.1 => /usr/lib/x86_64-linux-gnu/libXxf86vm.so.1
> (0x7f118b3b2000)
>   libdrm.so.2 => /usr/lib/x86_64-linux-gnu/libdrm.so.2 
> (0x7f118b1a6000)
>   libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
> (0x7f118af88000)
>   libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f118ad84000)
>   libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f118a9bf000)
>   libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 
> (0x7f118a7bb000)
>   libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6
> (0x7f118a5b5000)
>   /lib64/ld-linux-x86-64.so.2 (0x7f118d3e)
> $
> 
> Concerning #6, from which I learnt a lot, thank you for that, two comments:
Glad to hear.

> 1) I wouldn't consider it good practice to redefine LLVM as a "system
> library" and then blame problems related to it on users
In my view once any library is installed system wide it can be considered
"system". As to who and why did that is not a another question for me to answer
;-)

> 2) I guess I could read your comment as saying that the bug lies with LLVM
> as they (at least up to version 3.6) don't version their symbols correct
> (though from a user-experience side there is an issue with libmesa, even if
> it is inherited)
> 
That plus the possible RTLD_GLOBAL issue. On the good side I should be looking
into our end soonish.

> I have pointed the ROOT people to this bug report, I hope they can draw
> their conclusions from this.  We're currently setting up mesa 11 and the
> latest version of ROOT, and I will report back.
> 
> ps concerning the choices about who should statically link, I agree with #9
> (submitted while I was putting this comment together).
Great, good luck (in an honest, non sarcastic way).

-- 
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 v2 08/42] i965/hsw: Enable L3 atomics.

[Francisco Jerez]

Samuel Iglesias Gonsálvez  writes:

> On 18/11/15 06:54, Jordan Justen wrote:
>> From: Francisco Jerez 
>> 
>> Improves performance of the arb_shader_image_load_store-atomicity
>> piglit test by over 25x (which isn't a real benchmark it's just heavy
>> on atomics -- the improvement in a microbenchmark I wrote a while ago
>> seemed to be even greater).  The drawback is one needs to be
>> extra-careful not to hang the GPU (in fact the whole system).  A DC
>> partition must have been allocated on L3, the "convert L3 cycle for DC
>> to UC" bit may not be set, the MOCS L3 cacheability bit must be set
>> for all surfaces accessed using DC atomics, and the SCRATCH1 and
>> ROW_CHICKEN3 bits must be kept in sync.
>> 
>> A fairly recent kernel is required for the command parser to allow
>> writes to these registers.
>> ---
>>  src/mesa/drivers/dri/i965/gen7_l3_state.c | 14 ++
>>  1 file changed, 14 insertions(+)
>> 
>> diff --git a/src/mesa/drivers/dri/i965/gen7_l3_state.c 
>> b/src/mesa/drivers/dri/i965/gen7_l3_state.c
>> index 48bca29..c863b7f 100644
>> --- a/src/mesa/drivers/dri/i965/gen7_l3_state.c
>> +++ b/src/mesa/drivers/dri/i965/gen7_l3_state.c
>> @@ -254,5 +254,19 @@ setup_l3_config(struct brw_context *brw, const struct 
>> brw_l3_config *cfg)
>>  SET_FIELD(cfg->n[L3P_T], GEN7_L3CNTLREG3_T_ALLOC));
>>  
>>ADVANCE_BATCH();
>> +
>> +  if (brw->is_haswell && brw->intelScreen->cmd_parser_version >= 4) {
>> + /* Enable L3 atomics on HSW if we have a DC partition, otherwise 
>> keep
>> +  * them disabled to avoid crashing the system hard.
>> +  */
>> + BEGIN_BATCH(5);
>> + OUT_BATCH(MI_LOAD_REGISTER_IMM | (5 - 2));
>> + OUT_BATCH(HSW_SCRATCH1);
>> + OUT_BATCH(has_dc ? 0 : HSW_SCRATCH1_L3_ATOMIC_DISABLE);
>> + OUT_BATCH(HSW_ROW_CHICKEN3);
>> + OUT_BATCH(HSW_ROW_CHICKEN3_L3_ATOMIC_DISABLE << 16 |
>> +   (has_dc ? 0 : HSW_ROW_CHICKEN3_L3_ATOMIC_DISABLE));
>
>
> I have not found references to ROW_CHICKEN3 nor register with 0xe49c
> address offset in HSW PRMs, so these could be stupid questions:
>

Yeah, these chicken registers are not part of the public PRMs.

> Why you need to set the L3 atomic disable flag in two different places
> in ROW_CHICKEN3 register? Also, why the first flag is set
> unconditionally while the second one only if we don't have a DC
> partition? This is what you want?

It's a masked register as many other MMIO registers on Gen hardware: the
upper 16 bits control which of the lower 16 bits are modified in the
register.

> 
>
> Also, if the "HSW_ROW_CHICKEN3_L3_ATOMIC_DISABLE << 16" is really
> needed, it could be defined as a constant in the first patch of the series.
>
If you think that would be more readable I guess we could define a
REG_MASK() macro and use it wherever we write a masked register.  See
attachment (applies on top of this patch).

> Sam
>
>> + ADVANCE_BATCH();
>> +  }
>> }
>>  }
>> 

From 4a3af3cf92bc45401242a676e0178e408eeafbb8 Mon Sep 17 00:00:00 2001
From: Francisco Jerez 
Date: Thu, 26 Nov 2015 16:42:43 +0200
Subject: [PATCH] i965: Define and use REG_MASK macro to make masked MMIO
 writes slightly more readable.

---
 src/mesa/drivers/dri/i965/brw_defines.h  | 6 ++
 src/mesa/drivers/dri/i965/brw_state_upload.c | 2 +-
 src/mesa/drivers/dri/i965/gen7_l3_state.c| 2 +-
 src/mesa/drivers/dri/i965/intel_reg.h| 2 +-
 4 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_defines.h b/src/mesa/drivers/dri/i965/brw_defines.h
index ade3ede..e08d385 100644
--- a/src/mesa/drivers/dri/i965/brw_defines.h
+++ b/src/mesa/drivers/dri/i965/brw_defines.h
@@ -41,6 +41,12 @@
 #define GET_BITS(data, high, low) ((data & INTEL_MASK((high), (low))) >> (low))
 #define GET_FIELD(word, field) (((word)  & field ## _MASK) >> field ## _SHIFT)
 
+/**
+ * For use with masked MMIO registers where the upper 16 bits control which
+ * of the lower bits are committed to the register.
+ */
+#define REG_MASK(value) ((value) << 16)
+
 #ifndef BRW_DEFINES_H
 #define BRW_DEFINES_H
 
diff --git a/src/mesa/drivers/dri/i965/brw_state_upload.c b/src/mesa/drivers/dri/i965/brw_state_upload.c
index cd1fbee..9ad40d2 100644
--- a/src/mesa/drivers/dri/i965/brw_state_upload.c
+++ b/src/mesa/drivers/dri/i965/brw_state_upload.c
@@ -386,7 +386,7 @@ brw_upload_initial_gpu_state(struct brw_context *brw)
   BEGIN_BATCH(3);
   OUT_BATCH(MI_LOAD_REGISTER_IMM | (3 - 2));
   OUT_BATCH(GEN7_CACHE_MODE_1);
-  OUT_BATCH((GEN9_PARTIAL_RESOLVE_DISABLE_IN_VC << 16) |
+  OUT_BATCH(REG_MASK(GEN9_PARTIAL_RESOLVE_DISABLE_IN_VC) |
 GEN9_PARTIAL_RESOLVE_DISABLE_IN_VC);
   ADVANCE_BATCH();
}
diff --git a/src/mesa/drivers/dri/i965/gen7_l3_state.c b/src/mesa/drivers/dri/i965/gen7_l3_state.c
index 239e5bd..022c01a 100644
--- a/src/mesa/drivers/dri/i965/gen7_l3_state.c
+++ b/src/mesa/drivers/dri/i965/gen7_l3_state

[Mesa-dev] [Bug 93103] llvm symbols leak through, cause trouble with software rendering in llvm-linked software

[bugzilla-daemon]

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

--- Comment #11 from Emil Velikov  ---
(In reply to Jose Fonseca from comment #9)

> $ nm -CD --defined-only /usr/lib/x86_64-linux-gnu/libLLVM-3.6.so.1
> 
> shows lot of them.
> 
I have the very vague memory that older versions of LLVM exported internal
symbols as well. Perhaps this bug is related to that defect ?

> So when
> distro decided to use a shared LLVM for the opengl drivers to save a few
> bytes, they basically gave the finger to everybody who needs to use bleeding
> edge LLVM and OpenGL...
> 
Not much we can do there I'm afraid. Distros have their policies and we have
the config switch for people to go the route they like.

> 
> (In reply to Emil Velikov from comment #3)
> > > In addition to that, we probably also need to use a LD version script to
> > > ensure that LLVM symbols don't pop in the dynamic symbol table.
> > We have those for a while. 
> 
> I'm not sure it helps if the problem is is
> /usr/lib/x86_64-linux-gnu/libLLVM-3.4.so.1  .  The only solution is if the
> system libLLVM-X.X.so an unique symbol version/namespace, or maybe the
> RTLD_LOCAL as you mentioned.
>
Michel mentioned that llvm 3.6 has versioned symbols, although I cannot see any
tag in my Archlinux cmake llvm 3.7 build. I do see a very nasty looking RPATH
though - $ORIGIN/../lib ... ouch.

> > Atm only the autotools build uses them (hint hint
> > scons).
> 
> Sure.  I'll look into it.

Thank you !

-- 
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 3/9] drivers/x11: scons: partially revert b9b40ef9b76

[Jose Fonseca]

On 25/11/15 21:31, Emil Velikov wrote:

From: Emil Velikov 

As glsl_types.{cpp,h} were  moved out of the sconscript (commit
b23a4859f4d "scons: Build nir/glsl_types.cpp once.") remove the dangling
includes.

Cc: Jose Fonseca 
Signed-off-by: Emil Velikov 
---
  src/mesa/drivers/x11/SConscript | 2 --
  1 file changed, 2 deletions(-)

diff --git a/src/mesa/drivers/x11/SConscript b/src/mesa/drivers/x11/SConscript
index cd5cccd..d29f987 100644
--- a/src/mesa/drivers/x11/SConscript
+++ b/src/mesa/drivers/x11/SConscript
@@ -4,8 +4,6 @@ env = env.Clone()

  env.Append(CPPPATH = [
  '#/src',
-'#/src/glsl',
-'#/src/glsl/nir',
  '#/src/mapi',
  '#/src/mesa',
  '#/src/mesa/main',




Looks good.

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

[Mesa-dev] [PATCH 2/2] svga: Don't return value from void function.

[Jose Fonseca]

Addresses MSVC warning C4098: 'svga_destroy_query' : 'void' function
returning a value.
---
 src/gallium/drivers/svga/svga_pipe_query.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/svga/svga_pipe_query.c 
b/src/gallium/drivers/svga/svga_pipe_query.c
index 5416a00..3859050 100644
--- a/src/gallium/drivers/svga/svga_pipe_query.c
+++ b/src/gallium/drivers/svga/svga_pipe_query.c
@@ -754,7 +754,8 @@ svga_destroy_query(struct pipe_context *pipe, struct 
pipe_query *q)
struct svga_query *sq;
 
if (q == NULL) {
-  return destroy_gb_query_obj(svga);
+  destroy_gb_query_obj(svga);
+  return;
}
 
sq = svga_query(q);
-- 
2.5.0

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

[Mesa-dev] [PATCH 1/2] gallium: Make pipe_query_result::batch array length non-zero.

[Jose Fonseca]

Zero length arrays are non standard:

   warning C4200: nonstandard extension used : zero-sized array in struct/union
   Cannot generate copy-ctor or copy-assignment operator when UDT contains a 
zero-sized array

And all code does `N * sizeof query_result->batch[0]`, so it should work
exactly the same.
---
 src/gallium/include/pipe/p_defines.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/gallium/include/pipe/p_defines.h 
b/src/gallium/include/pipe/p_defines.h
index b18eedd..cbf0ba6 100644
--- a/src/gallium/include/pipe/p_defines.h
+++ b/src/gallium/include/pipe/p_defines.h
@@ -822,8 +822,8 @@ union pipe_query_result
/* PIPE_QUERY_PIPELINE_STATISTICS */
struct pipe_query_data_pipeline_statistics pipeline_statistics;
 
-   /* batch queries */
-   union pipe_numeric_type_union batch[0];
+   /* batch queries (variable length) */
+   union pipe_numeric_type_union batch[1];
 };
 
 union pipe_color_union
-- 
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 8/8] mesa: rework the meaning of gl_debug_message::length

[Emil Velikov]

On 26 November 2015 at 05:26, Timothy Arceri
 wrote:
> On Thu, 2015-11-26 at 00:36 +, Emil Velikov wrote:
>> Currently it stores strlen(buf) whenever the user originally provided
>> a
>> negative value for length.
>>
>> Although I've not seen any explicit text in the spec, CTS requires
>> that
>> the very same length (be that negative value or not) is returned back
>> on
>> Pop.
>>
>> So let's push down the length < 0 checks, tweak the meaning of
>> gl_debug_message::length and fix GetDebugMessageLog to add and count
>> the
>> null terminators, as required by the spec.
>>
>> v2: return correct total length in GetDebugMessageLog
>>
>> XXX:
>>  - should we use -1, or strlen on ENOMEM in debug_message_store ?
>>  - split out the GetDebugMessageLog fixes into separate patch ?
>>  - split the "push the length < 0 check further down" into separate
>> patch ?
>>
>> Signed-off-by: Emil Velikov 
>> ---
>>  src/mesa/main/errors.c | 43 
>> ---
>>  1 file changed, 24 insertions(+), 19 deletions(-)
>>
>> diff --git a/src/mesa/main/errors.c b/src/mesa/main/errors.c
>> index 79149a9..78d21cc 100644
>> --- a/src/mesa/main/errors.c
>> +++ b/src/mesa/main/errors.c
>> @@ -76,6 +76,8 @@ struct gl_debug_message
>> enum mesa_debug_type type;
>> GLuint id;
>> enum mesa_debug_severity severity;
>> +   /* length as given by the user - if message was explicitly null
>> terminated,
>> +* length can be negative */
>> GLsizei length;
>> GLcharARB *message;
>>  };
>> @@ -211,14 +213,19 @@ debug_message_store(struct gl_debug_message
>> *msg,
>>  enum mesa_debug_severity severity,
>>  GLsizei len, const char *buf)
>>  {
>> +   GLsizei length = len;
>> +
>> assert(!msg->message && !msg->length);
>>
>> -   msg->message = malloc(len+1);
>> +   if (length < 0)
>> +  length = strlen(buf);
>> +
>> +   msg->message = malloc(length+1);
>> if (msg->message) {
>> -  (void) strncpy(msg->message, buf, (size_t)len);
>> -  msg->message[len] = '\0';
>> +  (void) strncpy(msg->message, buf, (size_t)length);
>> +  msg->message[length] = '\0';
>>
>> -  msg->length = len+1;
>> +  msg->length = len;
>>msg->source = source;
>>msg->type = type;
>>msg->id = id;
>> @@ -229,7 +236,7 @@ debug_message_store(struct gl_debug_message *msg,
>>
>>/* malloc failed! */
>>msg->message = out_of_memory;
>> -  msg->length = strlen(out_of_memory)+1;
>> +  msg->length = -1;
>
> Why change this?
>
Because negative length now means "message is a null terminated
string". This isn't a user provided string so it shouldn't matter. I'd
rather keep things consistent though :-)

>>msg->source = MESA_DEBUG_SOURCE_OTHER;
>>msg->type = MESA_DEBUG_TYPE_ERROR;
>>msg->id = oom_msg_id;
>> @@ -607,7 +614,7 @@ debug_log_message(struct gl_debug_state *debug,
>> GLint nextEmpty;
>> struct gl_debug_message *emptySlot;
>>
>> -   assert(len >= 0 && len < MAX_DEBUG_MESSAGE_LENGTH);
>> +   assert(len < MAX_DEBUG_MESSAGE_LENGTH);
>>
>> if (log->NumMessages == MAX_DEBUG_LOGGED_MESSAGES)
>>return;
>> @@ -1004,8 +1011,6 @@ _mesa_DebugMessageInsert(GLenum source, GLenum
>> type, GLuint id,
>> if (!validate_params(ctx, INSERT, callerstr, source, type,
>> severity))
>>return; /* GL_INVALID_ENUM */
>>
>> -   if (length < 0)
>> -  length = strlen(buf);
>
> This should be in the previous patch.
>
>> if (!validate_length(ctx, callerstr, length, buf))
>>return; /* GL_INVALID_VALUE */
>>
>> @@ -1047,23 +1052,28 @@ _mesa_GetDebugMessageLog(GLuint count,
>> GLsizei logSize, GLenum *sources,
>>
>> for (ret = 0; ret < count; ret++) {
>>const struct gl_debug_message *msg =
>> debug_fetch_message(debug);
>> +  GLsizei len;
>>
>>if (!msg)
>>   break;
>>
>> -  if (logSize < msg->length && messageLog != NULL)
>> +  len = msg->length;
>> +  if (len < 0)
>> + len = strlen(msg->message);
>> +
>> +  if (logSize < len+1 && messageLog != NULL)
>>   break;
>>
>>if (messageLog) {
>> - assert(msg->message[msg->length-1] == '\0');
>> - (void) strncpy(messageLog, msg->message, (size_t)msg
>> ->length);
>> + assert(msg->message[len] == '\0');
>> + (void) strncpy(messageLog, msg->message, (size_t)len+1);
>>
>> - messageLog += msg->length;
>> - logSize -= msg->length;
>> + messageLog += len+1;
>> + logSize -= len+1;
>>}
>>
>>if (lengths)
>> - *lengths++ = msg->length;
>> + *lengths++ = len+1;
>>if (severities)
>>   *severities++ = debug_severity_enums[msg->severity];
>>if (sources)
>> @@ -1173,8 +1183,6 @@ _mesa_PushDebugGroup(GLenum source, GLuint id,
>> GLsizei length,
>>return;
>> }
>>
>> -   if (length < 0)
>> -  length = strlen(message);
>
> This should be in the previo

[Mesa-dev] [Bug 93091] [opencl] segfault when running any opencl programs (like clinfo)

[bugzilla-daemon]

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

--- Comment #10 from Paulo Dias  ---
well FWIW it fixed it for me, no more crashes and clinfo and tests works.
might be hw specific or a different bug.
On Nov 26, 2015 11:02,  wrote:

> *Comment # 9  on
> bug 93091  from Emil
> Velikov  *
>
> (In reply to Samuel Pitoiset from comment #8 
> )> This segfault still 
> happens for me using mesa git, commit
> > ca976e6900dc8ff457ed9dba661d037c616abc59.
> >
> > OpenGL renderer string: Gallium 0.4 on NVE7
> > OpenGL core profile version string: 4.1 (Core Profile) Mesa 11.2.0-devel
> > (git-ca976e6)
> >
> > #0  pipe_loader_create_screen (dev=0x0) at pipe_loader.c:79
>
> Strange... I wonder if we're getting hit by the issue pointed out to Tom -
> namely we should cap the ldevs iteration in platform::platform() to the value
> returned by the second call to pipe_loader_probe. Reason being that second 
> call
> to pipe_loader_probe() may return smaller count (device has gone missing,
> enomem, other).
>
> Alternatively can someone pin-point the commit that causes this (note you 
> might
> need to cherry-pick patch in comment 1 
>  to fixup commit 
> ff9cd8a67ca).
>
> Thanks
>
> --
> You are receiving this mail because:
>
>- You reported the bug.
>
>

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

[Mesa-dev] [Bug 93103] llvm symbols leak through, cause trouble with software rendering in llvm-linked software

[bugzilla-daemon]

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

--- Comment #10 from Tobias Schlüter  ---
Probably no longer relevant per #8, and I don't know how to tell different
libGL.so.1 apart with certainty, but I guess you can do this based on ldd
output, so here goes (DRI appears, Xlib doesn't):
$ ldd /usr/lib/x86_64-linux-gnu/mesa/libGL.so
linux-vdso.so.1 =>  (0x7ffe71b89000)
libglapi.so.0 => /usr/lib/x86_64-linux-gnu/libglapi.so.0
(0x7f118cf53000)
libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x7f118cd41000)
libXdamage.so.1 => /usr/lib/x86_64-linux-gnu/libXdamage.so.1
(0x7f118cb3e000)
libXfixes.so.3 => /usr/lib/x86_64-linux-gnu/libXfixes.so.3
(0x7f118c938000)
libX11-xcb.so.1 => /usr/lib/x86_64-linux-gnu/libX11-xcb.so.1
(0x7f118c736000)
libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x7f118c401000)
libxcb-glx.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-glx.so.0
(0x7f118c1ea000)
libxcb-dri2.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-dri2.so.0
(0x7f118bfe5000)
libxcb-dri3.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-dri3.so.0
(0x7f118bde2000)
libxcb-present.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-present.so.0
(0x7f118bbdf000)
libxcb-sync.so.1 => /usr/lib/x86_64-linux-gnu/libxcb-sync.so.1
(0x7f118b9d9000)
libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x7f118b7ba000)
libxshmfence.so.1 => /usr/lib/x86_64-linux-gnu/libxshmfence.so.1
(0x7f118b5b8000)
libXxf86vm.so.1 => /usr/lib/x86_64-linux-gnu/libXxf86vm.so.1
(0x7f118b3b2000)
libdrm.so.2 => /usr/lib/x86_64-linux-gnu/libdrm.so.2 (0x7f118b1a6000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x7f118af88000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f118ad84000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f118a9bf000)
libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x7f118a7bb000)
libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6
(0x7f118a5b5000)
/lib64/ld-linux-x86-64.so.2 (0x7f118d3e)
$

Concerning #6, from which I learnt a lot, thank you for that, two comments:
1) I wouldn't consider it good practice to redefine LLVM as a "system library"
and then blame problems related to it on users
2) I guess I could read your comment as saying that the bug lies with LLVM as
they (at least up to version 3.6) don't version their symbols correct (though
from a user-experience side there is an issue with libmesa, even if it is
inherited)

I have pointed the ROOT people to this bug report, I hope they can draw their
conclusions from this.  We're currently setting up mesa 11 and the latest
version of ROOT, and I will report back.

ps concerning the choices about who should statically link, I agree with #9
(submitted while I was putting this comment together).

-- 
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 v2 2/8] mesa: do not enable KHR_debug for ES 1.0

[Emil Velikov]

On 26 November 2015 at 04:39, Timothy Arceri
 wrote:
> On Thu, 2015-11-26 at 00:36 +, Emil Velikov wrote:
>> The extension requires (cough implements) GetPointervKHR (alias of
>> GetPointerv) which in itself is available for ES 1.1 enabled mesa.
>>
>> Anyone willing to fish around and implement it for ES 1.0 is more
>> than
>> welcome to revert this commit. Until then lets restrict things.
>>
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93048
>> Signed-off-by: Emil Velikov 
>> ---
>>  src/mapi/glapi/gen/KHR_debug.xml | 20 ++--
>>  src/mesa/main/extensions_table.h |  2 +-
>>  2 files changed, 11 insertions(+), 11 deletions(-)
>>
>> diff --git a/src/mapi/glapi/gen/KHR_debug.xml
>> b/src/mapi/glapi/gen/KHR_debug.xml
>> index 431a788..50daba3 100644
>> --- a/src/mapi/glapi/gen/KHR_debug.xml
>> +++ b/src/mapi/glapi/gen/KHR_debug.xml
>> @@ -146,7 +146,7 @@
>>
>>
>>
>> -  > alias="DebugMessageControl" es1="1.0" es2="2.0">
>> +  > alias="DebugMessageControl" es1="1.1" es2="2.0">
>>  
>>  
>>  
>> @@ -155,7 +155,7 @@
>>  
>>
>>
>> -  > es1="1.0" es2="2.0">
>> +  > es1="1.1" es2="2.0">
>>  
>>  
>>  
>> @@ -164,12 +164,12 @@
>>  
>>
>>
>> -  > alias="DebugMessageCallback" es1="1.0" es2="2.0">
>> +  > alias="DebugMessageCallback" es1="1.1" es2="2.0">
>>  
>>  
>>
>>
>> -  > es1="1.0" es2="2.0">
>> +  > es1="1.1" es2="2.0">
>>  
>>  
>>  
>> @@ -186,23 +186,23 @@
>>  
>>
>>
>> -  > es1="1.0" es2="2.0">
>> +  > es1="1.1" es2="2.0">
>>  
>>  
>>  
>>  
>>
>>
>> -  > es2="2.0"/>
>> +  > es2="2.0"/>
>>
>> -  > es2="2.0">
>> +  > es2="2.0">
>>  
>>  
>>  
>>  
>>
>>
>> -  > es1="1.0" es2="2.0">
>> +  > es1="1.1" es2="2.0">
>>  
>>  
>>  
>> @@ -210,13 +210,13 @@
>>  
>>
>>
>> -  > es1="1.0" es2="2.0">
>> +  > es1="1.1" es2="2.0">
>>  
>>  
>>  
>>
>>
>> -  > es1="1.0" es2="2.0">
>> +  > es1="1.1" es2="2.0">
>>  
>>  
>>  
>> diff --git a/src/mesa/main/extensions_table.h
>> b/src/mesa/main/extensions_table.h
>> index 051d69a..52a4ed6 100644
>> --- a/src/mesa/main/extensions_table.h
>> +++ b/src/mesa/main/extensions_table.h
>> @@ -258,7 +258,7 @@ EXT(INGR_blend_func_separate,
>> EXT_blend_func_separate
>>  EXT(INTEL_performance_query ,
>> INTEL_performance_query, GLL, GLC,  x , ES2, 2013)
>>
>>  EXT(KHR_context_flush_control   , dummy_true
>>  , GLL, GLC,  x , ES2, 2014)
>> -EXT(KHR_debug   , dummy_true
>>  , GLL, GLC, ES1, ES2, 2012)
>> +EXT(KHR_debug   , dummy_true
>>  , GLL, GLC,  11, ES2, 2012)
>
> What is this table used for?
Two things 1) the classic "should we print the extension name in
glGetString(GL_EXTENSIONS)" and more accurate
_mesa_has_$extension_name. Latter is a new addition due to some bugs.

> And why do we use 11 here?
>
> The top of the file defines GLL, GLC, ES1 and ES2 as 0 and x as ~0 why
> isn't this also 0?
>

GLL, GLC... are "enable on any version of $API", while x is "always
disable for $API". Alternatively a number represents the minimum
required version for the said API.

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

[Mesa-dev] [Bug 93103] llvm symbols leak through, cause trouble with software rendering in llvm-linked software

[bugzilla-daemon]

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

--- Comment #9 from Jose Fonseca  ---
(In reply to Emil Velikov from comment #6)
> Check, if ever in doubt about the exposed symbols.
> 
> libGL itself
> $ nm -CD --defined-only /lib/libGL.so | grep -v " gl"
[...]
>
> DRI module, used by libGL (do check all the "*_dri.so" found in /lib)
> $ nm -CD --defined-only /lib/xorg/modules/dri/swrast_dri.so
[...]
> 
> As you can see, nothing from LLVM/Clang is explicitly exported/leaked.


My understanding from Tobias description is that the LLVM symbols from
/usr/lib/x86_64-linux-gnu/libLLVM-3.6.so.1 are clashing with a custom LLVM
build for cling -- https://root.cern.ch/cling-build-instructions

The real question is what symbols libLLVM-3.6.so provides, and 

$ nm -CD --defined-only /usr/lib/x86_64-linux-gnu/libLLVM-3.6.so.1

shows lot of them.


LLVM is used in lots of projects nowadays -- language interpreters, etc.   So
are OpenGL drivers -- they get loaded in all sort of processes.  So when distro
decided to use a shared LLVM for the opengl drivers to save a few bytes, they
basically gave the finger to everybody who needs to use bleeding edge LLVM and
OpenGL...


(In reply to Emil Velikov from comment #3)
> > In addition to that, we probably also need to use a LD version script to
> > ensure that LLVM symbols don't pop in the dynamic symbol table.
> We have those for a while. 

I'm not sure it helps if the problem is is
/usr/lib/x86_64-linux-gnu/libLLVM-3.4.so.1  .  The only solution is if the
system libLLVM-X.X.so an unique symbol version/namespace, or maybe the
RTLD_LOCAL as you mentioned.

> Atm only the autotools build uses them (hint hint
> scons).

Sure.  I'll look into it.

-- 
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 v2 6/8] mesa: accept TYPE_PUSH/POP_GROUP with glDebugMessageInsert

[Emil Velikov]

On 26 November 2015 at 04:55, Timothy Arceri
 wrote:
> On Thu, 2015-11-26 at 00:36 +, Emil Velikov wrote:
>> These new (relative to ARB_debug_output) tokens, have been explicitly
>> separated from the existing ones in the spec text. With the reference
>> to glDebugMessageInsert was dropped.
>>
>> At the same time, further down the spec says:
>>"The value of  must be one of the values from Table 5.4"
>>
>> ... and these two are listed in Table 5.4.
>>
>> The GL 4.3 and GLES 3.2 do not give any hints on the former
>> 'definition', plus CTS requires that the tokens are valid values for
>> glDebugMessageInsert.
>
> I still think this is a spec bug but if it helps pass the tests I guess
> it doesn't do much harm.
>
Yes it is a bit of "why on earth anyone would want to do that" kind of
thing, but it shouldn't hurt anything afaict. GL 4.3 was released some
3 years ago, so I doubt fixing this spec will help much. If apps are
already using it vendors will just add workaround to still allow it.

> Reviewed-by: Timothy Arceri 
>
Thanks
Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v2 1/1] i965: Do not overwrite optimizer dumps

[Juan A. Suarez Romero]

When using INTEL_DEBUG=optimizer, each optimizing step is dump to disk,
in a separate file.

But as fs_visitor::optimize() and vec4_visitor::run() are called more
than once, it ends up overwriting the files already on disk, loosing
then previous optimizer steps.

To avoid this, add a new static variable that tracks the global
iteration across the entire life of the program running.

v2: use atomic_inc() for the static variable (Jason).

Signed-off-by: Juan A. Suarez Romero 
---
 src/mesa/drivers/dri/i965/brw_fs.cpp   | 15 +++
 src/mesa/drivers/dri/i965/brw_vec4.cpp | 13 +
 2 files changed, 20 insertions(+), 8 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp 
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 7904f4d..72ee5cc 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -39,6 +39,7 @@
 #include "brw_program.h"
 #include "brw_dead_control_flow.h"
 #include "glsl/nir/glsl_types.h"
+#include "util/u_atomic.h"
 
 using namespace brw;
 
@@ -4948,6 +4949,9 @@ fs_visitor::calculate_register_pressure()
 void
 fs_visitor::optimize()
 {
+   static int global_iteration_atomic = 0;
+   int global_iteration;
+
/* Start by validating the shader we currently have. */
validate();
 
@@ -4978,8 +4982,9 @@ fs_visitor::optimize()
 \
   if (unlikely(INTEL_DEBUG & DEBUG_OPTIMIZER) && this_progress) {   \
  char filename[64]; \
- snprintf(filename, 64, "%s%d-%s-%02d-%02d-" #pass,  \
-  stage_abbrev, dispatch_width, nir->info.name, iteration, 
pass_num); \
+ snprintf(filename, 64, "%s%d-%s-%02d-%02d-%02d-" #pass,\
+  stage_abbrev, dispatch_width, nir->info.name, \
+  global_iteration, iteration, pass_num);   \
 \
  backend_shader::dump_instructions(filename);   \
   } \
@@ -4990,10 +4995,12 @@ fs_visitor::optimize()
   this_progress;\
})
 
+   global_iteration = p_atomic_inc_return(&global_iteration_atomic);
+
if (unlikely(INTEL_DEBUG & DEBUG_OPTIMIZER)) {
   char filename[64];
-  snprintf(filename, 64, "%s%d-%s-00-start",
-   stage_abbrev, dispatch_width, nir->info.name);
+  snprintf(filename, 64, "%s%d-%s-%02d-00-00-start",
+   stage_abbrev, dispatch_width, nir->info.name, global_iteration);
 
   backend_shader::dump_instructions(filename);
}
diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp 
b/src/mesa/drivers/dri/i965/brw_vec4.cpp
index 9a79d67..dd44b32 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4.cpp
@@ -29,6 +29,7 @@
 #include "brw_vec4_live_variables.h"
 #include "brw_dead_control_flow.h"
 #include "program/prog_parameter.h"
+#include "util/u_atomic.h"
 
 #define MAX_INSTRUCTION (1 << 30)
 
@@ -1779,6 +1780,9 @@ vec4_visitor::convert_to_hw_regs()
 bool
 vec4_visitor::run()
 {
+   static int global_iteration_atomic = 0;
+   int global_iteration;
+
if (shader_time_index >= 0)
   emit_shader_time_begin();
 
@@ -1812,8 +1816,8 @@ vec4_visitor::run()
\
   if (unlikely(INTEL_DEBUG & DEBUG_OPTIMIZER) && this_progress) {  \
  char filename[64];\
- snprintf(filename, 64, "%s-%s-%02d-%02d-" #pass,  \
-  stage_abbrev, nir->info.name, iteration, pass_num);  \
+ snprintf(filename, 64, "%s-%s-%02d-%02d-%02d-" #pass, \
+  stage_abbrev, nir->info.name, global_iteration, iteration, 
pass_num); \
\
  backend_shader::dump_instructions(filename);  \
   }\
@@ -1822,11 +1826,12 @@ vec4_visitor::run()
   this_progress;   \
})
 
+   global_iteration = p_atomic_inc_return(&global_iteration_atomic);
 
if (unlikely(INTEL_DEBUG & DEBUG_OPTIMIZER)) {
   char filename[64];
-  snprintf(filename, 64, "%s-%s-00-start",
-   stage_abbrev, nir->info.name);
+  snprintf(filename, 64, "%s-%s-%02d-00-00-start",
+   stage_abbrev, nir->info.name, global_iteration);
 
   backend_shader::dump_instructions(filename);
}
-- 
2.5.0

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

[Mesa-dev] [Bug 92945] [llvmpipe] [softpipe] piglit fs-ldexp-dvec4 regression

[bugzilla-daemon]

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

--- Comment #1 from Ilia Mirkin  ---
Reproduced on nvc0. Note that this issue appears to have little to do with
doubles. The shader address an output, color, as color[i] = 1 (i=loop index).
However it appears that the color output gets removed for some reason, or is
otherwise not look-up-able.

-- 
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 93114] No water rendered in CoR

[bugzilla-daemon]

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

--- Comment #5 from theduk...@gmail.com ---
Created attachment 120142
  --> https://bugs.freedesktop.org/attachment.cgi?id=120142&action=edit
water missing in Linux while using Mesa but visible in Win7

I can replicate this problem on both my pc:

1) Athlon II x4 640, AMD HD 7750

Distributor ID:LinuxMint
Description:Linux Mint 17.2 Rafaela
Release:17.2
Codename:rafaela

Linux 3.16.0-53-generic #72~14.04.1-Ubuntu SMP Fri Nov 6 18:17:23 UTC 2015
x86_64 x86_64 x86_64 GNU/Linux

OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD CAPE VERDE (DRM 2.39.0, LLVM 3.6.0)
OpenGL core profile version string: 3.3 (Core Profile) Mesa 11.0.4
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL version string: 3.0 Mesa 11.0.4
OpenGL shading language version string: 1.30
OpenGL context flags: (none)

The problem is there with Mesa 10.1.3 and Mesa 11.0.4 . Mesa 11.0.4 is from
xorg edgers ppa, Mesa 10.1.3 is the one that comes with the distro (I need at
least 10.6 to be able to run Dota 2).

You can see how it supposed to actually look from the image took in Win 7.

2) Athlon 64 x2 4000+, ATI HD 4350

Distributor ID:LinuxMint
Description:Linux Mint 17.1 Rebecca
Release:17.1
Codename:rebecca

Linux 4.2.0-18-generic #22~14.04.1-Ubuntu SMP Fri Nov 6 22:20:11 UTC 2015
x86_64 x86_64 x86_64 GNU/Linux


OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD RV710 (DRM 2.43.0, LLVM 3.6.0)
OpenGL core profile version string: 3.3 (Core Profile) Mesa 11.0.4
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 11.0.4
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:

The situation is even worst with HD 4350, the water is not rendered, also there
is the nude model bug.

In this case the problem happens in exactly same way (no water, nude model)
with kernel 3.13.0-37 and kernel 4.2.0-18.

-- 
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 93103] llvm symbols leak through, cause trouble with software rendering in llvm-linked software

[bugzilla-daemon]

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

--- Comment #8 from Emil Velikov  ---
(In reply to Jose Fonseca from comment #7)
> I wonder if Tobias is using XLIB-based libGL.so.1, as opposed to the DRI
> based libGL.so.1.

I fixed that one got around mesa 10.3 - see
src/gallium/targets/libgl-xlib/libgl-xlib.sym. I've been a good boy cleaning
there up :-P

-- 
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 93103] llvm symbols leak through, cause trouble with software rendering in llvm-linked software

[bugzilla-daemon]

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

--- Comment #7 from Jose Fonseca  ---
I wonder if Tobias is using XLIB-based libGL.so.1, as opposed to the DRI based
libGL.so.1.

-- 
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 93112] GLX: could not load software renderer

[bugzilla-daemon]

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

Emil Velikov  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Emil Velikov  ---
Albert, using please can be a world of difference :-P

Poma, upstream commit 59cfb21d4670559d49a721df766073d9d288b51a should already
fix this. Please reopen if that's not the case.

-- 
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 v2 10/11] gallium: do not wrap header inclusion in

[Jose Fonseca]

On 25/11/15 20:43, Emil Velikov wrote:

From: Emil Velikov 

Add one missing extern C guard within include/pipe/p_video_enums.h, and
remove the wrapping throughout gallium.

On Haiku one could even use the gallium debug_printf() although
that's another topic.

v2: Leave dbghelp.h as is (Jose)

Cc: Jose Fonseca 
Cc: Brian Paul 
Cc: Alexander von Gluck IV 
Signed-off-by: Emil Velikov 
---
  src/gallium/auxiliary/tgsi/tgsi_sanity.h | 4 ++--
  src/gallium/auxiliary/tgsi/tgsi_text.h   | 4 ++--
  src/gallium/auxiliary/util/u_debug.h | 8 +---
  src/gallium/auxiliary/util/u_draw_quad.h | 3 +--
  src/gallium/auxiliary/util/u_helpers.h   | 4 ++--
  src/gallium/auxiliary/util/u_video.h | 8 
  src/gallium/include/pipe/p_format.h  | 4 ++--
  src/gallium/include/pipe/p_video_codec.h | 4 ++--
  src/gallium/include/pipe/p_video_enums.h | 8 
  9 files changed, 28 insertions(+), 19 deletions(-)

diff --git a/src/gallium/auxiliary/tgsi/tgsi_sanity.h 
b/src/gallium/auxiliary/tgsi/tgsi_sanity.h
index 1ff7874..b78d1ab 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_sanity.h
+++ b/src/gallium/auxiliary/tgsi/tgsi_sanity.h
@@ -28,12 +28,12 @@
  #ifndef TGSI_SANITY_H
  #define TGSI_SANITY_H

+#include "pipe/p_compiler.h"
+
  #if defined __cplusplus
  extern "C" {
  #endif

-#include "pipe/p_compiler.h"
-
  struct tgsi_token;

  /* Check the given token stream for errors and common mistakes.
diff --git a/src/gallium/auxiliary/tgsi/tgsi_text.h 
b/src/gallium/auxiliary/tgsi/tgsi_text.h
index 6a306e6..a345657 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_text.h
+++ b/src/gallium/auxiliary/tgsi/tgsi_text.h
@@ -28,12 +28,12 @@
  #ifndef TGSI_TEXT_H
  #define TGSI_TEXT_H

+#include "pipe/p_compiler.h"
+
  #if defined __cplusplus
  extern "C" {
  #endif

-#include "pipe/p_compiler.h"
-
  struct tgsi_token;

  boolean
diff --git a/src/gallium/auxiliary/util/u_debug.h 
b/src/gallium/auxiliary/util/u_debug.h
index aaf223c..9319425 100644
--- a/src/gallium/auxiliary/util/u_debug.h
+++ b/src/gallium/auxiliary/util/u_debug.h
@@ -39,6 +39,11 @@
  #define U_DEBUG_H_


+#if defined(PIPE_OS_HAIKU)
+/* Haiku provides debug_printf in libroot with OS.h */
+#include 
+#endif
+
  #include "os/os_misc.h"

  #include "pipe/p_format.h"
@@ -94,9 +99,6 @@ debug_printf(const char *format, ...)
 (void) format; /* silence warning */
  #endif
  }
-#else /* is Haiku */
-/* Haiku provides debug_printf in libroot with OS.h */
-#include 
  #endif


diff --git a/src/gallium/auxiliary/util/u_draw_quad.h 
b/src/gallium/auxiliary/util/u_draw_quad.h
index b298ef2..6553d5d 100644
--- a/src/gallium/auxiliary/util/u_draw_quad.h
+++ b/src/gallium/auxiliary/util/u_draw_quad.h
@@ -32,6 +32,7 @@
  #include "pipe/p_compiler.h"
  #include "pipe/p_context.h"

+#include "util/u_draw.h"

  #ifdef __cplusplus
  extern "C" {
@@ -40,8 +41,6 @@ extern "C" {
  struct pipe_resource;
  struct cso_context;

-#include "util/u_draw.h"
-
  extern void
  util_draw_vertex_buffer(struct pipe_context *pipe, struct cso_context *cso,
  struct pipe_resource *vbuf, uint vbuf_slot,
diff --git a/src/gallium/auxiliary/util/u_helpers.h 
b/src/gallium/auxiliary/util/u_helpers.h
index f25f280..a9a53e4 100644
--- a/src/gallium/auxiliary/util/u_helpers.h
+++ b/src/gallium/auxiliary/util/u_helpers.h
@@ -28,12 +28,12 @@
  #ifndef U_HELPERS_H
  #define U_HELPERS_H

+#include "pipe/p_state.h"
+
  #ifdef __cplusplus
  extern "C" {
  #endif

-#include "pipe/p_state.h"
-
  void util_set_vertex_buffers_mask(struct pipe_vertex_buffer *dst,
uint32_t *enabled_buffers,
const struct pipe_vertex_buffer *src,
diff --git a/src/gallium/auxiliary/util/u_video.h 
b/src/gallium/auxiliary/util/u_video.h
index ddc0021..9196afc 100644
--- a/src/gallium/auxiliary/util/u_video.h
+++ b/src/gallium/auxiliary/util/u_video.h
@@ -28,10 +28,6 @@
  #ifndef U_VIDEO_H
  #define U_VIDEO_H

-#ifdef __cplusplus
-extern "C" {
-#endif
-
  #include "pipe/p_defines.h"
  #include "pipe/p_video_enums.h"

@@ -40,6 +36,10 @@ extern "C" {
  #include "util/u_debug.h"
  #include "util/u_math.h"

+#ifdef __cplusplus
+extern "C" {
+#endif
+
  static inline enum pipe_video_format
  u_reduce_video_profile(enum pipe_video_profile profile)
  {
diff --git a/src/gallium/include/pipe/p_format.h 
b/src/gallium/include/pipe/p_format.h
index d9c9f9b..820002c 100644
--- a/src/gallium/include/pipe/p_format.h
+++ b/src/gallium/include/pipe/p_format.h
@@ -29,12 +29,12 @@
  #ifndef PIPE_FORMAT_H
  #define PIPE_FORMAT_H

+#include "p_config.h"
+
  #ifdef __cplusplus
  extern "C" {
  #endif

-#include "p_config.h"
-
  /**
   * Formats for textures, surfaces and vertex data
   */
diff --git a/src/gallium/include/pipe/p_video_codec.h 
b/src/gallium/include/pipe/p_video_codec.h
index 196d00b..b5575ab 100644
--- a/src/gallium/include/pipe/p_video_codec.h
+++ b/src/gallium/include/pipe/p_video_codec.h
@@ -28,12 +28,12 @@
  #ifndef PIPE_VIDEO_CONTEXT_H
  

[Mesa-dev] [Bug 93103] llvm symbols leak through, cause trouble with software rendering in llvm-linked software

[bugzilla-daemon]

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

--- Comment #6 from Emil Velikov  ---
(In reply to Tobias Schlüter from comment #5)
> Thank you for the quick response!  I'll take the comments to mean that this
> shouldn't happen with very recent versions of libmesa and llvm.  It does
> happen with fairly recent versions though.
> 
A "global" (affecting all drivers) version script has been added in mesa circa
10.2.

> We verified on a colleague's system that the same error appears on Ubuntu
> 15.05 with libmesa 10.5.9 and libllvm 3.6, (there are some differences in
> the backtrace because we used a slightly simpler way of triggering the bug
> as documented in the ROOT bug report I was linking to).  I would be
> surprised if Ubuntu uses scons for the build, but I don't know.

Pretty much every Linux distributions uses the autotools.

Check, if ever in doubt about the exposed symbols.

libGL itself
$ nm -CD --defined-only /lib/libGL.so | grep -v " gl"
002969c8 b __bss_start
002969c8 d _edata
00297480 b _end
00074c54 T _fini
0004e9d0 T _glapi_create_table_from_handle
00017338 T _init


DRI module, used by libGL (do check all the "*_dri.so" found in /lib)
$ nm -CD --defined-only /lib/xorg/modules/dri/swrast_dri.so
00642e60 T amdgpu_winsys_create
00a62480 B __driDriverExtensions
00073510 T __driDriverGetExtensions_kms_swrast
000735d0 T __driDriverGetExtensions_nouveau
000735f0 T __driDriverGetExtensions_r300
00073610 T __driDriverGetExtensions_r600
00073630 T __driDriverGetExtensions_radeonsi
00073440 T __driDriverGetExtensions_swrast
00073650 T __driDriverGetExtensions_vmwgfx
003fa060 T nouveau_drm_screen_create
0062c9b0 T radeon_drm_winsys_create

As you can see, nothing from LLVM/Clang is explicitly exported/leaked.

> 
> I don't agree with Emil that it is a problem on the ROOT side (even though
> the installed a workaround): one should be able to use libmesa without being
> afraid that symbols leak through that are not part of libmesa's public
> interface.

First and foremost I would encourage you to try with statically linked LLVM as
Jose suggested.

On the actual issue and who's "doing things wrong" it's a combination of bugs
and suboptimal decisions:

 1 To avoid pollution of (conflicts in) global namespace, people must make sure
that they hide their symbols - as done with the ROOT report. Imho this is a
must fix.

 2 Mesa should not dlopen its module with RTLD_GLOBAL. This in itself may
pollute the global namespace (haven't checked), despite that we've hidden the
exported symbols.

 3 Using private libraries conflicting(incompatible) with the system ones is a
very bad idea. If needed one can 1) static link the private ones in their
application or 2) do LD_PRELOAD/LD_LIBRARY_PATH/RPATH magic to ensure the
correct libraries are loaded.

Fixing this on the client side is trivial (both 1 and 3.1). I'm afraid that
fixing the one in mesa is a lot more convoluted than the patch in comment 2 -
we tried and quickly had to revert it :-(

Not saying that mesa is perfect - on the contrary we should drop the
RTLD_GLOBAL hack. Then again others could do their fair share in keeping things
sane.

-- 
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 93112] GLX: could not load software renderer

[bugzilla-daemon]

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

Albert Freeman  changed:

   What|Removed |Added

Version|5.0.2   |git

-- 
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 93112] GLX: could not load software renderer

[bugzilla-daemon]

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

Albert Freeman  changed:

   What|Removed |Added

Version|git |5.0.2

--- Comment #1 from Albert Freeman  ---
git bisect

-- 
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 v3 11/42] i965: Implement L3 state atom.

[Francisco Jerez]

Matt Turner  writes:

> On Wed, Nov 25, 2015 at 6:26 AM, Francisco Jerez  
> wrote:
>> The L3 state atom calculates the target L3 partition weights when the
>> program bound to some shader stage is modified, and in case they are
>> far enough from the current partitioning it makes sure that the L3
>> state is re-emitted.
>>
>> v3: Fix for inconsistent units the context URB size is expressed in.
>> Clamp URB size to 1008 KB on SKL due to FF hardware limitation.
>> ---
>>  src/mesa/drivers/dri/i965/brw_context.h   |  6 +++
>>  src/mesa/drivers/dri/i965/brw_state.h |  1 +
>>  src/mesa/drivers/dri/i965/gen7_l3_state.c | 81 
>> +++
>>  3 files changed, 88 insertions(+)
>>
>> diff --git a/src/mesa/drivers/dri/i965/brw_context.h 
>> b/src/mesa/drivers/dri/i965/brw_context.h
>> index 9983454..b4f8de6 100644
>> --- a/src/mesa/drivers/dri/i965/brw_context.h
>> +++ b/src/mesa/drivers/dri/i965/brw_context.h
>> @@ -678,6 +678,8 @@ enum brw_predicate_state {
>>
>>  struct shader_times;
>>
>> +struct brw_l3_config;
>> +
>>  /**
>>   * brw_context is derived from gl_context.
>>   */
>> @@ -1220,6 +1222,10 @@ struct brw_context
>> int basevertex;
>>
>> struct {
>> +  const struct brw_l3_config *config;
>> +   } l3;
>> +
>> +   struct {
>>drm_intel_bo *bo;
>>const char **names;
>>int *ids;
>> diff --git a/src/mesa/drivers/dri/i965/brw_state.h 
>> b/src/mesa/drivers/dri/i965/brw_state.h
>> index 94734ba..49f301a 100644
>> --- a/src/mesa/drivers/dri/i965/brw_state.h
>> +++ b/src/mesa/drivers/dri/i965/brw_state.h
>> @@ -129,6 +129,7 @@ extern const struct brw_tracked_state gen7_depthbuffer;
>>  extern const struct brw_tracked_state gen7_clip_state;
>>  extern const struct brw_tracked_state gen7_disable_stages;
>>  extern const struct brw_tracked_state gen7_gs_state;
>> +extern const struct brw_tracked_state gen7_l3_state;
>>  extern const struct brw_tracked_state gen7_ps_state;
>>  extern const struct brw_tracked_state gen7_push_constant_space;
>>  extern const struct brw_tracked_state gen7_sbe_state;
>> diff --git a/src/mesa/drivers/dri/i965/gen7_l3_state.c 
>> b/src/mesa/drivers/dri/i965/gen7_l3_state.c
>> index 70a61ae..4c314f5 100644
>> --- a/src/mesa/drivers/dri/i965/gen7_l3_state.c
>> +++ b/src/mesa/drivers/dri/i965/gen7_l3_state.c
>> @@ -418,3 +418,84 @@ setup_l3_config(struct brw_context *brw, const struct 
>> brw_l3_config *cfg)
>>}
>> }
>>  }
>> +
>> +/**
>> + * Return the unit brw_context::urb::size is expressed in, in KB.  \sa
>> + * brw_device_info::urb::size.
>> + */
>> +static unsigned
>> +get_urb_size_scale(const struct brw_device_info *devinfo)
>> +{
>> +   return (devinfo->gen >= 8 ? devinfo->num_slices : 1);
>> +}
>> +
>> +/**
>> + * Update the URB size in the context state for the specified L3
>> + * configuration.
>> + */
>> +static void
>> +update_urb_size(struct brw_context *brw, const struct brw_l3_config *cfg)
>> +{
>> +   const struct brw_device_info *devinfo = brw->intelScreen->devinfo;
>> +   /* From the SKL "L3 Allocation and Programming" documentation:
>> +*
>> +* "URB is limited to 1008KB due to programming restrictions.  This is 
>> not
>> +* a restriction of the L3 implementation, but of the FF and other 
>> clients.
>> +* Therefore, in a GT4 implementation it is possible for the programmed
>> +* allocation of the L3 data array to provide 3*384KB=1152KB for URB, but
>> +* only 1008KB of this will be used."
>> +*/
>> +   const unsigned max = (devinfo->gen == 9 ? 1008 : ~0);
>> +   const unsigned sz =
>> +  MIN2(max, cfg->n[L3P_URB] * get_l3_way_size(devinfo)) /
>> +  get_urb_size_scale(devinfo);
>> +
>> +   if (brw->urb.size != sz) {
>> +  brw->urb.size = sz;
>> +  brw->ctx.NewDriverState |= BRW_NEW_URB_SIZE;
>> +   }
>> +}
>> +
>> +static void
>> +emit_l3_state(struct brw_context *brw)
>> +{
>> +   const struct brw_l3_weights w = get_pipeline_state_l3_weights(brw);
>> +   const float dw = diff_l3_weights(w, 
>> get_config_l3_weights(brw->l3.config));
>> +   /* The distance between any two compatible weight vectors cannot exceed 
>> two
>> +* due to the triangle inequality.
>> +*/
>> +   const float large_dw_threshold = 2.0;
>> +   /* Somewhat arbitrary, simply makes sure that there will be no repeated
>> +* transitions to the same L3 configuration, could probably do better 
>> here.
>> +*/
>> +   const float small_dw_threshold = 0.5;
>> +   /* If we're emitting a new batch the caches should already be clean and 
>> the
>> +* transition should be relatively cheap, so it shouldn't hurt much to 
>> use
>> +* the smaller threshold.  Otherwise use the larger threshold so that we
>> +* only reprogram the L3 mid-batch if the most recently programmed
>> +* configuration is incompatible with the current pipeline state.
>> +*/
>> +   const float dw_threshold = (brw->ctx.NewDriverState & BRW_NEW_BATCH ?
>> +   small_

[Mesa-dev] [Bug 93091] [opencl] segfault when running any opencl programs (like clinfo)

[bugzilla-daemon]

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

--- Comment #9 from Emil Velikov  ---
(In reply to Samuel Pitoiset from comment #8)
> This segfault still happens for me using mesa git, commit
> ca976e6900dc8ff457ed9dba661d037c616abc59.
> 
> OpenGL renderer string: Gallium 0.4 on NVE7
> OpenGL core profile version string: 4.1 (Core Profile) Mesa 11.2.0-devel
> (git-ca976e6)
> 
> #0  pipe_loader_create_screen (dev=0x0) at pipe_loader.c:79

Strange... I wonder if we're getting hit by the issue pointed out to Tom -
namely we should cap the ldevs iteration in platform::platform() to the value
returned by the second call to pipe_loader_probe. Reason being that second call
to pipe_loader_probe() may return smaller count (device has gone missing,
enomem, other).

Alternatively can someone pin-point the commit that causes this (note you might
need to cherry-pick patch in comment 1 to fixup commit ff9cd8a67ca).

Thanks

-- 
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] glsl: don't generate extra errors in ValidateProgramPipeline

[Tapani Pälli]

Reviewed-by: Tapani Pälli 

comment below;

On 11/26/2015 01:01 PM, Timothy Arceri wrote:

On Thu, 2015-11-26 at 21:50 +1100, Timothy Arceri wrote:

 From Section 11.1.3.11 (Validation) of the GLES 3.1 spec:

"An INVALID_OPERATION error is generated by any command that trans
-
fers vertices to the GL or launches compute work if the current
set
of active program objects cannot be executed, for reasons
including:"

It then goes on to list the rules we validate in the
_mesa_validate_program_pipeline() function.

For ValidateProgramPipeline the only meantion of generating an error
is:


mention



"An INVALID_OPERATION error is generated if pipeline is not a name
re-
turned from a previous call to GenProgramPipelines or if such a
name has
since been deleted by DeleteProgramPipelines,"

Which we handle separately.

This fixes:
ES31-CTS.sepshaderobjs.PipelineApi

No regressions on the eEQP 3.1 tests.

Cc: Gregory Hainaut 
Cc: Tapani Pälli 
---
  src/mesa/main/pipelineobj.c | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/mesa/main/pipelineobj.c
b/src/mesa/main/pipelineobj.c
index 0439129..285fc2f 100644
--- a/src/mesa/main/pipelineobj.c
+++ b/src/mesa/main/pipelineobj.c
@@ -928,8 +928,7 @@ _mesa_ValidateProgramPipeline(GLuint pipeline)
return;
 }

-   _mesa_validate_program_pipeline(ctx, pipe,
-   (ctx->_Shader->Name == pipe
->Name));


I'll also add and extra comment here:

/* We pass false for IsBound because we don't want a validation
  * failure to trigger an error.
  */


Maybe it would be good to state something like "ValidateProgramPipeline 
should not throw errors when pipeline validation fails but only update 
validation status".


It's bad that spec does not state this explicitly, this is quite clear 
difference in draw-time vs. ValidateProgramPipeline validation.



+   _mesa_validate_program_pipeline(ctx, pipe, false);

 /* Validate inputs against outputs, this cannot be done during
linking
  * since programs have been linked separately from each other.

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

Re: [Mesa-dev] [PATCH 2/5] i965/gen8+: Don't upload the MCS buffer for single-sampled textures

[Pohjolainen, Topi]

On Thu, Nov 26, 2015 at 11:39:20AM +0100, Neil Roberts wrote:
> > On Thu, Nov 26, 2015 at 11:18:34AM +0200, Pohjolainen, Topi wrote:
> >> On Wed, Nov 25, 2015 at 11:01:18AM -0800, Ben Widawsky wrote:
> >> > On Wed, Nov 25, 2015 at 06:36:36PM +0100, Neil Roberts wrote:
> >> > > For single-sampled textures the MCS buffer is only used to implement
> >> > > fast clears. However the surface always needs to be resolved before
> >> > > being used as a texture anyway so the the MCS buffer doesn't actually
> >> > > achieve anything. This is important for Gen9 because in that case SRGB
> >> > 
> >> > I admit a good deal of ignorance, but why do we have to do a resolve 
> >> > before we
> >> > sample from it? I thought the whole point of the MCS was that we can 
> >> > sample from
> >> > it without a resolve.
> >> 
> >> This is my understanding also, I can't see much benefit from the fast clear
> >> if it would need to be anyway resolved before reading it using GPU (reading
> >> using CPU is then another story of course).
> >
> > I know we have this piece of text in bspec:
> >
> > "If the MCS is enabled on a non-multisampled render target, the render
> > target must be resolved before being used for other purposes (display,
> > texture, CPU lock)."
> >
> > But on the other hand the fact that surface state supports definition of 
> > fast
> > cleared MCS buffer even for sampler engine suggest that "texture" in that
> > sentence refers to something else than sampling. Not to mention that we
> > already sample fast cleared color buffers with current Mesa driver and seem
> > to have no problems with it.
> 
> The resolve needs to be done for single-sampled render targets but for
> multisample targets we can safely sample from the MCS buffer. The MCS
> (or CCS or whatever it should be called in this case) is still useful
> even if we have to resolve because it saves memory bandwidth during
> rendering. Eg, the initial clear writes less data because it only writes
> to the smaller MCS buffer and not the larger color buffer. Any blending
> operations during rendering can also read from the CCS instead of the
> color buffer. I guess the assumption is that the bandwidth savings
> during rendering outweigh the extra cost added by having to resolve it.
> 
> To be clear, this patch doesn't add the resolve step needed before
> texturing, nor does anything in the series. The resolve step is already
> done for all gens in intel_update_state. Look at the bit with the
> comment ???Resolve depth buffer and render cache of each enabled texture???.
> It calls intel_miptree_resolve_color which resolves the CCS buffer for
> each singled-sampled surface that is going to be used as a texture. The
> only change this patch makes it to not not even set the aux buffer in
> the texture surface state.

Right you are, my mistake, Mesa already does resolve them before sampling.
There is then a difference for me to handle when I'm implementing resolves
for the lossless compression - sampling engine understands aux buffers in that
case and therefore the resolve-logic for fast clears is too strict for it as
such.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 93103] llvm symbols leak through, cause trouble with software rendering in llvm-linked software

[bugzilla-daemon]

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

--- Comment #5 from Tobias Schlüter  ---
Thank you for the quick response!  I'll take the comments to mean that this
shouldn't happen with very recent versions of libmesa and llvm.  It does happen
with fairly recent versions though.

We verified on a colleague's system that the same error appears on Ubuntu 15.05
with libmesa 10.5.9 and libllvm 3.6, (there are some differences in the
backtrace because we used a slightly simpler way of triggering the bug as
documented in the ROOT bug report I was linking to).  I would be surprised if
Ubuntu uses scons for the build, but I don't know.  Backtrace:
===
#5  0x7f5c3a87de31 in llvm::cl::AddLiteralOption(llvm::cl::Option&, char
const*) () from
/home/ritter/belle2/externals/development/Linux_x86_64/opt/root/lib/libCling.so
#6  0x7f5c2d944e3a in
llvm::PassRegistry::enumerateWith(llvm::PassRegistrationListener*) () from
/usr/lib/x86_64-linux-gnu/libLLVM-3.6.so.1
#7  0x7f5c2d6e86a8 in ?? () from /usr/lib/x86_64-linux-gnu/libLLVM-3.6.so.1
#8  0x7f5c3d4585ba in ?? () from /lib64/ld-linux-x86-64.so.2
#9  0x7f5c3d4586cb in ?? () from /lib64/ld-linux-x86-64.so.2
#10 0x7f5c3d45d587 in ?? () from /lib64/ld-linux-x86-64.so.2
#11 0x7f5c3d458464 in ?? () from /lib64/ld-linux-x86-64.so.2
#12 0x7f5c3d45c9a3 in ?? () from /lib64/ld-linux-x86-64.so.2
#13 0x7f5c3bea5fc9 in ?? () from /lib/x86_64-linux-gnu/libdl.so.2
#14 0x7f5c3d458464 in ?? () from /lib64/ld-linux-x86-64.so.2
#15 0x7f5c3bea662d in ?? () from /lib/x86_64-linux-gnu/libdl.so.2
#16 0x7f5c3bea6061 in dlopen () from /lib/x86_64-linux-gnu/libdl.so.2
#17 0x7f5c3938c47f in cling::DynamicLibraryManager::loadLibrary(std::string
const&, bool) () from
/home/ritter/belle2/externals/development/Linux_x86_64/opt/root/lib/libCling.so
...


I don't agree with Emil that it is a problem on the ROOT side (even though the
installed a workaround): one should be able to use libmesa without being afraid
that symbols leak through that are not part of libmesa's public interface.

-- 
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/1] i965: Do not overwrite optimizer dumps

[Juan A. Suarez Romero]

On Wed, 2015-11-25 at 11:05 -0800, Jason Ekstrand wrote:
> Right.  I didn't pay that much attention to the exact implementation.
> But we could do something like.
> 
> atomic int global_iteration_atomic = 0;
> 
> const int global_iteration = atomic_inc(global_iteration_atomic);
> 
> // use global_iteration everywhere
> 
> That wouldn't have the threading issues.  (Note, the above is pseudo-
> code)

I'll go with this solution, and it is more similar to the one I had in
mind.

Thanks.

J.A.

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

Re: [Mesa-dev] [PATCH 3/3] i965/gen9+: Switch thread scratch space to non-coherent stateless access.

[Francisco Jerez]

Kristian Høgsberg  writes:

> On Wed, Nov 25, 2015 at 11:37 AM, Francisco Jerez  
> wrote:
>> The thread scratch space is thread-local so using the full IA-coherent
>> stateless surface index (255 since Gen8) is unnecessary and
>> potentially expensive.  On Gen8 and early steppings of Gen9 this is
>> not a functional change because the kernel already sets bit 4 of
>> HDC_CHICKEN0 which overrides all HDC memory access to be non-coherent
>> in order to workaround a hardware bug.
>>
>> This happens to fix a full system hang when running any spilling code
>> on a pre-production SKL GT4e machine I have on my desk (forcing all
>> HDC access to non-coherent from the kernel up to stepping F0 might be
>> a good idea though regardless of this patch), and improves performance
>> of the OglPSBump2 SynMark benchmark run with INTEL_DEBUG=spill_fs by
>> 33% (11 runs, 5% significance) on a production SKL GT2 (on which HDC
>> IA-coherency is apparently functional so it wouldn't make sense to
>> disable globally).
>
> Very nice, all looks good to me. All three patches:
>
> Reviewed-by: Kristian Høgsberg  
>
Thanks!

>> ---
>>  src/mesa/drivers/dri/i965/brw_eu.h   |  2 ++
>>  src/mesa/drivers/dri/i965/brw_eu_emit.c  | 17 +++--
>>  src/mesa/drivers/dri/i965/brw_vec4_generator.cpp |  4 ++--
>>  3 files changed, 19 insertions(+), 4 deletions(-)
>>
>> diff --git a/src/mesa/drivers/dri/i965/brw_eu.h 
>> b/src/mesa/drivers/dri/i965/brw_eu.h
>> index 829e393..62891c7 100644
>> --- a/src/mesa/drivers/dri/i965/brw_eu.h
>> +++ b/src/mesa/drivers/dri/i965/brw_eu.h
>> @@ -317,6 +317,8 @@ void brw_oword_block_read(struct brw_codegen *p,
>>   uint32_t offset,
>>   uint32_t bind_table_index);
>>
>> +unsigned brw_scratch_surface_idx(const struct brw_codegen *p);
>> +
>>  void brw_oword_block_read_scratch(struct brw_codegen *p,
>>   struct brw_reg dest,
>>   struct brw_reg mrf,
>> diff --git a/src/mesa/drivers/dri/i965/brw_eu_emit.c 
>> b/src/mesa/drivers/dri/i965/brw_eu_emit.c
>> index da1ddfd..bb6f5dc 100644
>> --- a/src/mesa/drivers/dri/i965/brw_eu_emit.c
>> +++ b/src/mesa/drivers/dri/i965/brw_eu_emit.c
>> @@ -1997,6 +1997,19 @@ void gen6_math(struct brw_codegen *p,
>> brw_set_src1(p, insn, src1);
>>  }
>>
>> +/**
>> + * Return the right surface index to access the thread scratch space using
>> + * stateless dataport messages.
>> + */
>> +unsigned
>> +brw_scratch_surface_idx(const struct brw_codegen *p)
>> +{
>> +   /* The scratch space is thread-local so IA coherency is unnecessary. */
>> +   if (p->devinfo->gen >= 8)
>> +  return GEN8_BTI_STATELESS_NON_COHERENT;
>> +   else
>> +  return BRW_BTI_STATELESS;
>> +}
>>
>>  /**
>>   * Write a block of OWORDs (half a GRF each) from the scratch buffer,
>> @@ -2097,7 +2110,7 @@ void brw_oword_block_write_scratch(struct brw_codegen 
>> *p,
>>
>>brw_set_dp_write_message(p,
>>insn,
>> -  255, /* binding table index (255=stateless) */
>> +   brw_scratch_surface_idx(p),
>>msg_control,
>>msg_type,
>>mlen,
>> @@ -2183,7 +2196,7 @@ brw_oword_block_read_scratch(struct brw_codegen *p,
>>
>>brw_set_dp_read_message(p,
>>   insn,
>> - 255, /* binding table index (255=stateless) */
>> +  brw_scratch_surface_idx(p),
>>   msg_control,
>>   BRW_DATAPORT_READ_MESSAGE_OWORD_BLOCK_READ, /* 
>> msg_type */
>>   BRW_DATAPORT_READ_TARGET_RENDER_CACHE,
>> diff --git a/src/mesa/drivers/dri/i965/brw_vec4_generator.cpp 
>> b/src/mesa/drivers/dri/i965/brw_vec4_generator.cpp
>> index 20107ac..65b4358 100644
>> --- a/src/mesa/drivers/dri/i965/brw_vec4_generator.cpp
>> +++ b/src/mesa/drivers/dri/i965/brw_vec4_generator.cpp
>> @@ -800,7 +800,7 @@ generate_scratch_read(struct brw_codegen *p,
>> if (devinfo->gen < 6)
>>brw_inst_set_cond_modifier(devinfo, send, inst->base_mrf);
>> brw_set_dp_read_message(p, send,
>> -  255, /* binding table index: stateless access */
>> +   brw_scratch_surface_idx(p),
>>BRW_DATAPORT_OWORD_DUAL_BLOCK_1OWORD,
>>msg_type,
>>BRW_DATAPORT_READ_TARGET_RENDER_CACHE,
>> @@ -873,7 +873,7 @@ generate_scratch_write(struct brw_codegen *p,
>> if (devinfo->gen < 6)
>>brw_inst_set_cond_modifier(p->devinfo, send, inst->base_mrf);
>> brw_set_dp_write_message(p, send,
>> -   255, /* binding table index: stateless access */
>> +brw_scratch_surface_idx(p),
>> BRW

Re: [Mesa-dev] [PATCH v2 5.5/42] i965: Add slice count to the brw_device_info structure.

[Francisco Jerez]

Hi Ben,

Ben Widawsky  writes:

> The most important feedback I have on the patch is that we continue to add 
> stuff
> like this for compute when there is a libdrm interface which exposes all or 
> most
> of it - and that interface should either be expanded or removed. FWIW, I 
> wasn't
> a big fan of the interface when it was introduced, but it seems without 
> reading
> reading and decoding the fuse registers, we can't actually figure some of this
> stuff out on CHV.
>
CHV can only have one slice.

> Is there a reason we cannot use the libdrm interface to get this info?
>
I'm not aware of any libdrm interface that would give you the slice
count.

> On Wed, Nov 25, 2015 at 04:22:28PM +0200, Francisco Jerez wrote:
>> ---
>>  src/mesa/drivers/dri/i965/brw_device_info.c | 20 
>>  src/mesa/drivers/dri/i965/brw_device_info.h |  5 +
>>  2 files changed, 25 insertions(+)
>> 
>> diff --git a/src/mesa/drivers/dri/i965/brw_device_info.c 
>> b/src/mesa/drivers/dri/i965/brw_device_info.c
>> index 4550550..bf31898 100644
>> --- a/src/mesa/drivers/dri/i965/brw_device_info.c
>> +++ b/src/mesa/drivers/dri/i965/brw_device_info.c
>> @@ -28,6 +28,7 @@
>
> [snip]
>
> I don't know if "slice" means anything prior to IVB.

The SNB documentation already mentions it, but I'm not aware of any
device ever manufactured before HSW GT3 with more than one slice.

Regardless of whether the "slice" existed or not prior to that, because
the slice count is mainly just a multiplicative factor we should IMO set
the slice count to the multiplicative identity on all generations that
never had multiple slices, because that makes special-casing for them
unnecessary.

>
>> @@ -131,6 +137,7 @@ static const struct brw_device_info 
>> brw_device_info_ivb_gt1 = {
>>  static const struct brw_device_info brw_device_info_ivb_gt2 = {
>> GEN7_FEATURES, .is_ivybridge = true, .gt = 2,
>> .needs_unlit_centroid_workaround = true,
>> +   .num_slices = 1,
>> .max_vs_threads = 128,
>> .max_hs_threads = 128,
>> .max_ds_threads = 128,
>> @@ -150,6 +157,7 @@ static const struct brw_device_info 
>> brw_device_info_ivb_gt2 = {
>>  static const struct brw_device_info brw_device_info_byt = {
>> GEN7_FEATURES, .is_baytrail = true, .gt = 1,
>> .needs_unlit_centroid_workaround = true,
>> +   .num_slices = 1,
>> .has_llc = false,
>> .max_vs_threads = 36,
>> .max_hs_threads = 36,
>> @@ -175,6 +183,7 @@ static const struct brw_device_info brw_device_info_byt 
>> = {
>>  
>>  static const struct brw_device_info brw_device_info_hsw_gt1 = {
>> HSW_FEATURES, .gt = 1,
>> +   .num_slices = 1,
>> .max_vs_threads = 70,
>> .max_hs_threads = 70,
>> .max_ds_threads = 70,
>> @@ -193,6 +202,7 @@ static const struct brw_device_info 
>> brw_device_info_hsw_gt1 = {
>>  
>>  static const struct brw_device_info brw_device_info_hsw_gt2 = {
>> HSW_FEATURES, .gt = 2,
>> +   .num_slices = 1,
>> .max_vs_threads = 280,
>> .max_hs_threads = 256,
>> .max_ds_threads = 280,
>> @@ -211,6 +221,7 @@ static const struct brw_device_info 
>> brw_device_info_hsw_gt2 = {
>>  
>>  static const struct brw_device_info brw_device_info_hsw_gt3 = {
>> HSW_FEATURES, .gt = 3,
>> +   .num_slices = 2,
>> .max_vs_threads = 280,
>> .max_hs_threads = 256,
>> .max_ds_threads = 280,
>> @@ -243,6 +254,7 @@ static const struct brw_device_info 
>> brw_device_info_hsw_gt3 = {
>>  
>>  static const struct brw_device_info brw_device_info_bdw_gt1 = {
>> GEN8_FEATURES, .gt = 1,
>> +   .num_slices = 1,
>> .max_cs_threads = 42,
>> .urb = {
>>.size = 192,
>> @@ -256,6 +268,7 @@ static const struct brw_device_info 
>> brw_device_info_bdw_gt1 = {
>>  
>>  static const struct brw_device_info brw_device_info_bdw_gt2 = {
>> GEN8_FEATURES, .gt = 2,
>> +   .num_slices = 1,
>> .max_cs_threads = 56,
>> .urb = {
>>.size = 384,
>> @@ -269,6 +282,7 @@ static const struct brw_device_info 
>> brw_device_info_bdw_gt2 = {
>>  
>>  static const struct brw_device_info brw_device_info_bdw_gt3 = {
>> GEN8_FEATURES, .gt = 3,
>> +   .num_slices = 2,
>> .max_cs_threads = 56,
>> .urb = {
>>.size = 384,
>> @@ -283,6 +297,7 @@ static const struct brw_device_info 
>> brw_device_info_bdw_gt3 = {
>>  static const struct brw_device_info brw_device_info_chv = {
>> GEN8_FEATURES, .is_cherryview = 1, .gt = 1,
>> .has_llc = false,
>> +   .num_slices = 1,
>> .max_vs_threads = 80,
>> .max_hs_threads = 80,
>> .max_ds_threads = 80,
>> @@ -324,19 +339,23 @@ static const struct brw_device_info 
>> brw_device_info_chv = {
>>  
>>  static const struct brw_device_info brw_device_info_skl_gt1 = {
>> GEN9_FEATURES, .gt = 1,
>> +   .num_slices = 1,
>> .urb.size = 192,
>>  };
>>  
>>  static const struct brw_device_info brw_device_info_skl_gt2 = {
>> GEN9_FEATURES, .gt = 2,
>> +   .num_slices = 1,
>>  };
>>  
>>  static const struct brw_device_info brw_device_info_skl_gt3 = {
>>  

Re: [Mesa-dev] [PATCH] glsl: don't generate extra errors in ValidateProgramPipeline

[Timothy Arceri]

On Thu, 2015-11-26 at 21:50 +1100, Timothy Arceri wrote:
> From Section 11.1.3.11 (Validation) of the GLES 3.1 spec:
> 
>"An INVALID_OPERATION error is generated by any command that trans
> -
>fers vertices to the GL or launches compute work if the current
> set
>of active program objects cannot be executed, for reasons
> including:"
> 
> It then goes on to list the rules we validate in the
> _mesa_validate_program_pipeline() function.
> 
> For ValidateProgramPipeline the only meantion of generating an error
> is:
> 
>"An INVALID_OPERATION error is generated if pipeline is not a name
> re-
>turned from a previous call to GenProgramPipelines or if such a
> name has
>since been deleted by DeleteProgramPipelines,"
> 
> Which we handle separately.
> 
> This fixes:
> ES31-CTS.sepshaderobjs.PipelineApi
> 
> No regressions on the eEQP 3.1 tests.
> 
> Cc: Gregory Hainaut 
> Cc: Tapani Pälli 
> ---
>  src/mesa/main/pipelineobj.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/src/mesa/main/pipelineobj.c
> b/src/mesa/main/pipelineobj.c
> index 0439129..285fc2f 100644
> --- a/src/mesa/main/pipelineobj.c
> +++ b/src/mesa/main/pipelineobj.c
> @@ -928,8 +928,7 @@ _mesa_ValidateProgramPipeline(GLuint pipeline)
>return;
> }
>  
> -   _mesa_validate_program_pipeline(ctx, pipe,
> -   (ctx->_Shader->Name == pipe
> ->Name));

I'll also add and extra comment here:

/* We pass false for IsBound because we don't want a validation
 * failure to trigger an error.
 */ 

> +   _mesa_validate_program_pipeline(ctx, pipe, false);
>  
> /* Validate inputs against outputs, this cannot be done during
> linking
>  * since programs have been linked separately from each other.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] mesa/main: TexImage2DMultisample needs to pass OpenGL3.3 conformance test.

[Predut, Marius]

> -Original Message-
> From: mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org] On Behalf Of
> Timothy Arceri
> Sent: Wednesday, November 25, 2015 6:02 PM
> To: Palli, Tapani; Predut, Marius; mesa-dev@lists.freedesktop.org
> Subject: Re: [Mesa-dev] [PATCH] mesa/main: TexImage2DMultisample needs to pass
> OpenGL3.3 conformance test.
> 
> On Wed, 2015-11-25 at 17:13 +0200, Tapani Pälli wrote:
> > On 11/25/2015 04:00 PM, Predut, Marius wrote:
> > > > -Original Message-
> > > > From: mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org] On
> > > > Behalf Of Timothy Arceri
> > > > Sent: Wednesday, November 25, 2015 1:12 PM
> > > > To: Palli, Tapani; Predut, Marius; mesa-dev@lists.freedesktop.org
> > > > Subject: Re: [Mesa-dev] [PATCH] mesa/main: TexImage2DMultisample
> > > > needs to pass
> > > > OpenGL3.3 conformance test.
> > > >
> > > > On Wed, 2015-11-25 at 12:47 +0200, Tapani Pälli wrote:
> > > > > Hi;
> > > > >
> > > > > On 11/25/2015 01:15 PM, Marius Predut wrote:
> > > > > > Open GL 3.3 reference document says:
> > > > > > samples must be in the range zero to GL_MAX_TEXTURE_SIZE - 1.
> > > > > > Open GL.4 clearly states:
> > > > > > An INVALID_VALUE error is generated if samples is zero.
> > > > See my comment in bugzilla [1] I believe this is just a bug in the
> > > > reference pages, we implement things in Mesa going by what the
> > > > spec says and the spec says nothing about samples being 0 in the
> > > > 3.2 spec in fact it doen't even say anything in the 4.0 spec which
> > > > you have changed the check to.
> > > >
> > > > Also the 4.5 reference pages also conflict with the spec so this
> > > > is even more reason I think this change is wrong.
> > > >
> > > > [1] https://bugs.freedesktop.org/show_bug.cgi?id=91670
> > > >
> > > I don't think it is a bug in specs because in this case also the CTS
> > > and the piglit test is wrong:
> > >
> > > With this patch 2 things are fixed:
> > > 1.Khronos CTS conformance tests for OpenGL 3.3 2. The piglit test
> > > https://bugs.freedesktop.org/show_bug.cgi?id=93100 (Or
> > > https://bugs.freedesktop.org/show_bug.cgi?id=91670)
> > >
> > > The patch is based on this spec:
> > > https://www.opengl.org/sdk/docs/man3/xhtml/glTexImage3DMultisample.
> > > xml
> > >
> > > We can't believe or "suppose" something here, the specs need to be
> > > as an axioma.
> > > Can someone confirm that this reference includes the wrong specs?
> >
> > That's not a specification but a manual page. Timothy is pointing to
> > OpenGL specifications (available at www.opengl.org/registry). It is
> > true that for example 3.3 Core does not mention this error case which
> > means using 0 was allowed there. IMO either we should allow to use 0
> > (and bump it to 1?) when running on 3.x context since it's not
> > forbidden or maybe just locally patch this whenever running 3.x
> > conformance.
> 
> Hi Marius,
> 
> Please provide the test CTS test that you are trying to fix so that we can
> take a look at what the CTS is trying to test.
> 
> While the OpenGL 3.2 -> 4.2 specs seem to allow zero due simple to not
> mentioning it seems odd to me that the CTS would specificly test for this. As
> far as I understand it a value of 0 would result in undefined behaviour, so it
> doesn't seem right to allow this for these versions of OpenGL. IMO we should
> be going with the later specs that fix this oversight for all versions of GL.
> 
> One thing I can see the CTS doing in various tests is querying the GL
> implementation for values, its possible we are passing a value of 0 back to
> the tests somewhere and its trying to used this with the multisample
> functions. The only way to know whats going on is if you tell us which test
> you are trying to fix.
> 
> Tim


Hi Tim

On my case, in file 
otc_gen_graphics-khronos-glconform/framework/opengl/gluStateReset.cpp
I have something like :

if (type >= CONTEXTTYPE_GL32_CORE)
{
// Reset 2D multisample texture.
gl.bindTexture  (GL_TEXTURE_2D_MULTISAMPLE, 0);
gl.texImage2DMultisample(GL_TEXTURE_2D_MULTISAMPLE, 0, 
GL_RGBA8, 0, 0, GL_TRUE);
// Reset 2D multisample array texture.
gl.bindTexture  (GL_TEXTURE_2D_MULTISAMPLE_ARRAY, 
0);
gl.texImage3DMultisample(GL_TEXTURE_2D_MULTISAMPLE_ARRAY, 
0, GL_RGBA8, 0, 0, 0, GL_TRUE);
}
I run the piglit tests, and with 0 for sample I don’t see regressions.
(also this suppose rollback the piglit 
gl-3.2-layered-rendering-framebuffertexture test case)
(also I think the CTS needs update like (type >= CONTEXTTYPE_GL32_CORE && type 
< CONTEXTTYPE_GL40_CORE))
The command I used is : ./cts-runner --type=gl33 --logdir=.


This patch involve TexImage2DMultisample, TexImage3DMultisample, 
TexStorage2DMultisample, TexStorage3DMultisample

> 
> >
> > (It seems OpenGL 4.2 is the first spec to state the INVALID_VALUE
> > error case for 0.)
> > > > > O

[Mesa-dev] [PATCH] glsl: don't generate extra errors in ValidateProgramPipeline

[Timothy Arceri]

From Section 11.1.3.11 (Validation) of the GLES 3.1 spec:

   "An INVALID_OPERATION error is generated by any command that trans-
   fers vertices to the GL or launches compute work if the current set
   of active program objects cannot be executed, for reasons including:"

It then goes on to list the rules we validate in the
_mesa_validate_program_pipeline() function.

For ValidateProgramPipeline the only meantion of generating an error is:

   "An INVALID_OPERATION error is generated if pipeline is not a name re-
   turned from a previous call to GenProgramPipelines or if such a name has
   since been deleted by DeleteProgramPipelines,"

Which we handle separately.

This fixes:
ES31-CTS.sepshaderobjs.PipelineApi

No regressions on the eEQP 3.1 tests.

Cc: Gregory Hainaut 
Cc: Tapani Pälli 
---
 src/mesa/main/pipelineobj.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/mesa/main/pipelineobj.c b/src/mesa/main/pipelineobj.c
index 0439129..285fc2f 100644
--- a/src/mesa/main/pipelineobj.c
+++ b/src/mesa/main/pipelineobj.c
@@ -928,8 +928,7 @@ _mesa_ValidateProgramPipeline(GLuint pipeline)
   return;
}
 
-   _mesa_validate_program_pipeline(ctx, pipe,
-   (ctx->_Shader->Name == pipe->Name));
+   _mesa_validate_program_pipeline(ctx, pipe, false);
 
/* Validate inputs against outputs, this cannot be done during linking
 * since programs have been linked separately from each other.
-- 
2.4.3

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

Re: [Mesa-dev] [PATCH 1/1] i965: Do not overwrite optimizer dumps

[Eero Tamminen]

Hi,

On 11/25/2015 08:52 PM, Jason Ekstrand wrote:

On Wed, Nov 25, 2015 at 10:49 AM, Kenneth Graunke  wrote:

[...]

It almost seems like you want a hash of the program key - and maybe a
file containing a printed copy of the key so you can identify which
program is which.

Alternatively, one could use the address of the key with %p to obtain
a unique identifier.  That's easy and should solve the problem.


Unfortunately, the pointer is non-deterministic so comparing from one
run to another is going to be hard.  A quick-and-dirty hash of the key
might work though.


Why not use the same path/file prefix & hash as what 
MESA_SHADER_DUMP_PATH feature does?


Then it's easy to match saved GLSL source to the optimizer output.

(Windows driver uses same shader source hash for identifying everything 
from GLSL source to intermediate representation to shader asm and I 
think that's the only sane way.)



- Eero


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

Re: [Mesa-dev] [PATCH 2/5] i965/gen8+: Don't upload the MCS buffer for single-sampled textures

[Neil Roberts]

> On Thu, Nov 26, 2015 at 11:18:34AM +0200, Pohjolainen, Topi wrote:
>> On Wed, Nov 25, 2015 at 11:01:18AM -0800, Ben Widawsky wrote:
>> > On Wed, Nov 25, 2015 at 06:36:36PM +0100, Neil Roberts wrote:
>> > > For single-sampled textures the MCS buffer is only used to implement
>> > > fast clears. However the surface always needs to be resolved before
>> > > being used as a texture anyway so the the MCS buffer doesn't actually
>> > > achieve anything. This is important for Gen9 because in that case SRGB
>> > 
>> > I admit a good deal of ignorance, but why do we have to do a resolve 
>> > before we
>> > sample from it? I thought the whole point of the MCS was that we can 
>> > sample from
>> > it without a resolve.
>> 
>> This is my understanding also, I can't see much benefit from the fast clear
>> if it would need to be anyway resolved before reading it using GPU (reading
>> using CPU is then another story of course).
>
> I know we have this piece of text in bspec:
>
> "If the MCS is enabled on a non-multisampled render target, the render
> target must be resolved before being used for other purposes (display,
> texture, CPU lock)."
>
> But on the other hand the fact that surface state supports definition of fast
> cleared MCS buffer even for sampler engine suggest that "texture" in that
> sentence refers to something else than sampling. Not to mention that we
> already sample fast cleared color buffers with current Mesa driver and seem
> to have no problems with it.

The resolve needs to be done for single-sampled render targets but for
multisample targets we can safely sample from the MCS buffer. The MCS
(or CCS or whatever it should be called in this case) is still useful
even if we have to resolve because it saves memory bandwidth during
rendering. Eg, the initial clear writes less data because it only writes
to the smaller MCS buffer and not the larger color buffer. Any blending
operations during rendering can also read from the CCS instead of the
color buffer. I guess the assumption is that the bandwidth savings
during rendering outweigh the extra cost added by having to resolve it.

To be clear, this patch doesn't add the resolve step needed before
texturing, nor does anything in the series. The resolve step is already
done for all gens in intel_update_state. Look at the bit with the
comment “Resolve depth buffer and render cache of each enabled texture”.
It calls intel_miptree_resolve_color which resolves the CCS buffer for
each singled-sampled surface that is going to be used as a texture. The
only change this patch makes it to not not even set the aux buffer in
the texture surface state.

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

Re: [Mesa-dev] [PATCH 2/2] i965: run brw_vec4 optimizations in loop

[Juan A. Suarez Romero]

On Wed, 2015-11-25 at 16:16 -0800, Matt Turner wrote:
> I think in this case a better solution -- at least until we learn
> something more -- would be to initialize opt_vector_float()'s
> remaining_channels to only the live components of the register. Do
> you
> want to try that?


Sure! There's a lot of very interesting information here. Thanks!


J.A.

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

[Mesa-dev] [Bug 93114] No water rendered in CoR

[bugzilla-daemon]

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

--- Comment #4 from smidjar2@email.cz ---
Created attachment 120135
  --> https://bugs.freedesktop.org/attachment.cgi?id=120135&action=edit
Shader dump

There is part of shader dump, that I think may be relevant. I don't know if the
failure is for shader dump above or bellow the message, so I am keeping them
both.

-- 
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 93114] No water rendered in CoR

[bugzilla-daemon]

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

smidjar2@email.cz changed:

   What|Removed |Added

 Attachment #120132|0   |1
is obsolete||

--- Comment #3 from smidjar2@email.cz ---
Created attachment 120134
  --> https://bugs.freedesktop.org/attachment.cgi?id=120134&action=edit
Water in gallium-nine enabled wine

-- 
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 93114] No water rendered in CoR

[bugzilla-daemon]

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

smidjar2@email.cz changed:

   What|Removed |Added

 Attachment #120131|0   |1
is obsolete||

--- Comment #2 from smidjar2@email.cz ---
Created attachment 120133
  --> https://bugs.freedesktop.org/attachment.cgi?id=120133&action=edit
No Water in OpenGL

-- 
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 93114] No water rendered in CoR

[bugzilla-daemon]

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

--- Comment #1 from smidjar2@email.cz ---
Created attachment 120132
  --> https://bugs.freedesktop.org/attachment.cgi?id=120132&action=edit
Water in gallium-nine enabled Wine

-- 
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 93114] No water rendered in CoR

[bugzilla-daemon]

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

Bug ID: 93114
   Summary: No water rendered in CoR
   Product: Mesa
   Version: git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Mesa core
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: smidjar2@email.cz
QA Contact: mesa-dev@lists.freedesktop.org

Created attachment 120131
  --> https://bugs.freedesktop.org/attachment.cgi?id=120131&action=edit
No water for OpenGL

There is no water rendered for Champions of Regnum (aka Regnum Online). It
affects radeon and intel GPUs (nouveau untested, but probably too).

When using proprietary fglrx, water is rendered correctly. In the past I used
nvidia proprietary with my old GPU and water was there too. Water is also
rendered correctly when running the game under gallium-nine enabled Wine, so I
believe it is bug in OpenGL somewhere.

Also multitexturing doesn't seem to work for this game, this may be related to
the issue.

I am attaching a screenshot showing no water is there and another one showing
the water when running under wine.

-- 
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 2/5] i965/gen8+: Don't upload the MCS buffer for single-sampled textures

[Pohjolainen, Topi]

On Thu, Nov 26, 2015 at 11:18:34AM +0200, Pohjolainen, Topi wrote:
> On Wed, Nov 25, 2015 at 11:01:18AM -0800, Ben Widawsky wrote:
> > On Wed, Nov 25, 2015 at 06:36:36PM +0100, Neil Roberts wrote:
> > > For single-sampled textures the MCS buffer is only used to implement
> > > fast clears. However the surface always needs to be resolved before
> > > being used as a texture anyway so the the MCS buffer doesn't actually
> > > achieve anything. This is important for Gen9 because in that case SRGB
> > 
> > I admit a good deal of ignorance, but why do we have to do a resolve before 
> > we
> > sample from it? I thought the whole point of the MCS was that we can sample 
> > from
> > it without a resolve.
> 
> This is my understanding also, I can't see much benefit from the fast clear
> if it would need to be anyway resolved before reading it using GPU (reading
> using CPU is then another story of course).

I know we have this piece of text in bspec:

"If the MCS is enabled on a non-multisampled render target, the render
target must be resolved before being used for other purposes (display,
texture, CPU lock)."

But on the other hand the fact that surface state supports definition of fast
cleared MCS buffer even for sampler engine suggest that "texture" in that
sentence refers to something else than sampling. Not to mention that we
already sample fast cleared color buffers with current Mesa driver and seem
to have no problems with it.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/5] i965/gen8+: Don't upload the MCS buffer for single-sampled textures

[Pohjolainen, Topi]

On Wed, Nov 25, 2015 at 11:01:18AM -0800, Ben Widawsky wrote:
> On Wed, Nov 25, 2015 at 06:36:36PM +0100, Neil Roberts wrote:
> > For single-sampled textures the MCS buffer is only used to implement
> > fast clears. However the surface always needs to be resolved before
> > being used as a texture anyway so the the MCS buffer doesn't actually
> > achieve anything. This is important for Gen9 because in that case SRGB
> 
> I admit a good deal of ignorance, but why do we have to do a resolve before we
> sample from it? I thought the whole point of the MCS was that we can sample 
> from
> it without a resolve.

This is my understanding also, I can't see much benefit from the fast clear
if it would need to be anyway resolved before reading it using GPU (reading
using CPU is then another story of course).

> 
> > surfaces are not supported for fast clears and we don't want the
> > hardware to see the MCS buffer in that case.
> > ---
> >  src/mesa/drivers/dri/i965/gen8_surface_state.c | 6 +-
> >  1 file changed, 5 insertions(+), 1 deletion(-)
> > 
> > diff --git a/src/mesa/drivers/dri/i965/gen8_surface_state.c 
> > b/src/mesa/drivers/dri/i965/gen8_surface_state.c
> > index 80252a5..075424a 100644
> > --- a/src/mesa/drivers/dri/i965/gen8_surface_state.c
> > +++ b/src/mesa/drivers/dri/i965/gen8_surface_state.c
> > @@ -225,7 +225,11 @@ gen8_emit_texture_surface_state(struct brw_context 
> > *brw,
> >pitch = mt->pitch;
> > }
> >  
> > -   if (mt->mcs_mt) {
> > +   /* The MCS is not uploaded for single-sampled surfaces because the color
> > +* buffer should always have been resolved before it is used as a 
> > texture
> > +* so there is no need for it.
> > +*/
> > +   if (mt->mcs_mt && mt->num_samples > 1) {
> >aux_mt = mt->mcs_mt;
> >aux_mode = GEN8_SURFACE_AUX_MODE_MCS;
> >  
> 
> 
> -- 
> Ben Widawsky, Intel Open Source Technology Center
> ___
> 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 21/42] glsl: Add default matrix ordering in lower_buffer_access

[Iago Toral]

On Wed, 2015-11-25 at 11:59 -0800, Jordan Justen wrote:
> On 2015-11-25 01:32:37, Iago Toral wrote:
> > 
> > On Tue, 2015-11-17 at 21:54 -0800, Jordan Justen wrote:
> > > For compute shader shared variable we will set a default of column
> > > major.
> > > 
> > > Signed-off-by: Jordan Justen 
> > > ---
> > >  src/glsl/lower_buffer_access.cpp |  5 +++--
> > >  src/glsl/lower_buffer_access.h   | 10 ++
> > >  2 files changed, 13 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/src/glsl/lower_buffer_access.cpp 
> > > b/src/glsl/lower_buffer_access.cpp
> > > index 297ed69..66e7abe 100644
> > > --- a/src/glsl/lower_buffer_access.cpp
> > > +++ b/src/glsl/lower_buffer_access.cpp
> > > @@ -281,8 +281,9 @@ 
> > > lower_buffer_access::is_dereferenced_thing_row_major(const ir_rvalue 
> > > *deref)
> > >  
> > >   switch (matrix_layout) {
> > >   case GLSL_MATRIX_LAYOUT_INHERITED:
> > > -assert(!matrix);
> > > -return false;
> > > +assert(default_matrix_layout != GLSL_MATRIX_LAYOUT_INHERITED 
> > > ||
> > > +   !matrix);
> > > +return default_matrix_layout == GLSL_MATRIX_LAYOUT_ROW_MAJOR;
> > 
> > I am not sure I understand this. If shared variables are column major by
> > default, then isn't that the same behavior we have for ubos and ssbos?
> > In what case is this needed?
> 
> I think some code must walk the interface blocks an assign the
> interface matrix layouts to matrices which are set to inherit their
> layout.

Yes, there is code for that in ast_to_hir.cpp, see
ast_interface_block::hir().

> Since shared variables are not part of an interface block, this
> doesn't happen for matrices in shared variables. This leads to us
> hitting the previous assert(!matrix) code.

Ok, I see.

> Instead of this change we could also go through and mark all matrices
> in shared variables with a layout other than 'inherited' at an earlier
> stage.

Probably not worth it if we can handle it here without extra cost. Maybe
we can make the code more obvious though.

How about this instead?:

case GLSL_MATRIX_LAYOUT_INHERITED: {
   /* For interface block matrix variables we handle inherited layouts
* at HIR generation time, but we don't do that for shared 
* variables, which are always column-major
*/
   ir_variable *var = deref->variable_referenced();
   assert((var->is_in_buffer_block() && !matrix) ||
  var->data.mode == ir_var_shader_shared)
   return false;
}

Iago

> 
> > 
> > >   case GLSL_MATRIX_LAYOUT_COLUMN_MAJOR:
> > >  return false;
> > >   case GLSL_MATRIX_LAYOUT_ROW_MAJOR:
> > > diff --git a/src/glsl/lower_buffer_access.h 
> > > b/src/glsl/lower_buffer_access.h
> > > index f8e1070..82b35ed 100644
> > > --- a/src/glsl/lower_buffer_access.h
> > > +++ b/src/glsl/lower_buffer_access.h
> > > @@ -39,6 +39,14 @@ namespace lower_buffer_access {
> > >  
> > >  class lower_buffer_access : public ir_rvalue_enter_visitor {
> > >  public:
> > > +   lower_buffer_access() :
> > > +  default_matrix_layout(GLSL_MATRIX_LAYOUT_INHERITED)
> > > +   {}
> > > +
> > > +   lower_buffer_access(enum glsl_matrix_layout default_matrix_layout) :
> > > +  default_matrix_layout(default_matrix_layout)
> > > +   {}
> > > +
> > > virtual void
> > > insert_buffer_access(void *mem_ctx, ir_dereference *deref,
> > >  const glsl_type *type, ir_rvalue *offset,
> > > @@ -55,6 +63,8 @@ public:
> > >  ir_rvalue **offset, unsigned *const_offset,
> > >  bool *row_major, int *matrix_columns,
> > >  unsigned packing);
> > > +
> > > +   enum glsl_matrix_layout default_matrix_layout;
> > >  };
> > >  
> > >  } /* namespace lower_buffer_access */
> > 
> > 
> > 
> 


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

[Mesa-dev] [Bug 93091] [opencl] segfault when running any opencl programs (like clinfo)

[bugzilla-daemon]

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

--- Comment #8 from Samuel Pitoiset  ---
This segfault still happens for me using mesa git, commit
ca976e6900dc8ff457ed9dba661d037c616abc59.

OpenGL renderer string: Gallium 0.4 on NVE7
OpenGL core profile version string: 4.1 (Core Profile) Mesa 11.2.0-devel
(git-ca976e6)

#0  pipe_loader_create_screen (dev=0x0) at pipe_loader.c:79
#1  0x76177b0a in clover::device::device (this=0x641cd0, platform=...,
ldev=) at core/device.cpp:44
#2  0x76183226 in clover::create () at ./util/pointer.hpp:230
#3  clover::platform::platform (this=0x77dc5520 <(anonymous
namespace)::_clover_platform>) at core/platform.cpp:35
#4  0x7612e196 in __static_initialization_and_destruction_0
(__initialize_p=1, __priority=65535) at api/platform.cpp:29
#5  _GLOBAL__sub_I_platform.cpp(void) () at api/platform.cpp:120
#6  0x77dea27a in call_init.part () from /lib64/ld-linux-x86-64.so.2
#7  0x77dea38b in _dl_init () from /lib64/ld-linux-x86-64.so.2
#8  0x77ddbdba in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
#9  0x0001 in ?? ()
#10 0x7fffe356 in ?? ()
#11 0x in ?? ()

-- 
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] tinderbox regression

[Michel Dänzer]

On 26.11.2015 17:11, Dave Airlie wrote:
> http://tinderbox.x.org/builds/2015-11-26-0001/logs/mesa-mesa/#build
> 
> just went past me.

Fixed in
http://cgit.freedesktop.org/mesa/mesa/commit/?id=22d2dda03be32d23bc8e9f5823a4f2469737ddbe,
not sure why that tinderbox hasn't picked that up yet.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v3] st/va: delay decoder creation until max_references is known

[Julien Isorce]

In general max_references cannot be based on num_render_targets.

This patch allows to allocate buffers with an accurate size.
I.e. no more than necessary. For other codecs it is a fixed
value 2.

This is similar behaviour as vaapi/vdpau-driver.

For now HEVC case defaults to num_render_targets as before.
But it could also benefits this change by setting a more
accurate max_references number in handlePictureParameterBuffer.

Signed-off-by: Julien Isorce 
---
 src/gallium/state_trackers/va/context.c  | 48 +--
 src/gallium/state_trackers/va/picture.c  | 49 +++-
 src/gallium/state_trackers/va/picture_h264.c |  4 +++
 src/gallium/state_trackers/va/va_private.h   |  2 +-
 4 files changed, 69 insertions(+), 34 deletions(-)

diff --git a/src/gallium/state_trackers/va/context.c 
b/src/gallium/state_trackers/va/context.c
index f0051e5..192794f 100644
--- a/src/gallium/state_trackers/va/context.c
+++ b/src/gallium/state_trackers/va/context.c
@@ -187,7 +187,6 @@ vlVaCreateContext(VADriverContextP ctx, VAConfigID 
config_id, int picture_width,
   int picture_height, int flag, VASurfaceID *render_targets,
   int num_render_targets, VAContextID *context_id)
 {
-   struct pipe_video_codec templat = {};
vlVaDriver *drv;
vlVaContext *context;
int is_vpp;
@@ -213,27 +212,22 @@ vlVaCreateContext(VADriverContextP ctx, VAConfigID 
config_id, int picture_width,
  return VA_STATUS_ERROR_INVALID_CONTEXT;
   }
} else {
-  templat.profile = config_id;
-  templat.entrypoint = PIPE_VIDEO_ENTRYPOINT_BITSTREAM;
-  templat.chroma_format = PIPE_VIDEO_CHROMA_FORMAT_420;
-  templat.width = picture_width;
-  templat.height = picture_height;
-  templat.max_references = num_render_targets;
-  templat.expect_chunked_decode = true;
-
-  if (u_reduce_video_profile(templat.profile) ==
-PIPE_VIDEO_FORMAT_MPEG4_AVC)
-templat.level = u_get_h264_level(templat.width, templat.height,
- &templat.max_references);
-
-  context->decoder = drv->pipe->create_video_codec(drv->pipe, &templat);
-  if (!context->decoder) {
- FREE(context);
- return VA_STATUS_ERROR_ALLOCATION_FAILED;
-  }
-
-  if (u_reduce_video_profile(context->decoder->profile) ==
- PIPE_VIDEO_FORMAT_MPEG4_AVC) {
+  context->templat.profile = config_id;
+  context->templat.entrypoint = PIPE_VIDEO_ENTRYPOINT_BITSTREAM;
+  context->templat.chroma_format = PIPE_VIDEO_CHROMA_FORMAT_420;
+  context->templat.width = picture_width;
+  context->templat.height = picture_height;
+  context->templat.expect_chunked_decode = true;
+
+  switch (u_reduce_video_profile(context->templat.profile)) {
+  case PIPE_VIDEO_FORMAT_MPEG12:
+  case PIPE_VIDEO_FORMAT_VC1:
+  case PIPE_VIDEO_FORMAT_MPEG4:
+ context->templat.max_references = 2;
+ break;
+
+  case PIPE_VIDEO_FORMAT_MPEG4_AVC:
+ context->templat.max_references = 0;
  context->desc.h264.pps = CALLOC_STRUCT(pipe_h264_pps);
  if (!context->desc.h264.pps) {
 FREE(context);
@@ -245,10 +239,10 @@ vlVaCreateContext(VADriverContextP ctx, VAConfigID 
config_id, int picture_width,
 FREE(context);
 return VA_STATUS_ERROR_ALLOCATION_FAILED;
  }
-  }
+ break;
 
-  if (u_reduce_video_profile(context->decoder->profile) ==
-PIPE_VIDEO_FORMAT_HEVC) {
+ case PIPE_VIDEO_FORMAT_HEVC:
+ context->templat.max_references = num_render_targets;
  context->desc.h265.pps = CALLOC_STRUCT(pipe_h265_pps);
  if (!context->desc.h265.pps) {
 FREE(context);
@@ -260,6 +254,10 @@ vlVaCreateContext(VADriverContextP ctx, VAConfigID 
config_id, int picture_width,
 FREE(context);
 return VA_STATUS_ERROR_ALLOCATION_FAILED;
  }
+ break;
+
+  default:
+ break;
   }
}
 
diff --git a/src/gallium/state_trackers/va/picture.c 
b/src/gallium/state_trackers/va/picture.c
index 25d2940..8d938f4 100644
--- a/src/gallium/state_trackers/va/picture.c
+++ b/src/gallium/state_trackers/va/picture.c
@@ -59,14 +59,17 @@ vlVaBeginPicture(VADriverContextP ctx, VAContextID 
context_id, VASurfaceID rende
   return VA_STATUS_ERROR_INVALID_SURFACE;
 
context->target = surf->buffer;
+
if (!context->decoder) {
   /* VPP */
-  if ((context->target->buffer_format != PIPE_FORMAT_B8G8R8A8_UNORM  &&
+  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->tar

Re: [Mesa-dev] [PATCH v2 1/2] st/va: if h264 then delay decoder creation until max_references is known

[Julien Isorce]

On 25 November 2015 at 15:04, Emil Velikov  wrote:

> Hi Julien,
>
> On 25 November 2015 at 09:07, Julien Isorce 
> wrote:
> > From: Julien Isorce 
> >
> > In general max_references cannot be based on num_render_targets.
> >
> > This patch allow to allocate accurate sizes for buffers.
> > For other codecs it is a fixed value to 2.
> >
> > This is similar behaviour as vaapi/vdpau-driver.
> >
> > XXX: do the same for HEVC
> >
> > Signed-off-by: Julien Isorce 
> > ---
> >  src/gallium/state_trackers/va/context.c  | 41
> ++--
> >  src/gallium/state_trackers/va/picture.c  | 37
> ++---
> >  src/gallium/state_trackers/va/picture_h264.c | 29 +++-
> >  src/gallium/state_trackers/va/va_private.h   |  4 +--
> >  4 files changed, 78 insertions(+), 33 deletions(-)
> >
> > diff --git a/src/gallium/state_trackers/va/context.c
> b/src/gallium/state_trackers/va/context.c
> > index f0051e5..985007b 100644
> > --- a/src/gallium/state_trackers/va/context.c
> > +++ b/src/gallium/state_trackers/va/context.c
>
> > +  /* Can only create decoders for which max_references is known. */
> > +  if (u_reduce_video_profile(context->templat.profile) !=
> > + PIPE_VIDEO_FORMAT_MPEG4_AVC) {
> > + context->decoder = drv->pipe->create_video_codec(drv->pipe,
> > +&context->templat);
> > + if (!context->decoder) {
> > +FREE(context);
> > +return VA_STATUS_ERROR_ALLOCATION_FAILED;
> > + }
> >}
> What is the benefit of delaying only h264 ? Won't this make things
> less obvious and you'll have more subtle checks throughout ?
>

Good idea, I had a try and indeed it is much easier.


>
> > --- a/src/gallium/state_trackers/va/picture.c
> > +++ b/src/gallium/state_trackers/va/picture.c
> > @@ -60,6 +60,12 @@ vlVaBeginPicture(VADriverContextP ctx, VAContextID
> context_id, VASurfaceID rende
> >
> > context->target = surf->buffer;
> > if (!context->decoder) {
> > +  /* Decoder creation is delayed until max_references is set. */
> > +  if (u_reduce_video_profile(context->templat.profile) ==
> > +  PIPE_VIDEO_FORMAT_MPEG4_AVC)
> > + return context->templat.max_references == 0 ?
> > +VA_STATUS_SUCCESS : VA_STATUS_ERROR_INVALID_CONTEXT;
> > +
> Can we really hit the VA_STATUS_ERROR_INVALID_CONTEXT case here ? The
> only way that I can think of is consecutive BeginPicture calls without
> a EndPicture - surely that can cause issues even without this patch.
>

You are right, I'll remove this :) Thx


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

Re: [Mesa-dev] [PATCH v2 1/2] st/va: if h264 then delay decoder creation until max_references is known

[Julien Isorce]

On 25 November 2015 at 09:51, Christian König 
wrote:

> On 25.11.2015 10:12, Julien Isorce wrote:
>
> For commit message please read:
>
> "HEVC case is left unchanged since delaying decoder creation is not needed
> on AMD hardware."
>
>
> In this case please update the commit message, but honestly I'm not sure
> if we don't use the max_references somewhere in the DPB calculation for
> HEVC.
>

Hi , thx for the review.

For HEVC I'll keep same initialization of max_references but since I'll
also delay decoder creation for all codecs (to have only one code path to
maintain as Emil suggested), so one will be able to set this value in
handlePictureParameterBuffer as well.


>
> Some more comments below.
>
>
>
> instead of
>
> "XXX: do the same for HEVC"
>
> On 25 November 2015 at 09:07, Julien Isorce 
> wrote:
>
>> From: Julien Isorce 
>>
>> In general max_references cannot be based on num_render_targets.
>>
>> This patch allow to allocate accurate sizes for buffers.
>> For other codecs it is a fixed value to 2.
>>
>> This is similar behaviour as vaapi/vdpau-driver.
>>
>> XXX: do the same for HEVC
>>
>> Signed-off-by: Julien Isorce 
>> ---
>>  src/gallium/state_trackers/va/context.c  | 41
>> ++--
>>  src/gallium/state_trackers/va/picture.c  | 37
>> ++---
>>  src/gallium/state_trackers/va/picture_h264.c | 29 +++-
>>  src/gallium/state_trackers/va/va_private.h   |  4 +--
>>  4 files changed, 78 insertions(+), 33 deletions(-)
>>
>> diff --git a/src/gallium/state_trackers/va/context.c
>> b/src/gallium/state_trackers/va/context.c
>> index f0051e5..985007b 100644
>> --- a/src/gallium/state_trackers/va/context.c
>> +++ b/src/gallium/state_trackers/va/context.c
>> @@ -187,7 +187,6 @@ vlVaCreateContext(VADriverContextP ctx, VAConfigID
>> config_id, int picture_width,
>>int picture_height, int flag, VASurfaceID
>> *render_targets,
>>int num_render_targets, VAContextID *context_id)
>>  {
>> -   struct pipe_video_codec templat = {};
>> vlVaDriver *drv;
>> vlVaContext *context;
>> int is_vpp;
>> @@ -213,27 +212,28 @@ vlVaCreateContext(VADriverContextP ctx, VAConfigID
>> config_id, int picture_width,
>>   return VA_STATUS_ERROR_INVALID_CONTEXT;
>>}
>> } else {
>> -  templat.profile = config_id;
>> -  templat.entrypoint = PIPE_VIDEO_ENTRYPOINT_BITSTREAM;
>> -  templat.chroma_format = PIPE_VIDEO_CHROMA_FORMAT_420;
>> -  templat.width = picture_width;
>> -  templat.height = picture_height;
>> -  templat.max_references = num_render_targets;
>> -  templat.expect_chunked_decode = true;
>> -
>> -  if (u_reduce_video_profile(templat.profile) ==
>> -PIPE_VIDEO_FORMAT_MPEG4_AVC)
>> -templat.level = u_get_h264_level(templat.width, templat.height,
>> - &templat.max_references);
>> -
>> -  context->decoder = drv->pipe->create_video_codec(drv->pipe,
>> &templat);
>> -  if (!context->decoder) {
>> - FREE(context);
>> - return VA_STATUS_ERROR_ALLOCATION_FAILED;
>> +  context->templat.profile = config_id;
>> +  context->templat.entrypoint = PIPE_VIDEO_ENTRYPOINT_BITSTREAM;
>> +  context->templat.chroma_format = PIPE_VIDEO_CHROMA_FORMAT_420;
>> +  context->templat.width = picture_width;
>> +  context->templat.height = picture_height;
>> +  context->templat.max_references = 2;
>> +  context->templat.expect_chunked_decode = true;
>> +
>> +  /* Can only create decoders for which max_references is known. */
>> +  if (u_reduce_video_profile(context->templat.profile) !=
>> + PIPE_VIDEO_FORMAT_MPEG4_AVC) {
>> + context->decoder = drv->pipe->create_video_codec(drv->pipe,
>> +&context->templat);
>> + if (!context->decoder) {
>> +FREE(context);
>> +return VA_STATUS_ERROR_ALLOCATION_FAILED;
>> + }
>>}
>>
>> -  if (u_reduce_video_profile(context->decoder->profile) ==
>> +  if (u_reduce_video_profile(context->templat.profile) ==
>>   PIPE_VIDEO_FORMAT_MPEG4_AVC) {
>>
>
> Please join this check with the one above, maybe even make this a switch
> statement.
>
> Apart from that looks good to me.
>
>
>
Ack, I'll make this a switch.

> + context->templat.max_references = 0;
>>   context->desc.h264.pps = CALLOC_STRUCT(pipe_h264_pps);
>>   if (!context->desc.h264.pps) {
>>  FREE(context);
>> @@ -247,8 +247,9 @@ vlVaCreateContext(VADriverContextP ctx, VAConfigID
>> config_id, int picture_width,
>>   }
>>}
>>
>> -  if (u_reduce_video_profile(context->decoder->profile) ==
>> +  if (u_reduce_video_profile(context->templat.profile) ==
>>  PIPE_VIDEO_FORMAT_HEVC) {
>> + context->templat.max_references = num_render_targets;
>>   context->desc.h265.pps = CALLOC_STRUCT(pipe_h265_pps);
>>   if (!context->desc.h265.

Re: [Mesa-dev] [PATCH v2 13/42] i965: Work around L3 state leaks during context switches.

[Samuel Iglesias Gonsálvez]

I don't see anything wrong with this patch but you might want wait for
Ben's approval as he might know better than me if this work-around is
right (he is the author of the kernel commit mentioned in this patch).

Reviewed-by: Samuel Iglesias Gonsálvez 

Sam

On 18/11/15 06:54, Jordan Justen wrote:
> From: Francisco Jerez 
> 
> This is going to require some rather intrusive kernel changes to fix
> properly, in the meantime (and forever on at least pre-v4.1 kernels)
> we'll have to restore the hardware defaults at the end of every batch
> in which the L3 configuration was changed to avoid interfering with
> the DDX and GL clients that use an older non-L3-aware version of Mesa.
> ---
>  src/mesa/drivers/dri/i965/brw_state.h |  4 +++
>  src/mesa/drivers/dri/i965/gen7_l3_state.c | 48 
> +++
>  src/mesa/drivers/dri/i965/intel_batchbuffer.c |  7 
>  src/mesa/drivers/dri/i965/intel_batchbuffer.h |  6 +++-
>  4 files changed, 64 insertions(+), 1 deletion(-)
> 
> diff --git a/src/mesa/drivers/dri/i965/brw_state.h 
> b/src/mesa/drivers/dri/i965/brw_state.h
> index 49f301a..b7c0039 100644
> --- a/src/mesa/drivers/dri/i965/brw_state.h
> +++ b/src/mesa/drivers/dri/i965/brw_state.h
> @@ -380,6 +380,10 @@ void gen7_update_binding_table_from_array(struct 
> brw_context *brw,
>  void gen7_disable_hw_binding_tables(struct brw_context *brw);
>  void gen7_reset_hw_bt_pool_offsets(struct brw_context *brw);
>  
> +/* gen7_l3_state.c */
> +void
> +gen7_restore_default_l3_config(struct brw_context *brw);
> +
>  #ifdef __cplusplus
>  }
>  #endif
> diff --git a/src/mesa/drivers/dri/i965/gen7_l3_state.c 
> b/src/mesa/drivers/dri/i965/gen7_l3_state.c
> index 45bad02..84ab118 100644
> --- a/src/mesa/drivers/dri/i965/gen7_l3_state.c
> +++ b/src/mesa/drivers/dri/i965/gen7_l3_state.c
> @@ -495,3 +495,51 @@ const struct brw_tracked_state gen7_l3_state = {
> },
> .emit = emit_l3_state
>  };
> +
> +/**
> + * Hack to restore the default L3 configuration.
> + *
> + * This will be called at the end of every batch in order to reset the L3
> + * configuration to the default values for the time being until the kernel is
> + * fixed.  Until kernel commit 6702cf16e0ba8b0129f5aa1b6609d4e9c70bc13b
> + * (included in v4.1) we would set the MI_RESTORE_INHIBIT bit when submitting
> + * batch buffers for the default context used by the DDX, which meant that 
> any
> + * context state changed by the GL would leak into the DDX, the assumption
> + * being that the DDX would initialize any state it cares about manually.  
> The
> + * DDX is however not careful enough to program an L3 configuration
> + * explicitly, and it makes assumptions about it (URB size) which won't hold
> + * and cause it to misrender if we let our L3 set-up to leak into the DDX.
> + *
> + * Since v4.1 of the Linux kernel the default context is saved and restored
> + * normally, so it's far less likely for our L3 programming to interfere with
> + * other contexts -- In fact restoring the default L3 configuration at the 
> end
> + * of the batch will be redundant most of the time.  A kind of state leak is
> + * still possible though if the context making assumptions about L3 state is
> + * created immediately after our context was active (e.g. without the DDX
> + * default context being scheduled in between) because at present the DRM
> + * doesn't fully initialize the contents of newly created contexts and 
> instead
> + * sets the MI_RESTORE_INHIBIT flag causing it to inherit the state from the
> + * last active context.
> + *
> + * It's possible to realize such a scenario if, say, an X server (or a GL
> + * application using an outdated non-L3-aware Mesa version) is started while
> + * another GL application is running and happens to have modified the L3
> + * configuration, or if no X server is running at all and a GL application
> + * using a non-L3-aware Mesa version is started after another GL application
> + * ran and modified the L3 configuration -- The latter situation can actually
> + * be reproduced easily on IVB in our CI system.
> + */
> +void
> +gen7_restore_default_l3_config(struct brw_context *brw)
> +{
> +   const struct brw_l3_weights w =
> +  get_default_l3_weights(brw->intelScreen->devinfo, false, false);
> +   const struct brw_l3_config *const cfg =
> +  get_l3_config(brw->intelScreen->devinfo, w);
> +
> +   if (cfg != brw->l3.config && brw->can_do_pipelined_register_writes) {
> +  setup_l3_config(brw, cfg);
> +  update_urb_size(brw, cfg);
> +  brw->l3.config = cfg;
> +   }
> +}
> diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c 
> b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> index 0363bd3..f778074 100644
> --- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> +++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> @@ -208,6 +208,13 @@ brw_finish_batch(struct brw_context *brw)
> brw_emit_query_end(brw);
>  
> if (brw->batch.ring == RENDER_RING) {
> +  /* Work around L3 state

Re: [Mesa-dev] [PATCH v2 24/42] nir: Translate glsl shared var load intrinsic to nir intrinsic

[Iago Toral]

On Wed, 2015-11-25 at 10:17 -0500, Connor Abbott wrote:
> On Wed, Nov 25, 2015 at 4:48 AM, Iago Toral  wrote:
> > On Tue, 2015-11-17 at 21:54 -0800, Jordan Justen wrote:
> >> Signed-off-by: Jordan Justen 
> >> ---
> >>  src/glsl/nir/glsl_to_nir.cpp  | 29 +
> >>  src/glsl/nir/nir_intrinsics.h |  1 +
> >>  2 files changed, 30 insertions(+)
> >>
> >> diff --git a/src/glsl/nir/glsl_to_nir.cpp b/src/glsl/nir/glsl_to_nir.cpp
> >> index 6d24341..a59d09c 100644
> >> --- a/src/glsl/nir/glsl_to_nir.cpp
> >> +++ b/src/glsl/nir/glsl_to_nir.cpp
> >> @@ -727,6 +727,8 @@ nir_visitor::visit(ir_call *ir)
> >>   op = nir_intrinsic_memory_barrier_image;
> >>} else if (strcmp(ir->callee_name(), 
> >> "__intrinsic_memory_barrier_shared") == 0) {
> >>   op = nir_intrinsic_memory_barrier_shared;
> >> +  } else if (strcmp(ir->callee_name(), "__intrinsic_load_shared") == 
> >> 0) {
> >> + op = nir_intrinsic_load_shared;
> >>} else {
> >>   unreachable("not reached");
> >>}
> >> @@ -974,6 +976,33 @@ nir_visitor::visit(ir_call *ir)
> >>   nir_builder_instr_insert(&b, &instr->instr);
> >>   break;
> >>}
> >> +  case nir_intrinsic_load_shared: {
> >> + exec_node *param = ir->actual_parameters.get_head();
> >> + ir_rvalue *offset = ((ir_instruction *)param)->as_rvalue();
> >> +
> >> + /* Check if we need the indirect version */
> >> + ir_constant *const_offset = offset->as_constant();
> >> + if (!const_offset) {
> >> +op = nir_intrinsic_load_shared_indirect;
> >> +ralloc_free(instr);
> >> +instr = nir_intrinsic_instr_create(shader, op);
> >> +instr->src[0] = nir_src_for_ssa(evaluate_rvalue(offset));
> >> +instr->const_index[0] = 0;
> >> +dest = &instr->dest;
> >> + } else {
> >> +instr->const_index[0] = const_offset->value.u[0];
> >> + }
> >> +
> >> + const glsl_type *type = ir->return_deref->var->type;
> >> + instr->num_components = type->vector_elements;
> >> +
> >> + /* Setup destination register */
> >> + nir_ssa_dest_init(&instr->instr, &instr->dest,
> >> +   type->vector_elements, NULL);
> >> +
> >> + nir_builder_instr_insert(&b, &instr->instr);
> >
> > In ubos and ssbo loads we need to fixup bool types, it looks like you
> > would need to do the same here, right?
> 
> I don't think that's necessary, because shared variables are never
> read/written on the CPU, so we just always use ~0/0 for true/false and
> never have to convert to what the API expects.

Ah yes, that makes sense.

Reviewed-by: Iago Toral Quiroga 

> >
> >> + break;
> >> +  }
> >>default:
> >>   unreachable("not reached");
> >>}
> >> diff --git a/src/glsl/nir/nir_intrinsics.h b/src/glsl/nir/nir_intrinsics.h
> >> index b8d7d6c..de15128 100644
> >> --- a/src/glsl/nir/nir_intrinsics.h
> >> +++ b/src/glsl/nir/nir_intrinsics.h
> >> @@ -257,6 +257,7 @@ LOAD(per_vertex_input, 1, 1, 
> >> NIR_INTRINSIC_CAN_ELIMINATE | NIR_INTRINSIC_CAN_REO
> >>  LOAD(ssbo, 1, 1, NIR_INTRINSIC_CAN_ELIMINATE)
> >>  LOAD(output, 0, 1, NIR_INTRINSIC_CAN_ELIMINATE)
> >>  LOAD(per_vertex_output, 1, 1, NIR_INTRINSIC_CAN_ELIMINATE)
> >> +LOAD(shared, 0, 1, NIR_INTRINSIC_CAN_ELIMINATE)
> >>
> >>  /*
> >>   * Stores work the same way as loads, except now the first register input 
> >> is
> >
> >
> > ___
> > 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 93112] GLX: could not load software renderer

[bugzilla-daemon]

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

poma  changed:

   What|Removed |Added

   See Also||https://bugzilla.redhat.com
   ||/show_bug.cgi?id=1285666

-- 
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 93112] GLX: could not load software renderer

[bugzilla-daemon]

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

poma  changed:

   What|Removed |Added

   See Also||https://bugzilla.xfce.org/s
   ||how_bug.cgi?id=12331

-- 
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 93112] GLX: could not load software renderer

[bugzilla-daemon]

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

Bug ID: 93112
   Summary: GLX: could not load software renderer
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: GLX
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: pomidorabelis...@gmail.com
QA Contact: mesa-dev@lists.freedesktop.org

Created attachment 120128
  --> https://bugs.freedesktop.org/attachment.cgi?id=120128&action=edit
Mesa 11.2.0-devel (git-86fc97d) GLX: could not load software renderer

Mesa 11.2.0-devel (git-86fc97d)

Xorg:
(EE) AIGLX error: Calling driver entry point failed
(EE) GLX: could not load software renderer
(II) GLX: no usable GL providers found for screen 0

glxinfo:
Error: couldn't find RGB GLX visual or fbconfig

xfwm4 --compositor=on:
Segmentation fault (core dumped)

GLX compositor: Program terminated with signal SIGSEGV, Segmentation fault.
https://bugzilla.xfce.org/show_bug.cgi?id=12331

Information for package mesa
http://koji.fedoraproject.org/koji/packageinfo?packageID=184

-- 
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 v2] mesa: remove ARB_geometry_shader4

[Lofstedt, Marta]

> -Original Message-
> From: mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org] On
> Behalf Of Ilia Mirkin
> Sent: Wednesday, November 25, 2015 8:03 PM
> To: Marta Lofstedt
> Cc: mesa-dev@lists.freedesktop.org; Kenneth Graunke; Emil Velikov
> Subject: Re: [Mesa-dev] [PATCH v2] mesa: remove ARB_geometry_shader4
> 
> At first I thought it was a mistake to remove things from enum_strings.cpp,
> but it looks like the ARB/EXT extensions actually had different enum values
> than core GL 3.2 for the same things.
> 
> I've looked over all of this with some care and it looks right. Will need a 
> bunch
> of changes to support OES_geometry_shader, but that's for another change.

I hope to get some time to rebase my old oes_geometry_shader patches, this week.

Thanks again for the review, Ilia and Kenneth.

BR,
Marta
> This one is
> 
> Reviewed-by: Ilia Mirkin 
> 
> On Wed, Nov 25, 2015 at 6:16 AM, Marta Lofstedt
>  wrote:
> > From: Marta Lofstedt 
> >
> > No drivers currently implement ARB_geometry_shader4, nor are there any
> > plans to implement it.  We only support the version of geometry
> > shaders that was incorporated into OpenGL 3.2 / GLSL 1.50.
> >
> > Signed-off-by: Marta Lofstedt 
> > ---
> >  src/mapi/glapi/gen/ARB_geometry_shader4.xml | 57 -
> 
> >  src/mapi/glapi/gen/Makefile.am  |  1 -
> >  src/mapi/glapi/gen/gl_API.xml   |  2 +-
> >  src/mesa/main/api_validate.c|  2 +-
> >  src/mesa/main/config.h  |  2 +-
> >  src/mesa/main/context.h |  3 +-
> >  src/mesa/main/dlist.c   | 55 
> > 
> >  src/mesa/main/get.c |  7 
> >  src/mesa/main/get_hash_params.py| 12 ++
> >  src/mesa/main/mtypes.h  |  3 +-
> >  src/mesa/main/tests/enum_strings.cpp|  6 ---
> >  11 files changed, 9 insertions(+), 141 deletions(-)  delete mode
> > 100644 src/mapi/glapi/gen/ARB_geometry_shader4.xml
> >
> > diff --git a/src/mapi/glapi/gen/ARB_geometry_shader4.xml
> > b/src/mapi/glapi/gen/ARB_geometry_shader4.xml
> > deleted file mode 100644
> > index 280e7a0..000
> > --- a/src/mapi/glapi/gen/ARB_geometry_shader4.xml
> > +++ /dev/null
> > @@ -1,57 +0,0 @@
> > -
> > -
> > -
> > -
> > -
> > -
> > -
> > -
> > -
> > -
> > - value="0x8DDA"/>
> > -
> > -
> > - value="0x8C29"/>
> > - value="0x8DDD"/>
> > - value="0x8DDE"/>
> > - value="0x8B4B"/>
> > - value="0x8DDF"/>
> > - value="0x8DE0"/>
> > - name="MAX_GEOMETRY_TOTAL_OUTPUT_COMPONENTS_ARB"
> value="0x8DE1"/>
> > -
> > -
> > -
> > -
> > - value="0x8DA8"/>
> > - value="0x8DA9"/>
> > - value="0x8DA7"/>
> > - value="0x8CD4"/>
> > -
> > -
> > -
> > -
> > -
> > -
> > - alias="FramebufferTexture">
> > -
> > -
> > -
> > -
> > -
> > - alias="FramebufferTextureLayer">
> > -
> > -
> > -
> > -
> > -
> > -
> > -
> > -
> > -
> > -
> > -
> > -
> > -
> > -
> > -
> > -
> > diff --git a/src/mapi/glapi/gen/Makefile.am
> > b/src/mapi/glapi/gen/Makefile.am index a5a26a6..40b0e65 100644
> > --- a/src/mapi/glapi/gen/Makefile.am
> > +++ b/src/mapi/glapi/gen/Makefile.am
> > @@ -133,7 +133,6 @@ API_XML = \
> > ARB_ES3_compatibility.xml \
> > ARB_framebuffer_no_attachments.xml \
> > ARB_framebuffer_object.xml \
> > -   ARB_geometry_shader4.xml \
> > ARB_get_program_binary.xml \
> > ARB_get_texture_sub_image.xml \
> > ARB_gpu_shader_fp64.xml \
> > diff --git a/src/mapi/glapi/gen/gl_API.xml
> > b/src/mapi/glapi/gen/gl_API.xml index ec83cd4..6243bdd 100644
> > --- a/src/mapi/glapi/gen/gl_API.xml
> > +++ b/src/mapi/glapi/gen/gl_API.xml
> > @@ -7975,7 +7975,7 @@
> >
> >  
> >
> > - > xmlns:xi="http://www.w3.org/2001/XInclude"/>
> > +
> >
> >  
> >
> > diff --git a/src/mesa/main/api_validate.c
> > b/src/mesa/main/api_validate.c index a490189..cbfb6b5 100644
> > --- a/src/mesa/main/api_validate.c
> > +++ b/src/mesa/main/api_validate.c
> > @@ -170,7 +170,7 @@ _mesa_valid_prim_mode(struct gl_context *ctx,
> GLenum mode, const char *name)
> >return GL_FALSE;
> > }
> >
> > -   /* From the ARB_geometry_shader4 spec:
> > +   /* From the OpenGL 4.5 specification, section 11.3.1:
> >  *
> >  * The error INVALID_OPERATION is generated if Begin, or any command
> that
> >  * implicitly calls Begin, is called when a geometry shader is active 
> > and:
> > diff --git a/src/mesa/main/config.h b/src/mesa/main/config.h index
> > f29de5f..2d53e2f 100644
> > --- a/src/mesa/main/config.h
> > +++ b/src/mesa/main/config.h
> > @@ -246,7 +246,7 @@
> >  #define MAX_FEEDBACK_BUFFERS 4
> >  #define MAX_FEEDBACK_ATTRIBS 32
> >
> > -/** For GL_ARB_geometry_shader4 */
> > +/** For geometry sha

Re: [Mesa-dev] [PATCH v2 12/42] i965: Add debug flag to print out the new L3 state during transitions.

[Samuel Iglesias Gonsálvez]

Reviewed-by: Samuel Iglesias Gonsálvez 

On 18/11/15 06:54, Jordan Justen wrote:
> From: Francisco Jerez 
> 
> ---
>  src/mesa/drivers/dri/i965/gen7_l3_state.c | 17 +
>  src/mesa/drivers/dri/i965/intel_debug.c   |  1 +
>  src/mesa/drivers/dri/i965/intel_debug.h   |  1 +
>  3 files changed, 19 insertions(+)
> 
> diff --git a/src/mesa/drivers/dri/i965/gen7_l3_state.c 
> b/src/mesa/drivers/dri/i965/gen7_l3_state.c
> index 58eb07b..45bad02 100644
> --- a/src/mesa/drivers/dri/i965/gen7_l3_state.c
> +++ b/src/mesa/drivers/dri/i965/gen7_l3_state.c
> @@ -435,6 +435,18 @@ update_urb_size(struct brw_context *brw, const struct 
> brw_l3_config *cfg)
> }
>  }
>  
> +/**
> + * Print out the specified L3 configuration.
> + */
> +static void
> +dump_l3_config(const struct brw_l3_config *cfg)
> +{
> +   fprintf(stderr, "SLM=%d URB=%d ALL=%d DC=%d RO=%d IS=%d C=%d T=%d\n",
> +   cfg->n[L3P_SLM], cfg->n[L3P_URB], cfg->n[L3P_ALL],
> +   cfg->n[L3P_DC], cfg->n[L3P_RO],
> +   cfg->n[L3P_IS], cfg->n[L3P_C], cfg->n[L3P_T]);
> +}
> +
>  static void
>  emit_l3_state(struct brw_context *brw)
>  {
> @@ -464,6 +476,11 @@ emit_l3_state(struct brw_context *brw)
>setup_l3_config(brw, cfg);
>update_urb_size(brw, cfg);
>brw->l3.config = cfg;
> +
> +  if (unlikely(INTEL_DEBUG & DEBUG_L3)) {
> + fprintf(stderr, "L3 config transition (%f > %f): ", dw, 
> dw_threshold);
> + dump_l3_config(cfg);
> +  }
> }
>  }
>  
> diff --git a/src/mesa/drivers/dri/i965/intel_debug.c 
> b/src/mesa/drivers/dri/i965/intel_debug.c
> index f53c4ab..3fe941c 100644
> --- a/src/mesa/drivers/dri/i965/intel_debug.c
> +++ b/src/mesa/drivers/dri/i965/intel_debug.c
> @@ -79,6 +79,7 @@ static const struct debug_control debug_control[] = {
> { "tcs", DEBUG_TCS },
> { "ds",  DEBUG_TES },
> { "tes", DEBUG_TES },
> +   { "l3",  DEBUG_L3 },
> { NULL,0 }
>  };
>  
> diff --git a/src/mesa/drivers/dri/i965/intel_debug.h 
> b/src/mesa/drivers/dri/i965/intel_debug.h
> index 9c6030a..5d3f97a 100644
> --- a/src/mesa/drivers/dri/i965/intel_debug.h
> +++ b/src/mesa/drivers/dri/i965/intel_debug.h
> @@ -71,6 +71,7 @@ extern uint64_t INTEL_DEBUG;
>  #define DEBUG_NO_COMPACTION   (1ull << 35)
>  #define DEBUG_TCS (1ull << 36)
>  #define DEBUG_TES (1ull << 37)
> +#define DEBUG_L3  (1ull << 38)
>  
>  #ifdef HAVE_ANDROID_PLATFORM
>  #define LOG_TAG "INTEL-MESA"
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2 14/42] i965: Hook up L3 partitioning state atom.

[Samuel Iglesias Gonsálvez]

Reviewed-by: Samuel Iglesias Gonsálvez 

On 18/11/15 06:54, Jordan Justen wrote:
> From: Francisco Jerez 
> 
> ---
>  src/mesa/drivers/dri/i965/brw_context.h  | 4 ++--
>  src/mesa/drivers/dri/i965/brw_state_upload.c | 4 
>  2 files changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/src/mesa/drivers/dri/i965/brw_context.h 
> b/src/mesa/drivers/dri/i965/brw_context.h
> index cc011f7..a162079 100644
> --- a/src/mesa/drivers/dri/i965/brw_context.h
> +++ b/src/mesa/drivers/dri/i965/brw_context.h
> @@ -1178,8 +1178,8 @@ struct brw_context
> } perfmon;
>  
> int num_atoms[BRW_NUM_PIPELINES];
> -   const struct brw_tracked_state render_atoms[60];
> -   const struct brw_tracked_state compute_atoms[9];
> +   const struct brw_tracked_state render_atoms[61];
> +   const struct brw_tracked_state compute_atoms[10];
>  
> /* If (INTEL_DEBUG & DEBUG_BATCH) */
> struct {
> diff --git a/src/mesa/drivers/dri/i965/brw_state_upload.c 
> b/src/mesa/drivers/dri/i965/brw_state_upload.c
> index aab5c91..cd1fbee 100644
> --- a/src/mesa/drivers/dri/i965/brw_state_upload.c
> +++ b/src/mesa/drivers/dri/i965/brw_state_upload.c
> @@ -186,6 +186,7 @@ static const struct brw_tracked_state 
> *gen7_render_atoms[] =
> &brw_cc_vp,
> &gen7_sf_clip_viewport,
>  
> +   &gen7_l3_state,
> &gen7_push_constant_space,
> &gen7_urb,
> &gen6_blend_state,/* must do before cc unit */
> @@ -257,6 +258,7 @@ static const struct brw_tracked_state 
> *gen7_render_atoms[] =
>  static const struct brw_tracked_state *gen7_compute_atoms[] =
>  {
> &brw_state_base_address,
> +   &gen7_l3_state,
> &brw_cs_image_surfaces,
> &gen7_cs_push_constants,
> &brw_cs_pull_constants,
> @@ -275,6 +277,7 @@ static const struct brw_tracked_state 
> *gen8_render_atoms[] =
> &brw_cc_vp,
> &gen8_sf_clip_viewport,
>  
> +   &gen7_l3_state,
> &gen7_push_constant_space,
> &gen7_urb,
> &gen8_blend_state,
> @@ -352,6 +355,7 @@ static const struct brw_tracked_state 
> *gen8_render_atoms[] =
>  static const struct brw_tracked_state *gen8_compute_atoms[] =
>  {
> &gen8_state_base_address,
> +   &gen7_l3_state,
> &brw_cs_image_surfaces,
> &gen7_cs_push_constants,
> &brw_cs_pull_constants,
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] tinderbox regression

[Dave Airlie]

http://tinderbox.x.org/builds/2015-11-26-0001/logs/mesa-mesa/#build

just went past me.

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

[Mesa-dev] [PATCH 02.5/11] i965/vec4: Stop pretending to support indirect output stores

[Jason Ekstrand]

Since we're using nir_lower_outputs_to_temporaries to shadow all our
outputs, it's impossible to actually get an indirect store.  The code we
had to "handle" this was pretty bogus as it created a register with a
reladdr and then stuffed it in a fixed varying slot without so much as a
MOV.  Not only does this not do the MOV, it also puts the indirect on the
wrong side of the transaction.  Let's just delete the broken dead code.
---

This was squashed into patch 3 but probably deserves its own patch.

 src/mesa/drivers/dri/i965/brw_vec4_nir.cpp | 12 +++-
 1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_vec4_nir.cpp 
b/src/mesa/drivers/dri/i965/brw_vec4_nir.cpp
index 96787db..8e06d6b 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_nir.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_nir.cpp
@@ -393,21 +393,15 @@ vec4_visitor::nir_emit_intrinsic(nir_intrinsic_instr 
*instr)
}
 
case nir_intrinsic_store_output_indirect:
-  has_indirect = true;
-  /* fallthrough */
+  unreachable("nir_lower_outputs_to_temporaries should prevent this");
+
case nir_intrinsic_store_output: {
   int varying = instr->const_index[0];
 
   src = get_nir_src(instr->src[0], BRW_REGISTER_TYPE_F,
 instr->num_components);
-  dest = dst_reg(src);
 
-  if (has_indirect) {
- dest.reladdr = new(mem_ctx) src_reg(get_nir_src(instr->src[1],
- BRW_REGISTER_TYPE_D,
- 1));
-  }
-  output_reg[varying] = dest;
+  output_reg[varying] = dst_reg(src);
   break;
}
 
-- 
2.5.0.400.gff86faf

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