Re: [Mesa-dev] [ANNOUNCE] Mesa 18.1.2 release candidate

2018-06-18 Thread Juan A. Suarez Romero
On Fri, 2018-06-15 at 12:47 -0400, Ilia Mirkin wrote:
> On Fri, Jun 15, 2018 at 12:36 PM, Dylan Baker  wrote:
> > I don't even understand why we make these announcements TBH. I have a public
> > 18.1-proposed branch that I push to *every weekday*. Anyone can pull that 
> > branch
> > *anytime* to get the latest version. The only thing the announce email 
> > really
> > serves AFAICT, is to say "the staging/proposed branch has been merged to the
> > release branch". I don't think that's all that interesting TBH.
> 
> "any time" means "no time". The announcement is "speak now or forever
> hold your peace". Gives driver teams a chance to review the list and
> test things out before they go out into a full release. Should they be
> doing this daily/continuously? Probably. But that's not the current
> state.
> 

I agree on this. And I think the reason to wait 48h is to give time enough for
teams to do proper testing, specially when there are many timezones that people
get the pre-announcement several hours later.


But, I also think that the pre-announcement is too much verbose. It includes lot
of information that can be easily get from the git branch itself. The only thing
I would probably keep is about trivial conflicts, sending an explicit email to
the authors to say "I [slightly] changed your commit; please, take a look just
in case", and the rejected patch list, also mailing the authors.


J.A.

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


Re: [Mesa-dev] [PATCH] mesa: add ff fragment shader support for geom and tess shaders

2018-06-18 Thread Gustaw Smolarczyk
2018-06-18 4:39 GMT+02:00 Timothy Arceri :

> This is required for compatibility profile support.

