[Mesa-dev] [Bug 98595] glsl: ralloc assertion "info->canary == CANARY" failed

[bugzilla-daemon]

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

--- Comment #6 from Timothy Arceri  ---
(In reply to Jonathan Gray from comment #5)
> Indeed the abort is not triggered with gcc 4.9 but is with gcc 4.2.1.
> 
> For gcc < 4.4.3 and for clang HAS_TRIVIAL_DESTRUCTOR is set to
> __has_trivial_destructor(T) otherwise it is (false).
> 
> Everything worked last weeked, though that was before
> cc6aa1d161280f10ded7834d1ec2413bc97589fe.

Did you bisect to that commit? Besides me jumping the gun (sorry about that)
and marking this a duplicate of a bug caused by that change it doesn't look
like it should have anything to do with this bug.

More likely to do will the linear allocator changes that landed 6 days ago. e.g 
23e373eb4f9ca374313306701890642c30e8877e

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

[Mesa-dev] [Bug 98606] Compile error in gallium target VA--LLVM undefined referencences

[bugzilla-daemon]

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

Bug ID: 98606
   Summary: Compile error in gallium target VA--LLVM undefined
referencences
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Other
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: bug0xa...@hushmail.com
QA Contact: mesa-dev@lists.freedesktop.org

Created attachment 127795
  --> https://bugs.freedesktop.org/attachment.cgi?id=127795=edit
Part of the comiple log

Compiling using GCC 5.3.0 multilib.
LLVM git installed.

Over time I have tried to comiple mesa git with different versions of libva,
libvdpau and llvm but still get the same compile error as shown in the attached
log.

I am a still able to install the libGL.so by forcing make (make -k) but I no
longer have VA-API decode ability like in the past.

-- 
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 98595] glsl: ralloc assertion "info->canary == CANARY" failed

[bugzilla-daemon]

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

--- Comment #5 from Jonathan Gray  ---
Indeed the abort is not triggered with gcc 4.9 but is with gcc 4.2.1.

For gcc < 4.4.3 and for clang HAS_TRIVIAL_DESTRUCTOR is set to
__has_trivial_destructor(T) otherwise it is (false).

Everything worked last weeked, though that was before
cc6aa1d161280f10ded7834d1ec2413bc97589fe.

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

[Mesa-dev] [Bug 98002] Mud rendering bug in Portal 2

[bugzilla-daemon]

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

almos  changed:

   What|Removed |Added

 CC||aaalmo...@gmail.com

--- Comment #11 from almos  ---
(In reply to Clément Guérin from comment #10)
> almos, disabling your ad blocker should do the trick. Sorry about that.

I tried that, but apart from the very NSFW advertisements nothing happens.

-- 
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 98002] Mud rendering bug in Portal 2

[bugzilla-daemon]

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

--- Comment #10 from Clément Guérin  ---
almos, disabling your ad blocker should do the trick. Sorry about that.

-- 
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] i965: Order write of query availablity with earlier writes

[Alejandro Piñeiro]

