Re: [Mesa-dev] [RFC PATCH] gallium: add interface for advanced MSAA

[Marek Olšák]

It was marketed that way because D3D didn't have API to do anything else.

In practice, EQAA can do arbitrary color coverage, color storage, and Z/S
sample counts, and each color render target can have different values too.
So everything is allowed, but the combinations that don't make sense only
waste memory and do useless work that is not stored.

The configs with the best quality/performance tradeoff are "8 >= color
coverage samples == Z/S samples >= color storage samples" (the upper limit
is for AMD). Having maximum Z/S samples doesn't decrease performance in
some cases due to internal GPU optimizations, so it's better to keep them
for quality.

The full range of configs that don't waste memory and don't do useless work
(i.e. they can be useful) is "16 >= color coverage samples >= Z/S samples
>= color storage samples". The color coverage is the only one that can have
16 samples. Z/S has to have 8 or less. Z/S can sometimes have higher
quality than allocated due to Z/S compression, but front-to-back rendering
quality drops to the allocated Z/S sample count when Z/S doesn't compress
well. The Z/S hw can run at color coverage sample rate regardless of
allocated Z/S samples.

color storage samples == 1 may also be useful if the resolve shader is
implemented well, but it starts to compete with MLAA. I still prefer to
have the maximum Z/S sample count here as dictated by the first equation
above.

Marek


On Mon, May 21, 2018 at 9:14 PM, Roland Scheidegger 
wrote:

> I was under the (apparently wrong) impression EQAA always worked like
> that too.
> Even AMD's marketing said EQAA has the same number of
> stencil/depth/color samples as regular MSAA (when the feature was new,
> HD 6900,
> https://developer.amd.com/wordpress/media/2012/10/EQAA%
> 2520Modes%2520for%2520AMD%2520HD%25206900%2520Series%2520Cards.pdf).
> As well as every article I've seen on that subject...
> So I believe the EQAA options available with windows never use more
> depth storage samples than color storage samples.
> And both CSAA and EQAA were generally met with lukewarm reception - as
> you noted, for front to back rendering it's useless.
> I'll agree that in theory having more depth samples sounds quite useful,
> but maybe in practice the cost is too high (EQAA as well as CSAA were
> marketed as nearly free compared to the MSAA modes with the same number
> of depth/stencil/color samples, I could imagine if you use the same
> number of depth storage samples as coverage samples the cost could
> approach closer to a MSAA mode which just has the higher number of
> samples for color too, but I guess it would depend on the number and
> type of color buffers).
>
> Roland
>
>
>
> Am 22.05.2018 um 02:46 schrieb Marek Olšák:
> > Your understanding is correct. I misunderstood CSAA. So it looks like
> > that CSAA is more useless than I thought. You get the coverage-samples
> > level of quality for back-to-front rendering, but you may get the
> > depth-samples level of quality for front-to-back rendering, because
> > "edges" generated by depth test failures have the same quality as the
> > number of depth samples (if depth values are uncompressed). AMD supports
> > that mode too, but I don't recommend using it because of the possible
> > decrease in front-to-back rendering quality.
> >
> > The way the CAP is defined doesn't actually allow NV's implementation of
> > CSAA. A new CAP would be needed.
> >
> > We'll add a new GL extension for advanced MSAA. The NV extension is
> > unusable, because it changes GL behavior in a non-backward-compatible
> > way by allowing storage_samples = 2 for all renderbuffers (which is
> > cheating, but not surprising from NV).
> >
> > Marek
> >
> > On Mon, May 21, 2018 at 12:55 PM, Axel Davy  > > wrote:
> >
> > Hi,
> >
> > I get the impression when looking at online documentation about EQAA
> > and CSAA, like
> > http://www.nvidia.fr/object/coverage-sampled-aa.html
> >  3A__www.nvidia.fr_object_coverage-2Dsampled-2Daa.html&d=DwMFaQ&c=
> uilaK90D4TOVoH58JNXRgQ&r=_QIjpv-UJ77xEQY8fIYoQtr5qv8wKrPJc7v7_
> -CYAb0&m=mT5z2nGhAlFu_lLjhtTx-Gb1xMAX_goZ2-tp5FknDXU&s=lTxXM-
> R2kvTIBzi4Wjjl8uT7R88UhQgdvkIHJLVaQsQ&e=>
> >
> > that the number of stored samples is the same for the color and
> > depth buffers.
> > Only the samples used for coverage is greater.
> >
> > With your proposal, isn't the number of samples stored in the depth
> > buffer always the same than the number of samples used for coverage ?
> > That reduces the use-cases. In nine, we have to enforce the number
> > of stored samples to be the same for the color and the depth buffer,
> > but we could increase the number of samples used for coverage and
> > enable EQAA/CSAA (in fact there is a similar way to advertise the
> > feature for Nvidia and Amd).
> >
> > But maybe I misunderstood.
> >
> > Yours,
> >
> > Axel Davy

Re: [Mesa-dev] [ANNOUNCE] mesa 18.1.0

[Stuart Young]

Appears that while the release notes for 18.1.0 are actually up on the
website[1], the News[2] column on the main website didn't get updated, as
18.1.0 isn't listed there.


1. https://www.mesa3d.org/relnotes/18.1.0.html
2. https://www.mesa3d.org/index.html


On 19 May 2018 at 09:43,  wrote:

> Mesa 18.1.0 is now available.
>
> Here is a short list of notable features compared to 18.0
>  - OpenGL 3.1 with ARB_compatibility on nv50, nvc0, r600, radeonsi,
> softpipe, llvmpipe, svga
>  - GL_ARB_bindless_texture on nvc0/maxwell+
>  - GL_ARB_transform_feedback_overflow_query on nvc0
>  - GL_EXT_semaphore on radeonsi
>  - GL_EXT_semaphore_fd on radeonsi
>  - GL_EXT_shader_framebuffer_fetch on i965 on desktop GL (GLES was
> already supported)
>  - GL_EXT_shader_framebuffer_fetch_non_coherent on i965
>  - GL_KHR_blend_equation_advanced on radeonsi
>  - Disk shader cache support for i965 enabled by default
>
> git tag: mesa-18.1.0
>
> https://mesa.freedesktop.org/archive/mesa-18.1.0.tar.gz
> MD5:  45e5f4ae434f8e28e11838f6f4de9e32  mesa-18.1.0.tar.gz
> SHA1: afaa43310b58154e2fcbc62b5f2b9e30e3cc16ca  mesa-18.1.0.tar.gz
> SHA256: b1c1dbb42597190503d3abc518b12de880623f097c6cb6c293ecf69ae87e6fbf
> mesa-18.1.0.tar.gz
> SHA512: 409ba9fc3cfe3668d82e3026d3d12b4ac816bd2732cc1f87302249142530
> 2475ab24a1e19963e1a80dadfadab8e341e71b0ed8c3acc87950378e86ea2e14bbf1
> mesa-18.1.0.tar.gz
> PGP:  https://mesa.freedesktop.org/archive/mesa-18.1.0.tar.gz.sig
>
> https://mesa.freedesktop.org/archive/mesa-18.1.0.tar.xz
> MD5:  5f4b0d414f2fcef927e465315eb6aa45  mesa-18.1.0.tar.xz
> SHA1: 3da4b5f4ae3705c017a8f988f1304be45eed875f  mesa-18.1.0.tar.xz
> SHA256: c855c5b67ef993b7621f76d8b120769ec0415f1c3616eaff44ef7f7f300aceba
> mesa-18.1.0.tar.xz
> SHA512: 8b26af2df8b94373cbc339521974cd568c1d4ff4204986ee7b439e4cf3eb
> e14d822ea081a7769b68eca9263b7bc6dbca01836b8bb0d6495d2e2614c4e3d601ad
> mesa-18.1.0.tar.xz
> PGP:  https://mesa.freedesktop.org/archive/mesa-18.1.0.tar.xz.sig
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>


-- 
Stuart Young (aka Cefiar)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] llvmpipe: improve rasterization discard logic

[Brian Paul]

On 05/21/2018 07:34 PM, srol...@vmware.com wrote:

From: Roland Scheidegger 

This unifies the explicit rasterization dicard as well as the implicit


"discard"

Looks OK to me.  Minor nits below.

Reviewed-by: Brian Paul 



rasterization disabled logic (which we need for another state tracker),
which really should do the exact same thing.
We'll now toss out the prims early on in setup with (implicit or
explicit) discard, rather than do setup and binning with them, which
was entirely pointless.
(We should eventually get rid of implicit discard, which should also
enable us to discard stuff already in draw, hence draw would be
able to skip the pointless clip and fallback stages in this case.)
We still need separate logic for only null ps - this is not the same
as rasterization discard. But simplify the logic there and don't count
primitives simply when there's an empty fs, regardless of depth/stencil
tests, which seems perfectly acceptable by d3d10.
While here, also fix statistics for primitives if face culling is
enabled.
No piglit changes.
---
  src/gallium/drivers/llvmpipe/lp_context.h   |  1 -
  src/gallium/drivers/llvmpipe/lp_jit.c   |  1 +
  src/gallium/drivers/llvmpipe/lp_jit.h   |  5 +++
  src/gallium/drivers/llvmpipe/lp_rast.c  | 12 +++-
  src/gallium/drivers/llvmpipe/lp_rast_priv.h |  6 
  src/gallium/drivers/llvmpipe/lp_scene.c |  5 ++-
  src/gallium/drivers/llvmpipe/lp_scene.h | 10 +++---
  src/gallium/drivers/llvmpipe/lp_setup.c | 18 ++-
  src/gallium/drivers/llvmpipe/lp_setup_line.c| 27 ++--
  src/gallium/drivers/llvmpipe/lp_setup_point.c   | 21 +
  src/gallium/drivers/llvmpipe/lp_setup_tri.c | 29 -
  src/gallium/drivers/llvmpipe/lp_setup_vbuf.c|  2 +-
  src/gallium/drivers/llvmpipe/lp_state_derived.c | 22 ++---
  src/gallium/drivers/llvmpipe/lp_state_fs.c  | 41 -
  src/gallium/drivers/llvmpipe/lp_state_fs.h  |  5 ---
  15 files changed, 118 insertions(+), 87 deletions(-)

