date:20150926

[Mesa-dev] [Bug 91797] [r600g] Company of Heroes 2 crash when zooming on the map

2015-09-26 Thread bugzilla-daemon

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

--- Comment #2 from Marek Olšák  ---
Is it always reproducible? If yes, could you create an apitrace?

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

[Mesa-dev] [Bug 91643] mesa-demos-8.2.0 (latest released version) fails to build against mesa-10.6.4-2.mga6.tainted.src.rpm

2015-09-26 Thread bugzilla-daemon

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

Marek Olšák  changed:

   What|Removed |Added

 CC||m...@fireburn.co.uk

--- Comment #8 from Marek Olšák  ---
*** Bug 91020 has been marked as a duplicate of this bug. ***

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

[Mesa-dev] [Bug 91020] Mesa's demo / tools won't compile since EGL changes

2015-09-26 Thread bugzilla-daemon

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

Marek Olšák  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #6 from Marek Olšák  ---


*** This bug has been marked as a duplicate of bug 91643 ***

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

Re: [Mesa-dev] [PATCH 2/6] mesa: rename gl_shader_program's NumUniformBlocks to NumUniformShaderStorageBlocks

2015-09-26 Thread Jordan Justen

On 2015-09-25 01:24:46, Samuel Iglesias Gonsalvez wrote:
> Because it counts shader storage blocks too.
> 
> Signed-off-by: Samuel Iglesias Gonsalvez 
> ---
>  src/glsl/link_uniform_initializers.cpp |  2 +-
>  src/glsl/link_uniforms.cpp |  4 ++--
>  src/glsl/linker.cpp| 10 +-
>  src/glsl/standalone_scaffolding.cpp|  2 +-
>  src/mesa/drivers/dri/i965/brw_fs_nir.cpp   |  8 
>  src/mesa/drivers/dri/i965/brw_vec4_nir.cpp |  8 
>  src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp |  2 +-
>  src/mesa/main/mtypes.h |  2 +-
>  src/mesa/main/shaderapi.c  |  2 +-
>  src/mesa/main/shaderobj.c  |  2 +-
>  src/mesa/main/uniforms.c   |  8 
>  11 files changed, 25 insertions(+), 25 deletions(-)
> 
> diff --git a/src/glsl/link_uniform_initializers.cpp 
> b/src/glsl/link_uniform_initializers.cpp
> index 05000fc..f7fbcb0 100644
> --- a/src/glsl/link_uniform_initializers.cpp
> +++ b/src/glsl/link_uniform_initializers.cpp
> @@ -48,7 +48,7 @@ static unsigned
>  get_uniform_block_index(const gl_shader_program *shProg,
>  const char *uniformBlockName)
>  {
> -   for (unsigned i = 0; i < shProg->NumUniformBlocks; i++) {
> +   for (unsigned i = 0; i < shProg->NumUniformShaderStorageBlocks; i++) {

Since UBO and SSBO both fall under the interface blocks category, what
about NumBufferInterfaceBlocks instead? 'Buffer' seems to distinguish
them from interstage interface blocks.

-Jordan

>if (!strcmp(shProg->UniformBlocks[i].Name, uniformBlockName))
>  return i;
> }
> diff --git a/src/glsl/link_uniforms.cpp b/src/glsl/link_uniforms.cpp
> index 1c901e2..7b6c6d6 100644
> --- a/src/glsl/link_uniforms.cpp
> +++ b/src/glsl/link_uniforms.cpp
> @@ -504,7 +504,7 @@ public:
>   if (var->is_interface_instance() && var->type->is_array()) {
>  unsigned l = strlen(var->get_interface_type()->name);
>  
> -for (unsigned i = 0; i < prog->NumUniformBlocks; i++) {
> +for (unsigned i = 0; i < prog->NumUniformShaderStorageBlocks; 
> i++) {
> if (strncmp(var->get_interface_type()->name,
> prog->UniformBlocks[i].Name,
> l) == 0
> @@ -514,7 +514,7 @@ public:
> }
>  }
>   } else {
> -for (unsigned i = 0; i < prog->NumUniformBlocks; i++) {
> +for (unsigned i = 0; i < prog->NumUniformShaderStorageBlocks; 
> i++) {
> if (strcmp(var->get_interface_type()->name,
>prog->UniformBlocks[i].Name) == 0) {
>ubo_block_index = i;
> diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
> index 9d419ac..d6a62bf 100644
> --- a/src/glsl/linker.cpp
> +++ b/src/glsl/linker.cpp
> @@ -1187,7 +1187,7 @@ interstage_cross_validate_uniform_blocks(struct 
> gl_shader_program *prog)
>for (unsigned int j = 0; j < sh->NumUniformBlocks; j++) {
>  int index = link_cross_validate_uniform_block(prog,
>>UniformBlocks,
> -  
> >NumUniformBlocks,
> +  
> >NumUniformShaderStorageBlocks,
>>UniformBlocks[j]);
>  
>  if (index == -1) {
> @@ -2802,7 +2802,7 @@ check_resources(struct gl_context *ctx, struct 
> gl_shader_program *prog)
> unsigned shader_blocks[MESA_SHADER_STAGES] = {0};
> unsigned total_shader_storage_blocks = 0;
>  
> -   for (unsigned i = 0; i < prog->NumUniformBlocks; i++) {
> +   for (unsigned i = 0; i < prog->NumUniformShaderStorageBlocks; i++) {
>/* Don't check SSBOs for Uniform Block Size */
>if (!prog->UniformBlocks[i].IsShaderStorage &&
>prog->UniformBlocks[i].UniformBufferSize > 
> ctx->Const.MaxUniformBlockSize) {
> @@ -2836,7 +2836,7 @@ check_resources(struct gl_context *ctx, struct 
> gl_shader_program *prog)
>  
>if (total_uniform_blocks > ctx->Const.MaxCombinedUniformBlocks) {
>  linker_error(prog, "Too many combined uniform blocks (%d/%d)\n",
> - prog->NumUniformBlocks,
> + prog->NumUniformShaderStorageBlocks,
>   ctx->Const.MaxCombinedUniformBlocks);
>} else {
>  for (unsigned i = 0; i < MESA_SHADER_STAGES; i++) {
> @@ -2939,7 +2939,7 @@ check_image_resources(struct gl_context *ctx, struct 
> gl_shader_program *prog)
>  
>   total_image_units += sh->NumImages;
>  
> - for (unsigned j = 0; j < prog->NumUniformBlocks; j++) {
> + for (unsigned j = 0; j < prog->NumUniformShaderStorageBlocks; j++) {
>  int stage_index = prog->UniformBlockStageIndex[i][j];
>  if (stage_index !=

[Mesa-dev] [Bug 91643] mesa-demos-8.2.0 (latest released version) fails to build against mesa-10.6.4-2.mga6.tainted.src.rpm

2015-09-26 Thread bugzilla-daemon

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

Marek Olšák  changed:

   What|Removed |Added

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

--- Comment #7 from Marek Olšák  ---
Fixed by demos commit 74443c6ee79f3251f643ea05e94df58183e37d0d. 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
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] Mesa 11.0.1

2015-09-26 Thread Emil Velikov

Mesa 11.0.1 is now available.

With this release we have mostly nouveau and i965 fixes, although there
is the odd llvmpipe (big endian) and gbm bugfix.


Antia Puentes (2):
  i965/vec4: Fix saturation errors when coalescing registers
  i965/vec4_nir: Load constants as integers

Anuj Phogat (1):
  meta: Abort meta pbo path if TexSubImage need signed unsigned conversion

Emil Velikov (3):
  docs: add sha256 checksums for 11.0.0
  Update version to 11.0.1
  docs: add release notes for 11.0.1

Iago Toral Quiroga (1):
  mesa: Fix GL_FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE for default framebuffer.

Ian Romanick (5):
  t_dd_dmatmp: Make "count" actually be the count
  t_dd_dmatmp: Clean up improper code formatting from previous patch
  t_dd_dmatmp: Use '& 3' instead of '% 4' everywhere
  t_dd_dmatmp: Pull out common 'count -= count & 3' code
  t_dd_dmatmp: Use addition instead of subtraction in loop bounds

Ilia Mirkin (6):
  st/mesa: avoid integer overflows with buffers >= 512MB
  nv50, nvc0: fix max texture buffer size to 128M elements
  freedreno/a3xx: fix blending of L8 format
  nv50,nvc0: detect underlying resource changes and update tic
  nv50,nvc0: flush texture cache in presence of coherent bufs
  radeonsi: load fmask ptr relative to the resources array

Jason Ekstrand (2):
  nir: Fix a bunch of ralloc parenting errors
  i965/vec4: Don't reswizzle hardware registers

Jeremy Huddleston (1):
  configure.ac: Add support to enable read-only text segment on x86.

Ray Strode (1):
  gbm: convert gbm bo format to fourcc format on dma-buf import

Tapani Pälli (2):
  mesa: fix errors when reading depth with glReadPixels
  i965: fix textureGrad for cubemaps

Ulrich Weigand (1):
  mesa: Fix texture compression on big-endian systems


git tag: mesa-11.0.1

ftp://ftp.freedesktop.org/pub/mesa/11.0.1/mesa-11.0.1.tar.gz
MD5: 7c4065b88206ab878f8ad8de620daf4b  mesa-11.0.1.tar.gz
SHA1: 28214092898e3abf9e6beff67f429cc6fc90feca  mesa-11.0.1.tar.gz
SHA256: 6dab262877e12c0546a0e2970c6835a0f217e6d4026ccecb3cd5dd733d1ce867  
mesa-11.0.1.tar.gz
PGP: ftp://ftp.freedesktop.org/pub/mesa/11.0.1/mesa-11.0.1.tar.gz.sig

ftp://ftp.freedesktop.org/pub/mesa/11.0.1/mesa-11.0.1.tar.xz
MD5: 52335bcd40be8e17e3af18d879d6a72f  mesa-11.0.1.tar.xz
SHA1: cd6334fcb6f9047155d22d13de70e1d78fdfef87  mesa-11.0.1.tar.xz
SHA256: 43d0dfcd1f1e36f07f8228cd76d90175d3fc74c1ed25d7071794a100a98ef2a6  
mesa-11.0.1.tar.xz
PGP: ftp://ftp.freedesktop.org/pub/mesa/11.0.1/mesa-11.0.1.tar.xz.sig

--
-Emil



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

[Mesa-dev] [PATCH] mesa: don't leak interface_name

2015-09-26 Thread Ilia Mirkin

Found by Coverity

Signed-off-by: Ilia Mirkin 
---
 src/mesa/main/shader_query.cpp | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/mesa/main/shader_query.cpp b/src/mesa/main/shader_query.cpp
index 99d9e10..e020dce 100644
--- a/src/mesa/main/shader_query.cpp
+++ b/src/mesa/main/shader_query.cpp
@@ -995,6 +995,7 @@ program_resource_top_level_array_stride(struct 
gl_shader_program *shProg,
   }
}
 found_top_level_array_size:
+   free(interface_name);
free(var_name);
return array_stride;
 }
-- 
2.4.9

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

Re: [Mesa-dev] [PATCH 4/6] main/tests: Enable glShaderStorageBlockBinding() check in dispatch_sanity test

2015-09-26 Thread Samuel Iglesias Gonsálvez

On 25/09/15 18:45, Matt Turner wrote:
> Reviewed-by: Matt Turner 
> 
> Please commit this one as soon as possible.
> 

Pushed. Thanks,

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

[Mesa-dev] Returning 0 from std430_base_alignment

2015-09-26 Thread Ilia Mirkin

Hi Samuel,

Coverity is up in a tizzy because std430_base_alignment can return 0
(which in turn would cause tons of errors since it's used with
glsl_align). Is there a better starting value that can be used for its
is_record() case? For std140 it's 16... I assume for std430 it's 4 or
something? That would allow Coverity to conclude that 0 will never be
returned from the function... as-is an empty struct would get an
alignment of 0 and create lots of div-by-zero. Not sure if that's a
legit scenario though.

Alternatively, an assert(base_alignment > 0) will most likely appease it.

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

Re: [Mesa-dev] [PATCH 6/6] i965: Simplify handling of VUE map changes.

2015-09-26 Thread Chris Forbes

For the v2 series:

Reviewed-by: Chris Forbes 

On Sat, Sep 12, 2015 at 6:58 PM, Kenneth Graunke 
wrote:

> The old code was disasterously complex - spread across multiple atoms
> which may not even run, inspecting the dirty bits to try and decide
> whether it was necessary to do checks...storing VS information in
> brw_context...extra flagging...
>
> This code tripped me and Carl up very badly when working on the
> shader cache code.  It's very fragile and hard to maintain.
>
> Now that geometry shaders only depend on their inputs and don't have
> to worry about the VS VUE map, we can dramatically simplify this:
> just compute the VUE map coming out of the geometry shader stage
> in brw_upload_programs.  If it changes, flag it.  Done.
>
> v2: Also check vue_map.separable.
>
> Signed-off-by: Kenneth Graunke 
> Reviewed-by: Chris Forbes  [v1]
> ---
>  src/mesa/drivers/dri/i965/brw_context.h  | 12 +---
>  src/mesa/drivers/dri/i965/brw_gs.c   | 16 +---
>  src/mesa/drivers/dri/i965/brw_state_upload.c | 16 +++-
>  src/mesa/drivers/dri/i965/brw_vs.c   | 15 ---
>  4 files changed, 17 insertions(+), 42 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_context.h
> b/src/mesa/drivers/dri/i965/brw_context.h
> index 772a9fd..4cac30c 100644
> --- a/src/mesa/drivers/dri/i965/brw_context.h
> +++ b/src/mesa/drivers/dri/i965/brw_context.h
> @@ -194,7 +194,6 @@ enum brw_state_id {
> BRW_STATE_GS_CONSTBUF,
> BRW_STATE_PROGRAM_CACHE,
> BRW_STATE_STATE_BASE_ADDRESS,
> -   BRW_STATE_VUE_MAP_VS,
> BRW_STATE_VUE_MAP_GEOM_OUT,
> BRW_STATE_TRANSFORM_FEEDBACK,
> BRW_STATE_RASTERIZER_DISCARD,
> @@ -276,7 +275,6 @@ enum brw_state_id {
>  #define BRW_NEW_GS_CONSTBUF (1ull << BRW_STATE_GS_CONSTBUF)
>  #define BRW_NEW_PROGRAM_CACHE   (1ull << BRW_STATE_PROGRAM_CACHE)
>  #define BRW_NEW_STATE_BASE_ADDRESS  (1ull <<
> BRW_STATE_STATE_BASE_ADDRESS)
> -#define BRW_NEW_VUE_MAP_VS  (1ull << BRW_STATE_VUE_MAP_VS)
>  #define BRW_NEW_VUE_MAP_GEOM_OUT(1ull <<
> BRW_STATE_VUE_MAP_GEOM_OUT)
>  #define BRW_NEW_TRANSFORM_FEEDBACK  (1ull <<
> BRW_STATE_TRANSFORM_FEEDBACK)
>  #define BRW_NEW_RASTERIZER_DISCARD  (1ull <<
> BRW_STATE_RASTERIZER_DISCARD)
> @@ -1375,16 +1373,8 @@ struct brw_context
> } curbe;
>
> /**
> -* Layout of vertex data exiting the vertex shader.
> -*
> -* BRW_NEW_VUE_MAP_VS is flagged when this VUE map changes.
> -*/
> -   struct brw_vue_map vue_map_vs;
> -
> -   /**
>  * Layout of vertex data exiting the geometry portion of the pipleine.
> -* This comes from the geometry shader if one exists, otherwise from
> the
> -* vertex shader.
> +* This comes from the last enabled shader stage (GS, DS, or VS).
>  *
>  * BRW_NEW_VUE_MAP_GEOM_OUT is flagged when the VUE map changes.
>  */
> diff --git a/src/mesa/drivers/dri/i965/brw_gs.c
> b/src/mesa/drivers/dri/i965/brw_gs.c
> index 77be9d9..1f219c0 100644
> --- a/src/mesa/drivers/dri/i965/brw_gs.c
> +++ b/src/mesa/drivers/dri/i965/brw_gs.c
> @@ -297,8 +297,7 @@ brw_gs_state_dirty(struct brw_context *brw)
> return brw_state_dirty(brw,
>_NEW_TEXTURE,
>BRW_NEW_GEOMETRY_PROGRAM |
> -  BRW_NEW_TRANSFORM_FEEDBACK |
> -  BRW_NEW_VUE_MAP_VS);
> +  BRW_NEW_TRANSFORM_FEEDBACK);
>  }
>
>  static void
> @@ -336,11 +335,6 @@ brw_upload_gs_prog(struct brw_context *brw)
>
> if (gp == NULL) {
>/* No geometry shader.  Vertex data just passes straight through. */
> -  if (brw->ctx.NewDriverState & BRW_NEW_VUE_MAP_VS) {
> - brw->vue_map_geom_out = brw->vue_map_vs;
> - brw->ctx.NewDriverState |= BRW_NEW_VUE_MAP_GEOM_OUT;
> -  }
> -
>if (brw->gen == 6 &&
>(brw->ctx.NewDriverState & BRW_NEW_TRANSFORM_FEEDBACK)) {
>   gen6_brw_upload_ff_gs_prog(brw);
> @@ -367,14 +361,6 @@ brw_upload_gs_prog(struct brw_context *brw)
>(void)success;
> }
> brw->gs.base.prog_data = >gs.prog_data->base.base;
> -
> -   if (brw->gs.prog_data->base.vue_map.slots_valid !=
> -   brw->vue_map_geom_out.slots_valid ||
> -   brw->gs.prog_data->base.vue_map.separate !=
> -   brw->vue_map_geom_out.separate) {
> -  brw->vue_map_geom_out = brw->gs.prog_data->base.vue_map;
> -  brw->ctx.NewDriverState |= BRW_NEW_VUE_MAP_GEOM_OUT;
> -   }
>  }
>
>  bool
> diff --git a/src/mesa/drivers/dri/i965/brw_state_upload.c
> b/src/mesa/drivers/dri/i965/brw_state_upload.c
> index 14627d5..89fde52 100644
> --- a/src/mesa/drivers/dri/i965/brw_state_upload.c
> +++ b/src/mesa/drivers/dri/i965/brw_state_upload.c
> @@ -593,7 +593,6 @@ static struct dirty_bit_map brw_bits[] = {
> DEFINE_BIT(BRW_NEW_GS_CONSTBUF),
> DEFINE_BIT(BRW_NEW_PROGRAM_CACHE),
>

[Mesa-dev] [PATCH] gallium/util: avoid unreferencing random memory on buffer alloc failure

2015-09-26 Thread Ilia Mirkin

Found by Coverity

Signed-off-by: Ilia Mirkin 
---
 src/gallium/auxiliary/util/u_blitter.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/auxiliary/util/u_blitter.c 
b/src/gallium/auxiliary/util/u_blitter.c
index 2fbf69c..b7b1ece 100644
--- a/src/gallium/auxiliary/util/u_blitter.c
+++ b/src/gallium/auxiliary/util/u_blitter.c
@@ -2065,7 +2065,7 @@ void util_blitter_clear_buffer(struct blitter_context 
*blitter,
struct blitter_context_priv *ctx = (struct blitter_context_priv*)blitter;
struct pipe_context *pipe = ctx->base.pipe;
struct pipe_vertex_buffer vb = {0};
-   struct pipe_stream_output_target *so_target;
+   struct pipe_stream_output_target *so_target = NULL;
unsigned offsets[PIPE_MAX_SO_BUFFERS] = {0};
 
assert(num_channels >= 1);
-- 
2.4.9

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

[Mesa-dev] [PATCH 1/2] state_trackers/hgl: Fix missing include path

2015-09-26 Thread Alexander von Gluck IV

---
 src/gallium/state_trackers/hgl/SConscript |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/src/gallium/state_trackers/hgl/SConscript 
b/src/gallium/state_trackers/hgl/SConscript
index 82a0ce0..d2389c8 100644
--- a/src/gallium/state_trackers/hgl/SConscript
+++ b/src/gallium/state_trackers/hgl/SConscript
@@ -9,6 +9,7 @@ env.Append(CPPPATH = [
 '#/src',
 '#/src/mapi',
 '#/src/mesa',
+'#/include/HaikuGL',
 ])
 
 sources = [
-- 
1.7.1

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

Re: [Mesa-dev] memoryBarrier + SSBO

2015-09-26 Thread Albert Freeman

On 27 September 2015 at 08:30, Ilia Mirkin  wrote:
> On Sat, Sep 26, 2015 at 6:12 PM, Albert Freeman
>  wrote:
>> On 26 September 2015 at 03:32, Ilia Mirkin  wrote:
>>> Hi Ian (and other spec experts),
>>>
>>> The ARB_ssbo spec mentions the following:
>>>
>>> OpenGL 4.0 (either core or compatibility profile) is required.
>>>
>>> ...
>>>
>>> Additionally, the shading language provides the memoryBarrier() function
>>> to control the relative order of memory accesses within individual 
>>> shader
>>> invocations and provides various memory qualifiers controlling how the
>>> memory corresponding to individual variables is accessed.
>>>
>>> However the memoryBarrier() function only becomes available in GLSL
>>> 4.20 [along with the glMemoryBarrier() function that the spec also
>>> refers to] or with ARB_shader_image_load_store.
>>>
>>> Is the implication that such functionality should be auto-exposed in
>>> image-less drivers that support ssbo? Or that this functionality
>>> should just not exist unless images are supported?
>>>
>>> This is relevant to me as I plan on adding ssbo support to gallium
>>> before images. Also, is there really anything in there that would
>>> prevent this from being exposed on a GL 3.1 driver (I'm thinking of
>>> freedreno which doesn't support GS yet and is my initial target for
>>> this, since I can make atomics actually work on there, unlike NVIDIA
>>> where the damn things just won't budge without some magic
>>> yet-to-be-found make-it-work bit).
>>>
>>> Cheers,
>>>
>>>   -ilia
>>
>> I think that is an error in the ARB_ssbo spec (as that spec also
>> mentions: "This extension is written against the OpenGL 4.2
>> (Compatibility Profile) Specification."). I believe this occurred as
>> ARB_ssbo was adapted from NV_ssbo; NV_ssbo does not mention
>> MemoryBarrier (i.e. someone forgot to update the version when NV_ssbo
>> was enhanced for ARB).
>
> Many extension specs are like this though... written as a diff against
> OpenGL version X, but require OpenGL version Y, s.t. Y < X.
>
> What are you saying is the spec error, by the way? The minimum version
> requirement? Or the fact that the interaction isn't listed?
>
>   -ilia
The minimum version requirement, it is GL 4.0 on NV_ssbo and wasen't
changed when that was "enhanced" (e.g. Memory Barrier stuff was added)
for ARB_ssbo.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] memoryBarrier + SSBO

2015-09-26 Thread Albert Freeman

On 27 September 2015 at 08:32, Albert Freeman  wrote:
> On 27 September 2015 at 08:30, Ilia Mirkin  wrote:
>> On Sat, Sep 26, 2015 at 6:12 PM, Albert Freeman
>>  wrote:
>>> On 26 September 2015 at 03:32, Ilia Mirkin  wrote:
 Hi Ian (and other spec experts),

 The ARB_ssbo spec mentions the following:

 OpenGL 4.0 (either core or compatibility profile) is required.

 ...

 Additionally, the shading language provides the memoryBarrier() 
 function
 to control the relative order of memory accesses within individual 
 shader
 invocations and provides various memory qualifiers controlling how the
 memory corresponding to individual variables is accessed.

 However the memoryBarrier() function only becomes available in GLSL
 4.20 [along with the glMemoryBarrier() function that the spec also
 refers to] or with ARB_shader_image_load_store.

 Is the implication that such functionality should be auto-exposed in
 image-less drivers that support ssbo? Or that this functionality
 should just not exist unless images are supported?

 This is relevant to me as I plan on adding ssbo support to gallium
 before images. Also, is there really anything in there that would
 prevent this from being exposed on a GL 3.1 driver (I'm thinking of
 freedreno which doesn't support GS yet and is my initial target for
 this, since I can make atomics actually work on there, unlike NVIDIA
 where the damn things just won't budge without some magic
 yet-to-be-found make-it-work bit).

 Cheers,

   -ilia
>>>
>>> I think that is an error in the ARB_ssbo spec (as that spec also
>>> mentions: "This extension is written against the OpenGL 4.2
>>> (Compatibility Profile) Specification."). I believe this occurred as
>>> ARB_ssbo was adapted from NV_ssbo; NV_ssbo does not mention
>>> MemoryBarrier (i.e. someone forgot to update the version when NV_ssbo
>>> was enhanced for ARB).
>>
>> Many extension specs are like this though... written as a diff against
>> OpenGL version X, but require OpenGL version Y, s.t. Y < X.
>>
>> What are you saying is the spec error, by the way? The minimum version
>> requirement? Or the fact that the interaction isn't listed?
>>
>>   -ilia
> The minimum version requirement, it is GL 4.0 on NV_ssbo and wasen't
> changed when that was "enhanced" (e.g. Memory Barrier stuff was added)
> for ARB_ssbo.
Actually, it could be either, probably better for the ARB to decide.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] gallium/util: avoid unreferencing random memory on buffer alloc failure

2015-09-26 Thread Albert Freeman

On 27 September 2015 at 09:35, Ilia Mirkin  wrote:
> On Sat, Sep 26, 2015 at 7:29 PM, Albert Freeman
>  wrote:
>> On 27 September 2015 at 03:46, Ilia Mirkin  wrote:
>>> Found by Coverity
>>>
>>> Signed-off-by: Ilia Mirkin 
>>> ---
>>>  src/gallium/auxiliary/util/u_blitter.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/src/gallium/auxiliary/util/u_blitter.c 
>>> b/src/gallium/auxiliary/util/u_blitter.c
>>> index 2fbf69c..b7b1ece 100644
>>> --- a/src/gallium/auxiliary/util/u_blitter.c
>>> +++ b/src/gallium/auxiliary/util/u_blitter.c
>>> @@ -2065,7 +2065,7 @@ void util_blitter_clear_buffer(struct blitter_context 
>>> *blitter,
>>> struct blitter_context_priv *ctx = (struct 
>>> blitter_context_priv*)blitter;
>>> struct pipe_context *pipe = ctx->base.pipe;
>>> struct pipe_vertex_buffer vb = {0};
>>> -   struct pipe_stream_output_target *so_target;
>>> +   struct pipe_stream_output_target *so_target = NULL;
>>> unsigned offsets[PIPE_MAX_SO_BUFFERS] = {0};
>>>
>>> assert(num_channels >= 1);
>>> --
>>> 2.4.9
>>>
>>> ___
>>> mesa-dev mailing list
>>> mesa-dev@lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>> "so_target = pipe->create_stream_output_target(pipe, dst, offset,
>> size);" unconditionally assigns to so_target before first use (unless
>> I am reading something incorrectly).
>>
>
>u_upload_data(ctx->upload, 0, num_channels*4, clear_value,
>  _offset, );
>if (!vb.buffer)
>   goto out;
> ...
>so_target = pipe->create_stream_output_target(pipe, dst, offset, size);
> ...
> out:
> ...
>pipe_so_target_reference(_target, NULL);
>
> If the goto out is taken, then _target gets unreferenced. This is
> done by (roughly speaking) freeing the pointer that gets passed in,
> and then assigning it to NULL.
>
>> Perhaps all function pointers that don't get implemented by a driver
>> should be zeroed? I am trying to think where this could be done (in
>> the gallium drivers themselves? (although that doesn’t seem the ideal
>> solution)). Perhaps in a function that is part of gallium itself
>> (outside drivers/[state trackers]/etc) that gets called upon driver
>> shared library load.
>
> Most things are calloc'd and are thus initialized to null. Not sure
> what that has to do with this issue though.
>
>   -ilia
Sorry, I was referencing slightly outdated mesa git code (without the goto).
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] mesa: Reduce libGL.so binary size by about 15%

2015-09-26 Thread Jeremy Huddleston Sequoia

Reviewing diffs of code that generates code is always ick. =(

This *looks* right to me, but has it been given a beating for correctness?  If 
not, let me know, and I'll give it a whirl when I have some cycles.

Reviewed-by: Jeremy Huddleston Sequoia 

---

You're right that this used to be use in xserver as well, but that was removed 
in:

commit e61e19959d9138d5b81b1f25b7aa3e257918170d
Author: Adam Jackson 
Date:   Tue Dec 3 13:45:43 2013 -0500

xquartz/glx: Convert to non-glapi dispatch

CGL doesn't have anything like glXGetProcAddress, and the old code just
called down to dlsym in any case.  It's a little mind-warping since
dlopening a framework actually loads multiple dylibs, but that's just
how OSX rolls.

Signed-off-by: Adam Jackson 
Reviewed-by: Jeremy Huddleston Sequoia 


> On Sep 22, 2015, at 15:55, Ian Romanick  wrote:
> 
> On 09/17/2015 03:19 PM, Arlie Davis wrote:
>> Ok, here's v2 of the change, with the suggested edits.
> 
> So... I think this code is fine, and I admire the effort.  I have a
> couple concerns.
> 
> 1. We have no way to test this, so it's quite possible something was broken.
> 
> 2. This function is only used in the OSX builds.  Jeremy is the
> maintainer for those builds, so I've added him to the CC list.
> 
> For every non-OSX build, we should just stop linking
> src/mapi/glapi/glapi_gentable.c.  I thought maybe the X sever used it,
> but I couldn't find any evidence of that.
> 
> If this is still a viable route, I have a few suggestions of follow-on
> patches...
> 
> I guess this patch is
> 
> Reviewed-by: Ian Romanick 
> 
> but I really think we need to get Jeremy's approval before pushing it.
> 
>> From 5f393faa058f453408dfc640eecae3fe6335dfed Mon Sep 17 00:00:00 2001
>> From: Arlie Davis 
>> Date: Tue, 15 Sep 2015 09:58:34 -0700
>> Subject: [PATCH] This patch significantly reduces the size of the libGL.so
>> binary. It does not change the (externally visible) behavior of libGL.so at
>> all.
>> 
>> gl_gentable.py generates a function, _glapi_create_table_from_handle.
>> This function allocates a large dispatch table, consisting of 1300 or so
>> function pointers, and fills this dispatch table by doing symbol lookups
>> on a given shared library.  Previously, gl_gentable.py would generate a
>> single, very large _glapi_create_table_from_handle function, with a short
>> cluster of lines for each entry point (function).  The idiom it generates
>> was a NULL check, a call to snprintf, a call to dlsym / GetProcAddress,
>> and then a store into the dispatch table.  Since this function processes
>> a large number of entry points, this code is duplicated many times over.
>> 
>> We can encode the same information much more compactly, by using a lookup
>> table.  The previous total size of _glapi_create_table_from_handle on x64
>> was 125848 bytes.  By using a lookup table, the size of
>> _glapi_create_table_from_handle (and the related lookup tables) is reduced
>> to 10840 bytes.  In other words, this enormous function is reduced by 91%.
>> The size of the entire libGL.so binary (measured when stripped) itself drops
>> by 15%.
>> 
>> So the purpose of this change is to reduce the binary size, which frees up
>> disk space, memory, etc.
>> ---
>> src/mapi/glapi/gen/gl_gentable.py | 57 
>> ---
>> 1 file changed, 41 insertions(+), 16 deletions(-)
>> 
>> diff --git a/src/mapi/glapi/gen/gl_gentable.py 
>> b/src/mapi/glapi/gen/gl_gentable.py
>> index 1b3eb72..7cd475a 100644
>> --- a/src/mapi/glapi/gen/gl_gentable.py
>> +++ b/src/mapi/glapi/gen/gl_gentable.py
>> @@ -113,6 +113,9 @@ __glapi_gentable_set_remaining_noop(struct _glapi_table 
>> *disp) {
>> dispatch[i] = p.v;
>> }
>> 
>> +"""
>> +
>> +footer = """
>> struct _glapi_table *
>> _glapi_create_table_from_handle(void *handle, const char *symbol_prefix) {
>> struct _glapi_table *disp = calloc(_glapi_get_dispatch_table_size(), 
>> sizeof(_glapi_proc));
>> @@ -123,27 +126,28 @@ _glapi_create_table_from_handle(void *handle, const 
>> char *symbol_prefix) {
>> 
>> if(symbol_prefix == NULL)
>> symbol_prefix = "";
>> -"""
>> 
>> -footer = """
>> -__glapi_gentable_set_remaining_noop(disp);
>> -
>> -return disp;
>> -}
>> -"""
>> +/* Note: This code relies on _glapi_table_func_names being sorted by the
>> + * entry point index of each function.
>> + */
>> +for (int func_index = 0; func_index < GLAPI_TABLE_COUNT; ++func_index) {
>> +const char *name = _glapi_table_func_names[func_index];
>> +void ** procp = &((void **)disp)[func_index];
>> 
>> -body_template = """
>> -if(!disp->%(name)s) {
>> -void ** procp = (void **) >%(name)s;
>> -snprintf(symboln, sizeof(symboln), "%%s%(entry_point)s", 
>> symbol_prefix);
>> +snprintf(symboln,

Re: [Mesa-dev] memoryBarrier + SSBO

2015-09-26 Thread Albert Freeman

On 26 September 2015 at 03:32, Ilia Mirkin  wrote:
> Hi Ian (and other spec experts),
>
> The ARB_ssbo spec mentions the following:
>
> OpenGL 4.0 (either core or compatibility profile) is required.
>
> ...
>
> Additionally, the shading language provides the memoryBarrier() function
> to control the relative order of memory accesses within individual shader
> invocations and provides various memory qualifiers controlling how the
> memory corresponding to individual variables is accessed.
>
> However the memoryBarrier() function only becomes available in GLSL
> 4.20 [along with the glMemoryBarrier() function that the spec also
> refers to] or with ARB_shader_image_load_store.
>
> Is the implication that such functionality should be auto-exposed in
> image-less drivers that support ssbo? Or that this functionality
> should just not exist unless images are supported?
>
> This is relevant to me as I plan on adding ssbo support to gallium
> before images. Also, is there really anything in there that would
> prevent this from being exposed on a GL 3.1 driver (I'm thinking of
> freedreno which doesn't support GS yet and is my initial target for
> this, since I can make atomics actually work on there, unlike NVIDIA
> where the damn things just won't budge without some magic
> yet-to-be-found make-it-work bit).
>
> Cheers,
>
>   -ilia
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
I think that is an error in the ARB_ssbo spec (as that spec also
mentions: "This extension is written against the OpenGL 4.2
(Compatibility Profile) Specification."). I believe this occurred as
ARB_ssbo was adapted from NV_ssbo; NV_ssbo does not mention
MemoryBarrier (i.e. someone forgot to update the version when NV_ssbo
was enhanced for ARB).
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] memoryBarrier + SSBO

2015-09-26 Thread Ilia Mirkin

On Sat, Sep 26, 2015 at 6:12 PM, Albert Freeman
 wrote:
> On 26 September 2015 at 03:32, Ilia Mirkin  wrote:
>> Hi Ian (and other spec experts),
>>
>> The ARB_ssbo spec mentions the following:
>>
>> OpenGL 4.0 (either core or compatibility profile) is required.
>>
>> ...
>>
>> Additionally, the shading language provides the memoryBarrier() function
>> to control the relative order of memory accesses within individual shader
>> invocations and provides various memory qualifiers controlling how the
>> memory corresponding to individual variables is accessed.
>>
>> However the memoryBarrier() function only becomes available in GLSL
>> 4.20 [along with the glMemoryBarrier() function that the spec also
>> refers to] or with ARB_shader_image_load_store.
>>
>> Is the implication that such functionality should be auto-exposed in
>> image-less drivers that support ssbo? Or that this functionality
>> should just not exist unless images are supported?
>>
>> This is relevant to me as I plan on adding ssbo support to gallium
>> before images. Also, is there really anything in there that would
>> prevent this from being exposed on a GL 3.1 driver (I'm thinking of
>> freedreno which doesn't support GS yet and is my initial target for
>> this, since I can make atomics actually work on there, unlike NVIDIA
>> where the damn things just won't budge without some magic
>> yet-to-be-found make-it-work bit).
>>
>> Cheers,
>>
>>   -ilia
>
> I think that is an error in the ARB_ssbo spec (as that spec also
> mentions: "This extension is written against the OpenGL 4.2
> (Compatibility Profile) Specification."). I believe this occurred as
> ARB_ssbo was adapted from NV_ssbo; NV_ssbo does not mention
> MemoryBarrier (i.e. someone forgot to update the version when NV_ssbo
> was enhanced for ARB).

Many extension specs are like this though... written as a diff against
OpenGL version X, but require OpenGL version Y, s.t. Y < X.

What are you saying is the spec error, by the way? The minimum version
requirement? Or the fact that the interaction isn't listed?

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

Re: [Mesa-dev] [PATCH] gallium/util: avoid unreferencing random memory on buffer alloc failure

2015-09-26 Thread Albert Freeman

On 27 September 2015 at 03:46, Ilia Mirkin  wrote:
> Found by Coverity
>
> Signed-off-by: Ilia Mirkin 
> ---
>  src/gallium/auxiliary/util/u_blitter.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/gallium/auxiliary/util/u_blitter.c 
> b/src/gallium/auxiliary/util/u_blitter.c
> index 2fbf69c..b7b1ece 100644
> --- a/src/gallium/auxiliary/util/u_blitter.c
> +++ b/src/gallium/auxiliary/util/u_blitter.c
> @@ -2065,7 +2065,7 @@ void util_blitter_clear_buffer(struct blitter_context 
> *blitter,
> struct blitter_context_priv *ctx = (struct blitter_context_priv*)blitter;
> struct pipe_context *pipe = ctx->base.pipe;
> struct pipe_vertex_buffer vb = {0};
> -   struct pipe_stream_output_target *so_target;
> +   struct pipe_stream_output_target *so_target = NULL;
> unsigned offsets[PIPE_MAX_SO_BUFFERS] = {0};
>
> assert(num_channels >= 1);
> --
> 2.4.9
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
"so_target = pipe->create_stream_output_target(pipe, dst, offset,
size);" unconditionally assigns to so_target before first use (unless
I am reading something incorrectly).

Perhaps all function pointers that don't get implemented by a driver
should be zeroed? I am trying to think where this could be done (in
the gallium drivers themselves? (although that doesn’t seem the ideal
solution)). Perhaps in a function that is part of gallium itself
(outside drivers/[state trackers]/etc) that gets called upon driver
shared library load.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] gallium/util: avoid unreferencing random memory on buffer alloc failure

2015-09-26 Thread Albert Freeman

Reviewed-by: Albert Freeman 

On 27 September 2015 at 09:41, Albert Freeman  wrote:
> On 27 September 2015 at 09:35, Ilia Mirkin  wrote:
>> On Sat, Sep 26, 2015 at 7:29 PM, Albert Freeman
>>  wrote:
>>> On 27 September 2015 at 03:46, Ilia Mirkin  wrote:
 Found by Coverity

 Signed-off-by: Ilia Mirkin 
 ---
  src/gallium/auxiliary/util/u_blitter.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/src/gallium/auxiliary/util/u_blitter.c 
 b/src/gallium/auxiliary/util/u_blitter.c
 index 2fbf69c..b7b1ece 100644
 --- a/src/gallium/auxiliary/util/u_blitter.c
 +++ b/src/gallium/auxiliary/util/u_blitter.c
 @@ -2065,7 +2065,7 @@ void util_blitter_clear_buffer(struct 
 blitter_context *blitter,
 struct blitter_context_priv *ctx = (struct 
 blitter_context_priv*)blitter;
 struct pipe_context *pipe = ctx->base.pipe;
 struct pipe_vertex_buffer vb = {0};
 -   struct pipe_stream_output_target *so_target;
 +   struct pipe_stream_output_target *so_target = NULL;
 unsigned offsets[PIPE_MAX_SO_BUFFERS] = {0};

 assert(num_channels >= 1);
 --
 2.4.9

 ___
 mesa-dev mailing list
 mesa-dev@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>> "so_target = pipe->create_stream_output_target(pipe, dst, offset,
>>> size);" unconditionally assigns to so_target before first use (unless
>>> I am reading something incorrectly).
>>>
>>
>>u_upload_data(ctx->upload, 0, num_channels*4, clear_value,
>>  _offset, );
>>if (!vb.buffer)
>>   goto out;
>> ...
>>so_target = pipe->create_stream_output_target(pipe, dst, offset, size);
>> ...
>> out:
>> ...
>>pipe_so_target_reference(_target, NULL);
>>
>> If the goto out is taken, then _target gets unreferenced. This is
>> done by (roughly speaking) freeing the pointer that gets passed in,
>> and then assigning it to NULL.
>>
>>> Perhaps all function pointers that don't get implemented by a driver
>>> should be zeroed? I am trying to think where this could be done (in
>>> the gallium drivers themselves? (although that doesn’t seem the ideal
>>> solution)). Perhaps in a function that is part of gallium itself
>>> (outside drivers/[state trackers]/etc) that gets called upon driver
>>> shared library load.
>>
>> Most things are calloc'd and are thus initialized to null. Not sure
>> what that has to do with this issue though.
>>
>>   -ilia
> Sorry, I was referencing slightly outdated mesa git code (without the goto).
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 92122] [bisected] Regression with Assault Android Cactus

2015-09-26 Thread bugzilla-daemon

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

--- Comment #2 from MWATTT  ---
This commit also breaks Cities: Skylines. The ground is not rendered.
Tested with a AMD JUNIPER chip and LLVMpipe.

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

Re: [Mesa-dev] [PATCH 06/11] loader: use HAVE_LIBDRM instead of ! __NOT_HAVE_DRM_H

2015-09-26 Thread Jeremy Huddleston Sequoia

Sorry, been slammed and trying to catch up.  I forget if I replied to this or 
not, but if you're still waiting on me:

Reviewed-by: Jeremy Huddleston Sequoia 


> On Jul 9, 2015, at 10:55, Ian Romanick  wrote:
> 
> I can't really speak to the Android.mk or SConscript changes, but the
> rest of this patch is
> 
> Reviewed-by: Ian Romanick 
> 
> You might also see what Jeremy Huddleston Sequoia 
> thinks, since most of this exists to support his platform. :)
> 
> On 07/08/2015 10:07 AM, Emil Velikov wrote:
>> Double negatives in English language are normally avoided, plus the
>> former seems cleaner and more consistent.
>> 
>> Signed-off-by: Emil Velikov 
>> ---
>> src/loader/Android.mk  | 6 ++
>> src/loader/Makefile.am | 5 +
>> src/loader/SConscript  | 2 --
>> src/loader/loader.c| 8 
>> src/loader/pci_id_driver_map.c | 2 +-
>> 5 files changed, 8 insertions(+), 15 deletions(-)
>> 
>> diff --git a/src/loader/Android.mk b/src/loader/Android.mk
>> index 92d9fd2..8690565 100644
>> --- a/src/loader/Android.mk
>> +++ b/src/loader/Android.mk
>> @@ -33,10 +33,8 @@ include $(CLEAR_VARS)
>> LOCAL_SRC_FILES := \
>>  $(LOADER_C_FILES)
>> 
>> -# swrast only
>> -ifeq ($(MESA_GPU_DRIVERS),swrast)
>> -LOCAL_CFLAGS += -D__NOT_HAVE_DRM_H
>> -else
>> +ifneq ($(filter-out swrast,$(MESA_GPU_DRIVERS)),)
>> +LOCAL_CFLAGS += -DHAVE_LIBDRM
>> LOCAL_SHARED_LIBRARIES := libdrm
>> endif
>> 
>> diff --git a/src/loader/Makefile.am b/src/loader/Makefile.am
>> index aef1bd6..5190f7f 100644
>> --- a/src/loader/Makefile.am
>> +++ b/src/loader/Makefile.am
>> @@ -48,10 +48,7 @@ libloader_la_CPPFLAGS += \
>> 
>> endif
>> 
>> -if !HAVE_LIBDRM
>> -libloader_la_CPPFLAGS += \
>> --D__NOT_HAVE_DRM_H
>> -else
>> +if HAVE_LIBDRM
>> libloader_la_CPPFLAGS += \
>>  $(LIBDRM_CFLAGS)
>> 
>> diff --git a/src/loader/SConscript b/src/loader/SConscript
>> index 16d1053..d98f11e 100644
>> --- a/src/loader/SConscript
>> +++ b/src/loader/SConscript
>> @@ -8,8 +8,6 @@ env.Prepend(CPPPATH = [
>> '#include'
>> ])
>> 
>> -env.Append(CPPDEFINES = ['__NOT_HAVE_DRM_H'])
>> -
>> if env['udev']:
>> env.PkgUseModules('UDEV')
>> env.Append(CPPDEFINES = ['HAVE_LIBUDEV'])
>> diff --git a/src/loader/loader.c b/src/loader/loader.c
>> index 8780587..4ed0a1f 100644
>> --- a/src/loader/loader.c
>> +++ b/src/loader/loader.c
>> @@ -85,7 +85,7 @@
>> #endif
>> #include "loader.h"
>> 
>> -#ifndef __NOT_HAVE_DRM_H
>> +#ifdef HAVE_LIBDRM
>> #include 
>> #endif
>> 
>> @@ -501,7 +501,7 @@ sysfs_get_pci_id_for_fd(int fd, int *vendor_id, int 
>> *chip_id)
>> }
>> #endif
>> 
>> -#if !defined(__NOT_HAVE_DRM_H)
>> +#if defined(HAVE_LIBDRM)
>> /* for i915 */
>> #include 
>> /* for radeon */
>> @@ -584,7 +584,7 @@ loader_get_pci_id_for_fd(int fd, int *vendor_id, int 
>> *chip_id)
>>if (sysfs_get_pci_id_for_fd(fd, vendor_id, chip_id))
>>   return 1;
>> #endif
>> -#if !defined(__NOT_HAVE_DRM_H)
>> +#if HAVE_LIBDRM
>>if (drm_get_pci_id_for_fd(fd, vendor_id, chip_id))
>>   return 1;
>> #endif
>> @@ -695,7 +695,7 @@ loader_get_driver_for_fd(int fd, unsigned driver_types)
>> 
>>if (!loader_get_pci_id_for_fd(fd, _id, _id)) {
>> 
>> -#ifndef __NOT_HAVE_DRM_H
>> +#if HAVE_LIBDRM
>>   /* fallback to drmGetVersion(): */
>>   drmVersionPtr version = drmGetVersion(fd);
>> 
>> diff --git a/src/loader/pci_id_driver_map.c b/src/loader/pci_id_driver_map.c
>> index cb6f705..3c4657f 100644
>> --- a/src/loader/pci_id_driver_map.c
>> +++ b/src/loader/pci_id_driver_map.c
>> @@ -23,7 +23,7 @@
>> 
>> int is_nouveau_vieux(int fd);
>> 
>> -#ifndef __NOT_HAVE_DRM_H
>> +#ifdef HAVE_LIBDRM
>> 
>> #include 
>> #include 
>> 
> 



smime.p7s
Description: S/MIME cryptographic signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] gallium/util: avoid unreferencing random memory on buffer alloc failure

2015-09-26 Thread Ilia Mirkin

On Sat, Sep 26, 2015 at 7:29 PM, Albert Freeman
 wrote:
> On 27 September 2015 at 03:46, Ilia Mirkin  wrote:
>> Found by Coverity
>>
>> Signed-off-by: Ilia Mirkin 
>> ---
>>  src/gallium/auxiliary/util/u_blitter.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/src/gallium/auxiliary/util/u_blitter.c 
>> b/src/gallium/auxiliary/util/u_blitter.c
>> index 2fbf69c..b7b1ece 100644
>> --- a/src/gallium/auxiliary/util/u_blitter.c
>> +++ b/src/gallium/auxiliary/util/u_blitter.c
>> @@ -2065,7 +2065,7 @@ void util_blitter_clear_buffer(struct blitter_context 
>> *blitter,
>> struct blitter_context_priv *ctx = (struct blitter_context_priv*)blitter;
>> struct pipe_context *pipe = ctx->base.pipe;
>> struct pipe_vertex_buffer vb = {0};
>> -   struct pipe_stream_output_target *so_target;
>> +   struct pipe_stream_output_target *so_target = NULL;
>> unsigned offsets[PIPE_MAX_SO_BUFFERS] = {0};
>>
>> assert(num_channels >= 1);
>> --
>> 2.4.9
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
> "so_target = pipe->create_stream_output_target(pipe, dst, offset,
> size);" unconditionally assigns to so_target before first use (unless
> I am reading something incorrectly).
>

   u_upload_data(ctx->upload, 0, num_channels*4, clear_value,
 _offset, );
   if (!vb.buffer)
  goto out;
...
   so_target = pipe->create_stream_output_target(pipe, dst, offset, size);
...
out:
...
   pipe_so_target_reference(_target, NULL);

If the goto out is taken, then _target gets unreferenced. This is
done by (roughly speaking) freeing the pointer that gets passed in,
and then assigning it to NULL.

> Perhaps all function pointers that don't get implemented by a driver
> should be zeroed? I am trying to think where this could be done (in
> the gallium drivers themselves? (although that doesn’t seem the ideal
> solution)). Perhaps in a function that is part of gallium itself
> (outside drivers/[state trackers]/etc) that gets called upon driver
> shared library load.

Most things are calloc'd and are thus initialized to null. Not sure
what that has to do with this issue though.

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

Re: [Mesa-dev] [PATCH 14/24] i965: fix atomic buffer index for bindings other than 0

2015-09-26 Thread Ilia Mirkin

On Thu, Sep 17, 2015 at 3:02 AM, Timothy Arceri  wrote:
> Since commit c0cd5b var->data.binding was being used as a replacement
> for atomic buffer index, but they don't have to be the same value they
> just happen to end up the same when binding is 0.
>
> Now that we store the atomic uniform location in var->data.location
> we can use this to lookup the atomic buffer index in uniform storage.

FWIW I ran into a similar problem when trying to implement atomic
counters in gallium. I assume that this logic depends on some other
bit from this patch series, since I don't see that we store the value
in var->data.location in the upstream code?

>
> For arrays of arrays the outer arrays have separate uniform locations
> however they all share the same buffer so we can get the buffer index
> using the base uniform location.
>
> Cc: Alejandro Piñeiro 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90175
> ---
>  src/glsl/nir/glsl_to_nir.cpp   |  2 --
>  src/glsl/nir/nir.h |  4 ++--
>  src/glsl/nir/nir_lower_atomics.c   | 18 --
>  src/mesa/drivers/dri/i965/brw_nir.c|  6 --
>  src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp |  2 +-
>  5 files changed, 19 insertions(+), 13 deletions(-)
>
> diff --git a/src/glsl/nir/glsl_to_nir.cpp b/src/glsl/nir/glsl_to_nir.cpp
> index c13f953..6b2da89 100644
> --- a/src/glsl/nir/glsl_to_nir.cpp
> +++ b/src/glsl/nir/glsl_to_nir.cpp
> @@ -330,8 +330,6 @@ nir_visitor::visit(ir_variable *ir)
>
> var->data.index = ir->data.index;
> var->data.binding = ir->data.binding;
> -   /* XXX Get rid of buffer_index */
> -   var->data.atomic.buffer_index = ir->data.binding;
> var->data.atomic.offset = ir->data.atomic.offset;
> var->data.image.read_only = ir->data.image_read_only;
> var->data.image.write_only = ir->data.image_write_only;
> diff --git a/src/glsl/nir/nir.h b/src/glsl/nir/nir.h
> index 3a19bd3..a974188 100644
> --- a/src/glsl/nir/nir.h
> +++ b/src/glsl/nir/nir.h
> @@ -308,7 +308,6 @@ typedef struct {
> * Location an atomic counter is stored at.
> */
>struct {
> - unsigned buffer_index;
>   unsigned offset;
>} atomic;
>
> @@ -1834,7 +1833,8 @@ void nir_lower_system_values(nir_shader *shader);
>  void nir_lower_tex_projector(nir_shader *shader);
>  void nir_lower_idiv(nir_shader *shader);
>
> -void nir_lower_atomics(nir_shader *shader);
> +void nir_lower_atomics(nir_shader *shader,
> +   const struct gl_shader_program *shader_program);
>  void nir_lower_to_source_mods(nir_shader *shader);
>
>  void nir_normalize_cubemap_coords(nir_shader *shader);
> diff --git a/src/glsl/nir/nir_lower_atomics.c 
> b/src/glsl/nir/nir_lower_atomics.c
> index 46e1376..52e7675 100644
> --- a/src/glsl/nir/nir_lower_atomics.c
> +++ b/src/glsl/nir/nir_lower_atomics.c
> @@ -25,6 +25,7 @@
>   *
>   */
>
> +#include "ir_uniform.h"
>  #include "nir.h"
>  #include "main/config.h"
>  #include 
> @@ -35,7 +36,8 @@
>   */
>
>  static void
> -lower_instr(nir_intrinsic_instr *instr, nir_function_impl *impl)
> +lower_instr(nir_intrinsic_instr *instr,
> +const struct gl_shader_program *shader_program)
>  {
> nir_intrinsic_op op;
> switch (instr->intrinsic) {
> @@ -60,10 +62,11 @@ lower_instr(nir_intrinsic_instr *instr, nir_function_impl 
> *impl)
>return; /* atomics passed as function arguments can't be lowered */
>
> void *mem_ctx = ralloc_parent(instr);
> +   unsigned uniform_loc = instr->variables[0]->var->data.location;
>
> nir_intrinsic_instr *new_instr = nir_intrinsic_instr_create(mem_ctx, op);
> new_instr->const_index[0] =
> -  (int) instr->variables[0]->var->data.atomic.buffer_index;
> +  shader_program->UniformStorage[uniform_loc].atomic_buffer_index;
>
> nir_load_const_instr *offset_const = nir_load_const_instr_create(mem_ctx, 
> 1);
> offset_const->value.u[0] = instr->variables[0]->var->data.atomic.offset;
> @@ -128,22 +131,25 @@ lower_instr(nir_intrinsic_instr *instr, 
> nir_function_impl *impl)
>  }
>
>  static bool
> -lower_block(nir_block *block, void *state)
> +lower_block(nir_block *block, void *prog)
>  {
> nir_foreach_instr_safe(block, instr) {
>if (instr->type == nir_instr_type_intrinsic)
> - lower_instr(nir_instr_as_intrinsic(instr), state);
> + lower_instr(nir_instr_as_intrinsic(instr),
> + (const struct gl_shader_program *) prog);
> }
>
> return true;
>  }
>
>  void
> -nir_lower_atomics(nir_shader *shader)
> +nir_lower_atomics(nir_shader *shader,
> +  const struct gl_shader_program *shader_program)
>  {
> nir_foreach_overload(shader, overload) {
>if (overload->impl) {
> - nir_foreach_block(overload->impl, lower_block, overload->impl);
> + nir_foreach_block(overload->impl, lower_block,
> +   (void

Re: [Mesa-dev] [PATCH 14/24] i965: fix atomic buffer index for bindings other than 0

2015-09-26 Thread Timothy Arceri



On 27 September 2015 6:23:42 am AEST, Ilia Mirkin  wrote:
>On Thu, Sep 17, 2015 at 3:02 AM, Timothy Arceri 
>wrote:
>> Since commit c0cd5b var->data.binding was being used as a replacement
>> for atomic buffer index, but they don't have to be the same value
>they
>> just happen to end up the same when binding is 0.
>>
>> Now that we store the atomic uniform location in var->data.location
>> we can use this to lookup the atomic buffer index in uniform storage.
>
>FWIW I ran into a similar problem when trying to implement atomic
>counters in gallium. I assume that this logic depends on some other
>bit from this patch series, since I don't see that we store the value
>in var->data.location in the upstream code?

It wad added recently [1] as part of my struct indirect indexing fix.

[1] http://cgit.freedesktop.org/mesa/mesa/tree/src/glsl/link_uniforms.cpp#n750


>
>>
>> For arrays of arrays the outer arrays have separate uniform locations
>> however they all share the same buffer so we can get the buffer index
>> using the base uniform location.
>>
>> Cc: Alejandro Piñeiro 
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90175
>> ---
>>  src/glsl/nir/glsl_to_nir.cpp   |  2 --
>>  src/glsl/nir/nir.h |  4 ++--
>>  src/glsl/nir/nir_lower_atomics.c   | 18
>--
>>  src/mesa/drivers/dri/i965/brw_nir.c|  6 --
>>  src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp |  2 +-
>>  5 files changed, 19 insertions(+), 13 deletions(-)
>>
>> diff --git a/src/glsl/nir/glsl_to_nir.cpp
>b/src/glsl/nir/glsl_to_nir.cpp
>> index c13f953..6b2da89 100644
>> --- a/src/glsl/nir/glsl_to_nir.cpp
>> +++ b/src/glsl/nir/glsl_to_nir.cpp
>> @@ -330,8 +330,6 @@ nir_visitor::visit(ir_variable *ir)
>>
>> var->data.index = ir->data.index;
>> var->data.binding = ir->data.binding;
>> -   /* XXX Get rid of buffer_index */
>> -   var->data.atomic.buffer_index = ir->data.binding;
>> var->data.atomic.offset = ir->data.atomic.offset;
>> var->data.image.read_only = ir->data.image_read_only;
>> var->data.image.write_only = ir->data.image_write_only;
>> diff --git a/src/glsl/nir/nir.h b/src/glsl/nir/nir.h
>> index 3a19bd3..a974188 100644
>> --- a/src/glsl/nir/nir.h
>> +++ b/src/glsl/nir/nir.h
>> @@ -308,7 +308,6 @@ typedef struct {
>> * Location an atomic counter is stored at.
>> */
>>struct {
>> - unsigned buffer_index;
>>   unsigned offset;
>>} atomic;
>>
>> @@ -1834,7 +1833,8 @@ void nir_lower_system_values(nir_shader
>*shader);
>>  void nir_lower_tex_projector(nir_shader *shader);
>>  void nir_lower_idiv(nir_shader *shader);
>>
>> -void nir_lower_atomics(nir_shader *shader);
>> +void nir_lower_atomics(nir_shader *shader,
>> +   const struct gl_shader_program
>*shader_program);
>>  void nir_lower_to_source_mods(nir_shader *shader);
>>
>>  void nir_normalize_cubemap_coords(nir_shader *shader);
>> diff --git a/src/glsl/nir/nir_lower_atomics.c
>b/src/glsl/nir/nir_lower_atomics.c
>> index 46e1376..52e7675 100644
>> --- a/src/glsl/nir/nir_lower_atomics.c
>> +++ b/src/glsl/nir/nir_lower_atomics.c
>> @@ -25,6 +25,7 @@
>>   *
>>   */
>>
>> +#include "ir_uniform.h"
>>  #include "nir.h"
>>  #include "main/config.h"
>>  #include 
>> @@ -35,7 +36,8 @@
>>   */
>>
>>  static void
>> -lower_instr(nir_intrinsic_instr *instr, nir_function_impl *impl)
>> +lower_instr(nir_intrinsic_instr *instr,
>> +const struct gl_shader_program *shader_program)
>>  {
>> nir_intrinsic_op op;
>> switch (instr->intrinsic) {
>> @@ -60,10 +62,11 @@ lower_instr(nir_intrinsic_instr *instr,
>nir_function_impl *impl)
>>return; /* atomics passed as function arguments can't be
>lowered */
>>
>> void *mem_ctx = ralloc_parent(instr);
>> +   unsigned uniform_loc = instr->variables[0]->var->data.location;
>>
>> nir_intrinsic_instr *new_instr =
>nir_intrinsic_instr_create(mem_ctx, op);
>> new_instr->const_index[0] =
>> -  (int) instr->variables[0]->var->data.atomic.buffer_index;
>> + 
>shader_program->UniformStorage[uniform_loc].atomic_buffer_index;
>>
>> nir_load_const_instr *offset_const =
>nir_load_const_instr_create(mem_ctx, 1);
>> offset_const->value.u[0] =
>instr->variables[0]->var->data.atomic.offset;
>> @@ -128,22 +131,25 @@ lower_instr(nir_intrinsic_instr *instr,
>nir_function_impl *impl)
>>  }
>>
>>  static bool
>> -lower_block(nir_block *block, void *state)
>> +lower_block(nir_block *block, void *prog)
>>  {
>> nir_foreach_instr_safe(block, instr) {
>>if (instr->type == nir_instr_type_intrinsic)
>> - lower_instr(nir_instr_as_intrinsic(instr), state);
>> + lower_instr(nir_instr_as_intrinsic(instr),
>> + (const struct gl_shader_program *) prog);
>> }
>>
>> return true;
>>  }
>>
>>  void
>> -nir_lower_atomics(nir_shader *shader)
>>

Re: [Mesa-dev] [Mesa-stable] [PATCH] i965/fs: Fix hang on IVB and VLV with image format mismatch.

2015-09-26 Thread Francisco Jerez

Emil Velikov  writes:

> Hi Francisco,
>
> On 9 September 2015 at 18:04, Ian Romanick  wrote:
>> On 09/09/2015 05:30 AM, Francisco Jerez wrote:
>>> Ian Romanick  writes:
>>>
 On 09/03/2015 06:03 AM, Francisco Jerez wrote:
> IVB and VLV hang sporadically when an untyped surface read or write
> message is used to access a surface of format other than RAW, as may
> happen when there is a mismatch between the format qualifier of the
> image uniform and the format of the actual image bound to the
> pipeline.  According to the spec this condition gives undefined
> results but may not lead to program termination (which is one of the
> possible outcomes of the hang).  Fix it by checking at runtime whether
> the surface is of the right type.
>
> Fixes the "arb_shader_image_load_store.invalid/format mismatch" piglit
> subtest.
>
> Reported-by: Mark Janes 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91718
> CC: mesa-sta...@lists.freedesktop.org
> ---
>  .../drivers/dri/i965/brw_fs_surface_builder.cpp| 42 
> +++---
>  1 file changed, 38 insertions(+), 4 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_fs_surface_builder.cpp 
> b/src/mesa/drivers/dri/i965/brw_fs_surface_builder.cpp
> index f60afc9..57ce87f 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs_surface_builder.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs_surface_builder.cpp
> @@ -313,12 +313,42 @@ namespace {
>
> namespace image_validity {
>/**
> +   * Check whether the bound image is suitable for untyped access.
> +   */
> +  brw_predicate
> +  emit_untyped_image_check(const fs_builder , const fs_reg 
> ,
> +   brw_predicate pred)
> +  {
> + const brw_device_info *devinfo = bld.shader->devinfo;
> + const fs_reg stride = offset(image, bld, 
> BRW_IMAGE_PARAM_STRIDE_OFFSET);
> +
> + if (devinfo->gen == 7 && !devinfo->is_haswell) {
> +/* Check whether the first stride component (i.e. the Bpp 
> value)
> + * is greater than four, what on Gen7 indicates that a 
> surface of
> + * type RAW has been bound for untyped access.  Reading or 
> writing
> + * to a surface of type other than RAW using untyped surface
> + * messages causes a hang on IVB and VLV.
> + */
> +set_predicate(pred,
> +  bld.CMP(bld.null_reg_ud(), stride, fs_reg(4),
> +  BRW_CONDITIONAL_G));
> +
> +return BRW_PREDICATE_NORMAL;
> + } else {
> +/* More recent generations handle the format mismatch
> + * gracefully.
> + */
> +return pred;
> + }
> +  }
> +
> +  /**
> * Check whether there is an image bound at the given index and 
> write
> * the comparison result to f0.0.  Returns an appropriate 
> predication
> * mode to use on subsequent image operations.
> */
>brw_predicate
> -  emit_surface_check(const fs_builder , const fs_reg )
> +  emit_typed_atomic_check(const fs_builder , const fs_reg )

 This change seems spurious (and also reasonable).

>>> The problem is that this patch introduces a new kind of surface check
>>> applicable to untyped surface reads and writes only, so it would have
>>> been confusing to keep the other surface check which is applicable to
>>> atomics only with its previous rather unspecific name.
>>>
>{
>   const brw_device_info *devinfo = bld.shader->devinfo;
>   const fs_reg size = offset(image, bld, 
> BRW_IMAGE_PARAM_SIZE_OFFSET);
> @@ -895,7 +925,9 @@ namespace brw {
>   * surface read on the result,
>   */
>  const brw_predicate pred =
> -   emit_bounds_check(bld, image, saddr, dims);
> +   emit_untyped_image_check(bld, image,
> +emit_bounds_check(bld, image,
> +  saddr, dims));

 These appear to be the only two users of emit_bounds_check... shouldn't
 the bounds still be tested?

>>> Yes, they are still.
>>
>> Ah... I completely missed that emit_bounds_check was moved into a
>> parameter of the call to emit_untyped_image_check.
>>
>> Reviewed-by: Ian Romanick 
>>
> Considering Ian's r-b, are there any obstacles why this hasn't landed
> in master yet ?
>
Nope, sorry, I've been on vacation and with intermittent

Re: [Mesa-dev] [PATCH] mesa: don't leak interface_name

2015-09-26 Thread Timothy Arceri



On 27 September 2015 3:39:22 am AEST, Ilia Mirkin  wrote:
>Found by Coverity
>
>Signed-off-by: Ilia Mirkin 

Reviewed-by: Timothy Arceri 

>---
> src/mesa/main/shader_query.cpp | 1 +
> 1 file changed, 1 insertion(+)
>
>diff --git a/src/mesa/main/shader_query.cpp
>b/src/mesa/main/shader_query.cpp
>index 99d9e10..e020dce 100644
>--- a/src/mesa/main/shader_query.cpp
>+++ b/src/mesa/main/shader_query.cpp
>@@ -995,6 +995,7 @@ program_resource_top_level_array_stride(struct
>gl_shader_program *shProg,
>   }
>}
> found_top_level_array_size:
>+   free(interface_name);
>free(var_name);
>return array_stride;
> }
>-- 
>2.4.9
>
>___
>mesa-dev mailing list
>mesa-dev@lists.freedesktop.org
>http://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Mesa-dev] [Bug 92125] make check DispatchSanity_test.GL31_CORE regression

2015-09-26 Thread bugzilla-daemon

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

Vinson Lee  changed:

   What|Removed |Added

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

--- Comment #2 from Vinson Lee  ---
commit 511a86383b9d6490788a15cca2df791c6d63bfd7
Author: Samuel Iglesias Gonsalvez 
Date:   Tue Sep 15 08:18:39 2015 +0200

main/tests: Enable glShaderStorageBlockBinding() check in dispatch_sanity
test

Signed-off-by: Samuel Iglesias Gonsalvez 
Reviewed-by: Matt Turner 

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

Re: [Mesa-dev] [PATCH 14/24] i965: fix atomic buffer index for bindings other than 0

2015-09-26 Thread Ilia Mirkin

On Sat, Sep 26, 2015 at 5:17 PM, Timothy Arceri  wrote:
>
>
> On 27 September 2015 6:23:42 am AEST, Ilia Mirkin  
> wrote:
>>On Thu, Sep 17, 2015 at 3:02 AM, Timothy Arceri 
>>wrote:
>>> Since commit c0cd5b var->data.binding was being used as a replacement
>>> for atomic buffer index, but they don't have to be the same value
>>they
>>> just happen to end up the same when binding is 0.
>>>
>>> Now that we store the atomic uniform location in var->data.location
>>> we can use this to lookup the atomic buffer index in uniform storage.
>>
>>FWIW I ran into a similar problem when trying to implement atomic
>>counters in gallium. I assume that this logic depends on some other
>>bit from this patch series, since I don't see that we store the value
>>in var->data.location in the upstream code?
>
> It wad added recently [1] as part of my struct indirect indexing fix.
>
> [1] http://cgit.freedesktop.org/mesa/mesa/tree/src/glsl/link_uniforms.cpp#n750

Oh, that's sneaky. It wasn't where I expected :)

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

Re: [Mesa-dev] [PATCH] i965/miptree: Rename intel_miptree_map::mt -> ::linear_mt (v2)

2015-09-26 Thread Michael Schellenberger Costa

Hi,
Am 25/09/2015 um 23:24 schrieb Chad Versace:
> Because that's what it is. It's an untiled, *linear* miptree.
> 
> v2: - Add space after /*. - Use one comment per function argument. 
> --- src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 28
> ++- 
> src/mesa/drivers/dri/i965/intel_mipmap_tree.h |  2 +- 2 files
> changed, 16 insertions(+), 14 deletions(-)
> 
> diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c index
> 1259664..067276c 100644 ---
> a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c +++
> b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c @@ -2140,16
> +2140,18 @@ intel_miptree_map_blit(struct brw_context *brw, struct
> intel_miptree_map *map, unsigned int level, unsigned int slice) { -
> map->mt = intel_miptree_create(brw, GL_TEXTURE_2D, mt->format, -
> 0, 0, -  map->w, map->h, 1, -
> 0, MIPTREE_LAYOUT_TILING_NONE); +   map->linear_mt =
> intel_miptree_create(brw, GL_TEXTURE_2D, mt->format, +
> /* first_level */ 0, + /*
> last_level */ 0,
I am not sure about mesa, but the logical ordering is:
ARG, /* Comment */

Best wishes
Michael
> + map->w, map->h, 1, +
> /* samples */ 0, +
> MIPTREE_LAYOUT_TILING_NONE);
> 
> -   if (!map->mt) { +   if (!map->linear_mt) { fprintf(stderr,
> "Failed to allocate blit temporary\n"); goto fail; } -
> map->stride = map->mt->pitch; +   map->stride =
> map->linear_mt->pitch;
> 
> /* One of either READ_BIT or WRITE_BIT or both is set.  READ_BIT
> implies no * INVALIDATE_RANGE_BIT.  WRITE_BIT needs the original
> values read in unless @@ -2160,7 +2162,7 @@
> intel_miptree_map_blit(struct brw_context *brw, if
> (!intel_miptree_blit(brw, mt, level, slice, map->x, map->y, false, 
> -  map->mt, 0, 0, +
> map->linear_mt, 0, 0, 0, 0, false, map->w, map->h, GL_COPY)) { 
> fprintf(stderr, "Failed to blit\n"); @@ -2168,7 +2170,7 @@
> intel_miptree_map_blit(struct brw_context *brw, } }
> 
> -   map->ptr = intel_miptree_map_raw(brw, map->mt); +   map->ptr =
> intel_miptree_map_raw(brw, map->linear_mt);
> 
> DBG("%s: %d,%d %dx%d from mt %p (%s) %d,%d = %p/%d\n", __func__, 
> map->x, map->y, map->w, map->h, @@ -2178,7 +2180,7 @@
> intel_miptree_map_blit(struct brw_context *brw, return;
> 
> fail: -   intel_miptree_release(>mt); +
> intel_miptree_release(>linear_mt); map->ptr = NULL; 
> map->stride = 0; } @@ -2192,11 +2194,11 @@
> intel_miptree_unmap_blit(struct brw_context *brw, { struct
> gl_context *ctx = >ctx;
> 
> -   intel_miptree_unmap_raw(brw, map->mt); +
> intel_miptree_unmap_raw(brw, map->linear_mt);
> 
> if (map->mode & GL_MAP_WRITE_BIT) { bool ok =
> intel_miptree_blit(brw, -
> map->mt, 0, 0, +   map->linear_mt,
> 0, 0, 0, 0, false, mt, level, slice, map->x, map->y, false, @@
> -2204,7 +2206,7 @@ intel_miptree_unmap_blit(struct brw_context
> *brw, WARN_ONCE(!ok, "Failed to blit from linear temporary
> mapping"); }
> 
> -   intel_miptree_release(>mt); +
> intel_miptree_release(>linear_mt); }
> 
> /** @@ -2728,7 +2730,7 @@ intel_miptree_unmap(struct brw_context
> *brw, intel_miptree_unmap_etc(brw, mt, map, level, slice); } else
> if (mt->stencil_mt && !(map->mode & BRW_MAP_DIRECT_BIT)) { 
> intel_miptree_unmap_depthstencil(brw, mt, map, level, slice); -   }
> else if (map->mt) { +   } else if (map->linear_mt) { 
> intel_miptree_unmap_blit(brw, mt, map, level, slice); #if
> defined(USE_SSE41) } else if (map->buffer && cpu_has_sse4_1) { diff
> --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
> b/src/mesa/drivers/dri/i965/intel_mipmap_tree.h index
> 830ff07..9f5397f 100644 ---
> a/src/mesa/drivers/dri/i965/intel_mipmap_tree.h +++
> b/src/mesa/drivers/dri/i965/intel_mipmap_tree.h @@ -84,7 +84,7 @@
> struct intel_miptree_map { /** Possibly malloced temporary buffer
> for the mapping. */ void *buffer; /** Possible pointer to a
> temporary linear miptree for the mapping. */ -   struct
> intel_mipmap_tree *mt; +   struct intel_mipmap_tree *linear_mt; /**
> Pointer to the start of (map_x, map_y) returned by the mapping. */ 
> void *ptr; /** Stride of the mapping. */
> 

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

Re: [Mesa-dev] Pending issues of lollipop-x86

2015-09-26 Thread Mauro Rossi

Hi,

Marek's patches solved Camera and Youtube crashes on nouveau and radeonsi.
I'm available to test on i965, if needed

I think at this point the remaining major problem for lollipop-x86 is the
font artifacts/invisible chars on i965GM (X3100)
still present in mesa 11.0.0, I need to check with 11.0.1

Mauro




2015-09-25 23:03 GMT+02:00 Marek Olšák :

> Guys, can you please try these patches? They should fix it for gallium
> drivers (not i965).
>
> Marek
>
> On Fri, Sep 25, 2015 at 10:35 PM, Marek Olšák  wrote:
> > On Fri, Sep 25, 2015 at 5:43 PM, Chih-Wei Huang 
> wrote:
> >> CC to mesa-dev for help.
> >>
> >> 2015-09-25 22:12 GMT+08:00 Chih-Wei Huang :
> >>> 2015-09-25 16:21 GMT+08:00 Chih-Wei Huang :
>  Actually I'm testing your mesa 11.0 branch
>  to see if it is acceptable.
>  The major issue I found is the
>  Camera and Youtube crashing in mesa.
> >>>
> >>> OK, I can almost confirm this is a known issue
> >>> I reported to mesa devs before.
> >>> It is caused by this commit:
> >>>
> >>> commit c636284ee8ee95bb3f3ad31aaf26a9512ec5006c
> >>> Author: Chad Versace 
> >>> Date:   Tue May 5 19:05:32 2015 -0700
> >>>
> >>> i965/sync: Implement DRI2_Fence extension
> >>>
> >>> By reverting it the crashing is gone.
> >>>
> >>> However, I still hope we can find
> >>> a correct fix.
> >>
> >> After some debugging, it crashed in
> >> dri2_client_wait_sync() of
> >> ...src/egl/drivers/dri2/egl_dri2.c
> >> The ctx returned by _eglGetCurrentContext()
> >> is NULL.
> >>
> >> static EGLint
> >> dri2_client_wait_sync(_EGLDriver *drv, _EGLDisplay *dpy, _EGLSync *sync,
> >>   EGLint flags, EGLTime timeout)
> >> {
> >>_EGLContext *ctx = _eglGetCurrentContext();
> >>
> >> ==> ctx is NULL
> >>
> >>if (dri2_dpy->fence->client_wait_sync(dri2_ctx->dri_context,  <==
> OOPS!
> >>  dri2_sync->fence, wait_flags,
> >>  timeout))
> >>
> >>
> >> Why does _eglGetCurrentContext() return NULL?
> >
> > Yes, we should fix this. A context isn't required here.
> >
> > Marek
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] i965: Don't tell the hardware about our UAV access.

2015-09-26 Thread Francisco Jerez

Emil Velikov  writes:

> Hi all,
>
> On 10 September 2015 at 00:30, Mark Janes  wrote:
>> Mark Janes  writes:
>>
>>> Francisco Jerez  writes:
>>>
 Mark Janes  writes:

> When I tested this, I saw an intermittent BSW gpu hang.  I haven't been
> able to confirm that it is due to the host-mem-barrier test.
>
 It would probably be useful to know if the hang is due to any of the
 image load/store tests or if it's something unrelated.
>>>
>>> Yes, you are right.  I will take some time tomorrow to catch the
>>> specific test.  Given the low rate of gpu hangs on BSW lately, I expect
>>> it will be due to image load/store tests.  However I need to confirm it.
>>
>> I spent time attempting to reproduce hangs with this patch on BSW today.
>> I forced 3 hangs, but none of them could be attributed to image
>> load/store tests.
>>
> With the above said, should we consider this as inconclusive fix ? If
> so, what is the plan going forward - is this going to the bin or we'll
> beat it into shape and merge it ?
>
Heh...  The above means that there is an outstanding hang bug on BSW,
but it's unrelated to the problem addressed by this patch (or
ARB_shader_image_load_store at any rate).  This patch fixes a GPU hang
on both BDW and BSW and I recommend it's included in the next stable
release.

> Thanks
> Emil


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

[Mesa-dev] [PATCH 2/2] egl: Fix missing Haiku include path

2015-09-26 Thread Alexander von Gluck IV

---
 src/egl/SConscript |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/src/egl/SConscript b/src/egl/SConscript
index f8102db..8f8b11a 100644
--- a/src/egl/SConscript
+++ b/src/egl/SConscript
@@ -8,6 +8,7 @@ env = env.Clone()
 
 env.Append(CPPPATH = [
 '#/include',
+'#/include/HaikuGL',
 '#/src/egl/main',
 '#/src',
 ])
-- 
1.7.1

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

[Mesa-dev] [Bug 91797] [r600g] Company of Heroes 2 crash when zooming on the map

[Mesa-dev] [Bug 91643] mesa-demos-8.2.0 (latest released version) fails to build against mesa-10.6.4-2.mga6.tainted.src.rpm

[Mesa-dev] [Bug 91020] Mesa's demo / tools won't compile since EGL changes

Re: [Mesa-dev] [PATCH 2/6] mesa: rename gl_shader_program's NumUniformBlocks to NumUniformShaderStorageBlocks

[Mesa-dev] [Bug 91643] mesa-demos-8.2.0 (latest released version) fails to build against mesa-10.6.4-2.mga6.tainted.src.rpm

[Mesa-dev] Mesa 11.0.1

[Mesa-dev] [PATCH] mesa: don't leak interface_name

Re: [Mesa-dev] [PATCH 4/6] main/tests: Enable glShaderStorageBlockBinding() check in dispatch_sanity test

[Mesa-dev] Returning 0 from std430_base_alignment

Re: [Mesa-dev] [PATCH 6/6] i965: Simplify handling of VUE map changes.

[Mesa-dev] [PATCH] gallium/util: avoid unreferencing random memory on buffer alloc failure

[Mesa-dev] [PATCH 1/2] state_trackers/hgl: Fix missing include path

Re: [Mesa-dev] memoryBarrier + SSBO

Re: [Mesa-dev] memoryBarrier + SSBO

Re: [Mesa-dev] [PATCH] gallium/util: avoid unreferencing random memory on buffer alloc failure

Re: [Mesa-dev] mesa: Reduce libGL.so binary size by about 15%

Re: [Mesa-dev] memoryBarrier + SSBO

Re: [Mesa-dev] memoryBarrier + SSBO

Re: [Mesa-dev] [PATCH] gallium/util: avoid unreferencing random memory on buffer alloc failure

Re: [Mesa-dev] [PATCH] gallium/util: avoid unreferencing random memory on buffer alloc failure

[Mesa-dev] [Bug 92122] [bisected] Regression with Assault Android Cactus

Re: [Mesa-dev] [PATCH 06/11] loader: use HAVE_LIBDRM instead of ! __NOT_HAVE_DRM_H

Re: [Mesa-dev] [PATCH] gallium/util: avoid unreferencing random memory on buffer alloc failure

Re: [Mesa-dev] [PATCH 14/24] i965: fix atomic buffer index for bindings other than 0

Re: [Mesa-dev] [PATCH 14/24] i965: fix atomic buffer index for bindings other than 0

Re: [Mesa-dev] [Mesa-stable] [PATCH] i965/fs: Fix hang on IVB and VLV with image format mismatch.

Re: [Mesa-dev] [PATCH] mesa: don't leak interface_name

[Mesa-dev] [Bug 92125] make check DispatchSanity_test.GL31_CORE regression

Re: [Mesa-dev] [PATCH 14/24] i965: fix atomic buffer index for bindings other than 0

Re: [Mesa-dev] [PATCH] i965/miptree: Rename intel_miptree_map::mt -> ::linear_mt (v2)

Re: [Mesa-dev] Pending issues of lollipop-x86

Re: [Mesa-dev] [PATCH] i965: Don't tell the hardware about our UAV access.

[Mesa-dev] [PATCH 2/2] egl: Fix missing Haiku include path

33 matches

Site Navigation

Mail list logo

Footer information