Re: [Mesa-dev] [PATCH] Revert "glsl: don't reference shader prog data during cache fallback"

[Timothy Arceri]

On 18/05/17 13:11, Timothy Arceri wrote:

On 17/05/17 22:50, Nicolai Hähnle wrote:

On 17.05.2017 14:26, Timothy Arceri wrote:

On 17/05/17 22:03, Nicolai Hähnle wrote:

On 17.05.2017 01:49, Timothy Arceri wrote:
This might work for gallium based drivers but I'm pretty sure this 
will

cause problems for the i965 fallback path.


What do those problems look like?


Sorry, I meant to add more details. The problem is that when the i965
driver has a cache miss for a variant this could be happening long after
link time. By this point we already have a reference and we also can't
just reallocate the shader data because uniforms etc have most likely
been set by this point.


Oh I see, thanks for the explanation.



And any ideas on how to address the issue then? There are a number of
places that assume prog->sh.data is non-NULL.


I'll need to take a closer look at the problem tomorrow. I'm not sure I
understand why it is NULL, I thought the reference happens in the GLSL
IR cache. Is it getting cleared somewhere by the tgsi pass?


As far as I understand, the gl_program object doesn't come from the 
cache in the fallback path. So the reference should happen in the 
place modified by this patch.


I see what has happened, this patch made it in but some other fallback 
patches that should really go along with it were left in the i965 branch.


https://cgit.freedesktop.org/~jljusten/mesa/commit/?h=i965-shader-cache=5d6c2450fe48e777f6c57d9b70653832afa9bccc 

https://cgit.freedesktop.org/~jljusten/mesa/commit/?h=i965-shader-cache=b832afe2c52c946a77b213b94850a765bbaf36af 

https://cgit.freedesktop.org/~jljusten/mesa/commit/?h=i965-shader-cache=d8e8e39cc8b83393eac1bc32c017d312fd9af082 

https://cgit.freedesktop.org/~jljusten/mesa/commit/?h=i965-shader-cache=919ca263e258142aa8649b2b1c640368c1c4bab9 



I can see two solutions:

1. Make use of the mesa_build_fallback_shader_program() helper Jordan 
has created (patch 2 above). This would probably allow us to skip some 
things in the glsl to tgsi pass on fallback.


2. Stop setting cache_fallback in st_load_tgsi_from_disk_cache(). This 
should be safe because unlike i965 we are always falling back at link 
time. We will unnecessarily free and reallocate a bunch of things here 
but it's probably not a huge deal.


Either way we should probably turn the env var in patch 4 above into a 
MESA_GLSL param so that we can force the fallback path for easy testing 
with piglit. I think you will find with this current patch that uniforms 
(among other things) will never be allocated storage on fallback because 
we skip that also.


For stable I think we might just want to land option 2, once we do some 
testing. I think option 1 would need a bit more time sitting in master 
before I was comfortable with it.


Thanks for spotting this, it was an oversight in testing on my behalf.

I've send out a patch for the env var and wait for your thoughts before 
doing anything further.


I changed my mind, I send out the env var patch and a fix that does 
option 2 for now.


https://patchwork.freedesktop.org/series/24601/



Thanks,
Tim



Cheers,
Nicolai





Cheers,
Nicolai




On 17/05/17 04:40, Nicolai Hähnle wrote:

From: Nicolai Hähnle 

This reverts commit 0e9991f957e296f46cfff40a94ffba0adf2a58e1.

At least when we fallback because of TGSI, the gl_program objects are
re-allocated, and we don't in fact already have a reference to the
gl_shader_program_data.

This fixes a crash that can be reproduced as follows:

1. Run any GL program with MESA_GLSL=cache_info.
2. Note the SHA of some tgsi_tokens.
3. Remove the corresponding file from ~/.cache/mesa and re-run.

Cc: 17.1 
---
  src/compiler/glsl/linker.cpp | 3 +--
  src/mesa/main/shaderobj.c| 3 +--
  2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/src/compiler/glsl/linker.cpp
b/src/compiler/glsl/linker.cpp
index 2e7dd2b..4776d09 100644
--- a/src/compiler/glsl/linker.cpp
+++ b/src/compiler/glsl/linker.cpp
@@ -2243,22 +2243,21 @@ link_intrastage_shaders(void *mem_ctx,
 struct gl_program *gl_prog =
ctx->Driver.NewProgram(ctx,

_mesa_shader_stage_to_program(shader_list[0]->Stage),
   prog->Name, false);
 if (!gl_prog) {
prog->data->LinkStatus = linking_failure;
_mesa_delete_linked_shader(ctx, linked);
return NULL;
 }
  -   if (!prog->data->cache_fallback)
-  _mesa_reference_shader_program_data(ctx, _prog->sh.data,
prog->data);
+   _mesa_reference_shader_program_data(ctx, _prog->sh.data,
prog->data);
   /* Don't use _mesa_reference_program() just take ownership */
 linked->Program = gl_prog;
   linked->ir = new(linked) exec_list;
 clone_ir_list(mem_ctx, linked->ir, main->ir);
   link_fs_inout_layout_qualifiers(prog, linked, shader_list,
num_shaders);
 link_tcs_out_layout_qualifiers(prog, gl_prog, shader_list,
num_shaders);
 link_tes_in_layout_qualifiers(prog, 

Re: [Mesa-dev] [PATCH 3/3] st/mesa: don't mark the program as in cache_fallback when there is cache miss

[Timothy Arceri]

On 18/05/17 15:22, Timothy Arceri wrote:

When we fallback currently the gl_program objects are re-allocated.

This is likely to change when the i965 cache lands, but for now
this fixes a crash when using MESA_GLSL=cache_fb. This env var
simulates the fallback path taken when a tgsi cache item doesn't
exist due to being evicted previously or some kind of error.

Unlike i965 we are always falling back at link time so it's safe to
just re-allocate everything. We will be unnecessarily freeing and
re-allocate a bunch of things here but it's probably not a huge deal,
and can be changed when the i965 code lands.


This should have:

Fixes: 0e9991f957e2 ("glsl: don't reference shader prog data during 
cache fallback")


I've added this locally.



Cc: Nicolai Hähnle 
---
  src/mesa/state_tracker/st_shader_cache.c | 1 -
  1 file changed, 1 deletion(-)

diff --git a/src/mesa/state_tracker/st_shader_cache.c 
b/src/mesa/state_tracker/st_shader_cache.c
index 394adbe..bb162cd 100644
--- a/src/mesa/state_tracker/st_shader_cache.c
+++ b/src/mesa/state_tracker/st_shader_cache.c
@@ -388,19 +388,18 @@ st_load_tgsi_from_disk_cache(struct gl_context *ctx,
  fallback_recompile:
 free(buffer);
  
 if (ctx->_Shader->Flags & GLSL_CACHE_INFO)

fprintf(stderr, "TGSI cache falling back to recompile.\n");
  
 for (unsigned i = 0; i < prog->NumShaders; i++) {

_mesa_glsl_compile_shader(ctx, prog->Shaders[i], false, false, true);
 }
  
-   prog->data->cache_fallback = true;

 _mesa_glsl_link_shader(ctx, prog);
  
 /* Turn the fallback flag back on if we disabled it previously */

 if (cache_fb)
ctx->_Shader->Flags |= GLSL_CACHE_FALLBACK;
  
 return true;

  }


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

Re: [Mesa-dev] [PATCH] i965: Add RGBX8888 and RGBA8888 to EGL configure and reorder the list

[Tapani Pälli]

On 05/18/2017 07:10 AM, Chih-Wei Huang wrote:

2017-05-18 12:01 GMT+08:00 Xu, Randy :

-Original Message-
From: Palli, Tapani

It's just applied. Isn't it?
Yesterday without this patch
the color format is mismatch apparently.

Yeah we do need this. TBH I don't quite understand why but will try to figure
it out. I remember we used to have a patch in Surfaceflinger at one point
because visual was hardcoded there and this might be related.

// Tapani

Sorry, that's for different issue, I mix it with RGB565 blending one.
This patch is required because some Android GLES test apps, like gl2_basic, 
need to create RGBA surface.

Indeed it is.

As Emil pointed out, the patch was merged before
but reverted later since it broke desktop.

So what's the current upstreaming plan?



I believe this visual is not supported by our driver properly, as 
example the angeles demo (one of those 'native test apps') has a lot of 
rendering artifacts so at least for now this will be only in Android tree.



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

[Mesa-dev] [PATCH 1/3] st/mesa: improve shader cache debug info

[Timothy Arceri]

This will explicitly state that we are following the fallback
path when we find invalid/corrupt cache items. It will also
output the fallback message when the fallback path is forced
via an environment variable, the following patches will allow
this.
---
 src/mesa/state_tracker/st_shader_cache.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/mesa/state_tracker/st_shader_cache.c 
b/src/mesa/state_tracker/st_shader_cache.c
index 23416c0..175d69d 100644
--- a/src/mesa/state_tracker/st_shader_cache.c
+++ b/src/mesa/state_tracker/st_shader_cache.c
@@ -361,32 +361,34 @@ st_load_tgsi_from_disk_cache(struct gl_context *ctx,
 
  st_set_prog_affected_state_flags(glprog);
  _mesa_associate_uniform_storage(ctx, prog, glprog->Parameters,
  false);
 
  free(buffer);
   } else {
  /* Failed to find a matching cached shader so fallback to recompile.
   */
  if (ctx->_Shader->Flags & GLSL_CACHE_INFO) {
-fprintf(stderr, "TGSI cache item not found falling back to "
-"compile.\n");
+fprintf(stderr, "TGSI cache item not found.\n");
  }
 
  goto fallback_recompile;
   }
}
 
return true;
 
 fallback_recompile:
free(buffer);
 
+   if (ctx->_Shader->Flags & GLSL_CACHE_INFO)
+  fprintf(stderr, "TGSI cache falling back to recompile.\n");
+
for (unsigned i = 0; i < prog->NumShaders; i++) {
   _mesa_glsl_compile_shader(ctx, prog->Shaders[i], false, false, true);
}
 
prog->data->cache_fallback = true;
_mesa_glsl_link_shader(ctx, prog);
 
return true;
 }
-- 
2.9.4

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

[Mesa-dev] [PATCH 2/3] mesa: add an env var to force cache fallback

[Timothy Arceri]

For the gallium state tracker a tgsi binary may have been evicted
from the cache to make space. In this case we would take the
fallback path and recompile/link the shader.

On i965 there are a number of reasons we can get to the program
upload stage and have neither IR nor a valid cached binary.
For example the binary may have been evicted from the cache or
we need a variant that wasn't previously cached.

This environment variable enables us to force the fallback path that
would be taken in these cases and makes it easier to debug these
otherwise hard to reproduce scenarios.

Cc: Jordan Justen 
---
 docs/shading.html|  2 ++
 src/mesa/main/mtypes.h   |  1 +
 src/mesa/main/shaderapi.c|  2 ++
 src/mesa/state_tracker/st_shader_cache.c | 14 +-
 4 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/docs/shading.html b/docs/shading.html
index 7e3d2e4..c789102 100644
--- a/docs/shading.html
+++ b/docs/shading.html
@@ -43,20 +43,22 @@ Contents
 The MESA_GLSL environment variable can be set to a comma-separated
 list of keywords to control some aspects of the GLSL compiler and shader
 execution.  These are generally used for debugging.
 
 
 dump - print GLSL shader code to stdout at link time
 log - log all GLSL shaders to files.
 The filenames will be "shader_X.vert" or "shader_X.frag" where X
 the shader ID.
 cache_info - print debug information about shader cache
+cache_fb - force cached shaders to be ignored and do a full
+recompile via the fallback path
 uniform - print message to stdout when glUniform is called
 nopvert - force vertex shaders to be a simple shader that just 
transforms
 the vertex position with ftransform() and passes through the color and
 texcoord[0] attributes.
 nopfrag - force fragment shader to be a simple shader that passes
 through the color attribute.
 useprog - log glUseProgram calls to stderr
 
 
 Example:  export MESA_GLSL=dump,nopt
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 28d3d948..941311b 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -2970,20 +2970,21 @@ struct gl_shader_program
 
 #define GLSL_DUMP  0x1  /**< Dump shaders to stdout */
 #define GLSL_LOG   0x2  /**< Write shaders to files */
 #define GLSL_UNIFORMS  0x4  /**< Print glUniform calls */
 #define GLSL_NOP_VERT  0x8  /**< Force no-op vertex shaders */
 #define GLSL_NOP_FRAG 0x10  /**< Force no-op fragment shaders */
 #define GLSL_USE_PROG 0x20  /**< Log glUseProgram calls */
 #define GLSL_REPORT_ERRORS 0x40  /**< Print compilation errors */
 #define GLSL_DUMP_ON_ERROR 0x80 /**< Dump shaders to stderr on compile error */
 #define GLSL_CACHE_INFO 0x100 /**< Print debug information about shader cache 
*/
+#define GLSL_CACHE_FALLBACK 0x200 /**< Force shader cache fallback paths */
 
 
 /**
  * Context state for GLSL vertex/fragment shaders.
  * Extended to support pipeline object
  */
 struct gl_pipeline_object
 {
/** Name of the pipeline object as received from glGenProgramPipelines.
 * It would be 0 for shaders without separate shader objects.
diff --git a/src/mesa/main/shaderapi.c b/src/mesa/main/shaderapi.c
index 68fb3fa..325542e 100644
--- a/src/mesa/main/shaderapi.c
+++ b/src/mesa/main/shaderapi.c
@@ -70,20 +70,22 @@ _mesa_get_shader_flags(void)
GLbitfield flags = 0x0;
const char *env = getenv("MESA_GLSL");
 
if (env) {
   if (strstr(env, "dump_on_error"))
  flags |= GLSL_DUMP_ON_ERROR;
   else if (strstr(env, "dump"))
  flags |= GLSL_DUMP;
   if (strstr(env, "log"))
  flags |= GLSL_LOG;
+  if (strstr(env, "cache_fb"))
+ flags |= GLSL_CACHE_FALLBACK;
   if (strstr(env, "cache_info"))
  flags |= GLSL_CACHE_INFO;
   if (strstr(env, "nopvert"))
  flags |= GLSL_NOP_VERT;
   if (strstr(env, "nopfrag"))
  flags |= GLSL_NOP_FRAG;
   if (strstr(env, "uniform"))
  flags |= GLSL_UNIFORMS;
   if (strstr(env, "useprog"))
  flags |= GLSL_USE_PROG;
diff --git a/src/mesa/state_tracker/st_shader_cache.c 
b/src/mesa/state_tracker/st_shader_cache.c
index 175d69d..394adbe 100644
--- a/src/mesa/state_tracker/st_shader_cache.c
+++ b/src/mesa/state_tracker/st_shader_cache.c
@@ -218,22 +218,30 @@ st_load_tgsi_from_disk_cache(struct gl_context *ctx,
}
 
/* Now that we have created the sha1 keys that will be used for writting to
 * the tgsi cache fallback to the regular glsl to tgsi path if we didn't
 * load the GLSL IR from cache. We do this as glsl to tgsi can alter things
 * such as gl_program_parameter_list which holds things like uniforms.
 */
if (prog->data->LinkStatus != linking_skipped)
   return false;
 
-   struct st_context *st = st_context(ctx);
uint8_t *buffer = NULL;
+   bool cache_fb = false;
+   if (ctx->_Shader->Flags & GLSL_CACHE_FALLBACK) {
+  /* Temporarily turn off the flag 

[Mesa-dev] [PATCH 3/3] st/mesa: don't mark the program as in cache_fallback when there is cache miss

[Timothy Arceri]

When we fallback currently the gl_program objects are re-allocated.

This is likely to change when the i965 cache lands, but for now
this fixes a crash when using MESA_GLSL=cache_fb. This env var
simulates the fallback path taken when a tgsi cache item doesn't
exist due to being evicted previously or some kind of error.

Unlike i965 we are always falling back at link time so it's safe to
just re-allocate everything. We will be unnecessarily freeing and
re-allocate a bunch of things here but it's probably not a huge deal,
and can be changed when the i965 code lands.

Cc: Nicolai Hähnle 
---
 src/mesa/state_tracker/st_shader_cache.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/src/mesa/state_tracker/st_shader_cache.c 
b/src/mesa/state_tracker/st_shader_cache.c
index 394adbe..bb162cd 100644
--- a/src/mesa/state_tracker/st_shader_cache.c
+++ b/src/mesa/state_tracker/st_shader_cache.c
@@ -388,19 +388,18 @@ st_load_tgsi_from_disk_cache(struct gl_context *ctx,
 fallback_recompile:
free(buffer);
 
if (ctx->_Shader->Flags & GLSL_CACHE_INFO)
   fprintf(stderr, "TGSI cache falling back to recompile.\n");
 
for (unsigned i = 0; i < prog->NumShaders; i++) {
   _mesa_glsl_compile_shader(ctx, prog->Shaders[i], false, false, true);
}
 
-   prog->data->cache_fallback = true;
_mesa_glsl_link_shader(ctx, prog);
 
/* Turn the fallback flag back on if we disabled it previously */
if (cache_fb)
   ctx->_Shader->Flags |= GLSL_CACHE_FALLBACK;
 
return true;
 }
-- 
2.9.4

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

Re: [Mesa-dev] [PATCH] i965: Add RGBX8888 and RGBA8888 to EGL configure and reorder the list

[Chih-Wei Huang]

2017-05-18 12:01 GMT+08:00 Xu, Randy :
>
>> -Original Message-
>> From: Palli, Tapani
>> >
>> > It's just applied. Isn't it?
>> > Yesterday without this patch
>> > the color format is mismatch apparently.
>>
>> Yeah we do need this. TBH I don't quite understand why but will try to figure
>> it out. I remember we used to have a patch in Surfaceflinger at one point
>> because visual was hardcoded there and this might be related.
>>
>> // Tapani
>
> Sorry, that's for different issue, I mix it with RGB565 blending one.
> This patch is required because some Android GLES test apps, like gl2_basic, 
> need to create RGBA surface.

Indeed it is.

As Emil pointed out, the patch was merged before
but reverted later since it broke desktop.

So what's the current upstreaming plan?


-- 
Chih-Wei
Android-x86 project
http://www.android-x86.org
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] i965: Add RGBX8888 and RGBA8888 to EGL configure and reorder the list

[Xu, Randy]

> -Original Message-
> From: Palli, Tapani
> Sent: Thursday, May 18, 2017 11:51 AM
> To: Chih-Wei Huang ; Xu, Randy
> 
> Cc: ML mesa-dev ; Emil Velikov
> 
> Subject: Re: [Mesa-dev] [PATCH] i965: Add RGBX and RGBA to EGL
> configure and reorder the list
> 
> On 05/18/2017 06:41 AM, Chih-Wei Huang wrote:
> > 2017-05-18 11:26 GMT+08:00 Xu, Randy :
> >>> -Original Message-
> >>> From: Chih-Wei Huang [mailto:cwhu...@android-x86.org]
> >>> Sent: Thursday, May 18, 2017 11:04 AM
> >>> To: Xu, Randy 
> >>> Cc: Emil Velikov ; ML mesa-dev  >>> d...@lists.freedesktop.org>
> >>> Subject: Re: [Mesa-dev] [PATCH] i965: Add RGBX and RGBA to
> >>> EGL configure and reorder the list
> >>>
> >>> 2017-05-12 12:04 GMT+08:00 Xu, Randy :
>  Thanks, Emil
> 
>  dEQP has patch to exclude 565 blend cases (commit named "Exclude
> >>> RGB565 blending cases from the must-pass"), so we don’t need any
> >>> patches now.
> >>>
> >>> Hi Randy, Tapani,
> >>> I think we still need a patch. Right?
> >>> I see the similar patch is still applied to Android-IA codebase.
> >> Which patch do you means? As Google has excluded the RGB565 for
> >> blending test, we don’t need patch Mesa
> > This one:
> > https://github.com/android-ia/external-
> mesa/commit/72d5e389c6adfbca8ec
> > 18885c93191dc62c78c82
> >
> > It's just applied. Isn't it?
> > Yesterday without this patch
> > the color format is mismatch apparently.
> 
> 
> Yeah we do need this. TBH I don't quite understand why but will try to figure
> it out. I remember we used to have a patch in Surfaceflinger at one point
> because visual was hardcoded there and this might be related.
> 
> // Tapani

Sorry, that's for different issue, I mix it with RGB565 blending one.
This patch is required because some Android GLES test apps, like gl2_basic, 
need to create RGBA surface.

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

Re: [Mesa-dev] [PATCH] i965: Add RGBX8888 and RGBA8888 to EGL configure and reorder the list

[Tapani Pälli]

On 05/18/2017 06:41 AM, Chih-Wei Huang wrote:

2017-05-18 11:26 GMT+08:00 Xu, Randy :

-Original Message-
From: Chih-Wei Huang [mailto:cwhu...@android-x86.org]
Sent: Thursday, May 18, 2017 11:04 AM
To: Xu, Randy 
Cc: Emil Velikov ; ML mesa-dev 
Subject: Re: [Mesa-dev] [PATCH] i965: Add RGBX and RGBA to EGL
configure and reorder the list

2017-05-12 12:04 GMT+08:00 Xu, Randy :

Thanks, Emil

dEQP has patch to exclude 565 blend cases (commit named "Exclude

RGB565 blending cases from the must-pass"), so we don’t need any patches
now.

Hi Randy, Tapani,
I think we still need a patch. Right?
I see the similar patch is still applied to Android-IA codebase.

Which patch do you means? As Google has excluded the RGB565 for blending test, 
we don’t need patch Mesa

This one:
https://github.com/android-ia/external-mesa/commit/72d5e389c6adfbca8ec18885c93191dc62c78c82

It's just applied. Isn't it?
Yesterday without this patch
the color format is mismatch apparently.



Yeah we do need this. TBH I don't quite understand why but will try to 
figure it out. I remember we used to have a patch in Surfaceflinger at 
one point because visual was hardcoded there and this might be related.


// Tapani

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

Re: [Mesa-dev] [PATCH] i965: Add RGBX8888 and RGBA8888 to EGL configure and reorder the list

[Chih-Wei Huang]

2017-05-18 11:26 GMT+08:00 Xu, Randy :
>
>> -Original Message-
>> From: Chih-Wei Huang [mailto:cwhu...@android-x86.org]
>> Sent: Thursday, May 18, 2017 11:04 AM
>> To: Xu, Randy 
>> Cc: Emil Velikov ; ML mesa-dev > d...@lists.freedesktop.org>
>> Subject: Re: [Mesa-dev] [PATCH] i965: Add RGBX and RGBA to EGL
>> configure and reorder the list
>>
>> 2017-05-12 12:04 GMT+08:00 Xu, Randy :
>> > Thanks, Emil
>> >
>> > dEQP has patch to exclude 565 blend cases (commit named "Exclude
>> RGB565 blending cases from the must-pass"), so we don’t need any patches
>> now.
>>
>> Hi Randy, Tapani,
>> I think we still need a patch. Right?
>> I see the similar patch is still applied to Android-IA codebase.
>
> Which patch do you means? As Google has excluded the RGB565 for blending 
> test, we don’t need patch Mesa

This one:
https://github.com/android-ia/external-mesa/commit/72d5e389c6adfbca8ec18885c93191dc62c78c82

It's just applied. Isn't it?
Yesterday without this patch
the color format is mismatch apparently.


-- 
Chih-Wei
Android-x86 project
http://www.android-x86.org
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] i965: Add RGBX8888 and RGBA8888 to EGL configure and reorder the list

[Xu, Randy]

> -Original Message-
> From: Chih-Wei Huang [mailto:cwhu...@android-x86.org]
> Sent: Thursday, May 18, 2017 11:04 AM
> To: Xu, Randy 
> Cc: Emil Velikov ; ML mesa-dev  d...@lists.freedesktop.org>
> Subject: Re: [Mesa-dev] [PATCH] i965: Add RGBX and RGBA to EGL
> configure and reorder the list
> 
> 2017-05-12 12:04 GMT+08:00 Xu, Randy :
> > Thanks, Emil
> >
> > dEQP has patch to exclude 565 blend cases (commit named "Exclude
> RGB565 blending cases from the must-pass"), so we don’t need any patches
> now.
> 
> Hi Randy, Tapani,
> I think we still need a patch. Right?
> I see the similar patch is still applied to Android-IA codebase.

Which patch do you means? As Google has excluded the RGB565 for blending test, 
we don’t need patch Mesa

> 
> 
> --
> Chih-Wei
> Android-x86 project
> http://www.android-x86.org
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] Revert "glsl: don't reference shader prog data during cache fallback"

[Timothy Arceri]

On 17/05/17 22:50, Nicolai Hähnle wrote:

On 17.05.2017 14:26, Timothy Arceri wrote:

On 17/05/17 22:03, Nicolai Hähnle wrote:

On 17.05.2017 01:49, Timothy Arceri wrote:

This might work for gallium based drivers but I'm pretty sure this will
cause problems for the i965 fallback path.


What do those problems look like?


Sorry, I meant to add more details. The problem is that when the i965
driver has a cache miss for a variant this could be happening long after
link time. By this point we already have a reference and we also can't
just reallocate the shader data because uniforms etc have most likely
been set by this point.


Oh I see, thanks for the explanation.



And any ideas on how to address the issue then? There are a number of
places that assume prog->sh.data is non-NULL.


I'll need to take a closer look at the problem tomorrow. I'm not sure I
understand why it is NULL, I thought the reference happens in the GLSL
IR cache. Is it getting cleared somewhere by the tgsi pass?


As far as I understand, the gl_program object doesn't come from the 
cache in the fallback path. So the reference should happen in the place 
modified by this patch.


I see what has happened, this patch made it in but some other fallback 
patches that should really go along with it were left in the i965 branch.


https://cgit.freedesktop.org/~jljusten/mesa/commit/?h=i965-shader-cache=5d6c2450fe48e777f6c57d9b70653832afa9bccc
https://cgit.freedesktop.org/~jljusten/mesa/commit/?h=i965-shader-cache=b832afe2c52c946a77b213b94850a765bbaf36af
https://cgit.freedesktop.org/~jljusten/mesa/commit/?h=i965-shader-cache=d8e8e39cc8b83393eac1bc32c017d312fd9af082
https://cgit.freedesktop.org/~jljusten/mesa/commit/?h=i965-shader-cache=919ca263e258142aa8649b2b1c640368c1c4bab9

I can see two solutions:

1. Make use of the mesa_build_fallback_shader_program() helper Jordan 
has created (patch 2 above). This would probably allow us to skip some 
things in the glsl to tgsi pass on fallback.


2. Stop setting cache_fallback in st_load_tgsi_from_disk_cache(). This 
should be safe because unlike i965 we are always falling back at link 
time. We will unnecessarily free and reallocate a bunch of things here 
but it's probably not a huge deal.


Either way we should probably turn the env var in patch 4 above into a 
MESA_GLSL param so that we can force the fallback path for easy testing 
with piglit. I think you will find with this current patch that uniforms 
(among other things) will never be allocated storage on fallback because 
we skip that also.


For stable I think we might just want to land option 2, once we do some 
testing. I think option 1 would need a bit more time sitting in master 
before I was comfortable with it.


Thanks for spotting this, it was an oversight in testing on my behalf.

I've send out a patch for the env var and wait for your thoughts before 
doing anything further.


Thanks,
Tim



Cheers,
Nicolai





Cheers,
Nicolai




On 17/05/17 04:40, Nicolai Hähnle wrote:

From: Nicolai Hähnle 

This reverts commit 0e9991f957e296f46cfff40a94ffba0adf2a58e1.

At least when we fallback because of TGSI, the gl_program objects are
re-allocated, and we don't in fact already have a reference to the
gl_shader_program_data.

This fixes a crash that can be reproduced as follows:

1. Run any GL program with MESA_GLSL=cache_info.
2. Note the SHA of some tgsi_tokens.
3. Remove the corresponding file from ~/.cache/mesa and re-run.

Cc: 17.1 
---
  src/compiler/glsl/linker.cpp | 3 +--
  src/mesa/main/shaderobj.c| 3 +--
  2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/src/compiler/glsl/linker.cpp
b/src/compiler/glsl/linker.cpp
index 2e7dd2b..4776d09 100644
--- a/src/compiler/glsl/linker.cpp
+++ b/src/compiler/glsl/linker.cpp
@@ -2243,22 +2243,21 @@ link_intrastage_shaders(void *mem_ctx,
 struct gl_program *gl_prog =
ctx->Driver.NewProgram(ctx,

_mesa_shader_stage_to_program(shader_list[0]->Stage),
   prog->Name, false);
 if (!gl_prog) {
prog->data->LinkStatus = linking_failure;
_mesa_delete_linked_shader(ctx, linked);
return NULL;
 }
  -   if (!prog->data->cache_fallback)
-  _mesa_reference_shader_program_data(ctx, _prog->sh.data,
prog->data);
+   _mesa_reference_shader_program_data(ctx, _prog->sh.data,
prog->data);
   /* Don't use _mesa_reference_program() just take ownership */
 linked->Program = gl_prog;
   linked->ir = new(linked) exec_list;
 clone_ir_list(mem_ctx, linked->ir, main->ir);
   link_fs_inout_layout_qualifiers(prog, linked, shader_list,
num_shaders);
 link_tcs_out_layout_qualifiers(prog, gl_prog, shader_list,
num_shaders);
 link_tes_in_layout_qualifiers(prog, gl_prog, shader_list,
num_shaders);
diff --git a/src/mesa/main/shaderobj.c b/src/mesa/main/shaderobj.c
index 8a5fa5e..f6f7bf5 100644
--- a/src/mesa/main/shaderobj.c
+++ 

Re: [Mesa-dev] [PATCH] i965: Add RGBX8888 and RGBA8888 to EGL configure and reorder the list

[Chih-Wei Huang]

2017-05-12 12:04 GMT+08:00 Xu, Randy :
> Thanks, Emil
>
> dEQP has patch to exclude 565 blend cases (commit named "Exclude RGB565 
> blending cases from the must-pass"), so we don’t need any patches now.

Hi Randy, Tapani,
I think we still need a patch. Right?
I see the similar patch is still applied
to Android-IA codebase.


-- 
Chih-Wei
Android-x86 project
http://www.android-x86.org
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] Android: correct libz dependency

[Chih-Wei Huang]

2017-05-17 21:11 GMT+08:00 Emil Velikov :
> On 17 May 2017 at 13:45, Rob Herring  wrote:
>> On Wed, May 17, 2017 at 12:10 AM, Chih-Wei Huang
>>  wrote:
>>> Commit 6facb0c0 ("android: fix libz dynamic library dependencies")
>>> unconditionally adds libz as a dependency to all shared libraries.
>>> That is unnecessary.
>>>
>>> Commit 85a9b1b5 introduced libz as a dependency to libmesa_util.
>>> So only the shared libraries that use libmesa_util need libz.
>>>
>>> Fix Android Lollipop build by adding the include path of zlib to
>>> libmesa_util explicitly instead of getting the path implicitly
>>> from zlib since it doesn't export the include path in Lollipop.
>>>
>>> Fixes: 6facb0c0 "android: fix libz dynamic library dependencies"
>>>
>>> Signed-off-by: Chih-Wei Huang 
>>> ---
>>>  Android.common.mk  | 4 
>>>  src/gallium/targets/dri/Android.mk | 3 ++-
>>>  src/intel/Android.vulkan.mk| 2 +-
>>>  src/mesa/drivers/dri/Android.mk| 3 ++-
>>>  src/util/Android.mk| 1 +
>>>  5 files changed, 6 insertions(+), 7 deletions(-)
>>
>> Reviewed-by: Rob Herring 
> Thanks Rob. Pushed to master.

Thank you.

BTW, since libmesa_util is used by several places,
is it better to change it to a shared library?


-- 
Chih-Wei
Android-x86 project
http://www.android-x86.org
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] glxglvnddispatch: Add missing dispatch for GetDriverConfig

[Hans de Goede]

Hi,

On 17-05-17 14:57, Emil Velikov wrote:

On 16 May 2017 at 22:42, Hans de Goede  wrote:

Hi,


On 05/16/2017 07:51 PM, Emil Velikov wrote:


Hi Hans

Please poke if patches fall through the cracks.

On 20 March 2017 at 11:05, Hans de Goede  wrote:


Together with some fixes to xdriinfo this fixes xdriinfo not working
with glvnd.

Since apps (xdriinfo) expect GetDriverConfig to work without going to
need through the dance to setup a glxcontext (which is a reasonable
expectation IMHO), the dispatch for this ends up significantly different
then any other dispatch function.

This patch gets the job done, but I'm not really happy with how this
patch turned out, suggestions for a better fix are welcome.

Cc: Kyle Brenneman 
Signed-off-by: Hans de Goede 
---
  src/glx/g_glxglvnddispatchfuncs.c   | 18 ++
  src/glx/g_glxglvnddispatchindices.h |  1 +
  2 files changed, 19 insertions(+)

diff --git a/src/glx/g_glxglvnddispatchfuncs.c
b/src/glx/g_glxglvnddispatchfuncs.c
index b5e3398..040cdf8 100644
--- a/src/glx/g_glxglvnddispatchfuncs.c
+++ b/src/glx/g_glxglvnddispatchfuncs.c
@@ -4,6 +4,7 @@
   */
  #include 

+#include "glxclient.h"
  #include "glxglvnd.h"
  #include "glxglvnddispatchfuncs.h"
  #include "g_glxglvnddispatchindices.h"
@@ -50,6 +51,7 @@ const char * const
__glXDispatchTableStrings[DI_LAST_INDEX] = {
  __ATTRIB(GetCurrentDisplayEXT),
  // glXGetCurrentDrawable implemented by libglvnd
  // glXGetCurrentReadDrawable implemented by libglvnd
+__ATTRIB(GetDriverConfig),



Back in Nov 2016 we had a chat with Adam and if I understood things
correctly the idea was to kill off the following:

glXGetScreenDriver
glXGetDriverConfig

Neither of those is part of an extension and the only user xdriinfo,
is not that useful.
Would be great if distributions let it to rest and we don't have to
worry about it ever being around ;-)



The problem is that driconf uses them and people actually use driconf,
see: https://bugzilla.redhat.com/show_bug.cgi?id=1429894


Ouch, had not idea people are still using that behemoth :-(
In that case we cannot nuke the API, so let's merge this patch.

Small nit: please drop the compilation guard. Those should be always
true when compiling the file.

Kyle/others - the GLVND bits are in, aren't they? Do you have any
comments on the patch?

With that the nit
Reviewed-by: Emil Velikov 
Cc: mesa-sta...@lists.freedesktop.org


Thank you, pushed with the nit fixed and the r-b and cc added.

Regards,

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

[Mesa-dev] [RFC v3] drm/i915: Select engines via class and instance in execbuffer2

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Building on top of the previous patch which exported the concept
of engine classes and instances, we can also use this instead of
the current awkward engine selection uAPI.

This is primarily interesting for the VCS engine selection which
is a) currently done via disjoint set of flags, and b) the
current I915_EXEC_BSD flags has different semantics depending on
the underlying hardware which is bad.

Proposed idea here is to reserve 16-bits of flags, to pass in
the engine class and instance (8 bits each), and a new flag
named I915_EXEC_CLASS_INSTACE to tell the kernel this new engine
selection API is in use.

The new uAPI also removes access to the weak VCS engine
balancing as currently existing in the driver.

Example usage to send a command to VCS0:

  eb.flags = i915_execbuffer2_engine(DRM_I915_ENGINE_CLASS_VIDEO_DECODE, 0);

Or to send a command to VCS1:

  eb.flags = i915_execbuffer2_engine(DRM_I915_ENGINE_CLASS_VIDEO_DECODE, 1);

v2:
 * Fix unknown flags mask.
 * Use I915_EXEC_RING_MASK for class. (Chris Wilson)

v3:
 * Add a map for fast class-instance engine lookup. (Chris Wilson)

Signed-off-by: Tvrtko Ursulin 
Cc: Ben Widawsky 
Cc: Chris Wilson 
Cc: Daniel Vetter 
Cc: Joonas Lahtinen 
Cc: Jon Bloomfield 
Cc: Daniel Charles 
Cc: "Rogozhkin, Dmitry V" 
Cc: Oscar Mateo 
Cc: "Gong, Zhipeng" 
Cc: intel-vaapi-me...@lists.01.org
Cc: mesa-dev@lists.freedesktop.org
---
 drivers/gpu/drm/i915/i915_drv.h|  1 +
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 30 ++
 drivers/gpu/drm/i915/i915_reg.h|  3 +++
 drivers/gpu/drm/i915/intel_engine_cs.c |  7 +++
 include/uapi/drm/i915_drm.h| 11 ++-
 5 files changed, 51 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 5dfa4a12e647..7bf4fd42480c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2066,6 +2066,7 @@ struct drm_i915_private {
struct pci_dev *bridge_dev;
struct i915_gem_context *kernel_context;
struct intel_engine_cs *engine[I915_NUM_ENGINES];
+   struct intel_engine_cs *engine_class[MAX_ENGINE_CLASS + 
1][MAX_ENGINE_INSTANCE + 1];
struct i915_vma *semaphore;
 
struct drm_dma_handle *status_page_dmah;
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index af1965774e7b..c1ad49ab64cd 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1492,6 +1492,33 @@ gen8_dispatch_bsd_engine(struct drm_i915_private 
*dev_priv,
return file_priv->bsd_engine;
 }
 
+extern u8 user_class_map[DRM_I915_ENGINE_CLASS_MAX];
+
+static struct intel_engine_cs *get_engine_class(struct drm_i915_private *i915,
+   u8 class, u8 instance)
+{
+   if (class > MAX_ENGINE_CLASS || instance > MAX_ENGINE_INSTANCE)
+   return NULL;
+
+   return i915->engine_class[class][instance];
+}
+
+static struct intel_engine_cs *
+eb_select_engine_class_instance(struct drm_i915_private *i915,
+   struct drm_i915_gem_execbuffer2 *args)
+{
+   u8 class, instance;
+
+   class = args->flags & I915_EXEC_RING_MASK;
+   if (class >= DRM_I915_ENGINE_CLASS_MAX)
+   return NULL;
+
+   instance = (args->flags >> I915_EXEC_INSTANCE_SHIFT) &&
+  I915_EXEC_INSTANCE_MASK;
+
+   return get_engine_class(i915, user_class_map[class], instance);
+}
+
 #define I915_USER_RINGS (4)
 
 static const enum intel_engine_id user_ring_map[I915_USER_RINGS + 1] = {
@@ -1510,6 +1537,9 @@ eb_select_engine(struct drm_i915_private *dev_priv,
unsigned int user_ring_id = args->flags & I915_EXEC_RING_MASK;
struct intel_engine_cs *engine;
 
+   if (args->flags & I915_EXEC_CLASS_INSTANCE)
+   return eb_select_engine_class_instance(dev_priv, args);
+
if (user_ring_id > I915_USER_RINGS) {
DRM_DEBUG("execbuf with unknown ring: %u\n", user_ring_id);
return NULL;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index ee144ec57935..a3b59043b991 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -92,6 +92,9 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
 #define VIDEO_ENHANCEMENT_CLASS2
 #define COPY_ENGINE_CLASS  3
 #define OTHER_CLASS4
+#define MAX_ENGINE_CLASS   4
+
+#define MAX_ENGINE_INSTANCE1
 
 /* PCI config space */
 
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 

Re: [Mesa-dev] [v3 04/19] intel/isl/gen6: Allow arrayed stencil

[Nanley Chery]

On Mon, May 15, 2017 at 03:07:54PM +0300, Topi Pohjolainen wrote:
> Nothing prevents arrayed stencil surfaces even though hardware
> doesn't support mipmapping.
> 
> Signed-off-by: Topi Pohjolainen 
> ---
>  src/intel/isl/isl.c | 1 -
>  1 file changed, 1 deletion(-)
> 

This patch is
Reviewed-by: Nanley Chery 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC] Deprecating old DRI loaders/drivers

[Rob Clark]

On Wed, May 17, 2017 at 5:13 PM, Timothy Arceri  wrote:
> On 18/05/17 04:23, Marek Olšák wrote:
>>
>> On Wed, May 17, 2017 at 7:36 PM, Ilia Mirkin  wrote:
>>>
>>> On Wed, May 17, 2017 at 1:26 PM, Ian Romanick 
>>> wrote:

 On 05/16/2017 09:04 PM, Jason Ekstrand wrote:
>
> On May 16, 2017 18:30:00 Timothy Arceri  wrote:
>
>> On 17/05/17 02:38, Ian Romanick wrote:
>>>
>>> What *actual* problem are you trying to solve?  Honestly, it seems
>>> like
>>> you're just trying to find stuff to do.  We have a mechanism to make
>>> this work, and it's not that hard.  Introducing a deprecation period
>>> and
>>> everything that involves will make it more work, not less.
>
>
> I think that's a fair question
>
>> To be fair aren't we in a stage in Mesa's life-cycle where the focus
>> is
>> on tidying-up / optimisations. It's not like there are large spec
>> updates in the pipeline.
>
>
> If we are genuinely making things more maintainable, then maybe
> deprecation is reasonable.  However, of it's just churn, then it may
> just be a source of new bugs to fix.  I think asking "why?" is
> perfectly
> reasonable.
>
> On the other side, perhaps we should consider instead taking advantage
> of the backwards comparability and dropping some of the old and
> unmaintained drivers from the tree, put them on a critical-bugfix-only
> branch, and recommend that distros build two mesas and only install the
> loader from the newer one.  Dropping i915, r200, and other effectively
> unmaintained drivers from the tree would make it much easier to do core
> state tracker cleanups since there would effectively only be two state
> trackers: gallium and i915. For example, there's a lot of code floating
> around for dealing with hardware that doesn't have native integers.


 r300 and r400 in Gallium do not have native integers.  I don't know
 about NV30.
>>>
>>>
>>> NV30 does not have native integers. Neither does a2xx. Not sure about
>>> etnaviv.
>>>
 I wanted to remove support for NV04 and NV05 last year because they are
 unused, unmaintained, and demonstrably *broken*, and I could not even
 get consensus on that.
>>>
>>>
>>> For the record, they work and are maintained (although imperfect, with
>>> some known breakage). Maintained, to me, means "if someone comes with
>>> an issue, there will be an attempt to address it". But they're rarely
>>> tested, and questionably used by anyone other than the tester (me),
>>> and only on NV5, as I don't have a NV4.
>>>
>>> Separately, I'd definitely consider a discussion about cleaving off
>>> the post-modern-times drivers (DX10+ hardware) from the
>>> pre-modern-times hardware (DX9 and older), and moving those off into a
>>> mesa-pre-dx9 repository. I doubt there are too many bugs/features for
>>> those that would greatly benefit from a shared repository. And mesa
>>> could shed a ton of support code in the process. On both sides.
>>
>>
>> This is the boldest proposal I've seen so far. I have some sentimental
>> feelings about gallium/r300, but if it were the only driver without
>> native integer support blocking some major Mesa cleanup, I would let
>> it go. If we wanna discuss driver removal, the most likely candidates
>> are i915g (completely broken currently) and maybe some classic
>> drivers. I guess some people have feelings about their classic drivers
>> too, but at the end of the day we have to decide what's best for the
>> future.
>>
>
> My thinking was that we would use a separate repository as Ilia is
> suggesting and it would essentially be a separate project from Mesa that
> evolves on its own i.e. the drivers wouldn't just be dropped in a branch
> like the dri1 drivers were and contributors would be free to clean-up all
> the unrelated code that is only used by the new drivers etc.
>
> In this scenario there would be no reason to feel sentimental as the drivers
> would live on and potentially in a better state than staying in Mesa, but
> maybe it's wishful thinking that such a project would gain much support.
>

Just one small annoyance to point out, that the non-pci drivers (ie.
basically the arm ones) don't have a pci-id to decide whether to load
${driver}_dri.so vs ${driver}_old_dri.so, which would be awkward if
the split was based on native-integers or not.

Other than that, Marek is probably right about not having many
contributors for the new tree (or branch).. although maybe that
doesn't matter if at least what used to work continues to work.  It
might be annoying if something new like dri4 came along..

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

Re: [Mesa-dev] [RFC] Deprecating old DRI loaders/drivers

[Timothy Arceri]

On 18/05/17 07:34, Marek Olšák wrote:
On May 17, 2017 11:13 PM, "Timothy Arceri" > wrote:


On 18/05/17 04:23, Marek Olšák wrote:

On Wed, May 17, 2017 at 7:36 PM, Ilia Mirkin
> wrote:

On Wed, May 17, 2017 at 1:26 PM, Ian Romanick
> wrote:

On 05/16/2017 09:04 PM, Jason Ekstrand wrote:

On May 16, 2017 18:30:00 Timothy Arceri
> wrote:

On 17/05/17 02:38, Ian Romanick wrote:

What *actual* problem are you trying to
solve?  Honestly, it seems like
you're just trying to find stuff to do.  We
have a mechanism to make
this work, and it's not that hard. 
Introducing a deprecation period and

everything that involves will make it more
work, not less.


I think that's a fair question

To be fair aren't we in a stage in Mesa's
life-cycle where the focus is
on tidying-up / optimisations. It's not like
there are large spec
updates in the pipeline.


If we are genuinely making things more maintainable,
then maybe
deprecation is reasonable.  However, of it's just
churn, then it may
just be a source of new bugs to fix.  I think asking
"why?" is perfectly
reasonable.

On the other side, perhaps we should consider
instead taking advantage
of the backwards comparability and dropping some of
the old and
unmaintained drivers from the tree, put them on a
critical-bugfix-only
branch, and recommend that distros build two mesas
and only install the
loader from the newer one.  Dropping i915, r200, and
other effectively
unmaintained drivers from the tree would make it
much easier to do core
state tracker cleanups since there would effectively
only be two state
trackers: gallium and i915. For example, there's a
lot of code floating
around for dealing with hardware that doesn't have
native integers.


r300 and r400 in Gallium do not have native integers.  I
don't know
about NV30.


NV30 does not have native integers. Neither does a2xx. Not
sure about etnaviv.

I wanted to remove support for NV04 and NV05 last year
because they are
unused, unmaintained, and demonstrably *broken*, and I
could not even
get consensus on that.


For the record, they work and are maintained (although
imperfect, with
some known breakage). Maintained, to me, means "if someone
comes with
an issue, there will be an attempt to address it". But
they're rarely
tested, and questionably used by anyone other than the
tester (me),
and only on NV5, as I don't have a NV4.

Separately, I'd definitely consider a discussion about
cleaving off
the post-modern-times drivers (DX10+ hardware) from the
pre-modern-times hardware (DX9 and older), and moving those
off into a
mesa-pre-dx9 repository. I doubt there are too many
bugs/features for
those that would greatly benefit from a shared repository.
And mesa
could shed a ton of support code in the process. On both sides.


This is the boldest proposal I've seen so far. I have some
sentimental
feelings about gallium/r300, but if it were the only driver without
native integer support blocking some major Mesa cleanup, I would let
it go. If we wanna discuss driver removal, the most likely
candidates
are i915g (completely broken currently) and maybe some classic
drivers. I guess some people have feelings about their classic
drivers
too, but at the end of the day we have to decide what's best for the
future.


My thinking was that we would use a separate repository as Ilia 

Re: [Mesa-dev] [RFC] Deprecating old DRI loaders/drivers

[Marek Olšák]

On May 17, 2017 11:13 PM, "Timothy Arceri"  wrote:

On 18/05/17 04:23, Marek Olšák wrote:

> On Wed, May 17, 2017 at 7:36 PM, Ilia Mirkin  wrote:
>
>> On Wed, May 17, 2017 at 1:26 PM, Ian Romanick 
>> wrote:
>>
>>> On 05/16/2017 09:04 PM, Jason Ekstrand wrote:
>>>
 On May 16, 2017 18:30:00 Timothy Arceri  wrote:

 On 17/05/17 02:38, Ian Romanick wrote:
>
>> What *actual* problem are you trying to solve?  Honestly, it seems
>> like
>> you're just trying to find stuff to do.  We have a mechanism to make
>> this work, and it's not that hard.  Introducing a deprecation period
>> and
>> everything that involves will make it more work, not less.
>>
>
 I think that's a fair question

 To be fair aren't we in a stage in Mesa's life-cycle where the focus is
> on tidying-up / optimisations. It's not like there are large spec
> updates in the pipeline.
>

 If we are genuinely making things more maintainable, then maybe
 deprecation is reasonable.  However, of it's just churn, then it may
 just be a source of new bugs to fix.  I think asking "why?" is perfectly
 reasonable.

 On the other side, perhaps we should consider instead taking advantage
 of the backwards comparability and dropping some of the old and
 unmaintained drivers from the tree, put them on a critical-bugfix-only
 branch, and recommend that distros build two mesas and only install the
 loader from the newer one.  Dropping i915, r200, and other effectively
 unmaintained drivers from the tree would make it much easier to do core
 state tracker cleanups since there would effectively only be two state
 trackers: gallium and i915. For example, there's a lot of code floating
 around for dealing with hardware that doesn't have native integers.

>>>
>>> r300 and r400 in Gallium do not have native integers.  I don't know
>>> about NV30.
>>>
>>
>> NV30 does not have native integers. Neither does a2xx. Not sure about
>> etnaviv.
>>
>> I wanted to remove support for NV04 and NV05 last year because they are
>>> unused, unmaintained, and demonstrably *broken*, and I could not even
>>> get consensus on that.
>>>
>>
>> For the record, they work and are maintained (although imperfect, with
>> some known breakage). Maintained, to me, means "if someone comes with
>> an issue, there will be an attempt to address it". But they're rarely
>> tested, and questionably used by anyone other than the tester (me),
>> and only on NV5, as I don't have a NV4.
>>
>> Separately, I'd definitely consider a discussion about cleaving off
>> the post-modern-times drivers (DX10+ hardware) from the
>> pre-modern-times hardware (DX9 and older), and moving those off into a
>> mesa-pre-dx9 repository. I doubt there are too many bugs/features for
>> those that would greatly benefit from a shared repository. And mesa
>> could shed a ton of support code in the process. On both sides.
>>
>
> This is the boldest proposal I've seen so far. I have some sentimental
> feelings about gallium/r300, but if it were the only driver without
> native integer support blocking some major Mesa cleanup, I would let
> it go. If we wanna discuss driver removal, the most likely candidates
> are i915g (completely broken currently) and maybe some classic
> drivers. I guess some people have feelings about their classic drivers
> too, but at the end of the day we have to decide what's best for the
> future.
>
>
My thinking was that we would use a separate repository as Ilia is
suggesting and it would essentially be a separate project from Mesa that
evolves on its own i.e. the drivers wouldn't just be dropped in a branch
like the dri1 drivers were and contributors would be free to clean-up all
the unrelated code that is only used by the new drivers etc.


Where can I find the contributors? As far as I know, there are none. It
would be a dead repo from the beginning.

Marek


In this scenario there would be no reason to feel sentimental as the
drivers would live on and potentially in a better state than staying in
Mesa, but maybe it's wishful thinking that such a project would gain much
support.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [Mesa-stable] [PATCH] egl: Partially revert 23c86c74, fix eglMakeCurrent

[Tomasz Figa]

Hi,

On Tue, May 16, 2017 at 11:35 PM, Tapani Pälli  wrote:
>
>
> On 05/16/2017 08:10 PM, Chad Versace wrote:
>>
>> On Tue 16 May 2017, Tapani Pälli wrote:
>>>
>>>
>>>
>>> On 05/16/2017 02:04 AM, Chad Versace wrote:

 Fixes regressions in Android CtsVerifier.apk on Intel Chrome OS devices
 due to incorrect error handling in eglMakeCurrent. See below on how to
 confirm the regression is fixed.

 This partially reverts

   commit 23c86c74cc450a23848b85cfe914376caede1cdf
   Author:  Chad Versace 
   Subject: egl: Emit error when EGLSurface is lost

 The bad commit added the error handling below. #2 and #3 were right,
 but #1 was wrong.

   1. eglMakeCurrent emits EGL_BAD_CURRENT_SURFACE if the calling
  thread has unflushed commands and either previous surface is no
  longer valid.

   2. eglMakeCurrent emits EGL_BAD_NATIVE_WINDOW if either new
 surface
  is no longer valid.

   3. eglSwapBuffers emits EGL_BAD_NATIVE_WINDOW if the swapped
 surface
  is no longer valid.

 Whe I wrote the bad commit, I misunderstood the EGL spec language
 for #1. The correct behavior is, if I understand correctly now:

   - Assume a bound EGLSurface is no longer valid.
   - Assume the bound EGLContext has unflushed commands.
   - The app calls eglMakeCurrent. The spec requires eglMakeCurrent
 to
 implicitly flush. After flushing, eglMakeCurrent emits
 EGL_BAD_CURRENT_SURFACE and does *not* alter the thread's
 current bindings.
   - If the app calls eglMakeCurrent again, and the app inserts no
 commands into the GL command stream between the two
 eglMakeCurrent
 calls, then this second eglMakeCurrent succeeds without emitting
 an
 error.

 How to confirm this fixes the regression:

   Download android-cts-verifier-7.1_r5-linux_x86-x86.zip from
   source.android.com, unpack, and `adb install CtsVerifier.apk`.
   Run test "Projection Cube". Click the Pass button (a
   green checkmark). Then run test "Projection Widget". Confirm that
   widgets are visible and that logcat does not complain about
   eglMakeCurrent failure.

   Then confirm there are no regressions in the cts-traded module
 that
   commit 263243b1 fixed:

   cts-tf > run cts --skip-preconditions --skip-device-info \
-m CtsCameraTestCases \
-t android.hardware.camera2.cts.RobustnessTest

   Tested with Chrome OS board "reef".
>>>
>>>
>>> both tests passed on Android-IA with this patch ... but if I minimize
>>> "Projection Widget" test it starts to bang EGL_BAD_NATIVE_WINDOW heavily.
>>> Is
>>> this expected behavior?
>>
>>
>> I'm unsure. I haven't yet tried that experiment. I'll give it a try when
>> I'm back at my desk.
>>
>> Which EGL function is emitting EGL_BAD_NATIVE_WINDOW in logcat?
>> eglMakeCurrent or eglSwapBuffers, or something else?
>
>
> doh sorry, I actually meant 'Projection Cube' test, not the widget test. But
> yep, when tapping switcher button eglMakeCurrent starts to emit the error
> (likely the app just continues to submit frames even when it's
> 'minimized'?). When switching back to app it cannot draw anymore as it keeps
> getting the error.

I don't remember exactly and I'm not an Android app expert either, but
I remember hearing something that the app needs to stop drawing when
the activity is paused (stopped?). Isn't that what's happening when an
app gets minimized?

Best regards,
Tomasz

>
>> What was the behavior before this patch? And before
>> commit 23c86c74 (egl: Emit error when EGLSurface is lost)?
>
>
> Without this patch (and before commit 23c86c74) I can minimize app to
> switcher and bring it back and it continues to draw.
>
> Note that everything else seems to work just fine though (tested lots of GL
> apps) so is this just something specific what cts-verifier is doing or not
> handling properly?
>
>
>
 Cc: "17.1" 
 Cc: Tomasz Figa 
 Cc: Nicolas Boichat 
 Cc: Emil Velikov 
 Fixes: 23c86c74 (egl: Emit error when EGLSurface is lost)
 ---
src/egl/main/eglapi.c | 19 ---
1 file changed, 19 deletions(-)

 diff --git a/src/egl/main/eglapi.c b/src/egl/main/eglapi.c
 index aa0eb94666..9cea2f41ff 100644
 --- a/src/egl/main/eglapi.c
 +++ b/src/egl/main/eglapi.c
 @@ -828,25 +828,6 @@ eglMakeCurrent(EGLDisplay dpy, EGLSurface draw,
 EGLSurface read,
 RETURN_EGL_ERROR(disp, EGL_BAD_MATCH, EGL_FALSE);
   }
 -   _EGLThreadInfo *t 

Re: [Mesa-dev] [RFC] Deprecating old DRI loaders/drivers

[Timothy Arceri]

On 18/05/17 04:23, Marek Olšák wrote:

On Wed, May 17, 2017 at 7:36 PM, Ilia Mirkin  wrote:

On Wed, May 17, 2017 at 1:26 PM, Ian Romanick  wrote:

On 05/16/2017 09:04 PM, Jason Ekstrand wrote:

On May 16, 2017 18:30:00 Timothy Arceri  wrote:


On 17/05/17 02:38, Ian Romanick wrote:

What *actual* problem are you trying to solve?  Honestly, it seems like
you're just trying to find stuff to do.  We have a mechanism to make
this work, and it's not that hard.  Introducing a deprecation period and
everything that involves will make it more work, not less.


I think that's a fair question


To be fair aren't we in a stage in Mesa's life-cycle where the focus is
on tidying-up / optimisations. It's not like there are large spec
updates in the pipeline.


If we are genuinely making things more maintainable, then maybe
deprecation is reasonable.  However, of it's just churn, then it may
just be a source of new bugs to fix.  I think asking "why?" is perfectly
reasonable.

On the other side, perhaps we should consider instead taking advantage
of the backwards comparability and dropping some of the old and
unmaintained drivers from the tree, put them on a critical-bugfix-only
branch, and recommend that distros build two mesas and only install the
loader from the newer one.  Dropping i915, r200, and other effectively
unmaintained drivers from the tree would make it much easier to do core
state tracker cleanups since there would effectively only be two state
trackers: gallium and i915. For example, there's a lot of code floating
around for dealing with hardware that doesn't have native integers.


r300 and r400 in Gallium do not have native integers.  I don't know
about NV30.


NV30 does not have native integers. Neither does a2xx. Not sure about etnaviv.


I wanted to remove support for NV04 and NV05 last year because they are
unused, unmaintained, and demonstrably *broken*, and I could not even
get consensus on that.


For the record, they work and are maintained (although imperfect, with
some known breakage). Maintained, to me, means "if someone comes with
an issue, there will be an attempt to address it". But they're rarely
tested, and questionably used by anyone other than the tester (me),
and only on NV5, as I don't have a NV4.

Separately, I'd definitely consider a discussion about cleaving off
the post-modern-times drivers (DX10+ hardware) from the
pre-modern-times hardware (DX9 and older), and moving those off into a
mesa-pre-dx9 repository. I doubt there are too many bugs/features for
those that would greatly benefit from a shared repository. And mesa
could shed a ton of support code in the process. On both sides.


This is the boldest proposal I've seen so far. I have some sentimental
feelings about gallium/r300, but if it were the only driver without
native integer support blocking some major Mesa cleanup, I would let
it go. If we wanna discuss driver removal, the most likely candidates
are i915g (completely broken currently) and maybe some classic
drivers. I guess some people have feelings about their classic drivers
too, but at the end of the day we have to decide what's best for the
future.



My thinking was that we would use a separate repository as Ilia is 
suggesting and it would essentially be a separate project from Mesa that 
evolves on its own i.e. the drivers wouldn't just be dropped in a branch 
like the dri1 drivers were and contributors would be free to clean-up 
all the unrelated code that is only used by the new drivers etc.


In this scenario there would be no reason to feel sentimental as the 
drivers would live on and potentially in a better state than staying in 
Mesa, but maybe it's wishful thinking that such a project would gain 
much support.

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

Re: [Mesa-dev] [v2 02/39] i965/gen6: Remove dead code in hiz surface setup

[Nanley Chery]

On Wed, May 03, 2017 at 12:22:15PM +0300, Topi Pohjolainen wrote:
> In intel_hiz_miptree_buf_create() the miptree is unconditionally
> created with MIPTREE_LAYOUT_FORCE_ALL_SLICE_AT_LOD.
> 
> Reviewed-by: Jason Ekstrand 
> Signed-off-by: Topi Pohjolainen 
> ---
>  src/mesa/drivers/dri/i965/gen6_depth_state.c | 13 ++---
>  1 file changed, 6 insertions(+), 7 deletions(-)
> 

This patch is
Reviewed-by: Nanley Chery 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] gallium/radeon: pipe AMDGPU_INFO_NUM_VRAM_CPU_PAGE_FAULTS into gallium HUD

[Samuel Pitoiset]

On 05/17/2017 10:45 PM, Marek Olšák wrote:

On Wed, May 17, 2017 at 9:19 PM, Samuel Pitoiset
 wrote:



On 05/17/2017 09:15 PM, Marek Olšák wrote:


From: Marek Olšák 

---
   src/gallium/drivers/radeon/r600_query.c   | 8 ++--
   src/gallium/drivers/radeon/r600_query.h   | 1 +
   src/gallium/drivers/radeon/radeon_winsys.h| 1 +
   src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c | 7 +++
   src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 1 +
   5 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/src/gallium/drivers/radeon/r600_query.c
b/src/gallium/drivers/radeon/r600_query.c
index 0d960bc..7edbb15 100644
--- a/src/gallium/drivers/radeon/r600_query.c
+++ b/src/gallium/drivers/radeon/r600_query.c
@@ -66,20 +66,21 @@ static enum radeon_value_id
winsys_id_from_type(unsigned type)
 case R600_QUERY_REQUESTED_VRAM: return
RADEON_REQUESTED_VRAM_MEMORY;
 case R600_QUERY_REQUESTED_GTT: return RADEON_REQUESTED_GTT_MEMORY;
 case R600_QUERY_MAPPED_VRAM: return RADEON_MAPPED_VRAM;
 case R600_QUERY_MAPPED_GTT: return RADEON_MAPPED_GTT;
 case R600_QUERY_BUFFER_WAIT_TIME: return
RADEON_BUFFER_WAIT_TIME_NS;
 case R600_QUERY_NUM_MAPPED_BUFFERS: return
RADEON_NUM_MAPPED_BUFFERS;
 case R600_QUERY_NUM_GFX_IBS: return RADEON_NUM_GFX_IBS;
 case R600_QUERY_NUM_SDMA_IBS: return RADEON_NUM_SDMA_IBS;
 case R600_QUERY_NUM_BYTES_MOVED: return RADEON_NUM_BYTES_MOVED;
 case R600_QUERY_NUM_EVICTIONS: return RADEON_NUM_EVICTIONS;
+   case R600_QUERY_NUM_VRAM_CPU_PAGE_FAULTS: return
RADEON_NUM_VRAM_CPU_PAGE_FAULTS;
 case R600_QUERY_VRAM_USAGE: return RADEON_VRAM_USAGE;
 case R600_QUERY_VRAM_VIS_USAGE: return RADEON_VRAM_VIS_USAGE;
 case R600_QUERY_GTT_USAGE: return RADEON_GTT_USAGE;
 case R600_QUERY_GPU_TEMPERATURE: return RADEON_GPU_TEMPERATURE;
 case R600_QUERY_CURRENT_GPU_SCLK: return RADEON_CURRENT_SCLK;
 case R600_QUERY_CURRENT_GPU_MCLK: return RADEON_CURRENT_MCLK;
 case R600_QUERY_CS_THREAD_BUSY: return RADEON_CS_THREAD_TIME;
 default: unreachable("query type does not correspond to winsys
id");
 }
   }
@@ -153,21 +154,22 @@ static bool r600_query_sw_begin(struct
r600_common_context *rctx,
 case R600_QUERY_CURRENT_GPU_SCLK:
 case R600_QUERY_CURRENT_GPU_MCLK:
 case R600_QUERY_BACK_BUFFER_PS_DRAW_RATIO:
 case R600_QUERY_NUM_MAPPED_BUFFERS:
 query->begin_result = 0;
 break;
 case R600_QUERY_BUFFER_WAIT_TIME:
 case R600_QUERY_NUM_GFX_IBS:
 case R600_QUERY_NUM_SDMA_IBS:
 case R600_QUERY_NUM_BYTES_MOVED:
-   case R600_QUERY_NUM_EVICTIONS: {
+   case R600_QUERY_NUM_EVICTIONS:
+   case R600_QUERY_NUM_VRAM_CPU_PAGE_FAULTS: {
 enum radeon_value_id ws_id =
winsys_id_from_type(query->b.type);
 query->begin_result = rctx->ws->query_value(rctx->ws,
ws_id);
 break;
 }
 case R600_QUERY_CS_THREAD_BUSY:
 ws_id = winsys_id_from_type(query->b.type);
 query->begin_result = rctx->ws->query_value(rctx->ws,
ws_id);
 query->begin_time = os_time_get_nano();
 break;
 case R600_QUERY_GALLIUM_THREAD_BUSY:
@@ -291,21 +293,22 @@ static bool r600_query_sw_end(struct
r600_common_context *rctx,
 case R600_QUERY_VRAM_VIS_USAGE:
 case R600_QUERY_GTT_USAGE:
 case R600_QUERY_GPU_TEMPERATURE:
 case R600_QUERY_CURRENT_GPU_SCLK:
 case R600_QUERY_CURRENT_GPU_MCLK:
 case R600_QUERY_BUFFER_WAIT_TIME:
 case R600_QUERY_NUM_MAPPED_BUFFERS:
 case R600_QUERY_NUM_GFX_IBS:
 case R600_QUERY_NUM_SDMA_IBS:
 case R600_QUERY_NUM_BYTES_MOVED:
-   case R600_QUERY_NUM_EVICTIONS: {
+   case R600_QUERY_NUM_EVICTIONS:
+   case R600_QUERY_NUM_VRAM_CPU_PAGE_FAULTS: {
 enum radeon_value_id ws_id =
winsys_id_from_type(query->b.type);
 query->end_result = rctx->ws->query_value(rctx->ws,
ws_id);
 break;
 }
 case R600_QUERY_CS_THREAD_BUSY:
 ws_id = winsys_id_from_type(query->b.type);
 query->end_result = rctx->ws->query_value(rctx->ws,
ws_id);
 query->end_time = os_time_get_nano();
 break;
 case R600_QUERY_GALLIUM_THREAD_BUSY:
@@ -1839,20 +1842,21 @@ static struct pipe_driver_query_info
r600_driver_query_list[] = {
 X("requested-VRAM", REQUESTED_VRAM, BYTES,
AVERAGE),
 X("requested-GTT",  REQUESTED_GTT,  BYTES,
AVERAGE),
 X("mapped-VRAM",MAPPED_VRAM,BYTES,
AVERAGE),
 X("mapped-GTT", MAPPED_GTT, BYTES,
AVERAGE),
 X("buffer-wait-time",   

Re: [Mesa-dev] [PATCH 2/2] gallium/radeon: pipe AMDGPU_INFO_NUM_VRAM_CPU_PAGE_FAULTS into gallium HUD

[Marek Olšák]

On Wed, May 17, 2017 at 9:19 PM, Samuel Pitoiset
 wrote:
>
>
> On 05/17/2017 09:15 PM, Marek Olšák wrote:
>>
>> From: Marek Olšák 
>>
>> ---
>>   src/gallium/drivers/radeon/r600_query.c   | 8 ++--
>>   src/gallium/drivers/radeon/r600_query.h   | 1 +
>>   src/gallium/drivers/radeon/radeon_winsys.h| 1 +
>>   src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c | 7 +++
>>   src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 1 +
>>   5 files changed, 16 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/gallium/drivers/radeon/r600_query.c
>> b/src/gallium/drivers/radeon/r600_query.c
>> index 0d960bc..7edbb15 100644
>> --- a/src/gallium/drivers/radeon/r600_query.c
>> +++ b/src/gallium/drivers/radeon/r600_query.c
>> @@ -66,20 +66,21 @@ static enum radeon_value_id
>> winsys_id_from_type(unsigned type)
>> case R600_QUERY_REQUESTED_VRAM: return
>> RADEON_REQUESTED_VRAM_MEMORY;
>> case R600_QUERY_REQUESTED_GTT: return RADEON_REQUESTED_GTT_MEMORY;
>> case R600_QUERY_MAPPED_VRAM: return RADEON_MAPPED_VRAM;
>> case R600_QUERY_MAPPED_GTT: return RADEON_MAPPED_GTT;
>> case R600_QUERY_BUFFER_WAIT_TIME: return
>> RADEON_BUFFER_WAIT_TIME_NS;
>> case R600_QUERY_NUM_MAPPED_BUFFERS: return
>> RADEON_NUM_MAPPED_BUFFERS;
>> case R600_QUERY_NUM_GFX_IBS: return RADEON_NUM_GFX_IBS;
>> case R600_QUERY_NUM_SDMA_IBS: return RADEON_NUM_SDMA_IBS;
>> case R600_QUERY_NUM_BYTES_MOVED: return RADEON_NUM_BYTES_MOVED;
>> case R600_QUERY_NUM_EVICTIONS: return RADEON_NUM_EVICTIONS;
>> +   case R600_QUERY_NUM_VRAM_CPU_PAGE_FAULTS: return
>> RADEON_NUM_VRAM_CPU_PAGE_FAULTS;
>> case R600_QUERY_VRAM_USAGE: return RADEON_VRAM_USAGE;
>> case R600_QUERY_VRAM_VIS_USAGE: return RADEON_VRAM_VIS_USAGE;
>> case R600_QUERY_GTT_USAGE: return RADEON_GTT_USAGE;
>> case R600_QUERY_GPU_TEMPERATURE: return RADEON_GPU_TEMPERATURE;
>> case R600_QUERY_CURRENT_GPU_SCLK: return RADEON_CURRENT_SCLK;
>> case R600_QUERY_CURRENT_GPU_MCLK: return RADEON_CURRENT_MCLK;
>> case R600_QUERY_CS_THREAD_BUSY: return RADEON_CS_THREAD_TIME;
>> default: unreachable("query type does not correspond to winsys
>> id");
>> }
>>   }
>> @@ -153,21 +154,22 @@ static bool r600_query_sw_begin(struct
>> r600_common_context *rctx,
>> case R600_QUERY_CURRENT_GPU_SCLK:
>> case R600_QUERY_CURRENT_GPU_MCLK:
>> case R600_QUERY_BACK_BUFFER_PS_DRAW_RATIO:
>> case R600_QUERY_NUM_MAPPED_BUFFERS:
>> query->begin_result = 0;
>> break;
>> case R600_QUERY_BUFFER_WAIT_TIME:
>> case R600_QUERY_NUM_GFX_IBS:
>> case R600_QUERY_NUM_SDMA_IBS:
>> case R600_QUERY_NUM_BYTES_MOVED:
>> -   case R600_QUERY_NUM_EVICTIONS: {
>> +   case R600_QUERY_NUM_EVICTIONS:
>> +   case R600_QUERY_NUM_VRAM_CPU_PAGE_FAULTS: {
>> enum radeon_value_id ws_id =
>> winsys_id_from_type(query->b.type);
>> query->begin_result = rctx->ws->query_value(rctx->ws,
>> ws_id);
>> break;
>> }
>> case R600_QUERY_CS_THREAD_BUSY:
>> ws_id = winsys_id_from_type(query->b.type);
>> query->begin_result = rctx->ws->query_value(rctx->ws,
>> ws_id);
>> query->begin_time = os_time_get_nano();
>> break;
>> case R600_QUERY_GALLIUM_THREAD_BUSY:
>> @@ -291,21 +293,22 @@ static bool r600_query_sw_end(struct
>> r600_common_context *rctx,
>> case R600_QUERY_VRAM_VIS_USAGE:
>> case R600_QUERY_GTT_USAGE:
>> case R600_QUERY_GPU_TEMPERATURE:
>> case R600_QUERY_CURRENT_GPU_SCLK:
>> case R600_QUERY_CURRENT_GPU_MCLK:
>> case R600_QUERY_BUFFER_WAIT_TIME:
>> case R600_QUERY_NUM_MAPPED_BUFFERS:
>> case R600_QUERY_NUM_GFX_IBS:
>> case R600_QUERY_NUM_SDMA_IBS:
>> case R600_QUERY_NUM_BYTES_MOVED:
>> -   case R600_QUERY_NUM_EVICTIONS: {
>> +   case R600_QUERY_NUM_EVICTIONS:
>> +   case R600_QUERY_NUM_VRAM_CPU_PAGE_FAULTS: {
>> enum radeon_value_id ws_id =
>> winsys_id_from_type(query->b.type);
>> query->end_result = rctx->ws->query_value(rctx->ws,
>> ws_id);
>> break;
>> }
>> case R600_QUERY_CS_THREAD_BUSY:
>> ws_id = winsys_id_from_type(query->b.type);
>> query->end_result = rctx->ws->query_value(rctx->ws,
>> ws_id);
>> query->end_time = os_time_get_nano();
>> break;
>> case R600_QUERY_GALLIUM_THREAD_BUSY:
>> @@ -1839,20 +1842,21 @@ static struct pipe_driver_query_info
>> r600_driver_query_list[] = {
>> X("requested-VRAM", REQUESTED_VRAM, BYTES,
>> AVERAGE),
>> X("requested-GTT",  REQUESTED_GTT,  BYTES,
>> AVERAGE),
>> 

Re: [Mesa-dev] [PATCH 2/4] st/mesa: silence a valgrind warning in u_threaded_context due to st_draw_vbo

[Samuel Pitoiset]

Use of uninitialized variable I guess? I would suggest to move this at 
the beginning of the function, as well as 'info.index_size = 0', but 
your call.


Except a little comment on patch 1, series is:

Reviewed-by: Samuel Pitoiset 

On 05/17/2017 09:14 PM, Marek Olšák wrote:

From: Marek Olšák 

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

diff --git a/src/mesa/state_tracker/st_draw.c b/src/mesa/state_tracker/st_draw.c
index 019001f..fe03a4a 100644
--- a/src/mesa/state_tracker/st_draw.c
+++ b/src/mesa/state_tracker/st_draw.c
@@ -177,20 +177,21 @@ st_draw_vbo(struct gl_context *ctx,
} else {
   /* indices are in user space memory */
   info.has_user_indices = true;
   info.index.user = ib->ptr;
}
  
setup_primitive_restart(ctx, );

 }
 else {
info.index_size = 0;
+  info.has_user_indices = false;
  
/* 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;
}
 }
  
 assert(!indirect);



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

Re: [Mesa-dev] [PATCH 1/4] glsl_to_tgsi: declare all SSBOs and atomics when indirect indexing is used

[Samuel Pitoiset]

On 05/17/2017 09:14 PM, Marek Olšák wrote:

From: Marek Olšák 

Only the first array element was declared, so tgsi_shader_info::
shader_buffers_declared didn't match what the shader was using.
---
  src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 25 +
  1 file changed, 13 insertions(+), 12 deletions(-)

diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp 
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index 54bc70f..e4d139e 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
@@ -413,21 +413,20 @@ public:
 unsigned num_inputs;
 unsigned num_input_arrays;
 struct inout_decl outputs[4 * PIPE_MAX_SHADER_OUTPUTS];
 unsigned num_outputs;
 unsigned num_output_arrays;
  
 int num_address_regs;

 uint32_t samplers_used;
 glsl_base_type sampler_types[PIPE_MAX_SAMPLERS];
 int sampler_targets[PIPE_MAX_SAMPLERS];   /**< One of TGSI_TEXTURE_* */
-   int buffers_used;
 int images_used;
 int image_targets[PIPE_MAX_SHADER_IMAGES];
 unsigned image_formats[PIPE_MAX_SHADER_IMAGES];
 bool indirect_addr_consts;
 int wpos_transform_const;
  
 int glsl_version;

 bool native_integers;
 bool have_sqrt;
 bool have_fma;
@@ -4536,21 +4535,20 @@ glsl_to_tgsi_visitor::glsl_to_tgsi_visitor()
 array_sizes = NULL;
 max_num_arrays = 0;
 next_array = 0;
 num_inputs = 0;
 num_outputs = 0;
 num_input_arrays = 0;
 num_output_arrays = 0;
 num_immediates = 0;
 num_address_regs = 0;
 samplers_used = 0;
-   buffers_used = 0;
 images_used = 0;
 indirect_addr_consts = false;
 wpos_transform_const = -1;
 glsl_version = 0;
 native_integers = false;
 mem_ctx = ralloc_context(NULL);
 ctx = NULL;
 prog = NULL;
 shader_program = NULL;
 shader = NULL;
@@ -4574,21 +4572,20 @@ extern "C" void 
free_glsl_to_tgsi_visitor(glsl_to_tgsi_visitor *v)
  
  
  /**

   * Count resources used by the given gpu program (number of texture
   * samplers, etc).
   */
  static void
  count_resources(glsl_to_tgsi_visitor *v, gl_program *prog)
  {
 v->samplers_used = 0;
-   v->buffers_used = 0;
 v->images_used = 0;
  
 foreach_in_list(glsl_to_tgsi_instruction, inst, >instructions) {

if (inst->info->is_tex) {
   for (int i = 0; i < inst->sampler_array_size; i++) {
  unsigned idx = inst->sampler_base + i;
  v->samplers_used |= 1u << idx;
  
  debug_assert(idx < (int)ARRAY_SIZE(v->sampler_types));

  v->sampler_types[idx] = inst->tex_type;
@@ -4601,21 +4598,21 @@ count_resources(glsl_to_tgsi_visitor *v, gl_program 
*prog)
   }
}
  
if (inst->tex_target == TEXTURE_EXTERNAL_INDEX)

   prog->ExternalSamplersUsed |= 1 << inst->resource.index;
  
if (inst->resource.file != PROGRAM_UNDEFINED && (

  is_resource_instruction(inst->op) ||
  inst->op == TGSI_OPCODE_STORE)) {
   if (inst->resource.file == PROGRAM_BUFFER) {
-v->buffers_used |= 1 << inst->resource.index;
+/* nothing to do */


I would suggest to remove the whole 'if' and replace 'else' by 'else if' 
(for images).



   } else if (inst->resource.file == PROGRAM_MEMORY) {
  v->use_shared_memory = true;
   } else {
  assert(inst->resource.file == PROGRAM_IMAGE);
  for (int i = 0; i < inst->sampler_array_size; i++) {
 unsigned idx = inst->sampler_base + i;
 v->images_used |= 1 << idx;
 v->image_targets[idx] =
st_translate_texture_target(inst->tex_target, false);
 v->image_formats[idx] = inst->image_format;
@@ -6586,30 +6583,34 @@ st_translate_program(
  break;
   default:
  unreachable("not reached");
   }
  
   ureg_DECL_sampler_view( ureg, i, program->sampler_targets[i],

   type, type, type, type );
}
 }
  
-   for (i = 0; i < frag_const->MaxAtomicBuffers; i++) {

-  if (program->buffers_used & (1 << i)) {
- t->buffers[i] = ureg_DECL_buffer(ureg, i, true);
+   /* Declare atomic and shader storage buffers. */
+   {
+  struct gl_program *prog = program->prog;
+
+  for (i = 0; i < prog->info.num_abos; i++) {
+ unsigned index = prog->sh.AtomicBuffers[i]->Binding;
+ assert(index < frag_const->MaxAtomicBuffers);
+ t->buffers[index] = ureg_DECL_buffer(ureg, index, true);
}
-   }
  
-   for (; i < frag_const->MaxAtomicBuffers + frag_const->MaxShaderStorageBlocks;

-i++) {
-  if (program->buffers_used & (1 << i)) {
- t->buffers[i] = ureg_DECL_buffer(ureg, i, false);
+  assert(prog->info.num_ssbos <= frag_const->MaxShaderStorageBlocks);
+  for (i = 0; i < prog->info.num_ssbos; i++) {
+ unsigned index 

[Mesa-dev] [PATCH 06/10] radeonsi: update si_ce_needed_cs_space

[Marek Olšák]

From: Marek Olšák 

---
 src/gallium/drivers/radeonsi/si_hw_context.c | 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_hw_context.c 
b/src/gallium/drivers/radeonsi/si_hw_context.c
index 5e97d56..3c59f1b 100644
--- a/src/gallium/drivers/radeonsi/si_hw_context.c
+++ b/src/gallium/drivers/radeonsi/si_hw_context.c
@@ -26,34 +26,35 @@
 
 #include "si_pipe.h"
 #include "radeon/r600_cs.h"
 
 static unsigned si_descriptor_list_cs_space(unsigned count, unsigned 
element_size)
 {
/* Ensure we have enough space to start a new range in a hole */
assert(element_size >= 3);
 
/* 5 dwords for possible load to reinitialize when we have no preamble
-* IB + 5 dwords for write to L2 + 3 bytes for every range written to
-* CE RAM.
+* IB + 5 dwords for write to L2 + 3 bytes for the packet header of
+* every disjoint range written to CE RAM.
 */
-   return 5 + 5 + 3 + count * element_size;
+   return 5 + (3 * count / 2) + count * element_size;
 }
 
 static unsigned si_ce_needed_cs_space(void)
 {
unsigned space = 0;
 
-   space += si_descriptor_list_cs_space(SI_NUM_CONST_BUFFERS, 4);
-   space += si_descriptor_list_cs_space(SI_NUM_SHADER_BUFFERS, 4);
-   space += si_descriptor_list_cs_space(SI_NUM_SAMPLERS, 16);
-   space += si_descriptor_list_cs_space(SI_NUM_IMAGES, 8);
+   space += si_descriptor_list_cs_space(SI_NUM_SHADER_BUFFERS +
+SI_NUM_CONST_BUFFERS, 4);
+   /* two 8-byte images share one 16-byte slot */
+   space += si_descriptor_list_cs_space(SI_NUM_IMAGES / 2 +
+SI_NUM_SAMPLERS, 16);
space *= SI_NUM_SHADERS;
 
space += si_descriptor_list_cs_space(SI_NUM_RW_BUFFERS, 4);
 
/* Increment CE counter packet */
space += 2;
 
return space;
 }
 
-- 
2.7.4

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

[Mesa-dev] [PATCH 02/10] radeonsi: merge sampler and image descriptor lists into one

[Marek Olšák]

From: Marek Olšák 

Sampler slots: slot[8], .. slot[39] (ascending)
Image slots: slot[7], .. slot[0] (descending)

Each image occupies 1/2 of each slot, so there are 16 images in total,
therefore the layout is: slot[15], .. slot[0]. (in 1/2 slot increments)

Updating image slot 2n+i (i <= 1) also dirties and re-uploads slot 2n+!i.
---
 src/gallium/drivers/radeonsi/si_descriptors.c | 134 ++
 src/gallium/drivers/radeonsi/si_shader.c  |  22 ++--
 src/gallium/drivers/radeonsi/si_shader.h  |  20 ++--
 src/gallium/drivers/radeonsi/si_shader_internal.h |   3 +-
 src/gallium/drivers/radeonsi/si_shader_tgsi_mem.c |  15 ++-
 src/gallium/drivers/radeonsi/si_state.h   |  17 ++-
 6 files changed, 99 insertions(+), 112 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_descriptors.c 
b/src/gallium/drivers/radeonsi/si_descriptors.c
index 5dc7068..177d2f3 100644
--- a/src/gallium/drivers/radeonsi/si_descriptors.c
+++ b/src/gallium/drivers/radeonsi/si_descriptors.c
@@ -92,48 +92,37 @@ static uint32_t null_image_descriptor[8] = {
0,
S_008F1C_TYPE(V_008F1C_SQ_RSRC_IMG_1D)
/* the rest must contain zeros, which is also used by the buffer
 * descriptor */
 };
 
 static void si_init_descriptors(struct si_descriptors *desc,
unsigned shader_userdata_index,
unsigned element_dw_size,
unsigned num_elements,
-   const uint32_t *null_descriptor,
unsigned *ce_offset)
 {
-   int i;
-
assert(num_elements <= sizeof(desc->dirty_mask)*8);
 
desc->list = CALLOC(num_elements, element_dw_size * 4);
desc->element_dw_size = element_dw_size;
desc->num_elements = num_elements;
-   desc->dirty_mask = num_elements == 32 ? ~0u : (1u << num_elements) - 1;
+   desc->dirty_mask = u_bit_consecutive64(0, num_elements);
desc->shader_userdata_offset = shader_userdata_index * 4;
 
if (ce_offset) {
desc->uses_ce = true;
desc->ce_offset = *ce_offset;
 
/* make sure that ce_offset stays 32 byte aligned */
*ce_offset += align(element_dw_size * num_elements * 4, 32);
}
-
-   /* Initialize the array to NULL descriptors if the element size is 8. */
-   if (null_descriptor) {
-   assert(element_dw_size % 8 == 0);
-   for (i = 0; i < num_elements * element_dw_size / 8; i++)
-   memcpy(desc->list + i * 8, null_descriptor,
-  8 * 4);
-   }
 }
 
 static void si_release_descriptors(struct si_descriptors *desc)
 {
r600_resource_reference(>buffer, NULL);
FREE(desc->list);
 }
 
 static bool si_ce_upload(struct si_context *sctx, unsigned ce_offset, unsigned 
size,
 unsigned *out_offset, struct r600_resource **out_buf) {
@@ -212,22 +201,22 @@ static bool si_upload_descriptors(struct si_context *sctx,
return true;
 
if (sctx->ce_ib && desc->uses_ce) {
uint32_t const* list = (uint32_t const*)desc->list;
 
if (desc->ce_ram_dirty)
si_ce_reinitialize_descriptors(sctx, desc);
 
while(desc->dirty_mask) {
int begin, count;
-   u_bit_scan_consecutive_range(>dirty_mask, ,
-);
+   u_bit_scan_consecutive_range64(>dirty_mask, 
,
+  );
 
begin *= desc->element_dw_size;
count *= desc->element_dw_size;
 
radeon_emit(sctx->ce_ib,
PKT3(PKT3_WRITE_CONST_RAM, count, 0));
radeon_emit(sctx->ce_ib, desc->ce_offset + begin * 4);
radeon_emit_array(sctx->ce_ib, list + begin, count);
}
 
@@ -266,30 +255,30 @@ si_descriptors_begin_new_cs(struct si_context *sctx, 
struct si_descriptors *desc
if (!desc->buffer)
return;
 
radeon_add_to_buffer_list(>b, >b.gfx, desc->buffer,
  RADEON_USAGE_READ, RADEON_PRIO_DESCRIPTORS);
 }
 
 /* SAMPLER VIEWS */
 
 static unsigned
-si_sampler_descriptors_idx(unsigned shader)
+si_sampler_and_image_descriptors_idx(unsigned shader)
 {
return SI_DESCS_FIRST_SHADER + shader * SI_NUM_SHADER_DESCS +
-  SI_SHADER_DESCS_SAMPLERS;
+  SI_SHADER_DESCS_SAMPLERS_AND_IMAGES;
 }
 
 static struct si_descriptors *
-si_sampler_descriptors(struct si_context *sctx, unsigned shader)
+si_sampler_and_image_descriptors(struct si_context *sctx, unsigned shader)
 {
-   return >descriptors[si_sampler_descriptors_idx(shader)];
+   return 

[Mesa-dev] [PATCH 09/10] radeonsi: remove CE offset alignment restriction

[Marek Olšák]

From: Marek Olšák 

This was only needed by LOAD_CONST_RAM, which is now only used to load
whole CE.
---
 src/gallium/drivers/radeonsi/si_descriptors.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/radeonsi/si_descriptors.c 
b/src/gallium/drivers/radeonsi/si_descriptors.c
index a2f40a8..af174d5 100644
--- a/src/gallium/drivers/radeonsi/si_descriptors.c
+++ b/src/gallium/drivers/radeonsi/si_descriptors.c
@@ -107,21 +107,21 @@ static void si_init_descriptors(struct si_descriptors 
*desc,
desc->element_dw_size = element_dw_size;
desc->num_elements = num_elements;
desc->dirty_mask = u_bit_consecutive64(0, num_elements);
desc->shader_userdata_offset = shader_userdata_index * 4;
 
if (ce_offset) {
desc->uses_ce = true;
desc->ce_offset = *ce_offset;
 
/* make sure that ce_offset stays 32 byte aligned */
-   *ce_offset += align(element_dw_size * num_elements * 4, 32);
+   *ce_offset += element_dw_size * num_elements * 4;
}
 }
 
 static void si_release_descriptors(struct si_descriptors *desc)
 {
r600_resource_reference(>buffer, NULL);
FREE(desc->list);
 }
 
 static bool si_ce_upload(struct si_context *sctx, unsigned ce_offset, unsigned 
size,
-- 
2.7.4

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

[Mesa-dev] [PATCH 08/10] radeonsi: only upload (dump to L2) those descriptors that are used by shaders

[Marek Olšák]

From: Marek Olšák 

This decreases the size of CE RAM dumps to L2, or the size of descriptor
uploads without CE.
---
 src/gallium/drivers/radeonsi/si_compute.c   | 28 ++--
 src/gallium/drivers/radeonsi/si_descriptors.c   | 85 -
 src/gallium/drivers/radeonsi/si_state.h | 18 +-
 src/gallium/drivers/radeonsi/si_state_shaders.c |  6 ++
 4 files changed, 113 insertions(+), 24 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_compute.c 
b/src/gallium/drivers/radeonsi/si_compute.c
index 22ef111..4c98066 100644
--- a/src/gallium/drivers/radeonsi/si_compute.c
+++ b/src/gallium/drivers/radeonsi/si_compute.c
@@ -201,21 +201,38 @@ static void *si_create_compute_state(
return NULL;
}
}
 
return program;
 }
 
 static void si_bind_compute_state(struct pipe_context *ctx, void *state)
 {
struct si_context *sctx = (struct si_context*)ctx;
-   sctx->cs_shader_state.program = (struct si_compute*)state;
+   struct si_compute *program = (struct si_compute*)state;
+
+   sctx->cs_shader_state.program = program;
+   if (!program)
+   return;
+
+   /* Wait because we need active slot usage masks. */
+   if (program->ir_type == PIPE_SHADER_IR_TGSI)
+   util_queue_fence_wait(>ready);
+
+   si_set_active_descriptors(sctx,
+ SI_DESCS_FIRST_COMPUTE +
+ SI_SHADER_DESCS_CONST_AND_SHADER_BUFFERS,
+ program->active_const_and_shader_buffers);
+   si_set_active_descriptors(sctx,
+ SI_DESCS_FIRST_COMPUTE +
+ SI_SHADER_DESCS_SAMPLERS_AND_IMAGES,
+ program->active_samplers_and_images);
 }
 
 static void si_set_global_binding(
struct pipe_context *ctx, unsigned first, unsigned n,
struct pipe_resource **resources,
uint32_t **handles)
 {
unsigned i;
struct si_context *sctx = (struct si_context*)ctx;
struct si_compute *program = sctx->cs_shader_state.program;
@@ -749,26 +766,23 @@ static void si_launch_grid(
bool cs_regalloc_hang =
(sctx->b.chip_class == SI ||
 sctx->b.family == CHIP_BONAIRE ||
 sctx->b.family == CHIP_KABINI) &&
info->block[0] * info->block[1] * info->block[2] > 256;
 
if (cs_regalloc_hang)
sctx->b.flags |= SI_CONTEXT_PS_PARTIAL_FLUSH |
 SI_CONTEXT_CS_PARTIAL_FLUSH;
 
-   if (program->ir_type == PIPE_SHADER_IR_TGSI) {
-   util_queue_fence_wait(>ready);
-
-   if (program->shader.compilation_failed)
-   return;
-   }
+   if (program->ir_type == PIPE_SHADER_IR_TGSI &&
+   program->shader.compilation_failed)
+   return;
 
si_decompress_compute_textures(sctx);
 
/* Add buffer sizes for memory checking in need_cs_space. */
r600_context_add_resource_size(ctx, >shader.bo->b.b);
/* TODO: add the scratch buffer */
 
if (info->indirect) {
r600_context_add_resource_size(ctx, info->indirect);
 
diff --git a/src/gallium/drivers/radeonsi/si_descriptors.c 
b/src/gallium/drivers/radeonsi/si_descriptors.c
index 38e4ae1..a2f40a8 100644
--- a/src/gallium/drivers/radeonsi/si_descriptors.c
+++ b/src/gallium/drivers/radeonsi/si_descriptors.c
@@ -118,26 +118,28 @@ static void si_init_descriptors(struct si_descriptors 
*desc,
}
 }
 
 static void si_release_descriptors(struct si_descriptors *desc)
 {
r600_resource_reference(>buffer, NULL);
FREE(desc->list);
 }
 
 static bool si_ce_upload(struct si_context *sctx, unsigned ce_offset, unsigned 
size,
-unsigned *out_offset, struct r600_resource **out_buf) {
+unsigned *out_offset, struct r600_resource **out_buf)
+{
uint64_t va;
 
u_suballocator_alloc(sctx->ce_suballocator, size,
-sctx->screen->b.info.tcc_cache_line_size,
-out_offset, (struct pipe_resource**)out_buf);
+si_optimal_tcc_alignment(sctx, size),
+(unsigned*)out_offset,
+(struct pipe_resource**)out_buf);
if (!out_buf)
return false;
 
va = (*out_buf)->gpu_address + *out_offset;
 
radeon_emit(sctx->ce_ib, PKT3(PKT3_DUMP_CONST_RAM, 3, 0));
radeon_emit(sctx->ce_ib, ce_offset);
radeon_emit(sctx->ce_ib, size / 4);
radeon_emit(sctx->ce_ib, va);
radeon_emit(sctx->ce_ib, va >> 32);
@@ -186,58 +188,70 @@ void si_ce_enable_loads(struct radeon_winsys_cs *ib)
radeon_emit(ib, PKT3(PKT3_CONTEXT_CONTROL, 1, 0));
radeon_emit(ib, CONTEXT_CONTROL_LOAD_ENABLE(1) |
   

[Mesa-dev] [PATCH 05/10] radeonsi: do only 1 big CE dump at end of IBs and one reload in the preamble

[Marek Olšák]

From: Marek Olšák 

A later commit will only upload descriptors used by shaders, so we won't do
full dumps anymore, so the only way to have a complete mirror of CE RAM
in memory is to do a separate dump after the last draw call.
---
 src/gallium/drivers/radeonsi/si_descriptors.c | 56 ---
 src/gallium/drivers/radeonsi/si_hw_context.c  |  8 +++-
 src/gallium/drivers/radeonsi/si_pipe.c|  1 +
 src/gallium/drivers/radeonsi/si_pipe.h|  3 ++
 src/gallium/drivers/radeonsi/si_state.h   |  6 +--
 5 files changed, 37 insertions(+), 37 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_descriptors.c 
b/src/gallium/drivers/radeonsi/si_descriptors.c
index 91cc9a6..38e4ae1 100644
--- a/src/gallium/drivers/radeonsi/si_descriptors.c
+++ b/src/gallium/drivers/radeonsi/si_descriptors.c
@@ -142,74 +142,69 @@ static bool si_ce_upload(struct si_context *sctx, 
unsigned ce_offset, unsigned s
radeon_emit(sctx->ce_ib, va);
radeon_emit(sctx->ce_ib, va >> 32);
 
radeon_add_to_buffer_list(>b, >b.gfx, *out_buf,
   RADEON_USAGE_READWRITE, RADEON_PRIO_DESCRIPTORS);
 
sctx->ce_need_synchronization = true;
return true;
 }
 
-static void si_ce_reinitialize_descriptors(struct si_context *sctx,
-   struct si_descriptors *desc)
+void si_ce_save_all_descriptors_at_ib_end(struct si_context* sctx)
 {
-   if (desc->buffer) {
-   struct r600_resource *buffer = (struct 
r600_resource*)desc->buffer;
-   unsigned list_size = desc->num_elements * desc->element_dw_size 
* 4;
-   uint64_t va = buffer->gpu_address + desc->buffer_offset;
-   struct radeon_winsys_cs *ib = sctx->ce_preamble_ib;
-
-   if (!ib)
-   ib = sctx->ce_ib;
+   bool success = si_ce_upload(sctx, 0, sctx->total_ce_ram_allocated,
+   >ce_ram_saved_offset,
+   >ce_ram_saved_buffer);
+   (void)success;
+   assert(success);
+}
 
-   list_size = align(list_size, 32);
+void si_ce_restore_all_descriptors_at_ib_start(struct si_context *sctx)
+{
+   if (!sctx->ce_ram_saved_buffer)
+   return;
 
-   radeon_emit(ib, PKT3(PKT3_LOAD_CONST_RAM, 3, 0));
-   radeon_emit(ib, va);
-   radeon_emit(ib, va >> 32);
-   radeon_emit(ib, list_size / 4);
-   radeon_emit(ib, desc->ce_offset);
+   struct radeon_winsys_cs *ib = sctx->ce_preamble_ib;
+   if (!ib)
+   ib = sctx->ce_ib;
 
-   radeon_add_to_buffer_list(>b, >b.gfx, desc->buffer,
-   RADEON_USAGE_READ, RADEON_PRIO_DESCRIPTORS);
-   }
-   desc->ce_ram_dirty = false;
-}
+   uint64_t va = sctx->ce_ram_saved_buffer->gpu_address +
+ sctx->ce_ram_saved_offset;
 
-void si_ce_reinitialize_all_descriptors(struct si_context *sctx)
-{
-   int i;
+   radeon_emit(ib, PKT3(PKT3_LOAD_CONST_RAM, 3, 0));
+   radeon_emit(ib, va);
+   radeon_emit(ib, va >> 32);
+   radeon_emit(ib, sctx->total_ce_ram_allocated / 4);
+   radeon_emit(ib, 0);
 
-   for (i = 0; i < SI_NUM_DESCS; ++i)
-   si_ce_reinitialize_descriptors(sctx, >descriptors[i]);
+   radeon_add_to_buffer_list(>b, >b.gfx,
+ sctx->ce_ram_saved_buffer,
+ RADEON_USAGE_READ, RADEON_PRIO_DESCRIPTORS);
 }
 
 void si_ce_enable_loads(struct radeon_winsys_cs *ib)
 {
radeon_emit(ib, PKT3(PKT3_CONTEXT_CONTROL, 1, 0));
radeon_emit(ib, CONTEXT_CONTROL_LOAD_ENABLE(1) |
CONTEXT_CONTROL_LOAD_CE_RAM(1));
radeon_emit(ib, CONTEXT_CONTROL_SHADOW_ENABLE(1));
 }
 
 static bool si_upload_descriptors(struct si_context *sctx,
  struct si_descriptors *desc,
  struct r600_atom * atom)
 {
unsigned list_size = desc->num_elements * desc->element_dw_size * 4;
 
if (sctx->ce_ib && desc->uses_ce) {
uint32_t const* list = (uint32_t const*)desc->list;
 
-   if (desc->ce_ram_dirty)
-   si_ce_reinitialize_descriptors(sctx, desc);
-
while(desc->dirty_mask) {
int begin, count;
u_bit_scan_consecutive_range64(>dirty_mask, 
,
   );
 
begin *= desc->element_dw_size;
count *= desc->element_dw_size;
 
radeon_emit(sctx->ce_ib,
PKT3(PKT3_WRITE_CONST_RAM, count, 0));
@@ -240,22 +235,20 @@ static bool si_upload_descriptors(struct si_context *sctx,
 
if (atom)
si_mark_atom_dirty(sctx, atom);
 
return true;
 }
 
 static 

[Mesa-dev] [PATCH 10/10] radeonsi/gfx9: use CE RAM optimally

[Marek Olšák]

From: Marek Olšák 

On GFX9 with only 4K CE RAM, define the range of slots that will be
allocated in CE RAM. All other slots will be uploaded directly. This will
switch dynamically according to which slots are used by current shaders.

GFX9 CE usage should now be similar to VI instead of being often disabled.

Tested on VI by taking the GFX9 CE allocation codepath and setting
num_ce_slots = 2 everywhere to get frequent switches between both modes.
CE is still disabled on GFX9.
---
 src/gallium/drivers/radeonsi/si_descriptors.c | 163 --
 src/gallium/drivers/radeonsi/si_state.h   |   7 ++
 2 files changed, 134 insertions(+), 36 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_descriptors.c 
b/src/gallium/drivers/radeonsi/si_descriptors.c
index af174d5..5753ae0 100644
--- a/src/gallium/drivers/radeonsi/si_descriptors.c
+++ b/src/gallium/drivers/radeonsi/si_descriptors.c
@@ -88,40 +88,45 @@ static uint32_t null_texture_descriptor[8] = {
 
 static uint32_t null_image_descriptor[8] = {
0,
0,
0,
S_008F1C_TYPE(V_008F1C_SQ_RSRC_IMG_1D)
/* the rest must contain zeros, which is also used by the buffer
 * descriptor */
 };
 
-static void si_init_descriptors(struct si_descriptors *desc,
+static void si_init_descriptors(struct si_context *sctx,
+   struct si_descriptors *desc,
unsigned shader_userdata_index,
unsigned element_dw_size,
unsigned num_elements,
+   unsigned first_ce_slot,
+   unsigned num_ce_slots,
unsigned *ce_offset)
 {
assert(num_elements <= sizeof(desc->dirty_mask)*8);
 
desc->list = CALLOC(num_elements, element_dw_size * 4);
desc->element_dw_size = element_dw_size;
desc->num_elements = num_elements;
+   desc->first_ce_slot = sctx->ce_ib ? first_ce_slot : 0;
+   desc->num_ce_slots = sctx->ce_ib ? num_ce_slots : 0;
desc->dirty_mask = u_bit_consecutive64(0, num_elements);
desc->shader_userdata_offset = shader_userdata_index * 4;
 
-   if (ce_offset) {
+   if (desc->num_ce_slots) {
desc->uses_ce = true;
desc->ce_offset = *ce_offset;
 
/* make sure that ce_offset stays 32 byte aligned */
-   *ce_offset += element_dw_size * num_elements * 4;
+   *ce_offset += element_dw_size * desc->num_ce_slots * 4;
}
 }
 
 static void si_release_descriptors(struct si_descriptors *desc)
 {
r600_resource_reference(>buffer, NULL);
FREE(desc->list);
 }
 
 static bool si_ce_upload(struct si_context *sctx, unsigned ce_offset, unsigned 
size,
@@ -195,38 +200,43 @@ static bool si_upload_descriptors(struct si_context *sctx,
  struct si_descriptors *desc,
  struct r600_atom * atom)
 {
unsigned slot_size = desc->element_dw_size * 4;
unsigned first_slot_offset = desc->first_active_slot * slot_size;
unsigned upload_size = desc->num_active_slots * slot_size;
 
if (!upload_size)
return true;
 
-   if (sctx->ce_ib && desc->uses_ce) {
-   uint32_t const* list = (uint32_t const*)desc->list;
+   if (desc->uses_ce) {
+   const uint32_t *list = desc->list +
+  desc->first_ce_slot * 
desc->element_dw_size;
+   uint64_t mask = (desc->dirty_mask >> desc->first_ce_slot) &
+   u_bit_consecutive64(0, desc->num_ce_slots);
 
-   while(desc->dirty_mask) {
+
+   while (mask) {
int begin, count;
-   u_bit_scan_consecutive_range64(>dirty_mask, 
,
-  );
+   u_bit_scan_consecutive_range64(, , );
 
begin *= desc->element_dw_size;
count *= desc->element_dw_size;
 
radeon_emit(sctx->ce_ib,
PKT3(PKT3_WRITE_CONST_RAM, count, 0));
radeon_emit(sctx->ce_ib, desc->ce_offset + begin * 4);
radeon_emit_array(sctx->ce_ib, list + begin, count);
}
 
-   if (!si_ce_upload(sctx, desc->ce_offset + first_slot_offset,
+   if (!si_ce_upload(sctx,
+ desc->ce_offset +
+ (first_slot_offset - desc->first_ce_slot * 
slot_size),
  upload_size, (unsigned*)>buffer_offset,
  >buffer))
return false;
} else {
uint32_t *ptr;
 
u_upload_alloc(sctx->b.b.const_uploader, 0, upload_size,

[Mesa-dev] [PATCH 01/10] radeonsi: merge constant and shader buffers descriptor lists into one

[Marek Olšák]

From: Marek Olšák 

Constant buffers: slot[16], .. slot[31] (ascending)
Shader buffers: slot[15], .. slot[0] (descending)

The idea is that if we have 4 constant buffers and 2 shader buffers, we only
have to upload 6 slots. That optimization is left for a later commit.
---
 src/gallium/drivers/radeonsi/si_debug.c   |  44 ---
 src/gallium/drivers/radeonsi/si_descriptors.c | 141 +++---
 src/gallium/drivers/radeonsi/si_pipe.h|   3 +-
 src/gallium/drivers/radeonsi/si_shader.c  |  32 ++---
 src/gallium/drivers/radeonsi/si_shader.h  |  20 ++-
 src/gallium/drivers/radeonsi/si_shader_internal.h |   3 +-
 src/gallium/drivers/radeonsi/si_shader_tgsi_mem.c |  13 +-
 src/gallium/drivers/radeonsi/si_state.h   |  25 +++-
 8 files changed, 150 insertions(+), 131 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_debug.c 
b/src/gallium/drivers/radeonsi/si_debug.c
index d1159ad..25c3882 100644
--- a/src/gallium/drivers/radeonsi/si_debug.c
+++ b/src/gallium/drivers/radeonsi/si_debug.c
@@ -373,37 +373,38 @@ static void si_dump_framebuffer(struct si_context *sctx, 
FILE *f)
}
 
if (state->zsbuf) {
rtex = (struct r600_texture*)state->zsbuf->texture;
fprintf(f, COLOR_YELLOW "Depth-stencil buffer:" COLOR_RESET 
"\n");
r600_print_texture_info(sctx->b.screen, rtex, f);
fprintf(f, "\n");
}
 }
 
+typedef unsigned (*slot_remap_func)(unsigned);
+
 static void si_dump_descriptor_list(struct si_descriptors *desc,
const char *shader_name,
const char *elem_name,
unsigned num_elements,
+   slot_remap_func slot_remap,
FILE *f)
 {
unsigned i, j;
-   uint32_t *cpu_list = desc->list;
-   uint32_t *gpu_list = desc->gpu_list;
-   const char *list_note = "GPU list";
-
-   if (!gpu_list) {
-   gpu_list = cpu_list;
-   list_note = "CPU list";
-   }
 
for (i = 0; i < num_elements; i++) {
+   unsigned dw_offset = slot_remap(i) * desc->element_dw_size;
+   uint32_t *gpu_ptr = desc->gpu_list ? desc->gpu_list : 
desc->list;
+   const char *list_note = desc->gpu_list ? "GPU list" : "CPU 
list";
+   uint32_t *cpu_list = desc->list + dw_offset;
+   uint32_t *gpu_list = gpu_ptr + dw_offset;
+
fprintf(f, COLOR_GREEN "%s%s slot %u (%s):" COLOR_RESET "\n",
shader_name, elem_name, i, list_note);
 
switch (desc->element_dw_size) {
case 4:
for (j = 0; j < 4; j++)
ac_dump_reg(f, R_008F00_SQ_BUF_RSRC_WORD0 + j*4,
gpu_list[j], 0x);
break;
case 8:
@@ -437,63 +438,75 @@ static void si_dump_descriptor_list(struct si_descriptors 
*desc,
gpu_list[12+j], 0x);
break;
}
 
if (memcmp(gpu_list, cpu_list, desc->element_dw_size * 4) != 0) 
{
fprintf(f, COLOR_RED "! This slot was corrupted in 
GPU memory !"
COLOR_RESET "\n");
}
 
fprintf(f, "\n");
-   gpu_list += desc->element_dw_size;
-   cpu_list += desc->element_dw_size;
}
 }
 
+static unsigned si_identity(unsigned slot)
+{
+   return slot;
+}
+
 static void si_dump_descriptors(struct si_context *sctx,
enum pipe_shader_type processor,
const struct tgsi_shader_info *info, FILE *f)
 {
struct si_descriptors *descs =
>descriptors[SI_DESCS_FIRST_SHADER +
   processor * SI_NUM_SHADER_DESCS];
static const char *shader_name[] = {"VS", "PS", "GS", "TCS", "TES", 
"CS"};
 
static const char *elem_name[] = {
" - Constant buffer",
" - Shader buffer",
" - Sampler",
" - Image",
};
+   static const slot_remap_func remap_func[] = {
+   si_get_constbuf_slot,
+   si_get_shaderbuf_slot,
+   si_identity,
+   si_identity,
+   };
unsigned enabled_slots[] = {
-   sctx->const_buffers[processor].enabled_mask,
-   sctx->shader_buffers[processor].enabled_mask,
+   sctx->const_and_shader_buffers[processor].enabled_mask >> 
SI_NUM_SHADER_BUFFERS,
+   
util_bitreverse(sctx->const_and_shader_buffers[processor].enabled_mask &
+   u_bit_consecutive(0, SI_NUM_SHADER_BUFFERS)),

[Mesa-dev] [PATCH 04/10] radeonsi: remove early return in si_upload_descriptors

[Marek Olšák]

From: Marek Olšák 

All updates of descriptors_dirty also set dirty_mask, so the return is
unnecessary. The next commit will want this function to be executed
even if dirty_mask == 0.
---
 src/gallium/drivers/radeonsi/si_descriptors.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_descriptors.c 
b/src/gallium/drivers/radeonsi/si_descriptors.c
index 177d2f3..91cc9a6 100644
--- a/src/gallium/drivers/radeonsi/si_descriptors.c
+++ b/src/gallium/drivers/radeonsi/si_descriptors.c
@@ -190,23 +190,20 @@ void si_ce_enable_loads(struct radeon_winsys_cs *ib)
CONTEXT_CONTROL_LOAD_CE_RAM(1));
radeon_emit(ib, CONTEXT_CONTROL_SHADOW_ENABLE(1));
 }
 
 static bool si_upload_descriptors(struct si_context *sctx,
  struct si_descriptors *desc,
  struct r600_atom * atom)
 {
unsigned list_size = desc->num_elements * desc->element_dw_size * 4;
 
-   if (!desc->dirty_mask)
-   return true;
-
if (sctx->ce_ib && desc->uses_ce) {
uint32_t const* list = (uint32_t const*)desc->list;
 
if (desc->ce_ram_dirty)
si_ce_reinitialize_descriptors(sctx, desc);
 
while(desc->dirty_mask) {
int begin, count;
u_bit_scan_consecutive_range64(>dirty_mask, 
,
   );
-- 
2.7.4

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

[Mesa-dev] [PATCH 03/10] radeonsi: clamp indirect index to the number of declared shader resources

[Marek Olšák]

From: Marek Olšák 

We'll do partial uploads of descriptor arrays, so we need to clamp
against what shaders declare.
---
 src/gallium/drivers/radeonsi/si_shader.c| 2 +-
 src/gallium/drivers/radeonsi/si_shader_internal.h   | 6 ++
 src/gallium/drivers/radeonsi/si_shader_tgsi_mem.c   | 6 +++---
 src/gallium/drivers/radeonsi/si_shader_tgsi_setup.c | 5 +
 4 files changed, 15 insertions(+), 4 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_shader.c 
b/src/gallium/drivers/radeonsi/si_shader.c
index f847e46..61f1384 100644
--- a/src/gallium/drivers/radeonsi/si_shader.c
+++ b/src/gallium/drivers/radeonsi/si_shader.c
@@ -1756,21 +1756,21 @@ static LLVMValueRef fetch_constant(
}
 
buf = reg->Register.Dimension ? reg->Dimension.Index : 0;
idx = reg->Register.Index * 4 + swizzle;
 
if (reg->Register.Dimension && reg->Dimension.Indirect) {
LLVMValueRef ptr = LLVMGetParam(ctx->main_fn, 
ctx->param_const_and_shader_buffers);
LLVMValueRef index;
index = si_get_bounded_indirect_index(ctx, >DimIndirect,
  reg->Dimension.Index,
- SI_NUM_CONST_BUFFERS);
+ ctx->num_const_buffers);
index = LLVMBuildAdd(ctx->gallivm.builder, index,
 LLVMConstInt(ctx->i32, 
SI_NUM_SHADER_BUFFERS, 0), "");
bufp = ac_build_indexed_load_const(>ac, ptr, index);
} else
bufp = load_const_buffer_desc(ctx, buf);
 
if (reg->Register.Indirect) {
addr = ctx->addrs[ireg->Index][ireg->Swizzle];
addr = LLVMBuildLoad(base->gallivm->builder, addr, "load addr 
reg");
addr = lp_build_mul_imm(_base->uint_bld, addr, 16);
diff --git a/src/gallium/drivers/radeonsi/si_shader_internal.h 
b/src/gallium/drivers/radeonsi/si_shader_internal.h
index 5094023..5ccde71 100644
--- a/src/gallium/drivers/radeonsi/si_shader_internal.h
+++ b/src/gallium/drivers/radeonsi/si_shader_internal.h
@@ -50,20 +50,26 @@ struct si_llvm_flow;
 
 struct si_shader_context {
struct lp_build_tgsi_context bld_base;
struct gallivm_state gallivm;
struct ac_llvm_context ac;
struct si_shader *shader;
struct si_screen *screen;
 
unsigned type; /* PIPE_SHADER_* specifies the type of shader. */
 
+   /* For clamping the non-constant index in resource indexing: */
+   unsigned num_const_buffers;
+   unsigned num_shader_buffers;
+   unsigned num_images;
+   unsigned num_samplers;
+
/* Whether the prolog will be compiled separately. */
bool separate_prolog;
 
/** This function is responsible for initilizing the inputs array and 
will be
  * called once for each input declared in the TGSI shader.
  */
void (*load_input)(struct si_shader_context *,
   unsigned input_index,
   const struct tgsi_full_declaration *decl,
   LLVMValueRef out[4]);
diff --git a/src/gallium/drivers/radeonsi/si_shader_tgsi_mem.c 
b/src/gallium/drivers/radeonsi/si_shader_tgsi_mem.c
index 5fc3420..d710c16 100644
--- a/src/gallium/drivers/radeonsi/si_shader_tgsi_mem.c
+++ b/src/gallium/drivers/radeonsi/si_shader_tgsi_mem.c
@@ -85,21 +85,21 @@ shader_buffer_fetch_rsrc(struct si_shader_context *ctx,
LLVMValueRef index;
LLVMValueRef rsrc_ptr = LLVMGetParam(ctx->main_fn,
 
ctx->param_const_and_shader_buffers);
 
if (!reg->Register.Indirect) {
index = LLVMConstInt(ctx->i32,
 
si_get_shaderbuf_slot(reg->Register.Index), 0);
} else {
index = si_get_bounded_indirect_index(ctx, >Indirect,
  reg->Register.Index,
- SI_NUM_SHADER_BUFFERS);
+ ctx->num_shader_buffers);
index = LLVMBuildSub(ctx->gallivm.builder,
 LLVMConstInt(ctx->i32, 
SI_NUM_SHADER_BUFFERS - 1, 0),
 index, "");
}
 
return ac_build_indexed_load_const(>ac, rsrc_ptr, index);
 }
 
 static bool tgsi_is_array_sampler(unsigned target)
 {
@@ -201,21 +201,21 @@ image_fetch_rsrc(
 *
 *If a shader performs an image load, store, or atomic
 *operation using an image variable declared as an array,
 *and if the index used to select an individual element is
 *negative or greater than or equal to the size of the
 *array, the results of the operation are undefined but may
  

[Mesa-dev] [PATCH 07/10] radeonsi: record which descriptor slots are used by shaders

[Marek Olšák]

From: Marek Olšák 

---
 src/gallium/drivers/radeonsi/si_compute.c   |  3 +++
 src/gallium/drivers/radeonsi/si_compute.h   |  4 
 src/gallium/drivers/radeonsi/si_shader.h|  4 
 src/gallium/drivers/radeonsi/si_state.h |  3 +++
 src/gallium/drivers/radeonsi/si_state_shaders.c | 27 +
 5 files changed, 41 insertions(+)

diff --git a/src/gallium/drivers/radeonsi/si_compute.c 
b/src/gallium/drivers/radeonsi/si_compute.c
index 3a519a72..22ef111 100644
--- a/src/gallium/drivers/radeonsi/si_compute.c
+++ b/src/gallium/drivers/radeonsi/si_compute.c
@@ -93,20 +93,23 @@ static void si_create_compute_state_async(void *job, int 
thread_index)
tm = program->compiler_ctx_state.tm;
}
 
memset(, 0, sizeof(sel));
 
sel.screen = program->screen;
tgsi_scan_shader(program->tokens, );
sel.tokens = program->tokens;
sel.type = PIPE_SHADER_COMPUTE;
sel.local_size = program->local_size;
+   si_get_active_slot_masks(,
+>active_const_and_shader_buffers,
+>active_samplers_and_images);
 
program->shader.selector = 
program->shader.is_monolithic = true;
program->uses_grid_size = sel.info.uses_grid_size;
program->uses_block_size = sel.info.uses_block_size;
 
if (si_shader_create(program->screen, tm, >shader, debug)) {
program->shader.compilation_failed = true;
} else {
bool scratch_enabled = shader->config.scratch_bytes_per_wave > 
0;
diff --git a/src/gallium/drivers/radeonsi/si_compute.h 
b/src/gallium/drivers/radeonsi/si_compute.h
index ed33104..764d708 100644
--- a/src/gallium/drivers/radeonsi/si_compute.h
+++ b/src/gallium/drivers/radeonsi/si_compute.h
@@ -27,20 +27,24 @@
 #include "si_shader.h"
 
 #define MAX_GLOBAL_BUFFERS 22
 
 struct si_compute {
struct si_screen *screen;
struct tgsi_token *tokens;
struct util_queue_fence ready;
struct si_compiler_ctx_state compiler_ctx_state;
 
+   /* bitmasks of used descriptor slots */
+   uint32_t active_const_and_shader_buffers;
+   uint64_t active_samplers_and_images;
+
unsigned ir_type;
unsigned local_size;
unsigned private_size;
unsigned input_size;
struct si_shader shader;
 
struct pipe_resource *global_buffers[MAX_GLOBAL_BUFFERS];
unsigned use_code_object_v2 : 1;
unsigned variable_group_size : 1;
unsigned uses_grid_size:1;
diff --git a/src/gallium/drivers/radeonsi/si_shader.h 
b/src/gallium/drivers/radeonsi/si_shader.h
index ffb7dc3..aab902b 100644
--- a/src/gallium/drivers/radeonsi/si_shader.h
+++ b/src/gallium/drivers/radeonsi/si_shader.h
@@ -345,20 +345,24 @@ struct si_shader_selector {
 */
unsignedcolors_written_4bit;
 
/* CS parameters */
unsigned local_size;
 
uint64_toutputs_written;/* "get_unique_index" bits */
uint32_tpatch_outputs_written;  /* "get_unique_index_patch" 
bits */
 
uint64_tinputs_read;/* "get_unique_index" bits */
+
+   /* bitmasks of used descriptor slots */
+   uint32_tactive_const_and_shader_buffers;
+   uint64_tactive_samplers_and_images;
 };
 
 /* Valid shader configurations:
  *
  * API shaders   VS | TCS | TES | GS |pass| PS
  * are compiled as: | | ||thru|
  *  | | |||
  * Only VS & PS: VS | | ||| PS
  * GFX6 - with GS:   ES | | | GS | VS | PS
  *  - with tess: LS | HS  | VS  ||| PS
diff --git a/src/gallium/drivers/radeonsi/si_state.h 
b/src/gallium/drivers/radeonsi/si_state.h
index 9b506a8..f2003a5 100644
--- a/src/gallium/drivers/radeonsi/si_state.h
+++ b/src/gallium/drivers/radeonsi/si_state.h
@@ -346,20 +346,23 @@ si_create_sampler_view_custom(struct pipe_context *ctx,
  const struct pipe_sampler_view *state,
  unsigned width0, unsigned height0,
  unsigned force_level);
 
 /* si_state_shader.c */
 bool si_update_shaders(struct si_context *sctx);
 void si_init_shader_functions(struct si_context *sctx);
 bool si_init_shader_cache(struct si_screen *sscreen);
 void si_destroy_shader_cache(struct si_screen *sscreen);
 void si_init_shader_selector_async(void *job, int thread_index);
+void si_get_active_slot_masks(const struct tgsi_shader_info *info,
+ uint32_t *const_and_shader_buffers,
+ uint64_t *samplers_and_images);
 
 /* si_state_draw.c */
 void si_init_ia_multi_vgt_param_table(struct si_context *sctx);
 void si_emit_cache_flush(struct si_context *sctx);
 void si_ce_pre_draw_synchronization(struct si_context *sctx);
 void si_ce_post_draw_synchronization(struct si_context *sctx);
 

[Mesa-dev] [PATCH 00/10] RadeonSI: Shader descriptor layout & upload improvements

[Marek Olšák]

Hi,

This is unlikely to have any performance benefit except for maybe Vega
and Raven.

The goals of this series are:
- Remove 4 user SGPRs by merging per-shader descriptor arrays. Shader
  buffers and constant buffers share one array. Samplers and images
  share the other one.
- Only upload (or dump to L2) those descriptor slots that are used by
  shaders. For example, it no longer does 2KB uploads of sampler slots
  in most situations.
- For GFX9, allocate only those descriptors slots in CE RAM that are
  likely to be used by apps. If some shader needs more, the driver
  will upload the bigger array directly instead of using CE. This will
  switch dynamically based on what the current shader needs. CE RAM
  on GFX9 is actually large enough to handle most apps, we just need
  to use it intelligently.

Please review.

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

Re: [Mesa-dev] [PATCH 2/2] gallium/radeon: pipe AMDGPU_INFO_NUM_VRAM_CPU_PAGE_FAULTS into gallium HUD

[Samuel Pitoiset]

On 05/17/2017 09:15 PM, Marek Olšák wrote:

From: Marek Olšák 

---
  src/gallium/drivers/radeon/r600_query.c   | 8 ++--
  src/gallium/drivers/radeon/r600_query.h   | 1 +
  src/gallium/drivers/radeon/radeon_winsys.h| 1 +
  src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c | 7 +++
  src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 1 +
  5 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/src/gallium/drivers/radeon/r600_query.c 
b/src/gallium/drivers/radeon/r600_query.c
index 0d960bc..7edbb15 100644
--- a/src/gallium/drivers/radeon/r600_query.c
+++ b/src/gallium/drivers/radeon/r600_query.c
@@ -66,20 +66,21 @@ static enum radeon_value_id winsys_id_from_type(unsigned 
type)
case R600_QUERY_REQUESTED_VRAM: return RADEON_REQUESTED_VRAM_MEMORY;
case R600_QUERY_REQUESTED_GTT: return RADEON_REQUESTED_GTT_MEMORY;
case R600_QUERY_MAPPED_VRAM: return RADEON_MAPPED_VRAM;
case R600_QUERY_MAPPED_GTT: return RADEON_MAPPED_GTT;
case R600_QUERY_BUFFER_WAIT_TIME: return RADEON_BUFFER_WAIT_TIME_NS;
case R600_QUERY_NUM_MAPPED_BUFFERS: return RADEON_NUM_MAPPED_BUFFERS;
case R600_QUERY_NUM_GFX_IBS: return RADEON_NUM_GFX_IBS;
case R600_QUERY_NUM_SDMA_IBS: return RADEON_NUM_SDMA_IBS;
case R600_QUERY_NUM_BYTES_MOVED: return RADEON_NUM_BYTES_MOVED;
case R600_QUERY_NUM_EVICTIONS: return RADEON_NUM_EVICTIONS;
+   case R600_QUERY_NUM_VRAM_CPU_PAGE_FAULTS: return 
RADEON_NUM_VRAM_CPU_PAGE_FAULTS;
case R600_QUERY_VRAM_USAGE: return RADEON_VRAM_USAGE;
case R600_QUERY_VRAM_VIS_USAGE: return RADEON_VRAM_VIS_USAGE;
case R600_QUERY_GTT_USAGE: return RADEON_GTT_USAGE;
case R600_QUERY_GPU_TEMPERATURE: return RADEON_GPU_TEMPERATURE;
case R600_QUERY_CURRENT_GPU_SCLK: return RADEON_CURRENT_SCLK;
case R600_QUERY_CURRENT_GPU_MCLK: return RADEON_CURRENT_MCLK;
case R600_QUERY_CS_THREAD_BUSY: return RADEON_CS_THREAD_TIME;
default: unreachable("query type does not correspond to winsys id");
}
  }
@@ -153,21 +154,22 @@ static bool r600_query_sw_begin(struct 
r600_common_context *rctx,
case R600_QUERY_CURRENT_GPU_SCLK:
case R600_QUERY_CURRENT_GPU_MCLK:
case R600_QUERY_BACK_BUFFER_PS_DRAW_RATIO:
case R600_QUERY_NUM_MAPPED_BUFFERS:
query->begin_result = 0;
break;
case R600_QUERY_BUFFER_WAIT_TIME:
case R600_QUERY_NUM_GFX_IBS:
case R600_QUERY_NUM_SDMA_IBS:
case R600_QUERY_NUM_BYTES_MOVED:
-   case R600_QUERY_NUM_EVICTIONS: {
+   case R600_QUERY_NUM_EVICTIONS:
+   case R600_QUERY_NUM_VRAM_CPU_PAGE_FAULTS: {
enum radeon_value_id ws_id = winsys_id_from_type(query->b.type);
query->begin_result = rctx->ws->query_value(rctx->ws, ws_id);
break;
}
case R600_QUERY_CS_THREAD_BUSY:
ws_id = winsys_id_from_type(query->b.type);
query->begin_result = rctx->ws->query_value(rctx->ws, ws_id);
query->begin_time = os_time_get_nano();
break;
case R600_QUERY_GALLIUM_THREAD_BUSY:
@@ -291,21 +293,22 @@ static bool r600_query_sw_end(struct r600_common_context 
*rctx,
case R600_QUERY_VRAM_VIS_USAGE:
case R600_QUERY_GTT_USAGE:
case R600_QUERY_GPU_TEMPERATURE:
case R600_QUERY_CURRENT_GPU_SCLK:
case R600_QUERY_CURRENT_GPU_MCLK:
case R600_QUERY_BUFFER_WAIT_TIME:
case R600_QUERY_NUM_MAPPED_BUFFERS:
case R600_QUERY_NUM_GFX_IBS:
case R600_QUERY_NUM_SDMA_IBS:
case R600_QUERY_NUM_BYTES_MOVED:
-   case R600_QUERY_NUM_EVICTIONS: {
+   case R600_QUERY_NUM_EVICTIONS:
+   case R600_QUERY_NUM_VRAM_CPU_PAGE_FAULTS: {
enum radeon_value_id ws_id = winsys_id_from_type(query->b.type);
query->end_result = rctx->ws->query_value(rctx->ws, ws_id);
break;
}
case R600_QUERY_CS_THREAD_BUSY:
ws_id = winsys_id_from_type(query->b.type);
query->end_result = rctx->ws->query_value(rctx->ws, ws_id);
query->end_time = os_time_get_nano();
break;
case R600_QUERY_GALLIUM_THREAD_BUSY:
@@ -1839,20 +1842,21 @@ static struct pipe_driver_query_info 
r600_driver_query_list[] = {
X("requested-VRAM",   REQUESTED_VRAM, BYTES, AVERAGE),
X("requested-GTT",REQUESTED_GTT,  BYTES, AVERAGE),
X("mapped-VRAM",  MAPPED_VRAM,BYTES, AVERAGE),
X("mapped-GTT",   MAPPED_GTT, BYTES, 
AVERAGE),
X("buffer-wait-time", BUFFER_WAIT_TIME,   MICROSECONDS, 
CUMULATIVE),
X("num-mapped-buffers",   NUM_MAPPED_BUFFERS, UINT64, 
AVERAGE),
X("num-GFX-IBs",  NUM_GFX_IBS,UINT64, 

Re: [Mesa-dev] [PATCH 3/4] glsl: Merge if-simplification and conditional discard optimization

[Thomas Helland]

And that would be your's truly, butchering the in-reply-to.
Sorry about that. The two updated patches can be found on:

https://lists.freedesktop.org/archives/mesa-dev/2017-May/155996.html

https://lists.freedesktop.org/archives/mesa-dev/2017-May/155995.html
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2.5/4] glsl: Reduce overhead in conditional discard optimization

[Thomas Helland]

Don't descend into assignments. This is the same optimization
that is already done in opt_if_simplification.
---
 src/compiler/glsl/opt_conditional_discard.cpp | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/src/compiler/glsl/opt_conditional_discard.cpp 
b/src/compiler/glsl/opt_conditional_discard.cpp
index 6d8a23460d..d7cb2069ed 100644
--- a/src/compiler/glsl/opt_conditional_discard.cpp
+++ b/src/compiler/glsl/opt_conditional_discard.cpp
@@ -46,12 +46,23 @@ public:
}
 
ir_visitor_status visit_leave(ir_if *);
+   ir_visitor_status visit_enter(ir_assignment *);
 
bool progress;
 };
 
 } /* anonymous namespace */
 
+/* We only care about the top level "if" instructions, so don't
+ * descend into expressions.
+ */
+ir_visitor_status
+opt_conditional_discard_visitor::visit_enter(ir_assignment *ir)
+{
+   (void) ir;
+   return visit_continue_with_parent;
+}
+
 bool
 opt_conditional_discard(exec_list *instructions)
 {
-- 
2.12.2

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

[Mesa-dev] [PATCH 2/2] gallium/radeon: pipe AMDGPU_INFO_NUM_VRAM_CPU_PAGE_FAULTS into gallium HUD

[Marek Olšák]

From: Marek Olšák 

---
 src/gallium/drivers/radeon/r600_query.c   | 8 ++--
 src/gallium/drivers/radeon/r600_query.h   | 1 +
 src/gallium/drivers/radeon/radeon_winsys.h| 1 +
 src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c | 7 +++
 src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 1 +
 5 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/src/gallium/drivers/radeon/r600_query.c 
b/src/gallium/drivers/radeon/r600_query.c
index 0d960bc..7edbb15 100644
--- a/src/gallium/drivers/radeon/r600_query.c
+++ b/src/gallium/drivers/radeon/r600_query.c
@@ -66,20 +66,21 @@ static enum radeon_value_id winsys_id_from_type(unsigned 
type)
case R600_QUERY_REQUESTED_VRAM: return RADEON_REQUESTED_VRAM_MEMORY;
case R600_QUERY_REQUESTED_GTT: return RADEON_REQUESTED_GTT_MEMORY;
case R600_QUERY_MAPPED_VRAM: return RADEON_MAPPED_VRAM;
case R600_QUERY_MAPPED_GTT: return RADEON_MAPPED_GTT;
case R600_QUERY_BUFFER_WAIT_TIME: return RADEON_BUFFER_WAIT_TIME_NS;
case R600_QUERY_NUM_MAPPED_BUFFERS: return RADEON_NUM_MAPPED_BUFFERS;
case R600_QUERY_NUM_GFX_IBS: return RADEON_NUM_GFX_IBS;
case R600_QUERY_NUM_SDMA_IBS: return RADEON_NUM_SDMA_IBS;
case R600_QUERY_NUM_BYTES_MOVED: return RADEON_NUM_BYTES_MOVED;
case R600_QUERY_NUM_EVICTIONS: return RADEON_NUM_EVICTIONS;
+   case R600_QUERY_NUM_VRAM_CPU_PAGE_FAULTS: return 
RADEON_NUM_VRAM_CPU_PAGE_FAULTS;
case R600_QUERY_VRAM_USAGE: return RADEON_VRAM_USAGE;
case R600_QUERY_VRAM_VIS_USAGE: return RADEON_VRAM_VIS_USAGE;
case R600_QUERY_GTT_USAGE: return RADEON_GTT_USAGE;
case R600_QUERY_GPU_TEMPERATURE: return RADEON_GPU_TEMPERATURE;
case R600_QUERY_CURRENT_GPU_SCLK: return RADEON_CURRENT_SCLK;
case R600_QUERY_CURRENT_GPU_MCLK: return RADEON_CURRENT_MCLK;
case R600_QUERY_CS_THREAD_BUSY: return RADEON_CS_THREAD_TIME;
default: unreachable("query type does not correspond to winsys id");
}
 }
@@ -153,21 +154,22 @@ static bool r600_query_sw_begin(struct 
r600_common_context *rctx,
case R600_QUERY_CURRENT_GPU_SCLK:
case R600_QUERY_CURRENT_GPU_MCLK:
case R600_QUERY_BACK_BUFFER_PS_DRAW_RATIO:
case R600_QUERY_NUM_MAPPED_BUFFERS:
query->begin_result = 0;
break;
case R600_QUERY_BUFFER_WAIT_TIME:
case R600_QUERY_NUM_GFX_IBS:
case R600_QUERY_NUM_SDMA_IBS:
case R600_QUERY_NUM_BYTES_MOVED:
-   case R600_QUERY_NUM_EVICTIONS: {
+   case R600_QUERY_NUM_EVICTIONS:
+   case R600_QUERY_NUM_VRAM_CPU_PAGE_FAULTS: {
enum radeon_value_id ws_id = winsys_id_from_type(query->b.type);
query->begin_result = rctx->ws->query_value(rctx->ws, ws_id);
break;
}
case R600_QUERY_CS_THREAD_BUSY:
ws_id = winsys_id_from_type(query->b.type);
query->begin_result = rctx->ws->query_value(rctx->ws, ws_id);
query->begin_time = os_time_get_nano();
break;
case R600_QUERY_GALLIUM_THREAD_BUSY:
@@ -291,21 +293,22 @@ static bool r600_query_sw_end(struct r600_common_context 
*rctx,
case R600_QUERY_VRAM_VIS_USAGE:
case R600_QUERY_GTT_USAGE:
case R600_QUERY_GPU_TEMPERATURE:
case R600_QUERY_CURRENT_GPU_SCLK:
case R600_QUERY_CURRENT_GPU_MCLK:
case R600_QUERY_BUFFER_WAIT_TIME:
case R600_QUERY_NUM_MAPPED_BUFFERS:
case R600_QUERY_NUM_GFX_IBS:
case R600_QUERY_NUM_SDMA_IBS:
case R600_QUERY_NUM_BYTES_MOVED:
-   case R600_QUERY_NUM_EVICTIONS: {
+   case R600_QUERY_NUM_EVICTIONS:
+   case R600_QUERY_NUM_VRAM_CPU_PAGE_FAULTS: {
enum radeon_value_id ws_id = winsys_id_from_type(query->b.type);
query->end_result = rctx->ws->query_value(rctx->ws, ws_id);
break;
}
case R600_QUERY_CS_THREAD_BUSY:
ws_id = winsys_id_from_type(query->b.type);
query->end_result = rctx->ws->query_value(rctx->ws, ws_id);
query->end_time = os_time_get_nano();
break;
case R600_QUERY_GALLIUM_THREAD_BUSY:
@@ -1839,20 +1842,21 @@ static struct pipe_driver_query_info 
r600_driver_query_list[] = {
X("requested-VRAM", REQUESTED_VRAM, BYTES, AVERAGE),
X("requested-GTT",  REQUESTED_GTT,  BYTES, AVERAGE),
X("mapped-VRAM",MAPPED_VRAM,BYTES, AVERAGE),
X("mapped-GTT", MAPPED_GTT, BYTES, AVERAGE),
X("buffer-wait-time",   BUFFER_WAIT_TIME,   MICROSECONDS, 
CUMULATIVE),
X("num-mapped-buffers", NUM_MAPPED_BUFFERS, UINT64, 
AVERAGE),
X("num-GFX-IBs",NUM_GFX_IBS,UINT64, 
AVERAGE),
X("num-SDMA-IBs",   

[Mesa-dev] [PATCH 3/4] glsl: Merge if-simplification and conditional discard opt

[Thomas Helland]

The conditional discard pass is really just a form of if-simplification.
So there is no reason why we can not just merge the two, and avoid
running the visitor two times.

V2: Add back in the wrongly removed optimization
---
 src/compiler/Makefile.sources |  1 -
 src/compiler/glsl/glsl_parser_extras.cpp  |  1 -
 src/compiler/glsl/ir_optimization.h   |  1 -
 src/compiler/glsl/opt_conditional_discard.cpp | 99 ---
 src/compiler/glsl/opt_if_simplification.cpp   | 39 +++
 5 files changed, 39 insertions(+), 102 deletions(-)
 delete mode 100644 src/compiler/glsl/opt_conditional_discard.cpp

diff --git a/src/compiler/Makefile.sources b/src/compiler/Makefile.sources
index 611362ed73..964f454cca 100644
--- a/src/compiler/Makefile.sources
+++ b/src/compiler/Makefile.sources
@@ -114,7 +114,6 @@ LIBGLSL_FILES = \
glsl/lower_ubo_reference.cpp \
glsl/opt_algebraic.cpp \
glsl/opt_array_splitting.cpp \
-   glsl/opt_conditional_discard.cpp \
glsl/opt_constant_folding.cpp \
glsl/opt_constant_propagation.cpp \
glsl/opt_constant_variable.cpp \
diff --git a/src/compiler/glsl/glsl_parser_extras.cpp 
b/src/compiler/glsl/glsl_parser_extras.cpp
index 218ce6949a..220c3a94ed 100644
--- a/src/compiler/glsl/glsl_parser_extras.cpp
+++ b/src/compiler/glsl/glsl_parser_extras.cpp
@@ -2176,7 +2176,6 @@ do_common_optimization(exec_list *ir, bool linked,
}
propagate_invariance(ir);
OPT(do_if_simplification, ir);
-   OPT(opt_conditional_discard, ir);
OPT(do_copy_propagation, ir);
OPT(do_copy_propagation_elements, ir);
 
diff --git a/src/compiler/glsl/ir_optimization.h 
b/src/compiler/glsl/ir_optimization.h
index e9e705a1cc..7ffb47696c 100644
--- a/src/compiler/glsl/ir_optimization.h
+++ b/src/compiler/glsl/ir_optimization.h
@@ -96,7 +96,6 @@ bool ir_constant_fold(ir_rvalue **rvalue);
 bool do_rebalance_tree(exec_list *instructions);
 bool do_algebraic(exec_list *instructions, bool native_integers,
   const struct gl_shader_compiler_options *options);
-bool opt_conditional_discard(exec_list *instructions);
 bool do_constant_folding(exec_list *instructions);
 bool do_constant_variable(exec_list *instructions);
 bool do_constant_variable_unlinked(exec_list *instructions);
diff --git a/src/compiler/glsl/opt_conditional_discard.cpp 
b/src/compiler/glsl/opt_conditional_discard.cpp
deleted file mode 100644
index d7cb2069ed..00
--- a/src/compiler/glsl/opt_conditional_discard.cpp
+++ /dev/null
@@ -1,99 +0,0 @@
-/*
- * Copyright © 2014 Intel Corporation
- *
- * Permission is hereby granted, free of charge, to any person obtaining a
- * copy of this software and associated documentation files (the "Software"),
- * to deal in the Software without restriction, including without limitation
- * the rights to use, copy, modify, merge, publish, distribute, sublicense,
- * and/or sell copies of the Software, and to permit persons to whom the
- * Software is furnished to do so, subject to the following conditions:
- *
- * The above copyright notice and this permission notice (including the next
- * paragraph) shall be included in all copies or substantial portions of the
- * Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
- * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
- * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
- * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
- * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
- * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
- * DEALINGS IN THE SOFTWARE.
- */
-
-/**
- * \file opt_conditional_discard.cpp
- *
- * Replace
- *
- *if (cond) discard;
- *
- * with
- *
- *(discard )
- */
-
-#include "compiler/glsl_types.h"
-#include "ir.h"
-
-namespace {
-
-class opt_conditional_discard_visitor : public ir_hierarchical_visitor {
-public:
-   opt_conditional_discard_visitor()
-   {
-  progress = false;
-   }
-
-   ir_visitor_status visit_leave(ir_if *);
-   ir_visitor_status visit_enter(ir_assignment *);
-
-   bool progress;
-};
-
-} /* anonymous namespace */
-
-/* We only care about the top level "if" instructions, so don't
- * descend into expressions.
- */
-ir_visitor_status
-opt_conditional_discard_visitor::visit_enter(ir_assignment *ir)
-{
-   (void) ir;
-   return visit_continue_with_parent;
-}
-
-bool
-opt_conditional_discard(exec_list *instructions)
-{
-   opt_conditional_discard_visitor v;
-   v.run(instructions);
-   return v.progress;
-}
-
-ir_visitor_status
-opt_conditional_discard_visitor::visit_leave(ir_if *ir)
-{
-   /* Look for "if (...) discard" with no else clause or extra statements. */
-   if (ir->then_instructions.is_empty() ||
-   !ir->then_instructions.get_head_raw()->next->is_tail_sentinel() ||
-   !((ir_instruction *) 

[Mesa-dev] [PATCH 1/2] gallium/radeon: add a query for monitoring Gallium thread load

[Marek Olšák]

From: Marek Olšák 

---
 src/gallium/drivers/radeon/r600_query.c | 12 
 src/gallium/drivers/radeon/r600_query.h |  1 +
 2 files changed, 13 insertions(+)

diff --git a/src/gallium/drivers/radeon/r600_query.c 
b/src/gallium/drivers/radeon/r600_query.c
index 61fd662..0d960bc 100644
--- a/src/gallium/drivers/radeon/r600_query.c
+++ b/src/gallium/drivers/radeon/r600_query.c
@@ -163,20 +163,25 @@ static bool r600_query_sw_begin(struct 
r600_common_context *rctx,
case R600_QUERY_NUM_EVICTIONS: {
enum radeon_value_id ws_id = winsys_id_from_type(query->b.type);
query->begin_result = rctx->ws->query_value(rctx->ws, ws_id);
break;
}
case R600_QUERY_CS_THREAD_BUSY:
ws_id = winsys_id_from_type(query->b.type);
query->begin_result = rctx->ws->query_value(rctx->ws, ws_id);
query->begin_time = os_time_get_nano();
break;
+   case R600_QUERY_GALLIUM_THREAD_BUSY:
+   query->begin_result =
+   rctx->tc ? 
util_queue_get_thread_time_nano(>tc->queue, 0) : 0;
+   query->begin_time = os_time_get_nano();
+   break;
case R600_QUERY_GPU_LOAD:
case R600_QUERY_GPU_SHADERS_BUSY:
case R600_QUERY_GPU_TA_BUSY:
case R600_QUERY_GPU_GDS_BUSY:
case R600_QUERY_GPU_VGT_BUSY:
case R600_QUERY_GPU_IA_BUSY:
case R600_QUERY_GPU_SX_BUSY:
case R600_QUERY_GPU_WD_BUSY:
case R600_QUERY_GPU_BCI_BUSY:
case R600_QUERY_GPU_SC_BUSY:
@@ -296,20 +301,25 @@ static bool r600_query_sw_end(struct r600_common_context 
*rctx,
case R600_QUERY_NUM_EVICTIONS: {
enum radeon_value_id ws_id = winsys_id_from_type(query->b.type);
query->end_result = rctx->ws->query_value(rctx->ws, ws_id);
break;
}
case R600_QUERY_CS_THREAD_BUSY:
ws_id = winsys_id_from_type(query->b.type);
query->end_result = rctx->ws->query_value(rctx->ws, ws_id);
query->end_time = os_time_get_nano();
break;
+   case R600_QUERY_GALLIUM_THREAD_BUSY:
+   query->end_result =
+   rctx->tc ? 
util_queue_get_thread_time_nano(>tc->queue, 0) : 0;
+   query->end_time = os_time_get_nano();
+   break;
case R600_QUERY_GPU_LOAD:
case R600_QUERY_GPU_SHADERS_BUSY:
case R600_QUERY_GPU_TA_BUSY:
case R600_QUERY_GPU_GDS_BUSY:
case R600_QUERY_GPU_VGT_BUSY:
case R600_QUERY_GPU_IA_BUSY:
case R600_QUERY_GPU_SX_BUSY:
case R600_QUERY_GPU_WD_BUSY:
case R600_QUERY_GPU_BCI_BUSY:
case R600_QUERY_GPU_SC_BUSY:
@@ -373,20 +383,21 @@ static bool r600_query_sw_get_result(struct 
r600_common_context *rctx,
case PIPE_QUERY_GPU_FINISHED: {
struct pipe_screen *screen = rctx->b.screen;
struct pipe_context *ctx = rquery->b.flushed ? NULL : >b;
 
result->b = screen->fence_finish(screen, ctx, query->fence,
 wait ? PIPE_TIMEOUT_INFINITE : 
0);
return result->b;
}
 
case R600_QUERY_CS_THREAD_BUSY:
+   case R600_QUERY_GALLIUM_THREAD_BUSY:
result->u64 = (query->end_result - query->begin_result) * 100 /
  (query->end_time - query->begin_time);
return true;
case R600_QUERY_GPIN_ASIC_ID:
result->u32 = 0;
return true;
case R600_QUERY_GPIN_NUM_SIMD:
result->u32 = rctx->screen->info.num_good_compute_units;
return true;
case R600_QUERY_GPIN_NUM_RB:
@@ -1817,20 +1828,21 @@ static struct pipe_driver_query_info 
r600_driver_query_list[] = {
X("num-vs-flushes", NUM_VS_FLUSHES, UINT64, 
AVERAGE),
X("num-ps-flushes", NUM_PS_FLUSHES, UINT64, 
AVERAGE),
X("num-cs-flushes", NUM_CS_FLUSHES, UINT64, 
AVERAGE),
X("num-fb-cache-flushes",   NUM_FB_CACHE_FLUSHES,   UINT64, 
AVERAGE),
X("num-L2-invalidates", NUM_L2_INVALIDATES, UINT64, 
AVERAGE),
X("num-L2-writebacks",  NUM_L2_WRITEBACKS,  UINT64, 
AVERAGE),
X("tc-offloaded-slots", TC_OFFLOADED_SLOTS, UINT64, 
AVERAGE),
X("tc-direct-slots",TC_DIRECT_SLOTS,UINT64, 
AVERAGE),
X("tc-num-syncs",   TC_NUM_SYNCS,   UINT64, 
AVERAGE),
X("CS-thread-busy", CS_THREAD_BUSY, UINT64, 
AVERAGE),
+   X("gallium-thread-busy",GALLIUM_THREAD_BUSY,UINT64, 
AVERAGE),
X("requested-VRAM", REQUESTED_VRAM, BYTES, AVERAGE),
X("requested-GTT",  REQUESTED_GTT,  BYTES, AVERAGE),

[Mesa-dev] [PATCH 3/4] gallium/u_threaded: add a fast path for unbinding shader images

[Marek Olšák]

From: Marek Olšák 

---
 src/gallium/auxiliary/util/u_threaded_context.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/src/gallium/auxiliary/util/u_threaded_context.c 
b/src/gallium/auxiliary/util/u_threaded_context.c
index 50cb820..e33c846 100644
--- a/src/gallium/auxiliary/util/u_threaded_context.c
+++ b/src/gallium/auxiliary/util/u_threaded_context.c
@@ -148,21 +148,21 @@ tc_add_sized_call(struct threaded_context *tc, enum 
tc_call_id id,
return >payload;
 }
 
 #define tc_add_struct_typed_call(tc, execute, type) \
((struct type*)tc_add_sized_call(tc, execute, sizeof(struct type)))
 
 #define tc_add_slot_based_call(tc, execute, type, num_slots) \
((struct type*)tc_add_sized_call(tc, execute, \
 sizeof(struct type) + \
 sizeof(((struct type*)NULL)->slot[0]) * \
-num_slots))
+(num_slots)))
 
 static union tc_payload *
 tc_add_small_call(struct threaded_context *tc, enum tc_call_id id)
 {
return tc_add_sized_call(tc, id, 0);
 }
 
 static void
 _tc_sync(struct threaded_context *tc, const char *info, const char *func)
 {
@@ -757,69 +757,75 @@ tc_set_sampler_views(struct pipe_context *_pipe,
  p->slot[i] = NULL;
  pipe_sampler_view_reference(>slot[i], views[i]);
   }
} else {
   memset(p->slot, 0, count * sizeof(views[0]));
}
 }
 
 struct tc_shader_images {
ubyte shader, start, count;
+   bool unbind;
struct pipe_image_view slot[0]; /* more will be allocated if needed */
 };
 
 static void
 tc_call_set_shader_images(struct pipe_context *pipe, union tc_payload *payload)
 {
struct tc_shader_images *p = (struct tc_shader_images *)payload;
unsigned count = p->count;
 
+   if (p->unbind) {
+  pipe->set_shader_images(pipe, p->shader, p->start, p->count, NULL);
+  return;
+   }
+
pipe->set_shader_images(pipe, p->shader, p->start, p->count, p->slot);
 
for (unsigned i = 0; i < count; i++)
   pipe_resource_reference(>slot[i].resource, NULL);
 }
 
 static void
 tc_set_shader_images(struct pipe_context *_pipe,
  enum pipe_shader_type shader,
  unsigned start, unsigned count,
  const struct pipe_image_view *images)
 {
if (!count)
   return;
 
struct threaded_context *tc = threaded_context(_pipe);
struct tc_shader_images *p =
-  tc_add_slot_based_call(tc, TC_CALL_set_shader_images, tc_shader_images, 
count);
+  tc_add_slot_based_call(tc, TC_CALL_set_shader_images, tc_shader_images,
+ images ? count : 0);
 
p->shader = shader;
p->start = start;
p->count = count;
+   p->unbind = images == NULL;
 
if (images) {
   for (unsigned i = 0; i < count; i++) {
  tc_set_resource_reference(>slot[i].resource, images[i].resource);
 
  if (images[i].access & PIPE_IMAGE_ACCESS_WRITE &&
  images[i].resource &&
  images[i].resource->target == PIPE_BUFFER) {
 struct threaded_resource *tres =
threaded_resource(images[i].resource);
 
 util_range_add(>valid_buffer_range, images[i].u.buf.offset,
images[i].u.buf.offset + images[i].u.buf.size);
  }
   }
   memcpy(p->slot, images, count * sizeof(images[0]));
-   } else {
-  memset(p->slot, 0, count * sizeof(images[0]));
}
 }
 
 struct tc_shader_buffers {
ubyte shader, start, count;
struct pipe_shader_buffer slot[0]; /* more will be allocated if needed */
 };
 
 static void
 tc_call_set_shader_buffers(struct pipe_context *pipe, union tc_payload 
*payload)
-- 
2.7.4

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

[Mesa-dev] [PATCH 1/4] glsl_to_tgsi: declare all SSBOs and atomics when indirect indexing is used

[Marek Olšák]

From: Marek Olšák 

Only the first array element was declared, so tgsi_shader_info::
shader_buffers_declared didn't match what the shader was using.
---
 src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 25 +
 1 file changed, 13 insertions(+), 12 deletions(-)

diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp 
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index 54bc70f..e4d139e 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
@@ -413,21 +413,20 @@ public:
unsigned num_inputs;
unsigned num_input_arrays;
struct inout_decl outputs[4 * PIPE_MAX_SHADER_OUTPUTS];
unsigned num_outputs;
unsigned num_output_arrays;
 
int num_address_regs;
uint32_t samplers_used;
glsl_base_type sampler_types[PIPE_MAX_SAMPLERS];
int sampler_targets[PIPE_MAX_SAMPLERS];   /**< One of TGSI_TEXTURE_* */
-   int buffers_used;
int images_used;
int image_targets[PIPE_MAX_SHADER_IMAGES];
unsigned image_formats[PIPE_MAX_SHADER_IMAGES];
bool indirect_addr_consts;
int wpos_transform_const;
 
int glsl_version;
bool native_integers;
bool have_sqrt;
bool have_fma;
@@ -4536,21 +4535,20 @@ glsl_to_tgsi_visitor::glsl_to_tgsi_visitor()
array_sizes = NULL;
max_num_arrays = 0;
next_array = 0;
num_inputs = 0;
num_outputs = 0;
num_input_arrays = 0;
num_output_arrays = 0;
num_immediates = 0;
num_address_regs = 0;
samplers_used = 0;
-   buffers_used = 0;
images_used = 0;
indirect_addr_consts = false;
wpos_transform_const = -1;
glsl_version = 0;
native_integers = false;
mem_ctx = ralloc_context(NULL);
ctx = NULL;
prog = NULL;
shader_program = NULL;
shader = NULL;
@@ -4574,21 +4572,20 @@ extern "C" void 
free_glsl_to_tgsi_visitor(glsl_to_tgsi_visitor *v)
 
 
 /**
  * Count resources used by the given gpu program (number of texture
  * samplers, etc).
  */
 static void
 count_resources(glsl_to_tgsi_visitor *v, gl_program *prog)
 {
v->samplers_used = 0;
-   v->buffers_used = 0;
v->images_used = 0;
 
foreach_in_list(glsl_to_tgsi_instruction, inst, >instructions) {
   if (inst->info->is_tex) {
  for (int i = 0; i < inst->sampler_array_size; i++) {
 unsigned idx = inst->sampler_base + i;
 v->samplers_used |= 1u << idx;
 
 debug_assert(idx < (int)ARRAY_SIZE(v->sampler_types));
 v->sampler_types[idx] = inst->tex_type;
@@ -4601,21 +4598,21 @@ count_resources(glsl_to_tgsi_visitor *v, gl_program 
*prog)
  }
   }
 
   if (inst->tex_target == TEXTURE_EXTERNAL_INDEX)
  prog->ExternalSamplersUsed |= 1 << inst->resource.index;
 
   if (inst->resource.file != PROGRAM_UNDEFINED && (
 is_resource_instruction(inst->op) ||
 inst->op == TGSI_OPCODE_STORE)) {
  if (inst->resource.file == PROGRAM_BUFFER) {
-v->buffers_used |= 1 << inst->resource.index;
+/* nothing to do */
  } else if (inst->resource.file == PROGRAM_MEMORY) {
 v->use_shared_memory = true;
  } else {
 assert(inst->resource.file == PROGRAM_IMAGE);
 for (int i = 0; i < inst->sampler_array_size; i++) {
unsigned idx = inst->sampler_base + i;
v->images_used |= 1 << idx;
v->image_targets[idx] =
   st_translate_texture_target(inst->tex_target, false);
v->image_formats[idx] = inst->image_format;
@@ -6586,30 +6583,34 @@ st_translate_program(
 break;
  default:
 unreachable("not reached");
  }
 
  ureg_DECL_sampler_view( ureg, i, program->sampler_targets[i],
  type, type, type, type );
   }
}
 
-   for (i = 0; i < frag_const->MaxAtomicBuffers; i++) {
-  if (program->buffers_used & (1 << i)) {
- t->buffers[i] = ureg_DECL_buffer(ureg, i, true);
+   /* Declare atomic and shader storage buffers. */
+   {
+  struct gl_program *prog = program->prog;
+
+  for (i = 0; i < prog->info.num_abos; i++) {
+ unsigned index = prog->sh.AtomicBuffers[i]->Binding;
+ assert(index < frag_const->MaxAtomicBuffers);
+ t->buffers[index] = ureg_DECL_buffer(ureg, index, true);
   }
-   }
 
-   for (; i < frag_const->MaxAtomicBuffers + 
frag_const->MaxShaderStorageBlocks;
-i++) {
-  if (program->buffers_used & (1 << i)) {
- t->buffers[i] = ureg_DECL_buffer(ureg, i, false);
+  assert(prog->info.num_ssbos <= frag_const->MaxShaderStorageBlocks);
+  for (i = 0; i < prog->info.num_ssbos; i++) {
+ unsigned index = frag_const->MaxAtomicBuffers + i;
+ t->buffers[index] = ureg_DECL_buffer(ureg, index, false);
   }
}
 
if (program->use_shared_memory)
   t->shared_memory = ureg_DECL_memory(ureg, TGSI_MEMORY_TYPE_SHARED);
 
for 

[Mesa-dev] [PATCH 4/4] gallium/u_threaded: add a fast path for unbinding shader buffers

[Marek Olšák]

From: Marek Olšák 

---
 src/gallium/auxiliary/util/u_threaded_context.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/src/gallium/auxiliary/util/u_threaded_context.c 
b/src/gallium/auxiliary/util/u_threaded_context.c
index e33c846..8ea7f8a 100644
--- a/src/gallium/auxiliary/util/u_threaded_context.c
+++ b/src/gallium/auxiliary/util/u_threaded_context.c
@@ -817,69 +817,75 @@ tc_set_shader_images(struct pipe_context *_pipe,
 util_range_add(>valid_buffer_range, images[i].u.buf.offset,
images[i].u.buf.offset + images[i].u.buf.size);
  }
   }
   memcpy(p->slot, images, count * sizeof(images[0]));
}
 }
 
 struct tc_shader_buffers {
ubyte shader, start, count;
+   bool unbind;
struct pipe_shader_buffer slot[0]; /* more will be allocated if needed */
 };
 
 static void
 tc_call_set_shader_buffers(struct pipe_context *pipe, union tc_payload 
*payload)
 {
struct tc_shader_buffers *p = (struct tc_shader_buffers *)payload;
unsigned count = p->count;
 
+   if (p->unbind) {
+  pipe->set_shader_buffers(pipe, p->shader, p->start, p->count, NULL);
+  return;
+   }
+
pipe->set_shader_buffers(pipe, p->shader, p->start, p->count, p->slot);
 
for (unsigned i = 0; i < count; i++)
   pipe_resource_reference(>slot[i].buffer, NULL);
 }
 
 static void
 tc_set_shader_buffers(struct pipe_context *_pipe, unsigned shader,
   unsigned start, unsigned count,
   const struct pipe_shader_buffer *buffers)
 {
if (!count)
   return;
 
struct threaded_context *tc = threaded_context(_pipe);
struct tc_shader_buffers *p =
-  tc_add_slot_based_call(tc, TC_CALL_set_shader_buffers, 
tc_shader_buffers, count);
+  tc_add_slot_based_call(tc, TC_CALL_set_shader_buffers, tc_shader_buffers,
+ buffers ? count : 0);
 
p->shader = shader;
p->start = start;
p->count = count;
+   p->unbind = buffers == NULL;
 
if (buffers) {
   for (unsigned i = 0; i < count; i++) {
  struct pipe_shader_buffer *dst = >slot[i];
  const struct pipe_shader_buffer *src = buffers + i;
 
  tc_set_resource_reference(>buffer, src->buffer);
  dst->buffer_offset = src->buffer_offset;
  dst->buffer_size = src->buffer_size;
 
  if (src->buffer) {
 struct threaded_resource *tres = threaded_resource(src->buffer);
 
 util_range_add(>valid_buffer_range, src->buffer_offset,
src->buffer_offset + src->buffer_size);
  }
   }
-   } else {
-  memset(p->slot, 0, count * sizeof(buffers[0]));
}
 }
 
 struct tc_vertex_buffers {
ubyte start, count;
bool unbind;
struct pipe_vertex_buffer slot[0]; /* more will be allocated if needed */
 };
 
 static void
-- 
2.7.4

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

[Mesa-dev] [PATCH 2/4] st/mesa: silence a valgrind warning in u_threaded_context due to st_draw_vbo

[Marek Olšák]

From: Marek Olšák 

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

diff --git a/src/mesa/state_tracker/st_draw.c b/src/mesa/state_tracker/st_draw.c
index 019001f..fe03a4a 100644
--- a/src/mesa/state_tracker/st_draw.c
+++ b/src/mesa/state_tracker/st_draw.c
@@ -177,20 +177,21 @@ st_draw_vbo(struct gl_context *ctx,
   } else {
  /* indices are in user space memory */
  info.has_user_indices = true;
  info.index.user = ib->ptr;
   }
 
   setup_primitive_restart(ctx, );
}
else {
   info.index_size = 0;
+  info.has_user_indices = false;
 
   /* 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;
   }
}
 
assert(!indirect);
-- 
2.7.4

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

Re: [Mesa-dev] [PATCH 2/2] gallium: Add renderonly-based support for pl111+vc4.

[Emil Velikov]

On 17 May 2017 at 18:53, Eric Anholt  wrote:
> Emil Velikov  writes:
>
>> Hi Eric,
>>
>> On 11 May 2017 at 00:06, Eric Anholt  wrote:
>>> This follows the model of imx (display) and etnaviv (render): pl111 is a
>>> display-only device, so when asked to do GL for it, we see if we have a
>>> vc4 renderer, make the vc4 screen, and have vc4 call back to pl111 to do
>>> scanout allocations.
>>>
>>> The difference from etnaviv is that we share the same BO between vc4 and
>>> pl111, rather than having a vc4 bo and a pl11 bo and copies between the
>>> two.  The only mismatch between their requirements is that vc4 requires
>>> 4-pixel (at 32bpp) stride alignment, while pl111 requires that stride
>>> match width.  The kernel will reject any modesets to an incorrect stride,
>>> so the 3D driver doesn't need to worry about that.
>>> ---
>> I'm not familiar with the hardware itself so I cannot comment on those.
>> There's a couple of small notes within, but overall the patch looks good.
>>
>>>  .travis.yml|  2 +-
>>>  Makefile.am|  2 +-
>> Yes, thank you!
>>
>>
>>> --- a/Android.mk
>>> +++ b/Android.mk
>>
>>>  classic_drivers := i915 i965
>>> -gallium_drivers := swrast freedreno i915g nouveau r300g r600g radeonsi 
>>> vmwgfx vc4 virgl
>>> +gallium_drivers := swrast freedreno i915g nouveau pl111 r300g r600g 
>>> radeonsi vmwgfx vc4 virgl
>>>
>> The recent Android cleanups by RobH which will cause a clash. The gist
>> is below, but feel free to skim through commit
>> 3f097396a1642bb7033002d0bdd37e194afce06a.
>>  - rework for the new gallium_drivers format
>>  - add a couple of lines in src/gallium/drivers/pl111/Android.mk
>> analogous to the vc4 - the "ifneq $HAVE_foo" hunk
>>  - drop the guard in src/gallium/Android.mk
>>
>>
>>> +++ b/src/gallium/winsys/pl111/drm/pl111_drm_winsys.c
>>
>>> -#include 
>>>  #include 
>>> +#include 
>>>
>>> -#include "vc4_drm_public.h"
>>> +#include "pl111_drm_public.h"
>>> +#include "vc4/drm/vc4_drm_public.h"
>>> +#include "xf86drm.h"
>>>
>>> -#include "vc4/vc4_screen.h"
>>> +#include "pipe/p_screen.h"
>>> +#include "renderonly/renderonly.h"
>>
>>> +#include "util/u_format.h"
>> Seems unused.
>>
>>>
>>> -struct pipe_screen *
>>> -vc4_drm_screen_create(int fd)
>>> +struct pipe_screen *pl111_drm_screen_create(int fd)
>>>  {
>>> -   return vc4_screen_create(fcntl(fd, F_DUPFD_CLOEXEC, 3));
>>> +   struct renderonly ro = {
>>> +  /* Passes the vc4-allocated BO through to the pl111 DRM device using
>>> +   * PRIME buffer sharing.  The VC4 BO must be linear, which the 
>>> SCANOUT
>>> +   * flag on allocation will have ensured.
>>> +   */
>>> +  .create_for_resource = renderonly_create_gpu_import_for_resource,
>>> +  .kms_fd = fd,
>>> +  .gpu_fd = drmOpenWithType("vc4", NULL, DRM_NODE_RENDER),
>> Please don't use the drmOpen* API. It's a legacy dragon with very
>> subtle and inner workings.
>> Using drmGetDevice[s] should provide any information that you need.
>> Alternatively please let us know what's missing so we can address it.
>
> One this platform, there are exactly two devices, one is vc4 and the
> other is pl111.  drmOpenWithType is exactly the API we want, and if you
> want something else, then you should probably replace its insides
> instead of telling people to use a different API.

Changing the insides also changes the behaviour, which could break users :-\

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

Re: [Mesa-dev] [PATCH] glxglvnddispatch: Add missing dispatch for GetDriverConfig

[Kyle Brenneman]

On 05/17/2017 12:50 PM, Emil Velikov wrote:

On 17 May 2017 at 17:05, Kyle Brenneman  wrote:


The patch assumes that glXGetDriverConfig will only ever be implemented by
Mesa. As long as that's a safe assumption, the change looks right to me.

Can you elaborate a bit more here? Both the AMDGPU-PRO stack and the
ImgTec driver used in CrOS uses Mesa as a base, thus they export the
function.
Admittedly the latter does not use GLX, AFAICT.

-Emil
The GLVND dispatch functions (dispatch_GetDriverConfig in this case) are 
what gets returned to the application from glXGetProcAddress. Normally, 
they'd figure out a vendor library based on the function parameters and 
then look up that vendor's implementation. In this case, though, the 
dispatch function calls Mesa's glXGetDriverConfig function directly.


That said, unless it can figure out a display and screen number from the 
driver name, I don't think there's much else that the dispatch function 
could do.

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

Re: [Mesa-dev] [PATCH 3/4] glsl: Merge if-simplification and conditional discard optimization

[Thomas Helland]

2017-05-16 18:42 GMT+02:00 Ian Romanick :
> On 05/16/2017 05:35 AM, Thomas Helland wrote:
>> 2017-05-16 3:31 GMT+02:00 Matt Turner :
>>> On Mon, Apr 24, 2017 at 4:50 PM, Matt Turner  wrote:
 On Thu, Apr 6, 2017 at 12:49 PM, Thomas Helland
  wrote:
> The conditional discard pass follows the same pattern, so merge the
> two, and avoid running the visitor two times.
> ---
>  src/compiler/Makefile.sources |  1 -
>  src/compiler/glsl/glsl_parser_extras.cpp  |  1 -
>  src/compiler/glsl/ir_optimization.h   |  1 -
>  src/compiler/glsl/opt_conditional_discard.cpp | 88 
> ---
>  src/compiler/glsl/opt_if_simplification.cpp   | 50 +++
>  5 files changed, 39 insertions(+), 102 deletions(-)
>  delete mode 100644 src/compiler/glsl/opt_conditional_discard.cpp
>
> diff --git a/src/compiler/Makefile.sources b/src/compiler/Makefile.sources
> index 5197c31bb3..817ab3a755 100644
> --- a/src/compiler/Makefile.sources
> +++ b/src/compiler/Makefile.sources
> @@ -114,7 +114,6 @@ LIBGLSL_FILES = \
> glsl/lower_ubo_reference.cpp \
> glsl/opt_algebraic.cpp \
> glsl/opt_array_splitting.cpp \
> -   glsl/opt_conditional_discard.cpp \
> glsl/opt_constant_folding.cpp \
> glsl/opt_constant_propagation.cpp \
> glsl/opt_constant_variable.cpp \
> diff --git a/src/compiler/glsl/glsl_parser_extras.cpp 
> b/src/compiler/glsl/glsl_parser_extras.cpp
> index 307e0d6215..fe25c23ccc 100644
> --- a/src/compiler/glsl/glsl_parser_extras.cpp
> +++ b/src/compiler/glsl/glsl_parser_extras.cpp
> @@ -2139,7 +2139,6 @@ do_common_optimization(exec_list *ir, bool linked,
> }
> propagate_invariance(ir);
> OPT(do_if_simplification, ir);
> -   OPT(opt_conditional_discard, ir);
> OPT(do_copy_propagation, ir);
> OPT(do_copy_propagation_elements, ir);
>
> diff --git a/src/compiler/glsl/ir_optimization.h 
> b/src/compiler/glsl/ir_optimization.h
> index 5d57ca85fd..022b7ab12f 100644
> --- a/src/compiler/glsl/ir_optimization.h
> +++ b/src/compiler/glsl/ir_optimization.h
> @@ -93,7 +93,6 @@ bool ir_constant_fold(ir_rvalue **rvalue);
>  bool do_rebalance_tree(exec_list *instructions);
>  bool do_algebraic(exec_list *instructions, bool native_integers,
>const struct gl_shader_compiler_options *options);
> -bool opt_conditional_discard(exec_list *instructions);
>  bool do_constant_folding(exec_list *instructions);
>  bool do_constant_variable(exec_list *instructions);
>  bool do_constant_variable_unlinked(exec_list *instructions);
> diff --git a/src/compiler/glsl/opt_conditional_discard.cpp 
> b/src/compiler/glsl/opt_conditional_discard.cpp
> deleted file mode 100644
> index 6d8a23460d..00
> --- a/src/compiler/glsl/opt_conditional_discard.cpp
> +++ /dev/null
> @@ -1,88 +0,0 @@
> -/*
> - * Copyright © 2014 Intel Corporation
> - *
> - * Permission is hereby granted, free of charge, to any person obtaining 
> a
> - * copy of this software and associated documentation files (the 
> "Software"),
> - * to deal in the Software without restriction, including without 
> limitation
> - * the rights to use, copy, modify, merge, publish, distribute, 
> sublicense,
> - * and/or sell copies of the Software, and to permit persons to whom the
> - * Software is furnished to do so, subject to the following conditions:
> - *
> - * The above copyright notice and this permission notice (including the 
> next
> - * paragraph) shall be included in all copies or substantial portions of 
> the
> - * Software.
> - *
> - * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, 
> EXPRESS OR
> - * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF 
> MERCHANTABILITY,
> - * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT 
> SHALL
> - * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR 
> OTHER
> - * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, 
> ARISING
> - * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> - * DEALINGS IN THE SOFTWARE.
> - */
> -
> -/**
> - * \file opt_conditional_discard.cpp
> - *
> - * Replace
> - *
> - *if (cond) discard;
> - *
> - * with
> - *
> - *(discard )
> - */
> -
> -#include "compiler/glsl_types.h"
> -#include "ir.h"
> -
> -namespace {
> -
> -class opt_conditional_discard_visitor : public ir_hierarchical_visitor {
> -public:
> -   opt_conditional_discard_visitor()
> -   {
> - 

Re: [Mesa-dev] [PATCH] glxglvnddispatch: Add missing dispatch for GetDriverConfig

[Emil Velikov]

On 17 May 2017 at 17:05, Kyle Brenneman  wrote:

> The patch assumes that glXGetDriverConfig will only ever be implemented by
> Mesa. As long as that's a safe assumption, the change looks right to me.

Can you elaborate a bit more here? Both the AMDGPU-PRO stack and the
ImgTec driver used in CrOS uses Mesa as a base, thus they export the
function.
Admittedly the latter does not use GLX, AFAICT.

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

Re: [Mesa-dev] [PATCH v2 2/3] tgsi: store the sampler view type directly in the instruction

[Samuel Pitoiset]

On 05/17/2017 08:03 PM, Marek Olšák wrote:

mesa_to_tgsi is for the old Mesa IR. The return type is always FLOAT.
Same for atifs_to_tgsi.


Ah okay, I will change this.



Marek

On Wed, May 17, 2017 at 7:06 PM, Samuel Pitoiset
 wrote:

RadeonSI needs to do a special lowering for Gather4 with integer
formats, but with bindless samplers we just can't access the index.

Instead, store the return type in the instruction like the target.

v2: - fix padding
 - initialize default value of ReturnType
 - replace debug_assert() by assert()

Signed-off-by: Samuel Pitoiset 
---
  src/gallium/auxiliary/tgsi/tgsi_build.c|  6 +-
  src/gallium/auxiliary/tgsi/tgsi_ureg.c |  7 +--
  src/gallium/auxiliary/tgsi/tgsi_ureg.h | 11 ---
  src/gallium/include/pipe/p_shader_tokens.h |  4 +++-
  src/mesa/state_tracker/st_atifs_to_tgsi.c  |  2 +-
  src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 17 ++---
  src/mesa/state_tracker/st_mesa_to_tgsi.c   | 21 +
  src/mesa/state_tracker/st_mesa_to_tgsi.h   |  4 
  8 files changed, 49 insertions(+), 23 deletions(-)

diff --git a/src/gallium/auxiliary/tgsi/tgsi_build.c 
b/src/gallium/auxiliary/tgsi/tgsi_build.c
index 39c20b5e88..00843241f8 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_build.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_build.c
@@ -720,6 +720,7 @@ tgsi_default_instruction_texture( void )

 instruction_texture.Texture = TGSI_TEXTURE_UNKNOWN;
 instruction_texture.NumOffsets = 0;
+   instruction_texture.ReturnType = TGSI_RETURN_TYPE_UNKNOWN;
 instruction_texture.Padding = 0;

 return instruction_texture;
@@ -729,6 +730,7 @@ static struct tgsi_instruction_texture
  tgsi_build_instruction_texture(
 unsigned texture,
 unsigned num_offsets,
+   unsigned return_type,
 struct tgsi_token *prev_token,
 struct tgsi_instruction *instruction,
 struct tgsi_header *header )
@@ -737,6 +739,7 @@ tgsi_build_instruction_texture(

 instruction_texture.Texture = texture;
 instruction_texture.NumOffsets = num_offsets;
+   instruction_texture.ReturnType = return_type;
 instruction_texture.Padding = 0;
 instruction->Texture = 1;

@@ -1090,7 +1093,8 @@ tgsi_build_full_instruction(

*instruction_texture = tgsi_build_instruction_texture(
   full_inst->Texture.Texture,
-full_inst->Texture.NumOffsets,
+ full_inst->Texture.NumOffsets,
+ full_inst->Texture.ReturnType,
   prev_token,
   instruction,
   header   );
diff --git a/src/gallium/auxiliary/tgsi/tgsi_ureg.c 
b/src/gallium/auxiliary/tgsi/tgsi_ureg.c
index 9eb00d0919..5bd779728a 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_ureg.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_ureg.c
@@ -1289,7 +1289,7 @@ ureg_fixup_label(struct ureg_program *ureg,
  void
  ureg_emit_texture(struct ureg_program *ureg,
unsigned extended_token,
-  unsigned target, unsigned num_offsets)
+  unsigned target, unsigned return_type, unsigned num_offsets)
  {
 union tgsi_any_token *out, *insn;

@@ -1301,6 +1301,7 @@ ureg_emit_texture(struct ureg_program *ureg,
 out[0].value = 0;
 out[0].insn_texture.Texture = target;
 out[0].insn_texture.NumOffsets = num_offsets;
+   out[0].insn_texture.ReturnType = return_type;
  }

  void
@@ -1386,6 +1387,7 @@ ureg_tex_insn(struct ureg_program *ureg,
const struct ureg_dst *dst,
unsigned nr_dst,
unsigned target,
+  unsigned return_type,
const struct tgsi_texture_offset *texoffsets,
unsigned nr_offset,
const struct ureg_src *src,
@@ -1407,7 +1409,8 @@ ureg_tex_insn(struct ureg_program *ureg,
   nr_dst,
   nr_src);

-   ureg_emit_texture( ureg, insn.extended_token, target, nr_offset );
+   ureg_emit_texture( ureg, insn.extended_token, target, return_type,
+  nr_offset );

 for (i = 0; i < nr_offset; i++)
ureg_emit_texture_offset( ureg, [i]);
diff --git a/src/gallium/auxiliary/tgsi/tgsi_ureg.h 
b/src/gallium/auxiliary/tgsi/tgsi_ureg.h
index 6d2f5c0e99..54f95ba565 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_ureg.h
+++ b/src/gallium/auxiliary/tgsi/tgsi_ureg.h
@@ -555,6 +555,7 @@ ureg_tex_insn(struct ureg_program *ureg,
const struct ureg_dst *dst,
unsigned nr_dst,
unsigned target,
+  unsigned return_type,
const struct tgsi_texture_offset *texoffsets,
unsigned nr_offset,
const struct ureg_src *src,
@@ -596,7 +597,7 @@ ureg_emit_label(struct ureg_program *ureg,
  void
  ureg_emit_texture(struct ureg_program *ureg,
unsigned insn_token,
-  unsigned target, unsigned num_offsets);
+  unsigned target, unsigned return_type, 

Re: [Mesa-dev] [PATCH 2/3] tgsi: store the sampler view type directly in the instruction

[Samuel Pitoiset]

On 05/17/2017 08:06 PM, Ilia Mirkin wrote:

On Wed, May 17, 2017 at 5:17 AM, Samuel Pitoiset
 wrote:

@@ -695,6 +696,7 @@ struct tgsi_instruction_texture
 unsigned Texture  : 8;/* TGSI_TEXTURE_ */
 unsigned NumOffsets : 4;
 unsigned Padding : 20;
+   unsigned ReturnType : 3; /* TGSI_RETURN_TYPE_x */
  };

  /* for texture offsets in GLSL and DirectX.


You really want to add that second word? Instead of, say, reducing the
padding by 3 bits?


Fixed in v2. :)




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

Re: [Mesa-dev] [PATCH 11/11] intel/aubinator_error_decode: Disassemble shader programs

[Anuj Phogat]

On Wed, May 17, 2017 at 10:51 AM, Matt Turner  wrote:
> On Wed, May 17, 2017 at 9:29 AM, Anuj Phogat  wrote:
>> On Mon, May 1, 2017 at 1:54 PM, Matt Turner  wrote:
>>> ---
>>>  src/intel/Makefile.tools.am  |   6 +-
>>>  src/intel/tools/aubinator_error_decode.c | 178 
>>> ++-
>>>  2 files changed, 180 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/src/intel/Makefile.tools.am b/src/intel/Makefile.tools.am
>>> index 576beea..1175118 100644
>>> --- a/src/intel/Makefile.tools.am
>>> +++ b/src/intel/Makefile.tools.am
>>> @@ -47,11 +47,15 @@ tools_aubinator_LDADD = \
>>>
>>>
>>>  tools_aubinator_error_decode_SOURCES = \
>>> -   tools/aubinator_error_decode.c
>>> +   tools/aubinator_error_decode.c \
>>> +   tools/disasm.c \
>>> +   tools/gen_disasm.h
>>>
>>>  tools_aubinator_error_decode_LDADD = \
>>> common/libintel_common.la \
>>> +   compiler/libintel_compiler.la \
>>> $(top_builddir)/src/util/libmesautil.la \
>>> +   $(PTHREAD_LIBS) \
>>> $(EXPAT_LIBS) \
>>> $(ZLIB_LIBS)
>>>
>>> diff --git a/src/intel/tools/aubinator_error_decode.c 
>>> b/src/intel/tools/aubinator_error_decode.c
>>> index 244bef8..ef77c01 100644
>>> --- a/src/intel/tools/aubinator_error_decode.c
>>> +++ b/src/intel/tools/aubinator_error_decode.c
>>> @@ -40,6 +40,7 @@
>>>
>>>  #include "common/gen_decoder.h"
>>>  #include "util/macros.h"
>>> +#include "gen_disasm.h"
>>>
>>>  #define CSI "\e["
>>>  #define BLUE_HEADER  CSI "0;44m"
>>> @@ -209,6 +210,17 @@ print_fault_data(struct gen_device_info *devinfo, 
>>> uint32_t data1, uint32_t data0
>>>  #define CSI "\e["
>>>  #define NORMAL   CSI "0m"
>>>
>>> +struct program {
>>> +   const char *type;
>>> +   const char *command;
>>> +   uint64_t command_offset;
>>> +   uint64_t instruction_base_address;
>>> +   uint64_t ksp;
>>> +};
>>> +
>>> +static struct program programs[4096];
>>> +static int num_programs = 0;
>>> +
>>>  static void decode(struct gen_spec *spec,
>>> const char *buffer_name,
>>> const char *ring_name,
>>> @@ -219,6 +231,7 @@ static void decode(struct gen_spec *spec,
>>> uint32_t *p, *end = (data + *count);
>>> int length;
>>> struct gen_group *inst;
>>> +   uint64_t current_instruction_base_address = 0;
>>>
>>> for (p = data; p < end; p += length) {
>>>const char *color = option_full_decode ? BLUE_HEADER : NORMAL,
>>> @@ -246,6 +259,127 @@ static void decode(struct gen_spec *spec,
>>>
>>>if (strcmp(inst->name, "MI_BATCH_BUFFER_END") == 0)
>>>   break;
>>> +
>>> +  if (strcmp(inst->name, "STATE_BASE_ADDRESS") == 0) {
>>> + struct gen_field_iterator iter;
>>> + gen_field_iterator_init(, inst, p, false);
>>> +
>>> + while (gen_field_iterator_next()) {
>>> +if (strcmp(iter.name, "Instruction Base Address") == 0) {
>>> +   current_instruction_base_address = strtol(iter.value, NULL, 
>>> 16);
>>> +}
>>> + }
>>> +  } else if (strcmp(inst->name,   "WM_STATE") == 0 ||
>>> + strcmp(inst->name, "3DSTATE_PS") == 0 ||
>>> + strcmp(inst->name, "3DSTATE_WM") == 0) {
>>> + struct gen_field_iterator iter;
>>> + gen_field_iterator_init(, inst, p, false);
>>> + uint64_t ksp[3] = {0, 0, 0};
>>> + bool enabled[3] = {false, false, false};
>>> +
>>> + while (gen_field_iterator_next()) {
>>> +if (strncmp(iter.name, "Kernel Start Pointer ",
>>> +strlen("Kernel Start Pointer ")) == 0) {
>>> +   int idx = iter.name[strlen("Kernel Start Pointer ")] - '0';
>>> +   ksp[idx] = strtol(iter.value, NULL, 16);
>>> +} else if (strcmp(iter.name, "8 Pixel Dispatch Enable") == 0) {
>>> +   enabled[0] = strcmp(iter.value, "true") == 0;
>>> +} else if (strcmp(iter.name, "16 Pixel Dispatch Enable") == 0) 
>>> {
>>> +   enabled[1] = strcmp(iter.value, "true") == 0;
>>> +} else if (strcmp(iter.name, "32 Pixel Dispatch Enable") == 0) 
>>> {
>>> +   enabled[2] = strcmp(iter.value, "true") == 0;
>>> +}
>>> + }
>>> +
>>> + /* FINISHME: Broken for multi-program WM_STATE,
>>> +  * which Mesa does not use
>>> +  */
>>> + if (enabled[0] + enabled[1] + enabled[2] == 1) {
>>> +const char *type = enabled[0] ? "SIMD8 fragment shader" :
>>> +   enabled[1] ? "SIMD16 fragment shader" :
>>> +   enabled[2] ? "SIMD32 fragment shader" : 
>>> NULL;
>>> +
>>> +programs[num_programs++] = (struct program) {
>>> +   .type = type,
>>> +   .command = inst->name,
>>> +   .command_offset = offset,
>>> +   .instruction_base_address = 
>>> 

Re: [Mesa-dev] [RFC] Deprecating old DRI loaders/drivers

[Marek Olšák]

On Wed, May 17, 2017 at 7:36 PM, Ilia Mirkin  wrote:
> On Wed, May 17, 2017 at 1:26 PM, Ian Romanick  wrote:
>> On 05/16/2017 09:04 PM, Jason Ekstrand wrote:
>>> On May 16, 2017 18:30:00 Timothy Arceri  wrote:
>>>
 On 17/05/17 02:38, Ian Romanick wrote:
> What *actual* problem are you trying to solve?  Honestly, it seems like
> you're just trying to find stuff to do.  We have a mechanism to make
> this work, and it's not that hard.  Introducing a deprecation period and
> everything that involves will make it more work, not less.
>>>
>>> I think that's a fair question
>>>
 To be fair aren't we in a stage in Mesa's life-cycle where the focus is
 on tidying-up / optimisations. It's not like there are large spec
 updates in the pipeline.
>>>
>>> If we are genuinely making things more maintainable, then maybe
>>> deprecation is reasonable.  However, of it's just churn, then it may
>>> just be a source of new bugs to fix.  I think asking "why?" is perfectly
>>> reasonable.
>>>
>>> On the other side, perhaps we should consider instead taking advantage
>>> of the backwards comparability and dropping some of the old and
>>> unmaintained drivers from the tree, put them on a critical-bugfix-only
>>> branch, and recommend that distros build two mesas and only install the
>>> loader from the newer one.  Dropping i915, r200, and other effectively
>>> unmaintained drivers from the tree would make it much easier to do core
>>> state tracker cleanups since there would effectively only be two state
>>> trackers: gallium and i915. For example, there's a lot of code floating
>>> around for dealing with hardware that doesn't have native integers.
>>
>> r300 and r400 in Gallium do not have native integers.  I don't know
>> about NV30.
>
> NV30 does not have native integers. Neither does a2xx. Not sure about etnaviv.
>
>> I wanted to remove support for NV04 and NV05 last year because they are
>> unused, unmaintained, and demonstrably *broken*, and I could not even
>> get consensus on that.
>
> For the record, they work and are maintained (although imperfect, with
> some known breakage). Maintained, to me, means "if someone comes with
> an issue, there will be an attempt to address it". But they're rarely
> tested, and questionably used by anyone other than the tester (me),
> and only on NV5, as I don't have a NV4.
>
> Separately, I'd definitely consider a discussion about cleaving off
> the post-modern-times drivers (DX10+ hardware) from the
> pre-modern-times hardware (DX9 and older), and moving those off into a
> mesa-pre-dx9 repository. I doubt there are too many bugs/features for
> those that would greatly benefit from a shared repository. And mesa
> could shed a ton of support code in the process. On both sides.

This is the boldest proposal I've seen so far. I have some sentimental
feelings about gallium/r300, but if it were the only driver without
native integer support blocking some major Mesa cleanup, I would let
it go. If we wanna discuss driver removal, the most likely candidates
are i915g (completely broken currently) and maybe some classic
drivers. I guess some people have feelings about their classic drivers
too, but at the end of the day we have to decide what's best for the
future.

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

Re: [Mesa-dev] [RFC] Deprecating old DRI loaders/drivers

[Christian Gmeiner]

2017-05-17 20:03 GMT+02:00 Rob Clark :
> On Wed, May 17, 2017 at 1:36 PM, Ilia Mirkin  wrote:
>> On Wed, May 17, 2017 at 1:26 PM, Ian Romanick  wrote:
>>> On 05/16/2017 09:04 PM, Jason Ekstrand wrote:
 On May 16, 2017 18:30:00 Timothy Arceri  wrote:

> On 17/05/17 02:38, Ian Romanick wrote:
>> What *actual* problem are you trying to solve?  Honestly, it seems like
>> you're just trying to find stuff to do.  We have a mechanism to make
>> this work, and it's not that hard.  Introducing a deprecation period and
>> everything that involves will make it more work, not less.

 I think that's a fair question

> To be fair aren't we in a stage in Mesa's life-cycle where the focus is
> on tidying-up / optimisations. It's not like there are large spec
> updates in the pipeline.

 If we are genuinely making things more maintainable, then maybe
 deprecation is reasonable.  However, of it's just churn, then it may
 just be a source of new bugs to fix.  I think asking "why?" is perfectly
 reasonable.

 On the other side, perhaps we should consider instead taking advantage
 of the backwards comparability and dropping some of the old and
 unmaintained drivers from the tree, put them on a critical-bugfix-only
 branch, and recommend that distros build two mesas and only install the
 loader from the newer one.  Dropping i915, r200, and other effectively
 unmaintained drivers from the tree would make it much easier to do core
 state tracker cleanups since there would effectively only be two state
 trackers: gallium and i915. For example, there's a lot of code floating
 around for dealing with hardware that doesn't have native integers.
>>>
>>> r300 and r400 in Gallium do not have native integers.  I don't know
>>> about NV30.
>>
>> NV30 does not have native integers. Neither does a2xx. Not sure about 
>> etnaviv.
>
> It doesn't look like etnaviv currently supports native integers.  But
> I guess some variants do (since some support gles3/gles31).  There are
> also still folks who want to use a2xx (although not sure that I've
> seen any patches posted yet).
>
> I think dropping support for gallium drivers that don't support
> integers would be rather unfortunate.  The older classic drivers might
> be a different story.
>

I have the same opinion as Rob. There are variants of viv gpus that
support integers
and that fact is hidden behind a feature flag that the gallium driver
should take care of
(in some near future - hopefully).

greets
--
Christian Gmeiner, MSc

https://www.youtube.com/user/AloryOFFICIAL
https://soundcloud.com/christian-gmeiner


> BR,
> -R
>
>>> I wanted to remove support for NV04 and NV05 last year because they are
>>> unused, unmaintained, and demonstrably *broken*, and I could not even
>>> get consensus on that.
>>
>> For the record, they work and are maintained (although imperfect, with
>> some known breakage). Maintained, to me, means "if someone comes with
>> an issue, there will be an attempt to address it". But they're rarely
>> tested, and questionably used by anyone other than the tester (me),
>> and only on NV5, as I don't have a NV4.
>>
>> Separately, I'd definitely consider a discussion about cleaving off
>> the post-modern-times drivers (DX10+ hardware) from the
>> pre-modern-times hardware (DX9 and older), and moving those off into a
>> mesa-pre-dx9 repository. I doubt there are too many bugs/features for
>> those that would greatly benefit from a shared repository. And mesa
>> could shed a ton of support code in the process. On both sides.
>>
>>   -ilia
>> ___
>> 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 07/43] intel/isl: Add support for gen4 cube maps to get_image_offset_sa

[Pohjolainen, Topi]

On Wed, May 17, 2017 at 02:40:55AM -0700, Kenneth Graunke wrote:
> On Tuesday, May 16, 2017 11:29:32 PM PDT Pohjolainen, Topi wrote:
> > On Tue, May 16, 2017 at 03:45:01PM -0700, Jason Ekstrand wrote:
> > > Gen4 cube maps are a 2-D surface with ISL_DIM_LAYOUT_GEN4_3D which is a
> > > bit weird but accurate none the less.
> > > ---
> > >  src/intel/isl/isl.c | 23 ++-
> > >  1 file changed, 18 insertions(+), 5 deletions(-)
> > > 
> > > diff --git a/src/intel/isl/isl.c b/src/intel/isl/isl.c
> > > index f70e188..c728a85 100644
> > > --- a/src/intel/isl/isl.c
> > > +++ b/src/intel/isl/isl.c
> > > @@ -1829,8 +1829,15 @@ get_image_offset_sa_gen4_3d(const struct isl_surf 
> > > *surf,
> > >  uint32_t *y_offset_sa)
> > >  {
> > > assert(level < surf->levels);
> > > -   assert(logical_z_offset_px < isl_minify(surf->phys_level0_sa.depth, 
> > > level));
> > > -   assert(surf->phys_level0_sa.array_len == 1);
> > > +   if (surf->dim == ISL_SURF_DIM_3D) {
> > > +  assert(surf->phys_level0_sa.array_len == 1);
> > > +  assert(logical_z_offset_px < 
> > > isl_minify(surf->phys_level0_sa.depth, level));
> > > +   } else {
> > > +  assert(surf->dim == ISL_SURF_DIM_2D);
> > > +  assert(surf->usage & ISL_SURF_USAGE_CUBE_BIT);
> > > +  assert(surf->phys_level0_sa.array_len == 6);
> > 
> > Doesn't CUBE_MAP_ARRAY come here?
> 
> Nope - GL_ARB_texture_cube_map_array is Gen6+ only.  It'll never happen
> on Gen4-5.  Old hardware doesn't have cube array support.

Okay, I didn't even think there wasn't support on older hw.

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

Re: [Mesa-dev] [PATCH 2/3] tgsi: store the sampler view type directly in the instruction

[Ilia Mirkin]

On Wed, May 17, 2017 at 5:17 AM, Samuel Pitoiset
 wrote:
> @@ -695,6 +696,7 @@ struct tgsi_instruction_texture
> unsigned Texture  : 8;/* TGSI_TEXTURE_ */
> unsigned NumOffsets : 4;
> unsigned Padding : 20;
> +   unsigned ReturnType : 3; /* TGSI_RETURN_TYPE_x */
>  };
>
>  /* for texture offsets in GLSL and DirectX.

You really want to add that second word? Instead of, say, reducing the
padding by 3 bits?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/3] radeonsi: get the sampler view type from inst->Texture for TG4

[Marek Olšák]

On Wed, May 17, 2017 at 11:17 AM, Samuel Pitoiset
 wrote:
> This will also magically fix this special lowering for
> bindless samplers.
>
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/gallium/drivers/radeonsi/si_shader_tgsi_mem.c | 7 +++
>  1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/src/gallium/drivers/radeonsi/si_shader_tgsi_mem.c 
> b/src/gallium/drivers/radeonsi/si_shader_tgsi_mem.c
> index 13b46949d0..cd40d3eeaf 100644
> --- a/src/gallium/drivers/radeonsi/si_shader_tgsi_mem.c
> +++ b/src/gallium/drivers/radeonsi/si_shader_tgsi_mem.c
> @@ -1772,17 +1772,16 @@ static void build_tex_intrinsic(const struct 
> lp_build_tgsi_action *action,
> /* The hardware needs special lowering for Gather4 with integer 
> formats. */
> if (ctx->screen->b.chip_class <= VI &&
> opcode == TGSI_OPCODE_TG4) {
> -   struct tgsi_shader_info *info = >shader->selector->info;
> /* This will also work with non-constant indexing because of 
> how
>  * glsl_to_tgsi works and we intent to preserve that behavior.
>  */

This comment can be removed, because it talks about getting the return
type from declarations.

With my comments on patch 2 & 3 addressed, the series is:

Reviewed-by: Marek Olšák 

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

Re: [Mesa-dev] [PATCH v2 2/3] tgsi: store the sampler view type directly in the instruction

[Marek Olšák]

mesa_to_tgsi is for the old Mesa IR. The return type is always FLOAT.
Same for atifs_to_tgsi.

Marek

On Wed, May 17, 2017 at 7:06 PM, Samuel Pitoiset
 wrote:
> RadeonSI needs to do a special lowering for Gather4 with integer
> formats, but with bindless samplers we just can't access the index.
>
> Instead, store the return type in the instruction like the target.
>
> v2: - fix padding
> - initialize default value of ReturnType
> - replace debug_assert() by assert()
>
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/gallium/auxiliary/tgsi/tgsi_build.c|  6 +-
>  src/gallium/auxiliary/tgsi/tgsi_ureg.c |  7 +--
>  src/gallium/auxiliary/tgsi/tgsi_ureg.h | 11 ---
>  src/gallium/include/pipe/p_shader_tokens.h |  4 +++-
>  src/mesa/state_tracker/st_atifs_to_tgsi.c  |  2 +-
>  src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 17 ++---
>  src/mesa/state_tracker/st_mesa_to_tgsi.c   | 21 +
>  src/mesa/state_tracker/st_mesa_to_tgsi.h   |  4 
>  8 files changed, 49 insertions(+), 23 deletions(-)
>
> diff --git a/src/gallium/auxiliary/tgsi/tgsi_build.c 
> b/src/gallium/auxiliary/tgsi/tgsi_build.c
> index 39c20b5e88..00843241f8 100644
> --- a/src/gallium/auxiliary/tgsi/tgsi_build.c
> +++ b/src/gallium/auxiliary/tgsi/tgsi_build.c
> @@ -720,6 +720,7 @@ tgsi_default_instruction_texture( void )
>
> instruction_texture.Texture = TGSI_TEXTURE_UNKNOWN;
> instruction_texture.NumOffsets = 0;
> +   instruction_texture.ReturnType = TGSI_RETURN_TYPE_UNKNOWN;
> instruction_texture.Padding = 0;
>
> return instruction_texture;
> @@ -729,6 +730,7 @@ static struct tgsi_instruction_texture
>  tgsi_build_instruction_texture(
> unsigned texture,
> unsigned num_offsets,
> +   unsigned return_type,
> struct tgsi_token *prev_token,
> struct tgsi_instruction *instruction,
> struct tgsi_header *header )
> @@ -737,6 +739,7 @@ tgsi_build_instruction_texture(
>
> instruction_texture.Texture = texture;
> instruction_texture.NumOffsets = num_offsets;
> +   instruction_texture.ReturnType = return_type;
> instruction_texture.Padding = 0;
> instruction->Texture = 1;
>
> @@ -1090,7 +1093,8 @@ tgsi_build_full_instruction(
>
>*instruction_texture = tgsi_build_instruction_texture(
>   full_inst->Texture.Texture,
> -full_inst->Texture.NumOffsets,
> + full_inst->Texture.NumOffsets,
> + full_inst->Texture.ReturnType,
>   prev_token,
>   instruction,
>   header   );
> diff --git a/src/gallium/auxiliary/tgsi/tgsi_ureg.c 
> b/src/gallium/auxiliary/tgsi/tgsi_ureg.c
> index 9eb00d0919..5bd779728a 100644
> --- a/src/gallium/auxiliary/tgsi/tgsi_ureg.c
> +++ b/src/gallium/auxiliary/tgsi/tgsi_ureg.c
> @@ -1289,7 +1289,7 @@ ureg_fixup_label(struct ureg_program *ureg,
>  void
>  ureg_emit_texture(struct ureg_program *ureg,
>unsigned extended_token,
> -  unsigned target, unsigned num_offsets)
> +  unsigned target, unsigned return_type, unsigned 
> num_offsets)
>  {
> union tgsi_any_token *out, *insn;
>
> @@ -1301,6 +1301,7 @@ ureg_emit_texture(struct ureg_program *ureg,
> out[0].value = 0;
> out[0].insn_texture.Texture = target;
> out[0].insn_texture.NumOffsets = num_offsets;
> +   out[0].insn_texture.ReturnType = return_type;
>  }
>
>  void
> @@ -1386,6 +1387,7 @@ ureg_tex_insn(struct ureg_program *ureg,
>const struct ureg_dst *dst,
>unsigned nr_dst,
>unsigned target,
> +  unsigned return_type,
>const struct tgsi_texture_offset *texoffsets,
>unsigned nr_offset,
>const struct ureg_src *src,
> @@ -1407,7 +1409,8 @@ ureg_tex_insn(struct ureg_program *ureg,
>   nr_dst,
>   nr_src);
>
> -   ureg_emit_texture( ureg, insn.extended_token, target, nr_offset );
> +   ureg_emit_texture( ureg, insn.extended_token, target, return_type,
> +  nr_offset );
>
> for (i = 0; i < nr_offset; i++)
>ureg_emit_texture_offset( ureg, [i]);
> diff --git a/src/gallium/auxiliary/tgsi/tgsi_ureg.h 
> b/src/gallium/auxiliary/tgsi/tgsi_ureg.h
> index 6d2f5c0e99..54f95ba565 100644
> --- a/src/gallium/auxiliary/tgsi/tgsi_ureg.h
> +++ b/src/gallium/auxiliary/tgsi/tgsi_ureg.h
> @@ -555,6 +555,7 @@ ureg_tex_insn(struct ureg_program *ureg,
>const struct ureg_dst *dst,
>unsigned nr_dst,
>unsigned target,
> +  unsigned return_type,
>const struct tgsi_texture_offset *texoffsets,
>unsigned nr_offset,
>const struct ureg_src *src,
> @@ -596,7 +597,7 @@ ureg_emit_label(struct ureg_program *ureg,
>  void
>  ureg_emit_texture(struct ureg_program *ureg,
>unsigned insn_token,
> -  unsigned 

Re: [Mesa-dev] [RFC] Deprecating old DRI loaders/drivers

[Rob Clark]

On Wed, May 17, 2017 at 1:36 PM, Ilia Mirkin  wrote:
> On Wed, May 17, 2017 at 1:26 PM, Ian Romanick  wrote:
>> On 05/16/2017 09:04 PM, Jason Ekstrand wrote:
>>> On May 16, 2017 18:30:00 Timothy Arceri  wrote:
>>>
 On 17/05/17 02:38, Ian Romanick wrote:
> What *actual* problem are you trying to solve?  Honestly, it seems like
> you're just trying to find stuff to do.  We have a mechanism to make
> this work, and it's not that hard.  Introducing a deprecation period and
> everything that involves will make it more work, not less.
>>>
>>> I think that's a fair question
>>>
 To be fair aren't we in a stage in Mesa's life-cycle where the focus is
 on tidying-up / optimisations. It's not like there are large spec
 updates in the pipeline.
>>>
>>> If we are genuinely making things more maintainable, then maybe
>>> deprecation is reasonable.  However, of it's just churn, then it may
>>> just be a source of new bugs to fix.  I think asking "why?" is perfectly
>>> reasonable.
>>>
>>> On the other side, perhaps we should consider instead taking advantage
>>> of the backwards comparability and dropping some of the old and
>>> unmaintained drivers from the tree, put them on a critical-bugfix-only
>>> branch, and recommend that distros build two mesas and only install the
>>> loader from the newer one.  Dropping i915, r200, and other effectively
>>> unmaintained drivers from the tree would make it much easier to do core
>>> state tracker cleanups since there would effectively only be two state
>>> trackers: gallium and i915. For example, there's a lot of code floating
>>> around for dealing with hardware that doesn't have native integers.
>>
>> r300 and r400 in Gallium do not have native integers.  I don't know
>> about NV30.
>
> NV30 does not have native integers. Neither does a2xx. Not sure about etnaviv.

It doesn't look like etnaviv currently supports native integers.  But
I guess some variants do (since some support gles3/gles31).  There are
also still folks who want to use a2xx (although not sure that I've
seen any patches posted yet).

I think dropping support for gallium drivers that don't support
integers would be rather unfortunate.  The older classic drivers might
be a different story.

BR,
-R

>> I wanted to remove support for NV04 and NV05 last year because they are
>> unused, unmaintained, and demonstrably *broken*, and I could not even
>> get consensus on that.
>
> For the record, they work and are maintained (although imperfect, with
> some known breakage). Maintained, to me, means "if someone comes with
> an issue, there will be an attempt to address it". But they're rarely
> tested, and questionably used by anyone other than the tester (me),
> and only on NV5, as I don't have a NV4.
>
> Separately, I'd definitely consider a discussion about cleaving off
> the post-modern-times drivers (DX10+ hardware) from the
> pre-modern-times hardware (DX9 and older), and moving those off into a
> mesa-pre-dx9 repository. I doubt there are too many bugs/features for
> those that would greatly benefit from a shared repository. And mesa
> could shed a ton of support code in the process. On both sides.
>
>   -ilia
> ___
> 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/2] gallium: Add renderonly-based support for pl111+vc4.

[Eric Anholt]

Emil Velikov  writes:

> Hi Eric,
>
> On 11 May 2017 at 00:06, Eric Anholt  wrote:
>> This follows the model of imx (display) and etnaviv (render): pl111 is a
>> display-only device, so when asked to do GL for it, we see if we have a
>> vc4 renderer, make the vc4 screen, and have vc4 call back to pl111 to do
>> scanout allocations.
>>
>> The difference from etnaviv is that we share the same BO between vc4 and
>> pl111, rather than having a vc4 bo and a pl11 bo and copies between the
>> two.  The only mismatch between their requirements is that vc4 requires
>> 4-pixel (at 32bpp) stride alignment, while pl111 requires that stride
>> match width.  The kernel will reject any modesets to an incorrect stride,
>> so the 3D driver doesn't need to worry about that.
>> ---
> I'm not familiar with the hardware itself so I cannot comment on those.
> There's a couple of small notes within, but overall the patch looks good.
>
>>  .travis.yml|  2 +-
>>  Makefile.am|  2 +-
> Yes, thank you!
>
>
>> --- a/Android.mk
>> +++ b/Android.mk
>
>>  classic_drivers := i915 i965
>> -gallium_drivers := swrast freedreno i915g nouveau r300g r600g radeonsi 
>> vmwgfx vc4 virgl
>> +gallium_drivers := swrast freedreno i915g nouveau pl111 r300g r600g 
>> radeonsi vmwgfx vc4 virgl
>>
> The recent Android cleanups by RobH which will cause a clash. The gist
> is below, but feel free to skim through commit
> 3f097396a1642bb7033002d0bdd37e194afce06a.
>  - rework for the new gallium_drivers format
>  - add a couple of lines in src/gallium/drivers/pl111/Android.mk
> analogous to the vc4 - the "ifneq $HAVE_foo" hunk
>  - drop the guard in src/gallium/Android.mk
>
>
>> +++ b/src/gallium/winsys/pl111/drm/pl111_drm_winsys.c
>
>> -#include 
>>  #include 
>> +#include 
>>
>> -#include "vc4_drm_public.h"
>> +#include "pl111_drm_public.h"
>> +#include "vc4/drm/vc4_drm_public.h"
>> +#include "xf86drm.h"
>>
>> -#include "vc4/vc4_screen.h"
>> +#include "pipe/p_screen.h"
>> +#include "renderonly/renderonly.h"
>
>> +#include "util/u_format.h"
> Seems unused.
>
>>
>> -struct pipe_screen *
>> -vc4_drm_screen_create(int fd)
>> +struct pipe_screen *pl111_drm_screen_create(int fd)
>>  {
>> -   return vc4_screen_create(fcntl(fd, F_DUPFD_CLOEXEC, 3));
>> +   struct renderonly ro = {
>> +  /* Passes the vc4-allocated BO through to the pl111 DRM device using
>> +   * PRIME buffer sharing.  The VC4 BO must be linear, which the SCANOUT
>> +   * flag on allocation will have ensured.
>> +   */
>> +  .create_for_resource = renderonly_create_gpu_import_for_resource,
>> +  .kms_fd = fd,
>> +  .gpu_fd = drmOpenWithType("vc4", NULL, DRM_NODE_RENDER),
> Please don't use the drmOpen* API. It's a legacy dragon with very
> subtle and inner workings.
> Using drmGetDevice[s] should provide any information that you need.
> Alternatively please let us know what's missing so we can address it.

One this platform, there are exactly two devices, one is vc4 and the
other is pl111.  drmOpenWithType is exactly the API we want, and if you
want something else, then you should probably replace its insides
instead of telling people to use a different API.


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

Re: [Mesa-dev] [PATCH 11/11] intel/aubinator_error_decode: Disassemble shader programs

[Matt Turner]

On Wed, May 17, 2017 at 9:29 AM, Anuj Phogat  wrote:
> On Mon, May 1, 2017 at 1:54 PM, Matt Turner  wrote:
>> ---
>>  src/intel/Makefile.tools.am  |   6 +-
>>  src/intel/tools/aubinator_error_decode.c | 178 
>> ++-
>>  2 files changed, 180 insertions(+), 4 deletions(-)
>>
>> diff --git a/src/intel/Makefile.tools.am b/src/intel/Makefile.tools.am
>> index 576beea..1175118 100644
>> --- a/src/intel/Makefile.tools.am
>> +++ b/src/intel/Makefile.tools.am
>> @@ -47,11 +47,15 @@ tools_aubinator_LDADD = \
>>
>>
>>  tools_aubinator_error_decode_SOURCES = \
>> -   tools/aubinator_error_decode.c
>> +   tools/aubinator_error_decode.c \
>> +   tools/disasm.c \
>> +   tools/gen_disasm.h
>>
>>  tools_aubinator_error_decode_LDADD = \
>> common/libintel_common.la \
>> +   compiler/libintel_compiler.la \
>> $(top_builddir)/src/util/libmesautil.la \
>> +   $(PTHREAD_LIBS) \
>> $(EXPAT_LIBS) \
>> $(ZLIB_LIBS)
>>
>> diff --git a/src/intel/tools/aubinator_error_decode.c 
>> b/src/intel/tools/aubinator_error_decode.c
>> index 244bef8..ef77c01 100644
>> --- a/src/intel/tools/aubinator_error_decode.c
>> +++ b/src/intel/tools/aubinator_error_decode.c
>> @@ -40,6 +40,7 @@
>>
>>  #include "common/gen_decoder.h"
>>  #include "util/macros.h"
>> +#include "gen_disasm.h"
>>
>>  #define CSI "\e["
>>  #define BLUE_HEADER  CSI "0;44m"
>> @@ -209,6 +210,17 @@ print_fault_data(struct gen_device_info *devinfo, 
>> uint32_t data1, uint32_t data0
>>  #define CSI "\e["
>>  #define NORMAL   CSI "0m"
>>
>> +struct program {
>> +   const char *type;
>> +   const char *command;
>> +   uint64_t command_offset;
>> +   uint64_t instruction_base_address;
>> +   uint64_t ksp;
>> +};
>> +
>> +static struct program programs[4096];
>> +static int num_programs = 0;
>> +
>>  static void decode(struct gen_spec *spec,
>> const char *buffer_name,
>> const char *ring_name,
>> @@ -219,6 +231,7 @@ static void decode(struct gen_spec *spec,
>> uint32_t *p, *end = (data + *count);
>> int length;
>> struct gen_group *inst;
>> +   uint64_t current_instruction_base_address = 0;
>>
>> for (p = data; p < end; p += length) {
>>const char *color = option_full_decode ? BLUE_HEADER : NORMAL,
>> @@ -246,6 +259,127 @@ static void decode(struct gen_spec *spec,
>>
>>if (strcmp(inst->name, "MI_BATCH_BUFFER_END") == 0)
>>   break;
>> +
>> +  if (strcmp(inst->name, "STATE_BASE_ADDRESS") == 0) {
>> + struct gen_field_iterator iter;
>> + gen_field_iterator_init(, inst, p, false);
>> +
>> + while (gen_field_iterator_next()) {
>> +if (strcmp(iter.name, "Instruction Base Address") == 0) {
>> +   current_instruction_base_address = strtol(iter.value, NULL, 
>> 16);
>> +}
>> + }
>> +  } else if (strcmp(inst->name,   "WM_STATE") == 0 ||
>> + strcmp(inst->name, "3DSTATE_PS") == 0 ||
>> + strcmp(inst->name, "3DSTATE_WM") == 0) {
>> + struct gen_field_iterator iter;
>> + gen_field_iterator_init(, inst, p, false);
>> + uint64_t ksp[3] = {0, 0, 0};
>> + bool enabled[3] = {false, false, false};
>> +
>> + while (gen_field_iterator_next()) {
>> +if (strncmp(iter.name, "Kernel Start Pointer ",
>> +strlen("Kernel Start Pointer ")) == 0) {
>> +   int idx = iter.name[strlen("Kernel Start Pointer ")] - '0';
>> +   ksp[idx] = strtol(iter.value, NULL, 16);
>> +} else if (strcmp(iter.name, "8 Pixel Dispatch Enable") == 0) {
>> +   enabled[0] = strcmp(iter.value, "true") == 0;
>> +} else if (strcmp(iter.name, "16 Pixel Dispatch Enable") == 0) {
>> +   enabled[1] = strcmp(iter.value, "true") == 0;
>> +} else if (strcmp(iter.name, "32 Pixel Dispatch Enable") == 0) {
>> +   enabled[2] = strcmp(iter.value, "true") == 0;
>> +}
>> + }
>> +
>> + /* FINISHME: Broken for multi-program WM_STATE,
>> +  * which Mesa does not use
>> +  */
>> + if (enabled[0] + enabled[1] + enabled[2] == 1) {
>> +const char *type = enabled[0] ? "SIMD8 fragment shader" :
>> +   enabled[1] ? "SIMD16 fragment shader" :
>> +   enabled[2] ? "SIMD32 fragment shader" : NULL;
>> +
>> +programs[num_programs++] = (struct program) {
>> +   .type = type,
>> +   .command = inst->name,
>> +   .command_offset = offset,
>> +   .instruction_base_address = current_instruction_base_address,
>> +   .ksp = ksp[0],
>> +};
>> + } else {
>> +if (enabled[0]) /* SIMD8 */ {
>> +   programs[num_programs++] = (struct program) {
>> +

Re: [Mesa-dev] [RFC] Deprecating old DRI loaders/drivers

[Jason Ekstrand]

On Wed, May 17, 2017 at 10:36 AM, Ilia Mirkin  wrote:

> On Wed, May 17, 2017 at 1:26 PM, Ian Romanick  wrote:
> > On 05/16/2017 09:04 PM, Jason Ekstrand wrote:
> >> On May 16, 2017 18:30:00 Timothy Arceri  wrote:
> >>
> >>> On 17/05/17 02:38, Ian Romanick wrote:
>  What *actual* problem are you trying to solve?  Honestly, it seems
> like
>  you're just trying to find stuff to do.  We have a mechanism to make
>  this work, and it's not that hard.  Introducing a deprecation period
> and
>  everything that involves will make it more work, not less.
> >>
> >> I think that's a fair question
> >>
> >>> To be fair aren't we in a stage in Mesa's life-cycle where the focus is
> >>> on tidying-up / optimisations. It's not like there are large spec
> >>> updates in the pipeline.
> >>
> >> If we are genuinely making things more maintainable, then maybe
> >> deprecation is reasonable.  However, of it's just churn, then it may
> >> just be a source of new bugs to fix.  I think asking "why?" is perfectly
> >> reasonable.
> >>
> >> On the other side, perhaps we should consider instead taking advantage
> >> of the backwards comparability and dropping some of the old and
> >> unmaintained drivers from the tree, put them on a critical-bugfix-only
> >> branch, and recommend that distros build two mesas and only install the
> >> loader from the newer one.  Dropping i915, r200, and other effectively
> >> unmaintained drivers from the tree would make it much easier to do core
> >> state tracker cleanups since there would effectively only be two state
> >> trackers: gallium and i915. For example, there's a lot of code floating
> >> around for dealing with hardware that doesn't have native integers.
> >
> > r300 and r400 in Gallium do not have native integers.  I don't know
> > about NV30.
>
> NV30 does not have native integers. Neither does a2xx. Not sure about
> etnaviv.
>
> > I wanted to remove support for NV04 and NV05 last year because they are
> > unused, unmaintained, and demonstrably *broken*, and I could not even
> > get consensus on that.
>
> For the record, they work and are maintained (although imperfect, with
> some known breakage). Maintained, to me, means "if someone comes with
> an issue, there will be an attempt to address it". But they're rarely
> tested, and questionably used by anyone other than the tester (me),
> and only on NV5, as I don't have a NV4.
>

I didn't say they couldn't be maintained on the "ancient" branch but it
would mean bugfix-only which it sounds like is already the current status.


> Separately, I'd definitely consider a discussion about cleaving off
> the post-modern-times drivers (DX10+ hardware) from the
> pre-modern-times hardware (DX9 and older), and moving those off into a
> mesa-pre-dx9 repository. I doubt there are too many bugs/features for
> those that would greatly benefit from a shared repository. And mesa
> could shed a ton of support code in the process. On both sides.
>
>   -ilia
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC] Deprecating old DRI loaders/drivers

[Ilia Mirkin]

On Wed, May 17, 2017 at 1:26 PM, Ian Romanick  wrote:
> On 05/16/2017 09:04 PM, Jason Ekstrand wrote:
>> On May 16, 2017 18:30:00 Timothy Arceri  wrote:
>>
>>> On 17/05/17 02:38, Ian Romanick wrote:
 What *actual* problem are you trying to solve?  Honestly, it seems like
 you're just trying to find stuff to do.  We have a mechanism to make
 this work, and it's not that hard.  Introducing a deprecation period and
 everything that involves will make it more work, not less.
>>
>> I think that's a fair question
>>
>>> To be fair aren't we in a stage in Mesa's life-cycle where the focus is
>>> on tidying-up / optimisations. It's not like there are large spec
>>> updates in the pipeline.
>>
>> If we are genuinely making things more maintainable, then maybe
>> deprecation is reasonable.  However, of it's just churn, then it may
>> just be a source of new bugs to fix.  I think asking "why?" is perfectly
>> reasonable.
>>
>> On the other side, perhaps we should consider instead taking advantage
>> of the backwards comparability and dropping some of the old and
>> unmaintained drivers from the tree, put them on a critical-bugfix-only
>> branch, and recommend that distros build two mesas and only install the
>> loader from the newer one.  Dropping i915, r200, and other effectively
>> unmaintained drivers from the tree would make it much easier to do core
>> state tracker cleanups since there would effectively only be two state
>> trackers: gallium and i915. For example, there's a lot of code floating
>> around for dealing with hardware that doesn't have native integers.
>
> r300 and r400 in Gallium do not have native integers.  I don't know
> about NV30.

NV30 does not have native integers. Neither does a2xx. Not sure about etnaviv.

> I wanted to remove support for NV04 and NV05 last year because they are
> unused, unmaintained, and demonstrably *broken*, and I could not even
> get consensus on that.

For the record, they work and are maintained (although imperfect, with
some known breakage). Maintained, to me, means "if someone comes with
an issue, there will be an attempt to address it". But they're rarely
tested, and questionably used by anyone other than the tester (me),
and only on NV5, as I don't have a NV4.

Separately, I'd definitely consider a discussion about cleaving off
the post-modern-times drivers (DX10+ hardware) from the
pre-modern-times hardware (DX9 and older), and moving those off into a
mesa-pre-dx9 repository. I doubt there are too many bugs/features for
those that would greatly benefit from a shared repository. And mesa
could shed a ton of support code in the process. On both sides.

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

Re: [Mesa-dev] [RFC] Deprecating old DRI loaders/drivers

[Ian Romanick]

On 05/16/2017 09:04 PM, Jason Ekstrand wrote:
> On May 16, 2017 18:30:00 Timothy Arceri  wrote:
> 
>> On 17/05/17 02:38, Ian Romanick wrote:
>>> What *actual* problem are you trying to solve?  Honestly, it seems like
>>> you're just trying to find stuff to do.  We have a mechanism to make
>>> this work, and it's not that hard.  Introducing a deprecation period and
>>> everything that involves will make it more work, not less.
> 
> I think that's a fair question
> 
>> To be fair aren't we in a stage in Mesa's life-cycle where the focus is
>> on tidying-up / optimisations. It's not like there are large spec
>> updates in the pipeline.
> 
> If we are genuinely making things more maintainable, then maybe
> deprecation is reasonable.  However, of it's just churn, then it may
> just be a source of new bugs to fix.  I think asking "why?" is perfectly
> reasonable.
> 
> On the other side, perhaps we should consider instead taking advantage
> of the backwards comparability and dropping some of the old and
> unmaintained drivers from the tree, put them on a critical-bugfix-only
> branch, and recommend that distros build two mesas and only install the
> loader from the newer one.  Dropping i915, r200, and other effectively
> unmaintained drivers from the tree would make it much easier to do core
> state tracker cleanups since there would effectively only be two state
> trackers: gallium and i915. For example, there's a lot of code floating
> around for dealing with hardware that doesn't have native integers.

r300 and r400 in Gallium do not have native integers.  I don't know
about NV30.

I wanted to remove support for NV04 and NV05 last year because they are
unused, unmaintained, and demonstrably *broken*, and I could not even
get consensus on that.

> --Jason

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

Re: [Mesa-dev] [PATCH 1/3] tgsi: remove some unused OPCODE macros

[Roland Scheidegger]

It looks like we don't use them internally neither, so
Reviewed-by: Roland Scheidegger 

Am 17.05.2017 um 11:17 schrieb Samuel Pitoiset:
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/gallium/auxiliary/tgsi/tgsi_opcode_tmp.h |  42 ---
>  src/gallium/auxiliary/tgsi/tgsi_ureg.h   | 158 
> ---
>  2 files changed, 200 deletions(-)
> 
> diff --git a/src/gallium/auxiliary/tgsi/tgsi_opcode_tmp.h 
> b/src/gallium/auxiliary/tgsi/tgsi_opcode_tmp.h
> index ab73fabaca..96ac4803a7 100644
> --- a/src/gallium/auxiliary/tgsi/tgsi_opcode_tmp.h
> +++ b/src/gallium/auxiliary/tgsi/tgsi_opcode_tmp.h
> @@ -28,26 +28,6 @@
>  #define OP12_TEX(a) OP12(a)
>  #endif
>  
> -#ifndef OP14_TEX
> -#define OP14_TEX(a) OP14(a)
> -#endif
> -
> -#ifndef OP12_SAMPLE
> -#define OP12_SAMPLE(a) OP12(a)
> -#endif
> -
> -#ifndef OP13_SAMPLE
> -#define OP13_SAMPLE(a) OP13(a)
> -#endif
> -
> -#ifndef OP14_SAMPLE
> -#define OP14_SAMPLE(a) OP14(a)
> -#endif
> -
> -#ifndef OP15_SAMPLE
> -#define OP15_SAMPLE(a) OP15(a)
> -#endif
> -
>  #ifndef OP00_LBL
>  #define OP00_LBL(a) OP00(a)
>  #endif
> @@ -178,15 +158,6 @@ OP01(CASE)
>  OP00(DEFAULT)
>  OP00(ENDSWITCH)
>  
> -OP13_SAMPLE(SAMPLE)
> -OP12_SAMPLE(SAMPLE_I)
> -OP13_SAMPLE(SAMPLE_I_MS)
> -OP14_SAMPLE(SAMPLE_B)
> -OP14_SAMPLE(SAMPLE_C)
> -OP14_SAMPLE(SAMPLE_C_LZ)
> -OP15_SAMPLE(SAMPLE_D)
> -OP14_SAMPLE(SAMPLE_L)
> -OP13_SAMPLE(GATHER4)
>  OP12(SVIEWINFO)
>  OP13(SAMPLE_POS)
>  OP12(SAMPLE_INFO)
> @@ -206,21 +177,8 @@ OP12(UMUL_HI)
>  #undef OP12
>  #undef OP13
>  
> -#ifdef OP14
> -#undef OP14
> -#endif
> -
> -#ifdef OP15
> -#undef OP15
> -#endif
> -
>  #undef OP00_LBL
>  #undef OP01_LBL
>  
>  #undef OP12_TEX
>  #undef OP14_TEX
> -
> -#undef OP12_SAMPLE
> -#undef OP13_SAMPLE
> -#undef OP14_SAMPLE
> -#undef OP15_SAMPLE
> diff --git a/src/gallium/auxiliary/tgsi/tgsi_ureg.h 
> b/src/gallium/auxiliary/tgsi/tgsi_ureg.h
> index d301915948..6d2f5c0e99 100644
> --- a/src/gallium/auxiliary/tgsi/tgsi_ureg.h
> +++ b/src/gallium/auxiliary/tgsi/tgsi_ureg.h
> @@ -763,29 +763,6 @@ static inline void ureg_##op( struct ureg_program *ureg, 
>\
> ureg_fixup_insn_size( ureg, insn.insn_token );   \
>  }
>  
> -#define OP12_SAMPLE( op )   \
> -static inline void ureg_##op( struct ureg_program *ureg,\
> -  struct ureg_dst dst,  \
> -  struct ureg_src src0, \
> -  struct ureg_src src1 )\
> -{   \
> -   unsigned opcode = TGSI_OPCODE_##op;  \
> -   unsigned target = TGSI_TEXTURE_UNKNOWN;  \
> -   struct ureg_emit_insn_result insn;   \
> -   if (ureg_dst_is_empty(dst))  \
> -  return;   \
> -   insn = ureg_emit_insn(ureg,  \
> - opcode,\
> - dst.Saturate,  \
> - 1, \
> - 2);\
> -   ureg_emit_texture( ureg, insn.extended_token, target, 0 );   \
> -   ureg_emit_dst( ureg, dst );  \
> -   ureg_emit_src( ureg, src0 ); \
> -   ureg_emit_src( ureg, src1 ); \
> -   ureg_fixup_insn_size( ureg, insn.insn_token );   \
> -}
> -
>  #define OP13( op )  \
>  static inline void ureg_##op( struct ureg_program *ureg,\
>struct ureg_dst dst,  \
> @@ -809,31 +786,6 @@ static inline void ureg_##op( struct ureg_program *ureg, 
>\
> ureg_fixup_insn_size( ureg, insn.insn_token );   \
>  }
>  
> -#define OP13_SAMPLE( op )   \
> -static inline void ureg_##op( struct ureg_program *ureg,\
> -  struct ureg_dst dst,  \
> -  struct ureg_src src0, \
> -  struct ureg_src src1, \
> -  struct ureg_src src2 )\
> -{   \
> -   unsigned opcode = TGSI_OPCODE_##op;  \
> -   unsigned target = TGSI_TEXTURE_UNKNOWN;  \
> -   struct 

Re: [Mesa-dev] Bug in 17.1.0-rc4 source packaging for swr?

[Emil Velikov]

On 10 May 2017 at 03:51, Chuck Atkins  wrote:
> I just tried to build 17.0.4-rc4 from the tarball with swr enabled and got
> errors about my python not having mako:
>
> make[5]: Entering directory
> '/tmp/atkins3/mesa/build/mesa-17.1.0-rc4_gcc-6.3.0_haswell/src/gallium/drivers/swr'
>   GEN  rasterizer/jitter/gen_builder.hpp
> Traceback (most recent call last):
>   File
> "../../../../../../mesa-17.1.0-rc4/src/gallium/drivers/swr/rasterizer/codegen/gen_llvm_ir_macros.py",
> line 24, in 
> from gen_common import MakoTemplateWriter, ArgumentParser
>   File
> "/tmp/atkins3/mesa/mesa-17.1.0-rc4/src/gallium/drivers/swr/rasterizer/codegen/gen_common.py",
> line 27, in 
> from mako.template import Template
> ImportError: No module named mako.template
> Makefile:2424: recipe for target 'rasterizer/jitter/gen_builder.hpp' failed
>
> As I understood it, mako should only be required when building out of git.
> Unless this has changed, it seems there are some generated files missing
> from the source tarball.
>
You're spot on here Chuck. Tarball should build without any tools such
as python/lex/etc.

At the moment the rasterizer/jitter/gen_builder.hpp file isn't shipped
in the tarball, hence the problem.
The file is omitted intentionally, as mentioned in the Makefile [1].
Would be great if we can fix that, so any suggestions would be
appreciated.

Tim, I believe we briefly had a chat about this a while back. Do you
have any ideas how to generate the file that works across all
supported LLVM versions?

Thanks
Emil

[1] 
https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/swr/Makefile.am#n195
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v2 2/3] tgsi: store the sampler view type directly in the instruction

[Samuel Pitoiset]

RadeonSI needs to do a special lowering for Gather4 with integer
formats, but with bindless samplers we just can't access the index.

Instead, store the return type in the instruction like the target.

v2: - fix padding
- initialize default value of ReturnType
- replace debug_assert() by assert()

Signed-off-by: Samuel Pitoiset 
---
 src/gallium/auxiliary/tgsi/tgsi_build.c|  6 +-
 src/gallium/auxiliary/tgsi/tgsi_ureg.c |  7 +--
 src/gallium/auxiliary/tgsi/tgsi_ureg.h | 11 ---
 src/gallium/include/pipe/p_shader_tokens.h |  4 +++-
 src/mesa/state_tracker/st_atifs_to_tgsi.c  |  2 +-
 src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 17 ++---
 src/mesa/state_tracker/st_mesa_to_tgsi.c   | 21 +
 src/mesa/state_tracker/st_mesa_to_tgsi.h   |  4 
 8 files changed, 49 insertions(+), 23 deletions(-)

diff --git a/src/gallium/auxiliary/tgsi/tgsi_build.c 
b/src/gallium/auxiliary/tgsi/tgsi_build.c
index 39c20b5e88..00843241f8 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_build.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_build.c
@@ -720,6 +720,7 @@ tgsi_default_instruction_texture( void )
 
instruction_texture.Texture = TGSI_TEXTURE_UNKNOWN;
instruction_texture.NumOffsets = 0;
+   instruction_texture.ReturnType = TGSI_RETURN_TYPE_UNKNOWN;
instruction_texture.Padding = 0;
 
return instruction_texture;
@@ -729,6 +730,7 @@ static struct tgsi_instruction_texture
 tgsi_build_instruction_texture(
unsigned texture,
unsigned num_offsets,
+   unsigned return_type,
struct tgsi_token *prev_token,
struct tgsi_instruction *instruction,
struct tgsi_header *header )
@@ -737,6 +739,7 @@ tgsi_build_instruction_texture(
 
instruction_texture.Texture = texture;
instruction_texture.NumOffsets = num_offsets;
+   instruction_texture.ReturnType = return_type;
instruction_texture.Padding = 0;
instruction->Texture = 1;
 
@@ -1090,7 +1093,8 @@ tgsi_build_full_instruction(
 
   *instruction_texture = tgsi_build_instruction_texture(
  full_inst->Texture.Texture,
-full_inst->Texture.NumOffsets,
+ full_inst->Texture.NumOffsets,
+ full_inst->Texture.ReturnType,
  prev_token,
  instruction,
  header   );
diff --git a/src/gallium/auxiliary/tgsi/tgsi_ureg.c 
b/src/gallium/auxiliary/tgsi/tgsi_ureg.c
index 9eb00d0919..5bd779728a 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_ureg.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_ureg.c
@@ -1289,7 +1289,7 @@ ureg_fixup_label(struct ureg_program *ureg,
 void
 ureg_emit_texture(struct ureg_program *ureg,
   unsigned extended_token,
-  unsigned target, unsigned num_offsets)
+  unsigned target, unsigned return_type, unsigned num_offsets)
 {
union tgsi_any_token *out, *insn;
 
@@ -1301,6 +1301,7 @@ ureg_emit_texture(struct ureg_program *ureg,
out[0].value = 0;
out[0].insn_texture.Texture = target;
out[0].insn_texture.NumOffsets = num_offsets;
+   out[0].insn_texture.ReturnType = return_type;
 }
 
 void
@@ -1386,6 +1387,7 @@ ureg_tex_insn(struct ureg_program *ureg,
   const struct ureg_dst *dst,
   unsigned nr_dst,
   unsigned target,
+  unsigned return_type,
   const struct tgsi_texture_offset *texoffsets,
   unsigned nr_offset,
   const struct ureg_src *src,
@@ -1407,7 +1409,8 @@ ureg_tex_insn(struct ureg_program *ureg,
  nr_dst,
  nr_src);
 
-   ureg_emit_texture( ureg, insn.extended_token, target, nr_offset );
+   ureg_emit_texture( ureg, insn.extended_token, target, return_type,
+  nr_offset );
 
for (i = 0; i < nr_offset; i++)
   ureg_emit_texture_offset( ureg, [i]);
diff --git a/src/gallium/auxiliary/tgsi/tgsi_ureg.h 
b/src/gallium/auxiliary/tgsi/tgsi_ureg.h
index 6d2f5c0e99..54f95ba565 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_ureg.h
+++ b/src/gallium/auxiliary/tgsi/tgsi_ureg.h
@@ -555,6 +555,7 @@ ureg_tex_insn(struct ureg_program *ureg,
   const struct ureg_dst *dst,
   unsigned nr_dst,
   unsigned target,
+  unsigned return_type,
   const struct tgsi_texture_offset *texoffsets,
   unsigned nr_offset,
   const struct ureg_src *src,
@@ -596,7 +597,7 @@ ureg_emit_label(struct ureg_program *ureg,
 void
 ureg_emit_texture(struct ureg_program *ureg,
   unsigned insn_token,
-  unsigned target, unsigned num_offsets);
+  unsigned target, unsigned return_type, unsigned num_offsets);
 
 void
 ureg_emit_texture_offset(struct ureg_program *ureg,
@@ -748,6 +749,7 @@ static inline void ureg_##op( struct ureg_program *ureg,
\
   struct ureg_src src1 )\
 { 

Re: [Mesa-dev] [PATCH 2/3] tgsi: store the sampler view type directly in the instruction

[Samuel Pitoiset]

On 05/17/2017 06:02 PM, Roland Scheidegger wrote:

Am 17.05.2017 um 11:17 schrieb Samuel Pitoiset:

RadeonSI needs to do a special lowering for Gather4 with integer
formats, but with bindless samplers we just can't access the index.

Instead, store the return type in the instruction like the target.

Signed-off-by: Samuel Pitoiset 
---
  src/gallium/auxiliary/tgsi/tgsi_ureg.c |  7 +--
  src/gallium/auxiliary/tgsi/tgsi_ureg.h | 11 ---
  src/gallium/include/pipe/p_shader_tokens.h |  2 ++
  src/mesa/state_tracker/st_atifs_to_tgsi.c  |  2 +-
  src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 17 ++---
  src/mesa/state_tracker/st_mesa_to_tgsi.c   | 21 +
  src/mesa/state_tracker/st_mesa_to_tgsi.h   |  4 
  7 files changed, 43 insertions(+), 21 deletions(-)

diff --git a/src/gallium/auxiliary/tgsi/tgsi_ureg.c 
b/src/gallium/auxiliary/tgsi/tgsi_ureg.c
index 9eb00d0919..1cdb95cc95 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_ureg.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_ureg.c
@@ -1289,7 +1289,7 @@ ureg_fixup_label(struct ureg_program *ureg,
  void
  ureg_emit_texture(struct ureg_program *ureg,
unsigned extended_token,
-  unsigned target, unsigned num_offsets)
+  unsigned target, unsigned return_type, unsigned num_offsets)
  {
 union tgsi_any_token *out, *insn;
  
@@ -1300,6 +1300,7 @@ ureg_emit_texture(struct ureg_program *ureg,
  
 out[0].value = 0;

 out[0].insn_texture.Texture = target;
+   out[0].insn_texture.ReturnType = return_type;
 out[0].insn_texture.NumOffsets = num_offsets;
  }
  
@@ -1386,6 +1387,7 @@ ureg_tex_insn(struct ureg_program *ureg,

const struct ureg_dst *dst,
unsigned nr_dst,
unsigned target,
+  unsigned return_type,
const struct tgsi_texture_offset *texoffsets,
unsigned nr_offset,
const struct ureg_src *src,
@@ -1407,7 +1409,8 @@ ureg_tex_insn(struct ureg_program *ureg,
   nr_dst,
   nr_src);
  
-   ureg_emit_texture( ureg, insn.extended_token, target, nr_offset );

+   ureg_emit_texture( ureg, insn.extended_token, target, return_type,
+  nr_offset );
  
 for (i = 0; i < nr_offset; i++)

ureg_emit_texture_offset( ureg, [i]);
diff --git a/src/gallium/auxiliary/tgsi/tgsi_ureg.h 
b/src/gallium/auxiliary/tgsi/tgsi_ureg.h
index 6d2f5c0e99..54f95ba565 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_ureg.h
+++ b/src/gallium/auxiliary/tgsi/tgsi_ureg.h
@@ -555,6 +555,7 @@ ureg_tex_insn(struct ureg_program *ureg,
const struct ureg_dst *dst,
unsigned nr_dst,
unsigned target,
+  unsigned return_type,
const struct tgsi_texture_offset *texoffsets,
unsigned nr_offset,
const struct ureg_src *src,
@@ -596,7 +597,7 @@ ureg_emit_label(struct ureg_program *ureg,
  void
  ureg_emit_texture(struct ureg_program *ureg,
unsigned insn_token,
-  unsigned target, unsigned num_offsets);
+  unsigned target, unsigned return_type, unsigned num_offsets);
  
  void

  ureg_emit_texture_offset(struct ureg_program *ureg,
@@ -748,6 +749,7 @@ static inline void ureg_##op( struct ureg_program *ureg,
\
struct ureg_src src1 )\
  {   \
 unsigned opcode = TGSI_OPCODE_##op;  \
+   unsigned return_type = TGSI_RETURN_TYPE_UNKNOWN; \
 struct ureg_emit_insn_result insn;   \
 if (ureg_dst_is_empty(dst))  \
return;   \
@@ -756,7 +758,8 @@ static inline void ureg_##op( struct ureg_program *ureg,
\
   dst.Saturate,  \
   1, \
   2);\
-   ureg_emit_texture( ureg, insn.extended_token, target, 0 );  \
+   ureg_emit_texture( ureg, insn.extended_token, target,\
+  return_type, 0 ); \
 ureg_emit_dst( ureg, dst );  \
 ureg_emit_src( ureg, src0 ); \
 ureg_emit_src( ureg, src1 ); \
@@ -796,6 +799,7 @@ static inline void ureg_##op( struct ureg_program *ureg,
\
struct ureg_src src3 )\
  {   \
 

Re: [Mesa-dev] [PATCH 2/3] tgsi: store the sampler view type directly in the instruction

[Samuel Pitoiset]

On 05/17/2017 02:21 PM, Samuel Pitoiset wrote:



On 05/17/2017 02:02 PM, Nicolai Hähnle wrote:

On 17.05.2017 11:17, Samuel Pitoiset wrote:

RadeonSI needs to do a special lowering for Gather4 with integer
formats, but with bindless samplers we just can't access the index.

Instead, store the return type in the instruction like the target.

Signed-off-by: Samuel Pitoiset 
---
 src/gallium/auxiliary/tgsi/tgsi_ureg.c |  7 +--
 src/gallium/auxiliary/tgsi/tgsi_ureg.h | 11 ---
 src/gallium/include/pipe/p_shader_tokens.h |  2 ++
 src/mesa/state_tracker/st_atifs_to_tgsi.c  |  2 +-
 src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 17 ++---
 src/mesa/state_tracker/st_mesa_to_tgsi.c   | 21 +
 src/mesa/state_tracker/st_mesa_to_tgsi.h   |  4 
 7 files changed, 43 insertions(+), 21 deletions(-)

diff --git a/src/gallium/auxiliary/tgsi/tgsi_ureg.c 
b/src/gallium/auxiliary/tgsi/tgsi_ureg.c

index 9eb00d0919..1cdb95cc95 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_ureg.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_ureg.c
@@ -1289,7 +1289,7 @@ ureg_fixup_label(struct ureg_program *ureg,
 void
 ureg_emit_texture(struct ureg_program *ureg,
   unsigned extended_token,
-  unsigned target, unsigned num_offsets)
+  unsigned target, unsigned return_type, unsigned 
num_offsets)

 {
union tgsi_any_token *out, *insn;

@@ -1300,6 +1300,7 @@ ureg_emit_texture(struct ureg_program *ureg,

out[0].value = 0;
out[0].insn_texture.Texture = target;
+   out[0].insn_texture.ReturnType = return_type;
out[0].insn_texture.NumOffsets = num_offsets;
 }

@@ -1386,6 +1387,7 @@ ureg_tex_insn(struct ureg_program *ureg,
   const struct ureg_dst *dst,
   unsigned nr_dst,
   unsigned target,
+  unsigned return_type,
   const struct tgsi_texture_offset *texoffsets,
   unsigned nr_offset,
   const struct ureg_src *src,
@@ -1407,7 +1409,8 @@ ureg_tex_insn(struct ureg_program *ureg,
  nr_dst,
  nr_src);

-   ureg_emit_texture( ureg, insn.extended_token, target, nr_offset );
+   ureg_emit_texture( ureg, insn.extended_token, target, return_type,
+  nr_offset );

for (i = 0; i < nr_offset; i++)
   ureg_emit_texture_offset( ureg, [i]);
diff --git a/src/gallium/auxiliary/tgsi/tgsi_ureg.h 
b/src/gallium/auxiliary/tgsi/tgsi_ureg.h

index 6d2f5c0e99..54f95ba565 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_ureg.h
+++ b/src/gallium/auxiliary/tgsi/tgsi_ureg.h
@@ -555,6 +555,7 @@ ureg_tex_insn(struct ureg_program *ureg,
   const struct ureg_dst *dst,
   unsigned nr_dst,
   unsigned target,
+  unsigned return_type,
   const struct tgsi_texture_offset *texoffsets,
   unsigned nr_offset,
   const struct ureg_src *src,
@@ -596,7 +597,7 @@ ureg_emit_label(struct ureg_program *ureg,
 void
 ureg_emit_texture(struct ureg_program *ureg,
   unsigned insn_token,
-  unsigned target, unsigned num_offsets);
+  unsigned target, unsigned return_type, unsigned 
num_offsets);


 void
 ureg_emit_texture_offset(struct ureg_program *ureg,
@@ -748,6 +749,7 @@ static inline void ureg_##op( struct ureg_program 
*ureg,\
   struct ureg_src src1 
)\

 { \
unsigned opcode = 
TGSI_OPCODE_##op;  \
+   unsigned return_type = 
TGSI_RETURN_TYPE_UNKNOWN; \
struct ureg_emit_insn_result 
insn;   \
if 
(ureg_dst_is_empty(dst))  \

return;   \
@@ -756,7 +758,8 @@ static inline void ureg_##op( struct ureg_program 
*ureg,\

dst.Saturate,  \
1, \
2);\
-   ureg_emit_texture( ureg, insn.extended_token, target, 0 );\
+   ureg_emit_texture( ureg, insn.extended_token, 
target,\
+  return_type, 0 
); \
ureg_emit_dst( ureg, dst 
);  \
ureg_emit_src( ureg, src0 
); \
ureg_emit_src( ureg, src1 
); \
@@ -796,6 +799,7 @@ static inline void ureg_##op( struct ureg_program 
*ureg,\
   struct ureg_src src3 
)\

 { \
unsigned opcode = 
TGSI_OPCODE_##op;  \
+   unsigned return_type = 
TGSI_RETURN_TYPE_UNKNOWN; \
struct ureg_emit_insn_result 
insn;   \
if 

Re: [Mesa-dev] [RFC v3] drm/i915: Select engines via class and instance in execbuffer2

[Chris Wilson]

On Wed, May 17, 2017 at 04:40:57PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin 
> 
> Building on top of the previous patch which exported the concept
> of engine classes and instances, we can also use this instead of
> the current awkward engine selection uAPI.
> 
> This is primarily interesting for the VCS engine selection which
> is a) currently done via disjoint set of flags, and b) the
> current I915_EXEC_BSD flags has different semantics depending on
> the underlying hardware which is bad.
> 
> Proposed idea here is to reserve 16-bits of flags, to pass in
> the engine class and instance (8 bits each), and a new flag
> named I915_EXEC_CLASS_INSTACE to tell the kernel this new engine
> selection API is in use.
> 
> The new uAPI also removes access to the weak VCS engine
> balancing as currently existing in the driver.
> 
> Example usage to send a command to VCS0:
> 
>   eb.flags = i915_execbuffer2_engine(DRM_I915_ENGINE_CLASS_VIDEO_DECODE, 0);
> 
> Or to send a command to VCS1:
> 
>   eb.flags = i915_execbuffer2_engine(DRM_I915_ENGINE_CLASS_VIDEO_DECODE, 1);
> 
> v2:
>  * Fix unknown flags mask.
>  * Use I915_EXEC_RING_MASK for class. (Chris Wilson)
> 
> v3:
>  * Add a map for fast class-instance engine lookup. (Chris Wilson)
> 
> Signed-off-by: Tvrtko Ursulin 
> Cc: Ben Widawsky 
> Cc: Chris Wilson 
> Cc: Daniel Vetter 
> Cc: Joonas Lahtinen 
> Cc: Jon Bloomfield 
> Cc: Daniel Charles 
> Cc: "Rogozhkin, Dmitry V" 
> Cc: Oscar Mateo 
> Cc: "Gong, Zhipeng" 
> Cc: intel-vaapi-me...@lists.01.org
> Cc: mesa-dev@lists.freedesktop.org
> ---
>  drivers/gpu/drm/i915/i915_drv.h|  1 +
>  drivers/gpu/drm/i915/i915_gem_execbuffer.c | 30 
> ++
>  drivers/gpu/drm/i915/i915_reg.h|  3 +++
>  drivers/gpu/drm/i915/intel_engine_cs.c |  7 +++
>  include/uapi/drm/i915_drm.h| 11 ++-
>  5 files changed, 51 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 5dfa4a12e647..7bf4fd42480c 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2066,6 +2066,7 @@ struct drm_i915_private {
>   struct pci_dev *bridge_dev;
>   struct i915_gem_context *kernel_context;
>   struct intel_engine_cs *engine[I915_NUM_ENGINES];
> + struct intel_engine_cs *engine_class[MAX_ENGINE_CLASS + 
> 1][MAX_ENGINE_INSTANCE + 1];
>   struct i915_vma *semaphore;
>  
>   struct drm_dma_handle *status_page_dmah;
> diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
> b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> index af1965774e7b..c1ad49ab64cd 100644
> --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> @@ -1492,6 +1492,33 @@ gen8_dispatch_bsd_engine(struct drm_i915_private 
> *dev_priv,
>   return file_priv->bsd_engine;
>  }
>  
> +extern u8 user_class_map[DRM_I915_ENGINE_CLASS_MAX];
> +
> +static struct intel_engine_cs *get_engine_class(struct drm_i915_private 
> *i915,
> + u8 class, u8 instance)
> +{
> + if (class > MAX_ENGINE_CLASS || instance > MAX_ENGINE_INSTANCE)
> + return NULL;
> +
> + return i915->engine_class[class][instance];
> +}

Be bold make this this an intel_engine_lookup(), I forsee some other
users appearing very shortly.

> +static struct intel_engine_cs *
> +eb_select_engine_class_instance(struct drm_i915_private *i915,
> + struct drm_i915_gem_execbuffer2 *args)
> +{
> + u8 class, instance;
> +
> + class = args->flags & I915_EXEC_RING_MASK;
> + if (class >= DRM_I915_ENGINE_CLASS_MAX)
> + return NULL;
> +
> + instance = (args->flags >> I915_EXEC_INSTANCE_SHIFT) &&
> +I915_EXEC_INSTANCE_MASK;
> +
> + return get_engine_class(i915, user_class_map[class], instance);
> +}
> +
>  #define I915_USER_RINGS (4)
>  
>  static const enum intel_engine_id user_ring_map[I915_USER_RINGS + 1] = {
> @@ -1510,6 +1537,9 @@ eb_select_engine(struct drm_i915_private *dev_priv,
>   unsigned int user_ring_id = args->flags & I915_EXEC_RING_MASK;
>   struct intel_engine_cs *engine;
>  
> + if (args->flags & I915_EXEC_CLASS_INSTANCE)
> + return eb_select_engine_class_instance(dev_priv, args);
> +
>   if (user_ring_id > I915_USER_RINGS) {
>   DRM_DEBUG("execbuf with unknown ring: %u\n", user_ring_id);
>   return NULL;
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index ee144ec57935..a3b59043b991 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ 

Re: [Mesa-dev] [PATCH 11/11] intel/aubinator_error_decode: Disassemble shader programs

[Anuj Phogat]

On Mon, May 1, 2017 at 1:54 PM, Matt Turner  wrote:
> ---
>  src/intel/Makefile.tools.am  |   6 +-
>  src/intel/tools/aubinator_error_decode.c | 178 
> ++-
>  2 files changed, 180 insertions(+), 4 deletions(-)
>
> diff --git a/src/intel/Makefile.tools.am b/src/intel/Makefile.tools.am
> index 576beea..1175118 100644
> --- a/src/intel/Makefile.tools.am
> +++ b/src/intel/Makefile.tools.am
> @@ -47,11 +47,15 @@ tools_aubinator_LDADD = \
>
>
>  tools_aubinator_error_decode_SOURCES = \
> -   tools/aubinator_error_decode.c
> +   tools/aubinator_error_decode.c \
> +   tools/disasm.c \
> +   tools/gen_disasm.h
>
>  tools_aubinator_error_decode_LDADD = \
> common/libintel_common.la \
> +   compiler/libintel_compiler.la \
> $(top_builddir)/src/util/libmesautil.la \
> +   $(PTHREAD_LIBS) \
> $(EXPAT_LIBS) \
> $(ZLIB_LIBS)
>
> diff --git a/src/intel/tools/aubinator_error_decode.c 
> b/src/intel/tools/aubinator_error_decode.c
> index 244bef8..ef77c01 100644
> --- a/src/intel/tools/aubinator_error_decode.c
> +++ b/src/intel/tools/aubinator_error_decode.c
> @@ -40,6 +40,7 @@
>
>  #include "common/gen_decoder.h"
>  #include "util/macros.h"
> +#include "gen_disasm.h"
>
>  #define CSI "\e["
>  #define BLUE_HEADER  CSI "0;44m"
> @@ -209,6 +210,17 @@ print_fault_data(struct gen_device_info *devinfo, 
> uint32_t data1, uint32_t data0
>  #define CSI "\e["
>  #define NORMAL   CSI "0m"
>
> +struct program {
> +   const char *type;
> +   const char *command;
> +   uint64_t command_offset;
> +   uint64_t instruction_base_address;
> +   uint64_t ksp;
> +};
> +
> +static struct program programs[4096];
> +static int num_programs = 0;
> +
>  static void decode(struct gen_spec *spec,
> const char *buffer_name,
> const char *ring_name,
> @@ -219,6 +231,7 @@ static void decode(struct gen_spec *spec,
> uint32_t *p, *end = (data + *count);
> int length;
> struct gen_group *inst;
> +   uint64_t current_instruction_base_address = 0;
>
> for (p = data; p < end; p += length) {
>const char *color = option_full_decode ? BLUE_HEADER : NORMAL,
> @@ -246,6 +259,127 @@ static void decode(struct gen_spec *spec,
>
>if (strcmp(inst->name, "MI_BATCH_BUFFER_END") == 0)
>   break;
> +
> +  if (strcmp(inst->name, "STATE_BASE_ADDRESS") == 0) {
> + struct gen_field_iterator iter;
> + gen_field_iterator_init(, inst, p, false);
> +
> + while (gen_field_iterator_next()) {
> +if (strcmp(iter.name, "Instruction Base Address") == 0) {
> +   current_instruction_base_address = strtol(iter.value, NULL, 
> 16);
> +}
> + }
> +  } else if (strcmp(inst->name,   "WM_STATE") == 0 ||
> + strcmp(inst->name, "3DSTATE_PS") == 0 ||
> + strcmp(inst->name, "3DSTATE_WM") == 0) {
> + struct gen_field_iterator iter;
> + gen_field_iterator_init(, inst, p, false);
> + uint64_t ksp[3] = {0, 0, 0};
> + bool enabled[3] = {false, false, false};
> +
> + while (gen_field_iterator_next()) {
> +if (strncmp(iter.name, "Kernel Start Pointer ",
> +strlen("Kernel Start Pointer ")) == 0) {
> +   int idx = iter.name[strlen("Kernel Start Pointer ")] - '0';
> +   ksp[idx] = strtol(iter.value, NULL, 16);
> +} else if (strcmp(iter.name, "8 Pixel Dispatch Enable") == 0) {
> +   enabled[0] = strcmp(iter.value, "true") == 0;
> +} else if (strcmp(iter.name, "16 Pixel Dispatch Enable") == 0) {
> +   enabled[1] = strcmp(iter.value, "true") == 0;
> +} else if (strcmp(iter.name, "32 Pixel Dispatch Enable") == 0) {
> +   enabled[2] = strcmp(iter.value, "true") == 0;
> +}
> + }
> +
> + /* FINISHME: Broken for multi-program WM_STATE,
> +  * which Mesa does not use
> +  */
> + if (enabled[0] + enabled[1] + enabled[2] == 1) {
> +const char *type = enabled[0] ? "SIMD8 fragment shader" :
> +   enabled[1] ? "SIMD16 fragment shader" :
> +   enabled[2] ? "SIMD32 fragment shader" : NULL;
> +
> +programs[num_programs++] = (struct program) {
> +   .type = type,
> +   .command = inst->name,
> +   .command_offset = offset,
> +   .instruction_base_address = current_instruction_base_address,
> +   .ksp = ksp[0],
> +};
> + } else {
> +if (enabled[0]) /* SIMD8 */ {
> +   programs[num_programs++] = (struct program) {
> +  .type = "SIMD8 fragment shader",
> +  .command = inst->name,
> +  .command_offset = offset,
> +  .instruction_base_address = 
> 

Re: [Mesa-dev] [PATCH 26/43] intel/blorp: Pull the pipeline bits of blorp_exec into a helper

[Jason Ekstrand]

On Wed, May 17, 2017 at 5:53 AM, Pohjolainen, Topi <
topi.pohjolai...@gmail.com> wrote:

> On Tue, May 16, 2017 at 03:45:20PM -0700, Jason Ekstrand wrote:
> > ---
> >  src/intel/blorp/blorp_genX_exec.h | 56 ++
> -
> >  1 file changed, 31 insertions(+), 25 deletions(-)
> >
> > diff --git a/src/intel/blorp/blorp_genX_exec.h
> b/src/intel/blorp/blorp_genX_exec.h
> > index 9e61f69..0bb4b9a 100644
> > --- a/src/intel/blorp/blorp_genX_exec.h
> > +++ b/src/intel/blorp/blorp_genX_exec.h
> > @@ -1316,33 +1316,14 @@ blorp_emit_viewport_state(struct blorp_batch
> *batch,
> >  #endif
> >  }
> >
> > -
> > -/**
> > - * \brief Execute a blit or render pass operation.
> > - *
> > - * To execute the operation, this function manually constructs and
> emits a
> > - * batch to draw a rectangle primitive. The batchbuffer is flushed
> before
> > - * constructing and after emitting the batch.
> > - *
> > - * This function alters no GL state.
> > - */
> >  static void
> > -blorp_exec(struct blorp_batch *batch, const struct blorp_params *params)
> > +blorp_emit_pipeline(struct blorp_batch *batch,
> > +const struct blorp_params *params)
> >  {
> > uint32_t blend_state_offset = 0;
> > -   uint32_t color_calc_state_offset = 0;
> > +   uint32_t color_calc_state_offset;
> > uint32_t depth_stencil_state_offset;
> >
> > -#if GEN_GEN >= 8
> > -   if (params->hiz_op != BLORP_HIZ_OP_NONE) {
> > -  blorp_emit_gen8_hiz_op(batch, params);
> > -  return;
> > -   }
> > -#endif
> > -
> > -   blorp_emit_vertex_buffers(batch, params);
> > -   blorp_emit_vertex_elements(batch, params);
> > -
> > emit_urb_config(batch, params);
> >
> > if (params->wm_prog_data) {
> > @@ -1351,7 +1332,7 @@ blorp_exec(struct blorp_batch *batch, const struct
> blorp_params *params)
> > color_calc_state_offset = blorp_emit_color_calc_state(batch,
> params);
> > depth_stencil_state_offset = blorp_emit_depth_stencil_state(batch,
> params);
> >
> > -#if GEN_GEN <= 6
> > +#if GEN_GEN == 6
> > /* 3DSTATE_CC_STATE_POINTERS
> >  *
> >  * The pointer offsets are relative to
> > @@ -1385,8 +1366,6 @@ blorp_exec(struct blorp_batch *batch, const struct
> blorp_params *params)
> > blorp_emit(batch, GENX(3DSTATE_CONSTANT_GS), gs);
> > blorp_emit(batch, GENX(3DSTATE_CONSTANT_PS), ps);
> >
> > -   blorp_emit_surface_states(batch, params);
> > -
> > if (params->src.enabled)
> >blorp_emit_sampler_state(batch, params);
> >
> > @@ -1423,6 +1402,33 @@ blorp_exec(struct blorp_batch *batch, const
> struct blorp_params *params)
> > blorp_emit_ps_config(batch, params);
> >
> > blorp_emit_viewport_state(batch, params);
> > +}
> > +
> > +/**
> > + * \brief Execute a blit or render pass operation.
> > + *
> > + * To execute the operation, this function manually constructs and
> emits a
> > + * batch to draw a rectangle primitive. The batchbuffer is flushed
> before
> > + * constructing and after emitting the batch.
> > + *
> > + * This function alters no GL state.
> > + */
> > +static void
> > +blorp_exec(struct blorp_batch *batch, const struct blorp_params *params)
> > +{
> > +#if GEN_GEN >= 8
> > +   if (params->hiz_op != BLORP_HIZ_OP_NONE) {
> > +  blorp_emit_gen8_hiz_op(batch, params);
> > +  return;
> > +   }
> > +#endif
> > +
> > +   blorp_emit_vertex_buffers(batch, params);
> > +   blorp_emit_vertex_elements(batch, params);
> > +
> > +   blorp_emit_pipeline(batch, params);
> > +
> > +   blorp_emit_surface_states(batch, params);
>
> I thought binding table had to be earlier but I can't actually see any
> reason
> why. Well, jenkins would scream if it had to be.


I think the requirement you're thinking of is that BINDING_TABLE_POINTERS
has to be emitted after 3DSTATE_CONSTANTS_*S on gen9.  I don't know of any
other binding table ordering requirements.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 25/43] intel/blorp/blit: Add support for normalized coordinates

[Jason Ekstrand]

On Wed, May 17, 2017 at 5:42 AM, Pohjolainen, Topi <
topi.pohjolai...@gmail.com> wrote:

> On Tue, May 16, 2017 at 03:45:19PM -0700, Jason Ekstrand wrote:
> > Gen5 and earlier can't do non-normalized coordinates so we need to
> > compensate in the shader.  Fortunately, it's pretty easy plumb through.
> > ---
> >  src/intel/blorp/blorp_blit.c | 27 ++-
> >  src/intel/blorp/blorp_priv.h |  6 ++
> >  2 files changed, 28 insertions(+), 5 deletions(-)
> >
> > diff --git a/src/intel/blorp/blorp_blit.c b/src/intel/blorp/blorp_blit.c
> > index 144bfb3..23e33de 100644
> > --- a/src/intel/blorp/blorp_blit.c
> > +++ b/src/intel/blorp/blorp_blit.c
> > @@ -55,6 +55,7 @@ struct brw_blorp_blit_vars {
> > nir_variable *v_src_z;
> > nir_variable *v_src_offset;
> > nir_variable *v_dst_offset;
> > +   nir_variable *v_src_inv_size;
> >
> > /* gl_FragCoord */
> > nir_variable *frag_coord;
> > @@ -79,6 +80,7 @@ brw_blorp_blit_vars_init(nir_builder *b, struct
> brw_blorp_blit_vars *v,
> > LOAD_INPUT(src_z, glsl_uint_type())
> > LOAD_INPUT(src_offset, glsl_vector_type(GLSL_TYPE_UINT, 2))
> > LOAD_INPUT(dst_offset, glsl_vector_type(GLSL_TYPE_UINT, 2))
> > +   LOAD_INPUT(src_inv_size, glsl_vector_type(GLSL_TYPE_FLOAT, 2))
> >
> >  #undef LOAD_INPUT
> >
> > @@ -198,10 +200,15 @@ blorp_create_nir_tex_instr(nir_builder *b, struct
> brw_blorp_blit_vars *v,
> >
> >  static nir_ssa_def *
> >  blorp_nir_tex(nir_builder *b, struct brw_blorp_blit_vars *v,
> > -  nir_ssa_def *pos, nir_alu_type dst_type)
> > +  const struct brw_blorp_blit_prog_key *key, nir_ssa_def
> *pos)
> >  {
> > +   /* If the sampler requires normalized coordinates, we need to
> compensate. */
> > +   if (key->src_coords_normalized)
> > +  pos = nir_fmul(b, pos, nir_load_var(b, v->v_src_inv_size));
> > +
> > nir_tex_instr *tex =
> > -  blorp_create_nir_tex_instr(b, v, nir_texop_tex, pos, 2, dst_type);
> > +  blorp_create_nir_tex_instr(b, v, nir_texop_tex, pos, 2,
> > + key->texture_data_type);
> >
> > assert(pos->num_components == 2);
> > tex->sampler_dim = GLSL_SAMPLER_DIM_2D;
> > @@ -1188,7 +1195,7 @@ brw_blorp_build_nir_shader(struct blorp_context
> *blorp, void *mem_ctx,
> >   src_pos = nir_ishl(, src_pos, nir_imm_int(, 1));
> >   src_pos = nir_iadd(, src_pos, nir_imm_int(, 1));
> >   src_pos = nir_i2f32(, src_pos);
> > - color = blorp_nir_tex(, , src_pos, key->texture_data_type);
> > + color = blorp_nir_tex(, , key, src_pos);
> >} else {
> >   /* Gen7+ hardware doesn't automaticaly blend. */
> >   color = blorp_nir_manual_blend_average(, , src_pos,
> key->src_samples,
> > @@ -1200,7 +1207,7 @@ brw_blorp_build_nir_shader(struct blorp_context
> *blorp, void *mem_ctx,
> >color = blorp_nir_manual_blend_bilinear(, src_pos,
> key->src_samples, key, );
> > } else {
> >if (key->bilinear_filter) {
> > - color = blorp_nir_tex(, , src_pos, key->texture_data_type);
> > + color = blorp_nir_tex(, , key, src_pos);
> >} else {
> >   /* We're going to use texelFetch, so we need integers */
> >   if (src_pos->num_components == 2) {
> > @@ -2056,9 +2063,19 @@ blorp_blit(struct blorp_batch *batch,
> > wm_prog_key.y_scale = params.src.surf.samples / wm_prog_key.x_scale;
> >
> > if (filter == GL_LINEAR &&
> > -   params.src.surf.samples <= 1 && params.dst.surf.samples <= 1)
> > +   params.src.surf.samples <= 1 && params.dst.surf.samples <= 1) {
> >wm_prog_key.bilinear_filter = true;
> >
> > +  if (batch->blorp->isl_dev->info->gen < 6) {
> > + /* Gen4-5 don't support non-normalized texture coordinates */
> > + wm_prog_key.src_coords_normalized = true;
> > + params.wm_inputs.src_inv_size[0] =
> > +1.0f / minify(params.src.surf.logical_level0_px.width,
> src_level);
> > + params.wm_inputs.src_inv_size[1] =
> > +1.0f / minify(params.src.surf.logical_level0_px.height,
> src_level);
> > +  }
> > +   }
> > +
> > if ((params.src.surf.usage & ISL_SURF_USAGE_DEPTH_BIT) == 0 &&
> > (params.src.surf.usage & ISL_SURF_USAGE_STENCIL_BIT) == 0 &&
> > !isl_format_has_int_channel(params.src.surf.format) &&
> > diff --git a/src/intel/blorp/blorp_priv.h b/src/intel/blorp/blorp_priv.h
> > index c61ab08..39da5af 100644
> > --- a/src/intel/blorp/blorp_priv.h
> > +++ b/src/intel/blorp/blorp_priv.h
> > @@ -124,6 +124,9 @@ struct brw_blorp_wm_inputs
> > struct blorp_surf_offset src_offset;
> > struct blorp_surf_offset dst_offset;
> >
> > +   /* (1/width, 1/height) for the source surface */
> > +   float src_inv_size[2];
> > +
>
> There is still the "pad[1]" in the end which I think is now correct, before
> it should have been "pad[3]", right? It aligns to vec4.


Yes


> Do we really need
> that anymore...
>

Maybe?  The real requirement is 

Re: [Mesa-dev] [PATCH 09/43] intel/isl: Add gen4_filter_tiling

[Jason Ekstrand]

On Tue, May 16, 2017 at 11:40 PM, Pohjolainen, Topi <
topi.pohjolai...@gmail.com> wrote:

> On Tue, May 16, 2017 at 03:45:03PM -0700, Jason Ekstrand wrote:
> > ---
> >  src/intel/isl/isl.c  |  3 +--
> >  src/intel/isl/isl_gen4.c | 51 ++
> ++
> >  src/intel/isl/isl_gen4.h |  5 +
> >  3 files changed, 57 insertions(+), 2 deletions(-)
> >
> > diff --git a/src/intel/isl/isl.c b/src/intel/isl/isl.c
> > index c728a85..321850e 100644
> > --- a/src/intel/isl/isl.c
> > +++ b/src/intel/isl/isl.c
> > @@ -296,8 +296,7 @@ isl_surf_choose_tiling(const struct isl_device *dev,
> > if (ISL_DEV_GEN(dev) >= 6) {
> >isl_gen6_filter_tiling(dev, info, _flags);
> > } else {
> > -  isl_finishme("%s: gen%u", __func__, ISL_DEV_GEN(dev));
> > -  isl_gen6_filter_tiling(dev, info, _flags);
> > +  isl_gen4_filter_tiling(dev, info, _flags);
> > }
> >
> > #define CHOOSE(__tiling) \
> > diff --git a/src/intel/isl/isl_gen4.c b/src/intel/isl/isl_gen4.c
> > index 9fed454..63547f7 100644
> > --- a/src/intel/isl/isl_gen4.c
> > +++ b/src/intel/isl/isl_gen4.c
> > @@ -38,6 +38,57 @@ isl_gen4_choose_msaa_layout(const struct isl_device
> *dev,
> >  }
> >
> >  void
> > +isl_gen4_filter_tiling(const struct isl_device *dev,
> > +   const struct isl_surf_init_info *restrict info,
> > +   isl_tiling_flags_t *flags)
> > +{
> > +   /* Gen4-5 only support linear, X, and Y-tiling. */
> > +   *flags &= ISL_TILING_LINEAR_BIT | ISL_TILING_X_BIT |
> ISL_TILING_Y0_BIT;
>
> Can we put () around .. | .. | .. just as you have further down?
>

Sure.


> > +
> > +   if (isl_surf_usage_is_depth_or_stencil(info->usage)) {
> > +  assert(!ISL_DEV_USE_SEPARATE_STENCIL(dev));
> > +
> > +  /* From the g35 PRM Vol. 2, 3DSTATE_DEPTH_BUFFER::Tile Walk:
> > +   *
> > +   *"The Depth Buffer, if tiled, must use Y-Major tiling"
> > +   */
> > +  *flags &= ISL_TILING_LINEAR_BIT | ISL_TILING_Y0_BIT;
>
> Same here.
>
> > +   }
> > +
> > +   if (info->usage & (ISL_SURF_USAGE_DISPLAY_ROTATE_90_BIT |
> > +  ISL_SURF_USAGE_DISPLAY_ROTATE_180_BIT |
> > +  ISL_SURF_USAGE_DISPLAY_ROTATE_270_BIT)) {
> > +  assert(*flags & ISL_SURF_USAGE_DISPLAY_BIT);
> > +  isl_finishme("%s:%s: handle rotated display surfaces",
> > +   __FILE__, __func__);
> > +   }
> > +
> > +   if (info->usage & (ISL_SURF_USAGE_DISPLAY_FLIP_X_BIT |
> > +  ISL_SURF_USAGE_DISPLAY_FLIP_Y_BIT)) {
> > +  assert(*flags & ISL_SURF_USAGE_DISPLAY_BIT);
> > +  isl_finishme("%s:%s: handle flipped display surfaces",
> > +   __FILE__, __func__);
> > +   }
> > +
> > +   if (info->usage & ISL_SURF_USAGE_DISPLAY_BIT) {
> > +  /* Before Skylake, the display engine does not accept Y */
> > +  *flags &= (ISL_TILING_LINEAR_BIT | ISL_TILING_X_BIT);
> > +   }
> > +
> > +   assert(info->samples == 1);
> > +
> > +   /* From the g35 PRM, Volume 1, 11.5.5, "Per-Stream Tile Format
> Support":
> > +*
> > +*"NOTE: 128BPE Format Color buffer ( render target ) MUST be
> either
> > +*TileX or Linear."
> > +*
> > +* This is required all the way up to Sandy Bridge.
> > +*/
> > +   if (isl_format_get_layout(info->format)->bpb >= 128)
> > +  *flags &= ~ISL_TILING_Y0_BIT;
> > +}
> > +
> > +void
> >  isl_gen4_choose_image_alignment_el(const struct isl_device *dev,
> > const struct isl_surf_init_info
> *restrict info,
> > enum isl_tiling tiling,
> > diff --git a/src/intel/isl/isl_gen4.h b/src/intel/isl/isl_gen4.h
> > index dc6102b..c04f7fb 100644
> > --- a/src/intel/isl/isl_gen4.h
> > +++ b/src/intel/isl/isl_gen4.h
> > @@ -37,6 +37,11 @@ isl_gen4_choose_msaa_layout(const struct isl_device
> *dev,
> >  enum isl_msaa_layout *msaa_layout);
> >
> >  void
> > +isl_gen4_filter_tiling(const struct isl_device *dev,
> > +   const struct isl_surf_init_info *restrict info,
> > +   isl_tiling_flags_t *flags);
> > +
> > +void
> >  isl_gen4_choose_image_alignment_el(const struct isl_device *dev,
> > const struct isl_surf_init_info
> *restrict info,
> > enum isl_tiling tiling,
> > --
> > 2.5.0.400.gff86faf
> >
> > ___
> > 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 14/43] intel/genxml: Add SAMPLER_STATE to gen 4.5

[Jason Ekstrand]

On Wed, May 17, 2017 at 2:10 AM, Pohjolainen, Topi <
topi.pohjolai...@gmail.com> wrote:

> On Tue, May 16, 2017 at 03:45:08PM -0700, Jason Ekstrand wrote:
> > Somehow this got missed.
>
> This is identical to gen4, right?
>

I copied+pasted from gen4.xml.  I just diff'd gen4 and gen5 and the only
difference is monocrome filter width/height which we don't use.  It appears
these two fields were added on G45.  I'll go ahead and add them, not that
it matters.

--Jason


> > ---
> >  src/intel/genxml/gen45.xml | 61 ++
> 
> >  1 file changed, 61 insertions(+)
> >
> > diff --git a/src/intel/genxml/gen45.xml b/src/intel/genxml/gen45.xml
> > index bde6080..0365a36 100644
> > --- a/src/intel/genxml/gen45.xml
> > +++ b/src/intel/genxml/gen45.xml
> > @@ -549,6 +549,67 @@
> >  
> >
> >
> > +  
> > +
> > +
> > +
> > + prefix="MIPFILTER">
> > +  
> > +  
> > +  
> > +
> > + prefix="MAPFILTER">
> > +  
> > +  
> > +  
> > +  
> > +
> > + prefix="MAPFILTER"/>
> > +
> > +
> > +  
> > +  
> > +  
> > +  
> > +  
> > +  
> > +  
> > +  
> > +
> > +
> > +
> > + type="uint">
> > +  
> > +  
> > +
> > + type="Texture_Coordinate_Mode"/>
> > + type="Texture_Coordinate_Mode"/>
> > + type="Texture_Coordinate_Mode"/>
> > + type="offset"/>
> > +
> > +
> > + prefix="KEYFILTER">
> > +  
> > +  
> > +
> > +
> > +  
> > +  
> > +  
> > +  
> > +  
> > +  
> > +  
> > +  
> > +
> > + end="109" type="bool"/>
> > + end="110" type="bool"/>
> > + end="111" type="bool"/>
> > + end="112" type="bool"/>
> > + end="113" type="bool"/>
> > + end="114" type="bool"/>
> > +  
> > +
> >
> >   type="address"/>
> >  
> > --
> > 2.5.0.400.gff86faf
> >
> > ___
> > 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] [Mesa-stable] [PATCH 1/3] i965/vec4/gs: restore the uniform values which was overwritten by failed vec4_gs_visitor execution

[Francisco Jerez]

Samuel Iglesias Gonsálvez  writes:

> Kind reminder that patches 1 and 3 are still unreviewed.
>

Seems terrible, this makes me feel like deleting the vec4 back-end
instead.  But okay, series is:

Acked-by: Francisco Jerez 

> Sam
>
> On Fri, 2017-05-05 at 12:38 +0200, Samuel Iglesias Gonsálvez wrote:
>> We are going to add a packing feature to reduce the usage of the push
>> constant buffer. One of the consequences is that 'nr_params' would be
>> modified by vec4_visitor's run call, so we need to restore it if one
>> of
>> them failed before executing the fallback ones. Same thing happens to
>> the
>> uniforms values that would be reordered afterwards.
>> 
>> Fixes GL45-CTS.arrays_of_arrays_gl.InteractionFunctionCalls2 when
>> the dvec4 alignment and packing patch is applied.
>> 
>> Signed-off-by: Samuel Iglesias Gonsálvez 
>> Cc: "17.1" 
>> ---
>>  src/intel/compiler/brw_vec4_gs_visitor.cpp | 26
>> ++
>>  1 file changed, 26 insertions(+)
>> 
>> diff --git a/src/intel/compiler/brw_vec4_gs_visitor.cpp
>> b/src/intel/compiler/brw_vec4_gs_visitor.cpp
>> index 4a8b5be30e..5fcd02831a 100644
>> --- a/src/intel/compiler/brw_vec4_gs_visitor.cpp
>> +++ b/src/intel/compiler/brw_vec4_gs_visitor.cpp
>> @@ -868,10 +868,36 @@ brw_compile_gs(const struct brw_compiler
>> *compiler, void *log_data,
>>  
>>   vec4_gs_visitor v(compiler, log_data, , prog_data,
>> shader,
>> mem_ctx, true /* no_spills */,
>> shader_time_index);
>> +
>> + /* Backup 'nr_params' and 'param' as they can be modified
>> by the
>> +  * the DUAL_OBJECT visitor. If it fails, we will run the
>> fallback
>> +  * (DUAL_INSTANCED or SINGLE mode) and we need to restore
>> original
>> +  * values.
>> +  */
>> + const unsigned param_count = prog_data-
>> >base.base.nr_params;
>> + gl_constant_value **param = ralloc_array(NULL,
>> gl_constant_value*,
>> +  param_count);
>> + memcpy(param, prog_data->base.base.param,
>> +sizeof(gl_constant_value*) * param_count);
>> +
>>   if (v.run()) {
>> +/* Success! Backup is not needed */
>> +ralloc_free(param);
>>  return brw_vec4_generate_assembly(compiler, log_data,
>> mem_ctx,
>>    shader, _data-
>> >base, v.cfg,
>>    final_assembly_size);
>> + } else {
>> +/* These variables could be modified by the execution of
>> the GS
>> + * visitor if it packed the uniforms in the push
>> constant buffer.
>> + * As it failed, we need restore them so we can start
>> again with
>> + * DUAL_INSTANCED or SINGLE mode.
>> + *
>> + * FIXME: Could more variables be modified by this
>> execution?
>> + */
>> +memcpy(prog_data->base.base.param, param,
>> +   sizeof(gl_constant_value*) * param_count);
>> +prog_data->base.base.nr_params = param_count;
>> +ralloc_free(param);
>>   }
>>    }
>> }
> ___
> mesa-stable mailing list
> mesa-sta...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-stable


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

Re: [Mesa-dev] [PATCH 12/43] intel/genxml: Sampler state is a pointer on gen4-5

[Jason Ekstrand]

On Wed, May 17, 2017 at 2:08 AM, Pohjolainen, Topi <
topi.pohjolai...@gmail.com> wrote:

> On Tue, May 16, 2017 at 03:45:06PM -0700, Jason Ekstrand wrote:
> > ---
> >  src/intel/genxml/gen4.xml | 6 +++---
> >  src/intel/genxml/gen45.xml| 6 +++---
> >  src/intel/genxml/gen5.xml | 6 +++---
> >  src/mesa/drivers/dri/i965/genX_state_upload.c | 2 +-
> >  4 files changed, 10 insertions(+), 10 deletions(-)
> >
> > diff --git a/src/intel/genxml/gen4.xml b/src/intel/genxml/gen4.xml
> > index 27dd8ff..0d68125 100644
> > --- a/src/intel/genxml/gen4.xml
> > +++ b/src/intel/genxml/gen4.xml
> > @@ -477,7 +477,7 @@
> >   type="uint"/>
> >   type="uint"/>
> >   type="uint"/>
> > - type="address"/>
> > + type="address"/>
>
> That is the correct name although the spec says it represents offset.
>
> In "5.2.1.1 GS_STATE":
>
>"It is specified as a 32-byte-granular offset from the General State
> Pointer."
>
> We try to follow the exact names in PRMs, right?
>

Yeah... This is something that falls somewhere between documentation and
implementation.  In i965, we set the general state pointer to 0 and use a
relocation so this effectively becomes a pointer.  I don't care too much
what it's called but it looks a little weird to have an address in a field
labled offset.  I guess we do that for scratch..

--Jason


> >  
> >  
> >  
> > @@ -750,7 +750,7 @@
> >   type="uint"/>
> >   type="uint"/>
> >  
> > - type="address"/>
> > + type="address"/>
> >  
> >   type="bool"/>
> >  
> > @@ -779,7 +779,7 @@
> >   type="uint"/>
> >   type="uint"/>
> >   end="99" type="uint"/>
> > - type="address"/>
> > + type="address"/>
> >  
> >  
> >   type="uint"/>
> > diff --git a/src/intel/genxml/gen45.xml b/src/intel/genxml/gen45.xml
> > index e63f3bd..de6552c 100644
> > --- a/src/intel/genxml/gen45.xml
> > +++ b/src/intel/genxml/gen45.xml
> > @@ -480,7 +480,7 @@
> >   type="uint"/>
> >   type="bool"/>
> >  
> > - type="address"/>
> > + type="address"/>
> >  
> >  
> >  
> > @@ -701,7 +701,7 @@
> >   type="uint"/>
> >   type="uint"/>
> >  
> > - type="address"/>
> > + type="address"/>
> >  
> >   type="bool"/>
> >  
> > @@ -731,7 +731,7 @@
> >   type="uint"/>
> >   type="uint"/>
> >   end="99" type="uint"/>
> > - type="address"/>
> > + type="address"/>
> >  
> >  
> >   type="uint"/>
> > diff --git a/src/intel/genxml/gen5.xml b/src/intel/genxml/gen5.xml
> > index a521737..f6e912b 100644
> > --- a/src/intel/genxml/gen5.xml
> > +++ b/src/intel/genxml/gen5.xml
> > @@ -479,7 +479,7 @@
> >   type="bool"/>
> >   type="bool"/>
> >  
> > - type="address"/>
> > + type="address"/>
> >  
> >  
> >  
> > @@ -857,7 +857,7 @@
> >   type="uint"/>
> >   type="uint"/>
> >  
> > - type="address"/>
> > + type="address"/>
> >  
> >   type="bool"/>
> >  
> > @@ -886,7 +886,7 @@
> >   type="uint"/>
> >   type="uint"/>
> >   end="99" type="uint"/>
> > - type="address"/>
> > + type="address"/>
> >  
> >  
> >   type="uint"/>
> > diff --git a/src/mesa/drivers/dri/i965/genX_state_upload.c
> b/src/mesa/drivers/dri/i965/genX_state_upload.c
> > index 3921a6f..ce11d16 100644
> > --- a/src/mesa/drivers/dri/i965/genX_state_upload.c
> > +++ b/src/mesa/drivers/dri/i965/genX_state_upload.c
> > @@ -1827,7 +1827,7 @@ genX(upload_vs_state)(struct brw_context *brw)
> >   CLAMP(brw->urb.nr_vs_entries / 2, 1, devinfo->max_vs_threads)
> - 1;
> >
> >vs.StatisticsEnable = false;
> > -  vs.SamplerStateOffset =
> > +  vs.SamplerStatePointer =
> >   instruction_ro_bo(brw->batch.bo, stage_state->sampler_offset);
> >  #endif
> >
> > --
> > 2.5.0.400.gff86faf
> >
> > ___
> > 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: remove an incorrect assertion

[Marek Olšák]

Reviewed-by: Marek Olšák 

Marek

On Wed, May 17, 2017 at 3:18 PM, Nicolai Hähnle  wrote:
> From: Nicolai Hähnle 
>
> There is really no reason why the current DrawBuffer needs to be complete
> at this point. In particularly, the assertion gets hit on the X server side
> in libglx when running .../piglit/bin/glx-get-current-display-ext -auto
> (which uses indirect GLX rendering).
>
> Fixes: 19b61799e3d0 ("st/mesa: don't cast the incomplete framebufer to 
> st_framebuffer")
> Reported-by: Michel Dänzer 
> ---
>  src/mesa/state_tracker/st_manager.c | 2 --
>  1 file changed, 2 deletions(-)
>
> diff --git a/src/mesa/state_tracker/st_manager.c 
> b/src/mesa/state_tracker/st_manager.c
> index 3178e25..cc781f4 100644
> --- a/src/mesa/state_tracker/st_manager.c
> +++ b/src/mesa/state_tracker/st_manager.c
> @@ -830,22 +830,20 @@ st_api_destroy(struct st_api *stapi)
>
>  /**
>   * Flush the front buffer if the current context renders to the front buffer.
>   */
>  void
>  st_manager_flush_frontbuffer(struct st_context *st)
>  {
> struct st_framebuffer *stfb = st_ws_framebuffer(st->ctx->DrawBuffer);
> struct st_renderbuffer *strb = NULL;
>
> -   assert(st->ctx->DrawBuffer != _mesa_get_incomplete_framebuffer());
> -
> if (stfb)
>strb = 
> st_renderbuffer(stfb->Base.Attachment[BUFFER_FRONT_LEFT].Renderbuffer);
> if (!strb)
>return;
>
> /* never a dummy fb */
> stfb->iface->flush_front(>iface, stfb->iface, 
> ST_ATTACHMENT_FRONT_LEFT);
>  }
>
>  /**
> --
> 2.9.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] glxglvnddispatch: Add missing dispatch for GetDriverConfig

[Kyle Brenneman]

On 05/17/2017 06:57 AM, Emil Velikov wrote:

On 16 May 2017 at 22:42, Hans de Goede  wrote:

Hi,


On 05/16/2017 07:51 PM, Emil Velikov wrote:

Hi Hans

Please poke if patches fall through the cracks.

On 20 March 2017 at 11:05, Hans de Goede  wrote:

Together with some fixes to xdriinfo this fixes xdriinfo not working
with glvnd.

Since apps (xdriinfo) expect GetDriverConfig to work without going to
need through the dance to setup a glxcontext (which is a reasonable
expectation IMHO), the dispatch for this ends up significantly different
then any other dispatch function.

This patch gets the job done, but I'm not really happy with how this
patch turned out, suggestions for a better fix are welcome.

Cc: Kyle Brenneman 
Signed-off-by: Hans de Goede 
---
  src/glx/g_glxglvnddispatchfuncs.c   | 18 ++
  src/glx/g_glxglvnddispatchindices.h |  1 +
  2 files changed, 19 insertions(+)

diff --git a/src/glx/g_glxglvnddispatchfuncs.c
b/src/glx/g_glxglvnddispatchfuncs.c
index b5e3398..040cdf8 100644
--- a/src/glx/g_glxglvnddispatchfuncs.c
+++ b/src/glx/g_glxglvnddispatchfuncs.c
@@ -4,6 +4,7 @@
   */
  #include 

+#include "glxclient.h"
  #include "glxglvnd.h"
  #include "glxglvnddispatchfuncs.h"
  #include "g_glxglvnddispatchindices.h"
@@ -50,6 +51,7 @@ const char * const
__glXDispatchTableStrings[DI_LAST_INDEX] = {
  __ATTRIB(GetCurrentDisplayEXT),
  // glXGetCurrentDrawable implemented by libglvnd
  // glXGetCurrentReadDrawable implemented by libglvnd
+__ATTRIB(GetDriverConfig),


Back in Nov 2016 we had a chat with Adam and if I understood things
correctly the idea was to kill off the following:

glXGetScreenDriver
glXGetDriverConfig

Neither of those is part of an extension and the only user xdriinfo,
is not that useful.
Would be great if distributions let it to rest and we don't have to
worry about it ever being around ;-)


The problem is that driconf uses them and people actually use driconf,
see: https://bugzilla.redhat.com/show_bug.cgi?id=1429894


Ouch, had not idea people are still using that behemoth :-(
In that case we cannot nuke the API, so let's merge this patch.

Small nit: please drop the compilation guard. Those should be always
true when compiling the file.

Kyle/others - the GLVND bits are in, aren't they? Do you have any
comments on the patch?

With that the nit
Reviewed-by: Emil Velikov 
Cc: mesa-sta...@lists.freedesktop.org

Thanks
Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
The patch assumes that glXGetDriverConfig will only ever be implemented 
by Mesa. As long as that's a safe assumption, the change looks right to me.

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

Re: [Mesa-dev] [PATCH 2/3] tgsi: store the sampler view type directly in the instruction

[Roland Scheidegger]

Am 17.05.2017 um 11:17 schrieb Samuel Pitoiset:
> RadeonSI needs to do a special lowering for Gather4 with integer
> formats, but with bindless samplers we just can't access the index.
> 
> Instead, store the return type in the instruction like the target.
> 
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/gallium/auxiliary/tgsi/tgsi_ureg.c |  7 +--
>  src/gallium/auxiliary/tgsi/tgsi_ureg.h | 11 ---
>  src/gallium/include/pipe/p_shader_tokens.h |  2 ++
>  src/mesa/state_tracker/st_atifs_to_tgsi.c  |  2 +-
>  src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 17 ++---
>  src/mesa/state_tracker/st_mesa_to_tgsi.c   | 21 +
>  src/mesa/state_tracker/st_mesa_to_tgsi.h   |  4 
>  7 files changed, 43 insertions(+), 21 deletions(-)
> 
> diff --git a/src/gallium/auxiliary/tgsi/tgsi_ureg.c 
> b/src/gallium/auxiliary/tgsi/tgsi_ureg.c
> index 9eb00d0919..1cdb95cc95 100644
> --- a/src/gallium/auxiliary/tgsi/tgsi_ureg.c
> +++ b/src/gallium/auxiliary/tgsi/tgsi_ureg.c
> @@ -1289,7 +1289,7 @@ ureg_fixup_label(struct ureg_program *ureg,
>  void
>  ureg_emit_texture(struct ureg_program *ureg,
>unsigned extended_token,
> -  unsigned target, unsigned num_offsets)
> +  unsigned target, unsigned return_type, unsigned 
> num_offsets)
>  {
> union tgsi_any_token *out, *insn;
>  
> @@ -1300,6 +1300,7 @@ ureg_emit_texture(struct ureg_program *ureg,
>  
> out[0].value = 0;
> out[0].insn_texture.Texture = target;
> +   out[0].insn_texture.ReturnType = return_type;
> out[0].insn_texture.NumOffsets = num_offsets;
>  }
>  
> @@ -1386,6 +1387,7 @@ ureg_tex_insn(struct ureg_program *ureg,
>const struct ureg_dst *dst,
>unsigned nr_dst,
>unsigned target,
> +  unsigned return_type,
>const struct tgsi_texture_offset *texoffsets,
>unsigned nr_offset,
>const struct ureg_src *src,
> @@ -1407,7 +1409,8 @@ ureg_tex_insn(struct ureg_program *ureg,
>   nr_dst,
>   nr_src);
>  
> -   ureg_emit_texture( ureg, insn.extended_token, target, nr_offset );
> +   ureg_emit_texture( ureg, insn.extended_token, target, return_type,
> +  nr_offset );
>  
> for (i = 0; i < nr_offset; i++)
>ureg_emit_texture_offset( ureg, [i]);
> diff --git a/src/gallium/auxiliary/tgsi/tgsi_ureg.h 
> b/src/gallium/auxiliary/tgsi/tgsi_ureg.h
> index 6d2f5c0e99..54f95ba565 100644
> --- a/src/gallium/auxiliary/tgsi/tgsi_ureg.h
> +++ b/src/gallium/auxiliary/tgsi/tgsi_ureg.h
> @@ -555,6 +555,7 @@ ureg_tex_insn(struct ureg_program *ureg,
>const struct ureg_dst *dst,
>unsigned nr_dst,
>unsigned target,
> +  unsigned return_type,
>const struct tgsi_texture_offset *texoffsets,
>unsigned nr_offset,
>const struct ureg_src *src,
> @@ -596,7 +597,7 @@ ureg_emit_label(struct ureg_program *ureg,
>  void
>  ureg_emit_texture(struct ureg_program *ureg,
>unsigned insn_token,
> -  unsigned target, unsigned num_offsets);
> +  unsigned target, unsigned return_type, unsigned 
> num_offsets);
>  
>  void
>  ureg_emit_texture_offset(struct ureg_program *ureg,
> @@ -748,6 +749,7 @@ static inline void ureg_##op( struct ureg_program *ureg,  
>   \
>struct ureg_src src1 )\
>  {   \
> unsigned opcode = TGSI_OPCODE_##op;  \
> +   unsigned return_type = TGSI_RETURN_TYPE_UNKNOWN; \
> struct ureg_emit_insn_result insn;   \
> if (ureg_dst_is_empty(dst))  \
>return;   \
> @@ -756,7 +758,8 @@ static inline void ureg_##op( struct ureg_program *ureg,  
>   \
>   dst.Saturate,  \
>   1, \
>   2);\
> -   ureg_emit_texture( ureg, insn.extended_token, target, 0 );
> \
> +   ureg_emit_texture( ureg, insn.extended_token, target,\
> +  return_type, 0 ); \
> ureg_emit_dst( ureg, dst );  \
> ureg_emit_src( ureg, src0 ); \
> ureg_emit_src( ureg, src1 ); \
> @@ -796,6 +799,7 @@ static inline void ureg_##op( struct ureg_program *ureg,  
>   \
>struct ureg_src src3 )   

Re: [Mesa-dev] [PATCH 05/43] i965/blorp: Properly handle mt->first_level

[Jason Ekstrand]

On Tue, May 16, 2017 at 11:16 PM, Pohjolainen, Topi <
topi.pohjolai...@gmail.com> wrote:

> On Tue, May 16, 2017 at 03:44:59PM -0700, Jason Ekstrand wrote:
> > The guts of blorp and ISL don't understand i965's partial miptrees.
> > Instead, we need to subtract off first_level before we hand anything off
> > to blorp.
> > ---
> >  src/mesa/drivers/dri/i965/brw_blorp.c | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/src/mesa/drivers/dri/i965/brw_blorp.c
> b/src/mesa/drivers/dri/i965/brw_blorp.c
> > index ebc4612..64aa4c9 100644
> > --- a/src/mesa/drivers/dri/i965/brw_blorp.c
> > +++ b/src/mesa/drivers/dri/i965/brw_blorp.c
> > @@ -271,6 +271,9 @@ blorp_surf_for_miptree(struct brw_context *brw,
> > }
> > assert((surf->aux_usage == ISL_AUX_USAGE_NONE) ==
> >(surf->aux_addr.buffer == NULL));
>
> Here it would be nice to have an assert:
>
>   assert(*level >= mt->first_level);
>

I'm happy to add that explicitly here.  However it is already checked above
by check_level_layer.


> > +
> > +   /* ISL wants real levels, not offset ones. */
> > +   *level -= mt->first_level;
> >  }
> >
> >  static enum isl_format
> > --
> > 2.5.0.400.gff86faf
> >
> > ___
> > 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] [RFC] Deprecating old DRI loaders/drivers

[Jason Ekstrand]

On Wed, May 17, 2017 at 3:39 AM, Emil Velikov 
wrote:

> On 17 May 2017 at 05:04, Jason Ekstrand  wrote:
>
> > If we are genuinely making things more maintainable, then maybe
> deprecation
> > is reasonable.  However, of it's just churn, then it may just be a
> source of
> > new bugs to fix.  I think asking "why?" is perfectly reasonable.
> >
> Seems like I failed to state it clearly:
> The new code added is a few warning messages. Those in itself will
> flag up any existing bugs that we have failed to catch.
> Followed by some period X, those will be removed alongside the unused code.
>

What code?  I think a decent part of the communication problem is that this
entire discussion is about a generic "deprecation period" that could
theoretically be applied to any feature.  Could you please be specific
about exactly what code you are itching to remove and why?  I firmly
believe that untested code is broken code and should be removed, but you
have yet to provide any details.  You said you have a branch.  Could you
provide a link?


> > On the other side, perhaps we should consider instead taking advantage of
> > the backwards comparability and dropping some of the old and unmaintained
> > drivers from the tree, put them on a critical-bugfix-only branch, and
> > recommend that distros build two mesas and only install the loader from
> the
> > newer one.  Dropping i915, r200, and other effectively unmaintained
> drivers
> > from the tree would make it much easier to do core state tracker cleanups
> > since there would effectively only be two state trackers: gallium and
> i915.
> > For example, there's a lot of code floating around for dealing with
> hardware
> > that doesn't have native integers.
> >
> FWIW I have patches for i915 and nouveau_vieux which add support for
> DRI2_FLUSH v4 and others.
>
> I tend to agree with your idea here, although it's somewhat orthogonal
> to what I'm suggesting.
> Can we move that to its own thread?
>

If we're going to talk about generic deprication periods, then they're
absolutely related.  If we're going to drop old drivers then the answer to
the question becomes "never" for any versions they're using.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 00/43] BLORP for everyone!

[Pohjolainen, Topi]

On Wed, May 17, 2017 at 09:48:40AM +0300, Pohjolainen, Topi wrote:
> On Tue, May 16, 2017 at 03:44:54PM -0700, Jason Ekstrand wrote:
> > When Sandy Bridge came out, surface state management suddenly became
> > significantly more complicated because of HiZ, MSAA, and separate stencil.
> > In order to deal with all of these complications, Paul Berry write BLORP
> > which is a blit framework that's capable of handling all of the exotic
> > cases we have to deal with in a modern Intel driver.  As time went on,
> > blorp was ported to Ivy Bridge and then Haswell.  At Broadwell, we tried to
> > get away from blorp but eventually decided that having one more copy of
> > state setup wasn't so bad compared to dealing with meta so it was brought
> > forward to gen8-9.  However, it has never been back-ported to gen4-5...
> > Until today!
> > 
> > Why should we do this?  For one thing, it's actually less code.  The patch
> > which actually adds gen4 support to blorp is around 300 LOC.  If you add on
> > the patch which adds SF program support, you get another 50.  On the other
> > hand, the meta PBO upload path is 450 lines of code all by itself and that
> > doesn't include the DD table entry or the code we have to carry in i965 to
> > support it.  Secondly, it lets us unify a bunch of gen6 and gen4 stuff.
> > You can already see in this series that I delete an entire blitframebuffers
> > implementation because we were carrying 2 just so gen4-5 could have its
> > own.
> > 
> > This series doesn't actually get everything converted over but it does
> > convert enough that I'm reasonably confident that it all works.  In the
> > process, this series fixes 12 tests: 2 on ILK, 2 on g45, and 8 on i965.
> > I intentionally did most of the BLORP port in a single patch.  This way
> > it's easy for the reviewer to see both the new state setup code as well as
> > the few modifications that have to be made to blorp_blit and blorp_clear to
> > handle new cases created by gen4.
> > 
> > The only thing I'm not entirely happy with is the way color write disables
> > get plumbed through ISL.  That said, I don't come up with a better
> > mechanism so I'm fine with what I have.
> > 
> > This series is available here:
> > 
> > https://cgit.freedesktop.org/~jekstrand/mesa/log/?h=review/blorp-gen4
> > 
> > Happy reviewing!
> > 
> > 
> > Jason Ekstrand (43):
> >   i965/blorp: Do and end-of-pipe sync on both sides of fast-clear ops

I had to fight quite a bit not to regress performance when I added "proper"
end of pipe sync involving the post-flush write. This meant tracking more
carefully that we didn't flush in vain if something else trickered a flush
between fast clear and use.
Of course, what you have here is correct thing to do, only it may also
introduce extra, unneeded flushing. If that happens we can optimize those
cases later on:

Reviewed-by: Topi Pohjolainen 

> >   i965: Use blorp_copy for doing r8 stencil updates on HSW
> >   intel/blorp: Move the gen7 stencil format workaround to blorp_blit
> >   i965/miptree: Take first_level into account when converting to ISL
> >   i965/blorp: Properly handle mt->first_level
> >   intel/isl: Don't request space for stencil/hiz packets unless needed
> 
> Patches 2-6:
> Reviewed-by: Topi Pohjolainen 
> 
> >   intel/isl: Add support for gen4 cube maps to get_image_offset_sa
> >   intel/isl: Add support for setting component write disables
> >   intel/isl: Add gen4_filter_tiling
> 
> Patches 8 and 9:
> Reviewed-by: Topi Pohjolainen 
> 
> >   intel/genxml: Make a bunch of things offsets on gen4-5

Patch 10:
Reviewed-by: Topi Pohjolainen 

> >   intel/gensml: Suffix KSP0 fields on Iron Lake
> >   intel/genxml: Sampler state is a pointer on gen4-5
> >   intel/genxml: Rename the CC_VIEWPORT pointer on gen4-5
> >   intel/genxml: Add SAMPLER_STATE to gen 4.5
> >   intel/genxml: Iron Lake doesn't support non-normalized sampler
> > coordinates
> >   intel/genxml: Use the right subtype for VF_STATISTICS on gen4
> >   intel/genxml: Rename 3DSTATE_AA_LINE_PARAMS on gen5

Patches 12-17:
Reviewed-by: Topi Pohjolainen 

> >   intel/decoder: Handle gen4 VF_STATISTICS and PIPELINE_SELECT
> >   intel/decoder: Handle the BLT ring in gen_group_get_length
> >   intel/compiler: Make brw_disasm take const assembly
> >   i965/sf: make brw_sf_prog_key::interp_mode an array
> >   i965/clip: Make brw_clip_prog_key::interp_mode an array
> >   i965: Move SF compilation to the compiler
> >   i965: Move clip program compilation to the compiler
> >   intel/blorp/blit: Add support for normalized coordinates
> >   intel/blorp: Pull the pipeline bits of blorp_exec into a helper
> >   intel/blorp: Delete isl_to_gen_ds_surfype
> >   intel/blorp: Don't use ffma directly
> >   intel/blorp: Re-arrange blorp_genX_exec.h
> >   intel/blorp: Make the common genX_blorp_exec code gen4-safe
> >   

[Mesa-dev] [Bug 101071] compiling glsl fails with undefined reference to `pthread_create'

[bugzilla-daemon]

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

--- Comment #2 from war...@o2.pl ---
Emil,
For custom DSO:

[piotro@minimyth-dev ~]$ export
LD_LIBRARY_PATH=/home/piotro/minimyth-dev/images/build/usr/lib/
[piotro@minimyth-dev ~]$ env
XDG_SESSION_ID=c7
TERM=xterm
SHELL=/bin/bash
SSH_CLIENT=192.168.1.254 41500 22
SSH_TTY=/dev/pts/0
USER=piotro
LD_LIBRARY_PATH=/home/piotro/minimyth-dev/images/build/usr/lib/
MAIL=/var/spool/mail/piotro
PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
HG=/usr/bin/hg
PWD=/home/piotro
LANG=en_US.UTF8
SHLVL=1
HOME=/home/piotro
LOGNAME=piotro
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1001/bus
SSH_CONNECTION=192.168.1.254 41500 192.168.1.190 22
XDG_RUNTIME_DIR=/run/user/1001
_=/usr/bin/env
[piotro@minimyth-dev ~]$ ldd -r
/home/piotro/minimyth-dev/images/build/usr/lib/gcc/x86_64-minimyth-linux-gnu/5.3.0/libstdc++.so
linux-vdso.so.1 (0x7ffee99fd000)
libm.so.6 => /usr/lib/libm.so.6 (0x7faef68e6000)
libc.so.6 => /usr/lib/libc.so.6 (0x7faef6542000)
/usr/lib64/ld-linux-x86-64.so.2 (0x55db774d7000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x7faef632b000)
[piotro@minimyth-dev ~]$

for libstdc++ I need to look as it...

-- 
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] st/mesa: remove an incorrect assertion

[Nicolai Hähnle]

From: Nicolai Hähnle 

There is really no reason why the current DrawBuffer needs to be complete
at this point. In particularly, the assertion gets hit on the X server side
in libglx when running .../piglit/bin/glx-get-current-display-ext -auto
(which uses indirect GLX rendering).

Fixes: 19b61799e3d0 ("st/mesa: don't cast the incomplete framebufer to 
st_framebuffer")
Reported-by: Michel Dänzer 
---
 src/mesa/state_tracker/st_manager.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/src/mesa/state_tracker/st_manager.c 
b/src/mesa/state_tracker/st_manager.c
index 3178e25..cc781f4 100644
--- a/src/mesa/state_tracker/st_manager.c
+++ b/src/mesa/state_tracker/st_manager.c
@@ -830,22 +830,20 @@ st_api_destroy(struct st_api *stapi)
 
 /**
  * Flush the front buffer if the current context renders to the front buffer.
  */
 void
 st_manager_flush_frontbuffer(struct st_context *st)
 {
struct st_framebuffer *stfb = st_ws_framebuffer(st->ctx->DrawBuffer);
struct st_renderbuffer *strb = NULL;
 
-   assert(st->ctx->DrawBuffer != _mesa_get_incomplete_framebuffer());
-
if (stfb)
   strb = 
st_renderbuffer(stfb->Base.Attachment[BUFFER_FRONT_LEFT].Renderbuffer);
if (!strb)
   return;
 
/* never a dummy fb */
stfb->iface->flush_front(>iface, stfb->iface, ST_ATTACHMENT_FRONT_LEFT);
 }
 
 /**
-- 
2.9.3

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

Re: [Mesa-dev] [PATCH] Android: correct libz dependency

[Emil Velikov]

On 17 May 2017 at 13:45, Rob Herring  wrote:
> On Wed, May 17, 2017 at 12:10 AM, Chih-Wei Huang
>  wrote:
>> Commit 6facb0c0 ("android: fix libz dynamic library dependencies")
>> unconditionally adds libz as a dependency to all shared libraries.
>> That is unnecessary.
>>
>> Commit 85a9b1b5 introduced libz as a dependency to libmesa_util.
>> So only the shared libraries that use libmesa_util need libz.
>>
>> Fix Android Lollipop build by adding the include path of zlib to
>> libmesa_util explicitly instead of getting the path implicitly
>> from zlib since it doesn't export the include path in Lollipop.
>>
>> Fixes: 6facb0c0 "android: fix libz dynamic library dependencies"
>>
>> Signed-off-by: Chih-Wei Huang 
>> ---
>>  Android.common.mk  | 4 
>>  src/gallium/targets/dri/Android.mk | 3 ++-
>>  src/intel/Android.vulkan.mk| 2 +-
>>  src/mesa/drivers/dri/Android.mk| 3 ++-
>>  src/util/Android.mk| 1 +
>>  5 files changed, 6 insertions(+), 7 deletions(-)
>
> Reviewed-by: Rob Herring 
Thanks Rob. Pushed to master.

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

Re: [Mesa-dev] [PATCH] glxglvnddispatch: Add missing dispatch for GetDriverConfig

[Emil Velikov]

On 16 May 2017 at 22:42, Hans de Goede  wrote:
> Hi,
>
>
> On 05/16/2017 07:51 PM, Emil Velikov wrote:
>>
>> Hi Hans
>>
>> Please poke if patches fall through the cracks.
>>
>> On 20 March 2017 at 11:05, Hans de Goede  wrote:
>>>
>>> Together with some fixes to xdriinfo this fixes xdriinfo not working
>>> with glvnd.
>>>
>>> Since apps (xdriinfo) expect GetDriverConfig to work without going to
>>> need through the dance to setup a glxcontext (which is a reasonable
>>> expectation IMHO), the dispatch for this ends up significantly different
>>> then any other dispatch function.
>>>
>>> This patch gets the job done, but I'm not really happy with how this
>>> patch turned out, suggestions for a better fix are welcome.
>>>
>>> Cc: Kyle Brenneman 
>>> Signed-off-by: Hans de Goede 
>>> ---
>>>  src/glx/g_glxglvnddispatchfuncs.c   | 18 ++
>>>  src/glx/g_glxglvnddispatchindices.h |  1 +
>>>  2 files changed, 19 insertions(+)
>>>
>>> diff --git a/src/glx/g_glxglvnddispatchfuncs.c
>>> b/src/glx/g_glxglvnddispatchfuncs.c
>>> index b5e3398..040cdf8 100644
>>> --- a/src/glx/g_glxglvnddispatchfuncs.c
>>> +++ b/src/glx/g_glxglvnddispatchfuncs.c
>>> @@ -4,6 +4,7 @@
>>>   */
>>>  #include 
>>>
>>> +#include "glxclient.h"
>>>  #include "glxglvnd.h"
>>>  #include "glxglvnddispatchfuncs.h"
>>>  #include "g_glxglvnddispatchindices.h"
>>> @@ -50,6 +51,7 @@ const char * const
>>> __glXDispatchTableStrings[DI_LAST_INDEX] = {
>>>  __ATTRIB(GetCurrentDisplayEXT),
>>>  // glXGetCurrentDrawable implemented by libglvnd
>>>  // glXGetCurrentReadDrawable implemented by libglvnd
>>> +__ATTRIB(GetDriverConfig),
>>
>>
>> Back in Nov 2016 we had a chat with Adam and if I understood things
>> correctly the idea was to kill off the following:
>>
>> glXGetScreenDriver
>> glXGetDriverConfig
>>
>> Neither of those is part of an extension and the only user xdriinfo,
>> is not that useful.
>> Would be great if distributions let it to rest and we don't have to
>> worry about it ever being around ;-)
>
>
> The problem is that driconf uses them and people actually use driconf,
> see: https://bugzilla.redhat.com/show_bug.cgi?id=1429894
>
Ouch, had not idea people are still using that behemoth :-(
In that case we cannot nuke the API, so let's merge this patch.

Small nit: please drop the compilation guard. Those should be always
true when compiling the file.

Kyle/others - the GLVND bits are in, aren't they? Do you have any
comments on the patch?

With that the nit
Reviewed-by: Emil Velikov 
Cc: mesa-sta...@lists.freedesktop.org

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

Re: [Mesa-dev] [PATCH 26/43] intel/blorp: Pull the pipeline bits of blorp_exec into a helper

[Pohjolainen, Topi]

On Tue, May 16, 2017 at 03:45:20PM -0700, Jason Ekstrand wrote:
> ---
>  src/intel/blorp/blorp_genX_exec.h | 56 
> ++-
>  1 file changed, 31 insertions(+), 25 deletions(-)
> 
> diff --git a/src/intel/blorp/blorp_genX_exec.h 
> b/src/intel/blorp/blorp_genX_exec.h
> index 9e61f69..0bb4b9a 100644
> --- a/src/intel/blorp/blorp_genX_exec.h
> +++ b/src/intel/blorp/blorp_genX_exec.h
> @@ -1316,33 +1316,14 @@ blorp_emit_viewport_state(struct blorp_batch *batch,
>  #endif
>  }
>  
> -
> -/**
> - * \brief Execute a blit or render pass operation.
> - *
> - * To execute the operation, this function manually constructs and emits a
> - * batch to draw a rectangle primitive. The batchbuffer is flushed before
> - * constructing and after emitting the batch.
> - *
> - * This function alters no GL state.
> - */
>  static void
> -blorp_exec(struct blorp_batch *batch, const struct blorp_params *params)
> +blorp_emit_pipeline(struct blorp_batch *batch,
> +const struct blorp_params *params)
>  {
> uint32_t blend_state_offset = 0;
> -   uint32_t color_calc_state_offset = 0;
> +   uint32_t color_calc_state_offset;
> uint32_t depth_stencil_state_offset;
>  
> -#if GEN_GEN >= 8
> -   if (params->hiz_op != BLORP_HIZ_OP_NONE) {
> -  blorp_emit_gen8_hiz_op(batch, params);
> -  return;
> -   }
> -#endif
> -
> -   blorp_emit_vertex_buffers(batch, params);
> -   blorp_emit_vertex_elements(batch, params);
> -
> emit_urb_config(batch, params);
>  
> if (params->wm_prog_data) {
> @@ -1351,7 +1332,7 @@ blorp_exec(struct blorp_batch *batch, const struct 
> blorp_params *params)
> color_calc_state_offset = blorp_emit_color_calc_state(batch, params);
> depth_stencil_state_offset = blorp_emit_depth_stencil_state(batch, 
> params);
>  
> -#if GEN_GEN <= 6
> +#if GEN_GEN == 6
> /* 3DSTATE_CC_STATE_POINTERS
>  *
>  * The pointer offsets are relative to
> @@ -1385,8 +1366,6 @@ blorp_exec(struct blorp_batch *batch, const struct 
> blorp_params *params)
> blorp_emit(batch, GENX(3DSTATE_CONSTANT_GS), gs);
> blorp_emit(batch, GENX(3DSTATE_CONSTANT_PS), ps);
>  
> -   blorp_emit_surface_states(batch, params);
> -
> if (params->src.enabled)
>blorp_emit_sampler_state(batch, params);
>  
> @@ -1423,6 +1402,33 @@ blorp_exec(struct blorp_batch *batch, const struct 
> blorp_params *params)
> blorp_emit_ps_config(batch, params);
>  
> blorp_emit_viewport_state(batch, params);
> +}
> +
> +/**
> + * \brief Execute a blit or render pass operation.
> + *
> + * To execute the operation, this function manually constructs and emits a
> + * batch to draw a rectangle primitive. The batchbuffer is flushed before
> + * constructing and after emitting the batch.
> + *
> + * This function alters no GL state.
> + */
> +static void
> +blorp_exec(struct blorp_batch *batch, const struct blorp_params *params)
> +{
> +#if GEN_GEN >= 8
> +   if (params->hiz_op != BLORP_HIZ_OP_NONE) {
> +  blorp_emit_gen8_hiz_op(batch, params);
> +  return;
> +   }
> +#endif
> +
> +   blorp_emit_vertex_buffers(batch, params);
> +   blorp_emit_vertex_elements(batch, params);
> +
> +   blorp_emit_pipeline(batch, params);
> +
> +   blorp_emit_surface_states(batch, params);

I thought binding table had to be earlier but I can't actually see any reason
why. Well, jenkins would scream if it had to be.

>  
> if (!(batch->flags & BLORP_BATCH_NO_EMIT_DEPTH_STENCIL))
>blorp_emit_depth_stencil_config(batch, params);
> -- 
> 2.5.0.400.gff86faf
> 
> ___
> 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] Revert "glsl: don't reference shader prog data during cache fallback"

[Nicolai Hähnle]

On 17.05.2017 14:26, Timothy Arceri wrote:

On 17/05/17 22:03, Nicolai Hähnle wrote:

On 17.05.2017 01:49, Timothy Arceri wrote:

This might work for gallium based drivers but I'm pretty sure this will
cause problems for the i965 fallback path.


What do those problems look like?


Sorry, I meant to add more details. The problem is that when the i965
driver has a cache miss for a variant this could be happening long after
link time. By this point we already have a reference and we also can't
just reallocate the shader data because uniforms etc have most likely
been set by this point.


Oh I see, thanks for the explanation.



And any ideas on how to address the issue then? There are a number of
places that assume prog->sh.data is non-NULL.


I'll need to take a closer look at the problem tomorrow. I'm not sure I
understand why it is NULL, I thought the reference happens in the GLSL
IR cache. Is it getting cleared somewhere by the tgsi pass?


As far as I understand, the gl_program object doesn't come from the 
cache in the fallback path. So the reference should happen in the place 
modified by this patch.


Cheers,
Nicolai





Cheers,
Nicolai




On 17/05/17 04:40, Nicolai Hähnle wrote:

From: Nicolai Hähnle 

This reverts commit 0e9991f957e296f46cfff40a94ffba0adf2a58e1.

At least when we fallback because of TGSI, the gl_program objects are
re-allocated, and we don't in fact already have a reference to the
gl_shader_program_data.

This fixes a crash that can be reproduced as follows:

1. Run any GL program with MESA_GLSL=cache_info.
2. Note the SHA of some tgsi_tokens.
3. Remove the corresponding file from ~/.cache/mesa and re-run.

Cc: 17.1 
---
  src/compiler/glsl/linker.cpp | 3 +--
  src/mesa/main/shaderobj.c| 3 +--
  2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/src/compiler/glsl/linker.cpp
b/src/compiler/glsl/linker.cpp
index 2e7dd2b..4776d09 100644
--- a/src/compiler/glsl/linker.cpp
+++ b/src/compiler/glsl/linker.cpp
@@ -2243,22 +2243,21 @@ link_intrastage_shaders(void *mem_ctx,
 struct gl_program *gl_prog =
ctx->Driver.NewProgram(ctx,

_mesa_shader_stage_to_program(shader_list[0]->Stage),
   prog->Name, false);
 if (!gl_prog) {
prog->data->LinkStatus = linking_failure;
_mesa_delete_linked_shader(ctx, linked);
return NULL;
 }
  -   if (!prog->data->cache_fallback)
-  _mesa_reference_shader_program_data(ctx, _prog->sh.data,
prog->data);
+   _mesa_reference_shader_program_data(ctx, _prog->sh.data,
prog->data);
   /* Don't use _mesa_reference_program() just take ownership */
 linked->Program = gl_prog;
   linked->ir = new(linked) exec_list;
 clone_ir_list(mem_ctx, linked->ir, main->ir);
   link_fs_inout_layout_qualifiers(prog, linked, shader_list,
num_shaders);
 link_tcs_out_layout_qualifiers(prog, gl_prog, shader_list,
num_shaders);
 link_tes_in_layout_qualifiers(prog, gl_prog, shader_list,
num_shaders);
diff --git a/src/mesa/main/shaderobj.c b/src/mesa/main/shaderobj.c
index 8a5fa5e..f6f7bf5 100644
--- a/src/mesa/main/shaderobj.c
+++ b/src/mesa/main/shaderobj.c
@@ -427,22 +427,21 @@ _mesa_free_shader_program_data(struct gl_context
*ctx,
  /**
   * Free/delete a shader program object.
   */
  void
  _mesa_delete_shader_program(struct gl_context *ctx,
  struct gl_shader_program *shProg)
  {
 _mesa_free_shader_program_data(ctx, shProg);
-   if (!shProg->data->cache_fallback)
-  _mesa_reference_shader_program_data(ctx, >data, NULL);
+   _mesa_reference_shader_program_data(ctx, >data, NULL);
 ralloc_free(shProg);
  }
  /**
   * Lookup a GLSL program object.
   */
  struct gl_shader_program *
  _mesa_lookup_shader_program(struct gl_context *ctx, GLuint name)
  {


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






--
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] Android: correct libz dependency

[Rob Herring]

On Wed, May 17, 2017 at 12:10 AM, Chih-Wei Huang
 wrote:
> Commit 6facb0c0 ("android: fix libz dynamic library dependencies")
> unconditionally adds libz as a dependency to all shared libraries.
> That is unnecessary.
>
> Commit 85a9b1b5 introduced libz as a dependency to libmesa_util.
> So only the shared libraries that use libmesa_util need libz.
>
> Fix Android Lollipop build by adding the include path of zlib to
> libmesa_util explicitly instead of getting the path implicitly
> from zlib since it doesn't export the include path in Lollipop.
>
> Fixes: 6facb0c0 "android: fix libz dynamic library dependencies"
>
> Signed-off-by: Chih-Wei Huang 
> ---
>  Android.common.mk  | 4 
>  src/gallium/targets/dri/Android.mk | 3 ++-
>  src/intel/Android.vulkan.mk| 2 +-
>  src/mesa/drivers/dri/Android.mk| 3 ++-
>  src/util/Android.mk| 1 +
>  5 files changed, 6 insertions(+), 7 deletions(-)

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

Re: [Mesa-dev] [PATCH 25/43] intel/blorp/blit: Add support for normalized coordinates

[Pohjolainen, Topi]

On Tue, May 16, 2017 at 03:45:19PM -0700, Jason Ekstrand wrote:
> Gen5 and earlier can't do non-normalized coordinates so we need to
> compensate in the shader.  Fortunately, it's pretty easy plumb through.
> ---
>  src/intel/blorp/blorp_blit.c | 27 ++-
>  src/intel/blorp/blorp_priv.h |  6 ++
>  2 files changed, 28 insertions(+), 5 deletions(-)
> 
> diff --git a/src/intel/blorp/blorp_blit.c b/src/intel/blorp/blorp_blit.c
> index 144bfb3..23e33de 100644
> --- a/src/intel/blorp/blorp_blit.c
> +++ b/src/intel/blorp/blorp_blit.c
> @@ -55,6 +55,7 @@ struct brw_blorp_blit_vars {
> nir_variable *v_src_z;
> nir_variable *v_src_offset;
> nir_variable *v_dst_offset;
> +   nir_variable *v_src_inv_size;
>  
> /* gl_FragCoord */
> nir_variable *frag_coord;
> @@ -79,6 +80,7 @@ brw_blorp_blit_vars_init(nir_builder *b, struct 
> brw_blorp_blit_vars *v,
> LOAD_INPUT(src_z, glsl_uint_type())
> LOAD_INPUT(src_offset, glsl_vector_type(GLSL_TYPE_UINT, 2))
> LOAD_INPUT(dst_offset, glsl_vector_type(GLSL_TYPE_UINT, 2))
> +   LOAD_INPUT(src_inv_size, glsl_vector_type(GLSL_TYPE_FLOAT, 2))
>  
>  #undef LOAD_INPUT
>  
> @@ -198,10 +200,15 @@ blorp_create_nir_tex_instr(nir_builder *b, struct 
> brw_blorp_blit_vars *v,
>  
>  static nir_ssa_def *
>  blorp_nir_tex(nir_builder *b, struct brw_blorp_blit_vars *v,
> -  nir_ssa_def *pos, nir_alu_type dst_type)
> +  const struct brw_blorp_blit_prog_key *key, nir_ssa_def *pos)
>  {
> +   /* If the sampler requires normalized coordinates, we need to compensate. 
> */
> +   if (key->src_coords_normalized)
> +  pos = nir_fmul(b, pos, nir_load_var(b, v->v_src_inv_size));
> +
> nir_tex_instr *tex =
> -  blorp_create_nir_tex_instr(b, v, nir_texop_tex, pos, 2, dst_type);
> +  blorp_create_nir_tex_instr(b, v, nir_texop_tex, pos, 2,
> + key->texture_data_type);
>  
> assert(pos->num_components == 2);
> tex->sampler_dim = GLSL_SAMPLER_DIM_2D;
> @@ -1188,7 +1195,7 @@ brw_blorp_build_nir_shader(struct blorp_context *blorp, 
> void *mem_ctx,
>   src_pos = nir_ishl(, src_pos, nir_imm_int(, 1));
>   src_pos = nir_iadd(, src_pos, nir_imm_int(, 1));
>   src_pos = nir_i2f32(, src_pos);
> - color = blorp_nir_tex(, , src_pos, key->texture_data_type);
> + color = blorp_nir_tex(, , key, src_pos);
>} else {
>   /* Gen7+ hardware doesn't automaticaly blend. */
>   color = blorp_nir_manual_blend_average(, , src_pos, 
> key->src_samples,
> @@ -1200,7 +1207,7 @@ brw_blorp_build_nir_shader(struct blorp_context *blorp, 
> void *mem_ctx,
>color = blorp_nir_manual_blend_bilinear(, src_pos, key->src_samples, 
> key, );
> } else {
>if (key->bilinear_filter) {
> - color = blorp_nir_tex(, , src_pos, key->texture_data_type);
> + color = blorp_nir_tex(, , key, src_pos);
>} else {
>   /* We're going to use texelFetch, so we need integers */
>   if (src_pos->num_components == 2) {
> @@ -2056,9 +2063,19 @@ blorp_blit(struct blorp_batch *batch,
> wm_prog_key.y_scale = params.src.surf.samples / wm_prog_key.x_scale;
>  
> if (filter == GL_LINEAR &&
> -   params.src.surf.samples <= 1 && params.dst.surf.samples <= 1)
> +   params.src.surf.samples <= 1 && params.dst.surf.samples <= 1) {
>wm_prog_key.bilinear_filter = true;
>  
> +  if (batch->blorp->isl_dev->info->gen < 6) {
> + /* Gen4-5 don't support non-normalized texture coordinates */
> + wm_prog_key.src_coords_normalized = true;
> + params.wm_inputs.src_inv_size[0] =
> +1.0f / minify(params.src.surf.logical_level0_px.width, 
> src_level);
> + params.wm_inputs.src_inv_size[1] =
> +1.0f / minify(params.src.surf.logical_level0_px.height, 
> src_level);
> +  }
> +   }
> +
> if ((params.src.surf.usage & ISL_SURF_USAGE_DEPTH_BIT) == 0 &&
> (params.src.surf.usage & ISL_SURF_USAGE_STENCIL_BIT) == 0 &&
> !isl_format_has_int_channel(params.src.surf.format) &&
> diff --git a/src/intel/blorp/blorp_priv.h b/src/intel/blorp/blorp_priv.h
> index c61ab08..39da5af 100644
> --- a/src/intel/blorp/blorp_priv.h
> +++ b/src/intel/blorp/blorp_priv.h
> @@ -124,6 +124,9 @@ struct brw_blorp_wm_inputs
> struct blorp_surf_offset src_offset;
> struct blorp_surf_offset dst_offset;
>  
> +   /* (1/width, 1/height) for the source surface */
> +   float src_inv_size[2];
> +

There is still the "pad[1]" in the end which I think is now correct, before
it should have been "pad[3]", right? It aligns to vec4. Do we really need
that anymore...

> /* Minimum layer setting works for all the textures types but texture_3d
>  * for which the setting has no effect. Use the z-coordinate instead.
>  */
> @@ -228,6 +231,9 @@ struct brw_blorp_blit_prog_key
> /* Number of bits per channel in the source image. */
> uint8_t src_bpc;
>  
> 

Re: [Mesa-dev] [PATCH] Revert "glsl: don't reference shader prog data during cache fallback"

[Timothy Arceri]

On 17/05/17 22:03, Nicolai Hähnle wrote:

On 17.05.2017 01:49, Timothy Arceri wrote:

This might work for gallium based drivers but I'm pretty sure this will
cause problems for the i965 fallback path.


What do those problems look like?


Sorry, I meant to add more details. The problem is that when the i965 
driver has a cache miss for a variant this could be happening long after 
link time. By this point we already have a reference and we also can't 
just reallocate the shader data because uniforms etc have most likely 
been set by this point.


And any ideas on how to address the 
issue then? There are a number of places that assume prog->sh.data is 
non-NULL.


I'll need to take a closer look at the problem tomorrow. I'm not sure I 
understand why it is NULL, I thought the reference happens in the GLSL 
IR cache. Is it getting cleared somewhere by the tgsi pass?




Cheers,
Nicolai




On 17/05/17 04:40, Nicolai Hähnle wrote:

From: Nicolai Hähnle 

This reverts commit 0e9991f957e296f46cfff40a94ffba0adf2a58e1.

At least when we fallback because of TGSI, the gl_program objects are
re-allocated, and we don't in fact already have a reference to the
gl_shader_program_data.

This fixes a crash that can be reproduced as follows:

1. Run any GL program with MESA_GLSL=cache_info.
2. Note the SHA of some tgsi_tokens.
3. Remove the corresponding file from ~/.cache/mesa and re-run.

Cc: 17.1 
---
  src/compiler/glsl/linker.cpp | 3 +--
  src/mesa/main/shaderobj.c| 3 +--
  2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/src/compiler/glsl/linker.cpp b/src/compiler/glsl/linker.cpp
index 2e7dd2b..4776d09 100644
--- a/src/compiler/glsl/linker.cpp
+++ b/src/compiler/glsl/linker.cpp
@@ -2243,22 +2243,21 @@ link_intrastage_shaders(void *mem_ctx,
 struct gl_program *gl_prog =
ctx->Driver.NewProgram(ctx,

_mesa_shader_stage_to_program(shader_list[0]->Stage),
   prog->Name, false);
 if (!gl_prog) {
prog->data->LinkStatus = linking_failure;
_mesa_delete_linked_shader(ctx, linked);
return NULL;
 }
  -   if (!prog->data->cache_fallback)
-  _mesa_reference_shader_program_data(ctx, _prog->sh.data,
prog->data);
+   _mesa_reference_shader_program_data(ctx, _prog->sh.data,
prog->data);
   /* Don't use _mesa_reference_program() just take ownership */
 linked->Program = gl_prog;
   linked->ir = new(linked) exec_list;
 clone_ir_list(mem_ctx, linked->ir, main->ir);
   link_fs_inout_layout_qualifiers(prog, linked, shader_list,
num_shaders);
 link_tcs_out_layout_qualifiers(prog, gl_prog, shader_list,
num_shaders);
 link_tes_in_layout_qualifiers(prog, gl_prog, shader_list,
num_shaders);
diff --git a/src/mesa/main/shaderobj.c b/src/mesa/main/shaderobj.c
index 8a5fa5e..f6f7bf5 100644
--- a/src/mesa/main/shaderobj.c
+++ b/src/mesa/main/shaderobj.c
@@ -427,22 +427,21 @@ _mesa_free_shader_program_data(struct gl_context
*ctx,
  /**
   * Free/delete a shader program object.
   */
  void
  _mesa_delete_shader_program(struct gl_context *ctx,
  struct gl_shader_program *shProg)
  {
 _mesa_free_shader_program_data(ctx, shProg);
-   if (!shProg->data->cache_fallback)
-  _mesa_reference_shader_program_data(ctx, >data, NULL);
+   _mesa_reference_shader_program_data(ctx, >data, NULL);
 ralloc_free(shProg);
  }
  /**
   * Lookup a GLSL program object.
   */
  struct gl_shader_program *
  _mesa_lookup_shader_program(struct gl_context *ctx, GLuint name)
  {


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




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

[Mesa-dev] [Bug 101071] compiling glsl fails with undefined reference to `pthread_create'

[bugzilla-daemon]

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

--- Comment #1 from Emil Velikov  ---
Seems like the cross-compiled libstdc++.so is missing the pthread symbol.
Something like the following will help you check if that's the case.

1) setup your platforms so the custom DSO's are detected. For example
$export LD_LIBRARY_PATH=/home/piotro/minimyth-dev/images/build/usr/lib/...
2) using the correct ldd issue:
$ldd -r
/home/piotro/minimyth-dev/images/build/usr/lib/gcc/x86_64-minimyth-linux-gnu/5.3.0/libstdc++.so

If you see "undefined symbol: ..." then something's funny in your setup.

Can you check with the libstdc++.so authors that they use "-no-undefined
-Wl,--no-undefined" to the LDFLAGS. It will flag issues as the binary is
linked.

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

Re: [Mesa-dev] [PATCH 2/3] tgsi: store the sampler view type directly in the instruction

[Samuel Pitoiset]

On 05/17/2017 02:02 PM, Nicolai Hähnle wrote:

On 17.05.2017 11:17, Samuel Pitoiset wrote:

RadeonSI needs to do a special lowering for Gather4 with integer
formats, but with bindless samplers we just can't access the index.

Instead, store the return type in the instruction like the target.

Signed-off-by: Samuel Pitoiset 
---
 src/gallium/auxiliary/tgsi/tgsi_ureg.c |  7 +--
 src/gallium/auxiliary/tgsi/tgsi_ureg.h | 11 ---
 src/gallium/include/pipe/p_shader_tokens.h |  2 ++
 src/mesa/state_tracker/st_atifs_to_tgsi.c  |  2 +-
 src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 17 ++---
 src/mesa/state_tracker/st_mesa_to_tgsi.c   | 21 +
 src/mesa/state_tracker/st_mesa_to_tgsi.h   |  4 
 7 files changed, 43 insertions(+), 21 deletions(-)

diff --git a/src/gallium/auxiliary/tgsi/tgsi_ureg.c 
b/src/gallium/auxiliary/tgsi/tgsi_ureg.c

index 9eb00d0919..1cdb95cc95 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_ureg.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_ureg.c
@@ -1289,7 +1289,7 @@ ureg_fixup_label(struct ureg_program *ureg,
 void
 ureg_emit_texture(struct ureg_program *ureg,
   unsigned extended_token,
-  unsigned target, unsigned num_offsets)
+  unsigned target, unsigned return_type, unsigned 
num_offsets)

 {
union tgsi_any_token *out, *insn;

@@ -1300,6 +1300,7 @@ ureg_emit_texture(struct ureg_program *ureg,

out[0].value = 0;
out[0].insn_texture.Texture = target;
+   out[0].insn_texture.ReturnType = return_type;
out[0].insn_texture.NumOffsets = num_offsets;
 }

@@ -1386,6 +1387,7 @@ ureg_tex_insn(struct ureg_program *ureg,
   const struct ureg_dst *dst,
   unsigned nr_dst,
   unsigned target,
+  unsigned return_type,
   const struct tgsi_texture_offset *texoffsets,
   unsigned nr_offset,
   const struct ureg_src *src,
@@ -1407,7 +1409,8 @@ ureg_tex_insn(struct ureg_program *ureg,
  nr_dst,
  nr_src);

-   ureg_emit_texture( ureg, insn.extended_token, target, nr_offset );
+   ureg_emit_texture( ureg, insn.extended_token, target, return_type,
+  nr_offset );

for (i = 0; i < nr_offset; i++)
   ureg_emit_texture_offset( ureg, [i]);
diff --git a/src/gallium/auxiliary/tgsi/tgsi_ureg.h 
b/src/gallium/auxiliary/tgsi/tgsi_ureg.h

index 6d2f5c0e99..54f95ba565 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_ureg.h
+++ b/src/gallium/auxiliary/tgsi/tgsi_ureg.h
@@ -555,6 +555,7 @@ ureg_tex_insn(struct ureg_program *ureg,
   const struct ureg_dst *dst,
   unsigned nr_dst,
   unsigned target,
+  unsigned return_type,
   const struct tgsi_texture_offset *texoffsets,
   unsigned nr_offset,
   const struct ureg_src *src,
@@ -596,7 +597,7 @@ ureg_emit_label(struct ureg_program *ureg,
 void
 ureg_emit_texture(struct ureg_program *ureg,
   unsigned insn_token,
-  unsigned target, unsigned num_offsets);
+  unsigned target, unsigned return_type, unsigned 
num_offsets);


 void
 ureg_emit_texture_offset(struct ureg_program *ureg,
@@ -748,6 +749,7 @@ static inline void ureg_##op( struct ureg_program 
*ureg,\
   struct ureg_src src1 
)\
 {   
\
unsigned opcode = 
TGSI_OPCODE_##op;  \
+   unsigned return_type = 
TGSI_RETURN_TYPE_UNKNOWN; \
struct ureg_emit_insn_result 
insn;   \
if 
(ureg_dst_is_empty(dst))  \
   
return;   \
@@ -756,7 +758,8 @@ static inline void ureg_##op( struct ureg_program 
*ureg,\
  
dst.Saturate,  \
  
1, \
  
2);\

-   ureg_emit_texture( ureg, insn.extended_token, target, 0 );\
+   ureg_emit_texture( ureg, insn.extended_token, 
target,\
+  return_type, 0 
); \
ureg_emit_dst( ureg, dst 
);  \
ureg_emit_src( ureg, src0 
); \
ureg_emit_src( ureg, src1 
); \
@@ -796,6 +799,7 @@ static inline void ureg_##op( struct ureg_program 
*ureg,\
   struct ureg_src src3 
)\
 {   
\
unsigned opcode = 
TGSI_OPCODE_##op;

Re: [Mesa-dev] [PATCH] Revert "glsl: don't reference shader prog data during cache fallback"

[Nicolai Hähnle]

On 17.05.2017 01:49, Timothy Arceri wrote:

This might work for gallium based drivers but I'm pretty sure this will
cause problems for the i965 fallback path.


What do those problems look like? And any ideas on how to address the 
issue then? There are a number of places that assume prog->sh.data is 
non-NULL.


Cheers,
Nicolai




On 17/05/17 04:40, Nicolai Hähnle wrote:

From: Nicolai Hähnle 

This reverts commit 0e9991f957e296f46cfff40a94ffba0adf2a58e1.

At least when we fallback because of TGSI, the gl_program objects are
re-allocated, and we don't in fact already have a reference to the
gl_shader_program_data.

This fixes a crash that can be reproduced as follows:

1. Run any GL program with MESA_GLSL=cache_info.
2. Note the SHA of some tgsi_tokens.
3. Remove the corresponding file from ~/.cache/mesa and re-run.

Cc: 17.1 
---
  src/compiler/glsl/linker.cpp | 3 +--
  src/mesa/main/shaderobj.c| 3 +--
  2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/src/compiler/glsl/linker.cpp b/src/compiler/glsl/linker.cpp
index 2e7dd2b..4776d09 100644
--- a/src/compiler/glsl/linker.cpp
+++ b/src/compiler/glsl/linker.cpp
@@ -2243,22 +2243,21 @@ link_intrastage_shaders(void *mem_ctx,
 struct gl_program *gl_prog =
ctx->Driver.NewProgram(ctx,

_mesa_shader_stage_to_program(shader_list[0]->Stage),
   prog->Name, false);
 if (!gl_prog) {
prog->data->LinkStatus = linking_failure;
_mesa_delete_linked_shader(ctx, linked);
return NULL;
 }
  -   if (!prog->data->cache_fallback)
-  _mesa_reference_shader_program_data(ctx, _prog->sh.data,
prog->data);
+   _mesa_reference_shader_program_data(ctx, _prog->sh.data,
prog->data);
   /* Don't use _mesa_reference_program() just take ownership */
 linked->Program = gl_prog;
   linked->ir = new(linked) exec_list;
 clone_ir_list(mem_ctx, linked->ir, main->ir);
   link_fs_inout_layout_qualifiers(prog, linked, shader_list,
num_shaders);
 link_tcs_out_layout_qualifiers(prog, gl_prog, shader_list,
num_shaders);
 link_tes_in_layout_qualifiers(prog, gl_prog, shader_list,
num_shaders);
diff --git a/src/mesa/main/shaderobj.c b/src/mesa/main/shaderobj.c
index 8a5fa5e..f6f7bf5 100644
--- a/src/mesa/main/shaderobj.c
+++ b/src/mesa/main/shaderobj.c
@@ -427,22 +427,21 @@ _mesa_free_shader_program_data(struct gl_context
*ctx,
  /**
   * Free/delete a shader program object.
   */
  void
  _mesa_delete_shader_program(struct gl_context *ctx,
  struct gl_shader_program *shProg)
  {
 _mesa_free_shader_program_data(ctx, shProg);
-   if (!shProg->data->cache_fallback)
-  _mesa_reference_shader_program_data(ctx, >data, NULL);
+   _mesa_reference_shader_program_data(ctx, >data, NULL);
 ralloc_free(shProg);
  }
  /**
   * Lookup a GLSL program object.
   */
  struct gl_shader_program *
  _mesa_lookup_shader_program(struct gl_context *ctx, GLuint name)
  {


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



--
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/3] tgsi: store the sampler view type directly in the instruction

[Nicolai Hähnle]

On 17.05.2017 11:17, Samuel Pitoiset wrote:

RadeonSI needs to do a special lowering for Gather4 with integer
formats, but with bindless samplers we just can't access the index.

Instead, store the return type in the instruction like the target.

Signed-off-by: Samuel Pitoiset 
---
 src/gallium/auxiliary/tgsi/tgsi_ureg.c |  7 +--
 src/gallium/auxiliary/tgsi/tgsi_ureg.h | 11 ---
 src/gallium/include/pipe/p_shader_tokens.h |  2 ++
 src/mesa/state_tracker/st_atifs_to_tgsi.c  |  2 +-
 src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 17 ++---
 src/mesa/state_tracker/st_mesa_to_tgsi.c   | 21 +
 src/mesa/state_tracker/st_mesa_to_tgsi.h   |  4 
 7 files changed, 43 insertions(+), 21 deletions(-)

diff --git a/src/gallium/auxiliary/tgsi/tgsi_ureg.c 
b/src/gallium/auxiliary/tgsi/tgsi_ureg.c
index 9eb00d0919..1cdb95cc95 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_ureg.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_ureg.c
@@ -1289,7 +1289,7 @@ ureg_fixup_label(struct ureg_program *ureg,
 void
 ureg_emit_texture(struct ureg_program *ureg,
   unsigned extended_token,
-  unsigned target, unsigned num_offsets)
+  unsigned target, unsigned return_type, unsigned num_offsets)
 {
union tgsi_any_token *out, *insn;

@@ -1300,6 +1300,7 @@ ureg_emit_texture(struct ureg_program *ureg,

out[0].value = 0;
out[0].insn_texture.Texture = target;
+   out[0].insn_texture.ReturnType = return_type;
out[0].insn_texture.NumOffsets = num_offsets;
 }

@@ -1386,6 +1387,7 @@ ureg_tex_insn(struct ureg_program *ureg,
   const struct ureg_dst *dst,
   unsigned nr_dst,
   unsigned target,
+  unsigned return_type,
   const struct tgsi_texture_offset *texoffsets,
   unsigned nr_offset,
   const struct ureg_src *src,
@@ -1407,7 +1409,8 @@ ureg_tex_insn(struct ureg_program *ureg,
  nr_dst,
  nr_src);

-   ureg_emit_texture( ureg, insn.extended_token, target, nr_offset );
+   ureg_emit_texture( ureg, insn.extended_token, target, return_type,
+  nr_offset );

for (i = 0; i < nr_offset; i++)
   ureg_emit_texture_offset( ureg, [i]);
diff --git a/src/gallium/auxiliary/tgsi/tgsi_ureg.h 
b/src/gallium/auxiliary/tgsi/tgsi_ureg.h
index 6d2f5c0e99..54f95ba565 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_ureg.h
+++ b/src/gallium/auxiliary/tgsi/tgsi_ureg.h
@@ -555,6 +555,7 @@ ureg_tex_insn(struct ureg_program *ureg,
   const struct ureg_dst *dst,
   unsigned nr_dst,
   unsigned target,
+  unsigned return_type,
   const struct tgsi_texture_offset *texoffsets,
   unsigned nr_offset,
   const struct ureg_src *src,
@@ -596,7 +597,7 @@ ureg_emit_label(struct ureg_program *ureg,
 void
 ureg_emit_texture(struct ureg_program *ureg,
   unsigned insn_token,
-  unsigned target, unsigned num_offsets);
+  unsigned target, unsigned return_type, unsigned num_offsets);

 void
 ureg_emit_texture_offset(struct ureg_program *ureg,
@@ -748,6 +749,7 @@ static inline void ureg_##op( struct ureg_program *ureg,
\
   struct ureg_src src1 )\
 {   \
unsigned opcode = TGSI_OPCODE_##op;  \
+   unsigned return_type = TGSI_RETURN_TYPE_UNKNOWN; \
struct ureg_emit_insn_result insn;   \
if (ureg_dst_is_empty(dst))  \
   return;   \
@@ -756,7 +758,8 @@ static inline void ureg_##op( struct ureg_program *ureg,
\
  dst.Saturate,  \
  1, \
  2);\
-   ureg_emit_texture( ureg, insn.extended_token, target, 0 );  \
+   ureg_emit_texture( ureg, insn.extended_token, target,\
+  return_type, 0 ); \
ureg_emit_dst( ureg, dst );  \
ureg_emit_src( ureg, src0 ); \
ureg_emit_src( ureg, src1 ); \
@@ -796,6 +799,7 @@ static inline void ureg_##op( struct ureg_program *ureg,
\
   struct ureg_src src3 )\
 {   \
unsigned opcode = TGSI_OPCODE_##op;  \
+   unsigned return_type = TGSI_RETURN_TYPE_UNKNOWN;

Re: [Mesa-dev] [PATCH] mesa: Allow MESA_FORMAT_LAYOUT_S3TC in non-desktop mesa

[Tapani Pälli]

On 05/17/2017 12:05 PM, Tapani Pälli wrote:



On 05/17/2017 11:49 AM, Gao, Chun wrote:
Thanks for your comments. Are we working on GL_EXT_sRGB, or is there 
any plan for that?


There has been work done to enable it:

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

I believe Harish has been fixing some of the faults, work is still ongoing.


although yeah now when reading the spec, it's not going to solve this 
one, it says:


--- 8< ---

3) Should we allow the SRGB_*_S3TC_DXT* or any of the other COMPRESSED 
formats if the implementation supports any of those formats?


No since all hardware doesn't support this.  It can be added as a 
separate extension if needed.

--- 8< ---

so ... ATM I'm not sure what the correct solution here is.





-Original Message-
From: Palli, Tapani
Sent: Wednesday, May 17, 2017 4:35 PM
To: Gao, Chun ; mesa-dev@lists.freedesktop.org
Subject: Re: [Mesa-dev] [PATCH] mesa: Allow MESA_FORMAT_LAYOUT_S3TC in 
non-desktop mesa




On 05/17/2017 11:09 AM, Gao, Chun wrote:

I know EXT_texture_sRGB  is desktop OpenGL extension.
On Android-IA and ChromeOS ARC++, the game 
https://play.google.com/store/apps/details?id=com.eline.neveralonemobile 
could not display some texture correctly. I found the following 
formats which the game uses were blocked in 
_mesa_is_compressed_format():

GL_COMPRESSED_SRGB_ALPHA_S3TC_DXT5_EXT
GL_COMPRESSED_SRGB_S3TC_DXT1_EXT
GL_COMPRESSED_RGBA_S3TC_DXT5_EXT
GL_COMPRESSED_RGB_S3TC_DXT1_EXT

After removing _mesa_is_desktop_gl(ctx), the issue get fixed. I don't 
know why the android game uses desktop OpenGL formats 
GL_COMPRESSED_SRGB_ALPHA_S3TC_DXT5_EXT and 
GL_COMPRESSED_SRGB_S3TC_DXT1_EXT.  To make it work, I removed the 
desktop check.


OK, this is useful information and means that the game has a bug.

If I understand requirements correctly here if/when GL_EXT_sRGB 
extension support is added, then this game should start to work OK.





-Original Message-
From: Palli, Tapani
Sent: Wednesday, May 17, 2017 3:36 PM
To: Gao, Chun ; mesa-dev@lists.freedesktop.org
Subject: Re: [Mesa-dev] [PATCH] mesa: Allow MESA_FORMAT_LAYOUT_S3TC 
in non-desktop mesa


IMO this is not correct. Are you having problems with some application?

For Android games Mesa should already return true for the previous check
(ANGLE_texture_compression_dxt) and things should work OK. The check 
you are touching is desktop specific because EXT_texture_sRGB is 
available only on desktop GL (closest gles equivalent being 
GL_EXT_sRGB which we don't support).



On 05/17/2017 10:22 AM, Gao Chun wrote:

As s3tc formats are used in many Android games, desktop mesa check
should be removed for MESA_FORMAT_LAYOUT_S3TC.
---
src/mesa/main/glformats.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/mesa/main/glformats.c b/src/mesa/main/glformats.c
index 4f240206ff45..e4f283c4dfa8 100644
--- a/src/mesa/main/glformats.c
+++ b/src/mesa/main/glformats.c
@@ -1376,8 +1376,7 @@ _mesa_is_compressed_format(const struct 
gl_context *ctx, GLenum format)

  */
 return ctx->Extensions.ANGLE_texture_compression_dxt;
  } else {
- return _mesa_is_desktop_gl(ctx)
-&& ctx->Extensions.EXT_texture_sRGB
+ return ctx->Extensions.EXT_texture_sRGB
&& ctx->Extensions.EXT_texture_compression_s3tc;
  }
   case MESA_FORMAT_LAYOUT_FXT1:


___
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