[Mesa-dev] [PATCH 3/4] mesa: Allow relax various desktop-only checks for cube arrays

2016-05-30 Thread Chris Forbes
Signed-off-by: Chris Forbes 
---
 src/mesa/main/get.c  | 2 +-
 src/mesa/main/get_hash_params.py | 6 +++---
 src/mesa/main/teximage.c | 3 ++-
 src/mesa/main/texobj.c   | 2 +-
 src/mesa/main/texparam.c | 3 ++-
 src/mesa/main/texstorage.c   | 3 ++-
 6 files changed, 11 insertions(+), 8 deletions(-)

diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c
index 9f70749..4f46572 100644
--- a/src/mesa/main/get.c
+++ b/src/mesa/main/get.c
@@ -1914,7 +1914,7 @@ tex_binding_to_index(const struct gl_context *ctx, GLenum 
binding)
   _mesa_has_OES_texture_buffer(ctx)) ?
  TEXTURE_BUFFER_INDEX : -1;
case GL_TEXTURE_BINDING_CUBE_MAP_ARRAY:
-  return _mesa_is_desktop_gl(ctx) && 
ctx->Extensions.ARB_texture_cube_map_array
+  return ctx->Extensions.ARB_texture_cube_map_array
  ? TEXTURE_CUBE_ARRAY_INDEX : -1;
case GL_TEXTURE_BINDING_2D_MULTISAMPLE:
   return _mesa_is_desktop_gl(ctx) && 