On 05/11/16 19:57, Chris Wilson wrote:
> Currently we signal the availabilty of the query result using an
typo: availability (this also affects commit message)
> unordered pipe-control write. As it is unordered, it may be executed
> before the write of the query result itself - and so an observer may
> read the query result too early. 
From that "may", I assume that the problem this patch tries to fix
doesn't happen 100% of the times, and that depends on a race condition.
Is that true?
> Fix this by requesting that the write
> of the availablity flag is ordered after earlier pipe control writes.
>
> Testcase: piglit/arb_query_buffer_object-qbo/*async*
What that means? That this patch fixes those tests? or just that the
functionality is tested by those piglit tests?
> Signed-off-by: Chris Wilson 
> ---
>  src/mesa/drivers/dri/i965/gen6_queryobj.c | 12 ++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/gen6_queryobj.c 
> b/src/mesa/drivers/dri/i965/gen6_queryobj.c
> index bbd3c44..f6b90f7 100644
> --- a/src/mesa/drivers/dri/i965/gen6_queryobj.c
> +++ b/src/mesa/drivers/dri/i965/gen6_queryobj.c
> @@ -60,8 +60,16 @@ set_query_availability(struct brw_context *brw, struct 
> brw_query_object *query,
>  */
> if (brw->ctx.Extensions.ARB_query_buffer_object &&

Just before this if there is a really big comment explaining what the
code is doing, and why it is as it is. Probably it would be good to
update, specially when it mentions CS stalls, that you use below.

> brw_is_query_pipelined(query)) {
> -  brw_emit_pipe_control_write(brw,
> -  PIPE_CONTROL_WRITE_IMMEDIATE,
> +  unsigned flags = PIPE_CONTROL_WRITE_IMMEDIATE;
> +
> +  if (available)
> + /* Order available *after* the query results */
> + flags |= PIPE_CONTROL_FLUSH_ENABLE;

As it is two lines of code, it needs brackets (as reference, the
previous code technically didn't need the brackets for the
brw_emit_pipe_control_write call, but it had it, as it was written using
more than one line of code).

> +  else
> + /* Make it unavailable *before* any pipelined reads */
> + flags |= PIPE_CONTROL_CS_STALL;
Ditto.


> +
> +  brw_emit_pipe_control_write(brw, flags,
>query->bo, 2 * sizeof(uint64_t),
>available, 0);
> }


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

Re: [Mesa-dev] [PATCH 2/2] Make shader refcounting atomic.

[Timothy Arceri]

On Sat, 2016-11-05 at 15:37 +0100, Steinar H. Gunderson wrote:
> These were racy when using the same shaders (seemingly even from
> different
> program objects) on multiple theads sharing the same objects, leading
> to
> issues such as (excerpts from an apitrace dump from a real
> application):

I'll let others comment on this one but you may also be interested in
this discussion:

https://lists.freedesktop.org/archives/mesa-dev/2016-October/132629.htm
l

> 
>   1097 @0 glCreateProgram() = 9
>   1099 @0 glAttachShader(program = 9, shader = 7)
>   1101 @0 glAttachShader(program = 9, shader = 8)
>   [...]
>   18122 @2 glCreateProgram() = 137
>   18128 @2 glAttachShader(program = 137, shader = 7)
>   18130 @2 glAttachShader(program = 137, shader = 8)
>   [...]
>   437559 @0 glUseProgram(program = 9)
>   437582 @2 glUseProgram(program = 137)
>   437613 @2 glUseProgram(program = 9)
>   437614 @2 glGetError() = GL_INVALID_VALUE
> 
> with nothing deleting the shaders or programs in-between; just racy
> refcounting, as confirmed by Helgrind:
> 
>   ==13727== Possible data race during read of size 4 at 0x2B3B2648 by
> thread #1
>   ==13727== Locks held: none
>   ==13727==at 0x1EEBF613: _mesa_reference_shader_program_
> (shaderobj.c:247)
>   ==13727==by 0x1EEBDFB2: _mesa_use_program (shaderapi.c:1259)
>   ==13727==by 0x60FA618:
> movit::EffectChain::execute_phase(movit::Phase*, bool, std::set std::less, std::allocator >*, std::map unsigned int, std::less,
> std::allocator > >*,
> std::set,
> std::allocator >*) (effect_chain.cpp:1885)
>   [...]
>   ==13727== This conflicts with a previous write of size 4 by thread
> #20
>   ==13727== Locks held: none
>   ==13727==at 0x1EEBF600: _mesa_reference_shader_program_
> (shaderobj.c:236)
>   ==13727==by 0x1EEBDFB2: _mesa_use_program (shaderapi.c:1259)
>   ==13727==by 0x60FA618:
> movit::EffectChain::execute_phase(movit::Phase*, bool, std::set std::less, std::allocator >*, std::map unsigned int, std::less,
> std::allocator > >*,
> std::set,
> std::allocator >*) (effect_chain.cpp:1885)
> 
> Cc: 11.2 12.0 13.0 
> Signed-off-by: Steinar H. Gunderson 
> ---
>  src/mesa/main/shaderobj.c | 23 +--
>  1 file changed, 9 insertions(+), 14 deletions(-)
> 
> diff --git a/src/mesa/main/shaderobj.c b/src/mesa/main/shaderobj.c
> index 8fd574e..08e4379 100644
> --- a/src/mesa/main/shaderobj.c
> +++ b/src/mesa/main/shaderobj.c
> @@ -41,6 +41,7 @@
>  #include "program/prog_parameter.h"
>  #include "util/ralloc.h"
>  #include "util/string_to_uint_map.h"
> +#include "util/u_atomic.h"
>  
>  /***
> ***/
>  /*** Shader object
> functions***/
> @@ -64,14 +65,11 @@ _mesa_reference_shader(struct gl_context *ctx,
> struct gl_shader **ptr,
> }
> if (*ptr) {
>    /* Unreference the old shader */
> -  GLboolean deleteFlag = GL_FALSE;
>    struct gl_shader *old = *ptr;
> +  int old_refcount = p_atomic_dec_return(>RefCount);
>  
> -  assert(old->RefCount > 0);
> -  old->RefCount--;
> -  deleteFlag = (old->RefCount == 0);
> -
> -  if (deleteFlag) {
> +  assert(old_refcount >= 0);
> +  if (old_refcount == 0) {
>    if (old->Name != 0)
>   _mesa_HashRemove(ctx->Shared->ShaderObjects, old->Name);
>   _mesa_delete_shader(ctx, old);
> @@ -83,7 +81,7 @@ _mesa_reference_shader(struct gl_context *ctx,
> struct gl_shader **ptr,
>  
> if (sh) {
>    /* reference new */
> -  sh->RefCount++;
> +  p_atomic_inc(>RefCount);
>    *ptr = sh;
> }
>  }
> @@ -226,14 +224,11 @@ _mesa_reference_shader_program_(struct
> gl_context *ctx,
> }
> if (*ptr) {
>    /* Unreference the old shader program */
> -  GLboolean deleteFlag = GL_FALSE;
>    struct gl_shader_program *old = *ptr;
> +  int old_refcount = p_atomic_dec_return(>RefCount);
>  
> -  assert(old->RefCount > 0);
> -  old->RefCount--;
> -  deleteFlag = (old->RefCount == 0);
> -
> -  if (deleteFlag) {
> +  assert(old_refcount >= 0);
> +  if (old_refcount == 0) {
>    if (old->Name != 0)
>   _mesa_HashRemove(ctx->Shared->ShaderObjects, old->Name);
>   _mesa_delete_shader_program(ctx, old);
> @@ -244,7 +239,7 @@ _mesa_reference_shader_program_(struct gl_context
> *ctx,
> assert(!*ptr);
>  
> if (shProg) {
> -  shProg->RefCount++;
> +  p_atomic_inc(>RefCount);
>    *ptr = shProg;
> }
>  }
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org

Re: [Mesa-dev] [PATCH 1/2] Fix races during _mesa_HashWalk().

[Timothy Arceri]

On Sat, 2016-11-05 at 15:28 +0100, Steinar H. Gunderson wrote:
> There is currently no protection against walking a hash (using
> _mesa_HashWalk()) and modifying it at the same time, for instance by
> inserting
> or deleting elements. This leads to segfaults in multithreaded code
> if e.g.
> someone calls glTexImage2D (which may have to walk the list of FBOs)
> while
> another thread is calling glDeleteFramebuffers on another thread with
> the two
> contexts sharing lists.
> 
> The reason for this is that _mesa_HashWalk() doesn't actually take
> the mutex
> that normally protects the hash; it takes an entirely different
> mutex.
> Thus, walks are only protected against other walks, and there is also
> no
> outer lock taking this. There is an old comment saying that this is
> to fix
> problems with deadlock if the callback needs to take a mutex, but now
> that we
> have recursive mutexes, this is a non-issue.

Can you please change this line to say something like. With this change
we switch to using a recursive mutex, which avoids the deadlock.

I was a little confused. At first I thought it was already using a
recursive mutex.

Otherwise the change looks correct to me.

Reviewed-by: Timothy Arceri 


One thing that concerns me is that we can now call _mesa_HashRemove
from the callback in _mesa_HashDeleteAll.

I think we may need a patch before this one that changes
_mesa_HashDeleteAll to wrap _mesa_hash_table_remove(table->ht, entry);
with a deleted entry check otherwise the entry counts will get all
messed up.

   /* Check that the cb didn't already delete the entry. If not
    * remove it.
    */
   if (entry->key != table->ht->deleted_key) {
      _mesa_hash_table_remove(table->ht, entry);
   }
 
> 
> A demonstration Helgrind hit from a real application:
> 
> ==13412== Possible data race during write of size 8 at 0x3498C6A8 by
> thread #1
> ==13412== Locks held: 2, at addresses 0x1AF09530 0x2B3DF400
> ==13412==at 0x1F040C99: _mesa_hash_table_remove
> (hash_table.c:395)
> ==13412==by 0x1EE98174: _mesa_HashRemove_unlocked (hash.c:350)
> ==13412==by 0x1EE98174: _mesa_HashRemove (hash.c:365)
> ==13412==by 0x1EE2372D: _mesa_DeleteFramebuffers
> (fbobject.c:2669)
> ==13412==by 0x6105AA4:
> movit::ResourcePool::cleanup_unlinked_fbos(void*)
> (resource_pool.cpp:473)
> ==13412==by 0x610615B: movit::ResourcePool::release_fbo(unsigned
> int) (resource_pool.cpp:442)
> [...]
> ==13412== This conflicts with a previous read of size 8 by thread #20
> ==13412== Locks held: 2, at addresses 0x1AF09558 0x1AF73318
> ==13412==at 0x1F040CD9: _mesa_hash_table_next_entry
> (hash_table.c:415)
> ==13412==by 0x1EE982A8: _mesa_HashWalk (hash.c:426)
> ==13412==by 0x1EED6DFD: _mesa_update_fbo_texture.part.33
> (teximage.c:2683)
> ==13412==by 0x1EED9410: _mesa_update_fbo_texture
> (teximage.c:3043)
> ==13412==by 0x1EED9410: teximage (teximage.c:3073)
> ==13412==by 0x1EEDA28F: _mesa_TexImage2D (teximage.c:3105)
> ==13412==by 0x166A68: operator() (mixer.cpp:454)
> 
> There are many more interactions than just these two possible.
> 
> Cc: 11.2 12.0 13.0 
> Signed-off-by: Steinar H. Gunderson 
> ---
>  src/mesa/main/hash.c | 18 +++---
>  1 file changed, 7 insertions(+), 11 deletions(-)
> 
> diff --git a/src/mesa/main/hash.c b/src/mesa/main/hash.c
> index 7d8a5fd..670438a 100644
> --- a/src/mesa/main/hash.c
> +++ b/src/mesa/main/hash.c
> @@ -59,7 +59,6 @@ struct _mesa_HashTable {
> struct hash_table *ht;
> GLuint MaxKey;/**< highest key inserted
> so far */
> mtx_t Mutex;/**< mutual exclusion lock */
> -   mtx_t WalkMutex;/**< for _mesa_HashWalk() */
> GLboolean InDeleteAll;/**< Debug check */
> /** Value that would be in the table for DELETED_KEY_VALUE. */
> void *deleted_key_data;
> @@ -129,8 +128,11 @@ _mesa_NewHashTable(void)
>    }
>  
>    _mesa_hash_table_set_deleted_key(table->ht,
> uint_key(DELETED_KEY_VALUE));
> -  mtx_init(>Mutex, mtx_plain);
> -  mtx_init(>WalkMutex, mtx_plain);
> +  /*
> +   * Needs to be recursive, since the callback in
> _mesa_HashWalk()
> +   * is allowed to call _mesa_HashRemove().
> +   */
> +  mtx_init(>Mutex, mtx_recursive);
> }
> else {
>    _mesa_error_no_memory(__func__);
> @@ -161,7 +163,6 @@ _mesa_DeleteHashTable(struct _mesa_HashTable
> *table)
> _mesa_hash_table_destroy(table->ht, NULL);
>  
> mtx_destroy(>Mutex);
> -   mtx_destroy(>WalkMutex);
> free(table);
>  }
>  
> @@ -401,11 +402,6 @@ _mesa_HashDeleteAll(struct _mesa_HashTable
> *table,
>  
>  /**
>   * Walk over all entries in a hash table, calling callback function
> for each.
> - * Note: we use a separate mutex in this function to avoid a
> recursive
> - * locking deadlock (in case the callback calls _mesa_HashRemove())
> and to
> - * 

Re: [Mesa-dev] [PATCH] android: amd/common: add support for libmesa_amd_common

[Marek Olšák]

On Nov 5, 2016 9:03 PM, "Mauro Rossi"  wrote:
>
> 2016-11-05 18:58 GMT+01:00 Marek Olšák :
> > Hi,
> >
> > I pushed the patch from the bug report. Hopefully it's the same as this
one.
> >
> > Marek
>
> Hi Marek, thanks,
> it is identical.
>
> As a side note, for any people trying to build mesa-dev for android,
> a problem affecting our nougat-x86 x84_64 build  is that we
> (android-x86 volounteers) haven't managed to properly fix llvm to
> export prototypes of LLVMInitializeAMDGPU* functions, even if AMDGPU
> backend was bullt.
>
> The problem is the same mentioned here:
> https://lists.freedesktop.org/archives/mesa-dev/2016-March/109602.html
> where issue seems related to missing porting of
> ./include/llvm/Config/Target.def processing in Android makefiles in
> llvm.
>
> At the moment in my personal branch I'm using the
> -Wno-error=implicit-function-declaration LOCAL_CFLAG,
> but it can't be upstreamed to mesa-dev
>
> I will need to knock at the door of llvm/aosp experts, in the
> appropriate forums or just continue my trial and error progression.

If you want to add some hacks to Mesa for Android, that's fine with me. I
don't think we have many Android users, so some build system hacks
shouldn't bother anyone, is that right Emil?

Marek

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

Re: [Mesa-dev] [PATCH] android: amd/common: add support for libmesa_amd_common

[Mauro Rossi]

2016-11-05 18:58 GMT+01:00 Marek Olšák :
> Hi,
>
> I pushed the patch from the bug report. Hopefully it's the same as this one.
>
> Marek

Hi Marek, thanks,
it is identical.

As a side note, for any people trying to build mesa-dev for android,
a problem affecting our nougat-x86 x84_64 build  is that we
(android-x86 volounteers) haven't managed to properly fix llvm to
export prototypes of LLVMInitializeAMDGPU* functions, even if AMDGPU
backend was bullt.

The problem is the same mentioned here:
https://lists.freedesktop.org/archives/mesa-dev/2016-March/109602.html
where issue seems related to missing porting of
./include/llvm/Config/Target.def processing in Android makefiles in
llvm.

At the moment in my personal branch I'm using the
-Wno-error=implicit-function-declaration LOCAL_CFLAG,
but it can't be upstreamed to mesa-dev

I will need to knock at the door of llvm/aosp experts, in the
appropriate forums or just continue my trial and error progression.

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

[Mesa-dev] [PATCH] i965: Order write of query availablity with earlier writes

[Chris Wilson]

Currently we signal the availabilty of the query result using an
unordered pipe-control write. As it is unordered, it may be executed
before the write of the query result itself - and so an observer may
read the query result too early. Fix this by requesting that the write
of the availablity flag is ordered after earlier pipe control writes.

Testcase: piglit/arb_query_buffer_object-qbo/*async*
Signed-off-by: Chris Wilson 
---
 src/mesa/drivers/dri/i965/gen6_queryobj.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/gen6_queryobj.c 
b/src/mesa/drivers/dri/i965/gen6_queryobj.c
index bbd3c44..f6b90f7 100644
--- a/src/mesa/drivers/dri/i965/gen6_queryobj.c
+++ b/src/mesa/drivers/dri/i965/gen6_queryobj.c
@@ -60,8 +60,16 @@ set_query_availability(struct brw_context *brw, struct 
brw_query_object *query,
 */
if (brw->ctx.Extensions.ARB_query_buffer_object &&
brw_is_query_pipelined(query)) {
-  brw_emit_pipe_control_write(brw,
-  PIPE_CONTROL_WRITE_IMMEDIATE,
+  unsigned flags = PIPE_CONTROL_WRITE_IMMEDIATE;
+
+  if (available)
+ /* Order available *after* the query results */
+ flags |= PIPE_CONTROL_FLUSH_ENABLE;
+  else
+ /* Make it unavailable *before* any pipelined reads */
+ flags |= PIPE_CONTROL_CS_STALL;
+
+  brw_emit_pipe_control_write(brw, flags,
   query->bo, 2 * sizeof(uint64_t),
   available, 0);
}
-- 
2.10.2

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

Re: [Mesa-dev] [PATCH 1/2] glsl: fix slot_end calculations and simplify reserved_slots check

[Ilia Mirkin]

On Sat, Nov 5, 2016 at 1:03 PM, Ilia Mirkin  wrote:
> The previous code was confused about whether slot_end was inclusive or
> exclusive. Make it so that it is inclusive consistently, and use it for
> setting the new location. This should also better deal with arrays of
> incomplete size, since the slot check will assume it gets packed.
>
> Signed-off-by: Ilia Mirkin 
> ---
>
> No regressions in Intel's jenkins runs, which I believe hit both piglit and 
> CTS.
> This is somewhat subtle code, but I think I covered what it was trying to do.
>
>  src/compiler/glsl/link_varyings.cpp | 50 
> -
>  1 file changed, 22 insertions(+), 28 deletions(-)
>
> diff --git a/src/compiler/glsl/link_varyings.cpp 
> b/src/compiler/glsl/link_varyings.cpp
> index e622b3e..49843cc 100644
> --- a/src/compiler/glsl/link_varyings.cpp
> +++ b/src/compiler/glsl/link_varyings.cpp
> @@ -1546,14 +1546,16 @@ varying_matches::assign_locations(struct 
> gl_shader_program *prog,
>
>previous_var_xfb_only = var->data.is_xfb_only;
>
> -  unsigned num_elements =  type->count_attribute_slots(is_vertex_input);
> -  unsigned slot_end;
> -  if (this->disable_varying_packing &&
> -  !is_varying_packing_safe(type, var))
> - slot_end = 4;
> -  else
> - slot_end = type->without_array()->vector_elements;
> -  slot_end += *location - 1;
> +  /* The number of components taken up by this variable. For vertex 
> shader
> +   * inputs, we use the number of slots * 4, as they have different
> +   * counting rules.
> +   */
> +  unsigned num_components = is_vertex_input ?
> + type->count_attribute_slots(is_vertex_input) * 4 :
> + this->matches[i].num_components;
> +
> +  /* The last slot for this variable, inclusive. */
> +  unsigned slot_end = *location + num_components - 1;
>
>/* FIXME: We could be smarter in the below code and loop back over
> * trying to fill any locations that we skipped because we couldn't 
> pack
> @@ -1561,29 +1563,21 @@ varying_matches::assign_locations(struct 
> gl_shader_program *prog,
> * hit the linking error if we run out of room and suggest they use
> * explicit locations.
> */
> -  for (unsigned j = 0; j < num_elements; j++) {
> - while ((slot_end < MAX_VARYING * 4u) &&
> -((reserved_slots & (UINT64_C(1) << *location / 4u) ||
> - (reserved_slots & (UINT64_C(1) << slot_end / 4u) {
> -
> -*location = ALIGN(*location + 1, 4);
> -slot_end = *location;
> -
> -/* reset the counter and try again */
> -j = 0;
> +  while (slot_end < MAX_VARYING * 4u) {
> + const unsigned slots = (slot_end / 4u) - (*location / 4u) + 1;
> + const uint64_t slot_mask = ((1ull << slots) - 1) << (*location / 
> 4u);
> +
> + assert(slots > 0);
> + if (reserved_slots & slot_mask) {
> +*location = ALIGN(slot_end + 1, 4);

I was a bit overzealous about changing this -- should be

*location = ALIGN(*location + 1, 4);

Since the reserved slot could be the first one. I've made this change
locally. Intel's CI is still happy.

Various bit arithmetic could be done to improve this, but ... meh.
Hardly seems worth it.

> +slot_end = *location + num_components - 1;
> +continue;
>   }
>
> - /* Increase the slot to make sure there is enough room for next
> -  * array element.
> -  */
> - if (this->disable_varying_packing &&
> - !is_varying_packing_safe(type, var))
> -slot_end += 4;
> - else
> -slot_end += type->without_array()->vector_elements;
> + break;
>}
>
> -  if (!var->data.patch && *location >= MAX_VARYING * 4u) {
> +  if (!var->data.patch && slot_end >= MAX_VARYING * 4u) {
>   linker_error(prog, "insufficient contiguous locations available for 
> "
>"%s it is possible an array or struct could not be "
>"packed between varyings with explicit locations. Try "
> @@ -1593,7 +1587,7 @@ varying_matches::assign_locations(struct 
> gl_shader_program *prog,
>
>this->matches[i].generic_location = *location;
>
> -  *location += this->matches[i].num_components;
> +  *location = slot_end + 1;
> }
>
> return (generic_location + 3) / 4;
> --
> 2.7.3
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] nvc0: get rid of NVE4_COMPUTE_MP_PM_{A, B}_SIGSEL_XXX

[Samuel Pitoiset]

On 11/05/2016 06:06 PM, Ilia Mirkin wrote:

On Sat, Nov 5, 2016 at 12:56 PM, Samuel Pitoiset
 wrote:

Instead, hardcode group sigsel because there are a bunch of unknown
groups, especially on SM50/SM52.

Signed-off-by: Samuel Pitoiset 
---
 .../drivers/nouveau/nvc0/nvc0_query_hw_sm.c| 112 ++---
 1 file changed, 56 insertions(+), 56 deletions(-)

diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_query_hw_sm.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_query_hw_sm.c
index d472120..2136368 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_query_hw_sm.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_query_hw_sm.c
@@ -504,8 +504,8 @@ struct nvc0_hw_sm_query_cfg
uint8_t norm[2]; /* normalization num,denom */
 };

-#define _CA(f, m, g, s) { f, NVE4_COMPUTE_MP_PM_FUNC_MODE_##m, 0, 
NVE4_COMPUTE_MP_PM_A_SIGSEL_##g, 0, s }
-#define _CB(f, m, g, s) { f, NVE4_COMPUTE_MP_PM_FUNC_MODE_##m, 1, 
NVE4_COMPUTE_MP_PM_B_SIGSEL_##g, 0, s }
+#define _CA(f, m, g, s) { f, NVE4_COMPUTE_MP_PM_FUNC_MODE_##m, 0, g, 0, s }
+#define _CB(f, m, g, s) { f, NVE4_COMPUTE_MP_PM_FUNC_MODE_##m, 1, g, 0, s }


If you wanted, you could introduce a second set of macros that took
the value directly, and left some that had the symbolic names. Up to
you... this is basically your code - I don't know what any of this
does or how it works.


Yes, but I don't care about the symbolic names. :-)
And they are only "REd" for GK104 and they change at every compute 
capability version, which makes hard to determine.





 #define _Q(n, c) [NVE4_HW_SM_QUERY_##n] = c

 /*  Compute capability 3.0 (GK104:GK110)  */
@@ -513,7 +513,7 @@ static const struct nvc0_hw_sm_query_cfg
 sm30_active_cycles =
 {
.type = NVC0_HW_SM_QUERY_ACTIVE_CYCLES,
-   .ctr[0]   = _CB(0x0001, B6, WARP, 0x),
+   .ctr[0]   = _CB(0x0001, B6, 0x02, 0x),
.num_counters = 1,
.norm = { 1, 1 },
 };
@@ -522,7 +522,7 @@ static const struct nvc0_hw_sm_query_cfg
 sm30_active_warps =
 {
.type = NVC0_HW_SM_QUERY_ACTIVE_WARPS,
-   .ctr[0]   = _CB(0x003f, B6, WARP, 0x31483104),
+   .ctr[0]   = _CB(0x003f, B6, 0x02, 0x31483104),
.num_counters = 1,
.norm = { 2, 1 },
 };
@@ -531,7 +531,7 @@ static const struct nvc0_hw_sm_query_cfg
 sm30_atom_cas_count =
 {
.type = NVC0_HW_SM_QUERY_ATOM_CAS_COUNT,
-   .ctr[0]   = _CA(0x0001, B6, BRANCH, 0x4),
+   .ctr[0]   = _CA(0x0001, B6, 0x1c, 0x4),
.num_counters = 1,
.norm = { 1, 1 },
 };
@@ -540,7 +540,7 @@ static const struct nvc0_hw_sm_query_cfg
 sm30_atom_count =
 {
.type = NVC0_HW_SM_QUERY_ATOM_COUNT,
-   .ctr[0]   = _CA(0x0001, B6, BRANCH, 0x),
+   .ctr[0]   = _CA(0x0001, B6, 0x1c, 0x),
.num_counters = 1,
.norm = { 1, 1 },
 };
@@ -549,7 +549,7 @@ static const struct nvc0_hw_sm_query_cfg
 sm30_branch =
 {
.type = NVC0_HW_SM_QUERY_BRANCH,
-   .ctr[0]   = _CA(0x0001, B6, BRANCH, 0x000c),
+   .ctr[0]   = _CA(0x0001, B6, 0x1c, 0x000c),
.num_counters = 1,
.norm = { 1, 1 },
 };
@@ -558,7 +558,7 @@ static const struct nvc0_hw_sm_query_cfg
 sm30_divergent_branch =
 {
.type = NVC0_HW_SM_QUERY_DIVERGENT_BRANCH,
-   .ctr[0]   = _CA(0x0001, B6, BRANCH, 0x0010),
+   .ctr[0]   = _CA(0x0001, B6, 0x1c, 0x0010),
.num_counters = 1,
.norm = { 1, 1 },
 };
@@ -567,7 +567,7 @@ static const struct nvc0_hw_sm_query_cfg
 sm30_gld_request =
 {
.type = NVC0_HW_SM_QUERY_GLD_REQUEST,
-   .ctr[0]   = _CA(0x0001, B6, LDST, 0x0010),
+   .ctr[0]   = _CA(0x0001, B6, 0x1b, 0x0010),
.num_counters = 1,
.norm = { 1, 1 },
 };
@@ -576,7 +576,7 @@ static const struct nvc0_hw_sm_query_cfg
 sm30_gld_mem_div_replay =
 {
.type = NVC0_HW_SM_QUERY_GLD_MEM_DIV_REPLAY,
-   .ctr[0]   = _CB(0x0001, B6, REPLAY, 0x0010),
+   .ctr[0]   = _CB(0x0001, B6, 0x08, 0x0010),
.num_counters = 1,
.norm = { 1, 1 },
 };
@@ -585,7 +585,7 @@ static const struct nvc0_hw_sm_query_cfg
 sm30_gst_transactions =
 {
.type = NVC0_HW_SM_QUERY_GST_TRANSACTIONS,
-   .ctr[0]   = _CB(0x0001, B6, MEM, 0x0004),
+   .ctr[0]   = _CB(0x0001, B6, 0x11, 0x0004),
.num_counters = 1,
.norm = { 1, 1 },
 };
@@ -594,7 +594,7 @@ static const struct nvc0_hw_sm_query_cfg
 sm30_gst_mem_div_replay =
 {
.type = NVC0_HW_SM_QUERY_GST_MEM_DIV_REPLAY,
-   .ctr[0]   = _CB(0x0001, B6, REPLAY, 0x0014),
+   .ctr[0]   = _CB(0x0001, B6, 0x08, 0x0014),
.num_counters = 1,
.norm = { 1, 1 },
 };
@@ -603,7 +603,7 @@ static const struct nvc0_hw_sm_query_cfg
 sm30_gred_count =
 {
.type = NVC0_HW_SM_QUERY_GRED_COUNT,
-   .ctr[0]   = _CA(0x0001, B6, BRANCH, 0x0008),
+   .ctr[0]   = _CA(0x0001, B6, 0x1c, 0x0008),

Re: [Mesa-dev] [PATCH 1/2] tgsi/scan: fix images_buffers regressions

[Brian Paul]

On 11/05/2016 11:38 AM, Marek Olšák wrote:

From: Marek Olšák 

The first IF statement disabled the second one.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98599
---
  src/gallium/auxiliary/tgsi/tgsi_scan.c | 5 ++---
  1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/src/gallium/auxiliary/tgsi/tgsi_scan.c 
b/src/gallium/auxiliary/tgsi/tgsi_scan.c
index aeb326a..26cb2be 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_scan.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_scan.c
@@ -465,20 +465,22 @@ scan_declaration(struct tgsi_shader_info *info,
   int buffer = 0;

   if (fulldecl->Declaration.Dimension)
  buffer = fulldecl->Dim.Index2D;

   info->const_file_max[buffer] =
  MAX2(info->const_file_max[buffer], (int)reg);
   info->const_buffers_declared |= 1u << buffer;
} else if (file == TGSI_FILE_IMAGE) {
   info->images_declared |= 1u << reg;
+ if (fulldecl->Image.Resource == TGSI_TEXTURE_BUFFER)
+info->images_buffers |= 1 << reg;
} else if (file == TGSI_FILE_BUFFER) {
   info->shader_buffers_declared |= 1u << reg;
} else if (file == TGSI_FILE_INPUT) {
   info->input_semantic_name[reg] = (ubyte) semName;
   info->input_semantic_index[reg] = (ubyte) semIndex;
   info->input_interpolate[reg] = (ubyte)fulldecl->Interp.Interpolate;
   info->input_interpolate_loc[reg] = (ubyte)fulldecl->Interp.Location;
   info->input_cylindrical_wrap[reg] = 
(ubyte)fulldecl->Interp.CylindricalWrap;

   /* Vertex shaders can have inputs with holes between them. */
@@ -586,23 +588,20 @@ scan_declaration(struct tgsi_shader_info *info,
   assert(target < TGSI_TEXTURE_UNKNOWN);
   if (info->sampler_targets[reg] == TGSI_TEXTURE_UNKNOWN) {
  /* Save sampler target for this sampler index */
  info->sampler_targets[reg] = target;
  info->sampler_type[reg] = type;
   } else {
  /* if previously declared, make sure targets agree */
  assert(info->sampler_targets[reg] == target);
  assert(info->sampler_type[reg] == type);
   }
-  } else if (file == TGSI_FILE_IMAGE) {
- if (fulldecl->Image.Resource == TGSI_TEXTURE_BUFFER)
-info->images_buffers |= 1 << reg;
}
 }
  }


  static void
  scan_immediate(struct tgsi_shader_info *info)
  {
 uint reg = info->immediate_count++;
 uint file = TGSI_FILE_IMMEDIATE;



For both,
Reviewed-by: Brian Paul 


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

[Mesa-dev] [Bug 98595] glsl: ralloc assertion "info->canary == CANARY" failed

[bugzilla-daemon]

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

--- Comment #4 from Marek Olšák  ---
It's not a duplicated of that bug.

This bug is different. It looks like the HAS_TRIVIAL_DESTRUCTOR macro isn't
done correctly on OpenBSD.

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

Re: [Mesa-dev] [PATCH] st/mesa: initialize members of glsl_to_tgsi_instruction in emit_asm()

[Marek Olšák]

Reviewed-by: Marek Olšák 

Marek

On Sat, Nov 5, 2016 at 7:00 PM, Brian Paul  wrote:
> This fixes random crashes with MSVC release builds.  It seems the
> members are implicitly initialized to zero with gcc, but not MSVC.
> In particular, the tex_offset_num_offset field was non-zero causing
> a loop over the NULL tex_offsets array to crash.
>
> Zero-init those fields and a few others to be safe.
>
> The regression began with acc23b04cfd64e "ralloc: remove memset from
> ralloc_size".
> ---
>  src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp 
> b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
> index 882e959..a4679e5 100644
> --- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
> +++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
> @@ -680,6 +680,10 @@ glsl_to_tgsi_visitor::emit_asm(ir_instruction *ir, 
> unsigned op,
> inst->is_64bit_expanded = false;
> inst->ir = ir;
> inst->dead_mask = 0;
> +   inst->tex_offsets = NULL;
> +   inst->tex_offset_num_offset = 0;
> +   inst->saturate = 0;
> +   inst->tex_shadow = 0;
> /* default to float, for paths where this is not initialized
>  * (since 0==UINT which is likely wrong):
>  */
> --
> 1.9.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 98595] glsl: ralloc assertion "info->canary == CANARY" failed

[bugzilla-daemon]

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

--- Comment #3 from Mark Janes  ---
I can't say that this is a duplicate of bug 98592, which was fixed for intel
hardware on linux.

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

[Mesa-dev] [PATCH] st/mesa: initialize members of glsl_to_tgsi_instruction in emit_asm()

[Brian Paul]

This fixes random crashes with MSVC release builds.  It seems the
members are implicitly initialized to zero with gcc, but not MSVC.
In particular, the tex_offset_num_offset field was non-zero causing
a loop over the NULL tex_offsets array to crash.

Zero-init those fields and a few others to be safe.

The regression began with acc23b04cfd64e "ralloc: remove memset from
ralloc_size".
---
 src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp 
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index 882e959..a4679e5 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
@@ -680,6 +680,10 @@ glsl_to_tgsi_visitor::emit_asm(ir_instruction *ir, 
unsigned op,
inst->is_64bit_expanded = false;
inst->ir = ir;
inst->dead_mask = 0;
+   inst->tex_offsets = NULL;
+   inst->tex_offset_num_offset = 0;
+   inst->saturate = 0;
+   inst->tex_shadow = 0;
/* default to float, for paths where this is not initialized
 * (since 0==UINT which is likely wrong):
 */
-- 
1.9.1

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

Re: [Mesa-dev] [PATCH] android: amd/common: add support for libmesa_amd_common

[Marek Olšák]

Hi,

I pushed the patch from the bug report. Hopefully it's the same as this one.

Marek

On Sat, Nov 5, 2016 at 1:21 PM, Mauro Rossi  wrote:
> Hi Nicolai,
>
> please review the attached patch which is necessary fix android build,
> as per https://bugs.freedesktop.org/show_bug.cgi?id=98573
>
> Tested with nougat-x86 build
> Kind regards
>
> Mauro
>
>
> From 36777861d42ec5ae0c0ed6a60835c76d13e38555 Mon Sep 17 00:00:00 2001
> From: Mauro Rossi 
> Date: Sat, 5 Nov 2016 00:00:29 +0100
> Subject: [PATCH] android: amd/common: add support for libmesa_amd_common
>
> Fixes the following building error introduced with commit 7115e56
> and related amd/common dependencies:
>
> external/mesa/src/gallium/drivers/radeonsi/si_shader.c:6861: error:
> undefined reference to 'ac_is_sgpr_param'
> external/mesa/src/gallium/drivers/radeonsi/si_shader.c:6951: error:
> undefined reference to 'ac_is_sgpr_param'
> clang++: error: linker command failed with exit code 1 (use -v to see
> invocation)
>
> ninja: build stopped: subcommand failed.
> build/core/ninja.mk:148: recipe for target 'ninja_wrapper' failed
> make: *** [ninja_wrapper] Error 1
> ---
>  src/amd/Android.common.mk  | 47 
> ++
>  src/amd/Android.mk |  1 +
>  src/amd/Makefile.sources   | 11 +
>  src/gallium/targets/dri/Android.mk |  2 +-
>  4 files changed, 60 insertions(+), 1 deletion(-)
>  create mode 100644 src/amd/Android.common.mk
>
> diff --git a/src/amd/Android.common.mk b/src/amd/Android.common.mk
> new file mode 100644
> index 000..0dbb299
> --- /dev/null
> +++ b/src/amd/Android.common.mk
> @@ -0,0 +1,47 @@
> +# Copyright © 2016 Red Hat.
> +# 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 (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.
> +
> +# ---
> +# Build libmesa_amd_common
> +# ---
> +
> +include $(CLEAR_VARS)
> +
> +LOCAL_MODULE := libmesa_amd_common
> +
> +LOCAL_SRC_FILES := $(AMD_COMPILER_SOURCES)
> +
> +LOCAL_C_INCLUDES := \
> + $(MESA_TOP)/include \
> + $(MESA_TOP)/src \
> + $(MESA_TOP)/src/amd/common \
> + $(MESA_TOP)/src/gallium/include \
> + $(MESA_TOP)/src/gallium/auxiliary \
> + external/llvm/include \
> + external/llvm/device/include \
> + external/libcxx/include \
> + external/elfutils/$(if $(filter
> 5,$(MESA_ANDROID_MAJOR_VERSION)),0.153/,$(if $(filter
> 6,$(MESA_ANDROID_MAJOR_VERSION)),src/))libelf
> +
> +LOCAL_STATIC_LIBRARIES := libLLVMCore
> +
> +include $(MESA_COMMON_MK)
> +include $(BUILD_STATIC_LIBRARY)
> diff --git a/src/amd/Android.mk b/src/amd/Android.mk
> index 7b745fe..07af052 100644
> --- a/src/amd/Android.mk
> +++ b/src/amd/Android.mk
> @@ -26,3 +26,4 @@ LOCAL_PATH := $(call my-dir)
>  include $(LOCAL_PATH)/Makefile.sources
>
>  include $(LOCAL_PATH)/Android.addrlib.mk
> +include $(LOCAL_PATH)/Android.common.mk
> diff --git a/src/amd/Makefile.sources b/src/amd/Makefile.sources
> index 3114a21..5cbefa3 100644
> --- a/src/amd/Makefile.sources
> +++ b/src/amd/Makefile.sources
> @@ -25,3 +25,14 @@ ADDRLIB_FILES = \
>   addrlib/r800/egbaddrlib.h \
>   addrlib/r800/siaddrlib.cpp \
>   addrlib/r800/siaddrlib.h
> +
> +AMD_COMPILER_SOURCES = \
> + common/ac_binary.c \
> + common/ac_binary.h \
> + common/ac_llvm_helper.cpp \
> + common/ac_llvm_util.c \
> + common/ac_llvm_util.h
> +
> +AMD_NIR_SOURCES = \
> + common/ac_nir_to_llvm.c \
> + common/ac_nir_to_llvm.h
> diff --git a/src/gallium/targets/dri/Android.mk
> b/src/gallium/targets/dri/Android.mk
> index 18aefe3..90bb879 100644
> --- a/src/gallium/targets/dri/Android.mk
> +++ b/src/gallium/targets/dri/Android.mk
> @@ -81,7 +81,7 @@ gallium_DRIVERS += libmesa_pipe_r600
>  LOCAL_CFLAGS += -DGALLIUM_R600
>  endif
>  ifneq ($(filter radeonsi,$(MESA_GPU_DRIVERS)),)
> -gallium_DRIVERS += libmesa_pipe_radeonsi 

[Mesa-dev] [Bug 98595] glsl: ralloc assertion "info->canary == CANARY" failed

[bugzilla-daemon]

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

--- Comment #2 from Marek Olšák  ---
For some reason, OpenBSD things symbol_table_entry has a non-trivial destructor
and calls ralloc_set_destructor. However, it doesn't have a non-trivial
destructor. This looks like a C++ compiler bug.

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

[Mesa-dev] [PATCH 2/2] tgsi/scan: turn a huge if-else-if.. chain into a switch statement

[Marek Olšák]

From: Marek Olšák 

---
 src/gallium/auxiliary/tgsi/tgsi_scan.c | 44 +++---
 1 file changed, 30 insertions(+), 14 deletions(-)

diff --git a/src/gallium/auxiliary/tgsi/tgsi_scan.c 
b/src/gallium/auxiliary/tgsi/tgsi_scan.c
index 26cb2be..40a1340 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_scan.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_scan.c
@@ -448,62 +448,72 @@ scan_declaration(struct tgsi_shader_info *info,
  info->output_array_last[array_id] = fulldecl->Range.Last;
  break;
   }
   info->array_max[file] = MAX2(info->array_max[file], array_id);
}
 
for (reg = fulldecl->Range.First; reg <= fulldecl->Range.Last; reg++) {
   unsigned semName = fulldecl->Semantic.Name;
   unsigned semIndex = fulldecl->Semantic.Index +
  (reg - fulldecl->Range.First);
+  int buffer;
+  unsigned index, target, type;
 
   /* only first 32 regs will appear in this bitfield */
   info->file_mask[file] |= (1 << reg);
   info->file_count[file]++;
   info->file_max[file] = MAX2(info->file_max[file], (int)reg);
 
-  if (file == TGSI_FILE_CONSTANT) {
- int buffer = 0;
+  switch (file) {
+  case TGSI_FILE_CONSTANT:
+ buffer = 0;
 
  if (fulldecl->Declaration.Dimension)
 buffer = fulldecl->Dim.Index2D;
 
  info->const_file_max[buffer] =
 MAX2(info->const_file_max[buffer], (int)reg);
  info->const_buffers_declared |= 1u << buffer;
-  } else if (file == TGSI_FILE_IMAGE) {
+ break;
+
+  case TGSI_FILE_IMAGE:
  info->images_declared |= 1u << reg;
  if (fulldecl->Image.Resource == TGSI_TEXTURE_BUFFER)
 info->images_buffers |= 1 << reg;
-  } else if (file == TGSI_FILE_BUFFER) {
+ break;
+
+  case TGSI_FILE_BUFFER:
  info->shader_buffers_declared |= 1u << reg;
-  } else if (file == TGSI_FILE_INPUT) {
+ break;
+
+  case TGSI_FILE_INPUT:
  info->input_semantic_name[reg] = (ubyte) semName;
  info->input_semantic_index[reg] = (ubyte) semIndex;
  info->input_interpolate[reg] = (ubyte)fulldecl->Interp.Interpolate;
  info->input_interpolate_loc[reg] = (ubyte)fulldecl->Interp.Location;
  info->input_cylindrical_wrap[reg] = 
(ubyte)fulldecl->Interp.CylindricalWrap;
 
  /* Vertex shaders can have inputs with holes between them. */
  info->num_inputs = MAX2(info->num_inputs, reg + 1);
 
  if (semName == TGSI_SEMANTIC_PRIMID)
 info->uses_primid = TRUE;
  else if (procType == PIPE_SHADER_FRAGMENT) {
 if (semName == TGSI_SEMANTIC_POSITION)
info->reads_position = TRUE;
 else if (semName == TGSI_SEMANTIC_FACE)
info->uses_frontface = TRUE;
  }
-  }
-  else if (file == TGSI_FILE_SYSTEM_VALUE) {
- unsigned index = fulldecl->Range.First;
+ break;
+
+  case TGSI_FILE_SYSTEM_VALUE:
+ index = fulldecl->Range.First;
 
  info->system_value_semantic_name[index] = semName;
  info->num_system_values = MAX2(info->num_system_values, index + 1);
 
  switch (semName) {
  case TGSI_SEMANTIC_INSTANCEID:
 info->uses_instanceid = TRUE;
 break;
  case TGSI_SEMANTIC_VERTEXID:
 info->uses_vertexid = TRUE;
@@ -523,22 +533,23 @@ scan_declaration(struct tgsi_shader_info *info,
  case TGSI_SEMANTIC_POSITION:
 info->reads_position = TRUE;
 break;
  case TGSI_SEMANTIC_FACE:
 info->uses_frontface = TRUE;
 break;
  case TGSI_SEMANTIC_SAMPLEMASK:
 info->reads_samplemask = TRUE;
 break;
  }
-  }
-  else if (file == TGSI_FILE_OUTPUT) {
+ break;
+
+  case TGSI_FILE_OUTPUT:
  info->output_semantic_name[reg] = (ubyte) semName;
  info->output_semantic_index[reg] = (ubyte) semIndex;
  info->num_outputs = MAX2(info->num_outputs, reg + 1);
 
  if (semName == TGSI_SEMANTIC_COLOR)
 info->colors_written |= 1 << semIndex;
 
  if (procType == PIPE_SHADER_VERTEX ||
  procType == PIPE_SHADER_GEOMETRY ||
  procType == PIPE_SHADER_TESS_CTRL ||
@@ -571,37 +582,42 @@ scan_declaration(struct tgsi_shader_info *info,
info->writes_samplemask = TRUE;
break;
 }
  }
 
  if (procType == PIPE_SHADER_VERTEX) {
 if (semName == TGSI_SEMANTIC_EDGEFLAG) {
info->writes_edgeflag = TRUE;
 }
  }
-  } else if (file == TGSI_FILE_SAMPLER) {
+ break;
+
+  case TGSI_FILE_SAMPLER:
  STATIC_ASSERT(sizeof(info->samplers_declared) * 8 >= 
PIPE_MAX_SAMPLERS);
  info->samplers_declared |= 1u << reg;
-  } else if (file == TGSI_FILE_SAMPLER_VIEW) {
- unsigned 

[Mesa-dev] [PATCH 1/2] tgsi/scan: fix images_buffers regressions

[Marek Olšák]

From: Marek Olšák 

The first IF statement disabled the second one.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98599
---
 src/gallium/auxiliary/tgsi/tgsi_scan.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/src/gallium/auxiliary/tgsi/tgsi_scan.c 
b/src/gallium/auxiliary/tgsi/tgsi_scan.c
index aeb326a..26cb2be 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_scan.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_scan.c
@@ -465,20 +465,22 @@ scan_declaration(struct tgsi_shader_info *info,
  int buffer = 0;
 
  if (fulldecl->Declaration.Dimension)
 buffer = fulldecl->Dim.Index2D;
 
  info->const_file_max[buffer] =
 MAX2(info->const_file_max[buffer], (int)reg);
  info->const_buffers_declared |= 1u << buffer;
   } else if (file == TGSI_FILE_IMAGE) {
  info->images_declared |= 1u << reg;
+ if (fulldecl->Image.Resource == TGSI_TEXTURE_BUFFER)
+info->images_buffers |= 1 << reg;
   } else if (file == TGSI_FILE_BUFFER) {
  info->shader_buffers_declared |= 1u << reg;
   } else if (file == TGSI_FILE_INPUT) {
  info->input_semantic_name[reg] = (ubyte) semName;
  info->input_semantic_index[reg] = (ubyte) semIndex;
  info->input_interpolate[reg] = (ubyte)fulldecl->Interp.Interpolate;
  info->input_interpolate_loc[reg] = (ubyte)fulldecl->Interp.Location;
  info->input_cylindrical_wrap[reg] = 
(ubyte)fulldecl->Interp.CylindricalWrap;
 
  /* Vertex shaders can have inputs with holes between them. */
@@ -586,23 +588,20 @@ scan_declaration(struct tgsi_shader_info *info,
  assert(target < TGSI_TEXTURE_UNKNOWN);
  if (info->sampler_targets[reg] == TGSI_TEXTURE_UNKNOWN) {
 /* Save sampler target for this sampler index */
 info->sampler_targets[reg] = target;
 info->sampler_type[reg] = type;
  } else {
 /* if previously declared, make sure targets agree */
 assert(info->sampler_targets[reg] == target);
 assert(info->sampler_type[reg] == type);
  }
-  } else if (file == TGSI_FILE_IMAGE) {
- if (fulldecl->Image.Resource == TGSI_TEXTURE_BUFFER)
-info->images_buffers |= 1 << reg;
   }
}
 }
 
 
 static void
 scan_immediate(struct tgsi_shader_info *info)
 {
uint reg = info->immediate_count++;
uint file = TGSI_FILE_IMMEDIATE;
-- 
2.7.4

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

[Mesa-dev] [Bug 98599] xterm menus corrupt since tgsi/scan: handle indirect image indexing correctly

[bugzilla-daemon]

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

--- Comment #5 from Marek Olšák  ---
Thanks. I see the problem.

-- 
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] nvc0: get rid of NVE4_COMPUTE_MP_PM_{A, B}_SIGSEL_XXX

[Ilia Mirkin]

On Sat, Nov 5, 2016 at 12:56 PM, Samuel Pitoiset
 wrote:
> Instead, hardcode group sigsel because there are a bunch of unknown
> groups, especially on SM50/SM52.
>
> Signed-off-by: Samuel Pitoiset 
> ---
>  .../drivers/nouveau/nvc0/nvc0_query_hw_sm.c| 112 
> ++---
>  1 file changed, 56 insertions(+), 56 deletions(-)
>
> diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_query_hw_sm.c 
> b/src/gallium/drivers/nouveau/nvc0/nvc0_query_hw_sm.c
> index d472120..2136368 100644
> --- a/src/gallium/drivers/nouveau/nvc0/nvc0_query_hw_sm.c
> +++ b/src/gallium/drivers/nouveau/nvc0/nvc0_query_hw_sm.c
> @@ -504,8 +504,8 @@ struct nvc0_hw_sm_query_cfg
> uint8_t norm[2]; /* normalization num,denom */
>  };
>
> -#define _CA(f, m, g, s) { f, NVE4_COMPUTE_MP_PM_FUNC_MODE_##m, 0, 
> NVE4_COMPUTE_MP_PM_A_SIGSEL_##g, 0, s }
> -#define _CB(f, m, g, s) { f, NVE4_COMPUTE_MP_PM_FUNC_MODE_##m, 1, 
> NVE4_COMPUTE_MP_PM_B_SIGSEL_##g, 0, s }
> +#define _CA(f, m, g, s) { f, NVE4_COMPUTE_MP_PM_FUNC_MODE_##m, 0, g, 0, s }
> +#define _CB(f, m, g, s) { f, NVE4_COMPUTE_MP_PM_FUNC_MODE_##m, 1, g, 0, s }

If you wanted, you could introduce a second set of macros that took
the value directly, and left some that had the symbolic names. Up to
you... this is basically your code - I don't know what any of this
does or how it works.

>  #define _Q(n, c) [NVE4_HW_SM_QUERY_##n] = c
>
>  /*  Compute capability 3.0 (GK104:GK110)  */
> @@ -513,7 +513,7 @@ static const struct nvc0_hw_sm_query_cfg
>  sm30_active_cycles =
>  {
> .type = NVC0_HW_SM_QUERY_ACTIVE_CYCLES,
> -   .ctr[0]   = _CB(0x0001, B6, WARP, 0x),
> +   .ctr[0]   = _CB(0x0001, B6, 0x02, 0x),
> .num_counters = 1,
> .norm = { 1, 1 },
>  };
> @@ -522,7 +522,7 @@ static const struct nvc0_hw_sm_query_cfg
>  sm30_active_warps =
>  {
> .type = NVC0_HW_SM_QUERY_ACTIVE_WARPS,
> -   .ctr[0]   = _CB(0x003f, B6, WARP, 0x31483104),
> +   .ctr[0]   = _CB(0x003f, B6, 0x02, 0x31483104),
> .num_counters = 1,
> .norm = { 2, 1 },
>  };
> @@ -531,7 +531,7 @@ static const struct nvc0_hw_sm_query_cfg
>  sm30_atom_cas_count =
>  {
> .type = NVC0_HW_SM_QUERY_ATOM_CAS_COUNT,
> -   .ctr[0]   = _CA(0x0001, B6, BRANCH, 0x4),
> +   .ctr[0]   = _CA(0x0001, B6, 0x1c, 0x4),
> .num_counters = 1,
> .norm = { 1, 1 },
>  };
> @@ -540,7 +540,7 @@ static const struct nvc0_hw_sm_query_cfg
>  sm30_atom_count =
>  {
> .type = NVC0_HW_SM_QUERY_ATOM_COUNT,
> -   .ctr[0]   = _CA(0x0001, B6, BRANCH, 0x),
> +   .ctr[0]   = _CA(0x0001, B6, 0x1c, 0x),
> .num_counters = 1,
> .norm = { 1, 1 },
>  };
> @@ -549,7 +549,7 @@ static const struct nvc0_hw_sm_query_cfg
>  sm30_branch =
>  {
> .type = NVC0_HW_SM_QUERY_BRANCH,
> -   .ctr[0]   = _CA(0x0001, B6, BRANCH, 0x000c),
> +   .ctr[0]   = _CA(0x0001, B6, 0x1c, 0x000c),
> .num_counters = 1,
> .norm = { 1, 1 },
>  };
> @@ -558,7 +558,7 @@ static const struct nvc0_hw_sm_query_cfg
>  sm30_divergent_branch =
>  {
> .type = NVC0_HW_SM_QUERY_DIVERGENT_BRANCH,
> -   .ctr[0]   = _CA(0x0001, B6, BRANCH, 0x0010),
> +   .ctr[0]   = _CA(0x0001, B6, 0x1c, 0x0010),
> .num_counters = 1,
> .norm = { 1, 1 },
>  };
> @@ -567,7 +567,7 @@ static const struct nvc0_hw_sm_query_cfg
>  sm30_gld_request =
>  {
> .type = NVC0_HW_SM_QUERY_GLD_REQUEST,
> -   .ctr[0]   = _CA(0x0001, B6, LDST, 0x0010),
> +   .ctr[0]   = _CA(0x0001, B6, 0x1b, 0x0010),
> .num_counters = 1,
> .norm = { 1, 1 },
>  };
> @@ -576,7 +576,7 @@ static const struct nvc0_hw_sm_query_cfg
>  sm30_gld_mem_div_replay =
>  {
> .type = NVC0_HW_SM_QUERY_GLD_MEM_DIV_REPLAY,
> -   .ctr[0]   = _CB(0x0001, B6, REPLAY, 0x0010),
> +   .ctr[0]   = _CB(0x0001, B6, 0x08, 0x0010),
> .num_counters = 1,
> .norm = { 1, 1 },
>  };
> @@ -585,7 +585,7 @@ static const struct nvc0_hw_sm_query_cfg
>  sm30_gst_transactions =
>  {
> .type = NVC0_HW_SM_QUERY_GST_TRANSACTIONS,
> -   .ctr[0]   = _CB(0x0001, B6, MEM, 0x0004),
> +   .ctr[0]   = _CB(0x0001, B6, 0x11, 0x0004),
> .num_counters = 1,
> .norm = { 1, 1 },
>  };
> @@ -594,7 +594,7 @@ static const struct nvc0_hw_sm_query_cfg
>  sm30_gst_mem_div_replay =
>  {
> .type = NVC0_HW_SM_QUERY_GST_MEM_DIV_REPLAY,
> -   .ctr[0]   = _CB(0x0001, B6, REPLAY, 0x0014),
> +   .ctr[0]   = _CB(0x0001, B6, 0x08, 0x0014),
> .num_counters = 1,
> .norm = { 1, 1 },
>  };
> @@ -603,7 +603,7 @@ static const struct nvc0_hw_sm_query_cfg
>  sm30_gred_count =
>  {
> .type = NVC0_HW_SM_QUERY_GRED_COUNT,
> -   .ctr[0]   = _CA(0x0001, B6, BRANCH, 0x0008),
> +   .ctr[0]   = _CA(0x0001, B6, 0x1c, 

[Mesa-dev] [PATCH 1/2] glsl: fix slot_end calculations and simplify reserved_slots check

[Ilia Mirkin]

The previous code was confused about whether slot_end was inclusive or
exclusive. Make it so that it is inclusive consistently, and use it for
setting the new location. This should also better deal with arrays of
incomplete size, since the slot check will assume it gets packed.

Signed-off-by: Ilia Mirkin 
---

No regressions in Intel's jenkins runs, which I believe hit both piglit and CTS.
This is somewhat subtle code, but I think I covered what it was trying to do.

 src/compiler/glsl/link_varyings.cpp | 50 -
 1 file changed, 22 insertions(+), 28 deletions(-)

diff --git a/src/compiler/glsl/link_varyings.cpp 
b/src/compiler/glsl/link_varyings.cpp
index e622b3e..49843cc 100644
--- a/src/compiler/glsl/link_varyings.cpp
+++ b/src/compiler/glsl/link_varyings.cpp
@@ -1546,14 +1546,16 @@ varying_matches::assign_locations(struct 
gl_shader_program *prog,
 
   previous_var_xfb_only = var->data.is_xfb_only;
 
-  unsigned num_elements =  type->count_attribute_slots(is_vertex_input);
-  unsigned slot_end;
-  if (this->disable_varying_packing &&
-  !is_varying_packing_safe(type, var))
- slot_end = 4;
-  else
- slot_end = type->without_array()->vector_elements;
-  slot_end += *location - 1;
+  /* The number of components taken up by this variable. For vertex shader
+   * inputs, we use the number of slots * 4, as they have different
+   * counting rules.
+   */
+  unsigned num_components = is_vertex_input ?
+ type->count_attribute_slots(is_vertex_input) * 4 :
+ this->matches[i].num_components;
+
+  /* The last slot for this variable, inclusive. */
+  unsigned slot_end = *location + num_components - 1;
 
   /* FIXME: We could be smarter in the below code and loop back over
* trying to fill any locations that we skipped because we couldn't pack
@@ -1561,29 +1563,21 @@ varying_matches::assign_locations(struct 
gl_shader_program *prog,
* hit the linking error if we run out of room and suggest they use
* explicit locations.
*/
-  for (unsigned j = 0; j < num_elements; j++) {
- while ((slot_end < MAX_VARYING * 4u) &&
-((reserved_slots & (UINT64_C(1) << *location / 4u) ||
- (reserved_slots & (UINT64_C(1) << slot_end / 4u) {
-
-*location = ALIGN(*location + 1, 4);
-slot_end = *location;
-
-/* reset the counter and try again */
-j = 0;
+  while (slot_end < MAX_VARYING * 4u) {
+ const unsigned slots = (slot_end / 4u) - (*location / 4u) + 1;
+ const uint64_t slot_mask = ((1ull << slots) - 1) << (*location / 4u);
+
+ assert(slots > 0);
+ if (reserved_slots & slot_mask) {
+*location = ALIGN(slot_end + 1, 4);
+slot_end = *location + num_components - 1;
+continue;
  }
 
- /* Increase the slot to make sure there is enough room for next
-  * array element.
-  */
- if (this->disable_varying_packing &&
- !is_varying_packing_safe(type, var))
-slot_end += 4;
- else
-slot_end += type->without_array()->vector_elements;
+ break;
   }
 
-  if (!var->data.patch && *location >= MAX_VARYING * 4u) {
+  if (!var->data.patch && slot_end >= MAX_VARYING * 4u) {
  linker_error(prog, "insufficient contiguous locations available for "
   "%s it is possible an array or struct could not be "
   "packed between varyings with explicit locations. Try "
@@ -1593,7 +1587,7 @@ varying_matches::assign_locations(struct 
gl_shader_program *prog,
 
   this->matches[i].generic_location = *location;
 
-  *location += this->matches[i].num_components;
+  *location = slot_end + 1;
}
 
return (generic_location + 3) / 4;
-- 
2.7.3

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

[Mesa-dev] [PATCH 2/2] glsl: record number of components used in each slot for varying packing

[Ilia Mirkin]

Instead of packing varyings into vec4's, keep track of how many
components each slot uses and create varyings with matching types. This
ensures that we don't end up using more components than the orginal
shader, which is especially important for geometry shader output limits.

Signed-off-by: Ilia Mirkin 
---

This comes up for nouveau, where the limit is 1024 output components for a GS,
and the hardware complains *loudly* if you even think about going over.

 src/compiler/glsl/ir_optimization.h |  4 +++-
 src/compiler/glsl/link_varyings.cpp | 16 +---
 src/compiler/glsl/lower_packed_varyings.cpp | 21 -
 3 files changed, 32 insertions(+), 9 deletions(-)

diff --git a/src/compiler/glsl/ir_optimization.h 
b/src/compiler/glsl/ir_optimization.h
index 6f2bc32..8cee418 100644
--- a/src/compiler/glsl/ir_optimization.h
+++ b/src/compiler/glsl/ir_optimization.h
@@ -136,7 +136,9 @@ void lower_shared_reference(struct gl_linked_shader *shader,
 void lower_ubo_reference(struct gl_linked_shader *shader,
  bool clamp_block_indices);
 void lower_packed_varyings(void *mem_ctx,
-   unsigned locations_used, ir_variable_mode mode,
+   unsigned locations_used,
+   const uint8_t *components,
+   ir_variable_mode mode,
unsigned gs_input_vertices,
gl_linked_shader *shader,
bool disable_varying_packing, bool xfb_enabled);
diff --git a/src/compiler/glsl/link_varyings.cpp 
b/src/compiler/glsl/link_varyings.cpp
index 49843cc..a1dd133 100644
--- a/src/compiler/glsl/link_varyings.cpp
+++ b/src/compiler/glsl/link_varyings.cpp
@@ -1217,6 +1217,7 @@ public:
~varying_matches();
void record(ir_variable *producer_var, ir_variable *consumer_var);
unsigned assign_locations(struct gl_shader_program *prog,
+ uint8_t *components,
  uint64_t reserved_slots);
void store_locations() const;
 
@@ -1482,6 +1483,7 @@ varying_matches::record(ir_variable *producer_var, 
ir_variable *consumer_var)
  */
 unsigned
 varying_matches::assign_locations(struct gl_shader_program *prog,
+  uint8_t *components,
   uint64_t reserved_slots)
 {
/* If packing has been disabled then we cannot safely sort the varyings by
@@ -1585,6 +1587,12 @@ varying_matches::assign_locations(struct 
gl_shader_program *prog,
   var->name);
   }
 
+  if (slot_end < MAX_VARYINGS_INCL_PATCH * 4u) {
+ for (unsigned j = *location / 4u; j < slot_end / 4u; j++)
+components[j] = 4;
+ components[slot_end / 4u] = (slot_end & 3) + 1;
+  }
+
   this->matches[i].generic_location = *location;
 
   *location = slot_end + 1;
@@ -2203,7 +2211,9 @@ assign_varying_locations(struct gl_context *ctx,
   }
}
 
-   const unsigned slots_used = matches.assign_locations(prog, reserved_slots);
+   uint8_t components[MAX_VARYINGS_INCL_PATCH] = {0};
+   const unsigned slots_used = matches.assign_locations(
+ prog, components, reserved_slots);
matches.store_locations();
 
for (unsigned i = 0; i < num_tfeedback_decls; ++i) {
@@ -2263,13 +2273,13 @@ assign_varying_locations(struct gl_context *ctx,
}
 
if (producer) {
-  lower_packed_varyings(mem_ctx, slots_used, ir_var_shader_out,
+  lower_packed_varyings(mem_ctx, slots_used, components, ir_var_shader_out,
 0, producer, disable_varying_packing,
 xfb_enabled);
}
 
if (consumer) {
-  lower_packed_varyings(mem_ctx, slots_used, ir_var_shader_in,
+  lower_packed_varyings(mem_ctx, slots_used, components, ir_var_shader_in,
 consumer_vertices, consumer,
 disable_varying_packing, xfb_enabled);
}
diff --git a/src/compiler/glsl/lower_packed_varyings.cpp 
b/src/compiler/glsl/lower_packed_varyings.cpp
index 19bbe57..b16f25f 100644
--- a/src/compiler/glsl/lower_packed_varyings.cpp
+++ b/src/compiler/glsl/lower_packed_varyings.cpp
@@ -164,7 +164,9 @@ namespace {
 class lower_packed_varyings_visitor
 {
 public:
-   lower_packed_varyings_visitor(void *mem_ctx, unsigned locations_used,
+   lower_packed_varyings_visitor(void *mem_ctx,
+ unsigned locations_used,
+ const uint8_t *components,
  ir_variable_mode mode,
  unsigned gs_input_vertices,
  exec_list *out_instructions,
@@ -203,6 +205,8 @@ private:
 */
const unsigned locations_used;
 
+   const uint8_t* components;
+
/**
 * Array of pointers to the packed varyings that have been created for each
 * generic varying 

[Mesa-dev] [Bug 98599] xterm menus corrupt since tgsi/scan: handle indirect image indexing correctly

[bugzilla-daemon]

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

--- Comment #4 from Andy Furniss  ---
Created attachment 127792
  --> https://bugs.freedesktop.org/attachment.cgi?id=127792=edit
xterm menu bad rendering

So I rechecked by reset --hard onto bad and then the one before and the one
before is OK.

Attaching what bad looks like.

This is not straight forward though, as by chance when testing, SWMBO turned
the TV on, which meant when I restarted X I had 2 outputs enabled. Like this I
can't see the issue. Turning off the hdmi with xrandr made the bad rendering
come back.

-- 
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 98599] xterm menus corrupt since tgsi/scan: handle indirect image indexing correctly

[bugzilla-daemon]

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

--- Comment #3 from Andy Furniss  ---
(In reply to Marek Olšák from comment #1)
> The X server doesn't use shader images, so I think the bisection went wrong.
> The X server should be restarted for every bisection step.

It seemed like a clean bisect - I did restart X every step.

It doesn't revert from head though, so I couldn't confirm with that.

Also tested with llvm a bit off head (as I have a bug open for head), but it
made no difference.

Will re-check later.

-- 
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 98555] NWN won't start on 13.0

[bugzilla-daemon]

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

--- Comment #2 from Alan Swanson  ---
Same error occurs with amdgpu running libdrm 2.4.71 and mesa git. However issue
 only occurrs when using NWUser which wraps various file and dir functions to
provide per user settings and saves. Haven't played NWN for a while so don't
know when started occurring.

libGL error: MESA-LOADER: failed to retrieve device information
libGL error: unable to load driver: amdgpu_dri.so
libGL error: driver pointer missing
libGL error: failed to load driver: amdgpu

-- 
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] nvc0: get rid of NVE4_COMPUTE_MP_PM_{A, B}_SIGSEL_XXX

[Samuel Pitoiset]

Instead, hardcode group sigsel because there are a bunch of unknown
groups, especially on SM50/SM52.

Signed-off-by: Samuel Pitoiset 
---
 .../drivers/nouveau/nvc0/nvc0_query_hw_sm.c| 112 ++---
 1 file changed, 56 insertions(+), 56 deletions(-)

diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_query_hw_sm.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_query_hw_sm.c
index d472120..2136368 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_query_hw_sm.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_query_hw_sm.c
@@ -504,8 +504,8 @@ struct nvc0_hw_sm_query_cfg
uint8_t norm[2]; /* normalization num,denom */
 };
 
-#define _CA(f, m, g, s) { f, NVE4_COMPUTE_MP_PM_FUNC_MODE_##m, 0, 
NVE4_COMPUTE_MP_PM_A_SIGSEL_##g, 0, s }
-#define _CB(f, m, g, s) { f, NVE4_COMPUTE_MP_PM_FUNC_MODE_##m, 1, 
NVE4_COMPUTE_MP_PM_B_SIGSEL_##g, 0, s }
+#define _CA(f, m, g, s) { f, NVE4_COMPUTE_MP_PM_FUNC_MODE_##m, 0, g, 0, s }
+#define _CB(f, m, g, s) { f, NVE4_COMPUTE_MP_PM_FUNC_MODE_##m, 1, g, 0, s }
 #define _Q(n, c) [NVE4_HW_SM_QUERY_##n] = c
 
 /*  Compute capability 3.0 (GK104:GK110)  */
@@ -513,7 +513,7 @@ static const struct nvc0_hw_sm_query_cfg
 sm30_active_cycles =
 {
.type = NVC0_HW_SM_QUERY_ACTIVE_CYCLES,
-   .ctr[0]   = _CB(0x0001, B6, WARP, 0x),
+   .ctr[0]   = _CB(0x0001, B6, 0x02, 0x),
.num_counters = 1,
.norm = { 1, 1 },
 };
@@ -522,7 +522,7 @@ static const struct nvc0_hw_sm_query_cfg
 sm30_active_warps =
 {
.type = NVC0_HW_SM_QUERY_ACTIVE_WARPS,
-   .ctr[0]   = _CB(0x003f, B6, WARP, 0x31483104),
+   .ctr[0]   = _CB(0x003f, B6, 0x02, 0x31483104),
.num_counters = 1,
.norm = { 2, 1 },
 };
@@ -531,7 +531,7 @@ static const struct nvc0_hw_sm_query_cfg
 sm30_atom_cas_count =
 {
.type = NVC0_HW_SM_QUERY_ATOM_CAS_COUNT,
-   .ctr[0]   = _CA(0x0001, B6, BRANCH, 0x4),
+   .ctr[0]   = _CA(0x0001, B6, 0x1c, 0x4),
.num_counters = 1,
.norm = { 1, 1 },
 };
@@ -540,7 +540,7 @@ static const struct nvc0_hw_sm_query_cfg
 sm30_atom_count =
 {
.type = NVC0_HW_SM_QUERY_ATOM_COUNT,
-   .ctr[0]   = _CA(0x0001, B6, BRANCH, 0x),
+   .ctr[0]   = _CA(0x0001, B6, 0x1c, 0x),
.num_counters = 1,
.norm = { 1, 1 },
 };
@@ -549,7 +549,7 @@ static const struct nvc0_hw_sm_query_cfg
 sm30_branch =
 {
.type = NVC0_HW_SM_QUERY_BRANCH,
-   .ctr[0]   = _CA(0x0001, B6, BRANCH, 0x000c),
+   .ctr[0]   = _CA(0x0001, B6, 0x1c, 0x000c),
.num_counters = 1,
.norm = { 1, 1 },
 };
@@ -558,7 +558,7 @@ static const struct nvc0_hw_sm_query_cfg
 sm30_divergent_branch =
 {
.type = NVC0_HW_SM_QUERY_DIVERGENT_BRANCH,
-   .ctr[0]   = _CA(0x0001, B6, BRANCH, 0x0010),
+   .ctr[0]   = _CA(0x0001, B6, 0x1c, 0x0010),
.num_counters = 1,
.norm = { 1, 1 },
 };
@@ -567,7 +567,7 @@ static const struct nvc0_hw_sm_query_cfg
 sm30_gld_request =
 {
.type = NVC0_HW_SM_QUERY_GLD_REQUEST,
-   .ctr[0]   = _CA(0x0001, B6, LDST, 0x0010),
+   .ctr[0]   = _CA(0x0001, B6, 0x1b, 0x0010),
.num_counters = 1,
.norm = { 1, 1 },
 };
@@ -576,7 +576,7 @@ static const struct nvc0_hw_sm_query_cfg
 sm30_gld_mem_div_replay =
 {
.type = NVC0_HW_SM_QUERY_GLD_MEM_DIV_REPLAY,
-   .ctr[0]   = _CB(0x0001, B6, REPLAY, 0x0010),
+   .ctr[0]   = _CB(0x0001, B6, 0x08, 0x0010),
.num_counters = 1,
.norm = { 1, 1 },
 };
@@ -585,7 +585,7 @@ static const struct nvc0_hw_sm_query_cfg
 sm30_gst_transactions =
 {
.type = NVC0_HW_SM_QUERY_GST_TRANSACTIONS,
-   .ctr[0]   = _CB(0x0001, B6, MEM, 0x0004),
+   .ctr[0]   = _CB(0x0001, B6, 0x11, 0x0004),
.num_counters = 1,
.norm = { 1, 1 },
 };
@@ -594,7 +594,7 @@ static const struct nvc0_hw_sm_query_cfg
 sm30_gst_mem_div_replay =
 {
.type = NVC0_HW_SM_QUERY_GST_MEM_DIV_REPLAY,
-   .ctr[0]   = _CB(0x0001, B6, REPLAY, 0x0014),
+   .ctr[0]   = _CB(0x0001, B6, 0x08, 0x0014),
.num_counters = 1,
.norm = { 1, 1 },
 };
@@ -603,7 +603,7 @@ static const struct nvc0_hw_sm_query_cfg
 sm30_gred_count =
 {
.type = NVC0_HW_SM_QUERY_GRED_COUNT,
-   .ctr[0]   = _CA(0x0001, B6, BRANCH, 0x0008),
+   .ctr[0]   = _CA(0x0001, B6, 0x1c, 0x0008),
.num_counters = 1,
.norm = { 1, 1 },
 };
@@ -612,7 +612,7 @@ static const struct nvc0_hw_sm_query_cfg
 sm30_gst_request =
 {
.type = NVC0_HW_SM_QUERY_GST_REQUEST,
-   .ctr[0]   = _CA(0x0001, B6, LDST, 0x0014),
+   .ctr[0]   = _CA(0x0001, B6, 0x1b, 0x0014),
.num_counters = 1,
.norm = { 1, 1 },
 };
@@ -621,7 +621,7 @@ static const struct nvc0_hw_sm_query_cfg
 sm30_inst_executed =
 {
.type = NVC0_HW_SM_QUERY_INST_EXECUTED,
-   .ctr[0]   = _CA(0x0003, B6, EXEC, 

[Mesa-dev] [Bug 98599] xterm menus corrupt since tgsi/scan: handle indirect image indexing correctly

[bugzilla-daemon]

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

--- Comment #2 from Ilia Mirkin  ---
(In reply to Marek Olšák from comment #1)
> The X server doesn't use shader images, so I think the bisection went wrong.
> The X server should be restarted for every bisection step.

It probably does via GLAMOR + PBO's I would assume.

-- 
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 98599] xterm menus corrupt since tgsi/scan: handle indirect image indexing correctly

[bugzilla-daemon]

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

--- Comment #1 from Marek Olšák  ---
The X server doesn't use shader images, so I think the bisection went wrong.
The X server should be restarted for every bisection step.

-- 
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 2/2] Make shader refcounting atomic.

[Steinar H. Gunderson]

These were racy when using the same shaders (seemingly even from different
program objects) on multiple theads sharing the same objects, leading to
issues such as (excerpts from an apitrace dump from a real application):

  1097 @0 glCreateProgram() = 9
  1099 @0 glAttachShader(program = 9, shader = 7)
  1101 @0 glAttachShader(program = 9, shader = 8)
  [...]
  18122 @2 glCreateProgram() = 137
  18128 @2 glAttachShader(program = 137, shader = 7)
  18130 @2 glAttachShader(program = 137, shader = 8)
  [...]
  437559 @0 glUseProgram(program = 9)
  437582 @2 glUseProgram(program = 137)
  437613 @2 glUseProgram(program = 9)
  437614 @2 glGetError() = GL_INVALID_VALUE

with nothing deleting the shaders or programs in-between; just racy
refcounting, as confirmed by Helgrind:

  ==13727== Possible data race during read of size 4 at 0x2B3B2648 by thread #1
  ==13727== Locks held: none
  ==13727==at 0x1EEBF613: _mesa_reference_shader_program_ (shaderobj.c:247)
  ==13727==by 0x1EEBDFB2: _mesa_use_program (shaderapi.c:1259)
  ==13727==by 0x60FA618: movit::EffectChain::execute_phase(movit::Phase*, 
bool, std::set*, 
std::map, 
std::allocator > >*, 
std::set, std::allocator 
>*) (effect_chain.cpp:1885)
  [...]
  ==13727== This conflicts with a previous write of size 4 by thread #20
  ==13727== Locks held: none
  ==13727==at 0x1EEBF600: _mesa_reference_shader_program_ (shaderobj.c:236)
  ==13727==by 0x1EEBDFB2: _mesa_use_program (shaderapi.c:1259)
  ==13727==by 0x60FA618: movit::EffectChain::execute_phase(movit::Phase*, 
bool, std::set*, 
std::map, 
std::allocator > >*, 
std::set, std::allocator 
>*) (effect_chain.cpp:1885)

Cc: 11.2 12.0 13.0 
Signed-off-by: Steinar H. Gunderson 
---
 src/mesa/main/shaderobj.c | 23 +--
 1 file changed, 9 insertions(+), 14 deletions(-)

diff --git a/src/mesa/main/shaderobj.c b/src/mesa/main/shaderobj.c
index 8fd574e..08e4379 100644
--- a/src/mesa/main/shaderobj.c
+++ b/src/mesa/main/shaderobj.c
@@ -41,6 +41,7 @@
 #include "program/prog_parameter.h"
 #include "util/ralloc.h"
 #include "util/string_to_uint_map.h"
+#include "util/u_atomic.h"
 
 /**/
 /*** Shader object functions***/
@@ -64,14 +65,11 @@ _mesa_reference_shader(struct gl_context *ctx, struct 
gl_shader **ptr,
}
if (*ptr) {
   /* Unreference the old shader */
-  GLboolean deleteFlag = GL_FALSE;
   struct gl_shader *old = *ptr;
+  int old_refcount = p_atomic_dec_return(>RefCount);
 
-  assert(old->RefCount > 0);
-  old->RefCount--;
-  deleteFlag = (old->RefCount == 0);
-
-  if (deleteFlag) {
+  assert(old_refcount >= 0);
+  if (old_refcount == 0) {
 if (old->Name != 0)
_mesa_HashRemove(ctx->Shared->ShaderObjects, old->Name);
  _mesa_delete_shader(ctx, old);
@@ -83,7 +81,7 @@ _mesa_reference_shader(struct gl_context *ctx, struct 
gl_shader **ptr,
 
if (sh) {
   /* reference new */
-  sh->RefCount++;
+  p_atomic_inc(>RefCount);
   *ptr = sh;
}
 }
@@ -226,14 +224,11 @@ _mesa_reference_shader_program_(struct gl_context *ctx,
}
if (*ptr) {
   /* Unreference the old shader program */
-  GLboolean deleteFlag = GL_FALSE;
   struct gl_shader_program *old = *ptr;
+  int old_refcount = p_atomic_dec_return(>RefCount);
 
-  assert(old->RefCount > 0);
-  old->RefCount--;
-  deleteFlag = (old->RefCount == 0);
-
-  if (deleteFlag) {
+  assert(old_refcount >= 0);
+  if (old_refcount == 0) {
 if (old->Name != 0)
_mesa_HashRemove(ctx->Shared->ShaderObjects, old->Name);
  _mesa_delete_shader_program(ctx, old);
@@ -244,7 +239,7 @@ _mesa_reference_shader_program_(struct gl_context *ctx,
assert(!*ptr);
 
if (shProg) {
-  shProg->RefCount++;
+  p_atomic_inc(>RefCount);
   *ptr = shProg;
}
 }
-- 
2.8.0.rc3.226.g39d4020

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

[Mesa-dev] [PATCH 1/2] Fix races during _mesa_HashWalk().

[Steinar H. Gunderson]

There is currently no protection against walking a hash (using
_mesa_HashWalk()) and modifying it at the same time, for instance by inserting
or deleting elements. This leads to segfaults in multithreaded code if e.g.
someone calls glTexImage2D (which may have to walk the list of FBOs) while
another thread is calling glDeleteFramebuffers on another thread with the two
contexts sharing lists.

The reason for this is that _mesa_HashWalk() doesn't actually take the mutex
that normally protects the hash; it takes an entirely different mutex.
Thus, walks are only protected against other walks, and there is also no
outer lock taking this. There is an old comment saying that this is to fix
problems with deadlock if the callback needs to take a mutex, but now that we
have recursive mutexes, this is a non-issue.

A demonstration Helgrind hit from a real application:

==13412== Possible data race during write of size 8 at 0x3498C6A8 by thread #1
==13412== Locks held: 2, at addresses 0x1AF09530 0x2B3DF400
==13412==at 0x1F040C99: _mesa_hash_table_remove (hash_table.c:395)
==13412==by 0x1EE98174: _mesa_HashRemove_unlocked (hash.c:350)
==13412==by 0x1EE98174: _mesa_HashRemove (hash.c:365)
==13412==by 0x1EE2372D: _mesa_DeleteFramebuffers (fbobject.c:2669)
==13412==by 0x6105AA4: movit::ResourcePool::cleanup_unlinked_fbos(void*) 
(resource_pool.cpp:473)
==13412==by 0x610615B: movit::ResourcePool::release_fbo(unsigned int) 
(resource_pool.cpp:442)
[...]
==13412== This conflicts with a previous read of size 8 by thread #20
==13412== Locks held: 2, at addresses 0x1AF09558 0x1AF73318
==13412==at 0x1F040CD9: _mesa_hash_table_next_entry (hash_table.c:415)
==13412==by 0x1EE982A8: _mesa_HashWalk (hash.c:426)
==13412==by 0x1EED6DFD: _mesa_update_fbo_texture.part.33 (teximage.c:2683)
==13412==by 0x1EED9410: _mesa_update_fbo_texture (teximage.c:3043)
==13412==by 0x1EED9410: teximage (teximage.c:3073)
==13412==by 0x1EEDA28F: _mesa_TexImage2D (teximage.c:3105)
==13412==by 0x166A68: operator() (mixer.cpp:454)

There are many more interactions than just these two possible.

Cc: 11.2 12.0 13.0 
Signed-off-by: Steinar H. Gunderson 
---
 src/mesa/main/hash.c | 18 +++---
 1 file changed, 7 insertions(+), 11 deletions(-)

diff --git a/src/mesa/main/hash.c b/src/mesa/main/hash.c
index 7d8a5fd..670438a 100644
--- a/src/mesa/main/hash.c
+++ b/src/mesa/main/hash.c
@@ -59,7 +59,6 @@ struct _mesa_HashTable {
struct hash_table *ht;
GLuint MaxKey;/**< highest key inserted so far */
mtx_t Mutex;/**< mutual exclusion lock */
-   mtx_t WalkMutex;/**< for _mesa_HashWalk() */
GLboolean InDeleteAll;/**< Debug check */
/** Value that would be in the table for DELETED_KEY_VALUE. */
void *deleted_key_data;
@@ -129,8 +128,11 @@ _mesa_NewHashTable(void)
   }
 
   _mesa_hash_table_set_deleted_key(table->ht, uint_key(DELETED_KEY_VALUE));
-  mtx_init(>Mutex, mtx_plain);
-  mtx_init(>WalkMutex, mtx_plain);
+  /*
+   * Needs to be recursive, since the callback in _mesa_HashWalk()
+   * is allowed to call _mesa_HashRemove().
+   */
+  mtx_init(>Mutex, mtx_recursive);
}
else {
   _mesa_error_no_memory(__func__);
@@ -161,7 +163,6 @@ _mesa_DeleteHashTable(struct _mesa_HashTable *table)
_mesa_hash_table_destroy(table->ht, NULL);
 
mtx_destroy(>Mutex);
-   mtx_destroy(>WalkMutex);
free(table);
 }
 
@@ -401,11 +402,6 @@ _mesa_HashDeleteAll(struct _mesa_HashTable *table,
 
 /**
  * Walk over all entries in a hash table, calling callback function for each.
- * Note: we use a separate mutex in this function to avoid a recursive
- * locking deadlock (in case the callback calls _mesa_HashRemove()) and to
- * prevent multiple threads/contexts from getting tangled up.
- * A lock-less version of this function could be used when the table will
- * not be modified.
  * \param table  the hash table to walk
  * \param callback  the callback function
  * \param userData  arbitrary pointer to pass along to the callback
@@ -422,13 +418,13 @@ _mesa_HashWalk(const struct _mesa_HashTable *table,
 
assert(table);
assert(callback);
-   mtx_lock(>WalkMutex);
+   mtx_lock(>Mutex);
hash_table_foreach(table->ht, entry) {
   callback((uintptr_t)entry->key, entry->data, userData);
}
if (table->deleted_key_data)
   callback(DELETED_KEY_VALUE, table->deleted_key_data, userData);
-   mtx_unlock(>WalkMutex);
+   mtx_unlock(>Mutex);
 }
 
 static void
-- 
2.8.0.rc3.226.g39d4020

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

[Mesa-dev] [Bug 98599] xterm menus corrupt since tgsi/scan: handle indirect image indexing correctly

[bugzilla-daemon]

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

Andy Furniss  changed:

   What|Removed |Added

 CC||mar...@gmail.com

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

[Mesa-dev] [Bug 98599] xterm menus corrupt since tgsi/scan: handle indirect image indexing correctly

[bugzilla-daemon]

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

Bug ID: 98599
   Summary: xterm menus corrupt since tgsi/scan: handle indirect
image indexing correctly
   Product: Mesa
   Version: git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Mesa core
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: adf.li...@gmail.com
QA Contact: mesa-dev@lists.freedesktop.org

Only just noticed this as I don't usually use xterm menus (control mouse
button).

The menus since below are top 1/3 OK bottom 2/3 black.

Setup is R9285 tonga, xserver 1.18.4, git heads xf86-video-amdgpu, llvm and
mesa.

Desktop is fluxbox, xterm 322.

commit d89890d000da36c51484ee170b2d9727d2766a93
Author: Marek Olšák 
Date:   Sun Oct 9 19:21:33 2016 +0200

tgsi/scan: handle indirect image indexing correctly

-- 
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 98595] glsl: ralloc assertion "info->canary == CANARY" failed

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

 Resolution|DUPLICATE   |---
 Status|RESOLVED|REOPENED

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

Re: [Mesa-dev] [PATCH] Revert "st/vdpau: use linear layout for output surfaces"

[Marek Olšák]

On Nov 5, 2016 1:19 PM, "Christian König"  wrote:
>
> Am 04.11.2016 um 17:43 schrieb Marek Olšák:
>>
>> On Fri, Nov 4, 2016 at 5:23 PM, Alex Deucher 
wrote:
>>>
>>> On Fri, Nov 4, 2016 at 10:57 AM, Marek Olšák  wrote:

 On Nov 4, 2016 3:29 PM, "Emil Velikov" 
wrote:
>
> On 31 October 2016 at 15:12, Marek Olšák  wrote:
>>
>> First, DRI_PRIME should work OK on radeon & amdgpu. I've been testing
>> it with 2 GPUs in 2 PCIe slots. (only OpenGL though)
>>
>> I think the thread got derailed at the beginning and nobody asked the
>> important question:
>>
>> Does radeonsi need PIPE_BIND_VIDEO_DECODE_OUTPUT that it would
>> translate into linear?
>>
> Agreed things got derailed a bit.
>
> On the patch itself, can we get an ack/r-b, please?
> It'll be nice to have nouveau working again, until a
> better/alternative solution is found.

 I'm okay with the patch. My only concern is decoding performance. If
the
 decoder works in 64x1 blocks, tiling will hurt. That's the theory. I
don't
 know how the decoder works.
>>>
>>> Linear definitely performs better.  Some early UVD blocks didn't even
>>> support tiling IIRC.
>>
>> I've looked at the code and it looks like VdpOutputSurface is only
>> used for final 3D passes and not as a decoding output, while
>> VdpVideoSurface is used as a decoding output. Is that correct?
>
>
> Yeah, that is correct. We don't use tiling with the VdpVideoSurface
either because it isn't really beneficial for video decoding.

In that case, this whole discussion was pointless, because the linear
layout is inefficient if it's only used by 3D and shouldn't have been used
here in the first place.

Marek

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

[Mesa-dev] [Bug 98563] Xorg segfaults with displaylink attached and mesa version >= 13.0

[bugzilla-daemon]

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

--- Comment #5 from Andrew Poelstra  ---
Created attachment 127790
  --> https://bugs.freedesktop.org/attachment.cgi?id=127790=edit
Photo of kernel panic when plugging in UGA-4KDP with libdrm
677cd97dc4a930af508388713f5016baf664ed18

-- 
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 98563] Xorg segfaults with displaylink attached and mesa version >= 13.0

[bugzilla-daemon]

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

--- Comment #4 from Andrew Poelstra  ---
(In reply to Emil Velikov from comment #3)
> The following libdrm commit should fix it. Please apply it locally and let
> me know if it works.
> 
> commit 677cd97dc4a930af508388713f5016baf664ed18
> Author: Rob Herring 
> Date:   Fri Oct 21 10:07:59 2016 -0700
> 
> Return an -ENODEV from drmGetDevice() when no device was found.
> 
> https://cgit.freedesktop.org/mesa/drm/commit/
> ?id=677cd97dc4a930af508388713f5016baf664ed18
> 
> Btw you can fetch the patch alone or just rebuild libdrm/master.
> 
> There is another pending fix in the drmDevice area, so as soon as we get a
> confirmation [from a few devs], I'll see that we get another libdrm release.

I also see this bug, my hardware is a UGA-4KDP DisplayLink HDMI device branded
"pluggable".

With Rob's patch, if X is running and I plug in the device (or if I plug it in
then start X), my kernel panics with "PAX: overwritten function pointer or
return address detected:  [01] PREEMPT SMP".

(Actually this might not be the panic -- several lines down grsec says "Halting
the system due to suspicous kernel crash caused by root" so possibly with a
non-grsec kernel it would keep running. I'd prefer not to try :))

-- 
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 79858] Artifacts/Glitches in Blender menu

[bugzilla-daemon]

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

--- Comment #5 from Edward O'Callaghan  ---
(In reply to Michel Dänzer from comment #3)
> I think this is more likely a generic DRI2 issue related to front buffer
> rendering than anything driver specific.

Correct yes,

Run blender with `LIBGL_DRI3_DISABLE=1`. I reported it to them however they
don't listen well.

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

[Mesa-dev] [PATCH] android: amd/common: add support for libmesa_amd_common

[Mauro Rossi]

Hi Nicolai,

please review the attached patch which is necessary fix android build,
as per https://bugs.freedesktop.org/show_bug.cgi?id=98573

Tested with nougat-x86 build
Kind regards

Mauro


>From 36777861d42ec5ae0c0ed6a60835c76d13e38555 Mon Sep 17 00:00:00 2001
From: Mauro Rossi 
Date: Sat, 5 Nov 2016 00:00:29 +0100
Subject: [PATCH] android: amd/common: add support for libmesa_amd_common

Fixes the following building error introduced with commit 7115e56
and related amd/common dependencies:

external/mesa/src/gallium/drivers/radeonsi/si_shader.c:6861: error:
undefined reference to 'ac_is_sgpr_param'
external/mesa/src/gallium/drivers/radeonsi/si_shader.c:6951: error:
undefined reference to 'ac_is_sgpr_param'
clang++: error: linker command failed with exit code 1 (use -v to see
invocation)

ninja: build stopped: subcommand failed.
build/core/ninja.mk:148: recipe for target 'ninja_wrapper' failed
make: *** [ninja_wrapper] Error 1
---
 src/amd/Android.common.mk  | 47 ++
 src/amd/Android.mk |  1 +
 src/amd/Makefile.sources   | 11 +
 src/gallium/targets/dri/Android.mk |  2 +-
 4 files changed, 60 insertions(+), 1 deletion(-)
 create mode 100644 src/amd/Android.common.mk

diff --git a/src/amd/Android.common.mk b/src/amd/Android.common.mk
new file mode 100644
index 000..0dbb299
--- /dev/null
+++ b/src/amd/Android.common.mk
@@ -0,0 +1,47 @@
+# Copyright © 2016 Red Hat.
+# 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 (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.
+
+# ---
+# Build libmesa_amd_common
+# ---
+
+include $(CLEAR_VARS)
+
+LOCAL_MODULE := libmesa_amd_common
+
+LOCAL_SRC_FILES := $(AMD_COMPILER_SOURCES)
+
+LOCAL_C_INCLUDES := \
+ $(MESA_TOP)/include \
+ $(MESA_TOP)/src \
+ $(MESA_TOP)/src/amd/common \
+ $(MESA_TOP)/src/gallium/include \
+ $(MESA_TOP)/src/gallium/auxiliary \
+ external/llvm/include \
+ external/llvm/device/include \
+ external/libcxx/include \
+ external/elfutils/$(if $(filter
5,$(MESA_ANDROID_MAJOR_VERSION)),0.153/,$(if $(filter
6,$(MESA_ANDROID_MAJOR_VERSION)),src/))libelf
+
+LOCAL_STATIC_LIBRARIES := libLLVMCore
+
+include $(MESA_COMMON_MK)
+include $(BUILD_STATIC_LIBRARY)
diff --git a/src/amd/Android.mk b/src/amd/Android.mk
index 7b745fe..07af052 100644
--- a/src/amd/Android.mk
+++ b/src/amd/Android.mk
@@ -26,3 +26,4 @@ LOCAL_PATH := $(call my-dir)
 include $(LOCAL_PATH)/Makefile.sources

 include $(LOCAL_PATH)/Android.addrlib.mk
+include $(LOCAL_PATH)/Android.common.mk
diff --git a/src/amd/Makefile.sources b/src/amd/Makefile.sources
index 3114a21..5cbefa3 100644
--- a/src/amd/Makefile.sources
+++ b/src/amd/Makefile.sources
@@ -25,3 +25,14 @@ ADDRLIB_FILES = \
  addrlib/r800/egbaddrlib.h \
  addrlib/r800/siaddrlib.cpp \
  addrlib/r800/siaddrlib.h
+
+AMD_COMPILER_SOURCES = \
+ common/ac_binary.c \
+ common/ac_binary.h \
+ common/ac_llvm_helper.cpp \
+ common/ac_llvm_util.c \
+ common/ac_llvm_util.h
+
+AMD_NIR_SOURCES = \
+ common/ac_nir_to_llvm.c \
+ common/ac_nir_to_llvm.h
diff --git a/src/gallium/targets/dri/Android.mk
b/src/gallium/targets/dri/Android.mk
index 18aefe3..90bb879 100644
--- a/src/gallium/targets/dri/Android.mk
+++ b/src/gallium/targets/dri/Android.mk
@@ -81,7 +81,7 @@ gallium_DRIVERS += libmesa_pipe_r600
 LOCAL_CFLAGS += -DGALLIUM_R600
 endif
 ifneq ($(filter radeonsi,$(MESA_GPU_DRIVERS)),)
-gallium_DRIVERS += libmesa_pipe_radeonsi libmesa_winsys_amdgpu
+gallium_DRIVERS += libmesa_pipe_radeonsi libmesa_winsys_amdgpu
libmesa_amd_common
 LOCAL_SHARED_LIBRARIES += libLLVM libdrm_amdgpu
 LOCAL_CFLAGS += -DGALLIUM_RADEONSI
 endif
-- 
2.9.3
From 36777861d42ec5ae0c0ed6a60835c76d13e38555 Mon Sep 17 00:00:00 2001
From: Mauro Rossi 
Date: Sat, 5 Nov 2016 00:00:29 +0100
Subject: [PATCH] android: amd/common: add support for 

Re: [Mesa-dev] [PATCH] Revert "st/vdpau: use linear layout for output surfaces"

[Christian König]

Am 04.11.2016 um 17:43 schrieb Marek Olšák:

On Fri, Nov 4, 2016 at 5:23 PM, Alex Deucher  wrote:

On Fri, Nov 4, 2016 at 10:57 AM, Marek Olšák  wrote:

On Nov 4, 2016 3:29 PM, "Emil Velikov"  wrote:

On 31 October 2016 at 15:12, Marek Olšák  wrote:

First, DRI_PRIME should work OK on radeon & amdgpu. I've been testing
it with 2 GPUs in 2 PCIe slots. (only OpenGL though)

I think the thread got derailed at the beginning and nobody asked the
important question:

Does radeonsi need PIPE_BIND_VIDEO_DECODE_OUTPUT that it would
translate into linear?


Agreed things got derailed a bit.

On the patch itself, can we get an ack/r-b, please?
It'll be nice to have nouveau working again, until a
better/alternative solution is found.

I'm okay with the patch. My only concern is decoding performance. If the
decoder works in 64x1 blocks, tiling will hurt. That's the theory. I don't
know how the decoder works.

Linear definitely performs better.  Some early UVD blocks didn't even
support tiling IIRC.

I've looked at the code and it looks like VdpOutputSurface is only
used for final 3D passes and not as a decoding output, while
VdpVideoSurface is used as a decoding output. Is that correct?


Yeah, that is correct. We don't use tiling with the VdpVideoSurface 
either because it isn't really beneficial for video decoding.


Regards,
Christian.



Marek



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

Re: [Mesa-dev] [PATCH] glcpp: initializes version to -1

[Karol Herbst]

2016-11-05 2:50 GMT+01:00 Ian Romanick :
> (Sorry about the top post. Sent from my phone.)
>
> That expression will allow versions like 0130 as valid.  If you just want to
> allow 0, you need a more complex regular expression.  I feel like that's
> just a bandage... what about other bad values like "#version -130"?  Won't
> that have the same problem that 0 currently has?
>

no, it doesn't.

I tested the patch with glsl_compiler

"#version 0130": 0:1(10): error: GLSL 0.88 is not supported. Supported
versions are: 1.10, 1.20, 1.30, 1.00 ES, and 3.00 ES

"#version 0": 0:1(10): error: GLSL 0.00 is not supported. Supported
versions are: 1.10, 1.20, 1.30, 1.00 ES, and 3.00 ES

"#version -130":0:1(10): preprocessor error: syntax error, unexpected
'-', expecting INTEGER or INTEGER_STRING

but

"#version 0512": 0:1(10): error: GLSL 3.30 is not supported. Supported
versions are: 1.10, 1.20, 1.30, 1.00 ES, and 3.00 ES

so the issue with this would be, that "0512" is parsed as 3.30, which
isn't right either, but the current master version does the same. \o/
new bug found

>
> On November 4, 2016 6:09:58 AM "Juan A. Suarez Romero" 
> wrote:
>
>> Shader can define #version as an integer, including 0.
>>
>> Initializes version to -1 to know later if shader has defined a #version
>> or not.
>>
>> It fixes 4 piglit tests:
>>   spec/glsl-1.10/compiler/version-0.frag: crash pass
>>   spec/glsl-1.10/compiler/version-0.vert: crash pass
>>   spec/glsl-es-3.00/compiler/version-0.frag: crash pass
>>   spec/glsl-es-3.00/compiler/version-0.vert: crash pass
>>
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97420
>> ---
>>  src/compiler/glsl/glcpp/glcpp-parse.y | 8 
>>  src/compiler/glsl/glcpp/glcpp.h   | 2 +-
>>  src/compiler/glsl/glsl_lexer.ll   | 2 +-
>>  3 files changed, 6 insertions(+), 6 deletions(-)
>>
>> diff --git a/src/compiler/glsl/glcpp/glcpp-parse.y
>> b/src/compiler/glsl/glcpp/glcpp-parse.y
>> index b80ff04..6207a62 100644
>> --- a/src/compiler/glsl/glcpp/glcpp-parse.y
>> +++ b/src/compiler/glsl/glcpp/glcpp-parse.y
>> @@ -420,13 +420,13 @@ control_line_success:
>> _glcpp_parser_skip_stack_pop (parser, & @1);
>> } NEWLINE
>>  |  HASH_TOKEN VERSION_TOKEN integer_constant NEWLINE {
>> -   if (parser->version != 0) {
>> +   if (parser->version != -1) {
>> glcpp_error(& @1, parser, "#version must appear on
>> the first line");
>> }
>> _glcpp_parser_handle_version_declaration(parser, $3, NULL,
>> true);
>> }
>>  |  HASH_TOKEN VERSION_TOKEN integer_constant IDENTIFIER NEWLINE {
>> -   if (parser->version != 0) {
>> +   if (parser->version != -1) {
>> glcpp_error(& @1, parser, "#version must appear on
>> the first line");
>> }
>> _glcpp_parser_handle_version_declaration(parser, $3, $4,
>> true);
>> @@ -1360,7 +1360,7 @@ glcpp_parser_create(glcpp_extension_iterator
>> extensions, void *state, gl_api api
>> parser->extensions = extensions;
>> parser->state = state;
>> parser->api = api;
>> -   parser->version = 0;
>> +   parser->version = -1;
>>
>> parser->has_new_line_number = 0;
>> parser->new_line_number = 1;
>> @@ -2293,7 +2293,7 @@
>> _glcpp_parser_handle_version_declaration(glcpp_parser_t *parser, intmax_t
>> versio
>>   const char *es_identifier,
>>   bool explicitly_set)
>>  {
>> -   if (parser->version != 0)
>> +   if (parser->version != -1)
>>return;
>>
>> parser->version = version;
>> diff --git a/src/compiler/glsl/glcpp/glcpp.h
>> b/src/compiler/glsl/glcpp/glcpp.h
>> index bb4ad67..2acac0c 100644
>> --- a/src/compiler/glsl/glcpp/glcpp.h
>> +++ b/src/compiler/glsl/glcpp/glcpp.h
>> @@ -207,7 +207,7 @@ struct glcpp_parser {
>> glcpp_extension_iterator extensions;
>> void *state;
>> gl_api api;
>> -   unsigned version;
>> +   int version;
>> bool has_new_line_number;
>> int new_line_number;
>> bool has_new_source_number;
>> diff --git a/src/compiler/glsl/glsl_lexer.ll
>> b/src/compiler/glsl/glsl_lexer.ll
>> index b473af7..7d1d616 100644
>> --- a/src/compiler/glsl/glsl_lexer.ll
>> +++ b/src/compiler/glsl/glsl_lexer.ll
>> @@ -249,7 +249,7 @@ HASH^{SPC}#{SPC}
>>yylval->identifier =
>> linear_strdup(mem_ctx, yytext);
>>return IDENTIFIER;
>> }
>> -[1-9][0-9]*{
>> +[0-9][0-9]*{
>> yylval->n = strtol(yytext, NULL, 10);
>> return INTCONSTANT;
>> }
>> --
>> 2.7.4
>
>
>
> ___
> mesa-dev 

Re: [Mesa-dev] [PATCH] i965: only try print GLSL IR once when using INTEL_DEBUG to dump ir

[Alejandro Piñeiro]

On 04/11/16 22:27, Timothy Arceri wrote:
> On Fri, 2016-11-04 at 18:43 +0100, Alejandro Piñeiro wrote:
>> Nitpick: I found the commit message hard to understand until I read
>> the
>> summary.
> Ok I'll duplicate some of the summary in the commit message.

Ok, thanks.

>> On 03/11/16 11:47, Timothy Arceri wrote:
>>> Since we started releasing GLSL IR after linking the only time we
>>> can
>>> print GLSL IR is during linking. When regenerating variants only
>>> NIR
>>> will be available.
>>> ---
>>>  src/mesa/drivers/dri/i965/brw_cs.c  |  6 --
>>>  src/mesa/drivers/dri/i965/brw_gs.c  |  3 ---
>>>  src/mesa/drivers/dri/i965/brw_link.cpp  | 10 ++
>>>  src/mesa/drivers/dri/i965/brw_program.c | 19 ---
>>>  src/mesa/drivers/dri/i965/brw_program.h |  3 +--
>>>  src/mesa/drivers/dri/i965/brw_tcs.c |  3 ---
>>>  src/mesa/drivers/dri/i965/brw_tes.c |  3 ---
>>>  src/mesa/drivers/dri/i965/brw_vs.c  |  3 ++-
>>>  src/mesa/drivers/dri/i965/brw_wm.c  |  8 
>>>  9 files changed, 21 insertions(+), 37 deletions(-)
>>>
>>> diff --git a/src/mesa/drivers/dri/i965/brw_cs.c
>>> b/src/mesa/drivers/dri/i965/brw_cs.c
>>> index d16fff8..8b13b49 100644
>>> --- a/src/mesa/drivers/dri/i965/brw_cs.c
>>> +++ b/src/mesa/drivers/dri/i965/brw_cs.c
>>> @@ -116,9 +116,6 @@ brw_codegen_cs_prog(struct brw_context *brw,
>>>start_time = get_time();
>>> }
>>>  
>>> -   if (unlikely(INTEL_DEBUG & DEBUG_CS))
>>> -  brw_dump_ir("compute", prog, >base, >program);
>>> -
>>> int st_index = -1;
>>> if (INTEL_DEBUG & DEBUG_SHADER_TIME)
>>>st_index = brw_get_shader_time_index(brw, prog, 
 program, ST_CS);
>>> @@ -172,9 +169,6 @@ brw_codegen_cs_prog(struct brw_context *brw,
>>> prog_data.base.total_scratch,
>>> scratch_ids_per_subslice * subslices);
>>>  
>>> -   if (unlikely(INTEL_DEBUG & DEBUG_CS))
>>> -  fprintf(stderr, "\n");
>>> -
>>> brw_upload_cache(>cache, BRW_CACHE_CS_PROG,
>>>  key, sizeof(*key),
>>>  program, program_size,
>>> diff --git a/src/mesa/drivers/dri/i965/brw_gs.c
>>> b/src/mesa/drivers/dri/i965/brw_gs.c
>>> index 0f052d2..77efa63 100644
>>> --- a/src/mesa/drivers/dri/i965/brw_gs.c
>>> +++ b/src/mesa/drivers/dri/i965/brw_gs.c
>>> @@ -143,9 +143,6 @@ brw_codegen_gs_prog(struct brw_context *brw,
>>> _data.base.vue_map, outputs_written,
>>> prog->SeparateShader);
>>>  
>>> -   if (unlikely(INTEL_DEBUG & DEBUG_GS))
>>> -  brw_dump_ir("geometry", prog, gs, NULL);
>>> -
>>> int st_index = -1;
>>> if (INTEL_DEBUG & DEBUG_SHADER_TIME)
>>>st_index = brw_get_shader_time_index(brw, prog, NULL,
>>> ST_GS);
>>> diff --git a/src/mesa/drivers/dri/i965/brw_link.cpp
>>> b/src/mesa/drivers/dri/i965/brw_link.cpp
>>> index f75b384..7c8ea3e 100644
>>> --- a/src/mesa/drivers/dri/i965/brw_link.cpp
>>> +++ b/src/mesa/drivers/dri/i965/brw_link.cpp
>>> @@ -266,6 +266,16 @@ brw_link_shader(struct gl_context *ctx, struct
>>> gl_shader_program *shProg)
>>>  
>>>brw_add_texrect_params(prog);
>>>  
>>> +  bool debug_enabled =
>>> + (INTEL_DEBUG & intel_debug_flag_for_shader_stage(shader-
 Stage));
>>> +
>>> +  if (debug_enabled && shader->ir) {
>>> + fprintf(stderr, "GLSL IR for native %s shader %d:\n",
>>> + _mesa_shader_stage_to_string(shader->Stage),
>>> shProg->Name);
>>> + _mesa_print_ir(stderr, shader->ir, NULL);
>>> + fprintf(stderr, "\n\n");
>>> +  }
>>> +
>>>prog->nir = brw_create_nir(brw, shProg, prog,
>>> (gl_shader_stage) stage,
>>>   compiler->scalar_stage[stage]);
>>>  
>>> diff --git a/src/mesa/drivers/dri/i965/brw_program.c
>>> b/src/mesa/drivers/dri/i965/brw_program.c
>>> index 647f138..d45be22 100644
>>> --- a/src/mesa/drivers/dri/i965/brw_program.c
>>> +++ b/src/mesa/drivers/dri/i965/brw_program.c
>>> @@ -638,22 +638,11 @@ brw_stage_prog_data_free(const void *p)
>>>  }
>>>  
>>>  void
>>> -brw_dump_ir(const char *stage, struct gl_shader_program
>>> *shader_prog,
>>> -struct gl_linked_shader *shader, struct gl_program
>>> *prog)
>>> +brw_dump_arb_asm(const char *stage, struct gl_program *prog)
>>>  {
>>> -   if (shader_prog) {
>>> -  if (shader->ir) {
>>> - fprintf(stderr,
>>> - "GLSL IR for native %s shader %d:\n",
>>> - stage, shader_prog->Name);
>>> - _mesa_print_ir(stderr, shader->ir, NULL);
>>> - fprintf(stderr, "\n\n");
>>> -  }
>>> -   } else {
>>> -  fprintf(stderr, "ARB_%s_program %d ir for native %s
>>> shader\n",
>>> -  stage, prog->Id, stage);
>>> -  _mesa_print_program(prog);
>>> -   }
>>> +   fprintf(stderr, "ARB_%s_program %d ir for native %s shader\n",
>>> +   stage, prog->Id, stage);
>>> +   _mesa_print_program(prog);
>>>  }
>>>  
>>>  void
>>> diff 

Re: [Mesa-dev] [PATCH 16/18] intel/blorp: Properly handle color compression in blorp_copy

[Pohjolainen, Topi]

On Fri, Nov 04, 2016 at 05:59:29PM -0700, Jason Ekstrand wrote:
>On Nov 4, 2016 2:30 AM, "Pohjolainen, Topi"
><[1]topi.pohjolai...@gmail.com> wrote:
>>
>> On Fri, Nov 04, 2016 at 11:17:13AM +0200, Pohjolainen, Topi wrote:
>> > On Fri, Oct 28, 2016 at 02:17:12AM -0700, Jason Ekstrand wrote:
>> > > Previously, blorp copy operations were CCS-unaware so you had to
>perform
>> > > resolves on the source and destination before performing the
>copy.  This
>> > > commit makes blorp_copy capable of handling CCS-compressed images
>without
>> > > any resolves.
>> > >
>> > > Signed-off-by: Jason Ekstrand <[2]ja...@jlekstrand.net>
>> > > ---
>> > >  src/intel/blorp/blorp_blit.c | 173
>++-
>> > >  src/intel/blorp/blorp_priv.h |   6 ++
>> > >  2 files changed, 177 insertions(+), 2 deletions(-)
>> > >
>> > > diff --git a/src/intel/blorp/blorp_blit.c
>b/src/intel/blorp/blorp_blit.c
>> > > index 07bb181..598b7c9 100644
>> > > --- a/src/intel/blorp/blorp_blit.c
>> > > +++ b/src/intel/blorp/blorp_blit.c
>> > > @@ -851,6 +851,66 @@ blorp_nir_manual_blend_bilinear(nir_builder
>*b, nir_ssa_def *pos,
>> > >frac_y);
>> > >  }
>> > >
>> > > +/** Perform a color bit-cast operation
>> > > + *
>> > > + * For copy operations involving CCS, we may need to use
>different formats for
>> > > + * the source and destination surfaces.  The two formats must
>both be UINT
>> > > + * formats and must have the same size but may have different
>bit layouts.
>> > > + * For instance, we may be copying from R8G8B8A8_UINT to
>R32_UINT or R32_UINT
>> > > + * to R16G16_UINT.  This function generates code to shuffle bits
>around to get
>> > > + * us from one to the other.
>> > > + */
>> > > +static nir_ssa_def *
>> > > +bit_cast_color(struct nir_builder *b, nir_ssa_def *color,
>> > > +   const struct brw_blorp_blit_prog_key *key)
>> > > +{
>> > > +   assert(key->texture_data_type == nir_type_uint);
>> > > +
>> > > +   if (key->dst_bpc > key->src_bpc) {
>> > > +  nir_ssa_def *u = nir_ssa_undef(b, 1, 32);
>> > > +  nir_ssa_def *dst_chan[2] = { u, u };
>> > > +  unsigned shift = 0;
>> > > +  unsigned dst_idx = 0;
>> > > +  for (unsigned i = 0; i < 4; i++) {
>> > > + nir_ssa_def *shifted = nir_ishl(b, nir_channel(b,
>color, i),
>> > > +nir_imm_int(b,
>shift));
>> > > + if (shift == 0) {
>> > > +dst_chan[dst_idx] = shifted;
>> > > + } else {
>> > > +dst_chan[dst_idx] = nir_ior(b, dst_chan[dst_idx],
>shifted);
>> > > + }
>> > > +
>> > > + shift += key->src_bpc;
>> > > + if (shift >= key->dst_bpc) {
>> > > +dst_idx++;
>> > > +shift = 0;
>> > > + }
>> > > +  }
>> >
>> > This iterates unconditionally over 4 source components regardless
>how many
>> > there are in source, right? Lets assume we have dst == R32_UINT and
>> > src == R16G16_UINT, don't we get the following where iterations
>with i = 2
>> > and i = 3 try to access non-existing z and w components:
>> >
>> > i = 0:
>> > nir_ssa_def *shifted = nir_ishl(b, nir_channel(b,
>color, 0),
>> > nir_imm_int(b, 0));
>> > dst_chan[0] = shifted;
>> >
>> > i = 1:
>> > nir_ssa_def *shifted = nir_ishl(b, nir_channel(b,
>color, 1),
>> > nir_imm_int(b, 16));
>> > dst_chan[0] = nir_ior(b, dst_chan[0], shifted);
>> >
>> > i = 2:
>> > nir_ssa_def *shifted = nir_ishl(b, nir_channel(b,
>color, 2),
>> > nir_imm_int(b, 0));
>> > dst_chan[1] = shifted;
>> >
>> > i = 3:
>> > nir_ssa_def *shifted = nir_ishl(b, nir_channel(b,
>color, 3),
>> > nir_imm_int(b, 16));
>> > dst_chan[1] = nir_ior(b, dst_chan[1], shifted);
>>
>> If this is intentional and the idea is to rely on optimization passes
>to
>> remove unnecessary writes to "dst_chan[1]" then a comment would be
>nice.
> 
>It is intentional but instead of relying on any compiler magic, we're
>just relying on the fact that the texturing instruction always returns
>a vec4 and the render target write always takes a vec4.  I could have
>included the number of components in the key and used that to not
>generate pointless conversion code in a few places but that would have
>ended up making it more complicated and we would end 

[Mesa-dev] [Bug 98595] glsl: ralloc assertion "info->canary == CANARY" failed

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

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

--- Comment #1 from Timothy Arceri  ---


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

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

Re: [Mesa-dev] [PATCH v3] vl/dri3: use external texture as back buffers(v3)

[Nayan Deshmukh]

Hi Leo,

Thanks for the reference patch.

 There are only a number of output surfaces taking turns as the
mixer render targets, so we probably can use the same pixmap
 corresponding to each of output surface texture.

The mixer renders to a VdpOutputSurface which is provided to it by the
application, so we can't make any assumptions on the surface that will
be provided it may or may not be the same. Instead we could have
additional fields in vlVdpOutputSurface which stores the handle and
pixamp of the texture.

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