diff --git a/src/gallium/drivers/llvmpipe/lp_context.h 
b/src/gallium/drivers/llvmpipe/lp_context.h
index 54d98fd..7a2f253 100644
--- a/src/gallium/drivers/llvmpipe/lp_context.h
+++ b/src/gallium/drivers/llvmpipe/lp_context.h
@@ -136,7 +136,6 @@ struct llvmpipe_context {
 struct blitter_context *blitter;
  
 unsigned tex_timestamp;

-   boolean no_rast;
  
 /** List of all fragment shader variants */

 struct lp_fs_variant_list_item fs_variants_list;
diff --git a/src/gallium/drivers/llvmpipe/lp_jit.c 
b/src/gallium/drivers/llvmpipe/lp_jit.c
index a2762f3..e2309f4 100644
--- a/src/gallium/drivers/llvmpipe/lp_jit.c
+++ b/src/gallium/drivers/llvmpipe/lp_jit.c
@@ -212,6 +212,7 @@ lp_jit_create_types(struct lp_fragment_shader_variant *lp)
elem_types[LP_JIT_THREAD_DATA_CACHE] =
  LLVMPointerType(lp_build_format_cache_type(gallivm), 0);
elem_types[LP_JIT_THREAD_DATA_COUNTER] = LLVMInt64TypeInContext(lc);
+  elem_types[LP_JIT_THREAD_DATA_INVOCATIONS] = LLVMInt64TypeInContext(lc);
elem_types[LP_JIT_THREAD_DATA_RASTER_STATE_VIEWPORT_INDEX] =
  LLVMInt32TypeInContext(lc);
  
diff --git a/src/gallium/drivers/llvmpipe/lp_jit.h b/src/gallium/drivers/llvmpipe/lp_jit.h

index 9db26f2..312d1a1 100644
--- a/src/gallium/drivers/llvmpipe/lp_jit.h
+++ b/src/gallium/drivers/llvmpipe/lp_jit.h
@@ -192,6 +192,7 @@ struct lp_jit_thread_data
  {
 struct lp_build_format_cache *cache;
 uint64_t vis_counter;
+   uint64_t ps_invocations;
  
 /*

  * Non-interpolated rasterizer state passed through to the fragment shader.
@@ -205,6 +206,7 @@ struct lp_jit_thread_data
  enum {
 LP_JIT_THREAD_DATA_CACHE = 0,
 LP_JIT_THREAD_DATA_COUNTER,
+   LP_JIT_THREAD_DATA_INVOCATIONS,
 LP_JIT_THREAD_DATA_RASTER_STATE_VIEWPORT_INDEX,
 LP_JIT_THREAD_DATA_COUNT
  };
@@ -216,6 +218,9 @@ enum {
  #define lp_jit_thread_data_counter(_gallivm, _ptr) \
 lp_build_struct_get_ptr(_gallivm, _ptr, LP_JIT_THREAD_DATA_COUNTER, 
"counter")
  
+#define lp_jit_thread_data_invocations(_gallivm, _ptr) \

+   lp_build_struct_get_ptr(_gallivm, _ptr, LP_JIT_THREAD_DATA_INVOCATIONS, 
"invocs")
+
  #define lp_jit_thread_data_raster_state_viewport_index(_gallivm, _ptr) \
 lp_build_struct_get(_gallivm, _ptr, \
 LP_JIT_THREAD_DATA_RASTER_STATE_VIEWPORT_INDEX, \
diff --git a/src/gallium/drivers/llvmpipe/lp_rast.c 
b/src/gallium/drivers/llvmpipe/lp_rast.c
index 939944a..9d4f9f8 100644
--- a/src/gallium/drivers/llvmpipe/lp_rast.c
+++ b/src/gallium/drivers/llvmpipe/lp_rast.c
@@ -107,7 +107,7 @@ lp_rast_tile_begin(struct lp_rasterizer_task *task,
  task->scene->fb.height - y * TILE_SIZE : TILE_SIZE;
  
 task->thread_data.vis_counter = 0;

-   task->ps_invocations = 0;
+   task->thread_data.ps_invocations = 0;
  
 for (i = 0; i < task->scene->fb.nr_cbufs; i++) {

if (task->scene

[Mesa-dev] [PATCH] llvmpipe: improve rasterization discard logic

[sroland]

From: Roland Scheidegger 

This unifies the explicit rasterization dicard as well as the implicit
rasterization disabled logic (which we need for another state tracker),
which really should do the exact same thing.
We'll now toss out the prims early on in setup with (implicit or
explicit) discard, rather than do setup and binning with them, which
was entirely pointless.
(We should eventually get rid of implicit discard, which should also
enable us to discard stuff already in draw, hence draw would be
able to skip the pointless clip and fallback stages in this case.)
We still need separate logic for only null ps - this is not the same
as rasterization discard. But simplify the logic there and don't count
primitives simply when there's an empty fs, regardless of depth/stencil
tests, which seems perfectly acceptable by d3d10.
While here, also fix statistics for primitives if face culling is
enabled.
No piglit changes.
---
 src/gallium/drivers/llvmpipe/lp_context.h   |  1 -
 src/gallium/drivers/llvmpipe/lp_jit.c   |  1 +
 src/gallium/drivers/llvmpipe/lp_jit.h   |  5 +++
 src/gallium/drivers/llvmpipe/lp_rast.c  | 12 +++-
 src/gallium/drivers/llvmpipe/lp_rast_priv.h |  6 
 src/gallium/drivers/llvmpipe/lp_scene.c |  5 ++-
 src/gallium/drivers/llvmpipe/lp_scene.h | 10 +++---
 src/gallium/drivers/llvmpipe/lp_setup.c | 18 ++-
 src/gallium/drivers/llvmpipe/lp_setup_line.c| 27 ++--
 src/gallium/drivers/llvmpipe/lp_setup_point.c   | 21 +
 src/gallium/drivers/llvmpipe/lp_setup_tri.c | 29 -
 src/gallium/drivers/llvmpipe/lp_setup_vbuf.c|  2 +-
 src/gallium/drivers/llvmpipe/lp_state_derived.c | 22 ++---
 src/gallium/drivers/llvmpipe/lp_state_fs.c  | 41 -
 src/gallium/drivers/llvmpipe/lp_state_fs.h  |  5 ---
 15 files changed, 118 insertions(+), 87 deletions(-)

diff --git a/src/gallium/drivers/llvmpipe/lp_context.h 
b/src/gallium/drivers/llvmpipe/lp_context.h
index 54d98fd..7a2f253 100644
--- a/src/gallium/drivers/llvmpipe/lp_context.h
+++ b/src/gallium/drivers/llvmpipe/lp_context.h
@@ -136,7 +136,6 @@ struct llvmpipe_context {
struct blitter_context *blitter;
 
unsigned tex_timestamp;
-   boolean no_rast;
 
/** List of all fragment shader variants */
struct lp_fs_variant_list_item fs_variants_list;
diff --git a/src/gallium/drivers/llvmpipe/lp_jit.c 
b/src/gallium/drivers/llvmpipe/lp_jit.c
index a2762f3..e2309f4 100644
--- a/src/gallium/drivers/llvmpipe/lp_jit.c
+++ b/src/gallium/drivers/llvmpipe/lp_jit.c
@@ -212,6 +212,7 @@ lp_jit_create_types(struct lp_fragment_shader_variant *lp)
   elem_types[LP_JIT_THREAD_DATA_CACHE] =
 LLVMPointerType(lp_build_format_cache_type(gallivm), 0);
   elem_types[LP_JIT_THREAD_DATA_COUNTER] = LLVMInt64TypeInContext(lc);
+  elem_types[LP_JIT_THREAD_DATA_INVOCATIONS] = LLVMInt64TypeInContext(lc);
   elem_types[LP_JIT_THREAD_DATA_RASTER_STATE_VIEWPORT_INDEX] =
 LLVMInt32TypeInContext(lc);
 
diff --git a/src/gallium/drivers/llvmpipe/lp_jit.h 
b/src/gallium/drivers/llvmpipe/lp_jit.h
index 9db26f2..312d1a1 100644
--- a/src/gallium/drivers/llvmpipe/lp_jit.h
+++ b/src/gallium/drivers/llvmpipe/lp_jit.h
@@ -192,6 +192,7 @@ struct lp_jit_thread_data
 {
struct lp_build_format_cache *cache;
uint64_t vis_counter;
+   uint64_t ps_invocations;
 
/*
 * Non-interpolated rasterizer state passed through to the fragment shader.
@@ -205,6 +206,7 @@ struct lp_jit_thread_data
 enum {
LP_JIT_THREAD_DATA_CACHE = 0,
LP_JIT_THREAD_DATA_COUNTER,
+   LP_JIT_THREAD_DATA_INVOCATIONS,
LP_JIT_THREAD_DATA_RASTER_STATE_VIEWPORT_INDEX,
LP_JIT_THREAD_DATA_COUNT
 };
@@ -216,6 +218,9 @@ enum {
 #define lp_jit_thread_data_counter(_gallivm, _ptr) \
lp_build_struct_get_ptr(_gallivm, _ptr, LP_JIT_THREAD_DATA_COUNTER, 
"counter")
 
+#define lp_jit_thread_data_invocations(_gallivm, _ptr) \
+   lp_build_struct_get_ptr(_gallivm, _ptr, LP_JIT_THREAD_DATA_INVOCATIONS, 
"invocs")
+
 #define lp_jit_thread_data_raster_state_viewport_index(_gallivm, _ptr) \
lp_build_struct_get(_gallivm, _ptr, \
LP_JIT_THREAD_DATA_RASTER_STATE_VIEWPORT_INDEX, \
diff --git a/src/gallium/drivers/llvmpipe/lp_rast.c 
b/src/gallium/drivers/llvmpipe/lp_rast.c
index 939944a..9d4f9f8 100644
--- a/src/gallium/drivers/llvmpipe/lp_rast.c
+++ b/src/gallium/drivers/llvmpipe/lp_rast.c
@@ -107,7 +107,7 @@ lp_rast_tile_begin(struct lp_rasterizer_task *task,
 task->scene->fb.height - y * TILE_SIZE : TILE_SIZE;
 
task->thread_data.vis_counter = 0;
-   task->ps_invocations = 0;
+   task->thread_data.ps_invocations = 0;
 
for (i = 0; i < task->scene->fb.nr_cbufs; i++) {
   if (task->scene->fb.cbufs[i]) {
@@ -446,10 +446,6 @@ lp_rast_shade_quads_mask(struct lp_rasterizer_task *task,
 * allocated 4x4 blocks hence need to filter them out here.
 */
if ((x % TILE_S

Re: [Mesa-dev] [RFC PATCH] gallium: add interface for advanced MSAA

[Roland Scheidegger]

I was under the (apparently wrong) impression EQAA always worked like
that too.
Even AMD's marketing said EQAA has the same number of
stencil/depth/color samples as regular MSAA (when the feature was new,
HD 6900,
https://developer.amd.com/wordpress/media/2012/10/EQAA%2520Modes%2520for%2520AMD%2520HD%25206900%2520Series%2520Cards.pdf).
As well as every article I've seen on that subject...
So I believe the EQAA options available with windows never use more
depth storage samples than color storage samples.
And both CSAA and EQAA were generally met with lukewarm reception - as
you noted, for front to back rendering it's useless.
I'll agree that in theory having more depth samples sounds quite useful,
but maybe in practice the cost is too high (EQAA as well as CSAA were
marketed as nearly free compared to the MSAA modes with the same number
of depth/stencil/color samples, I could imagine if you use the same
number of depth storage samples as coverage samples the cost could
approach closer to a MSAA mode which just has the higher number of
samples for color too, but I guess it would depend on the number and
type of color buffers).

Roland



Am 22.05.2018 um 02:46 schrieb Marek Olšák:
> Your understanding is correct. I misunderstood CSAA. So it looks like
> that CSAA is more useless than I thought. You get the coverage-samples
> level of quality for back-to-front rendering, but you may get the
> depth-samples level of quality for front-to-back rendering, because
> "edges" generated by depth test failures have the same quality as the
> number of depth samples (if depth values are uncompressed). AMD supports
> that mode too, but I don't recommend using it because of the possible
> decrease in front-to-back rendering quality.
> 
> The way the CAP is defined doesn't actually allow NV's implementation of
> CSAA. A new CAP would be needed.
> 
> We'll add a new GL extension for advanced MSAA. The NV extension is
> unusable, because it changes GL behavior in a non-backward-compatible
> way by allowing storage_samples = 2 for all renderbuffers (which is
> cheating, but not surprising from NV).
> 
> Marek
> 
> On Mon, May 21, 2018 at 12:55 PM, Axel Davy  > wrote:
> 
> Hi,
> 
> I get the impression when looking at online documentation about EQAA
> and CSAA, like
> http://www.nvidia.fr/object/coverage-sampled-aa.html
> 
> 
> 
> that the number of stored samples is the same for the color and
> depth buffers.
> Only the samples used for coverage is greater.
> 
> With your proposal, isn't the number of samples stored in the depth
> buffer always the same than the number of samples used for coverage ?
> That reduces the use-cases. In nine, we have to enforce the number
> of stored samples to be the same for the color and the depth buffer,
> but we could increase the number of samples used for coverage and
> enable EQAA/CSAA (in fact there is a similar way to advertise the
> feature for Nvidia and Amd).
> 
> But maybe I misunderstood.
> 
> Yours,
> 
> Axel Davy
> 
> 
> On 18/05/2018 06:05, Marek Olšák wrote:
> 
> From: Marek Olšák mailto:marek.ol...@amd.com>>
> 
> The interface only uses general MSAA terms, so it's "advanced
> MSAA" and not
> something vendor-specific.
> 
> It's a proper subset of EQAA, and a proper superset of CSAA, so
> it's neither.
> 
> Changes:
> - pipe_resource is changed
> - is_format_supported is changed
> - a new CAP is added
> ---
>   src/gallium/docs/source/screen.rst   | 31
> ++--
>   src/gallium/include/pipe/p_defines.h |  1 +
>   src/gallium/include/pipe/p_screen.h  |  1 +
>   src/gallium/include/pipe/p_state.h   | 18 +---
>   4 files changed, 46 insertions(+), 5 deletions(-)
> 
> diff --git a/src/gallium/docs/source/screen.rst
> b/src/gallium/docs/source/screen.rst
> index 5bc6ee99f08..cf4787a1c49 100644
> --- a/src/gallium/docs/source/screen.rst
> +++ b/src/gallium/docs/source/screen.rst
> @@ -398,20 +398,25 @@ The integer capabilities:
>   * ``PIPE_CAP_LOAD_CONSTBUF``: True if the driver supports
> TGSI_OPCODE_LOAD use
>     with constant buffers.
>   * ``PIPE_CAP_TGSI_ANY_REG_AS_ADDRESS``: Any TGSI register can
> be used as
>     an address for indirect register indexing.
>   * ``PIPE_CAP_TILE_RASTER_ORDER``: Whether the driver supports
>     GL_MESA_tile_raster_order, using the tile_raster_order_*
> fields in
>     pipe_ras

Re: [Mesa-dev] [RFC PATCH] gallium: add interface for advanced MSAA

[Marek Olšák]

Your understanding is correct. I misunderstood CSAA. So it looks like that
CSAA is more useless than I thought. You get the coverage-samples level of
quality for back-to-front rendering, but you may get the depth-samples
level of quality for front-to-back rendering, because "edges" generated by
depth test failures have the same quality as the number of depth samples
(if depth values are uncompressed). AMD supports that mode too, but I don't
recommend using it because of the possible decrease in front-to-back
rendering quality.

The way the CAP is defined doesn't actually allow NV's implementation of
CSAA. A new CAP would be needed.

We'll add a new GL extension for advanced MSAA. The NV extension is
unusable, because it changes GL behavior in a non-backward-compatible way
by allowing storage_samples = 2 for all renderbuffers (which is cheating,
but not surprising from NV).

Marek

On Mon, May 21, 2018 at 12:55 PM, Axel Davy  wrote:

> Hi,
>
> I get the impression when looking at online documentation about EQAA and
> CSAA, like
> http://www.nvidia.fr/object/coverage-sampled-aa.html
>
> that the number of stored samples is the same for the color and depth
> buffers.
> Only the samples used for coverage is greater.
>
> With your proposal, isn't the number of samples stored in the depth buffer
> always the same than the number of samples used for coverage ?
> That reduces the use-cases. In nine, we have to enforce the number of
> stored samples to be the same for the color and the depth buffer, but we
> could increase the number of samples used for coverage and enable EQAA/CSAA
> (in fact there is a similar way to advertise the feature for Nvidia and
> Amd).
>
> But maybe I misunderstood.
>
> Yours,
>
> Axel Davy
>
>
> On 18/05/2018 06:05, Marek Olšák wrote:
>
>> From: Marek Olšák 
>>
>> The interface only uses general MSAA terms, so it's "advanced MSAA" and
>> not
>> something vendor-specific.
>>
>> It's a proper subset of EQAA, and a proper superset of CSAA, so it's
>> neither.
>>
>> Changes:
>> - pipe_resource is changed
>> - is_format_supported is changed
>> - a new CAP is added
>> ---
>>   src/gallium/docs/source/screen.rst   | 31 ++--
>>   src/gallium/include/pipe/p_defines.h |  1 +
>>   src/gallium/include/pipe/p_screen.h  |  1 +
>>   src/gallium/include/pipe/p_state.h   | 18 +---
>>   4 files changed, 46 insertions(+), 5 deletions(-)
>>
>> diff --git a/src/gallium/docs/source/screen.rst
>> b/src/gallium/docs/source/screen.rst
>> index 5bc6ee99f08..cf4787a1c49 100644
>> --- a/src/gallium/docs/source/screen.rst
>> +++ b/src/gallium/docs/source/screen.rst
>> @@ -398,20 +398,25 @@ The integer capabilities:
>>   * ``PIPE_CAP_LOAD_CONSTBUF``: True if the driver supports
>> TGSI_OPCODE_LOAD use
>> with constant buffers.
>>   * ``PIPE_CAP_TGSI_ANY_REG_AS_ADDRESS``: Any TGSI register can be used
>> as
>> an address for indirect register indexing.
>>   * ``PIPE_CAP_TILE_RASTER_ORDER``: Whether the driver supports
>> GL_MESA_tile_raster_order, using the tile_raster_order_* fields in
>> pipe_rasterizer_state.
>>   * ``PIPE_CAP_MAX_COMBINED_SHADER_OUTPUT_RESOURCES``: Limit on combined
>> shader
>> output resources (images + buffers + fragment outputs). If 0 the state
>> tracker works it out.
>> +* ``PIPE_CAP_FRAMEBUFFER_MIXED_SAMPLES``: Framebuffer attachments can
>> have
>> +  different number of samples each with the following restriction:
>> + color.nr_samples >= zs.nr_samples >= color.nr_storage_samples
>> +  If 0 is returned, the following restriction applies:
>> + color.nr_samples == zs.nr_samples >= color.nr_storage_samples
>>   * ``PIPE_CAP_SIGNED_VERTEX_BUFFER_OFFSET``:
>> Whether pipe_vertex_buffer::buffer_offset is treated as signed. The
>> u_vbuf
>> module needs this for optimal performance in workstation applications.
>>   * ``PIPE_CAP_CONTEXT_PRIORITY_MASK``: For drivers that support
>> per-context
>> priorities, this returns a bitmask of PIPE_CONTEXT_PRIORITY_x for the
>> supported priority levels.  A driver that does not support prioritized
>> contexts can return 0.
>>   * ``PIPE_CAP_FENCE_SIGNAL``: True if the driver supports signaling
>> semaphores
>> using fence_server_signal().
>>   * ``PIPE_CAP_CONSTBUF0_FLAGS``: The bits of pipe_resource::flags that
>> must be
>> @@ -718,20 +723,23 @@ is_format_supported
>> Determine if a resource in the given format can be used in a specific
>> manner.
>> **format** the resource format
>> **target** one of the PIPE_TEXTURE_x flags
>> **sample_count** the number of samples. 0 and 1 mean no multisampling,
>>   the maximum allowed legal value is 32.
>>   +**storage_sample_count** the number of storage samples. This must be <=
>> +sample_count. See the documentation of ``pipe_resource::nr_storage_sa
>> mples``.
>> +
>>   **bindings** is a bitmask of :ref:`PIPE_BIND` flags.
>> Returns TRUE if all usages can be satisfied.
>>   can_create_resource
>>  

[Mesa-dev] [PATCHv2 3/4] i965: Handle non-zero texture buffer offsets in buffer object range calculation.

[Francisco Jerez]

Otherwise the specified surface state will allow the GPU to access
memory up to BufferOffset bytes past the end of the buffer.  Found by
inspection.

v2: Protect against out-of-range BufferOffset (Nanley).
Cc: mesa-sta...@lists.freedesktop.org
---
 src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c 
b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
index af629a17bfa..39e898243db 100644
--- a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
+++ b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
@@ -647,6 +647,7 @@ buffer_texture_range_size(struct brw_context *brw,
const unsigned texel_size = 
_mesa_get_format_bytes(obj->_BufferObjectFormat);
const unsigned buffer_size = (!obj->BufferObject ? 0 :
  obj->BufferObject->Size);
+   const unsigned buffer_offset = MIN2(buffer_size, obj->BufferOffset);
 
/* The ARB_texture_buffer_specification says:
 *
@@ -664,7 +665,8 @@ buffer_texture_range_size(struct brw_context *brw,
 * so that when ISL divides by stride to obtain the number of texels, that
 * texel count is clamped to MAX_TEXTURE_BUFFER_SIZE.
 */
-   return MIN3((unsigned)obj->BufferSize, buffer_size,
+   return MIN3((unsigned)obj->BufferSize,
+   buffer_size - buffer_offset,
brw->ctx.Const.MaxTextureBufferSize * texel_size);
 }
 
-- 
2.16.1

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

[Mesa-dev] [PATCH] v3d: Fix automake linking error.

[Vinson Lee]

  CXXLDgallium_dri.la
../../../../src/broadcom/.libs/libbroadcom.a(clif_dump.o): In function 
`clif_dump_packet':
src/broadcom/clif/clif_dump.c:87: undefined reference to 
`v3d33_clif_dump_packet'
src/broadcom/clif/clif_dump.c:85: undefined reference to 
`v3d41_clif_dump_packet'
../../../../src/broadcom/.libs/libbroadcom.a(clif_dump.o): In function 
`clif_process_worklist':
src/broadcom/clif/clif_dump.c:140: undefined reference to 
`v3d41_clif_dump_gl_shader_state_record'
src/broadcom/clif/clif_dump.c:144: undefined reference to 
`v3d33_clif_dump_gl_shader_state_record'

Signed-off-by: Vinson Lee 
---
 src/gallium/drivers/v3d/Automake.inc | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/v3d/Automake.inc 
b/src/gallium/drivers/v3d/Automake.inc
index 7cf8ae7cd8..91ae826b30 100644
--- a/src/gallium/drivers/v3d/Automake.inc
+++ b/src/gallium/drivers/v3d/Automake.inc
@@ -5,7 +5,9 @@ TARGET_CPPFLAGS += -DGALLIUM_V3D
 TARGET_LIB_DEPS += \
$(top_builddir)/src/gallium/winsys/v3d/drm/libv3ddrm.la \
$(top_builddir)/src/gallium/drivers/v3d/libv3d.la \
-   $(top_builddir)/src/broadcom/libbroadcom.la
+   $(top_builddir)/src/broadcom/libbroadcom.la \
+   $(top_builddir)/src/broadcom/libbroadcom_v33.la \
+   $(top_builddir)/src/broadcom/libbroadcom_v41.la
 
 if !HAVE_GALLIUM_VC4
 TARGET_LIB_DEPS += $(top_builddir)/src/broadcom/cle/libbroadcom_cle.la
-- 
2.17.0

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

Re: [Mesa-dev] [PATCH] radeonsi: Track pipe_vertex_buffers for relocs.

[Marek Olšák]

On Sun, May 20, 2018 at 2:21 PM, Mathias Fröhlich  wrote:

> Hi Marek,
>
> On Sunday, 20 May 2018 20:08:08 CEST Marek Olšák wrote:
> > The old code saves which vertex element is the first to use a VBO slot.
> > When VBOs are added to the buffer list, each VBO is added only for such
> > vertex elements, and not added for others. So the old and new code do
> > exactly the same thing but differently.
>
> But its doing that with less calls to radeon_add_to_buffer_list/amdg
> pu_cs_add_buffer.
> It avoids duplicate calls for pipe_vertex_elements refering to the same
> pipe_vertex_buffer.
>

And the old code does exactly the same thing - it avoids duplicate calls
for the same pipe_vertex_buffer, because vertex elements reusing vertex
buffer slots don't have their bit set in first_vb_use_mask, so
add_to_buffer_list is never called for those vertex elements.

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

Re: [Mesa-dev] [PATCH] i965/glk: Add l3 banks count for 2x6 configuration

[Clayton Craft]

Quoting Anuj Phogat (2018-05-21 15:21:56)
> 2x6 configuration with pci-id 0x3185 has same number of
> banks (2) as 3x6 configuration (pci-id 0x3184).

This passes testing, you can add me to the tested-by.

> 
> Reported-by: Clayton Craft 
> Signed-off-by: Anuj Phogat 
> Cc: 
> Cc: Lionel Landwerlin 
> Cc: Francisco Jerez 
> ---
>  src/intel/dev/gen_device_info.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/intel/dev/gen_device_info.c b/src/intel/dev/gen_device_info.c
> index 653cece6d70..8e971329892 100644
> --- a/src/intel/dev/gen_device_info.c
> +++ b/src/intel/dev/gen_device_info.c
> @@ -732,10 +732,10 @@ static const struct gen_device_info gen_device_info_glk 
> = {
> .l3_banks = 2,
>  };
>  
> -/*TODO: Initialize l3_banks when we know the number. */
>  static const struct gen_device_info gen_device_info_glk_2x6 = {
> GEN9_LP_FEATURES_2X6,
> .is_geminilake = true,
> +   .l3_banks = 2,
>  };
>  
>  static const struct gen_device_info gen_device_info_cfl_gt1 = {
> -- 
> 2.17.0
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev


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

Re: [Mesa-dev] [RFC PATCH] Replace an flock with a random filename to evade some very ugly system dependent code

[Timothy Arceri]

On 22/05/18 04:40, Benedikt Schemmer wrote:

Ok, small update. Please ignore this rfc.
I finally got appveyor to build my repo.

There are at least these dependencies that would need to addressed (for anybody 
wanting tor try):

#include  // can be eliminated sometimes by replacing with 
__TIMESTAMP__ or maybe better __DATE__ __TIME__
#include 
#include 
#include 
#include 
#include "zlib.h" // complains about redefinition vsnprintf (I used version 
1.23)


So for now: code duplication it is ;)


appveyor has mingw available, maybe I will give that a try sometime
https://www.appveyor.com/docs/build-environment/

and they even have an ubuntu image available
https://www.appveyor.com/docs/getting-started-with-appveyor-for-linux/

wonder why that isnt being used instead of msvc 2015 with llvm 3.3.1?


Because VMWare uses that setup to builds its drivers, appveyor was setup 
to avoid breaking those builds on windows.





Am 21.05.2018 um 01:19 schrieb Timothy Arceri:



On 20/05/18 22:16, Benedikt Schemmer wrote:

There is exactly one flock in mesa and it caused mesa not to build
on windows when shader cache was enabled.

It should be possible to revert 9f8dc3bf03ec825bae7041858dda6ca2e9a34363
"utils: build sha1/disk cache only with Android/Autoconf" currently
guarding the offending code with ENABLE_SHADER_CACHE

This would allow shader cache to work on windows I think.


NAK. rand() is not thread safe.

Why are you trying to make this build on windows? There is no use case for this 
on windows currently so it won't even be tested. There are also other calls 
such as getuid() etc that will fail on windows.

If someone want this to work on windows they should just write windows specific 
paths IMO.



I dont have a test system with windows though.
This builds on linux and is tested with Deus Ex:MD and Metro 2033 Redux
both with cold shader cache.

Really
Fixes: d1efa09d342bff3e5def2978a0bef748d74f9c82

CC: Tapani Pälli 
CC: "Marek Olšák" 
CC: Emil Velikov 
CC: Timothy Arceri 
CC: Samuel Pitoiset 
---
This enables the patch
[PATCH 1/3] mesa/main/shaderapi: Use generate_sha1() unconditionally

   src/util/disk_cache.c | 48 +++-
   1 file changed, 35 insertions(+), 13 deletions(-)

diff --git a/src/util/disk_cache.c b/src/util/disk_cache.c
index 4a762eff20..ca47bb15fb 100644
--- a/src/util/disk_cache.c
+++ b/src/util/disk_cache.c
@@ -28,7 +28,6 @@
   #include 
   #include 
   #include 
-#include 
   #include 
   #include 
   #include 
@@ -848,6 +847,29 @@ struct cache_entry_file_data {
  uint32_t uncompressed_size;
   };
   +static char *
+generate_random_string(int length) {
+   static const char a[] = "0123456789abcdef";
+
+   if (length > 16)
+  return NULL;
+
+   char buf[16];
+   char *rndstr;
+
+   for (int i = 0; i < length - 1; ++i) {
+   // assign a random element from the lookup table
+   buf[i] = a[rand() % (sizeof(a) - 1)];
+   }
+
+   buf[length - 1] = 0;
+
+   if (asprintf(&rndstr, "%s", buf) == -1)
+  return NULL;
+
+   return rndstr;
+}
+
   static void
   cache_put(void *job, int thread_index)
   {
@@ -855,7 +877,7 @@ cache_put(void *job, int thread_index)
    int fd = -1, fd_final = -1, err, ret;
  unsigned i = 0;
-   char *filename = NULL, *filename_tmp = NULL;
+   char *filename = NULL, *filename_tmp = NULL, *random = NULL;
  struct disk_cache_put_job *dc_job = (struct disk_cache_put_job *) job;
    filename = get_cache_file(dc_job->cache, dc_job->key);
@@ -873,7 +895,16 @@ cache_put(void *job, int thread_index)
   * final destination filename, (to prevent any readers from seeing
   * a partially written file).
   */
-   if (asprintf(&filename_tmp, "%s.tmp", filename) == -1)
+
+   /* This next part used to be an flock(), which would prevent windows systems
+    * to build. 4 hex characters should be enough to prevent filename race
+    * conditions for now.
+   */
+   random = generate_random_string(4);
+   if (random == NULL)
+  goto done;
+
+   if (asprintf(&filename_tmp, "%s_%s.tmp", filename, random) == -1)
     goto done;
    fd = open(filename_tmp, O_WRONLY | O_CLOEXEC | O_CREAT, 0644);
@@ -890,16 +921,7 @@ cache_put(void *job, int thread_index)
    goto done;
  }
   -   /* With the temporary file open, we take an exclusive flock on
-    * it. If the flock fails, then another process still has the file
-    * open with the flock held. So just let that file be responsible
-    * for writing the file.
-    */
-   err = flock(fd, LOCK_EX | LOCK_NB);
-   if (err == -1)
-  goto done;
-
-   /* Now that we have the lock on the open temporary file, we can
+   /* Now that we have the open temporary file, we can
   * check to see if the destination file already exists. If so,
   * another process won the race between when we saw that the file
   * didn't exist and now. In this case, we don't do anything more,


___
mesa-de

Re: [Mesa-dev] [PATCH v2 2/3] glsl: allow built-in variables to be explicitly declared

[Timothy Arceri]

Ian can I get your thoughts on this series?

On 12/05/18 14:49, Timothy Arceri wrote:

Mesa seems to be the only implementation that doesn't allow builtins
to be explicitly declared. The GLSL 1.30 spec seems to imply that
buitins may be explicitly declared.

This this allows the game "Full Bore" the be playable (when using
MESA_GL_VERSION_OVERRIDE=3.3COMPAT). It will also allow us to
remove the allow_glsl_builtin_variable_redeclaration dri override.

 From the GLSL 1.30 spec Section 7.2 (Fragment Shader Special
Variables):

 "Both gl_FragColor and gl_FragData are deprecated; the preferred
 usage is to explicitly declare these outputs in the fragment
 shader using the out storage qualifier."

To avoid some GLSL ES tests failing we add a check to make sure
precision matches on the redeclared builtin.
---
  src/compiler/glsl/ast_to_hir.cpp | 32 ++--
  1 file changed, 22 insertions(+), 10 deletions(-)

diff --git a/src/compiler/glsl/ast_to_hir.cpp b/src/compiler/glsl/ast_to_hir.cpp
index a7a9ac80769..54d0816a986 100644
--- a/src/compiler/glsl/ast_to_hir.cpp
+++ b/src/compiler/glsl/ast_to_hir.cpp
@@ -4390,14 +4390,8 @@ get_variable_being_redeclared(ir_variable **var_ptr, 
YYLTYPE loc,
earlier->data.precision = var->data.precision;
earlier->data.memory_coherent = var->data.memory_coherent;
  
-   } else if (earlier->data.how_declared == ir_var_declared_implicitly &&

-  state->allow_builtin_variable_redeclaration) {
-  /* Allow verbatim redeclarations of built-in variables. Not explicitly
-   * valid, but some applications do it.
-   */
-  if (earlier->data.mode != var->data.mode &&
-  !(earlier->data.mode == ir_var_system_value &&
-var->data.mode == ir_var_shader_in)) {
+   } else if (allow_all_redeclarations) {
+  if (earlier->data.mode != var->data.mode) {
   _mesa_glsl_error(&loc, state,
"redeclaration of `%s' with incorrect qualifiers",
var->name);
@@ -4406,8 +4400,22 @@ get_variable_being_redeclared(ir_variable **var_ptr, 
YYLTYPE loc,
"redeclaration of `%s' has incorrect type",
var->name);
}
-   } else if (allow_all_redeclarations) {
-  if (earlier->data.mode != var->data.mode) {
+   } else if (earlier->data.how_declared == ir_var_declared_implicitly) {
+  /* Allow verbatim redeclarations of built-in variables. The GLSL 1.30
+   * spec seems to imply that buitins may be explicitly declared.
+   *
+   * From the GLSL 1.30 spec Section 7.2 (Fragment Shader Special
+   * Variables):
+   *
+   *"Both gl_FragColor and gl_FragData are deprecated; the preferred
+   *usage is to explicitly declare these outputs in the fragment
+   *shader using the out storage qualifier."
+   */
+  enum ir_variable_mode builtin_mode =
+ glsl_external_mode((ir_variable_mode) earlier->data.mode,
+state->stage, earlier->data.location);
+
+  if (builtin_mode != var->data.mode) {
   _mesa_glsl_error(&loc, state,
"redeclaration of `%s' with incorrect qualifiers",
var->name);
@@ -4415,6 +4423,10 @@ get_variable_being_redeclared(ir_variable **var_ptr, 
YYLTYPE loc,
   _mesa_glsl_error(&loc, state,
"redeclaration of `%s' has incorrect type",
var->name);
+  } else if (earlier->data.precision != var->data.precision) {
+ _mesa_glsl_error(&loc, state,
+  "redeclaration of `%s' has incorrect precision",
+  var->name);
}
 } else {
_mesa_glsl_error(&loc, state, "`%s' redeclared", var->name);


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

Re: [Mesa-dev] [PATCH 1/2] glsl: always enable OES_standard_derivatives features if supported

[Timothy Arceri]

On 22/05/18 03:13, Ian Romanick wrote:

On 05/16/2018 12:04 AM, Timothy Arceri wrote:

The GLSL ES 1.0 spec made these features optional. With
OES_standard_derivatives they are guaranteed to be available
but currently the extension must be enabled to use them.

Instead this changes the code to check if the driver supports
the extension and if so always enables them.

This fixes compiler errors in Google Earth VR.


This sounds like a bug in Google Earth VR.  Has anyone reported it to them?


I can't find anywhere to report bugs for it. To be honest I seem to be 
having trouble with this app even on Nvidia and windows, I'm not sure if 
its working anywhere currently.

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

Re: [Mesa-dev] [PATCH] Revert "st/nir: use NIR for asm programs"

[Timothy Arceri]

On 22/05/18 04:15, Eric Anholt wrote:

Timothy Arceri  writes:


On 18/05/18 00:53, Eric Anholt wrote:

This reverts commit 5c33e8c7729edd5e16020ebb8703be96523e04f2.  It broke
fixed function vertex programs on vc4 and v3d, and apparently caused
trouble for radeonsi's NIR paths as well.


Has someone reported trouble with radeonsi NIR? I'm not aware of any
issues. Dave's patch [1] was for fixing iris, I had no way to test so
didn't try send it out myself after you confirmed it fixed your issue.


OK, I had that mistaken.

Still, an unexplained workaround on a branch is not a great response to
this.  And even with that workaround plus your change, the following
tests are still broken on V3D:

gl-1.0-rendermode-fallback
opengl-1.1/gl_select-*
fp-arb-fragment-coord-conventions-integer.shader_test
vp-max-array
ati_fragment_shader-render-constants and 6 others.

I'd like to land the revert until there are clean piglit results.


Sure. As I said I have no idea why the workaround helps, seems radeonsi 
does something different to the other drivers. For now feel free to push 
the revert.


Acked-by: Timothy Arceri 




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

Re: [Mesa-dev] [PATCH] i965/glk: Add l3 banks count for 2x6 configuration

[Lionel Landwerlin]

On 21/05/18 23:25, Lionel Landwerlin wrote:

On 21/05/18 23:21, Anuj Phogat wrote:

2x6 configuration with pci-id 0x3185 has same number of
banks (2) as 3x6 configuration (pci-id 0x3184).

Reported-by: Clayton Craft 
Signed-off-by: Anuj Phogat 
Cc: 
Cc: Lionel Landwerlin 
Cc: Francisco Jerez 


It matches my reading of the documentation :)

Reviewed-by: Lionel Landwerlin 


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




---
  src/intel/dev/gen_device_info.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/intel/dev/gen_device_info.c 
b/src/intel/dev/gen_device_info.c

index 653cece6d70..8e971329892 100644
--- a/src/intel/dev/gen_device_info.c
+++ b/src/intel/dev/gen_device_info.c
@@ -732,10 +732,10 @@ static const struct gen_device_info 
gen_device_info_glk = {

 .l3_banks = 2,
  };
  -/*TODO: Initialize l3_banks when we know the number. */
  static const struct gen_device_info gen_device_info_glk_2x6 = {
 GEN9_LP_FEATURES_2X6,
 .is_geminilake = true,
+   .l3_banks = 2,
  };
    static const struct gen_device_info gen_device_info_cfl_gt1 = {



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



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

Re: [Mesa-dev] [PATCH] i965/glk: Add l3 banks count for 2x6 configuration

[Lionel Landwerlin]

On 21/05/18 23:21, Anuj Phogat wrote:

2x6 configuration with pci-id 0x3185 has same number of
banks (2) as 3x6 configuration (pci-id 0x3184).

Reported-by: Clayton Craft 
Signed-off-by: Anuj Phogat 
Cc: 
Cc: Lionel Landwerlin 
Cc: Francisco Jerez 


It matches my reading of the documentation :)

Reviewed-by: Lionel Landwerlin 


---
  src/intel/dev/gen_device_info.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/intel/dev/gen_device_info.c b/src/intel/dev/gen_device_info.c
index 653cece6d70..8e971329892 100644
--- a/src/intel/dev/gen_device_info.c
+++ b/src/intel/dev/gen_device_info.c
@@ -732,10 +732,10 @@ static const struct gen_device_info gen_device_info_glk = 
{
 .l3_banks = 2,
  };
  
-/*TODO: Initialize l3_banks when we know the number. */

  static const struct gen_device_info gen_device_info_glk_2x6 = {
 GEN9_LP_FEATURES_2X6,
 .is_geminilake = true,
+   .l3_banks = 2,
  };
  
  static const struct gen_device_info gen_device_info_cfl_gt1 = {



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

[Mesa-dev] [PATCH] i965/glk: Add l3 banks count for 2x6 configuration

[Anuj Phogat]

2x6 configuration with pci-id 0x3185 has same number of
banks (2) as 3x6 configuration (pci-id 0x3184).

Reported-by: Clayton Craft 
Signed-off-by: Anuj Phogat 
Cc: 
Cc: Lionel Landwerlin 
Cc: Francisco Jerez 
---
 src/intel/dev/gen_device_info.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/intel/dev/gen_device_info.c b/src/intel/dev/gen_device_info.c
index 653cece6d70..8e971329892 100644
--- a/src/intel/dev/gen_device_info.c
+++ b/src/intel/dev/gen_device_info.c
@@ -732,10 +732,10 @@ static const struct gen_device_info gen_device_info_glk = 
{
.l3_banks = 2,
 };
 
-/*TODO: Initialize l3_banks when we know the number. */
 static const struct gen_device_info gen_device_info_glk_2x6 = {
GEN9_LP_FEATURES_2X6,
.is_geminilake = true,
+   .l3_banks = 2,
 };
 
 static const struct gen_device_info gen_device_info_cfl_gt1 = {
-- 
2.17.0

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

[Mesa-dev] [Bug 106283] Shader replacements works only for limited use cases

[bugzilla-daemon]

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

--- Comment #10 from i...@yahoo.com ---
(In reply to iive from comment #9)
> (In reply to Tapani Pälli from comment #8)
> > I'm working on something different ATM and would not like to context switch
> > but will look at this later. If changes from b...@besd.de make sense, it
> > would be good to land those first. I'm not sure what implications his set
> > has on using shader-db so I'm hoping some active user of shader-db to
> > comment/review his series.
> 
[...]
> 
> Just tell me after how many days/weeks I should remind you to check this
> again.

Just a reminder about the shader replacement feature request.

I hope that you haven't forgotten about it.

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

[Mesa-dev] [PATCH 4.16 039/110] drm/i915/gen9: Add WaClearHIZ_WM_CHICKEN3 for bxt and glk

[Greg Kroah-Hartman]

4.16-stable review patch.  If anyone has any objections, please let me know.

--

From: Michel Thierry 

commit b579f924a90f42fa561afd8201514fc216b71949 upstream.

Factor in clear values wherever required while updating destination
min/max.

References: HSDES#160184
Signed-off-by: Michel Thierry 
Cc: mesa-dev@lists.freedesktop.org
Cc: Mika Kuoppala 
Cc: Oscar Mateo 
Reviewed-by: Mika Kuoppala 
Signed-off-by: Chris Wilson 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20180510200708.18097-1-michel.thie...@intel.com
Cc: sta...@vger.kernel.org
Cc: Joonas Lahtinen 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20180514165445.9198-1-michel.thie...@intel.com
(backported from commit 0c79f9cb77eae28d48a4f9fc1b3341aacbbd260c)
Signed-off-by: Joonas Lahtinen 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/gpu/drm/i915/i915_reg.h|3 +++
 drivers/gpu/drm/i915/intel_engine_cs.c |4 
 2 files changed, 7 insertions(+)

--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7139,6 +7139,9 @@ enum {
 #define SLICE_ECO_CHICKEN0 _MMIO(0x7308)
 #define   PIXEL_MASK_CAMMING_DISABLE   (1 << 14)
 
+#define GEN9_WM_CHICKEN3   _MMIO(0x5588)
+#define   GEN9_FACTOR_IN_CLR_VAL_HIZ   (1 << 9)
+
 /* WaCatErrorRejectionIssue */
 #define GEN7_SQ_CHICKEN_MBCUNIT_CONFIG _MMIO(0x9030)
 #define  GEN7_SQ_CHICKEN_MBCUNIT_SQINTMOB  (1<<11)
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1098,6 +1098,10 @@ static int gen9_init_workarounds(struct
WA_SET_FIELD_MASKED(GEN8_CS_CHICKEN1, GEN9_PREEMPT_GPGPU_LEVEL_MASK,
GEN9_PREEMPT_GPGPU_COMMAND_LEVEL);
 
+   /* WaClearHIZ_WM_CHICKEN3:bxt,glk */
+   if (IS_GEN9_LP(dev_priv))
+   WA_SET_BIT_MASKED(GEN9_WM_CHICKEN3, GEN9_FACTOR_IN_CLR_VAL_HIZ);
+
/* WaVFEStateAfterPipeControlwithMediaStateClear:skl,bxt,glk,cfl */
ret = wa_ring_whitelist_reg(engine, GEN9_CTX_PREEMPT_REG);
if (ret)


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

[Mesa-dev] [HOWTO] CI on appveyor with a linux image

[Benedikt Schemmer]

I thought this might be interesting because currently appveyor is only used 
with MSVC and LLVM 3.3.1

They can however provide Ubuntu 16.04 LTS. Its free for OSS.
You only need some kind of repository.

Basic setup is easy
https://www.appveyor.com/docs/

The hard part is the appveyor.yml file, which you can find below.
This builds mesa every time you commit.

Probably not the best config options and only for 64-bit, because I dont know 
how to do 32-bit builds on Ubuntu.
So if somebody does, help is more than welcome.

And if the Vmware guys feel like sharing, this can be merged with the current 
appveyor.yml (somehow, doesn't seem to hard though)

p.s. there are line breaks after the autogen that you will have to remove 
manually (should be one long line)
---
# http://www.appveyor.com/doc
#
# To setup AppVeyor for your own personal repositories do the following:
# - Sign up
# - Add a new project
# - Select Git and fill in the Git clone URL
# - Setup a Git hook as explained in
#   https://github.com/appveyor/webhooks#installing-git-hook
# - Check 'Settings > General > Skip branches without appveyor.yml'
# - Check 'Settings > General > Rolling builds'
# - Setup the global or project notifications to your liking
#
# Note that kicking (or restarting) a build via the web UI will not work, as it
# will fail to find appveyor.yml .  The Git hook is the most practical way to
# kick a build.
#
# See also:
# - 
http://help.appveyor.com/discussions/problems/2209-node-grunt-build-specify-a-project-or-solution-file-the-directory-does-not-contain-a-project-or-solution-file
# - 
http://help.appveyor.com/discussions/questions/1184-build-config-vs-appveyoryaml

version: '{build}'

branches:
  except:
  - /^travis.*$/

# Don't download the full Mesa history to speed up cloning.  However the clone
# depth must not be too small, otherwise builds might fail when lots of patches
# are committed in succession, because the desired commit is not found on the
# truncated history.
#
# See also:
# - https://www.appveyor.com/blog/2014/06/04/shallow-clone-for-git-repositories
clone_depth: 100

image: ubuntu
platform: Any CPU
configuration: Release


install:
- ls -al
- sh: sudo sed -i~orig -e 's$# deb-src http://us$deb-src http://us$' 
/etc/apt/sources.list
- sh: sudo add-apt-repository ppa:oibaf/graphics-drivers
- sh: sudo apt-get update
- sh: sudo DEBIAN_FRONTEND=noninteractive apt-get -y -o 
Dpkg::Options::="--force-confdef" -o Dpkg::Options::="--force-confold" upgrade
- sh: sudo apt-get build-dep mesa -y
- sh: sudo apt-get install libxvmc-dev libxcb-xvmc0-dev libomxil-bellagio-dev -y

build_script:
- sh: ./autogen.sh --enable-dri --with-dri-drivers="nouveau i915 i965 r200 
radeon swrast" --enable-osmesa --enable-glx-tls --enable-shared-glapi 
--enable-texture-float --enable-driglx-direct
--enable-dri3 --with-platforms="x11 wayland drm" --enable-xa --enable-llvm 
ac_cv_path_LLVM_CONFIG=llvm-config-5.0 --enable-vdpau --enable-omx-bellagio 
--enable-va --enable-xvmc --enable-opencl
--enable-opencl-icd --enable-nine --enable-gallium-extra-hud --enable-lmsensors 
--with-gallium-drivers=" nouveau svga r600 r300 i915 virgl radeonsi swrast" 
--enable-gles1 --enable-gles2 --enable-gle
--with-vulkan-drivers=intel,radeon
- sh: make
- sh: sudo make install
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/3] mesa/main/shaderapi: purely non-functional cleanups, like whitespace errors and cleanups

[Benedikt Schemmer]

Am 21.05.2018 um 19:21 schrieb Ian Romanick:
> On 05/10/2018 02:05 AM, Benedikt Schemmer wrote:
>> remove a memset too and yes, this is all functionally identical
>>
>> ---
>>  src/mesa/main/shaderapi.c | 40 
>>  1 file changed, 20 insertions(+), 20 deletions(-)
>>
>> diff --git a/src/mesa/main/shaderapi.c b/src/mesa/main/shaderapi.c
>> index e8acca4490..1d0ca5374b 100644
>> --- a/src/mesa/main/shaderapi.c
>> +++ b/src/mesa/main/shaderapi.c
>> @@ -241,11 +241,10 @@ _mesa_init_shader_state(struct gl_context *ctx)
>> /* Device drivers may override these to control what kind of instructions
>>  * are generated by the GLSL compiler.
>>  */
>> -   struct gl_shader_compiler_options options;
>> +   struct gl_shader_compiler_options options = {};
>> gl_shader_stage sh;
>> int i;
>>
>> -   memset(&options, 0, sizeof(options));
> 
> This is not functionally the same.  The memset will zero padding fields
> added by the compiler, but '= {}' does not.

I did check with
https://godbolt.org/
and at least for clang (which generates a memset for {}) and gcc it is exactly 
the same

void test(void) {
struct gl_shader_compiler_options options = {};
memset(&options, 0, sizeof(options));
}

gcc:
  // = {}
  mov QWORD PTR [rbp-32], 0
  mov QWORD PTR [rbp-24], 0
  mov QWORD PTR [rbp-16], 0

  // memset
  lea rax, [rbp-32]
  mov edx, 24
  mov esi, 0
  mov rdi, rax
  call memset

clang:

  // = {}
  mov rdi, rsi
  mov qword ptr [rbp - 32], rsi # 8-byte Spill
  mov esi, eax
  mov qword ptr [rbp - 40], rdx # 8-byte Spill
  mov dword ptr [rbp - 44], eax # 4-byte Spill
  call memset

  //memset
  mov rdx, qword ptr [rbp - 32] # 8-byte Reload
  mov rdi, rdx
  mov esi, dword ptr [rbp - 44] # 4-byte Reload
  mov rdx, qword ptr [rbp - 40] # 8-byte Reload
  call memset

but your right intel compilers generate something weird:

  // = {}
  lea rax, QWORD PTR [-32+rbp] #71.47
  mov edx, 0 #71.47
  mov ecx, 24 #71.47
  mov rdi, rax #71.47
  mov eax, edx #71.47
  and eax, 65535 #71.47
  mov ah, al #71.47
  mov edx, eax #71.47
  shl eax, 16 #71.47
  or eax, edx #71.47
  mov esi, ecx #71.47
  shr rcx, 2 #71.47
  rep stosd #71.47
  mov ecx, esi #71.47
  and ecx, 3 #71.47
  rep stosb #71.47

  // memset
  lea rax, QWORD PTR [-32+rbp] #72.5
  mov edx, 0 #72.5
  mov ecx, 24 #72.5
  mov rdi, rax #72.5
  mov esi, edx #72.5
  mov rdx, rcx #72.5
  call memset #72.5
  mov QWORD PTR [-8+rbp], rax #72.5


> 
> I'm also not fond of the The '!= 0' and '== NULL' changes.  Pretty much
> everywhere in core Mesa uses those patterns.>
> I feel like most of this is just a bunch of spurious changes that will
> just make cherry picking patches to stable irritating later on.
> 
>> options.MaxUnrollIterations = 32;
>> options.MaxIfDepth = UINT_MAX;
>>
>> @@ -254,7 +253,7 @@ _mesa_init_shader_state(struct gl_context *ctx)
>>
>> ctx->Shader.Flags = _mesa_get_shader_flags();
>>
>> -   if (ctx->Shader.Flags != 0)
>> +   if (ctx->Shader.Flags)
>>ctx->Const.GenerateTemporaryNames = true;
>>
>> /* Extended for ARB_separate_shader_objects */
>> @@ -771,7 +770,8 @@ get_programiv(struct gl_context *ctx, GLuint program, 
>> GLenum pname,
>>GLint *params)
>>  {
>> struct gl_shader_program *shProg
>> -  = _mesa_lookup_shader_program_err(ctx, program, 
>> "glGetProgramiv(program)");
>> +  = _mesa_lookup_shader_program_err(ctx, program,
>> +"glGetProgramiv(program)");
>>
>> /* Is transform feedback available in this context?
>>  */
>> @@ -953,7 +953,7 @@ get_programiv(struct gl_context *ctx, GLuint program, 
>> GLenum pname,
>>*params = shProg->BinaryRetreivableHint;
>>return;
>> case GL_PROGRAM_BINARY_LENGTH:
>> -  if (ctx->Const.NumProgramBinaryFormats == 0) {
>> +  if (!ctx->Const.NumProgramBinaryFormats) {
>>   *params = 0;
>>} else {
>>   _mesa_get_program_binary_length(ctx, shProg, params);
>> @@ -974,7 +974,7 @@ get_programiv(struct gl_context *ctx, GLuint program, 
>> GLenum pname,
>>   "linked)");
>>   return;
>>}
>> -  if (shProg->_LinkedShaders[MESA_SHADER_COMPUTE] == NULL) {
>> +  if (!shProg->_LinkedShaders[MESA_SHADER_COMPUTE]) {
>>   _mesa_error(ctx, GL_INVALID_OPERATION, "glGetProgramiv(no compute "
>>   "shaders)");
>>   return;
>> @@ -1234,7 +1234,7 @@ _mesa_compile_shader(struct gl_context *ctx, struct 
>> gl_shader *sh)
>> } else {
>>if (ctx->_Shader->Flags & GLSL_DUMP) {
>>   _mesa_log("GLSL source for %s shader %d:\n",
>> - _mesa_shader_stage_to_string(sh->Stage), sh->Name);
>> +   _mesa_shader_stage_to_string(sh->Stage), sh->Name);
>>   _mesa_log("%s\n", sh->Source);
>>}
>>
>> @@ -1381,13 +1381,13 @@ link_program(struct gl_context *ctx, struct 
>> gl_shader_program *shProg,
>>GLuint i;
>>

[Mesa-dev] [PATCH 4.14 27/95] drm/i915/gen9: Add WaClearHIZ_WM_CHICKEN3 for bxt and glk

[Greg Kroah-Hartman]

4.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Michel Thierry 

commit b579f924a90f42fa561afd8201514fc216b71949 upstream.

Factor in clear values wherever required while updating destination
min/max.

References: HSDES#160184
Signed-off-by: Michel Thierry 
Cc: mesa-dev@lists.freedesktop.org
Cc: Mika Kuoppala 
Cc: Oscar Mateo 
Reviewed-by: Mika Kuoppala 
Signed-off-by: Chris Wilson 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20180510200708.18097-1-michel.thie...@intel.com
Cc: sta...@vger.kernel.org
Cc: Joonas Lahtinen 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20180514165445.9198-1-michel.thie...@intel.com
(backported from commit 0c79f9cb77eae28d48a4f9fc1b3341aacbbd260c)
Signed-off-by: Joonas Lahtinen 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/gpu/drm/i915/i915_reg.h|3 +++
 drivers/gpu/drm/i915/intel_engine_cs.c |4 
 2 files changed, 7 insertions(+)

--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7044,6 +7044,9 @@ enum {
 #define SLICE_ECO_CHICKEN0 _MMIO(0x7308)
 #define   PIXEL_MASK_CAMMING_DISABLE   (1 << 14)
 
+#define GEN9_WM_CHICKEN3   _MMIO(0x5588)
+#define   GEN9_FACTOR_IN_CLR_VAL_HIZ   (1 << 9)
+
 /* WaCatErrorRejectionIssue */
 #define GEN7_SQ_CHICKEN_MBCUNIT_CONFIG _MMIO(0x9030)
 #define  GEN7_SQ_CHICKEN_MBCUNIT_SQINTMOB  (1<<11)
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -900,6 +900,10 @@ static int gen9_init_workarounds(struct
I915_WRITE(GEN8_L3SQCREG4, (I915_READ(GEN8_L3SQCREG4) |
GEN8_LQSC_FLUSH_COHERENT_LINES));
 
+   /* WaClearHIZ_WM_CHICKEN3:bxt,glk */
+   if (IS_GEN9_LP(dev_priv))
+   WA_SET_BIT_MASKED(GEN9_WM_CHICKEN3, GEN9_FACTOR_IN_CLR_VAL_HIZ);
+
/* WaVFEStateAfterPipeControlwithMediaStateClear:skl,bxt,glk,cfl */
ret = wa_ring_whitelist_reg(engine, GEN9_CTX_PREEMPT_REG);
if (ret)


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

[Mesa-dev] [Bug 106595] [RADV] Rendering distortions only when MSAA is enabled

[bugzilla-daemon]

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

--- Comment #3 from zefkerri...@gmail.com ---
https://cgit.freedesktop.org/mesa/mesa/commit/?id=73df16dcee79e2281c8d8a830dbbe6655359c82d
This video I shot before applying this patch, but I believe that the issue of
wings rendering is not related to the issue of mountains rendering. But I think
that the issue of the surface of the wings can be related to the subject of
this bug report.

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

[Mesa-dev] [Bug 106595] [RADV] Rendering distortions only when MSAA is enabled

[bugzilla-daemon]

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

--- Comment #2 from zefkerri...@gmail.com ---
(In reply to Samuel Pitoiset from comment #1)
> Do you have
> https://cgit.freedesktop.org/mesa/mesa/commit/
> ?id=73df16dcee79e2281c8d8a830dbbe6655359c82d in your tree?

Yes, I have. But this patch, as I understood it, is intended to correct exactly
the opposite issue when the distorted rendering occurs if the MSAA is NOT
included. But in my case everything is exactly the opposite: I see the
distortion of rendering if MSAA is enabled. The fact is that in WoW there are
different types of surfaces, and for some of them, MSAA enabling leads to
distortion of rendering but at the same time eliminating the distortion of
rendering on some other surfaces.

Please watch the video on this link and pay attention to how the character's
wings change when I turn the MSAA on and off. It is clear that the mountains
are beginning to be correctly rendered when I turn on the MSAA, but at the same
time the enabling of MSAA breaks the correct rendering of the wings surface of
this character. Perhaps your patch solves the issue of broken mountains
rendering in this case, but the rendering of the wings is still broken.
https://mega.nz/#!iVVHFTgL!Yb20wUpRyfLsuNH0JOqJT21zQd-hFxnpwBJcEBD3t00

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

Re: [Mesa-dev] [PATCH v2] mesa: handle a bunch of formats in IMPLEMENTATION_COLOR_READ_*

[Eric Anholt]

Tomeu Vizoso  writes:

> Virgl could save a lot of work converting buffers in the host side
> between formats if Mesa supported a bunch of other formats when reading
> pixels.
>
> This commit adds cases to handle specific formats so that the values
> reported by the two calls match more closely the underlying native
> formats.
>
> In GLES is important that IMPLEMENTATION_COLOR_READ_* return the native
> format and data type because the spec only allows reading with those,
> besides GL_RGBA or GL_RGBA_INTEGER.
>
> Additionally, because virgl currently doesn't implement such
> conversions, this commit fixes several tests in
> dEQP-GLES3.functional.fbo.color.clear.*, when using virgl in the guest
> side.
>
> Additionally, assert that those functions' result match
> _mesa_format_matches_format_and_type, so both functions are kept in
> sync.
>
> Signed-off-by: Tomeu Vizoso 
>
> v2: * Let R10G10B10A2_UINT fall back to GL_RGBA_INTEGER (Eric Anholt)
> * Assert with _mesa_format_matches_format_and_type (Eric Anholt)
> ---
>  src/mesa/main/framebuffer.c | 117 
>  1 file changed, 80 insertions(+), 37 deletions(-)
>
> diff --git a/src/mesa/main/framebuffer.c b/src/mesa/main/framebuffer.c
> index 8e751b453b75..6be4ecbc58f9 100644
> --- a/src/mesa/main/framebuffer.c
> +++ b/src/mesa/main/framebuffer.c
> @@ -834,22 +834,72 @@ _mesa_get_color_read_format(struct gl_context *ctx,
> }
> else {
>const mesa_format format = fb->_ColorReadBuffer->Format;
> -  const GLenum data_type = _mesa_get_format_datatype(format);
> -
> -  if (format == MESA_FORMAT_B8G8R8A8_UNORM)
> - return GL_BGRA;
> -  else if (format == MESA_FORMAT_B5G6R5_UNORM)
> - return GL_RGB;
> -  else if (format == MESA_FORMAT_R_UNORM8)
> - return GL_RED;
> -
> -  switch (data_type) {
> -  case GL_UNSIGNED_INT:
> -  case GL_INT:
> - return GL_RGBA_INTEGER;
> +  GLenum gl_format, data_type;
> +  GLuint comps;
> +
> +  _mesa_uncompressed_format_to_type_and_comps(format, &data_type, 
> &comps);
> +
> +  switch(format) {

Needs a space: "switch (format) {"

> +  case MESA_FORMAT_RGBA_UINT8:
> + gl_format = GL_RGBA_INTEGER;
> + break;
> +  case MESA_FORMAT_B8G8R8A8_UNORM:
> + gl_format = GL_BGRA;
> + break;
> +  case MESA_FORMAT_B5G6R5_UNORM:
> +  case MESA_FORMAT_R11G11B10_FLOAT:
> + gl_format = GL_RGB;
> + break;
> +  case MESA_FORMAT_RG_FLOAT32:
> +  case MESA_FORMAT_RG_FLOAT16:
> +  case MESA_FORMAT_R8G8_UNORM:
> + gl_format = GL_RG;
> + break;
> +  case MESA_FORMAT_RG_SINT32:
> +  case MESA_FORMAT_RG_UINT32:
> +  case MESA_FORMAT_RG_SINT16:
> +  case MESA_FORMAT_RG_UINT16:
> +  case MESA_FORMAT_RG_SINT8:
> +  case MESA_FORMAT_RG_UINT8:
> + gl_format = GL_RG_INTEGER;
> + break;
> +  case MESA_FORMAT_R_FLOAT32:
> +  case MESA_FORMAT_R_FLOAT16:
> +  case MESA_FORMAT_R_UNORM8:
> + gl_format = GL_RED;
> + break;
> +  case MESA_FORMAT_R_SINT32:
> +  case MESA_FORMAT_R_UINT32:
> +  case MESA_FORMAT_R_SINT16:
> +  case MESA_FORMAT_R_UINT16:
> +  case MESA_FORMAT_R_SINT8:
> +  case MESA_FORMAT_R_UINT8:
> + gl_format = GL_RED_INTEGER;
> + break;
>default:
> - return GL_RGBA;
> + switch (data_type) {
> + case GL_UNSIGNED_INT:
> + case GL_UNSIGNED_INT_2_10_10_10_REV:
> + case GL_UNSIGNED_SHORT:
> + case GL_INT:
> + case GL_SHORT:
> + case GL_BYTE:
> +gl_format = GL_RGBA_INTEGER;
> +break;
> + default:
> +gl_format = GL_RGBA;
> +break;
> + }
>}
> +
> +  /* GL_RGBA and GL_RGBA_INTEGER should be always valid */
> +  assert(gl_format == GL_RGBA ||
> + gl_format == GL_RGBA_INTEGER ||
> + _mesa_format_matches_format_and_type(format, gl_format,
> +  data_type,
> +  ctx->Pack.SwapBytes, 
> NULL));
> +

I like the idea, but it looks like this assertion won't work out --
R8G8_UNORM will always assertion fail on !littleEndian, for example.
Assertion failing when SwapBytes changes would also be bad.

> +  return gl_format;
> }
>  }
>  
> @@ -882,29 +932,22 @@ _mesa_get_color_read_type(struct gl_context *ctx,
>return GL_NONE;
> }
> else {
> -  const GLenum format = fb->_ColorReadBuffer->Format;
> -  const GLenum data_type = _mesa_get_format_datatype(format);
> -
> -  if (format == MESA_FORMAT_B5G6R5_UNORM)
> - return GL_UNSIGNED_SHORT_5_6_5;
> -
> -  if (format == MESA_FORMAT_B10G10R10A2_UNORM ||
> -  format == MESA_FORMAT_B10G10R10X2_UNORM ||
> -  format == MESA_FORMAT_R10G10B10A2_UNORM ||
> -  format == MESA_FORMAT_R10G10B10

[Mesa-dev] [Bug 106595] [RADV] Rendering distortions only when MSAA is enabled

[bugzilla-daemon]

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

--- Comment #1 from Samuel Pitoiset  ---
Do you have
https://cgit.freedesktop.org/mesa/mesa/commit/?id=73df16dcee79e2281c8d8a830dbbe6655359c82d
in your tree?

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

[Mesa-dev] [Bug 106595] [RADV] Rendering distortions only when MSAA is enabled

[bugzilla-daemon]

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

zefkerri...@gmail.com changed:

   What|Removed |Added

 CC||zefkerri...@gmail.com

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

[Mesa-dev] [Bug 106595] [RADV] Rendering distortions only when MSAA is enabled

[bugzilla-daemon]

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

Bug ID: 106595
   Summary: [RADV] Rendering distortions only when MSAA is enabled
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Vulkan/radeon
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: zefkerri...@gmail.com
QA Contact: mesa-dev@lists.freedesktop.org

Created attachment 139666
  --> https://bugs.freedesktop.org/attachment.cgi?id=139666&action=edit
WoW corrupted rendering screenshots

[RADV] Blizzard's World of Warcraft (Wine Staging + DXVK) has a rendering
distortions when MSAA is enabled.

Arch Linux, Mesa-git, but this also happens with any stable version of Mesa.
GPU: AMD Radeon HD7770 with the amdgpu Linux kernel driver.
Freshest Wine (git) + Staging patchset (git) + DXVK (git).
Please tell me if you need more info or any logs and how do I do them.

I attached a few screenshots of this issue:
1) Without any AA enabled, and therefore with proper rendering
2) With MSAAx2
3) With MSAAx4
4) And a few screenshots with MSAAx8.

This issue happens only if MSAA is enabled, but does not happen if any other
types of AA are enabled.

-- 
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 mesa] i965: Check result of make_surface() for miptree_create

[Ian Romanick]

On 05/17/2018 05:05 AM, Eric Engestrom wrote:
> From: Andrea Azzarone 
> 
> Since make_surface() can fail we need to check the result before 
> dereferencing it.
> 
> Bug: https://github.com/mesa3d/mesa/pull/5
> Bug: https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1760415
> Reviewed-by: Eric Engestrom 
> ---
> Andrea: We don't use github, I only happened to notice your pull request :)
> Next time you want to send us something, send it here :P
> ---
>  src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c 
> b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> index 67086ee6c0e8d6b6feb0..43687ea77abfe9989882 100644
> --- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> +++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> @@ -718,6 +718,9 @@ miptree_create(struct brw_context *brw,
>   ISL_SURF_USAGE_DEPTH_BIT | ISL_SURF_USAGE_TEXTURE_BIT,
>   BO_ALLOC_BUSY, 0, NULL);
>  
> +  if (!mt)
> + return NULL;
> +

So... I sent this same patch a few months ago, but we decided to not
land it.

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


>if (needs_separate_stencil(brw, mt, format) &&
>!make_separate_stencil_surface(brw, mt)) {
>   intel_miptree_release(&mt);
> 

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

Re: [Mesa-dev] [RFC PATCH] Replace an flock with a random filename to evade some very ugly system dependent code

[Benedikt Schemmer]

Ok, small update. Please ignore this rfc.
I finally got appveyor to build my repo.

There are at least these dependencies that would need to addressed (for anybody 
wanting tor try):

#include  // can be eliminated sometimes by replacing with 
__TIMESTAMP__ or maybe better __DATE__ __TIME__
#include 
#include 
#include 
#include 
#include "zlib.h" // complains about redefinition vsnprintf (I used version 
1.23)


So for now: code duplication it is ;)


appveyor has mingw available, maybe I will give that a try sometime
https://www.appveyor.com/docs/build-environment/

and they even have an ubuntu image available
https://www.appveyor.com/docs/getting-started-with-appveyor-for-linux/

wonder why that isnt being used instead of msvc 2015 with llvm 3.3.1?

Am 21.05.2018 um 01:19 schrieb Timothy Arceri:
> 
> 
> On 20/05/18 22:16, Benedikt Schemmer wrote:
>> There is exactly one flock in mesa and it caused mesa not to build
>> on windows when shader cache was enabled.
>>
>> It should be possible to revert 9f8dc3bf03ec825bae7041858dda6ca2e9a34363
>> "utils: build sha1/disk cache only with Android/Autoconf" currently
>> guarding the offending code with ENABLE_SHADER_CACHE
>>
>> This would allow shader cache to work on windows I think.
> 
> NAK. rand() is not thread safe.
> 
> Why are you trying to make this build on windows? There is no use case for 
> this on windows currently so it won't even be tested. There are also other 
> calls such as getuid() etc that will fail on windows.
> 
> If someone want this to work on windows they should just write windows 
> specific paths IMO.
> 
>>
>> I dont have a test system with windows though.
>> This builds on linux and is tested with Deus Ex:MD and Metro 2033 Redux
>> both with cold shader cache.
>>
>> Really
>> Fixes: d1efa09d342bff3e5def2978a0bef748d74f9c82
>>
>> CC: Tapani Pälli 
>> CC: "Marek Olšák" 
>> CC: Emil Velikov 
>> CC: Timothy Arceri 
>> CC: Samuel Pitoiset 
>> ---
>> This enables the patch
>> [PATCH 1/3] mesa/main/shaderapi: Use generate_sha1() unconditionally
>>
>>   src/util/disk_cache.c | 48 +++-
>>   1 file changed, 35 insertions(+), 13 deletions(-)
>>
>> diff --git a/src/util/disk_cache.c b/src/util/disk_cache.c
>> index 4a762eff20..ca47bb15fb 100644
>> --- a/src/util/disk_cache.c
>> +++ b/src/util/disk_cache.c
>> @@ -28,7 +28,6 @@
>>   #include 
>>   #include 
>>   #include 
>> -#include 
>>   #include 
>>   #include 
>>   #include 
>> @@ -848,6 +847,29 @@ struct cache_entry_file_data {
>>  uint32_t uncompressed_size;
>>   };
>>   +static char *
>> +generate_random_string(int length) {
>> +   static const char a[] = "0123456789abcdef";
>> +
>> +   if (length > 16)
>> +  return NULL;
>> +
>> +   char buf[16];
>> +   char *rndstr;
>> +
>> +   for (int i = 0; i < length - 1; ++i) {
>> +   // assign a random element from the lookup table
>> +   buf[i] = a[rand() % (sizeof(a) - 1)];
>> +   }
>> +
>> +   buf[length - 1] = 0;
>> +
>> +   if (asprintf(&rndstr, "%s", buf) == -1)
>> +  return NULL;
>> +
>> +   return rndstr;
>> +}
>> +
>>   static void
>>   cache_put(void *job, int thread_index)
>>   {
>> @@ -855,7 +877,7 @@ cache_put(void *job, int thread_index)
>>    int fd = -1, fd_final = -1, err, ret;
>>  unsigned i = 0;
>> -   char *filename = NULL, *filename_tmp = NULL;
>> +   char *filename = NULL, *filename_tmp = NULL, *random = NULL;
>>  struct disk_cache_put_job *dc_job = (struct disk_cache_put_job *) job;
>>    filename = get_cache_file(dc_job->cache, dc_job->key);
>> @@ -873,7 +895,16 @@ cache_put(void *job, int thread_index)
>>   * final destination filename, (to prevent any readers from seeing
>>   * a partially written file).
>>   */
>> -   if (asprintf(&filename_tmp, "%s.tmp", filename) == -1)
>> +
>> +   /* This next part used to be an flock(), which would prevent windows 
>> systems
>> +    * to build. 4 hex characters should be enough to prevent filename race
>> +    * conditions for now.
>> +   */
>> +   random = generate_random_string(4);
>> +   if (random == NULL)
>> +  goto done;
>> +
>> +   if (asprintf(&filename_tmp, "%s_%s.tmp", filename, random) == -1)
>>     goto done;
>>    fd = open(filename_tmp, O_WRONLY | O_CLOEXEC | O_CREAT, 0644);
>> @@ -890,16 +921,7 @@ cache_put(void *job, int thread_index)
>>    goto done;
>>  }
>>   -   /* With the temporary file open, we take an exclusive flock on
>> -    * it. If the flock fails, then another process still has the file
>> -    * open with the flock held. So just let that file be responsible
>> -    * for writing the file.
>> -    */
>> -   err = flock(fd, LOCK_EX | LOCK_NB);
>> -   if (err == -1)
>> -  goto done;
>> -
>> -   /* Now that we have the lock on the open temporary file, we can
>> +   /* Now that we have the open temporary file, we can
>>   * check to see if the destination file already exists. If so,
>>   * another process won the race between when we 

Re: [Mesa-dev] [PATCH] vbo: remove MaxVertexAttribStride assert check.

[Ian Romanick]

On 05/17/2018 11:56 PM, Mathias Fröhlich wrote:
> Hi Dave,
> 
> On Friday, 18 May 2018 06:57:19 CEST Dave Airlie wrote:
>>> May be I should take care of all of these type of asserts, also the ones
>>> with MaxVertexAttribRelativeOffset and care for not checking them
>>> when the extension version is unavailable or checking against the OpenGL
>>> spec guaranteed minimum values for both constants instead of the actual 
>>> ones.
>>> ... means, there are more asserts of this kind.
>>>
>>> Well, alternatively since you probably aim for supporting GL4.4 at one 
>>> point, you
>>> could alternatively set the constant already? AFAICT the
>>> PIPE_CAP_MAX_VERTEX_ATTRIB_STRIDE is only used to set the
>>> constant and does not imply anything beyond.
>>
>> Well it's not just virgl, won't this break things like r300 and i915?
> 
> I dont think so.
> 
> The constant is set to the opengl mandated minimum of 2048 in
> _mesa_init_constants which seems not overwritten by any classic driver.
> In gallium there is the cap which overwrites the constant past setting
> it from mesa. As far as I greped yesterday, only virgil just returns 0.
> The rest returns the mandated 2048, there is one exception with etnaviv
> that returns 128 when being asked for PIPE_CAP_MAX_VERTEX_ATTRIB_STRIDE.
> If you look into etnaviv this stems from having only 8 bits in the hardware
> register for the stride.

Or maybe leave the assert but have virgl return a real value instead of
0?  The whole reason that _mesa_init_constants sets things to sensible
default values is so that we don't need workarounds in the main code for
drivers that don't support the functionality.

> So, I realize, that I have been taking the constant MaxVertexAttribStride 
> as either a well maintained hardware limit or at least as a lower bound to 
> that hardware limit. Means I did not expect this presence of that
> value (well being != 0, I mean) to be dependent on the OpenGL version
> but on the backing driver.
> 
> What does that mean to virgl. Well, I see you cant get (OpenGL < 4.4 or no
> GL_ARB_vertex_attrib_binding) or dont know (virgil does not ask the host
> currently) the real value.
> Also the current implementation just checks this to give a some hint what goes
> wrong, especially there should be no crash if the assert fails.
> That together is why I just said 'fine, I have to treat that differently, you 
> get my r-b
> so that my assert gets out of your way'.
> 
> Putting that all together, I see the route:
> * just remove the assert, cross you fingers and dont check at all.
>Most likely it all works.
>All modern hardware can do 2048 and beyond and the vbo module
>can only produce strides up to VBO_ATTRIB_MAX*4*4 < 2048.
>It wont work if the virtualization host runs etnaviv or equivalent
>limited and somebody does a high count of vertex attributes through
>virgil - unlikely.
> * Extend the assert to
>   assert(MaxVertexAttribStride == 0 || stride < MaxVertexAttribStride)
>   Then virgil does not get the check.
> * Replace the assert with a gl error. Then the application gets at least
>a hint that there was some resource exceeded. You will need to give
>some limit for virgl or we play the MaxVertexAttribStride == 0 game
>so that virgil just does not get that checked.
> 
> I think I need to downgrade the assert to an error at least as I cannot
> internally to mesa guarantee that it has to hold.
> 
> I am more concerned about the MaxVertexAttribRelativeOffset constant
> which is required from _mesa_update_vao_derived_arrays. It is again set to
> the OpenGL mandated minimum of 2047 from _mesa_init_constants. Since
> there is no gallium cap for that, it cannot just be set to 0 from virgil.
> Etnaviv is again technically not able to handle the OpenGL mandated
> minimum but should again work for most of the practical cases.
> But finding a zero in MaxVertexAttribRelativeOffset would not work
> for _mesa_update_vao_derived_arrays.
> 
> best
> 
> Mathias
> 
> 
> ___
> 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] v3d: Include v3d_drm.h path.

[Eric Anholt]

Vinson Lee  writes:

> Fix build error.
>
>   CC   v3d_blit.lo
> In file included from v3d_blit.c:27:0:
> v3d_context.h:39:10: fatal error: v3d_drm.h: No such file or directory
>  #include "v3d_drm.h"
>   ^~~
>
> Fixes: 8a793d42f1cc ("v3d: Switch the vc5 driver to using the finalized V3D 
> UABI.")
> Signed-off-by: Vinson Lee 

Looks like I never enabled it by default on automake, so travis didn't
catch it.  Pushed now, thanks!


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] Revert "st/nir: use NIR for asm programs"

[Eric Anholt]

Timothy Arceri  writes:

> On 18/05/18 00:53, Eric Anholt wrote:
>> This reverts commit 5c33e8c7729edd5e16020ebb8703be96523e04f2.  It broke
>> fixed function vertex programs on vc4 and v3d, and apparently caused
>> trouble for radeonsi's NIR paths as well.
>
> Has someone reported trouble with radeonsi NIR? I'm not aware of any 
> issues. Dave's patch [1] was for fixing iris, I had no way to test so 
> didn't try send it out myself after you confirmed it fixed your issue.

OK, I had that mistaken.

Still, an unexplained workaround on a branch is not a great response to
this.  And even with that workaround plus your change, the following
tests are still broken on V3D:

gl-1.0-rendermode-fallback
opengl-1.1/gl_select-*
fp-arb-fragment-coord-conventions-integer.shader_test
vp-max-array
ati_fragment_shader-render-constants and 6 others.

I'd like to land the revert until there are clean piglit results.


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 1/3] docs/releasing: Add complete command line to scripts

[Ian Romanick]

With the nits in patch 3 fixed, this series is

Reviewed-by: Ian Romanick 

On 05/21/2018 10:34 AM, Dylan Baker wrote:
> particularly that bugzilla_mesa and shortlog_mesa take an argument to
> pass directly to git.
> ---
>  docs/releasing.html | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/docs/releasing.html b/docs/releasing.html
> index a022d0c484b..d69eba1136f 100644
> --- a/docs/releasing.html
> +++ b/docs/releasing.html
> @@ -547,8 +547,8 @@ Two scripts are available to help generate portions of 
> the release notes:
>  
>  
>  
> - ./bin/bugzilla_mesa.sh
> - ./bin/shortlog_mesa.sh
> + ./bin/bugzilla_mesa.sh $previous_release_point..$current_release_point
> + ./bin/shortlog_mesa.sh $previous_release_point..$current_release_point
>  
>  
>  
> 

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

Re: [Mesa-dev] [PATCH 3/3] docs/releasing: Add note about using a staging branch

[Ian Romanick]

On 05/21/2018 10:34 AM, Dylan Baker wrote:
> ---
>  docs/releasing.html | 19 +++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/docs/releasing.html b/docs/releasing.html
> index 07f100caae1..20fc4579a32 100644
> --- a/docs/releasing.html
> +++ b/docs/releasing.html
> @@ -249,6 +249,25 @@ Now go to
>   href="https://bugs.freedesktop.org/editversions.cgi?action=add&product=Mesa";
>  target="_parent">Bugzilla and add the new Mesa version X.Y.
>  
>  
> +
> +Use a stanging branch:
> +
> +
> +git checkout X.Y
> +git checkout -b X.Y-proposed
> +
> +
> +This branch should be reported to any teams using a CI to track upcoming 
> stable
> +branches. This will allow that team to report an CI regressions to the 
> release

 those teams any CI regressions

> +manager, while leaving the X.Y branch in a continuously usable state. To
> +that end it is most useful if the release manager run the relavent scripts

 relevant

> +(such as git-fixes-pick-list.sh) once per day, and update this branch. When 
> it is
> +time to make a release, the X.Y branch should be rebased to the X.Y-proposed 
> branch.
> +
> +The staging branch can be force pushed (for example, to remove a patch that
> +causes regressions), while the X.Y should not be force pushed.
> +
> +
>  
>  Check that there are no distribution breaking changes and revert them if 
> needed.
>  For example: files being overwritten on install, etc. Happens extremely 
> rarely -
> 

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

Re: [Mesa-dev] [PATCH] nir/print: fix printing of 8/16 bit constant variables

[Karol Herbst]

On Mon, May 21, 2018 at 7:31 PM, Chema Casanova  wrote:
> As GLSL_TYPE_FLOAT16 type support is not implemented in this patch, we
> would need to change commit summary to ".. 8/16 bit integer constant.."
> or just implement half float support with something like.
>
> +   case GLSL_TYPE_FLOAT16:
> +  for (i = 0; i < cols; i++) {
> + for (j = 0; j < rows; j++) {
> +if (i + j > 0) fprintf(fp, ", ");
> +fprintf(fp, "%f",_mesa_half_to_float(c->values[i].u16[j]));
> + }
> +  }
> +  break;
>
>
> Chema
>

yeah, I guess it makes sense to include it as well, thanks!

>
> El 21/05/18 a las 14:51, Karol Herbst escribió:
>> Signed-off-by: Karol Herbst 
>> ---
>>  src/compiler/nir/nir_print.c | 22 ++
>>  1 file changed, 22 insertions(+)
>>
>> diff --git a/src/compiler/nir/nir_print.c b/src/compiler/nir/nir_print.c
>> index 97b2d6164cd..e331a26d932 100644
>> --- a/src/compiler/nir/nir_print.c
>> +++ b/src/compiler/nir/nir_print.c
>> @@ -299,6 +299,28 @@ print_constant(nir_constant *c, const struct glsl_type 
>> *type, print_state *state
>> unsigned i, j;
>>
>> switch (glsl_get_base_type(type)) {
>> +   case GLSL_TYPE_UINT8:
>> +   case GLSL_TYPE_INT8:
>> +  /* Only float base types can be matrices. */
>> +  assert(cols == 1);
>> +
>> +  for (i = 0; i < rows; i++) {
>> + if (i > 0) fprintf(fp, ", ");
>> + fprintf(fp, "0x%02x", c->values[0].u8[i]);
>> +  }
>> +  break;
>> +
>> +   case GLSL_TYPE_UINT16:
>> +   case GLSL_TYPE_INT16:
>> +  /* Only float base types can be matrices. */
>> +  assert(cols == 1);
>> +
>> +  for (i = 0; i < rows; i++) {
>> + if (i > 0) fprintf(fp, ", ");
>> + fprintf(fp, "0x%04x", c->values[0].u16[i]);
>> +  }
>> +  break;
>> +
>> case GLSL_TYPE_UINT:
>> case GLSL_TYPE_INT:
>> case GLSL_TYPE_BOOL:
>>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 3/3] docs/releasing: Add note about using a staging branch

[Dylan Baker]

---
 docs/releasing.html | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/docs/releasing.html b/docs/releasing.html
index 07f100caae1..20fc4579a32 100644
--- a/docs/releasing.html
+++ b/docs/releasing.html
@@ -249,6 +249,25 @@ Now go to
 https://bugs.freedesktop.org/editversions.cgi?action=add&product=Mesa";
 target="_parent">Bugzilla and add the new Mesa version X.Y.
 
 
+
+Use a stanging branch:
+
+
+git checkout X.Y
+git checkout -b X.Y-proposed
+
+
+This branch should be reported to any teams using a CI to track upcoming stable
+branches. This will allow that team to report an CI regressions to the release
+manager, while leaving the X.Y branch in a continuously usable state. To
+that end it is most useful if the release manager run the relavent scripts
+(such as git-fixes-pick-list.sh) once per day, and update this branch. When it 
is
+time to make a release, the X.Y branch should be rebased to the X.Y-proposed 
branch.
+
+The staging branch can be force pushed (for example, to remove a patch that
+causes regressions), while the X.Y should not be force pushed.
+
+
 
 Check that there are no distribution breaking changes and revert them if 
needed.
 For example: files being overwritten on install, etc. Happens extremely rarely 
-
-- 
2.17.0

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

[Mesa-dev] [PATCH 1/3] docs/releasing: Add complete command line to scripts

[Dylan Baker]

particularly that bugzilla_mesa and shortlog_mesa take an argument to
pass directly to git.
---
 docs/releasing.html | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/docs/releasing.html b/docs/releasing.html
index a022d0c484b..d69eba1136f 100644
--- a/docs/releasing.html
+++ b/docs/releasing.html
@@ -547,8 +547,8 @@ Two scripts are available to help generate portions of the 
release notes:
 
 
 
-   ./bin/bugzilla_mesa.sh
-   ./bin/shortlog_mesa.sh
+   ./bin/bugzilla_mesa.sh $previous_release_point..$current_release_point
+   ./bin/shortlog_mesa.sh $previous_release_point..$current_release_point
 
 
 
-- 
2.17.0

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

[Mesa-dev] [PATCH 2/3] docs/releasing: add meson to build systems to test

[Dylan Baker]

---
 docs/releasing.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/releasing.html b/docs/releasing.html
index d69eba1136f..07f100caae1 100644
--- a/docs/releasing.html
+++ b/docs/releasing.html
@@ -122,7 +122,7 @@ Currently Ilia Mirkin and AMD devs have requested 
"permanent" exception.
 
 
 
-make distcheck, scons and scons check must pass
+make distcheck, scons and scons check, and meson + ninja test must pass
 Testing with different version of system components - LLVM and others is 
also
 performed where possible.
 As a general rule, testing with various combinations of configure
-- 
2.17.0

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

[Mesa-dev] [PATCH 1/2] bin/bugzilla_mesa.sh: explicitly set the --pretty argument

[Dylan Baker]

Signed-off-by: Dylan Baker 
---
 bin/bugzilla_mesa.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bin/bugzilla_mesa.sh b/bin/bugzilla_mesa.sh
index a8f5305844b..9095bc9deea 100755
--- a/bin/bugzilla_mesa.sh
+++ b/bin/bugzilla_mesa.sh
@@ -23,7 +23,7 @@ echo ""
 echo ""
 
 # extract fdo urls from commit log
-git log $* | grep 'bugs.freedesktop.org/show_bug' | sed -e $trim_before | sort 
-n -u | sed -e $use_after |\
+git log --pretty=medium $* | grep 'bugs.freedesktop.org/show_bug' | sed -e 
$trim_before | sort -n -u | sed -e $use_after |\
 while read url
 do
id=$(echo $url | cut -d'=' -f2)
-- 
2.17.0

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

[Mesa-dev] [PATCH 2/2] bin/get-pick-listh.sh: force git --pretty=medium

[Dylan Baker]

Signed-off-by: Dylan Baker 
---
 bin/get-pick-list.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bin/get-pick-list.sh b/bin/get-pick-list.sh
index 1bd0b367d8b..9e9a39e494b 100755
--- a/bin/get-pick-list.sh
+++ b/bin/get-pick-list.sh
@@ -12,7 +12,7 @@
 latest_branchpoint=`git merge-base origin/master HEAD`
 
 # Grep for commits with "cherry picked from commit" in the commit message.
-git log --reverse --grep="cherry picked from commit" $latest_branchpoint..HEAD 
|\
+git log --reverse --pretty=medium --grep="cherry picked from commit" 
$latest_branchpoint..HEAD |\
grep "cherry picked from commit" |\
sed -e 's/^[[:space:]]*(cherry picked from commit[[:space:]]*//' -e 
's/)//' > already_picked
 
-- 
2.17.0

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

Re: [Mesa-dev] [PATCH] nir/print: fix printing of 8/16 bit constant variables

[Chema Casanova]

As GLSL_TYPE_FLOAT16 type support is not implemented in this patch, we
would need to change commit summary to ".. 8/16 bit integer constant.."
or just implement half float support with something like.

+   case GLSL_TYPE_FLOAT16:
+  for (i = 0; i < cols; i++) {
+ for (j = 0; j < rows; j++) {
+if (i + j > 0) fprintf(fp, ", ");
+fprintf(fp, "%f",_mesa_half_to_float(c->values[i].u16[j]));
+ }
+  }
+  break;


Chema

El 21/05/18 a las 14:51, Karol Herbst escribió:
> Signed-off-by: Karol Herbst 
> ---
>  src/compiler/nir/nir_print.c | 22 ++
>  1 file changed, 22 insertions(+)
> 
> diff --git a/src/compiler/nir/nir_print.c b/src/compiler/nir/nir_print.c
> index 97b2d6164cd..e331a26d932 100644
> --- a/src/compiler/nir/nir_print.c
> +++ b/src/compiler/nir/nir_print.c
> @@ -299,6 +299,28 @@ print_constant(nir_constant *c, const struct glsl_type 
> *type, print_state *state
> unsigned i, j;
>  
> switch (glsl_get_base_type(type)) {
> +   case GLSL_TYPE_UINT8:
> +   case GLSL_TYPE_INT8:
> +  /* Only float base types can be matrices. */
> +  assert(cols == 1);
> +
> +  for (i = 0; i < rows; i++) {
> + if (i > 0) fprintf(fp, ", ");
> + fprintf(fp, "0x%02x", c->values[0].u8[i]);
> +  }
> +  break;
> +
> +   case GLSL_TYPE_UINT16:
> +   case GLSL_TYPE_INT16:
> +  /* Only float base types can be matrices. */
> +  assert(cols == 1);
> +
> +  for (i = 0; i < rows; i++) {
> + if (i > 0) fprintf(fp, ", ");
> + fprintf(fp, "0x%04x", c->values[0].u16[i]);
> +  }
> +  break;
> +
> case GLSL_TYPE_UINT:
> case GLSL_TYPE_INT:
> case GLSL_TYPE_BOOL:
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] r600/compute: Mark several functions as static

[Bruno Jimenez]

On Mon, 2018-05-21 at 09:34 -0500, Aaron Watry wrote:
> On Mon, May 21, 2018 at 9:34 AM, Aaron Watry 
> wrote:
> > On Mon, May 21, 2018 at 6:25 AM, Bruno Jimenez  > m> wrote:
> > > On Fri, 2018-05-18 at 22:52 -0400, Jan Vesely wrote:
> > > > On Fri, 2018-05-18 at 21:31 -0500, Aaron Watry wrote:
> > > > > On Fri, May 18, 2018 at 1:15 PM, Jan Vesely  > > > > rs.edu
> > > > > > wrote:
> > > > > > On Thu, 2018-05-17 at 19:20 -0500, Aaron Watry wrote:
> > > > > > > They're not used anywhere else, so keep them private
> > > > > > > 
> > > > > > > Signed-off-by: Aaron Watry 
> > > > > > 
> > > > > > I'm not sure what the original purpose of the removed
> > > > > > functions
> > > > > > was. If
> > > > > > you recall please add it to the commit message.
> > > > > 
> > > > > I didn't really bother looking into it when I made this
> > > > > change (I
> > > > > didn't write this code in the first place).  This is
> > > > > something that
> > > > > I've had sitting in my local repo for a while, and just want
> > > > > to
> > > > > stop
> > > > > rebasing it.
> > > > > 
> > > > > It was originally found a while ago when I started looking
> > > > > into the
> > > > > thread-safety (or lack thereof) of the compute pool for r600.
> > > > > Figured
> > > > > there was no point trying to fix code that was unused.
> > > > 
> > > > OK, nvm then. I was just curious how we ended up with so much
> > > > dead
> > > > code.
> > > 
> > > Hiya,
> > > 
> > > I can comment on that (mainly because I was the one who almost
> > > re-wrote
> > > the memory pool).
> > > 
> > > The reason is that I did most of these as a GSoC which started
> > > trying
> > > to fix a bug in the code that growth the pool when memory was
> > > needed
> > > and it continued with improving the pool. These functions are
> > > mostly
> > > remains from the original implementation. If I remember
> > > correctly, I
> > > sent a patch to remove them (and also a big patch which was a
> > > comment
> > > explaning how the pool worked and why it was like that) but it
> > > never
> > > got reviewed.
> > > 
> > > In fact, the implementation IS NOT complete as it lacks a path to
> > > unmap
> > > memory. I also had some patches for this, but as before, they
> > > never got
> > > reviewed...
> > 
> > I'm going to guess that this list contains some of the patches you
> > were talking about:
> > https://patchwork.freedesktop.org/project/mesa/list/?submitter=1166
> > 0&state=*
> > 
> > Especially the superseded ones. If you want to point them out, I
> > can
> > try either rebasing or (finally) reviewing them as appropriate.
> 
> And by superseded, I really meant "Not Applicable"... Too early.
> 
> --Aaron

Hi,

I'm afraid that those are not all the patches that I had... and as
said, I do not have access to the laptop where I believe they still
are.

Still, if you are interested in checking the pool, I can check the code
and tell you how it works, why it is like this and what is missing.

Best regards,
Bruno

> 
> > 
> > --Aaron
> > 
> > > 
> > > I might still have the patches in my old laptop, but I don't have
> > > access to it, sorry. Either way, I more or less remember how
> > > everything
> > > worked, although I don't have a way of testing it because I no
> > > longer
> > > have a computer with a R600 card.
> > > 
> > > If nothing breaks (compiling) you can have my
> > > 
> > > Reviewed-by: Bruno Jiménez 
> > > 
> > > If you need anything regarding this code, just ask and I'll see
> > > if I
> > > can dig up from my memory how it worked (and why)
> > > 
> > > Best Regards,
> > > Bruno
> > > 
> > > > 
> > > > > 
> > > > > > Either way:
> > > > > > 
> > > > > > Reviewed-by: Jan Vesely 
> > > > > 
> > > > > For this one, or both?
> > > > 
> > > > for the series.
> > > > 
> > > > thanks,
> > > > Jan
> > > > 
> > > > > 
> > > > > --Aaron
> > > > > 
> > > > > > 
> > > > > > Jan
> > > > > > 
> > > > > > > ---
> > > > > > >  .../drivers/r600/compute_memory_pool.c| 35
> > > > > > > +++
> > > > > > >  .../drivers/r600/compute_memory_pool.h| 24 ---
> > > > > > > --
> > > > > > > 
> > > > > > >  2 files changed, 29 insertions(+), 30 deletions(-)
> > > > > > > 
> > > > > > > diff --git
> > > > > > > a/src/gallium/drivers/r600/compute_memory_pool.c
> > > > > > > b/src/gallium/drivers/r600/compute_memory_pool.c
> > > > > > > index d1ef25ae1e..981d944b8d 100644
> > > > > > > --- a/src/gallium/drivers/r600/compute_memory_pool.c
> > > > > > > +++ b/src/gallium/drivers/r600/compute_memory_pool.c
> > > > > > > @@ -43,6 +43,29 @@
> > > > > > >  #include 
> > > > > > > 
> > > > > > >  #define ITEM_ALIGNMENT 1024
> > > > > > > +
> > > > > > > +/* A few forward declarations of static functions */
> > > > > > > +static void compute_memory_shadow(struct
> > > > > > > compute_memory_pool*
> > > > > > > pool,
> > > > > > > + struct pipe_context *pipe, int device_to_host);
> > > > > > > +
> > > > > > > +static void compute_memory_defrag(struct
> > > > > > 

Re: [Mesa-dev] [PATCH 3/3] mesa/main/shaderapi: purely non-functional cleanups, like whitespace errors and cleanups

[Ian Romanick]

On 05/10/2018 02:05 AM, Benedikt Schemmer wrote:
> remove a memset too and yes, this is all functionally identical
> 
> ---
>  src/mesa/main/shaderapi.c | 40 
>  1 file changed, 20 insertions(+), 20 deletions(-)
> 
> diff --git a/src/mesa/main/shaderapi.c b/src/mesa/main/shaderapi.c
> index e8acca4490..1d0ca5374b 100644
> --- a/src/mesa/main/shaderapi.c
> +++ b/src/mesa/main/shaderapi.c
> @@ -241,11 +241,10 @@ _mesa_init_shader_state(struct gl_context *ctx)
> /* Device drivers may override these to control what kind of instructions
>  * are generated by the GLSL compiler.
>  */
> -   struct gl_shader_compiler_options options;
> +   struct gl_shader_compiler_options options = {};
> gl_shader_stage sh;
> int i;
> 
> -   memset(&options, 0, sizeof(options));

This is not functionally the same.  The memset will zero padding fields
added by the compiler, but '= {}' does not.

I'm also not fond of the The '!= 0' and '== NULL' changes.  Pretty much
everywhere in core Mesa uses those patterns.

I feel like most of this is just a bunch of spurious changes that will
just make cherry picking patches to stable irritating later on.

> options.MaxUnrollIterations = 32;
> options.MaxIfDepth = UINT_MAX;
> 
> @@ -254,7 +253,7 @@ _mesa_init_shader_state(struct gl_context *ctx)
> 
> ctx->Shader.Flags = _mesa_get_shader_flags();
> 
> -   if (ctx->Shader.Flags != 0)
> +   if (ctx->Shader.Flags)
>ctx->Const.GenerateTemporaryNames = true;
> 
> /* Extended for ARB_separate_shader_objects */
> @@ -771,7 +770,8 @@ get_programiv(struct gl_context *ctx, GLuint program, 
> GLenum pname,
>GLint *params)
>  {
> struct gl_shader_program *shProg
> -  = _mesa_lookup_shader_program_err(ctx, program, 
> "glGetProgramiv(program)");
> +  = _mesa_lookup_shader_program_err(ctx, program,
> +"glGetProgramiv(program)");
> 
> /* Is transform feedback available in this context?
>  */
> @@ -953,7 +953,7 @@ get_programiv(struct gl_context *ctx, GLuint program, 
> GLenum pname,
>*params = shProg->BinaryRetreivableHint;
>return;
> case GL_PROGRAM_BINARY_LENGTH:
> -  if (ctx->Const.NumProgramBinaryFormats == 0) {
> +  if (!ctx->Const.NumProgramBinaryFormats) {
>   *params = 0;
>} else {
>   _mesa_get_program_binary_length(ctx, shProg, params);
> @@ -974,7 +974,7 @@ get_programiv(struct gl_context *ctx, GLuint program, 
> GLenum pname,
>   "linked)");
>   return;
>}
> -  if (shProg->_LinkedShaders[MESA_SHADER_COMPUTE] == NULL) {
> +  if (!shProg->_LinkedShaders[MESA_SHADER_COMPUTE]) {
>   _mesa_error(ctx, GL_INVALID_OPERATION, "glGetProgramiv(no compute "
>   "shaders)");
>   return;
> @@ -1234,7 +1234,7 @@ _mesa_compile_shader(struct gl_context *ctx, struct 
> gl_shader *sh)
> } else {
>if (ctx->_Shader->Flags & GLSL_DUMP) {
>   _mesa_log("GLSL source for %s shader %d:\n",
> - _mesa_shader_stage_to_string(sh->Stage), sh->Name);
> +   _mesa_shader_stage_to_string(sh->Stage), sh->Name);
>   _mesa_log("%s\n", sh->Source);
>}
> 
> @@ -1381,13 +1381,13 @@ link_program(struct gl_context *ctx, struct 
> gl_shader_program *shProg,
>GLuint i;
> 
>printf("Link %u shaders in program %u: %s\n",
> -   shProg->NumShaders, shProg->Name,
> -   shProg->data->LinkStatus ? "Success" : "Failed");
> + shProg->NumShaders, shProg->Name,
> + shProg->data->LinkStatus ? "Success" : "Failed");
> 
>for (i = 0; i < shProg->NumShaders; i++) {
>   printf(" shader %u, stage %u\n",
> -  shProg->Shaders[i]->Name,
> -  shProg->Shaders[i]->Stage);
> +shProg->Shaders[i]->Name,
> +shProg->Shaders[i]->Stage);
>}
> }
>  }
> @@ -1460,7 +1460,7 @@ void
>  _mesa_active_program(struct gl_context *ctx, struct gl_shader_program 
> *shProg,
>const char *caller)
>  {
> -   if ((shProg != NULL) && !shProg->data->LinkStatus) {
> +   if ((shProg) && !shProg->data->LinkStatus) {
>_mesa_error(ctx, GL_INVALID_OPERATION,
> "%s(program %u not linked)", caller, shProg->Name);
>return;
> @@ -1794,7 +1794,7 @@ void GLAPIENTRY
>  _mesa_GetObjectParameterfvARB(GLhandleARB object, GLenum pname,
>GLfloat *params)
>  {
> -   GLint iparams[1] = {0};  /* XXX is one element enough? */
> +   GLint iparams[1] = {};  /* XXX is one element enough? */
> _mesa_GetObjectParameterivARB(object, pname, iparams);
> params[0] = (GLfloat) iparams[0];
>  }
> @@ -1912,7 +1912,7 @@ shader_source(struct gl_context *ctx, GLuint shaderObj, 
> GLsizei count,
>if (!sh)
>   return;
> 
> -  if (string == NULL) {

Re: [Mesa-dev] [PATCH 1/2] glsl: always enable OES_standard_derivatives features if supported

[Ian Romanick]

On 05/16/2018 12:04 AM, Timothy Arceri wrote:
> The GLSL ES 1.0 spec made these features optional. With
> OES_standard_derivatives they are guaranteed to be available
> but currently the extension must be enabled to use them.
> 
> Instead this changes the code to check if the driver supports
> the extension and if so always enables them.
> 
> This fixes compiler errors in Google Earth VR.

This sounds like a bug in Google Earth VR.  Has anyone reported it to them?

> ---
>  src/compiler/glsl/builtin_functions.cpp | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/compiler/glsl/builtin_functions.cpp 
> b/src/compiler/glsl/builtin_functions.cpp
> index e1ee9943172..1ecbdc98404 100644
> --- a/src/compiler/glsl/builtin_functions.cpp
> +++ b/src/compiler/glsl/builtin_functions.cpp
> @@ -446,7 +446,7 @@ fs_oes_derivatives(const _mesa_glsl_parse_state *state)
>  {
> return state->stage == MESA_SHADER_FRAGMENT &&
>(state->is_version(110, 300) ||
> -   state->OES_standard_derivatives_enable);
> +   state->extensions->OES_standard_derivatives);
>  }
>  
>  static bool
> 

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

Re: [Mesa-dev] [PATCH 2/2] radv: fix computation of user sgprs for 32-bit pointers

[Bas Nieuwenhuizen]

Reviewed-by: Bas Nieuwenhuizen 

On Mon, May 21, 2018 at 4:57 PM, Samuel Pitoiset
 wrote:
> With 32-bit pointers we only need one user SGPR per desc set.
>
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/amd/vulkan/radv_nir_to_llvm.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/src/amd/vulkan/radv_nir_to_llvm.c 
> b/src/amd/vulkan/radv_nir_to_llvm.c
> index c6063dca6c8..54a3d7c1878 100644
> --- a/src/amd/vulkan/radv_nir_to_llvm.c
> +++ b/src/amd/vulkan/radv_nir_to_llvm.c
> @@ -694,8 +694,10 @@ static void allocate_user_sgprs(struct 
> radv_shader_context *ctx,
>
> uint32_t available_sgprs = ctx->options->chip_class >= GFX9 ? 32 : 16;
> uint32_t remaining_sgprs = available_sgprs - user_sgpr_count;
> +   uint32_t num_desc_set =
> +   util_bitcount(ctx->shader_info->info.desc_set_used_mask);
>
> -   if (remaining_sgprs / 2 < 
> util_bitcount(ctx->shader_info->info.desc_set_used_mask)) {
> +   if (remaining_sgprs / (HAVE_32BIT_POINTERS ? 1 : 2) < num_desc_set) {
> user_sgpr_info->indirect_all_descriptor_sets = true;
> }
>  }
> --
> 2.17.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC PATCH 1/3] mesa/main/extensions: make constants slightly more expressive and adjust layout

[Ian Romanick]

I'm not in favor of this patch.  The lines in this file are already
annoyingly long.  I don't think making them longer helps.

On 05/19/2018 06:18 AM, Benedikt Schemmer wrote:
> This just makes the constants more descriptive
> 
> CC: "Marek Olšák"  
> CC: Eric Anholt 
> CC: Emil Velikov 
> CC: Timothy Arceri 
> CC: Ilia Mirkin 
> 
> Signed-off-by: Benedikt Schemmer 
> ---
>  src/mesa/main/extensions_table.h | 833 
> ---
>  1 file changed, 417 insertions(+), 416 deletions(-)
> 
> diff --git a/src/mesa/main/extensions_table.h 
> b/src/mesa/main/extensions_table.h
> index ffb1caccdd..931e0d4d33 100644
> --- a/src/mesa/main/extensions_table.h
> +++ b/src/mesa/main/extensions_table.h
> @@ -1,439 +1,440 @@
>  /* The extension table is alphabetically sorted by the extension name string 
> column. */
>  
> -#define GLL 0
> -#define GLC 0
> -#define ES1 0
> -#define ES2 0
> -#define  x ~0
> +#define ANYGLL 0
> +#define ANYGLC 0
> +#define ANYES1 0
> +#define ANYES2 0
> +#define   x   ~0
>  
> -EXT(3DFX_texture_compression_FXT1   , TDFX_texture_compression_FXT1  
> , GLL, GLC,  x ,  x , 1999)
> +//EXT(name_str  , driver_cap 
> ,GLL_ver,GLC_ver, gles_ver, glES2_ver, )
> +EXT(3DFX_texture_compression_FXT1   , TDFX_texture_compression_FXT1  
> , ANYGLL, ANYGLC,   x   ,   x   , 1999)
>  
> -EXT(AMD_conservative_depth  , ARB_conservative_depth 
> , GLL, GLC,  x ,  x , 2009)
> -EXT(AMD_draw_buffers_blend  , ARB_draw_buffers_blend 
> , GLL, GLC,  x ,  x , 2009)
> -EXT(AMD_performance_monitor , AMD_performance_monitor
> , GLL, GLC,  x ,  x , 2007)
> -EXT(AMD_pinned_memory   , AMD_pinned_memory  
> , GLL, GLC,  x ,  x , 2013)
> -EXT(AMD_seamless_cubemap_per_texture, 
> AMD_seamless_cubemap_per_texture   , GLL, GLC,  x ,  x , 2009)
> -EXT(AMD_shader_stencil_export   , ARB_shader_stencil_export  
> , GLL, GLC,  x ,  x , 2009)
> -EXT(AMD_shader_trinary_minmax   , dummy_true 
> , GLL, GLC,  x ,  x , 2012)
> -EXT(AMD_vertex_shader_layer , AMD_vertex_shader_layer
> ,  x , GLC,  x ,  x , 2012)
> -EXT(AMD_vertex_shader_viewport_index, 
> AMD_vertex_shader_viewport_index   ,  x , GLC,  x ,  x , 2012)
> +EXT(AMD_conservative_depth  , ARB_conservative_depth 
> , ANYGLL, ANYGLC,   x   ,   x   , 2009)
> +EXT(AMD_draw_buffers_blend  , ARB_draw_buffers_blend 
> , ANYGLL, ANYGLC,   x   ,   x   , 2009)
> +EXT(AMD_performance_monitor , AMD_performance_monitor
> , ANYGLL, ANYGLC,   x   ,   x   , 2007)
> +EXT(AMD_pinned_memory   , AMD_pinned_memory  
> , ANYGLL, ANYGLC,   x   ,   x   , 2013)
> +EXT(AMD_seamless_cubemap_per_texture, 
> AMD_seamless_cubemap_per_texture   , ANYGLL, ANYGLC,   x   ,   x   , 2009)
> +EXT(AMD_shader_stencil_export   , ARB_shader_stencil_export  
> , ANYGLL, ANYGLC,   x   ,   x   , 2009)
> +EXT(AMD_shader_trinary_minmax   , dummy_true 
> , ANYGLL, ANYGLC,   x   ,   x   , 2012)
> +EXT(AMD_vertex_shader_layer , AMD_vertex_shader_layer
> ,   x   , ANYGLC,   x   ,   x   , 2012)
> +EXT(AMD_vertex_shader_viewport_index, 
> AMD_vertex_shader_viewport_index   ,   x   , ANYGLC,   x   ,   x   , 2012)
>  
> -EXT(ANDROID_extension_pack_es31a, ANDROID_extension_pack_es31a   
> ,  x ,  x ,  x ,  31, 2014)
> +EXT(ANDROID_extension_pack_es31a, ANDROID_extension_pack_es31a   
> ,   x   ,   x   ,   x   ,  31   , 2014)
>  
> -EXT(ANGLE_texture_compression_dxt3  , ANGLE_texture_compression_dxt  
> , GLL, GLC, ES1, ES2, 2011)
> -EXT(ANGLE_texture_compression_dxt5  , ANGLE_texture_compression_dxt  
> , GLL, GLC, ES1, ES2, 2011)
> +EXT(ANGLE_texture_compression_dxt3  , ANGLE_texture_compression_dxt  
> , ANYGLL, ANYGLC, ANYES1, ANYES2, 2011)
> +EXT(ANGLE_texture_compression_dxt5  , ANGLE_texture_compression_dxt  
> , ANYGLL, ANYGLC, ANYES1, ANYES2, 2011)
>  
> -EXT(APPLE_object_purgeable  , APPLE_object_purgeable 
> , GLL, GLC,  x ,  x , 2006)
> -EXT(APPLE_packed_pixels , dummy_true 
> , GLL,  x ,  x ,  x , 2002)
> -EXT(APPLE_texture_max_level , dummy_true 
> ,  x ,  x , ES1, ES2, 2009)
> +EXT(APPLE_object_purgeable  , APPLE_object_purgeable 
> , ANYGLL, ANYGLC,   x   ,   x   , 2006)
> +EXT(APPLE_packed_pixels , dummy_true 

Re: [Mesa-dev] [RFC] glsl: bump default glsl version to 130 if EXT_gpu_shader4 used

[Ian Romanick]

On 05/15/2018 04:41 PM, Marek Olšák wrote:
> On Tue, May 15, 2018 at 4:59 PM, Jason Ekstrand  > wrote:
> 
> On Tue, May 15, 2018 at 1:38 PM, Marek Olšák  > wrote:
> 
> On Tue, May 15, 2018 at 4:09 PM, Ilia Mirkin
> mailto:imir...@alum.mit.edu>> wrote:
> 
> On Tue, May 15, 2018 at 3:54 PM, Marek Olšák
> mailto:mar...@gmail.com>> wrote:
> > On Tue, May 15, 2018 at 3:36 PM, Ilia Mirkin 
> mailto:imir...@alum.mit.edu>> wrote:
> >>
> >> The extension is totally different... it adds things like 
> "unsigned
> >> int", and a ton of texture*/shadow* variants. If it helps this 
> one
> >> shader compile, that's a coincidence. IMO it's dangerous to 
> start
> >> throwing things like this in.
> >
> >
> > That's why it prints a warning. The extension isn't exposed.
> 
> It bumps the GLSL version to 1.30 though, which e.g. makes
> "in" and
> "out" a keyword. And a bunch of other stuff like that. Just
> seems
> dangerous.
> 
> 
> It may seem dangerous, but not after you consider that it
> changes a compile failure into "some behavior" and a warning.
> That is pretty safe, because you'll either get a compile failure
> again, or you'll get correct behavior as if a subset of the
> extension was exposed. Either case is harmless.
> 
> 
> This does seem really sketchy.  It's a spec violation because we are
> required to fail the shader compile for unknown extensions.  And
> it's letting a shader through even though we know it's likely to die
> in a fire later on due to the fact that we only implement 30% of
> gpu_shader4.  On top of that, the best justification we can come up
> with is a broken app that assumes gpu_shader4 but doesn't actually
> use it.
> 
> 
> The best justification that we actually have is that there is an app
> which uses GLSL 1.20 + EXT_gpu_shader4 but actually only needs GLSL 1.30.

The phrase "fix your app" comes to mind.

I am strongly not in favor of this patch.

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

Re: [Mesa-dev] [RFC PATCH] gallium: add interface for advanced MSAA

[Axel Davy]

Hi,

I get the impression when looking at online documentation about EQAA and 
CSAA, like

http://www.nvidia.fr/object/coverage-sampled-aa.html

that the number of stored samples is the same for the color and depth 
buffers.

Only the samples used for coverage is greater.

With your proposal, isn't the number of samples stored in the depth 
buffer always the same than the number of samples used for coverage ?
That reduces the use-cases. In nine, we have to enforce the number of 
stored samples to be the same for the color and the depth buffer, but we 
could increase the number of samples used for coverage and enable 
EQAA/CSAA (in fact there is a similar way to advertise the feature for 
Nvidia and Amd).


But maybe I misunderstood.

Yours,

Axel Davy

On 18/05/2018 06:05, Marek Olšák wrote:

From: Marek Olšák 

The interface only uses general MSAA terms, so it's "advanced MSAA" and not
something vendor-specific.

It's a proper subset of EQAA, and a proper superset of CSAA, so it's neither.

Changes:
- pipe_resource is changed
- is_format_supported is changed
- a new CAP is added
---
  src/gallium/docs/source/screen.rst   | 31 ++--
  src/gallium/include/pipe/p_defines.h |  1 +
  src/gallium/include/pipe/p_screen.h  |  1 +
  src/gallium/include/pipe/p_state.h   | 18 +---
  4 files changed, 46 insertions(+), 5 deletions(-)

diff --git a/src/gallium/docs/source/screen.rst 
b/src/gallium/docs/source/screen.rst
index 5bc6ee99f08..cf4787a1c49 100644
--- a/src/gallium/docs/source/screen.rst
+++ b/src/gallium/docs/source/screen.rst
@@ -398,20 +398,25 @@ The integer capabilities:
  * ``PIPE_CAP_LOAD_CONSTBUF``: True if the driver supports TGSI_OPCODE_LOAD use
with constant buffers.
  * ``PIPE_CAP_TGSI_ANY_REG_AS_ADDRESS``: Any TGSI register can be used as
an address for indirect register indexing.
  * ``PIPE_CAP_TILE_RASTER_ORDER``: Whether the driver supports
GL_MESA_tile_raster_order, using the tile_raster_order_* fields in
pipe_rasterizer_state.
  * ``PIPE_CAP_MAX_COMBINED_SHADER_OUTPUT_RESOURCES``: Limit on combined shader
output resources (images + buffers + fragment outputs). If 0 the state
tracker works it out.
+* ``PIPE_CAP_FRAMEBUFFER_MIXED_SAMPLES``: Framebuffer attachments can have
+  different number of samples each with the following restriction:
+ color.nr_samples >= zs.nr_samples >= color.nr_storage_samples
+  If 0 is returned, the following restriction applies:
+ color.nr_samples == zs.nr_samples >= color.nr_storage_samples
  * ``PIPE_CAP_SIGNED_VERTEX_BUFFER_OFFSET``:
Whether pipe_vertex_buffer::buffer_offset is treated as signed. The u_vbuf
module needs this for optimal performance in workstation applications.
  * ``PIPE_CAP_CONTEXT_PRIORITY_MASK``: For drivers that support per-context
priorities, this returns a bitmask of PIPE_CONTEXT_PRIORITY_x for the
supported priority levels.  A driver that does not support prioritized
contexts can return 0.
  * ``PIPE_CAP_FENCE_SIGNAL``: True if the driver supports signaling semaphores
using fence_server_signal().
  * ``PIPE_CAP_CONSTBUF0_FLAGS``: The bits of pipe_resource::flags that must be
@@ -718,20 +723,23 @@ is_format_supported
  
  Determine if a resource in the given format can be used in a specific manner.
  
  **format** the resource format
  
  **target** one of the PIPE_TEXTURE_x flags
  
  **sample_count** the number of samples. 0 and 1 mean no multisampling,

  the maximum allowed legal value is 32.
  
+**storage_sample_count** the number of storage samples. This must be <=

+sample_count. See the documentation of ``pipe_resource::nr_storage_samples``.
+
  **bindings** is a bitmask of :ref:`PIPE_BIND` flags.
  
  Returns TRUE if all usages can be satisfied.
  
  
  can_create_resource

  ^^^
  
  Check if a resource can actually be created (but don't actually allocate any

  memory).  This is used to implement OpenGL's proxy textures.  Typically, a
@@ -761,22 +769,41 @@ Modern APIs allow using buffers as shader resources.
  (1 for 1D or 1D array textures).
  
  **depth0** the depth of the base mip level of the texture

  (1 for everything else).
  
  **array_size** the array size for 1D and 2D array textures.

  For cube maps this must be 6, for other textures 1.
  
  **last_level** the last mip map level present.
  
-**nr_samples** the nr of msaa samples. 0 (or 1) specifies a resource

-which isn't multisampled.
+**nr_samples**: Number of samples determining quality, driving the rasterizer,
+shading, and framebuffer. It is the number of samples seen by the whole
+graphics pipeline. 0 and 1 specify a resource which isn't multisampled.
+
+**nr_storage_samples**: Only color buffers can set this lower than nr_samples.
+Multiple samples within a pixel can have the same color. ``nr_storage_samples``
+determines how many slots for different colors there are per pixel.
+If there are not enough slots to store all sample colors, some samples will

[Mesa-dev] [Bug 77449] Tracker bug for all bugs related to Steam titles

[bugzilla-daemon]

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

Kai  changed:

   What|Removed |Added

 Depends on||106594


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=106594
[Bug 106594] [radeonsi,regression,apitrace] Prison Architect exhibits glitches
-- 
You are receiving this mail because:
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC PATCH] gallium: add interface for advanced MSAA

[Roland Scheidegger]

This looks reasonable to me.

Roland

Am 18.05.2018 um 06:05 schrieb Marek Olšák:
> From: Marek Olšák 
> 
> The interface only uses general MSAA terms, so it's "advanced MSAA" and not
> something vendor-specific.
> 
> It's a proper subset of EQAA, and a proper superset of CSAA, so it's neither.
> 
> Changes:
> - pipe_resource is changed
> - is_format_supported is changed
> - a new CAP is added
> ---
>  src/gallium/docs/source/screen.rst   | 31 ++--
>  src/gallium/include/pipe/p_defines.h |  1 +
>  src/gallium/include/pipe/p_screen.h  |  1 +
>  src/gallium/include/pipe/p_state.h   | 18 +---
>  4 files changed, 46 insertions(+), 5 deletions(-)
> 
> diff --git a/src/gallium/docs/source/screen.rst 
> b/src/gallium/docs/source/screen.rst
> index 5bc6ee99f08..cf4787a1c49 100644
> --- a/src/gallium/docs/source/screen.rst
> +++ b/src/gallium/docs/source/screen.rst
> @@ -398,20 +398,25 @@ The integer capabilities:
>  * ``PIPE_CAP_LOAD_CONSTBUF``: True if the driver supports TGSI_OPCODE_LOAD 
> use
>with constant buffers.
>  * ``PIPE_CAP_TGSI_ANY_REG_AS_ADDRESS``: Any TGSI register can be used as
>an address for indirect register indexing.
>  * ``PIPE_CAP_TILE_RASTER_ORDER``: Whether the driver supports
>GL_MESA_tile_raster_order, using the tile_raster_order_* fields in
>pipe_rasterizer_state.
>  * ``PIPE_CAP_MAX_COMBINED_SHADER_OUTPUT_RESOURCES``: Limit on combined shader
>output resources (images + buffers + fragment outputs). If 0 the state
>tracker works it out.
> +* ``PIPE_CAP_FRAMEBUFFER_MIXED_SAMPLES``: Framebuffer attachments can have
> +  different number of samples each with the following restriction:
> + color.nr_samples >= zs.nr_samples >= color.nr_storage_samples
> +  If 0 is returned, the following restriction applies:
> + color.nr_samples == zs.nr_samples >= color.nr_storage_samples
>  * ``PIPE_CAP_SIGNED_VERTEX_BUFFER_OFFSET``:
>Whether pipe_vertex_buffer::buffer_offset is treated as signed. The u_vbuf
>module needs this for optimal performance in workstation applications.
>  * ``PIPE_CAP_CONTEXT_PRIORITY_MASK``: For drivers that support per-context
>priorities, this returns a bitmask of PIPE_CONTEXT_PRIORITY_x for the
>supported priority levels.  A driver that does not support prioritized
>contexts can return 0.
>  * ``PIPE_CAP_FENCE_SIGNAL``: True if the driver supports signaling semaphores
>using fence_server_signal().
>  * ``PIPE_CAP_CONSTBUF0_FLAGS``: The bits of pipe_resource::flags that must be
> @@ -718,20 +723,23 @@ is_format_supported
>  
>  Determine if a resource in the given format can be used in a specific manner.
>  
>  **format** the resource format
>  
>  **target** one of the PIPE_TEXTURE_x flags
>  
>  **sample_count** the number of samples. 0 and 1 mean no multisampling,
>  the maximum allowed legal value is 32.
>  
> +**storage_sample_count** the number of storage samples. This must be <=
> +sample_count. See the documentation of ``pipe_resource::nr_storage_samples``.
> +
>  **bindings** is a bitmask of :ref:`PIPE_BIND` flags.
>  
>  Returns TRUE if all usages can be satisfied.
>  
>  
>  can_create_resource
>  ^^^
>  
>  Check if a resource can actually be created (but don't actually allocate any
>  memory).  This is used to implement OpenGL's proxy textures.  Typically, a
> @@ -761,22 +769,41 @@ Modern APIs allow using buffers as shader resources.
>  (1 for 1D or 1D array textures).
>  
>  **depth0** the depth of the base mip level of the texture
>  (1 for everything else).
>  
>  **array_size** the array size for 1D and 2D array textures.
>  For cube maps this must be 6, for other textures 1.
>  
>  **last_level** the last mip map level present.
>  
> -**nr_samples** the nr of msaa samples. 0 (or 1) specifies a resource
> -which isn't multisampled.
> +**nr_samples**: Number of samples determining quality, driving the 
> rasterizer,
> +shading, and framebuffer. It is the number of samples seen by the whole
> +graphics pipeline. 0 and 1 specify a resource which isn't multisampled.
> +
> +**nr_storage_samples**: Only color buffers can set this lower than 
> nr_samples.
> +Multiple samples within a pixel can have the same color. 
> ``nr_storage_samples``
> +determines how many slots for different colors there are per pixel.
> +If there are not enough slots to store all sample colors, some samples will
> +have an undefined color (called "undefined samples").
> +
> +The resolve blit behavior is driver-specific, but can be one of these two:
> +1. Only defined samples will be averaged. Undefined samples will be ignored.
> +2. Undefined samples will be approximated by looking at surrounding defined
> +   samples (even in different pixels).
> +
> +Blits and MSAA texturing: If the sample being fetched is undefined, one of
> +the defined samples is returned instead.
> +
> +Sample shading (``set_min_samples``) will operate at a sample frequency that
> +is at most ``nr_storage_samples

Re: [Mesa-dev] [PATCH 02/19] intel/fs: Use groups for SIMD16 LINTERP on gen11+

[Kenneth Graunke]

On Monday, May 21, 2018 7:04:39 AM PDT Jason Ekstrand wrote:
> On May 20, 2018 23:45:27 Kenneth Graunke  wrote:
> 
> > On Friday, May 18, 2018 4:35:15 PM PDT Jason Ekstrand wrote:
> >> This is better than compression control because it naturally extends to
> >> SIMD32.
> >> ---
> >> src/intel/compiler/brw_fs_generator.cpp | 6 ++
> >> 1 file changed, 2 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/src/intel/compiler/brw_fs_generator.cpp 
> >> b/src/intel/compiler/brw_fs_generator.cpp
> >> index 0c050a7..f435f97 100644
> >> --- a/src/intel/compiler/brw_fs_generator.cpp
> >> +++ b/src/intel/compiler/brw_fs_generator.cpp
> >> @@ -795,16 +795,14 @@ fs_generator::generate_linterp(fs_inst *inst,
> >>   */
> >>  brw_inst_set_saturate(p->devinfo, i[0], false);
> >> } else {
> >> - brw_set_default_compression_control(p, BRW_COMPRESSION_NONE);
> >> + brw_set_default_group(p, inst->group);
> >>  i[0] = brw_MAD(p,acc, dwR, offset(delta_x, 0), dwP);
> >>  i[1] = brw_MAD(p, offset(dst, 0), acc, offset(delta_x, 1), dwQ);
> >>
> >> - brw_set_default_compression_control(p, BRW_COMPRESSION_2NDHALF);
> >> + brw_set_default_group(p, inst->group + 8);
> >>  i[2] = brw_MAD(p,acc, dwR, offset(delta_y, 0), dwP);
> >>  i[3] = brw_MAD(p, offset(dst, 1), acc, offset(delta_y, 1), dwQ);
> >>
> >> - brw_set_default_compression_control(p, 
> >> BRW_COMPRESSION_COMPRESSED);
> >> -
> >>  brw_inst_set_cond_modifier(p->devinfo, i[1], inst->conditional_mod);
> >>  brw_inst_set_cond_modifier(p->devinfo, i[3], inst->conditional_mod);
> >
> > The last hunk you dropped is supposed to restore the original state, so
> > subsequent things continue working...I think you either want to change
> > it to brw_set_default_group(inst->group)...or push/pop the state around
> > this whole section...
> 
> It's not needed because no more instructions get emitted and we push/pop 
> around the giant generator switch anyway.  Still, I guess it doesn't hurt 
> to push/pop over extra time.

Mmm, yeah...but we do push/pop around most other sections that
temporarily whack something.  It's probably fine as is, but I think
it would be clearer to add it explicitly around this block.

With that change,
Reviewed-by: Kenneth Graunke 


signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2/2] radv: fix computation of user sgprs for 32-bit pointers

[Samuel Pitoiset]

With 32-bit pointers we only need one user SGPR per desc set.

Signed-off-by: Samuel Pitoiset 
---
 src/amd/vulkan/radv_nir_to_llvm.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/amd/vulkan/radv_nir_to_llvm.c 
b/src/amd/vulkan/radv_nir_to_llvm.c
index c6063dca6c8..54a3d7c1878 100644
--- a/src/amd/vulkan/radv_nir_to_llvm.c
+++ b/src/amd/vulkan/radv_nir_to_llvm.c
@@ -694,8 +694,10 @@ static void allocate_user_sgprs(struct radv_shader_context 
*ctx,
 
uint32_t available_sgprs = ctx->options->chip_class >= GFX9 ? 32 : 16;
uint32_t remaining_sgprs = available_sgprs - user_sgpr_count;
+   uint32_t num_desc_set =
+   util_bitcount(ctx->shader_info->info.desc_set_used_mask);
 
-   if (remaining_sgprs / 2 < 
util_bitcount(ctx->shader_info->info.desc_set_used_mask)) {
+   if (remaining_sgprs / (HAVE_32BIT_POINTERS ? 1 : 2) < num_desc_set) {
user_sgpr_info->indirect_all_descriptor_sets = true;
}
 }
-- 
2.17.0

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

[Mesa-dev] [PATCH 1/2] radv: drop user_sgpr_info::sgpr_count

[Samuel Pitoiset]

It's only used inside allocate_user_sgprs().

Signed-off-by: Samuel Pitoiset 
---
 src/amd/vulkan/radv_nir_to_llvm.c | 24 +++-
 1 file changed, 11 insertions(+), 13 deletions(-)

diff --git a/src/amd/vulkan/radv_nir_to_llvm.c 
b/src/amd/vulkan/radv_nir_to_llvm.c
index 10114cbe187..c6063dca6c8 100644
--- a/src/amd/vulkan/radv_nir_to_llvm.c
+++ b/src/amd/vulkan/radv_nir_to_llvm.c
@@ -588,7 +588,6 @@ set_loc_desc(struct radv_shader_context *ctx, int idx,  
uint8_t *sgpr_idx,
 
 struct user_sgpr_info {
bool need_ring_offsets;
-   uint8_t sgpr_count;
bool indirect_all_descriptor_sets;
 };
 
@@ -635,6 +634,8 @@ static void allocate_user_sgprs(struct radv_shader_context 
*ctx,
bool needs_view_index,
struct user_sgpr_info *user_sgpr_info)
 {
+   uint8_t user_sgpr_count = 0;
+
memset(user_sgpr_info, 0, sizeof(struct user_sgpr_info));
 
/* until we sort out scratch/global buffers always assign ring offsets 
for gs/vs/es */
@@ -651,25 +652,25 @@ static void allocate_user_sgprs(struct 
radv_shader_context *ctx,
 
/* 2 user sgprs will nearly always be allocated for scratch/rings */
if (ctx->options->supports_spill || user_sgpr_info->need_ring_offsets) {
-   user_sgpr_info->sgpr_count += 2;
+   user_sgpr_count += 2;
}
 
switch (stage) {
case MESA_SHADER_COMPUTE:
if (ctx->shader_info->info.cs.uses_grid_size)
-   user_sgpr_info->sgpr_count += 3;
+   user_sgpr_count += 3;
break;
case MESA_SHADER_FRAGMENT:
-   user_sgpr_info->sgpr_count += 
ctx->shader_info->info.ps.needs_sample_positions;
+   user_sgpr_count += 
ctx->shader_info->info.ps.needs_sample_positions;
break;
case MESA_SHADER_VERTEX:
if (!ctx->is_gs_copy_shader)
-   user_sgpr_info->sgpr_count += count_vs_user_sgprs(ctx);
+   user_sgpr_count += count_vs_user_sgprs(ctx);
break;
case MESA_SHADER_TESS_CTRL:
if (has_previous_stage) {
if (previous_stage == MESA_SHADER_VERTEX)
-   user_sgpr_info->sgpr_count += 
count_vs_user_sgprs(ctx);
+   user_sgpr_count += count_vs_user_sgprs(ctx);
}
break;
case MESA_SHADER_TESS_EVAL:
@@ -677,7 +678,7 @@ static void allocate_user_sgprs(struct radv_shader_context 
*ctx,
case MESA_SHADER_GEOMETRY:
if (has_previous_stage) {
if (previous_stage == MESA_SHADER_VERTEX) {
-   user_sgpr_info->sgpr_count += 
count_vs_user_sgprs(ctx);
+   user_sgpr_count += count_vs_user_sgprs(ctx);
}
}
break;
@@ -686,19 +687,16 @@ static void allocate_user_sgprs(struct 
radv_shader_context *ctx,
}
 
if (needs_view_index)
-   user_sgpr_info->sgpr_count++;
+   user_sgpr_count++;
 
if (ctx->shader_info->info.loads_push_constants)
-   user_sgpr_info->sgpr_count += HAVE_32BIT_POINTERS ? 1 : 2;
+   user_sgpr_count += HAVE_32BIT_POINTERS ? 1 : 2;
 
uint32_t available_sgprs = ctx->options->chip_class >= GFX9 ? 32 : 16;
-   uint32_t remaining_sgprs = available_sgprs - user_sgpr_info->sgpr_count;
+   uint32_t remaining_sgprs = available_sgprs - user_sgpr_count;
 
if (remaining_sgprs / 2 < 
util_bitcount(ctx->shader_info->info.desc_set_used_mask)) {
-   user_sgpr_info->sgpr_count += HAVE_32BIT_POINTERS ? 1 : 2;
user_sgpr_info->indirect_all_descriptor_sets = true;
-   } else {
-   user_sgpr_info->sgpr_count += 
util_bitcount(ctx->shader_info->info.desc_set_used_mask) * 2;
}
 }
 
-- 
2.17.0

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

[Mesa-dev] [Bug 106479] NDEBUG not defined for libamdgpu_addrlib

[bugzilla-daemon]

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

Bas Nieuwenhuizen  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO

--- Comment #1 from Bas Nieuwenhuizen  ---
The NDEBUG issue has been fixed in the latest git.

Could you give more information on how to reproduce the assert so that we also
have a chance to fix it?

Alternatively a full backtrace with debug symbols would also be very much
appreciated.

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

[Mesa-dev] [Bug 106479] NDEBUG not defined for libamdgpu_addrlib

[bugzilla-daemon]

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

Bas Nieuwenhuizen  changed:

   What|Removed |Added

  Component|Mesa core   |Drivers/Vulkan/radeon

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

[Mesa-dev] [Bug 106511] radv: MSAA broken on SI (assertion failure in vkCreateImage)

[bugzilla-daemon]

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

--- Comment #2 from Bas Nieuwenhuizen  ---
This should be fixed with

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

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

Re: [Mesa-dev] [PATCH 4/5] egl/wayland: Allow client->server format conversion for PRIME offload.

[Eric Engestrom]

On Saturday, 2018-05-19 05:32:41 +0200, Mario Kleiner wrote:
> Support PRIME render offload between a Wayland server gpu and a Wayland
> client gpu with different channel ordering for their color formats,
> e.g., between Intel drivers which currently only support ARGB2101010
> and XRGB2101010 import/display and nouveau which only supports ABGR2101010
> rendering and display on nv-50 and later.
> 
> In the wl_visuals table, we also store for each format an alternate
> sibling format which stores colors at the same precision, but with
> different channel ordering, e.g., ARGB2101010 <-> ABGR2101010.
> 
> If a given client-gpu renderable format is not supported by the server
> for import, but the alternate format is supported by the server, expose
> the client-gpu renderable format as a valid EGLConfig to the client. At
> eglSwapBuffers time, during the blitImage() detiling blit from the client
> backbuffer to the linear buffer, the client format is converted to the
> server supported format. As we have to do a copy for PRIME anyway,
> this channel swizzling conversion comes essentially for free.
> 
> Note that even if a server gpu in principle does support sampling
> from the clients native format, this conversion will be a performance
> advantage if it allows to convert to the servers preferred format
> for direct scanout, as the Wayland compositor may then be able to
> directly page-flip a fullscreen client wl_buffer onto the primary
> plane, or onto a hardware overlay plane, avoiding an extra data copy
> for desktop composition.
> 
> Tested so far under Weston with: nouveau single-gpu, Intel single-gpu,
> AMD single-gpu, "Optimus" Intel server iGPU for display + NVidia
> client dGPU for rendering.
> 
> Signed-off-by: Mario Kleiner 
> Cc: Daniel Stone 
> ---
>  src/egl/drivers/dri2/platform_wayland.c | 67 
> -
>  1 file changed, 58 insertions(+), 9 deletions(-)
> 
> diff --git a/src/egl/drivers/dri2/platform_wayland.c 
> b/src/egl/drivers/dri2/platform_wayland.c
> index 89a7f90118..fb364a6233 100644
> --- a/src/egl/drivers/dri2/platform_wayland.c
> +++ b/src/egl/drivers/dri2/platform_wayland.c
> @@ -68,49 +68,50 @@ static const struct dri2_wl_visual {
> uint32_t wl_drm_format;
> uint32_t wl_shm_format;
> int dri_image_format;
> +   int alt_dri_image_format;

A comment here wouldn't hurt, to explain what this "alt" is to someone
who sees the code after it landed :)

> int bpp;
> unsigned int rgba_masks[4];
>  } dri2_wl_visuals[] = {
> {
>   "XRGB2101010",
>   WL_DRM_FORMAT_XRGB2101010, WL_SHM_FORMAT_XRGB2101010,
> - __DRI_IMAGE_FORMAT_XRGB2101010, 32,
> + __DRI_IMAGE_FORMAT_XRGB2101010, __DRI_IMAGE_FORMAT_XBGR2101010, 32,
>   { 0x3ff0, 0x000ffc00, 0x03ff, 0x }
> },
> {
>   "ARGB2101010",
>   WL_DRM_FORMAT_ARGB2101010, WL_SHM_FORMAT_ARGB2101010,
> - __DRI_IMAGE_FORMAT_ARGB2101010, 32,
> + __DRI_IMAGE_FORMAT_ARGB2101010, __DRI_IMAGE_FORMAT_ABGR2101010, 32,
>   { 0x3ff0, 0x000ffc00, 0x03ff, 0xc000 }
> },
> {
>   "XBGR2101010",
>   WL_DRM_FORMAT_XBGR2101010, WL_SHM_FORMAT_XBGR2101010,
> - __DRI_IMAGE_FORMAT_XBGR2101010, 32,
> + __DRI_IMAGE_FORMAT_XBGR2101010, __DRI_IMAGE_FORMAT_XRGB2101010, 32,
>   { 0x03ff, 0x000ffc00, 0x3ff0, 0x }
> },
> {
>   "ABGR2101010",
>   WL_DRM_FORMAT_ABGR2101010, WL_SHM_FORMAT_ABGR2101010,
> - __DRI_IMAGE_FORMAT_ABGR2101010, 32,
> + __DRI_IMAGE_FORMAT_ABGR2101010, __DRI_IMAGE_FORMAT_ARGB2101010, 32,
>   { 0x03ff, 0x000ffc00, 0x3ff0, 0xc000 }
> },
> {
>   "XRGB",
>   WL_DRM_FORMAT_XRGB, WL_SHM_FORMAT_XRGB,
> - __DRI_IMAGE_FORMAT_XRGB, 32,
> + __DRI_IMAGE_FORMAT_XRGB, __DRI_IMAGE_FORMAT_NONE, 32,
>   { 0x00ff, 0xff00, 0x00ff, 0x }
> },
> {
>   "ARGB",
>   WL_DRM_FORMAT_ARGB, WL_SHM_FORMAT_ARGB,
> - __DRI_IMAGE_FORMAT_ARGB, 32,
> + __DRI_IMAGE_FORMAT_ARGB, __DRI_IMAGE_FORMAT_NONE, 32,
>   { 0x00ff, 0xff00, 0x00ff, 0xff00 }
> },
> {
>   "RGB565",
>   WL_DRM_FORMAT_RGB565, WL_SHM_FORMAT_RGB565,
> - __DRI_IMAGE_FORMAT_RGB565, 16,
> + __DRI_IMAGE_FORMAT_RGB565, __DRI_IMAGE_FORMAT_NONE, 16,
>   { 0xf800, 0x07e0, 0x001f, 0x }
> },
>  };
> @@ -450,15 +451,23 @@ get_back_bo(struct dri2_egl_surface *dri2_surf)
> int use_flags;
> int visual_idx;
> unsigned int dri_image_format;
> +   unsigned int linear_dri_image_format;
> uint64_t *modifiers;
> int num_modifiers;
>  
> visual_idx = dri2_wl_visual_idx_from_fourcc(dri2_surf->format);
> assert(visual_idx != -1);
> dri_image_format = dri2_wl_visuals[visual_idx].dri_image_format;
> +   linear_dri_image_format = dri_image_format;
> modifiers = u_vector_tail(&dri2_dpy->wl_modifiers[visual_idx]);
> num_modifiers = u_vector_length(&dri2_dp

Re: [Mesa-dev] [PATCH 2/2] r600/compute: Mark several functions as static

[Aaron Watry]

On Mon, May 21, 2018 at 9:34 AM, Aaron Watry  wrote:
> On Mon, May 21, 2018 at 6:25 AM, Bruno Jimenez  wrote:
>> On Fri, 2018-05-18 at 22:52 -0400, Jan Vesely wrote:
>>> On Fri, 2018-05-18 at 21:31 -0500, Aaron Watry wrote:
>>> > On Fri, May 18, 2018 at 1:15 PM, Jan Vesely >> > > wrote:
>>> > > On Thu, 2018-05-17 at 19:20 -0500, Aaron Watry wrote:
>>> > > > They're not used anywhere else, so keep them private
>>> > > >
>>> > > > Signed-off-by: Aaron Watry 
>>> > >
>>> > > I'm not sure what the original purpose of the removed functions
>>> > > was. If
>>> > > you recall please add it to the commit message.
>>> >
>>> > I didn't really bother looking into it when I made this change (I
>>> > didn't write this code in the first place).  This is something that
>>> > I've had sitting in my local repo for a while, and just want to
>>> > stop
>>> > rebasing it.
>>> >
>>> > It was originally found a while ago when I started looking into the
>>> > thread-safety (or lack thereof) of the compute pool for r600.
>>> > Figured
>>> > there was no point trying to fix code that was unused.
>>>
>>> OK, nvm then. I was just curious how we ended up with so much dead
>>> code.
>>
>> Hiya,
>>
>> I can comment on that (mainly because I was the one who almost re-wrote
>> the memory pool).
>>
>> The reason is that I did most of these as a GSoC which started trying
>> to fix a bug in the code that growth the pool when memory was needed
>> and it continued with improving the pool. These functions are mostly
>> remains from the original implementation. If I remember correctly, I
>> sent a patch to remove them (and also a big patch which was a comment
>> explaning how the pool worked and why it was like that) but it never
>> got reviewed.
>>
>> In fact, the implementation IS NOT complete as it lacks a path to unmap
>> memory. I also had some patches for this, but as before, they never got
>> reviewed...
>
> I'm going to guess that this list contains some of the patches you
> were talking about:
> https://patchwork.freedesktop.org/project/mesa/list/?submitter=11660&state=*
>
> Especially the superseded ones. If you want to point them out, I can
> try either rebasing or (finally) reviewing them as appropriate.

And by superseded, I really meant "Not Applicable"... Too early.

--Aaron

>
> --Aaron
>
>>
>> I might still have the patches in my old laptop, but I don't have
>> access to it, sorry. Either way, I more or less remember how everything
>> worked, although I don't have a way of testing it because I no longer
>> have a computer with a R600 card.
>>
>> If nothing breaks (compiling) you can have my
>>
>> Reviewed-by: Bruno Jiménez 
>>
>> If you need anything regarding this code, just ask and I'll see if I
>> can dig up from my memory how it worked (and why)
>>
>> Best Regards,
>> Bruno
>>
>>>
>>> >
>>> > > Either way:
>>> > >
>>> > > Reviewed-by: Jan Vesely 
>>> >
>>> > For this one, or both?
>>>
>>> for the series.
>>>
>>> thanks,
>>> Jan
>>>
>>> >
>>> > --Aaron
>>> >
>>> > >
>>> > > Jan
>>> > >
>>> > > > ---
>>> > > >  .../drivers/r600/compute_memory_pool.c| 35
>>> > > > +++
>>> > > >  .../drivers/r600/compute_memory_pool.h| 24 -
>>> > > > 
>>> > > >  2 files changed, 29 insertions(+), 30 deletions(-)
>>> > > >
>>> > > > diff --git a/src/gallium/drivers/r600/compute_memory_pool.c
>>> > > > b/src/gallium/drivers/r600/compute_memory_pool.c
>>> > > > index d1ef25ae1e..981d944b8d 100644
>>> > > > --- a/src/gallium/drivers/r600/compute_memory_pool.c
>>> > > > +++ b/src/gallium/drivers/r600/compute_memory_pool.c
>>> > > > @@ -43,6 +43,29 @@
>>> > > >  #include 
>>> > > >
>>> > > >  #define ITEM_ALIGNMENT 1024
>>> > > > +
>>> > > > +/* A few forward declarations of static functions */
>>> > > > +static void compute_memory_shadow(struct compute_memory_pool*
>>> > > > pool,
>>> > > > + struct pipe_context *pipe, int device_to_host);
>>> > > > +
>>> > > > +static void compute_memory_defrag(struct compute_memory_pool
>>> > > > *pool,
>>> > > > + struct pipe_resource *src, struct pipe_resource *dst,
>>> > > > + struct pipe_context *pipe);
>>> > > > +
>>> > > > +static int compute_memory_promote_item(struct
>>> > > > compute_memory_pool *pool,
>>> > > > + struct compute_memory_item *item, struct pipe_context
>>> > > > *pipe,
>>> > > > + int64_t allocated);
>>> > > > +
>>> > > > +static void compute_memory_move_item(struct
>>> > > > compute_memory_pool *pool,
>>> > > > + struct pipe_resource *src, struct pipe_resource *dst,
>>> > > > + struct compute_memory_item *item, uint64_t
>>> > > > new_start_in_dw,
>>> > > > + struct pipe_context *pipe);
>>> > > > +
>>> > > > +static void compute_memory_transfer(struct
>>> > > > compute_memory_pool* pool,
>>> > > > + struct pipe_context * pipe, int device_to_host,
>>> > > > + struct compute_memory_item* chunk, void* data,
>>> > > > + int offset_in_chunk, int size);
>>> > > > +
>>> > > >  /**
>>> > > >   * Creates a new po

Re: [Mesa-dev] [PATCH 2/2] r600/compute: Mark several functions as static

[Aaron Watry]

On Mon, May 21, 2018 at 6:25 AM, Bruno Jimenez  wrote:
> On Fri, 2018-05-18 at 22:52 -0400, Jan Vesely wrote:
>> On Fri, 2018-05-18 at 21:31 -0500, Aaron Watry wrote:
>> > On Fri, May 18, 2018 at 1:15 PM, Jan Vesely > > > wrote:
>> > > On Thu, 2018-05-17 at 19:20 -0500, Aaron Watry wrote:
>> > > > They're not used anywhere else, so keep them private
>> > > >
>> > > > Signed-off-by: Aaron Watry 
>> > >
>> > > I'm not sure what the original purpose of the removed functions
>> > > was. If
>> > > you recall please add it to the commit message.
>> >
>> > I didn't really bother looking into it when I made this change (I
>> > didn't write this code in the first place).  This is something that
>> > I've had sitting in my local repo for a while, and just want to
>> > stop
>> > rebasing it.
>> >
>> > It was originally found a while ago when I started looking into the
>> > thread-safety (or lack thereof) of the compute pool for r600.
>> > Figured
>> > there was no point trying to fix code that was unused.
>>
>> OK, nvm then. I was just curious how we ended up with so much dead
>> code.
>
> Hiya,
>
> I can comment on that (mainly because I was the one who almost re-wrote
> the memory pool).
>
> The reason is that I did most of these as a GSoC which started trying
> to fix a bug in the code that growth the pool when memory was needed
> and it continued with improving the pool. These functions are mostly
> remains from the original implementation. If I remember correctly, I
> sent a patch to remove them (and also a big patch which was a comment
> explaning how the pool worked and why it was like that) but it never
> got reviewed.
>
> In fact, the implementation IS NOT complete as it lacks a path to unmap
> memory. I also had some patches for this, but as before, they never got
> reviewed...

I'm going to guess that this list contains some of the patches you
were talking about:
https://patchwork.freedesktop.org/project/mesa/list/?submitter=11660&state=*

Especially the superseded ones. If you want to point them out, I can
try either rebasing or (finally) reviewing them as appropriate.

--Aaron

>
> I might still have the patches in my old laptop, but I don't have
> access to it, sorry. Either way, I more or less remember how everything
> worked, although I don't have a way of testing it because I no longer
> have a computer with a R600 card.
>
> If nothing breaks (compiling) you can have my
>
> Reviewed-by: Bruno Jiménez 
>
> If you need anything regarding this code, just ask and I'll see if I
> can dig up from my memory how it worked (and why)
>
> Best Regards,
> Bruno
>
>>
>> >
>> > > Either way:
>> > >
>> > > Reviewed-by: Jan Vesely 
>> >
>> > For this one, or both?
>>
>> for the series.
>>
>> thanks,
>> Jan
>>
>> >
>> > --Aaron
>> >
>> > >
>> > > Jan
>> > >
>> > > > ---
>> > > >  .../drivers/r600/compute_memory_pool.c| 35
>> > > > +++
>> > > >  .../drivers/r600/compute_memory_pool.h| 24 -
>> > > > 
>> > > >  2 files changed, 29 insertions(+), 30 deletions(-)
>> > > >
>> > > > diff --git a/src/gallium/drivers/r600/compute_memory_pool.c
>> > > > b/src/gallium/drivers/r600/compute_memory_pool.c
>> > > > index d1ef25ae1e..981d944b8d 100644
>> > > > --- a/src/gallium/drivers/r600/compute_memory_pool.c
>> > > > +++ b/src/gallium/drivers/r600/compute_memory_pool.c
>> > > > @@ -43,6 +43,29 @@
>> > > >  #include 
>> > > >
>> > > >  #define ITEM_ALIGNMENT 1024
>> > > > +
>> > > > +/* A few forward declarations of static functions */
>> > > > +static void compute_memory_shadow(struct compute_memory_pool*
>> > > > pool,
>> > > > + struct pipe_context *pipe, int device_to_host);
>> > > > +
>> > > > +static void compute_memory_defrag(struct compute_memory_pool
>> > > > *pool,
>> > > > + struct pipe_resource *src, struct pipe_resource *dst,
>> > > > + struct pipe_context *pipe);
>> > > > +
>> > > > +static int compute_memory_promote_item(struct
>> > > > compute_memory_pool *pool,
>> > > > + struct compute_memory_item *item, struct pipe_context
>> > > > *pipe,
>> > > > + int64_t allocated);
>> > > > +
>> > > > +static void compute_memory_move_item(struct
>> > > > compute_memory_pool *pool,
>> > > > + struct pipe_resource *src, struct pipe_resource *dst,
>> > > > + struct compute_memory_item *item, uint64_t
>> > > > new_start_in_dw,
>> > > > + struct pipe_context *pipe);
>> > > > +
>> > > > +static void compute_memory_transfer(struct
>> > > > compute_memory_pool* pool,
>> > > > + struct pipe_context * pipe, int device_to_host,
>> > > > + struct compute_memory_item* chunk, void* data,
>> > > > + int offset_in_chunk, int size);
>> > > > +
>> > > >  /**
>> > > >   * Creates a new pool.
>> > > >   */
>> > > > @@ -106,7 +129,7 @@ void compute_memory_pool_delete(struct
>> > > > compute_memory_pool* pool)
>> > > >   * \returns -1 if it fails, 0 otherwise
>> > > >   * \see compute_memory_finalize_pending
>> > > >   */
>> > > > -int compute_memory_grow_def

Re: [Mesa-dev] [PATCH 3/5] egl/x11: Handle both depth 30 formats for eglCreateImage(). (v3)

[Eric Engestrom]

On Saturday, 2018-05-19 05:32:40 +0200, Mario Kleiner wrote:
> We need to distinguish if the backing storage of a pixmap
> is XRGB2101010 or XBGR2101010, as different gpu hw supports
> different formats. NVidia hw prefers XBGR, whereas AMD and
> Intel are happy with XRGB.
> 
> Use the red channel mask of the first depth 30 visual of
> the x-screen to distinguish which hw format to choose.
> 
> This fixes desktop composition of color depth 30 windows
> when the X11 compositor uses EGL.
> 
> v2: Switch from using the visual of the root window to simply
> using the first depth 30 visual for the x-screen, as testing
> shows that each driver only exports either xrgb ordering or
> xbgr ordering for the channel masks of its depth 30 visuals,
> so this should be unambiguous and avoid trouble if X ever
> supports depth 30 pixmaps on screens with a non-depth 30 root
> window visual. This per Michels suggestion.
> 
> v3: No change to v2, but spent some time testing this more on
> AMD hw, with my software hacked up to intentionally choose
> pixel formats/visual with the non-preferred xBGR2101010
> ordering on the ati-ddx, also with a standard non-OpenGL
> X-Window with depth 30 visual, to make sure that things show
> up properly with the right colors on the screen when going
> through EGL+OpenGL based compositing on KDE-5. Iow. to confirm
> that my explanation to the v2 patch on the mailing list of why
> it should work and the actual practice agree (or possibly that
> i am good at fooling myself during testing ;).
> 
> Signed-off-by: Mario Kleiner 
> Cc: Michel Dänzer 
> ---
>  src/egl/drivers/dri2/egl_dri2.h  |  7 +++
>  src/egl/drivers/dri2/platform_x11.c  | 36 
> +++-
>  src/egl/drivers/dri2/platform_x11_dri3.c | 12 +++
>  3 files changed, 50 insertions(+), 5 deletions(-)
> 
> diff --git a/src/egl/drivers/dri2/egl_dri2.h b/src/egl/drivers/dri2/egl_dri2.h
> index adabc527f8..7e7032d989 100644
> --- a/src/egl/drivers/dri2/egl_dri2.h
> +++ b/src/egl/drivers/dri2/egl_dri2.h
> @@ -413,6 +413,8 @@ EGLBoolean
>  dri2_initialize_x11(_EGLDriver *drv, _EGLDisplay *disp);
>  void
>  dri2_teardown_x11(struct dri2_egl_display *dri2_dpy);
> +unsigned int
> +dri2_x11_get_red_mask_for_depth(struct dri2_egl_display *dri2_dpy, int 
> depth);
>  #else
>  static inline EGLBoolean
>  dri2_initialize_x11(_EGLDriver *drv, _EGLDisplay *disp)
> @@ -421,6 +423,11 @@ dri2_initialize_x11(_EGLDriver *drv, _EGLDisplay *disp)
>  }
>  static inline void
>  dri2_teardown_x11(struct dri2_egl_display *dri2_dpy) {}
> +static inline unsigned int
> +dri2_x11_get_red_mask_for_depth(struct dri2_egl_display *dri2_dpy, int depth)
> +{
> +   return 0;
> +}
>  #endif
>  
>  #ifdef HAVE_DRM_PLATFORM
> diff --git a/src/egl/drivers/dri2/platform_x11.c 
> b/src/egl/drivers/dri2/platform_x11.c
> index 7aca0a9020..aabae02adb 100644
> --- a/src/egl/drivers/dri2/platform_x11.c
> +++ b/src/egl/drivers/dri2/platform_x11.c
> @@ -209,6 +209,36 @@ get_xcb_screen(xcb_screen_iterator_t iter, int screen)
>  return NULL;
>  }
>  
> +static xcb_visualtype_t *
> +get_xcb_visualtype_for_depth(struct dri2_egl_display *dri2_dpy, int depth)
> +{
> +   xcb_visualtype_iterator_t visual_iter;
> +   xcb_screen_t *screen = dri2_dpy->screen;
> +   xcb_depth_iterator_t depth_iter = 
> xcb_screen_allowed_depths_iterator(screen);
> +
> +   for (; depth_iter.rem; xcb_depth_next(&depth_iter)) {
> +  if (depth_iter.data->depth != depth)
> + continue;
> +
> +  visual_iter = xcb_depth_visuals_iterator(depth_iter.data);
> +  if (visual_iter.rem)
> + return visual_iter.data;
> +   }
> +
> +   return NULL;
> +}
> +
> +/* Get red channel mask for given depth. */
> +unsigned int
> +dri2_x11_get_red_mask_for_depth(struct dri2_egl_display *dri2_dpy, int depth)
> +{
> +   unsigned int red_mask = 0;
> +   xcb_visualtype_t *visual = get_xcb_visualtype_for_depth(dri2_dpy, depth);
> +   if (visual)
> +  red_mask = visual->red_mask;
> +
> +   return red_mask;

Nit: drop the local `red_mask` and just `return visual->red_mask`/`return 0`

Reviewed-by: Eric Engestrom 

> +}
>  
>  /**
>   * Called via eglCreateWindowSurface(), drv->API.CreateWindowSurface().
> @@ -1058,7 +1088,11 @@ dri2_create_image_khr_pixmap(_EGLDisplay *disp, 
> _EGLContext *ctx,
>format = __DRI_IMAGE_FORMAT_XRGB;
>break;
> case 30:
> -  format = __DRI_IMAGE_FORMAT_XRGB2101010;
> +  /* Different preferred formats for different hw */
> +  if (dri2_x11_get_red_mask_for_depth(dri2_dpy, 30) == 0x3ff)
> + format = __DRI_IMAGE_FORMAT_XBGR2101010;
> +  else
> + format = __DRI_IMAGE_FORMAT_XRGB2101010;
>break;
> case 32:
>format = __DRI_IMAGE_FORMAT_ARGB;
> diff --git a/src/egl/drivers/dri2/platform_x11_dri3.c 
> b/src/egl/drivers/dri2/platform_x11_dri3.c
> index 5cb6d65c0a..9525b20158 100644
> --- a/src/egl/drivers/dri2/pl

Re: [Mesa-dev] [PATCH] radv: fix centroid interpolation

[Bas Nieuwenhuizen]

On Mon, May 21, 2018 at 2:37 PM, Ilia Mirkin  wrote:
> What do centroid / sample interpolation modes mean in a non-msaa
> environment? Or does key.fs.multisample mean something else?

Yeah that was what I was wondering too. It is valid for shaders to use
so we should handel it, but I suspect under normal operations we have
centroid=center.  I'm still not sure how this would interact with e.g.
VK_EXT_sample_locations if you set the single sample to a non-center
location though, which would be the interesting corner case.


>
> On Mon, May 21, 2018 at 5:15 AM, Samuel Pitoiset
>  wrote:
>> It's legal to set the centroid and sample interpolation modes
>> when MSAA disabled. So, we have to initialize the centroid
>> inputs because the hardware doesn't.
>>
>> This fixes rendering issues with DXVK and The Witness, World of
>> Warcraft, Trackmania and probably more games.
>>
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106315
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102390
>> CC: 18.0 18.1 
>> Signed-off-by: Samuel Pitoiset 
>> ---
>>  src/amd/vulkan/radv_nir_to_llvm.c | 3 ---
>>  1 file changed, 3 deletions(-)
>>
>> diff --git a/src/amd/vulkan/radv_nir_to_llvm.c 
>> b/src/amd/vulkan/radv_nir_to_llvm.c
>> index 9b9619b877e..2d91ded7fe5 100644
>> --- a/src/amd/vulkan/radv_nir_to_llvm.c
>> +++ b/src/amd/vulkan/radv_nir_to_llvm.c
>> @@ -2075,9 +2075,6 @@ static void
>>  prepare_interp_optimize(struct radv_shader_context *ctx,
>>  struct nir_shader *nir)
>>  {
>> -   if (!ctx->options->key.fs.multisample)
>> -   return;
>> -
>> bool uses_center = false;
>> bool uses_centroid = false;
>> nir_foreach_variable(variable, &nir->inputs) {
>> --
>> 2.17.0
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 02/19] intel/fs: Use groups for SIMD16 LINTERP on gen11+

[Jason Ekstrand]

On May 20, 2018 23:45:27 Kenneth Graunke  wrote:


On Friday, May 18, 2018 4:35:15 PM PDT Jason Ekstrand wrote:

This is better than compression control because it naturally extends to
SIMD32.
---
src/intel/compiler/brw_fs_generator.cpp | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/src/intel/compiler/brw_fs_generator.cpp 
b/src/intel/compiler/brw_fs_generator.cpp

index 0c050a7..f435f97 100644
--- a/src/intel/compiler/brw_fs_generator.cpp
+++ b/src/intel/compiler/brw_fs_generator.cpp
@@ -795,16 +795,14 @@ fs_generator::generate_linterp(fs_inst *inst,
  */
 brw_inst_set_saturate(p->devinfo, i[0], false);
} else {
- brw_set_default_compression_control(p, BRW_COMPRESSION_NONE);
+ brw_set_default_group(p, inst->group);
 i[0] = brw_MAD(p,acc, dwR, offset(delta_x, 0), dwP);
 i[1] = brw_MAD(p, offset(dst, 0), acc, offset(delta_x, 1), dwQ);

- brw_set_default_compression_control(p, BRW_COMPRESSION_2NDHALF);
+ brw_set_default_group(p, inst->group + 8);
 i[2] = brw_MAD(p,acc, dwR, offset(delta_y, 0), dwP);
 i[3] = brw_MAD(p, offset(dst, 1), acc, offset(delta_y, 1), dwQ);

- brw_set_default_compression_control(p, BRW_COMPRESSION_COMPRESSED);
-
 brw_inst_set_cond_modifier(p->devinfo, i[1], inst->conditional_mod);
 brw_inst_set_cond_modifier(p->devinfo, i[3], inst->conditional_mod);


The last hunk you dropped is supposed to restore the original state, so
subsequent things continue working...I think you either want to change
it to brw_set_default_group(inst->group)...or push/pop the state around
this whole section...


It's not needed because no more instructions get emitted and we push/pop 
around the giant generator switch anyway.  Still, I guess it doesn't hurt 
to push/pop over extra time.



I like the change, though.




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

[Mesa-dev] [PATCH] ac/surface/gfx6: Don't force a tile index for fmask.

[Bas Nieuwenhuizen]

The bpe of the fmask often differs from the bpe of the main
surface. On SI that means it has to get a different tile
index.

addrlib is capable of figuring this out itself, so just pass
-1 instead to let it know that it is not preset.

Fixes: 9bf3570fed0 "ac/surface/gfx6: compute FMASK together with the color 
surface"
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106511
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106499
---
 src/amd/common/ac_surface.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/amd/common/ac_surface.c b/src/amd/common/ac_surface.c
index d7da9950256..b50157cdb9a 100644
--- a/src/amd/common/ac_surface.c
+++ b/src/amd/common/ac_surface.c
@@ -868,7 +868,7 @@ static int gfx6_compute_surface(ADDR_HANDLE addrlib,
fin.numSlices = AddrSurfInfoIn.numSlices;
fin.numSamples = AddrSurfInfoIn.numSamples;
fin.numFrags = AddrSurfInfoIn.numFrags;
-   fin.tileIndex = AddrSurfInfoOut.tileIndex;
+   fin.tileIndex = -1;
fout.pTileInfo = &fmask_tile_info;
 
r = AddrComputeFmaskInfo(addrlib, &fin, &fout);
-- 
2.17.0

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

[Mesa-dev] [PATCH] nir/print: fix printing of 8/16 bit constant variables

[Karol Herbst]

Signed-off-by: Karol Herbst 
---
 src/compiler/nir/nir_print.c | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/src/compiler/nir/nir_print.c b/src/compiler/nir/nir_print.c
index 97b2d6164cd..e331a26d932 100644
--- a/src/compiler/nir/nir_print.c
+++ b/src/compiler/nir/nir_print.c
@@ -299,6 +299,28 @@ print_constant(nir_constant *c, const struct glsl_type 
*type, print_state *state
unsigned i, j;
 
switch (glsl_get_base_type(type)) {
+   case GLSL_TYPE_UINT8:
+   case GLSL_TYPE_INT8:
+  /* Only float base types can be matrices. */
+  assert(cols == 1);
+
+  for (i = 0; i < rows; i++) {
+ if (i > 0) fprintf(fp, ", ");
+ fprintf(fp, "0x%02x", c->values[0].u8[i]);
+  }
+  break;
+
+   case GLSL_TYPE_UINT16:
+   case GLSL_TYPE_INT16:
+  /* Only float base types can be matrices. */
+  assert(cols == 1);
+
+  for (i = 0; i < rows; i++) {
+ if (i > 0) fprintf(fp, ", ");
+ fprintf(fp, "0x%04x", c->values[0].u16[i]);
+  }
+  break;
+
case GLSL_TYPE_UINT:
case GLSL_TYPE_INT:
case GLSL_TYPE_BOOL:
-- 
2.17.0

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

Re: [Mesa-dev] Splitting a texture between multiple samplers in Gallium

[Ilia Mirkin]

So ... what do you do when someone attaches max_samplers' worth of
RGBA32F textures to a single stage? My guess is that you just fail to
render and tell the application author, "don't do that". The
alternative is to expose 1/4th of the true maximum, which is probably
undesirable.

Normally these kinds of quirks are handled directly in the driver.
Have a look at e.g. how ASTC SRGB quirks are handled in freedreno --
on A420.0 the alpha channel gets srgb conversion as well (even though
it shouldn't), so one has to bind the texture twice -- once for rgb,
once for alpha. The compiler needs to be aware of this as well.

Hope this helps,

  -ilia

On Mon, May 21, 2018 at 8:15 AM, Konstantin P.  wrote:
> We are writing a driver for some proprietary hardware using Gallium. And
> this hardware supports GL_ARB_texture_float, but requires to change texture
> format from PIPE_FORMAT_R32G32B32A32_FLOAT to PIPE_FORMAT_R8G8B8A8_UNORM and
> use four samplers (one R8G8B8A8_UNORM texture for each original color). How
> we should do it in a Gallium properly? If we will create multiple samplers
> in create_sampler_view - it can cause a crash, when we have a
> PIPE_MAX_SAMPLERS num of "large" textures. We want to use something similar
> to u_transfer_helper, but for this format. So, I have some questions
> regarding Gallium architecture, which affects this situation:
>
> 1. Where we should write a splitter? In a pipe_resource, or in a
> pipe_transfer, or in a sampler_view?
> 2. Do you have something related to this case in Gallium already to not to
> reinvent a bicycle? (If you have, we will use internal functions and not
> write our own).
> 3. Do you even support this kind of hardware which splits textures? Because
> I cannot found any example except u_transfer_helper (but it is only for one
> specific case, not for general).
>
> ___
> 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] radv: fix centroid interpolation

[Ilia Mirkin]

What do centroid / sample interpolation modes mean in a non-msaa
environment? Or does key.fs.multisample mean something else?

On Mon, May 21, 2018 at 5:15 AM, Samuel Pitoiset
 wrote:
> It's legal to set the centroid and sample interpolation modes
> when MSAA disabled. So, we have to initialize the centroid
> inputs because the hardware doesn't.
>
> This fixes rendering issues with DXVK and The Witness, World of
> Warcraft, Trackmania and probably more games.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106315
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102390
> CC: 18.0 18.1 
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/amd/vulkan/radv_nir_to_llvm.c | 3 ---
>  1 file changed, 3 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_nir_to_llvm.c 
> b/src/amd/vulkan/radv_nir_to_llvm.c
> index 9b9619b877e..2d91ded7fe5 100644
> --- a/src/amd/vulkan/radv_nir_to_llvm.c
> +++ b/src/amd/vulkan/radv_nir_to_llvm.c
> @@ -2075,9 +2075,6 @@ static void
>  prepare_interp_optimize(struct radv_shader_context *ctx,
>  struct nir_shader *nir)
>  {
> -   if (!ctx->options->key.fs.multisample)
> -   return;
> -
> bool uses_center = false;
> bool uses_centroid = false;
> nir_foreach_variable(variable, &nir->inputs) {
> --
> 2.17.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] Splitting a texture between multiple samplers in Gallium

[Konstantin P.]

We are writing a driver for some proprietary hardware using Gallium. And
this hardware supports GL_ARB_texture_float, but requires to change texture
format from PIPE_FORMAT_R32G32B32A32_FLOAT to PIPE_FORMAT_R8G8B8A8_UNORM
and use four samplers (one R8G8B8A8_UNORM texture for each original color).
How we should do it in a Gallium properly? If we will create multiple
samplers in create_sampler_view - it can cause a crash, when we have a
PIPE_MAX_SAMPLERS num of "large" textures. We want to use something similar
to u_transfer_helper, but for this format. So, I have some questions
regarding Gallium architecture, which affects this situation:

1. Where we should write a splitter? In a pipe_resource, or in a
pipe_transfer, or in a sampler_view?
2. Do you have something related to this case in Gallium already to not to
reinvent a bicycle? (If you have, we will use internal functions and not
write our own).
3. Do you even support this kind of hardware which splits textures? Because
I cannot found any example except u_transfer_helper (but it is only for one
specific case, not for general).
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 102390] centroid interpolation causes broken attribute values

[bugzilla-daemon]

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

Samuel Pitoiset  changed:

   What|Removed |Added

 Status|NEEDINFO|RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Samuel Pitoiset  ---
I think the original report was correct and the issue should most likely be
fixed in master with
https://cgit.freedesktop.org/mesa/mesa/commit/?id=73df16dcee79e2281c8d8a830dbbe6655359c82d

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

[Mesa-dev] [Bug 106315] The witness + dxvk suffers flickering garbage

[bugzilla-daemon]

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

Samuel Pitoiset  changed:

   What|Removed |Added

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

--- Comment #4 from Samuel Pitoiset  ---
Fixed with
https://cgit.freedesktop.org/mesa/mesa/commit/?id=73df16dcee79e2281c8d8a830dbbe6655359c82d

The patch should be available in next mesa 18.0.5/18.1.1.

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

Re: [Mesa-dev] [PATCH 2/2] r600/compute: Mark several functions as static

[Bruno Jimenez]

On Fri, 2018-05-18 at 22:52 -0400, Jan Vesely wrote:
> On Fri, 2018-05-18 at 21:31 -0500, Aaron Watry wrote:
> > On Fri, May 18, 2018 at 1:15 PM, Jan Vesely  > > wrote:
> > > On Thu, 2018-05-17 at 19:20 -0500, Aaron Watry wrote:
> > > > They're not used anywhere else, so keep them private
> > > > 
> > > > Signed-off-by: Aaron Watry 
> > > 
> > > I'm not sure what the original purpose of the removed functions
> > > was. If
> > > you recall please add it to the commit message.
> > 
> > I didn't really bother looking into it when I made this change (I
> > didn't write this code in the first place).  This is something that
> > I've had sitting in my local repo for a while, and just want to
> > stop
> > rebasing it.
> > 
> > It was originally found a while ago when I started looking into the
> > thread-safety (or lack thereof) of the compute pool for r600.
> > Figured
> > there was no point trying to fix code that was unused.
> 
> OK, nvm then. I was just curious how we ended up with so much dead
> code.

Hiya,

I can comment on that (mainly because I was the one who almost re-wrote 
the memory pool).

The reason is that I did most of these as a GSoC which started trying
to fix a bug in the code that growth the pool when memory was needed
and it continued with improving the pool. These functions are mostly
remains from the original implementation. If I remember correctly, I
sent a patch to remove them (and also a big patch which was a comment
explaning how the pool worked and why it was like that) but it never
got reviewed.

In fact, the implementation IS NOT complete as it lacks a path to unmap
memory. I also had some patches for this, but as before, they never got
reviewed...

I might still have the patches in my old laptop, but I don't have
access to it, sorry. Either way, I more or less remember how everything
worked, although I don't have a way of testing it because I no longer
have a computer with a R600 card.

If nothing breaks (compiling) you can have my

Reviewed-by: Bruno Jiménez 

If you need anything regarding this code, just ask and I'll see if I
can dig up from my memory how it worked (and why)

Best Regards,
Bruno

> 
> > 
> > > Either way:
> > > 
> > > Reviewed-by: Jan Vesely 
> > 
> > For this one, or both?
> 
> for the series.
> 
> thanks,
> Jan
> 
> > 
> > --Aaron
> > 
> > > 
> > > Jan
> > > 
> > > > ---
> > > >  .../drivers/r600/compute_memory_pool.c| 35
> > > > +++
> > > >  .../drivers/r600/compute_memory_pool.h| 24 -
> > > > 
> > > >  2 files changed, 29 insertions(+), 30 deletions(-)
> > > > 
> > > > diff --git a/src/gallium/drivers/r600/compute_memory_pool.c
> > > > b/src/gallium/drivers/r600/compute_memory_pool.c
> > > > index d1ef25ae1e..981d944b8d 100644
> > > > --- a/src/gallium/drivers/r600/compute_memory_pool.c
> > > > +++ b/src/gallium/drivers/r600/compute_memory_pool.c
> > > > @@ -43,6 +43,29 @@
> > > >  #include 
> > > > 
> > > >  #define ITEM_ALIGNMENT 1024
> > > > +
> > > > +/* A few forward declarations of static functions */
> > > > +static void compute_memory_shadow(struct compute_memory_pool*
> > > > pool,
> > > > + struct pipe_context *pipe, int device_to_host);
> > > > +
> > > > +static void compute_memory_defrag(struct compute_memory_pool
> > > > *pool,
> > > > + struct pipe_resource *src, struct pipe_resource *dst,
> > > > + struct pipe_context *pipe);
> > > > +
> > > > +static int compute_memory_promote_item(struct
> > > > compute_memory_pool *pool,
> > > > + struct compute_memory_item *item, struct pipe_context
> > > > *pipe,
> > > > + int64_t allocated);
> > > > +
> > > > +static void compute_memory_move_item(struct
> > > > compute_memory_pool *pool,
> > > > + struct pipe_resource *src, struct pipe_resource *dst,
> > > > + struct compute_memory_item *item, uint64_t
> > > > new_start_in_dw,
> > > > + struct pipe_context *pipe);
> > > > +
> > > > +static void compute_memory_transfer(struct
> > > > compute_memory_pool* pool,
> > > > + struct pipe_context * pipe, int device_to_host,
> > > > + struct compute_memory_item* chunk, void* data,
> > > > + int offset_in_chunk, int size);
> > > > +
> > > >  /**
> > > >   * Creates a new pool.
> > > >   */
> > > > @@ -106,7 +129,7 @@ void compute_memory_pool_delete(struct
> > > > compute_memory_pool* pool)
> > > >   * \returns -1 if it fails, 0 otherwise
> > > >   * \see compute_memory_finalize_pending
> > > >   */
> > > > -int compute_memory_grow_defrag_pool(struct compute_memory_pool
> > > > *pool,
> > > > +static int compute_memory_grow_defrag_pool(struct
> > > > compute_memory_pool *pool,
> > > >   struct pipe_context *pipe, int new_size_in_dw)
> > > >  {
> > > >   new_size_in_dw = align(new_size_in_dw, ITEM_ALIGNMENT);
> > > > @@ -168,7 +191,7 @@ int compute_memory_grow_defrag_pool(struct
> > > > compute_memory_pool *pool,
> > > >   * \param device_to_host 1 for device->host, 0 for host-
> > > > >device
> > > >   * \see compute_me

Re: [Mesa-dev] [PATCH] intel/eu: Set EXECUTE_1 when setting the rounding mode in cr0

[Chema Casanova]

Thanks for fixing the full overwrite of the Control Register.

Reviewed-by: Jose Maria Casanova Crespo 

El 19/05/18 a las 05:09, Jason Ekstrand escribió:
> Fixes: d6cd14f2131a5b "i965/fs: Define new shader opcode to..."
> ---
>  src/intel/compiler/brw_eu_emit.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/src/intel/compiler/brw_eu_emit.c 
> b/src/intel/compiler/brw_eu_emit.c
> index 6c9dced..4f51d51 100644
> --- a/src/intel/compiler/brw_eu_emit.c
> +++ b/src/intel/compiler/brw_eu_emit.c
> @@ -3716,6 +3716,7 @@ brw_rounding_mode(struct brw_codegen *p,
> if (bits != BRW_CR0_RND_MODE_MASK) {
>brw_inst *inst = brw_AND(p, brw_cr0_reg(0), brw_cr0_reg(0),
> brw_imm_ud(~BRW_CR0_RND_MODE_MASK));
> +  brw_inst_set_exec_size(p->devinfo, inst, BRW_EXECUTE_1);
>  
>/* From the Skylake PRM, Volume 7, page 760:
> *  "Implementation Restriction on Register Access: When the control
> @@ -3730,6 +3731,7 @@ brw_rounding_mode(struct brw_codegen *p,
> if (bits) {
>brw_inst *inst = brw_OR(p, brw_cr0_reg(0), brw_cr0_reg(0),
>brw_imm_ud(bits));
> +  brw_inst_set_exec_size(p->devinfo, inst, BRW_EXECUTE_1);
>brw_inst_set_thread_control(p->devinfo, inst, BRW_THREAD_SWITCH);
> }
>  }
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 09/22] intel/compiler: implement 16-bit multiply-add

[Eero Tamminen]

Hi,

On 21.05.2018 10:42, Iago Toral wrote:

On Fri, 2018-05-18 at 12:08 +0300, Eero Tamminen wrote:

On 17.05.2018 14:25, Eero Tamminen wrote:

On 17.05.2018 11:46, Iago Toral Quiroga wrote:

The PRM for MAD states that F, DF and HF are supported, however,
then
it requires that the instruction includes a 2-bit mask specifying
the types of each operand like this:


  >

00: 32-bit float
01: 32-bit signed integer
10: 32-bit unsigned integer
11: 64-bit float


Where this was?


This is in the decription of the MAD instruction here (for SKL):

https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-skl
-vol02a-commandreference-instructions.pdf

It guess the contents for this were copy & pasted from previous PRMs
that didn't support HF...


Ouch.  That looks pretty different from what's in here:
https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-skl-vol07-3d_media_gpgpu.pdf

And in BSW one:

In
https://01.org/sites/default/files/documentation/intel-gfx-bspec-os
rc-chv-bsw-vol07-3d-media-gpgpu-engine.pdf


I'll ask around who's currently maintaining the 01.org docs, and could 
she/he update the opcode docs. All of them from BSW to KBL seem to have 
the old information, while the Media GPGPU docs have newer info.



Btw.  Did you have test-cases utilizing mad() instructions, and did
they work OK with your patchset?

(If yes, better test-cases may be required.)



Section "EU Changes by Processor Generation" states:
-
These features or behaviors are added for CHV, BSW, continuing to
later generations:
...
In the 3-source instruction format, widen the SrcType and DstType
fields
and add an encoding for the HF (Half Float) type.
-

(I.e. it applies to GEN9+ [1] and on GEN8 for BSW/CHV.)


Actually, I have just verified that the BDW PRMs have the exact same
thing, but stating BDW instead of BSW/CHV, so I guess BDW should be
supported too.


Yes, right.



In section "GEN Instruction Format – 3-src" table, both "Dst Type"
and
"Src Type" fields are 3 bits, and there's additional 1 bit "Src1
Type"
and "Src2 Type" fields to differentiate formats for src1 & src2.


  >

Then, when looking at "Source or Destination Operand Fields
(Alphabetically by Short Name)" section:
---
DstType:

Encoding for three source instructions:
000b = :f. Single precision Float (32-bit).
001b = :d. Signed Doubleword integer.
010b = :ud. Unsigned Doubleword integer.
011b = :df. Double precision Float (64-bit).
100b = :hf. Half precision Float (16-bit).
101b - 111b. Reserved.

...

SrcType:

Three source instructions use one SrcType field for all source
operands,
with a 3-bit encoding that allows fewer data types:

Encoding for three source instructions:
000b = :f. Single precision Float (32-bit).
001b = :d. Signed Doubleword integer.
010b = :ud. Unsigned Doubleword integer.
011b = :df. Double precision Float (64-bit).
100b = :hf. Half precision Float (16-bit).
101b - 111b. Reserved.

Three source instructions can use operands with mixed-mode
precision.
When SrcType field is set to :f or :hf it defines precision for
source 0
only, and fields Src1Type and Src2Type define precision for other
source
operands:
0b = :f. Single precision Float (32-bit).
1b = :hf. Half precision Float (16-bit).
---


Note also the section "Special Requirements for Handling Mixed Mode
Float Operations".


Both BDW & BSW specs list also this restriction, which is lifted GEN9:
* Calculations using the HF (Half Float) type do not support denormals 
or gradual underflow.




Btw. Mesa supporting HF with mad() is important because pln()
doesn't support it in HW, but you can implement pln() HF version
with two mad()s.



- Eero


[1]: SkyLake & KabyLake PRMs lists same amount of bits, but don't
tell
what they represent (often one needs to look into PRM for the HW
where
these changes were first introduced, which in this case was
Braswell /
Cherryview).



So 16-bit float would not be supported.  The driver also asserts
that
the types involved in ALING16 3-src operations are one of these
(MAD is always emitted as an align16 instruction prior to gen10).
---
   src/intel/compiler/brw_fs_nir.cpp | 9 -
   1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/src/intel/compiler/brw_fs_nir.cpp
b/src/intel/compiler/brw_fs_nir.cpp
index 91283ab4911..58ddc456bae 100644
--- a/src/intel/compiler/brw_fs_nir.cpp
+++ b/src/intel/compiler/brw_fs_nir.cpp
@@ -1525,7 +1525,14 @@ fs_visitor::nir_emit_alu(const fs_builder
&bld,
nir_alu_instr *instr)
 break;
  case nir_op_ffma:
-  inst = bld.MAD(result, op[2], op[1], op[0]);
+  /* 3-src MAD doesn't support 16-bit operands */
+  if (nir_dest_bit_size(instr->dest.dest) >= 32) {
+ inst = bld.MAD(result, op[2], op[1], op[0]);
+  } else {
+ fs_reg tmp = bld.vgrf(BRW_REGISTER_TYPE_HF);
+ bld.MUL(tmp, op[1], op[0]);
+  

Re: [Mesa-dev] [RFC PATCH] Replace an flock with a random filename to evade some very ugly system dependent code

[Benedikt Schemmer]

Am 21.05.2018 um 01:19 schrieb Timothy Arceri:
> 
> 
> On 20/05/18 22:16, Benedikt Schemmer wrote:
>> There is exactly one flock in mesa and it caused mesa not to build
>> on windows when shader cache was enabled.
>>
>> It should be possible to revert 9f8dc3bf03ec825bae7041858dda6ca2e9a34363
>> "utils: build sha1/disk cache only with Android/Autoconf" currently
>> guarding the offending code with ENABLE_SHADER_CACHE
>>
>> This would allow shader cache to work on windows I think.
> 
> NAK. rand() is not thread safe.
> 
> Why are you trying to make this build on windows? 

Appveyor
https://ci.appveyor.com/project/mesa3d/mesa/build/3186

was the reason why large parts are guarded by ENABLE_SHADER_CACHE
which prevents me from using a simple function in the patch I mentioned

I can of course circumvent that by just duplicating the code I
need.

It just seems cleaner to have no system dependent code here.
But you're right: its quite convoluted and every time I think I got it
something else pops up ;)

There are also other dependencies (dlfcn.h) that need to be
removed. I already have, at least to some degree. I dont know how to eliminate
the runtime check for the llvm build though, but that is only used by amd code
so I moved it to ac_llvm_util.h for the moment which seems to work.

si_pipe.c somewhere around line 800 now looks like:
---
if (ac_get_function_timestamp(LLVMInitializeAMDGPUTargetInfo,
  &llvm_timestamp)) {
res = asprintf(×tamp_str, "%s_%u",
   __TIMESTAMP__, llvm_timestamp);
}
---

>There is no use case for this on windows currently so it won't even be tested. 
>There are also other calls such as getuid() etc that >will fail on windows.
> 
> If someone want this to work on windows they should just write windows 
> specific paths IMO.
> 
>>
>> I dont have a test system with windows though.
>> This builds on linux and is tested with Deus Ex:MD and Metro 2033 Redux
>> both with cold shader cache.
>>
>> Really
>> Fixes: d1efa09d342bff3e5def2978a0bef748d74f9c82
>>
>> CC: Tapani Pälli 
>> CC: "Marek Olšák" 
>> CC: Emil Velikov 
>> CC: Timothy Arceri 
>> CC: Samuel Pitoiset 
>> ---
>> This enables the patch
>> [PATCH 1/3] mesa/main/shaderapi: Use generate_sha1() unconditionally
>>
>>   src/util/disk_cache.c | 48 +++-
>>   1 file changed, 35 insertions(+), 13 deletions(-)
>>
>> diff --git a/src/util/disk_cache.c b/src/util/disk_cache.c
>> index 4a762eff20..ca47bb15fb 100644
>> --- a/src/util/disk_cache.c
>> +++ b/src/util/disk_cache.c
>> @@ -28,7 +28,6 @@
>>   #include 
>>   #include 
>>   #include 
>> -#include 
>>   #include 
>>   #include 
>>   #include 
>> @@ -848,6 +847,29 @@ struct cache_entry_file_data {
>>  uint32_t uncompressed_size;
>>   };
>>   +static char *
>> +generate_random_string(int length) {
>> +   static const char a[] = "0123456789abcdef";
>> +
>> +   if (length > 16)
>> +  return NULL;
>> +
>> +   char buf[16];
>> +   char *rndstr;
>> +
>> +   for (int i = 0; i < length - 1; ++i) {
>> +   // assign a random element from the lookup table
>> +   buf[i] = a[rand() % (sizeof(a) - 1)];
>> +   }
>> +
>> +   buf[length - 1] = 0;
>> +
>> +   if (asprintf(&rndstr, "%s", buf) == -1)
>> +  return NULL;
>> +
>> +   return rndstr;
>> +}
>> +
>>   static void
>>   cache_put(void *job, int thread_index)
>>   {
>> @@ -855,7 +877,7 @@ cache_put(void *job, int thread_index)
>>    int fd = -1, fd_final = -1, err, ret;
>>  unsigned i = 0;
>> -   char *filename = NULL, *filename_tmp = NULL;
>> +   char *filename = NULL, *filename_tmp = NULL, *random = NULL;
>>  struct disk_cache_put_job *dc_job = (struct disk_cache_put_job *) job;
>>    filename = get_cache_file(dc_job->cache, dc_job->key);
>> @@ -873,7 +895,16 @@ cache_put(void *job, int thread_index)
>>   * final destination filename, (to prevent any readers from seeing
>>   * a partially written file).
>>   */
>> -   if (asprintf(&filename_tmp, "%s.tmp", filename) == -1)
>> +
>> +   /* This next part used to be an flock(), which would prevent windows 
>> systems
>> +    * to build. 4 hex characters should be enough to prevent filename race
>> +    * conditions for now.
>> +   */
>> +   random = generate_random_string(4);
>> +   if (random == NULL)
>> +  goto done;
>> +
>> +   if (asprintf(&filename_tmp, "%s_%s.tmp", filename, random) == -1)
>>     goto done;
>>    fd = open(filename_tmp, O_WRONLY | O_CLOEXEC | O_CREAT, 0644);
>> @@ -890,16 +921,7 @@ cache_put(void *job, int thread_index)
>>    goto done;
>>  }
>>   -   /* With the temporary file open, we take an exclusive flock on
>> -    * it. If the flock fails, then another process still has the file
>> -    * open with the flock held. So just let that file be responsible
>> -    * for writing the file.
>> -    */
>> -   err = flock(fd, LOCK_EX | LOCK_NB);
>> -   if (err == -1)
>> 

Re: [Mesa-dev] [PATCH] radv: fix centroid interpolation

[Bas Nieuwenhuizen]

Reviewed-by: Bas Nieuwenhuizen 

On Mon, May 21, 2018 at 11:15 AM, Samuel Pitoiset
 wrote:
> It's legal to set the centroid and sample interpolation modes
> when MSAA disabled. So, we have to initialize the centroid
> inputs because the hardware doesn't.
>
> This fixes rendering issues with DXVK and The Witness, World of
> Warcraft, Trackmania and probably more games.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106315
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102390
> CC: 18.0 18.1 
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/amd/vulkan/radv_nir_to_llvm.c | 3 ---
>  1 file changed, 3 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_nir_to_llvm.c 
> b/src/amd/vulkan/radv_nir_to_llvm.c
> index 9b9619b877e..2d91ded7fe5 100644
> --- a/src/amd/vulkan/radv_nir_to_llvm.c
> +++ b/src/amd/vulkan/radv_nir_to_llvm.c
> @@ -2075,9 +2075,6 @@ static void
>  prepare_interp_optimize(struct radv_shader_context *ctx,
>  struct nir_shader *nir)
>  {
> -   if (!ctx->options->key.fs.multisample)
> -   return;
> -
> bool uses_center = false;
> bool uses_centroid = false;
> nir_foreach_variable(variable, &nir->inputs) {
> --
> 2.17.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] radv: fix centroid interpolation

[Samuel Pitoiset]

It's legal to set the centroid and sample interpolation modes
when MSAA disabled. So, we have to initialize the centroid
inputs because the hardware doesn't.

This fixes rendering issues with DXVK and The Witness, World of
Warcraft, Trackmania and probably more games.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106315
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102390
CC: 18.0 18.1 
Signed-off-by: Samuel Pitoiset 
---
 src/amd/vulkan/radv_nir_to_llvm.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/src/amd/vulkan/radv_nir_to_llvm.c 
b/src/amd/vulkan/radv_nir_to_llvm.c
index 9b9619b877e..2d91ded7fe5 100644
--- a/src/amd/vulkan/radv_nir_to_llvm.c
+++ b/src/amd/vulkan/radv_nir_to_llvm.c
@@ -2075,9 +2075,6 @@ static void
 prepare_interp_optimize(struct radv_shader_context *ctx,
 struct nir_shader *nir)
 {
-   if (!ctx->options->key.fs.multisample)
-   return;
-
bool uses_center = false;
bool uses_centroid = false;
nir_foreach_variable(variable, &nir->inputs) {
-- 
2.17.0

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

[Mesa-dev] [Bug 106587] Dota2 is very dark when using vulkan render on a Intel << AMD prime setup

[bugzilla-daemon]

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

Bas Nieuwenhuizen  changed:

   What|Removed |Added

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

-- 
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 18/47] (0018b) Fix for Patch 0018; I have no idea if this is a real fix or not

[Rantala, Valtteri]

This should not have been here at the first place. This patch set is a POC that 
simd32 gives performance boosts for certain benchmarks.  As you said it really 
needs clean up and more testing, before it can be merged.

--
Valtteri

From: mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org] On Behalf Of 
Jason Ekstrand
Sent: Monday, May 21, 2018 7:24 AM
To: Tang, Shaofeng 
Cc: ML mesa-dev 
Subject: Re: [Mesa-dev] [PATCH 18/47] (0018b) Fix for Patch 0018; I have no 
idea if this is a real fix or not

As is evident from patches like this, this series is nowhere near ready for 
upstream.  There's quite a bit of clean up work to do before it will be really 
ready to merge.  I've been working on trying to clean up Francisco's original 
branch and sent out the first 19 ready-for-upstream patches on Friday: 
https://patchwork.freedesktop.org/series/43450/  I intend to send more later 
this week once I get a couple of GPU hangs sorted out.

--Jason

On Sun, May 20, 2018 at 8:29 PM, Shaofeng Tang 
mailto:shaofeng.t...@intel.com>> wrote:
From: Kevin Rogovin mailto:kevin.rogo...@intel.com>>

Change-Id: Ic5948415e0b4d6799b6a88ac507c1999ccb1df39
---
 src/intel/compiler/brw_fs.cpp | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.cpp
index 121f9f8..b089b79 100644
--- a/src/intel/compiler/brw_fs.cpp
+++ b/src/intel/compiler/brw_fs.cpp
@@ -3349,7 +3349,11 @@ fs_visitor::emit_repclear_shader()

assign_constant_locations();
assign_curb_setup();
-   allocate_registers(16, false);
+   /* WARNING: the original SIMD32 series has this line added, in patch
+* "i965/fs: Rework FB write header setup for SIMD32 and better scheduling."
+* but giving this line makes bad things happen later.
+*/
+   // allocate_registers(16, false);

/* Now that we have the uniform assigned, go ahead and force it to a vec4. 
*/
if (uniforms > 0) {
--
2.7.4

___
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 PATCH] virgl: Always assume that ORIGIN_UPPER_LEFT and PIXEL_CENTER* are supported

[Gert Wollny]

Am Donnerstag, den 17.05.2018, 12:33 +0200 schrieb Gert Wollny:
> The driver must support at least one of
> 
>   PIPE_CAP_TGSI_FS_COORD_ORIGIN_UPPER_LEFT
>   PIPE_CAP_TGSI_FS_COORD_ORIGIN_LOWER_LEFT
> 
> and one of
> 
>   PIPE_CAP_TGSI_FS_COORD_PIXEL_CENTER_HALF_INTEGER
>   PIPE_CAP_TGSI_FS_COORD_PIXEL_CENTER_INTEGER
> 
> otherwise glsl_to_tgsi will fire an assert.
> 
> ORIGIN_UPPER_LEFT is the default convention, and is supported by
> all mesa drivers, hence it seems reasonable to always report the caps
> to be enabled.  On gles ORIGIN_LOWER_LEFT is generally not supported,
> so we rely on the caps reported by the host that depend on whether we
> run on an GL or an EGL host.
> 
> For PIXEL_CENTER it is completely host driver dependend on what is
> supported, and since we do not report the actual host driver
> capabilities
> it is best to mark both as supported, this is how it works for a GL
> host too.
> 
> Fixes:
>   dEQP-GLES3.functional.shaders.builtin_variable.fragcoord_xyz
>   dEQP-GLES3.functional.shaders.metamorphic.bubblesort_flag.variant_1
>   dEQP-GLES3.functional.shaders.metamorphic.bubblesort_flag.variant_2
> 
> Signed-off-by: Gert Wollny 
> ---
> When I return 1 for  PIPE_CAP_TGSI_FS_COORD_ORIGIN_LOWER_LEFT too,
> the test fail on an r600g gle host. Likewise, when I disable one of
> the two PIXEL_CENTER caps. 
> 
> However, I send this as an RFC, because there are some of the
> *texture* tests that flip: some start to pass with this patch and
> some start to fail, in total 16 test are fixed with this patch and 15
> regress on Intel. I have not yet established whether these tests are
> actually unstable.

After quite some testing I've come to the conclusion that the tests
that flip between Pass and Fail are tests that are generally unstable
when run inside Qemu, so it should be save to apply it. 

Best, 
Gert 

> 
> thanks for any comments.
> Gert
> 
>  src/gallium/drivers/virgl/virgl_screen.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/src/gallium/drivers/virgl/virgl_screen.c
> b/src/gallium/drivers/virgl/virgl_screen.c
> index 1ca9e85de7..f4fdc61b14 100644
> --- a/src/gallium/drivers/virgl/virgl_screen.c
> +++ b/src/gallium/drivers/virgl/virgl_screen.c
> @@ -88,9 +88,10 @@ virgl_get_param(struct pipe_screen *screen, enum
> pipe_cap param)
> case PIPE_CAP_INDEP_BLEND_FUNC:
>return vscreen->caps.caps.v1.bset.indep_blend_func;
> case PIPE_CAP_TGSI_FS_COORD_ORIGIN_UPPER_LEFT:
> -   case PIPE_CAP_TGSI_FS_COORD_ORIGIN_LOWER_LEFT:
> case PIPE_CAP_TGSI_FS_COORD_PIXEL_CENTER_HALF_INTEGER:
> case PIPE_CAP_TGSI_FS_COORD_PIXEL_CENTER_INTEGER:
> +  return 1;
> +   case PIPE_CAP_TGSI_FS_COORD_ORIGIN_LOWER_LEFT:
>return vscreen->caps.caps.v1.bset.fragment_coord_conventions;
> case PIPE_CAP_DEPTH_CLIP_DISABLE:
>return vscreen->caps.caps.v1.bset.depth_clip_disable;
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev