Re: [Mesa-dev] [PATCH] amd/addrlib: limit fastcall/regparm to i386

[Dave Airlie]

On 22 Oct. 2016 15:51, "Jason Ekstrand"  wrote:
>
> Wait... Why are we building the AMD driver on ARM?  I know AMD has been
talking about ARM-based servers, but are they actually strapping GPUs to
them?

PCIE on ARM somewhere.

Dave.

>
> On Fri, Oct 21, 2016 at 1:16 AM, Nicolai Hähnle 
wrote:
>>
>> On 21.10.2016 00:20, Rob Herring wrote:
>>>
>>> The use of regparm causes an error on arm/arm64 builds with clang.
>>> fastcall is allowed, but still throws a warning. As both options only
>>> have effect on 32-bit x86 builds, limit them to that case.
>>
>>
>> While we haven't been particularly good at syncing things
back-and-forth, this code is shared with closed source driver builds,
including on Windows.
>>
>> Please re-structure the patch so that it really only changes the
behavior with Clang. (For example, that MSVC doesn't define __i386__ as far
as I'm aware.)
>>
>> Thanks,
>> Nicolai
>>
>>>
>>> Signed-off-by: Rob Herring 
>>> ---
>>>  src/amd/addrlib/addrtypes.h | 10 +++---
>>>  1 file changed, 7 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/src/amd/addrlib/addrtypes.h b/src/amd/addrlib/addrtypes.h
>>> index 4c68ac544b88..183b5a751c3a 100644
>>> --- a/src/amd/addrlib/addrtypes.h
>>> +++ b/src/amd/addrlib/addrtypes.h
>>> @@ -87,10 +87,14 @@ typedef intINT;
>>>  #endif
>>>
>>>  #ifndef ADDR_FASTCALL
>>> -#if defined(__GNUC__)
>>> -#define ADDR_FASTCALL __attribute__((regparm(0)))
>>> +#if defined(__i386__)
>>> +   #if defined(__GNUC__)
>>> +#define ADDR_FASTCALL __attribute__((regparm(0)))
>>> +#else
>>> +#define ADDR_FASTCALL __fastcall
>>> +#endif
>>>  #else
>>> -#define ADDR_FASTCALL __fastcall
>>> +   #define ADDR_FASTCALL
>>>  #endif
>>>  #endif
>>>
>>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] amd/addrlib: limit fastcall/regparm to i386

[Jason Ekstrand]

Wait... Why are we building the AMD driver on ARM?  I know AMD has been
talking about ARM-based servers, but are they actually strapping GPUs to
them?

On Fri, Oct 21, 2016 at 1:16 AM, Nicolai Hähnle  wrote:

> On 21.10.2016 00:20, Rob Herring wrote:
>
>> The use of regparm causes an error on arm/arm64 builds with clang.
>> fastcall is allowed, but still throws a warning. As both options only
>> have effect on 32-bit x86 builds, limit them to that case.
>>
>
> While we haven't been particularly good at syncing things back-and-forth,
> this code is shared with closed source driver builds, including on Windows.
>
> Please re-structure the patch so that it really only changes the behavior
> with Clang. (For example, that MSVC doesn't define __i386__ as far as I'm
> aware.)
>
> Thanks,
> Nicolai
>
>
>> Signed-off-by: Rob Herring 
>> ---
>>  src/amd/addrlib/addrtypes.h | 10 +++---
>>  1 file changed, 7 insertions(+), 3 deletions(-)
>>
>> diff --git a/src/amd/addrlib/addrtypes.h b/src/amd/addrlib/addrtypes.h
>> index 4c68ac544b88..183b5a751c3a 100644
>> --- a/src/amd/addrlib/addrtypes.h
>> +++ b/src/amd/addrlib/addrtypes.h
>> @@ -87,10 +87,14 @@ typedef intINT;
>>  #endif
>>
>>  #ifndef ADDR_FASTCALL
>> -#if defined(__GNUC__)
>> -#define ADDR_FASTCALL __attribute__((regparm(0)))
>> +#if defined(__i386__)
>> +   #if defined(__GNUC__)
>> +#define ADDR_FASTCALL __attribute__((regparm(0)))
>> +#else
>> +#define ADDR_FASTCALL __fastcall
>> +#endif
>>  #else
>> -#define ADDR_FASTCALL __fastcall
>> +   #define ADDR_FASTCALL
>>  #endif
>>  #endif
>>
>>
>> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] isl/format: Correct ASTC entries of format info table

[Jason Ekstrand]

Are there separate formats for HDR?  I'm not seeing any.  I guess since the
HDR is a strict superset of LDR, it doesn't make much sense to have
separate enums.  In any case, thanks for fixing this!

Reviewed-by: Jason Ekstrand 

Helper functions are so much better...

On Fri, Oct 21, 2016 at 3:50 PM, Nanley Chery  wrote:

> With the isl_format_supports* helpers, we can now conveniently
> report support for this format on Cherry View.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92925
> Signed-off-by: Nanley Chery 
> ---
>  src/intel/isl/isl_format.c | 70 +++---
> 
>  1 file changed, 42 insertions(+), 28 deletions(-)
>
> diff --git a/src/intel/isl/isl_format.c b/src/intel/isl/isl_format.c
> index daf2d81..98806f4 100644
> --- a/src/intel/isl/isl_format.c
> +++ b/src/intel/isl/isl_format.c
> @@ -307,34 +307,34 @@ static const struct surface_format_info
> format_info[] = {
> SF(80, 80,  x,  x,  x,  x,  x,  x,  x,x,   ETC2_EAC_SRGB8_A8)
> SF(90,  x,  x,  x,  x,  x, 75,  x,  x,x,   R8G8B8_UINT)
> SF(90,  x,  x,  x,  x,  x, 75,  x,  x,x,   R8G8B8_SINT)
> -   SF(80, 80,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_4X4_FLT16)
> -   SF(80, 80,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_5X4_FLT16)
> -   SF(80, 80,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_5X5_FLT16)
> -   SF(80, 80,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_6X5_FLT16)
> -   SF(80, 80,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_6X6_FLT16)
> -   SF(80, 80,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_8X5_FLT16)
> -   SF(80, 80,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_8X6_FLT16)
> -   SF(80, 80,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_8X8_FLT16)
> -   SF(80, 80,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_10X5_FLT16)
> -   SF(80, 80,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_10X6_FLT16)
> -   SF(80, 80,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_10X8_FLT16)
> -   SF(80, 80,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_10X10_FLT16)
> -   SF(80, 80,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_12X10_FLT16)
> -   SF(80, 80,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_12X12_FLT16)
> -   SF(80, 80,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_4X4_U8SRGB)
> -   SF(80, 80,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_5X4_U8SRGB)
> -   SF(80, 80,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_5X5_U8SRGB)
> -   SF(80, 80,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_6X5_U8SRGB)
> -   SF(80, 80,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_6X6_U8SRGB)
> -   SF(80, 80,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_8X5_U8SRGB)
> -   SF(80, 80,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_8X6_U8SRGB)
> -   SF(80, 80,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_8X8_U8SRGB)
> -   SF(80, 80,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_10X5_U8SRGB)
> -   SF(80, 80,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_10X6_U8SRGB)
> -   SF(80, 80,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_10X8_U8SRGB)
> -   SF(80, 80,  x,  x,  x,  x,  x,  x,  x,x,
>  ASTC_LDR_2D_10X10_U8SRGB)
> -   SF(80, 80,  x,  x,  x,  x,  x,  x,  x,x,
>  ASTC_LDR_2D_12X10_U8SRGB)
> -   SF(80, 80,  x,  x,  x,  x,  x,  x,  x,x,
>  ASTC_LDR_2D_12X12_U8SRGB)
> +   SF(90, 90,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_4X4_FLT16)
> +   SF(90, 90,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_5X4_FLT16)
> +   SF(90, 90,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_5X5_FLT16)
> +   SF(90, 90,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_6X5_FLT16)
> +   SF(90, 90,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_6X6_FLT16)
> +   SF(90, 90,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_8X5_FLT16)
> +   SF(90, 90,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_8X6_FLT16)
> +   SF(90, 90,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_8X8_FLT16)
> +   SF(90, 90,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_10X5_FLT16)
> +   SF(90, 90,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_10X6_FLT16)
> +   SF(90, 90,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_10X8_FLT16)
> +   SF(90, 90,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_10X10_FLT16)
> +   SF(90, 90,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_12X10_FLT16)
> +   SF(90, 90,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_12X12_FLT16)
> +   SF(90, 90,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_4X4_U8SRGB)
> +   SF(90, 90,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_5X4_U8SRGB)
> +   SF(90, 90,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_5X5_U8SRGB)
> +   SF(90, 90,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_6X5_U8SRGB)
> +   SF(90, 90,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_6X6_U8SRGB)
> +   SF(90, 90,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_8X5_U8SRGB)
> +   SF(90, 90,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_8X6_U8SRGB)
> +   

[Mesa-dev] [Bug 98172] Concurrent call to glClientWaitSync results in segfault in one of the waiters.

[bugzilla-daemon]

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

--- Comment #42 from Suzuki, Shinji  ---
Sorry for the clutter. Timeout is not handled in the previous attempt.
(The use of the shared completion flag seems to have potential synchronization
problem because a waiter can see a successful wait as a result of unsuccessful
call to fence_finish() if another thread comes and completes a successful
fence_finish() call after the first thread completes unsuccessful
fence_finish() but before returns.)

static void st_client_wait_sync(struct gl_context *ctx,
struct gl_sync_object *obj,
GLbitfield flags, GLuint64 timeout)
{
   struct pipe_screen *screen = st_context(ctx)->pipe->screen;
   struct st_sync_object *so = (struct st_sync_object*)obj;
   struct pipe_fence_handle *fence = NULL;

   /* We don't care about GL_SYNC_FLUSH_COMMANDS_BIT, because flush is  
* already called when creating a fence. 
*/

   /* Duplicate the reference so that the fence object is guaranteed to 
* be alive at least until associated 'unref' below is executed. 
* This is important because multiple threads have to execute
* fence_finish() concurrently even if they target same fence object 
* in order to deal with potentially different time-out settings.
*/
   screen->fence_reference(screen, , so->fence);

   if (fence) {
  if(screen->fence_finish(screen, fence, timeout)) {
 so->b.StatusFlag = GL_TRUE;
 if( p_atomic_cmpxchg(>fence, fence, NULL) == fence ) {
/* Get done with 'so->object'. This is a 'unref' op.
 * Borrow the value in 'fence' since so->fence is already   
 * set to NULL by the cmpxchg above.
 */
struct pipe_fence_handle * fence_copy = fence;
screen->fence_reference(screen, _copy, NULL);
 }
  }
   } // fence==0 means the fence has already reached
   screen->fence_reference(screen, , NULL);
}

-- 
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 V3] i965: rewrite brw_setup_vue_interpolation()

[Timothy Arceri]

Here brw_setup_vue_interpolation() is rewritten not to use the InterpQualifier
array in gl_fragment_program which will allow us to remove it.

This change also makes the code which is only used by gen4/5 more self contained
as it now has its own gen5_fragment_program struct rather than storing the map
in brw_context. This means the interpolation map will only get processed once
and will get stored in the in memory cache rather than being processed everytime
the fs changes.

Also by calling this from the fs compile code rather than from the upload code
and using the interpolation assigned there we can get rid of the
BRW_NEW_INTERPOLATION_MAP flag.

It might not seem ideal to add a gen5_fragment_program struct however by the end
of this series we will have gotten rid of all the brw_{shader_stage}_program
structs and replaced them with a generic brw_program struct so there will only
be two program structs which is better than what we have now.

V2: Don't remove BRW_NEW_INTERPOLATION_MAP from dirty_bit_map until the 
following
patch to fix build error.

V3 - Suggestions by Jason:
- name struct gen4_fragment_program rather than gen5_fragment_program
- don't use enum with memset()
- create interp mode set helper and simplify logic to call it
- add assert when calling function to show prog will never be NULL for
 gen4/5 i.e. no Vulkan
---
 src/intel/blorp/blorp.c   |  6 +-
 src/intel/vulkan/anv_pipeline.c   |  2 +-
 src/mesa/drivers/dri/i965/brw_clip.c  | 19 +++--
 src/mesa/drivers/dri/i965/brw_clip.h  |  7 +-
 src/mesa/drivers/dri/i965/brw_clip_line.c |  2 +-
 src/mesa/drivers/dri/i965/brw_clip_tri.c  |  2 +-
 src/mesa/drivers/dri/i965/brw_clip_unfilled.c |  2 +-
 src/mesa/drivers/dri/i965/brw_clip_util.c | 10 +--
 src/mesa/drivers/dri/i965/brw_compiler.h  |  8 +-
 src/mesa/drivers/dri/i965/brw_context.h   | 45 ---
 src/mesa/drivers/dri/i965/brw_fs.cpp  |  4 +-
 src/mesa/drivers/dri/i965/brw_interpolation_map.c | 91 ---
 src/mesa/drivers/dri/i965/brw_nir.c   |  8 +-
 src/mesa/drivers/dri/i965/brw_nir.h   |  3 +-
 src/mesa/drivers/dri/i965/brw_program.c   | 10 ++-
 src/mesa/drivers/dri/i965/brw_sf.c| 14 +++-
 src/mesa/drivers/dri/i965/brw_sf.h|  4 +-
 src/mesa/drivers/dri/i965/brw_sf_emit.c   | 12 +--
 src/mesa/drivers/dri/i965/brw_state.h |  3 -
 src/mesa/drivers/dri/i965/brw_state_upload.c  |  5 +-
 src/mesa/drivers/dri/i965/brw_wm.c| 18 -
 src/mesa/drivers/dri/i965/brw_wm.h|  3 +-
 22 files changed, 149 insertions(+), 129 deletions(-)

diff --git a/src/intel/blorp/blorp.c b/src/intel/blorp/blorp.c
index 5209ee2..8905cfa 100644
--- a/src/intel/blorp/blorp.c
+++ b/src/intel/blorp/blorp.c
@@ -211,9 +211,9 @@ brw_blorp_compile_nir_shader(struct blorp_context *blorp, 
struct nir_shader *nir
nir_lower_io(nir, nir_var_uniform, nir_uniform_type_size, 0);
 
const unsigned *program =
-  brw_compile_fs(compiler, blorp->driver_ctx, mem_ctx,
- wm_key, _prog_data, nir,
- NULL, -1, -1, false, use_repclear, program_size, NULL);
+  brw_compile_fs(compiler, blorp->driver_ctx, mem_ctx, wm_key,
+ _prog_data, nir, NULL, -1, -1, false, use_repclear,
+ NULL, program_size, NULL);
 
/* Copy the relavent bits of wm_prog_data over into the blorp prog data */
prog_data->dispatch_8 = wm_prog_data.dispatch_8;
diff --git a/src/intel/vulkan/anv_pipeline.c b/src/intel/vulkan/anv_pipeline.c
index 72f0643..0aac711 100644
--- a/src/intel/vulkan/anv_pipeline.c
+++ b/src/intel/vulkan/anv_pipeline.c
@@ -678,7 +678,7 @@ anv_pipeline_compile_fs(struct anv_pipeline *pipeline,
   unsigned code_size;
   const unsigned *shader_code =
  brw_compile_fs(compiler, NULL, mem_ctx, , _data, nir,
-NULL, -1, -1, true, false, _size, NULL);
+NULL, -1, -1, true, false, NULL, _size, NULL);
   if (shader_code == NULL) {
  ralloc_free(mem_ctx);
  return vk_error(VK_ERROR_OUT_OF_HOST_MEMORY);
diff --git a/src/mesa/drivers/dri/i965/brw_clip.c 
b/src/mesa/drivers/dri/i965/brw_clip.c
index 1134fa4..8646b9e 100644
--- a/src/mesa/drivers/dri/i965/brw_clip.c
+++ b/src/mesa/drivers/dri/i965/brw_clip.c
@@ -68,11 +68,6 @@ static void compile_clip_prog( struct brw_context *brw,
c.key = *key;
c.vue_map = brw->vue_map_geom_out;
 
-   c.has_flat_shading =
-  brw_any_flat_varyings(>interpolation_mode);
-   c.has_noperspective_shading =
-  brw_any_noperspective_varyings(>interpolation_mode);
-
/* nr_regs is the number of registers filled by reading data from the VUE.
 * This program accesses the entire VUE, so nr_regs needs to be the size of
 * the VUE (measured in pairs, since two slots are stored in 

[Mesa-dev] [PATCH] isl/format: Correct ASTC entries of format info table

[Nanley Chery]

With the isl_format_supports* helpers, we can now conveniently
report support for this format on Cherry View.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92925
Signed-off-by: Nanley Chery 
---
 src/intel/isl/isl_format.c | 70 +++---
 1 file changed, 42 insertions(+), 28 deletions(-)

diff --git a/src/intel/isl/isl_format.c b/src/intel/isl/isl_format.c
index daf2d81..98806f4 100644
--- a/src/intel/isl/isl_format.c
+++ b/src/intel/isl/isl_format.c
@@ -307,34 +307,34 @@ static const struct surface_format_info format_info[] = {
SF(80, 80,  x,  x,  x,  x,  x,  x,  x,x,   ETC2_EAC_SRGB8_A8)
SF(90,  x,  x,  x,  x,  x, 75,  x,  x,x,   R8G8B8_UINT)
SF(90,  x,  x,  x,  x,  x, 75,  x,  x,x,   R8G8B8_SINT)
-   SF(80, 80,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_4X4_FLT16)
-   SF(80, 80,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_5X4_FLT16)
-   SF(80, 80,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_5X5_FLT16)
-   SF(80, 80,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_6X5_FLT16)
-   SF(80, 80,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_6X6_FLT16)
-   SF(80, 80,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_8X5_FLT16)
-   SF(80, 80,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_8X6_FLT16)
-   SF(80, 80,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_8X8_FLT16)
-   SF(80, 80,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_10X5_FLT16)
-   SF(80, 80,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_10X6_FLT16)
-   SF(80, 80,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_10X8_FLT16)
-   SF(80, 80,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_10X10_FLT16)
-   SF(80, 80,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_12X10_FLT16)
-   SF(80, 80,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_12X12_FLT16)
-   SF(80, 80,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_4X4_U8SRGB)
-   SF(80, 80,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_5X4_U8SRGB)
-   SF(80, 80,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_5X5_U8SRGB)
-   SF(80, 80,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_6X5_U8SRGB)
-   SF(80, 80,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_6X6_U8SRGB)
-   SF(80, 80,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_8X5_U8SRGB)
-   SF(80, 80,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_8X6_U8SRGB)
-   SF(80, 80,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_8X8_U8SRGB)
-   SF(80, 80,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_10X5_U8SRGB)
-   SF(80, 80,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_10X6_U8SRGB)
-   SF(80, 80,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_10X8_U8SRGB)
-   SF(80, 80,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_10X10_U8SRGB)
-   SF(80, 80,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_12X10_U8SRGB)
-   SF(80, 80,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_12X12_U8SRGB)
+   SF(90, 90,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_4X4_FLT16)
+   SF(90, 90,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_5X4_FLT16)
+   SF(90, 90,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_5X5_FLT16)
+   SF(90, 90,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_6X5_FLT16)
+   SF(90, 90,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_6X6_FLT16)
+   SF(90, 90,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_8X5_FLT16)
+   SF(90, 90,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_8X6_FLT16)
+   SF(90, 90,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_8X8_FLT16)
+   SF(90, 90,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_10X5_FLT16)
+   SF(90, 90,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_10X6_FLT16)
+   SF(90, 90,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_10X8_FLT16)
+   SF(90, 90,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_10X10_FLT16)
+   SF(90, 90,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_12X10_FLT16)
+   SF(90, 90,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_12X12_FLT16)
+   SF(90, 90,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_4X4_U8SRGB)
+   SF(90, 90,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_5X4_U8SRGB)
+   SF(90, 90,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_5X5_U8SRGB)
+   SF(90, 90,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_6X5_U8SRGB)
+   SF(90, 90,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_6X6_U8SRGB)
+   SF(90, 90,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_8X5_U8SRGB)
+   SF(90, 90,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_8X6_U8SRGB)
+   SF(90, 90,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_8X8_U8SRGB)
+   SF(90, 90,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_10X5_U8SRGB)
+   SF(90, 90,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_10X6_U8SRGB)
+   SF(90, 90,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_10X8_U8SRGB)
+   SF(90, 90,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_10X10_U8SRGB)
+   SF(90, 90,  x,  x,  x,  x,  x,  x,  x,x,   ASTC_LDR_2D_12X10_U8SRGB)
+   SF(90, 90,  x,  x,  x,  x,  x,  x,  x,x,   

[Mesa-dev] [Bug 98308] llvmpipe crashes with glxgears (LTO related)

[bugzilla-daemon]

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

--- Comment #13 from Marc Dietrich  ---
These options fail in src/mapi  (fixable by removing them there), but later
they generate an internal compiler error, which I can't deal with. I attached
my build script. Maybe you can reproduce the bug.

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

[Mesa-dev] [Bug 98308] llvmpipe crashes with glxgears (LTO related)

[bugzilla-daemon]

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

--- Comment #12 from Marc Dietrich  ---
Created attachment 127454
  --> https://bugs.freedesktop.org/attachment.cgi?id=127454=edit
build script

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

[Mesa-dev] [PATCH 3/3] i965/gen8: Don't enable alpha test and alpha to coverage if draw bufer zero is integer type

[Anuj Phogat]

We follow this rule at multiple places in i965 driver. This patch
doesn't fix any testcase.

Signed-off-by: Anuj Phogat 
---
 src/mesa/drivers/dri/i965/gen8_blend_state.c | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/gen8_blend_state.c 
b/src/mesa/drivers/dri/i965/gen8_blend_state.c
index 84cbf60..c721da1 100644
--- a/src/mesa/drivers/dri/i965/gen8_blend_state.c
+++ b/src/mesa/drivers/dri/i965/gen8_blend_state.c
@@ -218,13 +218,16 @@ gen8_upload_ps_blend(struct brw_context *brw)
if (brw_color_buffer_write_enabled(brw))
   dw1 |= GEN8_PS_BLEND_HAS_WRITEABLE_RT;
 
-   /* _NEW_COLOR */
-   if (ctx->Color.AlphaEnabled)
-  dw1 |= GEN8_PS_BLEND_ALPHA_TEST_ENABLE;
+   if(!buffer0_is_integer) {
+  /* _NEW_COLOR */
+  if (ctx->Color.AlphaEnabled)
+ dw1 |= GEN8_PS_BLEND_ALPHA_TEST_ENABLE;
 
-   /* _NEW_MULTISAMPLE */
-   if (_mesa_is_multisample_enabled(ctx) && 
ctx->Multisample.SampleAlphaToCoverage)
-  dw1 |= GEN8_PS_BLEND_ALPHA_TO_COVERAGE_ENABLE;
+  /* _NEW_MULTISAMPLE */
+  if (_mesa_is_multisample_enabled(ctx) &&
+  ctx->Multisample.SampleAlphaToCoverage)
+ dw1 |= GEN8_PS_BLEND_ALPHA_TO_COVERAGE_ENABLE;
+   }
 
/* Used for implementing the following bit of GL_EXT_texture_integer:
 * "Per-fragment operations that require floating-point color
-- 
2.5.5

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

[Mesa-dev] [PATCH 1/3] i965/gen8: Use DrawBuffer->_IntegerBuffers in gen8_upload_blend_state()

[Anuj Phogat]

No functional changes in this patch.

Signed-off-by: Anuj Phogat 
---
 src/mesa/drivers/dri/i965/gen8_blend_state.c | 10 ++
 1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/gen8_blend_state.c 
b/src/mesa/drivers/dri/i965/gen8_blend_state.c
index 4935d82..8aca8b8 100644
--- a/src/mesa/drivers/dri/i965/gen8_blend_state.c
+++ b/src/mesa/drivers/dri/i965/gen8_blend_state.c
@@ -59,11 +59,7 @@ gen8_upload_blend_state(struct brw_context *brw)
 * integer format, the SAMPLE_ALPHA_TO_COVERAGE and SAMPLE_ALPHA_TO_ONE
 * operations are skipped."
 */
-   struct gl_renderbuffer *rb0 = ctx->DrawBuffer->_ColorDrawBuffers[0];
-   GLenum rb_zero_type =
-  rb0 ? _mesa_get_format_datatype(rb0->Format) : GL_UNSIGNED_NORMALIZED;
-
-   if (rb_zero_type != GL_INT && rb_zero_type != GL_UNSIGNED_INT) {
+   if (!(ctx->DrawBuffer->_IntegerBuffers & 0x1)) {
   /* _NEW_MULTISAMPLE */
   if (_mesa_is_multisample_enabled(ctx)) {
  if (ctx->Multisample.SampleAlphaToCoverage) {
@@ -90,8 +86,6 @@ gen8_upload_blend_state(struct brw_context *brw)
for (int i = 0; i < nr_draw_buffers; i++) {
   /* _NEW_BUFFERS */
   struct gl_renderbuffer *rb = ctx->DrawBuffer->_ColorDrawBuffers[i];
-  GLenum rb_type =
- rb ? _mesa_get_format_datatype(rb->Format) : GL_UNSIGNED_NORMALIZED;
 
   /* Used for implementing the following bit of GL_EXT_texture_integer:
* "Per-fragment operations that require floating-point color
@@ -99,7 +93,7 @@ gen8_upload_blend_state(struct brw_context *brw)
*  blending, and dithering, have no effect when the corresponding
*  colors are written to an integer color buffer."
   */
-  bool integer = rb_type == GL_INT || rb_type == GL_UNSIGNED_INT;
+  bool integer = ctx->DrawBuffer->_IntegerBuffers & (0x1 << i);
 
   /* _NEW_COLOR */
   if (ctx->Color.ColorLogicOpEnabled) {
-- 
2.5.5

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

[Mesa-dev] [PATCH 2/3] i965/gen8: Use DrawBuffer->_IntegerBuffers in gen8_upload_ps_blend()

[Anuj Phogat]

No functional changes in this patch.

Signed-off-by: Anuj Phogat 
---
 src/mesa/drivers/dri/i965/gen8_blend_state.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/gen8_blend_state.c 
b/src/mesa/drivers/dri/i965/gen8_blend_state.c
index 8aca8b8..84cbf60 100644
--- a/src/mesa/drivers/dri/i965/gen8_blend_state.c
+++ b/src/mesa/drivers/dri/i965/gen8_blend_state.c
@@ -212,6 +212,7 @@ gen8_upload_ps_blend(struct brw_context *brw)
 
/* _NEW_BUFFERS */
struct gl_renderbuffer *rb = ctx->DrawBuffer->_ColorDrawBuffers[0];
+   const bool buffer0_is_integer = ctx->DrawBuffer->_IntegerBuffers & 0x1;
 
/* BRW_NEW_FRAGMENT_PROGRAM | _NEW_BUFFERS | _NEW_COLOR */
if (brw_color_buffer_write_enabled(brw))
@@ -236,11 +237,7 @@ gen8_upload_ps_blend(struct brw_context *brw)
 *  integer format, the SAMPLE_ALPHA_TO_COVERAGE and SAMPLE_ALPHA_TO_ONE
 *  operations are skipped."
 */
-   GLenum rb_type =
-  rb ? _mesa_get_format_datatype(rb->Format) : GL_UNSIGNED_NORMALIZED;
-
-   if (rb && rb_type != GL_INT && rb_type != GL_UNSIGNED_INT &&
-   (ctx->Color.BlendEnabled & 1)) {
+   if (rb && !buffer0_is_integer && (ctx->Color.BlendEnabled & 1)) {
   GLenum eqRGB = ctx->Color.Blend[0].EquationRGB;
   GLenum eqA = ctx->Color.Blend[0].EquationA;
   GLenum srcRGB = ctx->Color.Blend[0].SrcRGB;
-- 
2.5.5

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

[Mesa-dev] [PATCH] glsl/mesa: remove unused namespace support from the symbol table

[Timothy Arceri]

Namespace support seems to have been unused for a very long time.

Previously the hash table entry was never removed and the symbol name
wasn't freed until the symbol table was destroyed.

In theory this could reduced the number of times we need to copy a string
as duplicate names are reused. However in practice there is likely only a
limited number of symbols that are the same and this is likely to cause
other less than optimal behavious such as the hash_table continuously
growing.

Along with dropping namespace support this change removes entries from
the hashtable as they become unused.

Cc: Samuel Iglesias Gonsálvez 
---
 src/compiler/glsl/glsl_symbol_table.cpp |  18 +-
 src/compiler/glsl/ir_print_visitor.cpp  |   4 +-
 src/mesa/program/program_lexer.l|   2 +-
 src/mesa/program/program_parse.y|  18 +-
 src/mesa/program/symbol_table.c | 336 ++--
 src/mesa/program/symbol_table.h |  15 +-
 6 files changed, 128 insertions(+), 265 deletions(-)

diff --git a/src/compiler/glsl/glsl_symbol_table.cpp 
b/src/compiler/glsl/glsl_symbol_table.cpp
index 6d7baad..3162bb6 100644
--- a/src/compiler/glsl/glsl_symbol_table.cpp
+++ b/src/compiler/glsl/glsl_symbol_table.cpp
@@ -126,7 +126,7 @@ void glsl_symbol_table::pop_scope()
 
 bool glsl_symbol_table::name_declared_this_scope(const char *name)
 {
-   return _mesa_symbol_table_symbol_scope(table, -1, name) == 0;
+   return _mesa_symbol_table_symbol_scope(table, name) == 0;
 }
 
 bool glsl_symbol_table::add_variable(ir_variable *v)
@@ -152,7 +152,7 @@ bool glsl_symbol_table::add_variable(ir_variable *v)
 symbol_table_entry *entry = new(mem_ctx) symbol_table_entry(v);
 if (existing != NULL)
entry->f = existing->f;
-int added = _mesa_symbol_table_add_symbol(table, -1, v->name, entry);
+int added = _mesa_symbol_table_add_symbol(table, v->name, entry);
 assert(added == 0);
 (void)added;
 return true;
@@ -162,13 +162,13 @@ bool glsl_symbol_table::add_variable(ir_variable *v)
 
/* 1.20+ rules: */
symbol_table_entry *entry = new(mem_ctx) symbol_table_entry(v);
-   return _mesa_symbol_table_add_symbol(table, -1, v->name, entry) == 0;
+   return _mesa_symbol_table_add_symbol(table, v->name, entry) == 0;
 }
 
 bool glsl_symbol_table::add_type(const char *name, const glsl_type *t)
 {
symbol_table_entry *entry = new(mem_ctx) symbol_table_entry(t);
-   return _mesa_symbol_table_add_symbol(table, -1, name, entry) == 0;
+   return _mesa_symbol_table_add_symbol(table, name, entry) == 0;
 }
 
 bool glsl_symbol_table::add_interface(const char *name, const glsl_type *i,
@@ -180,7 +180,7 @@ bool glsl_symbol_table::add_interface(const char *name, 
const glsl_type *i,
   symbol_table_entry *entry =
  new(mem_ctx) symbol_table_entry(i, mode);
   bool add_interface_symbol_result =
- _mesa_symbol_table_add_symbol(table, -1, name, entry) == 0;
+ _mesa_symbol_table_add_symbol(table, name, entry) == 0;
   assert(add_interface_symbol_result);
   return add_interface_symbol_result;
} else {
@@ -199,7 +199,7 @@ bool glsl_symbol_table::add_function(ir_function *f)
   }
}
symbol_table_entry *entry = new(mem_ctx) symbol_table_entry(f);
-   return _mesa_symbol_table_add_symbol(table, -1, f->name, entry) == 0;
+   return _mesa_symbol_table_add_symbol(table, f->name, entry) == 0;
 }
 
 bool glsl_symbol_table::add_default_precision_qualifier(const char *type_name,
@@ -213,13 +213,13 @@ bool 
glsl_symbol_table::add_default_precision_qualifier(const char *type_name,
symbol_table_entry *entry =
   new(mem_ctx) symbol_table_entry(default_specifier);
 
-   return _mesa_symbol_table_add_symbol(table, -1, name, entry) == 0;
+   return _mesa_symbol_table_add_symbol(table, name, entry) == 0;
 }
 
 void glsl_symbol_table::add_global_function(ir_function *f)
 {
symbol_table_entry *entry = new(mem_ctx) symbol_table_entry(f);
-   int added = _mesa_symbol_table_add_global_symbol(table, -1, f->name, entry);
+   int added = _mesa_symbol_table_add_global_symbol(table, f->name, entry);
assert(added == 0);
(void)added;
 }
@@ -261,7 +261,7 @@ int 
glsl_symbol_table::get_default_precision_qualifier(const char *type_name)
 symbol_table_entry *glsl_symbol_table::get_entry(const char *name)
 {
return (symbol_table_entry *)
-  _mesa_symbol_table_find_symbol(table, -1, name);
+  _mesa_symbol_table_find_symbol(table, name);
 }
 
 void
diff --git a/src/compiler/glsl/ir_print_visitor.cpp 
b/src/compiler/glsl/ir_print_visitor.cpp
index cdbe184..703169e 100644
--- a/src/compiler/glsl/ir_print_visitor.cpp
+++ b/src/compiler/glsl/ir_print_visitor.cpp
@@ -130,14 +130,14 @@ ir_print_visitor::unique_name(ir_variable *var)
 
/* If there's no conflict, just use the original name */
const char* name = NULL;
-   if (_mesa_symbol_table_find_symbol(this->symbols, -1, var->name) == NULL) {
+   if 

[Mesa-dev] [PATCH] egl/android: implement minimal swap_buffers_with_damage

[Rob Herring]

Since commit 0a606a400fe3 ("egl: add eglSwapBuffersWithDamageKHR"),
Android has been broken because the function eglSwapBuffersWithDamageKHR
is provided regardless of the extension being present. Also, the Android
meta-EGL always advertises the extension regardless of the underlying
EGL implementation. As there doesn't seem to be a simple way
conditionally make the EGL function ptr NULL, just implement a brain
dead version for Android EGL.

Cc: Rob Clark 
Cc: Eric Engestrom 
Cc: Emil Velikov 
Signed-off-by: Rob Herring 
---
 src/egl/drivers/dri2/platform_android.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/src/egl/drivers/dri2/platform_android.c 
b/src/egl/drivers/dri2/platform_android.c
index 142ef05bd1ea..2a6527a34407 100644
--- a/src/egl/drivers/dri2/platform_android.c
+++ b/src/egl/drivers/dri2/platform_android.c
@@ -483,6 +483,14 @@ droid_swap_buffers(_EGLDriver *drv, _EGLDisplay *disp, 
_EGLSurface *draw)
return EGL_TRUE;
 }
 
+static EGLBoolean
+droid_swap_buffers_with_damage(_EGLDriver *drv, _EGLDisplay *disp,
+   _EGLSurface *draw, const EGLint *rects,
+   EGLint n_rects)
+{
+   return droid_swap_buffers(drv, disp, draw);
+}
+
 static _EGLImage *
 droid_create_image_from_prime_fd(_EGLDisplay *disp, _EGLContext *ctx,
  struct ANativeWindowBuffer *buf, int fd)
@@ -876,7 +884,7 @@ static struct dri2_egl_display_vtbl droid_display_vtbl = {
.create_image = droid_create_image_khr,
.swap_interval = dri2_fallback_swap_interval,
.swap_buffers = droid_swap_buffers,
-   .swap_buffers_with_damage = dri2_fallback_swap_buffers_with_damage,
+   .swap_buffers_with_damage = droid_swap_buffers_with_damage,
.swap_buffers_region = dri2_fallback_swap_buffers_region,
.post_sub_buffer = dri2_fallback_post_sub_buffer,
.copy_buffers = dri2_fallback_copy_buffers,
-- 
2.10.1

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

Re: [Mesa-dev] [PATCH V2] i965: rewrite brw_setup_vue_interpolation()

[Jason Ekstrand]

On Thu, Oct 20, 2016 at 8:23 PM, Timothy Arceri <
timothy.arc...@collabora.com> wrote:

> Here brw_setup_vue_interpolation() is rewritten not to use the
> InterpQualifier
> array in gl_fragment_program which will allow us to remove it.
>
> This change also makes the code which is only used by gen4/5 more self
> contained
> as it now has its own gen5_fragment_program struct rather than storing the
> map
> in brw_context. This means the interpolation map will only get processed
> once
> and will get stored in the in memory cache rather than being processed
> everytime
> the fs changes.
>
> Also by calling this from the fs compile code rather than from the upload
> code
> and using the interpolation assigned there we can get rid of the
> BRW_NEW_INTERPOLATION_MAP flag.
>
> It might not seem ideal to add a gen5_fragment_program struct however by
> the end
> of this series we will have gotten rid of all the
> brw_{shader_stage}_program
> structs and replaced them with a generic brw_program struct so there will
> only
> be two program structs which is better than what we have now.
>
> V2: Don't remove BRW_NEW_INTERPOLATION_MAP from dirty_bit_map until the
> following
> patch to fix build error.
> ---
>  src/intel/blorp/blorp.c   |  6 +-
>  src/intel/vulkan/anv_pipeline.c   |  2 +-
>  src/mesa/drivers/dri/i965/brw_clip.c  | 19 ++---
>  src/mesa/drivers/dri/i965/brw_clip.h  |  7 +-
>  src/mesa/drivers/dri/i965/brw_clip_line.c |  2 +-
>  src/mesa/drivers/dri/i965/brw_clip_tri.c  |  2 +-
>  src/mesa/drivers/dri/i965/brw_clip_unfilled.c |  2 +-
>  src/mesa/drivers/dri/i965/brw_clip_util.c | 10 +--
>  src/mesa/drivers/dri/i965/brw_compiler.h  |  8 ++-
>  src/mesa/drivers/dri/i965/brw_context.h   | 45 
>  src/mesa/drivers/dri/i965/brw_fs.cpp  |  4 +-
>  src/mesa/drivers/dri/i965/brw_interpolation_map.c | 85
> +++
>  src/mesa/drivers/dri/i965/brw_nir.c   |  7 +-
>  src/mesa/drivers/dri/i965/brw_nir.h   |  3 +-
>  src/mesa/drivers/dri/i965/brw_program.c   | 10 ++-
>  src/mesa/drivers/dri/i965/brw_sf.c| 14 ++--
>  src/mesa/drivers/dri/i965/brw_sf.h|  4 +-
>  src/mesa/drivers/dri/i965/brw_sf_emit.c   | 12 ++--
>  src/mesa/drivers/dri/i965/brw_state.h |  3 -
>  src/mesa/drivers/dri/i965/brw_state_upload.c  |  5 +-
>  src/mesa/drivers/dri/i965/brw_wm.c| 18 +++--
>  src/mesa/drivers/dri/i965/brw_wm.h|  3 +-
>  22 files changed, 142 insertions(+), 129 deletions(-)
>
> diff --git a/src/intel/blorp/blorp.c b/src/intel/blorp/blorp.c
> index 5209ee2..8905cfa 100644
> --- a/src/intel/blorp/blorp.c
> +++ b/src/intel/blorp/blorp.c
> @@ -211,9 +211,9 @@ brw_blorp_compile_nir_shader(struct blorp_context
> *blorp, struct nir_shader *nir
> nir_lower_io(nir, nir_var_uniform, nir_uniform_type_size, 0);
>
> const unsigned *program =
> -  brw_compile_fs(compiler, blorp->driver_ctx, mem_ctx,
> - wm_key, _prog_data, nir,
> - NULL, -1, -1, false, use_repclear, program_size,
> NULL);
> +  brw_compile_fs(compiler, blorp->driver_ctx, mem_ctx, wm_key,
> + _prog_data, nir, NULL, -1, -1, false,
> use_repclear,
> + NULL, program_size, NULL);
>
> /* Copy the relavent bits of wm_prog_data over into the blorp prog
> data */
> prog_data->dispatch_8 = wm_prog_data.dispatch_8;
> diff --git a/src/intel/vulkan/anv_pipeline.c b/src/intel/vulkan/anv_
> pipeline.c
> index 72f0643..0aac711 100644
> --- a/src/intel/vulkan/anv_pipeline.c
> +++ b/src/intel/vulkan/anv_pipeline.c
> @@ -678,7 +678,7 @@ anv_pipeline_compile_fs(struct anv_pipeline *pipeline,
>unsigned code_size;
>const unsigned *shader_code =
>   brw_compile_fs(compiler, NULL, mem_ctx, , _data, nir,
> -NULL, -1, -1, true, false, _size, NULL);
> +NULL, -1, -1, true, false, NULL, _size,
> NULL);
>if (shader_code == NULL) {
>   ralloc_free(mem_ctx);
>   return vk_error(VK_ERROR_OUT_OF_HOST_MEMORY);
> diff --git a/src/mesa/drivers/dri/i965/brw_clip.c
> b/src/mesa/drivers/dri/i965/brw_clip.c
> index 1134fa4..06650b6 100644
> --- a/src/mesa/drivers/dri/i965/brw_clip.c
> +++ b/src/mesa/drivers/dri/i965/brw_clip.c
> @@ -68,11 +68,6 @@ static void compile_clip_prog( struct brw_context *brw,
> c.key = *key;
> c.vue_map = brw->vue_map_geom_out;
>
> -   c.has_flat_shading =
> -  brw_any_flat_varyings(>interpolation_mode);
> -   c.has_noperspective_shading =
> -  brw_any_noperspective_varyings(>interpolation_mode);
> -
> /* nr_regs is the number of registers filled by reading data from the
> VUE.
>  * This program accesses the entire VUE, so nr_regs needs to be the
> size of
>  * the VUE (measured in pairs, since two slots 

[Mesa-dev] [Bug 96737] [GLX] Xsession Log In breakage - Switch User / Switch To Greeter / VT Switch related

[bugzilla-daemon]

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

poma  changed:

   What|Removed |Added

Version|12.0|unspecified
   Assignee|mesa-dev@lists.freedesktop. |nouveau@lists.freedesktop.o
   |org |rg
Product|Mesa|xorg
  Component|GLX |Driver/nouveau
 QA Contact|mesa-dev@lists.freedesktop. |xorg-t...@lists.x.org
   |org |

-- 
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 1/3] anv: Suffix the intel_icd file with the host CPU

[Matt Turner]

On Fri, Oct 21, 2016 at 7:31 AM, Mike Lothian  wrote:
> Does this need to be target CPU rather than host?

target and host should always be the same for Mesa, as far as I
understand. See
https://gcc.gnu.org/onlinedocs/gccint/Configure-Terms.html
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] radv: allow cmask transitions without fast clear

[Bas Nieuwenhuizen]

Reviewed-by: Bas Nieuwenhuizen 

On Fri, Oct 21, 2016 at 1:36 AM, Dave Airlie  wrote:
> From: Dave Airlie 
>
> This fixes
> dEQP-VK.pipeline.multisample.sampled_image*
>
> These all render to multisampled image, and then
> sample from it, so we must transition it correctly,
> since we have a cmask and fmask this will cause
> the correct transition.
>
> Cc: "13.0" 
> Signed-off-by: Dave Airlie 
> ---
>  src/amd/vulkan/radv_cmd_buffer.c | 3 ---
>  1 file changed, 3 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_cmd_buffer.c 
> b/src/amd/vulkan/radv_cmd_buffer.c
> index 3f1a6f4..690c739 100644
> --- a/src/amd/vulkan/radv_cmd_buffer.c
> +++ b/src/amd/vulkan/radv_cmd_buffer.c
> @@ -2163,9 +2163,6 @@ static void radv_handle_cmask_image_transition(struct 
> radv_cmd_buffer *cmd_buffe
> radv_initialise_cmask(cmd_buffer, image, 0xu);
> } else if (radv_layout_has_cmask(image, src_layout) &&
>!radv_layout_has_cmask(image, dst_layout)) {
> -
> -   if (!cmd_buffer->device->allow_fast_clears)
> -   return;
> radv_fast_clear_flush_image_inplace(cmd_buffer, image);
> }
>  }
> --
> 2.5.5
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/2] vulkan/wsi/x11: fix ARGB window support

[Fredrik Höglund]

Pass the correct depth to xcb_dri3_pixmap_from_buffer_checked().
Otherwise xcb_present_pixmap() fails with a BadMatch error.

Cc: "13.0" 
---
 src/vulkan/wsi/wsi_common_x11.c | 19 +++
 1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/src/vulkan/wsi/wsi_common_x11.c b/src/vulkan/wsi/wsi_common_x11.c
index b5832c6..0128e1c 100644
--- a/src/vulkan/wsi/wsi_common_x11.c
+++ b/src/vulkan/wsi/wsi_common_x11.c
@@ -471,6 +471,7 @@ struct x11_swapchain {
xcb_connection_t *   conn;
xcb_window_t window;
xcb_gc_t gc;
+   uint32_t depth;
VkExtent2D   extent;
uint32_t image_count;
 
@@ -625,7 +626,6 @@ x11_image_init(VkDevice device_h, struct x11_swapchain 
*chain,
uint32_t row_pitch;
uint32_t offset;
uint32_t bpp = 32;
-   uint32_t depth = 24;
int fd;
uint32_t size;
 
@@ -651,7 +651,7 @@ x11_image_init(VkDevice device_h, struct x11_swapchain 
*chain,
   pCreateInfo->imageExtent.width,
   pCreateInfo->imageExtent.height,
   row_pitch,
-  depth, bpp, fd);
+  chain->depth, bpp, fd);
xcb_discard_reply(chain->conn, cookie.sequence);
 
int fence_fd = xshmfence_alloc_shm();
@@ -752,18 +752,29 @@ x11_surface_create_swapchain(VkIcdSurfaceBase 
*icd_surface,
if (chain == NULL)
   return VK_ERROR_OUT_OF_HOST_MEMORY;
 
+   xcb_connection_t *conn = x11_surface_get_connection(icd_surface);
+   xcb_window_t window = x11_surface_get_window(icd_surface);
+   xcb_get_geometry_reply_t *geometry =
+  xcb_get_geometry_reply(conn, xcb_get_geometry(conn, window), NULL);
+
+   if (geometry == NULL)
+  return VK_ERROR_SURFACE_LOST_KHR;
+
chain->base.device = device;
chain->base.destroy = x11_swapchain_destroy;
chain->base.get_images = x11_get_images;
chain->base.acquire_next_image = x11_acquire_next_image;
chain->base.queue_present = x11_queue_present;
chain->base.image_fns = image_fns;
-   chain->conn = x11_surface_get_connection(icd_surface);
-   chain->window = x11_surface_get_window(icd_surface);
+   chain->conn = conn;
+   chain->window = window;
+   chain->depth = geometry->depth;
chain->extent = pCreateInfo->imageExtent;
chain->image_count = num_images;
chain->send_sbc = 0;
 
+   free(geometry);
+
chain->event_id = xcb_generate_id(chain->conn);
xcb_present_select_input(chain->conn, chain->event_id, chain->window,
 XCB_PRESENT_EVENT_MASK_CONFIGURE_NOTIFY |
-- 
2.1.4

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

Re: [Mesa-dev] [ANNOUNCE] mesa 13.0.0-rc1

[Emil Velikov]

On 20 October 2016 at 20:46, Kai Wasserbäch  wrote:
> Hey Emil, hey Jason,
> Emil Velikov wrote on 20.10.2016 17:28:
>> On 20 October 2016 at 16:20, Jason Ekstrand  wrote:
>>> On Oct 20, 2016 8:11 AM, "Emil Velikov"  wrote:

 On 19 October 2016 at 20:31, Jason Ekstrand  wrote:
> On Wed, Oct 19, 2016 at 12:16 PM, Emil Velikov
> 
> wrote:
>>
>> On 19 October 2016 at 19:50, Kai Wasserbäch
>> 
>> wrote:
>>> Hey Emil,
>>> just curious why you did the revert
>>>
>>>
>>> ().
>>> Wouldn't distros just set --disable-vulkan-icd-full-driver-path (I
>>> know
>>> I'm
>>> doing that for Multi-Arch compatibility for my local builds)?
>>>
>> Yes they can, yet they shouldn't need to bother to begin with, since
>> the code itself is not aimed at deployment ;-)
>
>
> What code isn't aimed at deployment?
>
> Don't just go reverting commits in the release branch on your own
> authority
> with no discussion.  If that flag is causing problems for distros and
> packagers, let's hear from them and they can tell us what they need.
>
 I believe I mentioned it before - due to the high traffic on mesa-dev@
 little-to-no distro maintainers get to read upon decisions and/or cast
 their opinion. In most cases they'll just workout something locally
 and not bother (-ETIME or other) prodding upstream.

 I believe I explained it in length why the original and follow up are
 bad idea, suggested two alternative solutions and a Nack on the patch.
 Only to get all that fall though the cracks :-\

> Also, it's not in there for developers.  It's in there for people who
> want
> to do a local build and have "make install" work somewhat correctly.
 Doing `make install' to a non-default prefix falls in the
 development/testing category.

 In either case using  LD_LIBRARY_PATH is a must _regardless_ of the
 software that one's building/testing. That is unless you're using
 chroot :-)
>>>
>>> ./configure --prefix=$HOME/.local
>>> make
>>> make install
>>>
>>> Works today without LD_LIBRARY_PATH
>>>
>> "In either case using  LD_LIBRARY_PATH is a must _regardless_ of the
>> software that one's building/testing".
>>
>> I realise that the Vulkan spec does not mention that, but this is a
>> common practise that everyone should be using.
>>
>> Mildly related: I thought you/others are using VK_ICD_FILENAMES +
>> dev_icd.json. Or is that one somehow wrong/deprecated ?
>
> maybe the solution to this discussion can be to switch the default around 
> then?
> By default you get the relative (just library name), and if you set something
> like "--with-vulkan-icd-loader-path=..." you get a full path?
> That way distributions don't have to do anything and developers can set it
> easily enough.
>
Better yet, Jason got a series which generates distinct, per-cpu json
file with each one containing the full path + name of the driver.
This way as the loader iterates over the json files, it will (attempt
to) dlopen all of them and manage only the ones that work.

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

[Mesa-dev] [PATCH 2/2] vulkan/wsi/wayland: fix ARGB window support

[Fredrik Höglund]

Use an ARGB format for the DRM buffer when the compositeAlpha field
in VkSwapchainCreateInfoKHR is set to
VK_COMPOSITE_ALPHA_PRE_MULTIPLIED_BIT_KHR.

Cc: "13.0" 
---
 src/vulkan/wsi/wsi_common_wayland.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/src/vulkan/wsi/wsi_common_wayland.c 
b/src/vulkan/wsi/wsi_common_wayland.c
index fc13bde..196ee28 100644
--- a/src/vulkan/wsi/wsi_common_wayland.c
+++ b/src/vulkan/wsi/wsi_common_wayland.c
@@ -702,6 +702,9 @@ wsi_wl_surface_create_swapchain(VkIcdSurfaceBase 
*icd_surface,
if (chain == NULL)
   return VK_ERROR_OUT_OF_HOST_MEMORY;
 
+   bool alpha = pCreateInfo->compositeAlpha ==
+  VK_COMPOSITE_ALPHA_PRE_MULTIPLIED_BIT_KHR;
+
chain->base.device = device;
chain->base.destroy = wsi_wl_swapchain_destroy;
chain->base.get_images = wsi_wl_swapchain_get_images;
@@ -711,7 +714,7 @@ wsi_wl_surface_create_swapchain(VkIcdSurfaceBase 
*icd_surface,
chain->surface = surface->surface;
chain->extent = pCreateInfo->imageExtent;
chain->vk_format = pCreateInfo->imageFormat;
-   chain->drm_format = wl_drm_format_for_vk_format(chain->vk_format, false);
+   chain->drm_format = wl_drm_format_for_vk_format(chain->vk_format, alpha);
 
chain->present_mode = pCreateInfo->presentMode;
chain->fifo_ready = true;
-- 
2.1.4

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

[Mesa-dev] [Bug 98308] llvmpipe crashes with glxgears (LTO related)

[bugzilla-daemon]

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

--- Comment #11 from Maciej Cencora  ---
I thought so. FWIW I cannot reproduce the crash on gcc 6.2.

Could you re-compile mesa with -fsanitize=address and -fsanitize=undefined in
C/CXX_FLAGS, and paste the output from glxgears run?

-- 
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/ir: remove outdated comment about SHLADD

[Ilia Mirkin]

Reviewed-by: Ilia Mirkin 

On Fri, Oct 21, 2016 at 12:35 PM, Samuel Pitoiset
 wrote:
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp | 1 -
>  src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp  | 1 -
>  2 files changed, 2 deletions(-)
>
> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp 
> b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
> index ce20ed3..7af31d0 100644
> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
> @@ -722,7 +722,6 @@ CodeEmitterGK110::emitUADD(const Instruction *i)
> }
>  }
>
> -// TODO: shl-add
>  void
>  CodeEmitterGK110::emitIMAD(const Instruction *i)
>  {
> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp 
> b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp
> index 0be9f7a..94a0ed0 100644
> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp
> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp
> @@ -732,7 +732,6 @@ CodeEmitterNVC0::emitUADD(const Instruction *i)
> }
>  }
>
> -// TODO: shl-add
>  void
>  CodeEmitterNVC0::emitIMAD(const Instruction *i)
>  {
> --
> 2.10.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/3] gallium/hud: protect against and initialization race

[Eduardo Lima Mitev]

On 10/20/2016 08:45 PM, Steven Toth wrote:
> In the event that multiple threads attempt to install a graph
> concurrently, protect the shared list.
> 
> Signed-off-by: Steven Toth 
> ---
>  src/gallium/auxiliary/hud/hud_cpufreq.c  | 12 ++--
>  src/gallium/auxiliary/hud/hud_diskstat.c | 13 +++--
>  src/gallium/auxiliary/hud/hud_nic.c  | 12 ++--
>  src/gallium/auxiliary/hud/hud_sensors_temp.c | 12 ++--
>  4 files changed, 41 insertions(+), 8 deletions(-)
> 
> diff --git a/src/gallium/auxiliary/hud/hud_cpufreq.c 
> b/src/gallium/auxiliary/hud/hud_cpufreq.c
> index e66c3e4..19a6f08 100644
> --- a/src/gallium/auxiliary/hud/hud_cpufreq.c
> +++ b/src/gallium/auxiliary/hud/hud_cpufreq.c
> @@ -36,6 +36,7 @@
>  #include "hud/hud_private.h"
>  #include "util/list.h"
>  #include "os/os_time.h"
> +#include "os/os_thread.h"
>  #include "util/u_memory.h"
>  #include 
>  #include 
> @@ -61,6 +62,7 @@ struct cpufreq_info
>  
>  static int gcpufreq_count = 0;
>  static struct list_head gcpufreq_list;
> +pipe_static_mutex(gcpufreq_mutex);
>  
>  static struct cpufreq_info *
>  find_cfi_by_index(int cpu_index, int mode)
> @@ -186,16 +188,21 @@ hud_get_num_cpufreq(bool displayhelp)
> int cpu_index;
>  
> /* Return the number of CPU metrics we support. */
> -   if (gcpufreq_count)
> +   pipe_mutex_lock(gcpufreq_mutex);
> +   if (gcpufreq_count) {
> +  pipe_mutex_unlock(gcpufreq_mutex);
>return gcpufreq_count;
> +   }


Notice that this won't return the correct value. The value of
'gcpufreq_count' might have changed to zero between the unlock and the
return. Maybe what you want is to save the value in a temporary variable
inside the protected region, then return that temporary. Something like:

int tmp_count;
pipe_mutex_lock(gcpufreq_mutex);
if (gcpufreq_count) {
   tmp_count = gcpufreq_count;
   pipe_mutex_unlock(gcpufreq_mutex);
   return tmp_count;
}

Same comment applies to several other similar chunks in this patch.

>  
> /* Scan /sys/devices.../cpu, for every object type we support, create
>  * and persist an object to represent its different metrics.
>  */
> list_inithead(_list);
> DIR *dir = opendir("/sys/devices/system/cpu");
> -   if (!dir)
> +   if (!dir) {
> +  pipe_mutex_unlock(gcpufreq_mutex);
>return 0;
> +   }
>  
> while ((dp = readdir(dir)) != NULL) {
>  
> @@ -239,6 +246,7 @@ hud_get_num_cpufreq(bool displayhelp)
>}
> }
>  
> +   pipe_mutex_unlock(gcpufreq_mutex);
> return gcpufreq_count;
>  }
>  
> diff --git a/src/gallium/auxiliary/hud/hud_diskstat.c 
> b/src/gallium/auxiliary/hud/hud_diskstat.c
> index 5fada1f..f1cc2bb 100644
> --- a/src/gallium/auxiliary/hud/hud_diskstat.c
> +++ b/src/gallium/auxiliary/hud/hud_diskstat.c
> @@ -35,6 +35,7 @@
>  #include "hud/hud_private.h"
>  #include "util/list.h"
>  #include "os/os_time.h"
> +#include "os/os_thread.h"
>  #include "util/u_memory.h"
>  #include 
>  #include 
> @@ -81,6 +82,7 @@ struct diskstat_info
>   */
>  static int gdiskstat_count = 0;
>  static struct list_head gdiskstat_list;
> +pipe_static_mutex(gdiskstat_mutex);
>  
>  static struct diskstat_info *
>  find_dsi_by_name(const char *n, int mode)
> @@ -244,16 +246,21 @@ hud_get_num_disks(bool displayhelp)
> char name[64];
>  
> /* Return the number of block devices and partitions. */
> -   if (gdiskstat_count)
> +   pipe_mutex_lock(gdiskstat_mutex);
> +   if (gdiskstat_count) {
> +  pipe_mutex_unlock(gdiskstat_mutex);
>return gdiskstat_count;
> +   }
>  
> /* Scan /sys/block, for every object type we support, create and
>  * persist an object to represent its different statistics.
>  */
> list_inithead(_list);
> DIR *dir = opendir("/sys/block/");
> -   if (!dir)
> +   if (!dir) {
> +  pipe_mutex_unlock(gdiskstat_mutex);
>return 0;
> +   }
>  
> while ((dp = readdir(dir)) != NULL) {
>  
> @@ -278,6 +285,7 @@ hud_get_num_disks(bool displayhelp)
>struct dirent *dpart;
>DIR *pdir = opendir(basename);
>if (!pdir) {
> + pipe_mutex_unlock(gdiskstat_mutex);
>   close(dir);
>   return 0;
>}
> @@ -312,6 +320,7 @@ hud_get_num_disks(bool displayhelp)
>   puts(line);
>}
> }
> +   pipe_mutex_unlock(gdiskstat_mutex);
>  
> return gdiskstat_count;
>  }
> diff --git a/src/gallium/auxiliary/hud/hud_nic.c 
> b/src/gallium/auxiliary/hud/hud_nic.c
> index 2795c93..f9935de 100644
> --- a/src/gallium/auxiliary/hud/hud_nic.c
> +++ b/src/gallium/auxiliary/hud/hud_nic.c
> @@ -35,6 +35,7 @@
>  #include "hud/hud_private.h"
>  #include "util/list.h"
>  #include "os/os_time.h"
> +#include "os/os_thread.h"
>  #include "util/u_memory.h"
>  #include 
>  #include 
> @@ -66,6 +67,7 @@ struct nic_info
>   */
>  static int gnic_count = 0;
>  static struct list_head gnic_list;
> +pipe_static_mutex(gnic_mutex);
>  
>  static struct nic_info *
>  

[Mesa-dev] [PATCH] nvc0/ir: remove outdated comment about SHLADD

[Samuel Pitoiset]

Signed-off-by: Samuel Pitoiset 
---
 src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp | 1 -
 src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp  | 1 -
 2 files changed, 2 deletions(-)

diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
index ce20ed3..7af31d0 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
@@ -722,7 +722,6 @@ CodeEmitterGK110::emitUADD(const Instruction *i)
}
 }
 
-// TODO: shl-add
 void
 CodeEmitterGK110::emitIMAD(const Instruction *i)
 {
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp
index 0be9f7a..94a0ed0 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp
@@ -732,7 +732,6 @@ CodeEmitterNVC0::emitUADD(const Instruction *i)
}
 }
 
-// TODO: shl-add
 void
 CodeEmitterNVC0::emitIMAD(const Instruction *i)
 {
-- 
2.10.0

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

Re: [Mesa-dev] [PATCH 2/3] gallium/hud: fix a previously allocated handle.

[Eduardo Lima Mitev]

On 10/20/2016 08:45 PM, Steven Toth wrote:
> We're missing the closedir() to the matching opendir().
> 

What about changing the commit title to: "gallium/hud: close a
previously opened handle"?

Either way:

Reviewed-by: Eduardo Lima Mitev 

> Signed-off-by: Steven Toth 
> ---
>  src/gallium/auxiliary/hud/hud_cpufreq.c  | 1 +
>  src/gallium/auxiliary/hud/hud_diskstat.c | 5 -
>  src/gallium/auxiliary/hud/hud_nic.c  | 1 +
>  3 files changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/src/gallium/auxiliary/hud/hud_cpufreq.c 
> b/src/gallium/auxiliary/hud/hud_cpufreq.c
> index bfc748b..e66c3e4 100644
> --- a/src/gallium/auxiliary/hud/hud_cpufreq.c
> +++ b/src/gallium/auxiliary/hud/hud_cpufreq.c
> @@ -225,6 +225,7 @@ hud_get_num_cpufreq(bool displayhelp)
>snprintf(fn, sizeof(fn), "%s/cpufreq/scaling_max_freq", basename);
>add_object(dp->d_name, fn, CPUFREQ_MAXIMUM, cpu_index);
> }
> +   closedir(dir);
>  
> if (displayhelp) {
>list_for_each_entry(struct cpufreq_info, cfi, _list, list) {
> diff --git a/src/gallium/auxiliary/hud/hud_diskstat.c 
> b/src/gallium/auxiliary/hud/hud_diskstat.c
> index 7d4f500..5fada1f 100644
> --- a/src/gallium/auxiliary/hud/hud_diskstat.c
> +++ b/src/gallium/auxiliary/hud/hud_diskstat.c
> @@ -277,8 +277,10 @@ hud_get_num_disks(bool displayhelp)
>/* Add any partitions */
>struct dirent *dpart;
>DIR *pdir = opendir(basename);
> -  if (!pdir)
> +  if (!pdir) {
> + close(dir);
>   return 0;
> +  }
>  
>while ((dpart = readdir(pdir)) != NULL) {
>   /* Avoid 'lo' and '..' and '.' */
> @@ -298,6 +300,7 @@ hud_get_num_disks(bool displayhelp)
>   add_object_part(basename, dpart->d_name, DISKSTAT_WR);
>}
> }
> +   closedir(dir);
>  
> if (displayhelp) {
>list_for_each_entry(struct diskstat_info, dsi, _list, list) {
> diff --git a/src/gallium/auxiliary/hud/hud_nic.c 
> b/src/gallium/auxiliary/hud/hud_nic.c
> index 719dd04..2795c93 100644
> --- a/src/gallium/auxiliary/hud/hud_nic.c
> +++ b/src/gallium/auxiliary/hud/hud_nic.c
> @@ -399,6 +399,7 @@ hud_get_num_nics(bool displayhelp)
>}
>  
> }
> +   closedir(dir);
>  
> list_for_each_entry(struct nic_info, nic, _list, list) {
>char line[64];
> 

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

Re: [Mesa-dev] [PATCH 1/3] gallium/hud: fix a problem where objects are free'd while in use.

[Eduardo Lima Mitev]

Didn't test it myself, but looks good:

Reviewed-by: Eduardo Lima Mitev 

On 10/20/2016 08:45 PM, Steven Toth wrote:
> Instead of trying to maintain a reference counted list of valid HUD
> objects, and freeing them accordingly, creating race conditions
> between unanticipated multiple threads, simply accept they're
> allocated once and never released until the process terminates.
> 
> They're a shared resource between multiple threads, so accept
> they're always available for use.
> 
> Signed-off-by: Steven Toth 
> ---
>  src/gallium/auxiliary/hud/hud_cpufreq.c  | 13 -
>  src/gallium/auxiliary/hud/hud_diskstat.c | 13 -
>  src/gallium/auxiliary/hud/hud_nic.c  | 13 -
>  src/gallium/auxiliary/hud/hud_sensors_temp.c | 16 
>  4 files changed, 55 deletions(-)
> 
> diff --git a/src/gallium/auxiliary/hud/hud_cpufreq.c 
> b/src/gallium/auxiliary/hud/hud_cpufreq.c
> index 4501bbb..bfc748b 100644
> --- a/src/gallium/auxiliary/hud/hud_cpufreq.c
> +++ b/src/gallium/auxiliary/hud/hud_cpufreq.c
> @@ -112,14 +112,6 @@ query_cfi_load(struct hud_graph *gr)
> }
>  }
>  
> -static void
> -free_query_data(void *p)
> -{
> -   struct cpufreq_info *cfi = (struct cpufreq_info *)p;
> -   list_del(>list);
> -   FREE(cfi);
> -}
> -
>  /**
>* Create and initialize a new object for a specific CPU.
>* \param  pane  parent context.
> @@ -162,11 +154,6 @@ hud_cpufreq_graph_install(struct hud_pane *pane, int 
> cpu_index,
> gr->query_data = cfi;
> gr->query_new_value = query_cfi_load;
>  
> -   /* Don't use free() as our callback as that messes up Gallium's
> -* memory debugger.  Use simple free_query_data() wrapper.
> -*/
> -   gr->free_query_data = free_query_data;
> -
> hud_pane_add_graph(pane, gr);
> hud_pane_set_max_value(pane, 300 /* 3 GHz */);
>  }
> diff --git a/src/gallium/auxiliary/hud/hud_diskstat.c 
> b/src/gallium/auxiliary/hud/hud_diskstat.c
> index b248baf..7d4f500 100644
> --- a/src/gallium/auxiliary/hud/hud_diskstat.c
> +++ b/src/gallium/auxiliary/hud/hud_diskstat.c
> @@ -162,14 +162,6 @@ query_dsi_load(struct hud_graph *gr)
> }
>  }
>  
> -static void
> -free_query_data(void *p)
> -{
> -   struct diskstat_info *nic = (struct diskstat_info *) p;
> -   list_del(>list);
> -   FREE(nic);
> -}
> -
>  /**
>* Create and initialize a new object for a specific block I/O device.
>* \param  pane  parent context.
> @@ -208,11 +200,6 @@ hud_diskstat_graph_install(struct hud_pane *pane, const 
> char *dev_name,
> gr->query_data = dsi;
> gr->query_new_value = query_dsi_load;
>  
> -   /* Don't use free() as our callback as that messes up Gallium's
> -* memory debugger.  Use simple free_query_data() wrapper.
> -*/
> -   gr->free_query_data = free_query_data;
> -
> hud_pane_add_graph(pane, gr);
> hud_pane_set_max_value(pane, 100);
>  }
> diff --git a/src/gallium/auxiliary/hud/hud_nic.c 
> b/src/gallium/auxiliary/hud/hud_nic.c
> index fb6b8c0..719dd04 100644
> --- a/src/gallium/auxiliary/hud/hud_nic.c
> +++ b/src/gallium/auxiliary/hud/hud_nic.c
> @@ -234,14 +234,6 @@ query_nic_load(struct hud_graph *gr)
> }
>  }
>  
> -static void
> -free_query_data(void *p)
> -{
> -   struct nic_info *nic = (struct nic_info *) p;
> -   list_del(>list);
> -   FREE(nic);
> -}
> -
>  /**
>* Create and initialize a new object for a specific network interface dev.
>* \param  pane  parent context.
> @@ -284,11 +276,6 @@ hud_nic_graph_install(struct hud_pane *pane, const char 
> *nic_name,
> gr->query_data = nic;
> gr->query_new_value = query_nic_load;
>  
> -   /* Don't use free() as our callback as that messes up Gallium's
> -* memory debugger.  Use simple free_query_data() wrapper.
> -*/
> -   gr->free_query_data = free_query_data;
> -
> hud_pane_add_graph(pane, gr);
> hud_pane_set_max_value(pane, 100);
>  }
> diff --git a/src/gallium/auxiliary/hud/hud_sensors_temp.c 
> b/src/gallium/auxiliary/hud/hud_sensors_temp.c
> index e41b847..4a8a4fc 100644
> --- a/src/gallium/auxiliary/hud/hud_sensors_temp.c
> +++ b/src/gallium/auxiliary/hud/hud_sensors_temp.c
> @@ -189,17 +189,6 @@ query_sti_load(struct hud_graph *gr)
> }
>  }
>  
> -static void
> -free_query_data(void *p)
> -{
> -   struct sensors_temp_info *sti = (struct sensors_temp_info *) p;
> -   list_del(>list);
> -   if (sti->chip)
> -  sensors_free_chip_name(sti->chip);
> -   FREE(sti);
> -   sensors_cleanup();
> -}
> -
>  /**
>* Create and initialize a new object for a specific sensor interface dev.
>* \param  pane  parent context.
> @@ -237,11 +226,6 @@ hud_sensors_temp_graph_install(struct hud_pane *pane, 
> const char *dev_name,
> gr->query_data = sti;
> gr->query_new_value = query_sti_load;
>  
> -   /* Don't use free() as our callback as that messes up Gallium's
> -* memory debugger.  Use simple free_query_data() wrapper.
> -*/
> -   gr->free_query_data 

Re: [Mesa-dev] [PATCH 1/3] anv: Suffix the intel_icd file with the host CPU

[Jason Ekstrand]

On Fri, Oct 21, 2016 at 9:11 AM, Emil Velikov 
wrote:

> On 21 October 2016 at 16:58, Jason Ekstrand  wrote:
>
> > Will do.  Do I need to add intel_icd.@host_cpu@.json to EXTRA_DIST?
> >
> No need, since new file will/should be regenerated as one runs configure.
>
> >>
> >> With those the series is:
> >> Reviewed-by: Emil Velikov 
> >
> >
> > Thanks!  Sorry this has taken so long to get right.
> Np. Thanks for coming up with this neat solution.
>
> Fwiw I am leaning that we'd want this (I can backport it) in 13.0, so
> add the mesa-stable@ tag/let me know if you agree.


I 100% agree.  I'll add the CC tag before I push.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] anv: Suffix the intel_icd file with the host CPU

[Emil Velikov]

On 21 October 2016 at 16:58, Jason Ekstrand  wrote:

> Will do.  Do I need to add intel_icd.@host_cpu@.json to EXTRA_DIST?
>
No need, since new file will/should be regenerated as one runs configure.

>>
>> With those the series is:
>> Reviewed-by: Emil Velikov 
>
>
> Thanks!  Sorry this has taken so long to get right.
Np. Thanks for coming up with this neat solution.

Fwiw I am leaning that we'd want this (I can backport it) in 13.0, so
add the mesa-stable@ tag/let me know if you agree.

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

[Mesa-dev] [Bug 98308] llvmpipe crashes with glxgears (LTO related)

[bugzilla-daemon]

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

--- Comment #10 from Marc Dietrich  ---
this only fixes the (unrelated) warning in comment 5, but not the crash in
llvmpipe reported in this bug.

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

Re: [Mesa-dev] [PATCH 1/3] anv: Suffix the intel_icd file with the host CPU

[Jason Ekstrand]

On Fri, Oct 21, 2016 at 7:31 AM, Mike Lothian  wrote:

> Does this need to be target CPU rather than host?
>

No, we want host.  See also

https://www.gnu.org/software/autoconf/manual/autoconf-2.65/html_node/Specifying-Target-Triplets.html


> On Fri, 21 Oct 2016 at 14:53 Emil Velikov 
> wrote:
>
>> Thank you very very very much for this, Jason !
>>
>> On 21 October 2016 at 01:07, Jason Ekstrand  wrote:
>>
>> > drivers because they may put it in /usr/local or $HOME/.local or
>> some
>> > other
>> Drop the "/usr/local or " part. The dynamic linker looks in there, by
>> default.
>>
>> > more exotic location.  In this case, you can't use an ICD json file
>> with
>> > just a library name because it doesn't know where to find it; you
>> also
>> > have
>> s/; you also have/, so you have/
>>
>> Please update .gitignore and drop the intel_icd.json reference from
>> EXTRA_DIST.
>>
>> With those the series is:
>> Reviewed-by: Emil Velikov 
>>
>> Thanks again,
>> Emil
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] anv: Suffix the intel_icd file with the host CPU

[Jason Ekstrand]

On Fri, Oct 21, 2016 at 6:52 AM, Emil Velikov 
wrote:

> Thank you very very very much for this, Jason !
>

If you're happy and I'm happy, I'd say we've got ourselves a solution!


> On 21 October 2016 at 01:07, Jason Ekstrand  wrote:
>
> > drivers because they may put it in /usr/local or $HOME/.local or some
> > other
> Drop the "/usr/local or " part. The dynamic linker looks in there, by
> default.
>

Sure.


> > more exotic location.  In this case, you can't use an ICD json file
> with
> > just a library name because it doesn't know where to find it; you
> also
> > have
> s/; you also have/, so you have/
>
> Please update .gitignore and drop the intel_icd.json reference from
> EXTRA_DIST.
>

Will do.  Do I need to add intel_icd.@host_cpu@.json to EXTRA_DIST?


> With those the series is:
> Reviewed-by: Emil Velikov 
>

Thanks!  Sorry this has taken so long to get right.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] nvc0/ir: fix emission of SHLADD with NEG modifiers

[Ilia Mirkin]

Acked-by: Ilia Mirkin 

Mind double-checking the one in emitIMAD?

On Fri, Oct 21, 2016 at 11:43 AM, Samuel Pitoiset
 wrote:
> This affects GF100:GK110 chipsets, but not GM107+ where the
> logic is a bit different. The emitters tried to emit sub
> instead of subr when src0 has a NEG modifier.
>
> This fixes the following piglit tests glsl-fs-loop-nested
> and glsl-vs-loop-nested.
>
> Signed-off-by: Samuel Pitoiset 
> Cc: "13.0" 
> ---
>  src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp | 2 +-
>  src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp  | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp 
> b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
> index ce20ed3..dbba4b1 100644
> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
> @@ -760,7 +760,7 @@ CodeEmitterGK110::emitISAD(const Instruction *i)
>  void
>  CodeEmitterGK110::emitSHLADD(const Instruction *i)
>  {
> -   uint8_t addOp = (i->src(2).mod.neg() << 1) | i->src(0).mod.neg();
> +   uint8_t addOp = (i->src(0).mod.neg() << 1) | i->src(2).mod.neg();
> const ImmediateValue *imm = i->src(1).get()->asImm();
> assert(imm);
>
> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp 
> b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp
> index 0be9f7a..3d3e1cb 100644
> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp
> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp
> @@ -762,7 +762,7 @@ CodeEmitterNVC0::emitIMAD(const Instruction *i)
>  void
>  CodeEmitterNVC0::emitSHLADD(const Instruction *i)
>  {
> -   uint8_t addOp = (i->src(2).mod.neg() << 1) | i->src(0).mod.neg();
> +   uint8_t addOp = (i->src(0).mod.neg() << 1) | i->src(2).mod.neg();
> const ImmediateValue *imm = i->src(1).get()->asImm();
> assert(imm);
>
> --
> 2.10.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] nvc0/ir: fix emission of SHLADD with NEG modifiers

[Samuel Pitoiset]

This affects GF100:GK110 chipsets, but not GM107+ where the
logic is a bit different. The emitters tried to emit sub
instead of subr when src0 has a NEG modifier.

This fixes the following piglit tests glsl-fs-loop-nested
and glsl-vs-loop-nested.

Signed-off-by: Samuel Pitoiset 
Cc: "13.0" 
---
 src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp | 2 +-
 src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
index ce20ed3..dbba4b1 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
@@ -760,7 +760,7 @@ CodeEmitterGK110::emitISAD(const Instruction *i)
 void
 CodeEmitterGK110::emitSHLADD(const Instruction *i)
 {
-   uint8_t addOp = (i->src(2).mod.neg() << 1) | i->src(0).mod.neg();
+   uint8_t addOp = (i->src(0).mod.neg() << 1) | i->src(2).mod.neg();
const ImmediateValue *imm = i->src(1).get()->asImm();
assert(imm);
 
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp
index 0be9f7a..3d3e1cb 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp
@@ -762,7 +762,7 @@ CodeEmitterNVC0::emitIMAD(const Instruction *i)
 void
 CodeEmitterNVC0::emitSHLADD(const Instruction *i)
 {
-   uint8_t addOp = (i->src(2).mod.neg() << 1) | i->src(0).mod.neg();
+   uint8_t addOp = (i->src(0).mod.neg() << 1) | i->src(2).mod.neg();
const ImmediateValue *imm = i->src(1).get()->asImm();
assert(imm);
 
-- 
2.10.0

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

Re: [Mesa-dev] [PATCH 00/15] GLSL memory allocation rework for faster compilation

[Tapani Pälli]

On 10/21/2016 04:57 PM, Eero Tamminen wrote:

Hi,

On 21.10.2016 14:07, Tapani Pälli wrote:

I did run some valgrind comparisons with gfxbench4, your branch against
Mesa master. I did not spot anything obvious related to ralloc.

On i965 there's a huge load of invalid writes's and read's in general
but this happens on master as well so maybe these are not 'valid hits'.


I don't see those with master from 3 weeks ago.  Did you remember to 
compile libdrm with Valgrind headers present, so that buffer allocs 
are annotated for Valgrind?




Yeah, I will need to double-check that. I'll try again on Monday and we 
can investigate the results together, I believe some were for Mesa core 
as well related to compressed texture handling.





There's also some leaks both with master and your branch but your branch
has less, so it seems to fix some things.



- Eero


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



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

Re: [Mesa-dev] [PATCH] st/mesa: use u_bit_scan64() on 64-bit CPUs

[Marek Olšák]

On Fri, Oct 21, 2016 at 4:41 PM, Roland Scheidegger  wrote:
> Am 21.10.2016 um 15:17 schrieb Marek Olšák:
>> On Oct 21, 2016 12:06 PM, "Jan Ziak" <0xe2.0x9a.0...@gmail.com
>> > wrote:
>>>
>>> On Fri, Oct 21, 2016 at 12:04 PM, Marek Olšák > > wrote:
>>> > This won't make it faster.
>>>
>>> Why?
>>
>> It's obviously a micro optimization that adds more stuff than it
>> benefits the runtime. I don't think that real performance improvements
>> will be so simple and obvious.
>>
>> Marek
>>
>
> Still, shouldn't it be faster though, even if just very very minimally so?

If at least one of the atoms gets updated, the overhead of the update
function will be so high that the saved couple of instructions in the
while loop will be unmeasurable.

Yes, st_validate_state is pretty huge in profilers. However, the
problem is not only in st_validate_state and the atoms, but also in
most of mesa/main that sets the _NEW_* flags, which in turn invokes
more state updates than needed. That's a big problem of mesa/main and
quite a complex one to solve. It's also partly a Gallium design
problem, because OpenGL doesn't have per-stage shader resource slots
like DX11 has, but instead all texture etc. slots are global, e.g.
texture unit 0 is slot 0 in all shader stages.

This is going into some deep design issues and even if we had a
perfect design, how much performance could we get with that? Isn't a
threaded GL dispatch 100x easier than rewriting Mesa?

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

[Mesa-dev] [Bug 98308] llvmpipe crashes with glxgears (LTO related)

[bugzilla-daemon]

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

--- Comment #9 from Maciej Cencora  ---
Created attachment 127452
  --> https://bugs.freedesktop.org/attachment.cgi?id=127452=edit
Proposed patch

Try this patch. It silences the warning for me on gcc-6.2, but I don't know if
that was actually the problem triggering the crash.

-- 
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 v2] egl: add check that eglCreateContext gets a valid config

[Eric Engestrom]

On Thursday, 2016-10-20 19:46:19 +0100, Emil Velikov wrote:
> On 20 October 2016 at 18:20, Tapani Pälli  wrote:
> > Fixes following dEQP test:
> >
> >dEQP-EGL.functional.negative_api.create_context
> >
> > v2: don't break EGL_KHR_no_config_context (Eric Engestrom)
> >
> > Signed-off-by: Tapani Pälli 
> > ---
> >
> > Eric, the check you proposed does not work as KHR_no_config_context
> > is always there in extension list with Mesa EGL. So, solution is to
> > validate any given config that's not EGL_NO_CONFIG_KHR (0).
> >
> Strictly speaking KHR_no_config_context is false for the haiku EGL
> driver, no idea how well though :-)
> 
> >  src/egl/main/eglapi.c | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/src/egl/main/eglapi.c b/src/egl/main/eglapi.c
> > index d8bd76d..ca19274 100644
> > --- a/src/egl/main/eglapi.c
> > +++ b/src/egl/main/eglapi.c
> > @@ -734,6 +734,9 @@ eglCreateContext(EGLDisplay dpy, EGLConfig config, 
> > EGLContext share_list,
> >
> > _EGL_CHECK_DISPLAY(disp, EGL_NO_CONTEXT, drv);
> >
> > +   if (config != EGL_NO_CONFIG_KHR)
> > +  _EGL_CHECK_CONFIG(disp, conf, EGL_NO_CONTEXT, drv);
> > +
> > if (!config && !disp->Extensions.KHR_no_config_context)
> >RETURN_EGL_ERROR(disp, EGL_BAD_CONFIG, EGL_NO_CONTEXT);
> >
> config != EGL_NO_CONFIG_KHR vs !config reads a bit odd - can we go for
> one or the other ?

Couldn't the second `if` be turned into an `else if(!disp->Ext...`?
I think that'd be clearer. (That said, it can be a separate patch.)

Reviewed-by: Eric Engestrom 

> Regardless of which one you'd go for:
> 
> Cc: "12.0 13.0" 
> Reviewed-by: Emil Velikov 
> 
> Thanks
> Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] st/mesa: use u_bit_scan64() on 64-bit CPUs

[Roland Scheidegger]

Am 21.10.2016 um 15:17 schrieb Marek Olšák:
> On Oct 21, 2016 12:06 PM, "Jan Ziak" <0xe2.0x9a.0...@gmail.com
> > wrote:
>>
>> On Fri, Oct 21, 2016 at 12:04 PM, Marek Olšák  > wrote:
>> > This won't make it faster.
>>
>> Why?
> 
> It's obviously a micro optimization that adds more stuff than it
> benefits the runtime. I don't think that real performance improvements
> will be so simple and obvious.
> 
> Marek
> 

Still, shouldn't it be faster though, even if just very very minimally so?

Roland


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

Re: [Mesa-dev] [PATCH 1/3] anv: Suffix the intel_icd file with the host CPU

[Mike Lothian]

Does this need to be target CPU rather than host?

On Fri, 21 Oct 2016 at 14:53 Emil Velikov  wrote:

> Thank you very very very much for this, Jason !
>
> On 21 October 2016 at 01:07, Jason Ekstrand  wrote:
>
> > drivers because they may put it in /usr/local or $HOME/.local or some
> > other
> Drop the "/usr/local or " part. The dynamic linker looks in there, by
> default.
>
> > more exotic location.  In this case, you can't use an ICD json file
> with
> > just a library name because it doesn't know where to find it; you
> also
> > have
> s/; you also have/, so you have/
>
> Please update .gitignore and drop the intel_icd.json reference from
> EXTRA_DIST.
>
> With those the series is:
> Reviewed-by: Emil Velikov 
>
> Thanks again,
> Emil
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/5] nvc0/ir: use levelZero flag when the lod is set to 0

[Ilia Mirkin]

Yeah, it might actually need to be arg+1, -1. I didn't test this patch
too thoroughly...

On Fri, Oct 21, 2016 at 9:53 AM, Samuel Pitoiset
 wrote:
> This patch breaks a bunch of piglit tests, see a short list below:
>
> bin/arb_texture_barrier-blending-in-shader 512 42 1 128 7 -auto -fbo
> bin/arb_texture_buffer_object-formats vs core -auto -fbo
> bin/texelFetch 140 vs sampler2DRect -auto -fbo
> bin/mesa_pack_invert-readpixels -auto -fbo
> ...
>
> Around 150 regressions.
>
> I suspect the moveSources() to be wrong just because texture arguments are
> crazy. :-)
>
> On 10/21/2016 08:30 AM, Ilia Mirkin wrote:
>>
>> Signed-off-by: Ilia Mirkin 
>> ---
>>  src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp | 9
>> +
>>  1 file changed, 9 insertions(+)
>>
>> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
>> b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
>> index 68f2b15..4181422 100644
>> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
>> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
>> @@ -662,6 +662,15 @@ NVC0LoweringPass::handleTEX(TexInstruction *i)
>>}
>> }
>>
>> +   ImmediateValue lod;
>> +   if (!i->tex.target.isMS() && (i->op == OP_TXL || i->op == OP_TXF) &&
>> +   i->src(arg).getImmediate(lod) && lod.isInteger(0)) {
>> +  if (i->op == OP_TXL)
>> + i->op = OP_TEX;
>> +  i->tex.levelZero = true;
>> +  i->moveSources(arg, -1);
>> +   }
>> +
>> // Arguments to the TEX instruction are a little insane. Even though
>> the
>> // encoding is identical between SM20 and SM30, the arguments mean
>> // different things between Fermi and Kepler+. A lot of arguments are
>>
>
> --
> -Samuel
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 00/15] GLSL memory allocation rework for faster compilation

[Eero Tamminen]

Hi,

On 21.10.2016 14:07, Tapani Pälli wrote:

I did run some valgrind comparisons with gfxbench4, your branch against
Mesa master. I did not spot anything obvious related to ralloc.

On i965 there's a huge load of invalid writes's and read's in general
but this happens on master as well so maybe these are not 'valid hits'.


I don't see those with master from 3 weeks ago.  Did you remember to 
compile libdrm with Valgrind headers present, so that buffer allocs are 
annotated for Valgrind?




There's also some leaks both with master and your branch but your branch
has less, so it seems to fix some things.



- Eero


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

Re: [Mesa-dev] [PATCH 2/5] nvc0/ir: use levelZero flag when the lod is set to 0

[Samuel Pitoiset]

This patch breaks a bunch of piglit tests, see a short list below:

bin/arb_texture_barrier-blending-in-shader 512 42 1 128 7 -auto -fbo
bin/arb_texture_buffer_object-formats vs core -auto -fbo
bin/texelFetch 140 vs sampler2DRect -auto -fbo
bin/mesa_pack_invert-readpixels -auto -fbo
...

Around 150 regressions.

I suspect the moveSources() to be wrong just because texture arguments 
are crazy. :-)


On 10/21/2016 08:30 AM, Ilia Mirkin wrote:

Signed-off-by: Ilia Mirkin 
---
 src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp | 9 +
 1 file changed, 9 insertions(+)

diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
index 68f2b15..4181422 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
@@ -662,6 +662,15 @@ NVC0LoweringPass::handleTEX(TexInstruction *i)
   }
}

+   ImmediateValue lod;
+   if (!i->tex.target.isMS() && (i->op == OP_TXL || i->op == OP_TXF) &&
+   i->src(arg).getImmediate(lod) && lod.isInteger(0)) {
+  if (i->op == OP_TXL)
+ i->op = OP_TEX;
+  i->tex.levelZero = true;
+  i->moveSources(arg, -1);
+   }
+
// Arguments to the TEX instruction are a little insane. Even though the
// encoding is identical between SM20 and SM30, the arguments mean
// different things between Fermi and Kepler+. A lot of arguments are



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

Re: [Mesa-dev] [PATCH 1/3] anv: Suffix the intel_icd file with the host CPU

[Emil Velikov]

Thank you very very very much for this, Jason !

On 21 October 2016 at 01:07, Jason Ekstrand  wrote:

> drivers because they may put it in /usr/local or $HOME/.local or some
> other
Drop the "/usr/local or " part. The dynamic linker looks in there, by default.

> more exotic location.  In this case, you can't use an ICD json file with
> just a library name because it doesn't know where to find it; you also
> have
s/; you also have/, so you have/

Please update .gitignore and drop the intel_icd.json reference from EXTRA_DIST.

With those the series is:
Reviewed-by: Emil Velikov 

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

Re: [Mesa-dev] [PATCH] st/mesa: use u_bit_scan64() on 64-bit CPUs

[Marek Olšák]

On Oct 21, 2016 3:23 PM, "Jan Ziak" <0xe2.0x9a.0...@gmail.com> wrote:
>
> On Fri, Oct 21, 2016 at 3:17 PM, Marek Olšák  wrote:
> > On Oct 21, 2016 12:06 PM, "Jan Ziak" <0xe2.0x9a.0...@gmail.com> wrote:
> >>
> >> On Fri, Oct 21, 2016 at 12:04 PM, Marek Olšák  wrote:
> >> > This won't make it faster.
> >>
> >> Why?
> >
> > It's obviously a micro optimization
>
> Yes.
>
> > that adds more stuff than it benefits
> > the runtime. I don't think that real performance improvements will be so
> > simple and obvious.
>
> What idea would you consider a real performance improvement (in
> relation to function st_validate_state() for example)?

There is no easy thing to do there. Multithreaded OpenGL dispatch is the
easiest not-easy thing. My FDO repository contains a branch where it's
partially done.

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

Re: [Mesa-dev] [PATCH 00/15] GLSL memory allocation rework for faster compilation

[Marek Olšák]

On Oct 21, 2016 1:07 PM, "Tapani Pälli"  wrote:
>
>
>
> On 10/21/2016 12:51 PM, Marek Olšák wrote:
>>
>> On Fri, Oct 21, 2016 at 6:58 AM, Tapani Pälli 
wrote:
>>>
>>>
>>>
>>> On 10/20/2016 09:24 PM, Marek Olšák wrote:


 On Thu, Oct 20, 2016 at 6:31 PM, Tapani Pälli 
 wrote:
>
>
> On 10/20/2016 06:55 PM, Marek Olšák wrote:
>>
>>
>>
>> On Mon, Oct 17, 2016 at 9:03 PM, Marek Olšák 
wrote:
>>>
>>>
>>>
>>> Hi,
>>>
>>> The latest branch:
>>> https://cgit.freedesktop.org/~mareko/mesa/log/?h=glsl-alloc-rework2
>>>
>>> It contains:
>>> - all review comments resolved
>>> - commits from Tapani's jenkins branch (fixes for glsl, nir, i965)
>>>
>>> My updated patches are also on the list if you wanna review them.
>>
>>
>>
>> Since there are no other comments, it looks like it's ready to land.
>> i965 and Gallium were tested by Tapani and me, respectively. The
>> branch contains all fixes first, followed by the allocation changes.
>
>
>
>
> I haven't had time for further testing but it would make sense to try
> also
> with some benchmarks and steam games on i965. JP recalled there was
> something that got triggered by Manhattan earlier with his patches.
I'll
> try
> to get this testing done tomorrow.



 I suggest you put shaders from Manhattan into your shader-db, so that
 you don't have to run the game under valgrind. Also in future, it's
 better to use shader-db instead of running games for stuff like this.

>>>
>>> Makes sense as ralloc is mostly used in compiler but I think some of
those
>>> rallocated structures get also accessed when app calls GL API. I'll run
at
>>> least gfxbench manually just as a paranoid check to see if there's
anything.
>>>
>>> About shader-db .. should we consider making a scripts folder there and
>>> start sharing some? It's used for instruction count analysis, memory
>>> analysis .. would be nice to have some sort of 'standard' skeleton
scripts
>>> for this which can be then modified for purposes.
>>
>>
>> Not sure what you mean. Our script for shader-db reporting is
si-report.py.
>>
>
> I mean scripts for comparing runs. For example for compile time
performance one might use Eric Anholt's compare-perf but that requires some
additional scripts that print correct output from run. Or maybe for leaks
it would be interesting to have a comparison summary script of memory leaks
between runs? Current scripts seem to only report instruction count
difference between 2 runs?

Well, it only reports instruction count difference for Intel. Our stats are
completely different.  I use the "time" command to measure compiler
performance. It seems to do the job well.

>
> I did run some valgrind comparisons with gfxbench4, your branch against
Mesa master. I did not spot anything obvious related to ralloc.
>
> On i965 there's a huge load of invalid writes's and read's in general but
this happens on master as well so maybe these are not 'valid hits'. There's
also some leaks both with master and your branch but your branch has less,
so it seems to fix some things.

It can't fix anything. Both allocators are hierarchical, so most code
doesn't care about freeing memory.

I usually don't see any invalid reads and writes with radeonsi.

Marek

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

Re: [Mesa-dev] [PATCH] st/mesa: use u_bit_scan64() on 64-bit CPUs

[Jan Ziak]

On Fri, Oct 21, 2016 at 3:17 PM, Marek Olšák  wrote:
> On Oct 21, 2016 12:06 PM, "Jan Ziak" <0xe2.0x9a.0...@gmail.com> wrote:
>>
>> On Fri, Oct 21, 2016 at 12:04 PM, Marek Olšák  wrote:
>> > This won't make it faster.
>>
>> Why?
>
> It's obviously a micro optimization

Yes.

> that adds more stuff than it benefits
> the runtime. I don't think that real performance improvements will be so
> simple and obvious.

What idea would you consider a real performance improvement (in
relation to function st_validate_state() for example)?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] st/mesa: use u_bit_scan64() on 64-bit CPUs

[Marek Olšák]

On Oct 21, 2016 12:06 PM, "Jan Ziak" <0xe2.0x9a.0...@gmail.com> wrote:
>
> On Fri, Oct 21, 2016 at 12:04 PM, Marek Olšák  wrote:
> > This won't make it faster.
>
> Why?

It's obviously a micro optimization that adds more stuff than it benefits
the runtime. I don't think that real performance improvements will be so
simple and obvious.

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

Re: [Mesa-dev] [PATCH 3/5] nv50/ir: it appears that OP_DISCARD can't take a join modifier

[Samuel Pitoiset]

On 10/21/2016 11:18 AM, Samuel Pitoiset wrote:

Reviewed-by: Samuel Pitoiset 

On 10/21/2016 08:30 AM, Ilia Mirkin wrote:

nvdisasm does not print a .S even though the bit is set.

Signed-off-by: Ilia Mirkin 
---
 src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
index cc5d1f4..f6fce44 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
@@ -2970,6 +2970,7 @@ FlatteningPass::visit(BasicBlock *bb)
  insn = insn->prev;
  if (insn && !insn->getPredicate() &&
  !insn->asFlow() &&
+ insn->op != OP_DISCARD &&
  insn->op != OP_TEXBAR &&


We should *really* improve the situation here, because the check is
going to be insane...


For example, this is the list of instructions which support a JOIN on 
SM35: http://hastebin.com/lamuyocozo


I could try to cook up something better actually. :-)




  !isTextureOp(insn->op) && // probably just nve4
  !isSurfaceOp(insn->op) && // not confirmed





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

[Mesa-dev] [Bug 98172] Concurrent call to glClientWaitSync results in segfault in one of the waiters.

[bugzilla-daemon]

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

--- Comment #41 from Suzuki, Shinji  ---
I think now I have better understanding of the problem we are dealing with
here.

>Not thread safe (race condition on so->fence):
>  screen->fence_reference(screen, >fence, NULL);
>
>Always thread safe (if fence is a local variable):
>  screen->fence_reference(screen, , NULL);

I think above can be more concisely stated that
"screen->fence_reference(screen, , NULL);
is thread-safe if calls are serialized otherwise not thread safe".

What's fundamentally wrong with the untouched mesa code is that
screen->fence_reference(screen, >fence, NULL) is potentially called more
than once. If the calls are serialized, no crash occurs because the second and
later calls behave as no-op. Protecting each call with a mutex is a way to
assure that serial execution. But that is an indirect resolution of the
problem. A direct resolution is to have screen->fence_reference() not to be
called more than once because that shared reference contributes to only one
increment in the reference count. Below is my latest attempt.

static void st_client_wait_sync(struct gl_context *ctx,
struct gl_sync_object *obj,
GLbitfield flags, GLuint64 timeout)
{
   struct pipe_screen *screen = st_context(ctx)->pipe->screen;  
   struct st_sync_object *so = (struct st_sync_object*)obj; 
   struct pipe_fence_handle *fence = NULL;  

   /* Duplicate the reference so that the fence object is guaranteed to
* be alive at least until associated 'unref' below is executed.
* This is important because multiple threads have to execute
* fence_finish() concurrently even if they target same fence object
* to deal with potentially different time-out settings.
*/
   screen->fence_reference(screen, , so->fence);  

   if (fence && screen->fence_finish(screen, fence, timeout)) {
  if( p_atomic_cmpxchg(>fence, fence, NULL) == fence ) {
 /* Get done with 'so->object'. This is a 'unref' op.
  * Borrow the value in 'fence' since so->fence is already
  * set to NULL by the cmpxchg above.
  */
 struct pipe_fence_handle * fence_copy = fence; 
 screen->fence_reference(screen, _copy, NULL);
  } 
   }
   so->b.StatusFlag = GL_TRUE;   
   screen->fence_reference(screen, , NULL);   
}

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

[Mesa-dev] [PATCH] mesa: fix error handling in DrawBuffers

[Tapani Pälli]

Patch rearranges error checking so that enum checking provided via
destmask happens before other checks. It needs to be done in this
order because other error checks do not work properly if there were
invalid enums passed.

Patch also refines one existing check and it's documentation to match
GLES 3.0 spec (also in later specs). This was somewhat mysteriously
referring to desktop GL but had a check for gles3.

Fixes following dEQP tests:

   dEQP-GLES31.functional.debug.negative_coverage.get_error.buffer.draw_buffers

no CI regressions observed.

Signed-off-by: Tapani Pälli 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98134
---
 src/mesa/main/buffers.c | 71 ++---
 1 file changed, 37 insertions(+), 34 deletions(-)

