date:20180330

Re: [Mesa-dev] [PATCH] ac/nir: Fix include for LLVMAddPromoteMemoryToRegisterPass

2018-03-30 Thread Dylan Baker

Quoting Mike Lothian (2018-03-29 17:49:30)
> 
> 
> On Fri, 30 Mar 2018, 01:42 Dylan Baker,  wrote:
> 
> Quoting Mike Lothian (2018-03-29 16:56:28)
> > Include llvm-c/Transforms/Utils.h with the newest LLVM 7
> >
> > Fixes: 2dd4f35c7fc llvm-c: Split Utils out of Scalar.h
> 
> I have no comment on the patch itself.
> 
> JFYI, this tag ("Fixes") has specific meaning in mesa and should only 
> refer
> to
> mesa commits (we have scripts for stable releases that parse that
> information).
> 
> Dylan
> 
> 
> Ah sorry about that

No worries, these are mesa specific so a lot people don't know what they're for.

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] spirv: Fix building with SCons

2018-03-30 Thread Jason Ekstrand


On March 30, 2018 09:40:13 Brian Paul  wrote:

OK, I'll have some patches soon but I'm stuck on one issue.

Around spriv_to_nir.c:2090 we have

if (operands & SpvImageOperandsConstOffsetsMask) {
gather_offsets = vtn_ssa_value(b, w[idx++]);
(*p++) = (nir_tex_src){};
}

The (nir_tex_src){} expression is not valid for MSVC (syntax error).  I
haven't figured out exactly what that's supposed to do.

It's a GCC extension. An initializer with empty braces initializer to zero. 
I'm on my phone so I can't see any more context but that line strikes me 
as a bit weird.  We could add a NIR_TEX_SRC_INIT helper of this is useful.



Replacing it with (*p++) = (nir_tex_src)0; works but I'm not sure that's
correct.

I don't know what that does...


Ilia wrote the line in question.  Ilia?

-Brian



On 03/30/2018 09:25 AM, Brian Paul wrote:
Thanks, Neil.

This fixes the SCons build on Linux, but on Windows there's a whole
bunch of other issues:

c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(232):
error C2085:
'vtn_instruction_handler': not in formal parameter list
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(235):
error C2085:
'vtn_build_cfg': not in formal parameter list
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(237):
error C2146:
syntax error: missing ')' before identifier 'instruction_handler'
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(237):
error C2081:
'vtn_instruction_handler': name in formal parameter list illegal
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(237):
error C2085:
'vtn_function_emit': not in formal parameter list
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(237):
error C2146:
syntax error: missing ',' before identifier 'instruction_handler'
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(237):
error C2059:
syntax error: ')'
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(241):
error C2146:
syntax error: missing ')' before identifier 'handler'
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(241):
error C2081:
'vtn_instruction_handler': name in formal parameter list illegal
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(241):
error C2085:
'vtn_foreach_instruction': not in formal parameter list
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(241):
error C2146:
syntax error: missing ',' before identifier 'handler'
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(241):
error C2059:
syntax error: ')'
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(369):
error C2085:
'vtn_types_compatible': not in formal parameter list
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(504):
error C2061:
syntax error: identifier 'vtn_instruction_handler'
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(505):
error C2059:
syntax error: '}'
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(506):
error C2059:
syntax error: '}'
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(597):
error C2036:
'vtn_value *': unknown size
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(607):
error C2037:
left of 'value_type' specifies undefined struct/union 'vtn_value'
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(607):
error C2065:
'vtn_value_type_invalid': undeclared identifier
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(609):
error C2037:
left of 'value_type' specifies undefined struct/union 'vtn_value'
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(611):
error C2036:
'vtn_value *': unknown size
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(618):
error C2037:
left of 'base_type' specifies undefined struct/union 'vtn_type'
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(618):
error C2065:
'vtn_base_type_pointer': undeclared identifier
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(619):
error C2065:
'vtn_value_type_pointer': undeclared identifier
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(620):
error C2037:
left of 'pointer' specifies undefined struct/union 'vtn_value'
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(620):
error C2037:
left of 'def' specifies undefined struct/union 'vtn_ssa_value'
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(620):
warning C413
3: 'function': incompatible types - from 'vtn_type *' to 'nir_ssa_def *'
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(620):
error C2198:
'vtn_pointer_from_ssa': too few arguments for call
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(622):
error C2065:
'vtn_value_type_ssa': undeclared identifier
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(623):
error C2037:
left of 'ssa' specifies undefined struct/union 'vtn_value'
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(634):
error C2037:
left of 'value_type'

Re: [Mesa-dev] Question about NIR changes since mesa 17.3

2018-03-30 Thread Timothy Arceri


On 31/03/18 00:43, Qiang Yu wrote:

Hi guys,

I'm rebasing the mesa-lima code from 17.3 to 18.0 and found the NIR changes
in 18.0 will always do nir_lower_io_to_scalar_early() for the output of 
vertex

shader and input of fragment shader. My first question is:
Is it for the link time optimization that we can drop un-used channel in 
a slot

and merge channels in different slots to one slot if possible?


Correct.



Mali4xx GPU has different processor for vertex shader (GP) and fragment
shader (PP). Scalar is OK for GP, but PP more like vec ops. So this scalar
change make PP not comfortable. I like the link time optimization, so don't
want to just disable it. My second question is:
Is there any NIR helper that I can use to merge scalar input to vector 
again?

Or what's the right way to make the scalar input vector again?

I see master mesa branch will further do nir_lower_alu_to_scalar
for all nir which will get more pain for mali PP, so my third question is:
How other vec GPU solve this problem or anyway to disable it?


It's not a problem for any other GPUs using Gallium currently. You might 
need to add a CAP and skip the passes for your driver or run a new 
recombine pass which I think you might need to write. You could check 
with the i965 guys if a pass exist as they are the only ones using NIR 
with a vector backend, but I don't think there is.




Thanks,
Qiang

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

[Mesa-dev] [AppVeyor] mesa master #7342 completed

2018-03-30 Thread AppVeyor



Build mesa 7342 completed



Commit bebf758c49 by Brian Paul on 3/27/2018 6:39 PM:

docs: document WGL_SWAP_INTERVAL env var\n\nReviewed-by: Charmaine Lee 


Configure your notification preferences

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

Re: [Mesa-dev] [PATCH] nir+drivers: add helpers to get # of src/dest components

2018-03-30 Thread Eric Anholt

Rob Clark  writes:

> Add helpers to get the number of src/dest components for an intrinsic,
> and update spots that were open-coding this logic to use the helpers
> instead.
>
> Signed-off-by: Rob Clark 
> ---
>  src/compiler/nir/nir.h | 22 
> ++
>  src/compiler/nir/nir_opt_copy_propagate.c  |  5 +
>  src/compiler/nir/nir_validate.c| 10 ++
>  src/compiler/spirv/spirv_to_nir.c  |  3 +--
>  .../drivers/freedreno/ir3/ir3_compiler_nir.c   |  6 +-
>  src/intel/compiler/brw_fs_nir.cpp  | 11 +--
>  6 files changed, 32 insertions(+), 25 deletions(-)

Reviewed-by: Eric Anholt 


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

[Mesa-dev] [Bug 105817] scons build broken by glSpecializeShaderARB

2018-03-30 Thread bugzilla-daemon

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

Brian Paul  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #3 from Brian Paul  ---
Should be fixed as of 26bc983c8374fd98dc3b8f8fa273f3063e3ac249 with the patch
series by Neil and myself.

-- 
You are receiving this mail because:
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] mesa: readpixels add support for GL_HALF_FLOAT

2018-03-30 Thread Eric Anholt

Lin Johnson  writes:

> Ext_color_buffer_half_float is using type GL_HALF_FLOAT
> and data_type GL_FLOAT. This fix Android CTS test
> android.view.cts.PixelCopyTest
> v2: remove commtens of Ext_color_buffer_half_float.
> As Ext_color_buffer__float can use type GL_HALF_FLOAT
>
> Reviewed-by:   Palli, Tapani 
> Signed-off-by: Lin Johnson 

I've been looking into CTS issues on VC5, and I think this patch should
be reverted.

The issue is that the text above that in the spec disallows this case.
From GLES 3.0.2:

Only two combinations of format and type are accepted in most
cases. The first varies depending on the format of the currently
bound rendering surface. For normalized fixed-point rendering
surfaces, the combination format RGBA and type UNSIGNED_BYTE is
accepted. For signed integer rendering surfaces, the combina- tion
format RGBA_INTEGER and type INT is accepted. For unsigned integer
rendering surfaces, the combination format RGBA_INTEGER and type
UNSIGNED_INT is accepted.

[...]

ReadPixels generates an INVALID_OPERATION error if the combination
of format and type is unsupported.

and this spec adds on to that first paragraph:

For floating-point rendering surfaces, the combination
format RGBA and type FLOAT is accepted.

The second allowed combo is:

The second is an implementation-chosen format from among those
defined in table 3.2, excluding formats DEPTH_COMPONENT and
DEPTH_STENCIL . The values of format and type for this format may be
determined by calling Get- Integerv with the symbolic constants
IMPLEMENTATION_COLOR_READ_FORMAT and IMPLEMENTATION_COLOR_READ_TYPE
, respectively.

The failing cases are in the CTS's packed_pixels testsuite, such as:

KHR-GLES3.packed_pixels.pbo_rectangle.r11f_g11f_b10f

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

Re: [Mesa-dev] [PATCH 2/6] nir/spirv: fix MSVC warning in vtn_align_u32()

2018-03-30 Thread Neil Roberts

Patches 2-6 are:

Reviewed-by: Neil Roberts 

Thanks a lot for fixing this.

Regards,
- Neil

Brian Paul  writes:

> Fixes warning that "negation of an unsigned value results in an
> unsigned value".
> ---
>  src/compiler/spirv/vtn_private.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/compiler/spirv/vtn_private.h 
> b/src/compiler/spirv/vtn_private.h
> index d8a00f9..269de92 100644
> --- a/src/compiler/spirv/vtn_private.h
> +++ b/src/compiler/spirv/vtn_private.h
> @@ -732,7 +732,7 @@ void vtn_handle_decoration(struct vtn_builder *b, SpvOp 
> opcode,
>  static inline uint32_t
>  vtn_align_u32(uint32_t v, uint32_t a)
>  {
> -   assert(a != 0 && a == (a & -a));
> +   assert(a != 0 && a == (a & -((int32_t) a)));
> return (v + a - 1) & ~(a - 1);
>  }
>  
> -- 
> 2.7.4
>
> ___
> 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 support for 4 constant offsets in tg4

2018-03-30 Thread Karol Herbst

On Fri, Mar 30, 2018 at 9:35 PM, Eric Anholt  wrote:
> Karol Herbst  writes:
>
>> Nvidia hardware can do that natively so there is no need to lower that to 
>> four
>> TG4s instructions.
>>
>> Signed-off-by: Karol Herbst 
>> ---
>>  src/compiler/glsl/glsl_to_nir.cpp | 25 ++---
>>  src/compiler/nir/nir.h|  9 -
>>  src/compiler/nir/nir_print.c  |  9 +
>>  3 files changed, 35 insertions(+), 8 deletions(-)
>>
>> diff --git a/src/compiler/glsl/glsl_to_nir.cpp 
>> b/src/compiler/glsl/glsl_to_nir.cpp
>> index c4a6d52a5b2..4ea5f1616a7 100644
>> --- a/src/compiler/glsl/glsl_to_nir.cpp
>> +++ b/src/compiler/glsl/glsl_to_nir.cpp
>> @@ -2042,7 +2042,9 @@ nir_visitor::visit(ir_texture *ir)
>>num_srcs++;
>> if (ir->shadow_comparator != NULL)
>>num_srcs++;
>> -   if (ir->offset != NULL)
>> +   if (ir->offset != NULL && ir->offset->type->is_array())
>> +  num_srcs += ir->offset->type->array_size();
>> +   else if (ir->offset != NULL)
>>num_srcs++;
>>
>> nir_tex_instr *instr = nir_tex_instr_create(this->shader, num_srcs);
>> @@ -2097,12 +2099,21 @@ nir_visitor::visit(ir_texture *ir)
>>
>> if (ir->offset != NULL) {
>>/* we don't support multiple offsets yet */
>> -  assert(ir->offset->type->is_vector() || 
>> ir->offset->type->is_scalar());
>> -
>> -  instr->src[src_number].src =
>> - nir_src_for_ssa(evaluate_rvalue(ir->offset));
>> -  instr->src[src_number].src_type = nir_tex_src_offset;
>> -  src_number++;
>> +  if (ir->offset->type->is_vector() || ir->offset->type->is_scalar()) {
>> + instr->src[src_number].src =
>> +nir_src_for_ssa(evaluate_rvalue(ir->offset));
>> + instr->src[src_number].src_type = nir_tex_src_offset;
>> + src_number++;
>> +  } else if (ir->offset->type->is_array()) {
>> + for (int i = 0; i < ir->offset->type->array_size(); i++) {
>> +instr->src[src_number].src =
>> +   
>> nir_src_for_ssa(evaluate_rvalue(ir->offset->as_constant()->get_array_element(i)->as_rvalue()));
>> +instr->src[src_number].src_type = 
>> (nir_tex_src_type)(nir_tex_src_offset + i);
>> +src_number++;
>> + }
>> +  } else {
>> + assert(false);
>
> Maybe just do assert(ir->offset->type->is_array()) in the previous block
> instead of the extra else.  And optionally pull
> ir->offset->as_constant() out to a temporary for nicer column wrapping.
> Other than that, this seems good.
>

well the thing is, it only works with constants within the array. If
you have non constant values the code wouldn't assert on that. But I
will try to think about something nice there.

> Reviewed-by: Eric Anholt 
>
> If I'm reading my specs right, I'll be able to use this on vc6, too.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] nir: add support for 4 constant offsets in tg4

2018-03-30 Thread Eric Anholt

Karol Herbst  writes:

> Nvidia hardware can do that natively so there is no need to lower that to four
> TG4s instructions.
>
> Signed-off-by: Karol Herbst 
> ---
>  src/compiler/glsl/glsl_to_nir.cpp | 25 ++---
>  src/compiler/nir/nir.h|  9 -
>  src/compiler/nir/nir_print.c  |  9 +
>  3 files changed, 35 insertions(+), 8 deletions(-)
>
> diff --git a/src/compiler/glsl/glsl_to_nir.cpp 
> b/src/compiler/glsl/glsl_to_nir.cpp
> index c4a6d52a5b2..4ea5f1616a7 100644
> --- a/src/compiler/glsl/glsl_to_nir.cpp
> +++ b/src/compiler/glsl/glsl_to_nir.cpp
> @@ -2042,7 +2042,9 @@ nir_visitor::visit(ir_texture *ir)
>num_srcs++;
> if (ir->shadow_comparator != NULL)
>num_srcs++;
> -   if (ir->offset != NULL)
> +   if (ir->offset != NULL && ir->offset->type->is_array())
> +  num_srcs += ir->offset->type->array_size();
> +   else if (ir->offset != NULL)
>num_srcs++;
>  
> nir_tex_instr *instr = nir_tex_instr_create(this->shader, num_srcs);
> @@ -2097,12 +2099,21 @@ nir_visitor::visit(ir_texture *ir)
>  
> if (ir->offset != NULL) {
>/* we don't support multiple offsets yet */
> -  assert(ir->offset->type->is_vector() || ir->offset->type->is_scalar());
> -
> -  instr->src[src_number].src =
> - nir_src_for_ssa(evaluate_rvalue(ir->offset));
> -  instr->src[src_number].src_type = nir_tex_src_offset;
> -  src_number++;
> +  if (ir->offset->type->is_vector() || ir->offset->type->is_scalar()) {
> + instr->src[src_number].src =
> +nir_src_for_ssa(evaluate_rvalue(ir->offset));
> + instr->src[src_number].src_type = nir_tex_src_offset;
> + src_number++;
> +  } else if (ir->offset->type->is_array()) {
> + for (int i = 0; i < ir->offset->type->array_size(); i++) {
> +instr->src[src_number].src =
> +   
> nir_src_for_ssa(evaluate_rvalue(ir->offset->as_constant()->get_array_element(i)->as_rvalue()));
> +instr->src[src_number].src_type = 
> (nir_tex_src_type)(nir_tex_src_offset + i);
> +src_number++;
> + }
> +  } else {
> + assert(false);

Maybe just do assert(ir->offset->type->is_array()) in the previous block
instead of the extra else.  And optionally pull
ir->offset->as_constant() out to a temporary for nicer column wrapping.
Other than that, this seems good.

Reviewed-by: Eric Anholt 

If I'm reading my specs right, I'll be able to use this on vc6, too.


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

Re: [Mesa-dev] [PATCH] glapi: define GL_API to be KEYWORD1 in glapi_dispatch.c (v2)

2018-03-30 Thread Mathias Fröhlich

Hi Brian,

Thanks!

Reviewed-by: Mathias Fröhlich 

best 

Mathias

On Friday, 30 March 2018 20:52:58 CEST Brian Paul wrote:
> This fixes a Windows build warning where the prototypes for the ES
> function in the header file don't match the prototypes in this file
> because the GL_API and GLAPI macros are defined differently.
> 
> v2: defined GL_API to KEYWORD1 instead of GLAPI, per Mathias.
> ---
>  src/mapi/glapi/glapi_dispatch.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/src/mapi/glapi/glapi_dispatch.c b/src/mapi/glapi/
glapi_dispatch.c
> index 3239523..ca15449 100644
> --- a/src/mapi/glapi/glapi_dispatch.c
> +++ b/src/mapi/glapi/glapi_dispatch.c
> @@ -97,6 +97,13 @@
>   */
>  #include 
>  
> +
> +/* Redefine GL_API to avoid MSVC/MinGW warnings about different dllimport
> + * attributes for these prototypes vs those in the GLES/gl.h header.
> + */
> +#undef GL_API
> +#define GL_API KEYWORD1
> +
>  GL_API void GL_APIENTRY glClearDepthf (GLclampf depth);
>  GL_API void GL_APIENTRY glClipPlanef (GLenum plane, const GLfloat 
*equation);
>  GL_API void GL_APIENTRY glFrustumf (GLfloat left, GLfloat right, GLfloat 
bottom, GLfloat top, GLfloat zNear, GLfloat zFar);
> 




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

[Mesa-dev] [PATCH] glapi: define GL_API to be KEYWORD1 in glapi_dispatch.c (v2)

2018-03-30 Thread Brian Paul

This fixes a Windows build warning where the prototypes for the ES
function in the header file don't match the prototypes in this file
because the GL_API and GLAPI macros are defined differently.

v2: defined GL_API to KEYWORD1 instead of GLAPI, per Mathias.
---
 src/mapi/glapi/glapi_dispatch.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/src/mapi/glapi/glapi_dispatch.c b/src/mapi/glapi/glapi_dispatch.c
index 3239523..ca15449 100644
--- a/src/mapi/glapi/glapi_dispatch.c
+++ b/src/mapi/glapi/glapi_dispatch.c
@@ -97,6 +97,13 @@
  */
 #include 
 
+
+/* Redefine GL_API to avoid MSVC/MinGW warnings about different dllimport
+ * attributes for these prototypes vs those in the GLES/gl.h header.
+ */
+#undef GL_API
+#define GL_API KEYWORD1
+
 GL_API void GL_APIENTRY glClearDepthf (GLclampf depth);
 GL_API void GL_APIENTRY glClipPlanef (GLenum plane, const GLfloat *equation);
 GL_API void GL_APIENTRY glFrustumf (GLfloat left, GLfloat right, GLfloat 
bottom, GLfloat top, GLfloat zNear, GLfloat zFar);
-- 
2.7.4

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

Re: [Mesa-dev] [PATCH] glapi: define GL_API to be GLAPI in glapi_dispatch.c

2018-03-30 Thread Brian Paul


On 03/30/2018 09:39 AM, Mathias Fröhlich wrote:


On Friday, 30 March 2018 16:42:43 CEST Brian Paul wrote:

This fixes a Windows build warning where the prototypes for the ES
function in the header file don't match the prototypes in this file
because the GL_API and GLAPI macros are defined differently.
---
  src/mapi/glapi/glapi_dispatch.c | 5 +
  1 file changed, 5 insertions(+)

diff --git a/src/mapi/glapi/glapi_dispatch.c b/src/mapi/glapi/

glapi_dispatch.c

index 3239523..f0a8c36 100644
--- a/src/mapi/glapi/glapi_dispatch.c
+++ b/src/mapi/glapi/glapi_dispatch.c
@@ -97,6 +97,11 @@
   */
  #include 
  
+

+/* Use the GLAPI annotation from GL/gl.h, not GL_API from GLES/gl.h */
+#undef GL_API
+#define GL_API GLAPI
+



Hi Brian,

I wonder if this proposed change introduces some similar warning on some non
windows builds.

It looks like down in the generated glapitemp.h included down the file, the
functions get implemented like

KEYWORD1  KEYWORD2 glSomething(...);

So, may be you want to define:

#define GL_API KEYWORD1

to match the prototypes with the implementation?


That works too.  I'll post a v2.

-Brian


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

Re: [Mesa-dev] [PATCH] RFC: Externd IMG_context_priority with NV_context_priority_realtime

2018-03-30 Thread Kenneth Graunke

On Friday, March 30, 2018 7:40:13 AM PDT Chris Wilson wrote:
> NV_context_priority_realtime
> https://www.khronos.org/registry/EGL/extensions/NV/EGL_NV_context_priority_realtime.txt
> 
> "This extension allows an EGLContext to be created with one extra
> priority level in addition to three priority levels that are part of
> EGL_IMG_context_priority extension.
> 
> This new level has extra privileges that are not available to other three
> levels. Some of the privileges may include:
> - Allow realtime priority to only few contexts
> - Allow realtime priority only to trusted applications
> - Make sure realtime priority contexts are executed immediately
> - Preempt any current context running on GPU on submission of
>   commands for realtime context"
> 
> At its most basic, it just adds an extra enum and level into the existing
> context priority framework.
> 
> For i915, we are proposing to use a quality-of-service parameter in
> addition to that of just a priority that usurps everyone. Due to our HW,
> preemption may not be immediate and will be forced to wait until an
> uncooperative process hits an arbitration point. To prevent that unduly
> impacting the privileged RealTime context, we back up the preemption
> request with a timeout to reset the GPU and forcibly evict the GPU hog
> in order to execute the new context.

I am strongly against exposing this in general.  Performing a GPU reset
in the middle of a batch can completely screw up whatever application
was running.  If the application is using robustness extensions, we may
be forced to return GL_DEVICE_LOST, causing the application to have to
recreate their entire GL context and start over.  If not, we may try to
let them limp on(*) - and hope they didn't get too badly damaged by some
of their commands not executing, or executing twice (if the kernel tries
to resubmit it).  But it may very well cause the app to misrender, or
even crash.

This seems like a crazy plan to me.  Scheduling has never been allowed
to just kill random processes.  If you ever hit that case, then your
customers will see random application crashes, glitches, GPU hangs,
and be pretty unhappy with the result.  And not because something was
broken, but because somebody was impatient and an app was a bit slow.

If you have work that is so mission critical, maybe you shouldn't run it
on the same machine as one that runs applications which you care so
little about that you're willing to watch them crash and burn.  Don't
run the entertainment system on the flight computer, so to speak.

At any rate, I suspect you wouldn't go down this path unless you
absolutely had to, and there was some incredible forcing function at
play.  Which is why I said "against exposing this in general".  Maybe
you have a customer that's willing to play with fire.  I just wanted
to make it very abundantly clear that this is hazardous.

--Ken

(*) We don't actually let things limp along after a bad hang today, if
execbuf fails we just exit(1) and let it crash and burn.  We really
should fix that (but I need to fix some state tracking bugs first).

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

Re: [Mesa-dev] [PATCH 1/1] gallivm: Fix build after llvm r328839

2018-03-30 Thread Jan Vesely

On Fri, 2018-03-30 at 18:41 +0200, Dieter Nützel wrote:
> Hello Jan,
> 
> can you have a look on this one (instead) and commit?
> https://lists.freedesktop.org/archives/mesa-dev/2018-March/190535.html
> https://patchwork.freedesktop.org/series/40916/

You should probably ask respective maintainers for that.
Looking at the patch, it'd be nicer if split. I didn't notice that
ac/nir prefixed change touches gallivm. It'd also be preferrable if
LLVM reference used revision numbers instead of git hash (afaik llvm
still uses mainly svn).

Jan

> 
> It has r-b from Samuel Pitoiset and t-b from me.
> 
> Thanks,
> 
> Dieter
> 
> Am 30.03.2018 18:30, schrieb Jan Vesely:
> > LLVM r328839 moved few function declrations to a new Utils.h header.
> > Fixes:
> > gallivm/lp_bld_init.c:145:7: error: implicit declaration of function
> > ‘LLVMAddPromoteMemoryToRegisterPass’; did you mean
> > ‘LLVMAddDemoteMemoryToRegisterPass’?
> > 
> > Signed-off-by: Jan Vesely 
> > ---
> >  src/gallium/auxiliary/gallivm/lp_bld_init.c | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/src/gallium/auxiliary/gallivm/lp_bld_init.c
> > b/src/gallium/auxiliary/gallivm/lp_bld_init.c
> > index 6ddc509a81..dae9d01552 100644
> > --- a/src/gallium/auxiliary/gallivm/lp_bld_init.c
> > +++ b/src/gallium/auxiliary/gallivm/lp_bld_init.c
> > @@ -40,6 +40,9 @@
> > 
> >  #include 
> >  #include 
> > +#if HAVE_LLVM >= 0x0700
> > +#include 
> > +#endif
> >  #include 


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

[Mesa-dev] [PATCH 14/14] i965/blorp: Delete redundant code

2018-03-30 Thread Nanley Chery

---
 src/mesa/drivers/dri/i965/brw_blorp.c | 53 +++
 1 file changed, 10 insertions(+), 43 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_blorp.c 
b/src/mesa/drivers/dri/i965/brw_blorp.c
index 244067bfac6..2ec6f841502 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp.c
+++ b/src/mesa/drivers/dri/i965/brw_blorp.c
@@ -1187,65 +1187,33 @@ do_single_blorp_clear(struct brw_context *brw, struct 
gl_framebuffer *fb,
if (x0 == x1 || y0 == y1)
   return;
 
-   bool can_fast_clear = !partial_clear;
+   bool can_fast_clear = true;
 
bool color_write_disable[4] = { false, false, false, false };
if (set_write_disables(irb, GET_COLORMASK(ctx->Color.ColorMask, buf),
   color_write_disable))
   can_fast_clear = false;
 
-   /* We store clear colors as floats or uints as needed.  If there are
-* texture views in play, the formats will not properly be respected
-* during resolves because the resolve operations only know about the
-* miptree and not the renderbuffer.
-*/
-   if (irb->Base.Base.Format != irb->mt->format)
-  can_fast_clear = false;
-
-   if (!irb->mt->supports_fast_clear ||
-   !brw_is_color_fast_clear_compatible(brw, irb->mt, 
>Color.ClearColor))
-  can_fast_clear = false;
-
-   /* Surface state can only record one fast clear color value. Therefore
-* unless different levels/layers agree on the color it can be used to
-* represent only single level/layer. Here it will be reserved for the
-* first slice (level 0, layer 0).
-*/
-   if (irb->layer_count > 1 || irb->mt_level || irb->mt_layer)
-  can_fast_clear = false;
-
unsigned level = irb->mt_level;
const unsigned num_layers = fb->MaxNumLayers ? irb->layer_count : 1;
 
-   /* If the MCS buffer hasn't been allocated yet, we need to allocate it now.
-*/
-   if (can_fast_clear && !irb->mt->mcs_buf) {
-  assert(irb->mt->aux_usage == ISL_AUX_USAGE_CCS_D);
-  if (!intel_miptree_alloc_ccs(brw, irb->mt)) {
- /* There are a few reasons in addition to out-of-memory, that can
-  * cause intel_miptree_alloc_non_msrt_mcs to fail.  Try to recover by
-  * falling back to non-fast clear.
-  */
- can_fast_clear = false;
-  }
-   }
-
/* FINISHME: Debug and enable fast clears */
const struct gen_device_info *devinfo = >screen->devinfo;
if (devinfo->gen >= 11)
   can_fast_clear = false;
 
-   if (can_fast_clear) {
+   if (can_fast_clear &&
+   intel_miptree_set_clear_color(brw, irb->mt, irb->mt_level,
+ irb->mt_layer, num_layers, partial_clear,
+ irb->Base.Base.Format,
+ >Color.ClearColor)) {
+
+  /* We don't yet handle multiple slices. */
+  assert(num_layers == 1 && irb->mt_level == 0 && irb->mt_layer == 0 );
+
   const enum isl_aux_state aux_state =
  intel_miptree_get_aux_state(irb->mt, irb->mt_level, irb->mt_layer);
 
-  MAYBE_UNUSED const bool color_set =
- intel_miptree_set_clear_color(brw, irb->mt, irb->mt_level,
-   irb->mt_layer, num_layers, 
partial_clear,
-   irb->Base.Base.Format,
-   >Color.ClearColor);
-  assert(color_set);
-
   /* If the buffer is already in ISL_AUX_STATE_CLEAR, the clear
* is redundant and can be skipped.
*/
@@ -1255,7 +1223,6 @@ do_single_blorp_clear(struct brw_context *brw, struct 
gl_framebuffer *fb,
   DBG("%s (fast) to mt %p level %d layers %d+%d\n", __FUNCTION__,
   irb->mt, irb->mt_level, irb->mt_layer, num_layers);
 
-  /* We can't setup the blorp_surf until we've allocated the MCS above */
   struct isl_surf isl_tmp[2];
   struct blorp_surf surf;
   blorp_surf_for_miptree(brw, , irb->mt, irb->mt->aux_usage, true,
-- 
2.16.2

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

[Mesa-dev] [PATCH 08/14] i965: Add and use a getter for depth miptree clear values

2018-03-30 Thread Nanley Chery

Balance the miptree API by having a getter for depth clear values.
---
 src/mesa/drivers/dri/i965/brw_misc_state.c| 15 ---
 src/mesa/drivers/dri/i965/gen6_depth_state.c  |  4 ++--
 src/mesa/drivers/dri/i965/gen7_misc_state.c   |  3 +--
 src/mesa/drivers/dri/i965/gen8_depth_state.c  |  3 ++-
 src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 19 +++
 src/mesa/drivers/dri/i965/intel_mipmap_tree.h |  5 +
 6 files changed, 29 insertions(+), 20 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_misc_state.c 
b/src/mesa/drivers/dri/i965/brw_misc_state.c
index 05517ebf587..27608d1d472 100644
--- a/src/mesa/drivers/dri/i965/brw_misc_state.c
+++ b/src/mesa/drivers/dri/i965/brw_misc_state.c
@@ -343,21 +343,6 @@ brw_emit_depthbuffer(struct brw_context *brw)
 width, height, tile_x, tile_y);
 }
 
-uint32_t
-brw_convert_depth_value(mesa_format format, float value)
-{
-   switch (format) {
-   case MESA_FORMAT_Z_FLOAT32:
-  return float_as_int(value);
-   case MESA_FORMAT_Z_UNORM16:
-  return value * ((1u << 16) - 1);
-   case MESA_FORMAT_Z24_UNORM_X8_UINT:
-  return value * ((1u << 24) - 1);
-   default:
-  unreachable("Invalid depth format");
-   }
-}
-
 void
 brw_emit_depth_stencil_hiz(struct brw_context *brw,
struct intel_mipmap_tree *depth_mt,
diff --git a/src/mesa/drivers/dri/i965/gen6_depth_state.c 
b/src/mesa/drivers/dri/i965/gen6_depth_state.c
index 3a66b42fec1..3332a765dc1 100644
--- a/src/mesa/drivers/dri/i965/gen6_depth_state.c
+++ b/src/mesa/drivers/dri/i965/gen6_depth_state.c
@@ -212,8 +212,8 @@ gen6_emit_depth_stencil_hiz(struct brw_context *brw,
  GEN5_DEPTH_CLEAR_VALID |
  (2 - 2));
if (depth_mt) {
-  OUT_BATCH(brw_convert_depth_value(depth_mt->format,
-depth_mt->fast_clear_color.f32[0]));
+  const struct gen_device_info *devinfo = >screen->devinfo;
+  OUT_BATCH(intel_miptree_get_depth_clear_value(devinfo, depth_mt));
} else {
   OUT_BATCH(0);
}
diff --git a/src/mesa/drivers/dri/i965/gen7_misc_state.c 
b/src/mesa/drivers/dri/i965/gen7_misc_state.c
index 58f0a1bdbfd..7091ecf02a5 100644
--- a/src/mesa/drivers/dri/i965/gen7_misc_state.c
+++ b/src/mesa/drivers/dri/i965/gen7_misc_state.c
@@ -176,8 +176,7 @@ gen7_emit_depth_stencil_hiz(struct brw_context *brw,
BEGIN_BATCH(3);
OUT_BATCH(GEN7_3DSTATE_CLEAR_PARAMS << 16 | (3 - 2));
if (depth_mt) {
-  OUT_BATCH(brw_convert_depth_value(depth_mt->format,
-depth_mt->fast_clear_color.f32[0]));
+  OUT_BATCH(intel_miptree_get_depth_clear_value(devinfo, depth_mt));
} else {
   OUT_BATCH(0);
}
diff --git a/src/mesa/drivers/dri/i965/gen8_depth_state.c 
b/src/mesa/drivers/dri/i965/gen8_depth_state.c
index 27705d35df9..5679bced9ff 100644
--- a/src/mesa/drivers/dri/i965/gen8_depth_state.c
+++ b/src/mesa/drivers/dri/i965/gen8_depth_state.c
@@ -120,7 +120,8 @@ emit_depth_packets(struct brw_context *brw,
 
BEGIN_BATCH(3);
OUT_BATCH(GEN7_3DSTATE_CLEAR_PARAMS << 16 | (3 - 2));
-   OUT_BATCH(depth_mt ? depth_mt->fast_clear_color.u32[0] : 0);
+   OUT_BATCH(depth_mt ?
+ intel_miptree_get_depth_clear_value(devinfo, depth_mt) : 0);
OUT_BATCH(1);
ADVANCE_BATCH();
 
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c 
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
index 87c730452b5..dec2e614938 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
@@ -3825,3 +3825,22 @@ intel_miptree_get_clear_color(const struct 
gen_device_info *devinfo,
   return mt->fast_clear_color;
}
 }
+
+uint32_t
+intel_miptree_get_depth_clear_value(const struct gen_device_info *devinfo,
+const struct intel_mipmap_tree *mt)
+{
+   if (devinfo->gen >= 8)
+  return mt->fast_clear_color.u32[0];
+
+   switch (mt->format) {
+   case MESA_FORMAT_Z_FLOAT32:
+  return mt->fast_clear_color.u32[0];
+   case MESA_FORMAT_Z_UNORM16:
+  return mt->fast_clear_color.f32[0] * ((1u << 16) - 1);
+   case MESA_FORMAT_Z24_UNORM_X8_UINT:
+  return mt->fast_clear_color.f32[0] * ((1u << 24) - 1);
+   default:
+  unreachable("Invalid depth format");
+   }
+}
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.h 
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
index e66a2a8d384..edf9a619218 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
@@ -732,6 +732,11 @@ intel_miptree_set_depth_clear_value(struct brw_context 
*brw,
 struct intel_mipmap_tree *mt,
 float clear_value);
 
+/* Get a clear value suitable for filling out an ISL depth state. */
+uint32_t
+intel_miptree_get_depth_clear_value(const struct gen_device_info *devinfo,
+const

[Mesa-dev] [PATCH 12/14] i965/blorp: Also skip the fast clear if the clear color differs

2018-03-30 Thread Nanley Chery

If the aux state is CLEAR and clear color value has changed, only the
surface state must be updated. The bit-pattern in the aux buffer is
exactly the same.
---
 src/mesa/drivers/dri/i965/brw_blorp.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_blorp.c 
b/src/mesa/drivers/dri/i965/brw_blorp.c
index c6fa5195ee3..bf7164688bb 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp.c
+++ b/src/mesa/drivers/dri/i965/brw_blorp.c
@@ -1239,13 +1239,12 @@ do_single_blorp_clear(struct brw_context *brw, struct 
gl_framebuffer *fb,
   const enum isl_aux_state aux_state =
  intel_miptree_get_aux_state(irb->mt, irb->mt_level, irb->mt_layer);
 
-  bool same_clear_color =
- !intel_miptree_set_clear_color(brw, irb->mt, >Color.ClearColor);
+  intel_miptree_set_clear_color(brw, irb->mt, >Color.ClearColor);
 
-  /* If the buffer is already in INTEL_FAST_CLEAR_STATE_CLEAR, the clear
+  /* If the buffer is already in ISL_AUX_STATE_CLEAR, the clear
* is redundant and can be skipped.
*/
-  if (aux_state == ISL_AUX_STATE_CLEAR && same_clear_color)
+  if (aux_state == ISL_AUX_STATE_CLEAR)
  return;
 
   DBG("%s (fast) to mt %p level %d layers %d+%d\n", __FUNCTION__,
-- 
2.16.2

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

[Mesa-dev] [PATCH 07/14] i965/meta_util: Re-enable sRGB-encoded fast-clears on CNL

2018-03-30 Thread Nanley Chery

The paths which sample with the clear color are now using a getter which
performs the sRGB decode needed to enable this fast clear.

This path can be exercised by fast-clearing a texture, then performing
an operation which requires sRGB decoding. Test coverage for this
feature is provided with the following tests:

* Shader texture calls:
  - spec@ext_texture_srgb@tex-srgb

* Shader texelfetch calls:
  - spec@arb_framebuffer_srgb@fbo-fast-clear
  - spec@arb_framebuffer_srgb@msaa-fast-clear

* Blending:
  - spec@arb_framebuffer_srgb@arb_framebuffer_srgb-fast-clear-blend

* Blitting:
  - spec@arb_framebuffer_srgb@blit texture srgb msaa enabled clear
---
 src/mesa/drivers/dri/i965/brw_meta_util.c | 11 ---
 1 file changed, 11 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_meta_util.c 
b/src/mesa/drivers/dri/i965/brw_meta_util.c
index b31181521c7..d292f5a8e24 100644
--- a/src/mesa/drivers/dri/i965/brw_meta_util.c
+++ b/src/mesa/drivers/dri/i965/brw_meta_util.c
@@ -293,18 +293,7 @@ brw_is_color_fast_clear_compatible(struct brw_context *brw,
brw->mesa_to_isl_render_format[mt->format])
   return false;
 
-   const bool srgb_rb = _mesa_get_srgb_format_linear(mt->format) != mt->format;
-  /* Gen10 doesn't automatically decode the clear color of sRGB buffers. Since
-   * we currently don't perform this decode in software, avoid a fast-clear
-   * altogether. TODO: Do this in software.
-   */
const mesa_format format = _mesa_get_render_format(ctx, mt->format);
-   if (devinfo->gen >= 10 && srgb_rb) {
-  perf_debug("sRGB fast clear not enabled for (%s)",
- _mesa_get_format_name(format));
-  return false;
-   }
-
if (_mesa_is_format_integer_color(format)) {
   if (devinfo->gen >= 8) {
  perf_debug("Integer fast clear not enabled for (%s)",
-- 
2.16.2

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

[Mesa-dev] [PATCH 04/14] util/srgb: Add a float sRGB -> linear helper

2018-03-30 Thread Nanley Chery

From: Jason Ekstrand 

Reviewed-by: Nanley Chery 
---
 src/util/format_srgb.h | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/src/util/format_srgb.h b/src/util/format_srgb.h
index 34b50afe3d1..596af56f4cd 100644
--- a/src/util/format_srgb.h
+++ b/src/util/format_srgb.h
@@ -54,6 +54,20 @@ extern const unsigned
 util_format_linear_to_srgb_helper_table[104];
 
 
+static inline float
+util_format_srgb_to_linear_float(float cs)
+{
+   if (cs <= 0.0f)
+  return 0.0f;
+   else if (cs <= 0.04045f)
+  return cs / 12.92f;
+   else if (cs < 1.0f)
+  return powf((cs + 0.055) / 1.055f, 2.4f);
+   else
+  return 1.0f;
+}
+
+
 static inline float
 util_format_linear_to_srgb_float(float cl)
 {
-- 
2.16.2

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

[Mesa-dev] [Bug 105775] SI reaches the maximum IB size in dwords and fail to submit

2018-03-30 Thread bugzilla-daemon

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

--- Comment #22 from Amarildo  ---
Thanks, Samuel. Looking forward to the fix.

If there's anything I can do to speed testing, let me know.

-- 
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 10/14] i965/brw_clear: Don't resolve to change the depth clear value

2018-03-30 Thread Nanley Chery

Choose to compress the new depth value, instead of doing both a resolve
and fast-clear. This should reduce bandwidth consumption.
---
 src/mesa/drivers/dri/i965/brw_clear.c | 22 ++
 1 file changed, 10 insertions(+), 12 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_clear.c 
b/src/mesa/drivers/dri/i965/brw_clear.c
index 3b5f6122439..fedd31a4317 100644
--- a/src/mesa/drivers/dri/i965/brw_clear.c
+++ b/src/mesa/drivers/dri/i965/brw_clear.c
@@ -172,8 +172,8 @@ brw_fast_clear_depth(struct gl_context *ctx)
 
const uint32_t num_layers = depth_att->Layered ? depth_irb->layer_count : 1;
 
-   /* If we're clearing to a new clear value, then we need to resolve any clear
-* flags out of the HiZ buffer into the real depth buffer.
+   /* If we're clearing to a new clear value, then we need to ensure that the
+* old clear blocks will be overwritten.
 */
if (mt->fast_clear_color.f32[0] != clear_value) {
   for (uint32_t level = mt->first_level; level <= mt->last_level; level++) 
{
@@ -186,7 +186,7 @@ brw_fast_clear_depth(struct gl_context *ctx)
 if (level == depth_irb->mt_level &&
 layer >= depth_irb->mt_layer &&
 layer < depth_irb->mt_layer + num_layers) {
-   /* We're going to clear this layer anyway.  Leave it alone. */
+   /* We're going to clear this layer anyway. */
continue;
 }
 
@@ -199,16 +199,14 @@ brw_fast_clear_depth(struct gl_context *ctx)
continue;
 }
 
-/* If we got here, then the level may have fast-clear bits that
- * use the old clear value.  We need to do a depth resolve to get
- * rid of their use of the clear value before we can change it.
- * Fortunately, few applications ever change their depth clear
- * value so this shouldn't happen often.
+/* If we got here, then the level may have fast-clear bits that use
+ * the old clear value. Since a slow cleared block is the same size
+ * a fast-cleared block, the bandwidth savings likely aren't enough
+ * to justify a full resolve. Fall back to slow clear. Fortunately,
+ * few applications ever change their depth clear value so this
+ * shouldn't happen often.
  */
-intel_hiz_exec(brw, mt, level, layer, 1,
-   ISL_AUX_OP_FULL_RESOLVE);
-intel_miptree_set_aux_state(brw, mt, level, layer, 1,
-ISL_AUX_STATE_RESOLVED);
+return false;
  }
   }
 
-- 
2.16.2

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

[Mesa-dev] [PATCH 01/14] i965: Use the brw_context for the clear color and value setters

2018-03-30 Thread Nanley Chery

Do what all the other functions in the miptree API do.
---
 src/mesa/drivers/dri/i965/brw_blorp.c | 2 +-
 src/mesa/drivers/dri/i965/brw_clear.c | 2 +-
 src/mesa/drivers/dri/i965/intel_mipmap_tree.h | 8 
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_blorp.c 
b/src/mesa/drivers/dri/i965/brw_blorp.c
index 44064fc0cf3..f5a653fff97 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp.c
+++ b/src/mesa/drivers/dri/i965/brw_blorp.c
@@ -1241,7 +1241,7 @@ do_single_blorp_clear(struct brw_context *brw, struct 
gl_framebuffer *fb,
>Color.ClearColor);
 
   bool same_clear_color =
- !intel_miptree_set_clear_color(ctx, irb->mt, clear_color);
+ !intel_miptree_set_clear_color(brw, irb->mt, clear_color);
 
   /* If the buffer is already in INTEL_FAST_CLEAR_STATE_CLEAR, the clear
* is redundant and can be skipped.
diff --git a/src/mesa/drivers/dri/i965/brw_clear.c 
b/src/mesa/drivers/dri/i965/brw_clear.c
index 8aa83722ee9..8f7594baf59 100644
--- a/src/mesa/drivers/dri/i965/brw_clear.c
+++ b/src/mesa/drivers/dri/i965/brw_clear.c
@@ -212,7 +212,7 @@ brw_fast_clear_depth(struct gl_context *ctx)
  }
   }
 
-  intel_miptree_set_depth_clear_value(ctx, mt, clear_value);
+  intel_miptree_set_depth_clear_value(brw, mt, clear_value);
}
 
bool need_clear = false;
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.h 
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
index 07c85807e80..0c24b93e3da 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
@@ -717,26 +717,26 @@ intel_miptree_sample_with_hiz(struct brw_context *brw,
 
 
 static inline bool
-intel_miptree_set_clear_color(struct gl_context *ctx,
+intel_miptree_set_clear_color(struct brw_context *brw,
   struct intel_mipmap_tree *mt,
   union isl_color_value clear_color)
 {
if (memcmp(>fast_clear_color, _color, sizeof(clear_color)) != 0) {
   mt->fast_clear_color = clear_color;
-  ctx->NewDriverState |= BRW_NEW_AUX_STATE;
+  brw->ctx.NewDriverState |= BRW_NEW_AUX_STATE;
   return true;
}
return false;
 }
 
 static inline bool
-intel_miptree_set_depth_clear_value(struct gl_context *ctx,
+intel_miptree_set_depth_clear_value(struct brw_context *brw,
 struct intel_mipmap_tree *mt,
 float clear_value)
 {
if (mt->fast_clear_color.f32[0] != clear_value) {
   mt->fast_clear_color.f32[0] = clear_value;
-  ctx->NewDriverState |= BRW_NEW_AUX_STATE;
+  brw->ctx.NewDriverState |= BRW_NEW_AUX_STATE;
   return true;
}
return false;
-- 
2.16.2

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

[Mesa-dev] [PATCH 06/14] i965/miptree: Extend the sRGB-blending WA to future platforms

2018-03-30 Thread Nanley Chery

The blending issue seems to be present on CNL as well.
---
 src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c 
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
index c21c4d8bae1..87c730452b5 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
@@ -2704,11 +2704,11 @@ intel_miptree_render_aux_usage(struct brw_context *brw,
  return ISL_AUX_USAGE_NONE;
   }
 
-  /* gen9 hardware technically supports non-0/1 clear colors with sRGB
+  /* gen9+ hardware technically supports non-0/1 clear colors with sRGB
* formats.  However, there are issues with blending where it doesn't
* properly apply the sRGB curve to the clear color when blending.
*/
-  if (devinfo->gen == 9 && blend_enabled &&
+  if (devinfo->gen >= 9 && blend_enabled &&
   isl_format_is_srgb(render_format) &&
   !isl_color_value_is_zero_one(mt->fast_clear_color, render_format))
  return ISL_AUX_USAGE_NONE;
-- 
2.16.2

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

[Mesa-dev] [PATCH 11/14] i965/brw_clear: Delete redundant code

2018-03-30 Thread Nanley Chery

Remove the last external user of intel_miptree::fast_color_clear in
favor of the setter function.
---
 src/mesa/drivers/dri/i965/brw_clear.c | 47 +++
 1 file changed, 4 insertions(+), 43 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_clear.c 
b/src/mesa/drivers/dri/i965/brw_clear.c
index fedd31a4317..bfcc943255b 100644
--- a/src/mesa/drivers/dri/i965/brw_clear.c
+++ b/src/mesa/drivers/dri/i965/brw_clear.c
@@ -172,49 +172,10 @@ brw_fast_clear_depth(struct gl_context *ctx)
 
const uint32_t num_layers = depth_att->Layered ? depth_irb->layer_count : 1;
 
-   /* If we're clearing to a new clear value, then we need to ensure that the
-* old clear blocks will be overwritten.
-*/
-   if (mt->fast_clear_color.f32[0] != clear_value) {
-  for (uint32_t level = mt->first_level; level <= mt->last_level; level++) 
{
- if (!intel_miptree_level_has_hiz(mt, level))
-continue;
-
- const unsigned level_layers = brw_get_num_logical_layers(mt, level);
-
- for (uint32_t layer = 0; layer < level_layers; layer++) {
-if (level == depth_irb->mt_level &&
-layer >= depth_irb->mt_layer &&
-layer < depth_irb->mt_layer + num_layers) {
-   /* We're going to clear this layer anyway. */
-   continue;
-}
-
-enum isl_aux_state aux_state =
-   intel_miptree_get_aux_state(mt, level, layer);
-
-if (aux_state != ISL_AUX_STATE_CLEAR &&
-aux_state != ISL_AUX_STATE_COMPRESSED_CLEAR) {
-   /* This slice doesn't have any fast-cleared bits. */
-   continue;
-}
-
-/* If we got here, then the level may have fast-clear bits that use
- * the old clear value. Since a slow cleared block is the same size
- * a fast-cleared block, the bandwidth savings likely aren't enough
- * to justify a full resolve. Fall back to slow clear. Fortunately,
- * few applications ever change their depth clear value so this
- * shouldn't happen often.
- */
-return false;
- }
-  }
-
-  MAYBE_UNUSED bool new_clear =
- intel_miptree_set_depth_clear_value(brw, mt, depth_irb->mt_level,
- depth_irb->mt_layer, num_layers,
- false, clear_value);
-  assert(new_clear);
+   if (!intel_miptree_set_depth_clear_value(brw, mt, depth_irb->mt_level,
+depth_irb->mt_layer, num_layers,
+false, clear_value)) {
+  return false;
}
 
bool need_clear = false;
-- 
2.16.2

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

[Mesa-dev] [PATCH 09/14] i965: Allow failure when setting the depth clear value

2018-03-30 Thread Nanley Chery

We'd like for the caller to use the miptree clear color helper
functions. Unfortunately, to fast-clear depth with good performance, you
have to know if the current clear color differs from the pending one.
Adjust the setter to reject a clear color if doing so would hurt
performance by introducing resolves.

Only update the function here to help bisection and review.
---
 src/mesa/drivers/dri/i965/brw_clear.c |  6 +++-
 src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 47 ---
 src/mesa/drivers/dri/i965/intel_mipmap_tree.h |  8 -
 3 files changed, 55 insertions(+), 6 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_clear.c 
b/src/mesa/drivers/dri/i965/brw_clear.c
index 8f7594baf59..3b5f6122439 100644
--- a/src/mesa/drivers/dri/i965/brw_clear.c
+++ b/src/mesa/drivers/dri/i965/brw_clear.c
@@ -212,7 +212,11 @@ brw_fast_clear_depth(struct gl_context *ctx)
  }
   }
 
-  intel_miptree_set_depth_clear_value(brw, mt, clear_value);
+  MAYBE_UNUSED bool new_clear =
+ intel_miptree_set_depth_clear_value(brw, mt, depth_irb->mt_level,
+ depth_irb->mt_layer, num_layers,
+ false, clear_value);
+  assert(new_clear);
}
 
bool need_clear = false;
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c 
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
index dec2e614938..bbf09153be7 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
@@ -3794,14 +3794,53 @@ intel_miptree_set_clear_color(struct brw_context *brw,
 bool
 intel_miptree_set_depth_clear_value(struct brw_context *brw,
 struct intel_mipmap_tree *mt,
-float clear_value)
-{
+uint32_t level,
+uint32_t start_layer, uint32_t num_layers,
+bool partial_clear, float clear_value)
+{
+   /* To avoid resolves when fast-clearing, we allow a miptree range to be set
+* with a clear value if the following statements hold true:
+*1. The clear value is valid.
+*2. If the clear value is different from the current value, then:
+*   a) the full RT of each slice in the desired range will be cleared.
+*   b) the desired range includes pre-existing clear blocks.
+*/
if (mt->fast_clear_color.f32[0] != clear_value) {
+  if (partial_clear)
+ return false;
+
+  /* The desired range is problematic if it isn't a superset of the range
+   * of the miptree which already contains clear blocks. Try to find a
+   * slice outside the desired range which contains clear blocks, and won't
+   * be cleared at this time.
+   */
+  for (unsigned mlev = mt->first_level; mlev <= mt->last_level; mlev++) {
+ if (!intel_miptree_level_has_hiz(mt, mlev))
+continue;
+
+ const unsigned level_layers = brw_get_num_logical_layers(mt, mlev);
+
+ for (unsigned layer = 0; layer < level_layers; layer++) {
+const enum isl_aux_state aux_state =
+   intel_miptree_get_aux_state(mt, mlev, layer);
+const bool contains_cleared_blocks =
+   aux_state == ISL_AUX_STATE_CLEAR ||
+   aux_state == ISL_AUX_STATE_COMPRESSED_CLEAR;
+const bool wont_be_cleared =
+   mlev != level ||
+   layer < start_layer ||
+   layer >= start_layer + num_layers;
+
+if (contains_cleared_blocks && wont_be_cleared)
+   return false;
+ }
+  }
+
   mt->fast_clear_color.f32[0] = clear_value;
   brw->ctx.NewDriverState |= BRW_NEW_AUX_STATE;
-  return true;
}
-   return false;
+
+   return true;
 }
 
 union isl_color_value
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.h 
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
index edf9a619218..4915198ce1c 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
@@ -727,10 +727,16 @@ intel_miptree_get_clear_color(const struct 
gen_device_info *devinfo,
   enum isl_format view_format,
   bool sampling);
 
+/* Try to mark a range of slices in the miptree as having a given clear value.
+ * Upon success, the caller must ensure that the range's aux bits will
+ * represent the clear value. This may involve performing a fast-clear.
+ */
 bool
 intel_miptree_set_depth_clear_value(struct brw_context *brw,
 struct intel_mipmap_tree *mt,
-float clear_value);
+uint32_t level,
+uint32_t start_layer, uint32_t num_layers,
+bool partial_clear, float clear_value);

[Mesa-dev] [PATCH 03/14] i965: Make the miptree clear color setter take a gl_color_union

2018-03-30 Thread Nanley Chery

We want to hide the internal details of how the miptree's clear color
is calculated.
---
 src/mesa/drivers/dri/i965/brw_blorp.c | 5 +
 src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 6 +-
 src/mesa/drivers/dri/i965/intel_mipmap_tree.h | 2 +-
 3 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_blorp.c 
b/src/mesa/drivers/dri/i965/brw_blorp.c
index f5a653fff97..6ab5267ddea 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp.c
+++ b/src/mesa/drivers/dri/i965/brw_blorp.c
@@ -1236,12 +1236,9 @@ do_single_blorp_clear(struct brw_context *brw, struct 
gl_framebuffer *fb,
if (can_fast_clear) {
   const enum isl_aux_state aux_state =
  intel_miptree_get_aux_state(irb->mt, irb->mt_level, irb->mt_layer);
-  union isl_color_value clear_color =
- brw_meta_convert_fast_clear_color(brw, irb->mt,
-   >Color.ClearColor);
 
   bool same_clear_color =
- !intel_miptree_set_clear_color(brw, irb->mt, clear_color);
+ !intel_miptree_set_clear_color(brw, irb->mt, >Color.ClearColor);
 
   /* If the buffer is already in INTEL_FAST_CLEAR_STATE_CLEAR, the clear
* is redundant and can be skipped.
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c 
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
index 163accf023b..7aa0e7920d3 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
@@ -36,6 +36,7 @@
 
 #include "brw_blorp.h"
 #include "brw_context.h"
+#include "brw_meta_util.h"
 #include "brw_state.h"
 
 #include "main/enums.h"
@@ -3774,8 +3775,11 @@ intel_miptree_get_aux_isl_usage(const struct brw_context 
*brw,
 bool
 intel_miptree_set_clear_color(struct brw_context *brw,
   struct intel_mipmap_tree *mt,
-  union isl_color_value clear_color)
+  const union gl_color_union *color)
 {
+   const union isl_color_value clear_color =
+  brw_meta_convert_fast_clear_color(brw, mt, color);
+
if (memcmp(>fast_clear_color, _color, sizeof(clear_color)) != 0) {
   mt->fast_clear_color = clear_color;
   brw->ctx.NewDriverState |= BRW_NEW_AUX_STATE;
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.h 
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
index 600296904ba..961f8fe812e 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
@@ -718,7 +718,7 @@ intel_miptree_sample_with_hiz(struct brw_context *brw,
 bool
 intel_miptree_set_clear_color(struct brw_context *brw,
   struct intel_mipmap_tree *mt,
-  union isl_color_value clear_color);
+  const union gl_color_union *color);
 
 bool
 intel_miptree_set_depth_clear_value(struct brw_context *brw,
-- 
2.16.2

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

[Mesa-dev] [PATCH 02/14] i965/miptree: Move the clear color and value setter implementations

2018-03-30 Thread Nanley Chery

These will get more complex in later commits.
---
 src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 26 ++
 src/mesa/drivers/dri/i965/intel_mipmap_tree.h | 25 -
 2 files changed, 30 insertions(+), 21 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c 
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
index 23cb40f3226..163accf023b 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
@@ -3770,3 +3770,29 @@ intel_miptree_get_aux_isl_usage(const struct brw_context 
*brw,
 
return mt->aux_usage;
 }
+
+bool
+intel_miptree_set_clear_color(struct brw_context *brw,
+  struct intel_mipmap_tree *mt,
+  union isl_color_value clear_color)
+{
+   if (memcmp(>fast_clear_color, _color, sizeof(clear_color)) != 0) {
+  mt->fast_clear_color = clear_color;
+  brw->ctx.NewDriverState |= BRW_NEW_AUX_STATE;
+  return true;
+   }
+   return false;
+}
+
+bool
+intel_miptree_set_depth_clear_value(struct brw_context *brw,
+struct intel_mipmap_tree *mt,
+float clear_value)
+{
+   if (mt->fast_clear_color.f32[0] != clear_value) {
+  mt->fast_clear_color.f32[0] = clear_value;
+  brw->ctx.NewDriverState |= BRW_NEW_AUX_STATE;
+  return true;
+   }
+   return false;
+}
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.h 
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
index 0c24b93e3da..600296904ba 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
@@ -715,32 +715,15 @@ bool
 intel_miptree_sample_with_hiz(struct brw_context *brw,
   struct intel_mipmap_tree *mt);
 
-
-static inline bool
+bool
 intel_miptree_set_clear_color(struct brw_context *brw,
   struct intel_mipmap_tree *mt,
-  union isl_color_value clear_color)
-{
-   if (memcmp(>fast_clear_color, _color, sizeof(clear_color)) != 0) {
-  mt->fast_clear_color = clear_color;
-  brw->ctx.NewDriverState |= BRW_NEW_AUX_STATE;
-  return true;
-   }
-   return false;
-}
+  union isl_color_value clear_color);
 
-static inline bool
+bool
 intel_miptree_set_depth_clear_value(struct brw_context *brw,
 struct intel_mipmap_tree *mt,
-float clear_value)
-{
-   if (mt->fast_clear_color.f32[0] != clear_value) {
-  mt->fast_clear_color.f32[0] = clear_value;
-  brw->ctx.NewDriverState |= BRW_NEW_AUX_STATE;
-  return true;
-   }
-   return false;
-}
+float clear_value);
 
 #ifdef __cplusplus
 }
-- 
2.16.2

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

[Mesa-dev] [PATCH 05/14] i965/miptree: Add and use a getter for the clear color

2018-03-30 Thread Nanley Chery

Use a getter which allows CNL to sample from sRGB textures correctly.
---
 src/mesa/drivers/dri/i965/brw_blorp.c|  4 +++-
 src/mesa/drivers/dri/i965/brw_wm_surface_state.c |  4 +++-
 src/mesa/drivers/dri/i965/intel_mipmap_tree.c| 25 
 src/mesa/drivers/dri/i965/intel_mipmap_tree.h|  7 +++
 4 files changed, 38 insertions(+), 2 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_blorp.c 
b/src/mesa/drivers/dri/i965/brw_blorp.c
index 6ab5267ddea..c6fa5195ee3 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp.c
+++ b/src/mesa/drivers/dri/i965/brw_blorp.c
@@ -172,7 +172,9 @@ blorp_surf_for_miptree(struct brw_context *brw,
   /* We only really need a clear color if we also have an auxiliary
* surface.  Without one, it does nothing.
*/
-  surf->clear_color = mt->fast_clear_color;
+  surf->clear_color =
+ intel_miptree_get_clear_color(devinfo, mt, mt->surf.format,
+   !is_render_target);
 
   surf->aux_surf = aux_surf;
   surf->aux_addr = (struct blorp_address) {
diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c 
b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
index caa92d7d878..2c9e986b184 100644
--- a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
+++ b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
@@ -178,7 +178,9 @@ brw_emit_surface_state(struct brw_context *brw,
   /* We only really need a clear color if we also have an auxiliary
* surface.  Without one, it does nothing.
*/
-  clear_color = mt->fast_clear_color;
+  clear_color =
+ intel_miptree_get_clear_color(devinfo, mt, view.format,
+   view.usage & 
ISL_SURF_USAGE_TEXTURE_BIT);
}
 
void *state = brw_state_batch(brw,
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c 
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
index 7aa0e7920d3..c21c4d8bae1 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
@@ -46,6 +46,9 @@
 #include "main/texcompress_etc.h"
 #include "main/teximage.h"
 #include "main/streaming-load-memcpy.h"
+
+#include "util/format_srgb.h"
+
 #include "x86/common_x86_asm.h"
 
 #define FILE_DEBUG_FLAG DEBUG_MIPTREE
@@ -3800,3 +3803,25 @@ intel_miptree_set_depth_clear_value(struct brw_context 
*brw,
}
return false;
 }
+
+union isl_color_value
+intel_miptree_get_clear_color(const struct gen_device_info *devinfo,
+  const struct intel_mipmap_tree *mt,
+  enum isl_format view_format,
+  bool sampling)
+{
+   /* Prior to gen10, the clear color can be used unchanged. From gen10
+* onwards, HW no longer gamma-corrects the clear color for sampling
+* operations.
+*/
+   if (devinfo->gen >= 10 && isl_format_is_srgb(view_format) && sampling) {
+  union isl_color_value linear_color = mt->fast_clear_color;
+  for (unsigned i = 0; i < 3; i++) {
+ linear_color.f32[i] =
+util_format_srgb_to_linear_float(mt->fast_clear_color.f32[i]);
+  }
+  return linear_color;
+   } else {
+  return mt->fast_clear_color;
+   }
+}
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.h 
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
index 961f8fe812e..e66a2a8d384 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
@@ -720,6 +720,13 @@ intel_miptree_set_clear_color(struct brw_context *brw,
   struct intel_mipmap_tree *mt,
   const union gl_color_union *color);
 
+/* Get a clear color suitable for filling out an ISL surface state. */
+union isl_color_value
+intel_miptree_get_clear_color(const struct gen_device_info *devinfo,
+  const struct intel_mipmap_tree *mt,
+  enum isl_format view_format,
+  bool sampling);
+
 bool
 intel_miptree_set_depth_clear_value(struct brw_context *brw,
 struct intel_mipmap_tree *mt,
-- 
2.16.2

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

[Mesa-dev] [PATCH 00/14] Enable sRGB-encoded fast-clears on CannonLake

2018-03-30 Thread Nanley Chery

Starting with CannonLake, the sampler no longer decodes the surface
state clear color when using an sRGB-formatted texture. This change
requires that our driver perform this decode in software instead. We
accounted for this change initially by disabling fast-clears when sRGB
encode was enabled. This series implements the software decode and
re-enables sRGB-encoded fast-clears.

The software decode is performed through a new getter for the miptree
clear color. To keep the miptree API balanced and to discourage its
users from accessing the clear color field directly, we add a getter for
the depth clear value and change the existing setters so that the user
no longer needs to know the current clear color to perform an efficient
clear operation.

Two piglit tests have been modified to test that the linearization of
the clear color occurs (when appropriate) for shader texture() calls and
on framebuffer blit sources. The modification patches can be found here:
https://lists.freedesktop.org/archives/piglit/2018-March/023996.html

Jason Ekstrand (1):
  util/srgb: Add a float sRGB -> linear helper

Nanley Chery (13):
  i965: Use the brw_context for the clear color and value setters
  i965/miptree: Move the clear color and value setter implementations
  i965: Make the miptree clear color setter take a gl_color_union
  i965/miptree: Add and use a getter for the clear color
  i965/miptree: Extend the sRGB-blending WA to future platforms
  i965/meta_util: Re-enable sRGB-encoded fast-clears on CNL
  i965: Add and use a getter for depth miptree clear values
  i965: Allow failure when setting the depth clear value
  i965/brw_clear: Don't resolve to change the depth clear value
  i965/brw_clear: Delete redundant code
  i965/blorp: Also skip the fast clear if the clear color differs
  i965/miptree: Allow failure when setting the clear color
  i965/blorp: Delete redundant code

 src/mesa/drivers/dri/i965/brw_blorp.c|  60 +++--
 src/mesa/drivers/dri/i965/brw_clear.c|  45 +--
 src/mesa/drivers/dri/i965/brw_meta_util.c|  11 --
 src/mesa/drivers/dri/i965/brw_misc_state.c   |  15 ---
 src/mesa/drivers/dri/i965/brw_wm_surface_state.c |   4 +-
 src/mesa/drivers/dri/i965/gen6_depth_state.c |   4 +-
 src/mesa/drivers/dri/i965/gen7_misc_state.c  |   3 +-
 src/mesa/drivers/dri/i965/gen8_depth_state.c |   3 +-
 src/mesa/drivers/dri/i965/intel_mipmap_tree.c| 165 ++-
 src/mesa/drivers/dri/i965/intel_mipmap_tree.h|  53 
 src/util/format_srgb.h   |  14 ++
 11 files changed, 233 insertions(+), 144 deletions(-)

-- 
2.16.2

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

[Mesa-dev] [PATCH 13/14] i965/miptree: Allow failure when setting the clear color

2018-03-30 Thread Nanley Chery

To balance of the miptree clear color API, make this function behave
like the depth clear value setter.
---
 src/mesa/drivers/dri/i965/brw_blorp.c |  7 +++-
 src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 54 +--
 src/mesa/drivers/dri/i965/intel_mipmap_tree.h |  6 ++-
 3 files changed, 62 insertions(+), 5 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_blorp.c 
b/src/mesa/drivers/dri/i965/brw_blorp.c
index bf7164688bb..244067bfac6 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp.c
+++ b/src/mesa/drivers/dri/i965/brw_blorp.c
@@ -1239,7 +1239,12 @@ do_single_blorp_clear(struct brw_context *brw, struct 
gl_framebuffer *fb,
   const enum isl_aux_state aux_state =
  intel_miptree_get_aux_state(irb->mt, irb->mt_level, irb->mt_layer);
 
-  intel_miptree_set_clear_color(brw, irb->mt, >Color.ClearColor);
+  MAYBE_UNUSED const bool color_set =
+ intel_miptree_set_clear_color(brw, irb->mt, irb->mt_level,
+   irb->mt_layer, num_layers, 
partial_clear,
+   irb->Base.Base.Format,
+   >Color.ClearColor);
+  assert(color_set);
 
   /* If the buffer is already in ISL_AUX_STATE_CLEAR, the clear
* is redundant and can be skipped.
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c 
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
index bbf09153be7..3a764ef64ab 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
@@ -3777,18 +3777,66 @@ intel_miptree_get_aux_isl_usage(const struct 
brw_context *brw,
 
 bool
 intel_miptree_set_clear_color(struct brw_context *brw,
-  struct intel_mipmap_tree *mt,
+  struct intel_mipmap_tree *mt, uint32_t level,
+  uint32_t start_layer, uint32_t num_layers,
+  bool partial_clear, mesa_format view_format,
   const union gl_color_union *color)
 {
+   if (!mt->supports_fast_clear)
+  return false;
+
+   if (!brw_is_color_fast_clear_compatible(brw, mt, color))
+  return false;
+
+   /* From the Kaby Lake PRM, Vol. 7, Section
+* "Color Clear of Non-MultiSampler Render Target Restrictions":
+*
+* Clear is supported only on the full RT; i.e., no partial clear or
+* overlapping clears.
+*
+* This restriction exists all the way back to Ivy Bridge.
+*/
+   if (partial_clear)
+  return false;
+
+   /* Surface state can only record one fast clear color value. Therefore
+* unless different levels/layers agree on the color it can be used to
+* represent only single level/layer. Here it will be reserved for the
+* first slice (level 0, layer 0).
+*/
+   if (num_layers > 1 || level || start_layer) {
+  perf_debug("Multi-slice fast-clear disabled on color miptree.\n");
+  return false;
+   }
+
+   /* We store clear colors as floats or uints as needed.  If there are
+* texture views in play, the formats will not properly be respected
+* during resolves because the resolve operations only know about the
+* miptree and not the renderbuffer.
+*/
+   if (view_format != mt->format) {
+  perf_debug("Texture view fast-clear disabled.\n");
+  return false;
+   }
+
+   /* In order to mark the range as having the given clear color, we need to
+* have an aux buffer. If one hasn't been allocated yet, do it now.
+*/
+   if (!mt->mcs_buf) {
+  assert(mt->aux_usage == ISL_AUX_USAGE_CCS_D);
+  if (!intel_miptree_alloc_ccs(brw, mt))
+ return false;
+   }
+
const union isl_color_value clear_color =
   brw_meta_convert_fast_clear_color(brw, mt, color);
 
if (memcmp(>fast_clear_color, _color, sizeof(clear_color)) != 0) {
   mt->fast_clear_color = clear_color;
   brw->ctx.NewDriverState |= BRW_NEW_AUX_STATE;
-  return true;
}
-   return false;
+
+   return true;
 }
 
 bool
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.h 
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
index 4915198ce1c..14f57294c06 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
@@ -715,9 +715,13 @@ bool
 intel_miptree_sample_with_hiz(struct brw_context *brw,
   struct intel_mipmap_tree *mt);
 
+/* Do what intel_miptree_set_depth_clear_value() does, but for color buffers.
+ */
 bool
 intel_miptree_set_clear_color(struct brw_context *brw,
-  struct intel_mipmap_tree *mt,
+  struct intel_mipmap_tree *mt, uint32_t level,
+  uint32_t start_layer, uint32_t num_layers,
+  bool partial_clear, mesa_format view_format,
   const union gl_color_union *color);
 
 /* Get a clear color suitable for filling

[Mesa-dev] [Bug 105817] scons build broken by glSpecializeShaderARB

2018-03-30 Thread bugzilla-daemon

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

--- Comment #2 from Alejandro Piñeiro (freenode IRC: apinheiro) 
 ---
Brian Paul has just sent a series, with Neil's patch, plus some extra to get it
working on MSVC:
https://lists.freedesktop.org/archives/mesa-dev/2018-March/190597.html

-- 
You are receiving this mail because:
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] spirv: Fix building with SCons

2018-03-30 Thread Brian Paul

OK, I just posted a series of patches which seems to fix everything on 
Windows/MSVC.


Neil, I added fixes for the osmesa and libgl-gdi targets to your patch.

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

[Mesa-dev] [PATCH 4/6] nir/spirv: fix MSVC syntax error in vtn_handle_texture()

2018-03-30 Thread Brian Paul

---
 src/compiler/spirv/spirv_to_nir.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/compiler/spirv/spirv_to_nir.c 
b/src/compiler/spirv/spirv_to_nir.c
index 2550ef0..72ab426 100644
--- a/src/compiler/spirv/spirv_to_nir.c
+++ b/src/compiler/spirv/spirv_to_nir.c
@@ -2086,8 +2086,9 @@ vtn_handle_texture(struct vtn_builder *b, SpvOp opcode,
  (*p++) = vtn_tex_src(b, w[idx++], nir_tex_src_offset);
 
   if (operands & SpvImageOperandsConstOffsetsMask) {
+ nir_tex_src none = {0};
  gather_offsets = vtn_ssa_value(b, w[idx++]);
- (*p++) = (nir_tex_src){};
+ (*p++) = none;
   }
 
   if (operands & SpvImageOperandsSampleMask) {
-- 
2.7.4

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

[Mesa-dev] [PATCH 5/6] nir/spirv: s/uint32_t/SpvOp/ in various functions

2018-03-30 Thread Brian Paul

The MSVC compiler warns when the function parameter types don't
exactly match with respect to enum vs. uint32_t.  Use SpvOp everywhere.

Alternately, uint32_t could be used everywhere.  There doesn't seem
to be an advantage to one over the other.
---
 src/compiler/spirv/vtn_amd.c | 4 ++--
 src/compiler/spirv/vtn_glsl450.c | 2 +-
 src/compiler/spirv/vtn_private.h | 8 
 3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/src/compiler/spirv/vtn_amd.c b/src/compiler/spirv/vtn_amd.c
index 320e3b0..0d5b429 100644
--- a/src/compiler/spirv/vtn_amd.c
+++ b/src/compiler/spirv/vtn_amd.c
@@ -27,7 +27,7 @@
 #include "GLSL.ext.AMD.h"
 
 bool
-vtn_handle_amd_gcn_shader_instruction(struct vtn_builder *b, uint32_t 
ext_opcode,
+vtn_handle_amd_gcn_shader_instruction(struct vtn_builder *b, SpvOp ext_opcode,
   const uint32_t *w, unsigned count)
 {
const struct glsl_type *dest_type =
@@ -57,7 +57,7 @@ vtn_handle_amd_gcn_shader_instruction(struct vtn_builder *b, 
uint32_t ext_opcode
 }
 
 bool
-vtn_handle_amd_shader_trinary_minmax_instruction(struct vtn_builder *b, 
uint32_t ext_opcode,
+vtn_handle_amd_shader_trinary_minmax_instruction(struct vtn_builder *b, SpvOp 
ext_opcode,
  const uint32_t *w, unsigned 
count)
 {
struct nir_builder *nb = >nb;
diff --git a/src/compiler/spirv/vtn_glsl450.c b/src/compiler/spirv/vtn_glsl450.c
index eb0b90f..d208215 100644
--- a/src/compiler/spirv/vtn_glsl450.c
+++ b/src/compiler/spirv/vtn_glsl450.c
@@ -810,7 +810,7 @@ handle_glsl450_interpolation(struct vtn_builder *b, enum 
GLSLstd450 opcode,
 }
 
 bool
-vtn_handle_glsl450_instruction(struct vtn_builder *b, uint32_t ext_opcode,
+vtn_handle_glsl450_instruction(struct vtn_builder *b, SpvOp ext_opcode,
const uint32_t *w, unsigned count)
 {
switch ((enum GLSLstd450)ext_opcode) {
diff --git a/src/compiler/spirv/vtn_private.h b/src/compiler/spirv/vtn_private.h
index 982b426..b501bbf 100644
--- a/src/compiler/spirv/vtn_private.h
+++ b/src/compiler/spirv/vtn_private.h
@@ -230,7 +230,7 @@ struct vtn_function {
SpvFunctionControlMask control;
 };
 
-typedef bool (*vtn_instruction_handler)(struct vtn_builder *, uint32_t,
+typedef bool (*vtn_instruction_handler)(struct vtn_builder *, SpvOp,
 const uint32_t *, unsigned);
 
 void vtn_build_cfg(struct vtn_builder *b, const uint32_t *words,
@@ -718,7 +718,7 @@ void vtn_handle_alu(struct vtn_builder *b, SpvOp opcode,
 void vtn_handle_subgroup(struct vtn_builder *b, SpvOp opcode,
  const uint32_t *w, unsigned count);
 
-bool vtn_handle_glsl450_instruction(struct vtn_builder *b, uint32_t ext_opcode,
+bool vtn_handle_glsl450_instruction(struct vtn_builder *b, SpvOp ext_opcode,
 const uint32_t *words, unsigned count);
 
 struct vtn_builder* vtn_create_builder(const uint32_t *words, size_t 
word_count,
@@ -744,9 +744,9 @@ vtn_u64_literal(const uint32_t *w)
return (uint64_t)w[1] << 32 | w[0];
 }
 
-bool vtn_handle_amd_gcn_shader_instruction(struct vtn_builder *b, uint32_t 
ext_opcode,
+bool vtn_handle_amd_gcn_shader_instruction(struct vtn_builder *b, SpvOp 
ext_opcode,
const uint32_t *words, unsigned 
count);
 
-bool vtn_handle_amd_shader_trinary_minmax_instruction(struct vtn_builder *b, 
uint32_t ext_opcode,
+bool vtn_handle_amd_shader_trinary_minmax_instruction(struct vtn_builder *b, 
SpvOp ext_opcode,
  const uint32_t *words, 
unsigned count);
 #endif /* _VTN_PRIVATE_H_ */
-- 
2.7.4

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

[Mesa-dev] [PATCH 1/6] spirv: Fix building with SCons

2018-03-30 Thread Brian Paul

From: Neil Roberts 

The SCons build broke with commit ba975140d3c9 because a SPIR-V
function is called from Mesa main. This adds a convenience library for
SPIR-V and adds it to everything that was including nir. It also adds
both nir and spirv to drivers/x11/SConscript.

Also add nir/spirv modules to osmesa and libgl-gdi targets. (Brian Paul)
---
 src/compiler/Makefile.nir.am  |  3 +-
 src/compiler/SConscript   |  1 +
 src/compiler/SConscript.spirv | 54 +++
 src/gallium/targets/dri/SConscript|  1 +
 src/gallium/targets/haiku-softpipe/SConscript |  1 +
 src/gallium/targets/libgl-gdi/SConscript  |  6 ++-
 src/gallium/targets/libgl-xlib/SConscript |  1 +
 src/gallium/targets/osmesa/SConscript |  1 +
 src/mesa/drivers/osmesa/SConscript|  2 +
 src/mesa/drivers/x11/SConscript   |  2 +
 10 files changed, 70 insertions(+), 2 deletions(-)
 create mode 100644 src/compiler/SConscript.spirv

diff --git a/src/compiler/Makefile.nir.am b/src/compiler/Makefile.nir.am
index 32e4145..27dc129 100644
--- a/src/compiler/Makefile.nir.am
+++ b/src/compiler/Makefile.nir.am
@@ -100,4 +100,5 @@ EXTRA_DIST += \
nir/nir_opt_algebraic.py\
nir/tests \
nir/README \
-   SConscript.nir
+   SConscript.nir \
+   SConstript.spirv
diff --git a/src/compiler/SConscript b/src/compiler/SConscript
index 44509a9..0a0c073 100644
--- a/src/compiler/SConscript
+++ b/src/compiler/SConscript
@@ -27,3 +27,4 @@ Export('compiler')
 
 SConscript('SConscript.glsl')
 SConscript('SConscript.nir')
+SConscript('SConscript.spirv')
diff --git a/src/compiler/SConscript.spirv b/src/compiler/SConscript.spirv
new file mode 100644
index 000..4941088
--- /dev/null
+++ b/src/compiler/SConscript.spirv
@@ -0,0 +1,54 @@
+import common
+
+Import('*')
+
+from sys import executable as python_cmd
+
+env = env.Clone()
+
+env.MSVC2013Compat()
+
+env.Prepend(CPPPATH = [
+'#include',
+'#src',
+'#src/mapi',
+'#src/mesa',
+'#src/gallium/include',
+'#src/gallium/auxiliary',
+'#src/compiler/nir',
+'#src/compiler/spirv',
+])
+
+# Make generated headers reachable from the include path.
+env.Prepend(CPPPATH = [Dir('.').abspath, Dir('nir').abspath])
+env.Prepend(CPPPATH = [Dir('.').abspath, Dir('spirv').abspath])
+
+# spirv generated sources
+
+env.CodeGenerate(
+target = 'spirv/spirv_info.c',
+script = 'spirv/spirv_info_c.py',
+source = ['spirv/spirv.core.grammar.json'],
+command = python_cmd + ' $SCRIPT $SOURCE $TARGET'
+)
+
+env.CodeGenerate(
+target = 'spirv/vtn_gather_types.c',
+script = 'spirv/vtn_gather_types_c.py',
+source = ['spirv/spirv.core.grammar.json'],
+command = python_cmd + ' $SCRIPT $SOURCE $TARGET'
+)
+
+# parse Makefile.sources
+source_lists = env.ParseSourceList('Makefile.sources')
+
+spirv_sources = source_lists['SPIRV_FILES']
+spirv_sources += source_lists['SPIRV_GENERATED_FILES']
+
+spirv = env.ConvenienceLibrary(
+target = 'spirv',
+source = spirv_sources,
+)
+
+env.Alias('spirv', spirv)
+Export('spirv')
diff --git a/src/gallium/targets/dri/SConscript 
b/src/gallium/targets/dri/SConscript
index f5c2818..ff6ce3b 100644
--- a/src/gallium/targets/dri/SConscript
+++ b/src/gallium/targets/dri/SConscript
@@ -45,6 +45,7 @@ env.Prepend(LIBS = [
 mesa,
 glsl,
 nir,
+spirv,
 gallium,
 megadrivers_stub,
 dri_common,
diff --git a/src/gallium/targets/haiku-softpipe/SConscript 
b/src/gallium/targets/haiku-softpipe/SConscript
index f80c167..89792fb 100644
--- a/src/gallium/targets/haiku-softpipe/SConscript
+++ b/src/gallium/targets/haiku-softpipe/SConscript
@@ -10,6 +10,7 @@ env.Prepend(LIBS = [
 mesa,
 glsl,
 nir,
+spirv,
 gallium
 ])
 
diff --git a/src/gallium/targets/libgl-gdi/SConscript 
b/src/gallium/targets/libgl-gdi/SConscript
index d3251ca..b5ba0fa 100644
--- a/src/gallium/targets/libgl-gdi/SConscript
+++ b/src/gallium/targets/libgl-gdi/SConscript
@@ -18,7 +18,11 @@ env.Append(LIBS = [
 'ws2_32',
 ])
 
-env.Prepend(LIBS = [mesautil])
+env.Prepend(LIBS = [
+mesautil,
+nir,
+spirv
+])
 
 sources = ['libgl_gdi.c']
 drivers = []
diff --git a/src/gallium/targets/libgl-xlib/SConscript 
b/src/gallium/targets/libgl-xlib/SConscript
index a81ac79..b94ef35 100644
--- a/src/gallium/targets/libgl-xlib/SConscript
+++ b/src/gallium/targets/libgl-xlib/SConscript
@@ -33,6 +33,7 @@ env.Prepend(LIBS = [
 mesa,
 glsl,
 nir,
+spirv,
 gallium,
 ])
 
diff --git a/src/gallium/targets/osmesa/SConscript 
b/src/gallium/targets/osmesa/SConscript
index 7be1b48..ccf7d51 100644
--- a/src/gallium/targets/osmesa/SConscript
+++ b/src/gallium/targets/osmesa/SConscript
@@ -18,6 +18,7 @@ env.Prepend(LIBS = [
 trace,
 glsl,
 nir,
+spirv,
 mesautil,
 softpipe
 ])
diff --git a/src/mesa/drivers/osmesa/SConscript

[Mesa-dev] [PATCH 6/6] spirv: s/uint/unsigned/ to fix MSVC build

2018-03-30 Thread Brian Paul

---
 src/compiler/spirv/vtn_cfg.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/compiler/spirv/vtn_cfg.c b/src/compiler/spirv/vtn_cfg.c
index 3d5de37..e7d2f9e 100644
--- a/src/compiler/spirv/vtn_cfg.c
+++ b/src/compiler/spirv/vtn_cfg.c
@@ -513,7 +513,7 @@ vtn_cfg_walk_blocks(struct vtn_builder *b, struct list_head 
*cf_list,
  "Selector of OpSelect must have a type of OpTypeInt");
 
  bool is_default = true;
- const uint bitsize = nir_alu_type_get_type_size(cond_type);
+ const unsigned bitsize = nir_alu_type_get_type_size(cond_type);
  for (const uint32_t *w = block->branch + 2; w < branch_end;) {
 uint64_t literal = 0;
 if (!is_default) {
-- 
2.7.4

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

[Mesa-dev] [PATCH 2/6] nir/spirv: fix MSVC warning in vtn_align_u32()

2018-03-30 Thread Brian Paul

Fixes warning that "negation of an unsigned value results in an
unsigned value".
---
 src/compiler/spirv/vtn_private.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/compiler/spirv/vtn_private.h b/src/compiler/spirv/vtn_private.h
index d8a00f9..269de92 100644
--- a/src/compiler/spirv/vtn_private.h
+++ b/src/compiler/spirv/vtn_private.h
@@ -732,7 +732,7 @@ void vtn_handle_decoration(struct vtn_builder *b, SpvOp 
opcode,
 static inline uint32_t
 vtn_align_u32(uint32_t v, uint32_t a)
 {
-   assert(a != 0 && a == (a & -a));
+   assert(a != 0 && a == (a & -((int32_t) a)));
return (v + a - 1) & ~(a - 1);
 }
 
-- 
2.7.4

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

[Mesa-dev] [PATCH 3/6] nir/spirv: move NORETURN annotation on _vtn_fail() prototype

2018-03-30 Thread Brian Paul

This needs to before the function, not after, to compile with MSVC.
This works with gcc too.
---
 src/compiler/spirv/vtn_private.h | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/compiler/spirv/vtn_private.h b/src/compiler/spirv/vtn_private.h
index 269de92..982b426 100644
--- a/src/compiler/spirv/vtn_private.h
+++ b/src/compiler/spirv/vtn_private.h
@@ -71,8 +71,10 @@ void _vtn_warn(struct vtn_builder *b, const char *file, 
unsigned line,
  * So long as these two things continue to hold, we can easily longjmp back to
  * spirv_to_nir(), clean up the builder, and return NULL.
  */
-void _vtn_fail(struct vtn_builder *b, const char *file, unsigned line,
-   const char *fmt, ...) NORETURN PRINTFLIKE(4, 5);
+NORETURN void
+_vtn_fail(struct vtn_builder *b, const char *file, unsigned line,
+ const char *fmt, ...) PRINTFLIKE(4, 5);
+
 #define vtn_fail(...) _vtn_fail(b, __FILE__, __LINE__, __VA_ARGS__)
 
 /** Fail if the given expression evaluates to true */
-- 
2.7.4

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

Re: [Mesa-dev] [PATCH 1/5] radeonsi: remove fast color clear for single-sample buffers

2018-03-30 Thread Marek Olšák

Yes.

Marek

On Fri, Mar 30, 2018, 4:47 AM Dieter Nützel  wrote:

> Hello Marek,
>
> 2-3 landed.
> Is #1 dead after my findings? ;-)
>
> Dieter
>
> Am 11.03.2018 19:11, schrieb Marek Olšák:
> > From: Marek Olšák 
> >
> > This should improve the score for the GpuTest Triangle benchmark.
> > Vulkan doesn't use this either.
> > ---
> >  src/gallium/drivers/radeon/r600_pipe_common.h |  1 -
> >  src/gallium/drivers/radeon/r600_texture.c | 11 +---
> >  src/gallium/drivers/radeonsi/si_clear.c   | 37
> > ++-
> >  src/gallium/drivers/radeonsi/si_state.c   |  6 -
> >  4 files changed, 3 insertions(+), 52 deletions(-)
> >
> > diff --git a/src/gallium/drivers/radeon/r600_pipe_common.h
> > b/src/gallium/drivers/radeon/r600_pipe_common.h
> > index 7941903..9701757 100644
> > --- a/src/gallium/drivers/radeon/r600_pipe_common.h
> > +++ b/src/gallium/drivers/radeon/r600_pipe_common.h
> > @@ -209,21 +209,20 @@ struct r600_cmask_info {
> >  struct r600_texture {
> >   struct r600_resourceresource;
> >
> >   struct radeon_surf  surface;
> >   uint64_tsize;
> >   struct r600_texture *flushed_depth_texture;
> >
> >   /* Colorbuffer compression and fast clear. */
> >   struct r600_fmask_info  fmask;
> >   struct r600_cmask_info  cmask;
> > - struct r600_resource*cmask_buffer;
> >   uint64_tdcc_offset; /* 0 = disabled */
> >   unsignedcb_color_info; /* fast clear
> enable bit */
> >   unsignedcolor_clear_value[2];
> >   unsigned
> last_msaa_resolve_target_micro_mode;
> >   unsignednum_level0_transfers;
> >
> >   /* Depth buffer compression and fast clear. */
> >   uint64_thtile_offset;
> >   float   depth_clear_value;
> >   uint16_tdirty_level_mask; /* each bit says
> if that mipmap is
> > compressed */
> > diff --git a/src/gallium/drivers/radeon/r600_texture.c
> > b/src/gallium/drivers/radeon/r600_texture.c
> > index 125e7ef..03bc955 100644
> > --- a/src/gallium/drivers/radeon/r600_texture.c
> > +++ b/src/gallium/drivers/radeon/r600_texture.c
> > @@ -405,26 +405,22 @@ void si_texture_discard_cmask(struct si_screen
> > *sscreen,
> >  {
> >   if (!rtex->cmask.size)
> >   return;
> >
> >   assert(rtex->resource.b.b.nr_samples <= 1);
> >
> >   /* Disable CMASK. */
> >   memset(>cmask, 0, sizeof(rtex->cmask));
> >   rtex->cmask.base_address_reg = rtex->resource.gpu_address >> 8;
> >   rtex->dirty_level_mask = 0;
> > -
> >   rtex->cb_color_info &= ~S_028C70_FAST_CLEAR(1);
> >
> > - if (rtex->cmask_buffer != >resource)
> > - r600_resource_reference(>cmask_buffer, NULL);
> > -
> >   /* Notify all contexts about the change. */
> >   p_atomic_inc(>dirty_tex_counter);
> >   p_atomic_inc(>compressed_colortex_counter);
> >  }
> >
> >  static bool r600_can_disable_dcc(struct r600_texture *rtex)
> >  {
> >   /* We can't disable DCC if it can be written by another process. */
> >   return rtex->dcc_offset &&
> >  (!rtex->resource.b.is_shared ||
> > @@ -813,24 +809,20 @@ static boolean r600_texture_get_handle(struct
> > pipe_screen* screen,
> > slice_size, whandle);
> >  }
> >
> >  static void r600_texture_destroy(struct pipe_screen *screen,
> >struct pipe_resource *ptex)
> >  {
> >   struct r600_texture *rtex = (struct r600_texture*)ptex;
> >   struct r600_resource *resource = >resource;
> >
> >   r600_texture_reference(>flushed_depth_texture, NULL);
> > -
> > - if (rtex->cmask_buffer != >resource) {
> > - r600_resource_reference(>cmask_buffer, NULL);
> > - }
> >   pb_reference(>buf, NULL);
> >   r600_resource_reference(>dcc_separate_buffer, NULL);
> >   r600_resource_reference(>last_dcc_separate_buffer, NULL);
> >   FREE(rtex);
> >  }
> >
> >  static const struct u_resource_vtbl r600_texture_vtbl;
> >
> >  /* The number of samples can be specified independently of the
> > texture. */
> >  void si_texture_get_fmask_info(struct si_screen *sscreen,
> > @@ -1262,21 +1254,20 @@ r600_texture_create_object(struct pipe_screen
> > *screen,
> >   rtex->db_compatible = true;
> >
> >   if (!(sscreen->debug_flags & DBG(NO_HYPERZ)))
> >   r600_texture_allocate_htile(sscreen, rtex);
> >   }
> >   } else {
> >   if (base->nr_samples > 1) {
> >   if (!buf) {
> >   r600_texture_allocate_fmask(sscreen, rtex);
> >   r600_texture_allocate_cmask(sscreen, rtex);
> > -

Re: [Mesa-dev] [PATCH 1/1] gallivm: Fix build after llvm r328839

2018-03-30 Thread Dieter Nützel


Hello Jan,

can you have a look on this one (instead) and commit?
https://lists.freedesktop.org/archives/mesa-dev/2018-March/190535.html
https://patchwork.freedesktop.org/series/40916/

It has r-b from Samuel Pitoiset and t-b from me.

Thanks,

Dieter

Am 30.03.2018 18:30, schrieb Jan Vesely:

LLVM r328839 moved few function declrations to a new Utils.h header.
Fixes:
gallivm/lp_bld_init.c:145:7: error: implicit declaration of function
‘LLVMAddPromoteMemoryToRegisterPass’; did you mean
‘LLVMAddDemoteMemoryToRegisterPass’?

Signed-off-by: Jan Vesely 
---
 src/gallium/auxiliary/gallivm/lp_bld_init.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/gallium/auxiliary/gallivm/lp_bld_init.c
b/src/gallium/auxiliary/gallivm/lp_bld_init.c
index 6ddc509a81..dae9d01552 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_init.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_init.c
@@ -40,6 +40,9 @@

 #include 
 #include 
+#if HAVE_LLVM >= 0x0700
+#include 
+#endif
 #include 

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

Re: [Mesa-dev] [PATCH] spirv: Fix building with SCons

2018-03-30 Thread Ilia Mirkin

On Fri, Mar 30, 2018 at 12:40 PM, Brian Paul  wrote:
> OK, I'll have some patches soon but I'm stuck on one issue.
>
> Around spriv_to_nir.c:2090 we have
>
>   if (operands & SpvImageOperandsConstOffsetsMask) {
>  gather_offsets = vtn_ssa_value(b, w[idx++]);
>  (*p++) = (nir_tex_src){};
>   }
>
> The (nir_tex_src){} expression is not valid for MSVC (syntax error).  I
> haven't figured out exactly what that's supposed to do.
>
> Replacing it with (*p++) = (nir_tex_src)0; works but I'm not sure that's
> correct.
>
> Ilia wrote the line in question.  Ilia?

I believe it's the equivalent of

nir_tex_src foo = {};
*p++ = foo;

Or similarly,

memset(p++, 0, sizeof(nir_tex_src));

[As an aside, I have no recollection of writing this. I did do some
minor feature enablement work for some SPIR-V things, so perhaps that
was it?]

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

Re: [Mesa-dev] [PATCH] spirv: Fix building with SCons

2018-03-30 Thread Brian Paul


On 03/30/2018 10:40 AM, Brian Paul wrote:

OK, I'll have some patches soon but I'm stuck on one issue.

Around spriv_to_nir.c:2090 we have

   if (operands & SpvImageOperandsConstOffsetsMask) {
  gather_offsets = vtn_ssa_value(b, w[idx++]);
  (*p++) = (nir_tex_src){};
   }

The (nir_tex_src){} expression is not valid for MSVC (syntax error).  I 
haven't figured out exactly what that's supposed to do.


Replacing it with (*p++) = (nir_tex_src)0; works but I'm not sure that's 
correct.


I take that back.  Replacing the code with:

 nir_tex_src none = {0};
 gather_offsets = vtn_ssa_value(b, w[idx++]);
 (*p++) = none;

is what works.

-Brian



Ilia wrote the line in question.  Ilia?

-Brian



On 03/30/2018 09:25 AM, Brian Paul wrote:

Thanks, Neil.

This fixes the SCons build on Linux, but on Windows there's a whole 
bunch of other issues:


c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(232): 
error C2085:

  'vtn_instruction_handler': not in formal parameter list
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(235): 
error C2085:

  'vtn_build_cfg': not in formal parameter list
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(237): 
error C2146:

  syntax error: missing ')' before identifier 'instruction_handler'
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(237): 
error C2081:

  'vtn_instruction_handler': name in formal parameter list illegal
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(237): 
error C2085:

  'vtn_function_emit': not in formal parameter list
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(237): 
error C2146:

  syntax error: missing ',' before identifier 'instruction_handler'
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(237): 
error C2059:

  syntax error: ')'
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(241): 
error C2146:

  syntax error: missing ')' before identifier 'handler'
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(241): 
error C2081:

  'vtn_instruction_handler': name in formal parameter list illegal
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(241): 
error C2085:

  'vtn_foreach_instruction': not in formal parameter list
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(241): 
error C2146:

  syntax error: missing ',' before identifier 'handler'
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(241): 
error C2059:

  syntax error: ')'
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(369): 
error C2085:

  'vtn_types_compatible': not in formal parameter list
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(504): 
error C2061:

  syntax error: identifier 'vtn_instruction_handler'
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(505): 
error C2059:

  syntax error: '}'
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(506): 
error C2059:

  syntax error: '}'
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(597): 
error C2036:

  'vtn_value *': unknown size
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(607): 
error C2037:

  left of 'value_type' specifies undefined struct/union 'vtn_value'
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(607): 
error C2065:

  'vtn_value_type_invalid': undeclared identifier
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(609): 
error C2037:

  left of 'value_type' specifies undefined struct/union 'vtn_value'
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(611): 
error C2036:

  'vtn_value *': unknown size
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(618): 
error C2037:

  left of 'base_type' specifies undefined struct/union 'vtn_type'
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(618): 
error C2065:

  'vtn_base_type_pointer': undeclared identifier
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(619): 
error C2065:

  'vtn_value_type_pointer': undeclared identifier
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(620): 
error C2037:

  left of 'pointer' specifies undefined struct/union 'vtn_value'
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(620): 
error C2037:

  left of 'def' specifies undefined struct/union 'vtn_ssa_value'
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(620): 
warning C413

3: 'function': incompatible types - from 'vtn_type *' to 'nir_ssa_def *'
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(620): 
error C2198:

  'vtn_pointer_from_ssa': too few arguments for call
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(622): 
error C2065:

  'vtn_value_type_ssa': undeclared identifier
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(623): 
error C2037:

  left of 'ssa' specifies undefined struct/union 'vtn_value'

Re: [Mesa-dev] [PATCH] spirv: Fix building with SCons

2018-03-30 Thread Brian Paul


OK, I'll have some patches soon but I'm stuck on one issue.

Around spriv_to_nir.c:2090 we have

  if (operands & SpvImageOperandsConstOffsetsMask) {
 gather_offsets = vtn_ssa_value(b, w[idx++]);
 (*p++) = (nir_tex_src){};
  }

The (nir_tex_src){} expression is not valid for MSVC (syntax error).  I 
haven't figured out exactly what that's supposed to do.


Replacing it with (*p++) = (nir_tex_src)0; works but I'm not sure that's 
correct.


Ilia wrote the line in question.  Ilia?

-Brian



On 03/30/2018 09:25 AM, Brian Paul wrote:

Thanks, Neil.

This fixes the SCons build on Linux, but on Windows there's a whole 
bunch of other issues:


c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(232): 
error C2085:

  'vtn_instruction_handler': not in formal parameter list
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(235): 
error C2085:

  'vtn_build_cfg': not in formal parameter list
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(237): 
error C2146:

  syntax error: missing ')' before identifier 'instruction_handler'
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(237): 
error C2081:

  'vtn_instruction_handler': name in formal parameter list illegal
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(237): 
error C2085:

  'vtn_function_emit': not in formal parameter list
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(237): 
error C2146:

  syntax error: missing ',' before identifier 'instruction_handler'
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(237): 
error C2059:

  syntax error: ')'
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(241): 
error C2146:

  syntax error: missing ')' before identifier 'handler'
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(241): 
error C2081:

  'vtn_instruction_handler': name in formal parameter list illegal
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(241): 
error C2085:

  'vtn_foreach_instruction': not in formal parameter list
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(241): 
error C2146:

  syntax error: missing ',' before identifier 'handler'
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(241): 
error C2059:

  syntax error: ')'
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(369): 
error C2085:

  'vtn_types_compatible': not in formal parameter list
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(504): 
error C2061:

  syntax error: identifier 'vtn_instruction_handler'
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(505): 
error C2059:

  syntax error: '}'
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(506): 
error C2059:

  syntax error: '}'
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(597): 
error C2036:

  'vtn_value *': unknown size
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(607): 
error C2037:

  left of 'value_type' specifies undefined struct/union 'vtn_value'
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(607): 
error C2065:

  'vtn_value_type_invalid': undeclared identifier
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(609): 
error C2037:

  left of 'value_type' specifies undefined struct/union 'vtn_value'
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(611): 
error C2036:

  'vtn_value *': unknown size
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(618): 
error C2037:

  left of 'base_type' specifies undefined struct/union 'vtn_type'
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(618): 
error C2065:

  'vtn_base_type_pointer': undeclared identifier
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(619): 
error C2065:

  'vtn_value_type_pointer': undeclared identifier
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(620): 
error C2037:

  left of 'pointer' specifies undefined struct/union 'vtn_value'
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(620): 
error C2037:

  left of 'def' specifies undefined struct/union 'vtn_ssa_value'
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(620): 
warning C413

3: 'function': incompatible types - from 'vtn_type *' to 'nir_ssa_def *'
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(620): 
error C2198:

  'vtn_pointer_from_ssa': too few arguments for call
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(622): 
error C2065:

  'vtn_value_type_ssa': undeclared identifier
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(623): 
error C2037:

  left of 'ssa' specifies undefined struct/union 'vtn_value'
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(634): 
error C2037:

  left of 'value_type' specifies undefined struct/union 'vtn_value'
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(645): 
error C2065:

  'vtn_value_type_constant': undeclared

[Mesa-dev] [PATCH 1/1] gallivm: Fix build after llvm r328839

2018-03-30 Thread Jan Vesely

LLVM r328839 moved few function declrations to a new Utils.h header.
Fixes:
gallivm/lp_bld_init.c:145:7: error: implicit declaration of function 
‘LLVMAddPromoteMemoryToRegisterPass’; did you mean 
‘LLVMAddDemoteMemoryToRegisterPass’?

Signed-off-by: Jan Vesely 
---
 src/gallium/auxiliary/gallivm/lp_bld_init.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/gallium/auxiliary/gallivm/lp_bld_init.c 
b/src/gallium/auxiliary/gallivm/lp_bld_init.c
index 6ddc509a81..dae9d01552 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_init.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_init.c
@@ -40,6 +40,9 @@
 
 #include 
 #include 
+#if HAVE_LLVM >= 0x0700
+#include 
+#endif
 #include 
 
 
-- 
2.14.3

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

Re: [Mesa-dev] [PATCH] glapi: define GL_API to be GLAPI in glapi_dispatch.c

2018-03-30 Thread Charmaine Lee


Reviewed-by: Charmaine Lee 


From: Brian Paul 
Sent: Friday, March 30, 2018 7:42 AM
To: mesa-dev@lists.freedesktop.org
Cc: Charmaine Lee; Neha Bhende
Subject: [PATCH] glapi: define GL_API to be GLAPI in glapi_dispatch.c

This fixes a Windows build warning where the prototypes for the ES
function in the header file don't match the prototypes in this file
because the GL_API and GLAPI macros are defined differently.
---
 src/mapi/glapi/glapi_dispatch.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/src/mapi/glapi/glapi_dispatch.c b/src/mapi/glapi/glapi_dispatch.c
index 3239523..f0a8c36 100644
--- a/src/mapi/glapi/glapi_dispatch.c
+++ b/src/mapi/glapi/glapi_dispatch.c
@@ -97,6 +97,11 @@
  */
 #include 

+
+/* Use the GLAPI annotation from GL/gl.h, not GL_API from GLES/gl.h */
+#undef GL_API
+#define GL_API GLAPI
+
 GL_API void GL_APIENTRY glClearDepthf (GLclampf depth);
 GL_API void GL_APIENTRY glClipPlanef (GLenum plane, const GLfloat *equation);
 GL_API void GL_APIENTRY glFrustumf (GLfloat left, GLfloat right, GLfloat 
bottom, GLfloat top, GLfloat zNear, GLfloat zFar);
--
2.7.4

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

Re: [Mesa-dev] [PATCH] x11: Only report supported DRI3/Present versions

2018-03-30 Thread Daniel Stone

On 23 March 2018 at 13:03, Emil Velikov  wrote:
> On 22 March 2018 at 15:27, Daniel Stone  wrote:
>> The version passed to QueryVersion requests is the version that the
>> client supports. We were just passing in whatever version of XCB was
>> present on the system, which may not be a version that Mesa actually
>> explicitly supports, e.g. it might bring unwanted semantics.
>>
>> Set specific protocol versions which we support, and only pass those.
>>
>> Signed-off-by: Daniel Stone 
> Thanks for sorting this out Dan. With the small nitpicks, patch is
>
> Fixes: 7aeef2d4efd ("dri3: allow building against older xcb (v3)")
> Reviewed-by: Emil Velikov 

Thanks Emil, pushed with the whitespace/wording changes.

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

[Mesa-dev] [Bug 105775] SI reaches the maximum IB size in dwords and fail to submit

2018-03-30 Thread bugzilla-daemon

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

Samuel Pitoiset  changed:

   What|Removed |Added

Summary|F1 2017 crashes on GCN 1.0  |SI reaches the maximum IB
   |cards   |size in dwords and fail to
   ||submit

--- Comment #21 from Samuel Pitoiset  ---
That's a critical issue. Only SI is affected but the problem can be reproduced
with recent chips and RADV_DEBUG=noibs. I have started to work on this but the
fix isn't yet working.

-- 
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] vbo: MaxVertexAttribStride is not always set

2018-03-30 Thread Jakob Bornecrantz


On 2018-03-30 16:49, Mathias Fröhlich wrote:

On Friday, 30 March 2018 17:38:39 CEST Jakob Bornecrantz wrote:

This assert is hit on hardware which does expose GL 4.4 or GLES 3.1.


Uff - sorry!

Reviewed-by: Mathias Fröhlich 


Thanks, tho that should be "which does NOT expose" but you got the gist.

Cheers, Jakob.



Mathias



Signed-off-by: Jakob Bornecrantz 
---
  src/mesa/vbo/vbo_save_api.c | 7 ++-
  1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/src/mesa/vbo/vbo_save_api.c b/src/mesa/vbo/vbo_save_api.c
index a367a569c8..71304ede49 100644
--- a/src/mesa/vbo/vbo_save_api.c
+++ b/src/mesa/vbo/vbo_save_api.c
@@ -492,8 +492,13 @@ update_vao(struct gl_context *ctx,
 _mesa_reference_vao(ctx, vao, NULL);
 *vao = _mesa_new_vao(ctx, ~((GLuint)0));
  
+   /*

+* assert(stride <= ctx->Const.MaxVertexAttribStride);
+* MaxVertexAttribStride is not set for drivers that does not
+* expose GL 44 or GLES 31.
+*/
+
 /* Bind the buffer object at binding point 0 */
-   assert(stride <= ctx->Const.MaxVertexAttribStride);
 _mesa_bind_vertex_buffer(ctx, *vao, 0, bo, buffer_offset, stride,

false);
  
 /* Retrieve the mapping from VBO_ATTRIB to VERT_ATTRIB space









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

[Mesa-dev] [Bug 103999] 4x MSAA with RG32F shows garbage on triangle edges

2018-03-30 Thread bugzilla-daemon

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

--- Comment #9 from Samuel Pitoiset  ---
Cool, could try again mesa master to confirm the issue is really fixed? Thanks!

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

Re: [Mesa-dev] [PATCH] mesa: fix MSVC bitshift overflow warnings

2018-03-30 Thread Roland Scheidegger

Am 30.03.2018 um 17:09 schrieb Brian Paul:
> In the BITFIELD_MASK() macro, if b==32 the expression evaluates to
> ~0u, but the compiler still sees the expression (1 << 32) in the
> unused part and issues a warning about integer bitshift overflow.
> 
> Fix that by using (b) % 32 to ensure the max shift is 31 bits.
> 
> This issue has been present for a while, but shows up much more
> often because of the recent VBO changes.
> ---
>  src/mesa/main/mtypes.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
> index 801bd17..b7a7b34 100644
> --- a/src/mesa/main/mtypes.h
> +++ b/src/mesa/main/mtypes.h
> @@ -59,7 +59,7 @@ extern "C" {
>  #define BITFIELD_BIT(b)  ((GLbitfield)1 << (b))
>  /** Set all bits up to excluding bit b */
>  #define BITFIELD_MASK(b)  \
> -   ((b) == 32 ? (~(GLbitfield)0) : BITFIELD_BIT(b) - 1)
> +   ((b) == 32 ? (~(GLbitfield)0) : BITFIELD_BIT((b) % 32) - 1)
>  /** Set count bits starting from bit b  */
>  #define BITFIELD_RANGE(b, count) \
> (BITFIELD_MASK((b) + (count)) & ~BITFIELD_MASK(b))
> 

Looks reasonable to me.
Reviewed-by: Roland Scheidegger 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] vbo: MaxVertexAttribStride is not always set

2018-03-30 Thread Mathias Fröhlich

On Friday, 30 March 2018 17:38:39 CEST Jakob Bornecrantz wrote:
> This assert is hit on hardware which does expose GL 4.4 or GLES 3.1.

Uff - sorry!

Reviewed-by: Mathias Fröhlich 

Mathias

> 
> Signed-off-by: Jakob Bornecrantz 
> ---
>  src/mesa/vbo/vbo_save_api.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/src/mesa/vbo/vbo_save_api.c b/src/mesa/vbo/vbo_save_api.c
> index a367a569c8..71304ede49 100644
> --- a/src/mesa/vbo/vbo_save_api.c
> +++ b/src/mesa/vbo/vbo_save_api.c
> @@ -492,8 +492,13 @@ update_vao(struct gl_context *ctx,
> _mesa_reference_vao(ctx, vao, NULL);
> *vao = _mesa_new_vao(ctx, ~((GLuint)0));
>  
> +   /*
> +* assert(stride <= ctx->Const.MaxVertexAttribStride);
> +* MaxVertexAttribStride is not set for drivers that does not
> +* expose GL 44 or GLES 31.
> +*/
> +
> /* Bind the buffer object at binding point 0 */
> -   assert(stride <= ctx->Const.MaxVertexAttribStride);
> _mesa_bind_vertex_buffer(ctx, *vao, 0, bo, buffer_offset, stride, 
false);
>  
> /* Retrieve the mapping from VBO_ATTRIB to VERT_ATTRIB space
> 




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

[Mesa-dev] [PATCH] vulkan/wsi/wayland: fix leaks

2018-03-30 Thread James Legg

Fixes: bfa22266cd vulkan/wsi/wayland: Add support for zwp_dmabuf
CC: Daniel Stone 
CC: Jason Ekstrand 
---
 src/vulkan/wsi/wsi_common_wayland.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/vulkan/wsi/wsi_common_wayland.c 
b/src/vulkan/wsi/wsi_common_wayland.c
index d36947bc29..ec38a4e578 100644
--- a/src/vulkan/wsi/wsi_common_wayland.c
+++ b/src/vulkan/wsi/wsi_common_wayland.c
@@ -317,8 +317,12 @@ wsi_wl_display_finish(struct wsi_wl_display *display)
assert(display->refcount == 0);
 
u_vector_finish(>formats);
+   u_vector_finish(>modifiers.argb);
+   u_vector_finish(>modifiers.xrgb);
if (display->drm)
   wl_drm_destroy(display->drm);
+   if (display->dmabuf)
+  zwp_linux_dmabuf_v1_destroy(display->dmabuf);
if (display->wl_display_wrapper)
   wl_proxy_wrapper_destroy(display->wl_display_wrapper);
if (display->queue)
-- 
2.14.3

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

Re: [Mesa-dev] Status of radeonsi NIR

2018-03-30 Thread Benedikt Schemmer

Hi all,

I did some more testing with NIR and wanted to share the results.
https://github.com/bendat78/mymesa/tree/mymesa2/testresults

Overall it seems nir could be better than tgsi, but there are some
shaders with significant regressions and I think that introduces
framerate drops that are quite noticable in some games (Total War:
WARHAMMER benchmark for example).

See the run* directory for comparisons of tgsi vs nir for different
versions of llvm and tgsi or nir vs different llvm backends (also
includes complete shader db output (around 50k shaders)).

NIR gets better with every version increase of llvm, which optimizes for
code size (why not speed ?).

I found no serious regressions so far, however I think that NIR is
responsible for some crashes that happen in Metro 2033 Redux (beginning
before actual game) and Dead Island classic (ingame) so probably related
to compilation issues.

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

Re: [Mesa-dev] [PATCH] vbo: Use alloca for _vbo_draw_indirect.

2018-03-30 Thread Mathias Fröhlich

Hi Brian,

> Can you just rename 'space' to 'prim' and rm the prim = space assignment 
> below?
> 
> Also, could you put a comment on this function to explain the draw_count 
> and space/prim parameters, at least?
I'll try my best!

> Other than that, the series looks good.
> 
> Reviewed-by: Brian Paul 
Thanks for the review!!!

> Sorry for the slow review, busy with other things.
No worries. I can make use of the wait time in between :-)
But now, today is mesa time for me ...
Thank you!

best

Mathias


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

Re: [Mesa-dev] [PATCH] glapi: define GL_API to be GLAPI in glapi_dispatch.c

2018-03-30 Thread Mathias Fröhlich


On Friday, 30 March 2018 16:42:43 CEST Brian Paul wrote:
> This fixes a Windows build warning where the prototypes for the ES
> function in the header file don't match the prototypes in this file
> because the GL_API and GLAPI macros are defined differently.
> ---
>  src/mapi/glapi/glapi_dispatch.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/src/mapi/glapi/glapi_dispatch.c b/src/mapi/glapi/
glapi_dispatch.c
> index 3239523..f0a8c36 100644
> --- a/src/mapi/glapi/glapi_dispatch.c
> +++ b/src/mapi/glapi/glapi_dispatch.c
> @@ -97,6 +97,11 @@
>   */
>  #include 
>  
> +
> +/* Use the GLAPI annotation from GL/gl.h, not GL_API from GLES/gl.h */
> +#undef GL_API
> +#define GL_API GLAPI
> +


Hi Brian,

I wonder if this proposed change introduces some similar warning on some non 
windows builds.

It looks like down in the generated glapitemp.h included down the file, the 
functions get implemented like 

KEYWORD1  KEYWORD2 glSomething(...);

So, may be you want to define:

#define GL_API KEYWORD1

to match the prototypes with the implementation?

best
Mathias

>  GL_API void GL_APIENTRY glClearDepthf (GLclampf depth);
>  GL_API void GL_APIENTRY glClipPlanef (GLenum plane, const GLfloat 
*equation);
>  GL_API void GL_APIENTRY glFrustumf (GLfloat left, GLfloat right, GLfloat 
bottom, GLfloat top, GLfloat zNear, GLfloat zFar);
> 




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

[Mesa-dev] [PATCH] vbo: MaxVertexAttribStride is not always set

2018-03-30 Thread Jakob Bornecrantz

This assert is hit on hardware which does expose GL 4.4 or GLES 3.1.

Signed-off-by: Jakob Bornecrantz 
---
 src/mesa/vbo/vbo_save_api.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/src/mesa/vbo/vbo_save_api.c b/src/mesa/vbo/vbo_save_api.c
index a367a569c8..71304ede49 100644
--- a/src/mesa/vbo/vbo_save_api.c
+++ b/src/mesa/vbo/vbo_save_api.c
@@ -492,8 +492,13 @@ update_vao(struct gl_context *ctx,
_mesa_reference_vao(ctx, vao, NULL);
*vao = _mesa_new_vao(ctx, ~((GLuint)0));
 
+   /*
+* assert(stride <= ctx->Const.MaxVertexAttribStride);
+* MaxVertexAttribStride is not set for drivers that does not
+* expose GL 44 or GLES 31.
+*/
+
/* Bind the buffer object at binding point 0 */
-   assert(stride <= ctx->Const.MaxVertexAttribStride);
_mesa_bind_vertex_buffer(ctx, *vao, 0, bo, buffer_offset, stride, false);
 
/* Retrieve the mapping from VBO_ATTRIB to VERT_ATTRIB space
-- 
2.14.1

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

Re: [Mesa-dev] [PATCH] spirv: Fix building with SCons

2018-03-30 Thread Brian Paul


Thanks, Neil.

This fixes the SCons build on Linux, but on Windows there's a whole 
bunch of other issues:


c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(232): 
error C2085:

 'vtn_instruction_handler': not in formal parameter list
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(235): 
error C2085:

 'vtn_build_cfg': not in formal parameter list
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(237): 
error C2146:

 syntax error: missing ')' before identifier 'instruction_handler'
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(237): 
error C2081:

 'vtn_instruction_handler': name in formal parameter list illegal
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(237): 
error C2085:

 'vtn_function_emit': not in formal parameter list
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(237): 
error C2146:

 syntax error: missing ',' before identifier 'instruction_handler'
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(237): 
error C2059:

 syntax error: ')'
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(241): 
error C2146:

 syntax error: missing ')' before identifier 'handler'
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(241): 
error C2081:

 'vtn_instruction_handler': name in formal parameter list illegal
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(241): 
error C2085:

 'vtn_foreach_instruction': not in formal parameter list
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(241): 
error C2146:

 syntax error: missing ',' before identifier 'handler'
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(241): 
error C2059:

 syntax error: ')'
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(369): 
error C2085:

 'vtn_types_compatible': not in formal parameter list
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(504): 
error C2061:

 syntax error: identifier 'vtn_instruction_handler'
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(505): 
error C2059:

 syntax error: '}'
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(506): 
error C2059:

 syntax error: '}'
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(597): 
error C2036:

 'vtn_value *': unknown size
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(607): 
error C2037:

 left of 'value_type' specifies undefined struct/union 'vtn_value'
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(607): 
error C2065:

 'vtn_value_type_invalid': undeclared identifier
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(609): 
error C2037:

 left of 'value_type' specifies undefined struct/union 'vtn_value'
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(611): 
error C2036:

 'vtn_value *': unknown size
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(618): 
error C2037:

 left of 'base_type' specifies undefined struct/union 'vtn_type'
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(618): 
error C2065:

 'vtn_base_type_pointer': undeclared identifier
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(619): 
error C2065:

 'vtn_value_type_pointer': undeclared identifier
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(620): 
error C2037:

 left of 'pointer' specifies undefined struct/union 'vtn_value'
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(620): 
error C2037:

 left of 'def' specifies undefined struct/union 'vtn_ssa_value'
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(620): 
warning C413

3: 'function': incompatible types - from 'vtn_type *' to 'nir_ssa_def *'
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(620): 
error C2198:

 'vtn_pointer_from_ssa': too few arguments for call
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(622): 
error C2065:

 'vtn_value_type_ssa': undeclared identifier
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(623): 
error C2037:

 left of 'ssa' specifies undefined struct/union 'vtn_value'
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(634): 
error C2037:

 left of 'value_type' specifies undefined struct/union 'vtn_value'
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(645): 
error C2065:

 'vtn_value_type_constant': undeclared identifier
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(645): 
error C2037:

 left of 'constant' specifies undefined struct/union 'vtn_value'
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(645): 
warning C403

3: 'vtn_constant_value' must return a value
c:\users\brian\projects\mesa\src\compiler\spirv\vtn_private.h(735): 
warning C414

6: unary minus operator applied to unsigned type, result still unsigned
src\compiler\spirv\gl_spirv.c(89): error C2065: 
'vtn_value_type_constant': undec

lared identifier
src\compiler\spirv\gl_spirv.c(250): warning C4013:

Re: [Mesa-dev] [PATCH] mesa: fix MSVC bitshift overflow warnings

2018-03-30 Thread Mathias Fröhlich

On Friday, 30 March 2018 17:09:40 CEST Brian Paul wrote:
> In the BITFIELD_MASK() macro, if b==32 the expression evaluates to
> ~0u, but the compiler still sees the expression (1 << 32) in the
> unused part and issues a warning about integer bitshift overflow.
> 
> Fix that by using (b) % 32 to ensure the max shift is 31 bits.
> 
> This issue has been present for a while, but shows up much more
> often because of the recent VBO changes.
> ---
>  src/mesa/main/mtypes.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
> index 801bd17..b7a7b34 100644
> --- a/src/mesa/main/mtypes.h
> +++ b/src/mesa/main/mtypes.h
> @@ -59,7 +59,7 @@ extern "C" {
>  #define BITFIELD_BIT(b)  ((GLbitfield)1 << (b))
>  /** Set all bits up to excluding bit b */
>  #define BITFIELD_MASK(b)  \
> -   ((b) == 32 ? (~(GLbitfield)0) : BITFIELD_BIT(b) - 1)
> +   ((b) == 32 ? (~(GLbitfield)0) : BITFIELD_BIT((b) % 32) - 1)
>  /** Set count bits starting from bit b  */
>  #define BITFIELD_RANGE(b, count) \
> (BITFIELD_MASK((b) + (count)) & ~BITFIELD_MASK(b))
> 

Definitely:

Reviewed-by: Mathias Fröhlich 

best
Mathias


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

[Mesa-dev] [Bug 105817] scons build broken by glSpecializeShaderARB

2018-03-30 Thread bugzilla-daemon

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

--- Comment #1 from Neil Roberts  ---
I posted a patch for this. Any comments from someone experienced with SCons
would be much appreciated.

https://patchwork.freedesktop.org/patch/214058/

-- 
You are receiving this mail because:
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] spirv: Fix building with SCons

2018-03-30 Thread Neil Roberts

The SCons build broke with commit ba975140d3c9 because a SPIR-V
function is called from Mesa main. This adds a convenience library for
SPIR-V and adds it to everything that was including nir. It also adds
both nir and spirv to drivers/x11/SConscript.

---

It would be great if someone who depends on SCons could test this. We
weren’t sure if there was a good reason why nir isn’t already included
in drivers/x11/SConscript and whether adding it might break some
platform.

 src/compiler/Makefile.nir.am  |  3 +-
 src/compiler/SConscript   |  1 +
 src/compiler/SConscript.spirv | 54 +++
 src/gallium/targets/dri/SConscript|  1 +
 src/gallium/targets/haiku-softpipe/SConscript |  1 +
 src/gallium/targets/libgl-xlib/SConscript |  1 +
 src/gallium/targets/osmesa/SConscript |  1 +
 src/mesa/drivers/x11/SConscript   |  2 +
 8 files changed, 63 insertions(+), 1 deletion(-)
 create mode 100644 src/compiler/SConscript.spirv

diff --git a/src/compiler/Makefile.nir.am b/src/compiler/Makefile.nir.am
index 32e4145b70f..27dc129e57b 100644
--- a/src/compiler/Makefile.nir.am
+++ b/src/compiler/Makefile.nir.am
@@ -100,4 +100,5 @@ EXTRA_DIST += \
nir/nir_opt_algebraic.py\
nir/tests \
nir/README \
-   SConscript.nir
+   SConscript.nir \
+   SConstript.spirv
diff --git a/src/compiler/SConscript b/src/compiler/SConscript
index 44509a9a95b..0a0c0737422 100644
--- a/src/compiler/SConscript
+++ b/src/compiler/SConscript
@@ -27,3 +27,4 @@ Export('compiler')
 
 SConscript('SConscript.glsl')
 SConscript('SConscript.nir')
+SConscript('SConscript.spirv')
diff --git a/src/compiler/SConscript.spirv b/src/compiler/SConscript.spirv
new file mode 100644
index 000..49410881d0b
--- /dev/null
+++ b/src/compiler/SConscript.spirv
@@ -0,0 +1,54 @@
+import common
+
+Import('*')
+
+from sys import executable as python_cmd
+
+env = env.Clone()
+
+env.MSVC2013Compat()
+
+env.Prepend(CPPPATH = [
+'#include',
+'#src',
+'#src/mapi',
+'#src/mesa',
+'#src/gallium/include',
+'#src/gallium/auxiliary',
+'#src/compiler/nir',
+'#src/compiler/spirv',
+])
+
+# Make generated headers reachable from the include path.
+env.Prepend(CPPPATH = [Dir('.').abspath, Dir('nir').abspath])
+env.Prepend(CPPPATH = [Dir('.').abspath, Dir('spirv').abspath])
+
+# spirv generated sources
+
+env.CodeGenerate(
+target = 'spirv/spirv_info.c',
+script = 'spirv/spirv_info_c.py',
+source = ['spirv/spirv.core.grammar.json'],
+command = python_cmd + ' $SCRIPT $SOURCE $TARGET'
+)
+
+env.CodeGenerate(
+target = 'spirv/vtn_gather_types.c',
+script = 'spirv/vtn_gather_types_c.py',
+source = ['spirv/spirv.core.grammar.json'],
+command = python_cmd + ' $SCRIPT $SOURCE $TARGET'
+)
+
+# parse Makefile.sources
+source_lists = env.ParseSourceList('Makefile.sources')
+
+spirv_sources = source_lists['SPIRV_FILES']
+spirv_sources += source_lists['SPIRV_GENERATED_FILES']
+
+spirv = env.ConvenienceLibrary(
+target = 'spirv',
+source = spirv_sources,
+)
+
+env.Alias('spirv', spirv)
+Export('spirv')
diff --git a/src/gallium/targets/dri/SConscript 
b/src/gallium/targets/dri/SConscript
index f5c2818d04f..ff6ce3bf4e0 100644
--- a/src/gallium/targets/dri/SConscript
+++ b/src/gallium/targets/dri/SConscript
@@ -45,6 +45,7 @@ env.Prepend(LIBS = [
 mesa,
 glsl,
 nir,
+spirv,
 gallium,
 megadrivers_stub,
 dri_common,
diff --git a/src/gallium/targets/haiku-softpipe/SConscript 
b/src/gallium/targets/haiku-softpipe/SConscript
index f80c167d83b..89792fba132 100644
--- a/src/gallium/targets/haiku-softpipe/SConscript
+++ b/src/gallium/targets/haiku-softpipe/SConscript
@@ -10,6 +10,7 @@ env.Prepend(LIBS = [
 mesa,
 glsl,
 nir,
+spirv,
 gallium
 ])
 
diff --git a/src/gallium/targets/libgl-xlib/SConscript 
b/src/gallium/targets/libgl-xlib/SConscript
index a81ac793251..b94ef350b16 100644
--- a/src/gallium/targets/libgl-xlib/SConscript
+++ b/src/gallium/targets/libgl-xlib/SConscript
@@ -33,6 +33,7 @@ env.Prepend(LIBS = [
 mesa,
 glsl,
 nir,
+spirv,
 gallium,
 ])
 
diff --git a/src/gallium/targets/osmesa/SConscript 
b/src/gallium/targets/osmesa/SConscript
index 7be1b48c0b2..ccf7d5170c4 100644
--- a/src/gallium/targets/osmesa/SConscript
+++ b/src/gallium/targets/osmesa/SConscript
@@ -18,6 +18,7 @@ env.Prepend(LIBS = [
 trace,
 glsl,
 nir,
+spirv,
 mesautil,
 softpipe
 ])
diff --git a/src/mesa/drivers/x11/SConscript b/src/mesa/drivers/x11/SConscript
index 59c8df4b3c2..b097dcc5900 100644
--- a/src/mesa/drivers/x11/SConscript
+++ b/src/mesa/drivers/x11/SConscript
@@ -21,6 +21,8 @@ env.Prepend(LIBS = [
 compiler,
 glsl,
 mesa,
+spirv,
+nir,
 ])
 
 sources = [
-- 
2.14.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org

[Mesa-dev] [PATCH] mesa: fix MSVC bitshift overflow warnings

2018-03-30 Thread Brian Paul

In the BITFIELD_MASK() macro, if b==32 the expression evaluates to
~0u, but the compiler still sees the expression (1 << 32) in the
unused part and issues a warning about integer bitshift overflow.

Fix that by using (b) % 32 to ensure the max shift is 31 bits.

This issue has been present for a while, but shows up much more
often because of the recent VBO changes.
---
 src/mesa/main/mtypes.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 801bd17..b7a7b34 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -59,7 +59,7 @@ extern "C" {
 #define BITFIELD_BIT(b)  ((GLbitfield)1 << (b))
 /** Set all bits up to excluding bit b */
 #define BITFIELD_MASK(b)  \
-   ((b) == 32 ? (~(GLbitfield)0) : BITFIELD_BIT(b) - 1)
+   ((b) == 32 ? (~(GLbitfield)0) : BITFIELD_BIT((b) % 32) - 1)
 /** Set count bits starting from bit b  */
 #define BITFIELD_RANGE(b, count) \
(BITFIELD_MASK((b) + (count)) & ~BITFIELD_MASK(b))
-- 
2.7.4

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

Re: [Mesa-dev] [PATCH 00/11 v2] TGSI: improved live range tracking, also including arrays

2018-03-30 Thread Dieter Nützel


Am 30.03.2018 17:01, schrieb Ilia Mirkin:
On Fri, Mar 30, 2018 at 10:33 AM, Dieter Nützel  
wrote:

For the series:

Tested-by: Dieter Nützel 

with glmark2, UH, UV, KDE Plasma5 (my desktop)
R600_DEBUG=sisched,nir
but on radeonsi, Polaris 20 (RX580) not r600 ;-)


This series is relevant to TGSI. However you're forcing the nir path.
Your testing was largely a no-op, I'm afraid.

  -ilia


Oh dear, yes shit ;-)
I'll retry without 'nir' then...

Argh.

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

Re: [Mesa-dev] [PATCH 00/11 v2] TGSI: improved live range tracking, also including arrays

2018-03-30 Thread Ilia Mirkin

On Fri, Mar 30, 2018 at 10:33 AM, Dieter Nützel  wrote:
> For the series:
>
> Tested-by: Dieter Nützel 
>
> with glmark2, UH, UV, KDE Plasma5 (my desktop)
> R600_DEBUG=sisched,nir
> but on radeonsi, Polaris 20 (RX580) not r600 ;-)

This series is relevant to TGSI. However you're forcing the nir path.
Your testing was largely a no-op, I'm afraid.

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

Re: [Mesa-dev] [PATCH] st/mesa: add missing GLSL_TYPE_[U]INT8 cases in st_glsl_type_dword_size()

2018-03-30 Thread Mathias Fröhlich

Hi Brian,

looks plausible to me.
Reviewed-by: Mathias Fröhlich 

best
Mathias

On Thursday, 29 March 2018 03:40:29 CEST Brian Paul wrote:
> Silences a compiler warning about unhandled enum switch cases.
> ---
>  src/mesa/state_tracker/st_glsl_types.cpp | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/src/mesa/state_tracker/st_glsl_types.cpp b/src/mesa/
state_tracker/st_glsl_types.cpp
> index ef7b7fa..9ad76c9 100644
> --- a/src/mesa/state_tracker/st_glsl_types.cpp
> +++ b/src/mesa/state_tracker/st_glsl_types.cpp
> @@ -124,6 +124,9 @@ st_glsl_type_dword_size(const struct glsl_type *type)
> case GLSL_TYPE_INT16:
> case GLSL_TYPE_FLOAT16:
>return DIV_ROUND_UP(type->components(), 2);
> +   case GLSL_TYPE_UINT8:
> +   case GLSL_TYPE_INT8:
> +  return DIV_ROUND_UP(type->components(), 4);
> case GLSL_TYPE_DOUBLE:
> case GLSL_TYPE_UINT64:
> case GLSL_TYPE_INT64:
> 




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

[Mesa-dev] [PATCH] glapi: define GL_API to be GLAPI in glapi_dispatch.c

2018-03-30 Thread Brian Paul

This fixes a Windows build warning where the prototypes for the ES
function in the header file don't match the prototypes in this file
because the GL_API and GLAPI macros are defined differently.
---
 src/mapi/glapi/glapi_dispatch.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/src/mapi/glapi/glapi_dispatch.c b/src/mapi/glapi/glapi_dispatch.c
index 3239523..f0a8c36 100644
--- a/src/mapi/glapi/glapi_dispatch.c
+++ b/src/mapi/glapi/glapi_dispatch.c
@@ -97,6 +97,11 @@
  */
 #include 
 
+
+/* Use the GLAPI annotation from GL/gl.h, not GL_API from GLES/gl.h */
+#undef GL_API
+#define GL_API GLAPI
+
 GL_API void GL_APIENTRY glClearDepthf (GLclampf depth);
 GL_API void GL_APIENTRY glClipPlanef (GLenum plane, const GLfloat *equation);
 GL_API void GL_APIENTRY glFrustumf (GLfloat left, GLfloat right, GLfloat 
bottom, GLfloat top, GLfloat zNear, GLfloat zFar);
-- 
2.7.4

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

Re: [Mesa-dev] VC4 not working for me with mesa 17.3.7

2018-03-30 Thread Daniel Stone

Hi Andreas,

On 30 March 2018 at 15:18, Andreas Müller  wrote:
> What happened: I build all images cross with Openembedded/Yocto. To
> prepare next release there I updated my builds and that moved mesa
> 17.1.7 -> 17.3.7. Since then all applications using GL/GLES (e.g
> glmark2-es - tried others - same) complain with
>
> | Modifier 0x0 vs. tiling (0x701) mismatch
>
> and drawable region remains black.
> There was some discussion on meta-raspberrypi mailing list and it
> seems to happen to others too [1].
>
> I've attached a patch. That fixes glmark2-es and many others but e.g
> on KDE desktop mouse pointer is just pixel dust so I think that my
> (naive) approach only works around an issue caused somewhere else. To
> ne honest my background understanding is poor but it seems that
> modifier gets not properly for all cases.

Odd. That happens when something has already allocated the buffer as a
tiled buffer, but Mesa is being told that the buffer is linear. Are
you able to get a backtrace from when this error happens? (Either set
a breakpoint by hand, or just add 'uint32_t *crash = NULL; *crash =
1;' to force a segfault.)

I could only find one place where this would happen, which is when
using the old DRI2 interface with Gallium, but it really should be
using DRI3 ... nonetheless, does the attached patch help at all?

Cheers,
Daniel
diff --git a/src/gallium/state_trackers/dri/dri2.c b/src/gallium/state_trackers/dri/dri2.c
index 31d17d46c29..58a6757f037 100644
--- a/src/gallium/state_trackers/dri/dri2.c
+++ b/src/gallium/state_trackers/dri/dri2.c
@@ -806,6 +806,7 @@ dri2_allocate_textures(struct dri_context *ctx,
  whandle.handle = buf->name;
  whandle.stride = buf->pitch;
  whandle.offset = 0;
+ whandle.modifier = DRM_FORMAT_MOD_INVALID;
  if (screen->can_share_buffer)
 whandle.type = DRM_API_HANDLE_TYPE_SHARED;
  else
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] RFC: Externd IMG_context_priority with NV_context_priority_realtime

2018-03-30 Thread Chris Wilson

NV_context_priority_realtime
https://www.khronos.org/registry/EGL/extensions/NV/EGL_NV_context_priority_realtime.txt

"This extension allows an EGLContext to be created with one extra
priority level in addition to three priority levels that are part of
EGL_IMG_context_priority extension.

This new level has extra privileges that are not available to other three
levels. Some of the privileges may include:
- Allow realtime priority to only few contexts
- Allow realtime priority only to trusted applications
- Make sure realtime priority contexts are executed immediately
- Preempt any current context running on GPU on submission of
  commands for realtime context"

At its most basic, it just adds an extra enum and level into the existing
context priority framework.

For i915, we are proposing to use a quality-of-service parameter in
addition to that of just a priority that usurps everyone. Due to our HW,
preemption may not be immediate and will be forced to wait until an
uncooperative process hits an arbitration point. To prevent that unduly
impacting the privileged RealTime context, we back up the preemption
request with a timeout to reset the GPU and forcibly evict the GPU hog
in order to execute the new context.

Opens:

 - How is include/EGL/eglext.h meant to be updated to include the new
   extension?

 - screen->priority_mask in freedeno_screen.c (Rob?)

References: 95ecf3df6237 ("egl: Support IMG_context_priority")
Signed-off-by: Chris Wilson 
Cc: Rob Clark 
Cc: Ben Widawsky 
Cc: Emil Velikov 
Cc: Eric Engestrom 
Cc: Kenneth Graunke 
Cc: Joonas Lahtinen 
---
 docs/relnotes/18.1.0.html|  1 +
 include/EGL/eglext.h |  5 +
 include/GL/internal/dri_interface.h  |  2 ++
 src/egl/drivers/dri2/egl_dri2.c  |  3 +++
 src/egl/main/eglcontext.c|  3 +++
 src/egl/main/egldisplay.h|  7 ---
 src/gallium/include/pipe/p_defines.h | 12 +---
 src/gallium/include/state_tracker/st_api.h   |  1 +
 src/gallium/state_trackers/dri/dri_context.c |  3 +++
 src/mesa/drivers/dri/i965/brw_bufmgr.c   | 19 +++
 src/mesa/drivers/dri/i965/brw_bufmgr.h   |  3 +++
 src/mesa/drivers/dri/i965/brw_context.c  | 11 +++
 src/mesa/drivers/dri/i965/intel_screen.c |  6 ++
 src/mesa/state_tracker/st_manager.c  |  2 ++
 14 files changed, 72 insertions(+), 6 deletions(-)

diff --git a/docs/relnotes/18.1.0.html b/docs/relnotes/18.1.0.html
index 3e119078731..43f29932e39 100644
--- a/docs/relnotes/18.1.0.html
+++ b/docs/relnotes/18.1.0.html
@@ -51,6 +51,7 @@ Note: some of the new features are only available with 
certain drivers.
 GL_EXT_shader_framebuffer_fetch on i965 on desktop GL (GLES was already 
supported)
 GL_EXT_shader_framebuffer_fetch_non_coherent on i965
 Disk shader cache support for i965 enabled by default
+EGL_NV_context_priority_realtime on i965, freedeno
 
 
 Bug fixes
diff --git a/include/EGL/eglext.h b/include/EGL/eglext.h
index 2f990cc54d6..068dbb481c2 100644
--- a/include/EGL/eglext.h
+++ b/include/EGL/eglext.h
@@ -918,6 +918,11 @@ EGLAPI EGLSurface EGLAPIENTRY eglCreatePixmapSurfaceHI 
(EGLDisplay dpy, EGLConfi
 #define EGL_CONTEXT_PRIORITY_LOW_IMG  0x3103
 #endif /* EGL_IMG_context_priority */
 
+#ifndef EGL_NV_context_priority_realtime
+#define EGL_NV_context_priority 1_realtime
+#define EGL_CONTEXT_PRIORITY_REALTIME_NV  0x3357
+#endif /* EGL_NV_context_priority_realtime */
+
 #ifndef EGL_IMG_image_plane_attribs
 #define EGL_IMG_image_plane_attribs 1
 #define EGL_NATIVE_BUFFER_MULTIPLANE_SEPARATE_IMG 0x3105
diff --git a/include/GL/internal/dri_interface.h 
b/include/GL/internal/dri_interface.h
index 4f4795c7ae3..8be0d89e6a6 100644
--- a/include/GL/internal/dri_interface.h
+++ b/include/GL/internal/dri_interface.h
@@ -1129,6 +1129,7 @@ struct __DRIdri2LoaderExtensionRec {
 #define __DRI_CTX_PRIORITY_LOW 0
 #define __DRI_CTX_PRIORITY_MEDIUM  1
 #define __DRI_CTX_PRIORITY_HIGH2
+#define __DRI_CTX_PRIORITY_REALTIME3
 
 /**
  * \name Context release behaviors.
@@ -1855,6 +1856,7 @@ typedef struct __DRIDriverVtableExtensionRec {
 #define   __DRI2_RENDERER_HAS_CONTEXT_PRIORITY_LOW(1 << 0)
 #define   __DRI2_RENDERER_HAS_CONTEXT_PRIORITY_MEDIUM (1 << 1)
 #define   __DRI2_RENDERER_HAS_CONTEXT_PRIORITY_HIGH   (1 << 2)
+#define   __DRI2_RENDERER_HAS_CONTEXT_PRIORITY_REALTIME   (1 << 3)
 
 typedef struct __DRI2rendererQueryExtensionRec __DRI2rendererQueryExtension;
 struct __DRI2rendererQueryExtensionRec {
diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
index 45d0c7275c5..4bed1aa2c6f 100644
---

[Mesa-dev] [PATCH] st/mesa: add missing GLSL_TYPE_[U]INT8 cases in st_glsl_type_dword_size()

2018-03-30 Thread Brian Paul

Silences a compiler warning about unhandled enum switch cases.
---
 src/mesa/state_tracker/st_glsl_types.cpp | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/mesa/state_tracker/st_glsl_types.cpp 
b/src/mesa/state_tracker/st_glsl_types.cpp
index baba2d4..42d4e9c 100644
--- a/src/mesa/state_tracker/st_glsl_types.cpp
+++ b/src/mesa/state_tracker/st_glsl_types.cpp
@@ -124,6 +124,9 @@ st_glsl_type_dword_size(const struct glsl_type *type)
case GLSL_TYPE_INT16:
case GLSL_TYPE_FLOAT16:
   return DIV_ROUND_UP(type->components(), 2);
+   case GLSL_TYPE_UINT8:
+   case GLSL_TYPE_INT8:
+  return DIV_ROUND_UP(type->components(), 4);
case GLSL_TYPE_DOUBLE:
case GLSL_TYPE_UINT64:
case GLSL_TYPE_INT64:
-- 
2.7.4

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

Re: [Mesa-dev] [PATCH 00/11 v2] TGSI: improved live range tracking, also including arrays

2018-03-30 Thread Dieter Nützel


For the series:

Tested-by: Dieter Nützel 

with glmark2, UH, UV, KDE Plasma5 (my desktop)
R600_DEBUG=sisched,nir
but on radeonsi, Polaris 20 (RX580) not r600 ;-)

GREAT work Gert!

Dieter

Am 26.03.2018 11:27, schrieb Gert Wollny:

Dear all,

this is the merged version of two series [1] (TGSI: split, merge
and interleave arrays) and [2] (mesa/st/glsl_to_tgsi: Properly
resolve life times for simple if/else + use constructs) I sent
earlier. Considering that both parts target the same optimization
step and fix a bug if both are applied, I thought it is better to
add this second patch to the series. Changes refer to v1 of [1]:

v2:
 - rebase patches to latest HEAD
 - add some code that allows obtaining some statistics about register
   and instruction usage
 - Add patch [2] that improves resolving the live range estimation with
   simple if/else and use constructs. By adding this patch the series
   fixes https://bugs.freedesktop.org/show_bug.cgi?id=105371

 v1:
Patch 1: Split arrays that are only accessed directly:
I posted a first version off the the array splitting in patch 1 some
time ago. Eric Anholt pointed out that this might be done in
opt_array_splitting.cpp, but in another comment Timothy pointed out
that this is far from trivial, and he also pointed out that he was
proposing similar patches for NIR, but since currently no NIR->TGSI
transformation is available, TGSI based drivers can't make use of this.

While the reminder off the series could be applied without this patch, 
I
think it makes less sense to do all the optimizations on arrays that 
could
simply be split into individual registers, so I repost the patch with 
some

changes.

I tried to be exhaustive with comments and make the variable any type 
names
self-explaining, but since I've been staring at this code for a long 
time I
don't think I am capable of seeing any problems any more, so comments 
are very

welcome.

Best,
Gert

PS: I have no git write access.


[1] https://patchwork.freedesktop.org/series/37991/
[2] https://patchwork.freedesktop.org/series/39471/

Gert Wollny (11):
  mesa/st: glsl_to_tgsi: Split arrays who's elements are only accessed
directly
  mesa/st/glsl_to_tgsi: rename lifetime to register_live_range
  mesa/st: Add helper classes for array merging and interleaving
  mesa/st/glsl_to_tgsi: Add class to hold array information
  mesa/st/glsl_to_tgsi: Add array merge logic
  mesa/st/tests: Add unit tests for array merge helper classes.
  mesa/st/glsl_to_tgsi: refactor access_record and its use
  mesa/st/glsl_to_tgsi: move evaluation of read mask up in the call
hierarchy
  mesa/st/glsl_to_tgsi: add class for array access tracking
  mesa/st/glsl_to_tgsi: add array life range evaluation into tracking
code
  mesa/st/glsl_to_tgsi: Expose array live range tracking and merging

 src/mesa/Makefile.sources  |   2 +
 src/mesa/meson.build   |   2 +
 src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 144 +++-
 .../state_tracker/st_glsl_to_tgsi_array_merge.cpp  | 735 
+

 .../state_tracker/st_glsl_to_tgsi_array_merge.h| 186 ++
 .../state_tracker/st_glsl_to_tgsi_temprename.cpp   | 290 +---
 .../state_tracker/st_glsl_to_tgsi_temprename.h |  47 +-
 src/mesa/state_tracker/tests/Makefile.am   |  20 +-
 src/mesa/state_tracker/tests/st_tests_common.cpp   |  25 +-
 src/mesa/state_tracker/tests/st_tests_common.h |  20 +-
 .../tests/test_glsl_to_tgsi_array_merge.cpp| 296 +
 .../tests/test_glsl_to_tgsi_lifetime.cpp   |  10 +-
 12 files changed, 1644 insertions(+), 133 deletions(-)
 create mode 100644 
src/mesa/state_tracker/st_glsl_to_tgsi_array_merge.cpp
 create mode 100644 
src/mesa/state_tracker/st_glsl_to_tgsi_array_merge.h

 create mode 100644
src/mesa/state_tracker/tests/test_glsl_to_tgsi_array_merge.cpp

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

Re: [Mesa-dev] VC4 not working for me with mesa 17.3.7

2018-03-30 Thread Andreas Müller

On Fri, Mar 30, 2018 at 4:18 PM, Andreas Müller  wrote:
> Hi,
>
> hope here is the right place for this - my first post.
>
> What happened: I build all images cross with Openembedded/Yocto. To
> prepare next release there I updated my builds and that moved mesa
> 17.1.7 -> 17.3.7. Since then all applications using GL/GLES (e.g
> glmark2-es - tried others - same) complain with
>
> | Modifier 0x0 vs. tiling (0x701) mismatch
>
> and drawable region remains black.
> There was some discussion on meta-raspberrypi mailing list and it
> seems to happen to others too [1].
>
> I've attached a patch. That fixes glmark2-es and many others but e.g
> on KDE desktop mouse pointer is just pixel dust so I think that my
> (naive) approach only works around an issue caused somewhere else. To
> ne honest my background understanding is poor but it seems that
> modifier gets not properly for all cases.
>
> [1] https://lists.yoctoproject.org/pipermail/yocto/2018-March/040587.html
>
> If further information is required, please let me know.
>
Forgot to mention: At wayland/weston glmark-es2-wayland works without
issues without modification. By source update xserver-xorg moved
1.19.3 -> 1.19.6

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

[Mesa-dev] [PATCH kmscube 1/2] Rework default modifier handling

2018-03-30 Thread Emil Velikov

From: Emil Velikov 

Currently the default modifier is MOD_INVALID. At a later stage, if the
modifier is the same (the user may have explicit selected MOD_INVALID),
we'll fallback to MOD_LINEAR.

Simplify things to a) use MOD_LINEAR by default b) use the user modifier
- even if they request MOD_INVALID.

Signed-off-by: Emil Velikov 
---
 common.c  | 23 ++-
 kmscube.c |  2 +-
 2 files changed, 3 insertions(+), 22 deletions(-)

diff --git a/common.c b/common.c
index a092cdb..332e3e9 100644
--- a/common.c
+++ b/common.c
@@ -33,24 +33,13 @@
 
 static struct gbm gbm;
 
-#ifdef HAVE_GBM_MODIFIERS
-static int
-get_modifiers(uint64_t **mods)
-{
-   /* Assumed LINEAR is supported everywhere */
-   static uint64_t modifiers[] = {DRM_FORMAT_MOD_LINEAR};
-   *mods = modifiers;
-   return 1;
-}
-#endif
-
 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;
 
 #ifndef HAVE_GBM_MODIFIERS
-   if (modifier != DRM_FORMAT_MOD_INVALID) {
+   if (modifier != DRM_FORMAT_MOD_LINEAR) {
fprintf(stderr, "Modifiers requested but support isn't 
available\n");
return NULL;
}
@@ -58,16 +47,8 @@ const struct gbm * init_gbm(int drm_fd, int w, int h, 
uint64_t modifier)
gbm.format,
GBM_BO_USE_SCANOUT | GBM_BO_USE_RENDERING);
 #else
-   uint64_t *mods;
-   int count;
-   if (modifier != DRM_FORMAT_MOD_INVALID) {
-   count = 1;
-   mods = 
-   } else {
-   count = get_modifiers();
-   }
gbm.surface = gbm_surface_create_with_modifiers(gbm.dev, w, h,
-   gbm.format, mods, count);
+   gbm.format, , 1);
 #endif
 
if (!gbm.surface) {
diff --git a/kmscube.c b/kmscube.c
index 3a2c4dd..87a4205 100644
--- a/kmscube.c
+++ b/kmscube.c
@@ -76,7 +76,7 @@ int main(int argc, char *argv[])
const char *device = "/dev/dri/card0";
const char *video = NULL;
enum mode mode = SMOOTH;
-   uint64_t modifier = DRM_FORMAT_MOD_INVALID;
+   uint64_t modifier = DRM_FORMAT_MOD_LINEAR;
int atomic = 0;
int opt;
 
-- 
2.16.0

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

[Mesa-dev] [PATCH kmscube 2/2] Use weak functions to handle lack of gbm modifiers

2018-03-30 Thread Emil Velikov

From: Emil Velikov 

Add weak function declaration and check if they're valid prior
to calling the functions.

This allows us to remove conditional compilation, yet allowing the
modifiers codepath to work if API is available.

Cc: Christian Gmeiner 
Cc: Rob Clark 
Signed-off-by: Emil Velikov 
---
 common.c | 32 +---
 common.h |  2 ++
 configure.ac | 16 
 drm-common.c | 49 -
 4 files changed, 55 insertions(+), 44 deletions(-)

diff --git a/common.c b/common.c
index 332e3e9..1d97c91 100644
--- a/common.c
+++ b/common.c
@@ -33,23 +33,33 @@
 
 static struct gbm gbm;
 
+WEAK struct gbm_surface *
+gbm_surface_create_with_modifiers(struct gbm_device *gbm,
+  uint32_t width, uint32_t height,
+  uint32_t format,
+  const uint64_t *modifiers,
+  const unsigned int count);
+
 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;
 
-#ifndef HAVE_GBM_MODIFIERS
-   if (modifier != DRM_FORMAT_MOD_LINEAR) {
-   fprintf(stderr, "Modifiers requested but support isn't 
available\n");
-   return NULL;
+   if (gbm_surface_create_with_modifiers) {
+   gbm.surface = gbm_surface_create_with_modifiers(gbm.dev, w, h,
+   gbm.format,
+   , 1);
+
+   } else {
+   if (modifier != DRM_FORMAT_MOD_LINEAR) {
+   fprintf(stderr, "Modifiers requested but support isn't 
available\n");
+   return NULL;
+   }
+   gbm.surface = gbm_surface_create(gbm.dev, w, h,
+   gbm.format,
+   GBM_BO_USE_SCANOUT | 
GBM_BO_USE_RENDERING);
+
}
-   gbm.surface = gbm_surface_create(gbm.dev, w, h,
-   gbm.format,
-   GBM_BO_USE_SCANOUT | GBM_BO_USE_RENDERING);
-#else
-   gbm.surface = gbm_surface_create_with_modifiers(gbm.dev, w, h,
-   gbm.format, , 1);
-#endif
 
if (!gbm.surface) {
printf("failed to create gbm surface\n");
diff --git a/common.h b/common.h
index dc87825..42eb236 100644
--- a/common.h
+++ b/common.h
@@ -57,6 +57,8 @@ EGLAPI EGLSurface EGLAPIENTRY 
eglCreatePlatformPixmapSurfaceEXT (EGLDisplay dpy,
 #endif
 #endif /* EGL_EXT_platform_base */
 
+#define WEAK __attribute__((weak))
+
 struct gbm {
struct gbm_device *dev;
struct gbm_surface *surface;
diff --git a/configure.ac b/configure.ac
index 8397f7b..5a63afb 100644
--- a/configure.ac
+++ b/configure.ac
@@ -49,21 +49,5 @@ if test "x$HAVE_GST" = "xyes"; then
 fi
 AM_CONDITIONAL(ENABLE_GST, [test "x$HAVE_GST" = "xyes"])
 
-AC_CHECK_LIB([gbm], [gbm_bo_get_modifier], [gbm_modifiers=yes], [])
-
-AC_ARG_ENABLE([gbm-modifiers],
- [AS_HELP_STRING([--enable-gbm-modifiers],
- [enable using GBM modifiers @<:@default=auto@:>@])],
- [enable_gbm_modifiers="$enableval"],
- [enable_gbm_modifiers=auto])
-
-if test "x$enable_gbm_modifiers" = xyes -a "x$gbm_modifiers" != xyes; then
-   AC_MSG_ERROR([Cannot find gbm modifier supported mesa])
-fi
-
-if test "x$enable_gbm_modifiers" = xyes; then
-   AC_DEFINE(HAVE_GBM_MODIFIERS, 1, [Define if you can use GBM 
properties.])
-fi
-
 AC_CONFIG_FILES([Makefile])
 AC_OUTPUT
diff --git a/drm-common.c b/drm-common.c
index 1ec2820..136fe69 100644
--- a/drm-common.c
+++ b/drm-common.c
@@ -31,6 +31,18 @@
 #include "common.h"
 #include "drm-common.h"
 
+WEAK uint64_t
+gbm_bo_get_modifier(struct gbm_bo *bo);
+
+WEAK int
+gbm_bo_get_plane_count(struct gbm_bo *bo);
+
+WEAK uint32_t
+gbm_bo_get_stride_for_plane(struct gbm_bo *bo, int plane);
+
+WEAK uint32_t
+gbm_bo_get_offset(struct gbm_bo *bo, int plane);
+
 static void
 drm_fb_destroy_callback(struct gbm_bo *bo, void *data)
 {
@@ -62,26 +74,29 @@ struct drm_fb * drm_fb_get_from_bo(struct gbm_bo *bo)
height = gbm_bo_get_height(bo);
format = gbm_bo_get_format(bo);
 
-#ifdef HAVE_GBM_MODIFIERS
-   uint64_t modifiers[4] = {0};
-   modifiers[0] = gbm_bo_get_modifier(bo);
-   const int num_planes = gbm_bo_get_plane_count(bo);
-   for (int i = 0; i < num_planes; i++) {
-   strides[i] = gbm_bo_get_stride_for_plane(bo, i);
-   handles[i] = gbm_bo_get_handle(bo).u32;
-   offsets[i] = gbm_bo_get_offset(bo, i);
-   modifiers[i] = modifiers[0];
-   }
+   if (gbm_bo_get_modifier && gbm_bo_get_plane_count &&
+

[Mesa-dev] VC4 not working for me with mesa 17.3.7

2018-03-30 Thread Andreas Müller

Hi,

hope here is the right place for this - my first post.

What happened: I build all images cross with Openembedded/Yocto. To
prepare next release there I updated my builds and that moved mesa
17.1.7 -> 17.3.7. Since then all applications using GL/GLES (e.g
glmark2-es - tried others - same) complain with

| Modifier 0x0 vs. tiling (0x701) mismatch

and drawable region remains black.
There was some discussion on meta-raspberrypi mailing list and it
seems to happen to others too [1].

I've attached a patch. That fixes glmark2-es and many others but e.g
on KDE desktop mouse pointer is just pixel dust so I think that my
(naive) approach only works around an issue caused somewhere else. To
ne honest my background understanding is poor but it seems that
modifier gets not properly for all cases.

[1] https://lists.yoctoproject.org/pipermail/yocto/2018-March/040587.html

If further information is required, please let me know.

Regards

Andreas
From 5012db89d3704d383e455376922bd45f45b5683f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Andreas=20M=C3=BCller?= 
Date: Thu, 29 Mar 2018 22:18:25 +0200
Subject: [PATCH] VC4: Do not error out when linear modifier is requested but
 kernel supports tiling
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Fixes:
| Modifier 0x0 vs. tiling (0x701) mismatch

and black screen for glmark2

Tested withj mesa 17.3.7

Signed-off-by: Andreas Müller 
---
 src/gallium/drivers/vc4/vc4_resource.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/gallium/drivers/vc4/vc4_resource.c b/src/gallium/drivers/vc4/vc4_resource.c
index cdcbcc917e..472e6dd618 100644
--- a/src/gallium/drivers/vc4/vc4_resource.c
+++ b/src/gallium/drivers/vc4/vc4_resource.c
@@ -742,6 +742,9 @@ vc4_resource_from_handle(struct pipe_screen *pscreen,
 whandle->modifier = DRM_FORMAT_MOD_LINEAR;
 } else if (whandle->modifier == DRM_FORMAT_MOD_INVALID) {
 whandle->modifier = get_tiling.modifier;
+} else if (whandle->modifier == DRM_FORMAT_MOD_LINEAR && 
+   get_tiling.modifier == DRM_FORMAT_MOD_BROADCOM_VC4_T_TILED) {
+whandle->modifier = get_tiling.modifier;
 } else if (whandle->modifier != get_tiling.modifier) {
 fprintf(stderr,
 "Modifier 0x%llx vs. tiling (0x%llx) mismatch\n",
-- 
2.14.3

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

[Mesa-dev] Question about NIR changes since mesa 17.3

2018-03-30 Thread Qiang Yu

Hi guys,

I'm rebasing the mesa-lima code from 17.3 to 18.0 and found the NIR changes
in 18.0 will always do nir_lower_io_to_scalar_early() for the output of
vertex
shader and input of fragment shader. My first question is:
Is it for the link time optimization that we can drop un-used channel in a
slot
and merge channels in different slots to one slot if possible?

Mali4xx GPU has different processor for vertex shader (GP) and fragment
shader (PP). Scalar is OK for GP, but PP more like vec ops. So this scalar
change make PP not comfortable. I like the link time optimization, so don't
want to just disable it. My second question is:
Is there any NIR helper that I can use to merge scalar input to vector
again?
Or what's the right way to make the scalar input vector again?

I see master mesa branch will further do nir_lower_alu_to_scalar
for all nir which will get more pain for mali PP, so my third question is:
How other vec GPU solve this problem or anyway to disable it?

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

[Mesa-dev] [Bug 103999] 4x MSAA with RG32F shows garbage on triangle edges

2018-03-30 Thread bugzilla-daemon

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

--- Comment #8 from mais...@archlinux.us ---
Here's a renderdoc 1.0 capture on RX470 for reference:
https://drive.google.com/file/d/1e9zIRVhZxtdA5DodASi3FK75fuRBuqxO/view?usp=sharing

-- 
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] [Bug 103999] 4x MSAA with RG32F shows garbage on triangle edges

2018-03-30 Thread bugzilla-daemon

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

--- Comment #7 from mais...@archlinux.us ---
This seems to work fine now on 17.3.7.

-- 
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] st/mesa: don't draw if the bound element array buffer is not allocated

2018-03-30 Thread Dieter Nützel


Tested-by: Dieter Nützel 

Dieter

Am 21.03.2018 18:41, schrieb Marek Olšák:

From: Marek Olšák 

---
 src/mesa/state_tracker/st_draw.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/src/mesa/state_tracker/st_draw.c 
b/src/mesa/state_tracker/st_draw.c

index b95a2522b2e..73f936bb4a9 100644
--- a/src/mesa/state_tracker/st_draw.c
+++ b/src/mesa/state_tracker/st_draw.c
@@ -166,20 +166,27 @@ st_draw_vbo(struct gl_context *ctx,
   }

   info.index_size = ib->index_size;
   info.min_index = min_index;
   info.max_index = max_index;

   if (_mesa_is_bufferobj(bufobj)) {
  /* indices are in a real VBO */
  info.has_user_indices = false;
  info.index.resource = st_buffer_object(bufobj)->buffer;
+
+ /* Return if the bound element array buffer doesn't have any 
backing

+  * storage. (nothing to do)
+  */
+ if (!info.index.resource)
+return;
+
  start = pointer_to_offset(ib->ptr) / info.index_size;
   } else {
  /* indices are in user space memory */
  info.has_user_indices = true;
  info.index.user = ib->ptr;
   }

   setup_primitive_restart(ctx, );
}
else {

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

Re: [Mesa-dev] [PATCH 0/5] KHR_blend_equation_advanced for RadeonSI

2018-03-30 Thread Dieter Nützel


For the series:

Tested-by: Dieter Nützel 

R600_DEBUG=nofmask
show nice effects together with Anti-aliasing at least x8 on UH and UV

Greetings,
Dieter

Am 23.03.2018 20:35, schrieb Marek Olšák:

Hi,

This is the second and fianl version, and it adds MSAA support and
FBFETCH tests into Gallium.

Please review.

Thanks,
Marek
___
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 103852] Rendering errors when running dolphin-emu with Vulkan backend, radv (Super Smash Bros. Melee)

2018-03-30 Thread bugzilla-daemon

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

--- Comment #7 from Sven Arvidsson  ---
Absolutely file new bugs for each issue. Much easier to close duplicate bugs
than tracking more than one problem in a report (should it turn out be the same
problem in the end).


The freeze issue sounds like a good candidate for git bisect. I might give it a
try if I can reproduce and have the time.

-- 
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] [Bug 105817] scons build broken by glSpecializeShaderARB

2018-03-30 Thread bugzilla-daemon

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

Bug ID: 105817
   Summary: scons build broken by glSpecializeShaderARB
   Product: Mesa
   Version: git
  Hardware: Other
OS: All
Status: ASSIGNED
  Keywords: bisected, regression
  Severity: normal
  Priority: medium
 Component: Mesa core
  Assignee: apinhe...@igalia.com
  Reporter: mark.a.ja...@intel.com
QA Contact: mesa-dev@lists.freedesktop.org
CC: el...@igalia.com, nhaeh...@gmail.com

build/linux-x86_64-debug/mesa/libmesa.a(glspirv.os): In function
`_mesa_SpecializeShaderARB':
mesa/src/mesa/main/glspirv.c:170: undefined reference to `gl_spirv_validation'

Bisected to:
ba975140d3c99b60c63846c3c08bd158f7c95d42 is the first bad commit
commit ba975140d3c99b60c63846c3c08bd158f7c95d42
Author: Nicolai Hähnle 
Date:   Sat Jun 10 21:36:24 2017 +0200
mesa: Implement glSpecializeShaderARB

v2:
  * Use gl_spirv_validation instead of spirv_to_nir.  This method just
validates the shader. The conversion to NIR will happen later,
during linking. (Alejandro Piñeiro)
  * Use gl_shader_spirv_data struct to store the SPIR-V data.
(Eduardo Lima)
  * Use the 'spirv_data' member to tell if the gl_shader is a SPIR-V
shader, instead of a dedicated flag. (Timothy Arceri)

Signed-off-by: Nicolai Hähnle 
Signed-off-by: Alejandro Piñeiro 
Signed-off-by: Eduardo Lima Mitev 

Reviewed-by: Timothy Arceri 

-- 
You are receiving this mail because:
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] ac/nir: Fix include for LLVMAddPromoteMemoryToRegisterPass

2018-03-30 Thread Dieter Nützel


Samuel,

go for it.

Tested-by: Dieter Nützel 

Thanks Mike!

Dieter

Am 30.03.2018 11:32, schrieb Samuel Pitoiset:

With the Fixes tag removed, this is:

Reviewed-by: Samuel Pitoiset 

On 03/30/2018 01:56 AM, Mike Lothian wrote:

Include llvm-c/Transforms/Utils.h with the newest LLVM 7

Fixes: 2dd4f35c7fc llvm-c: Split Utils out of Scalar.h
Signed-of-by: Mike Lothian 

---

I don't have git commit rights

If you're happy with this patch please can you commit it

Cheers

Mike
---
  src/amd/vulkan/radv_nir_to_llvm.c   | 3 +++
  src/gallium/auxiliary/gallivm/lp_bld_init.c | 3 +++
  src/gallium/drivers/radeonsi/si_shader_tgsi_setup.c | 3 +++
  3 files changed, 9 insertions(+)

diff --git a/src/amd/vulkan/radv_nir_to_llvm.c 
b/src/amd/vulkan/radv_nir_to_llvm.c

index c6b4e8b532..2f0864da46 100644
--- a/src/amd/vulkan/radv_nir_to_llvm.c
+++ b/src/amd/vulkan/radv_nir_to_llvm.c
@@ -32,6 +32,9 @@
  #include 
  #include 
  #include 
+#if HAVE_LLVM >= 0x0700
+#include 
+#endif
#include "sid.h"
  #include "gfx9d.h"
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_init.c 
b/src/gallium/auxiliary/gallivm/lp_bld_init.c

index 6ddc509a81..dae9d01552 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_init.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_init.c
@@ -40,6 +40,9 @@
#include 
  #include 
+#if HAVE_LLVM >= 0x0700
+#include 
+#endif
  #include 
diff --git a/src/gallium/drivers/radeonsi/si_shader_tgsi_setup.c 
b/src/gallium/drivers/radeonsi/si_shader_tgsi_setup.c

index 79fdebe838..622fd26950 100644
--- a/src/gallium/drivers/radeonsi/si_shader_tgsi_setup.c
+++ b/src/gallium/drivers/radeonsi/si_shader_tgsi_setup.c
@@ -40,6 +40,9 @@
  #include 
  #include 
  #include 
+#if HAVE_LLVM >= 0x0700
+#include 
+#endif
enum si_llvm_calling_convention {
RADEON_LLVM_AMDGPU_VS = 87,


___
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] ac/nir: Fix include for LLVMAddPromoteMemoryToRegisterPass

2018-03-30 Thread Samuel Pitoiset


With the Fixes tag removed, this is:

Reviewed-by: Samuel Pitoiset 

On 03/30/2018 01:56 AM, Mike Lothian wrote:

Include llvm-c/Transforms/Utils.h with the newest LLVM 7

Fixes: 2dd4f35c7fc llvm-c: Split Utils out of Scalar.h
Signed-of-by: Mike Lothian 

---

I don't have git commit rights

If you're happy with this patch please can you commit it

Cheers

Mike
---
  src/amd/vulkan/radv_nir_to_llvm.c   | 3 +++
  src/gallium/auxiliary/gallivm/lp_bld_init.c | 3 +++
  src/gallium/drivers/radeonsi/si_shader_tgsi_setup.c | 3 +++
  3 files changed, 9 insertions(+)

diff --git a/src/amd/vulkan/radv_nir_to_llvm.c 
b/src/amd/vulkan/radv_nir_to_llvm.c
index c6b4e8b532..2f0864da46 100644
--- a/src/amd/vulkan/radv_nir_to_llvm.c
+++ b/src/amd/vulkan/radv_nir_to_llvm.c
@@ -32,6 +32,9 @@
  #include 
  #include 
  #include 
+#if HAVE_LLVM >= 0x0700
+#include 
+#endif
  
  #include "sid.h"

  #include "gfx9d.h"
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_init.c 
b/src/gallium/auxiliary/gallivm/lp_bld_init.c
index 6ddc509a81..dae9d01552 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_init.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_init.c
@@ -40,6 +40,9 @@
  
  #include 

  #include 
+#if HAVE_LLVM >= 0x0700
+#include 
+#endif
  #include 
  
  
diff --git a/src/gallium/drivers/radeonsi/si_shader_tgsi_setup.c b/src/gallium/drivers/radeonsi/si_shader_tgsi_setup.c

index 79fdebe838..622fd26950 100644
--- a/src/gallium/drivers/radeonsi/si_shader_tgsi_setup.c
+++ b/src/gallium/drivers/radeonsi/si_shader_tgsi_setup.c
@@ -40,6 +40,9 @@
  #include 
  #include 
  #include 
+#if HAVE_LLVM >= 0x0700
+#include 
+#endif
  
  enum si_llvm_calling_convention {

RADEON_LLVM_AMDGPU_VS = 87,


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

Re: [Mesa-dev] [radv] compilation error with 'latest' LLVM (#4e45b963bcd)

2018-03-30 Thread Mike Lothian

I've submitted a patch for this, it was a change in the llvm-c includes

On Fri, 30 Mar 2018 at 08:43 Dieter Nützel  wrote:

> make[4]: Verzeichnis „/opt/mesa/src/amd/vulkan“ wird betreten
>CC   radv_nir_to_llvm.lo
> radv_nir_to_llvm.c: In function ‘ac_llvm_finalize_module’:
> radv_nir_to_llvm.c:2874:2: error: implicit declaration of function
> ‘LLVMAddPromoteMemoryToRegisterPass’; did you mean
> ‘LLVMAddDemoteMemoryToRegisterPass’?
> [-Werror=implicit-function-declaration]
>LLVMAddPromoteMemoryToRegisterPass(passmgr);
>^~
>LLVMAddDemoteMemoryToRegisterPass
> cc1: some warnings being treated as errors
> make[4]: *** [Makefile:983: radv_nir_to_llvm.lo] Fehler 1
>
> Thanks and
> Happy Easter!
>
> Dieter
> ___
> 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 1/5] radeonsi: remove fast color clear for single-sample buffers

2018-03-30 Thread Dieter Nützel


Hello Marek,

2-3 landed.
Is #1 dead after my findings? ;-)

Dieter

Am 11.03.2018 19:11, schrieb Marek Olšák:

From: Marek Olšák 

This should improve the score for the GpuTest Triangle benchmark.
Vulkan doesn't use this either.
---
 src/gallium/drivers/radeon/r600_pipe_common.h |  1 -
 src/gallium/drivers/radeon/r600_texture.c | 11 +---
 src/gallium/drivers/radeonsi/si_clear.c   | 37 
++-

 src/gallium/drivers/radeonsi/si_state.c   |  6 -
 4 files changed, 3 insertions(+), 52 deletions(-)

diff --git a/src/gallium/drivers/radeon/r600_pipe_common.h
b/src/gallium/drivers/radeon/r600_pipe_common.h
index 7941903..9701757 100644
--- a/src/gallium/drivers/radeon/r600_pipe_common.h
+++ b/src/gallium/drivers/radeon/r600_pipe_common.h
@@ -209,21 +209,20 @@ struct r600_cmask_info {
 struct r600_texture {
struct r600_resourceresource;

struct radeon_surf  surface;
uint64_tsize;
struct r600_texture *flushed_depth_texture;

/* Colorbuffer compression and fast clear. */
struct r600_fmask_info  fmask;
struct r600_cmask_info  cmask;
-   struct r600_resource*cmask_buffer;
uint64_tdcc_offset; /* 0 = disabled */
unsignedcb_color_info; /* fast clear enable bit 
*/
unsignedcolor_clear_value[2];
unsignedlast_msaa_resolve_target_micro_mode;
unsignednum_level0_transfers;

/* Depth buffer compression and fast clear. */
uint64_thtile_offset;
float   depth_clear_value;
 	uint16_t			dirty_level_mask; /* each bit says if that mipmap is 
compressed */

diff --git a/src/gallium/drivers/radeon/r600_texture.c
b/src/gallium/drivers/radeon/r600_texture.c
index 125e7ef..03bc955 100644
--- a/src/gallium/drivers/radeon/r600_texture.c
+++ b/src/gallium/drivers/radeon/r600_texture.c
@@ -405,26 +405,22 @@ void si_texture_discard_cmask(struct si_screen 
*sscreen,

 {
if (!rtex->cmask.size)
return;

assert(rtex->resource.b.b.nr_samples <= 1);

/* Disable CMASK. */
memset(>cmask, 0, sizeof(rtex->cmask));
rtex->cmask.base_address_reg = rtex->resource.gpu_address >> 8;
rtex->dirty_level_mask = 0;
-
rtex->cb_color_info &= ~S_028C70_FAST_CLEAR(1);

-   if (rtex->cmask_buffer != >resource)
-   r600_resource_reference(>cmask_buffer, NULL);
-
/* Notify all contexts about the change. */
p_atomic_inc(>dirty_tex_counter);
p_atomic_inc(>compressed_colortex_counter);
 }

 static bool r600_can_disable_dcc(struct r600_texture *rtex)
 {
/* We can't disable DCC if it can be written by another process. */
return rtex->dcc_offset &&
   (!rtex->resource.b.is_shared ||
@@ -813,24 +809,20 @@ static boolean r600_texture_get_handle(struct
pipe_screen* screen,
  slice_size, whandle);
 }

 static void r600_texture_destroy(struct pipe_screen *screen,
 struct pipe_resource *ptex)
 {
struct r600_texture *rtex = (struct r600_texture*)ptex;
struct r600_resource *resource = >resource;

r600_texture_reference(>flushed_depth_texture, NULL);
-
-   if (rtex->cmask_buffer != >resource) {
-   r600_resource_reference(>cmask_buffer, NULL);
-   }
pb_reference(>buf, NULL);
r600_resource_reference(>dcc_separate_buffer, NULL);
r600_resource_reference(>last_dcc_separate_buffer, NULL);
FREE(rtex);
 }

 static const struct u_resource_vtbl r600_texture_vtbl;

 /* The number of samples can be specified independently of the 
texture. */

 void si_texture_get_fmask_info(struct si_screen *sscreen,
@@ -1262,21 +1254,20 @@ r600_texture_create_object(struct pipe_screen 
*screen,

rtex->db_compatible = true;

if (!(sscreen->debug_flags & DBG(NO_HYPERZ)))
r600_texture_allocate_htile(sscreen, rtex);
}
} else {
if (base->nr_samples > 1) {
if (!buf) {
r600_texture_allocate_fmask(sscreen, rtex);
r600_texture_allocate_cmask(sscreen, rtex);
-   rtex->cmask_buffer = >resource;
}
if (!rtex->fmask.size || !rtex->cmask.size) {
FREE(rtex);
return NULL;
}
}

/* Shared textures must always set up DCC here.
 * If it's not present, it will be disabled by
 *

[Mesa-dev] [Bug 103852] Rendering errors when running dolphin-emu with Vulkan backend, radv (Super Smash Bros. Melee)

2018-03-30 Thread bugzilla-daemon

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

--- Comment #6 from Ben Clapp  ---
Bugs still present in 18.0.0.
In addition, there's now a new bug when using the radeonsi driver, where the
game will sometimes freeze altogether (not a complete GPU hang, you can kill
the dolphin-emu process and move on) during normal play that did not occur in
17.3.7.
(Since this is a radeonsi-only issue and not radv, might be worth opening a
separate ticket for.)

There also seems to be a very obvious stuttering issue introduced after the
update to 18.0.0 that doesn't seem present in other 3D applications.
This stuttering is a bit different from the "frame presentation issue" I
described before in that the audio stutters at the same time as the frame
drops, and the FPS actually does drop according to dolphin's FPS indicator.
Given this stuttering was not present with the exact same system/dolphin
build/etc. before updating to mesa 18.0.0, I can only guess there's something
weird going on with the driver here that is causing the stuttering issue.
The stuttering occurs whether you use dolphin's GL or Vulkan backends.

This gets off the topic of the originally reported bug (and perhaps is worth
opening a separate ticket over), but more recently I've found I can
consistently get GPU hangs when playing certain games other than Melee in
dolphin-emu, so it just seems that dolphin is in general using a range of
advanced GL/Vulkan features and mesa is tripping over a number of edge-cases
that aren't used by most Linux applications.

-- 
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 v2] radeonsi/nir: gather buffers declared more accurately and use const fast path

2018-03-30 Thread Timothy Arceri

For now we skip SI && HAVE_LLVM < 0x0600 for simplicity. We also skip
setting the more accurate masks for some builtin uniforms for now as
it causes some piglit regressions.
---
 src/gallium/drivers/radeonsi/si_shader.c |  7 +++
 src/gallium/drivers/radeonsi/si_shader_nir.c | 90 ++--
 2 files changed, 91 insertions(+), 6 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_shader.c 
b/src/gallium/drivers/radeonsi/si_shader.c
index 714415edba7..13b588eb68f 100644
--- a/src/gallium/drivers/radeonsi/si_shader.c
+++ b/src/gallium/drivers/radeonsi/si_shader.c
@@ -2374,8 +2374,15 @@ static LLVMValueRef load_const_buffer_desc(struct 
si_shader_context *ctx, int i)
 static LLVMValueRef load_ubo(struct ac_shader_abi *abi, LLVMValueRef index)
 {
struct si_shader_context *ctx = si_shader_context_from_abi(abi);
+   struct si_shader_selector *sel = ctx->shader->selector;
+
LLVMValueRef ptr = LLVMGetParam(ctx->main_fn, 
ctx->param_const_and_shader_buffers);
 
+   if (sel->info.const_buffers_declared == 1 &&
+   sel->info.shader_buffers_declared == 0) {
+   return load_const_buffer_desc_fast_path(ctx);
+   }
+
index = si_llvm_bound_index(ctx, index, ctx->num_const_buffers);
index = LLVMBuildAdd(ctx->ac.builder, index,
 LLVMConstInt(ctx->i32, SI_NUM_SHADER_BUFFERS, 0), 
"");
diff --git a/src/gallium/drivers/radeonsi/si_shader_nir.c 
b/src/gallium/drivers/radeonsi/si_shader_nir.c
index 437eefc54d0..e116c23815b 100644
--- a/src/gallium/drivers/radeonsi/si_shader_nir.c
+++ b/src/gallium/drivers/radeonsi/si_shader_nir.c
@@ -600,23 +600,98 @@ void si_nir_scan_shader(const struct nir_shader *nir,
 
info->num_outputs = num_outputs;
 
+   struct set *ubo_set = _mesa_set_create(NULL, _mesa_hash_pointer,
+  _mesa_key_pointer_equal);
+
+   unsigned ubo_idx = 1;
nir_foreach_variable(variable, >uniforms) {
const struct glsl_type *type = variable->type;
enum glsl_base_type base_type =
glsl_get_base_type(glsl_without_array(type));
unsigned aoa_size = MAX2(1, glsl_get_aoa_size(type));
 
+   /* Gather buffers declared bitmasks. Note: radeonsi doesn't
+* really use the mask (other than ubo_idx == 1 for regular
+* uniforms) its really only used for getting the buffer count
+* so we don't need to worry about the ordering.
+*/
+   if (variable->interface_type != NULL) {
+   if (variable->data.mode == nir_var_uniform) {
+
+   unsigned block_count;
+   if (base_type != GLSL_TYPE_INTERFACE) {
+   struct set_entry *entry =
+   _mesa_set_search(ubo_set, 
variable->interface_type);
+
+   /* Check if we have already processed
+* a member from this ubo.
+*/
+   if (entry)
+   continue;
+
+   block_count = 1;
+   } else {
+   block_count = aoa_size;
+   }
+
+   info->const_buffers_declared |= 
u_bit_consecutive(ubo_idx, block_count);
+   ubo_idx += block_count;
+
+   _mesa_set_add(ubo_set, 
variable->interface_type);
+   }
+
+   if (variable->data.mode == nir_var_shader_storage) {
+   /* TODO: make this more accurate */
+   info->shader_buffers_declared =
+   u_bit_consecutive(0, 
SI_NUM_SHADER_BUFFERS);
+   }
+
+   continue;
+   }
+
/* We rely on the fact that nir_lower_samplers_as_deref has
 * eliminated struct dereferences.
 */
-   if (base_type == GLSL_TYPE_SAMPLER)
+   if (base_type == GLSL_TYPE_SAMPLER) {
info->samplers_declared |=
u_bit_consecutive(variable->data.binding, 
aoa_size);
-   else if (base_type == GLSL_TYPE_IMAGE)
+
+   if (variable->data.bindless) {
+   info->const_buffers_declared |= 1;
+   info->const_file_max[0] +=
+   glsl_count_attribute_slots(type, false);
+   }
+   } else if (base_type == GLSL_TYPE_IMAGE) {
info->images_declared |=

[Mesa-dev] [radv] compilation error with 'latest' LLVM (#4e45b963bcd)

2018-03-30 Thread Dieter Nützel


make[4]: Verzeichnis „/opt/mesa/src/amd/vulkan“ wird betreten
  CC   radv_nir_to_llvm.lo
radv_nir_to_llvm.c: In function ‘ac_llvm_finalize_module’:
radv_nir_to_llvm.c:2874:2: error: implicit declaration of function 
‘LLVMAddPromoteMemoryToRegisterPass’; did you mean 
‘LLVMAddDemoteMemoryToRegisterPass’? 
[-Werror=implicit-function-declaration]

  LLVMAddPromoteMemoryToRegisterPass(passmgr);
  ^~
  LLVMAddDemoteMemoryToRegisterPass
cc1: some warnings being treated as errors
make[4]: *** [Makefile:983: radv_nir_to_llvm.lo] Fehler 1

Thanks and
Happy Easter!

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

Re: [Mesa-dev] [PATCH v4] i965: initialize SPIR-V capabilities

2018-03-30 Thread Alejandro Piñeiro



On 29/03/18 16:59, Jason Ekstrand wrote:
> On March 29, 2018 02:45:36 Alejandro Piñeiro 
> wrote:
>
> Needed for ARB_gl_spirv. Those are not the same that the Intel vulkan
> driver. From the ARB_spirv_extensions spec:
>
> "3. If a new GL extension is added that includes SPIR-V support via
> a new SPIR-V extension does it's SPIR-V extension also get
> enumerated by the SPIR_V_EXTENSIONS_ARB query?.
>
> RESOLVED. Yes. It's good to include it for consistency. Any SPIR-V
> functionality supported beyond the SPIR-V version that is required
> for the GL API version should be enumerated."
>
> So in addition to the core SPIR-V support, there is the possibility of
> specific GL extensions enabling specific SPIR-V extensions (so
> capabilities). That would mean that it is possible that OpenGL and
> Vulkan not having the same capabilities supported, even for the same
> driver. For this reason it is better to keep them separated.
>
> As an example: at the time of this patch writing Intel vulkan driver
> support multiview, but there isn't any OpenGL multiview GL extension
> supported.
>
> Note: we initialize SPIR-V capabilities at brwCreateContext instead of
> the usual brw_initialize_context_constants because we want to do that
> only if the extension is enabled.
>
> v2:
> * Rebase update (SpirVCapabilities not a pointer anymore)
> * Fill spirv capabilities for OpenGL >= 3.3 (Ian Romanick)
>
> v3:
> * Drop multiview support, as i965 doesn't support any multiview GL
> extension (Jason)
> * Fill spirv capabilities only if the extension is enabled (Jason)
> ---
>
> Minor tweak after last rebase against master.
>
>
> src/mesa/drivers/dri/i965/brw_context.c | 19 +++
> 1 file changed, 19 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_context.c
> b/src/mesa/drivers/dri/i965/brw_context.c
> index fca5c8e3072..11bd68ae61e 100644
> --- a/src/mesa/drivers/dri/i965/brw_context.c
> +++ b/src/mesa/drivers/dri/i965/brw_context.c
> @@ -78,6 +78,7 @@
>
> #include "common/gen_defines.h"
>
> +#include "compiler/spirv/nir_spirv.h"
> /***
> * Mesa's Driver Functions
> ***/
> @@ -343,6 +344,20 @@ brw_init_driver_functions(struct brw_context *brw,
> brw_deserialize_program_binary;
> }
>
> +static void
> +brw_initialize_spirv_supported_capabilities(struct brw_context *brw)
> +{
> +   const struct gen_device_info *devinfo = >screen->devinfo;
> +   struct gl_context *ctx = >ctx;
> +
>
> Not all of this is supported on all hardware so I assume this
> extension is gen7+ only.

Yes, the patch that will enable the extension for i965 will do that only
for gen7+

> If so, please add a comment 

Ok.

> it an assert to that effect and you'd patch will be

Ok.

>
> Reviewed-by: Jason Ekstrand 

Thanks!

>
>
> +   ctx->Const.SpirVCapabilities.float64 = devinfo->gen >= 8;
> +   ctx->Const.SpirVCapabilities.int64 = devinfo->gen >= 8;
> +   ctx->Const.SpirVCapabilities.tessellation = true;
> +   ctx->Const.SpirVCapabilities.draw_parameters = true;
> +   ctx->Const.SpirVCapabilities.image_write_without_format = true;
> +   ctx->Const.SpirVCapabilities.variable_pointers = true;
> +}
> +
> static void
> brw_initialize_context_constants(struct brw_context *brw)
> {
> @@ -1063,6 +1078,10 @@ brwCreateContext(gl_api api,
> _mesa_override_extensions(ctx);
> _mesa_compute_version(ctx);
>
> +   /* GL_ARB_gl_spirv */
> +   if (ctx->Extensions.ARB_gl_spirv)
> +  brw_initialize_spirv_supported_capabilities(brw);
> +
> _mesa_initialize_dispatch_tables(ctx);
> _mesa_initialize_vbo_vtxfmt(ctx);
>
> -- 
> 2.14.1
>
>
>
>


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

[Mesa-dev] [Bug 105613] Compute shader locks up within nested "for" loop

2018-03-30 Thread bugzilla-daemon

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

soredake  changed:

   What|Removed |Added

 CC||fds...@krutt.org

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

90 matches

Mail list logo