---
>  src/mesa/main/ff_fragment_shader.cpp | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/src/mesa/main/ff_fragment_shader.cpp
> b/src/mesa/main/ff_fragment_shader.cpp
> index a698931d99e..935a21624af 100644
> --- a/src/mesa/main/ff_fragment_shader.cpp
> +++ b/src/mesa/main/ff_fragment_shader.cpp
> @@ -229,7 +229,11 @@ static GLbitfield filter_fp_input_mask( GLbitfield
> fp_inputs,
>  * since vertex shader state validation comes after fragment state
>  * validation (see additional comments in state.c).
>  */
> -   if (vertexShader)
> +   if (ctx->_Shader->CurrentProgram[MESA_SHADER_GEOMETRY] != NULL)
> +  vprog = ctx->_Shader->CurrentProgram[MESA_SHADER_GEOMETRY];
> +   else if (ctx->_Shader->CurrentProgram[MESA_SHADER_TESS_EVAL] != NULL)
> +  vprog = ctx->_Shader->CurrentProgram[MESA_SHADER_TESS_EVAL];
> +   else if (vertexShader)
>


Shouldn't you also update the if condition on line 178? Otherwise, you
won't reach the if tree you change when the vertex shader is missing
(unless that was intended - I am not really familiar with how fixed
function shaders work alongside new features).

You could also move or update the comment that is just above your change.

Regards,
Gustaw Smolarczyk


>vprog = ctx->_Shader->CurrentProgram[MESA_SHADER_VERTEX];
> else
>vprog = ctx->VertexProgram.Current;
> --
> 2.17.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [Bug 106915] [GLSL] Unused arrays declared without a size should be handled like arrays of size 1.

2018-06-18 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=106915

--- Comment #7 from Neil Roberts  ---
The nvidia proprietary driver fails to link that test with the following error
message:

error: different buffer variables (named a.a[0] and a.s[0]) sharing the same
offset within a storage block (named a) between shaders

I wonder if that means it has decided a.s has zero size and therefore they
occupy the same offset. Either way it looks like they aren’t following the spec
either.

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


[Mesa-dev] [Bug 106595] [RADV] Rendering distortions only when MSAA is enabled

2018-06-18 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=106595

--- Comment #15 from zefkerri...@gmail.com ---
(In reply to Samuel Pitoiset from comment #11)
> You have to grab and build renderdoc from
> https://github.com/baldurk/renderdoc
> 
> Then, you can do "export ENABLE_VULKAN_RENDERDOC_CAPTURE=1", start the game
> and uses F12 for capturing a trace.

In my previous comment I gave you the rdc trace files.
Did you need any more logs or any other help from me?
Regards.

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


Re: [Mesa-dev] [PATCH] mesa: add ff fragment shader support for geom and tess shaders

2018-06-18 Thread Iago Toral
On Mon, 2018-06-18 at 09:43 +0200, Gustaw Smolarczyk wrote:
> 2018-06-18 4:39 GMT+02:00 Timothy Arceri :
> > This is required for compatibility profile support. 
> > 
> > ---
> > 
> >  src/mesa/main/ff_fragment_shader.cpp | 6 +-
> > 
> >  1 file changed, 5 insertions(+), 1 deletion(-)
> > 
> > 
> > 
> > diff --git a/src/mesa/main/ff_fragment_shader.cpp
> > b/src/mesa/main/ff_fragment_shader.cpp
> > 
> > index a698931d99e..935a21624af 100644
> > 
> > --- a/src/mesa/main/ff_fragment_shader.cpp
> > 
> > +++ b/src/mesa/main/ff_fragment_shader.cpp
> > 
> > @@ -229,7 +229,11 @@ static GLbitfield filter_fp_input_mask(
> > GLbitfield fp_inputs,
> > 
> >  * since vertex shader state validation comes after fragment
> > state
> > 
> >  * validation (see additional comments in state.c).
> > 
> >  */
> > 
> > -   if (vertexShader)
> > 
> > +   if (ctx->_Shader->CurrentProgram[MESA_SHADER_GEOMETRY] != NULL)
> > 
> > +  vprog = ctx->_Shader->CurrentProgram[MESA_SHADER_GEOMETRY];
> > 
> > +   else if (ctx->_Shader->CurrentProgram[MESA_SHADER_TESS_EVAL] !=
> > NULL)
> > 
> > +  vprog = ctx->_Shader->CurrentProgram[MESA_SHADER_TESS_EVAL];
> > 
> > +   else if (vertexShader)
> 
> 
> 
> Shouldn't you also update the if condition on line 178? Otherwise,
> you won't reach the if tree you change when the vertex shader is
> missing (unless that was intended - I am not really familiar with how
> fixed function shaders work alongside new features).

You don't have Tesselation / Geometry with fixed function GL, so I
think this should be fine.
Reviewed-by: Iago Toral Quiroga 
> You could also move or update the comment that is just above your
> change.
> 
> 
> Regards,Gustaw Smolarczyk 
> >vprog = ctx->_Shader->CurrentProgram[MESA_SHADER_VERTEX];
> > 
> > else
> > 
> >vprog = ctx->VertexProgram.Current;
> > 
> > -- 
> > 
> > 2.17.1
> > 
> > 
> > 
> > ___
> > 
> > mesa-dev mailing list
> > 
> > mesa-dev@lists.freedesktop.org
> > 
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> > 
> 
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] mesa: add ff fragment shader support for geom and tess shaders

2018-06-18 Thread Gustaw Smolarczyk
2018-06-18 10:39 GMT+02:00 Iago Toral :

> On Mon, 2018-06-18 at 09:43 +0200, Gustaw Smolarczyk wrote:
>
> 2018-06-18 4:39 GMT+02:00 Timothy Arceri :
>
> This is required for compatibility profile support.
> ---
>  src/mesa/main/ff_fragment_shader.cpp | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/src/mesa/main/ff_fragment_shader.cpp
> b/src/mesa/main/ff_fragment_shader.cpp
> index a698931d99e..935a21624af 100644
> --- a/src/mesa/main/ff_fragment_shader.cpp
> +++ b/src/mesa/main/ff_fragment_shader.cpp
> @@ -229,7 +229,11 @@ static GLbitfield filter_fp_input_mask( GLbitfield
> fp_inputs,
>  * since vertex shader state validation comes after fragment state
>  * validation (see additional comments in state.c).
>  */
> -   if (vertexShader)
> +   if (ctx->_Shader->CurrentProgram[MESA_SHADER_GEOMETRY] != NULL)
> +  vprog = ctx->_Shader->CurrentProgram[MESA_SHADER_GEOMETRY];
> +   else if (ctx->_Shader->CurrentProgram[MESA_SHADER_TESS_EVAL] != NULL)
> +  vprog = ctx->_Shader->CurrentProgram[MESA_SHADER_TESS_EVAL];
> +   else if (vertexShader)
>
>
>
> Shouldn't you also update the if condition on line 178? Otherwise, you
> won't reach the if tree you change when the vertex shader is missing
> (unless that was intended - I am not really familiar with how fixed
> function shaders work alongside new features).
>
>
> You don't have Tesselation / Geometry with fixed function GL, so I think
> this should be fine.
>

Well, this whole file implements fixed function fragment shader, so it will
only be reached when the fragment shader is missing. Unless you meant
that tessellation/geometry
shaders cannot be combined with fixed function vertex shader but fixed
function fragment shader is fine.

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


Re: [Mesa-dev] [PATCH] radv: Use less conservative approximation for context rolls.

2018-06-18 Thread Samuel Pitoiset

Reviewed-by: Samuel Pitoiset 

On 06/17/2018 03:40 AM, Bas Nieuwenhuizen wrote:

Drops the number of time we set the scissor by 4x for F1 2017,
which results in a consistent performance improvement of about 4%.
---
  src/amd/vulkan/radv_cmd_buffer.c | 9 ++---
  1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index a07717c7196..ccaab63b84b 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -3299,10 +3299,13 @@ static bool radv_need_late_scissor_emission(struct 
radv_cmd_buffer *cmd_buffer,
if (!cmd_buffer->device->physical_device->has_scissor_bug)
return false;
  
+	uint32_t used_states = cmd_buffer->state.pipeline->graphics.needed_dynamic_state | ~RADV_CMD_DIRTY_DYNAMIC_ALL;

+
+   /* Index & Vertex buffer don't change context regs, and pipeline is 
handled later. */
+   used_states &= ~(RADV_CMD_DIRTY_INDEX_BUFFER | 
RADV_CMD_DIRTY_VERTEX_BUFFER | RADV_CMD_DIRTY_PIPELINE);
+
/* Assume all state changes except  these two can imply context rolls. 
*/
-   if (cmd_buffer->state.dirty & ~(RADV_CMD_DIRTY_INDEX_BUFFER |
-   RADV_CMD_DIRTY_VERTEX_BUFFER |
-   RADV_CMD_DIRTY_PIPELINE))
+   if (cmd_buffer->state.dirty & used_states)
return true;
  
  	if (cmd_buffer->state.emitted_pipeline != cmd_buffer->state.pipeline)



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


[Mesa-dev] [Bug 106595] [RADV] Rendering distortions only when MSAA is enabled

2018-06-18 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=106595

--- Comment #16 from Samuel Pitoiset  ---
Unfortunately, I can't replay the trace because it's not the same hardware.

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


Re: [Mesa-dev] [PATCH 0/8] i965: Don't recycle BOs until they are idle

2018-06-18 Thread Michel Dänzer
On 2018-06-16 08:23 AM, Jason Ekstrand wrote:
> On Fri, Jun 15, 2018 at 4:44 PM, Eric Anholt  wrote:
> 
>> Michel Dänzer  writes:
>>
>>> On 2018-06-15 05:25 PM, Jason Ekstrand wrote:
 On June 15, 2018 01:14:24 Michel Dänzer  wrote:
> On 2018-06-15 07:31 AM, Jason Ekstrand wrote:
>>
>> I did some testing and x11perf -copywinwin500 is... exactly the same
>> with
>> or without my patches.  If anything they might improve it by just a
>> hair.
>
> Possible explanations I can think of:
>
> 1. Your glamor still has its own FBO cache. Which version of xserver
>> are
> you testing with?
>
 1.19 I think
>>>
>>> Okay, that doesn't have the glamor FBO cache anymore.
>>>
>>>
> 2. The i965 driver cache isn't hit even before these changes.

 It's definitely getting hit in both cases, it just may require a
 slightly larger cache of we aren't recycling BOs until they're idle.
>>>
>>> It might be more than just slightly, -copywinwin500 can queue many
>>> overlapping copies between flushes. Can you compare the maximum total
>>> cache size with and without this series?
>>
>> I suspect it'll be only about a factor of
>> how-many-batchbuffers-before-throttling difference -- while the
>> batchbuffer still references the BO, the bufmgr wouldn't see the buffer
>> to reuse it anyway.  I suspect we hit the aperture limit and flush in
>> the copywinwin500 case.
>>
> 
> At Ken's suggestion, I ran some statistics for hits/misses.  I did three
> runs each with master and with my branch:
> 
> Master:
> 
> hits = 455868,
> misses = 388,
> max_bucket_size = 160
> 
> hits = 404358,
> misses = 113,
> max_bucket_size = 34
> 
> hits = 497731,
> misses = 363,
> max_bucket_size = 148
> 
> With patches:
> 
> hits = 493634
> misses = 253,
> max_bucket_size = 85
> 
> hits = 495667,
> misses = 237,
> max_bucket_size = 83
> 
> hits = 454738,
> misses = 358,
> max_bucket_size = 132
> 
> Some of the numbers, as you can see, are rather noisy but the end result is
> about the same: we get at least 1000x as many cache hits as misses when
> running that test.  I don't think the choice to recycle busy BOs is really
> gaining us anything whatsoever.  It is worth noting that I did both of
> those runs in debug builds because I had to use gdb to get the data back
> out of the driver (prints inside the GL driver used by glamor don't work
> too well).  That probably affected things a bit but I doubt the end result
> would have been that much different.
> 
> Which begs the question, why does Michel see such a big difference on
> radeon?

The glamor FBO cache could reuse the temporary FBO even before flushing,
so only one such FBO was ever needed. From what Eric wrote above, it
sounds like the i965 cache can only reuse BOs after a flush, so there's
relatively little difference between reusing busy BOs or not.


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


Re: [Mesa-dev] [PATCH] mesa: add ff fragment shader support for geom and tess shaders

2018-06-18 Thread Iago Toral
On Mon, 2018-06-18 at 10:45 +0200, Gustaw Smolarczyk wrote:
> 2018-06-18 10:39 GMT+02:00 Iago Toral :
> > On Mon, 2018-06-18 at 09:43 +0200, Gustaw Smolarczyk wrote:
> > > 2018-06-18 4:39 GMT+02:00 Timothy Arceri :
> > > > This is required for compatibility profile support. 
> > > > ---
> > > >  src/mesa/main/ff_fragment_shader.cpp | 6 +-
> > > >  1 file changed, 5 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/src/mesa/main/ff_fragment_shader.cpp
> > > > b/src/mesa/main/ff_fragment_shader.cpp
> > > > index a698931d99e..935a21624af 100644
> > > > --- a/src/mesa/main/ff_fragment_shader.cpp
> > > > +++ b/src/mesa/main/ff_fragment_shader.cpp
> > > > @@ -229,7 +229,11 @@ static GLbitfield filter_fp_input_mask(
> > > > GLbitfield fp_inputs,
> > > >  * since vertex shader state validation comes after
> > > > fragment state
> > > >  * validation (see additional comments in state.c).
> > > >  */
> > > > -   if (vertexShader)
> > > > +   if (ctx->_Shader->CurrentProgram[MESA_SHADER_GEOMETRY] !=
> > > > NULL)
> > > > +  vprog = ctx->_Shader-
> > > > >CurrentProgram[MESA_SHADER_GEOMETRY];
> > > > +   else if (ctx->_Shader-
> > > > >CurrentProgram[MESA_SHADER_TESS_EVAL] != NULL)
> > > > +  vprog = ctx->_Shader-
> > > > >CurrentProgram[MESA_SHADER_TESS_EVAL];
> > > > +   else if (vertexShader)
> > > 
> > > 
> > > Shouldn't you also update the if condition on line 178?
> > > Otherwise, you won't reach the if tree you change when the vertex
> > > shader is missing (unless that was intended - I am not really
> > > familiar with how fixed function shaders work alongside new
> > > features).
> > 
> > You don't have Tesselation / Geometry with fixed function GL, so I
> > think this should be fine.
> > 
> 
> Well, this whole file implements fixed function fragment shader, so
> it will only be reached when the fragment shader is missing. Unless
> you meant that tessellation/geometry shaders cannot be combined with
> fixed function vertex shader but fixed function fragment shader is
> fine.

Yes, that is what I was thinking.  The OpenGL 4.5 spec with
compatibility profile states in 'chapter 12: fixed function vertex
processing":

"When programmable vertex processing (see chapter 11) is not being
performed, the fixed-function operations described in this chapter are 
performed instead. Vertices are first transformed as described in section 12.1, 
followed by lighting and coloring described described in section 12.2. The 
resulting transformed vertices are then processed as described in chapter 13."

And then 'Chapter 13: Fixed function vertex post-processing', doesn't
include geometry or tessellation shading, and seems to include the
fixed function stages that start after the geometry stage.

Iago


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


Re: [Mesa-dev] [PATCH] mesa: add ff fragment shader support for geom and tess shaders

2018-06-18 Thread Gustaw Smolarczyk
2018-06-18 11:19 GMT+02:00 Iago Toral :

> On Mon, 2018-06-18 at 10:45 +0200, Gustaw Smolarczyk wrote:
> > 2018-06-18 10:39 GMT+02:00 Iago Toral :
> > > On Mon, 2018-06-18 at 09:43 +0200, Gustaw Smolarczyk wrote:
> > > > 2018-06-18 4:39 GMT+02:00 Timothy Arceri :
> > > > > This is required for compatibility profile support.
> > > > > ---
> > > > >  src/mesa/main/ff_fragment_shader.cpp | 6 +-
> > > > >  1 file changed, 5 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/src/mesa/main/ff_fragment_shader.cpp
> > > > > b/src/mesa/main/ff_fragment_shader.cpp
> > > > > index a698931d99e..935a21624af 100644
> > > > > --- a/src/mesa/main/ff_fragment_shader.cpp
> > > > > +++ b/src/mesa/main/ff_fragment_shader.cpp
> > > > > @@ -229,7 +229,11 @@ static GLbitfield filter_fp_input_mask(
> > > > > GLbitfield fp_inputs,
> > > > >  * since vertex shader state validation comes after
> > > > > fragment state
> > > > >  * validation (see additional comments in state.c).
> > > > >  */
> > > > > -   if (vertexShader)
> > > > > +   if (ctx->_Shader->CurrentProgram[MESA_SHADER_GEOMETRY] !=
> > > > > NULL)
> > > > > +  vprog = ctx->_Shader-
> > > > > >CurrentProgram[MESA_SHADER_GEOMETRY];
> > > > > +   else if (ctx->_Shader-
> > > > > >CurrentProgram[MESA_SHADER_TESS_EVAL] != NULL)
> > > > > +  vprog = ctx->_Shader-
> > > > > >CurrentProgram[MESA_SHADER_TESS_EVAL];
> > > > > +   else if (vertexShader)
> > > >
> > > >
> > > > Shouldn't you also update the if condition on line 178?
> > > > Otherwise, you won't reach the if tree you change when the vertex
> > > > shader is missing (unless that was intended - I am not really
> > > > familiar with how fixed function shaders work alongside new
> > > > features).
> > >
> > > You don't have Tesselation / Geometry with fixed function GL, so I
> > > think this should be fine.
> > >
> >
> > Well, this whole file implements fixed function fragment shader, so
> > it will only be reached when the fragment shader is missing. Unless
> > you meant that tessellation/geometry shaders cannot be combined with
> > fixed function vertex shader but fixed function fragment shader is
> > fine.
>
> Yes, that is what I was thinking.  The OpenGL 4.5 spec with
> compatibility profile states in 'chapter 12: fixed function vertex
> processing":
>
> "When programmable vertex processing (see chapter 11) is not being
> performed, the fixed-function operations described in this chapter are
> performed instead. Vertices are first transformed as described in section
> 12.1, followed by lighting and coloring described described in section
> 12.2. The resulting transformed vertices are then processed as described in
> chapter 13."
>
> And then 'Chapter 13: Fixed function vertex post-processing', doesn't
> include geometry or tessellation shading, and seems to include the
> fixed function stages that start after the geometry stage.
>
> Iago
>

That makes sense then, thanks! Though it might be a good idea to add/update
the comment so that there are less confused people in the future.

Regards,
Gustaw Smolarczyk


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


Re: [Mesa-dev] [PATCH] mesa: add ff fragment shader support for geom and tess shaders

2018-06-18 Thread Timothy Arceri



On 18/06/18 18:45, Gustaw Smolarczyk wrote:
2018-06-18 10:39 GMT+02:00 Iago Toral >:


On Mon, 2018-06-18 at 09:43 +0200, Gustaw Smolarczyk wrote:

2018-06-18 4:39 GMT+02:00 Timothy Arceri mailto:tarc...@itsqueeze.com>>:

This is required for compatibility profile support.
---
 src/mesa/main/ff_fragment_shader.cpp | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/src/mesa/main/ff_fragment_shader.cpp
b/src/mesa/main/ff_fragment_shader.cpp
index a698931d99e..935a21624af 100644
--- a/src/mesa/main/ff_fragment_shader.cpp
+++ b/src/mesa/main/ff_fragment_shader.cpp
@@ -229,7 +229,11 @@ static GLbitfield filter_fp_input_mask(
GLbitfield fp_inputs,
     * since vertex shader state validation comes after fragment
state
     * validation (see additional comments in state.c).
     */
-   if (vertexShader)
+   if (ctx->_Shader->CurrentProgram[MESA_SHADER_GEOMETRY] != NULL)
+      vprog = ctx->_Shader->CurrentProgram[MESA_SHADER_GEOMETRY];
+   else if (ctx->_Shader->CurrentProgram[MESA_SHADER_TESS_EVAL]
!= NULL)
+      vprog = ctx->_Shader->CurrentProgram[MESA_SHADER_TESS_EVAL];
+   else if (vertexShader)



Shouldn't you also update the if condition on line 178? Otherwise,
you won't reach the if tree you change when the vertex shader is
missing (unless that was intended - I am not really familiar with
how fixed function shaders work alongside new features).


You don't have Tesselation / Geometry with fixed function GL, so I
think this should be fine.


Well, this whole file implements fixed function fragment shader, so it 
will only be reached when the fragment shader is missing. Unless you 
meant that tessellation/geometry shaders cannot be combined with fixed 
function vertex shader but fixed function fragment shader is fine.


You can only use a ff vertex shader with SSO (otherwise a geom/tess 
shader must be linked with a vertex shader). The combination of SSO with 
ff vertex, geom or tess and ff fragment shaders is highly unlikely but 
we do have a task for it on our TODO list. For now I'm happy to leave 
this change as is because any such use needs further testing/fixes to 
work correctly. I've discussed this with Marek and we think its ok to 
enable GL 3.2-3.3 first and fix these theoretically possible but low 
importance use cases as we progress further with compat profile support.


As for the comment I left it as is because its talking about GLSL vertex 
shaders vs ARB asm vertex programs. In that context its still a valid 
comment, there is no need to add anything about the other stages as the 
ordering there is obvious.




Regards,
Gustaw Smolarczyk


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


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


Re: [Mesa-dev] [PATCH] anv: Use a single global API patch version

2018-06-18 Thread Lionel Landwerlin
I was wondering whether we should pick up the patch version from the 
registry.

Anyway :

Reviewed-by: Lionel Landwerlin 

On 18/06/18 00:29, Jason Ekstrand wrote:

The Vulkan API has only one patch version shared among all of the
major.minor versions.  We should also advertise the same patch version
regardless of major.minor.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106941
---
  src/intel/vulkan/anv_extensions.py | 17 ++---
  src/intel/vulkan/anv_extensions_gen.py |  2 +-
  2 files changed, 11 insertions(+), 8 deletions(-)

diff --git a/src/intel/vulkan/anv_extensions.py 
b/src/intel/vulkan/anv_extensions.py
index 8160864685f..18851c0ff90 100644
--- a/src/intel/vulkan/anv_extensions.py
+++ b/src/intel/vulkan/anv_extensions.py
@@ -44,20 +44,22 @@ class Extension:
  self.enable = _bool_to_c_expr(enable)
  
  class ApiVersion:

-def __init__(self, max_patch_version, enable):
-self.max_patch_version = max_patch_version
+def __init__(self, version, enable):
+self.version = version
  self.enable = _bool_to_c_expr(enable)
  
+API_PATCH_VERSION = 76

+
  # Supported API versions.  Each one is the maximum patch version for the given
  # version.  Version come in increasing order and each version is available if
  # it's provided "enable" condition is true and all previous versions are
  # available.
  API_VERSIONS = [
-ApiVersion('1.0.57',True),
+ApiVersion('1.0',   True),
  
  # DRM_IOCTL_SYNCOBJ_WAIT is required for VK_KHR_external_fence which is a

  # required core feature in Vulkan 1.1
-ApiVersion('1.1.0', 'device->has_syncobj_wait'),
+ApiVersion('1.1',   'device->has_syncobj_wait'),
  ]
  
  MAX_API_VERSION = None # Computed later

@@ -160,6 +162,7 @@ class VkVersion:
  
  MAX_API_VERSION = VkVersion('0.0.0')

  for version in API_VERSIONS:
-version.max_patch_version = VkVersion(version.max_patch_version)
-assert version.max_patch_version > MAX_API_VERSION
-MAX_API_VERSION = version.max_patch_version
+version.version = VkVersion(version.version)
+version.version.patch = API_PATCH_VERSION
+assert version.version > MAX_API_VERSION
+MAX_API_VERSION = version.version
diff --git a/src/intel/vulkan/anv_extensions_gen.py 
b/src/intel/vulkan/anv_extensions_gen.py
index 5ea82204eea..b75cb3e6fbb 100644
--- a/src/intel/vulkan/anv_extensions_gen.py
+++ b/src/intel/vulkan/anv_extensions_gen.py
@@ -157,7 +157,7 @@ anv_physical_device_api_version(struct anv_physical_device 
*device)
  %for version in API_VERSIONS:
  if (!(${version.enable}))
  return version;
-version = ${version.max_patch_version.c_vk_version()};
+version = ${version.version.c_vk_version()};
  
  %endfor

  return version;



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


Re: [Mesa-dev] [PATCH] mesa: add better GLSL override support for compat profile

2018-06-18 Thread Iago Toral
On Mon, 2018-06-18 at 12:51 +1000, Timothy Arceri wrote:
> ---
>  src/mesa/main/version.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/src/mesa/main/version.c b/src/mesa/main/version.c
> index 1bdccf4a1df..0d2597a61f4 100644
> --- a/src/mesa/main/version.c
> +++ b/src/mesa/main/version.c
> @@ -228,6 +228,7 @@ _mesa_override_glsl_version(struct gl_constants
> *consts)
> }
>  
> n = sscanf(version, "%u", &consts->GLSLVersion);
> +   consts->GLSLVersionCompat = consts->GLSLVersion;
> if (n != 1) {
>fprintf(stderr, "error: invalid value for %s: %s\n", env_var,
> version);
>return;
> @@ -624,16 +625,21 @@ _mesa_compute_version(struct gl_context *ctx)
>switch (ctx->Version) {
>case 30:
>   ctx->Const.GLSLVersion = 130;
> + ctx->Const.GLSLVersionCompat = 130;
>   break;
>case 31:
>   ctx->Const.GLSLVersion = 140;
> + ctx->Const.GLSLVersionCompat = 140;
>   break;
>case 32:
>   ctx->Const.GLSLVersion = 150;
> + ctx->Const.GLSLVersionCompat = 150;
>   break;
>default:
> - if (ctx->Version >= 33)
> + if (ctx->Version >= 33) {
>  ctx->Const.GLSLVersion = ctx->Version * 10;
> +ctx->Const.GLSLVersionCompat = ctx->Version * 10;
> + }
>   break;

Looks like we should be able to just do this after the switch right?:

ctx->Const.GLSLVersionCompat = ctx->Const.GLSLVersion;

I'd prefer this unless there is something I am missing.

With that:
Reviewed-by: Iago Toral Quiroga 

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


Re: [Mesa-dev] [PATCH] mesa: add better GLSL override support for compat profile

2018-06-18 Thread Timothy Arceri



On 18/06/18 19:38, Iago Toral wrote:

On Mon, 2018-06-18 at 12:51 +1000, Timothy Arceri wrote:

---
  src/mesa/main/version.c | 8 +++-
  1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/src/mesa/main/version.c b/src/mesa/main/version.c
index 1bdccf4a1df..0d2597a61f4 100644
--- a/src/mesa/main/version.c
+++ b/src/mesa/main/version.c
@@ -228,6 +228,7 @@ _mesa_override_glsl_version(struct gl_constants
*consts)
 }
  
 n = sscanf(version, "%u", &consts->GLSLVersion);

+   consts->GLSLVersionCompat = consts->GLSLVersion;
 if (n != 1) {
fprintf(stderr, "error: invalid value for %s: %s\n", env_var,
version);
return;
@@ -624,16 +625,21 @@ _mesa_compute_version(struct gl_context *ctx)
switch (ctx->Version) {
case 30:
   ctx->Const.GLSLVersion = 130;
+ ctx->Const.GLSLVersionCompat = 130;
   break;
case 31:
   ctx->Const.GLSLVersion = 140;
+ ctx->Const.GLSLVersionCompat = 140;
   break;
case 32:
   ctx->Const.GLSLVersion = 150;
+ ctx->Const.GLSLVersionCompat = 150;
   break;
default:
- if (ctx->Version >= 33)
+ if (ctx->Version >= 33) {
  ctx->Const.GLSLVersion = ctx->Version * 10;
+ctx->Const.GLSLVersionCompat = ctx->Version * 10;
+ }
   break;


Looks like we should be able to just do this after the switch right?:

ctx->Const.GLSLVersionCompat = ctx->Const.GLSLVersion;

I'd prefer this unless there is something I am missing.


Yeah I realised I should have just done that after sending. Will fix.



With that:
Reviewed-by: Iago Toral Quiroga 


Thanks!




}
 }

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


[Mesa-dev] [Bug 106843] Cannot build osmesa with GLES support using Scons and MSVC

2018-06-18 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=106843

Alex Granni  changed:

   What|Removed |Added

   Severity|major   |critical

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


[Mesa-dev] [PATCH 1/2] drm/i915/gtt: Enable full-ppgtt by default everywhere

2018-06-18 Thread Chris Wilson
We should we have all the kinks worked out and full-ppgtt now works
reliably on gen7 (Ivybridge, Valleyview/Baytrail and Haswell). If we can
let userspace have full control over their own ppgtt, it makes softpinning
far more effective, in turn making GPU dispatch far more efficient and
more secure (due to better mm segregation). On the other hand, switching
over to a different GTT for every client does incur noticeable overhead.

Signed-off-by: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Mika Kuoppala 
Cc: Matthew Auld 
Reviewed-by: Joonas Lahtinen 
Cc: Jason Ekstrand 
Cc: Kenneth Graunke 
---

This has been run through piglit for ivb/vlv/hsw locally and hsw on
kernel's CI, but we would like at least one ack from Mesa as well. If
it's possible to run it through the full gamut of your testing, that
would be great.
-Chris

---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index c6aa761ca085..5ef5176e10fe 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -179,13 +179,11 @@ int intel_sanitize_enable_ppgtt(struct drm_i915_private 
*dev_priv,
return 0;
}
 
-   if (HAS_LOGICAL_RING_CONTEXTS(dev_priv)) {
-   if (has_full_48bit_ppgtt)
-   return 3;
+   if (has_full_48bit_ppgtt)
+   return 3;
 
-   if (has_full_ppgtt)
-   return 2;
-   }
+   if (has_full_ppgtt)
+   return 2;
 
return 1;
 }
-- 
2.17.1

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


[Mesa-dev] [PATCH 2/2] drm/i915/gtt: Full ppgtt everywhere, no excuses

2018-06-18 Thread Chris Wilson
We believe we have all the kinks worked out, even for the early
Valleyview devices, for whom we currently disable all ppgtt.

References: 62942ed7279d ("drm/i915/vlv: disable PPGTT on early revs v3")
Signed-off-by: Chris Wilson 
Cc: Ville Syrjälä 
Cc: Joonas Lahtinen 
Reviewed-by: Joonas Lahtinen 
Acked-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 5ef5176e10fe..dbc55ae234ac 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -173,12 +173,6 @@ int intel_sanitize_enable_ppgtt(struct drm_i915_private 
*dev_priv,
return 0;
}
 
-   /* Early VLV doesn't have this */
-   if (IS_VALLEYVIEW(dev_priv) && dev_priv->drm.pdev->revision < 0xb) {
-   DRM_DEBUG_DRIVER("disabling PPGTT on pre-B3 step VLV\n");
-   return 0;
-   }
-
if (has_full_48bit_ppgtt)
return 3;
 
-- 
2.17.1

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


Re: [Mesa-dev] [PATCH 1/2] drm/i915/gtt: Enable full-ppgtt by default everywhere

2018-06-18 Thread Chris Wilson
Quoting Chris Wilson (2018-06-18 11:10:23)
> We should we have all the kinks worked out and full-ppgtt now works
> reliably on gen7 (Ivybridge, Valleyview/Baytrail and Haswell). If we can
> let userspace have full control over their own ppgtt, it makes softpinning
> far more effective, in turn making GPU dispatch far more efficient and
> more secure (due to better mm segregation). On the other hand, switching
> over to a different GTT for every client does incur noticeable overhead.
> 
> Signed-off-by: Chris Wilson 
> Cc: Joonas Lahtinen 
> Cc: Mika Kuoppala 
> Cc: Matthew Auld 
> Reviewed-by: Joonas Lahtinen 
> Cc: Jason Ekstrand 
> Cc: Kenneth Graunke 
> ---
> 
> This has been run through piglit for ivb/vlv/hsw locally and hsw on
> kernel's CI, but we would like at least one ack from Mesa as well. If
> it's possible to run it through the full gamut of your testing, that
> would be great.

The patches applies to drm-tip, and requires fixes in drm-tip for at
least one GPU hang full-ppgtt caused in piglit.
-Chris
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH mesa] gallium: simplify util_format_is_supported()

2018-06-18 Thread Eric Engestrom
As of 66673bef941af344314f ("mesa: Unconditionally enable floating-point
textures"), the `bind` argument is no longer used, and the format check
is now a simple enum range check, so inline it and remove the
unnecessary argument from callers.

Cc: Timothy Arceri 
Cc: Matt Turner 
Cc: Ian Romanick 
Signed-off-by: Eric Engestrom 
---
 src/gallium/auxiliary/util/u_format.c   | 12 
 src/gallium/auxiliary/util/u_format.h   |  7 +--
 src/gallium/drivers/freedreno/a2xx/fd2_screen.c |  2 +-
 src/gallium/drivers/freedreno/a3xx/fd3_screen.c |  2 +-
 src/gallium/drivers/freedreno/a4xx/fd4_screen.c |  2 +-
 src/gallium/drivers/freedreno/a5xx/fd5_screen.c |  2 +-
 src/gallium/drivers/i915/i915_screen.c  |  2 +-
 src/gallium/drivers/nouveau/nv30/nv30_screen.c  |  2 +-
 src/gallium/drivers/nouveau/nv50/nv50_screen.c  |  2 +-
 src/gallium/drivers/nouveau/nvc0/nvc0_screen.c  |  2 +-
 src/gallium/drivers/r300/r300_screen.c  |  2 +-
 src/gallium/drivers/r600/evergreen_state.c  |  2 +-
 src/gallium/drivers/r600/r600_state.c   |  2 +-
 src/gallium/drivers/radeonsi/si_state.c |  2 +-
 src/gallium/drivers/v3d/v3d_screen.c|  2 +-
 src/gallium/drivers/vc4/vc4_screen.c|  2 +-
 16 files changed, 19 insertions(+), 28 deletions(-)

diff --git a/src/gallium/auxiliary/util/u_format.c 
b/src/gallium/auxiliary/util/u_format.c
index e0325e9c534974b15c65..d82d00a9d06fde2daeef 100644
--- a/src/gallium/auxiliary/util/u_format.c
+++ b/src/gallium/auxiliary/util/u_format.c
@@ -235,18 +235,6 @@ util_format_is_subsampled_422(enum pipe_format format)
   desc->block.bits == 32;
 }
 
-boolean
-util_format_is_supported(enum pipe_format format, unsigned bind)
-{
-   if (format >= PIPE_FORMAT_COUNT) {
-  return FALSE;
-   }
-
-   (void)bind;
-
-   return TRUE;
-}
-
 
 /**
  * Calculates the MRD for the depth format. MRD is used in depth bias
diff --git a/src/gallium/auxiliary/util/u_format.h 
b/src/gallium/auxiliary/util/u_format.h
index e497b4b3375a57771009..9c5df967b6c01288d0b3 100644
--- a/src/gallium/auxiliary/util/u_format.h
+++ b/src/gallium/auxiliary/util/u_format.h
@@ -721,8 +721,11 @@ util_is_format_compatible(const struct 
util_format_description *src_desc,
  * Whether the format is supported by Gallium for the given bindings.
  * This covers S3TC textures and floating-point render targets.
  */
-boolean
-util_format_is_supported(enum pipe_format format, unsigned bind);
+static boolean
+util_format_is_supported(enum pipe_format format)
+{
+   return format < PIPE_FORMAT_COUNT;
+}
 
 /**
  * Whether this format is a rgab8 variant.
diff --git a/src/gallium/drivers/freedreno/a2xx/fd2_screen.c 
b/src/gallium/drivers/freedreno/a2xx/fd2_screen.c
index c2a60c683f86f4f34b02..2b952c0391c34d59fb61 100644
--- a/src/gallium/drivers/freedreno/a2xx/fd2_screen.c
+++ b/src/gallium/drivers/freedreno/a2xx/fd2_screen.c
@@ -44,7 +44,7 @@ fd2_screen_is_format_supported(struct pipe_screen *pscreen,
 
if ((target >= PIPE_MAX_TEXTURE_TYPES) ||
(sample_count > 1) || /* TODO add MSAA */
-   !util_format_is_supported(format, usage)) {
+   !util_format_is_supported(format)) {
DBG("not supported: format=%s, target=%d, sample_count=%d, 
usage=%x",
util_format_name(format), target, sample_count, 
usage);
return FALSE;
diff --git a/src/gallium/drivers/freedreno/a3xx/fd3_screen.c 
b/src/gallium/drivers/freedreno/a3xx/fd3_screen.c
index 998ec7a0bdbaa076b73a..f4bbaeb63ddee4b830a8 100644
--- a/src/gallium/drivers/freedreno/a3xx/fd3_screen.c
+++ b/src/gallium/drivers/freedreno/a3xx/fd3_screen.c
@@ -45,7 +45,7 @@ fd3_screen_is_format_supported(struct pipe_screen *pscreen,
 
if ((target >= PIPE_MAX_TEXTURE_TYPES) ||
(sample_count > 1) || /* TODO add MSAA */
-   !util_format_is_supported(format, usage)) {
+   !util_format_is_supported(format)) {
DBG("not supported: format=%s, target=%d, sample_count=%d, 
usage=%x",
util_format_name(format), target, sample_count, 
usage);
return FALSE;
diff --git a/src/gallium/drivers/freedreno/a4xx/fd4_screen.c 
b/src/gallium/drivers/freedreno/a4xx/fd4_screen.c
index 1b81f8db2f354154ed59..70f13f809173ed551d8c 100644
--- a/src/gallium/drivers/freedreno/a4xx/fd4_screen.c
+++ b/src/gallium/drivers/freedreno/a4xx/fd4_screen.c
@@ -45,7 +45,7 @@ fd4_screen_is_format_supported(struct pipe_screen *pscreen,
 
if ((target >= PIPE_MAX_TEXTURE_TYPES) ||
(sample_count > 1) || /* TODO add MSAA */
-   !util_format_is_supported(format, usage)) {
+   !util_format_is_supported(format)) {
DBG("not supported: format=%s, target=%d, sample_count=%d, 
usage=%x",
util_format_name(format), t

Re: [Mesa-dev] [PATCH] i965: Fix fractional viewport coordinates handling on gen8+

2018-06-18 Thread danylo

Could anyone review this patch?

Here is a Wine dev reporting similar bug to Nvidia 
.
Test in Wine source to enable a workaround for this issue 
.
Similar patch for gallium/radeon 
.


Hope this will help.

-Danil

On 04.06.18 13:41, Danylo Piliaiev wrote:

On gen8+ fractional translation of viewport moved it by a whole integer.
The behaviour in this case isn't defined anywhere but some apps like
Wine may depend on viewport's width and height being ceiled.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106526
Signed-off-by: Danylo Piliaiev 
---
  src/mesa/drivers/dri/i965/genX_state_upload.c | 11 +--
  1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/genX_state_upload.c 
b/src/mesa/drivers/dri/i965/genX_state_upload.c
index 88fde9d..886290f 100644
--- a/src/mesa/drivers/dri/i965/genX_state_upload.c
+++ b/src/mesa/drivers/dri/i965/genX_state_upload.c
@@ -2586,12 +2586,11 @@ genX(upload_sf_clip_viewport)(struct brw_context *brw)
 * pipeline stall so we're better off just being a little more clever
 * with our viewport so we can emit it once at context creation time.
 */
-  const float viewport_Xmin = MAX2(ctx->ViewportArray[i].X, 0);
-  const float viewport_Ymin = MAX2(ctx->ViewportArray[i].Y, 0);
-  const float viewport_Xmax =
- MIN2(ctx->ViewportArray[i].X + ctx->ViewportArray[i].Width, fb_width);
-  const float viewport_Ymax =
- MIN2(ctx->ViewportArray[i].Y + ctx->ViewportArray[i].Height, 
fb_height);
+  const struct gl_viewport_attrib *vp = &ctx->ViewportArray[i];
+  const float viewport_Xmin = MAX2(vp->X, 0);
+  const float viewport_Ymin = MAX2(vp->Y, 0);
+  const float viewport_Xmax = MIN2(ceilf(vp->X + vp->Width), fb_width);
+  const float viewport_Ymax = MIN2(ceilf(vp->Y + vp->Height), fb_height);
  
if (render_to_fbo) {

   sfv.XMinViewPort = viewport_Xmin;


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


[Mesa-dev] [PATCH mesa] mesa: add missing return in error path

2018-06-18 Thread Eric Engestrom
Fixes: 67f40dadaadacd90 "mesa: add support for ARB_sample_locations"
Cc: Rhys Perry 
Cc: Brian Paul 
Signed-off-by: Eric Engestrom 
---
 src/mesa/main/fbobject.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index 5d7e5d29847dcfdbb23e..fa7a9361dfcfeaa105aa 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -4695,9 +4695,11 @@ sample_locations(struct gl_context *ctx, struct 
gl_framebuffer *fb,
if (!fb->SampleLocationTable) {
   size_t size = MAX_SAMPLE_LOCATION_TABLE_SIZE * 2 * sizeof(GLfloat);
   fb->SampleLocationTable = malloc(size);
-  if (!fb->SampleLocationTable)
+  if (!fb->SampleLocationTable) {
  _mesa_error(ctx, GL_OUT_OF_MEMORY,
  "Cannot allocate sample location table");
+ return;
+  }
   for (i = 0; i < MAX_SAMPLE_LOCATION_TABLE_SIZE * 2; i++)
  fb->SampleLocationTable[i] = 0.5f;
}
-- 
Cheers,
  Eric

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


Re: [Mesa-dev] [PATCH] r600: fix copy/paste bug for sampleMaskIn workaround

2018-06-18 Thread Eric Engestrom
On Friday, 2018-06-15 23:38:58 +0200, srol...@vmware.com wrote:
> From: Roland Scheidegger 
> 
> The sampleMaskIn workaround (b936f4d1ca0d2ab1e828ff6a6e617f12469687fa)
> tries to figure out if the shader is running at per-sample frequency, but
> there's a typo bug so it will only recognize per-sample linar inputs,
> not per-sample perspective ones.
> 
> Spotted by Eric Engestrom 

Fixes: b936f4d1ca0d2ab1e828a "r600: partly fix sampleMaskIn value"

(so that it goes on the stable branch as well)

> ---
>  src/gallium/drivers/r600/r600_shader.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/gallium/drivers/r600/r600_shader.c 
> b/src/gallium/drivers/r600/r600_shader.c
> index c9f2fa6485..c466a48262 100644
> --- a/src/gallium/drivers/r600/r600_shader.c
> +++ b/src/gallium/drivers/r600/r600_shader.c
> @@ -1247,7 +1247,7 @@ static int allocate_system_value_inputs(struct 
> r600_shader_ctx *ctx, int gpr_off
>   tgsi_parse_free(&parse);
>  
>   if (ctx->info.reads_samplemask &&
> - (ctx->info.uses_linear_sample || ctx->info.uses_linear_sample)) {
> + (ctx->info.uses_linear_sample || ctx->info.uses_persp_sample)) {
>   inputs[1].enabled = true;
>   }
>  
> -- 
> 2.12.3
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [Bug 106915] [GLSL] Unused arrays declared without a size should be handled like arrays of size 1.

2018-06-18 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=106915

Eleni Maria Stea  changed:

   What|Removed |Added

 CC||es...@igalia.com

--- Comment #8 from Eleni Maria Stea  ---
(In reply to Ian Romanick from comment #2)

> Before we do that... does this work on other implementations?  I am very
> surprised that this is valid, as it does not match recollection of how we
> designed SSBOs.  I'll be a little surprised if this works on other drivers. 
> Let's collection some information about that, then decide how to proceed.

I ran the test on a proprietary ATI driver [1], here's the output:

$ bin/shader_runner
tests/spec/arb_shader_storage_buffer_object/linker/unsized_array_member.shader_test
 
Failed to compile VS: Vertex shader failed to compile with the following
errors:
ERROR: 0:5: error(#413) Invalid implict array size is used on "uniform block
member", it only can be used on array's outer level
ERROR: 0:4: error(#415) only last member of shader storage buffer can be
unsized array
ERROR: 0:13: error(#143) Undeclared identifier: b
ERROR: 0:13: error(#216) Vector field selection out of range "a"
ERROR: 0:13: error(#145) Left of "[" is not of type array, matrix, or vector:
expression
ERROR: 0:13: error(#160) Cannot convert from: "float" to: "default out highp
4-component vector of vec4"
ERROR: error(#273) 6 compilation errors.  No code generated

[1]:
OpenGL renderer string: AMD Radeon HD 7400M Series
OpenGL version string: 4.4.13374 Compatibility Profile Context 13.35.1005
(installed fglrx version: 2:15.200-0ubuntu0.5)

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


Re: [Mesa-dev] [PATCH] Plumb invariant output attrib thru TGSI

2018-06-18 Thread Jakob Bornecrantz
TGSI already has a invariant field on declarations, we are running
into a bug with virgl because st_glsl_to_tgsi completely drops the
invariant flag on the floor when it comes to declarations (tho precise
is added to the ops). But virgl can't express precise ops (only
invariant and precise declarations) only declarations.

Going to do some testing on this patch soon.

Cheers, Jakob.

On Tue, Apr 10, 2018 at 7:02 PM Marek Olšák  wrote:
>
> This doesn't change TGSI. It only changes utilities around it.
>
> Marek
>
> On Mon, Apr 9, 2018 at 6:02 PM, Joe M. Kniss  wrote:
>>
>> Add support for glsl 'invariant' modifier for output data declarations.
>> Gallium drivers that use TGSI serialization currently loose invariant
>> modifiers in glsl shaders.
>>
>> Tested: chromiumos on qemu with virglrenderer.
>> Signed-off-by: Joe M. Kniss 
>> ---
>>  src/gallium/auxiliary/tgsi/tgsi_strings.c  |  2 ++
>>  src/gallium/auxiliary/tgsi/tgsi_strings.h  |  2 ++
>>  src/gallium/auxiliary/tgsi/tgsi_text.c | 18 +++
>>  src/gallium/auxiliary/tgsi/tgsi_ureg.c | 27 ++
>>  src/gallium/auxiliary/tgsi/tgsi_ureg.h |  4 +++-
>>  src/mesa/state_tracker/st_glsl_to_tgsi.cpp |  8 +--
>>  6 files changed, 45 insertions(+), 16 deletions(-)
>>
>> diff --git a/src/gallium/auxiliary/tgsi/tgsi_strings.c 
>> b/src/gallium/auxiliary/tgsi/tgsi_strings.c
>> index 4f28b49ce8..434871273f 100644
>> --- a/src/gallium/auxiliary/tgsi/tgsi_strings.c
>> +++ b/src/gallium/auxiliary/tgsi/tgsi_strings.c
>> @@ -185,6 +185,8 @@ const char 
>> *tgsi_interpolate_locations[TGSI_INTERPOLATE_LOC_COUNT] =
>> "SAMPLE",
>>  };
>>
>> +const char *tgsi_invariant_name = "INVARIANT";
>> +
>>  const char *tgsi_primitive_names[PIPE_PRIM_MAX] =
>>  {
>> "POINTS",
>> diff --git a/src/gallium/auxiliary/tgsi/tgsi_strings.h 
>> b/src/gallium/auxiliary/tgsi/tgsi_strings.h
>> index bb2d3458dd..20e3f7127f 100644
>> --- a/src/gallium/auxiliary/tgsi/tgsi_strings.h
>> +++ b/src/gallium/auxiliary/tgsi/tgsi_strings.h
>> @@ -52,6 +52,8 @@ extern const char 
>> *tgsi_interpolate_names[TGSI_INTERPOLATE_COUNT];
>>
>>  extern const char *tgsi_interpolate_locations[TGSI_INTERPOLATE_LOC_COUNT];
>>
>> +extern const char *tgsi_invariant_name;
>> +
>>  extern const char *tgsi_primitive_names[PIPE_PRIM_MAX];
>>
>>  extern const char *tgsi_fs_coord_origin_names[2];
>> diff --git a/src/gallium/auxiliary/tgsi/tgsi_text.c 
>> b/src/gallium/auxiliary/tgsi/tgsi_text.c
>> index 02241a66bf..815b1ee65d 100644
>> --- a/src/gallium/auxiliary/tgsi/tgsi_text.c
>> +++ b/src/gallium/auxiliary/tgsi/tgsi_text.c
>> @@ -1586,10 +1586,6 @@ static boolean parse_declaration( struct 
>> translate_ctx *ctx )
>>  break;
>>   }
>>}
>> -  if (i == TGSI_INTERPOLATE_COUNT) {
>> - report_error( ctx, "Expected semantic or interpolate attribute" );
>> - return FALSE;
>> -  }
>> }
>>
>> cur = ctx->cur;
>> @@ -1609,6 +1605,20 @@ static boolean parse_declaration( struct 
>> translate_ctx *ctx )
>>}
>> }
>>
>> +   cur = ctx->cur;
>> +   eat_opt_white( &cur );
>> +   if (*cur == ',' && !is_vs_input) {
>> +  cur++;
>> +  eat_opt_white( &cur );
>> +  if (str_match_nocase_whole( &cur, tgsi_invariant_name )) {
>> + decl.Declaration.Invariant = 1;
>> + ctx->cur = cur;
>> +  } else {
>> + report_error( ctx, "Expected semantic, interpolate attribute, or 
>> invariant ");
>> + return FALSE;
>> +  }
>> +   }
>> +
>> advance = tgsi_build_full_declaration(
>>&decl,
>>ctx->tokens_cur,
>> diff --git a/src/gallium/auxiliary/tgsi/tgsi_ureg.c 
>> b/src/gallium/auxiliary/tgsi/tgsi_ureg.c
>> index 393e015001..f54e2229a7 100644
>> --- a/src/gallium/auxiliary/tgsi/tgsi_ureg.c
>> +++ b/src/gallium/auxiliary/tgsi/tgsi_ureg.c
>> @@ -140,6 +140,7 @@ struct ureg_program
>>unsigned first;
>>unsigned last;
>>unsigned array_id;
>> +  unsigned invariant;
>> } output[UREG_MAX_OUTPUT];
>> unsigned nr_outputs, nr_output_regs;
>>
>> @@ -427,7 +428,8 @@ ureg_DECL_output_layout(struct ureg_program *ureg,
>>  unsigned index,
>>  unsigned usage_mask,
>>  unsigned array_id,
>> -unsigned array_size)
>> +unsigned array_size,
>> +unsigned invariant)
>>  {
>> unsigned i;
>>
>> @@ -455,6 +457,7 @@ ureg_DECL_output_layout(struct ureg_program *ureg,
>>ureg->output[i].first = index;
>>ureg->output[i].last = index + array_size - 1;
>>ureg->output[i].array_id = array_id;
>> +  ureg->output[i].invariant = invariant;
>>ureg->nr_output_regs = MAX2(ureg->nr_output_regs, index + array_size);
>>ureg->nr_outputs++;
>> }
>> @@ -480,7 +483,7 @@ ureg_DECL_output_masked(struct ureg_program *ureg,
>>  unsigned array_size)
>>  {
>> return ureg_D

Re: [Mesa-dev] [PATCH] r600: fix copy/paste bug for sampleMaskIn workaround

2018-06-18 Thread Roland Scheidegger
Am 18.06.2018 um 12:43 schrieb Eric Engestrom:
> On Friday, 2018-06-15 23:38:58 +0200, srol...@vmware.com wrote:
>> From: Roland Scheidegger 
>>
>> The sampleMaskIn workaround (b936f4d1ca0d2ab1e828ff6a6e617f12469687fa)
>> tries to figure out if the shader is running at per-sample frequency, but
>> there's a typo bug so it will only recognize per-sample linar inputs,
>> not per-sample perspective ones.
>>
>> Spotted by Eric Engestrom 
> 
> Fixes: b936f4d1ca0d2ab1e828a "r600: partly fix sampleMaskIn value"
Alright, albeit it's hardly a critical issue (and, before that patch, it
was just always wrong anyway and there weren't really bugs associated to
it...).

Roland


> 
> (so that it goes on the stable branch as well)
> 
>> ---
>>  src/gallium/drivers/r600/r600_shader.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/src/gallium/drivers/r600/r600_shader.c 
>> b/src/gallium/drivers/r600/r600_shader.c
>> index c9f2fa6485..c466a48262 100644
>> --- a/src/gallium/drivers/r600/r600_shader.c
>> +++ b/src/gallium/drivers/r600/r600_shader.c
>> @@ -1247,7 +1247,7 @@ static int allocate_system_value_inputs(struct 
>> r600_shader_ctx *ctx, int gpr_off
>>  tgsi_parse_free(&parse);
>>  
>>  if (ctx->info.reads_samplemask &&
>> -(ctx->info.uses_linear_sample || ctx->info.uses_linear_sample)) {
>> +(ctx->info.uses_linear_sample || ctx->info.uses_persp_sample)) {
>>  inputs[1].enabled = true;
>>  }
>>  
>> -- 
>> 2.12.3
>>

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


[Mesa-dev] [Bug 106595] [RADV] Rendering distortions only when MSAA is enabled

2018-06-18 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=106595

--- Comment #17 from zefkerri...@gmail.com ---
(In reply to Samuel Pitoiset from comment #16)
> Unfortunately, I can't replay the trace because it's not the same hardware.

I want to help you, but tell me please how I can do it?
Regards.

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


Re: [Mesa-dev] [PATCH] r600: fix copy/paste bug for sampleMaskIn workaround

2018-06-18 Thread Eric Engestrom
On Monday, 2018-06-18 13:07:12 +0200, Roland Scheidegger wrote:
> Am 18.06.2018 um 12:43 schrieb Eric Engestrom:
> > On Friday, 2018-06-15 23:38:58 +0200, srol...@vmware.com wrote:
> >> From: Roland Scheidegger 
> >>
> >> The sampleMaskIn workaround (b936f4d1ca0d2ab1e828ff6a6e617f12469687fa)
> >> tries to figure out if the shader is running at per-sample frequency, but
> >> there's a typo bug so it will only recognize per-sample linar inputs,
> >> not per-sample perspective ones.
> >>
> >> Spotted by Eric Engestrom 
> > 
> > Fixes: b936f4d1ca0d2ab1e828a "r600: partly fix sampleMaskIn value"
> Alright, albeit it's hardly a critical issue (and, before that patch, it
> was just always wrong anyway and there weren't really bugs associated to
> it...).

Sure, it's your call anyway.

> 
> Roland
> 
> 
> > 
> > (so that it goes on the stable branch as well)
> > 
> >> ---
> >>  src/gallium/drivers/r600/r600_shader.c | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/src/gallium/drivers/r600/r600_shader.c 
> >> b/src/gallium/drivers/r600/r600_shader.c
> >> index c9f2fa6485..c466a48262 100644
> >> --- a/src/gallium/drivers/r600/r600_shader.c
> >> +++ b/src/gallium/drivers/r600/r600_shader.c
> >> @@ -1247,7 +1247,7 @@ static int allocate_system_value_inputs(struct 
> >> r600_shader_ctx *ctx, int gpr_off
> >>tgsi_parse_free(&parse);
> >>  
> >>if (ctx->info.reads_samplemask &&
> >> -  (ctx->info.uses_linear_sample || ctx->info.uses_linear_sample)) {
> >> +  (ctx->info.uses_linear_sample || ctx->info.uses_persp_sample)) {
> >>inputs[1].enabled = true;
> >>}
> >>  
> >> -- 
> >> 2.12.3
> >>
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH v2 1/5] util: manually extract the program name from program_invocation_name

2018-06-18 Thread Eric Engestrom
On Friday, 2018-06-15 12:56:04 +1000, Timothy Arceri wrote:
> On 14/06/18 19:40, Eric Engestrom wrote:
> 
> > On Thursday, 2018-06-14 11:00:21 +1000, Timothy Arceri wrote:
> > > Glibc has the same code to get program_invocation_short_name. However
> > > for some reason the short name gets mangled for some wine apps.
> > > 
> > > For example with Google Earth VR I get:
> > > 
> > > program_invocation_name:
> > > "/home/tarceri/.local/share/Steam/steamapps/common/EarthVR/Earth.exe"
> > > 
> > > program_invocation_short_name:
> > > "e"
> > > ---
> > >   src/util/xmlconfig.c | 11 ++-
> > >   1 file changed, 10 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/src/util/xmlconfig.c b/src/util/xmlconfig.c
> > > index 60a6331c86c..ad943e2ce48 100644
> > > --- a/src/util/xmlconfig.c
> > > +++ b/src/util/xmlconfig.c
> > > @@ -45,7 +45,16 @@
> > >   /* These aren't declared in any libc5 header */
> > >   extern char *program_invocation_name, *program_invocation_short_name;
> > >   #endif
> > > -#define GET_PROGRAM_NAME() program_invocation_short_name
> > > +static const char *
> > > +__getProgramName()
> > > +{
> > > +char * arg = strrchr(program_invocation_name, '/');
> > > +if (arg)
> > > +return arg+1;
> > > +else
> > > +return program_invocation_name;
> > > +}
> > > +#define GET_PROGRAM_NAME() __getProgramName()
> > How about:
> > 
> >#include 
> >#define GET_PROGRAM_NAME() basename(program_invocation_name)
> 
> I'm happy to change, but I was simply staying consistent with how it is
> defined in other places in this file.

Either is fine, I just thought as I saw this "that's basename() !", but
I guess it doesn't really matter.

For either solution:
Acked-by: Eric Engestrom 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH v2 1/5] util: manually extract the program name from program_invocation_name

2018-06-18 Thread Eric Engestrom
On Monday, 2018-06-18 12:37:59 +0100, Eric Engestrom wrote:
> On Friday, 2018-06-15 12:56:04 +1000, Timothy Arceri wrote:
> > On 14/06/18 19:40, Eric Engestrom wrote:
> > 
> > > On Thursday, 2018-06-14 11:00:21 +1000, Timothy Arceri wrote:
> > > > Glibc has the same code to get program_invocation_short_name. However
> > > > for some reason the short name gets mangled for some wine apps.
> > > > 
> > > > For example with Google Earth VR I get:
> > > > 
> > > > program_invocation_name:
> > > > "/home/tarceri/.local/share/Steam/steamapps/common/EarthVR/Earth.exe"
> > > > 
> > > > program_invocation_short_name:
> > > > "e"
> > > > ---
> > > >   src/util/xmlconfig.c | 11 ++-
> > > >   1 file changed, 10 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/src/util/xmlconfig.c b/src/util/xmlconfig.c
> > > > index 60a6331c86c..ad943e2ce48 100644
> > > > --- a/src/util/xmlconfig.c
> > > > +++ b/src/util/xmlconfig.c
> > > > @@ -45,7 +45,16 @@
> > > >   /* These aren't declared in any libc5 header */
> > > >   extern char *program_invocation_name, *program_invocation_short_name;
> > > >   #endif
> > > > -#define GET_PROGRAM_NAME() program_invocation_short_name
> > > > +static const char *
> > > > +__getProgramName()
> > > > +{
> > > > +char * arg = strrchr(program_invocation_name, '/');
> > > > +if (arg)
> > > > +return arg+1;
> > > > +else
> > > > +return program_invocation_name;
> > > > +}
> > > > +#define GET_PROGRAM_NAME() __getProgramName()
> > > How about:
> > > 
> > >#include 
> > >#define GET_PROGRAM_NAME() basename(program_invocation_name)
> > 
> > I'm happy to change, but I was simply staying consistent with how it is
> > defined in other places in this file.
> 
> Either is fine, I just thought as I saw this "that's basename() !", but
> I guess it doesn't really matter.
> 
> For either solution:
> Acked-by: Eric Engestrom 

To be clear, this is just for patch 1, the rest of the series changes
stuff I don't know if it's ok to change, I'll let others decide :)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH mesa] gallium: simplify util_format_is_supported()

2018-06-18 Thread Timothy Arceri

Reviewed-by: Timothy Arceri 

On 18/06/18 20:15, Eric Engestrom wrote:

As of 66673bef941af344314f ("mesa: Unconditionally enable floating-point
textures"), the `bind` argument is no longer used, and the format check
is now a simple enum range check, so inline it and remove the
unnecessary argument from callers.

Cc: Timothy Arceri 
Cc: Matt Turner 
Cc: Ian Romanick 
Signed-off-by: Eric Engestrom 
---
  src/gallium/auxiliary/util/u_format.c   | 12 
  src/gallium/auxiliary/util/u_format.h   |  7 +--
  src/gallium/drivers/freedreno/a2xx/fd2_screen.c |  2 +-
  src/gallium/drivers/freedreno/a3xx/fd3_screen.c |  2 +-
  src/gallium/drivers/freedreno/a4xx/fd4_screen.c |  2 +-
  src/gallium/drivers/freedreno/a5xx/fd5_screen.c |  2 +-
  src/gallium/drivers/i915/i915_screen.c  |  2 +-
  src/gallium/drivers/nouveau/nv30/nv30_screen.c  |  2 +-
  src/gallium/drivers/nouveau/nv50/nv50_screen.c  |  2 +-
  src/gallium/drivers/nouveau/nvc0/nvc0_screen.c  |  2 +-
  src/gallium/drivers/r300/r300_screen.c  |  2 +-
  src/gallium/drivers/r600/evergreen_state.c  |  2 +-
  src/gallium/drivers/r600/r600_state.c   |  2 +-
  src/gallium/drivers/radeonsi/si_state.c |  2 +-
  src/gallium/drivers/v3d/v3d_screen.c|  2 +-
  src/gallium/drivers/vc4/vc4_screen.c|  2 +-
  16 files changed, 19 insertions(+), 28 deletions(-)

diff --git a/src/gallium/auxiliary/util/u_format.c 
b/src/gallium/auxiliary/util/u_format.c
index e0325e9c534974b15c65..d82d00a9d06fde2daeef 100644
--- a/src/gallium/auxiliary/util/u_format.c
+++ b/src/gallium/auxiliary/util/u_format.c
@@ -235,18 +235,6 @@ util_format_is_subsampled_422(enum pipe_format format)
desc->block.bits == 32;
  }
  
-boolean

-util_format_is_supported(enum pipe_format format, unsigned bind)
-{
-   if (format >= PIPE_FORMAT_COUNT) {
-  return FALSE;
-   }
-
-   (void)bind;
-
-   return TRUE;
-}
-
  
  /**

   * Calculates the MRD for the depth format. MRD is used in depth bias
diff --git a/src/gallium/auxiliary/util/u_format.h 
b/src/gallium/auxiliary/util/u_format.h
index e497b4b3375a57771009..9c5df967b6c01288d0b3 100644
--- a/src/gallium/auxiliary/util/u_format.h
+++ b/src/gallium/auxiliary/util/u_format.h
@@ -721,8 +721,11 @@ util_is_format_compatible(const struct 
util_format_description *src_desc,
   * Whether the format is supported by Gallium for the given bindings.
   * This covers S3TC textures and floating-point render targets.
   */
-boolean
-util_format_is_supported(enum pipe_format format, unsigned bind);
+static boolean
+util_format_is_supported(enum pipe_format format)
+{
+   return format < PIPE_FORMAT_COUNT;
+}
  
  /**

   * Whether this format is a rgab8 variant.
diff --git a/src/gallium/drivers/freedreno/a2xx/fd2_screen.c 
b/src/gallium/drivers/freedreno/a2xx/fd2_screen.c
index c2a60c683f86f4f34b02..2b952c0391c34d59fb61 100644
--- a/src/gallium/drivers/freedreno/a2xx/fd2_screen.c
+++ b/src/gallium/drivers/freedreno/a2xx/fd2_screen.c
@@ -44,7 +44,7 @@ fd2_screen_is_format_supported(struct pipe_screen *pscreen,
  
  	if ((target >= PIPE_MAX_TEXTURE_TYPES) ||

(sample_count > 1) || /* TODO add MSAA */
-   !util_format_is_supported(format, usage)) {
+   !util_format_is_supported(format)) {
DBG("not supported: format=%s, target=%d, sample_count=%d, 
usage=%x",
util_format_name(format), target, sample_count, 
usage);
return FALSE;
diff --git a/src/gallium/drivers/freedreno/a3xx/fd3_screen.c 
b/src/gallium/drivers/freedreno/a3xx/fd3_screen.c
index 998ec7a0bdbaa076b73a..f4bbaeb63ddee4b830a8 100644
--- a/src/gallium/drivers/freedreno/a3xx/fd3_screen.c
+++ b/src/gallium/drivers/freedreno/a3xx/fd3_screen.c
@@ -45,7 +45,7 @@ fd3_screen_is_format_supported(struct pipe_screen *pscreen,
  
  	if ((target >= PIPE_MAX_TEXTURE_TYPES) ||

(sample_count > 1) || /* TODO add MSAA */
-   !util_format_is_supported(format, usage)) {
+   !util_format_is_supported(format)) {
DBG("not supported: format=%s, target=%d, sample_count=%d, 
usage=%x",
util_format_name(format), target, sample_count, 
usage);
return FALSE;
diff --git a/src/gallium/drivers/freedreno/a4xx/fd4_screen.c 
b/src/gallium/drivers/freedreno/a4xx/fd4_screen.c
index 1b81f8db2f354154ed59..70f13f809173ed551d8c 100644
--- a/src/gallium/drivers/freedreno/a4xx/fd4_screen.c
+++ b/src/gallium/drivers/freedreno/a4xx/fd4_screen.c
@@ -45,7 +45,7 @@ fd4_screen_is_format_supported(struct pipe_screen *pscreen,
  
  	if ((target >= PIPE_MAX_TEXTURE_TYPES) ||

(sample_count > 1) || /* TODO add MSAA */
-   !util_format_is_supported(format, usage)) {
+   !util_format_is_supported(format)) {
DBG("not supported: format=%s, tar

[Mesa-dev] [Bug 106843] Cannot build osmesa with GLES support using Scons and MSVC

2018-06-18 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=106843

--- Comment #4 from Eric Engestrom  ---
Hi Alex,

First off, note that I don't know anything about scons, msvc or windows, but
Dylan has been adding Windows support to Meson
(https://lists.freedesktop.org/archives/mesa-dev/2018-June/197325.html).

Would you mind testing the work-in-progress branch and report if it works when
building with Meson?
git://people.freedesktop.org/~dbaker/mesa meson-windows

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


[Mesa-dev] [PATCH kmscube 1/2] gbm: fix fallback for drivers that don't support modifiers

2018-06-18 Thread Rob Clark
Gallium drivers that do not implement resource_create_with_modifiers()
will fail gbm_surface_create_with_modifiers() so fall back to the old
way.

Fixes: 4f7cec0 Use weak functions to handle lack of gbm modifiers
Signed-off-by: Rob Clark 
---
 common.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/common.c b/common.c
index faecd42..931fc06 100644
--- a/common.c
+++ b/common.c
@@ -44,13 +44,16 @@ const struct gbm * init_gbm(int drm_fd, int w, int h, 
uint64_t modifier)
 {
gbm.dev = gbm_create_device(drm_fd);
gbm.format = GBM_FORMAT_XRGB;
+   gbm.surface = NULL;
 
if (gbm_surface_create_with_modifiers) {
gbm.surface = gbm_surface_create_with_modifiers(gbm.dev, w, h,
gbm.format,
&modifier, 1);
 
-   } else {
+   }
+
+   if (!gbm.surface) {
if (modifier != DRM_FORMAT_MOD_LINEAR) {
fprintf(stderr, "Modifiers requested but support isn't 
available\n");
return NULL;
-- 
2.17.1

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


[Mesa-dev] [PATCH kmscube 2/2] add MSAA

2018-06-18 Thread Rob Clark
Signed-off-by: Rob Clark 
---
 common.c  |  5 +++--
 common.h  | 12 ++--
 cube-smooth.c |  4 ++--
 cube-tex.c|  4 ++--
 cube-video.c  |  4 ++--
 kmscube.c | 12 +---
 6 files changed, 24 insertions(+), 17 deletions(-)

diff --git a/common.c b/common.c
index 931fc06..d6d8d27 100644
--- a/common.c
+++ b/common.c
@@ -161,7 +161,7 @@ out:
return true;
 }
 
-int init_egl(struct egl *egl, const struct gbm *gbm)
+int init_egl(struct egl *egl, const struct gbm *gbm, int samples)
 {
EGLint major, minor;
 
@@ -170,13 +170,14 @@ int init_egl(struct egl *egl, const struct gbm *gbm)
EGL_NONE
};
 
-   static const EGLint config_attribs[] = {
+   const EGLint config_attribs[] = {
EGL_SURFACE_TYPE, EGL_WINDOW_BIT,
EGL_RED_SIZE, 1,
EGL_GREEN_SIZE, 1,
EGL_BLUE_SIZE, 1,
EGL_ALPHA_SIZE, 0,
EGL_RENDERABLE_TYPE, EGL_OPENGL_ES2_BIT,
+   EGL_SAMPLES, samples,
EGL_NONE
};
const char *egl_exts_client, *egl_exts_dpy, *gl_exts;
diff --git a/common.h b/common.h
index 898010d..cff2c33 100644
--- a/common.h
+++ b/common.h
@@ -118,7 +118,7 @@ static inline int __egl_check(void *ptr, const char *name)
 
 #define egl_check(egl, name) __egl_check((egl)->name, #name)
 
-int init_egl(struct egl *egl, const struct gbm *gbm);
+int init_egl(struct egl *egl, const struct gbm *gbm, int samples);
 int create_program(const char *vs_src, const char *fs_src);
 int link_program(unsigned program);
 
@@ -130,8 +130,8 @@ enum mode {
VIDEO, /* video textured cube */
 };
 
-const struct egl * init_cube_smooth(const struct gbm *gbm);
-const struct egl * init_cube_tex(const struct gbm *gbm, enum mode mode);
+const struct egl * init_cube_smooth(const struct gbm *gbm, int samples);
+const struct egl * init_cube_tex(const struct gbm *gbm, enum mode mode, int 
samples);
 
 #ifdef HAVE_GST
 
@@ -140,13 +140,13 @@ struct decoder * video_init(const struct egl *egl, const 
struct gbm *gbm, const
 EGLImage video_frame(struct decoder *dec);
 void video_deinit(struct decoder *dec);
 
-const struct egl * init_cube_video(const struct gbm *gbm, const char *video);
+const struct egl * init_cube_video(const struct gbm *gbm, const char *video, 
int samples);
 
 #else
 static inline const struct egl *
-init_cube_video(const struct gbm *gbm, const char *video)
+init_cube_video(const struct gbm *gbm, const char *video, int samples)
 {
-   (void)gbm; (void)video;
+   (void)gbm; (void)video; (void)samples;
printf("no GStreamer support!\n");
return NULL;
 }
diff --git a/cube-smooth.c b/cube-smooth.c
index f29face..483c2ae 100644
--- a/cube-smooth.c
+++ b/cube-smooth.c
@@ -218,11 +218,11 @@ static void draw_cube_smooth(unsigned i)
glDrawArrays(GL_TRIANGLE_STRIP, 20, 4);
 }
 
-const struct egl * init_cube_smooth(const struct gbm *gbm)
+const struct egl * init_cube_smooth(const struct gbm *gbm, int samples)
 {
int ret;
 
-   ret = init_egl(&gl.egl, gbm);
+   ret = init_egl(&gl.egl, gbm, samples);
if (ret)
return NULL;
 
diff --git a/cube-tex.c b/cube-tex.c
index 7353de4..09f18e3 100644
--- a/cube-tex.c
+++ b/cube-tex.c
@@ -569,13 +569,13 @@ static void draw_cube_tex(unsigned i)
glDrawArrays(GL_TRIANGLE_STRIP, 20, 4);
 }
 
-const struct egl * init_cube_tex(const struct gbm *gbm, enum mode mode)
+const struct egl * init_cube_tex(const struct gbm *gbm, enum mode mode, int 
samples)
 {
const char *fragment_shader_source = (mode == NV12_2IMG) ?
fragment_shader_source_2img : 
fragment_shader_source_1img;
int ret;
 
-   ret = init_egl(&gl.egl, gbm);
+   ret = init_egl(&gl.egl, gbm, samples);
if (ret)
return NULL;
 
diff --git a/cube-video.c b/cube-video.c
index 03bfb80..8cb8f24 100644
--- a/cube-video.c
+++ b/cube-video.c
@@ -301,12 +301,12 @@ static void draw_cube_video(unsigned i)
gl.last_fence = egl->eglCreateSyncKHR(egl->display, EGL_SYNC_FENCE_KHR, 
NULL);
 }
 
-const struct egl * init_cube_video(const struct gbm *gbm, const char 
*filenames)
+const struct egl * init_cube_video(const struct gbm *gbm, const char 
*filenames, int samples)
 {
char *fnames, *s;
int ret, i = 0;
 
-   ret = init_egl(&gl.egl, gbm);
+   ret = init_egl(&gl.egl, gbm, samples);
if (ret)
return NULL;
 
diff --git a/kmscube.c b/kmscube.c
index 87a4205..6275109 100644
--- a/kmscube.c
+++ b/kmscube.c
@@ -50,6 +50,7 @@ static const struct option longopts[] = {
{"device", required_argument, 0, 'D'},
{"mode",   required_argument, 0, 'M'},
{"modifier", required_argument, 0, 'm'},
+   {"samples",  required_argument, 0, 's'},
{"video",  required_argument, 0, 'V'},
{0, 0, 0, 0}
 };
@@ -67,6 +68,7 @@ static void usage(const char *name)

Re: [Mesa-dev] [PATCH] Plumb invariant output attrib thru TGSI

2018-06-18 Thread Elie Tournier
On Mon, Jun 18, 2018 at 12:06:42PM +0100, Jakob Bornecrantz wrote:
> TGSI already has a invariant field on declarations, we are running
> into a bug with virgl because st_glsl_to_tgsi completely drops the
> invariant flag on the floor when it comes to declarations (tho precise
> is added to the ops). But virgl can't express precise ops (only
> invariant and precise declarations) only declarations.
> 
> Going to do some testing on this patch soon.
> 
> Cheers, Jakob.
Supposing that it doesn't brake any gallium driver.
Maybe Marek can confirm. I only test on qemu with virgl.

Reviewed-by: Elie Tournier 

> 
> On Tue, Apr 10, 2018 at 7:02 PM Marek Olšák  wrote:
> >
> > This doesn't change TGSI. It only changes utilities around it.
> >
> > Marek
> >
> > On Mon, Apr 9, 2018 at 6:02 PM, Joe M. Kniss  wrote:
> >>
> >> Add support for glsl 'invariant' modifier for output data declarations.
> >> Gallium drivers that use TGSI serialization currently loose invariant
> >> modifiers in glsl shaders.
> >>
> >> Tested: chromiumos on qemu with virglrenderer.
> >> Signed-off-by: Joe M. Kniss 
> >> ---
> >>  src/gallium/auxiliary/tgsi/tgsi_strings.c  |  2 ++
> >>  src/gallium/auxiliary/tgsi/tgsi_strings.h  |  2 ++
> >>  src/gallium/auxiliary/tgsi/tgsi_text.c | 18 +++
> >>  src/gallium/auxiliary/tgsi/tgsi_ureg.c | 27 ++
> >>  src/gallium/auxiliary/tgsi/tgsi_ureg.h |  4 +++-
> >>  src/mesa/state_tracker/st_glsl_to_tgsi.cpp |  8 +--
> >>  6 files changed, 45 insertions(+), 16 deletions(-)
> >>
> >> diff --git a/src/gallium/auxiliary/tgsi/tgsi_strings.c 
> >> b/src/gallium/auxiliary/tgsi/tgsi_strings.c
> >> index 4f28b49ce8..434871273f 100644
> >> --- a/src/gallium/auxiliary/tgsi/tgsi_strings.c
> >> +++ b/src/gallium/auxiliary/tgsi/tgsi_strings.c
> >> @@ -185,6 +185,8 @@ const char 
> >> *tgsi_interpolate_locations[TGSI_INTERPOLATE_LOC_COUNT] =
> >> "SAMPLE",
> >>  };
> >>
> >> +const char *tgsi_invariant_name = "INVARIANT";
> >> +
> >>  const char *tgsi_primitive_names[PIPE_PRIM_MAX] =
> >>  {
> >> "POINTS",
> >> diff --git a/src/gallium/auxiliary/tgsi/tgsi_strings.h 
> >> b/src/gallium/auxiliary/tgsi/tgsi_strings.h
> >> index bb2d3458dd..20e3f7127f 100644
> >> --- a/src/gallium/auxiliary/tgsi/tgsi_strings.h
> >> +++ b/src/gallium/auxiliary/tgsi/tgsi_strings.h
> >> @@ -52,6 +52,8 @@ extern const char 
> >> *tgsi_interpolate_names[TGSI_INTERPOLATE_COUNT];
> >>
> >>  extern const char *tgsi_interpolate_locations[TGSI_INTERPOLATE_LOC_COUNT];
> >>
> >> +extern const char *tgsi_invariant_name;
> >> +
> >>  extern const char *tgsi_primitive_names[PIPE_PRIM_MAX];
> >>
> >>  extern const char *tgsi_fs_coord_origin_names[2];
> >> diff --git a/src/gallium/auxiliary/tgsi/tgsi_text.c 
> >> b/src/gallium/auxiliary/tgsi/tgsi_text.c
> >> index 02241a66bf..815b1ee65d 100644
> >> --- a/src/gallium/auxiliary/tgsi/tgsi_text.c
> >> +++ b/src/gallium/auxiliary/tgsi/tgsi_text.c
> >> @@ -1586,10 +1586,6 @@ static boolean parse_declaration( struct 
> >> translate_ctx *ctx )
> >>  break;
> >>   }
> >>}
> >> -  if (i == TGSI_INTERPOLATE_COUNT) {
> >> - report_error( ctx, "Expected semantic or interpolate attribute" 
> >> );
> >> - return FALSE;
> >> -  }
> >> }
> >>
> >> cur = ctx->cur;
> >> @@ -1609,6 +1605,20 @@ static boolean parse_declaration( struct 
> >> translate_ctx *ctx )
> >>}
> >> }
> >>
> >> +   cur = ctx->cur;
> >> +   eat_opt_white( &cur );
> >> +   if (*cur == ',' && !is_vs_input) {
> >> +  cur++;
> >> +  eat_opt_white( &cur );
> >> +  if (str_match_nocase_whole( &cur, tgsi_invariant_name )) {
> >> + decl.Declaration.Invariant = 1;
> >> + ctx->cur = cur;
> >> +  } else {
> >> + report_error( ctx, "Expected semantic, interpolate attribute, or 
> >> invariant ");
> >> + return FALSE;
> >> +  }
> >> +   }
> >> +
> >> advance = tgsi_build_full_declaration(
> >>&decl,
> >>ctx->tokens_cur,
> >> diff --git a/src/gallium/auxiliary/tgsi/tgsi_ureg.c 
> >> b/src/gallium/auxiliary/tgsi/tgsi_ureg.c
> >> index 393e015001..f54e2229a7 100644
> >> --- a/src/gallium/auxiliary/tgsi/tgsi_ureg.c
> >> +++ b/src/gallium/auxiliary/tgsi/tgsi_ureg.c
> >> @@ -140,6 +140,7 @@ struct ureg_program
> >>unsigned first;
> >>unsigned last;
> >>unsigned array_id;
> >> +  unsigned invariant;
> >> } output[UREG_MAX_OUTPUT];
> >> unsigned nr_outputs, nr_output_regs;
> >>
> >> @@ -427,7 +428,8 @@ ureg_DECL_output_layout(struct ureg_program *ureg,
> >>  unsigned index,
> >>  unsigned usage_mask,
> >>  unsigned array_id,
> >> -unsigned array_size)
> >> +unsigned array_size,
> >> +unsigned invariant)
> >>  {
> >> unsigned i;
> >>
> >> @@ -455,6 +457,7 @@ ureg_DECL_output_layout(struct ureg_program *ure

Re: [Mesa-dev] [PATCH mesa] mesa: add missing return in error path

2018-06-18 Thread Iago Toral
Reviewed-by: Iago Toral Quiroga 

On Mon, 2018-06-18 at 11:40 +0100, Eric Engestrom wrote:
> Fixes: 67f40dadaadacd90 "mesa: add support for
> ARB_sample_locations"
> Cc: Rhys Perry 
> Cc: Brian Paul 
> Signed-off-by: Eric Engestrom 
> ---
>  src/mesa/main/fbobject.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
> index 5d7e5d29847dcfdbb23e..fa7a9361dfcfeaa105aa 100644
> --- a/src/mesa/main/fbobject.c
> +++ b/src/mesa/main/fbobject.c
> @@ -4695,9 +4695,11 @@ sample_locations(struct gl_context *ctx,
> struct gl_framebuffer *fb,
> if (!fb->SampleLocationTable) {
>size_t size = MAX_SAMPLE_LOCATION_TABLE_SIZE * 2 *
> sizeof(GLfloat);
>fb->SampleLocationTable = malloc(size);
> -  if (!fb->SampleLocationTable)
> +  if (!fb->SampleLocationTable) {
>   _mesa_error(ctx, GL_OUT_OF_MEMORY,
>   "Cannot allocate sample location table");
> + return;
> +  }
>for (i = 0; i < MAX_SAMPLE_LOCATION_TABLE_SIZE * 2; i++)
>   fb->SampleLocationTable[i] = 0.5f;
> }
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] Plumb invariant output attrib thru TGSI

2018-06-18 Thread Jakob Bornecrantz
On Mon, Jun 18, 2018 at 1:06 PM Elie Tournier  wrote:
>
> On Mon, Jun 18, 2018 at 12:06:42PM +0100, Jakob Bornecrantz wrote:
> > TGSI already has a invariant field on declarations, we are running
> > into a bug with virgl because st_glsl_to_tgsi completely drops the
> > invariant flag on the floor when it comes to declarations (tho precise
> > is added to the ops). But virgl can't express precise ops (only
> > invariant and precise declarations) only declarations.
> >
> > Going to do some testing on this patch soon.
> >
> > Cheers, Jakob.
> Supposing that it doesn't brake any gallium driver.
> Maybe Marek can confirm. I only test on qemu with virgl.
>
> Reviewed-by: Elie Tournier 

Did a run with this patch using r600 on the host and virgl in the
guest, ran the Android GLES[2-3] CTS in the host and the guest, saw no
regressions so patch is
Tested-by: Jakob Bornecrantz 

As Elie said we might want to get somebody else to look at this as
this will no plumb down invariant where it in the past did not.

Cheers, Jakob.

>
> >
> > On Tue, Apr 10, 2018 at 7:02 PM Marek Olšák  wrote:
> > >
> > > This doesn't change TGSI. It only changes utilities around it.
> > >
> > > Marek
> > >
> > > On Mon, Apr 9, 2018 at 6:02 PM, Joe M. Kniss  wrote:
> > >>
> > >> Add support for glsl 'invariant' modifier for output data declarations.
> > >> Gallium drivers that use TGSI serialization currently loose invariant
> > >> modifiers in glsl shaders.
> > >>
> > >> Tested: chromiumos on qemu with virglrenderer.
> > >> Signed-off-by: Joe M. Kniss 
> > >> ---
> > >>  src/gallium/auxiliary/tgsi/tgsi_strings.c  |  2 ++
> > >>  src/gallium/auxiliary/tgsi/tgsi_strings.h  |  2 ++
> > >>  src/gallium/auxiliary/tgsi/tgsi_text.c | 18 +++
> > >>  src/gallium/auxiliary/tgsi/tgsi_ureg.c | 27 ++
> > >>  src/gallium/auxiliary/tgsi/tgsi_ureg.h |  4 +++-
> > >>  src/mesa/state_tracker/st_glsl_to_tgsi.cpp |  8 +--
> > >>  6 files changed, 45 insertions(+), 16 deletions(-)
> > >>
> > >> diff --git a/src/gallium/auxiliary/tgsi/tgsi_strings.c 
> > >> b/src/gallium/auxiliary/tgsi/tgsi_strings.c
> > >> index 4f28b49ce8..434871273f 100644
> > >> --- a/src/gallium/auxiliary/tgsi/tgsi_strings.c
> > >> +++ b/src/gallium/auxiliary/tgsi/tgsi_strings.c
> > >> @@ -185,6 +185,8 @@ const char 
> > >> *tgsi_interpolate_locations[TGSI_INTERPOLATE_LOC_COUNT] =
> > >> "SAMPLE",
> > >>  };
> > >>
> > >> +const char *tgsi_invariant_name = "INVARIANT";
> > >> +
> > >>  const char *tgsi_primitive_names[PIPE_PRIM_MAX] =
> > >>  {
> > >> "POINTS",
> > >> diff --git a/src/gallium/auxiliary/tgsi/tgsi_strings.h 
> > >> b/src/gallium/auxiliary/tgsi/tgsi_strings.h
> > >> index bb2d3458dd..20e3f7127f 100644
> > >> --- a/src/gallium/auxiliary/tgsi/tgsi_strings.h
> > >> +++ b/src/gallium/auxiliary/tgsi/tgsi_strings.h
> > >> @@ -52,6 +52,8 @@ extern const char 
> > >> *tgsi_interpolate_names[TGSI_INTERPOLATE_COUNT];
> > >>
> > >>  extern const char 
> > >> *tgsi_interpolate_locations[TGSI_INTERPOLATE_LOC_COUNT];
> > >>
> > >> +extern const char *tgsi_invariant_name;
> > >> +
> > >>  extern const char *tgsi_primitive_names[PIPE_PRIM_MAX];
> > >>
> > >>  extern const char *tgsi_fs_coord_origin_names[2];
> > >> diff --git a/src/gallium/auxiliary/tgsi/tgsi_text.c 
> > >> b/src/gallium/auxiliary/tgsi/tgsi_text.c
> > >> index 02241a66bf..815b1ee65d 100644
> > >> --- a/src/gallium/auxiliary/tgsi/tgsi_text.c
> > >> +++ b/src/gallium/auxiliary/tgsi/tgsi_text.c
> > >> @@ -1586,10 +1586,6 @@ static boolean parse_declaration( struct 
> > >> translate_ctx *ctx )
> > >>  break;
> > >>   }
> > >>}
> > >> -  if (i == TGSI_INTERPOLATE_COUNT) {
> > >> - report_error( ctx, "Expected semantic or interpolate 
> > >> attribute" );
> > >> - return FALSE;
> > >> -  }
> > >> }
> > >>
> > >> cur = ctx->cur;
> > >> @@ -1609,6 +1605,20 @@ static boolean parse_declaration( struct 
> > >> translate_ctx *ctx )
> > >>}
> > >> }
> > >>
> > >> +   cur = ctx->cur;
> > >> +   eat_opt_white( &cur );
> > >> +   if (*cur == ',' && !is_vs_input) {
> > >> +  cur++;
> > >> +  eat_opt_white( &cur );
> > >> +  if (str_match_nocase_whole( &cur, tgsi_invariant_name )) {
> > >> + decl.Declaration.Invariant = 1;
> > >> + ctx->cur = cur;
> > >> +  } else {
> > >> + report_error( ctx, "Expected semantic, interpolate attribute, 
> > >> or invariant ");
> > >> + return FALSE;
> > >> +  }
> > >> +   }
> > >> +
> > >> advance = tgsi_build_full_declaration(
> > >>&decl,
> > >>ctx->tokens_cur,
> > >> diff --git a/src/gallium/auxiliary/tgsi/tgsi_ureg.c 
> > >> b/src/gallium/auxiliary/tgsi/tgsi_ureg.c
> > >> index 393e015001..f54e2229a7 100644
> > >> --- a/src/gallium/auxiliary/tgsi/tgsi_ureg.c
> > >> +++ b/src/gallium/auxiliary/tgsi/tgsi_ureg.c
> > >> @@ -140,6 +140,7 @@ struct ureg_program
> > >>unsigned first;
> > >>unsigned l

[Mesa-dev] [PATCH] virgl: Remove debugging left-overs

2018-06-18 Thread Tomeu Vizoso
Some fprintfs were probably left unintentionally a few years ago and are
a bit of a nuisance.

Signed-off-by: Tomeu Vizoso 
Cc: Signed-off-by: Rob Herring 
Fixes: 2d3301e4d513 ("virgl: fix reference counting of prime handles")
---
 src/gallium/winsys/virgl/drm/virgl_drm_winsys.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/src/gallium/winsys/virgl/drm/virgl_drm_winsys.c 
b/src/gallium/winsys/virgl/drm/virgl_drm_winsys.c
index fb15708ddb19..aad6430c417d 100644
--- a/src/gallium/winsys/virgl/drm/virgl_drm_winsys.c
+++ b/src/gallium/winsys/virgl/drm/virgl_drm_winsys.c
@@ -417,7 +417,6 @@ virgl_drm_winsys_resource_create_handle(struct virgl_winsys 
*qws,
}
 
res = util_hash_table_get(qdws->bo_handles, (void*)(uintptr_t)handle);
-   fprintf(stderr, "resource %p for handle %d, pfd=%d\n", res, handle, 
whandle->handle);
if (res) {
   struct virgl_hw_res *r = NULL;
   virgl_drm_resource_reference(qdws, &r, res);
@@ -431,7 +430,6 @@ virgl_drm_winsys_resource_create_handle(struct virgl_winsys 
*qws,
if (whandle->type == WINSYS_HANDLE_TYPE_FD) {
   res->bo_handle = handle;
} else {
-  fprintf(stderr, "gem open handle %d\n", handle);
   memset(&open_arg, 0, sizeof(open_arg));
   open_arg.name = whandle->handle;
   if (drmIoctl(qdws->fd, DRM_IOCTL_GEM_OPEN, &open_arg)) {
-- 
2.17.0

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


[Mesa-dev] [PATCH] i965: Advertise 8 bits subpixel precision for viewport bounds on gen6+

2018-06-18 Thread Danylo Piliaiev
We use floating-points for viewport bounds so VIEWPORT_SUBPIXEL_BITS
should reflect this.

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

Signed-off-by: Danylo Piliaiev 
---
 src/mesa/drivers/dri/i965/brw_context.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/brw_context.c 
b/src/mesa/drivers/dri/i965/brw_context.c
index 9ced230..eacf326 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -688,7 +688,7 @@ brw_initialize_context_constants(struct brw_context *brw)
/* ARB_viewport_array, OES_viewport_array */
if (devinfo->gen >= 6) {
   ctx->Const.MaxViewports = GEN6_NUM_VIEWPORTS;
-  ctx->Const.ViewportSubpixelBits = 0;
+  ctx->Const.ViewportSubpixelBits = 8;
 
   /* Cast to float before negating because MaxViewportWidth is unsigned.
*/
-- 
2.7.4

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


[Mesa-dev] [PATCH] swr: bump minimum supported LLVM version to 5.0

2018-06-18 Thread Juan A. Suarez Romero
RADV now requires LLVM 5.0 or greater, and thus we can't build dist
tarball because swr requires LLVM 4.0.

Let's bump required LLVM to 5.0 in swr too.

Fixes: f9eb1ef870 ("amd: remove support for LLVM 4.0")
Cc: George Kyriazis 
Cc: Tim Rowley 
Cc: Emil Velikov 
Cc: Dylan Baker 
Cc: Eric Engestrom 
---
 .travis.yml | 12 ++--
 configure.ac|  7 ---
 meson.build |  4 +---
 src/gallium/drivers/swr/Makefile.am |  6 +++---
 src/gallium/drivers/swr/SConscript  |  4 ++--
 5 files changed, 16 insertions(+), 17 deletions(-)

diff --git a/.travis.yml b/.travis.yml
index b1fc7de9587..c9a30fa0ef5 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -92,7 +92,7 @@ matrix:
 - BUILD=make
 - MAKEFLAGS="-j4"
 - MAKE_CHECK_COMMAND="true"
-- LLVM_VERSION=4.0
+- LLVM_VERSION=5.0
 - LLVM_CONFIG="llvm-config-${LLVM_VERSION}"
 - OVERRIDE_CC="gcc-4.8"
 - OVERRIDE_CXX="g++-4.8"
@@ -105,12 +105,12 @@ matrix:
   addons:
 apt:
   sources:
-- llvm-toolchain-trusty-4.0
+- llvm-toolchain-trusty-5.0
   packages:
 # LLVM packaging is broken and misses these dependencies
 - libedit-dev
 # From sources above
-- llvm-4.0-dev
+- llvm-5.0-dev
 # Common
 - xz-utils
 - x11proto-xf86vidmode-dev
@@ -432,7 +432,7 @@ matrix:
 - BUILD=scons
 - SCONSFLAGS="-j4"
 - SCONS_TARGET="swr=1"
-- LLVM_VERSION=4.0
+- LLVM_VERSION=5.0
 - LLVM_CONFIG="llvm-config-${LLVM_VERSION}"
 # Keep it symmetrical to the make build. There's no actual SWR, yet.
 - SCONS_CHECK_COMMAND="true"
@@ -441,13 +441,13 @@ matrix:
   addons:
 apt:
   sources:
-- llvm-toolchain-trusty-4.0
+- llvm-toolchain-trusty-5.0
   packages:
 - scons
 # LLVM packaging is broken and misses these dependencies
 - libedit-dev
 # From sources above
-- llvm-4.0-dev
+- llvm-5.0-dev
 # Common
 - xz-utils
 - x11proto-xf86vidmode-dev
diff --git a/configure.ac b/configure.ac
index 7a0e4754208..543b6fe061b 100644
--- a/configure.ac
+++ b/configure.ac
@@ -110,7 +110,7 @@ LLVM_REQUIRED_OPENCL=3.9.0
 LLVM_REQUIRED_R600=3.9.0
 LLVM_REQUIRED_RADEONSI=5.0.0
 LLVM_REQUIRED_RADV=5.0.0
-LLVM_REQUIRED_SWR=4.0.0
+LLVM_REQUIRED_SWR=5.0.0
 
 dnl Check for progs
 AC_PROG_CPP
@@ -2755,8 +2755,9 @@ if test -n "$with_gallium_drivers"; then
 fi
 
 # XXX: Keep in sync with LLVM_REQUIRED_SWR
-AM_CONDITIONAL(SWR_INVALID_LLVM_VERSION, test "x$LLVM_VERSION" != x4.0.0 -a \
-  "x$LLVM_VERSION" != x4.0.1)
+AM_CONDITIONAL(SWR_INVALID_LLVM_VERSION, test "x$LLVM_VERSION" != x5.0.0 -a \
+  "x$LLVM_VERSION" != x5.0.1 -a \
+  "x$LLVM_VERSION" != x5.0.2)
 
 if test "x$enable_llvm" = "xyes" -a "$with_gallium_drivers"; then
 llvm_require_version $LLVM_REQUIRED_GALLIUM "gallium"
diff --git a/meson.build b/meson.build
index 65ae32172d2..a5662160d66 100644
--- a/meson.build
+++ b/meson.build
@@ -1130,10 +1130,8 @@ if with_gallium_opencl
   llvm_optional_modules += ['coroutines', 'opencl']
 endif
 
-if with_amd_vk or with_gallium_radeonsi
+if with_amd_vk or with_gallium_radeonsi or with_gallium_swr
   _llvm_version = '>= 5.0.0'
-elif with_gallium_swr
-  _llvm_version = '>= 4.0.0'
 elif with_gallium_opencl or with_gallium_r600
   _llvm_version = '>= 3.9.0'
 else
diff --git a/src/gallium/drivers/swr/Makefile.am 
b/src/gallium/drivers/swr/Makefile.am
index 8b3150288e6..5cc3f77478a 100644
--- a/src/gallium/drivers/swr/Makefile.am
+++ b/src/gallium/drivers/swr/Makefile.am
@@ -374,9 +374,9 @@ include $(top_srcdir)/install-gallium-links.mk
 # created with the oldest supported version of LLVM.
 dist-hook:
 if SWR_INVALID_LLVM_VERSION
-   @echo "***"
-   @echo "LLVM 4.0.0 or LLVM 4.0.1 required to create the tarball"
-   @echo "***"
+   @echo "*"
+   @echo "LLVM 5.0.x required to create the tarball"
+   @echo "*"
@test
 endif
 
diff --git a/src/gallium/drivers/swr/SConscript 
b/src/gallium/drivers/swr/SConscript
index 528cfac39f6..224372eb3f5 100644
--- a/src/gallium/drivers/swr/SConscript
+++ b/src/gallium/drivers/swr/SConscript
@@ -12,8 +12,8 @@ if not env['llvm']:
 env['swr'] = False
 Return()
 
-if env['LLVM_VERSION'] < distutils.version.LooseVersion('4.0'):
-print("warning: swr requires LLVM >= 4.0: not building swr")
+if env['LLVM_VERSION'] < distutils.version.LooseVersion('5.0'):
+print("

Re: [Mesa-dev] [PATCH] i965: Advertise 8 bits subpixel precision for viewport bounds on gen6+

2018-06-18 Thread Lionel Landwerlin

Hey Danylo,

Thanks for this patch.
I'm not really an expert here but my understanding is that it should 
reflect the number of bits in fixed point precision.

We use 32bits floats in the packets sent to the hardware.
Quoting the spec :

"If the implementation truely has floating point viewport bounds, it may 
report a sufficiently high value to indicate this. "


Maybe we should use something a bit bigger than 8?

Cheers,

-
Lionel

On 18/06/18 13:50, Danylo Piliaiev wrote:

We use floating-points for viewport bounds so VIEWPORT_SUBPIXEL_BITS
should reflect this.

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

Signed-off-by: Danylo Piliaiev 
---
  src/mesa/drivers/dri/i965/brw_context.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/brw_context.c 
b/src/mesa/drivers/dri/i965/brw_context.c
index 9ced230..eacf326 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -688,7 +688,7 @@ brw_initialize_context_constants(struct brw_context *brw)
 /* ARB_viewport_array, OES_viewport_array */
 if (devinfo->gen >= 6) {
ctx->Const.MaxViewports = GEN6_NUM_VIEWPORTS;
-  ctx->Const.ViewportSubpixelBits = 0;
+  ctx->Const.ViewportSubpixelBits = 8;
  
/* Cast to float before negating because MaxViewportWidth is unsigned.

 */



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


Re: [Mesa-dev] [PATCH mesa] gallium: simplify util_format_is_supported()

2018-06-18 Thread Matt Turner
On Mon, Jun 18, 2018 at 3:15 AM Eric Engestrom  wrote:
>
> As of 66673bef941af344314f ("mesa: Unconditionally enable floating-point
> textures"), the `bind` argument is no longer used, and the format check
> is now a simple enum range check, so inline it and remove the
> unnecessary argument from callers.
>
> Cc: Timothy Arceri 
> Cc: Matt Turner 
> Cc: Ian Romanick 
> Signed-off-by: Eric Engestrom 
> ---
>  src/gallium/auxiliary/util/u_format.c   | 12 
>  src/gallium/auxiliary/util/u_format.h   |  7 +--
>  src/gallium/drivers/freedreno/a2xx/fd2_screen.c |  2 +-
>  src/gallium/drivers/freedreno/a3xx/fd3_screen.c |  2 +-
>  src/gallium/drivers/freedreno/a4xx/fd4_screen.c |  2 +-
>  src/gallium/drivers/freedreno/a5xx/fd5_screen.c |  2 +-
>  src/gallium/drivers/i915/i915_screen.c  |  2 +-
>  src/gallium/drivers/nouveau/nv30/nv30_screen.c  |  2 +-
>  src/gallium/drivers/nouveau/nv50/nv50_screen.c  |  2 +-
>  src/gallium/drivers/nouveau/nvc0/nvc0_screen.c  |  2 +-
>  src/gallium/drivers/r300/r300_screen.c  |  2 +-
>  src/gallium/drivers/r600/evergreen_state.c  |  2 +-
>  src/gallium/drivers/r600/r600_state.c   |  2 +-
>  src/gallium/drivers/radeonsi/si_state.c |  2 +-
>  src/gallium/drivers/v3d/v3d_screen.c|  2 +-
>  src/gallium/drivers/vc4/vc4_screen.c|  2 +-
>  16 files changed, 19 insertions(+), 28 deletions(-)
>
> diff --git a/src/gallium/auxiliary/util/u_format.c 
> b/src/gallium/auxiliary/util/u_format.c
> index e0325e9c534974b15c65..d82d00a9d06fde2daeef 100644
> --- a/src/gallium/auxiliary/util/u_format.c
> +++ b/src/gallium/auxiliary/util/u_format.c
> @@ -235,18 +235,6 @@ util_format_is_subsampled_422(enum pipe_format format)
>desc->block.bits == 32;
>  }
>
> -boolean
> -util_format_is_supported(enum pipe_format format, unsigned bind)
> -{
> -   if (format >= PIPE_FORMAT_COUNT) {
> -  return FALSE;
> -   }
> -
> -   (void)bind;
> -
> -   return TRUE;
> -}
> -
>
>  /**
>   * Calculates the MRD for the depth format. MRD is used in depth bias
> diff --git a/src/gallium/auxiliary/util/u_format.h 
> b/src/gallium/auxiliary/util/u_format.h
> index e497b4b3375a57771009..9c5df967b6c01288d0b3 100644
> --- a/src/gallium/auxiliary/util/u_format.h
> +++ b/src/gallium/auxiliary/util/u_format.h
> @@ -721,8 +721,11 @@ util_is_format_compatible(const struct 
> util_format_description *src_desc,
>   * Whether the format is supported by Gallium for the given bindings.
>   * This covers S3TC textures and floating-point render targets.

I suspect this line was here because these two things might not be
available. But now they are :)

I think this line should be removed.

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


[Mesa-dev] [PATCH 2/2] ac/surface: Set compressZ for stencil-only surfaces.

2018-06-18 Thread Bas Nieuwenhuizen
We HTILE compress stencil-only surfaces too.

CC: 18.1 
---
 src/amd/common/ac_surface.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/amd/common/ac_surface.c b/src/amd/common/ac_surface.c
index 6600ff6b7ef..618b755afc7 100644
--- a/src/amd/common/ac_surface.c
+++ b/src/amd/common/ac_surface.c
@@ -670,7 +670,7 @@ static int gfx6_compute_surface(ADDR_HANDLE addrlib,
 config->info.levels == 1);
 
AddrSurfInfoIn.flags.noStencil = (surf->flags & RADEON_SURF_SBUFFER) == 
0;
-   AddrSurfInfoIn.flags.compressZ = AddrSurfInfoIn.flags.depth;
+   AddrSurfInfoIn.flags.compressZ = !!(surf->flags & 
RADEON_SURF_Z_OR_SBUFFER);
 
/* On CI/VI, the DB uses the same pitch and tile mode (except tilesplit)
 * for Z and stencil. This can cause a number of problems which we work
-- 
2.17.1

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


[Mesa-dev] [PATCH 1/2] amd/addrlib: Use correct tile index for S8 on SI.

2018-06-18 Thread Bas Nieuwenhuizen
Tile index 3 is "16 bpp depth PRT (non-MSAA), don't support
uncompressed depth" while tile index 0 is "non-AA compressed depth
or any stencil" per the comments at the top of the file.

On my Cape Verde this caused assertions due to the bank height of
tile index 3 being too low. (2 while needs to be aligned to 4).

AMDVLK probably did not hit this because it always sets compressZ
by default.

CC: Marek Olšák 
---
 src/amd/addrlib/r800/siaddrlib.cpp | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/amd/addrlib/r800/siaddrlib.cpp 
b/src/amd/addrlib/r800/siaddrlib.cpp
index bc009f5aff0..55217678254 100644
--- a/src/amd/addrlib/r800/siaddrlib.cpp
+++ b/src/amd/addrlib/r800/siaddrlib.cpp
@@ -2037,7 +2037,7 @@ VOID SiLib::HwlSetupTileInfo(
 ADDR_ASSERT(numSamples == 4);
 
 if (flags.depth)
-{
+{pTileInfo->bankHeight, bankHeightAlign
 switch (bpp)
 {
 case 16:
@@ -2097,7 +2097,7 @@ VOID SiLib::HwlSetupTileInfo(
 break;
 case 8:
 index = 2;
-break;
+break;pTileInfo->bankHeight, bankHeightAlign
 default:
 break;
 }
@@ -2105,7 +2105,7 @@ VOID SiLib::HwlSetupTileInfo(
 }
 else // unCompressZ
 {
-index = 3;
+index = 0;
 }
 }
 else //non PRT & non Depth & non Stencil
-- 
2.17.1

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


Re: [Mesa-dev] [PATCH mesa] gallium: simplify util_format_is_supported()

2018-06-18 Thread Eric Engestrom
On Monday, 2018-06-18 07:31:49 -0700, Matt Turner wrote:
> On Mon, Jun 18, 2018 at 3:15 AM Eric Engestrom  
> wrote:
> >
> > As of 66673bef941af344314f ("mesa: Unconditionally enable floating-point
> > textures"), the `bind` argument is no longer used, and the format check
> > is now a simple enum range check, so inline it and remove the
> > unnecessary argument from callers.
> >
> > Cc: Timothy Arceri 
> > Cc: Matt Turner 
> > Cc: Ian Romanick 
> > Signed-off-by: Eric Engestrom 
> > ---
> >  src/gallium/auxiliary/util/u_format.c   | 12 
> >  src/gallium/auxiliary/util/u_format.h   |  7 +--
> >  src/gallium/drivers/freedreno/a2xx/fd2_screen.c |  2 +-
> >  src/gallium/drivers/freedreno/a3xx/fd3_screen.c |  2 +-
> >  src/gallium/drivers/freedreno/a4xx/fd4_screen.c |  2 +-
> >  src/gallium/drivers/freedreno/a5xx/fd5_screen.c |  2 +-
> >  src/gallium/drivers/i915/i915_screen.c  |  2 +-
> >  src/gallium/drivers/nouveau/nv30/nv30_screen.c  |  2 +-
> >  src/gallium/drivers/nouveau/nv50/nv50_screen.c  |  2 +-
> >  src/gallium/drivers/nouveau/nvc0/nvc0_screen.c  |  2 +-
> >  src/gallium/drivers/r300/r300_screen.c  |  2 +-
> >  src/gallium/drivers/r600/evergreen_state.c  |  2 +-
> >  src/gallium/drivers/r600/r600_state.c   |  2 +-
> >  src/gallium/drivers/radeonsi/si_state.c |  2 +-
> >  src/gallium/drivers/v3d/v3d_screen.c|  2 +-
> >  src/gallium/drivers/vc4/vc4_screen.c|  2 +-
> >  16 files changed, 19 insertions(+), 28 deletions(-)
> >
> > diff --git a/src/gallium/auxiliary/util/u_format.c 
> > b/src/gallium/auxiliary/util/u_format.c
> > index e0325e9c534974b15c65..d82d00a9d06fde2daeef 100644
> > --- a/src/gallium/auxiliary/util/u_format.c
> > +++ b/src/gallium/auxiliary/util/u_format.c
> > @@ -235,18 +235,6 @@ util_format_is_subsampled_422(enum pipe_format format)
> >desc->block.bits == 32;
> >  }
> >
> > -boolean
> > -util_format_is_supported(enum pipe_format format, unsigned bind)
> > -{
> > -   if (format >= PIPE_FORMAT_COUNT) {
> > -  return FALSE;
> > -   }
> > -
> > -   (void)bind;
> > -
> > -   return TRUE;
> > -}
> > -
> >
> >  /**
> >   * Calculates the MRD for the depth format. MRD is used in depth bias
> > diff --git a/src/gallium/auxiliary/util/u_format.h 
> > b/src/gallium/auxiliary/util/u_format.h
> > index e497b4b3375a57771009..9c5df967b6c01288d0b3 100644
> > --- a/src/gallium/auxiliary/util/u_format.h
> > +++ b/src/gallium/auxiliary/util/u_format.h
> > @@ -721,8 +721,11 @@ util_is_format_compatible(const struct 
> > util_format_description *src_desc,
> >   * Whether the format is supported by Gallium for the given bindings.
> >   * This covers S3TC textures and floating-point render targets.
> 
> I suspect this line was here because these two things might not be
> available. But now they are :)
> 
> I think this line should be removed.

Thanks! Done, as well as removing "for the given bindings".

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


[Mesa-dev] [PATCH v2 1/2] amd/addrlib: Use correct tile index for S8 on SI.

2018-06-18 Thread Bas Nieuwenhuizen
Tile index 3 is "16 bpp depth PRT (non-MSAA), don't support
uncompressed depth" while tile index 0 is "non-AA compressed depth
or any stencil" per the comments at the top of the file.

On my Cape Verde this caused assertions due to the bank height of
tile index 3 being too low. (2 while needs to be aligned to 4).

AMDVLK probably did not hit this because it always sets compressZ
by default.

v2: Removed some garbage pastes (Ilia Mirkin)

CC: Marek Olšák 
---
 src/amd/addrlib/r800/siaddrlib.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/amd/addrlib/r800/siaddrlib.cpp 
b/src/amd/addrlib/r800/siaddrlib.cpp
index bc009f5aff0..79ae940b4c8 100644
--- a/src/amd/addrlib/r800/siaddrlib.cpp
+++ b/src/amd/addrlib/r800/siaddrlib.cpp
@@ -2105,7 +2105,7 @@ VOID SiLib::HwlSetupTileInfo(
 }
 else // unCompressZ
 {
-index = 3;
+index = 0;
 }
 }
 else //non PRT & non Depth & non Stencil
-- 
2.17.1

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


[Mesa-dev] [PATCH] freedreno: add initial a20x support

2018-06-18 Thread Jonathan Marek
the bare minimum to get a20x running with kmscube and some glmark2 scenes:
different CP_DRAW_INDX format and the different clear color register

Signed-off-by: Jonathan Marek 
---
 src/gallium/drivers/freedreno/a2xx/fd2_draw.c | 15 +++--
 src/gallium/drivers/freedreno/a2xx/fd2_emit.c | 10 ++
 .../drivers/freedreno/freedreno_draw.h| 32 ---
 .../drivers/freedreno/freedreno_screen.c  |  1 +
 .../drivers/freedreno/freedreno_screen.h  |  6 
 5 files changed, 50 insertions(+), 14 deletions(-)

diff --git a/src/gallium/drivers/freedreno/a2xx/fd2_draw.c 
b/src/gallium/drivers/freedreno/a2xx/fd2_draw.c
index ef9daddfcf..c12047628c 100644
--- a/src/gallium/drivers/freedreno/a2xx/fd2_draw.c
+++ b/src/gallium/drivers/freedreno/a2xx/fd2_draw.c
@@ -155,9 +155,18 @@ fd2_clear(struct fd_context *ctx, unsigned buffers,
OUT_PKT0(ring, REG_A2XX_TC_CNTL_STATUS, 1);
OUT_RING(ring, A2XX_TC_CNTL_STATUS_L2_INVALIDATE);
 
-   OUT_PKT3(ring, CP_SET_CONSTANT, 2);
-   OUT_RING(ring, CP_REG(REG_A2XX_CLEAR_COLOR));
-   OUT_RING(ring, colr);
+   if (is_a20x(ctx->screen)) {
+   OUT_PKT3(ring, CP_SET_CONSTANT, 5);
+   OUT_RING(ring, 0x0480);
+   OUT_RING(ring, color->ui[0]);
+   OUT_RING(ring, color->ui[1]);
+   OUT_RING(ring, color->ui[2]);
+   OUT_RING(ring, color->ui[3]);
+   } else {
+   OUT_PKT3(ring, CP_SET_CONSTANT, 2);
+   OUT_RING(ring, CP_REG(REG_A2XX_CLEAR_COLOR));
+   OUT_RING(ring, colr);
+   }
 
OUT_PKT3(ring, CP_SET_CONSTANT, 2);
OUT_RING(ring, CP_REG(REG_A2XX_A220_RB_LRZ_VSC_CONTROL));
diff --git a/src/gallium/drivers/freedreno/a2xx/fd2_emit.c 
b/src/gallium/drivers/freedreno/a2xx/fd2_emit.c
index 6927fa87fd..2b28bb23a3 100644
--- a/src/gallium/drivers/freedreno/a2xx/fd2_emit.c
+++ b/src/gallium/drivers/freedreno/a2xx/fd2_emit.c
@@ -415,6 +415,16 @@ fd2_emit_state_for_clear(struct fd_context *ctx)
 void
 fd2_emit_restore(struct fd_context *ctx, struct fd_ringbuffer *ring)
 {
+   if (is_a20x(ctx->screen)) {
+   OUT_PKT0(ring, REG_A2XX_RB_BC_CONTROL, 1);
+   OUT_RING(ring,
+   A2XX_RB_BC_CONTROL_ACCUM_TIMEOUT_SELECT(3) |
+   A2XX_RB_BC_CONTROL_DISABLE_LZ_NULL_ZCMD_DROP |
+   A2XX_RB_BC_CONTROL_ENABLE_CRC_UPDATE |
+   A2XX_RB_BC_CONTROL_ACCUM_DATA_FIFO_LIMIT(8) |
+   A2XX_RB_BC_CONTROL_MEM_EXPORT_TIMEOUT_SELECT(3));
+   }
+
OUT_PKT0(ring, REG_A2XX_TP0_CHICKEN, 1);
OUT_RING(ring, 0x0002);
 
diff --git a/src/gallium/drivers/freedreno/freedreno_draw.h 
b/src/gallium/drivers/freedreno/freedreno_draw.h
index b293f73b82..ec4b47898d 100644
--- a/src/gallium/drivers/freedreno/freedreno_draw.h
+++ b/src/gallium/drivers/freedreno/freedreno_draw.h
@@ -51,6 +51,8 @@ fd_draw(struct fd_batch *batch, struct fd_ringbuffer *ring,
uint32_t idx_size, uint32_t idx_offset,
struct pipe_resource *idx_buffer)
 {
+   uint32_t cnt, draw;
+
/* for debug after a lock up, write a unique counter value
 * to scratch7 for each draw, to make it easier to match up
 * register dumps to cmdstream.  The combination of IB
@@ -74,18 +76,26 @@ fd_draw(struct fd_batch *batch, struct fd_ringbuffer *ring,
OUT_RING(ring, 0);
}
 
-   OUT_PKT3(ring, CP_DRAW_INDX, idx_buffer ? 5 : 3);
-   OUT_RING(ring, 0x);/* viz query info. */
-   if (vismode == USE_VISIBILITY) {
-   /* leave vis mode blank for now, it will be patched up when
-* we know if we are binning or not
-*/
-   OUT_RINGP(ring, DRAW(primtype, src_sel, idx_type, 0, instances),
-   &batch->draw_patches);
-   } else {
-   OUT_RING(ring, DRAW(primtype, src_sel, idx_type, vismode, 
instances));
+   cnt = idx_buffer ? 5 : 3;
+   draw = DRAW(primtype, src_sel, idx_type, 0, instances);
+
+   if (is_a20x(batch->ctx->screen)) {
+   /* XXX instances field is overwritten */
+   draw &= 0x;
+   draw |= count << 16;
+   cnt -= 1;
}
-   OUT_RING(ring, count); /* NumIndices */
+
+   OUT_PKT3(ring, CP_DRAW_INDX, cnt);
+   OUT_RING(ring, 0x);/* viz query info. */
+   if (vismode == USE_VISIBILITY)
+   OUT_RINGP(ring, draw, &batch->draw_patches);
+   else
+   OUT_RING(ring, draw | DRAW(0, 0, 0, vismode, 0));
+
+   if (!is_a20x(batch->ctx->screen))
+   OUT_RING(ring, count);/* NumIndices */
+
if (idx_buffer) {
OUT_RELOC(ring, fd_resource(idx_buffer)->bo, idx_offset, 0, 0);
OUT_RING (ring, idx_size);
diff --git a/src/gallium/drivers/freedreno/freedreno_screen.c 
b/

[Mesa-dev] [PATCH] freedreno: a2xx: fix clear color

2018-06-18 Thread Jonathan Marek
the format of the CLEAR_COLOR register doesn't depend on the target format
this fixes clear color when rendering to 32-bit RGBA and 16-bit targets

Signed-off-by: Jonathan Marek 
---
 src/gallium/drivers/freedreno/a2xx/fd2_draw.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/freedreno/a2xx/fd2_draw.c 
b/src/gallium/drivers/freedreno/a2xx/fd2_draw.c
index c12047628c..2d3c029e57 100644
--- a/src/gallium/drivers/freedreno/a2xx/fd2_draw.c
+++ b/src/gallium/drivers/freedreno/a2xx/fd2_draw.c
@@ -133,7 +133,7 @@ fd2_clear(struct fd_context *ctx, unsigned buffers,
uint32_t reg, colr = 0;
 
if ((buffers & PIPE_CLEAR_COLOR) && fb->nr_cbufs)
-   colr  = pack_rgba(fb->cbufs[0]->format, color->f);
+   colr = pack_rgba(PIPE_FORMAT_R8G8B8A8_UNORM, color->f);
 
/* emit generic state for clear now: */
fd2_emit_state_for_clear(ctx);
-- 
2.17.1

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


Re: [Mesa-dev] [PATCH] swr: bump minimum supported LLVM version to 5.0

2018-06-18 Thread Eric Engestrom
On Monday, 2018-06-18 16:23:41 +0200, Juan A. Suarez Romero wrote:
> RADV now requires LLVM 5.0 or greater, and thus we can't build dist
> tarball because swr requires LLVM 4.0.
> 
> Let's bump required LLVM to 5.0 in swr too.
> 
> Fixes: f9eb1ef870 ("amd: remove support for LLVM 4.0")
> Cc: George Kyriazis 
> Cc: Tim Rowley 
> Cc: Emil Velikov 
> Cc: Dylan Baker 
> Cc: Eric Engestrom 

s/imgtec/intel/ :)
(I moved)

> ---
>  .travis.yml | 12 ++--
>  configure.ac|  7 ---
>  meson.build |  4 +---
>  src/gallium/drivers/swr/Makefile.am |  6 +++---
>  src/gallium/drivers/swr/SConscript  |  4 ++--
>  5 files changed, 16 insertions(+), 17 deletions(-)
> 
> diff --git a/.travis.yml b/.travis.yml
> index b1fc7de9587..c9a30fa0ef5 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -92,7 +92,7 @@ matrix:
>  - BUILD=make
>  - MAKEFLAGS="-j4"
>  - MAKE_CHECK_COMMAND="true"
> -- LLVM_VERSION=4.0
> +- LLVM_VERSION=5.0
>  - LLVM_CONFIG="llvm-config-${LLVM_VERSION}"
>  - OVERRIDE_CC="gcc-4.8"
>  - OVERRIDE_CXX="g++-4.8"
> @@ -105,12 +105,12 @@ matrix:
>addons:
>  apt:
>sources:
> -- llvm-toolchain-trusty-4.0
> +- llvm-toolchain-trusty-5.0
>packages:
>  # LLVM packaging is broken and misses these dependencies
>  - libedit-dev
>  # From sources above
> -- llvm-4.0-dev
> +- llvm-5.0-dev
>  # Common
>  - xz-utils
>  - x11proto-xf86vidmode-dev
> @@ -432,7 +432,7 @@ matrix:
>  - BUILD=scons
>  - SCONSFLAGS="-j4"
>  - SCONS_TARGET="swr=1"
> -- LLVM_VERSION=4.0
> +- LLVM_VERSION=5.0
>  - LLVM_CONFIG="llvm-config-${LLVM_VERSION}"
>  # Keep it symmetrical to the make build. There's no actual SWR, yet.
>  - SCONS_CHECK_COMMAND="true"
> @@ -441,13 +441,13 @@ matrix:
>addons:
>  apt:
>sources:
> -- llvm-toolchain-trusty-4.0
> +- llvm-toolchain-trusty-5.0
>packages:
>  - scons
>  # LLVM packaging is broken and misses these dependencies
>  - libedit-dev
>  # From sources above
> -- llvm-4.0-dev
> +- llvm-5.0-dev
>  # Common
>  - xz-utils
>  - x11proto-xf86vidmode-dev
> diff --git a/configure.ac b/configure.ac
> index 7a0e4754208..543b6fe061b 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -110,7 +110,7 @@ LLVM_REQUIRED_OPENCL=3.9.0
>  LLVM_REQUIRED_R600=3.9.0
>  LLVM_REQUIRED_RADEONSI=5.0.0
>  LLVM_REQUIRED_RADV=5.0.0
> -LLVM_REQUIRED_SWR=4.0.0
> +LLVM_REQUIRED_SWR=5.0.0
>  
>  dnl Check for progs
>  AC_PROG_CPP
> @@ -2755,8 +2755,9 @@ if test -n "$with_gallium_drivers"; then
>  fi
>  
>  # XXX: Keep in sync with LLVM_REQUIRED_SWR
> -AM_CONDITIONAL(SWR_INVALID_LLVM_VERSION, test "x$LLVM_VERSION" != x4.0.0 -a \
> -  "x$LLVM_VERSION" != x4.0.1)
> +AM_CONDITIONAL(SWR_INVALID_LLVM_VERSION, test "x$LLVM_VERSION" != x5.0.0 -a \
> +  "x$LLVM_VERSION" != x5.0.1 -a \
> +  "x$LLVM_VERSION" != x5.0.2)

That check seems designed to break every time something in mesa changes
supported llvm version. Is there a reason for it not to be a simple
`>= 4.0` check?

That's the hunk that was causing issues, wasn't it? Everything else in
this patch is just to keep the same version number everywhere?

Other than that, the patch itself looks reasonable, so given a good
answer to "why is this so fragile?", you can have my:
Reviewed-by: Eric Engestrom 

Otherwise, I would prefer to just turn the autotools check into
a `>= 4.0` like everything else does.

>  
>  if test "x$enable_llvm" = "xyes" -a "$with_gallium_drivers"; then
>  llvm_require_version $LLVM_REQUIRED_GALLIUM "gallium"
> diff --git a/meson.build b/meson.build
> index 65ae32172d2..a5662160d66 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -1130,10 +1130,8 @@ if with_gallium_opencl
>llvm_optional_modules += ['coroutines', 'opencl']
>  endif
>  
> -if with_amd_vk or with_gallium_radeonsi
> +if with_amd_vk or with_gallium_radeonsi or with_gallium_swr
>_llvm_version = '>= 5.0.0'
> -elif with_gallium_swr
> -  _llvm_version = '>= 4.0.0'
>  elif with_gallium_opencl or with_gallium_r600
>_llvm_version = '>= 3.9.0'
>  else
> diff --git a/src/gallium/drivers/swr/Makefile.am 
> b/src/gallium/drivers/swr/Makefile.am
> index 8b3150288e6..5cc3f77478a 100644
> --- a/src/gallium/drivers/swr/Makefile.am
> +++ b/src/gallium/drivers/swr/Makefile.am
> @@ -374,9 +374,9 @@ include $(top_srcdir)/install-gallium-links.mk
>  # created with the oldest supported version of LLVM.
>  dist-hook:
>  if SWR_INVALID_LLVM_VERSION
> - @echo "

[Mesa-dev] [Bug 106955] Mesa 18.1.2 not tagged in git

2018-06-18 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=106955

Bug ID: 106955
   Summary: Mesa 18.1.2 not tagged in git
   Product: Mesa
   Version: git
  Hardware: Other
OS: All
Status: NEW
  Severity: minor
  Priority: medium
 Component: Other
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: jo...@lunarg.com
QA Contact: mesa-dev@lists.freedesktop.org

For GIT, the repo at https://cgit.freedesktop.org/mesa/mesa/ ; I don't see mesa
18.1.2 tagged but it seems to be officially announced.

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


Re: [Mesa-dev] [PATCH mesa] radv: fix reported number of available VGPRs

2018-06-18 Thread Alex Smith
Reviewed-by: Alex Smith 

On 15 June 2018 at 17:52, Eric Engestrom  wrote:

> It's a bit late to round up after an integer division.
>
> Fixes: de889794134e6245e08a2 "radv: Implement VK_AMD_shader_info"
> Cc: Alex Smith 
> Signed-off-by: Eric Engestrom 
> ---
>  src/amd/vulkan/radv_shader.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/amd/vulkan/radv_shader.c b/src/amd/vulkan/radv_shader.c
> index 76790a19047a86abdad5..b31eb9bfda5e9e29e115 100644
> --- a/src/amd/vulkan/radv_shader.c
> +++ b/src/amd/vulkan/radv_shader.c
> @@ -808,7 +808,7 @@ radv_GetShaderInfoAMD(VkDevice _device,
> unsigned workgroup_size = local_size[0] *
> local_size[1] * local_size[2];
>
> statistics.numAvailableVgprs =
> statistics.numPhysicalVgprs /
> -
> ceil(workgroup_size / statistics.numPhysicalVgprs);
> +
> ceil((double)workgroup_size / statistics.numPhysicalVgprs);
>
> statistics.computeWorkGroupSize[0] =
> local_size[0];
> statistics.computeWorkGroupSize[1] =
> local_size[1];
> --
> Cheers,
>   Eric
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH v2 1/2] amd/addrlib: Use correct tile index for S8 on SI.

2018-06-18 Thread Marek Olšák
Do you need this if you set compressZ = true for stencil?

Marek

On Mon, Jun 18, 2018 at 11:00 AM, Bas Nieuwenhuizen  wrote:

> Tile index 3 is "16 bpp depth PRT (non-MSAA), don't support
> uncompressed depth" while tile index 0 is "non-AA compressed depth
> or any stencil" per the comments at the top of the file.
>
> On my Cape Verde this caused assertions due to the bank height of
> tile index 3 being too low. (2 while needs to be aligned to 4).
>
> AMDVLK probably did not hit this because it always sets compressZ
> by default.
>
> v2: Removed some garbage pastes (Ilia Mirkin)
>
> CC: Marek Olšák 
> ---
>  src/amd/addrlib/r800/siaddrlib.cpp | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/amd/addrlib/r800/siaddrlib.cpp b/src/amd/addrlib/r800/
> siaddrlib.cpp
> index bc009f5aff0..79ae940b4c8 100644
> --- a/src/amd/addrlib/r800/siaddrlib.cpp
> +++ b/src/amd/addrlib/r800/siaddrlib.cpp
> @@ -2105,7 +2105,7 @@ VOID SiLib::HwlSetupTileInfo(
>  }
>  else // unCompressZ
>  {
> -index = 3;
> +index = 0;
>  }
>  }
>  else //non PRT & non Depth & non Stencil
> --
> 2.17.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH v2 1/2] amd/addrlib: Use correct tile index for S8 on SI.

2018-06-18 Thread Bas Nieuwenhuizen
On Mon, Jun 18, 2018 at 6:08 PM, Marek Olšák  wrote:
> Do you need this if you set compressZ = true for stencil?

Technically not, then you don't hit the path anymore. Anyway even
though neither AMDVLK or RADV anymore if we do that, it still bugged
me that the index is wrong.

- Bas

>
> Marek
>
> On Mon, Jun 18, 2018 at 11:00 AM, Bas Nieuwenhuizen
>  wrote:
>>
>> Tile index 3 is "16 bpp depth PRT (non-MSAA), don't support
>> uncompressed depth" while tile index 0 is "non-AA compressed depth
>> or any stencil" per the comments at the top of the file.
>>
>> On my Cape Verde this caused assertions due to the bank height of
>> tile index 3 being too low. (2 while needs to be aligned to 4).
>>
>> AMDVLK probably did not hit this because it always sets compressZ
>> by default.
>>
>> v2: Removed some garbage pastes (Ilia Mirkin)
>>
>> CC: Marek Olšák 
>> ---
>>  src/amd/addrlib/r800/siaddrlib.cpp | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/src/amd/addrlib/r800/siaddrlib.cpp
>> b/src/amd/addrlib/r800/siaddrlib.cpp
>> index bc009f5aff0..79ae940b4c8 100644
>> --- a/src/amd/addrlib/r800/siaddrlib.cpp
>> +++ b/src/amd/addrlib/r800/siaddrlib.cpp
>> @@ -2105,7 +2105,7 @@ VOID SiLib::HwlSetupTileInfo(
>>  }
>>  else // unCompressZ
>>  {
>> -index = 3;
>> +index = 0;
>>  }
>>  }
>>  else //non PRT & non Depth & non Stencil
>> --
>> 2.17.1
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] anv: Use a single global API patch version

2018-06-18 Thread Jason Ekstrand
On Mon, Jun 18, 2018 at 2:33 AM, Lionel Landwerlin <
lionel.g.landwer...@intel.com> wrote:

> I was wondering whether we should pick up the patch version from the
> registry.
>

I've thought about that.  However, I like the manual step of someone saying
"Yes, I've been paying attention and I'm pretty sure we're still
compliant.  I'm not sure how much we actually gain from that though.  In
practice it probably just means that the number doesn't get bumped as often
as it should. :-/


> Anyway :
>
> Reviewed-by: Lionel Landwerlin 
>

Thanks!


>
> On 18/06/18 00:29, Jason Ekstrand wrote:
>
>> The Vulkan API has only one patch version shared among all of the
>> major.minor versions.  We should also advertise the same patch version
>> regardless of major.minor.
>>
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106941
>> ---
>>   src/intel/vulkan/anv_extensions.py | 17 ++---
>>   src/intel/vulkan/anv_extensions_gen.py |  2 +-
>>   2 files changed, 11 insertions(+), 8 deletions(-)
>>
>> diff --git a/src/intel/vulkan/anv_extensions.py
>> b/src/intel/vulkan/anv_extensions.py
>> index 8160864685f..18851c0ff90 100644
>> --- a/src/intel/vulkan/anv_extensions.py
>> +++ b/src/intel/vulkan/anv_extensions.py
>> @@ -44,20 +44,22 @@ class Extension:
>>   self.enable = _bool_to_c_expr(enable)
>> class ApiVersion:
>> -def __init__(self, max_patch_version, enable):
>> -self.max_patch_version = max_patch_version
>> +def __init__(self, version, enable):
>> +self.version = version
>>   self.enable = _bool_to_c_expr(enable)
>>   +API_PATCH_VERSION = 76
>> +
>>   # Supported API versions.  Each one is the maximum patch version for
>> the given
>>   # version.  Version come in increasing order and each version is
>> available if
>>   # it's provided "enable" condition is true and all previous versions are
>>   # available.
>>   API_VERSIONS = [
>> -ApiVersion('1.0.57',True),
>> +ApiVersion('1.0',   True),
>> # DRM_IOCTL_SYNCOBJ_WAIT is required for VK_KHR_external_fence
>> which is a
>>   # required core feature in Vulkan 1.1
>> -ApiVersion('1.1.0', 'device->has_syncobj_wait'),
>> +ApiVersion('1.1',   'device->has_syncobj_wait'),
>>   ]
>> MAX_API_VERSION = None # Computed later
>> @@ -160,6 +162,7 @@ class VkVersion:
>> MAX_API_VERSION = VkVersion('0.0.0')
>>   for version in API_VERSIONS:
>> -version.max_patch_version = VkVersion(version.max_patch_version)
>> -assert version.max_patch_version > MAX_API_VERSION
>> -MAX_API_VERSION = version.max_patch_version
>> +version.version = VkVersion(version.version)
>> +version.version.patch = API_PATCH_VERSION
>> +assert version.version > MAX_API_VERSION
>> +MAX_API_VERSION = version.version
>> diff --git a/src/intel/vulkan/anv_extensions_gen.py
>> b/src/intel/vulkan/anv_extensions_gen.py
>> index 5ea82204eea..b75cb3e6fbb 100644
>> --- a/src/intel/vulkan/anv_extensions_gen.py
>> +++ b/src/intel/vulkan/anv_extensions_gen.py
>> @@ -157,7 +157,7 @@ anv_physical_device_api_version(struct
>> anv_physical_device *device)
>>   %for version in API_VERSIONS:
>>   if (!(${version.enable}))
>>   return version;
>> -version = ${version.max_patch_version.c_vk_version()};
>> +version = ${version.version.c_vk_version()};
>> %endfor
>>   return version;
>>
>
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [Bug 106420] segfault in dri2_allocate_textures(), radeonsi_dri.so 18.1-rc3 using mpv

2018-06-18 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=106420

Axel Rohde  changed:

   What|Removed |Added

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

--- Comment #2 from Axel Rohde  ---
The issue is not reproducible with Mesa 18.1.1 build from Debian testing repo.
Hence I (originator) close the issue.

Btw, is it possible that nobody cared about this bug?

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


Re: [Mesa-dev] [PATCH v3 3/3] egl/android: Add DRM node probing and filtering

2018-06-18 Thread Robert Foss



On 2018-06-14 04:54, Tomasz Figa wrote:

On Thu, Jun 14, 2018 at 4:14 AM Rob Herring  wrote:


On Wed, Jun 13, 2018 at 12:19 PM, Amit Pundir  wrote:

On 13 June 2018 at 20:45, Rob Herring  wrote:


+Amit and John

On Sat, Jun 9, 2018 at 11:27 AM, Robert Foss  wrote:

This patch both adds support for probing & filtering DRM nodes
and switches away from using the GRALLOC_MODULE_PERFORM_GET_DRM_FD
gralloc call.

Currently the filtering is based just on the driver name,
and the desired name is supplied using the "drm.gpu.vendor_name"
Android property.


There's a potential issue with this whole approach and that is
SELinux. With the way SELinux locks down accesses, getting probing
thru device files to work can be a pain. It may be better now than the
prior version because sysfs is not probed. I'll leave it to Amit or
John to comment.


Right.. so ICYMI, this patch is already pulled into external/mesa3d
project of AOSP and I stumbled upon one such /dev/dri/ access denial
on db820c recently.


A prior version of the patch series which accesses sysfs too (via libdrm).



In AOSP, zygote spawned apps already have access to GPU device nodes
in the form of /dev/gpu_device file, but the missing part is the


It's "gpu_device" in terms a a SELinux context, right? Not an actual /dev path?


open-read access to "/dev/dri/" which need to be allowed explicitly.


Or we need a way to just open a specific device.


How does this work in drm_gralloc (or any other existing gralloc that
implements GRALLOC_MODULE_PERFORM_GET_DRM_FD)? What device node does
it open? I have some loose recollection that it had a property
specifying exact device. I guess we could use that property as the top
level override, bypassing the whole probing logic, if present.


drm_gralloc in aosp/master uses the "gralloc.drm.device" property.



Best regards,
Tomasz


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


Re: [Mesa-dev] [ANNOUNCE] Mesa 18.1.2 release candidate

2018-06-18 Thread Dylan Baker
Quoting Juan A. Suarez Romero (2018-06-18 00:22:02)
> On Fri, 2018-06-15 at 12:47 -0400, Ilia Mirkin wrote:
> > On Fri, Jun 15, 2018 at 12:36 PM, Dylan Baker  wrote:
> > > I don't even understand why we make these announcements TBH. I have a 
> > > public
> > > 18.1-proposed branch that I push to *every weekday*. Anyone can pull that 
> > > branch
> > > *anytime* to get the latest version. The only thing the announce email 
> > > really
> > > serves AFAICT, is to say "the staging/proposed branch has been merged to 
> > > the
> > > release branch". I don't think that's all that interesting TBH.
> > 
> > "any time" means "no time". The announcement is "speak now or forever
> > hold your peace". Gives driver teams a chance to review the list and
> > test things out before they go out into a full release. Should they be
> > doing this daily/continuously? Probably. But that's not the current
> > state.
> > 
> 
> I agree on this. And I think the reason to wait 48h is to give time enough for
> teams to do proper testing, specially when there are many timezones that 
> people
> get the pre-announcement several hours later.
> 
> 
> But, I also think that the pre-announcement is too much verbose. It includes 
> lot
> of information that can be easily get from the git branch itself. The only 
> thing
> I would probably keep is about trivial conflicts, sending an explicit email to
> the authors to say "I [slightly] changed your commit; please, take a look just
> in case", and the rejected patch list, also mailing the authors.

I follow up with authors about changes immediately. If it was rejected I reply
to the original patch letting them know I'm not planning to pull the commit and
why. If there's conflicts I ask the original author to look at the changes I've
made before pulling them into the staging branch. It feels much too late to be
asking someone to do that when the release is happening shortly.

Dylan


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


Re: [Mesa-dev] [ANNOUNCE] Mesa 18.1.2 release candidate

2018-06-18 Thread Juan A. Suarez Romero
On Mon, 2018-06-18 at 09:56 -0700, Dylan Baker wrote:
> Quoting Juan A. Suarez Romero (2018-06-18 00:22:02)
> > On Fri, 2018-06-15 at 12:47 -0400, Ilia Mirkin wrote:
> > > On Fri, Jun 15, 2018 at 12:36 PM, Dylan Baker  wrote:
> > > > I don't even understand why we make these announcements TBH. I have a 
> > > > public
> > > > 18.1-proposed branch that I push to *every weekday*. Anyone can pull 
> > > > that branch
> > > > *anytime* to get the latest version. The only thing the announce email 
> > > > really
> > > > serves AFAICT, is to say "the staging/proposed branch has been merged 
> > > > to the
> > > > release branch". I don't think that's all that interesting TBH.
> > > 
> > > "any time" means "no time". The announcement is "speak now or forever
> > > hold your peace". Gives driver teams a chance to review the list and
> > > test things out before they go out into a full release. Should they be
> > > doing this daily/continuously? Probably. But that's not the current
> > > state.
> > > 
> > 
> > I agree on this. And I think the reason to wait 48h is to give time enough 
> > for
> > teams to do proper testing, specially when there are many timezones that 
> > people
> > get the pre-announcement several hours later.
> > 
> > 
> > But, I also think that the pre-announcement is too much verbose. It 
> > includes lot
> > of information that can be easily get from the git branch itself. The only 
> > thing
> > I would probably keep is about trivial conflicts, sending an explicit email 
> > to
> > the authors to say "I [slightly] changed your commit; please, take a look 
> > just
> > in case", and the rejected patch list, also mailing the authors.
> 
> I follow up with authors about changes immediately. If it was rejected I reply
> to the original patch letting them know I'm not planning to pull the commit 
> and
> why. If there's conflicts I ask the original author to look at the changes 
> I've
> made before pulling them into the staging branch. It feels much too late to be
> asking someone to do that when the release is happening shortly.
> 

Yeah, you're right. Actually I do exactly the same, that's why I said "would
probably keep". But as you said, once the affected authors are notified,
everyone else can know about rejected/fixed conflicts just taking a look at the
list of commits. So we could remove that from the pre-announcement.

J.A.



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


[Mesa-dev] [PATCH 00/19] intel: extract performance query code

2018-06-18 Thread Lionel Landwerlin
Hi all,

This series can be broken in 3 parts :

 - Making the performace query code API agnostic so that it can be
   reused on other APIs (patches 1 -> 10)

 - Adding a new pma stall metric on gen 8 & 9 (patches 17)

 - Adding performance query support on gen 11 (patch 19)

Cheers,

Lionel Landwerlin (19):
  intel: genxml: add mask fields for INSTPM/CS_DEBUG_MODE2 registers
  i965: store device revision in gen_device_info
  i965: extract performance query metrics
  i965: move mdapi data structure to intel/perf
  i965: move OA accumulation code to intel/perf
  i965: move brw_timebase_scale to device info
  i965: move mdapi result data format to intel/perf
  i965: move mdapi guid into intel/perf
  intel/perf: stub gen10/11 missing definitions
  i965: perf: add mdapi pipeline statistics queries on gen10/11
  intel: perf: update HSW configuration
  intel: perf: bdw: add pma stall metric
  intel: perf: skl: add pma stall metric
  intel: perf: kbl: add pma stall metric
  intel: perf: cfl: add pma stall metric
  intel: perf: bxt: add pma stall metric
  intel: perf: glk: add pma stall metric
  intel: perf: chv: fixup counter names
  intel: perf: add support for ICL

 src/intel/Android.mk  | 1 +
 src/intel/Android.perf.mk |52 +
 src/intel/Makefile.am | 2 +
 src/intel/Makefile.perf.am|41 +
 src/intel/Makefile.sources|26 +
 src/intel/dev/gen_device_info.h   | 8 +
 src/intel/genxml/gen10.xml| 3 +
 src/intel/genxml/gen11.xml| 3 +
 src/intel/genxml/gen7.xml | 4 +
 src/intel/genxml/gen75.xml| 4 +
 src/intel/genxml/gen8.xml | 4 +
 src/intel/genxml/gen9.xml | 3 +
 src/intel/meson.build | 1 +
 src/intel/perf/gen_perf.c |   576 +
 src/intel/perf/gen_perf.h |   275 +
 .../i965/brw_oa.py => intel/perf/gen_perf.py} |79 +-
 src/intel/perf/gen_perf_mdapi.c   |   116 +
 src/intel/perf/gen_perf_mdapi.h   |   135 +
 src/intel/perf/meson.build|41 +
 .../brw_oa_bdw.xml => intel/perf/oa-bdw.xml}  |   203 +-
 .../brw_oa_bxt.xml => intel/perf/oa-bxt.xml}  |   113 +-
 .../perf/oa-cflgt2.xml}   |   103 +-
 .../perf/oa-cflgt3.xml}   |   103 +-
 .../brw_oa_chv.xml => intel/perf/oa-chv.xml}  |50 +-
 .../brw_oa_cnl.xml => intel/perf/oa-cnl.xml}  | 0
 .../brw_oa_glk.xml => intel/perf/oa-glk.xml}  |   113 +-
 .../brw_oa_hsw.xml => intel/perf/oa-hsw.xml}  | 3 +-
 src/intel/perf/oa-icl.xml | 12092 
 .../perf/oa-kblgt2.xml}   |   103 +-
 .../perf/oa-kblgt3.xml}   |   103 +-
 .../perf/oa-sklgt2.xml}   |   103 +-
 .../perf/oa-sklgt3.xml}   |   103 +-
 .../perf/oa-sklgt4.xml}   |   103 +-
 src/mesa/drivers/dri/i965/Android.mk  | 3 +-
 src/mesa/drivers/dri/i965/Makefile.am |12 +-
 src/mesa/drivers/dri/i965/Makefile.sources|19 -
 src/mesa/drivers/dri/i965/brw_context.h   |74 +-
 .../drivers/dri/i965/brw_performance_query.c  |   783 +-
 .../drivers/dri/i965/brw_performance_query.h  |   121 +-
 .../dri/i965/brw_performance_query_mdapi.c|   306 +-
 .../dri/i965/brw_performance_query_metrics.h  |57 -
 src/mesa/drivers/dri/i965/brw_queryobj.c  |15 +-
 src/mesa/drivers/dri/i965/gen6_queryobj.c | 4 +-
 src/mesa/drivers/dri/i965/intel_screen.c  | 4 +-
 src/mesa/drivers/dri/i965/intel_screen.h  | 3 -
 src/mesa/drivers/dri/i965/meson.build |32 +-
 46 files changed, 14849 insertions(+), 1253 deletions(-)
 create mode 100644 src/intel/Android.perf.mk
 create mode 100644 src/intel/Makefile.perf.am
 create mode 100644 src/intel/perf/gen_perf.c
 create mode 100644 src/intel/perf/gen_perf.h
 rename src/{mesa/drivers/dri/i965/brw_oa.py => intel/perf/gen_perf.py} (89%)
 create mode 100644 src/intel/perf/gen_perf_mdapi.c
 create mode 100644 src/intel/perf/gen_perf_mdapi.h
 create mode 100644 src/intel/perf/meson.build
 rename src/{mesa/drivers/dri/i965/brw_oa_bdw.xml => intel/perf/oa-bdw.xml} 
(98%)
 rename src/{mesa/drivers/dri/i965/brw_oa_bxt.xml => intel/perf/oa-bxt.xml} 
(98%)
 rename src/{mesa/drivers/dri/i965/brw_oa_cflgt2.xml => 
intel/perf/oa-cflgt2.xml} (98%)
 rename src/{mesa/drivers/dri/i965/brw_oa_cflgt3.xml => 
intel/perf/oa-cflgt3.xml} (99%)
 rename src/{mesa/drivers/dri/i965/brw_oa_chv.xml => intel/perf/oa-chv.xml} 
(99%)
 rename src/{mesa/drivers/dri/i965/brw_oa_cnl.xml => intel/perf/oa-cnl.xml} 
(100%)
 rename src/{mesa/drivers/dri/i965/brw_oa_glk.xml => intel/perf/oa-glk.xml} 
(98%)
 rename src/{mesa/drivers/dri/i965/brw_oa_hsw.xml => intel/perf/oa-hsw.xml} 
(99

[Mesa-dev] [PATCH 06/19] i965: move brw_timebase_scale to device info

2018-06-18 Thread Lionel Landwerlin
Signed-off-by: Lionel Landwerlin 
---
 src/intel/dev/gen_device_info.h   |  7 +++
 src/mesa/drivers/dri/i965/brw_context.h   |  1 -
 src/mesa/drivers/dri/i965/brw_performance_query.c |  8 ++--
 .../dri/i965/brw_performance_query_mdapi.c|  6 +++---
 src/mesa/drivers/dri/i965/brw_queryobj.c  | 15 ---
 src/mesa/drivers/dri/i965/gen6_queryobj.c |  4 ++--
 6 files changed, 22 insertions(+), 19 deletions(-)

diff --git a/src/intel/dev/gen_device_info.h b/src/intel/dev/gen_device_info.h
index e36a6f65653..420833b09bd 100644
--- a/src/intel/dev/gen_device_info.h
+++ b/src/intel/dev/gen_device_info.h
@@ -270,6 +270,13 @@ void gen_device_info_update_from_masks(struct 
gen_device_info *devinfo,
 void gen_device_info_update_from_topology(struct gen_device_info *devinfo,
   const struct 
drm_i915_query_topology_info *topology);
 
+static inline uint64_t
+gen_device_info_timebase_scale(const struct gen_device_info *devinfo,
+   uint64_t gpu_timestamp)
+{
+   return (10ull * gpu_timestamp) / devinfo->timestamp_frequency;
+}
+
 #ifdef __cplusplus
 }
 #endif
diff --git a/src/mesa/drivers/dri/i965/brw_context.h 
b/src/mesa/drivers/dri/i965/brw_context.h
index 0a8026a11aa..7671799b517 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -1307,7 +1307,6 @@ void brw_emit_query_begin(struct brw_context *brw);
 void brw_emit_query_end(struct brw_context *brw);
 void brw_query_counter(struct gl_context *ctx, struct gl_query_object *q);
 bool brw_is_query_pipelined(struct brw_query_object *query);
-uint64_t brw_timebase_scale(struct brw_context *brw, uint64_t gpu_timestamp);
 uint64_t brw_raw_timestamp_delta(struct brw_context *brw,
  uint64_t time0, uint64_t time1);
 
diff --git a/src/mesa/drivers/dri/i965/brw_performance_query.c 
b/src/mesa/drivers/dri/i965/brw_performance_query.c
index 8dae7721860..0c4fc0a0a83 100644
--- a/src/mesa/drivers/dri/i965/brw_performance_query.c
+++ b/src/mesa/drivers/dri/i965/brw_performance_query.c
@@ -785,14 +785,18 @@ accumulate_oa_reports(struct brw_context *brw,
 /* Ignore reports that come before the start marker.
  * (Note: takes care to allow overflow of 32bit timestamps)
  */
-if (brw_timebase_scale(brw, report[1] - start[1]) > 50)
+if (gen_device_info_timebase_scale(devinfo,
+   report[1] - start[1]) > 
50) {
continue;
+}
 
 /* Ignore reports that come after the end marker.
  * (Note: takes care to allow overflow of 32bit timestamps)
  */
-if (brw_timebase_scale(brw, report[1] - end[1]) <= 50)
+if (gen_device_info_timebase_scale(devinfo,
+   report[1] - end[1]) <= 
50) {
goto end;
+}
 
 /* For Gen8+ since the counters continue while other
  * contexts are running we need to discount any unrelated
diff --git a/src/mesa/drivers/dri/i965/brw_performance_query_mdapi.c 
b/src/mesa/drivers/dri/i965/brw_performance_query_mdapi.c
index 159f31441c5..919069f9e39 100644
--- a/src/mesa/drivers/dri/i965/brw_performance_query_mdapi.c
+++ b/src/mesa/drivers/dri/i965/brw_performance_query_mdapi.c
@@ -54,7 +54,7 @@ brw_perf_query_get_mdapi_oa_data(struct brw_context *brw,
   }
 
   mdapi_data->ReportsCount = result->reports_accumulated;
-  mdapi_data->TotalTime = brw_timebase_scale(brw, result->accumulator[0]);
+  mdapi_data->TotalTime = gen_device_info_timebase_scale(devinfo, 
result->accumulator[0]);
   mdapi_data->CoreFrequency = obj->oa.gt_frequency[1];
   mdapi_data->CoreFrequencyChanged = obj->oa.gt_frequency[0] != 
obj->oa.gt_frequency[1];
   return sizeof(*mdapi_data);
@@ -74,7 +74,7 @@ brw_perf_query_get_mdapi_oa_data(struct brw_context *brw,
 
   mdapi_data->ReportId = result->hw_id;
   mdapi_data->ReportsCount = result->reports_accumulated;
-  mdapi_data->TotalTime = brw_timebase_scale(brw, result->accumulator[0]);
+  mdapi_data->TotalTime = gen_device_info_timebase_scale(devinfo, 
result->accumulator[0]);
   mdapi_data->GPUTicks = result->accumulator[1];
   mdapi_data->CoreFrequency = obj->oa.gt_frequency[1];
   mdapi_data->CoreFrequencyChanged = obj->oa.gt_frequency[0] != 
obj->oa.gt_frequency[1];
@@ -100,7 +100,7 @@ brw_perf_query_get_mdapi_oa_data(struct brw_context *brw,
 
   mdapi_data->ReportId = result->hw_id;
   mdapi_data->ReportsCount = result->reports_accumulated;
-  mdapi_data->TotalTime = brw_timebase_scale(brw, result->accumulator[0]);
+  mdapi_data->TotalTime = gen_device_info_timebase_scale(devinfo, 
result->accumulator[0]);
   mdapi_data->GPUTicks = result->accumulator[

[Mesa-dev] [PATCH 01/19] intel: genxml: add mask fields for INSTPM/CS_DEBUG_MODE2 registers

2018-06-18 Thread Lionel Landwerlin
Those 2 registers have masks on the upper 16bits of field values that
should be applied in HW.

Signed-off-by: Lionel Landwerlin 
---
 src/intel/genxml/gen10.xml | 3 +++
 src/intel/genxml/gen11.xml | 3 +++
 src/intel/genxml/gen7.xml  | 4 
 src/intel/genxml/gen75.xml | 4 
 src/intel/genxml/gen8.xml  | 4 
 src/intel/genxml/gen9.xml  | 3 +++
 6 files changed, 21 insertions(+)

diff --git a/src/intel/genxml/gen10.xml b/src/intel/genxml/gen10.xml
index 67fda868193..bb94ea457af 100644
--- a/src/intel/genxml/gen10.xml
+++ b/src/intel/genxml/gen10.xml
@@ -3631,6 +3631,9 @@
 
 
 
+
+
+
   
 
 
diff --git a/src/intel/genxml/gen11.xml b/src/intel/genxml/gen11.xml
index dea1cd83aec..ef608428730 100644
--- a/src/intel/genxml/gen11.xml
+++ b/src/intel/genxml/gen11.xml
@@ -3629,6 +3629,9 @@
 
 
 
+
+
+
   
 
 
diff --git a/src/intel/genxml/gen7.xml b/src/intel/genxml/gen7.xml
index 895f5d232b5..3fa3df315ae 100644
--- a/src/intel/genxml/gen7.xml
+++ b/src/intel/genxml/gen7.xml
@@ -2621,6 +2621,10 @@
 
 
 
+
+
+
+
   
 
 
diff --git a/src/intel/genxml/gen75.xml b/src/intel/genxml/gen75.xml
index 54362bbb93c..e75f5d78b42 100644
--- a/src/intel/genxml/gen75.xml
+++ b/src/intel/genxml/gen75.xml
@@ -3135,6 +3135,10 @@
 
 
 
+
+
+
+
   
 
 
diff --git a/src/intel/genxml/gen8.xml b/src/intel/genxml/gen8.xml
index 24c91e2e578..7edfa8b5cba 100644
--- a/src/intel/genxml/gen8.xml
+++ b/src/intel/genxml/gen8.xml
@@ -3374,6 +3374,10 @@
 
 
 
+
+
+
+
   
 
 
diff --git a/src/intel/genxml/gen9.xml b/src/intel/genxml/gen9.xml
index dbef0726f11..d8407792b72 100644
--- a/src/intel/genxml/gen9.xml
+++ b/src/intel/genxml/gen9.xml
@@ -3703,6 +3703,9 @@
 
 
 
+
+
+
   
 
 
-- 
2.17.1

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


[Mesa-dev] [PATCH 03/19] i965: extract performance query metrics

2018-06-18 Thread Lionel Landwerlin
We would like to reuse performance query metrics in other APIs. Let's
make the query code dealing with the processing of raw counters into
human readable values API agnostic.

Signed-off-by: Lionel Landwerlin 
---
 src/intel/Android.mk  |   1 +
 src/intel/Android.perf.mk |  52 ++
 src/intel/Makefile.am |   2 +
 src/intel/Makefile.perf.am|  41 ++
 src/intel/Makefile.sources|  23 +
 src/intel/meson.build |   1 +
 src/intel/perf/gen_perf.c | 435 
 src/intel/perf/gen_perf.h | 258 +++
 .../i965/brw_oa.py => intel/perf/gen_perf.py} |  79 +--
 src/intel/perf/meson.build|  39 ++
 .../brw_oa_bdw.xml => intel/perf/oa-bdw.xml}  |   0
 .../brw_oa_bxt.xml => intel/perf/oa-bxt.xml}  |   0
 .../perf/oa-cflgt2.xml}   |   0
 .../perf/oa-cflgt3.xml}   |   0
 .../brw_oa_chv.xml => intel/perf/oa-chv.xml}  |   0
 .../brw_oa_cnl.xml => intel/perf/oa-cnl.xml}  |   0
 .../brw_oa_glk.xml => intel/perf/oa-glk.xml}  |   0
 .../brw_oa_hsw.xml => intel/perf/oa-hsw.xml}  |   0
 .../perf/oa-kblgt2.xml}   |   0
 .../perf/oa-kblgt3.xml}   |   0
 .../perf/oa-sklgt2.xml}   |   0
 .../perf/oa-sklgt3.xml}   |   0
 .../perf/oa-sklgt4.xml}   |   0
 src/mesa/drivers/dri/i965/Android.mk  |   3 +-
 src/mesa/drivers/dri/i965/Makefile.am |  12 +-
 src/mesa/drivers/dri/i965/Makefile.sources|  19 -
 src/mesa/drivers/dri/i965/brw_context.h   |  73 +-
 .../drivers/dri/i965/brw_performance_query.c  | 649 --
 .../drivers/dri/i965/brw_performance_query.h  |  80 +--
 .../dri/i965/brw_performance_query_mdapi.c| 114 ++-
 .../dri/i965/brw_performance_query_metrics.h  |  57 --
 src/mesa/drivers/dri/i965/meson.build |  32 +-
 32 files changed, 1099 insertions(+), 871 deletions(-)
 create mode 100644 src/intel/Android.perf.mk
 create mode 100644 src/intel/Makefile.perf.am
 create mode 100644 src/intel/perf/gen_perf.c
 create mode 100644 src/intel/perf/gen_perf.h
 rename src/{mesa/drivers/dri/i965/brw_oa.py => intel/perf/gen_perf.py} (89%)
 create mode 100644 src/intel/perf/meson.build
 rename src/{mesa/drivers/dri/i965/brw_oa_bdw.xml => intel/perf/oa-bdw.xml} 
(100%)
 rename src/{mesa/drivers/dri/i965/brw_oa_bxt.xml => intel/perf/oa-bxt.xml} 
(100%)
 rename src/{mesa/drivers/dri/i965/brw_oa_cflgt2.xml => 
intel/perf/oa-cflgt2.xml} (100%)
 rename src/{mesa/drivers/dri/i965/brw_oa_cflgt3.xml => 
intel/perf/oa-cflgt3.xml} (100%)
 rename src/{mesa/drivers/dri/i965/brw_oa_chv.xml => intel/perf/oa-chv.xml} 
(100%)
 rename src/{mesa/drivers/dri/i965/brw_oa_cnl.xml => intel/perf/oa-cnl.xml} 
(100%)
 rename src/{mesa/drivers/dri/i965/brw_oa_glk.xml => intel/perf/oa-glk.xml} 
(100%)
 rename src/{mesa/drivers/dri/i965/brw_oa_hsw.xml => intel/perf/oa-hsw.xml} 
(100%)
 rename src/{mesa/drivers/dri/i965/brw_oa_kblgt2.xml => 
intel/perf/oa-kblgt2.xml} (100%)
 rename src/{mesa/drivers/dri/i965/brw_oa_kblgt3.xml => 
intel/perf/oa-kblgt3.xml} (100%)
 rename src/{mesa/drivers/dri/i965/brw_oa_sklgt2.xml => 
intel/perf/oa-sklgt2.xml} (100%)
 rename src/{mesa/drivers/dri/i965/brw_oa_sklgt3.xml => 
intel/perf/oa-sklgt3.xml} (100%)
 rename src/{mesa/drivers/dri/i965/brw_oa_sklgt4.xml => 
intel/perf/oa-sklgt4.xml} (100%)
 delete mode 100644 src/mesa/drivers/dri/i965/brw_performance_query_metrics.h

diff --git a/src/intel/Android.mk b/src/intel/Android.mk
index 380473d0acb..96498141dd2 100644
--- a/src/intel/Android.mk
+++ b/src/intel/Android.mk
@@ -31,4 +31,5 @@ include $(LOCAL_PATH)/Android.compiler.mk
 include $(LOCAL_PATH)/Android.dev.mk
 include $(LOCAL_PATH)/Android.genxml.mk
 include $(LOCAL_PATH)/Android.isl.mk
+include $(LOCAL_PATH)/Android.perf.mk
 include $(LOCAL_PATH)/Android.vulkan.mk
diff --git a/src/intel/Android.perf.mk b/src/intel/Android.perf.mk
new file mode 100644
index 000..0d7d746a632
--- /dev/null
+++ b/src/intel/Android.perf.mk
@@ -0,0 +1,52 @@
+# Copyright © 2018 Intel Corporation
+#
+# Permission is hereby granted, free of charge, to any person obtaining a
+# copy of this software and associated documentation files (the "Software"),
+# to deal in the Software without restriction, including without limitation
+# the rights to use, copy, modify, merge, publish, distribute, sublicense,
+# and/or sell copies of the Software, and to permit persons to whom the
+# Software is furnished to do so, subject to the following conditions:
+#
+# The above copyright notice and this permission notice shall be included
+# in all copies or substantial portions of the Software.
+#
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGE

[Mesa-dev] [PATCH 04/19] i965: move mdapi data structure to intel/perf

2018-06-18 Thread Lionel Landwerlin
We'll want to reuse those structures later on.

Signed-off-by: Lionel Landwerlin 
---
 src/intel/Makefile.sources|   3 +-
 src/intel/perf/gen_perf_mdapi.h   | 119 ++
 .../dri/i965/brw_performance_query_mdapi.c| 103 ++-
 3 files changed, 128 insertions(+), 97 deletions(-)
 create mode 100644 src/intel/perf/gen_perf_mdapi.h

diff --git a/src/intel/Makefile.sources b/src/intel/Makefile.sources
index 33a7ec0f2f4..1cfe7f6a072 100644
--- a/src/intel/Makefile.sources
+++ b/src/intel/Makefile.sources
@@ -315,7 +315,8 @@ GEN_PERF_XML_FILES = \
 
 GEN_PERF_FILES = \
perf/gen_perf.c \
-   perf/gen_perf.h
+   perf/gen_perf.h \
+   perf/gen_perf_mdapi.h
 
 GEN_PERF_GENERATED_FILES = \
perf/gen_perf_metrics.c \
diff --git a/src/intel/perf/gen_perf_mdapi.h b/src/intel/perf/gen_perf_mdapi.h
new file mode 100644
index 000..dcaa8c3ebeb
--- /dev/null
+++ b/src/intel/perf/gen_perf_mdapi.h
@@ -0,0 +1,119 @@
+/*
+ * Copyright © 2018 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#ifndef GEN_PERF_MDAPI_H
+#define GEN_PERF_MDAPI_H
+
+#include 
+
+/*
+ * Data format expected by MDAPI.
+ */
+
+struct gen7_mdapi_metrics {
+   uint64_t TotalTime;
+
+   uint64_t ACounters[45];
+   uint64_t NOACounters[16];
+
+   uint64_t PerfCounter1;
+   uint64_t PerfCounter2;
+   uint32_t SplitOccured;
+   uint32_t CoreFrequencyChanged;
+   uint64_t CoreFrequency;
+   uint32_t ReportId;
+   uint32_t ReportsCount;
+};
+
+#define GTDI_QUERY_BDW_METRICS_OA_COUNT 36
+#define GTDI_QUERY_BDW_METRICS_OA_40b_COUNT 32
+#define GTDI_QUERY_BDW_METRICS_NOA_COUNT16
+struct gen8_mdapi_metrics {
+   uint64_t TotalTime;
+   uint64_t GPUTicks;
+   uint64_t OaCntr[GTDI_QUERY_BDW_METRICS_OA_COUNT];
+   uint64_t NoaCntr[GTDI_QUERY_BDW_METRICS_NOA_COUNT];
+   uint64_t BeginTimestamp;
+   uint64_t Reserved1;
+   uint64_t Reserved2;
+   uint32_t Reserved3;
+   uint32_t OverrunOccured;
+   uint64_t MarkerUser;
+   uint64_t MarkerDriver;
+
+   uint64_t SliceFrequency;
+   uint64_t UnsliceFrequency;
+   uint64_t PerfCounter1;
+   uint64_t PerfCounter2;
+   uint32_t SplitOccured;
+   uint32_t CoreFrequencyChanged;
+   uint64_t CoreFrequency;
+   uint32_t ReportId;
+   uint32_t ReportsCount;
+};
+
+#define GTDI_MAX_READ_REGS 16
+
+struct gen9_mdapi_metrics {
+   uint64_t TotalTime;
+   uint64_t GPUTicks;
+   uint64_t OaCntr[GTDI_QUERY_BDW_METRICS_OA_COUNT];
+   uint64_t NoaCntr[GTDI_QUERY_BDW_METRICS_NOA_COUNT];
+   uint64_t BeginTimestamp;
+   uint64_t Reserved1;
+   uint64_t Reserved2;
+   uint32_t Reserved3;
+   uint32_t OverrunOccured;
+   uint64_t MarkerUser;
+   uint64_t MarkerDriver;
+
+   uint64_t SliceFrequency;
+   uint64_t UnsliceFrequency;
+   uint64_t PerfCounter1;
+   uint64_t PerfCounter2;
+   uint32_t SplitOccured;
+   uint32_t CoreFrequencyChanged;
+   uint64_t CoreFrequency;
+   uint32_t ReportId;
+   uint32_t ReportsCount;
+
+   uint64_t UserCntr[GTDI_MAX_READ_REGS];
+   uint32_t UserCntrCfgId;
+   uint32_t Reserved4;
+};
+
+struct mdapi_pipeline_metrics {
+   uint64_t IAVertices;
+   uint64_t IAPrimitives;
+   uint64_t VSInvocations;
+   uint64_t GSInvocations;
+   uint64_t GSPrimitives;
+   uint64_t CInvocations;
+   uint64_t CPrimitives;
+   uint64_t PSInvocations;
+   uint64_t HSInvocations;
+   uint64_t DSInvocations;
+   uint64_t CSInvocations;
+};
+
+#endif /* GEN_PERF_MDAPI_H */
diff --git a/src/mesa/drivers/dri/i965/brw_performance_query_mdapi.c 
b/src/mesa/drivers/dri/i965/brw_performance_query_mdapi.c
index 0676e868b81..916b14c14ba 100644
--- a/src/mesa/drivers/dri/i965/brw_performance_query_mdapi.c
+++ b/src/mesa/drivers/dri/i965/brw_performance_query_mdapi.c
@@ -25,96 +25,7 @@
 #include "brw_performance_query.h"
 
 #include "perf/gen_perf.h"
-
-/**
- * Data format expected by MDAPI.
- */
-
-struct mdapi_gen7_metrics {
-   uint64_t TotalTime;

[Mesa-dev] [PATCH 07/19] i965: move mdapi result data format to intel/perf

2018-06-18 Thread Lionel Landwerlin
We want to reuse this in Anv.

Signed-off-by: Lionel Landwerlin 
---
 src/intel/Makefile.sources|   3 +-
 src/intel/perf/gen_perf_mdapi.c   | 116 ++
 src/intel/perf/gen_perf_mdapi.h   |   8 ++
 src/intel/perf/meson.build|   3 +-
 .../drivers/dri/i965/brw_performance_query.c  |  13 +-
 .../drivers/dri/i965/brw_performance_query.h  |   4 -
 .../dri/i965/brw_performance_query_mdapi.c|  89 --
 7 files changed, 138 insertions(+), 98 deletions(-)
 create mode 100644 src/intel/perf/gen_perf_mdapi.c

diff --git a/src/intel/Makefile.sources b/src/intel/Makefile.sources
index 1cfe7f6a072..d2696d20ff9 100644
--- a/src/intel/Makefile.sources
+++ b/src/intel/Makefile.sources
@@ -316,7 +316,8 @@ GEN_PERF_XML_FILES = \
 GEN_PERF_FILES = \
perf/gen_perf.c \
perf/gen_perf.h \
-   perf/gen_perf_mdapi.h
+   perf/gen_perf_mdapi.h \
+   perf/gen_perf_mdapi.c
 
 GEN_PERF_GENERATED_FILES = \
perf/gen_perf_metrics.c \
diff --git a/src/intel/perf/gen_perf_mdapi.c b/src/intel/perf/gen_perf_mdapi.c
new file mode 100644
index 000..38ca23088d2
--- /dev/null
+++ b/src/intel/perf/gen_perf_mdapi.c
@@ -0,0 +1,116 @@
+/*
+ * Copyright © 2018 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#include "gen_perf.h"
+#include "gen_perf_mdapi.h"
+
+#include "dev/gen_device_info.h"
+
+int
+gen_perf_query_result_write_mdapi(void *data, uint32_t data_size,
+  const struct gen_device_info *devinfo,
+  const struct gen_perf_query_result *result,
+  uint64_t freq_start, uint64_t freq_end)
+{
+   switch (devinfo->gen) {
+   case 7: {
+  struct gen7_mdapi_metrics *mdapi_data = (struct gen7_mdapi_metrics *) 
data;
+
+  if (data_size < sizeof(*mdapi_data))
+ return 0;
+
+  assert(devinfo->is_haswell);
+
+  for (int i = 0; i < ARRAY_SIZE(mdapi_data->ACounters); i++)
+ mdapi_data->ACounters[i] = result->accumulator[1 + i];
+
+  for (int i = 0; i < ARRAY_SIZE(mdapi_data->NOACounters); i++) {
+ mdapi_data->NOACounters[i] =
+result->accumulator[1 + ARRAY_SIZE(mdapi_data->ACounters) + i];
+  }
+
+  mdapi_data->ReportsCount = result->reports_accumulated;
+  mdapi_data->TotalTime =
+ gen_device_info_timebase_scale(devinfo, result->accumulator[0]);
+  mdapi_data->CoreFrequency = freq_end;
+  mdapi_data->CoreFrequencyChanged = freq_end != freq_start;
+  return sizeof(*mdapi_data);
+   }
+   case 8: {
+  struct gen8_mdapi_metrics *mdapi_data = (struct gen8_mdapi_metrics *) 
data;
+
+  if (data_size < sizeof(*mdapi_data))
+ return 0;
+
+  for (int i = 0; i < ARRAY_SIZE(mdapi_data->OaCntr); i++)
+ mdapi_data->OaCntr[i] = result->accumulator[2 + i];
+  for (int i = 0; i < ARRAY_SIZE(mdapi_data->NoaCntr); i++) {
+ mdapi_data->NoaCntr[i] =
+result->accumulator[2 + ARRAY_SIZE(mdapi_data->OaCntr) + i];
+  }
+
+  mdapi_data->ReportId = result->hw_id;
+  mdapi_data->ReportsCount = result->reports_accumulated;
+  mdapi_data->TotalTime =
+ gen_device_info_timebase_scale(devinfo, result->accumulator[0]);
+  mdapi_data->GPUTicks = result->accumulator[1];
+  mdapi_data->CoreFrequency = freq_end;
+  mdapi_data->CoreFrequencyChanged = freq_end != freq_start;
+  mdapi_data->SliceFrequency =
+ (result->slice_frequency[0] + result->slice_frequency[1]) / 2ULL;
+  mdapi_data->UnsliceFrequency =
+ (result->unslice_frequency[0] + result->unslice_frequency[1]) / 2ULL;
+  return sizeof(*mdapi_data);
+   }
+   case 9:
+   case 10:
+   case 11: {
+  struct gen9_mdapi_metrics *mdapi_data = (struct gen9_mdapi_metrics *) 
data;
+
+  if (data_size < sizeof(*mdapi_data))
+ 

[Mesa-dev] [PATCH 05/19] i965: move OA accumulation code to intel/perf

2018-06-18 Thread Lionel Landwerlin
We'll want to reuse this in our Vulkan extension.

Signed-off-by: Lionel Landwerlin 
---
 src/intel/perf/gen_perf.c | 135 ++
 src/intel/perf/gen_perf.h |  81 ++-
 .../drivers/dri/i965/brw_performance_query.c  | 134 +++--
 .../drivers/dri/i965/brw_performance_query.h  |  37 +
 .../dri/i965/brw_performance_query_mdapi.c|  41 +++---
 5 files changed, 229 insertions(+), 199 deletions(-)

diff --git a/src/intel/perf/gen_perf.c b/src/intel/perf/gen_perf.c
index 3a8819e6ba9..979195f3d86 100644
--- a/src/intel/perf/gen_perf.c
+++ b/src/intel/perf/gen_perf.c
@@ -433,3 +433,138 @@ gen_perf_load_oa_metrics(struct gen_perf *perf, int fd,
 
return true;
 }
+
+/* Accumulate 32bits OA counters */
+static inline void
+accumulate_uint32(const uint32_t *report0,
+  const uint32_t *report1,
+  uint64_t *accumulator)
+{
+   *accumulator += (uint32_t)(*report1 - *report0);
+}
+
+/* Accumulate 40bits OA counters */
+static inline void
+accumulate_uint40(int a_index,
+  const uint32_t *report0,
+  const uint32_t *report1,
+  uint64_t *accumulator)
+{
+   const uint8_t *high_bytes0 = (uint8_t *)(report0 + 40);
+   const uint8_t *high_bytes1 = (uint8_t *)(report1 + 40);
+   uint64_t high0 = (uint64_t)(high_bytes0[a_index]) << 32;
+   uint64_t high1 = (uint64_t)(high_bytes1[a_index]) << 32;
+   uint64_t value0 = report0[a_index + 4] | high0;
+   uint64_t value1 = report1[a_index + 4] | high1;
+   uint64_t delta;
+
+   if (value0 > value1)
+  delta = (1ULL << 40) + value1 - value0;
+   else
+  delta = value1 - value0;
+
+   *accumulator += delta;
+}
+
+static void
+gen8_read_report_clock_ratios(const uint32_t *report,
+  uint64_t *slice_freq_hz,
+  uint64_t *unslice_freq_hz)
+{
+   /* The lower 16bits of the RPT_ID field of the OA reports contains a
+* snapshot of the bits coming from the RP_FREQ_NORMAL register and is
+* divided this way :
+*
+* RPT_ID[31:25]: RP_FREQ_NORMAL[20:14] (low squashed_slice_clock_frequency)
+* RPT_ID[10:9]:  RP_FREQ_NORMAL[22:21] (high 
squashed_slice_clock_frequency)
+* RPT_ID[8:0]:   RP_FREQ_NORMAL[31:23] (squashed_unslice_clock_frequency)
+*
+* RP_FREQ_NORMAL[31:23]: Software Unslice Ratio Request
+*Multiple of 33.33MHz 2xclk (16 MHz 1xclk)
+*
+* RP_FREQ_NORMAL[22:14]: Software Slice Ratio Request
+*Multiple of 33.33MHz 2xclk (16 MHz 1xclk)
+*/
+
+   uint32_t unslice_freq = report[0] & 0x1ff;
+   uint32_t slice_freq_low = (report[0] >> 25) & 0x7f;
+   uint32_t slice_freq_high = (report[0] >> 9) & 0x3;
+   uint32_t slice_freq = slice_freq_low | (slice_freq_high << 7);
+
+   *slice_freq_hz = slice_freq * 1667ULL;
+   *unslice_freq_hz = unslice_freq * 1667ULL;
+}
+
+void
+gen_perf_query_result_read_frequencies(struct gen_perf_query_result *result,
+   const struct gen_device_info *devinfo,
+   const uint32_t *start,
+   const uint32_t *end)
+{
+   /* Slice/Unslice frequency is only available in the OA reports when the
+* "Disable OA reports due to clock ratio change" field in
+* OA_DEBUG_REGISTER is set to 1. This is how the kernel programs this
+* global register (see drivers/gpu/drm/i915/i915_perf.c)
+*
+* Documentation says this should be available on Gen9+ but experimentation
+* shows that Gen8 reports similar values, so we enable it there too.
+*/
+   if (devinfo->gen < 8)
+  return;
+
+   gen8_read_report_clock_ratios(start,
+ &result->slice_frequency[0],
+ &result->unslice_frequency[0]);
+   gen8_read_report_clock_ratios(end,
+ &result->slice_frequency[1],
+ &result->unslice_frequency[1]);
+}
+
+void
+gen_perf_query_result_accumulate(struct gen_perf_query_result *result,
+ const struct gen_perf_query_info *query,
+ const uint32_t *start,
+ const uint32_t *end)
+{
+   int i, idx = 0;
+
+   result->hw_id = start[2];
+   result->reports_accumulated++;
+
+   switch (query->oa_format) {
+   case I915_OA_FORMAT_A32u40_A4u32_B8_C8:
+  accumulate_uint32(start + 1, end + 1, result->accumulator + idx++); /* 
timestamp */
+  accumulate_uint32(start + 3, end + 3, result->accumulator + idx++); /* 
clock */
+
+  /* 32x 40bit A counters... */
+  for (i = 0; i < 32; i++)
+ accumulate_uint40(i, start, end, result->accumulator + idx++);
+
+  /* 4x 32bit A counters... */
+  for (i = 0; i < 4; i++)
+ accumulate_uint32(start + 36 + i, end + 36 + i, result->accumulator + 
idx++);
+
+  

[Mesa-dev] [PATCH 14/19] intel: perf: kbl: add pma stall metric

2018-06-18 Thread Lionel Landwerlin
Signed-off-by: Lionel Landwerlin 
---
 src/intel/perf/oa-kblgt2.xml | 103 ++-
 src/intel/perf/oa-kblgt3.xml | 103 ++-
 2 files changed, 204 insertions(+), 2 deletions(-)

diff --git a/src/intel/perf/oa-kblgt2.xml b/src/intel/perf/oa-kblgt2.xml
index da2954e9e2d..c9150c8dcbe 100644
--- a/src/intel/perf/oa-kblgt2.xml
+++ b/src/intel/perf/oa-kblgt2.xml
@@ -1,5 +1,5 @@
 
-
+
   
   
 
+  
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+
 
diff --git a/src/intel/perf/oa-kblgt3.xml b/src/intel/perf/oa-kblgt3.xml
index aa1e83e3da1..20911267138 100644
--- a/src/intel/perf/oa-kblgt3.xml
+++ b/src/intel/perf/oa-kblgt3.xml
@@ -1,5 +1,5 @@
 
-
+
   
   
 
+  
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+
 
-- 
2.17.1

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


[Mesa-dev] [PATCH 02/19] i965: store device revision in gen_device_info

2018-06-18 Thread Lionel Landwerlin
Signed-off-by: Lionel Landwerlin 
---
 src/intel/dev/gen_device_info.h   | 1 +
 src/mesa/drivers/dri/i965/brw_performance_query.c | 3 +--
 src/mesa/drivers/dri/i965/intel_screen.c  | 4 +++-
 src/mesa/drivers/dri/i965/intel_screen.h  | 3 ---
 4 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/src/intel/dev/gen_device_info.h b/src/intel/dev/gen_device_info.h
index 40b72383420..e36a6f65653 100644
--- a/src/intel/dev/gen_device_info.h
+++ b/src/intel/dev/gen_device_info.h
@@ -46,6 +46,7 @@ struct drm_i915_query_topology_info;
 struct gen_device_info
 {
int gen; /**< Generation number: 4, 5, 6, 7, ... */
+   int revision;
int gt;
 
bool is_g4x;
diff --git a/src/mesa/drivers/dri/i965/brw_performance_query.c 
b/src/mesa/drivers/dri/i965/brw_performance_query.c
index d45529fc0c7..7fb3af7c15f 100644
--- a/src/mesa/drivers/dri/i965/brw_performance_query.c
+++ b/src/mesa/drivers/dri/i965/brw_performance_query.c
@@ -2014,7 +2014,6 @@ init_oa_sys_vars(struct brw_context *brw)
 {
const struct gen_device_info *devinfo = &brw->screen->devinfo;
uint64_t min_freq_mhz = 0, max_freq_mhz = 0;
-   __DRIscreen *screen = brw->screen->driScrnPriv;
 
if (!read_sysfs_drm_device_file_uint64(brw, "gt_min_freq_mhz", 
&min_freq_mhz))
   return false;
@@ -2042,7 +2041,7 @@ init_oa_sys_vars(struct brw_context *brw)
brw->perfquery.sys_vars.gt_min_freq = min_freq_mhz * 100;
brw->perfquery.sys_vars.gt_max_freq = max_freq_mhz * 100;
brw->perfquery.sys_vars.timestamp_frequency = devinfo->timestamp_frequency;
-   brw->perfquery.sys_vars.revision = intel_device_get_revision(screen->fd);
+   brw->perfquery.sys_vars.revision = devinfo->revision;
compute_topology_builtins(brw);
 
return true;
diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
b/src/mesa/drivers/dri/i965/intel_screen.c
index cb357419a77..e51488d79b6 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -2353,7 +2353,7 @@ set_max_gl_versions(struct intel_screen *screen)
  * Return the revision (generally the revid field of the PCI header) of the
  * graphics device.
  */
-int
+static int
 intel_device_get_revision(int fd)
 {
struct drm_i915_getparam gp;
@@ -2457,6 +2457,8 @@ __DRIconfig **intelInitScreen2(__DRIscreen *dri_screen)
if (!gen_get_device_info(screen->deviceID, &screen->devinfo))
   return NULL;
 
+   screen->devinfo.revision = intel_device_get_revision(dri_screen->fd);
+
if (!intel_init_bufmgr(screen))
return NULL;
 
diff --git a/src/mesa/drivers/dri/i965/intel_screen.h 
b/src/mesa/drivers/dri/i965/intel_screen.h
index 8d56fcd9e7a..e21532a59b5 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.h
+++ b/src/mesa/drivers/dri/i965/intel_screen.h
@@ -139,9 +139,6 @@ double get_time(void);
 const int*
 intel_supported_msaa_modes(const struct intel_screen  *screen);
 
-int
-intel_device_get_revision(int fd);
-
 static inline bool
 can_do_pipelined_register_writes(const struct intel_screen *screen)
 {
-- 
2.17.1

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


[Mesa-dev] [PATCH 13/19] intel: perf: skl: add pma stall metric

2018-06-18 Thread Lionel Landwerlin
Signed-off-by: Lionel Landwerlin 
---
 src/intel/perf/oa-sklgt2.xml | 103 ++-
 src/intel/perf/oa-sklgt3.xml | 103 ++-
 src/intel/perf/oa-sklgt4.xml | 103 ++-
 3 files changed, 306 insertions(+), 3 deletions(-)

diff --git a/src/intel/perf/oa-sklgt2.xml b/src/intel/perf/oa-sklgt2.xml
index 343de0c5ea9..8256dfcce80 100644
--- a/src/intel/perf/oa-sklgt2.xml
+++ b/src/intel/perf/oa-sklgt2.xml
@@ -1,5 +1,5 @@
 
-
+
   
   
 
+  
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+
 
diff --git a/src/intel/perf/oa-sklgt3.xml b/src/intel/perf/oa-sklgt3.xml
index 00b016f0c64..571248cb243 100644
--- a/src/intel/perf/oa-sklgt3.xml
+++ b/src/intel/perf/oa-sklgt3.xml
@@ -1,5 +1,5 @@
 
-
+
   
   
 
+  
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+
 
diff --git a/src/intel/perf/oa-sklgt4.xml b/src/intel/perf/oa-sklgt4.xml
index d52fc335c9b..ea50d993a27 100644
--- a/src/intel/perf/oa-sklgt4.xml
+++ b/src/intel/perf/oa-sklgt4.xml
@@ -1,5 +1,5 @@
 
-
+
   
   
 
+  
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+
 
-- 
2.17.1

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


[Mesa-dev] [PATCH 09/19] intel/perf: stub gen10/11 missing definitions

2018-06-18 Thread Lionel Landwerlin
---
 src/intel/perf/gen_perf_mdapi.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/intel/perf/gen_perf_mdapi.h b/src/intel/perf/gen_perf_mdapi.h
index a2f8066dcf4..45fe171b030 100644
--- a/src/intel/perf/gen_perf_mdapi.h
+++ b/src/intel/perf/gen_perf_mdapi.h
@@ -108,6 +108,10 @@ struct gen9_mdapi_metrics {
uint32_t Reserved4;
 };
 
+/* Add new definition */
+#define gen10_mdapi_metrics gen9_mdapi_metrics
+#define gen11_mdapi_metrics gen9_mdapi_metrics
+
 struct mdapi_pipeline_metrics {
uint64_t IAVertices;
uint64_t IAPrimitives;
-- 
2.17.1

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


[Mesa-dev] [PATCH 15/19] intel: perf: cfl: add pma stall metric

2018-06-18 Thread Lionel Landwerlin
Signed-off-by: Lionel Landwerlin 
---
 src/intel/perf/oa-cflgt2.xml | 103 ++-
 src/intel/perf/oa-cflgt3.xml | 103 ++-
 2 files changed, 204 insertions(+), 2 deletions(-)

diff --git a/src/intel/perf/oa-cflgt2.xml b/src/intel/perf/oa-cflgt2.xml
index 15a8e13378e..29f71d47d2f 100644
--- a/src/intel/perf/oa-cflgt2.xml
+++ b/src/intel/perf/oa-cflgt2.xml
@@ -1,5 +1,5 @@
 
-
+
   
   
 
+  
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+
 
diff --git a/src/intel/perf/oa-cflgt3.xml b/src/intel/perf/oa-cflgt3.xml
index b7b8f52f9b0..986668f672a 100644
--- a/src/intel/perf/oa-cflgt3.xml
+++ b/src/intel/perf/oa-cflgt3.xml
@@ -1,5 +1,5 @@
 
-
+
   
   
 
+  
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+
 
-- 
2.17.1

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


[Mesa-dev] [PATCH 16/19] intel: perf: bxt: add pma stall metric

2018-06-18 Thread Lionel Landwerlin
Signed-off-by: Lionel Landwerlin 
---
 src/intel/perf/oa-bxt.xml | 113 +-
 1 file changed, 112 insertions(+), 1 deletion(-)

diff --git a/src/intel/perf/oa-bxt.xml b/src/intel/perf/oa-bxt.xml
index 5b18369b2cb..db018a3d62b 100644
--- a/src/intel/perf/oa-bxt.xml
+++ b/src/intel/perf/oa-bxt.xml
@@ -1,5 +1,5 @@
 
-
+
   
   
 
+  
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+
 
-- 
2.17.1

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


[Mesa-dev] [PATCH 08/19] i965: move mdapi guid into intel/perf

2018-06-18 Thread Lionel Landwerlin
One more thing we want to share between the different APIs.

Signed-off-by: Lionel Landwerlin 
---
 src/intel/perf/gen_perf_mdapi.h | 3 +++
 src/mesa/drivers/dri/i965/brw_performance_query_mdapi.c | 3 +--
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/intel/perf/gen_perf_mdapi.h b/src/intel/perf/gen_perf_mdapi.h
index fcdee079013..a2f8066dcf4 100644
--- a/src/intel/perf/gen_perf_mdapi.h
+++ b/src/intel/perf/gen_perf_mdapi.h
@@ -29,6 +29,9 @@
 struct gen_device_info;
 struct gen_perf_query_result;
 
+/* Guid has to matches with MDAPI's. */
+#define GEN_PERF_QUERY_GUID_MDAPI "2f01b241-7014-42a7-9eb6-a925cad3daba"
+
 /*
  * Data format expected by MDAPI.
  */
diff --git a/src/mesa/drivers/dri/i965/brw_performance_query_mdapi.c 
b/src/mesa/drivers/dri/i965/brw_performance_query_mdapi.c
index fbdbca1260c..d95a9638731 100644
--- a/src/mesa/drivers/dri/i965/brw_performance_query_mdapi.c
+++ b/src/mesa/drivers/dri/i965/brw_performance_query_mdapi.c
@@ -187,8 +187,7 @@ brw_perf_query_register_mdapi_oa_query(struct brw_context 
*brw)
 
query->kind = GEN_PERF_QUERY_TYPE_RAW;
query->name = "Intel_Raw_Hardware_Counters_Set_0_Query";
-   /* Guid has to matches with MDAPI's. */
-   query->guid = "2f01b241-7014-42a7-9eb6-a925cad3daba";
+   query->guid = GEN_PERF_QUERY_GUID_MDAPI;
 
{
   /* Accumulation buffer offsets copied from an actual query... */
-- 
2.17.1

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


[Mesa-dev] [PATCH 12/19] intel: perf: bdw: add pma stall metric

2018-06-18 Thread Lionel Landwerlin
Signed-off-by: Lionel Landwerlin 
---
 src/intel/perf/oa-bdw.xml | 203 +-
 1 file changed, 202 insertions(+), 1 deletion(-)

diff --git a/src/intel/perf/oa-bdw.xml b/src/intel/perf/oa-bdw.xml
index 258fcacfd59..714a1f08ea7 100644
--- a/src/intel/perf/oa-bdw.xml
+++ b/src/intel/perf/oa-bdw.xml
@@ -1,5 +1,5 @@
 
-
+
   
   
 
+  
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+
 
-- 
2.17.1

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


[Mesa-dev] [PATCH 18/19] intel: perf: chv: fixup counter names

2018-06-18 Thread Lionel Landwerlin
No functional changes, just cleaning up the names of the counters.

Signed-off-by: Lionel Landwerlin 
---
 src/intel/perf/oa-chv.xml | 50 +++
 1 file changed, 25 insertions(+), 25 deletions(-)

diff --git a/src/intel/perf/oa-chv.xml b/src/intel/perf/oa-chv.xml
index 2116c895ab9..85c50bb43bb 100644
--- a/src/intel/perf/oa-chv.xml
+++ b/src/intel/perf/oa-chv.xml
@@ -1,5 +1,5 @@
 
-
+
   
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 11/19] intel: perf: update HSW configuration

2018-06-18 Thread Lionel Landwerlin
One register that was in the configuration turned out to be IVB
specific. Let's just drop it.

Signed-off-by: Lionel Landwerlin 
---
 src/intel/perf/oa-hsw.xml | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/intel/perf/oa-hsw.xml b/src/intel/perf/oa-hsw.xml
index 861cc1212a7..a3bed73086b 100644
--- a/src/intel/perf/oa-hsw.xml
+++ b/src/intel/perf/oa-hsw.xml
@@ -1,5 +1,5 @@
 
-
+


  

  

-
 
   
 
-- 
2.17.1

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


[Mesa-dev] [PATCH 17/19] intel: perf: glk: add pma stall metric

2018-06-18 Thread Lionel Landwerlin
Signed-off-by: Lionel Landwerlin 
---
 src/intel/perf/oa-glk.xml | 113 +-
 1 file changed, 112 insertions(+), 1 deletion(-)

diff --git a/src/intel/perf/oa-glk.xml b/src/intel/perf/oa-glk.xml
index 68fcd2d6dde..e3da757f46f 100644
--- a/src/intel/perf/oa-glk.xml
+++ b/src/intel/perf/oa-glk.xml
@@ -1,5 +1,5 @@
 
-
+
   
   
 
+  
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+
 
-- 
2.17.1

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


[Mesa-dev] [PATCH 10/19] i965: perf: add mdapi pipeline statistics queries on gen10/11

2018-06-18 Thread Lionel Landwerlin
The Gen10+ expected format adds an additional counter which we can't
disclose yet. We can still make the size of the expected query result
match.

Signed-off-by: Lionel Landwerlin 
---
 src/intel/perf/gen_perf_mdapi.h|  1 +
 .../drivers/dri/i965/brw_performance_query_mdapi.c | 10 +-
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/src/intel/perf/gen_perf_mdapi.h b/src/intel/perf/gen_perf_mdapi.h
index 45fe171b030..3c3aec2c64e 100644
--- a/src/intel/perf/gen_perf_mdapi.h
+++ b/src/intel/perf/gen_perf_mdapi.h
@@ -124,6 +124,7 @@ struct mdapi_pipeline_metrics {
uint64_t HSInvocations;
uint64_t DSInvocations;
uint64_t CSInvocations;
+   uint64_t Reserved1; /* Gen10+ */
 };
 
 int gen_perf_query_result_write_mdapi(void *data, uint32_t data_size,
diff --git a/src/mesa/drivers/dri/i965/brw_performance_query_mdapi.c 
b/src/mesa/drivers/dri/i965/brw_performance_query_mdapi.c
index d95a9638731..f77560390d7 100644
--- a/src/mesa/drivers/dri/i965/brw_performance_query_mdapi.c
+++ b/src/mesa/drivers/dri/i965/brw_performance_query_mdapi.c
@@ -207,7 +207,7 @@ brw_perf_query_register_mdapi_statistic_query(struct 
brw_context *brw)
 {
const struct gen_device_info *devinfo = &brw->screen->devinfo;
 
-   if (!(devinfo->gen >= 7 && devinfo->gen <= 9))
+   if (!(devinfo->gen >= 7 && devinfo->gen <= 11))
   return;
 
struct gen_perf_query_info *query =
@@ -248,5 +248,13 @@ brw_perf_query_register_mdapi_statistic_query(struct 
brw_context *brw)
  "N compute shader invocations");
}
 
+   if (devinfo->gen >= 10) {
+  /* Reuse existing CS invocation register until we can expose this new
+   * one.
+   */
+  gen_perf_query_info_add_basic_stat_reg(query, CS_INVOCATION_COUNT,
+ "Reserved1");
+   }
+
query->data_size = sizeof(uint64_t) * query->n_counters;
 }
-- 
2.17.1

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


Re: [Mesa-dev] [PATCH 00/19] intel: extract performance query code

2018-06-18 Thread Lionel Landwerlin

I forgot that the last patch won't make it (too big).
The branch is here : 
https://github.com/djdeath/mesa/tree/wip/djdeath/perf-extract


Cheers,

-
Lionel

On 18/06/18 18:39, Lionel Landwerlin wrote:

Hi all,

This series can be broken in 3 parts :

  - Making the performace query code API agnostic so that it can be
reused on other APIs (patches 1 -> 10)

  - Adding a new pma stall metric on gen 8 & 9 (patches 17)

  - Adding performance query support on gen 11 (patch 19)

Cheers,

Lionel Landwerlin (19):
   intel: genxml: add mask fields for INSTPM/CS_DEBUG_MODE2 registers
   i965: store device revision in gen_device_info
   i965: extract performance query metrics
   i965: move mdapi data structure to intel/perf
   i965: move OA accumulation code to intel/perf
   i965: move brw_timebase_scale to device info
   i965: move mdapi result data format to intel/perf
   i965: move mdapi guid into intel/perf
   intel/perf: stub gen10/11 missing definitions
   i965: perf: add mdapi pipeline statistics queries on gen10/11
   intel: perf: update HSW configuration
   intel: perf: bdw: add pma stall metric
   intel: perf: skl: add pma stall metric
   intel: perf: kbl: add pma stall metric
   intel: perf: cfl: add pma stall metric
   intel: perf: bxt: add pma stall metric
   intel: perf: glk: add pma stall metric
   intel: perf: chv: fixup counter names
   intel: perf: add support for ICL

  src/intel/Android.mk  | 1 +
  src/intel/Android.perf.mk |52 +
  src/intel/Makefile.am | 2 +
  src/intel/Makefile.perf.am|41 +
  src/intel/Makefile.sources|26 +
  src/intel/dev/gen_device_info.h   | 8 +
  src/intel/genxml/gen10.xml| 3 +
  src/intel/genxml/gen11.xml| 3 +
  src/intel/genxml/gen7.xml | 4 +
  src/intel/genxml/gen75.xml| 4 +
  src/intel/genxml/gen8.xml | 4 +
  src/intel/genxml/gen9.xml | 3 +
  src/intel/meson.build | 1 +
  src/intel/perf/gen_perf.c |   576 +
  src/intel/perf/gen_perf.h |   275 +
  .../i965/brw_oa.py => intel/perf/gen_perf.py} |79 +-
  src/intel/perf/gen_perf_mdapi.c   |   116 +
  src/intel/perf/gen_perf_mdapi.h   |   135 +
  src/intel/perf/meson.build|41 +
  .../brw_oa_bdw.xml => intel/perf/oa-bdw.xml}  |   203 +-
  .../brw_oa_bxt.xml => intel/perf/oa-bxt.xml}  |   113 +-
  .../perf/oa-cflgt2.xml}   |   103 +-
  .../perf/oa-cflgt3.xml}   |   103 +-
  .../brw_oa_chv.xml => intel/perf/oa-chv.xml}  |50 +-
  .../brw_oa_cnl.xml => intel/perf/oa-cnl.xml}  | 0
  .../brw_oa_glk.xml => intel/perf/oa-glk.xml}  |   113 +-
  .../brw_oa_hsw.xml => intel/perf/oa-hsw.xml}  | 3 +-
  src/intel/perf/oa-icl.xml | 12092 
  .../perf/oa-kblgt2.xml}   |   103 +-
  .../perf/oa-kblgt3.xml}   |   103 +-
  .../perf/oa-sklgt2.xml}   |   103 +-
  .../perf/oa-sklgt3.xml}   |   103 +-
  .../perf/oa-sklgt4.xml}   |   103 +-
  src/mesa/drivers/dri/i965/Android.mk  | 3 +-
  src/mesa/drivers/dri/i965/Makefile.am |12 +-
  src/mesa/drivers/dri/i965/Makefile.sources|19 -
  src/mesa/drivers/dri/i965/brw_context.h   |74 +-
  .../drivers/dri/i965/brw_performance_query.c  |   783 +-
  .../drivers/dri/i965/brw_performance_query.h  |   121 +-
  .../dri/i965/brw_performance_query_mdapi.c|   306 +-
  .../dri/i965/brw_performance_query_metrics.h  |57 -
  src/mesa/drivers/dri/i965/brw_queryobj.c  |15 +-
  src/mesa/drivers/dri/i965/gen6_queryobj.c | 4 +-
  src/mesa/drivers/dri/i965/intel_screen.c  | 4 +-
  src/mesa/drivers/dri/i965/intel_screen.h  | 3 -
  src/mesa/drivers/dri/i965/meson.build |32 +-
  46 files changed, 14849 insertions(+), 1253 deletions(-)
  create mode 100644 src/intel/Android.perf.mk
  create mode 100644 src/intel/Makefile.perf.am
  create mode 100644 src/intel/perf/gen_perf.c
  create mode 100644 src/intel/perf/gen_perf.h
  rename src/{mesa/drivers/dri/i965/brw_oa.py => intel/perf/gen_perf.py} (89%)
  create mode 100644 src/intel/perf/gen_perf_mdapi.c
  create mode 100644 src/intel/perf/gen_perf_mdapi.h
  create mode 100644 src/intel/perf/meson.build
  rename src/{mesa/drivers/dri/i965/brw_oa_bdw.xml => intel/perf/oa-bdw.xml} 
(98%)
  rename src/{mesa/drivers/dri/i965/brw_oa_bxt.xml => intel/perf/oa-bxt.xml} 
(98%)
  rename src/{mesa/drivers/dri/i965/brw_oa_cflgt2.xml => 
intel/perf/oa-cflgt2.xml} (98%)
  rename src/{mesa/drivers/dri/i965/brw_oa_cflgt3.xml => 
intel/perf/oa-cflgt3.xml} (99%)
  rename src/{mesa/drivers/dri/i965/brw_oa_

Re: [Mesa-dev] [PATCH shaderdb] run: shader program file created via GetProgramBinary (v5)

2018-06-18 Thread Matt Turner
On Wed, May 23, 2018 at 3:12 PM Dongwon Kim  wrote:
>
> Thanks, Matt!!
> I am glad to see it is finally merged. By the way, not sure if you
> saw this patch.
>
> [PATCH shaderdb] run: handling binding of attribute variable name (v2)
> https://lists.freedesktop.org/archives/mesa-dev/2018-March/190179.html
>
> This is required for pre-binding of uniforms. It would be great
> if you can review and consider merging this as well.

Thanks for the reminder, and sorry for forgetting about this patch. I
just pushed it.

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


[Mesa-dev] [Bug 106915] [GLSL] Unused arrays declared without a size should be handled like arrays of size 1.

2018-06-18 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=106915

--- Comment #9 from Ian Romanick  ---
Okay... this doesn't work on any desktop implementation of GLSL.  In previous
cases like this we have decided we have decided that the spec is either unclear
or wrong.  Either way, please submit a Khronos spec bug for this issue that
included the test case and the results from all the implementations.

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


Re: [Mesa-dev] [PATCH] virgl: Remove debugging left-overs

2018-06-18 Thread Dave Airlie
On 18 June 2018 at 22:50, Tomeu Vizoso  wrote:
> Some fprintfs were probably left unintentionally a few years ago and are
> a bit of a nuisance.
>
> Signed-off-by: Tomeu Vizoso 
> Cc: Signed-off-by: Rob Herring 
> Fixes: 2d3301e4d513 ("virgl: fix reference counting of prime handles")

Reviewed-by: Dave Airlie 

> ---
>  src/gallium/winsys/virgl/drm/virgl_drm_winsys.c | 2 --
>  1 file changed, 2 deletions(-)
>
> diff --git a/src/gallium/winsys/virgl/drm/virgl_drm_winsys.c 
> b/src/gallium/winsys/virgl/drm/virgl_drm_winsys.c
> index fb15708ddb19..aad6430c417d 100644
> --- a/src/gallium/winsys/virgl/drm/virgl_drm_winsys.c
> +++ b/src/gallium/winsys/virgl/drm/virgl_drm_winsys.c
> @@ -417,7 +417,6 @@ virgl_drm_winsys_resource_create_handle(struct 
> virgl_winsys *qws,
> }
>
> res = util_hash_table_get(qdws->bo_handles, (void*)(uintptr_t)handle);
> -   fprintf(stderr, "resource %p for handle %d, pfd=%d\n", res, handle, 
> whandle->handle);
> if (res) {
>struct virgl_hw_res *r = NULL;
>virgl_drm_resource_reference(qdws, &r, res);
> @@ -431,7 +430,6 @@ virgl_drm_winsys_resource_create_handle(struct 
> virgl_winsys *qws,
> if (whandle->type == WINSYS_HANDLE_TYPE_FD) {
>res->bo_handle = handle;
> } else {
> -  fprintf(stderr, "gem open handle %d\n", handle);
>memset(&open_arg, 0, sizeof(open_arg));
>open_arg.name = whandle->handle;
>if (drmIoctl(qdws->fd, DRM_IOCTL_GEM_OPEN, &open_arg)) {
> --
> 2.17.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH mesa] meson: fix i965/anv/isl genX static lib names

2018-06-18 Thread Dylan Baker
Quoting Eric Engestrom (2018-06-15 04:15:31)
> Shouldn't make any functional difference, just that `liblibanv_gen90.a`
> will now be called `libanv_gen90.a`.
> 
> Fixes: 3218056e0eb375eeda470 "meson: Build i965 and dri stack"
> Fixes: d1992255bb29054fa5176 "meson: Add build Intel "anv" vulkan driver"
> Signed-off-by: Eric Engestrom 
> ---
>  src/intel/isl/meson.build | 2 +-
>  src/intel/vulkan/meson.build  | 2 +-
>  src/mesa/drivers/dri/i965/meson.build | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/src/intel/isl/meson.build b/src/intel/isl/meson.build
> index c70c5c05fcd1adb4c63b..5b57188d30c001172ab1 100644
> --- a/src/intel/isl/meson.build
> +++ b/src/intel/isl/meson.build
> @@ -54,7 +54,7 @@ foreach g : [['40', isl_gen4_files], ['50', []], ['60', 
> isl_gen6_files],
>   ['90', isl_gen9_files], ['100', []], ['110', []]]
>_gen = g[0]
>isl_gen_libs += static_library(
> -'libisl_gen@0@'.format(_gen),
> +'isl_gen@0@'.format(_gen),
>  [g[1], isl_gen_files, gen_xml_pack],
>  include_directories : [inc_common, inc_intel],
>  c_args : [c_vis_args, no_override_init_args,
> diff --git a/src/intel/vulkan/meson.build b/src/intel/vulkan/meson.build
> index f20a8a54c9bbdfb43dd3..159ad092314bcef6ec7c 100644
> --- a/src/intel/vulkan/meson.build
> +++ b/src/intel/vulkan/meson.build
> @@ -95,7 +95,7 @@ foreach g : [['70', ['gen7_cmd_buffer.c']], ['75', 
> ['gen7_cmd_buffer.c']],
>   ['100', ['gen8_cmd_buffer.c']], ['110', ['gen8_cmd_buffer.c']]]
>_gen = g[0]
>libanv_gen_libs += static_library(
> -'libanv_gen@0@'.format(_gen),
> +'anv_gen@0@'.format(_gen),
>  [anv_gen_files, g[1], anv_entrypoints[0], anv_extensions_h],
>  include_directories : [
>inc_common, inc_compiler, inc_drm_uapi, inc_intel, inc_vulkan_util,
> diff --git a/src/mesa/drivers/dri/i965/meson.build 
> b/src/mesa/drivers/dri/i965/meson.build
> index 20404d5b059736b9bc8c..761bb51d6faa696798cc 100644
> --- a/src/mesa/drivers/dri/i965/meson.build
> +++ b/src/mesa/drivers/dri/i965/meson.build
> @@ -138,7 +138,7 @@ files_i965 = files(
>  i965_gen_libs = []
>  foreach v : ['40', '45', '50', '60', '70', '75', '80', '90', '100', '110']
>i965_gen_libs += static_library(
> -'libi965_gen@0@'.format(v),
> +'i965_gen@0@'.format(v),
>  ['genX_blorp_exec.c', 'genX_state_upload.c', gen_xml_pack],
>  include_directories : [inc_common, inc_intel, inc_dri_common],
>  c_args : [
> -- 
> Cheers,
>   Eric
> 

There was a trivial merge conflict on the 18.1 branch I resolved, you can look
at it on my 18.1-proposed branch if you're interested.

Dylan


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


Re: [Mesa-dev] [PATCH v2 1/2] amd/addrlib: Use correct tile index for S8 on SI.

2018-06-18 Thread Marek Olšák
On Mon, Jun 18, 2018 at 12:12 PM, Bas Nieuwenhuizen  wrote:

> On Mon, Jun 18, 2018 at 6:08 PM, Marek Olšák  wrote:
> > Do you need this if you set compressZ = true for stencil?
>
> Technically not, then you don't hit the path anymore. Anyway even
> though neither AMDVLK or RADV anymore if we do that, it still bugged
> me that the index is wrong.
>

The way I update addrlib is that I copy all files from the internal repo
into Mesa and then maybe discard some Mesa-specific changes. This change is
very likely to get overwritten, so I would like to prevent addrlib changes
that don't have any impact on current Mesa.

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


Re: [Mesa-dev] [PATCH mesa] gallium: simplify util_format_is_supported()

2018-06-18 Thread Marek Olšák
The function can be removed completely, because it doesn't do anything now.

Marek

On Mon, Jun 18, 2018 at 10:55 AM, Eric Engestrom 
wrote:

> On Monday, 2018-06-18 07:31:49 -0700, Matt Turner wrote:
> > On Mon, Jun 18, 2018 at 3:15 AM Eric Engestrom 
> wrote:
> > >
> > > As of 66673bef941af344314f ("mesa: Unconditionally enable
> floating-point
> > > textures"), the `bind` argument is no longer used, and the format check
> > > is now a simple enum range check, so inline it and remove the
> > > unnecessary argument from callers.
> > >
> > > Cc: Timothy Arceri 
> > > Cc: Matt Turner 
> > > Cc: Ian Romanick 
> > > Signed-off-by: Eric Engestrom 
> > > ---
> > >  src/gallium/auxiliary/util/u_format.c   | 12 
> > >  src/gallium/auxiliary/util/u_format.h   |  7 +--
> > >  src/gallium/drivers/freedreno/a2xx/fd2_screen.c |  2 +-
> > >  src/gallium/drivers/freedreno/a3xx/fd3_screen.c |  2 +-
> > >  src/gallium/drivers/freedreno/a4xx/fd4_screen.c |  2 +-
> > >  src/gallium/drivers/freedreno/a5xx/fd5_screen.c |  2 +-
> > >  src/gallium/drivers/i915/i915_screen.c  |  2 +-
> > >  src/gallium/drivers/nouveau/nv30/nv30_screen.c  |  2 +-
> > >  src/gallium/drivers/nouveau/nv50/nv50_screen.c  |  2 +-
> > >  src/gallium/drivers/nouveau/nvc0/nvc0_screen.c  |  2 +-
> > >  src/gallium/drivers/r300/r300_screen.c  |  2 +-
> > >  src/gallium/drivers/r600/evergreen_state.c  |  2 +-
> > >  src/gallium/drivers/r600/r600_state.c   |  2 +-
> > >  src/gallium/drivers/radeonsi/si_state.c |  2 +-
> > >  src/gallium/drivers/v3d/v3d_screen.c|  2 +-
> > >  src/gallium/drivers/vc4/vc4_screen.c|  2 +-
> > >  16 files changed, 19 insertions(+), 28 deletions(-)
> > >
> > > diff --git a/src/gallium/auxiliary/util/u_format.c
> b/src/gallium/auxiliary/util/u_format.c
> > > index e0325e9c534974b15c65..d82d00a9d06fde2daeef 100644
> > > --- a/src/gallium/auxiliary/util/u_format.c
> > > +++ b/src/gallium/auxiliary/util/u_format.c
> > > @@ -235,18 +235,6 @@ util_format_is_subsampled_422(enum pipe_format
> format)
> > >desc->block.bits == 32;
> > >  }
> > >
> > > -boolean
> > > -util_format_is_supported(enum pipe_format format, unsigned bind)
> > > -{
> > > -   if (format >= PIPE_FORMAT_COUNT) {
> > > -  return FALSE;
> > > -   }
> > > -
> > > -   (void)bind;
> > > -
> > > -   return TRUE;
> > > -}
> > > -
> > >
> > >  /**
> > >   * Calculates the MRD for the depth format. MRD is used in depth bias
> > > diff --git a/src/gallium/auxiliary/util/u_format.h
> b/src/gallium/auxiliary/util/u_format.h
> > > index e497b4b3375a57771009..9c5df967b6c01288d0b3 100644
> > > --- a/src/gallium/auxiliary/util/u_format.h
> > > +++ b/src/gallium/auxiliary/util/u_format.h
> > > @@ -721,8 +721,11 @@ util_is_format_compatible(const struct
> util_format_description *src_desc,
> > >   * Whether the format is supported by Gallium for the given bindings.
> > >   * This covers S3TC textures and floating-point render targets.
> >
> > I suspect this line was here because these two things might not be
> > available. But now they are :)
> >
> > I think this line should be removed.
>
> Thanks! Done, as well as removing "for the given bindings".
>
> >
> > Reviewed-by: Matt Turner 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH v2 1/2] amd/addrlib: Use correct tile index for S8 on SI.

2018-06-18 Thread Bas Nieuwenhuizen
On Mon, Jun 18, 2018 at 10:39 PM, Marek Olšák  wrote:
> On Mon, Jun 18, 2018 at 12:12 PM, Bas Nieuwenhuizen
>  wrote:
>>
>> On Mon, Jun 18, 2018 at 6:08 PM, Marek Olšák  wrote:
>> > Do you need this if you set compressZ = true for stencil?
>>
>> Technically not, then you don't hit the path anymore. Anyway even
>> though neither AMDVLK or RADV anymore if we do that, it still bugged
>> me that the index is wrong.
>
>
> The way I update addrlib is that I copy all files from the internal repo
> into Mesa and then maybe discard some Mesa-specific changes. This change is
> very likely to get overwritten, so I would like to prevent addrlib changes
> that don't have any impact on current Mesa.

If I want to fix it "upstream", is the addrlib copy in
https://github.com/GPUOpen-Drivers/pal the right place to update?

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


Re: [Mesa-dev] [Mesa-stable] [PATCH 2/2] ac/surface: Set compressZ for stencil-only surfaces.

2018-06-18 Thread Marek Olšák
Reviewed-by: Marek Olšák 

Marek

On Mon, Jun 18, 2018 at 10:32 AM, Bas Nieuwenhuizen  wrote:

> We HTILE compress stencil-only surfaces too.
>
> CC: 18.1 
> ---
>  src/amd/common/ac_surface.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/amd/common/ac_surface.c b/src/amd/common/ac_surface.c
> index 6600ff6b7ef..618b755afc7 100644
> --- a/src/amd/common/ac_surface.c
> +++ b/src/amd/common/ac_surface.c
> @@ -670,7 +670,7 @@ static int gfx6_compute_surface(ADDR_HANDLE addrlib,
>  config->info.levels == 1);
>
> AddrSurfInfoIn.flags.noStencil = (surf->flags &
> RADEON_SURF_SBUFFER) == 0;
> -   AddrSurfInfoIn.flags.compressZ = AddrSurfInfoIn.flags.depth;
> +   AddrSurfInfoIn.flags.compressZ = !!(surf->flags &
> RADEON_SURF_Z_OR_SBUFFER);
>
> /* On CI/VI, the DB uses the same pitch and tile mode (except
> tilesplit)
>  * for Z and stencil. This can cause a number of problems which we
> work
> --
> 2.17.1
>
> ___
> mesa-stable mailing list
> mesa-sta...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-stable
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] radeonsi: enable OpenGL 3.3 compat profile

2018-06-18 Thread Marek Olšák
Reviewed-by: Marek Olšák 

Marek


On Mon, Jun 18, 2018 at 1:29 AM, Timothy Arceri 
wrote:

> Cc: Marek Olšák 
> ---
>
>  This is intended to apply on top of:
> https://patchwork.freedesktop.org/patch/229981/
>
>  All the high importance pieces are now implemented and
>  we have a reasonable number of piglit tests for these
>  bits.
>
>  src/gallium/drivers/radeonsi/si_get.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/radeonsi/si_get.c b/src/gallium/drivers/
> radeonsi/si_get.c
> index 154fabebdcc..8b03d8222ab 100644
> --- a/src/gallium/drivers/radeonsi/si_get.c
> +++ b/src/gallium/drivers/radeonsi/si_get.c
> @@ -215,7 +215,7 @@ static int si_get_param(struct pipe_screen *pscreen,
> enum pipe_cap param)
> return 420;
>
> case PIPE_CAP_GLSL_FEATURE_LEVEL_COMPATIBILITY:
> -   return 140;
> +   return 330;
>
> case PIPE_CAP_MAX_TEXTURE_BUFFER_SIZE:
> return MIN2(sscreen->info.max_alloc_size, INT_MAX);
> --
> 2.17.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] mesa: add ff fragment shader support for geom and tess shaders

2018-06-18 Thread Marek Olšák
Reviewed-by: Marek Olšák 

Marek


On Sun, Jun 17, 2018 at 10:39 PM, Timothy Arceri 
wrote:

> This is required for compatibility profile support.
> ---
>  src/mesa/main/ff_fragment_shader.cpp | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/src/mesa/main/ff_fragment_shader.cpp
> b/src/mesa/main/ff_fragment_shader.cpp
> index a698931d99e..935a21624af 100644
> --- a/src/mesa/main/ff_fragment_shader.cpp
> +++ b/src/mesa/main/ff_fragment_shader.cpp
> @@ -229,7 +229,11 @@ static GLbitfield filter_fp_input_mask( GLbitfield
> fp_inputs,
>  * since vertex shader state validation comes after fragment state
>  * validation (see additional comments in state.c).
>  */
> -   if (vertexShader)
> +   if (ctx->_Shader->CurrentProgram[MESA_SHADER_GEOMETRY] != NULL)
> +  vprog = ctx->_Shader->CurrentProgram[MESA_SHADER_GEOMETRY];
> +   else if (ctx->_Shader->CurrentProgram[MESA_SHADER_TESS_EVAL] != NULL)
> +  vprog = ctx->_Shader->CurrentProgram[MESA_SHADER_TESS_EVAL];
> +   else if (vertexShader)
>vprog = ctx->_Shader->CurrentProgram[MESA_SHADER_VERTEX];
> else
>vprog = ctx->VertexProgram.Current;
> --
> 2.17.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH v2 1/2] amd/addrlib: Use correct tile index for S8 on SI.

2018-06-18 Thread Marek Olšák
On Mon, Jun 18, 2018 at 4:41 PM, Bas Nieuwenhuizen 
wrote:

> On Mon, Jun 18, 2018 at 10:39 PM, Marek Olšák  wrote:
> > On Mon, Jun 18, 2018 at 12:12 PM, Bas Nieuwenhuizen
> >  wrote:
> >>
> >> On Mon, Jun 18, 2018 at 6:08 PM, Marek Olšák  wrote:
> >> > Do you need this if you set compressZ = true for stencil?
> >>
> >> Technically not, then you don't hit the path anymore. Anyway even
> >> though neither AMDVLK or RADV anymore if we do that, it still bugged
> >> me that the index is wrong.
> >
> >
> > The way I update addrlib is that I copy all files from the internal repo
> > into Mesa and then maybe discard some Mesa-specific changes. This change
> is
> > very likely to get overwritten, so I would like to prevent addrlib
> changes
> > that don't have any impact on current Mesa.
>
> If I want to fix it "upstream", is the addrlib copy in
> https://github.com/GPUOpen-Drivers/pal the right place to update?
>

No, that one is an imported copy too. If you want to fix this in the
original repository, you can send the patch to my amd address.

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


Re: [Mesa-dev] [PATCH] tgsi: add some atomic opcodes to tgsi_opcode_infer_type

2018-06-18 Thread Marek Olšák
Reviewed-by: Marek Olšák 

Marek


On Thu, Jun 14, 2018 at 7:35 PM, Gurchetan Singh <
gurchetansi...@chromium.org> wrote:

> We don't have cases for atomic types, some of which are explicitly
> signed or unsigned.
>
> The other opcodes could have uint or int return types, based on the
> sources.
> ---
>  src/gallium/auxiliary/tgsi/tgsi_info.c | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/src/gallium/auxiliary/tgsi/tgsi_info.c
> b/src/gallium/auxiliary/tgsi/tgsi_info.c
> index 4aa658785cf..6f3cd9c5304 100644
> --- a/src/gallium/auxiliary/tgsi/tgsi_info.c
> +++ b/src/gallium/auxiliary/tgsi/tgsi_info.c
> @@ -253,6 +253,9 @@ tgsi_opcode_infer_src_type(enum tgsi_opcode opcode,
> uint src_idx)
>return TGSI_TYPE_SIGNED;
>
> switch (opcode) {
> +   case TGSI_OPCODE_ATOMUADD:
> +   case TGSI_OPCODE_ATOMUMAX:
> +   case TGSI_OPCODE_ATOMUMIN:
> case TGSI_OPCODE_UIF:
> case TGSI_OPCODE_TXF:
> case TGSI_OPCODE_TXF_LZ:
> @@ -268,6 +271,8 @@ tgsi_opcode_infer_src_type(enum tgsi_opcode opcode,
> uint src_idx)
> case TGSI_OPCODE_U2I64:
> case TGSI_OPCODE_MEMBAR:
>return TGSI_TYPE_UNSIGNED;
> +   case TGSI_OPCODE_ATOMIMAX:
> +   case TGSI_OPCODE_ATOMIMIN:
> case TGSI_OPCODE_IMUL_HI:
> case TGSI_OPCODE_I2F:
> case TGSI_OPCODE_I2D:
> --
> 2.13.5
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH v3 1/2] gallium: add scalar isa shader cap

2018-06-18 Thread Marek Olšák
Reviewed-by: Marek Olšák 

Marek


On Fri, Jun 15, 2018 at 6:29 AM, Christian Gmeiner <
christian.gmei...@gmail.com> wrote:

> v1 -> v2:
>  - nv30 is _NOT_ scalar as suggested by Ilia Mirkin.
>  - Change from a screen cap to a shader cap as suggested
>by Eric Anholt.
>  - radeonsi is scalar as suggested by Marek Olšák.
>  - Change missing ones to be scalar.
>
> v2 -> v3:
>  - r600 prefers vec4 as suggested by Marek Olšák.
>
> Signed-off-by: Christian Gmeiner 
> Reviewed-by: Eric Anholt 
> ---
>  src/gallium/auxiliary/gallivm/lp_bld_limits.h| 2 ++
>  src/gallium/auxiliary/tgsi/tgsi_exec.h   | 2 ++
>  src/gallium/docs/source/screen.rst   | 1 +
>  src/gallium/drivers/etnaviv/etnaviv_screen.c | 1 +
>  src/gallium/drivers/freedreno/freedreno_screen.c | 3 ++-
>  src/gallium/drivers/nouveau/nv30/nv30_screen.c   | 2 ++
>  src/gallium/drivers/nouveau/nv50/nv50_screen.c   | 2 ++
>  src/gallium/drivers/nouveau/nvc0/nvc0_screen.c   | 2 ++
>  src/gallium/drivers/r600/r600_pipe.c | 2 ++
>  src/gallium/drivers/radeonsi/si_get.c| 2 ++
>  src/gallium/drivers/svga/svga_screen.c   | 6 ++
>  src/gallium/drivers/v3d/v3d_screen.c | 2 ++
>  src/gallium/drivers/vc4/vc4_screen.c | 2 ++
>  src/gallium/drivers/virgl/virgl_screen.c | 3 +++
>  src/gallium/include/pipe/p_defines.h | 1 +
>  15 files changed, 32 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/auxiliary/gallivm/lp_bld_limits.h
> b/src/gallium/auxiliary/gallivm/lp_bld_limits.h
> index c7755bfe1d..7b66b75872 100644
> --- a/src/gallium/auxiliary/gallivm/lp_bld_limits.h
> +++ b/src/gallium/auxiliary/gallivm/lp_bld_limits.h
> @@ -143,6 +143,8 @@ gallivm_get_shader_param(enum pipe_shader_cap param)
> case PIPE_SHADER_CAP_MAX_HW_ATOMIC_COUNTERS:
> case PIPE_SHADER_CAP_MAX_HW_ATOMIC_COUNTER_BUFFERS:
>return 0;
> +   case PIPE_SHADER_CAP_SCALAR_ISA:
> +  return 1;
> case PIPE_SHADER_CAP_MAX_UNROLL_ITERATIONS_HINT:
>return 32;
> }
> diff --git a/src/gallium/auxiliary/tgsi/tgsi_exec.h
> b/src/gallium/auxiliary/tgsi/tgsi_exec.h
> index 0fac7ea456..ed8b9e8869 100644
> --- a/src/gallium/auxiliary/tgsi/tgsi_exec.h
> +++ b/src/gallium/auxiliary/tgsi/tgsi_exec.h
> @@ -544,6 +544,8 @@ tgsi_exec_get_shader_param(enum pipe_shader_cap param)
> case PIPE_SHADER_CAP_MAX_HW_ATOMIC_COUNTERS:
> case PIPE_SHADER_CAP_MAX_HW_ATOMIC_COUNTER_BUFFERS:
>return 0;
> +   case PIPE_SHADER_CAP_SCALAR_ISA:
> +  return 1;
> case PIPE_SHADER_CAP_MAX_SHADER_BUFFERS:
>return PIPE_MAX_SHADER_BUFFERS;
> case PIPE_SHADER_CAP_MAX_SHADER_IMAGES:
> diff --git a/src/gallium/docs/source/screen.rst b/src/gallium/docs/source/
> screen.rst
> index 0f18b7a94b..a044099873 100644
> --- a/src/gallium/docs/source/screen.rst
> +++ b/src/gallium/docs/source/screen.rst
> @@ -546,6 +546,7 @@ MOV OUT[0], CONST[0][3]  # copy vector 3 of constbuf 0
>how many HW counters are available for this stage. (0 uses SSBO
> atomics).
>  * ``PIPE_SHADER_CAP_MAX_HW_ATOMIC_COUNTER_BUFFERS``: If atomic counters
> are
>separate, how many atomic counter buffers are available for this stage.
> +* ``PIPE_SHADER_CAP_SCALAR_ISA``: Whether the ISA is a scalar one.
>
>  .. _pipe_compute_cap:
>
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_screen.c
> b/src/gallium/drivers/etnaviv/etnaviv_screen.c
> index e031807117..e426514cc6 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_screen.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_screen.c
> @@ -473,6 +473,7 @@ etna_screen_get_shader_param(struct pipe_screen
> *pscreen,
> case PIPE_SHADER_CAP_TGSI_SKIP_MERGE_REGISTERS:
> case PIPE_SHADER_CAP_MAX_HW_ATOMIC_COUNTERS:
> case PIPE_SHADER_CAP_MAX_HW_ATOMIC_COUNTER_BUFFERS:
> +   case PIPE_SHADER_CAP_SCALAR_ISA:
>return 0;
> }
>
> diff --git a/src/gallium/drivers/freedreno/freedreno_screen.c
> b/src/gallium/drivers/freedreno/freedreno_screen.c
> index a414cb6d60..97eec73238 100644
> --- a/src/gallium/drivers/freedreno/freedreno_screen.c
> +++ b/src/gallium/drivers/freedreno/freedreno_screen.c
> @@ -592,7 +592,8 @@ fd_screen_get_shader_param(struct pipe_screen
> *pscreen,
> case PIPE_SHADER_CAP_TGSI_SKIP_MERGE_REGISTERS:
> case PIPE_SHADER_CAP_MAX_HW_ATOMIC_COUNTERS:
> case PIPE_SHADER_CAP_MAX_HW_ATOMIC_COUNTER_BUFFERS:
> -   return 0;
> +   case PIPE_SHADER_CAP_SCALAR_ISA:
> +   return 1;
> case PIPE_SHADER_CAP_MAX_SHADER_BUFFERS:
> case PIPE_SHADER_CAP_MAX_SHADER_IMAGES:
> if (is_a5xx(screen)) {
> diff --git a/src/gallium/drivers/nouveau/nv30/nv30_screen.c
> b/src/gallium/drivers/nouveau/nv30/nv30_screen.c
> index a77f70e6bb..dce88e1b1a 100644
> --- a/src/gallium/drivers/nouveau/nv30/nv30_screen.c
> +++ b/src/gallium/drivers/nouveau/nv30/nv30_screen.c
> @@ -343,6 +343,7 @@ nv30_screen_get_shader_param(struct pipe_screen
> *pscreen,
>case PIPE_SHADE

Re: [Mesa-dev] [PATCH 1/3] st/mesa/i965: Allow decompressing ETC2 to GL_RGBA

2018-06-18 Thread Marek Olšák
What about non-sRGB formats?

Marek

On Wed, May 23, 2018 at 4:54 AM, Tomeu Vizoso 
wrote:

> When Mesa itself implements ETC2 decompression, it currently
> decompresses to formats in the GL_BGRA component order.
>
> That can be problematic for drivers which cannot upload the texture data
> as GL_BGRA, such as Virgl when it's backed by GLES on the host.
>
> So this commit adds a flag to _mesa_unpack_etc2_format so callers can
> specify the optimal component order.
>
> In Gallium's case, it will be requested if the format isn't in
> PIPE_FORMAT_B8G8R8A8_SRGB format.
>
> For i965, it will remain GL_BGRA, as before.
>
> Signed-off-by: Tomeu Vizoso 
> ---
>  src/mesa/drivers/dri/i965/intel_mipmap_tree.c |  2 +-
>  src/mesa/main/texcompress_etc.c   | 56 +++
>  src/mesa/main/texcompress_etc.h   |  4 +-
>  src/mesa/state_tracker/st_cb_texture.c|  4 +-
>  4 files changed, 41 insertions(+), 25 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> index 67086ee6c0e8..4d9019ebf4ea 100644
> --- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> +++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> @@ -3370,7 +3370,7 @@ intel_miptree_unmap_etc(struct brw_context *brw,
> else
>_mesa_unpack_etc2_format(dst, mt->surf.row_pitch,
> map->ptr, map->stride,
> -   map->w, map->h, mt->etc_format);
> +   map->w, map->h, mt->etc_format, true);
>
> intel_miptree_unmap_raw(mt);
> free(map->buffer);
> diff --git a/src/mesa/main/texcompress_etc.c b/src/mesa/main/texcompress_
> etc.c
> index 099787b7f407..ce50ba32f9d4 100644
> --- a/src/mesa/main/texcompress_etc.c
> +++ b/src/mesa/main/texcompress_etc.c
> @@ -719,7 +719,8 @@ etc2_unpack_srgb8(uint8_t *dst_row,
>const uint8_t *src_row,
>unsigned src_stride,
>unsigned width,
> -  unsigned height)
> +  unsigned height,
> +  bool bgra)
>  {
> const unsigned bw = 4, bh = 4, bs = 8, comps = 4;
> struct etc2_block block;
> @@ -741,11 +742,14 @@ etc2_unpack_srgb8(uint8_t *dst_row,
>  for (i = 0; i < w; i++) {
> etc2_rgb8_fetch_texel(&block, i, j, dst,
>   false /* punchthrough_alpha */);
> -   /* Convert to MESA_FORMAT_B8G8R8A8_SRGB */
> -   tmp = dst[0];
> -   dst[0] = dst[2];
> -   dst[2] = tmp;
> -   dst[3] = 255;
> +
> +   if (bgra) {
> +  /* Convert to MESA_FORMAT_B8G8R8A8_SRGB */
> +  tmp = dst[0];
> +  dst[0] = dst[2];
> +  dst[2] = tmp;
> +  dst[3] = 255;
> +   }
>
> dst += comps;
>  }
> @@ -801,7 +805,8 @@ etc2_unpack_srgb8_alpha8(uint8_t *dst_row,
>   const uint8_t *src_row,
>   unsigned src_stride,
>   unsigned width,
> - unsigned height)
> + unsigned height,
> + bool bgra)
>  {
> /* If internalformat is COMPRESSED_SRGB8_ALPHA8_ETC2_EAC, each 4 × 4
> block
>  * of RGBA information is compressed to 128 bits. To decode a
> block, the
> @@ -825,11 +830,13 @@ etc2_unpack_srgb8_alpha8(uint8_t *dst_row,
>  for (i = 0; i < w; i++) {
> etc2_rgba8_fetch_texel(&block, i, j, dst);
>
> -   /* Convert to MESA_FORMAT_B8G8R8A8_SRGB */
> -   tmp = dst[0];
> -   dst[0] = dst[2];
> -   dst[2] = tmp;
> -   dst[3] = dst[3];
> +   if (bgra) {
> +  /* Convert to MESA_FORMAT_B8G8R8A8_SRGB */
> +  tmp = dst[0];
> +  dst[0] = dst[2];
> +  dst[2] = tmp;
> +  dst[3] = dst[3];
> +   }
>
> dst += comps;
>  }
> @@ -1058,7 +1065,8 @@ etc2_unpack_srgb8_punchthrough_alpha1(uint8_t
> *dst_row,
>   const uint8_t *src_row,
>   unsigned src_stride,
>   unsigned width,
> - unsigned height)
> + unsigned height,
> + bool bgra)
>  {
> const unsigned bw = 4, bh = 4, bs = 8, comps = 4;
> struct etc2_block block;
> @@ -1078,11 +1086,14 @@ etc2_unpack_srgb8_punchthrough_alpha1(uint8_t
> *dst_row,
>  for (i = 0; i < w; i++) {
> etc2_rgb8_fetch_texel(&block, i, j, dst,
>   true /* punchthrough_alpha */);
> -   /* Convert to MESA_FORMAT_B8G8R8A8_SRGB */
> -   tmp = 

Re: [Mesa-dev] [PATCH 2/9] intel/tools/aubinator: aubinate ppgtt aubs

2018-06-18 Thread Rafael Antognolli
Hi Lionel,

I've been going through the patch and I think the content so far is
mostly fine. However, it has a lot of things going on for a single patch
IMHO. I see changes for the execution list submission port, ppgtt, using
the RB tree for ggtt too, etc...

It definitely make it more painful to read (at least for me). Are these
changes so related that they couldn't be split up?

Rafael

On Thu, Jun 14, 2018 at 06:11:38PM +0100, Lionel Landwerlin wrote:
> From: Scott D Phillips 
> 
> v2: by Lionel
> Fix memfd_create compilation issue
> Fix pml4 address stored on 32 instead of 64bits
> Return no buffer if first ppgtt page is not mapped
> 
> Signed-off-by: Lionel Landwerlin 
> ---
>  src/intel/tools/aubinator.c | 460 
>  1 file changed, 410 insertions(+), 50 deletions(-)
> 
> diff --git a/src/intel/tools/aubinator.c b/src/intel/tools/aubinator.c
> index 3120e82b22e..99cd010dd9d 100644
> --- a/src/intel/tools/aubinator.c
> +++ b/src/intel/tools/aubinator.c
> @@ -37,12 +37,24 @@
>  #include 
>  #include 
>  
> +#include "util/list.h"
>  #include "util/macros.h"
> +#include "util/rb_tree.h"
>  
>  #include "common/gen_decoder.h"
>  #include "common/gen_disasm.h"
>  #include "intel_aub.h"
>  
> +#ifndef HAVE_MEMFD_CREATE
> +#include 
> +
> +static inline int
> +memfd_create(const char *name, unsigned int flags)
> +{
> +   return syscall(SYS_memfd_create, name, flags);
> +}
> +#endif
> +
>  /* Below is the only command missing from intel_aub.h in libdrm
>   * So, reuse intel_aub.h from libdrm and #define the
>   * AUB_MI_BATCH_BUFFER_END as below
> @@ -70,6 +82,31 @@ struct gen_batch_decode_ctx batch_ctx;
>  
>  uint64_t gtt_size, gtt_end;
>  void *gtt;
> +
> +struct bo_map {
> +   struct list_head link;
> +   struct gen_batch_decode_bo bo;
> +};
> +
> +struct ggtt_entry {
> +   struct rb_node node;
> +   uint64_t virt_addr;
> +   uint64_t phys_addr;
> +};
> +
> +struct phys_mem {
> +   struct rb_node node;
> +   uint64_t fd_offset;
> +   uint64_t phys_addr;
> +   uint8_t *data;
> +};
> +
> +static struct list_head maps;
> +static struct rb_tree ggtt = {NULL};
> +static struct rb_tree mem = {NULL};
> +int mem_fd = -1;
> +off_t mem_fd_len = 0;
> +
>  uint64_t general_state_base;
>  uint64_t surface_state_base;
>  uint64_t dynamic_state_base;
> @@ -99,6 +136,191 @@ valid_offset(uint32_t offset)
>  #define GEN_ENGINE_RENDER 1
>  #define GEN_ENGINE_BLITTER 2
>  
> +static inline struct ggtt_entry *
> +ggtt_entry_next(struct ggtt_entry *entry)
> +{
> +   if (!entry)
> +  return NULL;
> +   struct rb_node *node = rb_node_next(&entry->node);
> +   if (!node)
> +  return NULL;
> +   return rb_node_data(struct ggtt_entry, node, node);
> +}
> +
> +static inline int
> +cmp_uint64(uint64_t a, uint64_t b)
> +{
> +   if (a < b)
> +  return -1;
> +   if (a > b)
> +  return 1;
> +   return 0;
> +}
> +
> +static inline int
> +cmp_ggtt_entry(const struct rb_node *node, const void *addr)
> +{
> +   struct ggtt_entry *entry = rb_node_data(struct ggtt_entry, node, node);
> +   return cmp_uint64(entry->virt_addr, *(uint64_t *)addr);
> +}
> +
> +static struct ggtt_entry *
> +ensure_ggtt_entry(struct rb_tree *tree, uint64_t virt_addr)
> +{
> +   struct rb_node *node = rb_tree_search_sloppy(&ggtt, &virt_addr,
> +cmp_ggtt_entry);
> +   int cmp = 0;
> +   if (!node || (cmp = cmp_ggtt_entry(node, &virt_addr))) {
> +  struct ggtt_entry *new_entry = calloc(1, sizeof(*new_entry));
> +  new_entry->virt_addr = virt_addr;
> +  rb_tree_insert_at(&ggtt, node, &new_entry->node, cmp > 0);
> +  node = &new_entry->node;
> +   }
> +
> +   return rb_node_data(struct ggtt_entry, node, node);
> +}
> +
> +static struct ggtt_entry *
> +search_ggtt_entry(uint64_t virt_addr)
> +{
> +   virt_addr &= ~0xfff;
> +
> +   struct rb_node *node = rb_tree_search(&ggtt, &virt_addr, cmp_ggtt_entry);
> +
> +   if (!node)
> +  return NULL;
> +
> +   return rb_node_data(struct ggtt_entry, node, node);
> +}
> +
> +static inline int
> +cmp_phys_mem(const struct rb_node *node, const void *addr)
> +{
> +   struct phys_mem *mem = rb_node_data(struct phys_mem, node, node);
> +   return cmp_uint64(mem->phys_addr, *(uint64_t *)addr);
> +}
> +
> +static struct phys_mem *
> +ensure_phys_mem(uint64_t phys_addr)
> +{
> +   struct rb_node *node = rb_tree_search_sloppy(&mem, &phys_addr, 
> cmp_phys_mem);
> +   int cmp = 0;
> +   if (!node || (cmp = cmp_phys_mem(node, &phys_addr))) {
> +  struct phys_mem *new_mem = calloc(1, sizeof(*new_mem));
> +  new_mem->phys_addr = phys_addr;
> +  new_mem->fd_offset = mem_fd_len;
> +
> +  int ftruncate_res = ftruncate(mem_fd, mem_fd_len += 4096);
> +  assert(ftruncate_res == 0);
> +
> +  new_mem->data = mmap(NULL, 4096, PROT_READ | PROT_WRITE, MAP_SHARED,
> +   mem_fd, new_mem->fd_offset);
> +  assert(new_mem->data != MAP_FAILED);
> +
> +  rb_tree_insert_at(&mem, no

Re: [Mesa-dev] [PATCH 7/9] intel: aubinator: move address masking

2018-06-18 Thread Rafael Antognolli
Patches 4-7 are:

Reviewed-by: Rafael Antognolli 

On Thu, Jun 14, 2018 at 06:11:43PM +0100, Lionel Landwerlin wrote:
> The Masking is only needed for entry matching.
> 
> Signed-off-by: Lionel Landwerlin 
> ---
>  src/intel/tools/aubinator.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/src/intel/tools/aubinator.c b/src/intel/tools/aubinator.c
> index 2a1b91c0e54..6f2e0d503df 100644
> --- a/src/intel/tools/aubinator.c
> +++ b/src/intel/tools/aubinator.c
> @@ -329,12 +329,12 @@ get_ggtt_batch_bo(void *user_data, uint64_t address)
>  {
> struct gen_batch_decode_bo bo = {0};
>  
> -   address &= ~0xfff;
> -
> list_for_each_entry(struct bo_map, i, &maps, link)
>if (i->bo.addr <= address && i->bo.addr + i->bo.size > address)
>   return i->bo;
>  
> +   address &= ~0xfff;
> +
> struct ggtt_entry *start =
>(struct ggtt_entry *)rb_tree_search_sloppy(&ggtt, &address,
>   cmp_ggtt_entry);
> -- 
> 2.17.1
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] nir: add pass to move load_const

2018-06-18 Thread Ian Romanick
On 06/11/2018 08:23 AM, Rob Clark wrote:
> Run this pass late (after opt loop) to move load_const instructions back
> into the basic blocks which use the result, in cases where a load_const
> is only consumed in a single block.
> 
> This helps reduce register usage in cases where the backend driver
> cannot lower the load_const to a uniform.
> 
> v2: use nir_dominance_lca to figure out a better candidate block to
> move the load_const to, when all it's uses are not in the same
> block
> 
> Signed-off-by: Rob Clark 

I tried enabling this, and the results were a bit different than last
time.  A bunch of shaders were hurt for spills and fills... I may end up
tweaking this a bit before we enable it in i965.

Reviewed-by: Ian Romanick 

> ---
> Ian, I played around with the following hack on top of this:
> ---
>   diff --git a/src/compiler/nir/nir_move_load_const.c 
> b/src/compiler/nir/nir_move_load_const.c
>   index abc53fdce6a..7a84cce2da1 100644
>   --- a/src/compiler/nir/nir_move_load_const.c
>   +++ b/src/compiler/nir/nir_move_load_const.c
>   @@ -54,6 +54,10 @@ get_preferred_block(nir_ssa_def *def)
>  nir_instr *instr = use->parent_instr;
>  nir_block *use_block = instr->block;
>
>   +  // XXX hack:
>   +  if (use_block->imm_dom && exec_list_length(&use_block->instr_list) < 
> 3)
>   + use_block = use_block->imm_dom;
>   +
>  /*
>   * Kind of an ugly special-case, but phi instructions
>   * need to appear first in the block, so by definition
> ---
> 
> I just guessed that threshold at random.  But it does seem to help
> improve the "total cycles in shared programs"..  although my shaderdb
> numbers don't quite match yours (I guess I have an older copy of the
> closed db?)
> 
> However I guess it is probably best to leave it to the backend compiler
> to move load_const to an earlier block when needed to hide latency.
> 
>  src/compiler/Makefile.sources  |   1 +
>  src/compiler/nir/meson.build   |   1 +
>  src/compiler/nir/nir.h |   1 +
>  src/compiler/nir/nir_move_load_const.c | 141 +
>  4 files changed, 144 insertions(+)
>  create mode 100644 src/compiler/nir/nir_move_load_const.c
> 
> diff --git a/src/compiler/Makefile.sources b/src/compiler/Makefile.sources
> index d629c2b8ec8..252cbed0d26 100644
> --- a/src/compiler/Makefile.sources
> +++ b/src/compiler/Makefile.sources
> @@ -254,6 +254,7 @@ NIR_FILES = \
>   nir/nir_lower_wpos_center.c \
>   nir/nir_lower_wpos_ytransform.c \
>   nir/nir_metadata.c \
> + nir/nir_move_load_const.c \
>   nir/nir_move_vec_src_uses_to_dest.c \
>   nir/nir_normalize_cubemap_coords.c \
>   nir/nir_opt_conditional_discard.c \
> diff --git a/src/compiler/nir/meson.build b/src/compiler/nir/meson.build
> index 598c68aff9f..2b5da68c78b 100644
> --- a/src/compiler/nir/meson.build
> +++ b/src/compiler/nir/meson.build
> @@ -145,6 +145,7 @@ files_libnir = files(
>'nir_lower_wpos_ytransform.c',
>'nir_lower_bit_size.c',
>'nir_metadata.c',
> +  'nir_move_load_const.c',
>'nir_move_vec_src_uses_to_dest.c',
>'nir_normalize_cubemap_coords.c',
>'nir_opt_conditional_discard.c',
> diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
> index bb477742dc6..2d620454796 100644
> --- a/src/compiler/nir/nir.h
> +++ b/src/compiler/nir/nir.h
> @@ -2630,6 +2630,7 @@ bool nir_remove_dead_variables(nir_shader *shader, 
> nir_variable_mode modes);
>  bool nir_lower_constant_initializers(nir_shader *shader,
>   nir_variable_mode modes);
>  
> +bool nir_move_load_const(nir_shader *shader);
>  bool nir_move_vec_src_uses_to_dest(nir_shader *shader);
>  bool nir_lower_vec_to_movs(nir_shader *shader);
>  void nir_lower_alpha_test(nir_shader *shader, enum compare_func func,
> diff --git a/src/compiler/nir/nir_move_load_const.c 
> b/src/compiler/nir/nir_move_load_const.c
> new file mode 100644
> index 000..abc53fdce6a
> --- /dev/null
> +++ b/src/compiler/nir/nir_move_load_const.c
> @@ -0,0 +1,141 @@
> +/*
> + * Copyright © 2018 Red Hat
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR

Re: [Mesa-dev] [PATCH] nir: evaluate if condition uses inside the if branches

2018-06-18 Thread Ian Romanick
On 06/17/2018 05:15 PM, Timothy Arceri wrote:
> Since we know what side of the branch we ended up on we can just
> replace the use with a constant.
> 
> All helped shaders are from Unreal Engine 4 besides one shader from
> Dirt Showdown.
> 
> shader-db results SKL:
> 
> total instructions in shared programs: 13219725 -> 13219643 (<.01%)
> instructions in affected programs: 28917 -> 28835 (-0.28%)
> helped: 45
> HURT: 0
> 
> total cycles in shared programs: 529335971 -> 529334604 (<.01%)
> cycles in affected programs: 216209 -> 214842 (-0.63%)
> helped: 45
> HURT: 4
> ---
>  src/compiler/nir/nir_opt_if.c | 84 +++
>  1 file changed, 76 insertions(+), 8 deletions(-)
> 
> diff --git a/src/compiler/nir/nir_opt_if.c b/src/compiler/nir/nir_opt_if.c
> index 863ca630fbd..2666c5da395 100644
> --- a/src/compiler/nir/nir_opt_if.c
> +++ b/src/compiler/nir/nir_opt_if.c
> @@ -350,8 +350,53 @@ opt_if_loop_terminator(nir_if *nif)
> return true;
>  }
>  
> +static void
> +replace_if_condition_use_with_const(nir_src *use, nir_instr *instr,
> +unsigned nir_boolean, void *mem_ctx)
> +{
> +   /* Create const */
> +   nir_load_const_instr *load = nir_load_const_instr_create(mem_ctx, 1, 32);
> +   load->value.u32[0] = nir_boolean;
> +   nir_instr_insert_before(instr,  &load->instr);
> +
> +   /* Rewrite use to use const */
> +   nir_src new_src = nir_src_for_ssa(&load->def);
> +   nir_instr_rewrite_src(use->parent_instr, use, new_src);
> +}
> +
>  static bool
> -opt_if_cf_list(nir_builder *b, struct exec_list *cf_list)
> +opt_if_evaluate_condition_use(nir_if *nif, void *mem_ctx)
> +{
> +   bool progress = false;
> +
> +   /* Evaluate any uses of the if condition inside the if branches */
> +   nir_foreach_use_safe(use_src, nif->condition.ssa) {

Does this iterate both the uses by regular instructions and the uses by
other if-statements?  I was working on something similar (though using a
different approach) because I came across some shaders that, after loop
unrolling, had some neat stuff like

if (ssa_111) {
...
if (ssa_111) {
...
if (ssa_111) {
...
if (ssa_111) {
...
if (ssa_111) {
...
if (ssa_111) {
...

> +  nir_block *first_then = nir_if_first_then_block(nif);
> +  if (use_src->parent_instr->block->index > first_then->index) {
> + nir_block *first_else = nir_if_first_else_block(nif);
> + if (use_src->parent_instr->block->index < first_else->index) {
> +nir_instr *instr = nir_block_first_instr(first_then);
> +replace_if_condition_use_with_const(use_src, instr,
> +NIR_TRUE, mem_ctx);
> +
> +progress = true;
> + } else if (use_src->parent_instr->block->index <
> +nir_if_last_else_block(nif)->index) {
> +nir_instr *instr = nir_block_first_instr(first_else);
> +replace_if_condition_use_with_const(use_src, instr,
> +NIR_FALSE, mem_ctx);
> +
> +progress = true;
> + }
> +  }
> +   }
> +
> +   return progress;
> +}
> +
> +static bool
> +opt_if_cf_list(nir_builder *b, struct exec_list *cf_list, void *mem_ctx,
> +   bool *md_altered)
>  {
> bool progress = false;
> foreach_list_typed(nir_cf_node, cf_node, node, cf_list) {
> @@ -361,17 +406,30 @@ opt_if_cf_list(nir_builder *b, struct exec_list 
> *cf_list)
>  
>case nir_cf_node_if: {
>   nir_if *nif = nir_cf_node_as_if(cf_node);
> - progress |= opt_if_cf_list(b, &nif->then_list);
> - progress |= opt_if_cf_list(b, &nif->else_list);
> - progress |= opt_if_loop_terminator(nif);
> - progress |= opt_if_simplification(b, nif);
> + progress |= opt_if_cf_list(b, &nif->then_list, mem_ctx, md_altered);
> + progress |= opt_if_cf_list(b, &nif->else_list, mem_ctx, md_altered);
> +
> + if (*md_altered == false)
> +progress |= opt_if_evaluate_condition_use(nif, mem_ctx);
> +
> + bool lp_term_progress = opt_if_loop_terminator(nif);
> + bool if_simp_progress = opt_if_simplification(b, nif);
> + if (lp_term_progress || if_simp_progress) {
> +*md_altered = true;
> +progress = true;
> + }
> +
>   break;
>}
>  
>case nir_cf_node_loop: {
>   nir_loop *loop = nir_cf_node_as_loop(cf_node);
> - progress |= opt_if_cf_list(b, &loop->body);
> - progress |= opt_peel_loop_initial_if(loop);
> + progress |= opt_if_cf_list(b, &loop->body, mem_ctx, md_altered);
> + bool lp_peel_progress = opt_peel_loop_initial_if(loop);
> + if (lp_peel_progress) {
> +*md_altered = true;
> +progress 

Re: [Mesa-dev] [PATCH] [RFC] i965/blit: bump some limits to 64k

2018-06-18 Thread Nanley Chery
On Thu, Jun 14, 2018 at 07:50:54PM +0100, Chris Wilson wrote:
> Quoting Nanley Chery (2018-06-14 19:46:09)
> > On Thu, Jun 14, 2018 at 10:01:18AM -0700, Nanley Chery wrote:
> > > On Thu, Jun 14, 2018 at 04:18:30PM +0300, Martin Peres wrote:
> > > > This fixes screenshots using 8k+ wide display setups in modesetting.
> > > > 
> > > > Chris Wilson even recommended the changes in intel_mipmap_tree.c
> > > > should read 131072 instead of 65535, but I for sure got confused by
> > > > his explanation.
> > > > 
> > > > In any case, I would like to use this RFC patch as a forum to discuss
> > > > why the fallback path is broken[1], and as to what should be the
> > > > limits for HW-accelerated blits now that we got rid of the blitter
> > > > usage on recent platforms.
> > > > 
> > > 
> > > Hi,
> > > 
> > > My understanding is that the fallback path is broken because we silently
> > > ignore miptree_create_for_bo's request for a tiled miptree. This results
> > > in some parts of mesa treating the surface as tiled and other parts of
> > > treating the surface as linear.
> > > 
> > > I couldn't come up with a piglit test for this when I was working on a
> > > fix. Please let me know if you can think of any.
> > > 
> > > I think what the limits should be depends on which mesa branch you're
> > > working off of.
> > > 
> > > * On the master branch of mesa, which has some commits which reduce the
> > >   dependence on the BLT engine, we can remove these limits by using BLORP.
> > >   As much as I can tell, BLORP can handle images as wide as the surface
> > >   pitch limit in the RENDER_SURFACE_STATE packet will allow.
> > > 
> > >   I sent out a series [a] a couple weeks ago that removes the limits
> > >   imposed by the hardware blitter.
> > > 
> > > * On the stable branch however, we can modify some incorrect code to set
> > >   the correct BLT limits (as Chris has suggested). The BLT engine's pitch
> > >   field is a signed 16bit integer, whose unit changes depending on the
> > >   tiling of the surface. For linear surfaces, it's in units of bytes and
> > >   for non-linear surfaces, it's in units of dwords. This translates to
> > >   2^15-1 bytes or (2^15-1) * 4 bytes respectively.
> > >   
> > >   I made a branch [b] which does this already, but I think my rebasing +
> > >   testing strategy for stable branches on the CI might be incorrect.
> > 
> > I just rebased this branch onto master and tested it on the CI.
> > Everything passes except for SNB. I get 1 GPU hang and two test
> > failures:
> > * failure-gpu-hang-otc-gfxtest-snbgt1-01-snbm64.compile.error
> > * KHR-GL33.shaders.uniform_block.random.all_shared_buffer.3.snbm64
> > * 
> > dEQP-EGL.functional.color_clears.multi_context.gles3.rgba_pbuffer.snbm64
> 
> What are the command lines? Assuming piglit, which the last one doesn't
> appear to be, I can try, see what happens, and see if I can be of
> assistance.

I'm not sure how to run these tests with piglit... Also, when running
the last test by itself, I don't get a GPU hang. I'm assuming an unknown
test is causing others to fail. The CI does say the hanging test is
GTF-GL33.gtf21.GL.build.dvec4_frag, but I'm not sure how to run it to
confirm it.

-Nanley

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


Re: [Mesa-dev] [PATCH 00/16] Move the Mesa Website to Sphinx

2018-06-18 Thread Laura Ekstrand
Jordan's version is awesome.  But in general most people are concerned that
WebGL will crash browsers.

One idea is to look into using three.js, which is a front-end library for
web graphics.  It's backed by multiple frameworks including WebGL.

On Sun, Jun 17, 2018, 9:23 PM Jordan Justen 
wrote:

> On 2018-06-17 17:43:37, Jason Ekstrand wrote:
> > On Sun, Jun 17, 2018 at 5:34 PM, Jordan Justen <
> jordan.l.jus...@intel.com>
> > wrote:
> >
> > > On 2018-06-17 16:42:13, Jason Ekstrand wrote:
> > > > On Sun, Jun 17, 2018 at 4:21 PM, Matt Turner 
> wrote:
> > > >
> > > > > Also, Erik's is animated not with JavaScript at all, but just CSS.
> > > > > That's really cool.
> > > > >
> > > >
> > > > The only thing the JS does is turn the animation on and off.  The
> actual
> > > > animation is pure SVG. The main reason (as I understood it) for the
> > > > JavaScript is to make the gears *not* turn if someone has disabled
> > > > JavaScript.  I'm sure people will disagree as to whether or not
> that's a
> > > > feature. :-)  I'm not sure if you can get the turn-on-hover thing
> with
> > > just
> > > > SVG and not JS though... /me doesn't know either all that well.
> > >
> > > All the JS and webgl. :)
> > >
> > > https://people.freedesktop.org/~jljusten/webgl-logo/gears.html
> > >
> > > Actually, it doesn't start webgl until you move your mouse over the
> > > logo. Before that it is displaying a jpg of the gears.
> > >
> >
> > I like how the gears smoothly spin up and slow to a stop.  Not sure what
> I
> > think of the font.
>
> I changed the font to Roboto Slab, which I saw you mentioned earlier.
>
> -Jordan
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 00/16] Move the Mesa Website to Sphinx

2018-06-18 Thread Laura Ekstrand
This looks like a useful check for WebGL compatibility:
https://threejs.org/docs/index.html#manual/introduction/WebGL-compatibility-check

On Mon, Jun 18, 2018, 3:50 PM Laura Ekstrand  wrote:

> Jordan's version is awesome.  But in general most people are concerned
> that WebGL will crash browsers.
>
> One idea is to look into using three.js, which is a front-end library for
> web graphics.  It's backed by multiple frameworks including WebGL.
>
> On Sun, Jun 17, 2018, 9:23 PM Jordan Justen 
> wrote:
>
>> On 2018-06-17 17:43:37, Jason Ekstrand wrote:
>> > On Sun, Jun 17, 2018 at 5:34 PM, Jordan Justen <
>> jordan.l.jus...@intel.com>
>> > wrote:
>> >
>> > > On 2018-06-17 16:42:13, Jason Ekstrand wrote:
>> > > > On Sun, Jun 17, 2018 at 4:21 PM, Matt Turner 
>> wrote:
>> > > >
>> > > > > Also, Erik's is animated not with JavaScript at all, but just CSS.
>> > > > > That's really cool.
>> > > > >
>> > > >
>> > > > The only thing the JS does is turn the animation on and off.  The
>> actual
>> > > > animation is pure SVG. The main reason (as I understood it) for the
>> > > > JavaScript is to make the gears *not* turn if someone has disabled
>> > > > JavaScript.  I'm sure people will disagree as to whether or not
>> that's a
>> > > > feature. :-)  I'm not sure if you can get the turn-on-hover thing
>> with
>> > > just
>> > > > SVG and not JS though... /me doesn't know either all that well.
>> > >
>> > > All the JS and webgl. :)
>> > >
>> > > https://people.freedesktop.org/~jljusten/webgl-logo/gears.html
>> > >
>> > > Actually, it doesn't start webgl until you move your mouse over the
>> > > logo. Before that it is displaying a jpg of the gears.
>> > >
>> >
>> > I like how the gears smoothly spin up and slow to a stop.  Not sure
>> what I
>> > think of the font.
>>
>> I changed the font to Roboto Slab, which I saw you mentioned earlier.
>>
>> -Jordan
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 00/16] Move the Mesa Website to Sphinx

2018-06-18 Thread Ilia Mirkin
Not sure how much voting power I have, but I really like Erik's version at

https://codepen.io/kusma/pen/vrXppL

It uses CSS3 animation on hover, so it's pretty low impact. Some
slight cleverness could even include a fallback for a browser that
doesn't support SVG.

IMO solutions like three.js and so on are non-starters for something
as trivial as a logo. Having some mesa-demos ported using it might be
neat, but the logo should be kept simple and accessible.

  -ilia


On Mon, Jun 18, 2018 at 6:52 PM, Laura Ekstrand  wrote:
> This looks like a useful check for WebGL compatibility:
> https://threejs.org/docs/index.html#manual/introduction/WebGL-compatibility-check
>
> On Mon, Jun 18, 2018, 3:50 PM Laura Ekstrand  wrote:
>>
>> Jordan's version is awesome.  But in general most people are concerned
>> that WebGL will crash browsers.
>>
>> One idea is to look into using three.js, which is a front-end library for
>> web graphics.  It's backed by multiple frameworks including WebGL.
>>
>> On Sun, Jun 17, 2018, 9:23 PM Jordan Justen 
>> wrote:
>>>
>>> On 2018-06-17 17:43:37, Jason Ekstrand wrote:
>>> > On Sun, Jun 17, 2018 at 5:34 PM, Jordan Justen
>>> > 
>>> > wrote:
>>> >
>>> > > On 2018-06-17 16:42:13, Jason Ekstrand wrote:
>>> > > > On Sun, Jun 17, 2018 at 4:21 PM, Matt Turner 
>>> > > > wrote:
>>> > > >
>>> > > > > Also, Erik's is animated not with JavaScript at all, but just
>>> > > > > CSS.
>>> > > > > That's really cool.
>>> > > > >
>>> > > >
>>> > > > The only thing the JS does is turn the animation on and off.  The
>>> > > > actual
>>> > > > animation is pure SVG. The main reason (as I understood it) for the
>>> > > > JavaScript is to make the gears *not* turn if someone has disabled
>>> > > > JavaScript.  I'm sure people will disagree as to whether or not
>>> > > > that's a
>>> > > > feature. :-)  I'm not sure if you can get the turn-on-hover thing
>>> > > > with
>>> > > just
>>> > > > SVG and not JS though... /me doesn't know either all that well.
>>> > >
>>> > > All the JS and webgl. :)
>>> > >
>>> > > https://people.freedesktop.org/~jljusten/webgl-logo/gears.html
>>> > >
>>> > > Actually, it doesn't start webgl until you move your mouse over the
>>> > > logo. Before that it is displaying a jpg of the gears.
>>> > >
>>> >
>>> > I like how the gears smoothly spin up and slow to a stop.  Not sure
>>> > what I
>>> > think of the font.
>>>
>>> I changed the font to Roboto Slab, which I saw you mentioned earlier.
>>>
>>> -Jordan
>>> ___
>>> mesa-dev mailing list
>>> mesa-dev@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


  1   2   >