diff --git a/src/mesa/main/buffers.c b/src/mesa/main/buffers.c
index 86696b8..2b24e5a 100644
--- a/src/mesa/main/buffers.c
+++ b/src/mesa/main/buffers.c
@@ -389,17 +389,48 @@ draw_buffers(struct gl_context *ctx, struct 
gl_framebuffer *fb,
 
/* complicated error checking... */
for (output = 0; output < n; output++) {
-  /* Section 4.2 (Whole Framebuffer Operations) of the OpenGL 3.0
+  destMask[output] = draw_buffer_enum_to_bitmask(ctx, buffers[output]);
+
+  /* From the OpenGL 3.0 specification, page 258:
+   * "Each buffer listed in bufs must be one of the values from tables
+   *  4.5 or 4.6.  Otherwise, an INVALID_ENUM error is generated.
+   */
+  if (destMask[output] == BAD_MASK) {
+ _mesa_error(ctx, GL_INVALID_ENUM, "%s(invalid buffer %s)",
+ caller, _mesa_enum_to_string(buffers[output]));
+ return;
+  }
+
+  /* From the OpenGL 4.0 specification, page 256:
+   * "For both the default framebuffer and framebuffer objects, the
+   *  constants FRONT, BACK, LEFT, RIGHT, and FRONT_AND_BACK are not
+   *  valid in the bufs array passed to DrawBuffers, and will result in
+   *  the error INVALID_ENUM. This restriction is because these
+   *  constants may themselves refer to multiple buffers, as shown in
+   *  table 4.4."
+   *  Previous versions of the OpenGL specification say INVALID_OPERATION,
+   *  but the Khronos conformance tests expect INVALID_ENUM.
+   */
+  if (_mesa_bitcount(destMask[output]) > 1) {
+ _mesa_error(ctx, GL_INVALID_ENUM, "%s(invalid buffer %s)",
+ caller, _mesa_enum_to_string(buffers[output]));
+ return;
+  }
+
+  /* Section 4.2 (Whole Framebuffer Operations) of the OpenGL ES 3.0
* specification says:
*
-   * "Each buffer listed in bufs must be BACK, NONE, or one of the 
values
-   *  from table 4.3 (NONE, COLOR_ATTACHMENTi)"
+   * "If the GL is bound to a draw framebuffer object, the ith buffer
+   * listed in bufs must be COLOR_ATTACHMENTi or NONE . Specifying a
+   * buffer out of order, BACK , or COLOR_ATTACHMENTm where m is 
greater
+   * than or equal to the value of MAX_- COLOR_ATTACHMENTS , will
+   * generate the error INVALID_OPERATION .
*/
-  if (_mesa_is_gles3(ctx) && buffers[output] != GL_NONE &&
-  buffers[output] != GL_BACK &&
+  if (_mesa_is_gles3(ctx) && _mesa_is_user_fbo(fb) &&
+  buffers[output] != GL_NONE &&
   (buffers[output] < GL_COLOR_ATTACHMENT0 ||
buffers[output] >= GL_COLOR_ATTACHMENT0 + 
ctx->Const.MaxColorAttachments)) {
- _mesa_error(ctx, GL_INVALID_ENUM, "glDrawBuffers(buffer)");
+ _mesa_error(ctx, GL_INVALID_OPERATION, "glDrawBuffers(buffer)");
  return;
   }
 
@@ -423,34 +454,6 @@ draw_buffers(struct gl_context *ctx, struct gl_framebuffer 
*fb,
 return;
  }
 
- destMask[output] = draw_buffer_enum_to_bitmask(ctx, buffers[output]);
-
- /* From the OpenGL 3.0 specification, page 258:
-  * "Each buffer listed in bufs must be one of the values from tables
-  *  4.5 or 4.6.  Otherwise, an INVALID_ENUM error is generated.
-  */
- if (destMask[output] == BAD_MASK) {
-_mesa_error(ctx, GL_INVALID_ENUM, "%s(invalid buffer %s)",
-caller, _mesa_enum_to_string(buffers[output]));
-return;
- }
-
- /* From the OpenGL 4.0 specification, page 256:
-  * "For both the default framebuffer and framebuffer objects, the
-  *  constants FRONT, BACK, LEFT, RIGHT, and FRONT_AND_BACK are not
-  *  valid in the bufs array passed to DrawBuffers, and will result in
-  *  the error INVALID_ENUM. This restriction is because these
-  *  constants may themselves refer to multiple buffers, as shown in
-  *  table 4.4."
-  *  Previous versions of the OpenGL specification say 
INVALID_OPERATION,
-  *  but the Khronos conformance tests expect INVALID_ENUM.
-  */
- if 

[Mesa-dev] [Bug 98245] GLES3.1 link negative dEQP "expected linking to fail, but passed."

[bugzilla-daemon]

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

--- Comment #1 from Iago Toral  ---
These seem to be two different issues so I think it is probably best to create
two different bug reports.

I have sent a patch for review that fixes the first one:
https://lists.freedesktop.org/archives/mesa-dev/2016-October/132896.html

-- 
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] glsl: add matrix layout information to interface block types

[Iago Toral Quiroga]

So far we have been checking that interface block definitions had matching
matrix layouts by comparing the definitions of their fields, however, this
does not cover the case where the interface blocks are defined with
mismatching matrix layouts but don't define any field with a matrix type.
In this case Mesa will not fail to link because none of the fields will
inherit the mismatching layout qualifier.

This patch fixes the problem in the same way we fixed it for packing layout
information: we add the the layout information to the interface type and then
we check it matches during the uniform block linking process.

Fixes:
dEQP-GLES31.functional.shaders.linkage.uniform.block.layout_qualifier_mismatch_3

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98245
---
 src/compiler/glsl/ast_to_hir.cpp  |  2 ++
 src/compiler/glsl/builtin_variables.cpp   |  1 +
 src/compiler/glsl/link_uniform_blocks.cpp |  5 +
 src/compiler/glsl/linker.cpp  |  6 --
 src/compiler/glsl_types.cpp   | 24 +++-
 src/compiler/glsl_types.h | 13 -
 src/mesa/main/mtypes.h|  1 +
 7 files changed, 40 insertions(+), 12 deletions(-)

diff --git a/src/compiler/glsl/ast_to_hir.cpp b/src/compiler/glsl/ast_to_hir.cpp
index 6e2f253..adedcbb 100644
--- a/src/compiler/glsl/ast_to_hir.cpp
+++ b/src/compiler/glsl/ast_to_hir.cpp
@@ -7516,6 +7516,8 @@ ast_interface_block::hir(exec_list *instructions,
   glsl_type::get_interface_instance(fields,
 num_variables,
 packing,
+matrix_layout ==
+   GLSL_MATRIX_LAYOUT_ROW_MAJOR,
 this->block_name);
 
unsigned component_size = block_type->contains_double() ? 8 : 4;
diff --git a/src/compiler/glsl/builtin_variables.cpp 
b/src/compiler/glsl/builtin_variables.cpp
index 10a8750..ca266a4 100644
--- a/src/compiler/glsl/builtin_variables.cpp
+++ b/src/compiler/glsl/builtin_variables.cpp
@@ -352,6 +352,7 @@ per_vertex_accumulator::construct_interface_instance() const
 {
return glsl_type::get_interface_instance(this->fields, this->num_fields,
 GLSL_INTERFACE_PACKING_STD140,
+false,
 "gl_PerVertex");
 }
 
diff --git a/src/compiler/glsl/link_uniform_blocks.cpp 
b/src/compiler/glsl/link_uniform_blocks.cpp
index bb423c5..c0bdfa9 100644
--- a/src/compiler/glsl/link_uniform_blocks.cpp
+++ b/src/compiler/glsl/link_uniform_blocks.cpp
@@ -247,6 +247,7 @@ process_block_array(struct uniform_block_array_elements 
*ub_array, char **name,
 
   blocks[i].UniformBufferSize = 0;
   blocks[i]._Packing = gl_uniform_block_packing(type->interface_packing);
+  blocks[i]._RowMajor = type->get_interface_row_major();
 
   parcel->process(type, blocks[i].Name);
 
@@ -354,6 +355,7 @@ create_buffer_blocks(void *mem_ctx, struct gl_context *ctx,
 blocks[i].UniformBufferSize = 0;
 blocks[i]._Packing =
gl_uniform_block_packing(block_type->interface_packing);
+blocks[i]._RowMajor = block_type->get_interface_row_major();
 
 parcel.process(block_type,
b->has_instance_name ? block_type->name : "");
@@ -486,6 +488,9 @@ link_uniform_blocks_are_compatible(const gl_uniform_block 
*a,
if (a->_Packing != b->_Packing)
   return false;
 
+   if (a->_RowMajor != b->_RowMajor)
+  return false;
+
for (unsigned i = 0; i < a->NumUniforms; i++) {
   if (strcmp(a->Uniforms[i].Name, b->Uniforms[i].Name) != 0)
  return false;
diff --git a/src/compiler/glsl/linker.cpp b/src/compiler/glsl/linker.cpp
index 8599590..74f5c28 100644
--- a/src/compiler/glsl/linker.cpp
+++ b/src/compiler/glsl/linker.cpp
@@ -1505,9 +1505,10 @@ private:
   }
   glsl_interface_packing packing =
  (glsl_interface_packing) type->interface_packing;
+  bool row_major = (bool) type->interface_row_major;
   const glsl_type *new_ifc_type =
  glsl_type::get_interface_instance(fields, num_fields,
-   packing, type->name);
+   packing, row_major, type->name);
   delete [] fields;
   return new_ifc_type;
}
@@ -1535,9 +1536,10 @@ private:
   }
   glsl_interface_packing packing =
  (glsl_interface_packing) ifc_type->interface_packing;
+  bool row_major = (bool) ifc_type->interface_row_major;
   const glsl_type *new_ifc_type =
  glsl_type::get_interface_instance(fields, num_fields, packing,
-   ifc_type->name);
+   row_major, ifc_type->name);
   delete [] fields;
   for (unsigned i = 0; i < 

[Mesa-dev] [Bug 98134] dEQP-GLES31.functional.debug.negative_coverage.get_error.buffer.draw_buffers wants a different GL error code

[bugzilla-daemon]

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

--- Comment #3 from Tapani Pälli  ---
(In reply to Tapani Pälli from comment #2)
> Created attachment 127094 [details] [review]
> fix
> 
> This patch fixes the test. These tests fail in CI though:
> 
>  GL45-CTS.shader_image_size.advanced-nonMS-fs-uint
>  GL45-CTS.shader_image_size.advanced-nonMS-fs-int
>  GL45-CTS.shader_image_size.advanced-nonMS-fs-float
> 
> will take some more look later.

OK those failures were bogus, I just run same patch with current master and no
regressions were observed. Will cleanup the patch and send to the list.

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

Re: [Mesa-dev] [PATCH 00/15] GLSL memory allocation rework for faster compilation

[Tapani Pälli]

On 10/21/2016 12:51 PM, Marek Olšák wrote:

On Fri, Oct 21, 2016 at 6:58 AM, Tapani Pälli  wrote:



On 10/20/2016 09:24 PM, Marek Olšák wrote:


On Thu, Oct 20, 2016 at 6:31 PM, Tapani Pälli 
wrote:


On 10/20/2016 06:55 PM, Marek Olšák wrote:



On Mon, Oct 17, 2016 at 9:03 PM, Marek Olšák  wrote:



Hi,

The latest branch:
https://cgit.freedesktop.org/~mareko/mesa/log/?h=glsl-alloc-rework2

It contains:
- all review comments resolved
- commits from Tapani's jenkins branch (fixes for glsl, nir, i965)

My updated patches are also on the list if you wanna review them.



Since there are no other comments, it looks like it's ready to land.
i965 and Gallium were tested by Tapani and me, respectively. The
branch contains all fixes first, followed by the allocation changes.




I haven't had time for further testing but it would make sense to try
also
with some benchmarks and steam games on i965. JP recalled there was
something that got triggered by Manhattan earlier with his patches. I'll
try
to get this testing done tomorrow.



I suggest you put shaders from Manhattan into your shader-db, so that
you don't have to run the game under valgrind. Also in future, it's
better to use shader-db instead of running games for stuff like this.



Makes sense as ralloc is mostly used in compiler but I think some of those
rallocated structures get also accessed when app calls GL API. I'll run at
least gfxbench manually just as a paranoid check to see if there's anything.

About shader-db .. should we consider making a scripts folder there and
start sharing some? It's used for instruction count analysis, memory
analysis .. would be nice to have some sort of 'standard' skeleton scripts
for this which can be then modified for purposes.


Not sure what you mean. Our script for shader-db reporting is si-report.py.



I mean scripts for comparing runs. For example for compile time 
performance one might use Eric Anholt's compare-perf but that requires 
some additional scripts that print correct output from run. Or maybe for 
leaks it would be interesting to have a comparison summary script of 
memory leaks between runs? Current scripts seem to only report 
instruction count difference between 2 runs?


I did run some valgrind comparisons with gfxbench4, your branch against 
Mesa master. I did not spot anything obvious related to ralloc.


On i965 there's a huge load of invalid writes's and read's in general 
but this happens on master as well so maybe these are not 'valid hits'. 
There's also some leaks both with master and your branch but your branch 
has less, so it seems to fix some things.


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

Re: [Mesa-dev] [PATCH] st/mesa: use u_bit_scan64() on 64-bit CPUs

[Jan Ziak]

On Fri, Oct 21, 2016 at 12:04 PM, Marek Olšák  wrote:
> This won't make it faster.

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

Re: [Mesa-dev] [PATCH] st/mesa: use u_bit_scan64() on 64-bit CPUs

[Marek Olšák]

NAK.

This won't make it faster.

Marek

On Fri, Oct 21, 2016 at 11:58 AM, Jan Ziak <0xe2.0x9a.0...@gmail.com> wrote:
> st_validate_state() shows up in benchmarks. This patch makes it a little bit
> faster in 64-bit mode.
>
> Signed-off-by: Jan Ziak (http://atom-symbol.net) <0xe2.0x9a.0...@gmail.com>
> ---
>  src/mesa/state_tracker/st_atom.c | 25 +
>  1 file changed, 13 insertions(+), 12 deletions(-)
>
> diff --git a/src/mesa/state_tracker/st_atom.c 
> b/src/mesa/state_tracker/st_atom.c
> index 94e012a..210f6f3 100644
> --- a/src/mesa/state_tracker/st_atom.c
> +++ b/src/mesa/state_tracker/st_atom.c
> @@ -155,7 +155,6 @@ void st_validate_state( struct st_context *st, enum 
> st_pipeline pipeline )
>  {
> struct gl_context *ctx = st->ctx;
> uint64_t dirty, pipeline_mask;
> -   uint32_t dirty_lo, dirty_hi;
>
> /* Get Mesa driver state.
>  *
> @@ -200,17 +199,19 @@ void st_validate_state( struct st_context *st, enum 
> st_pipeline pipeline )
> if (!dirty)
>return;
>
> -   dirty_lo = dirty;
> -   dirty_hi = dirty >> 32;
> -
> -   /* Update states.
> -*
> -* Don't use u_bit_scan64, it may be slower on 32-bit.
> -*/
> -   while (dirty_lo)
> -  atoms[u_bit_scan(_lo)]->update(st);
> -   while (dirty_hi)
> -  atoms[32 + u_bit_scan(_hi)]->update(st);
> +   /* Update states. */
> +   if (sizeof(void*) > 4) {
> +  while (dirty)
> + atoms[u_bit_scan64()]->update(st);
> +   } else {
> +  /* Don't use u_bit_scan64, it may be slower on 32-bit. */
> +  uint32_t dirty_lo = dirty;
> +  uint32_t dirty_hi = dirty >> 32;
> +  while (dirty_lo)
> + atoms[u_bit_scan(_lo)]->update(st);
> +  while (dirty_hi)
> + atoms[32 + u_bit_scan(_hi)]->update(st);
> +   }
>
> /* Clear the render or compute state bits. */
> st->dirty &= ~pipeline_mask;
> ___
> 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] [PATCH] st/mesa: use u_bit_scan64() on 64-bit CPUs

[Jan Ziak]

st_validate_state() shows up in benchmarks. This patch makes it a little bit
faster in 64-bit mode.

Signed-off-by: Jan Ziak (http://atom-symbol.net) <0xe2.0x9a.0...@gmail.com>
---
 src/mesa/state_tracker/st_atom.c | 25 +
 1 file changed, 13 insertions(+), 12 deletions(-)

diff --git a/src/mesa/state_tracker/st_atom.c b/src/mesa/state_tracker/st_atom.c
index 94e012a..210f6f3 100644
--- a/src/mesa/state_tracker/st_atom.c
+++ b/src/mesa/state_tracker/st_atom.c
@@ -155,7 +155,6 @@ void st_validate_state( struct st_context *st, enum 
st_pipeline pipeline )
 {
struct gl_context *ctx = st->ctx;
uint64_t dirty, pipeline_mask;
-   uint32_t dirty_lo, dirty_hi;
 
/* Get Mesa driver state.
 *
@@ -200,17 +199,19 @@ void st_validate_state( struct st_context *st, enum 
st_pipeline pipeline )
if (!dirty)
   return;
 
-   dirty_lo = dirty;
-   dirty_hi = dirty >> 32;
-
-   /* Update states.
-*
-* Don't use u_bit_scan64, it may be slower on 32-bit.
-*/
-   while (dirty_lo)
-  atoms[u_bit_scan(_lo)]->update(st);
-   while (dirty_hi)
-  atoms[32 + u_bit_scan(_hi)]->update(st);
+   /* Update states. */
+   if (sizeof(void*) > 4) {
+  while (dirty)
+ atoms[u_bit_scan64()]->update(st);
+   } else {
+  /* Don't use u_bit_scan64, it may be slower on 32-bit. */
+  uint32_t dirty_lo = dirty;
+  uint32_t dirty_hi = dirty >> 32;
+  while (dirty_lo)
+ atoms[u_bit_scan(_lo)]->update(st);
+  while (dirty_hi)
+ atoms[32 + u_bit_scan(_hi)]->update(st);
+   }
 
/* Clear the render or compute state bits. */
st->dirty &= ~pipeline_mask;
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 00/15] GLSL memory allocation rework for faster compilation

[Marek Olšák]

On Fri, Oct 21, 2016 at 6:58 AM, Tapani Pälli  wrote:
>
>
> On 10/20/2016 09:24 PM, Marek Olšák wrote:
>>
>> On Thu, Oct 20, 2016 at 6:31 PM, Tapani Pälli 
>> wrote:
>>>
>>> On 10/20/2016 06:55 PM, Marek Olšák wrote:


 On Mon, Oct 17, 2016 at 9:03 PM, Marek Olšák  wrote:
>
>
> Hi,
>
> The latest branch:
> https://cgit.freedesktop.org/~mareko/mesa/log/?h=glsl-alloc-rework2
>
> It contains:
> - all review comments resolved
> - commits from Tapani's jenkins branch (fixes for glsl, nir, i965)
>
> My updated patches are also on the list if you wanna review them.


 Since there are no other comments, it looks like it's ready to land.
 i965 and Gallium were tested by Tapani and me, respectively. The
 branch contains all fixes first, followed by the allocation changes.
>>>
>>>
>>>
>>> I haven't had time for further testing but it would make sense to try
>>> also
>>> with some benchmarks and steam games on i965. JP recalled there was
>>> something that got triggered by Manhattan earlier with his patches. I'll
>>> try
>>> to get this testing done tomorrow.
>>
>>
>> I suggest you put shaders from Manhattan into your shader-db, so that
>> you don't have to run the game under valgrind. Also in future, it's
>> better to use shader-db instead of running games for stuff like this.
>>
>
> Makes sense as ralloc is mostly used in compiler but I think some of those
> rallocated structures get also accessed when app calls GL API. I'll run at
> least gfxbench manually just as a paranoid check to see if there's anything.
>
> About shader-db .. should we consider making a scripts folder there and
> start sharing some? It's used for instruction count analysis, memory
> analysis .. would be nice to have some sort of 'standard' skeleton scripts
> for this which can be then modified for purposes.

Not sure what you mean. Our script for shader-db reporting is si-report.py.

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

Re: [Mesa-dev] [PATCH] gallium: add PIPE_CAP_STREAM_OUTPUT_INTERLEAVE_BUFFERS

[Marek Olšák]

Reviewed-by: Marek Olšák 

Marek

On Fri, Oct 21, 2016 at 9:07 AM, Ilia Mirkin  wrote:
> This allows the driver to signal that it can't handle random
> interleaving of attributes across buffers. This is required for
> ARB_transform_feedback3, and it's initialized to whatever the previous
> value of PIPE_CAP_STREAM_OUTPUT_PAUSE_RESUME was except for nv50 where
> it is disabled. Note that the proprietary drivers never expose
> ARB_transform_feedback3 on any GT21x's (where nouveau previously did),
> and after some effort I was unable to get it to work.
>
> Signed-off-by: Ilia Mirkin 
> ---
>  docs/features.txt| 2 +-
>  src/gallium/docs/source/screen.rst   | 3 +++
>  src/gallium/drivers/freedreno/freedreno_screen.c | 1 +
>  src/gallium/drivers/i915/i915_screen.c   | 1 +
>  src/gallium/drivers/ilo/ilo_screen.c | 1 +
>  src/gallium/drivers/llvmpipe/lp_screen.c | 1 +
>  src/gallium/drivers/nouveau/nv30/nv30_screen.c   | 1 +
>  src/gallium/drivers/nouveau/nv50/nv50_screen.c   | 1 +
>  src/gallium/drivers/nouveau/nvc0/nvc0_screen.c   | 1 +
>  src/gallium/drivers/r300/r300_screen.c   | 1 +
>  src/gallium/drivers/r600/r600_pipe.c | 1 +
>  src/gallium/drivers/radeonsi/si_pipe.c   | 1 +
>  src/gallium/drivers/softpipe/sp_screen.c | 1 +
>  src/gallium/drivers/svga/svga_screen.c   | 1 +
>  src/gallium/drivers/swr/swr_screen.cpp   | 1 +
>  src/gallium/drivers/vc4/vc4_screen.c | 1 +
>  src/gallium/drivers/virgl/virgl_screen.c | 1 +
>  src/gallium/include/pipe/p_defines.h | 1 +
>  src/mesa/state_tracker/st_extensions.c   | 2 +-
>  19 files changed, 21 insertions(+), 2 deletions(-)
>
> diff --git a/docs/features.txt b/docs/features.txt
> index a677bfb..2c6691f 100644
> --- a/docs/features.txt
> +++ b/docs/features.txt
> @@ -133,7 +133,7 @@ GL 4.0, GLSL 4.00 --- all DONE: i965/gen8+, nvc0, r600, 
> radeonsi
>GL_ARB_texture_gather DONE (i965/gen6+, 
> nv50, llvmpipe, softpipe, swr)
>GL_ARB_texture_query_lod  DONE (i965, nv50, 
> softpipe)
>GL_ARB_transform_feedback2DONE (i965/gen7+, 
> nv50, llvmpipe, softpipe, swr)
> -  GL_ARB_transform_feedback3DONE (i965/gen7+, 
> nv50, llvmpipe, softpipe, swr)
> +  GL_ARB_transform_feedback3DONE (i965/gen7+, 
> llvmpipe, softpipe, swr)
>
>
>  GL 4.1, GLSL 4.10 --- all DONE: i965/gen8+, nvc0, r600, radeonsi
> diff --git a/src/gallium/docs/source/screen.rst 
> b/src/gallium/docs/source/screen.rst
> index d79e75e..6ad2bec 100644
> --- a/src/gallium/docs/source/screen.rst
> +++ b/src/gallium/docs/source/screen.rst
> @@ -361,6 +361,9 @@ The integer capabilities:
>equal interpolation qualifiers.
>Components may overlap, notably when the gaps in an array of dvec3 are
>filled in.
> +* ``PIPE_CAP_STREAM_OUTPUT_INTERLEAVE_BUFFERS``: Whether interleaved stream
> +  output mode is able to interleave across buffers. This is required for
> +  ARB_transform_feedback3.
>
>
>  .. _pipe_capf:
> diff --git a/src/gallium/drivers/freedreno/freedreno_screen.c 
> b/src/gallium/drivers/freedreno/freedreno_screen.c
> index 1f7c2a5..97da0d7 100644
> --- a/src/gallium/drivers/freedreno/freedreno_screen.c
> +++ b/src/gallium/drivers/freedreno/freedreno_screen.c
> @@ -307,6 +307,7 @@ fd_screen_get_param(struct pipe_screen *pscreen, enum 
> pipe_cap param)
> return PIPE_MAX_SO_BUFFERS;
> return 0;
> case PIPE_CAP_STREAM_OUTPUT_PAUSE_RESUME:
> +   case PIPE_CAP_STREAM_OUTPUT_INTERLEAVE_BUFFERS:
> if (is_ir3(screen))
> return 1;
> return 0;
> diff --git a/src/gallium/drivers/i915/i915_screen.c 
> b/src/gallium/drivers/i915/i915_screen.c
> index 003f855..bfadca3 100644
> --- a/src/gallium/drivers/i915/i915_screen.c
> +++ b/src/gallium/drivers/i915/i915_screen.c
> @@ -282,6 +282,7 @@ i915_get_param(struct pipe_screen *screen, enum pipe_cap 
> cap)
>
> case PIPE_CAP_MAX_DUAL_SOURCE_RENDER_TARGETS:
> case PIPE_CAP_STREAM_OUTPUT_PAUSE_RESUME:
> +   case PIPE_CAP_STREAM_OUTPUT_INTERLEAVE_BUFFERS:
> case PIPE_CAP_VERTEX_BUFFER_OFFSET_4BYTE_ALIGNED_ONLY:
> case PIPE_CAP_VERTEX_BUFFER_STRIDE_4BYTE_ALIGNED_ONLY:
> case PIPE_CAP_VERTEX_ELEMENT_SRC_OFFSET_4BYTE_ALIGNED_ONLY:
> diff --git a/src/gallium/drivers/ilo/ilo_screen.c 
> b/src/gallium/drivers/ilo/ilo_screen.c
> index 1904cd6..f3f182c 100644
> --- a/src/gallium/drivers/ilo/ilo_screen.c
> +++ b/src/gallium/drivers/ilo/ilo_screen.c
> @@ -399,6 +399,7 @@ ilo_get_param(struct pipe_screen *screen, enum pipe_cap 
> param)
> case PIPE_CAP_MAX_STREAM_OUTPUT_INTERLEAVED_COMPONENTS:
>return ILO_MAX_SO_BINDINGS;
> case PIPE_CAP_STREAM_OUTPUT_PAUSE_RESUME:

Re: [Mesa-dev] [PATCH] st/mesa: cleanup and fix primitive restart for indirect draws

[Marek Olšák]

Reviewed-by: Marek Olšák 

Marek

On Fri, Oct 21, 2016 at 10:18 AM, Nicolai Hähnle  wrote:
> From: Nicolai Hähnle 
>
> There are three intended functional changes here:
>
> 1. OpenGL 4.5 clarifies that primitive restart should only apply with index
>buffers, so make that change explicit in the indirect draw path.
>
> 2. Make PrimitiveRestartFixedIndex work with indirect draws.
>
> 3. The change where primitive_restart is only set when the restart index can
>actually have an effect (based on the size of indices) is also applied for
>indirect draws.
>
> Cc: 13.0 
> ---
>  src/mesa/state_tracker/st_draw.c | 45 
> +---
>  1 file changed, 28 insertions(+), 17 deletions(-)
>
> diff --git a/src/mesa/state_tracker/st_draw.c 
> b/src/mesa/state_tracker/st_draw.c
> index 5dcaff0..e9f25b6 100644
> --- a/src/mesa/state_tracker/st_draw.c
> +++ b/src/mesa/state_tracker/st_draw.c
> @@ -120,20 +120,44 @@ setup_index_buffer(struct st_context *st,
>/* indices are in user space memory */
>ibuffer->user_buffer = ib->ptr;
> }
>
> cso_set_index_buffer(st->cso_context, ibuffer);
> return TRUE;
>  }
>
>
>  /**
> + * Set the restart index.
> + */
> +static void
> +setup_primitive_restart(struct gl_context *ctx,
> +const struct _mesa_index_buffer *ib,
> +struct pipe_draw_info *info)
> +{
> +   if (ctx->Array._PrimitiveRestart) {
> +  info->restart_index = _mesa_primitive_restart_index(ctx, ib->type);
> +
> +  /* Enable primitive restart only when the restart index can have an
> +   * effect. This is required for correctness in radeonsi VI support.
> +   * Other hardware may also benefit from taking a faster, non-restart 
> path
> +   * when possible.
> +   */
> +  if ((ib->type == GL_UNSIGNED_INT) ||
> +  (ib->type == GL_UNSIGNED_SHORT && info->restart_index <= 0x) ||
> +  (ib->type == GL_UNSIGNED_BYTE && info->restart_index <= 0xff))
> + info->primitive_restart = true;
> +   }
> +}
> +
> +
> +/**
>   * Translate OpenGL primtive type (GL_POINTS, GL_TRIANGLE_STRIP, etc) to
>   * the corresponding Gallium type.
>   */
>  static unsigned
>  translate_prim(const struct gl_context *ctx, unsigned prim)
>  {
> /* GL prims should match Gallium prims, spot-check a few */
> STATIC_ASSERT(GL_POINTS == PIPE_PRIM_POINTS);
> STATIC_ASSERT(GL_QUADS == PIPE_PRIM_QUADS);
> STATIC_ASSERT(GL_TRIANGLE_STRIP_ADJACENCY == 
> PIPE_PRIM_TRIANGLE_STRIP_ADJACENCY);
> @@ -198,33 +222,21 @@ st_draw_vbo(struct gl_context *ctx,
>
>info.indexed = TRUE;
>if (min_index != ~0U && max_index != ~0U) {
>   info.min_index = min_index;
>   info.max_index = max_index;
>}
>
>/* The VBO module handles restart for the non-indexed GLDrawArrays
> * so we only set these fields for indexed drawing:
> */
> -  if (ctx->Array._PrimitiveRestart) {
> - info.restart_index = _mesa_primitive_restart_index(ctx, ib->type);
> -
> - /* Enable primitive restart only when the restart index can have an
> -  * effect. This is required for correctness in radeonsi VI support,
> -  * though other hardware may also benefit from taking a faster,
> -  * non-restart path when possible.
> -  */
> - if ((ibuffer.index_size >= 4) ||
> - (ibuffer.index_size >= 2 && info.restart_index <= 0x) ||
> - (info.restart_index <= 0xff))
> -info.primitive_restart = true;
> -  }
> +  setup_primitive_restart(ctx, ib, );
> }
> else {
>/* Transform feedback drawing is always non-indexed. */
>/* Set info.count_from_stream_output. */
>if (tfb_vertcount) {
>   if (!st_transform_feedback_draw_init(tfb_vertcount, stream, ))
>  return;
>}
> }
>
> @@ -303,31 +315,30 @@ st_indirect_draw_vbo(struct gl_context *ctx,
>
> if (ib) {
>if (!setup_index_buffer(st, ib, )) {
>   _mesa_error(ctx, GL_OUT_OF_MEMORY, "gl%sDrawElementsIndirect%s",
>   (draw_count > 1) ? "Multi" : "",
>   indirect_params ? "CountARB" : "");
>   return;
>}
>
>info.indexed = TRUE;
> +
> +  /* Primitive restart is not handled by the VBO module in this case. */
> +  setup_primitive_restart(ctx, ib, );
> }
>
> info.mode = translate_prim(ctx, mode);
> info.vertices_per_patch = ctx->TessCtrlProgram.patch_vertices;
> info.indirect = st_buffer_object(indirect_data)->buffer;
> info.indirect_offset = indirect_offset;
>
> -   /* Primitive restart is not handled by the VBO module in this case. */
> -   info.primitive_restart = ctx->Array._PrimitiveRestart;
> -   info.restart_index = ctx->Array.RestartIndex;
> -
> if (ST_DEBUG & 

Re: [Mesa-dev] [PATCH 3/5] nv50/ir: it appears that OP_DISCARD can't take a join modifier

[Samuel Pitoiset]

Reviewed-by: Samuel Pitoiset 

On 10/21/2016 08:30 AM, Ilia Mirkin wrote:

nvdisasm does not print a .S even though the bit is set.

Signed-off-by: Ilia Mirkin 
---
 src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
index cc5d1f4..f6fce44 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
@@ -2970,6 +2970,7 @@ FlatteningPass::visit(BasicBlock *bb)
  insn = insn->prev;
  if (insn && !insn->getPredicate() &&
  !insn->asFlow() &&
+ insn->op != OP_DISCARD &&
  insn->op != OP_TEXBAR &&


We should *really* improve the situation here, because the check is 
going to be insane...



  !isTextureOp(insn->op) && // probably just nve4
  !isSurfaceOp(insn->op) && // not confirmed



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

Re: [Mesa-dev] [PATCH 2/5] nvc0/ir: use levelZero flag when the lod is set to 0

[Samuel Pitoiset]

Reviewed-by: Samuel Pitoiset 

On 10/21/2016 08:30 AM, Ilia Mirkin wrote:

Signed-off-by: Ilia Mirkin 
---
 src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp | 9 +
 1 file changed, 9 insertions(+)

diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
index 68f2b15..4181422 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
@@ -662,6 +662,15 @@ NVC0LoweringPass::handleTEX(TexInstruction *i)
   }
}

+   ImmediateValue lod;
+   if (!i->tex.target.isMS() && (i->op == OP_TXL || i->op == OP_TXF) &&
+   i->src(arg).getImmediate(lod) && lod.isInteger(0)) {
+  if (i->op == OP_TXL)
+ i->op = OP_TEX;
+  i->tex.levelZero = true;
+  i->moveSources(arg, -1);
+   }
+
// Arguments to the TEX instruction are a little insane. Even though the
// encoding is identical between SM20 and SM30, the arguments mean
// different things between Fermi and Kepler+. A lot of arguments are



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

Re: [Mesa-dev] [PATCH 1/5] nv50/ir: use levelZero for non-frag tex/txp ops

[Samuel Pitoiset]

Reviewed-by: Samuel Pitoiset 

On 10/21/2016 08:30 AM, Ilia Mirkin wrote:

radeonsi also does the same thing. I suspect that this is likely to be a
no-op in reality, but it brings nouveau code closer to what the blob
produces. Plus it makes sense to not try to do auto-derivatives on this.

Signed-off-by: Ilia Mirkin 
---
 src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp | 5 +
 1 file changed, 5 insertions(+)

diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
index 96bdd4e..80fbaed 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
@@ -2237,6 +2237,11 @@ Converter::handleTEX(Value *dst[4], int R, int S, int L, 
int C, int Dx, int Dy)

if (tgsi.getOpcode() == TGSI_OPCODE_SAMPLE_C_LZ)
   texi->tex.levelZero = true;
+   if (prog->getType() != Program::TYPE_FRAGMENT &&
+   (tgsi.getOpcode() == TGSI_OPCODE_TEX ||
+tgsi.getOpcode() == TGSI_OPCODE_TEX2 ||
+tgsi.getOpcode() == TGSI_OPCODE_TXP))
+  texi->tex.levelZero = true;
if (tgsi.getOpcode() == TGSI_OPCODE_TG4 && !tgt.isShadow())
   texi->tex.gatherComp = tgsi.getSrc(1).getValueU32(0, info);




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

Re: [Mesa-dev] [PATCH] gallium: add PIPE_CAP_STREAM_OUTPUT_INTERLEAVE_BUFFERS

[Nicolai Hähnle]

On 21.10.2016 09:07, Ilia Mirkin wrote:

This allows the driver to signal that it can't handle random
interleaving of attributes across buffers. This is required for
ARB_transform_feedback3, and it's initialized to whatever the previous
value of PIPE_CAP_STREAM_OUTPUT_PAUSE_RESUME was except for nv50 where
it is disabled. Note that the proprietary drivers never expose
ARB_transform_feedback3 on any GT21x's (where nouveau previously did),
and after some effort I was unable to get it to work.


Reviewed-by: Nicolai Hähnle 



Signed-off-by: Ilia Mirkin 
---
 docs/features.txt| 2 +-
 src/gallium/docs/source/screen.rst   | 3 +++
 src/gallium/drivers/freedreno/freedreno_screen.c | 1 +
 src/gallium/drivers/i915/i915_screen.c   | 1 +
 src/gallium/drivers/ilo/ilo_screen.c | 1 +
 src/gallium/drivers/llvmpipe/lp_screen.c | 1 +
 src/gallium/drivers/nouveau/nv30/nv30_screen.c   | 1 +
 src/gallium/drivers/nouveau/nv50/nv50_screen.c   | 1 +
 src/gallium/drivers/nouveau/nvc0/nvc0_screen.c   | 1 +
 src/gallium/drivers/r300/r300_screen.c   | 1 +
 src/gallium/drivers/r600/r600_pipe.c | 1 +
 src/gallium/drivers/radeonsi/si_pipe.c   | 1 +
 src/gallium/drivers/softpipe/sp_screen.c | 1 +
 src/gallium/drivers/svga/svga_screen.c   | 1 +
 src/gallium/drivers/swr/swr_screen.cpp   | 1 +
 src/gallium/drivers/vc4/vc4_screen.c | 1 +
 src/gallium/drivers/virgl/virgl_screen.c | 1 +
 src/gallium/include/pipe/p_defines.h | 1 +
 src/mesa/state_tracker/st_extensions.c   | 2 +-
 19 files changed, 21 insertions(+), 2 deletions(-)

diff --git a/docs/features.txt b/docs/features.txt
index a677bfb..2c6691f 100644
--- a/docs/features.txt
+++ b/docs/features.txt
@@ -133,7 +133,7 @@ GL 4.0, GLSL 4.00 --- all DONE: i965/gen8+, nvc0, r600, 
radeonsi
   GL_ARB_texture_gather DONE (i965/gen6+, 
nv50, llvmpipe, softpipe, swr)
   GL_ARB_texture_query_lod  DONE (i965, nv50, 
softpipe)
   GL_ARB_transform_feedback2DONE (i965/gen7+, 
nv50, llvmpipe, softpipe, swr)
-  GL_ARB_transform_feedback3DONE (i965/gen7+, 
nv50, llvmpipe, softpipe, swr)
+  GL_ARB_transform_feedback3DONE (i965/gen7+, 
llvmpipe, softpipe, swr)


 GL 4.1, GLSL 4.10 --- all DONE: i965/gen8+, nvc0, r600, radeonsi
diff --git a/src/gallium/docs/source/screen.rst 
b/src/gallium/docs/source/screen.rst
index d79e75e..6ad2bec 100644
--- a/src/gallium/docs/source/screen.rst
+++ b/src/gallium/docs/source/screen.rst
@@ -361,6 +361,9 @@ The integer capabilities:
   equal interpolation qualifiers.
   Components may overlap, notably when the gaps in an array of dvec3 are
   filled in.
+* ``PIPE_CAP_STREAM_OUTPUT_INTERLEAVE_BUFFERS``: Whether interleaved stream
+  output mode is able to interleave across buffers. This is required for
+  ARB_transform_feedback3.


 .. _pipe_capf:
diff --git a/src/gallium/drivers/freedreno/freedreno_screen.c 
b/src/gallium/drivers/freedreno/freedreno_screen.c
index 1f7c2a5..97da0d7 100644
--- a/src/gallium/drivers/freedreno/freedreno_screen.c
+++ b/src/gallium/drivers/freedreno/freedreno_screen.c
@@ -307,6 +307,7 @@ fd_screen_get_param(struct pipe_screen *pscreen, enum 
pipe_cap param)
return PIPE_MAX_SO_BUFFERS;
return 0;
case PIPE_CAP_STREAM_OUTPUT_PAUSE_RESUME:
+   case PIPE_CAP_STREAM_OUTPUT_INTERLEAVE_BUFFERS:
if (is_ir3(screen))
return 1;
return 0;
diff --git a/src/gallium/drivers/i915/i915_screen.c 
b/src/gallium/drivers/i915/i915_screen.c
index 003f855..bfadca3 100644
--- a/src/gallium/drivers/i915/i915_screen.c
+++ b/src/gallium/drivers/i915/i915_screen.c
@@ -282,6 +282,7 @@ i915_get_param(struct pipe_screen *screen, enum pipe_cap 
cap)

case PIPE_CAP_MAX_DUAL_SOURCE_RENDER_TARGETS:
case PIPE_CAP_STREAM_OUTPUT_PAUSE_RESUME:
+   case PIPE_CAP_STREAM_OUTPUT_INTERLEAVE_BUFFERS:
case PIPE_CAP_VERTEX_BUFFER_OFFSET_4BYTE_ALIGNED_ONLY:
case PIPE_CAP_VERTEX_BUFFER_STRIDE_4BYTE_ALIGNED_ONLY:
case PIPE_CAP_VERTEX_ELEMENT_SRC_OFFSET_4BYTE_ALIGNED_ONLY:
diff --git a/src/gallium/drivers/ilo/ilo_screen.c 
b/src/gallium/drivers/ilo/ilo_screen.c
index 1904cd6..f3f182c 100644
--- a/src/gallium/drivers/ilo/ilo_screen.c
+++ b/src/gallium/drivers/ilo/ilo_screen.c
@@ -399,6 +399,7 @@ ilo_get_param(struct pipe_screen *screen, enum pipe_cap 
param)
case PIPE_CAP_MAX_STREAM_OUTPUT_INTERLEAVED_COMPONENTS:
   return ILO_MAX_SO_BINDINGS;
case PIPE_CAP_STREAM_OUTPUT_PAUSE_RESUME:
+   case PIPE_CAP_STREAM_OUTPUT_INTERLEAVE_BUFFERS:
   if (ilo_dev_gen(>dev) >= ILO_GEN(7))
  return is->dev.has_gen7_sol_reset;
   else
diff --git a/src/gallium/drivers/llvmpipe/lp_screen.c 

[Mesa-dev] [PATCH] st/mesa: cleanup and fix primitive restart for indirect draws

[Nicolai Hähnle]

From: Nicolai Hähnle 

There are three intended functional changes here:

1. OpenGL 4.5 clarifies that primitive restart should only apply with index
   buffers, so make that change explicit in the indirect draw path.

2. Make PrimitiveRestartFixedIndex work with indirect draws.

3. The change where primitive_restart is only set when the restart index can
   actually have an effect (based on the size of indices) is also applied for
   indirect draws.

Cc: 13.0 
---
 src/mesa/state_tracker/st_draw.c | 45 +---
 1 file changed, 28 insertions(+), 17 deletions(-)

diff --git a/src/mesa/state_tracker/st_draw.c b/src/mesa/state_tracker/st_draw.c
index 5dcaff0..e9f25b6 100644
--- a/src/mesa/state_tracker/st_draw.c
+++ b/src/mesa/state_tracker/st_draw.c
@@ -120,20 +120,44 @@ setup_index_buffer(struct st_context *st,
   /* indices are in user space memory */
   ibuffer->user_buffer = ib->ptr;
}
 
cso_set_index_buffer(st->cso_context, ibuffer);
return TRUE;
 }
 
 
 /**
+ * Set the restart index.
+ */
+static void
+setup_primitive_restart(struct gl_context *ctx,
+const struct _mesa_index_buffer *ib,
+struct pipe_draw_info *info)
+{
+   if (ctx->Array._PrimitiveRestart) {
+  info->restart_index = _mesa_primitive_restart_index(ctx, ib->type);
+
+  /* Enable primitive restart only when the restart index can have an
+   * effect. This is required for correctness in radeonsi VI support.
+   * Other hardware may also benefit from taking a faster, non-restart path
+   * when possible.
+   */
+  if ((ib->type == GL_UNSIGNED_INT) ||
+  (ib->type == GL_UNSIGNED_SHORT && info->restart_index <= 0x) ||
+  (ib->type == GL_UNSIGNED_BYTE && info->restart_index <= 0xff))
+ info->primitive_restart = true;
+   }
+}
+
+
+/**
  * Translate OpenGL primtive type (GL_POINTS, GL_TRIANGLE_STRIP, etc) to
  * the corresponding Gallium type.
  */
 static unsigned
 translate_prim(const struct gl_context *ctx, unsigned prim)
 {
/* GL prims should match Gallium prims, spot-check a few */
STATIC_ASSERT(GL_POINTS == PIPE_PRIM_POINTS);
STATIC_ASSERT(GL_QUADS == PIPE_PRIM_QUADS);
STATIC_ASSERT(GL_TRIANGLE_STRIP_ADJACENCY == 
PIPE_PRIM_TRIANGLE_STRIP_ADJACENCY);
@@ -198,33 +222,21 @@ st_draw_vbo(struct gl_context *ctx,
 
   info.indexed = TRUE;
   if (min_index != ~0U && max_index != ~0U) {
  info.min_index = min_index;
  info.max_index = max_index;
   }
 
   /* The VBO module handles restart for the non-indexed GLDrawArrays
* so we only set these fields for indexed drawing:
*/
-  if (ctx->Array._PrimitiveRestart) {
- info.restart_index = _mesa_primitive_restart_index(ctx, ib->type);
-
- /* Enable primitive restart only when the restart index can have an
-  * effect. This is required for correctness in radeonsi VI support,
-  * though other hardware may also benefit from taking a faster,
-  * non-restart path when possible.
-  */
- if ((ibuffer.index_size >= 4) ||
- (ibuffer.index_size >= 2 && info.restart_index <= 0x) ||
- (info.restart_index <= 0xff))
-info.primitive_restart = true;
-  }
+  setup_primitive_restart(ctx, ib, );
}
else {
   /* Transform feedback drawing is always non-indexed. */
   /* Set info.count_from_stream_output. */
   if (tfb_vertcount) {
  if (!st_transform_feedback_draw_init(tfb_vertcount, stream, ))
 return;
   }
}
 
@@ -303,31 +315,30 @@ st_indirect_draw_vbo(struct gl_context *ctx,
 
if (ib) {
   if (!setup_index_buffer(st, ib, )) {
  _mesa_error(ctx, GL_OUT_OF_MEMORY, "gl%sDrawElementsIndirect%s",
  (draw_count > 1) ? "Multi" : "",
  indirect_params ? "CountARB" : "");
  return;
   }
 
   info.indexed = TRUE;
+
+  /* Primitive restart is not handled by the VBO module in this case. */
+  setup_primitive_restart(ctx, ib, );
}
 
info.mode = translate_prim(ctx, mode);
info.vertices_per_patch = ctx->TessCtrlProgram.patch_vertices;
info.indirect = st_buffer_object(indirect_data)->buffer;
info.indirect_offset = indirect_offset;
 
-   /* Primitive restart is not handled by the VBO module in this case. */
-   info.primitive_restart = ctx->Array._PrimitiveRestart;
-   info.restart_index = ctx->Array.RestartIndex;
-
if (ST_DEBUG & DEBUG_DRAW) {
   debug_printf("st/draw indirect: mode %s drawcount %d indexed %d\n",
u_prim_name(info.mode),
draw_count,
info.indexed);
}
 
if (!st->has_multi_draw_indirect) {
   int i;
 
-- 
2.7.4

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

Re: [Mesa-dev] [PATCH] amd/addrlib: limit fastcall/regparm to i386

[Nicolai Hähnle]

On 21.10.2016 00:20, Rob Herring wrote:

The use of regparm causes an error on arm/arm64 builds with clang.
fastcall is allowed, but still throws a warning. As both options only
have effect on 32-bit x86 builds, limit them to that case.


While we haven't been particularly good at syncing things 
back-and-forth, this code is shared with closed source driver builds, 
including on Windows.


Please re-structure the patch so that it really only changes the 
behavior with Clang. (For example, that MSVC doesn't define __i386__ as 
far as I'm aware.)


Thanks,
Nicolai



Signed-off-by: Rob Herring 
---
 src/amd/addrlib/addrtypes.h | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/src/amd/addrlib/addrtypes.h b/src/amd/addrlib/addrtypes.h
index 4c68ac544b88..183b5a751c3a 100644
--- a/src/amd/addrlib/addrtypes.h
+++ b/src/amd/addrlib/addrtypes.h
@@ -87,10 +87,14 @@ typedef intINT;
 #endif

 #ifndef ADDR_FASTCALL
-#if defined(__GNUC__)
-#define ADDR_FASTCALL __attribute__((regparm(0)))
+#if defined(__i386__)
+   #if defined(__GNUC__)
+#define ADDR_FASTCALL __attribute__((regparm(0)))
+#else
+#define ADDR_FASTCALL __fastcall
+#endif
 #else
-#define ADDR_FASTCALL __fastcall
+   #define ADDR_FASTCALL
 #endif
 #endif



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

Re: [Mesa-dev] [PATCH 7/7] tgsi/scan: scan texture offset operands

[Nicolai Hähnle]

I don't feel so happy about adding the scans that don't have a clear 
plan of use. I see how the scan for atomic access could be interesting 
though. Anyway, the changes themselves look fine, so for the series:


Reviewed-by: Nicolai Hähnle 

On 20.10.2016 20:08, Marek Olšák wrote:

From: Marek Olšák 

This seems important considering how much we depend on some of the flags.
---
 src/gallium/auxiliary/tgsi/tgsi_scan.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/src/gallium/auxiliary/tgsi/tgsi_scan.c 
b/src/gallium/auxiliary/tgsi/tgsi_scan.c
index 00f55c7..cbb3eec 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_scan.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_scan.c
@@ -361,20 +361,36 @@ scan_instruction(struct tgsi_shader_info *info,
if (fullinst->Instruction.Opcode >= TGSI_OPCODE_F2D &&
fullinst->Instruction.Opcode <= TGSI_OPCODE_DSSG)
   info->uses_doubles = TRUE;

for (i = 0; i < fullinst->Instruction.NumSrcRegs; i++) {
   scan_src_operand(info, fullinst, >Src[i], i,
tgsi_util_get_inst_usage_mask(fullinst, i),
is_interp_instruction, _mem_inst);
}

+   if (fullinst->Instruction.Texture) {
+  for (i = 0; i < fullinst->Texture.NumOffsets; i++) {
+ struct tgsi_full_src_register src = {};
+
+ src.Register.File = fullinst->TexOffsets[i].File;
+ src.Register.Index = fullinst->TexOffsets[i].Index;
+ src.Register.SwizzleX = fullinst->TexOffsets[i].SwizzleX;
+ src.Register.SwizzleY = fullinst->TexOffsets[i].SwizzleY;
+ src.Register.SwizzleZ = fullinst->TexOffsets[i].SwizzleZ;
+
+ /* The usage mask is suboptimal but should be safe. */
+ scan_src_operand(info, fullinst, , 0, TGSI_WRITEMASK_XYZ,
+  false, _mem_inst);
+  }
+   }
+
/* check for indirect register writes */
for (i = 0; i < fullinst->Instruction.NumDstRegs; i++) {
   const struct tgsi_full_dst_register *dst = >Dst[i];
   if (dst->Register.Indirect) {
  info->indirect_files |= (1 << dst->Register.File);
  info->indirect_files_written |= (1 << dst->Register.File);
   }

   if (dst->Register.Dimension && dst->Dimension.Indirect)
  info->dim_indirect_files |= 1u << dst->Register.File;


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

[Mesa-dev] [PATCH] gallium: add PIPE_CAP_STREAM_OUTPUT_INTERLEAVE_BUFFERS

[Ilia Mirkin]

This allows the driver to signal that it can't handle random
interleaving of attributes across buffers. This is required for
ARB_transform_feedback3, and it's initialized to whatever the previous
value of PIPE_CAP_STREAM_OUTPUT_PAUSE_RESUME was except for nv50 where
it is disabled. Note that the proprietary drivers never expose
ARB_transform_feedback3 on any GT21x's (where nouveau previously did),
and after some effort I was unable to get it to work.

Signed-off-by: Ilia Mirkin 
---
 docs/features.txt| 2 +-
 src/gallium/docs/source/screen.rst   | 3 +++
 src/gallium/drivers/freedreno/freedreno_screen.c | 1 +
 src/gallium/drivers/i915/i915_screen.c   | 1 +
 src/gallium/drivers/ilo/ilo_screen.c | 1 +
 src/gallium/drivers/llvmpipe/lp_screen.c | 1 +
 src/gallium/drivers/nouveau/nv30/nv30_screen.c   | 1 +
 src/gallium/drivers/nouveau/nv50/nv50_screen.c   | 1 +
 src/gallium/drivers/nouveau/nvc0/nvc0_screen.c   | 1 +
 src/gallium/drivers/r300/r300_screen.c   | 1 +
 src/gallium/drivers/r600/r600_pipe.c | 1 +
 src/gallium/drivers/radeonsi/si_pipe.c   | 1 +
 src/gallium/drivers/softpipe/sp_screen.c | 1 +
 src/gallium/drivers/svga/svga_screen.c   | 1 +
 src/gallium/drivers/swr/swr_screen.cpp   | 1 +
 src/gallium/drivers/vc4/vc4_screen.c | 1 +
 src/gallium/drivers/virgl/virgl_screen.c | 1 +
 src/gallium/include/pipe/p_defines.h | 1 +
 src/mesa/state_tracker/st_extensions.c   | 2 +-
 19 files changed, 21 insertions(+), 2 deletions(-)

diff --git a/docs/features.txt b/docs/features.txt
index a677bfb..2c6691f 100644
--- a/docs/features.txt
+++ b/docs/features.txt
@@ -133,7 +133,7 @@ GL 4.0, GLSL 4.00 --- all DONE: i965/gen8+, nvc0, r600, 
radeonsi
   GL_ARB_texture_gather DONE (i965/gen6+, 
nv50, llvmpipe, softpipe, swr)
   GL_ARB_texture_query_lod  DONE (i965, nv50, 
softpipe)
   GL_ARB_transform_feedback2DONE (i965/gen7+, 
nv50, llvmpipe, softpipe, swr)
-  GL_ARB_transform_feedback3DONE (i965/gen7+, 
nv50, llvmpipe, softpipe, swr)
+  GL_ARB_transform_feedback3DONE (i965/gen7+, 
llvmpipe, softpipe, swr)
 
 
 GL 4.1, GLSL 4.10 --- all DONE: i965/gen8+, nvc0, r600, radeonsi
diff --git a/src/gallium/docs/source/screen.rst 
b/src/gallium/docs/source/screen.rst
index d79e75e..6ad2bec 100644
--- a/src/gallium/docs/source/screen.rst
+++ b/src/gallium/docs/source/screen.rst
@@ -361,6 +361,9 @@ The integer capabilities:
   equal interpolation qualifiers.
   Components may overlap, notably when the gaps in an array of dvec3 are
   filled in.
+* ``PIPE_CAP_STREAM_OUTPUT_INTERLEAVE_BUFFERS``: Whether interleaved stream
+  output mode is able to interleave across buffers. This is required for
+  ARB_transform_feedback3.
 
 
 .. _pipe_capf:
diff --git a/src/gallium/drivers/freedreno/freedreno_screen.c 
b/src/gallium/drivers/freedreno/freedreno_screen.c
index 1f7c2a5..97da0d7 100644
--- a/src/gallium/drivers/freedreno/freedreno_screen.c
+++ b/src/gallium/drivers/freedreno/freedreno_screen.c
@@ -307,6 +307,7 @@ fd_screen_get_param(struct pipe_screen *pscreen, enum 
pipe_cap param)
return PIPE_MAX_SO_BUFFERS;
return 0;
case PIPE_CAP_STREAM_OUTPUT_PAUSE_RESUME:
+   case PIPE_CAP_STREAM_OUTPUT_INTERLEAVE_BUFFERS:
if (is_ir3(screen))
return 1;
return 0;
diff --git a/src/gallium/drivers/i915/i915_screen.c 
b/src/gallium/drivers/i915/i915_screen.c
index 003f855..bfadca3 100644
--- a/src/gallium/drivers/i915/i915_screen.c
+++ b/src/gallium/drivers/i915/i915_screen.c
@@ -282,6 +282,7 @@ i915_get_param(struct pipe_screen *screen, enum pipe_cap 
cap)
 
case PIPE_CAP_MAX_DUAL_SOURCE_RENDER_TARGETS:
case PIPE_CAP_STREAM_OUTPUT_PAUSE_RESUME:
+   case PIPE_CAP_STREAM_OUTPUT_INTERLEAVE_BUFFERS:
case PIPE_CAP_VERTEX_BUFFER_OFFSET_4BYTE_ALIGNED_ONLY:
case PIPE_CAP_VERTEX_BUFFER_STRIDE_4BYTE_ALIGNED_ONLY:
case PIPE_CAP_VERTEX_ELEMENT_SRC_OFFSET_4BYTE_ALIGNED_ONLY:
diff --git a/src/gallium/drivers/ilo/ilo_screen.c 
b/src/gallium/drivers/ilo/ilo_screen.c
index 1904cd6..f3f182c 100644
--- a/src/gallium/drivers/ilo/ilo_screen.c
+++ b/src/gallium/drivers/ilo/ilo_screen.c
@@ -399,6 +399,7 @@ ilo_get_param(struct pipe_screen *screen, enum pipe_cap 
param)
case PIPE_CAP_MAX_STREAM_OUTPUT_INTERLEAVED_COMPONENTS:
   return ILO_MAX_SO_BINDINGS;
case PIPE_CAP_STREAM_OUTPUT_PAUSE_RESUME:
+   case PIPE_CAP_STREAM_OUTPUT_INTERLEAVE_BUFFERS:
   if (ilo_dev_gen(>dev) >= ILO_GEN(7))
  return is->dev.has_gen7_sol_reset;
   else
diff --git a/src/gallium/drivers/llvmpipe/lp_screen.c 
b/src/gallium/drivers/llvmpipe/lp_screen.c
index 3e4f1ef..4b502f0 100644
--- 

Re: [Mesa-dev] [PATCH] radv: allow cmask transitions without fast clear

[Edward O'Callaghan]

Acked-by: Edward O'Callaghan 

On 10/21/2016 10:36 AM, Dave Airlie wrote:
> From: Dave Airlie 
> 
> This fixes
> dEQP-VK.pipeline.multisample.sampled_image*
> 
> These all render to multisampled image, and then
> sample from it, so we must transition it correctly,
> since we have a cmask and fmask this will cause
> the correct transition.
> 
> Cc: "13.0" 
> Signed-off-by: Dave Airlie 
> ---
>  src/amd/vulkan/radv_cmd_buffer.c | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/src/amd/vulkan/radv_cmd_buffer.c 
> b/src/amd/vulkan/radv_cmd_buffer.c
> index 3f1a6f4..690c739 100644
> --- a/src/amd/vulkan/radv_cmd_buffer.c
> +++ b/src/amd/vulkan/radv_cmd_buffer.c
> @@ -2163,9 +2163,6 @@ static void radv_handle_cmask_image_transition(struct 
> radv_cmd_buffer *cmd_buffe
>   radv_initialise_cmask(cmd_buffer, image, 0xu);
>   } else if (radv_layout_has_cmask(image, src_layout) &&
>  !radv_layout_has_cmask(image, dst_layout)) {
> -
> - if (!cmd_buffer->device->allow_fast_clears)
> - return;
>   radv_fast_clear_flush_image_inplace(cmd_buffer, image);
>   }
>  }
> 



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

Re: [Mesa-dev] [PATCH 5/5] nv50/ir: detect when a SLCT is equivalent to a SET

[Ilia Mirkin]

On Fri, Oct 21, 2016 at 2:39 AM, Karol Herbst  wrote:
>
>
> On 21 October 2016 8:30:33 a.m. GMT+02:00, Ilia Mirkin  
> wrote:
>>Signed-off-by: Ilia Mirkin 
>>---
>>.../drivers/nouveau/codegen/nv50_ir_peephole.cpp   | 23
>>++
>> 1 file changed, 19 insertions(+), 4 deletions(-)
>>
>>diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
>>b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
>>index f6fce44..c555430 100644
>>--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
>>+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
>>@@ -637,10 +637,25 @@ ConstantFolding::expr(Instruction *i,
>>   }
>>   break;
>>case OP_SLCT:
>>-  if (a->data.u32 != b->data.u32)
>>- return;
>>-  res.data.u32 = a->data.u32;
>>-  break;
>>+  if (a->data.u32 == b->data.u32) {
>>+ res.data.u32 = a->data.u32;
>>+ break;
>>+  }
>>+  if ((a->data.u32 == 0 && b->data.u32 == 0x) ||
>>+  (b->data.u32 == 0 && a->data.u32 == 0x)) {
>>+ bld.setPosition(i, false);
>
> why do you need the bld.setPosition here?

Because an earlier version of the code had a bld.loadImm(0). However I
cleverly got rid of that, and stupidly forgot the bld.setPosition.

>
>>+ CmpInstruction *ci = i->asCmp();
>>+ i->op = OP_SET;
>>+ i->dType = TYPE_U32;
>>+ if (a->data.u32 == 0) {
>>+ci->setCond = inverseCondCode(ci->setCond);
>>+i->setSrc(1, i->getSrc(0));
>>+ }
>>+ i->setSrc(0, i->getSrc(2));
>>+ i->moveSources(3, -1);
>>+ ++foldCount;
>>+  }
>>+  return;
>>case OP_EXTBF: {
>>   int offset = b->data.u32 & 0xff;
>>   int width = (b->data.u32 >> 8) & 0xff;
>>--
>>2.7.3
>>
>>___
>>mesa-dev mailing list
>>mesa-dev@lists.freedesktop.org
>>https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 5/5] nv50/ir: detect when a SLCT is equivalent to a SET

[Karol Herbst]

On 21 October 2016 8:30:33 a.m. GMT+02:00, Ilia Mirkin  
wrote:
>Signed-off-by: Ilia Mirkin 
>---
>.../drivers/nouveau/codegen/nv50_ir_peephole.cpp   | 23
>++
> 1 file changed, 19 insertions(+), 4 deletions(-)
>
>diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
>b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
>index f6fce44..c555430 100644
>--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
>+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
>@@ -637,10 +637,25 @@ ConstantFolding::expr(Instruction *i,
>   }
>   break;
>case OP_SLCT:
>-  if (a->data.u32 != b->data.u32)
>- return;
>-  res.data.u32 = a->data.u32;
>-  break;
>+  if (a->data.u32 == b->data.u32) {
>+ res.data.u32 = a->data.u32;
>+ break;
>+  }
>+  if ((a->data.u32 == 0 && b->data.u32 == 0x) ||
>+  (b->data.u32 == 0 && a->data.u32 == 0x)) {
>+ bld.setPosition(i, false);

why do you need the bld.setPosition here?

>+ CmpInstruction *ci = i->asCmp();
>+ i->op = OP_SET;
>+ i->dType = TYPE_U32;
>+ if (a->data.u32 == 0) {
>+ci->setCond = inverseCondCode(ci->setCond);
>+i->setSrc(1, i->getSrc(0));
>+ }
>+ i->setSrc(0, i->getSrc(2));
>+ i->moveSources(3, -1);
>+ ++foldCount;
>+  }
>+  return;
>case OP_EXTBF: {
>   int offset = b->data.u32 & 0xff;
>   int width = (b->data.u32 >> 8) & 0xff;
>-- 
>2.7.3
>
>___
>mesa-dev mailing list
>mesa-dev@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

Re: [Mesa-dev] [PATCH v2.1] i965/gen7: expose OpenGL 4.0 on Haswell

[Iago Toral]

On Thu, 2016-10-20 at 16:25 -0700, Ian Romanick wrote:
> On 10/20/2016 12:09 AM, Iago Toral Quiroga wrote:
> > 
> > ARB_gpu_shader_fp64 was the last piece missing. Notice that some
> > hardware and kernel combinations do not support pipelined register
> > writes, which are required for some OpenGL 4.0 features, in which
> > case the driver won't expose 4.0.
> > 
> > v2 (Ian, Ken):
> >   - We should not set max_gl_core_version to 40 if we don't support
> > pipelined register writes. If we did that, then we would allow
> > the creation of GL4 contexts but the actual context we create
> > might only be 3.3. Check that we support this by looking at the
> > Kernel's supported command parser version. This requires
> > that we get the supported command parser version before we call
> > set_max_gl_versions() too.
> > ---
> >  src/mesa/drivers/dri/i965/intel_extensions.c |  2 ++
> >  src/mesa/drivers/dri/i965/intel_screen.c | 13 +++--
> >  2 files changed, 9 insertions(+), 6 deletions(-)
> > 
> > diff --git a/src/mesa/drivers/dri/i965/intel_extensions.c
> > b/src/mesa/drivers/dri/i965/intel_extensions.c
> > index 9cc22cc..8370dc4 100644
> > --- a/src/mesa/drivers/dri/i965/intel_extensions.c
> > +++ b/src/mesa/drivers/dri/i965/intel_extensions.c
> > @@ -272,6 +272,8 @@ intelInitExtensions(struct gl_context *ctx)
> >  
> > if (brw->gen >= 8)
> >    ctx->Const.GLSLVersion = 450;
> > +   else if (brw->is_haswell && brw->screen->cmd_parser_version >=
> > 2)
> > +  ctx->Const.GLSLVersion = 400;
> The GLSL version is (eventually) clamped by the GL version, so this
> doesn't matter as much.  I'm fine with it either way.

In that case I'll remove the check for simplicity.

> Reviewed-by: Ian Romanick 

Thanks!

> > 
> > else if (brw->gen >= 6)
> >    ctx->Const.GLSLVersion = 330;
> > else
> > diff --git a/src/mesa/drivers/dri/i965/intel_screen.c
> > b/src/mesa/drivers/dri/i965/intel_screen.c
> > index e1c3c19..20d75a2 100644
> > --- a/src/mesa/drivers/dri/i965/intel_screen.c
> > +++ b/src/mesa/drivers/dri/i965/intel_screen.c
> > @@ -1445,7 +1445,8 @@ set_max_gl_versions(struct intel_screen
> > *screen)
> >    dri_screen->max_gl_es2_version = has_astc ? 32 : 31;
> >    break;
> > case 7:
> > -  dri_screen->max_gl_core_version = 33;
> > +  dri_screen->max_gl_core_version =
> > + screen->devinfo.is_haswell && screen->cmd_parser_version
> > >= 2 ? 40 : 33;
> >    dri_screen->max_gl_compat_version = 30;
> >    dri_screen->max_gl_es1_version = 11;
> >    dri_screen->max_gl_es2_version = screen->devinfo.is_haswell
> > ? 31 : 30;
> > @@ -1650,6 +1651,11 @@ __DRIconfig **intelInitScreen2(__DRIscreen
> > *dri_screen)
> >    screen->winsys_msaa_samples_override = -1;
> > }
> >  
> > +   if (intel_get_param(screen, I915_PARAM_CMD_PARSER_VERSION,
> > +   >cmd_parser_version) < 0) {
> > +  screen->cmd_parser_version = 0;
> > +   }
> > +
> > set_max_gl_versions(screen);
> >  
> > /* Notification of GPU resets requires hardware contexts and a
> > kernel new
> > @@ -1671,11 +1677,6 @@ __DRIconfig **intelInitScreen2(__DRIscreen
> > *dri_screen)
> >   (ret != -1 || errno != EINVAL);
> > }
> >  
> > -   if (intel_get_param(screen, I915_PARAM_CMD_PARSER_VERSION,
> > -   >cmd_parser_version) < 0) {
> > -  screen->cmd_parser_version = 0;
> > -   }
> > -
> > /* Haswell requires command parser version 6 in order to write
> > to the
> >  * MI_MATH GPR registers, and version 7 in order to use
> >  * MI_LOAD_REGISTER_REG (which all users of MI_MATH use).
> > 
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 5/5] nv50/ir: detect when a SLCT is equivalent to a SET

[Ilia Mirkin]

Signed-off-by: Ilia Mirkin 
---
 .../drivers/nouveau/codegen/nv50_ir_peephole.cpp   | 23 ++
 1 file changed, 19 insertions(+), 4 deletions(-)

diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
index f6fce44..c555430 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
@@ -637,10 +637,25 @@ ConstantFolding::expr(Instruction *i,
   }
   break;
case OP_SLCT:
-  if (a->data.u32 != b->data.u32)
- return;
-  res.data.u32 = a->data.u32;
-  break;
+  if (a->data.u32 == b->data.u32) {
+ res.data.u32 = a->data.u32;
+ break;
+  }
+  if ((a->data.u32 == 0 && b->data.u32 == 0x) ||
+  (b->data.u32 == 0 && a->data.u32 == 0x)) {
+ bld.setPosition(i, false);
+ CmpInstruction *ci = i->asCmp();
+ i->op = OP_SET;
+ i->dType = TYPE_U32;
+ if (a->data.u32 == 0) {
+ci->setCond = inverseCondCode(ci->setCond);
+i->setSrc(1, i->getSrc(0));
+ }
+ i->setSrc(0, i->getSrc(2));
+ i->moveSources(3, -1);
+ ++foldCount;
+  }
+  return;
case OP_EXTBF: {
   int offset = b->data.u32 & 0xff;
   int width = (b->data.u32 >> 8) & 0xff;
-- 
2.7.3

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

[Mesa-dev] [PATCH 3/5] nv50/ir: it appears that OP_DISCARD can't take a join modifier

[Ilia Mirkin]

nvdisasm does not print a .S even though the bit is set.

Signed-off-by: Ilia Mirkin 
---
 src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
index cc5d1f4..f6fce44 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
@@ -2970,6 +2970,7 @@ FlatteningPass::visit(BasicBlock *bb)
  insn = insn->prev;
  if (insn && !insn->getPredicate() &&
  !insn->asFlow() &&
+ insn->op != OP_DISCARD &&
  insn->op != OP_TEXBAR &&
  !isTextureOp(insn->op) && // probably just nve4
  !isSurfaceOp(insn->op) && // not confirmed
-- 
2.7.3

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

[Mesa-dev] [PATCH 2/5] nvc0/ir: use levelZero flag when the lod is set to 0

[Ilia Mirkin]

Signed-off-by: Ilia Mirkin 
---
 src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp | 9 +
 1 file changed, 9 insertions(+)

diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
index 68f2b15..4181422 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
@@ -662,6 +662,15 @@ NVC0LoweringPass::handleTEX(TexInstruction *i)
   }
}
 
+   ImmediateValue lod;
+   if (!i->tex.target.isMS() && (i->op == OP_TXL || i->op == OP_TXF) &&
+   i->src(arg).getImmediate(lod) && lod.isInteger(0)) {
+  if (i->op == OP_TXL)
+ i->op = OP_TEX;
+  i->tex.levelZero = true;
+  i->moveSources(arg, -1);
+   }
+
// Arguments to the TEX instruction are a little insane. Even though the
// encoding is identical between SM20 and SM30, the arguments mean
// different things between Fermi and Kepler+. A lot of arguments are
-- 
2.7.3

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

[Mesa-dev] [PATCH 4/5] nv50/ir: don't carefully copy NOP values as a result of phi merging

[Ilia Mirkin]

In order to avoid impossible phi constraints, we insert moves in source
BBs to allow the RA to have the flexibility it needs. However there's
special logic in the RA to ignore NOPs. It's quite silly to then have
logic which carefully copies NOP values into registers. Leave the LValue
to be defined only by a NOP. (However it still needs a fresh
instruction as the LValue still gets a register assigned, we just
eliminate the instruction later.)

Signed-off-by: Ilia Mirkin 
---
 src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp
index 77a28a2..e5f4305 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp
@@ -470,9 +470,13 @@ RegAlloc::PhiMovesPass::visit(BasicBlock *bb)
 
   for (phi = bb->getPhi(); phi && phi->op == OP_PHI; phi = phi->next) {
  LValue *tmp = new_LValue(func, phi->getDef(0)->asLValue());
- mov = new_Instruction(func, OP_MOV, typeOfSize(tmp->reg.size));
-
- mov->setSrc(0, phi->getSrc(j));
+ Instruction *src = phi->getSrc(j)->getInsn();
+ if (src && src->op == OP_NOP) {
+mov = new_Instruction(func, OP_NOP, typeOfSize(tmp->reg.size));
+ } else {
+mov = new_Instruction(func, OP_MOV, typeOfSize(tmp->reg.size));
+mov->setSrc(0, phi->getSrc(j));
+ }
  mov->setDef(0, tmp);
  phi->setSrc(j, tmp);
 
-- 
2.7.3

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

[Mesa-dev] [PATCH 1/5] nv50/ir: use levelZero for non-frag tex/txp ops

[Ilia Mirkin]

radeonsi also does the same thing. I suspect that this is likely to be a
no-op in reality, but it brings nouveau code closer to what the blob
produces. Plus it makes sense to not try to do auto-derivatives on this.

Signed-off-by: Ilia Mirkin 
---
 src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp | 5 +
 1 file changed, 5 insertions(+)

diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
index 96bdd4e..80fbaed 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
@@ -2237,6 +2237,11 @@ Converter::handleTEX(Value *dst[4], int R, int S, int L, 
int C, int Dx, int Dy)
 
if (tgsi.getOpcode() == TGSI_OPCODE_SAMPLE_C_LZ)
   texi->tex.levelZero = true;
+   if (prog->getType() != Program::TYPE_FRAGMENT &&
+   (tgsi.getOpcode() == TGSI_OPCODE_TEX ||
+tgsi.getOpcode() == TGSI_OPCODE_TEX2 ||
+tgsi.getOpcode() == TGSI_OPCODE_TXP))
+  texi->tex.levelZero = true;
if (tgsi.getOpcode() == TGSI_OPCODE_TG4 && !tgt.isShadow())
   texi->tex.gatherComp = tgsi.getSrc(1).getValueU32(0, info);
 
-- 
2.7.3

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

Re: [Mesa-dev] [PATCH 2/2] glsl: update default precision qualifiers when they are set in the shader

[Samuel Iglesias Gonsálvez]

On 21/10/16 07:48, Timothy Arceri wrote:
> On Thu, 2016-10-20 at 12:39 +0200, Samuel Iglesias Gonsálvez wrote:
>> For that, we use gls_symbol_table::set_default_precision_qualifier()
>> that
>> can update an existing definition or add a new one if it doesn't
>> exist.
>>
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97804
>> Signed-off-by: Samuel Iglesias Gonsálvez 
> 
> Hi Samuel,
> 
> It looks like the parser pushes and pops scope of the symbol table so
> these changes should work. However it would be nice to see some piglit
> tests for this before landing these patches.
> 

Sure, I will write them.

>> ---
>>  src/compiler/glsl/ast_to_hir.cpp|  2 +-
>>  src/compiler/glsl/glsl_symbol_table.cpp | 15 +++
>>  src/compiler/glsl/glsl_symbol_table.h   |  2 ++
>>  3 files changed, 18 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/compiler/glsl/ast_to_hir.cpp
>> b/src/compiler/glsl/ast_to_hir.cpp
>> index 6e2f253..cc50ff8 100644
>> --- a/src/compiler/glsl/ast_to_hir.cpp
>> +++ b/src/compiler/glsl/ast_to_hir.cpp
>> @@ -6559,7 +6559,7 @@ ast_type_specifier::hir(exec_list
>> *instructions,
>>* is a slight abuse of the symbol table, but it has the
>> semantics
>>* that we want.
>>*/
>> - state->symbols->add_default_precision_qualifier(this-
>>> type_name,
>> + state->symbols->set_default_precision_qualifier(this-
>>> type_name,
>>   this-
>>> default_precision);
>>}
>>  
>> diff --git a/src/compiler/glsl/glsl_symbol_table.cpp
>> b/src/compiler/glsl/glsl_symbol_table.cpp
>> index 6d7baad..11e5c00 100644
>> --- a/src/compiler/glsl/glsl_symbol_table.cpp
>> +++ b/src/compiler/glsl/glsl_symbol_table.cpp
>> @@ -258,6 +258,21 @@ int
>> glsl_symbol_table::get_default_precision_qualifier(const char
>> *type_name)
>> return entry->a->default_precision;
>>  }
>>  
>> +bool glsl_symbol_table::set_default_precision_qualifier(const char
>> *type_name,
>> +int
>> precision)
>> +{
>> +   char *name = ralloc_asprintf(mem_ctx, "#default_precision_%s",
>> type_name);
>> +   symbol_table_entry *entry = get_entry(name);
>> +   if (!entry)
>> +  return add_default_precision_qualifier(type_name, precision);
> 
> I think I would rather just see this completely
> replace add_default_precision_qualifier() rather than duplicating a
> bunch of code. What do you think? I don't think avoiding
> the get_entry() call saves us much.
> 

Right, I though that too. I will write a v2 with that change.

Thanks,

Sam

>> +
>> +   ast_type_specifier *default_specifier = new(mem_ctx)
>> ast_type_specifier(name);
>> +   default_specifier->default_precision = precision;
>> +
>> +   entry = new(mem_ctx) symbol_table_entry(default_specifier);
>> +   return _mesa_symbol_table_replace_symbol(table, -1, name, entry)
>> == 0;
>> +}
>> +
>>  symbol_table_entry *glsl_symbol_table::get_entry(const char *name)
>>  {
>> return (symbol_table_entry *)
>> diff --git a/src/compiler/glsl/glsl_symbol_table.h
>> b/src/compiler/glsl/glsl_symbol_table.h
>> index 2f94d4c..69a6912 100644
>> --- a/src/compiler/glsl/glsl_symbol_table.h
>> +++ b/src/compiler/glsl/glsl_symbol_table.h
>> @@ -90,6 +90,8 @@ struct glsl_symbol_table {
>> const glsl_type *get_interface(const char *name,
>>enum ir_variable_mode mode);
>> int get_default_precision_qualifier(const char *type_name);
>> +   bool set_default_precision_qualifier(const char *type_name, int
>> precision);
>> +
>> /*@}*/
>>  
>> /**
> 



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