ctx->Extensions.ARB_texture_multisample
diff --git a/src/mesa/main/get_hash_params.py b/src/mesa/main/get_hash_params.py
index 2124072..7193296 100644
--- a/src/mesa/main/get_hash_params.py
+++ b/src/mesa/main/get_hash_params.py
@@ -458,6 +458,9 @@ descriptor=[
   [ "MIN_PROGRAM_TEXTURE_GATHER_OFFSET", 
"CONTEXT_INT(Const.MinProgramTextureGatherOffset), extra_ARB_texture_gather"],
   [ "MAX_PROGRAM_TEXTURE_GATHER_OFFSET", 
"CONTEXT_INT(Const.MaxProgramTextureGatherOffset), extra_ARB_texture_gather"],
 
+# GL_ARB_texture_cube_map_array / ES3.1 with GL_OES_texture_cube_map_array
+  [ "TEXTURE_BINDING_CUBE_MAP_ARRAY_ARB", "LOC_CUSTOM, TYPE_INT, 
TEXTURE_CUBE_ARRAY_INDEX, extra_ARB_texture_cube_map_array" ],
+
 # GL_ARB_compute_shader / GLES 3.1
   [ "MAX_COMPUTE_WORK_GROUP_INVOCATIONS", 
"CONTEXT_INT(Const.MaxComputeWorkGroupInvocations), 
extra_ARB_compute_shader_es31" ],
   [ "MAX_COMPUTE_UNIFORM_BLOCKS", 
"CONTEXT_INT(Const.Program[MESA_SHADER_COMPUTE].MaxUniformBlocks), 
extra_ARB_compute_shader_es31" ],
@@ -851,9 +854,6 @@ descriptor=[
 # GL_ARB_map_buffer_alignment
   [ "MIN_MAP_BUFFER_ALIGNMENT", "CONTEXT_INT(Const.MinMapBufferAlignment), 
NO_EXTRA" ],
 
-# GL_ARB_texture_cube_map_array
-  [ "TEXTURE_BINDING_CUBE_MAP_ARRAY_ARB", "LOC_CUSTOM, TYPE_INT, 
TEXTURE_CUBE_ARRAY_INDEX, extra_ARB_texture_cube_map_array" ],
-
 # GL_ARB_texture_gather
   [ "MAX_PROGRAM_TEXTURE_GATHER_COMPONENTS_ARB", 
"CONTEXT_INT(Const.MaxProgramTextureGatherComponents), 
extra_ARB_texture_gather"],
 
diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index 58b7f27..bfe0b18 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -1474,8 +1474,9 @@ legal_teximage_target(struct gl_context *ctx, GLuint 
dims, GLenum target)
   case GL_PROXY_TEXTURE_2D_ARRAY_EXT:
  return _mesa_is_desktop_gl(ctx) && ctx->Extensions.EXT_texture_array;
   case GL_TEXTURE_CUBE_MAP_ARRAY:
-  case GL_PROXY_TEXTURE_CUBE_MAP_ARRAY:
  return ctx->Extensions.ARB_texture_cube_map_array;
+  case GL_PROXY_TEXTURE_CUBE_MAP_ARRAY:
+ return _mesa_is_desktop_gl(ctx) && 
ctx->Extensions.ARB_texture_cube_map_array;
   default:
  return GL_FALSE;
   }
diff --git a/src/mesa/main/texobj.c b/src/mesa/main/texobj.c
index ed630bd..2e9d9e3 100644
--- a/src/mesa/main/texobj.c
+++ b/src/mesa/main/texobj.c
@@ -1579,7 +1579,7 @@ _mesa_tex_target_to_index(const struct gl_context *ctx, 
GLenum target)
   return _mesa_is_gles(ctx) && ctx->Extensions.OES_EGL_image_external
  ? TEXTURE_EXTERNAL_INDEX : -1;
case GL_TEXTURE_CUBE_MAP_ARRAY:
-  return _mesa_is_desktop_gl(ctx) && 
ctx->Extensions.ARB_texture_cube_map_array
+  return ctx->Extensions.ARB_texture_cube_map_array
  ? TEXTURE_CUBE_ARRAY_INDEX : -1;
case GL_TEXTURE_2D_MULTISAMPLE:
   return ((_mesa_is_desktop_gl(ctx) && 
ctx->Extensions.ARB_texture_multisample) ||
diff --git a/src/mesa/main/texparam.c b/src/mesa/main/texparam.c
index ba83f8f..d701b87 100644
--- a/src/mesa/main/texparam.c
+++ b/src/mesa/main/texparam.c
@@ -1243,6 +1243,8 @@ _mesa_legal_get_tex_level_parameter_target(struct 
gl_context *ctx, GLenum target
*/
   return (ctx->API == API_OPENGL_CORE && ctx->Version >= 31) ||
  _mesa_has_OES_texture_buffer(ctx);
+   case GL_TEXTURE_CUBE_MAP_ARRAY_ARB:
+  return ctx->Extensions.ARB_texture_cube_map_array;
}
 
if (!_mesa_is_desktop_gl(ctx))
@@ -1257,7 +1259,6 @@ _mesa_legal_get_tex_level_parameter_target(struct 
gl_context *ctx, GLenum target
   return GL_TRUE;
case GL_PROXY_TEXTURE_CUBE_MAP:
   return ctx->Extensions.ARB_texture_cube_map;
-   case GL_TEXTURE_CUBE_MAP_ARRAY_ARB:
case GL_PROXY_TEXTURE_CUBE_MAP_ARRAY_ARB:
   return ctx->Extensions.ARB_texture_cube_map_array;
case GL_TEXTURE_RECTANGLE_NV:
diff --git a/src/mesa/main/texstorage.c b/src/mesa/main/texstorage.c
index f4a0760..46869bb 100644
--- a/src/mesa/main/texstorage.c
+++ 

[Mesa-dev] [PATCH 4/4] docs: Note that OES_texture_cube_map_array is done.

2016-05-30 Thread Chris Forbes
Signed-off-by: Chris Forbes 
---
 docs/GL3.txt  | 2 +-
 docs/relnotes/12.1.0.html | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/docs/GL3.txt b/docs/GL3.txt
index e8d401d..eeaed52 100644
--- a/docs/GL3.txt
+++ b/docs/GL3.txt
@@ -269,7 +269,7 @@ GLES3.2, GLSL ES 3.2
   GL_OES_tessellation_shaderstarted (Ken)
   GL_OES_texture_border_clamp   DONE (all drivers)
   GL_OES_texture_buffer DONE (i965, nvc0, 
radeonsi)
-  GL_OES_texture_cube_map_array not started (based on 
GL_ARB_texture_cube_map_array, which is done for all drivers)
+  GL_OES_texture_cube_map_array DONE (all drivers that 
support GL_ARB_texture_cube_map_array)
   GL_OES_texture_stencil8   DONE (all drivers that 
support GL_ARB_texture_stencil8)
   GL_OES_texture_storage_multisample_2d_array   DONE (all drivers that 
support GL_ARB_texture_multisample)
 
diff --git a/docs/relnotes/12.1.0.html b/docs/relnotes/12.1.0.html
index 50eee17..3cb0f41 100644
--- a/docs/relnotes/12.1.0.html
+++ b/docs/relnotes/12.1.0.html
@@ -44,7 +44,7 @@ Note: some of the new features are only available with 
certain drivers.
 
 
 
-TBD
+   GL_OES_texture_cube_map_array on all drivers that support ES3.1 and 
ARB_texture_cube_map_array
 
 
 Bug fixes
-- 
2.8.3

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


[Mesa-dev] [PATCH 2/4] glsl: Add support for cube arrays in ES.

2016-05-30 Thread Chris Forbes
Signed-off-by: Chris Forbes 
---
 src/compiler/glsl/builtin_functions.cpp | 12 
 src/compiler/glsl/builtin_types.cpp | 23 ---
 src/compiler/glsl/glsl_lexer.ll | 14 +++---
 3 files changed, 31 insertions(+), 18 deletions(-)

diff --git a/src/compiler/glsl/builtin_functions.cpp 
b/src/compiler/glsl/builtin_functions.cpp
index edd02bb..46c8150 100644
--- a/src/compiler/glsl/builtin_functions.cpp
+++ b/src/compiler/glsl/builtin_functions.cpp
@@ -327,15 +327,19 @@ static bool
 fs_texture_cube_map_array(const _mesa_glsl_parse_state *state)
 {
return state->stage == MESA_SHADER_FRAGMENT &&
-  (state->is_version(400, 0) ||
-   state->ARB_texture_cube_map_array_enable);
+  (state->is_version(400, 320) ||
+   state->ARB_texture_cube_map_array_enable ||
+   state->EXT_texture_cube_map_array_enable ||
+   state->OES_texture_cube_map_array_enable);
 }
 
 static bool
 texture_cube_map_array(const _mesa_glsl_parse_state *state)
 {
-   return state->is_version(400, 0) ||
-  state->ARB_texture_cube_map_array_enable;
+   return state->is_version(400, 320) ||
+  state->ARB_texture_cube_map_array_enable ||
+  state->EXT_texture_cube_map_array_enable ||
+  state->OES_texture_cube_map_array_enable;
 }
 
 static bool
diff --git a/src/compiler/glsl/builtin_types.cpp 
b/src/compiler/glsl/builtin_types.cpp
index 5f208f8..2d1dc03 100644
--- a/src/compiler/glsl/builtin_types.cpp
+++ b/src/compiler/glsl/builtin_types.cpp
@@ -189,7 +189,7 @@ static const struct builtin_type_versions {
T(isamplerCube,130, 300)
T(isampler1DArray, 130, 999)
T(isampler2DArray, 130, 300)
-   T(isamplerCubeArray,   400, 999)
+   T(isamplerCubeArray,   400, 320)
T(isampler2DRect,  140, 999)
T(isamplerBuffer,  140, 320)
T(isampler2DMS,150, 310)
@@ -201,7 +201,7 @@ static const struct builtin_type_versions {
T(usamplerCube,130, 300)
T(usampler1DArray, 130, 999)
T(usampler2DArray, 130, 300)
-   T(usamplerCubeArray,   400, 999)
+   T(usamplerCubeArray,   400, 320)
T(usampler2DRect,  140, 999)
T(usamplerBuffer,  140, 320)
T(usampler2DMS,150, 310)
@@ -212,7 +212,7 @@ static const struct builtin_type_versions {
T(samplerCubeShadow,   130, 300)
T(sampler1DArrayShadow,130, 999)
T(sampler2DArrayShadow,130, 300)
-   T(samplerCubeArrayShadow,  400, 999)
+   T(samplerCubeArrayShadow,  400, 320)
T(sampler2DRectShadow, 140, 999)
 
T(struct_gl_DepthRangeParameters,  110, 100)
@@ -225,7 +225,7 @@ static const struct builtin_type_versions {
T(imageBuffer, 420, 320)
T(image1DArray,420, 999)
T(image2DArray,420, 310)
-   T(imageCubeArray,  420, 999)
+   T(imageCubeArray,  420, 320)
T(image2DMS,   420, 999)
T(image2DMSArray,  420, 999)
T(iimage1D,420, 999)
@@ -236,7 +236,7 @@ static const struct builtin_type_versions {
T(iimageBuffer,420, 320)
T(iimage1DArray,   420, 999)
T(iimage2DArray,   420, 310)
-   T(iimageCubeArray, 420, 999)
+   T(iimageCubeArray, 420, 320)
T(iimage2DMS,  420, 999)
T(iimage2DMSArray, 420, 999)
T(uimage1D,420, 999)
@@ -247,7 +247,7 @@ static const struct builtin_type_versions {
T(uimageBuffer,420, 320)
T(uimage1DArray,   420, 999)
T(uimage2DArray,   420, 310)
-   T(uimageCubeArray, 420, 999)
+   T(uimageCubeArray, 420, 320)
T(uimage2DMS,  420, 999)
T(uimage2DMSArray, 420, 999)
 
@@ -298,13 +298,22 @@ _mesa_glsl_initialize_types(struct _mesa_glsl_parse_state 
*state)
 * by the version-based loop, but attempting to add them a second time
 * is harmless.
 */
-   if (state->ARB_texture_cube_map_array_enable) {
+   if (state->ARB_texture_cube_map_array_enable ||
+   state->EXT_texture_cube_map_array_enable ||
+   state->OES_texture_cube_map_array_enable) {
   add_type(symbols, glsl_type::samplerCubeArray_type);
   add_type(symbols, glsl_type::samplerCubeArrayShadow_type);
   add_type(symbols, glsl_type::isamplerCubeArray_type);
   add_type(symbols, glsl_type::usamplerCubeArray_type);
}
 
+   if (state->EXT_texture_cube_map_array_enable ||
+   state->OES_texture_cube_map_array_enable) {
+  

[Mesa-dev] [PATCH 1/4] mesa: Add scaffolding for OES_texture_cube_map_array

2016-05-30 Thread Chris Forbes
This is the same as ARB_texture_cube_map_array plus some image
interactions.

Signed-off-by: Chris Forbes 
---
 src/compiler/glsl/glcpp/glcpp-parse.y|  5 -
 src/compiler/glsl/glsl_parser_extras.cpp |  2 ++
 src/compiler/glsl/glsl_parser_extras.h   |  4 
 src/mapi/glapi/gen/es_EXT.xml| 24 
 src/mesa/main/extensions_table.h |  2 ++
 5 files changed, 36 insertions(+), 1 deletion(-)

diff --git a/src/compiler/glsl/glcpp/glcpp-parse.y 
b/src/compiler/glsl/glcpp/glcpp-parse.y
index 4022727..ffc309a 100644
--- a/src/compiler/glsl/glcpp/glcpp-parse.y
+++ b/src/compiler/glsl/glcpp/glcpp-parse.y
@@ -2329,7 +2329,10 @@ _glcpp_parser_handle_version_declaration(glcpp_parser_t 
*parser, intmax_t versio
add_builtin_define(parser, "GL_EXT_texture_buffer", 1);
add_builtin_define(parser, "GL_OES_texture_buffer", 1);
 }
-
+if (extensions->ARB_texture_cube_map_array) {
+   add_builtin_define(parser, "GL_EXT_texture_cube_map_array", 1);
+   add_builtin_define(parser, "GL_OES_texture_cube_map_array", 1);
+}
 if (extensions->OES_shader_io_blocks) {
add_builtin_define(parser, "GL_EXT_shader_io_blocks", 1);
add_builtin_define(parser, "GL_OES_shader_io_blocks", 1);
diff --git a/src/compiler/glsl/glsl_parser_extras.cpp 
b/src/compiler/glsl/glsl_parser_extras.cpp
index 843998d..96c021a 100644
--- a/src/compiler/glsl/glsl_parser_extras.cpp
+++ b/src/compiler/glsl/glsl_parser_extras.cpp
@@ -631,6 +631,7 @@ static const _mesa_glsl_extension 
_mesa_glsl_supported_extensions[] = {
EXT(OES_standard_derivatives,   false, true,  
OES_standard_derivatives),
EXT(OES_texture_3D, false, true,  dummy_true),
EXT(OES_texture_buffer, false, true,  OES_texture_buffer),
+   EXT(OES_texture_cube_map_array, false, true,  
ARB_texture_cube_map_array),
EXT(OES_texture_storage_multisample_2d_array, false, true, 
ARB_texture_multisample),
 
/* All other extensions go here, sorted alphabetically.
@@ -650,6 +651,7 @@ static const _mesa_glsl_extension 
_mesa_glsl_supported_extensions[] = {
EXT(EXT_shader_samples_identical,   true,  true,  
EXT_shader_samples_identical),
EXT(EXT_texture_array,  true,  false, EXT_texture_array),
EXT(EXT_texture_buffer, false, true,  OES_texture_buffer),
+   EXT(EXT_texture_cube_map_array, false, true,  
ARB_texture_cube_map_array),
 };
 
 #undef EXT
diff --git a/src/compiler/glsl/glsl_parser_extras.h 
b/src/compiler/glsl/glsl_parser_extras.h
index a0c1903..eee949e 100644
--- a/src/compiler/glsl/glsl_parser_extras.h
+++ b/src/compiler/glsl/glsl_parser_extras.h
@@ -643,6 +643,8 @@ struct _mesa_glsl_parse_state {
bool OES_texture_3D_warn;
bool OES_texture_buffer_enable;
bool OES_texture_buffer_warn;
+   bool OES_texture_cube_map_array_enable;
+   bool OES_texture_cube_map_array_warn;
bool OES_texture_storage_multisample_2d_array_enable;
bool OES_texture_storage_multisample_2d_array_warn;
 
@@ -678,6 +680,8 @@ struct _mesa_glsl_parse_state {
bool EXT_texture_array_warn;
bool EXT_texture_buffer_enable;
bool EXT_texture_buffer_warn;
+   bool EXT_texture_cube_map_array_enable;
+   bool EXT_texture_cube_map_array_warn;
/*@}*/
 
/** Extensions supported by the OpenGL implementation. */
diff --git a/src/mapi/glapi/gen/es_EXT.xml b/src/mapi/glapi/gen/es_EXT.xml
index 6886dab..b21e85a 100644
--- a/src/mapi/glapi/gen/es_EXT.xml
+++ b/src/mapi/glapi/gen/es_EXT.xml
@@ -924,6 +924,18 @@
 
 
 
+
+
+
+
+
+
+
+
+
+
+
+
 http://www.w3.org/2001/XInclude"/>
 
 
@@ -1297,4 +1309,16 @@
 
 
 
+
+
+
+
+
+
+
+
+
+
+
+
 
diff --git a/src/mesa/main/extensions_table.h b/src/mesa/main/extensions_table.h
index b715f7c..be1aeb9 100644
--- a/src/mesa/main/extensions_table.h
+++ b/src/mesa/main/extensions_table.h
@@ -243,6 +243,7 @@ EXT(EXT_texture_compression_latc, 
EXT_texture_compression_latc
 EXT(EXT_texture_compression_rgtc, ARB_texture_compression_rgtc 
  , GLL, GLC,  x ,  x , 2004)
 EXT(EXT_texture_compression_s3tc, EXT_texture_compression_s3tc 
  , GLL, GLC,  x ,  x , 2000)
 EXT(EXT_texture_cube_map, ARB_texture_cube_map 
  , GLL,  x ,  x ,  x , 2001)
+EXT(EXT_texture_cube_map_array  , ARB_texture_cube_map_array   
  ,  x,   x ,  x ,  31, 2014)
 EXT(EXT_texture_edge_clamp  , dummy_true   
  , GLL,  x ,  x ,  x , 1997)
 EXT(EXT_texture_env_add , dummy_true   
  , GLL,  x ,  x ,  x , 1999)
 EXT(EXT_texture_env_combine , dummy_true   
  , GLL,  x ,  x ,  x , 2000)
@@ -360,6 +361,7 

Re: [Mesa-dev] [Mesa-stable] [PATCH] glx: fix crash with bad fbconfig

2016-05-30 Thread Tapani Pälli



On 05/31/2016 07:44 AM, Tapani Pälli wrote:

Hi;

On 05/30/2016 04:48 PM, Emil Velikov wrote:

Hi gents,

On 30 May 2016 at 10:13, Tapani Pälli  wrote:

From: Daniel Czarnowski 

GLX documentation states:
glXCreateNewContext can generate the following errors: (...)
GLXBadFBConfig if config is not a valid GLXFBConfig

Function checks if the given config is a valid config and sets proper
error code.

Fixes currently crashing glx-fbconfig-bad Piglit test.

Signed-off-by: Matt Roper 
Signed-off-by: Tapani Pälli 
Cc: "11.2" 
---
 src/glx/glxcmds.c | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/src/glx/glxcmds.c b/src/glx/glxcmds.c
index bff01d2..4bc7fc4 100644
--- a/src/glx/glxcmds.c
+++ b/src/glx/glxcmds.c
@@ -1629,8 +1629,35 @@ _X_EXPORT GLXContext
 glXCreateNewContext(Display * dpy, GLXFBConfig fbconfig,
 int renderType, GLXContext shareList, Bool
allowDirect)
 {
+   int list_size;
struct glx_config *config = (struct glx_config *) fbconfig;

+   if (!config)
+   {

Existing coding style is to put the opening bracket trailing on the
previous line. Same goes for the rest of the patch.


oops, it seems I did not pay enough attention to style with this patch,
got also some comments from Topi offline, will fix these, thanks Emil!


+   __glXSendError(dpy, GLXBadFBConfig, 0, X_GLXCreateNewContext,
false);
+   return NULL;
+   }
+
+   int screen = XDefaultScreen(dpy);

Use the DefaultScreen macro instead ?


+   struct glx_config **config_list = (struct glx_config **)
+  glXGetFBConfigs(dpy, screen, _size);
+

Worth checking (& bail) that list_size is negative ?


forgot to address this ...

glXGetFBConfigs may return NULL, however list_size is always at least 0 
so the current flow should be OK, in this case we will hit the error 
check where i == list_size.






+   int i;

unsigned i...


+   for (i = 0; i < list_size; i++)

... and cast list_size to unsigned ?


+   {
+   if (config_list[i] == config)
+   {
+   break;
+   }
+   }

Coding style: drop the brackets if there's only a single nested
statement. I.e. the above two pairs can go.


+   free(config_list);
+
+   if (i == list_size)
+   {
+   __glXSendError(dpy, GLXBadFBConfig, 0, X_GLXCreateNewContext,
false);
+   return NULL;
+   }
+


In general, please don't mix variable declarations and code.

Thanks
Emil


___
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/3] mesa: add scaffolding for OES/EXT_primitive_bounding_box

2016-05-30 Thread Ilia Mirkin
[re-adding mesa-dev]

Thanks for the review, Chris!

On Tue, May 31, 2016 at 12:48 AM, Chris Forbes  wrote:
> Oh, I accidentally dropped the list at the start. Feel free to copy the list
> on this whole discussion.
>
> - Chris
>
> On Tue, May 31, 2016 at 4:47 PM, Ilia Mirkin  wrote:
>>
>> Thanks! Did you mean to send this privately, or accidentally dropped the
>> list?
>>
>> On Tue, May 31, 2016 at 12:27 AM, Chris Forbes  wrote:
>> > With those changes, this patch is
>> >
>> > Reviewed-by: Chris Forbes 
>> >
>> > On Tue, May 31, 2016 at 3:44 PM, Ilia Mirkin 
>> > wrote:
>> >>
>> >> Indeed.
>> >>
>> >> https://github.com/imirkin/mesa/commit/1cec6e84afb6f921cbe3ab0d3068ea27d143cad6
>> >>
>> >> On Mon, May 30, 2016 at 8:36 PM, Chris Forbes  wrote:
>> >> > One more: you probably want to adjust version.c:539 as well.
>> >> >
>> >> > On Tue, May 31, 2016 at 10:42 AM, Ilia Mirkin 
>> >> > wrote:
>> >> >>
>> >> >> Gr, I always forget the glcpp-parse.y ones. Thanks for pointing that
>> >> >> out.
>> >> >>
>> >> >> As for standalone_scaffolding.cpp - I don't know what that's used
>> >> >> for,
>> >> >> so I tend to leave it alone when adding new things.
>> >> >>
>> >> >> On Mon, May 30, 2016 at 6:41 PM, Chris Forbes 
>> >> >> wrote:
>> >> >> > This seems to be missing hunks in glcpp-parse.y (to add the
>> >> >> > define)
>> >> >> > and
>> >> >> > in
>> >> >> > standalone_scaffolding.cpp (if you want to enable it there)
>> >> >> >
>> >> >> > On Tue, May 31, 2016 at 6:00 AM, Ilia Mirkin
>> >> >> > 
>> >> >> > wrote:
>> >> >> >>
>> >> >> >> Signed-off-by: Ilia Mirkin 
>> >> >> >> ---
>> >> >> >>  src/compiler/glsl/glsl_parser_extras.cpp |  2 ++
>> >> >> >>  src/compiler/glsl/glsl_parser_extras.h   |  4 +++
>> >> >> >>  src/mapi/glapi/gen/es_EXT.xml| 49
>> >> >> >> 
>> >> >> >>  src/mapi/glapi/gen/gl_genexec.py |  1 +
>> >> >> >>  src/mesa/Makefile.sources|  2 ++
>> >> >> >>  src/mesa/main/bbox.c | 44
>> >> >> >> 
>> >> >> >>  src/mesa/main/bbox.h | 42
>> >> >> >> +++
>> >> >> >>  src/mesa/main/context.c  |  2 ++
>> >> >> >>  src/mesa/main/extensions_table.h |  2 ++
>> >> >> >>  src/mesa/main/mtypes.h   |  1 +
>> >> >> >>  10 files changed, 149 insertions(+)
>> >> >> >>  create mode 100644 src/mesa/main/bbox.c
>> >> >> >>  create mode 100644 src/mesa/main/bbox.h
>> >> >> >>
>> >> >> >> diff --git a/src/compiler/glsl/glsl_parser_extras.cpp
>> >> >> >> b/src/compiler/glsl/glsl_parser_extras.cpp
>> >> >> >> index fc73a7e..7b2a150 100644
>> >> >> >> --- a/src/compiler/glsl/glsl_parser_extras.cpp
>> >> >> >> +++ b/src/compiler/glsl/glsl_parser_extras.cpp
>> >> >> >> @@ -625,6 +625,7 @@ static const _mesa_glsl_extension
>> >> >> >> _mesa_glsl_supported_extensions[] = {
>> >> >> >> EXT(OES_geometry_point_size,false, true,
>> >> >> >> OES_geometry_shader),
>> >> >> >> EXT(OES_geometry_shader,false, true,
>> >> >> >> OES_geometry_shader),
>> >> >> >> EXT(OES_gpu_shader5,false, true,
>> >> >> >> ARB_gpu_shader5),
>> >> >> >> +   EXT(OES_primitive_bounding_box, false, true,
>> >> >> >> OES_primitive_bounding_box),
>> >> >> >> EXT(OES_sample_variables,   false, true,
>> >> >> >> OES_sample_variables),
>> >> >> >> EXT(OES_shader_image_atomic,false, true,
>> >> >> >> ARB_shader_image_load_store),
>> >> >> >> EXT(OES_shader_io_blocks,   false, true,
>> >> >> >> OES_shader_io_blocks),
>> >> >> >> @@ -645,6 +646,7 @@ static const _mesa_glsl_extension
>> >> >> >> _mesa_glsl_supported_extensions[] = {
>> >> >> >> EXT(EXT_draw_buffers,   false,  true,
>> >> >> >> dummy_true),
>> >> >> >> EXT(EXT_clip_cull_distance, false, true,
>> >> >> >> ARB_cull_distance),
>> >> >> >> EXT(EXT_gpu_shader5,false, true,
>> >> >> >> ARB_gpu_shader5),
>> >> >> >> +   EXT(EXT_primitive_bounding_box, false, true,
>> >> >> >> OES_primitive_bounding_box),
>> >> >> >> EXT(EXT_separate_shader_objects,false, true,
>> >> >> >> dummy_true),
>> >> >> >> EXT(EXT_shader_integer_mix, true,  true,
>> >> >> >> EXT_shader_integer_mix),
>> >> >> >> EXT(EXT_shader_io_blocks,   false, true,
>> >> >> >> OES_shader_io_blocks),
>> >> >> >> diff --git a/src/compiler/glsl/glsl_parser_extras.h
>> >> >> >> b/src/compiler/glsl/glsl_parser_extras.h
>> >> >> >> index 8c43292..622a809 100644
>> >> >> >> --- a/src/compiler/glsl/glsl_parser_extras.h
>> >> >> >> +++ b/src/compiler/glsl/glsl_parser_extras.h
>> >> >> >> @@ -631,6 +631,8 @@ struct _mesa_glsl_parse_state {
>> >> >> >> bool OES_geometry_shader_warn;
>> >> 

Re: [Mesa-dev] [Mesa-stable] [PATCH] glx: fix crash with bad fbconfig

2016-05-30 Thread Tapani Pälli

Hi;

On 05/30/2016 04:48 PM, Emil Velikov wrote:

Hi gents,

On 30 May 2016 at 10:13, Tapani Pälli  wrote:

From: Daniel Czarnowski 

GLX documentation states:
glXCreateNewContext can generate the following errors: (...)
GLXBadFBConfig if config is not a valid GLXFBConfig

Function checks if the given config is a valid config and sets proper
error code.

Fixes currently crashing glx-fbconfig-bad Piglit test.

Signed-off-by: Matt Roper 
Signed-off-by: Tapani Pälli 
Cc: "11.2" 
---
 src/glx/glxcmds.c | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/src/glx/glxcmds.c b/src/glx/glxcmds.c
index bff01d2..4bc7fc4 100644
--- a/src/glx/glxcmds.c
+++ b/src/glx/glxcmds.c
@@ -1629,8 +1629,35 @@ _X_EXPORT GLXContext
 glXCreateNewContext(Display * dpy, GLXFBConfig fbconfig,
 int renderType, GLXContext shareList, Bool allowDirect)
 {
+   int list_size;
struct glx_config *config = (struct glx_config *) fbconfig;

+   if (!config)
+   {

Existing coding style is to put the opening bracket trailing on the
previous line. Same goes for the rest of the patch.


oops, it seems I did not pay enough attention to style with this patch, 
got also some comments from Topi offline, will fix these, thanks Emil!



+   __glXSendError(dpy, GLXBadFBConfig, 0, X_GLXCreateNewContext, false);
+   return NULL;
+   }
+
+   int screen = XDefaultScreen(dpy);

Use the DefaultScreen macro instead ?


+   struct glx_config **config_list = (struct glx_config **)
+  glXGetFBConfigs(dpy, screen, _size);
+

Worth checking (& bail) that list_size is negative ?


+   int i;

unsigned i...


+   for (i = 0; i < list_size; i++)

... and cast list_size to unsigned ?


+   {
+   if (config_list[i] == config)
+   {
+   break;
+   }
+   }

Coding style: drop the brackets if there's only a single nested
statement. I.e. the above two pairs can go.


+   free(config_list);
+
+   if (i == list_size)
+   {
+   __glXSendError(dpy, GLXBadFBConfig, 0, X_GLXCreateNewContext, false);
+   return NULL;
+   }
+


In general, please don't mix variable declarations and code.

Thanks
Emil


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


Re: [Mesa-dev] [PATCH] glsl/linker: fix multiple streams transform feedback.

2016-05-30 Thread Timothy Arceri
On Tue, 2016-05-31 at 12:54 +1000, Dave Airlie wrote:
> From: Dave Airlie 
> 
> e2791b38b42f83add5b07298c39741bf0a6d7d4b
> mesa/program_interface_query: fix transform feedback varyings.
> 
> caused a regression in
> GL45-
> CTS.gtf40.GL3Tests.transform_feedback3.transform_feedback3_multiple_s
> treams
> on radeonsi.
> 
> The problem was it was using the skip components varying to set
> the stream id, when it should wait until a varying was written,
> this just adds the varying checks in the right place.
> 
> Cc: "12.0" 
> Signed-off-by: Dave Airlie 

Makes sense to me.

Reviewed-by: Timothy Arceri 

> ---
>  src/compiler/glsl/link_varyings.cpp | 32 +
> ---
>  1 file changed, 17 insertions(+), 15 deletions(-)
> 
> diff --git a/src/compiler/glsl/link_varyings.cpp
> b/src/compiler/glsl/link_varyings.cpp
> index 34c8906..91a82f5 100644
> --- a/src/compiler/glsl/link_varyings.cpp
> +++ b/src/compiler/glsl/link_varyings.cpp
> @@ -1094,21 +1094,23 @@ store_tfeedback_info(struct gl_context *ctx,
> struct gl_shader_program *prog,
>  num_buffers++;
>  buffer_stream_id = -1;
>  continue;
> - } else if (buffer_stream_id == -1)  {
> -/* First varying writing to this buffer: remember its
> stream */
> -buffer_stream_id = (int)
> tfeedback_decls[i].get_stream_id();
> - } else if (buffer_stream_id !=
> -(int) tfeedback_decls[i].get_stream_id()) {
> -/* Varying writes to the same buffer from a different
> stream */
> -linker_error(prog,
> - "Transform feedback can't capture varyings
> belonging "
> - "to different vertex streams in a single
> buffer. "
> - "Varying %s writes to buffer from stream
> %u, other "
> - "varyings in the same buffer write from
> stream %u.",
> - tfeedback_decls[i].name(),
> - tfeedback_decls[i].get_stream_id(),
> - buffer_stream_id);
> -return false;
> + } else if (tfeedback_decls[i].is_varying()) {
> +if (buffer_stream_id == -1)  {
> +   /* First varying writing to this buffer: remember its
> stream */
> +   buffer_stream_id = (int)
> tfeedback_decls[i].get_stream_id();
> +} else if (buffer_stream_id !=
> +   (int) tfeedback_decls[i].get_stream_id()) {
> +   /* Varying writes to the same buffer from a different
> stream */
> +   linker_error(prog,
> +"Transform feedback can't capture
> varyings belonging "
> +"to different vertex streams in a single
> buffer. "
> +"Varying %s writes to buffer from stream
> %u, other "
> +"varyings in the same buffer write from
> stream %u.",
> +tfeedback_decls[i].name(),
> +tfeedback_decls[i].get_stream_id(),
> +buffer_stream_id);
> +   return false;
> +}
>   }
>  
>   if (has_xfb_qualifiers) {
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 2/2] nv50/ir: fix error finding free element in bitset in some situations

2016-05-30 Thread Ilia Mirkin
This really only hits for bitsets with a size of a multiple of 32. We
can end up with pos = -1 as a result of the ffs, which we in turn decide
is a valid position (since we fall through the loop and i == 1, we end
up adding 32 to it, so end up returning 31 again).

Up until recently this was largely unreachable, as the register file
sizes were all 63 or 255. However with the advent of compute shaders
which can restrict the number of registers, this can now happen.

Signed-off-by: Ilia Mirkin 
Cc: "12.0" 
---
 src/gallium/drivers/nouveau/codegen/nv50_ir_util.cpp | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_util.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_util.cpp
index d26acb3..682c569 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_util.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_util.cpp
@@ -365,6 +365,12 @@ int BitSet::findFreeRange(unsigned int count) const
  }
   }
}
+
+   // If we couldn't find a position, we can have a left-over -1 in pos. Make
+   // sure to abort in such a case.
+   if (pos < 0)
+  return -1;
+
pos += i * 32;
 
return ((pos + count) <= size) ? pos : -1;
-- 
2.7.3

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


[Mesa-dev] [PATCH 1/2] nv50/ir: print relevant file's bitset when showing RA info

2016-05-30 Thread Ilia Mirkin
Signed-off-by: Ilia Mirkin 
---
 src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp
index 6b52d7b..5bb6f78 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp
@@ -101,7 +101,7 @@ public:
   return (size < 4) ? u : ((u << unit[f]) / 4);
}
 
-   void print() const;
+   void print(DataFile f) const;
 
const bool restrictedGPR16Range;
 
@@ -156,10 +156,10 @@ RegisterSet::intersect(DataFile f, const RegisterSet *set)
 }
 
 void
-RegisterSet::print() const
+RegisterSet::print(DataFile f) const
 {
INFO("GPR:");
-   bits[FILE_GPR].print();
+   bits[f].print();
INFO("\n");
 }
 
@@ -1424,7 +1424,7 @@ GCRA::selectRegisters()
  continue;
   LValue *lval = node->getValue();
   if (prog->dbgFlags & NV50_IR_DEBUG_REG_ALLOC)
- regs.print();
+ regs.print(node->f);
   bool ret = regs.assign(node->reg, node->f, node->colors);
   if (ret) {
  INFO_DBG(prog->dbgFlags, REG_ALLOC, "assigned reg %i\n", node->reg);
-- 
2.7.3

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


[Mesa-dev] [Bug 95374] ARK:survival of the fittest fails when GL4.3 is enabled.

2016-05-30 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=95374

--- Comment #3 from Shawn Starr  ---
Copying the GLSL 150 shader cache to the missing file reveals the game crashes
unable to find the shader.

[spstarr@segfault Engine]$ cp GlobalShaderCache-GLSL_150.bin
GlobalShaderCache-GLSL_430.bin 
[spstarr@segfault Linux]$ ./ShooterGame 
Using binned.
4.5.1-0+UE4 7038 3077 402 5
Setting breakpad minidump AppID = 346110
Steam_SetMinidumpSteamID:  Caching Steam ID:  76561198199507765 [API loaded no]
LowLevelFatalError
[File:C:\SVN_Ark\Engine\Source\Runtime\Engine\Private\GlobalShader.cpp] [Line:
204] 
Missing global shader TFilterVS<32>, Please make sure cooking was successful.

-- 
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] radeonsi: lower SQRT to RSQ+RCP to fix the game Risen

2016-05-30 Thread Roland Scheidegger
Not sure if it's a good idea trying to fix wine bugs via driver hacks?

Roland

Am 31.05.2016 um 01:19 schrieb Marek Olšák:
> From: Marek Olšák 
> 
> Sadly, I haven't been able to find any other way to fix the bug
> for radeonsi. The game seems to expect DX9 behavior.
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94627
> (against nouveau)
> ---
>  .../drivers/radeon/radeon_setup_tgsi_llvm.c| 22 
> --
>  1 file changed, 20 insertions(+), 2 deletions(-)
> 
> diff --git a/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c 
> b/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
> index 74b36ec..c84c850 100644
> --- a/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
> +++ b/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
> @@ -1522,6 +1522,25 @@ static void emit_up2h(const struct 
> lp_build_tgsi_action *action,
>   }
>  }
>  
> +static void emit_sqrt(const struct lp_build_tgsi_action *action,
> +   struct lp_build_tgsi_context * bld_base,
> +   struct lp_build_emit_data * emit_data)
> +{
> + LLVMBuilderRef builder = bld_base->base.gallivm->builder;
> + LLVMValueRef arg = emit_data->args[0];
> +
> + /* The game "Risen" renders correctly only if RSQ + RCP is used to
> +  * implement SQRT.
> +  */
> + arg = lp_build_intrinsic(builder, "llvm.AMDGPU.rsq.f32",
> +  emit_data->dst_type, , 1,
> +  LLVMReadNoneAttribute);
> +
> + arg = LLVMBuildFDiv(builder, bld_base->base.one, arg, "");
> + emit_data->output[emit_data->chan] = arg;
> + return;
> +}
> +
>  void radeon_llvm_context_init(struct radeon_llvm_context * ctx, const char 
> *triple)
>  {
>   struct lp_type type;
> @@ -1671,8 +1690,7 @@ void radeon_llvm_context_init(struct 
> radeon_llvm_context * ctx, const char *trip
>   bld_base->op_actions[TGSI_OPCODE_SGT].emit = emit_set_cond;
>   bld_base->op_actions[TGSI_OPCODE_SIN].emit = build_tgsi_intrinsic_nomem;
>   bld_base->op_actions[TGSI_OPCODE_SIN].intr_name = "llvm.sin.f32";
> - bld_base->op_actions[TGSI_OPCODE_SQRT].emit = 
> build_tgsi_intrinsic_nomem;
> - bld_base->op_actions[TGSI_OPCODE_SQRT].intr_name = "llvm.sqrt.f32";
> + bld_base->op_actions[TGSI_OPCODE_SQRT].emit = emit_sqrt;
>   bld_base->op_actions[TGSI_OPCODE_SSG].emit = emit_ssg;
>   bld_base->op_actions[TGSI_OPCODE_TRUNC].emit = 
> build_tgsi_intrinsic_nomem;
>   bld_base->op_actions[TGSI_OPCODE_TRUNC].intr_name = "llvm.trunc.f32";
> 

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


[Mesa-dev] [PATCH] swr: [rasterizer common] avoid divison by zero

2016-05-30 Thread Eric Engestrom
Signed-off-by: Eric Engestrom 
---
 src/gallium/drivers/swr/rasterizer/common/rdtsc_buckets.cpp | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/src/gallium/drivers/swr/rasterizer/common/rdtsc_buckets.cpp 
b/src/gallium/drivers/swr/rasterizer/common/rdtsc_buckets.cpp
index 412182f..2b82967 100644
--- a/src/gallium/drivers/swr/rasterizer/common/rdtsc_buckets.cpp
+++ b/src/gallium/drivers/swr/rasterizer/common/rdtsc_buckets.cpp
@@ -107,10 +107,18 @@ void BucketManager::PrintBucket(FILE* f, UINT level, 
uint64_t threadCycles, uint
 };
 
 // compute percent of total cycles used by this bucket
-float percentTotal = (float)((double)bucket.elapsed / (double)threadCycles 
* 100.0);
+float percentTotal = 0;
+if (threadCycles)
+{
+percentTotal = (float)((double)bucket.elapsed / (double)threadCycles * 
100.0);
+}
 
 // compute percent of parent cycles used by this bucket
-float percentParent = (float)((double)bucket.elapsed / 
(double)parentCycles * 100.0);
+float percentParent = 0;
+if (parentCycles)
+{
+percentParent = (float)((double)bucket.elapsed / (double)parentCycles 
* 100.0);
+}
 
 // compute average cycle count per invocation
 uint64_t CPE = bucket.elapsed / bucket.count;
-- 
2.8.3

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


[Mesa-dev] [PATCH] st/va: restore old buffer format on error

2016-05-30 Thread Eric Engestrom
CoverityID: 1337953

Signed-off-by: Eric Engestrom 
---

Note that I do not know this code at all; I'm blindly following Coverity's 
advice on this one :]

---
 src/gallium/state_trackers/va/image.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/gallium/state_trackers/va/image.c 
b/src/gallium/state_trackers/va/image.c
index 92d014c..8cfe17a 100644
--- a/src/gallium/state_trackers/va/image.c
+++ b/src/gallium/state_trackers/va/image.c
@@ -490,6 +490,7 @@ vlVaPutImage(VADriverContextP ctx, VASurfaceID surface, 
VAImageID image,
 
views = surf->buffer->get_sampler_view_planes(surf->buffer);
if (!views) {
+  surf->templat.buffer_format = old_surf_format;
   pipe_mutex_unlock(drv->mutex);
   return VA_STATUS_ERROR_OPERATION_FAILED;
}
-- 
2.8.3

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


[Mesa-dev] [PATCH] target/d3dadapter9: make sure strings are null-terminated

2016-05-30 Thread Eric Engestrom
From strncpy's man page:
  Warning: If there is no null byte among the first n bytes of src, the
  string placed in dest will not be  null-terminated.

CoverityID: 1320457, 1320458, 1255671

Signed-off-by: Eric Engestrom 
---
 src/gallium/targets/d3dadapter9/description.c | 39 ++-
 src/gallium/targets/d3dadapter9/drm.c |  6 +++--
 2 files changed, 30 insertions(+), 15 deletions(-)

diff --git a/src/gallium/targets/d3dadapter9/description.c 
b/src/gallium/targets/d3dadapter9/description.c
index c0a8678..5d4e767 100644
--- a/src/gallium/targets/d3dadapter9/description.c
+++ b/src/gallium/targets/d3dadapter9/description.c
@@ -239,7 +239,8 @@ d3d_match_vendor_id( D3DADAPTER_IDENTIFIER9* drvid,
 DBG("unknown vendor 0x4%x, emulating 0x4%x\n", drvid->VendorId, 
fallback_ven);
 drvid->VendorId = fallback_ven;
 drvid->DeviceId = fallback_dev;
-strncpy(drvid->Description, fallback_name, sizeof(drvid->Description));
+strncpy(drvid->Description, fallback_name, sizeof(drvid->Description) - 1);
+drvid->Description[sizeof(drvid->Description) - 1] = 0;
 }
 
 /* fill in driver name and version */
@@ -248,22 +249,26 @@ void d3d_fill_driver_version(D3DADAPTER_IDENTIFIER9* 
drvid) {
 case HW_VENDOR_INTEL:
 drvid->DriverVersionLowPart = 0x000A0682;
 drvid->DriverVersionHighPart = 0x0006000F;
-strncpy(drvid->Driver, "igdumd32.dll", sizeof(drvid->Driver));
+strncpy(drvid->Driver, "igdumd32.dll", sizeof(drvid->Driver) - 1);
+drvid->Driver[sizeof(drvid->Driver) - 1] = 0;
 break;
 case HW_VENDOR_VMWARE:
 drvid->DriverVersionLowPart = 0x0001046E;
 drvid->DriverVersionHighPart = 0x0006000E;
-strncpy(drvid->Driver, "vm3dum.dll", sizeof(drvid->Driver));
+strncpy(drvid->Driver, "vm3dum.dll", sizeof(drvid->Driver) - 1);
+drvid->Driver[sizeof(drvid->Driver) - 1] = 0;
 break;
 case HW_VENDOR_AMD:
 drvid->DriverVersionLowPart = 0x000A0500;
 drvid->DriverVersionHighPart = 0x00060011;
-strncpy(drvid->Driver, "atiumdag.dll", sizeof(drvid->Driver));
+strncpy(drvid->Driver, "atiumdag.dll", sizeof(drvid->Driver) - 1);
+drvid->Driver[sizeof(drvid->Driver) - 1] = 0;
 break;
 case HW_VENDOR_NVIDIA:
 drvid->DriverVersionLowPart = 0x000D0FD4;
 drvid->DriverVersionHighPart = 0x00060012;
-strncpy(drvid->Driver, "nvd3dum.dll", sizeof(drvid->Driver));
+strncpy(drvid->Driver, "nvd3dum.dll", sizeof(drvid->Driver) - 1);
+drvid->Driver[sizeof(drvid->Driver) - 1] = 0;
 break;
 default:
 break;
@@ -277,46 +282,54 @@ void d3d_fill_cardname(D3DADAPTER_IDENTIFIER9* drvid) {
 case HW_VENDOR_INTEL:
 for (i = 0; i < sizeof(cards_intel) / sizeof(cards_intel[0]); i++) {
 if (strstr(drvid->Description, cards_intel[i].mesaname)) {
-strncpy(drvid->Description, cards_intel[i].d3d9name, 
sizeof(drvid->Description));
+strncpy(drvid->Description, cards_intel[i].d3d9name, 
sizeof(drvid->Description) - 1);
+drvid->Description[sizeof(drvid->Description) - 1] = 0;
 return;
 }
 }
 /* use a fall-back if nothing matches */
 DBG("Unknown card name %s!\n", drvid->DeviceName);
-strncpy(drvid->Description, cards_intel[0].d3d9name, 
sizeof(drvid->Description));
+strncpy(drvid->Description, cards_intel[0].d3d9name, 
sizeof(drvid->Description) - 1);
+drvid->Description[sizeof(drvid->Description) - 1] = 0;
 break;
 case HW_VENDOR_VMWARE:
 for (i = 0; i < sizeof(cards_vmware) / sizeof(cards_vmware[0]); i++) {
 if (strstr(drvid->Description, cards_vmware[i].mesaname)) {
-strncpy(drvid->Description, cards_vmware[i].d3d9name, 
sizeof(drvid->Description));
+strncpy(drvid->Description, cards_vmware[i].d3d9name, 
sizeof(drvid->Description) - 1);
+drvid->Description[sizeof(drvid->Description) - 1] = 0;
 return;
 }
 }
 /* use a fall-back if nothing matches */
 DBG("Unknown card name %s!\n", drvid->DeviceName);
-strncpy(drvid->Description, cards_vmware[0].d3d9name, 
sizeof(drvid->Description));
+strncpy(drvid->Description, cards_vmware[0].d3d9name, 
sizeof(drvid->Description) - 1);
+drvid->Description[sizeof(drvid->Description) - 1] = 0;
 break;
 case HW_VENDOR_AMD:
 for (i = 0; i < sizeof(cards_amd) / sizeof(cards_amd[0]); i++) {
 if (strstr(drvid->Description, cards_amd[i].mesaname)) {
-strncpy(drvid->Description, cards_amd[i].d3d9name, 
sizeof(drvid->Description));
+strncpy(drvid->Description, cards_amd[i].d3d9name, 
sizeof(drvid->Description) - 1);
+drvid->Description[sizeof(drvid->Description) - 1] = 0;
 return;
 

[Mesa-dev] [PATCH] st/glsl_to_tgsi: prevent infinite loop

2016-05-30 Thread Eric Engestrom
`unsigned j` would never fail `j >= 0`, leading to an infinite loop as
`j--` wraps around.

Signed-off-by: Eric Engestrom 
---
 src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp 
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index 423704c..3440407 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
@@ -2447,7 +2447,8 @@ shrink_array_declarations(struct array_decl *arrays, 
unsigned count,
   GLbitfield64 double_usage_mask,
   GLbitfield patch_usage_mask)
 {
-   unsigned i, j;
+   unsigned i;
+   int j;
 
/* Fix array declarations by removing unused array elements at both ends
 * of the arrays. For example, mat4[3] where only mat[1] is used.
-- 
2.8.3

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


[Mesa-dev] [PATCH] .gitignore: Ignore tags generated by `make tags`

2016-05-30 Thread Eric Engestrom
Signed-off-by: Eric Engestrom 
---
 .gitignore | 1 +
 1 file changed, 1 insertion(+)

diff --git a/.gitignore b/.gitignore
index 7db5639..d3f3589 100644
--- a/.gitignore
+++ b/.gitignore
@@ -48,3 +48,4 @@ Makefile
 Makefile.in
 .install-mesa-links
 .install-gallium-links
+TAGS
-- 
2.8.3

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


[Mesa-dev] [PATCH] glsl: Remove tautological check

2016-05-30 Thread Eric Engestrom
`size_t offset` can never be `< 0`

Signed-off-by: Eric Engestrom 
---
 src/compiler/glsl/blob.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/compiler/glsl/blob.c b/src/compiler/glsl/blob.c
index dd4341b..ef17255 100644
--- a/src/compiler/glsl/blob.c
+++ b/src/compiler/glsl/blob.c
@@ -107,7 +107,7 @@ blob_overwrite_bytes(struct blob *blob,
  size_t to_write)
 {
/* Detect an attempt to overwrite data out of bounds. */
-   if (offset < 0 || blob->size - offset < to_write)
+   if (blob->size - offset < to_write)
   return false;
 
memcpy(blob->data + offset, bytes, to_write);
-- 
2.8.3

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


[Mesa-dev] [PATCH] st/osmesa: remove double-write (overwriting)

2016-05-30 Thread Eric Engestrom
These two lines have been here since the file was created.
I'm guessing the second one was just for testing during dev, so it's the
one that's going away.

CoverityID: 1296205

Signed-off-by: Eric Engestrom 
---

This should probably be tested by someone who knows what they're doing :]

---
 src/gallium/state_trackers/osmesa/osmesa.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/src/gallium/state_trackers/osmesa/osmesa.c 
b/src/gallium/state_trackers/osmesa/osmesa.c
index 1071507..18f1b88 100644
--- a/src/gallium/state_trackers/osmesa/osmesa.c
+++ b/src/gallium/state_trackers/osmesa/osmesa.c
@@ -877,7 +877,6 @@ OSMesaGetIntegerv(GLint pname, GLint *value)
  int maxLevels = screen->get_param(screen,
PIPE_CAP_MAX_TEXTURE_2D_LEVELS);
  *value = 1 << (maxLevels - 1);
- *value = 8 * 1024;
   }
   return;
default:
-- 
2.8.3

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


[Mesa-dev] [PATCH] anv: limit string copy to target buffer size

2016-05-30 Thread Eric Engestrom
CoverityID: 1358935

Signed-off-by: Eric Engestrom 
---
 src/intel/vulkan/anv_device.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index 046777d..e451138 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -566,7 +566,8 @@ void anv_GetPhysicalDeviceProperties(
   .sparseProperties = {0}, /* Broadwell doesn't do sparse. */
};
 
-   strcpy(pProperties->deviceName, pdevice->name);
+   strncpy(pProperties->deviceName, pdevice->name, 
sizeof(pProperties->deviceName) - 1);
+   pProperties->deviceName[sizeof(pProperties->deviceName) - 1] = 0;
anv_device_get_cache_uuid(pProperties->pipelineCacheUUID);
 }
 
-- 
2.8.3

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


[Mesa-dev] [PATCH] glsl/linker: fix multiple streams transform feedback.

2016-05-30 Thread Dave Airlie
From: Dave Airlie 

e2791b38b42f83add5b07298c39741bf0a6d7d4b
mesa/program_interface_query: fix transform feedback varyings.

caused a regression in
GL45-CTS.gtf40.GL3Tests.transform_feedback3.transform_feedback3_multiple_streams
on radeonsi.

The problem was it was using the skip components varying to set
the stream id, when it should wait until a varying was written,
this just adds the varying checks in the right place.

Cc: "12.0" 
Signed-off-by: Dave Airlie 
---
 src/compiler/glsl/link_varyings.cpp | 32 +---
 1 file changed, 17 insertions(+), 15 deletions(-)

diff --git a/src/compiler/glsl/link_varyings.cpp 
b/src/compiler/glsl/link_varyings.cpp
index 34c8906..91a82f5 100644
--- a/src/compiler/glsl/link_varyings.cpp
+++ b/src/compiler/glsl/link_varyings.cpp
@@ -1094,21 +1094,23 @@ store_tfeedback_info(struct gl_context *ctx, struct 
gl_shader_program *prog,
 num_buffers++;
 buffer_stream_id = -1;
 continue;
- } else if (buffer_stream_id == -1)  {
-/* First varying writing to this buffer: remember its stream */
-buffer_stream_id = (int) tfeedback_decls[i].get_stream_id();
- } else if (buffer_stream_id !=
-(int) tfeedback_decls[i].get_stream_id()) {
-/* Varying writes to the same buffer from a different stream */
-linker_error(prog,
- "Transform feedback can't capture varyings belonging "
- "to different vertex streams in a single buffer. "
- "Varying %s writes to buffer from stream %u, other "
- "varyings in the same buffer write from stream %u.",
- tfeedback_decls[i].name(),
- tfeedback_decls[i].get_stream_id(),
- buffer_stream_id);
-return false;
+ } else if (tfeedback_decls[i].is_varying()) {
+if (buffer_stream_id == -1)  {
+   /* First varying writing to this buffer: remember its stream */
+   buffer_stream_id = (int) tfeedback_decls[i].get_stream_id();
+} else if (buffer_stream_id !=
+   (int) tfeedback_decls[i].get_stream_id()) {
+   /* Varying writes to the same buffer from a different stream */
+   linker_error(prog,
+"Transform feedback can't capture varyings 
belonging "
+"to different vertex streams in a single buffer. "
+"Varying %s writes to buffer from stream %u, other 
"
+"varyings in the same buffer write from stream 
%u.",
+tfeedback_decls[i].name(),
+tfeedback_decls[i].get_stream_id(),
+buffer_stream_id);
+   return false;
+}
  }
 
  if (has_xfb_qualifiers) {
-- 
2.5.5

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


Re: [Mesa-dev] [PATCH 0/2] fix load of unpacked double vector input varyings

2016-05-30 Thread Timothy Arceri
On Mon, 2016-05-30 at 15:46 +0200, Samuel Iglesias Gonsálvez wrote:
> 
> On 27/05/16 08:39, Samuel Iglesias Gonsálvez wrote:
> > 
> > 
> > 
> > On 26/05/16 09:46, Timothy Arceri wrote:
> > > 
> > > On Thu, 2016-05-26 at 17:44 +1000, Timothy Arceri wrote:
> > > > 
> > > > On Thu, 2016-05-26 at 07:56 +0200, Samuel Iglesias Gonsálvez
> > > > wrote:
> > > > > 
> > > > > 
> > > > > Hello,
> > > > > 
> > > > > Timothy found that tests with unpacked double vector input
> > > > > varyings
> > > > > were failing in i965 driver. For example, this is happening
> > > > > when
> > > > > using explicit locations because Mesa disables varying
> > > > > packing for
> > > > > that case.
> > > > > 
> > > > > These patches fix the following piglit test:
> > > > > 
> > > > > spec/arb_gpu_shader_fp64/execution/vs-fs-explicit-locations
> > > > > 
> > > > > Samuel Iglesias Gonsálvez (2):
> > > > >   i965/fs: fix offset when loading double vector input
> > > > > varyings
> > > > >   i965/fs: fix FS_OPCODE_CINTERP for unpacked double input
> > > > > varyings
> > > > > 
> > > > >  src/mesa/drivers/dri/i965/brw_fs.cpp | 13 -
> > > > >  src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 22
> > > > > +-
> > > > >  2 files changed, 33 insertions(+), 2 deletions(-)
> > > > > 
> > > > These are both:
> > > > 
> > > > Tested-by: Timothy Arceri 
> > > > 
> > > > The logic looks ok to me also, but you probably want someone
> > > > more familiar with the backend to take a quick look also.
> > > Forgot to ask. Did you also check the other stages work as
> > > expected
> > > with explicit locations?
> > > 
> > I did not check them. I am going to do it know and send patches if
> > needed.
> > 
> I needed to fix Geometry shaders too. I have sent a patch for it.
> 
> Sam

Thanks Sam. Can you also send a piglit test since there are no test
suites that seem to currently test this.

Thanks,
Tim

> 
> > 
> > Thanks,
> > 
> > Sam
> > 
> ___
> 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 0/3] r600g removal of unnecessary cache flushes

2016-05-30 Thread Grazvydas Ignotas
On Tue, May 31, 2016 at 2:58 AM, Grazvydas Ignotas  wrote:
> I've patched the CS validator and there seem to be some regressions:
>
> arb_map_buffer_range 11/11 5/11
> copybuffersubdata decrement-offset
> copybuffersubdata increment-offset
> copybuffersubdata offset=0
> map_invalidate_range_bit decrement-offset
> map_invalidate_range_bit increment-offset
> map_invalidate_range_bit offset=0
> arb_texture_buffer_object 77/78 76/78
> subdata-sync
> arb_vertex_buffer_object 16/16 13/16
> vbo-subdata-many drawarrays
> vbo-subdata-many drawelements
> vbo-subdata-many drawrangeelements
>
> The "good" run was done on newer git master than what your
> r600-opt-flushes branch is based on, don't know if it has any effect.
> Should I attempt to bisect?

9cb1646 "r600g: only do necessary cache flushes in cp_dma_copy_buffer"
seems to be the bad one.

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


[Mesa-dev] Set of 2 patches to fix building errors with kitkat-x86

2016-05-30 Thread Mauro Rossi
Hello there,

the following two patches are proposed to avoid building errors
on kitkat-x86 in order to enhance compatibility.

Please consider that these patches are applicable to both 
mesa-dev and mesa-stable, please pardon me if I may have just caused
double posting on mesa-stable.

[PATCH 1/2] android: fix building error in st_glsl_to_tgsi
[PATCH 2/2] egl: use CLOCK_MONOTONIC only when available
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 2/2] egl: use CLOCK_MONOTONIC only when available

2016-05-30 Thread Mauro Rossi
Fixes the following building error:

external/mesa/src/egl/drivers/dri2/egl_dri2.c:2476: error: undefined reference 
to 'pthread_condattr_setclock'
collect2: error: ld returned 1 exit status

Cc: 
---
 src/egl/drivers/dri2/egl_dri2.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
index f954cd5..9201f5b 100644
--- a/src/egl/drivers/dri2/egl_dri2.c
+++ b/src/egl/drivers/dri2/egl_dri2.c
@@ -2421,7 +2421,9 @@ dri2_create_sync(_EGLDriver *drv, _EGLDisplay *dpy,
struct dri2_egl_context *dri2_ctx = dri2_egl_context(ctx);
struct dri2_egl_sync *dri2_sync;
EGLint ret;
+#if defined(HAVE_PTHREAD_CONDATTR_SETCLOCK) && defined(HAVE_CLOCK_MONOTONIC)
pthread_condattr_t attr;
+#endif
 
dri2_sync = calloc(1, sizeof(struct dri2_egl_sync));
if (!dri2_sync) {
@@ -2466,6 +2468,7 @@ dri2_create_sync(_EGLDriver *drv, _EGLDisplay *dpy,
   break;
 
case EGL_SYNC_REUSABLE_KHR:
+#if defined(HAVE_PTHREAD_CONDATTR_SETCLOCK) && defined(HAVE_CLOCK_MONOTONIC)
   /* intialize attr */
   ret = pthread_condattr_init();
 
@@ -2491,6 +2494,15 @@ dri2_create_sync(_EGLDriver *drv, _EGLDisplay *dpy,
  free(dri2_sync);
  return NULL;
   }
+#else
+  ret = pthread_cond_init(_sync->cond, NULL);
+
+  if (ret) {
+ _eglError(EGL_BAD_ACCESS, "eglCreateSyncKHR");
+ free(dri2_sync);
+ return NULL;
+  }
+#endif
 
   /* initial status of reusable sync must be "unsignaled" */
   dri2_sync->base.SyncStatus = EGL_UNSIGNALED_KHR;
@@ -2594,7 +2606,11 @@ dri2_client_wait_sync(_EGLDriver *drv, _EGLDisplay *dpy, 
_EGLSync *sync,
   } else {
  /* if reusable sync has not been yet signaled */
  if (dri2_sync->base.SyncStatus != EGL_SIGNALED_KHR) {
+#if defined(HAVE_PTHREAD_CONDATTR_SETCLOCK) && defined(HAVE_CLOCK_MONOTONIC)
 clock_gettime(CLOCK_MONOTONIC, );
+#else
+clock_gettime(CLOCK_REALTIME, );
+#endif
 
 /* calculating when to expire */
 expire.nsec = timeout % 10L;
-- 
2.7.4

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


[Mesa-dev] [PATCH 1/2] android: fix building error in st_glsl_to_tgsi

2016-05-30 Thread Mauro Rossi
Fixes the following building error:

bionic/libc/include/string.h:105:33: error: call to '__memcpy_dest_size_error'
declared with attribute error: memcpy called with size bigger than destination

Cc: 
---
 src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp 
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index aa443a5..46079d2 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
@@ -3455,7 +3455,7 @@ glsl_to_tgsi_visitor::visit_image_intrinsic(ir_call *ir)
if (reladdr.file != PROGRAM_UNDEFINED) {
   emit_arl(ir, sampler_reladdr, reladdr);
   image.reladdr = ralloc(mem_ctx, st_src_reg);
-  memcpy(image.reladdr, _reladdr, sizeof(reladdr));
+  memcpy(image.reladdr, _reladdr, sizeof(sampler_reladdr));
}
 
st_dst_reg dst = undef_dst;
-- 
2.7.4

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


Re: [Mesa-dev] [PATCH 0/3] r600g removal of unnecessary cache flushes

2016-05-30 Thread Grazvydas Ignotas
I've patched the CS validator and there seem to be some regressions:

arb_map_buffer_range 11/11 5/11
copybuffersubdata decrement-offset
copybuffersubdata increment-offset
copybuffersubdata offset=0
map_invalidate_range_bit decrement-offset
map_invalidate_range_bit increment-offset
map_invalidate_range_bit offset=0
arb_texture_buffer_object 77/78 76/78
subdata-sync
arb_vertex_buffer_object 16/16 13/16
vbo-subdata-many drawarrays
vbo-subdata-many drawelements
vbo-subdata-many drawrangeelements

The "good" run was done on newer git master than what your
r600-opt-flushes branch is based on, don't know if it has any effect.
Should I attempt to bisect?

Gražvydas


On Tue, May 31, 2016 at 1:30 AM, Marek Olšák  wrote:
> On Tue, May 31, 2016 at 12:17 AM, Grazvydas Ignotas  wrote:
>> I've tried it on AMD JUNIPER (DRM 2.43.0 / 4.6.0) and it does not pass
>> the kernel CS validator with
>> [drm:evergreen_packet3_check.isra.14 [radeon]] *ERROR* Packet3 opcode
>> 42 not supported
>> printed many times.
>>
>> I guess it needs some kernel patch? I haven't found anything relevant
>> in Alex's kernel git.
>
> Yeah, it needs a kernel patch which doesn't exist yet I think.
>
> Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH] radeonsi: lower SQRT to RSQ+RCP to fix the game Risen

2016-05-30 Thread Marek Olšák
From: Marek Olšák 

Sadly, I haven't been able to find any other way to fix the bug
for radeonsi. The game seems to expect DX9 behavior.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94627
(against nouveau)
---
 .../drivers/radeon/radeon_setup_tgsi_llvm.c| 22 --
 1 file changed, 20 insertions(+), 2 deletions(-)

diff --git a/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c 
b/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
index 74b36ec..c84c850 100644
--- a/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
+++ b/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
@@ -1522,6 +1522,25 @@ static void emit_up2h(const struct lp_build_tgsi_action 
*action,
}
 }
 
+static void emit_sqrt(const struct lp_build_tgsi_action *action,
+ struct lp_build_tgsi_context * bld_base,
+ struct lp_build_emit_data * emit_data)
+{
+   LLVMBuilderRef builder = bld_base->base.gallivm->builder;
+   LLVMValueRef arg = emit_data->args[0];
+
+   /* The game "Risen" renders correctly only if RSQ + RCP is used to
+* implement SQRT.
+*/
+   arg = lp_build_intrinsic(builder, "llvm.AMDGPU.rsq.f32",
+emit_data->dst_type, , 1,
+LLVMReadNoneAttribute);
+
+   arg = LLVMBuildFDiv(builder, bld_base->base.one, arg, "");
+   emit_data->output[emit_data->chan] = arg;
+   return;
+}
+
 void radeon_llvm_context_init(struct radeon_llvm_context * ctx, const char 
*triple)
 {
struct lp_type type;
@@ -1671,8 +1690,7 @@ void radeon_llvm_context_init(struct radeon_llvm_context 
* ctx, const char *trip
bld_base->op_actions[TGSI_OPCODE_SGT].emit = emit_set_cond;
bld_base->op_actions[TGSI_OPCODE_SIN].emit = build_tgsi_intrinsic_nomem;
bld_base->op_actions[TGSI_OPCODE_SIN].intr_name = "llvm.sin.f32";
-   bld_base->op_actions[TGSI_OPCODE_SQRT].emit = 
build_tgsi_intrinsic_nomem;
-   bld_base->op_actions[TGSI_OPCODE_SQRT].intr_name = "llvm.sqrt.f32";
+   bld_base->op_actions[TGSI_OPCODE_SQRT].emit = emit_sqrt;
bld_base->op_actions[TGSI_OPCODE_SSG].emit = emit_ssg;
bld_base->op_actions[TGSI_OPCODE_TRUNC].emit = 
build_tgsi_intrinsic_nomem;
bld_base->op_actions[TGSI_OPCODE_TRUNC].intr_name = "llvm.trunc.f32";
-- 
2.7.4

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


[Mesa-dev] [PATCH] st/mesa: change SQRT lowering to fix the game Risen

2016-05-30 Thread Marek Olšák
From: Marek Olšák 

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94627
(against nouveau)
---
 src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp 
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index aa443a5..0f5ee02 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
@@ -1901,13 +1901,15 @@ glsl_to_tgsi_visitor::visit_expression(ir_expression* 
ir, st_src_reg *op)
   if (have_sqrt) {
  emit_scalar(ir, TGSI_OPCODE_SQRT, result_dst, op[0]);
   } else {
- /* sqrt(x) = x * rsq(x). */
- emit_scalar(ir, TGSI_OPCODE_RSQ, result_dst, op[0]);
- emit_asm(ir, TGSI_OPCODE_MUL, result_dst, result_src, op[0]);
- /* For incoming channels <= 0, set the result to 0. */
- op[0].negate = ~op[0].negate;
- emit_asm(ir, TGSI_OPCODE_CMP, result_dst,
-  op[0], result_src, st_src_reg_for_float(0.0));
+ /* This is the only instruction sequence that makes the game "Risen"
+  * render correctly. ABS is not required for the game, but since GLSL
+  * declares negative values as "undefined", allowing us to do whatever
+  * we want, I choose to use ABS to match DX9 and pre-GLSL RSQ
+  * behavior.
+  */
+ emit_scalar(ir, TGSI_OPCODE_ABS, result_dst, op[0]);
+ emit_scalar(ir, TGSI_OPCODE_RSQ, result_dst, result_src);
+ emit_scalar(ir, TGSI_OPCODE_RCP, result_dst, result_src);
   }
   break;
case ir_unop_rsq:
-- 
2.7.4

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


Re: [Mesa-dev] [PATCH] radeon/uvd: fix the H264 level for Tonga

2016-05-30 Thread Grigori Goronzy

On 2016-05-27 15:16, Emil Velikov wrote:

The odd things is that VLC uses/used to? check that information before
feeding the video to the decoder, while others implementations (like
the original one in mplayer done by the Nvidia devs) do/did? not
bother.



Many files either have an incorrect level set or they subtly exceed the 
restrictions of a common level, e.g. 4.1. So strict checks will make 
many files non-playable with VDPAU despite actually working fine without 
checks. That's why some players don't check the level.


That said, I wonder if the level 4.1 returned on UVD 3/4 for H.264 high 
profile is actually correct. These UVD variants can easily play 1080p60, 
right? Even UVD 2 can do that, I think. Level 4.1 only allows up to 
1080p30. So wouldn't level 4.2 be the right choice? Or are there some 
restrictions on the HW decoder that make it formally not capable of 
level 4.2?


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


[Mesa-dev] [Bug 95553] Requesting a new account for mesa and piglit (Andres Gomez)

2016-05-30 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=95553

Andrés Gómez García  changed:

   What|Removed |Added

Product|Mesa|freedesktop.org
 QA Contact|mesa-dev@lists.freedesktop. |
   |org |
   Assignee|mesa-dev@lists.freedesktop. |sitewranglers@lists.freedes
   |org |ktop.org
  Component|Other   |New Accounts

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


Re: [Mesa-dev] [PATCH 0/3] r600g removal of unnecessary cache flushes

2016-05-30 Thread Marek Olšák
On Tue, May 31, 2016 at 12:17 AM, Grazvydas Ignotas  wrote:
> I've tried it on AMD JUNIPER (DRM 2.43.0 / 4.6.0) and it does not pass
> the kernel CS validator with
> [drm:evergreen_packet3_check.isra.14 [radeon]] *ERROR* Packet3 opcode
> 42 not supported
> printed many times.
>
> I guess it needs some kernel patch? I haven't found anything relevant
> in Alex's kernel git.

Yeah, it needs a kernel patch which doesn't exist yet I think.

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


Re: [Mesa-dev] [PATCH 2/2] winsys/amdgpu: disable CE preamble until the kernel is fixed

2016-05-30 Thread Marek Olšák
I'm dropping the patch. It makes UE4 Elemental hang. We have a bigger
CE issue than I thought. It could be a Mesa issue too.

Marek

On Fri, May 27, 2016 at 12:12 PM, Marek Olšák  wrote:
> On Fri, May 27, 2016 at 11:12 AM, Christian König
>  wrote:
>> Am 27.05.2016 um 00:19 schrieb Marek Olšák:
>>>
>>> On Fri, May 27, 2016 at 12:13 AM, Alex Deucher 
>>> wrote:

 On Thu, May 26, 2016 at 5:51 PM, Marek Olšák  wrote:
>
> From: Marek Olšák 
>
> SDMA submission somehow interacts with the skipping CE preamble logic.
> This is a workaround for current kernels which have the bug.
>
> Sadly, I can't see what's wrong with the kernel driver. The CE preamble
> handling there looks good to me.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95545

 What exactly is going wrong?  Is the kernel not scheduling the
 preamble or is the ordering wrong or something else?
>>>
>>> There are VM faults for addresses that are too far away from memory
>>> allocated by the process.
>>>
>>> It looks like the contents of CE RAM come from a different process,
>>> which suggests that the CE preamble IB was skipped.
>>>
>>> Disabling the CE preamble IB means that the preamble packets are added
>>> to the main CE IB instead, which makes the problem go away.
>>
>>
>> Just a guess, but does commit 9f8fb5a2b339ba83493991ca8f1173a939a696d3 in
>> Alex drm-next-4.7 tree helps with the problem?
>>
>> commit 9f8fb5a2b339ba83493991ca8f1173a939a696d3
>> Author: Christian König 
>> Date:   Fri May 6 14:52:57 2016 +0200
>>
>> drm/amdgpu: move preamble IB handling into common code
>>
>> This fixes the handling which was completely broken when you
>> ad more than one preamble IB.
>
> I'm using amd-staging-4.5, which has that. Apparently it doesn't help.
>
> Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 2/3] android: libmesa_glsl: add a dependency on libmesa_nir static

2016-05-30 Thread Mauro Rossi
Fixes the following building error:

target  C++: libmesa_glsl <= external/mesa/src/compiler/glsl/glsl_to_nir.cpp
In file included from external/mesa/src/compiler/glsl/glsl_to_nir.h:28:0,
 from external/mesa/src/compiler/glsl/glsl_to_nir.cpp:28:
external/mesa/src/compiler/nir/nir.h:42:25: fatal error: nir_opcodes.h: No such 
file or directory
compilation terminated.
build/core/binary.mk:432: recipe for target 
'out/target/product/x86/obj/STATIC_LIBRARIES/libmesa_glsl_intermediates/glsl/glsl_to_nir.o'
 failed
make: *** 
[out/target/product/x86/obj/STATIC_LIBRARIES/libmesa_glsl_intermediates/glsl/glsl_to_nir.o]
 Error 1
make: *** Waiting for unfinished jobs

Cc: 
---
 src/compiler/Android.glsl.mk | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/compiler/Android.glsl.mk b/src/compiler/Android.glsl.mk
index 5d2bc18..21c1065 100644
--- a/src/compiler/Android.glsl.mk
+++ b/src/compiler/Android.glsl.mk
@@ -38,13 +38,14 @@ LOCAL_SRC_FILES := \
$(LIBGLSL_FILES) \
 
 LOCAL_C_INCLUDES := \
-   $(MESA_TOP)/src/compiler/nir \
$(MESA_TOP)/src/mapi \
$(MESA_TOP)/src/mesa \
$(MESA_TOP)/src/gallium/include \
$(MESA_TOP)/src/gallium/auxiliary
 
-LOCAL_STATIC_LIBRARIES := libmesa_compiler
+LOCAL_STATIC_LIBRARIES := \
+   libmesa_compiler \
+   libmesa_nir
 
 LOCAL_MODULE := libmesa_glsl
 
-- 
2.7.4

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


[Mesa-dev] [PATCH 3/3] isl: add support for Android libmesa_isl static library

2016-05-30 Thread Mauro Rossi
isl library is needed to build i965, libmesa_isl static library is added
to fix related Android building errors.

Any attempt to build libmesa_genxml as phony package module failed to deliver
gen{7,75,8,9}_pack.h autogenerated headers, needed to build 
libmesa_isl_gen{7,75,8,9}

Due to constraints in the Android Build System, libmesa_genxml is built as 
static library
and at least one source file needs to be compiled, so dummy.c is autogenerated 
for this scope.

libmesa_isl_gen{7,75,8,9} dependencies on libmesa_genxml are declared using 
LOCAL_WHOLE_STATIC_LIBRARIES,
in order to avoid building errors due to missing genxml/gen{7,75,8,9}_pack.h 
headers

Cc: 
---
 Android.mk   |   3 +
 src/intel/genxml/Android.mk  |  82 ++
 src/intel/isl/Android.mk | 157 +++
 src/mesa/drivers/dri/i965/Android.mk |   3 +-
 4 files changed, 244 insertions(+), 1 deletion(-)
 create mode 100644 src/intel/genxml/Android.mk
 create mode 100644 src/intel/isl/Android.mk

diff --git a/Android.mk b/Android.mk
index 6a5596b..8ab80f3 100644
--- a/Android.mk
+++ b/Android.mk
@@ -48,6 +48,7 @@ MESA_DRI_MODULE_UNSTRIPPED_PATH := 
$(TARGET_OUT_SHARED_LIBRARIES_UNSTRIPPED)/$(M
 
 MESA_COMMON_MK := $(MESA_TOP)/Android.common.mk
 MESA_PYTHON2 := python
+MESA_PYTHON3 := python3
 
 classic_drivers := i915 i965
 gallium_drivers := swrast freedreno i915g ilo nouveau r300g r600g radeonsi 
vmwgfx vc4 virgl
@@ -95,6 +96,8 @@ SUBDIRS := \
src/mesa \
src/util \
src/egl \
+   src/intel/genxml \
+   src/intel/isl \
src/mesa/drivers/dri
 
 INC_DIRS := $(call all-named-subdir-makefiles,$(SUBDIRS))
diff --git a/src/intel/genxml/Android.mk b/src/intel/genxml/Android.mk
new file mode 100644
index 000..e0137d5
--- /dev/null
+++ b/src/intel/genxml/Android.mk
@@ -0,0 +1,82 @@
+# Copyright © 2016 Intel Corporation
+# Copyright © 2016 Mauro Rossi 
+#
+# Permission is hereby granted, free of charge, to any person obtaining a
+# copy of this software and associated documentation files (the "Software"),
+# to deal in the Software without restriction, including without limitation
+# the rights to use, copy, modify, merge, publish, distribute, sublicense,
+# and/or sell copies of the Software, and to permit persons to whom the
+# Software is furnished to do so, subject to the following conditions:
+#
+# The above copyright notice and this permission notice shall be included
+# in all copies or substantial portions of the Software.
+#
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+# DEALINGS IN THE SOFTWARE.
+
+LOCAL_PATH := $(call my-dir)
+
+# Import variable GENERATED_FILES.
+include $(LOCAL_PATH)/Makefile.sources
+
+include $(CLEAR_VARS)
+
+LOCAL_MODULE := libmesa_genxml
+
+LOCAL_MODULE_CLASS := STATIC_LIBRARIES
+
+intermediates := $(call local-generated-sources-dir)
+
+# dummy.c source file is generated to meet the build system's rules.
+LOCAL_GENERATED_SOURCES += $(intermediates)/dummy.c
+
+$(intermediates)/dummy.c:
+   @mkdir -p $(dir $@)
+   @echo "Gen Dummy: $(PRIVATE_MODULE) <= $(notdir $(@))"
+   $(hide) touch $@
+
+# This is the list of auto-generated files headers
+LOCAL_GENERATED_SOURCES += $(addprefix $(intermediates)/genxml/, 
$(GENXML_GENERATED_FILES))
+
+define header-gen
+   @mkdir -p $(dir $@)
+   @echo "Gen Header: $(PRIVATE_MODULE) <= $(notdir $(@))"
+   $(hide) $(PRIVATE_SCRIPT) $(PRIVATE_XML) > $@
+endef
+
+$(intermediates)/genxml/gen6_pack.h: PRIVATE_SCRIPT := $(MESA_PYTHON3) 
$(LOCAL_PATH)/gen_pack_header.py
+$(intermediates)/genxml/gen6_pack.h: PRIVATE_XML := $(LOCAL_PATH)/gen6.xml
+$(intermediates)/genxml/gen6_pack.h: $(LOCAL_PATH)/gen6.xml 
$(LOCAL_PATH)/gen_pack_header.py
+   $(call header-gen)
+
+$(intermediates)/genxml/gen7_pack.h: PRIVATE_SCRIPT := $(MESA_PYTHON3) 
$(LOCAL_PATH)/gen_pack_header.py
+$(intermediates)/genxml/gen7_pack.h: PRIVATE_XML := $(LOCAL_PATH)/gen7.xml
+$(intermediates)/genxml/gen7_pack.h: $(LOCAL_PATH)/gen7.xml 
$(LOCAL_PATH)/gen_pack_header.py
+   $(call header-gen)
+
+$(intermediates)/genxml/gen75_pack.h: PRIVATE_SCRIPT := $(MESA_PYTHON3) 
$(LOCAL_PATH)/gen_pack_header.py
+$(intermediates)/genxml/gen75_pack.h: PRIVATE_XML := $(LOCAL_PATH)/gen75.xml
+$(intermediates)/genxml/gen75_pack.h: $(LOCAL_PATH)/gen75.xml 
$(LOCAL_PATH)/gen_pack_header.py
+   $(call header-gen)
+
+$(intermediates)/genxml/gen8_pack.h: PRIVATE_SCRIPT := $(MESA_PYTHON3) 
$(LOCAL_PATH)/gen_pack_header.py

[Mesa-dev] [PATCH 1/3] android: define MESA_EGL_NO_X11_HEADERS

2016-05-30 Thread Mauro Rossi
In order to avoid building errors due to missing X11 headers

Cc: 
---
 Android.common.mk | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Android.common.mk b/Android.common.mk
index cdba85f..5df9b7e 100644
--- a/Android.common.mk
+++ b/Android.common.mk
@@ -56,6 +56,7 @@ LOCAL_CFLAGS += \
-DHAVE___BUILTIN_UNREACHABLE \
-DHAVE_PTHREAD=1 \
-DHAVE_DLOPEN \
+   -DMESA_EGL_NO_X11_HEADERS \
-DTEXTURE_FLOAT_ENABLED \
-fvisibility=hidden \
-Wno-sign-compare
-- 
2.7.4

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


Re: [Mesa-dev] [PATCH 0/3] r600g removal of unnecessary cache flushes

2016-05-30 Thread Grazvydas Ignotas
I've tried it on AMD JUNIPER (DRM 2.43.0 / 4.6.0) and it does not pass
the kernel CS validator with
[drm:evergreen_packet3_check.isra.14 [radeon]] *ERROR* Packet3 opcode
42 not supported
printed many times.

I guess it needs some kernel patch? I haven't found anything relevant
in Alex's kernel git.

Gražvydas

On Fri, May 27, 2016 at 9:29 PM, Marek Olšák  wrote:
> This can improve performance of GPU-bound tests that benefit from warm caches 
> from previous draw calls.
>
> You can also get it from here:
>git://people.freedesktop.org/~mareko/mesa r600-opt-flushes
>
> Not tested with piglit. If somebody wants to run piglit with this, please let 
> me know which GPUs you've tested.
>
> 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


Re: [Mesa-dev] [PATCH 2/4] automake: rework the git_sha1.h rule, include in tarball

2016-05-30 Thread Emil Velikov
On 30 May 2016 at 22:22, Emil Velikov  wrote:
> On 30 May 2016 at 22:02, Jason Ekstrand  wrote:
>> On May 30, 2016 1:56 PM, "Grazvydas Ignotas"  wrote:
>>>
>>> On Mon, May 30, 2016 at 3:46 PM, Emil Velikov 
>>> wrote:
>>> > From: Emil Velikov 
>>> >
>>> > As we'll need the file in the release tarball, rework the rule so that
>>> > the file is regenerated _only_ if we're in a git repository.
>>> >
>>> > With this in place we can build vulkan (anv) from a release tarball.
>>>
>>> After this commit the OpenGL version strings no longer update as I
>>> move around my git commits and rebuild.
> It did when I tried it here. Do you have any specific steps ?
>
Scratch that... seems like I was going "incremental" builds into
separate destination locations - i.e. they weren't incremental at all.

I'll send a patch that reverts the relevant bits - just need to double
check that I'm not going to butcher it (again).
-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 2/4] automake: rework the git_sha1.h rule, include in tarball

2016-05-30 Thread Emil Velikov
On 30 May 2016 at 22:02, Jason Ekstrand  wrote:
> On May 30, 2016 1:56 PM, "Grazvydas Ignotas"  wrote:
>>
>> On Mon, May 30, 2016 at 3:46 PM, Emil Velikov 
>> wrote:
>> > From: Emil Velikov 
>> >
>> > As we'll need the file in the release tarball, rework the rule so that
>> > the file is regenerated _only_ if we're in a git repository.
>> >
>> > With this in place we can build vulkan (anv) from a release tarball.
>>
>> After this commit the OpenGL version strings no longer update as I
>> move around my git commits and rebuild.
It did when I tried it here. Do you have any specific steps ?

>> There was also a reason for
>> the .tmp file and cmp, so it doesn't rebuild everything #including
>> git_sha1.h every time.
>
There's a single file that includes the header so "everything" sounds
a bit strange ;-)

> I was wondering about that...
>
> I know that we've had some trouble with git_sha1.h getting regenerated in
> the past. Maybe this was an oversimplification. :-(
>
Since we want to generate a file with actual contents every time
possible (we could have done a dummy one before) it didn't make sense
to keep it. If people want it back we could do that.

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


Re: [Mesa-dev] [PATCH 2/4] automake: rework the git_sha1.h rule, include in tarball

2016-05-30 Thread Jason Ekstrand
On May 30, 2016 1:56 PM, "Grazvydas Ignotas"  wrote:
>
> On Mon, May 30, 2016 at 3:46 PM, Emil Velikov 
wrote:
> > From: Emil Velikov 
> >
> > As we'll need the file in the release tarball, rework the rule so that
> > the file is regenerated _only_ if we're in a git repository.
> >
> > With this in place we can build vulkan (anv) from a release tarball.
>
> After this commit the OpenGL version strings no longer update as I
> move around my git commits and rebuild. There was also a reason for
> the .tmp file and cmp, so it doesn't rebuild everything #including
> git_sha1.h every time.

I was wondering about that...

I know that we've had some trouble with git_sha1.h getting regenerated in
the past. Maybe this was an oversimplification. :-(

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


Re: [Mesa-dev] [PATCH] mesa: Enable LTO compilation

2016-05-30 Thread Jason Ekstrand
On May 30, 2016 1:31 PM, "Emil Velikov"  wrote:
>
> On 30 May 2016 at 21:10, Jason Ekstrand  wrote:
>>
>> On Mon, May 30, 2016 at 12:27 PM, Emil Velikov 
wrote:
>>>
>>> Hi there,
>>> On 30 May 2016 at 18:28, ⚛ <0xe2.0x9a.0...@gmail.com> wrote:
>>> > This patch enables compilation with -flto.
>>> >
>>> > The performance benefits of LTO (GCC 4.9 & 6.1) are about 1% for
glxgears.
>>> > Performance changes in OpenGL games haven't been measured yet, my
feeling is
>>> > that they are negligible.
>>> >
>>> Please try to send patches via git send-email for the future.
>>>
>>> While not a hard requirement, it would be nice if you setup your email
>>> client/git to show your name/nickname.
>>> It's always better to address someone directly, as opposed to "hey you".
>>>
>>> About the patch itself:
>>>  - Please add a summary message for the change. Peter's has a nice
>>> article on the topic [1].
>>>  - We normally try to include performance metrics in the commit
>>> message. It makes it easier to justify said change.
>>>  - Have you tried debugging the resulting binary ? As Matt mentioned
>>> there used to be issues with LTO, so if those are still unresolved we
>>> want to _avoid_ forcing that for everyone.
>>
>>
>> Regarding the above two comments:  The patch he attached does not enable
LTO, it just disables it for mapi so that *if* you put -flto in your
CFLAGS, it doesn't blow up.  If this patch were enabling LTO by default,
questions about performance and debugability would be reasonable.  However,
given that the patch is purely protective, the only real question required
to justify the patch is "is LTO actually a problem for mapi?"
>>
>
> Seems like I'm the next person to fall trap of the commit message...
that's embarrassing.
>
> Wrt the approach used... perhaps one should be checking for the same flag
like they use ? It should still work though - just good practise.
>
>>>
>>>  - Are you use the mapi hunk is needed ? last time I've tried (some
>>> months ago, copying the tweaks from the Clearlinux spec file [2])
>>> things built without issues.
>>
>>
>> You are claiming it isn't.
>>
>> That said, I tried to build with -flto recently and it blew up.  I don't
remember exactly why.
>
> Do you (others) recall any details about how you enabled it (tweak
*FLAGS, CC and/or other), if there was anything special in the configure
options and/or which the GCC version ?

I just set it on CFLAGS, CXXFLAGS, and LFLAGS

> I'll give it another try in a minute, just in case I butchered something.
>
> -Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [Bug 95346] Stellaris - Black/super dark planets

2016-05-30 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=95346

--- Comment #9 from Nicolai Hähnle  ---
There are several draw calls involved in rendering the planet, the last one is
803895. It's not clear which of them gives the incorrect result.

It would be helpful if somebody could provide snapshots of the framebuffer
after each of the involved draw calls (803513, 803584, 803714, 803793, 803895)
on a system that renders this _correctly_.

This can be done using the --snapshot argument to glretrace, or interactively
using qapitrace's "Lookup State" feature.

-- 
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 2/4] automake: rework the git_sha1.h rule, include in tarball

2016-05-30 Thread Grazvydas Ignotas
On Mon, May 30, 2016 at 3:46 PM, Emil Velikov  wrote:
> From: Emil Velikov 
>
> As we'll need the file in the release tarball, rework the rule so that
> the file is regenerated _only_ if we're in a git repository.
>
> With this in place we can build vulkan (anv) from a release tarball.

After this commit the OpenGL version strings no longer update as I
move around my git commits and rebuild. There was also a reason for
the .tmp file and cmp, so it doesn't rebuild everything #including
git_sha1.h every time.

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


Re: [Mesa-dev] [PATCH] mesa: Enable LTO compilation

2016-05-30 Thread Emil Velikov
On 30 May 2016 at 21:10, Jason Ekstrand  wrote:

> On Mon, May 30, 2016 at 12:27 PM, Emil Velikov 
> wrote:
>
>> Hi there,
>> On 30 May 2016 at 18:28, ⚛ <0xe2.0x9a.0...@gmail.com> wrote:
>> > This patch enables compilation with -flto.
>> >
>> > The performance benefits of LTO (GCC 4.9 & 6.1) are about 1% for
>> glxgears.
>> > Performance changes in OpenGL games haven't been measured yet, my
>> feeling is
>> > that they are negligible.
>> >
>> Please try to send patches via git send-email for the future.
>>
>> While not a hard requirement, it would be nice if you setup your email
>> client/git to show your name/nickname.
>> It's always better to address someone directly, as opposed to "hey you".
>>
>> About the patch itself:
>>  - Please add a summary message for the change. Peter's has a nice
>> article on the topic [1].
>>  - We normally try to include performance metrics in the commit
>> message. It makes it easier to justify said change.
>>  - Have you tried debugging the resulting binary ? As Matt mentioned
>> there used to be issues with LTO, so if those are still unresolved we
>> want to _avoid_ forcing that for everyone.
>>
>
> Regarding the above two comments:  The patch he attached does not enable
> LTO, it just disables it for mapi so that *if* you put -flto in your
> CFLAGS, it doesn't blow up.  If this patch were enabling LTO by default,
> questions about performance and debugability would be reasonable.  However,
> given that the patch is purely protective, the only real question required
> to justify the patch is "is LTO actually a problem for mapi?"
>
>
Seems like I'm the next person to fall trap of the commit message... that's
embarrassing.

Wrt the approach used... perhaps one should be checking for the same flag
like they use ? It should still work though - just good practise.


>  - Are you use the mapi hunk is needed ? last time I've tried (some
>> months ago, copying the tweaks from the Clearlinux spec file [2])
>> things built without issues.
>>
>
> You are claiming it isn't.
>
> That said, I tried to build with -flto recently and it blew up.  I don't
> remember exactly why.
>
Do you (others) recall any details about how you enabled it (tweak *FLAGS,
CC and/or other), if there was anything special in the configure options
and/or which the GCC version ?

I'll give it another try in a minute, just in case I butchered something.

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


Re: [Mesa-dev] [PATCH 2/4] automake: rework the git_sha1.h rule, include in tarball

2016-05-30 Thread Emil Velikov
On 30 May 2016 at 21:11, Matt Turner  wrote:
> On Mon, May 30, 2016 at 5:46 AM, Emil Velikov  
> wrote:
>> From: Emil Velikov 
>>
>> As we'll need the file in the release tarball, rework the rule so that
>> the file is regenerated _only_ if we're in a git repository.
>>
>> With this in place we can build vulkan (anv) from a release tarball.
>>
>> Cc: Jason Ekstrand 
>> Cc: Kristian Høgsberg Kristensen 
>> Signed-off-by: Emil Velikov 
>> ---
>> Not 100% sure if we want the file in any of the clean targets. I'm
>> leaning towards "no", yet I'm open to input.
>
> That would prevent rebuilds after 'make clean' when built from a
> tarball, wouldn't it?
Reading my comment ... it sounds a bit odd/misleading. It should have said:
 "I'm leaning that we don't want to cleanup the file. Not 100% sure so
I'm open to suggestions."

And yes. If we clean the file (with any target) then there'll be no
way to regenerate it when building from tarball. And thus we won't be
able to build Vulkan.

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


Re: [Mesa-dev] [PATCH] i965: Shrink stage_prog_data param array length

2016-05-30 Thread Jason Ekstrand
On Mon, May 30, 2016 at 9:50 AM, Emil Velikov 
wrote:

> On 29 May 2016 at 07:01, Jordan Justen  wrote:
> > It appears we were over-allocating these arrays.
> >
> > Previously we would use nir->num_uniforms directly for scalar
> > programs, and multiply it by 4 for vec4 programs.
> >
> > Instead we should have been dividing by 4 in both cases to convert
> > from bytes to a gl_constant_value count. The size of gl_constant_value
> > is 4 bytes.
> >
> > Signed-off-by: Jordan Justen 
> > ---
> >  Jenkins results looked good with this change.
> >
> >  src/mesa/drivers/dri/i965/brw_cs.c  | 2 +-
> >  src/mesa/drivers/dri/i965/brw_gs.c  | 4 +---
> >  src/mesa/drivers/dri/i965/brw_tcs.c | 4 +---
> >  src/mesa/drivers/dri/i965/brw_tes.c | 4 +---
> >  src/mesa/drivers/dri/i965/brw_vs.c  | 4 +---
> >  src/mesa/drivers/dri/i965/brw_wm.c  | 2 +-
> >  6 files changed, 6 insertions(+), 14 deletions(-)
> >
> > diff --git a/src/mesa/drivers/dri/i965/brw_cs.c
> b/src/mesa/drivers/dri/i965/brw_cs.c
> > index 0ab9ebd..a9cbde9 100644
> > --- a/src/mesa/drivers/dri/i965/brw_cs.c
> > +++ b/src/mesa/drivers/dri/i965/brw_cs.c
> > @@ -91,7 +91,7 @@ brw_codegen_cs_prog(struct brw_context *brw,
> >  * prog_data associated with the compiled program, and which will be
> freed
> >  * by the state cache.
> >  */
> > -   int param_count = cp->program.Base.nir->num_uniforms;
> > +   int param_count = cp->program.Base.nir->num_uniforms / 4;
> >
> Shouldn't one use sizeof(union gl_constant_value) over the hardcoded 4 ?
>

Yes and no.  The fact that gl_constant_value is 4 bytes is very tightly
intertwined with the rest of the code.  if gl_constant_value ever became 8
bytes it's very questionable as to whether or not we would want this to
change automatically.

--Jason


>
> -Emil
> ___
> 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 2/4] automake: rework the git_sha1.h rule, include in tarball

2016-05-30 Thread Matt Turner
On Mon, May 30, 2016 at 5:46 AM, Emil Velikov  wrote:
> From: Emil Velikov 
>
> As we'll need the file in the release tarball, rework the rule so that
> the file is regenerated _only_ if we're in a git repository.
>
> With this in place we can build vulkan (anv) from a release tarball.
>
> Cc: Jason Ekstrand 
> Cc: Kristian Høgsberg Kristensen 
> Signed-off-by: Emil Velikov 
> ---
> Not 100% sure if we want the file in any of the clean targets. I'm
> leaning towards "no", yet I'm open to input.

That would prevent rebuilds after 'make clean' when built from a
tarball, wouldn't it?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] mesa: Enable LTO compilation

2016-05-30 Thread Jason Ekstrand
On Mon, May 30, 2016 at 12:27 PM, Emil Velikov 
wrote:

> Hi there,
> On 30 May 2016 at 18:28, ⚛ <0xe2.0x9a.0...@gmail.com> wrote:
> > This patch enables compilation with -flto.
> >
> > The performance benefits of LTO (GCC 4.9 & 6.1) are about 1% for
> glxgears.
> > Performance changes in OpenGL games haven't been measured yet, my
> feeling is
> > that they are negligible.
> >
> Please try to send patches via git send-email for the future.
>
> While not a hard requirement, it would be nice if you setup your email
> client/git to show your name/nickname.
> It's always better to address someone directly, as opposed to "hey you".
>
> About the patch itself:
>  - Please add a summary message for the change. Peter's has a nice
> article on the topic [1].
>  - We normally try to include performance metrics in the commit
> message. It makes it easier to justify said change.
>  - Have you tried debugging the resulting binary ? As Matt mentioned
> there used to be issues with LTO, so if those are still unresolved we
> want to _avoid_ forcing that for everyone.
>

Regarding the above two comments:  The patch he attached does not enable
LTO, it just disables it for mapi so that *if* you put -flto in your
CFLAGS, it doesn't blow up.  If this patch were enabling LTO by default,
questions about performance and debugability would be reasonable.  However,
given that the patch is purely protective, the only real question required
to justify the patch is "is LTO actually a problem for mapi?"


>  - Are you use the mapi hunk is needed ? last time I've tried (some
> months ago, copying the tweaks from the Clearlinux spec file [2])
> things built without issues.
>

You are claiming it isn't.

That said, I tried to build with -flto recently and it blew up.  I don't
remember exactly why.


>
> Thanks
> Emil
>
> [1] http://who-t.blogspot.co.uk/2009/12/on-commit-messages.html
> [2] https://download.clearlinux.org/releases/8470/clear/source/SRPMS/
> ___
> 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 4/4] mesa: remove MESA_GIT_SHA1 guard

2016-05-30 Thread Jason Ekstrand
Reviewed-by: Jason Ekstrand 

On Mon, May 30, 2016 at 5:46 AM, Emil Velikov 
wrote:

> From: Emil Velikov 
>
> As of a few commits ago the header will always contain the macro.
>
> Signed-off-by: Emil Velikov 
> ---
>  src/mesa/main/version.c | 2 --
>  1 file changed, 2 deletions(-)
>
> diff --git a/src/mesa/main/version.c b/src/mesa/main/version.c
> index 7138cf3..74e06f9 100644
> --- a/src/mesa/main/version.c
> +++ b/src/mesa/main/version.c
> @@ -122,9 +122,7 @@ create_version_string(struct gl_context *ctx, const
> char *prefix)
> if (ctx->VersionString) {
>_mesa_snprintf(ctx->VersionString, max,
>  "%s%u.%u%s Mesa " PACKAGE_VERSION
> -#ifdef MESA_GIT_SHA1
>  " (" MESA_GIT_SHA1 ")"
> -#endif
>  ,
>  prefix,
>  ctx->Version / 10, ctx->Version % 10,
> --
> 2.8.2
>
> ___
> 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 2/4] automake: rework the git_sha1.h rule, include in tarball

2016-05-30 Thread Jason Ekstrand
On Mon, May 30, 2016 at 5:46 AM, Emil Velikov 
wrote:

> From: Emil Velikov 
>
> As we'll need the file in the release tarball, rework the rule so that
> the file is regenerated _only_ if we're in a git repository.
>
> With this in place we can build vulkan (anv) from a release tarball.
>

Reviewed-by: Jason Ekstrand 


>
> Cc: Jason Ekstrand 
> Cc: Kristian Høgsberg Kristensen 
> Signed-off-by: Emil Velikov 
> ---
> Not 100% sure if we want the file in any of the clean targets. I'm
> leaning towards "no", yet I'm open to input.
>

I think it'd be nice if it were in one but I don't know enough about the
implications of doing so to have a very trustworthy opinion.


> ---
>  .gitignore  |  1 -
>  src/Makefile.am | 20 +++-
>  2 files changed, 3 insertions(+), 18 deletions(-)
>
> diff --git a/.gitignore b/.gitignore
> index f42ca7f..90abe10 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -49,4 +49,3 @@ Makefile.in
>  .install-mesa-links
>  .install-gallium-links
>  /src/git_sha1.h
> -/src/git_sha1.h.tmp
> diff --git a/src/Makefile.am b/src/Makefile.am
> index d142aea..f5c0773 100644
> --- a/src/Makefile.am
> +++ b/src/Makefile.am
> @@ -19,30 +19,16 @@
>  # FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> DEALINGS
>  # IN THE SOFTWARE.
>
> -.PHONY: git_sha1.h.tmp
> -git_sha1.h.tmp:
> -   @# Don't assume that $(top_srcdir)/.git is a directory. It may be
> -   @# a gitlink file if $(top_srcdir) is a submodule checkout or a
> linked
> -   @# worktree.
> -   @touch git_sha1.h.tmp
> +git_sha1.h:
> @if test -e $(top_srcdir)/.git; then \
> if which git > /dev/null; then \
> git --git-dir=$(top_srcdir)/.git log -n 1 --oneline | \
> sed 's/^\([^ ]*\) .*/#define MESA_GIT_SHA1
> "git-\1"/' \
> -   > git_sha1.h.tmp ; \
> +   > git_sha1.h ; \
> fi \
> fi
>
> -git_sha1.h: git_sha1.h.tmp
> -   @echo "updating git_sha1.h"
> -   @if ! cmp -s git_sha1.h.tmp git_sha1.h; then \
> -   mv git_sha1.h.tmp git_sha1.h ;\
> -   else \
> -   rm git_sha1.h.tmp ;\
> -   fi
> -
>  BUILT_SOURCES = git_sha1.h
> -CLEANFILES = $(BUILT_SOURCES)
>
>  SUBDIRS = . gtest util mapi/glapi/gen mapi
>
> @@ -92,7 +78,7 @@ SUBDIRS += gallium
>  endif
>
>  EXTRA_DIST = \
> -   getopt hgl SConscript
> +   getopt hgl SConscript git_sha1.h
>
>  AM_CFLAGS = $(VISIBILITY_CFLAGS)
>  AM_CXXFLAGS = $(VISIBILITY_CXXFLAGS)
> --
> 2.8.2
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] mesa: Enable LTO compilation

2016-05-30 Thread Emil Velikov
Hi there,
On 30 May 2016 at 18:28, ⚛ <0xe2.0x9a.0...@gmail.com> wrote:
> This patch enables compilation with -flto.
>
> The performance benefits of LTO (GCC 4.9 & 6.1) are about 1% for glxgears.
> Performance changes in OpenGL games haven't been measured yet, my feeling is
> that they are negligible.
>
Please try to send patches via git send-email for the future.

While not a hard requirement, it would be nice if you setup your email
client/git to show your name/nickname.
It's always better to address someone directly, as opposed to "hey you".

About the patch itself:
 - Please add a summary message for the change. Peter's has a nice
article on the topic [1].
 - We normally try to include performance metrics in the commit
message. It makes it easier to justify said change.
 - Have you tried debugging the resulting binary ? As Matt mentioned
there used to be issues with LTO, so if those are still unresolved we
want to _avoid_ forcing that for everyone.
 - Are you use the mapi hunk is needed ? last time I've tried (some
months ago, copying the tweaks from the Clearlinux spec file [2])
things built without issues.

Thanks
Emil

[1] http://who-t.blogspot.co.uk/2009/12/on-commit-messages.html
[2] https://download.clearlinux.org/releases/8470/clear/source/SRPMS/
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] Mesa 12.0.0 release candidate 1

2016-05-30 Thread Emil Velikov
The first release candidate for Mesa 12.0.0 is now available.

The plan is to have one release candidate every Friday, until the final
release on June 10th or June 17th 2016.

As a reminder, with the 12.0 branch now created, patches nominated with:

CC: 

will now be candidates only for the new 12.0 branch. To nominate patches
for the older 11.1 branch as well, please use:

CC: "11.2 12.0" 

The expectation is that the 11.2 branch will remain alive with bi-weekly
releases until after 12.0.1 release.


Here are the people which helped shape the current release.

13  Adam Jackson
29  Alejandro Piñeiro
 2  Alex Deucher
 1  Andreas Fänger
 3  Andres Gomez
37  Antia Puentes
27  Anuj Phogat
 1  Ardinartsev Nikita
41  Axel Davy
79  Bas Nieuwenhuizen
19  Ben Widawsky
 1  BogDan Vatra
 4  Boyuan Zhang
   135  Brian Paul
 4  Bruce Cherniak
   425  Chad Versace
12  Charmaine Lee
13  Christian König
 2  Christian Schmidbauer
 2  Chuck Atkins
   133  Connor Abbott
 1  Daniel Czarnowski
 1  Daniel Scharrer
 3  Daniel Stone
   106  Dave Airlie
 1  Derek Foreman
 1  Dieter Nützel
 2  Dongwon Kim
27  Eduardo Lima Mitev
21  Edward O'Callaghan
 1  Egbert Eich
 3  Elie TOURNIER
   141  Emil Velikov
50  Eric Anholt
 1  Eric Engestrom
 1  Erik Faye-Lund
   139  Francisco Jerez
 2  Frederic Devernay
 5  George Kyriazis
 3  Giuseppe Bilotta
 8  Grazvydas Ignotas
 2  Haixia Shi
17  Hans de Goede
63  Iago Toral Quiroga
59  Ian Romanick
   119  Ilia Mirkin
 1  Iurie Salomov
10  Jakob Sinclair
 1  Jamey Sharp
 6  Jan Vesely
  1708  Jason Ekstrand
 1  Jiri Slaby
 5  John Sheu
 7  Jonathan Gray
94  Jordan Justen
56  José Fonseca
12  Juan A. Suarez Romero
 3  Juha-Pekka Heikkila
   236  Kenneth Graunke
 1  Knut Andre Tidemann
 1  Koop Mast
   298  Kristian Høgsberg
25  Kristian Høgsberg Kristensen
 1  Kyle Brenneman
 5  Lars Hamre
 2  Laurent Carlier
17  Leo Liu
 1  Maarten Lankhorst
 2  Marc-André Lureau
 1  Marcin Ślusarz
   191  Marek Olšák
13  Mark Janes
 1  Mark Kettenis
 1  Markus Wick
92  Matt Turner
 4  Mauro Rossi
 4  Michel Dänzer
 8  Miklós Máté
87  Nanley Chery
 1  Neil Roberts
   136  Nicolai Hähnle
 3  Nicolas Boichat
 2  Nicolas Dufresne
 2  Nishanth Peethambaran
16  Oded Gabbay
 7  Patrick Rudolph
 1  Philipp Zabel
 6  Pierre Moreau
 3  Plamena Manolova
17  Rhys Kidd
   132  Rob Clark
33  Rob Herring
 2  Robert Foss
18  Roland Scheidegger
 4  Romain Failliot
 1  Ronie Salgado
 1  Rovanion Luckey
 4  Russell King
23  Samuel Iglesias Gonsálvez
   133  Samuel Pitoiset
 2  Sarah Sharp
 1  Sinclair Yeh
 5  Sonny Jiang
 3  Stanimir Varbanov
 1  Stefan Dirsch
 1  Tamil velan
 1  Thomas Faller
 2  Thomas Hellstrom
16  Thomas Hindoe Paaboel Andersen
   139  Tim Rowley
   102  Timothy Arceri
 8  Tobias Klausmann
 4  Tom Stellard
68  Topi Pohjolainen
 2  Varad Gautam
 4  Vinson Lee
 1  Wang He
 3  WuZhen
 1  Youry Metlitsky
 1  xavier

git tag: mesa-12.0.0-rc1


ftp://ftp.freedesktop.org/pub/mesa/12.0.0/mesa-12.0.0-rc1.tar.gz
MD5: db64bba8a3473e375b9815ebfa276c68  mesa-12.0.0-rc1.tar.gz
SHA1: 4e4a622fb9e181db0473bfe48ba4b4bf8f073cf6  mesa-12.0.0-rc1.tar.gz
SHA256: c6d91a7ae3d0a8ec8c08b41ceccd81c79b31df8ef62dc7251b8657078a3f4702  
mesa-12.0.0-rc1.tar.gz
PGP: ftp://ftp.freedesktop.org/pub/mesa/12.0.0/mesa-12.0.0-rc1.tar.gz.sig

ftp://ftp.freedesktop.org/pub/mesa/12.0.0/mesa-12.0.0-rc1.tar.xz
MD5: 1b2d2764beca249bb81f23274fc1d75d  mesa-12.0.0-rc1.tar.xz
SHA1: bc3863ca4a3c14a55d32af1597192e05e4ab8f1b  mesa-12.0.0-rc1.tar.xz
SHA256: ce1483a4393aef2f265ec2619dec4bffd44d64ed06b8a00b063eb2aac77d12a7  
mesa-12.0.0-rc1.tar.xz
PGP: ftp://ftp.freedesktop.org/pub/mesa/12.0.0/mesa-12.0.0-rc1.tar.xz.sig

--
-Emil



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


[Mesa-dev] [Bug 95005] Unreal engine demos segfault after shader compilation error with OpenGL 4.3

2016-05-30 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=95005

--- Comment #16 from Marek Olšák  ---
Can this bug be closed then?

-- 
You are receiving this mail because:
You are on the CC list 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 04/14] i965/anv: Add uniform for a CS thread local base ID

2016-05-30 Thread Jason Ekstrand
I don't think "anv" is the right prefix for this patch.  Really, it's
adding local_id_index to cs_prog_data.

By and large, I think the code at the end of the series is what we want.  I
made a few comments but not many.  However, I think we could make it a bit
more bisectable if we wanted.  If you don't want to go through the effort,
feel free to just land the series as is (with the couple of suggestions
taken into account) with

Reviewed-by: Jason Ekstrand 

If you want to be a pedant, I think we could do something like the
following:

 1) Patch 7 with the anv changes as well
 2) This patch without the anv bits and with local_id_index always
initialized to -1 by brw_compile_cs
 3) Add the NIR pass
 4) Patch 8 only with a hack to set cross_thread_supported to false always
 5) Hook things up in i965
 6) Hook thnigs up in anv
 7) A single patch that properly sets local_id_index, runs the NIR pass,
and sets cross_thread_supported based on gen.

That would make the 'flip the switch" patch very small, probably a
half-dozen lines.  If you're going to be a pedant don't be a pedant on your
holiday... :-)

On Sun, May 29, 2016 at 3:38 PM, Jordan Justen 
wrote:

> Signed-off-by: Jordan Justen 
> ---
>  src/intel/vulkan/anv_pipeline.c  | 4 
>  src/mesa/drivers/dri/i965/brw_compiler.h | 1 +
>  src/mesa/drivers/dri/i965/brw_cs.c   | 3 +++
>  src/mesa/drivers/dri/i965/brw_fs.cpp | 8 
>  4 files changed, 16 insertions(+)
>
> diff --git a/src/intel/vulkan/anv_pipeline.c
> b/src/intel/vulkan/anv_pipeline.c
> index 789bc1a..504f0be 100644
> --- a/src/intel/vulkan/anv_pipeline.c
> +++ b/src/intel/vulkan/anv_pipeline.c
> @@ -338,6 +338,10 @@ anv_pipeline_compile(struct anv_pipeline *pipeline,
>pipeline->needs_data_cache = true;
> }
>
> +   if (stage == MESA_SHADER_COMPUTE)
> +  ((struct brw_cs_prog_data *)prog_data)->thread_local_id_index =
> + prog_data->nr_params++; /* The CS Thread ID uniform */
> +
> if (nir->info.num_ssbos > 0)
>pipeline->needs_data_cache = true;
>
> diff --git a/src/mesa/drivers/dri/i965/brw_compiler.h
> b/src/mesa/drivers/dri/i965/brw_compiler.h
> index 0844694..bed969c 100644
> --- a/src/mesa/drivers/dri/i965/brw_compiler.h
> +++ b/src/mesa/drivers/dri/i965/brw_compiler.h
> @@ -433,6 +433,7 @@ struct brw_cs_prog_data {
> bool uses_barrier;
> bool uses_num_work_groups;
> unsigned local_invocation_id_regs;
> +   int thread_local_id_index;
>
> struct {
>/** @{
> diff --git a/src/mesa/drivers/dri/i965/brw_cs.c
> b/src/mesa/drivers/dri/i965/brw_cs.c
> index a9cbde9..2a25584 100644
> --- a/src/mesa/drivers/dri/i965/brw_cs.c
> +++ b/src/mesa/drivers/dri/i965/brw_cs.c
> @@ -93,6 +93,9 @@ brw_codegen_cs_prog(struct brw_context *brw,
>  */
> int param_count = cp->program.Base.nir->num_uniforms / 4;
>
> +   /* The backend also sometimes add a param for the thread local id. */
> +   prog_data.thread_local_id_index = param_count++;
> +
> /* The backend also sometimes adds params for texture size. */
> param_count += 2 *
> ctx->Const.Program[MESA_SHADER_COMPUTE].MaxTextureImageUnits;
> prog_data.base.param =
> diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
> b/src/mesa/drivers/dri/i965/brw_fs.cpp
> index f5add6e..f7753db 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
> @@ -6469,6 +6469,14 @@ brw_compile_cs(const struct brw_compiler *compiler,
> void *log_data,
>true);
> brw_nir_lower_cs_shared(shader);
> prog_data->base.total_shared += shader->num_shared;
> +
> +   /* Now that we cloned the nir_shader, we can update num_uniforms based
> on
> +* the thread_local_id_index.
> +*/
> +   shader->num_uniforms =
> +  MAX2(shader->num_uniforms,
> +   (unsigned)4 * (prog_data->thread_local_id_index + 1));
> +
> shader = brw_postprocess_nir(shader, compiler->devinfo, true);
>
> prog_data->local_size[0] = shader->info.cs.local_size[0];
> --
> 2.8.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] mesa: Enable LTO compilation

2016-05-30 Thread Pierre Moreau
Ok, I found the answer to my question regarding the `-fno-lto`. IMHO that
should be in the commit message, since the patch only checks for availability
and disables LTO in one case, never enabling it explicitely.
Please ignore my previous mail.

Pierre

On 11:06 AM - May 30 2016, Matt Turner wrote:
> On Mon, May 30, 2016 at 11:02 AM, ⚛ <0xe2.0x9a.0...@gmail.com> wrote:
> >
> > On Mon, May 30, 2016 at 7:39 PM, Matt Turner  wrote:
> >>
> >> On Mon, May 30, 2016 at 10:28 AM, <0xe2.0x9a.0...@gmail.com> wrote:
> >> > This patch enables compilation with -flto.
> >> >
> >> > The performance benefits of LTO (GCC 4.9 & 6.1) are about 1% for 
> >> > glxgears.
> >> > Performance changes in OpenGL games haven't been measured yet, my 
> >> > feeling is
> >> > that they are negligible.
> >>
> >> Without a compelling reason, I don't think the build system should be
> >> adding compiler flags like this.
> >
> >
> > What does it mean "like this". The patched build system only checks whether 
> > -flto works because it needs to be disabled in mesa/src/mapi.
> >
> >>
> >> -flto makes debugging impossible, at least the last time I tried it
> >> with gcc. I don't think that's something we would want enabled
> >> whenever it's supported.
> >
> >
> > "Enable LTO compilation" means the person compiling Mesa can choose whether 
> > to use -flto.
> 
> Oh, I see. I misunderstood the patch initially.
> 
> Because src/mapi cannot be compiled with -flto, this patch *disables*
> -flto in that directory if it is enabled. Interesting.
> 
> (Please keep mesa-dev@ in Cc on your replies, and don't sent HTML mail)
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev


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] mesa: Enable LTO compilation

2016-05-30 Thread
On Mon, May 30, 2016 at 8:07 PM, Pierre Moreau  wrote:
> On 07:28 PM - May 30 2016, ⚛ wrote:
>> +if COMPILER_UNDERSTANDS_LTO
>> +CFLAGS += -fno-lto
>> +CXXFLAGS += -fno-lto
>
> This should be `-flto` if I’m not mistaken.
>
> Pierre

-fno-lto is correct because GCC has issues compiling the assembler
statements in C files in that directory.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] mesa: Enable LTO compilation

2016-05-30 Thread Matt Turner
On Mon, May 30, 2016 at 11:02 AM, ⚛ <0xe2.0x9a.0...@gmail.com> wrote:
>
> On Mon, May 30, 2016 at 7:39 PM, Matt Turner  wrote:
>>
>> On Mon, May 30, 2016 at 10:28 AM, <0xe2.0x9a.0...@gmail.com> wrote:
>> > This patch enables compilation with -flto.
>> >
>> > The performance benefits of LTO (GCC 4.9 & 6.1) are about 1% for glxgears.
>> > Performance changes in OpenGL games haven't been measured yet, my feeling 
>> > is
>> > that they are negligible.
>>
>> Without a compelling reason, I don't think the build system should be
>> adding compiler flags like this.
>
>
> What does it mean "like this". The patched build system only checks whether 
> -flto works because it needs to be disabled in mesa/src/mapi.
>
>>
>> -flto makes debugging impossible, at least the last time I tried it
>> with gcc. I don't think that's something we would want enabled
>> whenever it's supported.
>
>
> "Enable LTO compilation" means the person compiling Mesa can choose whether 
> to use -flto.

Oh, I see. I misunderstood the patch initially.

Because src/mapi cannot be compiled with -flto, this patch *disables*
-flto in that directory if it is enabled. Interesting.

(Please keep mesa-dev@ in Cc on your replies, and don't sent HTML mail)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] mesa: Enable LTO compilation

2016-05-30 Thread Pierre Moreau
On 07:28 PM - May 30 2016, ⚛ wrote:
> This patch enables compilation with -flto.
> 
> The performance benefits of LTO (GCC 4.9 & 6.1) are about 1% for glxgears.
> Performance changes in OpenGL games haven't been measured yet, my feeling
> is that they are negligible.

> diff --git a/configure.ac b/configure.ac
> index fc0b1db..e84a1ad 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -362,6 +362,8 @@ if test "x$GXX" = xyes; then
>  CXXFLAGS="$CXXFLAGS -fno-builtin-memcmp"
>  fi
>  
> +AX_CHECK_COMPILE_FLAG([-flto], AM_CONDITIONAL(COMPILER_UNDERSTANDS_LTO, 
> true), AM_CONDITIONAL(COMPILER_UNDERSTANDS_LTO, false))
> +
>  AC_SUBST([MSVC2013_COMPAT_CFLAGS])
>  AC_SUBST([MSVC2013_COMPAT_CXXFLAGS])
>  
> diff --git a/src/mapi/Makefile.am b/src/mapi/Makefile.am
> index 68a28a2..4b7d266 100644
> --- a/src/mapi/Makefile.am
> +++ b/src/mapi/Makefile.am
> @@ -51,6 +51,11 @@ AM_CPPFLAGS =  
> \
>  
>  include Makefile.sources
>  
> +if COMPILER_UNDERSTANDS_LTO
> +CFLAGS += -fno-lto
> +CXXFLAGS += -fno-lto

This should be `-flto` if I’m not mistaken.

Pierre

> +endif
> +
>  MKDIR_GEN = $(AM_V_at)$(MKDIR_P) $(@D)
>  PYTHON_GEN = $(AM_V_GEN)$(PYTHON2) $(PYTHON_FLAGS)
>  

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



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/2] vc4: Fix doxygen warnings

2016-05-30 Thread Emil Velikov
On 25 May 2016 at 22:10, Rhys Kidd  wrote:
> Now that vc4 automated code documentation can be generated with
> doxygen, fix the warnings issued by Doxygen 1.8.11.
>
> Signed-off-by: Rhys Kidd 
> ---
>  src/gallium/drivers/vc4/vc4_qir_schedule.c | 4 ++--
>  src/gallium/drivers/vc4/vc4_tiling.c   | 8 
>  2 files changed, 6 insertions(+), 6 deletions(-)
>
Thanks for the patches Rhys. Both should be in master now.

Eric, the VC4 patch was trivial enough and considering you're busy
with $other_work, so I've pushed as well. Hope you don't mind :-)

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


[Mesa-dev] [PATCH 3/3] glsl: add gl_BoundingBox and associated varying slots

2016-05-30 Thread Ilia Mirkin
Signed-off-by: Ilia Mirkin 
---
 src/compiler/glsl/builtin_variables.cpp | 10 ++
 src/compiler/glsl/ir_set_program_inouts.cpp |  4 +++-
 src/compiler/shader_enums.c |  2 ++
 src/compiler/shader_enums.h |  4 
 src/mesa/main/mtypes.h  |  2 ++
 src/mesa/program/prog_print.c   |  4 
 6 files changed, 25 insertions(+), 1 deletion(-)

diff --git a/src/compiler/glsl/builtin_variables.cpp 
b/src/compiler/glsl/builtin_variables.cpp
index 22d16de..b2c9c63 100644
--- a/src/compiler/glsl/builtin_variables.cpp
+++ b/src/compiler/glsl/builtin_variables.cpp
@@ -1036,6 +1036,16 @@ builtin_variable_generator::generate_tcs_special_vars()
   "gl_TessLevelOuter")->data.patch = 1;
add_output(VARYING_SLOT_TESS_LEVEL_INNER, array(float_t, 2),
   "gl_TessLevelInner")->data.patch = 1;
+   /* XXX What to do if multiple are flipped on? */
+   if (state->EXT_primitive_bounding_box_enable)
+  add_output(VARYING_SLOT_BOUNDING_BOX0, array(vec4_t, 2),
+ "gl_BoundingBoxEXT")->data.patch = 1;
+   if (state->OES_primitive_bounding_box_enable)
+  add_output(VARYING_SLOT_BOUNDING_BOX0, array(vec4_t, 2),
+ "gl_BoundingBoxOES")->data.patch = 1;
+   if (state->is_version(0, 320) || state->ARB_ES3_2_compatibility_enable)
+  add_output(VARYING_SLOT_BOUNDING_BOX0, array(vec4_t, 2),
+ "gl_BoundingBox")->data.patch = 1;
 }
 
 
diff --git a/src/compiler/glsl/ir_set_program_inouts.cpp 
b/src/compiler/glsl/ir_set_program_inouts.cpp
index 183b13b..1e2c4b0 100644
--- a/src/compiler/glsl/ir_set_program_inouts.cpp
+++ b/src/compiler/glsl/ir_set_program_inouts.cpp
@@ -99,7 +99,9 @@ mark(struct gl_program *prog, ir_variable *var, int offset, 
int len,
   int idx = var->data.location + var->data.index + offset + i;
   bool is_patch_generic = var->data.patch &&
   idx != VARYING_SLOT_TESS_LEVEL_INNER &&
-  idx != VARYING_SLOT_TESS_LEVEL_OUTER;
+  idx != VARYING_SLOT_TESS_LEVEL_OUTER &&
+  idx != VARYING_SLOT_BOUNDING_BOX0 &&
+  idx != VARYING_SLOT_BOUNDING_BOX1;
   GLbitfield64 bitfield;
 
   if (is_patch_generic) {
diff --git a/src/compiler/shader_enums.c b/src/compiler/shader_enums.c
index ff2f564..f49a862 100644
--- a/src/compiler/shader_enums.c
+++ b/src/compiler/shader_enums.c
@@ -158,6 +158,8 @@ gl_varying_slot_name(gl_varying_slot slot)
   ENUM(VARYING_SLOT_PNTC),
   ENUM(VARYING_SLOT_TESS_LEVEL_OUTER),
   ENUM(VARYING_SLOT_TESS_LEVEL_INNER),
+  ENUM(VARYING_SLOT_BOUNDING_BOX0),
+  ENUM(VARYING_SLOT_BOUNDING_BOX1),
   ENUM(VARYING_SLOT_VAR0),
   ENUM(VARYING_SLOT_VAR1),
   ENUM(VARYING_SLOT_VAR2),
diff --git a/src/compiler/shader_enums.h b/src/compiler/shader_enums.h
index df3124e..48122b5 100644
--- a/src/compiler/shader_enums.h
+++ b/src/compiler/shader_enums.h
@@ -214,6 +214,8 @@ typedef enum
VARYING_SLOT_PNTC, /* FS only */
VARYING_SLOT_TESS_LEVEL_OUTER, /* Only appears as TCS output. */
VARYING_SLOT_TESS_LEVEL_INNER, /* Only appears as TCS output. */
+   VARYING_SLOT_BOUNDING_BOX0, /* Only appears as TCS output. */
+   VARYING_SLOT_BOUNDING_BOX1, /* Only appears as TCS output. */
VARYING_SLOT_VAR0, /* First generic varying slot */
/* the remaining are simply for the benefit of gl_varying_slot_name()
 * and not to be construed as an upper bound:
@@ -294,6 +296,8 @@ const char *gl_varying_slot_name(gl_varying_slot slot);
 #define VARYING_BIT_PNTC BITFIELD64_BIT(VARYING_SLOT_PNTC)
 #define VARYING_BIT_TESS_LEVEL_OUTER 
BITFIELD64_BIT(VARYING_SLOT_TESS_LEVEL_OUTER)
 #define VARYING_BIT_TESS_LEVEL_INNER 
BITFIELD64_BIT(VARYING_SLOT_TESS_LEVEL_INNER)
+#define VARYING_BIT_BOUNDING_BOX0 BITFIELD64_BIT(VARYING_SLOT_BOUNDING_BOX0)
+#define VARYING_BIT_BOUNDING_BOX1 BITFIELD64_BIT(VARYING_SLOT_BOUNDING_BOX1)
 #define VARYING_BIT_VAR(V) BITFIELD64_BIT(VARYING_SLOT_VAR0 + (V))
 /*@}*/
 
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 88438f0..3c6e1f4 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -110,6 +110,8 @@ _mesa_varying_slot_in_fs(gl_varying_slot slot)
case VARYING_SLOT_LAYER:
case VARYING_SLOT_TESS_LEVEL_OUTER:
case VARYING_SLOT_TESS_LEVEL_INNER:
+   case VARYING_SLOT_BOUNDING_BOX0:
+   case VARYING_SLOT_BOUNDING_BOX1:
   return GL_FALSE;
default:
   return GL_TRUE;
diff --git a/src/mesa/program/prog_print.c b/src/mesa/program/prog_print.c
index 755d644..4116a6f 100644
--- a/src/mesa/program/prog_print.c
+++ b/src/mesa/program/prog_print.c
@@ -151,6 +151,8 @@ arb_input_attrib_string(GLuint index, GLenum progType)
   "fragment.(twenty-five)", /* VARYING_SLOT_TESS_LEVEL_INNER */
   "fragment.(twenty-six)", /* VARYING_SLOT_CULL_DIST0 */
   "fragment.(twenty-seven)", /* 

[Mesa-dev] [PATCH 2/3] mesa: add support for GL_PRIMITIVE_BOUNDING_BOX storage and query

2016-05-30 Thread Ilia Mirkin
Signed-off-by: Ilia Mirkin 
---
 src/mesa/main/bbox.c | 19 +++
 src/mesa/main/get.c  | 28 
 src/mesa/main/get_hash_params.py |  3 +++
 src/mesa/main/mtypes.h   |  7 +++
 4 files changed, 57 insertions(+)

diff --git a/src/mesa/main/bbox.c b/src/mesa/main/bbox.c
index 0ef5705..2184330 100644
--- a/src/mesa/main/bbox.c
+++ b/src/mesa/main/bbox.c
@@ -36,9 +36,28 @@ _mesa_PrimitiveBoundingBox(
   GLfloat minX, GLfloat minY, GLfloat minZ, GLfloat minW,
   GLfloat maxX, GLfloat maxY, GLfloat maxZ, GLfloat maxW)
 {
+   GET_CURRENT_CONTEXT(ctx);
+
+   ctx->PrimitiveBoundingBox[0] = minX;
+   ctx->PrimitiveBoundingBox[1] = minY;
+   ctx->PrimitiveBoundingBox[2] = minZ;
+   ctx->PrimitiveBoundingBox[3] = minW;
+   ctx->PrimitiveBoundingBox[4] = maxX;
+   ctx->PrimitiveBoundingBox[5] = maxY;
+   ctx->PrimitiveBoundingBox[6] = maxZ;
+   ctx->PrimitiveBoundingBox[7] = maxW;
 }
 
 void
 _mesa_init_bbox(struct gl_context *ctx)
 {
+   ctx->PrimitiveBoundingBox[0] =
+   ctx->PrimitiveBoundingBox[1] =
+   ctx->PrimitiveBoundingBox[2] = -1.0f;
+
+   ctx->PrimitiveBoundingBox[3] =
+   ctx->PrimitiveBoundingBox[4] =
+   ctx->PrimitiveBoundingBox[5] =
+   ctx->PrimitiveBoundingBox[6] =
+   ctx->PrimitiveBoundingBox[7] = 1.0f;
 }
diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c
index 9f70749..8d74b2e 100644
--- a/src/mesa/main/get.c
+++ b/src/mesa/main/get.c
@@ -111,6 +111,7 @@ enum value_type {
TYPE_FLOAT_2,
TYPE_FLOAT_3,
TYPE_FLOAT_4,
+   TYPE_FLOAT_8,
TYPE_FLOATN,
TYPE_FLOATN_2,
TYPE_FLOATN_3,
@@ -218,6 +219,7 @@ union value {
 #define CONTEXT_FLOAT2(field) CONTEXT_FIELD(field, TYPE_FLOAT_2)
 #define CONTEXT_FLOAT3(field) CONTEXT_FIELD(field, TYPE_FLOAT_3)
 #define CONTEXT_FLOAT4(field) CONTEXT_FIELD(field, TYPE_FLOAT_4)
+#define CONTEXT_FLOAT8(field) CONTEXT_FIELD(field, TYPE_FLOAT_8)
 #define CONTEXT_MATRIX(field) CONTEXT_FIELD(field, TYPE_MATRIX)
 #define CONTEXT_MATRIX_T(field) CONTEXT_FIELD(field, TYPE_MATRIX_T)
 
@@ -464,6 +466,7 @@ EXTRA_EXT(ARB_indirect_parameters);
 EXTRA_EXT(ATI_meminfo);
 EXTRA_EXT(NVX_gpu_memory_info);
 EXTRA_EXT(ARB_cull_distance);
+EXTRA_EXT(OES_primitive_bounding_box);
 
 static const int
 extra_ARB_color_buffer_float_or_glcore[] = {
@@ -1446,6 +1449,11 @@ _mesa_GetBooleanv(GLenum pname, GLboolean *params)
   params[0] = INT_TO_BOOLEAN(d->offset);
   break;
 
+   case TYPE_FLOAT_8:
+  params[7] = FLOAT_TO_BOOLEAN(((GLfloat *) p)[7]);
+  params[6] = FLOAT_TO_BOOLEAN(((GLfloat *) p)[6]);
+  params[5] = FLOAT_TO_BOOLEAN(((GLfloat *) p)[5]);
+  params[4] = FLOAT_TO_BOOLEAN(((GLfloat *) p)[4]);
case TYPE_FLOAT_4:
case TYPE_FLOATN_4:
   params[3] = FLOAT_TO_BOOLEAN(((GLfloat *) p)[3]);
@@ -1534,6 +1542,11 @@ _mesa_GetFloatv(GLenum pname, GLfloat *params)
   params[0] = (GLfloat) d->offset;
   break;
 
+   case TYPE_FLOAT_8:
+  params[7] = ((GLfloat *) p)[7];
+  params[6] = ((GLfloat *) p)[6];
+  params[5] = ((GLfloat *) p)[5];
+  params[4] = ((GLfloat *) p)[4];
case TYPE_FLOAT_4:
case TYPE_FLOATN_4:
   params[3] = ((GLfloat *) p)[3];
@@ -1622,6 +1635,11 @@ _mesa_GetIntegerv(GLenum pname, GLint *params)
   params[0] = d->offset;
   break;
 
+   case TYPE_FLOAT_8:
+  params[7] = IROUND(((GLfloat *) p)[7]);
+  params[6] = IROUND(((GLfloat *) p)[6]);
+  params[5] = IROUND(((GLfloat *) p)[5]);
+  params[4] = IROUND(((GLfloat *) p)[4]);
case TYPE_FLOAT_4:
   params[3] = IROUND(((GLfloat *) p)[3]);
case TYPE_FLOAT_3:
@@ -1716,6 +1734,11 @@ _mesa_GetInteger64v(GLenum pname, GLint64 *params)
   params[0] = d->offset;
   break;
 
+   case TYPE_FLOAT_8:
+  params[7] = IROUND64(((GLfloat *) p)[7]);
+  params[6] = IROUND64(((GLfloat *) p)[6]);
+  params[5] = IROUND64(((GLfloat *) p)[5]);
+  params[4] = IROUND64(((GLfloat *) p)[4]);
case TYPE_FLOAT_4:
   params[3] = IROUND64(((GLfloat *) p)[3]);
case TYPE_FLOAT_3:
@@ -1810,6 +1833,11 @@ _mesa_GetDoublev(GLenum pname, GLdouble *params)
   params[0] = d->offset;
   break;
 
+   case TYPE_FLOAT_8:
+  params[7] = ((GLfloat *) p)[7];
+  params[6] = ((GLfloat *) p)[6];
+  params[5] = ((GLfloat *) p)[5];
+  params[4] = ((GLfloat *) p)[4];
case TYPE_FLOAT_4:
case TYPE_FLOATN_4:
   params[3] = ((GLfloat *) p)[3];
diff --git a/src/mesa/main/get_hash_params.py b/src/mesa/main/get_hash_params.py
index 2124072..173c076 100644
--- a/src/mesa/main/get_hash_params.py
+++ b/src/mesa/main/get_hash_params.py
@@ -556,6 +556,9 @@ descriptor=[
 
 # GL_ARB_texture_buffer_range
   [ "TEXTURE_BUFFER_OFFSET_ALIGNMENT", 
"CONTEXT_INT(Const.TextureBufferOffsetAlignment), 
extra_ARB_texture_buffer_range" ],
+
+# GL_OES_primitive_bounding_box
+  [ "PRIMITIVE_BOUNDING_BOX_ARB", "CONTEXT_FLOAT8(PrimitiveBoundingBox), 
extra_OES_primitive_bounding_box" ],
 ]},
 
 # Remaining enums 

[Mesa-dev] [PATCH 1/3] mesa: add scaffolding for OES/EXT_primitive_bounding_box

2016-05-30 Thread Ilia Mirkin
Signed-off-by: Ilia Mirkin 
---
 src/compiler/glsl/glsl_parser_extras.cpp |  2 ++
 src/compiler/glsl/glsl_parser_extras.h   |  4 +++
 src/mapi/glapi/gen/es_EXT.xml| 49 
 src/mapi/glapi/gen/gl_genexec.py |  1 +
 src/mesa/Makefile.sources|  2 ++
 src/mesa/main/bbox.c | 44 
 src/mesa/main/bbox.h | 42 +++
 src/mesa/main/context.c  |  2 ++
 src/mesa/main/extensions_table.h |  2 ++
 src/mesa/main/mtypes.h   |  1 +
 10 files changed, 149 insertions(+)
 create mode 100644 src/mesa/main/bbox.c
 create mode 100644 src/mesa/main/bbox.h

diff --git a/src/compiler/glsl/glsl_parser_extras.cpp 
b/src/compiler/glsl/glsl_parser_extras.cpp
index fc73a7e..7b2a150 100644
--- a/src/compiler/glsl/glsl_parser_extras.cpp
+++ b/src/compiler/glsl/glsl_parser_extras.cpp
@@ -625,6 +625,7 @@ static const _mesa_glsl_extension 
_mesa_glsl_supported_extensions[] = {
EXT(OES_geometry_point_size,false, true,  OES_geometry_shader),
EXT(OES_geometry_shader,false, true,  OES_geometry_shader),
EXT(OES_gpu_shader5,false, true,  ARB_gpu_shader5),
+   EXT(OES_primitive_bounding_box, false, true,  
OES_primitive_bounding_box),
EXT(OES_sample_variables,   false, true,  OES_sample_variables),
EXT(OES_shader_image_atomic,false, true,  
ARB_shader_image_load_store),
EXT(OES_shader_io_blocks,   false, true,  OES_shader_io_blocks),
@@ -645,6 +646,7 @@ static const _mesa_glsl_extension 
_mesa_glsl_supported_extensions[] = {
EXT(EXT_draw_buffers,   false,  true, dummy_true),
EXT(EXT_clip_cull_distance, false, true,  ARB_cull_distance),
EXT(EXT_gpu_shader5,false, true,  ARB_gpu_shader5),
+   EXT(EXT_primitive_bounding_box, false, true,  
OES_primitive_bounding_box),
EXT(EXT_separate_shader_objects,false, true,  dummy_true),
EXT(EXT_shader_integer_mix, true,  true,  
EXT_shader_integer_mix),
EXT(EXT_shader_io_blocks,   false, true,  OES_shader_io_blocks),
diff --git a/src/compiler/glsl/glsl_parser_extras.h 
b/src/compiler/glsl/glsl_parser_extras.h
index 8c43292..622a809 100644
--- a/src/compiler/glsl/glsl_parser_extras.h
+++ b/src/compiler/glsl/glsl_parser_extras.h
@@ -631,6 +631,8 @@ struct _mesa_glsl_parse_state {
bool OES_geometry_shader_warn;
bool OES_gpu_shader5_enable;
bool OES_gpu_shader5_warn;
+   bool OES_primitive_bounding_box_enable;
+   bool OES_primitive_bounding_box_warn;
bool OES_sample_variables_enable;
bool OES_sample_variables_warn;
bool OES_shader_image_atomic_enable;
@@ -668,6 +670,8 @@ struct _mesa_glsl_parse_state {
bool EXT_draw_buffers_warn;
bool EXT_gpu_shader5_enable;
bool EXT_gpu_shader5_warn;
+   bool EXT_primitive_bounding_box_enable;
+   bool EXT_primitive_bounding_box_warn;
bool EXT_separate_shader_objects_enable;
bool EXT_separate_shader_objects_warn;
bool EXT_shader_integer_mix_enable;
diff --git a/src/mapi/glapi/gen/es_EXT.xml b/src/mapi/glapi/gen/es_EXT.xml
index 6886dab..23f75c9 100644
--- a/src/mapi/glapi/gen/es_EXT.xml
+++ b/src/mapi/glapi/gen/es_EXT.xml
@@ -924,6 +924,21 @@
 
 
 
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
 http://www.w3.org/2001/XInclude"/>
 
 
@@ -1079,6 +1094,21 @@
 
 
 
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
 
 
 
@@ -1297,4 +1327,23 @@
 
 
 
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
 
diff --git a/src/mapi/glapi/gen/gl_genexec.py b/src/mapi/glapi/gen/gl_genexec.py
index 72d7b6f..fe85e95 100644
--- a/src/mapi/glapi/gen/gl_genexec.py
+++ b/src/mapi/glapi/gen/gl_genexec.py
@@ -56,6 +56,7 @@ header = """/**
 #include "main/blit.h"
 #include "main/bufferobj.h"
 #include "main/arrayobj.h"
+#include "main/bbox.h"
 #include "main/buffers.h"
 #include "main/clear.h"
 #include "main/clip.h"
diff --git a/src/mesa/Makefile.sources b/src/mesa/Makefile.sources
index 5f7f46d..c9e55a1 100644
--- a/src/mesa/Makefile.sources
+++ b/src/mesa/Makefile.sources
@@ -24,6 +24,8 @@ MAIN_FILES = \
main/atifragshader.h \
main/attrib.c \
main/attrib.h \
+   main/bbox.c \
+   main/bbox.h \
main/blend.c \
main/blend.h \
main/blit.c \
diff --git a/src/mesa/main/bbox.c b/src/mesa/main/bbox.c
new file mode 100644
index 000..0ef5705
--- /dev/null
+++ b/src/mesa/main/bbox.c
@@ -0,0 +1,44 @@
+/*
+ * Mesa 3-D graphics library
+ *
+ * Copyright (C) 2016 Ilia Mirkin.  All Rights Reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of 

Re: [Mesa-dev] [PATCH] mesa: Enable LTO compilation

2016-05-30 Thread Rob Clark
On Mon, May 30, 2016 at 1:39 PM, Matt Turner  wrote:
> On Mon, May 30, 2016 at 10:28 AM, ⚛ <0xe2.0x9a.0...@gmail.com> wrote:
>> This patch enables compilation with -flto.
>>
>> The performance benefits of LTO (GCC 4.9 & 6.1) are about 1% for glxgears.
>> Performance changes in OpenGL games haven't been measured yet, my feeling is
>> that they are negligible.
>
> Without a compelling reason, I don't think the build system should be
> adding compiler flags like this.
>
> -flto makes debugging impossible, at least the last time I tried it
> with gcc. I don't think that's something we would want enabled
> whenever it's supported.

It would be interesting to know what gains it brings in scenarios less
synthetic than glxgears..  my suspicion is that we have been doing
manual lto forever (ie. use of static-inline fxn's where it matters).
If it turns out to be a significant gain, I wouldn't be against it.
Although perhaps only for non-debug builds..

BR,
-R

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


Re: [Mesa-dev] [PATCH v3 08/14] i965: Add CS push constant info to brw_cs_prog_data

2016-05-30 Thread Jason Ekstrand
On Sun, May 29, 2016 at 3:38 PM, Jordan Justen 
wrote:

> We need information about push constants in a few places for the GL
> driver, and another couple places for the vulkan driver.
>
> When we add support for uploading both a common (cross-thread) set of
> push constants, combined with the previous per-thread push constant
> data, things are going to get even more complicated. To simplify
> things, we add push constant info into the cs prog_data struct.
>
> The cross-thread constant support is added as of Haswell. To support
> it we need to make sure all push constants with uniform values are
> added to earlier registers. The register that varies per thread and
> holds the thread invocation's unique local ID needs to be added last.
>
> Signed-off-by: Jordan Justen 
> ---
>  src/mesa/drivers/dri/i965/brw_compiler.h | 12 +++
>  src/mesa/drivers/dri/i965/brw_fs.cpp | 58
> 
>  2 files changed, 70 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_compiler.h
> b/src/mesa/drivers/dri/i965/brw_compiler.h
> index f1f9e56..dda6297 100644
> --- a/src/mesa/drivers/dri/i965/brw_compiler.h
> +++ b/src/mesa/drivers/dri/i965/brw_compiler.h
> @@ -424,6 +424,12 @@ struct brw_wm_prog_data {
> int urb_setup[VARYING_SLOT_MAX];
>  };
>
> +struct brw_push_const_block {
> +   unsigned dwords; /* Dword count, not reg aligned */
> +   unsigned regs;
> +   unsigned size;   /* Bytes, register aligned */
> +};
> +
>  struct brw_cs_prog_data {
> struct brw_stage_prog_data base;
>
> @@ -437,6 +443,12 @@ struct brw_cs_prog_data {
> int thread_local_id_index;
>
> struct {
> +  struct brw_push_const_block cross_thread;
> +  struct brw_push_const_block per_thread;
> +  struct brw_push_const_block total;
> +   } push;
> +
> +   struct {
>/** @{
> * surface indices the CS-specific surfaces
> */
> diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
> b/src/mesa/drivers/dri/i965/brw_fs.cpp
> index 836ade0..bd37fbd 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
> @@ -6479,6 +6479,61 @@ fs_visitor::emit_cs_work_group_id_setup()
>  }
>
>  static void
> +fill_push_const_block_info(struct brw_push_const_block *block, unsigned
> dwords)
> +{
> +   block->dwords = dwords;
> +   block->regs = DIV_ROUND_UP(dwords, 8);
> +   block->size = block->regs * 32;
> +}
> +
> +static void
> +cs_fill_push_const_info(const struct brw_device_info *devinfo,
> +struct brw_cs_prog_data *cs_prog_data)
> +{
> +   const struct brw_stage_prog_data *prog_data =
> +  (struct brw_stage_prog_data*) cs_prog_data;
> +   bool fill_thread_id =
> +  cs_prog_data->thread_local_id_index >= 0 &&
> +  cs_prog_data->thread_local_id_index < (int)prog_data->nr_params;
> +   bool cross_thread_supported = devinfo->gen > 7 || devinfo->is_haswell;
> +
> +   /* The thread ID should be stored in the last param dword */
> +   assert(prog_data->nr_params > 0 || !fill_thread_id);
> +   assert(!fill_thread_id ||
> +  cs_prog_data->thread_local_id_index ==
> + (int)prog_data->nr_params - 1);
> +
> +   unsigned cross_thread_dwords, per_thread_dwords;
> +   if (cross_thread_supported && fill_thread_id) {
> +  /* Fill all but the last register with cross-thread payload */
> +  cross_thread_dwords = 8 * (cs_prog_data->thread_local_id_index / 8);
> +  per_thread_dwords = prog_data->nr_params - cross_thread_dwords;
> +  assert(per_thread_dwords > 0 && per_thread_dwords <= 8);
>

If I understand you correctly here, you're putting the bottom registers
(aligned down to 8) into the cross-thread space and putting whatever is
left including the thread_local_id into the per-thread space.  Seems
reasonable.  I probably would have been more lazy and burned a whole
register on the local_id. :-)


> +   } else if (cross_thread_supported && !fill_thread_id) {
> +  /* Fill all data using cross-thread payload */
> +  cross_thread_dwords = prog_data->nr_params;
> +  per_thread_dwords = 0u;
> +   } else {
> +  cross_thread_dwords = 0u;
> +  per_thread_dwords = prog_data->nr_params;
>

Mind putting the !cross_thread_supported case first?


> +   }
> +
> +   fill_push_const_block_info(_prog_data->push.cross_thread,
> cross_thread_dwords);
> +   fill_push_const_block_info(_prog_data->push.per_thread,
> per_thread_dwords);
> +
> +   unsigned total_dwords =
> +  (cs_prog_data->push.per_thread.size * cs_prog_data->threads +
> +   cs_prog_data->push.cross_thread.size) / 4;
> +   fill_push_const_block_info(_prog_data->push.total, total_dwords);
> +
> +   assert(cs_prog_data->push.cross_thread.dwords % 8 == 0 ||
> +  cs_prog_data->push.per_thread.size == 0);
> +   assert(cs_prog_data->push.cross_thread.dwords +
> +  cs_prog_data->push.per_thread.dwords ==
> +  prog_data->nr_params);
> +}
> +
> 

Re: [Mesa-dev] [PATCH v3 07/14] i965: Store number of threads in brw_cs_prog_data

2016-05-30 Thread Jason Ekstrand
Can the Vulkan driver take advantage of this too?

On Sun, May 29, 2016 at 3:38 PM, Jordan Justen 
wrote:

> Signed-off-by: Jordan Justen 
> ---
>  src/mesa/drivers/dri/i965/brw_compiler.h  |  1 +
>  src/mesa/drivers/dri/i965/brw_fs.cpp  | 15 ---
>  src/mesa/drivers/dri/i965/gen7_cs_state.c | 32
> ++-
>  3 files changed, 23 insertions(+), 25 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_compiler.h
> b/src/mesa/drivers/dri/i965/brw_compiler.h
> index bed969c..f1f9e56 100644
> --- a/src/mesa/drivers/dri/i965/brw_compiler.h
> +++ b/src/mesa/drivers/dri/i965/brw_compiler.h
> @@ -430,6 +430,7 @@ struct brw_cs_prog_data {
> GLuint dispatch_grf_start_reg_16;
> unsigned local_size[3];
> unsigned simd_size;
> +   unsigned threads;
> bool uses_barrier;
> bool uses_num_work_groups;
> unsigned local_invocation_id_regs;
> diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
> b/src/mesa/drivers/dri/i965/brw_fs.cpp
> index cbcde68..836ade0 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
> @@ -6478,6 +6478,15 @@ fs_visitor::emit_cs_work_group_id_setup()
> return reg;
>  }
>
> +static void
> +cs_set_simd_size(struct brw_cs_prog_data *cs_prog_data, unsigned size)
> +{
> +   cs_prog_data->simd_size = size;
> +   unsigned group_size = cs_prog_data->local_size[0] *
> +  cs_prog_data->local_size[1] * cs_prog_data->local_size[2];
> +   cs_prog_data->threads = (group_size + size - 1) / size;
> +}
> +
>  const unsigned *
>  brw_compile_cs(const struct brw_compiler *compiler, void *log_data,
> void *mem_ctx,
> @@ -6526,7 +6535,7 @@ brw_compile_cs(const struct brw_compiler *compiler,
> void *log_data,
>   fail_msg = v8.fail_msg;
>} else {
>   cfg = v8.cfg;
> - prog_data->simd_size = 8;
> + cs_set_simd_size(prog_data, 8);
>   prog_data->base.dispatch_grf_start_reg = v8.payload.num_regs;
>}
> }
> @@ -6551,7 +6560,7 @@ brw_compile_cs(const struct brw_compiler *compiler,
> void *log_data,
>   }
>} else {
>   cfg = v16.cfg;
> - prog_data->simd_size = 16;
> + cs_set_simd_size(prog_data, 16);
>   prog_data->dispatch_grf_start_reg_16 = v16.payload.num_regs;
>}
> }
> @@ -6578,7 +6587,7 @@ brw_compile_cs(const struct brw_compiler *compiler,
> void *log_data,
>   }
>} else {
>   cfg = v32.cfg;
> - prog_data->simd_size = 32;
> + cs_set_simd_size(prog_data, 32);
>}
> }
>
> diff --git a/src/mesa/drivers/dri/i965/gen7_cs_state.c
> b/src/mesa/drivers/dri/i965/gen7_cs_state.c
> index 7f484dd..619edfb 100644
> --- a/src/mesa/drivers/dri/i965/gen7_cs_state.c
> +++ b/src/mesa/drivers/dri/i965/gen7_cs_state.c
> @@ -33,17 +33,6 @@
>  #include "program/prog_statevars.h"
>  #include "compiler/glsl/ir_uniform.h"
>
> -static unsigned
> -get_cs_thread_count(const struct brw_cs_prog_data *cs_prog_data)
> -{
> -   const unsigned simd_size = cs_prog_data->simd_size;
> -   unsigned group_size = cs_prog_data->local_size[0] *
> -  cs_prog_data->local_size[1] * cs_prog_data->local_size[2];
> -
> -   return (group_size + simd_size - 1) / simd_size;
> -}
> -
> -
>  static void
>  brw_upload_cs_state(struct brw_context *brw)
>  {
> @@ -79,7 +68,6 @@ brw_upload_cs_state(struct brw_context *brw)
>(prog_data->nr_params + local_id_dwords) *
> sizeof(gl_constant_value);
> unsigned reg_aligned_constant_size = ALIGN(push_constant_data_size,
> 32);
> unsigned push_constant_regs = reg_aligned_constant_size / 32;
> -   unsigned threads = get_cs_thread_count(cs_prog_data);
>
> uint32_t dwords = brw->gen < 8 ? 8 : 9;
> BEGIN_BATCH(dwords);
> @@ -129,7 +117,8 @@ brw_upload_cs_state(struct brw_context *brw)
>  *
>  * Note: The constant data is built in brw_upload_cs_push_constants
> below.
>  */
> -   const uint32_t vfe_curbe_allocation = push_constant_regs * threads;
> +   const uint32_t vfe_curbe_allocation =
> +  push_constant_regs * cs_prog_data->threads;
> OUT_BATCH(SET_FIELD(vfe_urb_allocation, MEDIA_VFE_STATE_URB_ALLOC) |
>   SET_FIELD(vfe_curbe_allocation,
> MEDIA_VFE_STATE_CURBE_ALLOC));
> OUT_BATCH(0);
> @@ -141,7 +130,7 @@ brw_upload_cs_state(struct brw_context *brw)
>BEGIN_BATCH(4);
>OUT_BATCH(MEDIA_CURBE_LOAD << 16 | (4 - 2));
>OUT_BATCH(0);
> -  OUT_BATCH(ALIGN(reg_aligned_constant_size * threads, 64));
> +  OUT_BATCH(ALIGN(reg_aligned_constant_size * cs_prog_data->threads,
> 64));
>OUT_BATCH(stage_state->push_const_offset);
>ADVANCE_BATCH();
> }
> @@ -163,9 +152,9 @@ brw_upload_cs_state(struct brw_context *brw)
> desc[dw++] = SET_FIELD(push_constant_regs, MEDIA_CURBE_READ_LENGTH);
> const uint32_t media_threads =
>brw->gen >= 8 ?
> -  SET_FIELD(threads, 

Re: [Mesa-dev] [PATCH v3 06/14] i965: Add nir based intrinsic lowering and thread ID uniform

2016-05-30 Thread Jason Ekstrand
On Sun, May 29, 2016 at 3:38 PM, Jordan Justen 
wrote:

> We add a lowering pass for nir intrinsics. This pass can replace nir
> intrinsics with driver specific nir lower code.
>
> We lower the gl_LocalInvocationIndex intrinsic based on a uniform
> which is loaded with a thread specific ID.
>
> We also lower the gl_LocalInvocationID based on
> gl_LocalInvocationIndex.
>
> v2:
>  * Create variable during lowering pass. (Ken)
>
> v3:
>  * Don't create a variable, but instead just insert an intrisic call
>to load a uniform from the allocated location. (Jason)
>
> Signed-off-by: Jordan Justen 
> ---
>  src/mesa/drivers/dri/i965/Makefile.sources |   1 +
>  src/mesa/drivers/dri/i965/brw_nir.h|   2 +
>  src/mesa/drivers/dri/i965/brw_nir_intrinsics.c | 177
> +
>  3 files changed, 180 insertions(+)
>  create mode 100644 src/mesa/drivers/dri/i965/brw_nir_intrinsics.c
>
> diff --git a/src/mesa/drivers/dri/i965/Makefile.sources
> b/src/mesa/drivers/dri/i965/Makefile.sources
> index d8711ed..f448551 100644
> --- a/src/mesa/drivers/dri/i965/Makefile.sources
> +++ b/src/mesa/drivers/dri/i965/Makefile.sources
> @@ -46,6 +46,7 @@ i965_compiler_FILES = \
> brw_nir.c \
> brw_nir_analyze_boolean_resolves.c \
> brw_nir_attribute_workarounds.c \
> +   brw_nir_intrinsics.c \
> brw_nir_opt_peephole_ffma.c \
> brw_packed_float.c \
> brw_predicated_break.cpp \
> diff --git a/src/mesa/drivers/dri/i965/brw_nir.h
> b/src/mesa/drivers/dri/i965/brw_nir.h
> index 409e49a..74c354f 100644
> --- a/src/mesa/drivers/dri/i965/brw_nir.h
> +++ b/src/mesa/drivers/dri/i965/brw_nir.h
> @@ -91,6 +91,8 @@ void brw_nir_analyze_boolean_resolves(nir_shader *nir);
>  nir_shader *brw_preprocess_nir(const struct brw_compiler *compiler,
> nir_shader *nir);
>
> +bool brw_nir_lower_intrinsics(nir_shader *nir,
> +  struct brw_stage_prog_data *prog_data);
>  void brw_nir_lower_vs_inputs(nir_shader *nir,
>   const struct brw_device_info *devinfo,
>   bool is_scalar,
> diff --git a/src/mesa/drivers/dri/i965/brw_nir_intrinsics.c
> b/src/mesa/drivers/dri/i965/brw_nir_intrinsics.c
> new file mode 100644
> index 000..02816e7
> --- /dev/null
> +++ b/src/mesa/drivers/dri/i965/brw_nir_intrinsics.c
> @@ -0,0 +1,177 @@
> +/*
> + * Copyright (c) 2016 Intel Corporation
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the
> "Software"),
> + * to deal in the Software without restriction, including without
> limitation
> + * the rights to use, copy, modify, merge, publish, distribute,
> sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the
> next
> + * paragraph) shall be included in all copies or substantial portions of
> the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT
> SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
> OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> DEALINGS
> + * IN THE SOFTWARE.
> + */
> +
> +#include "brw_nir.h"
> +#include "compiler/nir/nir_builder.h"
> +
> +struct lower_intrinsics_state {
> +   nir_shader *nir;
> +   union {
> +  struct brw_stage_prog_data *prog_data;
> +  struct brw_cs_prog_data *cs_prog_data;
> +   };
> +   nir_function_impl *impl;
> +   bool progress;
> +   nir_builder builder;
> +   bool cs_thread_id_used;
> +};
> +
> +static int
> +get_cs_local_id_uniform_index(struct lower_intrinsics_state *state)
> +{
> +   assert(state->cs_prog_data->thread_local_id_index >= 0);
> +   state->cs_thread_id_used = true;
> +   return state->cs_prog_data->thread_local_id_index;
>

Maybe create the actual load_uniform intrinsic here?  It doesn't much
matter given that it's called exactly once.


> +}
> +
> +static bool
> +lower_cs_intrinsics_convert_block(struct lower_intrinsics_state *state,
> +  nir_block *block)
> +{
> +   bool progress = false;
> +   nir_builder *b = >builder;
> +   nir_shader *nir = state->nir;
> +
> +   nir_foreach_instr_safe(instr, block) {
> +  if (instr->type != nir_instr_type_intrinsic)
> + continue;
> +
> +  nir_intrinsic_instr *intrinsic = nir_instr_as_intrinsic(instr);
> +
> +  b->cursor = nir_after_instr(>instr);
> +
> +  nir_ssa_def *sysval;
> +  

Re: [Mesa-dev] [PATCH] mesa: Enable LTO compilation

2016-05-30 Thread Matt Turner
On Mon, May 30, 2016 at 10:28 AM, ⚛ <0xe2.0x9a.0...@gmail.com> wrote:
> This patch enables compilation with -flto.
>
> The performance benefits of LTO (GCC 4.9 & 6.1) are about 1% for glxgears.
> Performance changes in OpenGL games haven't been measured yet, my feeling is
> that they are negligible.

Without a compelling reason, I don't think the build system should be
adding compiler flags like this.

-flto makes debugging impossible, at least the last time I tried it
with gcc. I don't think that's something we would want enabled
whenever it's supported.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 23/25] i965/fs: Allow scalar source regions on SNB math instructions.

2016-05-30 Thread Matt Turner
On Fri, May 27, 2016 at 7:06 PM, Francisco Jerez  wrote:
> I haven't found any evidence that this isn't supported by the
> hardware, in fact according to the SNB hardware spec:
>
>  "The supported regioning modes for math instructions are align16,
>   align1 with the following restrictions:
>- Scalar source is supported.
>   [...]
>- Source and destination offset must be the same, except the case of
>  scalar source."

Strange. I added code to copy propagate to handle this, fixing some
regressions in

commit 7f5a8ac155283e78df2da5b172a65361a80d38b6
Author: Matt Turner 
Date:   Sat Apr 25 01:50:04 2015 -0700

i965/fs: Disallow constant propagation into POW on Gen 6.

Fixes assertion failures in three piglit tests on Gen 6 since commit
0087cf23e.

I'd like to run piglit before and after that commit and see what
changed on Sandybridge. I'll push it to Jenkins.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH] mesa: Enable LTO compilation

2016-05-30 Thread
This patch enables compilation with -flto.

The performance benefits of LTO (GCC 4.9 & 6.1) are about 1% for glxgears.
Performance changes in OpenGL games haven't been measured yet, my feeling
is that they are negligible.
diff --git a/configure.ac b/configure.ac
index fc0b1db..e84a1ad 100644
--- a/configure.ac
+++ b/configure.ac
@@ -362,6 +362,8 @@ if test "x$GXX" = xyes; then
 CXXFLAGS="$CXXFLAGS -fno-builtin-memcmp"
 fi
 
+AX_CHECK_COMPILE_FLAG([-flto], AM_CONDITIONAL(COMPILER_UNDERSTANDS_LTO, true), AM_CONDITIONAL(COMPILER_UNDERSTANDS_LTO, false))
+
 AC_SUBST([MSVC2013_COMPAT_CFLAGS])
 AC_SUBST([MSVC2013_COMPAT_CXXFLAGS])
 
diff --git a/src/mapi/Makefile.am b/src/mapi/Makefile.am
index 68a28a2..4b7d266 100644
--- a/src/mapi/Makefile.am
+++ b/src/mapi/Makefile.am
@@ -51,6 +51,11 @@ AM_CPPFLAGS =			\
 
 include Makefile.sources
 
+if COMPILER_UNDERSTANDS_LTO
+CFLAGS += -fno-lto
+CXXFLAGS += -fno-lto
+endif
+
 MKDIR_GEN = $(AM_V_at)$(MKDIR_P) $(@D)
 PYTHON_GEN = $(AM_V_GEN)$(PYTHON2) $(PYTHON_FLAGS)
 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 00/25] i965: Scalar back-end support for SIMD32, part 4.

2016-05-30 Thread Jason Ekstrand
On Sun, May 29, 2016 at 12:01 PM, Francisco Jerez 
wrote:

> Francisco Jerez  writes:
>
> > Jason Ekstrand  writes:
> >
> >> On Fri, May 27, 2016 at 7:05 PM, Francisco Jerez  >
> >> wrote:
> >>
> >>> This fixes the few code quality regressions from the previous series
> >>> enabling SIMD32 CS codegen in the back-end -- AFAICT by the end of the
> >>> series we can finally enable GL 4.3 on all Gen8+ hardware.
> >>>
> >>> Patches 1-8 delay the SIMD lowering pass after the bulk of
> >>> optimization passes have been run, which should decrease the
> >>> compilation time of mainly SIMD32 shaders and improve the code quality
> >>> of SIMD32 shaders on all generations and shaders of any dispatch width
> >>> on older generations (up to and including IVB) that use SIMD lowering
> >>> more intensively to implement various workarounds.
> >>>
> >>> Patches 9-14 rework the SIMD lowering pass to avoid emitting the copy
> >>> instructions used to zip and unzip register regions where possible,
> >>> since the register coalesce and copy propagation passes seem to
> >>> perform rather poorly at getting rid of them in some cases.  In the
> >>> long term we'll likely want to improve the register coalesce pass
> >>> irrespective of these changes.
> >>>
> >>> Patches 15-20 improve the compute-to-mrf pass used on Gen4-6 to handle
> >>> cases where the source of a VGRF-to-MRF copy is initialized by the
> >>> shader using multiple single-GRF writes, which becomes far more common
> >>> with the additional SIMD lowering going on after this series.
> >>>
> >>> Patches 21-24 are some other assorted changes improving code quality
> >>> on older gens.
> >>>
> >>> I wanted to provide more detailed (e.g. per commit) shader-db stats
> >>> with this series, but kind of ran out of time.  Let me know if you
> >>> would like to see more evidence that any of the changes below is
> >>> improving code quality in case it's not clear from the commit alone.
> >>>
> >>> [PATCH 01/25] i965/fs: Let CSE handle logical sampler sends as
> expressions.
> >>> [PATCH 02/25] i965/fs: Allow constant propagation into logical send
> >>> sources.
> >>> [PATCH 03/25] i965/fs: Add FS_OPCODE_FB_WRITE_LOGICAL to
> >>> has_side_effects().
> >>> [PATCH 04/25] i965/fs: Run SIMD and logical send lowering after the
> >>> optimization loop.
> >>> [PATCH 05/25] i965/fs: Take opt_redundant_discard_jumps out of the
> >>> optimization loop.
> >>> [PATCH 06/25] i965/fs: Fix UB list sentinel dereference in
> >>> opt_sampler_eot().
> >>> [PATCH 07/25] i965/fs: Implement opt_sampler_eot() in terms of logical
> >>> sends.
> >>
> >> [PATCH 08/25] SQUASH: i965/fs: Add basic dataflow check to
> >>> opt_sampler_eot().
> >>>
> >>
> >>
> >>> [PATCH 09/25] i965/fs: Refactor offset() into a separate function
> taking
> >>> the width as argument.
> >>> [PATCH 10/25] i965/fs: Generalize regions_overlap() from copy
> propagation
> >>> to handle non-VGRF files.
> >>> [PATCH 11/25] i965/fs: Factor out region zipping and unzipping from the
> >>> SIMD lowering pass.
> >>> [PATCH 12/25] i965/fs: Skip SIMD lowering source unzipping for regular
> >>> scalar regions.
> >>> [PATCH 13/25] i965/fs: Skip SIMD lowering destination zipping if
> possible.
> >>> [PATCH 14/25] i965/fs: Reindent emit_zip().
> >>>
> >>
> >> 9-14 Reviewed-by: Jason Ekstrand 
> >>
> >>
> >>> [PATCH 15/25] i965/fs: Teach regions_overlap() about COMPR4 MRF
> regions.
> >>> [PATCH 16/25] i965/fs: Simplify and improve accuracy of
> compute_to_mrf()
> >>> by using regions_overlap().
> >>> [PATCH 17/25] i965/fs: Fix compute-to-mrf VGRF region coverage
> condition.
> >>> [PATCH 18/25] i965/fs: Refactor compute_to_mrf() to split search and
> >>> rewrite into separate loops.
> >>> [PATCH 19/25] i965/fs: Teach compute_to_mrf about the COMPR4 address
> >>> transformation.
> >>> [PATCH 20/25] i965/fs: Extend compute_to_mrf() to coalesce VGRFs
> >>> initialized by multiple single-GRF writes.
> >>> [PATCH 21/25] i965/fs: Extend remove_duplicate_mrf_writes() to handle
> >>> non-VGRF to MRF copies.
> >>>
> >>
> >> 15-21 scare me.  A lot.  They even make me think that forking the
> compiler
> >> between SNB and IVB may be a good idea. :-/  MRFs are annoying, but
> COMPR4
> >> is such a gross hack that I really want to teach as little of the
> compiler
> >> about it as possible.
> >>
> > Heh, my impression (from writing the patches) is that COMPR4 was the
> > easiest part of it, it's not entirely unlike the usual Align1 source
> > regions -- with hard-wired width and vstride.  I agree it's kind of a
> > gross hardware feature but all it took to handle it in compute-to-mrf
> > was some simple arithmetic [it would get slightly more complex if
> > compute-to-mrf attempted to handle COMPR4 LOAD_PAYLOAD instructions, but
> > I don't think it would necessarily be an insane idea].
> >
> > Honestly, what made patches 16-20 really hard to write 

Re: [Mesa-dev] [PATCH 20/25] i965/fs: Extend compute_to_mrf() to coalesce VGRFs initialized by multiple single-GRF writes.

2016-05-30 Thread Jason Ekstrand
On Fri, May 27, 2016 at 7:06 PM, Francisco Jerez 
wrote:

> This requires using a bitset instead of a boolean flag to keep track
> of the GRFs we've seen a generating instruction for already.  The
> search loop continues until all instructions initializing the value of
> the source VGRF have been found, or it is determined that coalescing
> is not possible.
> ---
>  src/mesa/drivers/dri/i965/brw_fs.cpp | 46
> 
>  1 file changed, 36 insertions(+), 10 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
> b/src/mesa/drivers/dri/i965/brw_fs.cpp
> index 4062ea2..50552cb 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
> @@ -2782,6 +2782,20 @@ fs_visitor::opt_redundant_discard_jumps()
> return progress;
>  }
>
> +/**
> + * Compute a bitmask with GRF granularity with a bit set for each GRF
> starting
> + * from \p r which overlaps the region starting at \p r and spanning \p n
> GRF
> + * units.
> + */
> +static inline unsigned
> +mask_relative_to(const fs_reg , const fs_reg , unsigned n)
> +{
> +   const int rel_offset = (reg_offset(s) - reg_offset(r)) / REG_SIZE;
> +   assert(reg_space(r) == reg_space(s) &&
> +  rel_offset >= 0 && rel_offset < int(8 * sizeof(unsigned)));
>

Isn't that rel_offset < REG_SIZE?  Or do you mean "unsigned-many bits?


> +   return ((1 << n) - 1) << rel_offset;
> +}
> +
>  bool
>  fs_visitor::compute_to_mrf()
>  {
> @@ -2813,10 +2827,12 @@ fs_visitor::compute_to_mrf()
>if (this->virtual_grf_end[inst->src[0].nr] > ip)
>  continue;
>
> -  /* Found a move of a GRF to a MRF.  Let's see if we can go
> -   * rewrite the thing that made this GRF to write into the MRF.
> +  /* Found a move of a GRF to a MRF.  Let's see if we can go rewrite
> the
> +   * things that computed the value of all GRFs of the source
> region.  The
> +   * regs_left bitset keeps track of the registers we haven't yet
> found a
> +   * generating instruction for.
> */
> -  bool found = false;
> +  unsigned regs_left = (1 << inst->regs_read(0)) - 1;
>
>foreach_inst_in_block_reverse_starting_from(fs_inst, scan_inst,
> inst) {
>   if (regions_overlap(scan_inst->dst, scan_inst->regs_written *
> REG_SIZE,
> @@ -2855,10 +2871,11 @@ fs_visitor::compute_to_mrf()
>}
> }
>
> -   if (scan_inst->dst.reg_offset == inst->src[0].reg_offset)
> -   found = true;
> -
> -   break;
> +/* Clear the bits for any registers this instruction
> overwrites. */
> +regs_left &= ~mask_relative_to(
> +   inst->src[0], scan_inst->dst, scan_inst->regs_written);
> +if (!regs_left)
> +   break;
>
 }
>
>  /* We don't handle control flow here.  Most computation of
> @@ -2901,14 +2918,21 @@ fs_visitor::compute_to_mrf()
>   }
>}
>
> -  if (!found)
> +  if (regs_left)
>   continue;
>
> -  /* Found all generating instructions of our MRF's source value.
> +  /* Found all generating instructions of our MRF's source value, so
> it
> +   * should be safe to rewrite them to point to the MRF directly.
> */
> +  regs_left = (1 << inst->regs_read(0)) - 1;
> +
>foreach_inst_in_block_reverse_starting_from(fs_inst, scan_inst,
> inst) {
>   if (regions_overlap(scan_inst->dst, scan_inst->regs_written *
> REG_SIZE,
>   inst->src[0], inst->regs_read(0) *
> REG_SIZE)) {
> +/* Clear the bits for any registers this instruction
> overwrites. */
> +regs_left &= ~mask_relative_to(
> +   inst->src[0], scan_inst->dst, scan_inst->regs_written);
> +
>  const unsigned rel_offset = (reg_offset(scan_inst->dst) -
>   reg_offset(inst->src[0])) /
> REG_SIZE;
>
> @@ -2935,10 +2959,12 @@ fs_visitor::compute_to_mrf()
>  scan_inst->dst.file = MRF;
>  scan_inst->dst.reg_offset = 0;
>  scan_inst->saturate |= inst->saturate;
> -break;
> +if (!regs_left)
> +   break;
>   }
>}
>
> +  assert(!regs_left);
>inst->remove(block);
>progress = true;
> }
> --
> 2.7.3
>
> ___
> 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] i965: Shrink stage_prog_data param array length

2016-05-30 Thread Emil Velikov
On 29 May 2016 at 07:01, Jordan Justen  wrote:
> It appears we were over-allocating these arrays.
>
> Previously we would use nir->num_uniforms directly for scalar
> programs, and multiply it by 4 for vec4 programs.
>
> Instead we should have been dividing by 4 in both cases to convert
> from bytes to a gl_constant_value count. The size of gl_constant_value
> is 4 bytes.
>
> Signed-off-by: Jordan Justen 
> ---
>  Jenkins results looked good with this change.
>
>  src/mesa/drivers/dri/i965/brw_cs.c  | 2 +-
>  src/mesa/drivers/dri/i965/brw_gs.c  | 4 +---
>  src/mesa/drivers/dri/i965/brw_tcs.c | 4 +---
>  src/mesa/drivers/dri/i965/brw_tes.c | 4 +---
>  src/mesa/drivers/dri/i965/brw_vs.c  | 4 +---
>  src/mesa/drivers/dri/i965/brw_wm.c  | 2 +-
>  6 files changed, 6 insertions(+), 14 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_cs.c 
> b/src/mesa/drivers/dri/i965/brw_cs.c
> index 0ab9ebd..a9cbde9 100644
> --- a/src/mesa/drivers/dri/i965/brw_cs.c
> +++ b/src/mesa/drivers/dri/i965/brw_cs.c
> @@ -91,7 +91,7 @@ brw_codegen_cs_prog(struct brw_context *brw,
>  * prog_data associated with the compiled program, and which will be freed
>  * by the state cache.
>  */
> -   int param_count = cp->program.Base.nir->num_uniforms;
> +   int param_count = cp->program.Base.nir->num_uniforms / 4;
>
Shouldn't one use sizeof(union gl_constant_value) over the hardcoded 4 ?

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


[Mesa-dev] [Bug 95294] Support importing R8 and GR88 dma_bufs on ARM

2016-05-30 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=95294

Emil Velikov  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |NOTABUG

--- Comment #3 from Emil Velikov  ---
Ftr there is no "ARM" but specific drivers.

Stan's work covered the code for the gallium drivers and the freedreno driver.
The r600 and radeonsi (gallium) drivers already had the required driver changes
prior to his work :-)

Thus apart from the i965, freedreno, r600 and radeonsi everyone else will need
to add support for their driver.

Please file separate bugs (set severity to enhancement) with the driver that
you're interested in. Patches would be better though ;-)

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


Re: [Mesa-dev] [PATCH v3 3/3] gallium: push offset down to driver

2016-05-30 Thread Stanimir Varbanov
Cc Rob.

Sorry I forgot to Cc you on this v3.

On 05/27/2016 08:24 PM, Emil Velikov wrote:
> Hi Stan
> 
> On Thursday, 26 May 2016, Stanimir Varbanov 
> wrote:
> 
>> Push offset down to drivers when importing dmabuf. This is needed
>> to more fully support EGL_EXT_image_dma_buf_import when a non-zero
>> offset is specified.
>>
>> Signed-off-by: Stanimir Varbanov > >
>> ---
>>
>> Tesing has been done for freedreno, and compile tested following
>> gallium drivers:
>> nouveau,svga,virgl,r600,r300,radeonsi,swrast,i915,ilo
>>
>> Series looks a lot better and is
> Reviewed-by: Emil Velikov 
> 
> Rob feel free to push but please move the "Testing has been..." hunk before
> the --- line.We _want_ that information in git log.
> 
> Thanks
> Emil
> 


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


[Mesa-dev] [Bug 95294] Support importing R8 and GR88 dma_bufs on ARM

2016-05-30 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=95294

--- Comment #2 from Stanimir  ---
Please see the patchset at https://patchwork.freedesktop.org/series/7206/

-- 
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 95110] Some Ogre 2.1 demos doesn't render properly

2016-05-30 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=95110

Marek Olšák  changed:

   What|Removed |Added

 Resolution|--- |NOTOURBUG
 Status|NEW |RESOLVED

--- Comment #4 from Marek Olšák  ---
The apitrace contains invalid OpenGL calls, which may work with incorrect
drivers, but not with Mesa. This is the list of GL errors:

Mesa: User error: GL_INVALID_ENUM in glTexImage2D(incompatible format =
GL_DEPTH_COMPONENT, type = GL_DEPTH_COMPONENT)
Mesa: User error: GL_INVALID_ENUM in glTexImage2D(incompatible format =
GL_DEPTH_STENCIL, type = GL_DEPTH_STENCIL)
Mesa: User error: GL_INVALID_OPERATION in glTexImage2D(incompatible format =
GL_BGR, type = GL_UNSIGNED_SHORT_5_6_5)
Mesa: User error: GL_INVALID_OPERATION in glTexImage2D(integer/non-integer
format mismatch)
Mesa: User error: GL_INVALID_VALUE in glBindAttribLocation(index)
Mesa: User error: GL_INVALID_FRAMEBUFFER_OPERATION in glClear(incomplete
framebuffer)
Mesa: User error: GL_INVALID_FRAMEBUFFER_OPERATION in
glMultiDrawElementsIndirect(incomplete framebuffer)

The GLSL compiler also detected uninitialized variables in various shaders:

0:249(28): warning: `nNormal' used uninitialized
0:252(14): warning: `material' used uninitialized
0:252(14): warning: `ROUGHNESS' used uninitialized
0:288(54): warning: `diffuseCol' used uninitialized
0:290(37): warning: `specularCol' used uninitialized
etc.

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


[Mesa-dev] [Bug 95246] Segfault in glBindFramebuffer()

2016-05-30 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=95246

--- Comment #2 from Marek Olšák  ---
Fix: https://lists.freedesktop.org/archives/mesa-dev/2016-May/118763.html

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


[Mesa-dev] [PATCH] mesa: fix crash in driver_RenderTexture_is_safe

2016-05-30 Thread Marek Olšák
From: Marek Olšák 

This just fixed the crash with the apitrace in bug report.

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

Cc: 11.1 11.2 
---
 src/mesa/main/fbobject.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index fa5baa3..bf47c1c 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -389,7 +389,8 @@ driver_RenderTexture_is_safe(const struct 
gl_renderbuffer_attachment *att)
const struct gl_texture_image *const texImage =
   att->Texture->Image[att->CubeMapFace][att->TextureLevel];
 
-   if (texImage->Width == 0 || texImage->Height == 0 || texImage->Depth == 0)
+   if (!texImage ||
+   texImage->Width == 0 || texImage->Height == 0 || texImage->Depth == 0)
   return false;
 
if ((texImage->TexObject->Target == GL_TEXTURE_1D_ARRAY
-- 
2.7.4

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


[Mesa-dev] [Bug 95128] [Gallium] uninitialized once_flag causes unregistered targets

2016-05-30 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=95128

Marek Olšák  changed:

   What|Removed |Added

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

--- Comment #3 from Marek Olšák  ---
Pushed to master as cee459d84de7533d0e0a74a37f7fc4c0f2b77bcf. Closing.

-- 
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] [Mesa-stable] [PATCH] glx: fix crash with bad fbconfig

2016-05-30 Thread Emil Velikov
Hi gents,

On 30 May 2016 at 10:13, Tapani Pälli  wrote:
> From: Daniel Czarnowski 
>
> GLX documentation states:
> glXCreateNewContext can generate the following errors: (...)
> GLXBadFBConfig if config is not a valid GLXFBConfig
>
> Function checks if the given config is a valid config and sets proper
> error code.
>
> Fixes currently crashing glx-fbconfig-bad Piglit test.
>
> Signed-off-by: Matt Roper 
> Signed-off-by: Tapani Pälli 
> Cc: "11.2" 
> ---
>  src/glx/glxcmds.c | 27 +++
>  1 file changed, 27 insertions(+)
>
> diff --git a/src/glx/glxcmds.c b/src/glx/glxcmds.c
> index bff01d2..4bc7fc4 100644
> --- a/src/glx/glxcmds.c
> +++ b/src/glx/glxcmds.c
> @@ -1629,8 +1629,35 @@ _X_EXPORT GLXContext
>  glXCreateNewContext(Display * dpy, GLXFBConfig fbconfig,
>  int renderType, GLXContext shareList, Bool allowDirect)
>  {
> +   int list_size;
> struct glx_config *config = (struct glx_config *) fbconfig;
>
> +   if (!config)
> +   {
Existing coding style is to put the opening bracket trailing on the
previous line. Same goes for the rest of the patch.

> +   __glXSendError(dpy, GLXBadFBConfig, 0, X_GLXCreateNewContext, false);
> +   return NULL;
> +   }
> +
> +   int screen = XDefaultScreen(dpy);
Use the DefaultScreen macro instead ?

> +   struct glx_config **config_list = (struct glx_config **)
> +  glXGetFBConfigs(dpy, screen, _size);
> +
Worth checking (& bail) that list_size is negative ?

> +   int i;
unsigned i...

> +   for (i = 0; i < list_size; i++)
... and cast list_size to unsigned ?

> +   {
> +   if (config_list[i] == config)
> +   {
> +   break;
> +   }
> +   }
Coding style: drop the brackets if there's only a single nested
statement. I.e. the above two pairs can go.

> +   free(config_list);
> +
> +   if (i == list_size)
> +   {
> +   __glXSendError(dpy, GLXBadFBConfig, 0, X_GLXCreateNewContext, false);
> +   return NULL;
> +   }
> +

In general, please don't mix variable declarations and code.

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


Re: [Mesa-dev] [PATCH 0/2] fix load of unpacked double vector input varyings

2016-05-30 Thread Samuel Iglesias Gonsálvez


On 27/05/16 08:39, Samuel Iglesias Gonsálvez wrote:
> 
> 
> On 26/05/16 09:46, Timothy Arceri wrote:
>> On Thu, 2016-05-26 at 17:44 +1000, Timothy Arceri wrote:
>>> On Thu, 2016-05-26 at 07:56 +0200, Samuel Iglesias Gonsálvez wrote:

 Hello,

 Timothy found that tests with unpacked double vector input varyings
 were failing in i965 driver. For example, this is happening when
 using explicit locations because Mesa disables varying packing for
 that case.

 These patches fix the following piglit test:

 spec/arb_gpu_shader_fp64/execution/vs-fs-explicit-locations

 Samuel Iglesias Gonsálvez (2):
   i965/fs: fix offset when loading double vector input varyings
   i965/fs: fix FS_OPCODE_CINTERP for unpacked double input varyings

  src/mesa/drivers/dri/i965/brw_fs.cpp | 13 -
  src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 22
 +-
  2 files changed, 33 insertions(+), 2 deletions(-)

>>> These are both:
>>>
>>> Tested-by: Timothy Arceri 
>>>
>>> The logic looks ok to me also, but you probably want someone
>>> more familiar with the backend to take a quick look also.
>>
>> Forgot to ask. Did you also check the other stages work as expected
>> with explicit locations?
>>
> 
> I did not check them. I am going to do it know and send patches if needed.
> 

I needed to fix Geometry shaders too. I have sent a patch for it.

Sam

> Thanks,
> 
> Sam
> 



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


[Mesa-dev] [PATCH 3/2] i965/gs/scalar: Fix load input for doubles

2016-05-30 Thread Samuel Iglesias Gonsálvez
Signed-off-by: Samuel Iglesias Gonsálvez 
---
 src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 72 
 1 file changed, 54 insertions(+), 18 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp 
b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
index 85b482f..0d9fe6b 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
@@ -2092,24 +2092,60 @@ fs_visitor::emit_gs_input_load(const fs_reg ,
}
 
fs_inst *inst;
-   if (offset_const) {
-  /* Constant indexing - use global offset. */
-  inst = bld.emit(SHADER_OPCODE_URB_READ_SIMD8, dst, icp_handle);
-  inst->offset = base_offset + offset_const->u32[0];
-  inst->base_mrf = -1;
-  inst->mlen = 1;
-  inst->regs_written = num_components;
-   } else {
-  /* Indirect indexing - use per-slot offsets as well. */
-  const fs_reg srcs[] = { icp_handle, get_nir_src(offset_src) };
-  fs_reg payload = bld.vgrf(BRW_REGISTER_TYPE_UD, 2);
-  bld.LOAD_PAYLOAD(payload, srcs, ARRAY_SIZE(srcs), 0);
-
-  inst = bld.emit(SHADER_OPCODE_URB_READ_SIMD8_PER_SLOT, dst, payload);
-  inst->offset = base_offset;
-  inst->base_mrf = -1;
-  inst->mlen = 2;
-  inst->regs_written = num_components;
+
+   fs_reg tmp_dst = dst;
+   fs_reg indirect_offset = get_nir_src(offset_src);
+   unsigned num_iterations = 1;
+   unsigned orig_num_components = num_components;
+
+   if (type_sz(dst.type) == 8) {
+  if (num_components > 2) {
+ num_iterations = 2;
+ num_components = 2;
+  }
+  fs_reg tmp = fs_reg(VGRF, alloc.allocate(4), dst.type);
+  tmp_dst = tmp;
+   }
+
+   for (unsigned iter = 0; iter < num_iterations; iter++) {
+  if (offset_const) {
+ /* Constant indexing - use global offset. */
+ inst = bld.emit(SHADER_OPCODE_URB_READ_SIMD8, tmp_dst, icp_handle);
+ inst->offset = base_offset + offset_const->u32[0];
+ inst->base_mrf = -1;
+ inst->mlen = 1;
+ inst->regs_written = num_components * type_sz(tmp_dst.type) / 4;
+  } else {
+ /* Indirect indexing - use per-slot offsets as well. */
+ const fs_reg srcs[] = { icp_handle, indirect_offset };
+ fs_reg payload = bld.vgrf(BRW_REGISTER_TYPE_UD, 2);
+ bld.LOAD_PAYLOAD(payload, srcs, ARRAY_SIZE(srcs), 0);
+
+ inst = bld.emit(SHADER_OPCODE_URB_READ_SIMD8_PER_SLOT, tmp_dst, 
payload);
+ inst->offset = base_offset;
+ inst->base_mrf = -1;
+ inst->mlen = 2;
+ inst->regs_written = num_components * type_sz(tmp_dst.type) / 4;
+  }
+
+  if (type_sz(dst.type) == 8) {
+ shuffle_32bit_load_result_to_64bit_data(
+bld, tmp_dst, retype(tmp_dst, BRW_REGISTER_TYPE_F), 
num_components);
+
+ for (unsigned c = 0; c < num_components; c++)
+bld.MOV(offset(dst, bld, iter * 2 + c), offset(tmp_dst, bld, c));
+  }
+
+  if (num_iterations > 1) {
+ num_components = orig_num_components - 2;
+ if(offset_const) {
+base_offset++;
+ } else {
+fs_reg new_indirect = bld.vgrf(BRW_REGISTER_TYPE_UD, 1);
+bld.ADD(new_indirect, indirect_offset, brw_imm_ud(1u));
+indirect_offset = new_indirect;
+ }
+  }
}
 
if (is_point_size) {
-- 
2.7.4

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


Re: [Mesa-dev] [PATCH] radeon/uvd: fix the H264 level for Tonga

2016-05-30 Thread Andy Furniss

Christian König wrote:

Am 28.05.2016 um 00:45 schrieb Andy Furniss:

Emil Velikov wrote:

On 27 May 2016 at 15:40, Christian König 
wrote:


No, what I'm saying is that it is a number and not an enum.

This way you don't need to change the specification when you want to
support
a new level.


That's the case indeed. Thanks for explaining.


That's handy, FWIW the reason I thought it didn't go up to 5.2
was that I saw there was no 5_2 here -

http://http.download.nvidia.com/XFree86/vdpau/doxygen/html/group___vdp_decoder.html




Oh! So we really do have defines for that in the VDPAU spec, crap.

Anyway I think returning 5.2 here should work as well and you were
absolutely right the supported level for H264 is 5.2 on Tonga and later.

It's 5.1 for HEVC, both Alex and I where looking at the wrong column in
our hardware support table.

Thanks for pointing that out, just sent out v2 of the patch.


Great, though mentioning HEVC and tonga together may give false hope :-)

Though it would be nice to be wrong here, I guess the HEVC 5.1 reference
is for > tonga and not >= tonga.

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


Re: [Mesa-dev] [PATCH v3] glx: fix error code when there is no context bound

2016-05-30 Thread Emil Velikov
On 30 May 2016 at 07:53, Tapani Pälli  wrote:
> From: Bernard Kilarski 
>
> v2: change all related NULL checks to check against dummyContext
> v3: really check for dummyContext *only* when ctx was from
> __glXGetCurrentContext
>
> Signed-off-by: Bernard Kilarski 
> Signed-off-by: Matt Roper 
> Signed-off-by: Tapani Pälli 
> Cc: "11.2" 
> ---
>  src/glx/glx_pbuffer.c |  2 +-
>  src/glx/glxcmds.c | 12 ++--
>  src/glx/query_renderer.c  |  4 ++--
>  src/glx/tests/fake_glx_screen.cpp |  6 +-
>  4 files changed, 14 insertions(+), 10 deletions(-)
>

> +++ b/src/glx/glxcmds.c
There are a lot more places that need this fix.

glXWaitGL, glXWaitX glXUseXFont glXSwapBuffers (multiple cases, split
the apple bits?), glXGetCurrentDisplay, __glXSwapIntervalMESA,
__glXGetSwapIntervalMESA, __glXCopySubBufferMESA


And some more in
 - apple/apple_xgl_api_stereo.c
__applegl_glDrawBuffer __applegl_glDrawBuffers

 - apple/apple_xgl_api_viewport.c
__applegl_glViewport
Might be worth splitting the Apple changes and CCing Jeremy to test/ack.

 - glx_error.c
__glXSendError


> +++ b/src/glx/tests/fake_glx_screen.cpp
> @@ -75,7 +75,11 @@ indirect_create_context_attribs(struct glx_screen *base,
> return indirect_create_context(base, config_base, shareList, 0);
>  }
>
> -__thread void *__glX_tls_Context = NULL;
> +/* This is necessary so that we don't have to link with glxcurrent.c
> + * which would require us to link with X libraries and what not.
> + */
> +struct glx_context dummyContext;
Seemingly not required atm, although it would be safer to initialize
it as in glxcurrent.c. Namely:

struct glx_context dummyContext = {
   [0],
   [0],
   [0],
   [__GLX_BUFFER_LIMIT_SIZE],
   sizeof(dummyBuffer),
   
};

This way things won't explode in spectacular ways as we add more tests.

> +__thread void *__glX_tls_Context = 
>
Not 100% sure but I think we want to move this (and the dummyContext)
in the if !defined(GLX_USE_TLS) below ?

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


Re: [Mesa-dev] [PATCH v2 14/18] mesa_glinterop: remove mesa_glinterop typedefs

2016-05-30 Thread Marek Olšák
Reviewed-by: Marek Olšák 

Marek

On Mon, May 30, 2016 at 2:47 PM, Emil Velikov  wrote:
> From: Emil Velikov 
>
> As is there are two places that do the typedefs - dri_interface.h and
> this header. As we cannot include the former in here, just drop the
> typedefs and use the struct directly (as needed).
>
> This is required because typedef redefinition is C11 feature which is
> not supported on all the versions of GCC used to build mesa.
>
> v2: Kill the typedef alltogether, as per Marek.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96236
> Cc: Vinson Lee 
> Cc: Marek Olšák 
> Signed-off-by: Emil Velikov 
> ---
>  include/GL/internal/dri_interface.h   | 12 ++--
>  include/GL/mesa_glinterop.h   | 36 
> +--
>  src/egl/drivers/dri2/egl_dri2.c   |  6 +++---
>  src/egl/main/eglapi.c |  6 +++---
>  src/egl/main/eglapi.h | 12 ++--
>  src/gallium/state_trackers/dri/dri2.c |  6 +++---
>  src/glx/dri2_priv.h   |  6 +++---
>  src/glx/dri3_priv.h   |  6 +++---
>  src/glx/dri_common_interop.c  | 12 ++--
>  src/glx/glxclient.h   | 12 ++--
>  src/glx/glxcmds.c |  6 +++---
>  11 files changed, 60 insertions(+), 60 deletions(-)
>
> diff --git a/include/GL/internal/dri_interface.h 
> b/include/GL/internal/dri_interface.h
> index f80233b..1c73cce 100644
> --- a/include/GL/internal/dri_interface.h
> +++ b/include/GL/internal/dri_interface.h
> @@ -401,21 +401,21 @@ struct __DRI2fenceExtensionRec {
>  #define __DRI2_INTEROP "DRI2_Interop"
>  #define __DRI2_INTEROP_VERSION 1
>
> -typedef struct _mesa_glinterop_device_info mesa_glinterop_device_info;
> -typedef struct _mesa_glinterop_export_in mesa_glinterop_export_in;
> -typedef struct _mesa_glinterop_export_out mesa_glinterop_export_out;
> +struct mesa_glinterop_device_info;
> +struct mesa_glinterop_export_in;
> +struct mesa_glinterop_export_out;
>
>  struct __DRI2interopExtensionRec {
> __DRIextension base;
>
> /** Same as MesaGLInterop*QueryDeviceInfo. */
> int (*query_device_info)(__DRIcontext *ctx,
> -mesa_glinterop_device_info *out);
> +struct mesa_glinterop_device_info *out);
>
> /** Same as MesaGLInterop*ExportObject. */
> int (*export_object)(__DRIcontext *ctx,
> -mesa_glinterop_export_in *in,
> -mesa_glinterop_export_out *out);
> +struct mesa_glinterop_export_in *in,
> +struct mesa_glinterop_export_out *out);
>  };
>
>  /*@}*/
> diff --git a/include/GL/mesa_glinterop.h b/include/GL/mesa_glinterop.h
> index b805d63..c0c20d6 100644
> --- a/include/GL/mesa_glinterop.h
> +++ b/include/GL/mesa_glinterop.h
> @@ -92,7 +92,7 @@ enum {
>  /**
>   * Device information returned by Mesa.
>   */
> -typedef struct _mesa_glinterop_device_info {
> +struct mesa_glinterop_device_info {
> /* The caller should set this to the version of the struct they support */
> /* The callee will overwrite it if it supports a lower version.
>  *
> @@ -113,14 +113,14 @@ typedef struct _mesa_glinterop_device_info {
> uint32_t device_id;
>
> /* Structure version 1 ends here. */
> -} mesa_glinterop_device_info;
> +};
>
>  #define MESA_GLINTEROP_EXPORT_IN_VERSION 1
>
>  /**
>   * Input parameters to Mesa interop export functions.
>   */
> -typedef struct _mesa_glinterop_export_in {
> +struct mesa_glinterop_export_in {
> /* The caller should set this to the version of the struct they support */
> /* The callee will overwrite it if it supports a lower version.
>  *
> @@ -178,14 +178,14 @@ typedef struct _mesa_glinterop_export_in {
>  */
> void *out_driver_data;
> /* Structure version 1 ends here. */
> -} mesa_glinterop_export_in;
> +};
>
>  #define MESA_GLINTEROP_EXPORT_OUT_VERSION 1
>
>  /**
>   * Outputs of Mesa interop export functions.
>   */
> -typedef struct _mesa_glinterop_export_out {
> +struct mesa_glinterop_export_out {
> /* The caller should set this to the version of the struct they support */
> /* The callee will overwrite it if it supports a lower version.
>  *
> @@ -233,7 +233,7 @@ typedef struct _mesa_glinterop_export_out {
> /* The number of bytes written to out_driver_data. */
> uint32_t out_driver_data_written;
> /* Structure version 1 ends here. */
> -} mesa_glinterop_export_out;
> +};
>
>
>  /**
> @@ -247,7 +247,7 @@ typedef struct _mesa_glinterop_export_out {
>   */
>  int
>  MesaGLInteropGLXQueryDeviceInfo(Display *dpy, GLXContext context,
> -mesa_glinterop_device_info *out);
> +struct mesa_glinterop_device_info *out);
>
>
>  /**
> @@ -256,7 +256,7 

[Mesa-dev] [PATCH v2 14/18] mesa_glinterop: remove mesa_glinterop typedefs

2016-05-30 Thread Emil Velikov
From: Emil Velikov 

As is there are two places that do the typedefs - dri_interface.h and
this header. As we cannot include the former in here, just drop the
typedefs and use the struct directly (as needed).

This is required because typedef redefinition is C11 feature which is
not supported on all the versions of GCC used to build mesa.

v2: Kill the typedef alltogether, as per Marek.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96236
Cc: Vinson Lee 
Cc: Marek Olšák 
Signed-off-by: Emil Velikov 
---
 include/GL/internal/dri_interface.h   | 12 ++--
 include/GL/mesa_glinterop.h   | 36 +--
 src/egl/drivers/dri2/egl_dri2.c   |  6 +++---
 src/egl/main/eglapi.c |  6 +++---
 src/egl/main/eglapi.h | 12 ++--
 src/gallium/state_trackers/dri/dri2.c |  6 +++---
 src/glx/dri2_priv.h   |  6 +++---
 src/glx/dri3_priv.h   |  6 +++---
 src/glx/dri_common_interop.c  | 12 ++--
 src/glx/glxclient.h   | 12 ++--
 src/glx/glxcmds.c |  6 +++---
 11 files changed, 60 insertions(+), 60 deletions(-)

diff --git a/include/GL/internal/dri_interface.h 
b/include/GL/internal/dri_interface.h
index f80233b..1c73cce 100644
--- a/include/GL/internal/dri_interface.h
+++ b/include/GL/internal/dri_interface.h
@@ -401,21 +401,21 @@ struct __DRI2fenceExtensionRec {
 #define __DRI2_INTEROP "DRI2_Interop"
 #define __DRI2_INTEROP_VERSION 1
 
-typedef struct _mesa_glinterop_device_info mesa_glinterop_device_info;
-typedef struct _mesa_glinterop_export_in mesa_glinterop_export_in;
-typedef struct _mesa_glinterop_export_out mesa_glinterop_export_out;
+struct mesa_glinterop_device_info;
+struct mesa_glinterop_export_in;
+struct mesa_glinterop_export_out;
 
 struct __DRI2interopExtensionRec {
__DRIextension base;
 
/** Same as MesaGLInterop*QueryDeviceInfo. */
int (*query_device_info)(__DRIcontext *ctx,
-mesa_glinterop_device_info *out);
+struct mesa_glinterop_device_info *out);
 
/** Same as MesaGLInterop*ExportObject. */
int (*export_object)(__DRIcontext *ctx,
-mesa_glinterop_export_in *in,
-mesa_glinterop_export_out *out);
+struct mesa_glinterop_export_in *in,
+struct mesa_glinterop_export_out *out);
 };
 
 /*@}*/
diff --git a/include/GL/mesa_glinterop.h b/include/GL/mesa_glinterop.h
index b805d63..c0c20d6 100644
--- a/include/GL/mesa_glinterop.h
+++ b/include/GL/mesa_glinterop.h
@@ -92,7 +92,7 @@ enum {
 /**
  * Device information returned by Mesa.
  */
-typedef struct _mesa_glinterop_device_info {
+struct mesa_glinterop_device_info {
/* The caller should set this to the version of the struct they support */
/* The callee will overwrite it if it supports a lower version.
 *
@@ -113,14 +113,14 @@ typedef struct _mesa_glinterop_device_info {
uint32_t device_id;
 
/* Structure version 1 ends here. */
-} mesa_glinterop_device_info;
+};
 
 #define MESA_GLINTEROP_EXPORT_IN_VERSION 1
 
 /**
  * Input parameters to Mesa interop export functions.
  */
-typedef struct _mesa_glinterop_export_in {
+struct mesa_glinterop_export_in {
/* The caller should set this to the version of the struct they support */
/* The callee will overwrite it if it supports a lower version.
 *
@@ -178,14 +178,14 @@ typedef struct _mesa_glinterop_export_in {
 */
void *out_driver_data;
/* Structure version 1 ends here. */
-} mesa_glinterop_export_in;
+};
 
 #define MESA_GLINTEROP_EXPORT_OUT_VERSION 1
 
 /**
  * Outputs of Mesa interop export functions.
  */
-typedef struct _mesa_glinterop_export_out {
+struct mesa_glinterop_export_out {
/* The caller should set this to the version of the struct they support */
/* The callee will overwrite it if it supports a lower version.
 *
@@ -233,7 +233,7 @@ typedef struct _mesa_glinterop_export_out {
/* The number of bytes written to out_driver_data. */
uint32_t out_driver_data_written;
/* Structure version 1 ends here. */
-} mesa_glinterop_export_out;
+};
 
 
 /**
@@ -247,7 +247,7 @@ typedef struct _mesa_glinterop_export_out {
  */
 int
 MesaGLInteropGLXQueryDeviceInfo(Display *dpy, GLXContext context,
-mesa_glinterop_device_info *out);
+struct mesa_glinterop_device_info *out);
 
 
 /**
@@ -256,7 +256,7 @@ MesaGLInteropGLXQueryDeviceInfo(Display *dpy, GLXContext 
context,
  */
 int
 MesaGLInteropEGLQueryDeviceInfo(EGLDisplay dpy, EGLContext context,
-mesa_glinterop_device_info *out);
+struct mesa_glinterop_device_info *out);
 
 
 /**
@@ -272,8 +272,8 @@ 

[Mesa-dev] [PATCH 4/4] mesa: remove MESA_GIT_SHA1 guard

2016-05-30 Thread Emil Velikov
From: Emil Velikov 

As of a few commits ago the header will always contain the macro.

Signed-off-by: Emil Velikov 
---
 src/mesa/main/version.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/src/mesa/main/version.c b/src/mesa/main/version.c
index 7138cf3..74e06f9 100644
--- a/src/mesa/main/version.c
+++ b/src/mesa/main/version.c
@@ -122,9 +122,7 @@ create_version_string(struct gl_context *ctx, const char 
*prefix)
if (ctx->VersionString) {
   _mesa_snprintf(ctx->VersionString, max,
 "%s%u.%u%s Mesa " PACKAGE_VERSION
-#ifdef MESA_GIT_SHA1
 " (" MESA_GIT_SHA1 ")"
-#endif
 ,
 prefix,
 ctx->Version / 10, ctx->Version % 10,
-- 
2.8.2

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


[Mesa-dev] [PATCH 1/4] scons: move the git_sha1.h rule a level up

2016-05-30 Thread Emil Velikov
From: Emil Velikov 

Analogous to the previous commit.

Cc: Brian Paul 
Cc: Jose Fonseca 
Signed-off-by: Emil Velikov 
---
 src/SConscript  | 39 +++
 src/mesa/SConscript | 43 +++
 2 files changed, 42 insertions(+), 40 deletions(-)

diff --git a/src/SConscript b/src/SConscript
index 4ba0a32..d623c51 100644
--- a/src/SConscript
+++ b/src/SConscript
@@ -1,5 +1,44 @@
 Import('*')
+import filecmp
+import os
+import subprocess
 
+def write_git_sha1_h_file(filename):
+"""Mesa looks for a git_sha1.h file at compile time in order to display
+the current git hash id in the GL_VERSION string.  This function tries
+to retrieve the git hashid and write the header file.  An empty file
+will be created if anything goes wrong."""
+
+args = [ 'git', 'log', '-n', '1', '--oneline' ]
+try:
+(commit, foo) = subprocess.Popen(args, 
stdout=subprocess.PIPE).communicate()
+except:
+# git log command didn't work
+if not os.path.exists(filename):
+dirname = os.path.dirname(filename)
+if not os.path.exists(dirname):
+os.makedirs(dirname)
+# create an empty file if none already exists
+f = open(filename, "w")
+f.close()
+return
+
+commit = '#define MESA_GIT_SHA1 "git-%s"\n' % commit[0:7]
+tempfile = "git_sha1.h.tmp"
+f = open(tempfile, "w")
+f.write(commit)
+f.close()
+if not os.path.exists(filename) or not filecmp.cmp(tempfile, filename):
+# The filename does not exist or it's different from the new file,
+# so replace old file with new.
+if os.path.exists(filename):
+os.remove(filename)
+os.rename(tempfile, filename)
+return
+
+
+# Create the git_sha1.h header file
+write_git_sha1_h_file("git_sha1.h")
 
 if env['platform'] == 'windows':
 SConscript('getopt/SConscript')
diff --git a/src/mesa/SConscript b/src/mesa/SConscript
index 434800e..b9495f0 100644
--- a/src/mesa/SConscript
+++ b/src/mesa/SConscript
@@ -3,9 +3,6 @@
 
 
 Import('*')
-import filecmp
-import os
-import subprocess
 from sys import executable as python_cmd
 
 env = env.Clone()
@@ -119,45 +116,11 @@ if env['platform'] not in ('cygwin', 'darwin', 'windows', 
'haiku'):
 env.Append(CPPPATH = [matypes[0].dir])
 
 
-def write_git_sha1_h_file(filename):
-"""Mesa looks for a git_sha1.h file at compile time in order to display
-the current git hash id in the GL_VERSION string.  This function tries
-to retrieve the git hashid and write the header file.  An empty file
-will be created if anything goes wrong."""
-
-args = [ 'git', 'log', '-n', '1', '--oneline' ]
-try:
-(commit, foo) = subprocess.Popen(args, 
stdout=subprocess.PIPE).communicate()
-except:
-# git log command didn't work
-if not os.path.exists(filename):
-dirname = os.path.dirname(filename)
-if not os.path.exists(dirname):
-os.makedirs(dirname)
-# create an empty file if none already exists
-f = open(filename, "w")
-f.close()
-return
-
-commit = '#define MESA_GIT_SHA1 "git-%s"\n' % commit[0:7]
-tempfile = "git_sha1.h.tmp"
-f = open(tempfile, "w")
-f.write(commit)
-f.close()
-if not os.path.exists(filename) or not filecmp.cmp(tempfile, filename):
-# The filename does not exist or it's different from the new file,
-# so replace old file with new.
-if os.path.exists(filename):
-os.remove(filename)
-os.rename(tempfile, filename)
-return
-
-
-# Create the git_sha1.h header file
-write_git_sha1_h_file("main/git_sha1.h")
-# and update CPPPATH so the git_sha1.h header can be found
+# and update CPPPATH so the generated files can be found
 env.Append(CPPPATH = ["#" + env['build_dir'] + "/mesa/main"])
 
+# ... plus the path for the git_sha1.h header
+env.Append(CPPPATH = ["#" + env['build_dir']])
 
 #
 # Libraries
-- 
2.8.2

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


[Mesa-dev] [PATCH 2/4] automake: rework the git_sha1.h rule, include in tarball

2016-05-30 Thread Emil Velikov
From: Emil Velikov 

As we'll need the file in the release tarball, rework the rule so that
the file is regenerated _only_ if we're in a git repository.

With this in place we can build vulkan (anv) from a release tarball.

Cc: Jason Ekstrand 
Cc: Kristian Høgsberg Kristensen 
Signed-off-by: Emil Velikov 
---
Not 100% sure if we want the file in any of the clean targets. I'm
leaning towards "no", yet I'm open to input.
---
 .gitignore  |  1 -
 src/Makefile.am | 20 +++-
 2 files changed, 3 insertions(+), 18 deletions(-)

diff --git a/.gitignore b/.gitignore
index f42ca7f..90abe10 100644
--- a/.gitignore
+++ b/.gitignore
@@ -49,4 +49,3 @@ Makefile.in
 .install-mesa-links
 .install-gallium-links
 /src/git_sha1.h
-/src/git_sha1.h.tmp
diff --git a/src/Makefile.am b/src/Makefile.am
index d142aea..f5c0773 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -19,30 +19,16 @@
 # FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
 # IN THE SOFTWARE.
 
-.PHONY: git_sha1.h.tmp
-git_sha1.h.tmp:
-   @# Don't assume that $(top_srcdir)/.git is a directory. It may be
-   @# a gitlink file if $(top_srcdir) is a submodule checkout or a linked
-   @# worktree.
-   @touch git_sha1.h.tmp
+git_sha1.h:
@if test -e $(top_srcdir)/.git; then \
if which git > /dev/null; then \
git --git-dir=$(top_srcdir)/.git log -n 1 --oneline | \
sed 's/^\([^ ]*\) .*/#define MESA_GIT_SHA1 "git-\1"/' \
-   > git_sha1.h.tmp ; \
+   > git_sha1.h ; \
fi \
fi
 
-git_sha1.h: git_sha1.h.tmp
-   @echo "updating git_sha1.h"
-   @if ! cmp -s git_sha1.h.tmp git_sha1.h; then \
-   mv git_sha1.h.tmp git_sha1.h ;\
-   else \
-   rm git_sha1.h.tmp ;\
-   fi
-
 BUILT_SOURCES = git_sha1.h
-CLEANFILES = $(BUILT_SOURCES)
 
 SUBDIRS = . gtest util mapi/glapi/gen mapi
 
@@ -92,7 +78,7 @@ SUBDIRS += gallium
 endif
 
 EXTRA_DIST = \
-   getopt hgl SConscript
+   getopt hgl SConscript git_sha1.h
 
 AM_CFLAGS = $(VISIBILITY_CFLAGS)
 AM_CXXFLAGS = $(VISIBILITY_CXXFLAGS)
-- 
2.8.2

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


[Mesa-dev] [PATCH 3/4] scons: rework the git_sha1.h generation rule

2016-05-30 Thread Emil Velikov
From: Emil Velikov 

Analogous to the previous commit

Cc: Brian Paul 
Cc: Jose Fonseca 
Signed-off-by: Emil Velikov 
---
Note: this may cause "false positives" if one extracts the release
tarball in another git repository. This is a preexisting bug, which we
want to fix one day.
---
 src/SConscript | 19 ++-
 1 file changed, 2 insertions(+), 17 deletions(-)

diff --git a/src/SConscript b/src/SConscript
index d623c51..b93aee2 100644
--- a/src/SConscript
+++ b/src/SConscript
@@ -1,6 +1,4 @@
 Import('*')
-import filecmp
-import os
 import subprocess
 
 def write_git_sha1_h_file(filename):
@@ -14,26 +12,13 @@ def write_git_sha1_h_file(filename):
 (commit, foo) = subprocess.Popen(args, 
stdout=subprocess.PIPE).communicate()
 except:
 # git log command didn't work
-if not os.path.exists(filename):
-dirname = os.path.dirname(filename)
-if not os.path.exists(dirname):
-os.makedirs(dirname)
-# create an empty file if none already exists
-f = open(filename, "w")
-f.close()
+# bail out without touching/removing the existing file
 return
 
 commit = '#define MESA_GIT_SHA1 "git-%s"\n' % commit[0:7]
-tempfile = "git_sha1.h.tmp"
-f = open(tempfile, "w")
+f = open(filename, "w")
 f.write(commit)
 f.close()
-if not os.path.exists(filename) or not filecmp.cmp(tempfile, filename):
-# The filename does not exist or it's different from the new file,
-# so replace old file with new.
-if os.path.exists(filename):
-os.remove(filename)
-os.rename(tempfile, filename)
 return
 
 
-- 
2.8.2

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


Re: [Mesa-dev] [PATCH] radeon/uvd: fix the H264 level for Tonga

2016-05-30 Thread Christian König

Am 28.05.2016 um 00:45 schrieb Andy Furniss:

Emil Velikov wrote:
On 27 May 2016 at 15:40, Christian König  
wrote:



No, what I'm saying is that it is a number and not an enum.

This way you don't need to change the specification when you want to 
support

a new level.


That's the case indeed. Thanks for explaining.


That's handy, FWIW the reason I thought it didn't go up to 5.2
was that I saw there was no 5_2 here -

http://http.download.nvidia.com/XFree86/vdpau/doxygen/html/group___vdp_decoder.html 





Oh! So we really do have defines for that in the VDPAU spec, crap.

Anyway I think returning 5.2 here should work as well and you were 
absolutely right the supported level for H264 is 5.2 on Tonga and later.


It's 5.1 for HEVC, both Alex and I where looking at the wrong column in 
our hardware support table.


Thanks for pointing that out, just sent out v2 of the patch.

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


[Mesa-dev] [PATCH] radeon/uvd: fix the H264 level for Tonga v2

2016-05-30 Thread Christian König
From: Christian König 

We support 5.2 for a while now.

v2: we even support 5.2 for H264, 5.1 is for HEVC.

Signed-off-by: Christian König 
Cc: 
---
 src/gallium/drivers/radeon/radeon_video.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/radeon/radeon_video.c 
b/src/gallium/drivers/radeon/radeon_video.c
index da65ce8..aba1404 100644
--- a/src/gallium/drivers/radeon/radeon_video.c
+++ b/src/gallium/drivers/radeon/radeon_video.c
@@ -298,7 +298,7 @@ int rvid_get_video_param(struct pipe_screen *screen,
case PIPE_VIDEO_PROFILE_MPEG4_AVC_BASELINE:
case PIPE_VIDEO_PROFILE_MPEG4_AVC_MAIN:
case PIPE_VIDEO_PROFILE_MPEG4_AVC_HIGH:
-   return 41;
+   return (rscreen->family < CHIP_TONGA) ? 41 : 52;
case PIPE_VIDEO_PROFILE_HEVC_MAIN:
case PIPE_VIDEO_PROFILE_HEVC_MAIN_10:
return 186;
-- 
2.5.0

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


Re: [Mesa-dev] Drivers/Gallium/swr is missing from the list of Mesa components when entering a new bug

2016-05-30 Thread Emil Velikov
On 28 May 2016 at 12:40, Rowley, Timothy O  wrote:

>
> Maybe I wasn’t clear about my opinion when Emil asked before: I’m fine with a 
> swr component in bugzilla if that’s what the people in charge of bugzilla 
> would like.  I come with past experience in mozilla development, where there 
> was concern about the complexity of bugzilla for users filing issues, so 
> didn’t want to clutter up the component list if people weren’t asking for it.
>
Or I completely misunderstood you ;-) Let's call it this way:
The option is there (now). We had out first bug (plus its fix). How
many others will use it, is another topic ;-)

Tim, let me know if you'd like to tweak the Default assignee/CC or QA.

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


[Mesa-dev] [Bug 96238] swr fails to build outside of the main directory

2016-05-30 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=96238

Emil Velikov  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
  Component|Other   |Drivers/Gallium/swr

--- Comment #1 from Emil Velikov  ---
Should be fixed with:

commit 04987ef229f9f45f4452c95e894fcff980f84776
Author: Emil Velikov 
Date:   Fri May 27 15:35:44 2016 +0100

swr: automake: attempt to fix the out-of-tree build

Make sure that the output folder is created otherwise the python scripts
yells at us.

Cc: 0xe2.0x9a.0...@gmail.com
Cc: Tim Rowley 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96238
Signed-off-by: Emil Velikov 

-- 
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 1/2] gallium/util: fix coverity MIXED_ENUMS warning

2016-05-30 Thread Marek Olšák
On Sun, May 29, 2016 at 6:32 PM, Rob Clark  wrote:
> From: Rob Clark 
>
> CID 1362171, 1362170
>
> Looks like it should be pipe_transfer_usage in the prototype, based on
> how the parameter is used.  Note that I don't see any users of u_staging
> so maybe we should just remove it?

Yes, that would be a good idea.

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


[Mesa-dev] [PATCH] glx: fix crash with bad fbconfig

2016-05-30 Thread Tapani Pälli
From: Daniel Czarnowski 

GLX documentation states:
glXCreateNewContext can generate the following errors: (...)
GLXBadFBConfig if config is not a valid GLXFBConfig

Function checks if the given config is a valid config and sets proper
error code.

Fixes currently crashing glx-fbconfig-bad Piglit test.

Signed-off-by: Matt Roper 
Signed-off-by: Tapani Pälli 
Cc: "11.2" 
---
 src/glx/glxcmds.c | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/src/glx/glxcmds.c b/src/glx/glxcmds.c
index bff01d2..4bc7fc4 100644
--- a/src/glx/glxcmds.c
+++ b/src/glx/glxcmds.c
@@ -1629,8 +1629,35 @@ _X_EXPORT GLXContext
 glXCreateNewContext(Display * dpy, GLXFBConfig fbconfig,
 int renderType, GLXContext shareList, Bool allowDirect)
 {
+   int list_size;
struct glx_config *config = (struct glx_config *) fbconfig;
 
+   if (!config)
+   {
+   __glXSendError(dpy, GLXBadFBConfig, 0, X_GLXCreateNewContext, false);
+   return NULL;
+   }
+
+   int screen = XDefaultScreen(dpy);
+   struct glx_config **config_list = (struct glx_config **)
+  glXGetFBConfigs(dpy, screen, _size);
+
+   int i;
+   for (i = 0; i < list_size; i++)
+   {
+   if (config_list[i] == config)
+   {
+   break;
+   }
+   }
+   free(config_list);
+
+   if (i == list_size)
+   {
+   __glXSendError(dpy, GLXBadFBConfig, 0, X_GLXCreateNewContext, false);
+   return NULL;
+   }
+
return CreateContext(dpy, config->fbconfigID, config, shareList,
allowDirect, X_GLXCreateNewContext, renderType,
config->screen);
-- 
2.5.5

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


Re: [Mesa-dev] [PATCH] nvc0: fix some compute texture validation bits on kepler

2016-05-30 Thread Samuel Pitoiset
We should just try to refactor nve4_validate_tic() and 
nve4_compute_validate_textures() because it's quite similar now.


Anyway, this patch is:

Reviewed-by: Samuel Pitoiset 

On 05/30/2016 04:18 AM, Ilia Mirkin wrote:

(a) Make sure to update the TIC in case of an updated buffer address
(b) Mark newly-inactive textures dirty so that we update the handle in
set_tex_handles.

Signed-off-by: Ilia Mirkin 
---

Unfortunately none of this helps UE4 Elemental.

 src/gallium/drivers/nouveau/nvc0/nvc0_context.h | 2 ++
 src/gallium/drivers/nouveau/nvc0/nvc0_tex.c | 2 +-
 src/gallium/drivers/nouveau/nvc0/nve4_compute.c | 5 -
 3 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_context.h 
b/src/gallium/drivers/nouveau/nvc0/nvc0_context.h
index c099758..5e4ed3d 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_context.h
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_context.h
@@ -333,6 +333,8 @@ void nve4_set_tex_handles(struct nvc0_context *);
 void nvc0_validate_surfaces(struct nvc0_context *);
 void nve4_set_surface_info(struct nouveau_pushbuf *, struct pipe_image_view *,
struct nvc0_context *);
+void nvc0_update_tic(struct nvc0_context *, struct nv50_tic_entry *,
+ struct nv04_resource *);

 struct pipe_sampler_view *
 nvc0_create_texture_view(struct pipe_context *,
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_tex.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_tex.c
index b6ea1e3..92662aa 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_tex.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_tex.c
@@ -413,7 +413,7 @@ nvc0_create_texture_view(struct pipe_context *pipe,
return gf100_create_texture_view(pipe, texture, templ, flags, target);
 }

-static void
+void
 nvc0_update_tic(struct nvc0_context *nvc0, struct nv50_tic_entry *tic,
 struct nv04_resource *res)
 {
diff --git a/src/gallium/drivers/nouveau/nvc0/nve4_compute.c 
b/src/gallium/drivers/nouveau/nvc0/nve4_compute.c
index a4bbe8c..9052808 100644
--- a/src/gallium/drivers/nouveau/nvc0/nve4_compute.c
+++ b/src/gallium/drivers/nouveau/nvc0/nve4_compute.c
@@ -653,6 +653,7 @@ nve4_compute_validate_textures(struct nvc0_context *nvc0)
  continue;
   }
   res = nv04_resource(tic->pipe.texture);
+  nvc0_update_tic(nvc0, tic, res);

   if (tic->id < 0) {
  tic->id = nvc0_screen_tic_alloc(nvc0->screen, tic);
@@ -685,8 +686,10 @@ nve4_compute_validate_textures(struct nvc0_context *nvc0)
   if (dirty)
  BCTX_REFN(nvc0->bufctx_cp, CP_TEX(i), res, RD);
}
-   for (; i < nvc0->state.num_textures[s]; ++i)
+   for (; i < nvc0->state.num_textures[s]; ++i) {
   nvc0->tex_handles[s][i] |= NVE4_TIC_ENTRY_INVALID;
+  nvc0->textures_dirty[s] |= 1 << i;
+   }

if (n[0]) {
   BEGIN_NVC0(push, NVE4_CP(FLUSH), 1);



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


[Mesa-dev] [PATCH v3] glx: fix error code when there is no context bound

2016-05-30 Thread Tapani Pälli
From: Bernard Kilarski 

v2: change all related NULL checks to check against dummyContext
v3: really check for dummyContext *only* when ctx was from
__glXGetCurrentContext

Signed-off-by: Bernard Kilarski 
Signed-off-by: Matt Roper 
Signed-off-by: Tapani Pälli 
Cc: "11.2" 
---
 src/glx/glx_pbuffer.c |  2 +-
 src/glx/glxcmds.c | 12 ++--
 src/glx/query_renderer.c  |  4 ++--
 src/glx/tests/fake_glx_screen.cpp |  6 +-
 4 files changed, 14 insertions(+), 10 deletions(-)

diff --git a/src/glx/glx_pbuffer.c b/src/glx/glx_pbuffer.c
index 231ab20..ab29899 100644
--- a/src/glx/glx_pbuffer.c
+++ b/src/glx/glx_pbuffer.c
@@ -328,7 +328,7 @@ GetDrawableAttribute(Display * dpy, GLXDrawable drawable,
*   the calling thread's current context a GLXBadDrawable error is
*   generated."
*/
-  if (pdraw == NULL || gc == NULL || gc->currentDpy != dpy ||
+  if (pdraw == NULL || gc ==  || gc->currentDpy != dpy ||
  (gc->currentDrawable != drawable &&
  gc->currentReadable != drawable)) {
  __glXSendError(dpy, GLXBadDrawable, drawable,
diff --git a/src/glx/glxcmds.c b/src/glx/glxcmds.c
index 589a87a..bff01d2 100644
--- a/src/glx/glxcmds.c
+++ b/src/glx/glxcmds.c
@@ -1728,7 +1728,7 @@ __glXSwapIntervalSGI(int interval)
CARD32 *interval_ptr;
CARD8 opcode;
 
-   if (gc == NULL) {
+   if (gc == ) {
   return GLX_BAD_CONTEXT;
}
 
@@ -1834,7 +1834,7 @@ __glXGetVideoSyncSGI(unsigned int *count)
__GLXDRIdrawable *pdraw;
 #endif
 
-   if (!gc)
+   if (gc == )
   return GLX_BAD_CONTEXT;
 
 #ifdef GLX_DIRECT_RENDERING
@@ -1876,7 +1876,7 @@ __glXWaitVideoSyncSGI(int divisor, int remainder, 
unsigned int *count)
if (divisor <= 0 || remainder < 0)
   return GLX_BAD_VALUE;
 
-   if (!gc)
+   if (gc == )
   return GLX_BAD_CONTEXT;
 
 #ifdef GLX_DIRECT_RENDERING
@@ -2189,7 +2189,7 @@ __glXSwapBuffersMscOML(Display * dpy, GLXDrawable 
drawable,
struct glx_screen *psc = pdraw ? pdraw->psc : NULL;
 #endif
 
-   if (!gc) /* no GLX for this */
+   if (gc == ) /* no GLX for this */
   return -1;
 
 #ifdef GLX_DIRECT_RENDERING
@@ -2408,7 +2408,7 @@ __glXBindTexImageEXT(Display * dpy,
 {
struct glx_context *gc = __glXGetCurrentContext();
 
-   if (gc == NULL || gc->vtable->bind_tex_image == NULL)
+   if (gc ==  || gc->vtable->bind_tex_image == NULL)
   return;
 
gc->vtable->bind_tex_image(dpy, drawable, buffer, attrib_list);
@@ -2419,7 +2419,7 @@ __glXReleaseTexImageEXT(Display * dpy, GLXDrawable 
drawable, int buffer)
 {
struct glx_context *gc = __glXGetCurrentContext();
 
-   if (gc == NULL || gc->vtable->release_tex_image == NULL)
+   if (gc ==  || gc->vtable->release_tex_image == NULL)
   return;
 
gc->vtable->release_tex_image(dpy, drawable, buffer);
diff --git a/src/glx/query_renderer.c b/src/glx/query_renderer.c
index 9108ec2..4debf06 100644
--- a/src/glx/query_renderer.c
+++ b/src/glx/query_renderer.c
@@ -106,7 +106,7 @@ glXQueryCurrentRendererIntegerMESA(int attribute, unsigned 
int *value)
 {
struct glx_context *gc = __glXGetCurrentContext();
 
-   if (gc == NULL)
+   if (gc == )
   return False;
 
return __glXQueryRendererInteger(gc->psc, attribute, value);
@@ -166,7 +166,7 @@ glXQueryCurrentRendererStringMESA(int attribute)
 {
struct glx_context *gc = __glXGetCurrentContext();
 
-   if (gc == NULL)
+   if (gc == )
   return False;
 
return __glXQueryRendererString(gc->psc, attribute);
diff --git a/src/glx/tests/fake_glx_screen.cpp 
b/src/glx/tests/fake_glx_screen.cpp
index db20749..c288aa6 100644
--- a/src/glx/tests/fake_glx_screen.cpp
+++ b/src/glx/tests/fake_glx_screen.cpp
@@ -75,7 +75,11 @@ indirect_create_context_attribs(struct glx_screen *base,
return indirect_create_context(base, config_base, shareList, 0);
 }
 
-__thread void *__glX_tls_Context = NULL;
+/* This is necessary so that we don't have to link with glxcurrent.c
+ * which would require us to link with X libraries and what not.
+ */
+struct glx_context dummyContext;
+__thread void *__glX_tls_Context = 
 
 #if !defined(GLX_USE_TLS)
 extern "C" struct glx_context *
-- 
2.5.5

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