[Mesa-dev] [Bug 105377] Native dependency 'libtizonia' not found

[bugzilla-daemon]

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

Bug ID: 105377
   Summary: Native dependency 'libtizonia' not found
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Keywords: regression
  Severity: normal
  Priority: medium
 Component: Other
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: v...@freedesktop.org
QA Contact: mesa-dev@lists.freedesktop.org

$ meson builddir
[...]
Meson encountered an error in file meson.build, line 494, column 2:
Native dependency 'libtizonia' not found

-- 
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 v3 7/7] i965: ASTC5x5 workaround logic for blorp

[Rogovin, Kevin]

What would be a good place for this in the blorp code? I am guessing the only 
time that blorp would trigger an astc read is in blitting… what would you 
suggest for keeping it inside of blorp? The blorp_context struct is part of 
blorp not i965… to keep it in blorp would mean it needs to be passed down along 
the function calls somehow …

-Kevin

From: Jason Ekstrand [mailto:ja...@jlekstrand.net]
Sent: Tuesday, March 6, 2018 6:07 PM
To: Rogovin, Kevin 
Cc: ML mesa-dev 
Subject: Re: [Mesa-dev] [PATCH v3 7/7] i965: ASTC5x5 workaround logic for blorp

On Tue, Feb 27, 2018 at 1:30 AM, 
> wrote:
From: Kevin Rogovin >

Signed-off-by: Kevin Rogovin 
>
---
 src/mesa/drivers/dri/i965/genX_blorp_exec.c |  5 +
 src/mesa/drivers/dri/i965/intel_tex_image.c | 16 
 2 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/genX_blorp_exec.c 
b/src/mesa/drivers/dri/i965/genX_blorp_exec.c
index 062171a..b7c35e9 100644
--- a/src/mesa/drivers/dri/i965/genX_blorp_exec.c
+++ b/src/mesa/drivers/dri/i965/genX_blorp_exec.c
@@ -230,6 +230,11 @@ genX(blorp_exec)(struct blorp_batch *batch,
struct gl_context *ctx = >ctx;
bool check_aperture_failed_once = false;

+   if (brw->astc5x5_wa.blorp_sampling_from_astc5x5) {
+  gen9_set_astc5x5_wa_mode(brw, BRW_ASTC5x5_WA_MODE_HAS_ASTC5x5);
+   } else {
+  gen9_set_astc5x5_wa_mode(brw, BRW_ASTC5x5_WA_MODE_HAS_AUX);
+   }
/* Flush the sampler and render caches.  We definitely need to flush the
 * sampler cache so that we get updated contents from the render cache for
 * the glBlitFramebuffer() source.  Also, we are sometimes warned in the
diff --git a/src/mesa/drivers/dri/i965/intel_tex_image.c 
b/src/mesa/drivers/dri/i965/intel_tex_image.c
index e25bc9a..38967fb 100644
--- a/src/mesa/drivers/dri/i965/intel_tex_image.c
+++ b/src/mesa/drivers/dri/i965/intel_tex_image.c
@@ -824,10 +824,18 @@ intel_get_tex_sub_image(struct gl_context *ctx,
DBG("%s\n", __func__);

if (_mesa_is_bufferobj(ctx->Pack.BufferObj)) {
-  if (intel_gettexsubimage_blorp(brw, texImage,
- xoffset, yoffset, zoffset,
- width, height, depth, format, type,
- pixels, >Pack))
+  bool blorp_success;
+
+  brw->astc5x5_wa.blorp_sampling_from_astc5x5 =
+ (texImage->TexFormat == MESA_FORMAT_RGBA_ASTC_5x5 ||
+  texImage->TexFormat == MESA_FORMAT_SRGB8_ALPHA8_ASTC_5x5);
+  blorp_success = intel_gettexsubimage_blorp(brw, texImage,
+ xoffset, yoffset, zoffset,
+ width, height, depth,
+ format, type, pixels,
+ >Pack);
+  brw->astc5x5_wa.blorp_sampling_from_astc5x5 = false;
+  if (blorp_success)

Let's keep all of the code for detecting whether or not BLORP needs and 
implementing it together in BLORP.  We can just as easily detect ASTC5x5 there 
as here.

  return;

   perf_debug("%s: fallback to CPU mapping in PBO case\n", __func__);
--
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] [PATCH v3 3/7] i965: set ASTC5x5 workaround texture type tracking on texture validate

[Rogovin, Kevin]

Originally, I had the entire astc and aux checking in a dedicated function; 
would that be more preferable?

-Kevin

From: Jason Ekstrand [mailto:ja...@jlekstrand.net]
Sent: Tuesday, March 6, 2018 6:02 PM
To: Rogovin, Kevin 
Cc: ML mesa-dev 
Subject: Re: [Mesa-dev] [PATCH v3 3/7] i965: set ASTC5x5 workaround texture 
type tracking on texture validate

I don't really like this being in texture validation.  It has nothing to do 
with texture validation.  Instead, we should put it in 
brw_predraw_resolve_inputs and do it as a pre-pass.  This would let us store 
astc5x5_present as a local variable.  Also, I don't think we need 
texture_with_auxiliary_present for anything since our solution is to resolve 
those.

On Tue, Feb 27, 2018 at 1:30 AM, 
> wrote:
From: Kevin Rogovin >

Signed-off-by: Kevin Rogovin 
>
---
 src/mesa/drivers/dri/i965/intel_tex_validate.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/intel_tex_validate.c 
b/src/mesa/drivers/dri/i965/intel_tex_validate.c
index eaa60ba..2bf6c65 100644
--- a/src/mesa/drivers/dri/i965/intel_tex_validate.c
+++ b/src/mesa/drivers/dri/i965/intel_tex_validate.c
@@ -179,6 +179,8 @@ brw_validate_textures(struct brw_context *brw)
struct gl_context *ctx = >ctx;
const int max_enabled_unit = ctx->Texture._MaxEnabledTexImageUnit;

+   brw->astc5x5_wa.texture_astc5x5_present = false;
+   brw->astc5x5_wa.texture_with_auxilary_present = false;
for (int unit = 0; unit <= max_enabled_unit; unit++) {
   struct gl_texture_object *tex_obj = ctx->Texture.Unit[unit]._Current;

@@ -194,5 +196,18 @@ brw_validate_textures(struct brw_context *brw)

   intel_update_max_level(tex_obj, sampler);
   intel_finalize_mipmap_tree(brw, tex_obj);
+
+  /* ASTC5x5 workaround needs to know if textures in use have
+   * auxilary in buffers and/or a texture in use is ASTC5x5
+   */
+  struct intel_texture_object *tex = intel_texture_object(tex_obj);
+  struct intel_mipmap_tree *mt = tex->mt;
+  if (mt && mt->aux_usage != ISL_AUX_USAGE_NONE) {
+ brw->astc5x5_wa.texture_with_auxilary_present = true;
+  }
+  if (tex->_Format == MESA_FORMAT_RGBA_ASTC_5x5 ||
+  tex->_Format == MESA_FORMAT_SRGB8_ALPHA8_ASTC_5x5) {
+ brw->astc5x5_wa.texture_astc5x5_present = true;
+  }
}
 }
--
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] [PATCH] anv/entrypoints: VkGetDeviceProcAddr returns NULL for core instance commands

[Iago Toral]

On Tue, 2018-03-06 at 14:17 +0100, Iago Toral wrote:
> On Tue, 2018-03-06 at 13:05 +, Emil Velikov wrote:
> > On 6 March 2018 at 12:26, Iago Toral  wrote:
> > > On Tue, 2018-03-06 at 12:16 +, Emil Velikov wrote:
> > > > On 6 March 2018 at 12:09, Iago Toral  wrote:
> > > > > On Tue, 2018-03-06 at 11:21 +, Emil Velikov wrote:
> > > > > > On 6 March 2018 at 09:57, Bas Nieuwenhuizen  > > > > > .o
> > > > > > rg>
> > > > > > wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > On Tue, Mar 6, 2018 at 8:02 AM, Iago Toral  > > > > > > .c
> > > > > > > om>
> > > > > > > wrote:
> > > > > > > > 
> > > > > > > > On Mon, 2018-03-05 at 12:11 +, Emil Velikov wrote:
> > > > > > > > > Hi Iago,
> > > > > > > > > 
> > > > > > > > > Top level questions:
> > > > > > > > > 
> > > > > > > > > I think this and the original commit should go to
> > > > > > > > > stable
> > > > > > > > > right?
> > > > > > > > 
> > > > > > > > I am not sure if this qualifies for stable: these
> > > > > > > > patches
> > > > > > > > don't
> > > > > > > > fix any
> > > > > > > > user-visible bugs. If an application was calling
> > > > > > > > vkGetDeviceProcAddr to
> > > > > > > > get pointers to non-device functions (which is
> > > > > > > > incorrect
> > > > > > > > by
> > > > > > > > the
> > > > > > > > spec)
> > > > > > > > the previous behavior would allow it to get away with
> > > > > > > > it
> > > > > > > > without
> > > > > > > > issues, bit with these patches it will start to crash
> > > > > > > > since
> > > > > > > > it
> > > > > > > > will
> > > > > > > > receive NULL pointers.
> > > > > > > > 
> > > > > > 
> > > > > > According to Lenny's comment in the github issue there's
> > > > > > nothing
> > > > > > to
> > > > > > be
> > > > > > concerned. Namely:
> > > > > >  - "The pointers being returned are invalid. ... trying to
> > > > > > use
> > > > > > them
> > > > > > will result in a crash."
> > > > > >  - "Wolfenstein was acquiring, but not using the pointers."
> > > > > 
> > > > > Because it is not using the pointers :), if some other app is
> > > > > using
> > > > > them it will start to crash.
> > > > > 
> > > > > But that was not my point, my point was that this doesn't fix
> > > > > anything
> > > > > for users, so I was questioning whether it was material for
> > > > > stable
> > > > > based on that.
> > > > > 
> > > > 
> > > > Surely we don't want to apps be written against the current
> > > > incorrect
> > > > behaviour?
> > > > Which may go unnoticed since there are no validation/loader
> > > > checks
> > > > for
> > > > this (based on the github issue).
> > > 
> > > If there is such an application, and this patch makes it into the
> > > stable release, that application will probably start to crash.
> > 
> > Such an application will crash _regardless_ of the patch, as
> > mentioned earlier.
> > That is as per Lenny's analysis - haven't checked it personally.
> 
> I am not sure why he says that, the point of using vkGet*Addr is to
> get
> a driver function pointer so you can skip the loader completely. If
> you
> get a valid pointer and you pass valid parameters to it, I think it
> should work be just fine, but have't tested it myself, I can try to
> do
> that and see what happens.

Ok, I tested this and it didn't crash for me, but Lenny is is right
that the loader is doing wrapping/unwrapping of some of the function
parameters before this reaches the driver, so even if it doesn't crash
calling these functions won't produce correct results.

This means that applications that were doing this and were not
crashing, will certainly start to crash now (if they actually use the
function pointers), but I don't think this is very relevant, since 
even if they were not crashing before the patch they certainly were not
working properly anyway.

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

[Mesa-dev] [Bug 105376] es2gears_wayland reports 120 fps while drawing at 60 fps

[bugzilla-daemon]

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

Daniel van Vugt  changed:

   What|Removed |Added

 CC||daniel.van.vugt@canonical.c
   ||om

-- 
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 105376] es2gears_wayland reports 120 fps while drawing at 60 fps

[bugzilla-daemon]

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

--- Comment #1 from Daniel van Vugt  ---
Also seen in gnome-shell on Ubuntu 18.04:

$ es2gears_wayland
EGL_VERSION = 1.4 (DRI2)
vertex shader info:
fragment shader info:
info:
597 frames in 5.0 seconds = 119.138 FPS
600 frames in 5.0 seconds = 119.880 FPS
598 frames in 5.0 seconds = 119.481 FPS
600 frames in 5.0 seconds = 119.952 FPS
600 frames in 5.0 seconds = 119.880 FPS
600 frames in 5.0 seconds = 119.880 FPS
596 frames in 5.0 seconds = 119.105 FPS

But strangely not in weston:

$ es2gears_wayland
EGL_VERSION = 1.4 (DRI2)
vertex shader info:
fragment shader info:
info:
301 frames in 5.0 seconds = 60.176 FPS
300 frames in 5.0 seconds = 59.952 FPS
300 frames in 5.0 seconds = 59.952 FPS
300 frames in 5.0 seconds = 59.964 FPS
300 frames in 5.0 seconds = 59.928 FPS
300 frames in 5.0 seconds = 59.964 FPS

-- 
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 105376] es2gears_wayland reports 120 fps while drawing at 60 fps

[bugzilla-daemon]

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

Bug ID: 105376
   Summary: es2gears_wayland reports 120 fps while drawing at 60
fps
   Product: Mesa
   Version: unspecified
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Demos
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: b...@linkmauve.fr
QA Contact: mesa-dev@lists.freedesktop.org

es2gears_wayland is requesting two frame callbacks per frame, and then
reporting a framerate double of what it is actually drawing, see this log:

[1648215.456]  -> wl_surface@6.frame(new id wl_callback@11)
[1648215.507]  -> wl_surface@6.frame(new id wl_callback@12)
[1648215.552]  -> wl_surface@6.attach(wl_buffer@14, 0, 0)  
[1648215.577]  -> wl_surface@6.damage(0, 0, 2147483647, 2147483647)
[1648215.654]  -> wl_surface@6.commit()
[1648226.261] wl_display@1.delete_id(11)
[1648226.318] wl_display@1.delete_id(12)
[1648226.345] wl_callb...@11.done(1097662536)
[1648226.368] wl_buffer@9.release()  
[1648226.378] wl_callb...@12.done(1097662536)
[1648227.256]  -> wl_surface@6.frame(new id wl_callback@12)
[1648227.327]  -> wl_surface@6.frame(new id wl_callback@11)
[1648227.345]  -> wl_surface@6.attach(wl_buffer@9, 0, 0)   
[1648227.373]  -> wl_surface@6.damage(0, 0, 2147483647, 2147483647)
[1648227.473]  -> wl_surface@6.commit()
[1648247.237] wl_display@1.delete_id(12)
[1648247.288] wl_display@1.delete_id(11)
[1648247.309] wl_callb...@12.done(1097662553)
[1648247.341] wl_buffer@14.release() 
[1648247.356] wl_callb...@11.done(1097662553)

This is apparently caused by the fix for bug 101814, see also
https://gitlab.gnome.org/GNOME/mutter/issues/55

-- 
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 102542] mesa-17.2.0/src/gallium/state_trackers/nine/nine_ff.c:1938: bad assignment ?

[bugzilla-daemon]

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

--- Comment #3 from Axel Davy  ---
It seems I forgot to push such a patch. Thanks for reminding me.

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

[Mesa-dev] [Bug 99179] Mesa freezez the pc when running nativ games for linux

[bugzilla-daemon]

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

--- Comment #10 from Timothy Arceri  ---
Does this work now? There have been a bunch of improvements to this driver
recently.

-- 
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 102542] mesa-17.2.0/src/gallium/state_trackers/nine/nine_ff.c:1938: bad assignment ?

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

   Assignee|mesa-dev@lists.freedesktop. |davyax...@gmail.com
   |org |
 Status|NEW |ASSIGNED

--- Comment #2 from Timothy Arceri  ---
Can we close this now Axel?

-- 
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] spirv: Add SpvCapabilityShaderViewportIndexLayerEXT

[Samuel Iglesias Gonsálvez]

On 05/03/18 22:58, Caio Marcelo de Oliveira Filho wrote:
> This capability allows gl_ViewportIndex and gl_Layer to also be used
> as outputs in Vertex and Tesselation shaders.
>
> v2: Make conditional to the capability, add gl_Layer, add tesselation
> shaders. (Iago)
>
> v3: Don't export to tesselation control shader.
>
> v4: Add Reviewd-by tag.
>
> Reviewed-by: Iago Toral Quiroga 
> ---
>
> Iago, I don't have write access to the repository. Could you apply
> this?

I pushed the patch for you :-)

Sam

>  src/compiler/shader_info.h | 1 +
>  src/compiler/spirv/spirv_to_nir.c  | 4 
>  src/compiler/spirv/vtn_variables.c | 8 
>  3 files changed, 13 insertions(+)
>
> diff --git a/src/compiler/shader_info.h b/src/compiler/shader_info.h
> index e7fd7dbe62..2fcbde74be 100644
> --- a/src/compiler/shader_info.h
> +++ b/src/compiler/shader_info.h
> @@ -43,6 +43,7 @@ struct spirv_supported_capabilities {
> bool multiview;
> bool variable_pointers;
> bool storage_16bit;
> +   bool shader_viewport_index_layer;
>  };
>  
>  typedef struct shader_info {
> diff --git a/src/compiler/spirv/spirv_to_nir.c 
> b/src/compiler/spirv/spirv_to_nir.c
> index c6df764682..fdb2993db5 100644
> --- a/src/compiler/spirv/spirv_to_nir.c
> +++ b/src/compiler/spirv/spirv_to_nir.c
> @@ -3203,6 +3203,10 @@ vtn_handle_preamble_instruction(struct vtn_builder *b, 
> SpvOp opcode,
>   spv_check_supported(storage_16bit, cap);
>   break;
>  
> +  case SpvCapabilityShaderViewportIndexLayerEXT:
> + spv_check_supported(shader_viewport_index_layer, cap);
> + break;
> +
>default:
>   vtn_fail("Unhandled capability");
>}
> diff --git a/src/compiler/spirv/vtn_variables.c 
> b/src/compiler/spirv/vtn_variables.c
> index 7e8a090add..11d2aabac8 100644
> --- a/src/compiler/spirv/vtn_variables.c
> +++ b/src/compiler/spirv/vtn_variables.c
> @@ -1187,6 +1187,10 @@ vtn_get_builtin_location(struct vtn_builder *b,
>   *mode = nir_var_shader_in;
>else if (b->shader->info.stage == MESA_SHADER_GEOMETRY)
>   *mode = nir_var_shader_out;
> +  else if (b->options && b->options->caps.shader_viewport_index_layer &&
> +   (b->shader->info.stage == MESA_SHADER_VERTEX ||
> +b->shader->info.stage == MESA_SHADER_TESS_EVAL))
> + *mode = nir_var_shader_out;
>else
>   vtn_fail("invalid stage for SpvBuiltInLayer");
>break;
> @@ -1194,6 +1198,10 @@ vtn_get_builtin_location(struct vtn_builder *b,
>*location = VARYING_SLOT_VIEWPORT;
>if (b->shader->info.stage == MESA_SHADER_GEOMETRY)
>   *mode = nir_var_shader_out;
> +  else if (b->options && b->options->caps.shader_viewport_index_layer &&
> +   (b->shader->info.stage == MESA_SHADER_VERTEX ||
> +b->shader->info.stage == MESA_SHADER_TESS_EVAL))
> + *mode = nir_var_shader_out;
>else if (b->shader->info.stage == MESA_SHADER_FRAGMENT)
>   *mode = nir_var_shader_in;
>else




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

Re: [Mesa-dev] [PATCH] dri_util: when overriding, always reset the core version

[Tapani Pälli]

On 03/07/2018 12:36 AM, Marek Olšák wrote:

On Mon, Mar 5, 2018 at 7:33 AM, Tapani Pälli  wrote:

Hi;

On 03/02/2018 03:25 PM, Andres Gomez wrote:


This way we won't fail when validating just because we may have a non
overriden core version that is lower than the requested one, even when
the compat version is high enough.



Do I understand correctly that this happens because when version asked is >
3.2 then we always do core context, even when overriding to compat profile?


No. 3.2COMPAT will set both core and compat version limits to 3.2.



I see, I was trying to understand why core version matters when using 
compat profile but I'm not sure I get it, it probably should not matter.


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

Re: [Mesa-dev] [PATCH] android: anv: add libmesa_intel_dev static dependency

[Tapani Pälli]

Thanks, will push this;
Reviewed-by: Tapani Pälli 

On 03/07/2018 01:15 AM, Mauro Rossi wrote:

Fixes the following building errors:

external/mesa/src/intel/vulkan/anv_device.c:300: error: undefined reference to 
'gen_get_pci_device_id_override'
external/mesa/src/intel/vulkan/anv_device.c:312: error: undefined reference to 
'gen_get_device_name'
external/mesa/src/intel/vulkan/anv_device.c:313: error: undefined reference to 
'gen_get_device_info'
clang.real: error: linker command failed with exit code 1 (use -v to see 
invocation)

Fixes: 272bef0601a "intel: Split gen_device_info out into libintel_dev"
---
  src/intel/Android.vulkan.mk | 1 +
  1 file changed, 1 insertion(+)

diff --git a/src/intel/Android.vulkan.mk b/src/intel/Android.vulkan.mk
index 419d560b0c..0ec0d78a2f 100644
--- a/src/intel/Android.vulkan.mk
+++ b/src/intel/Android.vulkan.mk
@@ -300,6 +300,7 @@ LOCAL_WHOLE_STATIC_LIBRARIES := \
libmesa_blorp \
libmesa_compiler \
libmesa_intel_common \
+   libmesa_intel_dev \
libmesa_vulkan_common \
libmesa_anv_gen7 \
libmesa_anv_gen75 \


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

[Mesa-dev] [Bug 45466] Updated configure.ac check for llvm-config to use 32 version when appropriate

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

-- 
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 43068] MESA fails to draw gnome-shell properly | Half of letters are not drawn.

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

 Resolution|--- |WORKSFORME
 Status|NEW |RESOLVED

--- Comment #1 from Timothy Arceri  ---
Gnome shell and Mesa have changed alot since this was reported. I'm going to
assume this is working and close since we don't seem to have any recent reports
like this.

-- 
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 40600] avogadro crashes on startup due to bad target in _mesa_select_tex_object()

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #3 from Timothy Arceri  ---
Since this was working for Ken in 7.11 and there have been no further reports
I'm going to assume this still works. Closing.

-- 
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 13705] crash in quad_twoside_unfilled when starting k3dsurf

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|NEW |RESOLVED

--- Comment #1 from Timothy Arceri  ---
This function doesn't seem to exist in modern mesa. Closing.

-- 
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 18338] check_os_sse_support can leak exception under win32

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

   Assignee|mesa-dev@lists.freedesktop. |bri...@vmware.com
   |org |

--- Comment #3 from Timothy Arceri  ---
Hi Brain,

Looks like this patch was never applied. Are you guys interested in it? Or
should we close the bug?

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

[Mesa-dev] [Bug 101814] es2gears_wayland only achieves 40 FPS (in Weston and Gnome Shell)

[bugzilla-daemon]

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

--- Comment #5 from Daniel van Vugt  ---
Fix released in mesa-demos 8.4.0

Although this is a bit curious:
https://gitlab.gnome.org/GNOME/mutter/issues/55

-- 
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] ac/nir: don't put lod into args if it's zero.

[Timothy Arceri]

Reviewed-by: Timothy Arceri 

On 07/03/18 14:26, Dave Airlie wrote:

From: Dave Airlie 

If it's zero but put it in args we still end up consuming a
register for it.

This fixes some spilling in the NIR paths in Dirt Rally that
isn't seen with TGSI.

Signed-off-by: Dave Airlie 
---
  src/amd/common/ac_nir_to_llvm.c | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index f808dc89490..432b88a59b0 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -5094,8 +5094,7 @@ static void visit_tex(struct ac_nir_context *ctx, 
nir_tex_instr *instr)
}
  
  	/* Pack LOD */

-   if (lod && ((instr->op == nir_texop_txl && !lod_is_zero) ||
-   instr->op == nir_texop_txf)) {
+   if (lod && ((instr->op == nir_texop_txl || instr->op == nir_texop_txf) 
&& !lod_is_zero)) {
address[count++] = lod;
} else if (instr->op == nir_texop_txf_ms && sample_index) {
address[count++] = sample_index;


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

[Mesa-dev] [PATCH] ac/nir: don't put lod into args if it's zero.

[Dave Airlie]

From: Dave Airlie 

If it's zero but put it in args we still end up consuming a
register for it.

This fixes some spilling in the NIR paths in Dirt Rally that
isn't seen with TGSI.

Signed-off-by: Dave Airlie 
---
 src/amd/common/ac_nir_to_llvm.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index f808dc89490..432b88a59b0 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -5094,8 +5094,7 @@ static void visit_tex(struct ac_nir_context *ctx, 
nir_tex_instr *instr)
}
 
/* Pack LOD */
-   if (lod && ((instr->op == nir_texop_txl && !lod_is_zero) ||
-   instr->op == nir_texop_txf)) {
+   if (lod && ((instr->op == nir_texop_txl || instr->op == nir_texop_txf) 
&& !lod_is_zero)) {
address[count++] = lod;
} else if (instr->op == nir_texop_txf_ms && sample_index) {
address[count++] = sample_index;
-- 
2.14.3

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

[Mesa-dev] [Bug 105285] Mesa-utils -8.4 - glxinfo report has a blank value in GL_NUM_SHADING_LANGUAGE_VERSIONS subsection and also the aligniment below 4.3 seems not correct

[bugzilla-daemon]

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

--- Comment #9 from Arun Sivaraman  ---
you don't have to use my app to see the glxinfo -l issue i mentioned before , i
have already attached the glxinfo -l report of my gtx 850m. Other than this I
haven't seen any other issues. Thanks

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

[Mesa-dev] [PATCH 3/3] ac: make use of if/loop build helpers

[Timothy Arceri]

These helpers insert the basic block in the same order as they
appear in NIR making it easier to follow LLVM IR dumps. The helpers
also insert more useful labels onto the blocks.

TGSI use the line number of the corresponding opcode in the TGSI
dump as the label id, here we use the corresponding block index
from NIR.
---
 src/amd/common/ac_nir_to_llvm.c | 60 +
 1 file changed, 18 insertions(+), 42 deletions(-)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index cda91fe8bf..dc463ed253 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -5237,17 +5237,15 @@ static void visit_ssa_undef(struct ac_nir_context *ctx,
_mesa_hash_table_insert(ctx->defs, >def, undef);
 }
 
-static void visit_jump(struct ac_nir_context *ctx,
+static void visit_jump(struct ac_llvm_context *ctx,
   const nir_jump_instr *instr)
 {
switch (instr->type) {
case nir_jump_break:
-   LLVMBuildBr(ctx->ac.builder, ctx->break_block);
-   LLVMClearInsertionPosition(ctx->ac.builder);
+   ac_build_break(ctx);
break;
case nir_jump_continue:
-   LLVMBuildBr(ctx->ac.builder, ctx->continue_block);
-   LLVMClearInsertionPosition(ctx->ac.builder);
+   ac_build_continue(ctx);
break;
default:
fprintf(stderr, "Unknown NIR jump instr: ");
@@ -5285,7 +5283,7 @@ static void visit_block(struct ac_nir_context *ctx, 
nir_block *block)
visit_ssa_undef(ctx, nir_instr_as_ssa_undef(instr));
break;
case nir_instr_type_jump:
-   visit_jump(ctx, nir_instr_as_jump(instr));
+   visit_jump(>ac, nir_instr_as_jump(instr));
break;
default:
fprintf(stderr, "Unknown NIR instr type: ");
@@ -5302,56 +5300,34 @@ static void visit_if(struct ac_nir_context *ctx, nir_if 
*if_stmt)
 {
LLVMValueRef value = get_src(ctx, if_stmt->condition);
 
-   LLVMValueRef fn = 
LLVMGetBasicBlockParent(LLVMGetInsertBlock(ctx->ac.builder));
-   LLVMBasicBlockRef merge_block =
-   LLVMAppendBasicBlockInContext(ctx->ac.context, fn, "");
-   LLVMBasicBlockRef if_block =
-   LLVMAppendBasicBlockInContext(ctx->ac.context, fn, "");
-   LLVMBasicBlockRef else_block = merge_block;
-   if (!exec_list_is_empty(_stmt->else_list))
-   else_block = LLVMAppendBasicBlockInContext(
-   ctx->ac.context, fn, "");
-
-   LLVMValueRef cond = LLVMBuildICmp(ctx->ac.builder, LLVMIntNE, value,
- ctx->ac.i32_0, "");
-   LLVMBuildCondBr(ctx->ac.builder, cond, if_block, else_block);
-
-   LLVMPositionBuilderAtEnd(ctx->ac.builder, if_block);
+   nir_block *then_block =
+   (nir_block *) exec_list_get_head(_stmt->then_list);
+
+   ac_build_uif(>ac, value, then_block->index);
+
visit_cf_list(ctx, _stmt->then_list);
-   if (LLVMGetInsertBlock(ctx->ac.builder))
-   LLVMBuildBr(ctx->ac.builder, merge_block);
 
if (!exec_list_is_empty(_stmt->else_list)) {
-   LLVMPositionBuilderAtEnd(ctx->ac.builder, else_block);
+   nir_block *else_block =
+   (nir_block *) exec_list_get_head(_stmt->else_list);
+
+   ac_build_else(>ac, else_block->index);
visit_cf_list(ctx, _stmt->else_list);
-   if (LLVMGetInsertBlock(ctx->ac.builder))
-   LLVMBuildBr(ctx->ac.builder, merge_block);
}
 
-   LLVMPositionBuilderAtEnd(ctx->ac.builder, merge_block);
+   ac_build_endif(>ac, then_block->index);
 }
 
 static void visit_loop(struct ac_nir_context *ctx, nir_loop *loop)
 {
-   LLVMValueRef fn = 
LLVMGetBasicBlockParent(LLVMGetInsertBlock(ctx->ac.builder));
-   LLVMBasicBlockRef continue_parent = ctx->continue_block;
-   LLVMBasicBlockRef break_parent = ctx->break_block;
+   nir_block *first_loop_block =
+   (nir_block *) exec_list_get_head(>body);
 
-   ctx->continue_block =
-   LLVMAppendBasicBlockInContext(ctx->ac.context, fn, "");
-   ctx->break_block =
-   LLVMAppendBasicBlockInContext(ctx->ac.context, fn, "");
+   ac_build_bgnloop(>ac, first_loop_block->index);
 
-   LLVMBuildBr(ctx->ac.builder, ctx->continue_block);
-   LLVMPositionBuilderAtEnd(ctx->ac.builder, ctx->continue_block);
visit_cf_list(ctx, >body);
 
-   if (LLVMGetInsertBlock(ctx->ac.builder))
-   LLVMBuildBr(ctx->ac.builder, ctx->continue_block);
-   LLVMPositionBuilderAtEnd(ctx->ac.builder, ctx->break_block);
-
-   ctx->continue_block = continue_parent;
-   ctx->break_block = break_parent;
+   ac_build_endloop(>ac, first_loop_block->index);
 }
 
 

[Mesa-dev] [PATCH 1/3] ac: add if/loop build helpers

[Timothy Arceri]

These have been ported over from radeonsi.
---
 src/amd/common/ac_llvm_build.c  | 189 
 src/amd/common/ac_llvm_build.h  |  20 +
 src/amd/common/ac_nir_to_llvm.c |   2 +
 3 files changed, 211 insertions(+)

diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c
index 8140184b3b..da614e339f 100644
--- a/src/amd/common/ac_llvm_build.c
+++ b/src/amd/common/ac_llvm_build.c
@@ -41,6 +41,16 @@
 
 #include "shader_enums.h"
 
+#define AC_LLVM_INITIAL_CF_DEPTH 4
+
+/* Data for if/else/endif and bgnloop/endloop control flow structures.
+ */
+struct ac_llvm_flow {
+   /* Loop exit or next part of if/else/endif. */
+   LLVMBasicBlockRef next_block;
+   LLVMBasicBlockRef loop_entry_block;
+};
+
 /* Initialize module-independent parts of the context.
  *
  * The caller is responsible for initializing ctx::module and ctx::builder.
@@ -105,6 +115,14 @@ ac_llvm_context_init(struct ac_llvm_context *ctx, 
LLVMContextRef context,
ctx->empty_md = LLVMMDNodeInContext(ctx->context, NULL, 0);
 }
 
+void
+ac_llvm_context_dispose(struct ac_llvm_context *ctx)
+{
+   free(ctx->flow);
+   ctx->flow = NULL;
+   ctx->flow_depth_max = 0;
+}
+
 int
 ac_get_llvm_num_components(LLVMValueRef value)
 {
@@ -2132,3 +2150,174 @@ LLVMTypeRef ac_array_in_const32_addr_space(LLVMTypeRef 
elem_type)
return LLVMPointerType(LLVMArrayType(elem_type, 0),
   AC_CONST_32BIT_ADDR_SPACE);
 }
+
+static struct ac_llvm_flow *
+get_current_flow(struct ac_llvm_context *ctx)
+{
+   if (ctx->flow_depth > 0)
+   return >flow[ctx->flow_depth - 1];
+   return NULL;
+}
+
+static struct ac_llvm_flow *
+get_innermost_loop(struct ac_llvm_context *ctx)
+{
+   for (unsigned i = ctx->flow_depth; i > 0; --i) {
+   if (ctx->flow[i - 1].loop_entry_block)
+   return >flow[i - 1];
+   }
+   return NULL;
+}
+
+static struct ac_llvm_flow *
+push_flow(struct ac_llvm_context *ctx)
+{
+   struct ac_llvm_flow *flow;
+
+   if (ctx->flow_depth >= ctx->flow_depth_max) {
+   unsigned new_max = MAX2(ctx->flow_depth << 1,
+   AC_LLVM_INITIAL_CF_DEPTH);
+
+   ctx->flow = realloc(ctx->flow, new_max * sizeof(*ctx->flow));
+   ctx->flow_depth_max = new_max;
+   }
+
+   flow = >flow[ctx->flow_depth];
+   ctx->flow_depth++;
+
+   flow->next_block = NULL;
+   flow->loop_entry_block = NULL;
+   return flow;
+}
+
+static void set_basicblock_name(LLVMBasicBlockRef bb, const char *base,
+   int label_id)
+{
+   char buf[32];
+   snprintf(buf, sizeof(buf), "%s%d", base, label_id);
+   LLVMSetValueName(LLVMBasicBlockAsValue(bb), buf);
+}
+
+/* Append a basic block at the level of the parent flow.
+ */
+static LLVMBasicBlockRef append_basic_block(struct ac_llvm_context *ctx,
+   const char *name)
+{
+   assert(ctx->flow_depth >= 1);
+
+   if (ctx->flow_depth >= 2) {
+   struct ac_llvm_flow *flow = >flow[ctx->flow_depth - 2];
+
+   return LLVMInsertBasicBlockInContext(ctx->context,
+flow->next_block, name);
+   }
+
+   LLVMValueRef main_fn =
+   LLVMGetBasicBlockParent(LLVMGetInsertBlock(ctx->builder));
+   return LLVMAppendBasicBlockInContext(ctx->context, main_fn, name);
+}
+
+/* Emit a branch to the given default target for the current block if
+ * applicable -- that is, if the current block does not already contain a
+ * branch from a break or continue.
+ */
+static void emit_default_branch(LLVMBuilderRef builder,
+   LLVMBasicBlockRef target)
+{
+   if (!LLVMGetBasicBlockTerminator(LLVMGetInsertBlock(builder)))
+LLVMBuildBr(builder, target);
+}
+
+void ac_build_bgnloop(struct ac_llvm_context *ctx, int label_id)
+{
+   struct ac_llvm_flow *flow = push_flow(ctx);
+   flow->loop_entry_block = append_basic_block(ctx, "LOOP");
+   flow->next_block = append_basic_block(ctx, "ENDLOOP");
+   set_basicblock_name(flow->loop_entry_block, "loop", label_id);
+   LLVMBuildBr(ctx->builder, flow->loop_entry_block);
+   LLVMPositionBuilderAtEnd(ctx->builder, flow->loop_entry_block);
+}
+
+void ac_build_break(struct ac_llvm_context *ctx)
+{
+   struct ac_llvm_flow *flow = get_innermost_loop(ctx);
+   LLVMBuildBr(ctx->builder, flow->next_block);
+}
+
+void ac_build_continue(struct ac_llvm_context *ctx)
+{
+   struct ac_llvm_flow *flow = get_innermost_loop(ctx);
+   LLVMBuildBr(ctx->builder, flow->loop_entry_block);
+}
+
+void ac_build_else(struct ac_llvm_context *ctx, int label_id)
+{
+   struct ac_llvm_flow *current_branch = get_current_flow(ctx);
+   LLVMBasicBlockRef endif_block;
+
+   assert(!current_branch->loop_entry_block);
+
+   

[Mesa-dev] [PATCH 2/3] radeonsi: make use of if/loop build helpers in ac

[Timothy Arceri]

---
 src/gallium/drivers/radeonsi/si_shader_internal.h  |   8 -
 .../drivers/radeonsi/si_shader_tgsi_setup.c| 163 ++---
 2 files changed, 11 insertions(+), 160 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_shader_internal.h 
b/src/gallium/drivers/radeonsi/si_shader_internal.h
index dc73517018..92ab11d0af 100644
--- a/src/gallium/drivers/radeonsi/si_shader_internal.h
+++ b/src/gallium/drivers/radeonsi/si_shader_internal.h
@@ -43,13 +43,9 @@ struct ac_shader_binary;
 #define RADEON_LLVM_MAX_INPUTS 32 * 4
 #define RADEON_LLVM_MAX_OUTPUTS 32 * 4
 
-#define RADEON_LLVM_INITIAL_CF_DEPTH 4
-
 #define RADEON_LLVM_MAX_SYSTEM_VALUES 11
 #define RADEON_LLVM_MAX_ADDRS 16
 
-struct si_llvm_flow;
-
 struct si_shader_context {
struct lp_build_tgsi_context bld_base;
struct gallivm_state gallivm;
@@ -98,10 +94,6 @@ struct si_shader_context {
LLVMValueRef *imms;
unsigned imms_num;
 
-   struct si_llvm_flow *flow;
-   unsigned flow_depth;
-   unsigned flow_depth_max;
-
struct lp_build_if_state merged_wrap_if_state;
 
struct tgsi_array_info *temp_arrays;
diff --git a/src/gallium/drivers/radeonsi/si_shader_tgsi_setup.c 
b/src/gallium/drivers/radeonsi/si_shader_tgsi_setup.c
index 4a027d8659..1c62533a17 100644
--- a/src/gallium/drivers/radeonsi/si_shader_tgsi_setup.c
+++ b/src/gallium/drivers/radeonsi/si_shader_tgsi_setup.c
@@ -41,14 +41,6 @@
 #include 
 #include 
 
-/* Data for if/else/endif and bgnloop/endloop control flow structures.
- */
-struct si_llvm_flow {
-   /* Loop exit or next part of if/else/endif. */
-   LLVMBasicBlockRef next_block;
-   LLVMBasicBlockRef loop_entry_block;
-};
-
 enum si_llvm_calling_convention {
RADEON_LLVM_AMDGPU_VS = 87,
RADEON_LLVM_AMDGPU_GS = 88,
@@ -224,45 +216,6 @@ LLVMValueRef si_llvm_bound_index(struct si_shader_context 
*ctx,
return index;
 }
 
-static struct si_llvm_flow *
-get_current_flow(struct si_shader_context *ctx)
-{
-   if (ctx->flow_depth > 0)
-   return >flow[ctx->flow_depth - 1];
-   return NULL;
-}
-
-static struct si_llvm_flow *
-get_innermost_loop(struct si_shader_context *ctx)
-{
-   for (unsigned i = ctx->flow_depth; i > 0; --i) {
-   if (ctx->flow[i - 1].loop_entry_block)
-   return >flow[i - 1];
-   }
-   return NULL;
-}
-
-static struct si_llvm_flow *
-push_flow(struct si_shader_context *ctx)
-{
-   struct si_llvm_flow *flow;
-
-   if (ctx->flow_depth >= ctx->flow_depth_max) {
-   unsigned new_max = MAX2(ctx->flow_depth << 1, 
RADEON_LLVM_INITIAL_CF_DEPTH);
-   ctx->flow = REALLOC(ctx->flow,
-   ctx->flow_depth_max * sizeof(*ctx->flow),
-   new_max * sizeof(*ctx->flow));
-   ctx->flow_depth_max = new_max;
-   }
-
-   flow = >flow[ctx->flow_depth];
-   ctx->flow_depth++;
-
-   flow->next_block = NULL;
-   flow->loop_entry_block = NULL;
-   return flow;
-}
-
 static LLVMValueRef emit_swizzle(struct lp_build_tgsi_context *bld_base,
 LLVMValueRef value,
 unsigned swizzle_x,
@@ -954,42 +907,13 @@ void si_llvm_emit_store(struct lp_build_tgsi_context 
*bld_base,
}
 }
 
-static void set_basicblock_name(LLVMBasicBlockRef bb, const char *base, int pc)
+static int get_line(int pc)
 {
-   char buf[32];
/* Subtract 1 so that the number shown is that of the corresponding
 * opcode in the TGSI dump, e.g. an if block has the same suffix as
 * the instruction number of the corresponding TGSI IF.
 */
-   snprintf(buf, sizeof(buf), "%s%d", base, pc - 1);
-   LLVMSetValueName(LLVMBasicBlockAsValue(bb), buf);
-}
-
-/* Append a basic block at the level of the parent flow.
- */
-static LLVMBasicBlockRef append_basic_block(struct si_shader_context *ctx,
-   const char *name)
-{
-   assert(ctx->flow_depth >= 1);
-
-   if (ctx->flow_depth >= 2) {
-   struct si_llvm_flow *flow = >flow[ctx->flow_depth - 2];
-
-   return LLVMInsertBasicBlockInContext(ctx->ac.context,
-flow->next_block, name);
-   }
-
-   return LLVMAppendBasicBlockInContext(ctx->ac.context, ctx->main_fn, 
name);
-}
-
-/* Emit a branch to the given default target for the current block if
- * applicable -- that is, if the current block does not already contain a
- * branch from a break or continue.
- */
-static void emit_default_branch(LLVMBuilderRef builder, LLVMBasicBlockRef 
target)
-{
-   if (!LLVMGetBasicBlockTerminator(LLVMGetInsertBlock(builder)))
-LLVMBuildBr(builder, target);
+   return pc - 1;
 }
 
 static void bgnloop_emit(const struct lp_build_tgsi_action *action,
@@ -997,12 +921,7 @@ static void bgnloop_emit(const struct 

Re: [Mesa-dev] [PATCH v2] egl/android: Implement the eglSwapinterval for Android.

[Wu, Zhongmin]

Hi Eric:
Sorry, but what is the status about this patch.  I saw you said you was going 
to help to modify the comments and push it in the last mail. Is this patch 
merged in to lasts codes ?
Or do I miss something?

-Original Message-
From: Eric Engestrom [mailto:e...@engestrom.ch] 
Sent: Friday, January 19, 2018 3:46 
To: Emil Velikov 
Cc: Wu, Zhongmin ; ML mesa-dev 
; Tomasz Figa ; Rob Herring 
; Liu, Zhiquan ; Long, Zhifang 
; Kondapally, Kalyan ; 
Palli, Tapani ; Xu, Randy ; 
Bhardwaj, MunishX ; Kps, Harish Krupo 
; Chad Versace 
Subject: Re: [PATCH v2] egl/android: Implement the eglSwapinterval for Android.

On Thursday, 2018-01-18 19:07:06 +, Emil Velikov wrote:
> On 18 January 2018 at 17:43, Eric Engestrom  wrote:
> > On Thursday, 2018-01-18 07:52:42 +, Zhongmin Wu wrote:
> >> Implement the eglSwapinterval for Android platform to enable the 
> >> async mode for some GFX benchmarks such as Daimler C217, CityBench.
> >>
> >> Signed-off-by: Zhongmin Wu 
> >> ---
> >>  src/egl/drivers/dri2/platform_android.c | 21 +
> >>  1 file changed, 21 insertions(+)
> >>
> >> diff --git a/src/egl/drivers/dri2/platform_android.c 
> >> b/src/egl/drivers/dri2/platform_android.c
> >> index f6a24cd..3a64689 100644
> >> --- a/src/egl/drivers/dri2/platform_android.c
> >> +++ b/src/egl/drivers/dri2/platform_android.c
> >> @@ -476,6 +476,20 @@ droid_destroy_surface(_EGLDriver *drv, _EGLDisplay 
> >> *disp, _EGLSurface *surf)
> >> return EGL_TRUE;
> >>  }
> >>
> >> +static EGLBoolean
> >> +droid_swap_interval(_EGLDriver *drv, _EGLDisplay *dpy,
> >> +   _EGLSurface *surf, EGLint interval) {
> >> +   struct dri2_egl_surface *dri2_surf = dri2_egl_surface(surf);
> >> +   struct ANativeWindow *window = dri2_surf->window;
> >> +
> >> +   if (window->setSwapInterval(window, interval))
> >> +  return EGL_FALSE;
> >> +
> >> +   surf->SwapInterval = interval;
> >> +   return EGL_TRUE;
> >> +}
> >> +
> >>  static int
> >>  update_buffers(struct dri2_egl_surface *dri2_surf)  { @@ -1300,6 
> >> +1314,7 @@ static const struct dri2_egl_display_vtbl droid_display_vtbl = {
> >> .swap_buffers = droid_swap_buffers,
> >> .swap_buffers_with_damage = dri2_fallback_swap_buffers_with_damage, /* 
> >> Android implements the function */
> >> .swap_buffers_region = dri2_fallback_swap_buffers_region,
> >> +   .swap_interval = droid_swap_interval,
> >>  #if ANDROID_API_LEVEL >= 23
> >> .set_damage_region = droid_set_damage_region,  #else @@ -1443,6 
> >> +1458,12 @@ dri2_initialize_android(_EGLDriver *drv, _EGLDisplay 
> >> *dpy)
> >>
> >> dri2_setup_screen(dpy);
> >>
> >> +   /* we set the maximum swap interval as 1 for Android platform, Since
> >> +   it is the maximum value supported by Android according to the
> >> +   value of ANativeWindow::maxSwapInterval.
> >> +   */
> >> +   dri2_setup_swap_interval(dpy, 1);
> >
> > My C<->C++ interaction skills are more than rusty, but is it 
> > possible to use `ANativeWindow.maxSwapInterval` or something like this?
> >
> > Given that the dEQP tests all pass, whether with the current comment 
> > or the class field directly used in the code, this patch is:
> > Reviewed-by: Eric Engestrom 
> >
> > I'll push it for you in a couple days if no one objects :)
> >
> My current checkout shows the struct is nicely separated for inclusion 
> in both C and C++ sources.
> The C++ vfuncs are wrapped in a ifdef _cplusplus block, so the ABI 
> should be identical across both.
> 
> I'm suspecting that maxSwapInterval > 1 will require additional 
> changes, so I'd keep it as-is

That's actually a good point; this should indeed stay hard coded, with this 
comment.

> (nit the comment style and adding dEQP stats in the commit message).

I was going to do this before pushing, but you're right to point it out :)

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

Re: [Mesa-dev] [PATCH RFC] radeonsi: Disable IEEE_MODE.

[Marek Olšák]

You can change the behavior for clover, but I would like to keep the
current behavior for OpenGL.

Marek

On Sat, Mar 3, 2018 at 6:35 PM, Jan Vesely  wrote:
> Neither GL nor CL nor SPIRV needs the IEEE handling of sNaNs.
>
> Signed-off-by: Jan Vesely 
> ---
> This is the 3rd way to handle broken fmin/fmax in clover CL.
> It can be worked around in libclc (to not use
> llvm.fminnum/llvm.fmaxnum)[0]
> LLVM can be patched to not use IEEE_MODE[1]
> Or it can be fixed in the config reg in mesa.
>
> The third option is arguably the worst (changes semantics of compiled
> code), but since the first two efforts have been stalled for months.
> Here's the third one.
>
> Jan
>
> [0] http://lists.llvm.org/pipermail/libclc-dev/2017-November/thread.html#2692
> [1] https://reviews.llvm.org/D40514
>
>
>  src/gallium/drivers/radeonsi/si_compute.c | 8 
>  src/gallium/drivers/radeonsi/si_shader.c  | 6 +-
>  2 files changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/radeonsi/si_compute.c 
> b/src/gallium/drivers/radeonsi/si_compute.c
> index 41927988cf..d0fcba485b 100644
> --- a/src/gallium/drivers/radeonsi/si_compute.c
> +++ b/src/gallium/drivers/radeonsi/si_compute.c
> @@ -70,6 +70,10 @@ static void code_object_to_config(const amd_kernel_code_t 
> *code_object,
>   struct si_shader_config *out_config) {
>
> uint32_t rsrc1 = code_object->compute_pgm_resource_registers;
> +   /* Disable IEEE mode. IEEE_MODE determines sNaN handling by fmin/fmax
> +* instructions. Nothing wants the IEEE rules here.
> +* Ideally LLVM would not emit this configuration. */
> +   rsrc1 &= C_00B848_IEEE_MODE;
> uint32_t rsrc2 = code_object->compute_pgm_resource_registers >> 32;
> out_config->num_sgprs = code_object->wavefront_sgpr_count;
> out_config->num_vgprs = code_object->workitem_vgpr_count;
> @@ -137,6 +141,10 @@ static void si_create_compute_state_async(void *job, int 
> thread_index)
> S_00B848_SGPRS((shader->config.num_sgprs - 1) / 8) |
> S_00B848_DX10_CLAMP(1) |
> S_00B848_FLOAT_MODE(shader->config.float_mode);
> +   /* Disable IEEE mode. IEEE_MODE determines sNaN handling by
> +* fmin/fmax instructions. Nothing wants the IEEE rules.
> +* Ideally LLVM would not emit this configuration. */
> +   shader->config.rsrc1 &= C_00B848_IEEE_MODE;
>
> shader->config.rsrc2 =
> S_00B84C_USER_SGPR(user_sgprs) |
> diff --git a/src/gallium/drivers/radeonsi/si_shader.c 
> b/src/gallium/drivers/radeonsi/si_shader.c
> index 2a50b266f6..01bad71a4e 100644
> --- a/src/gallium/drivers/radeonsi/si_shader.c
> +++ b/src/gallium/drivers/radeonsi/si_shader.c
> @@ -5178,7 +5178,11 @@ void si_shader_binary_read_config(struct 
> ac_shader_binary *binary,
> conf->num_sgprs = MAX2(conf->num_sgprs, 
> (G_00B028_SGPRS(value) + 1) * 8);
> conf->num_vgprs = MAX2(conf->num_vgprs, 
> (G_00B028_VGPRS(value) + 1) * 4);
> conf->float_mode =  G_00B028_FLOAT_MODE(value);
> -   conf->rsrc1 = value;
> +   /* Disable IEEE mode. IEEE_MODE determines sNaN
> +* handling by fmin/fmax instructions.
> +* Nothing wants the IEEE rules here.
> +* Ideally LLVM would not emit this configuration. */
> +   conf->rsrc1 = value & C_00B848_IEEE_MODE;
> break;
> case R_00B02C_SPI_SHADER_PGM_RSRC2_PS:
> conf->lds_size = MAX2(conf->lds_size, 
> G_00B02C_EXTRA_LDS_SIZE(value));
> --
> 2.14.3
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] tizonia egl build fail

[Dylan Baker]

Quoting Andy Furniss (2018-03-06 15:12:37)
> make[5]: Entering directory 
> '/mnt/sdc1/Gits/mesa/src/gallium/state_trackers/omx/tizonia'
>CC   h264dprc.lo
> In file included from h264dprc.c:45:0:
> ../../../../../src/egl/drivers/dri2/egl_dri2.h:47:10: fatal error: 
> wayland/wayland-egl/wayland-egl-backend.h: No such file or directory
>   #include "wayland/wayland-egl/wayland-egl-backend.h"
>^~~
> compilation terminated.
> 
> 
> below will fix the build - no idea if it breaks anything else/is sane.
> 
> diff --git a/src/egl/drivers/dri2/egl_dri2.h 
> b/src/egl/drivers/dri2/egl_dri2.h
> index d36d02c3c4..3459216917 100644
> --- a/src/egl/drivers/dri2/egl_dri2.h
> +++ b/src/egl/drivers/dri2/egl_dri2.h
> @@ -44,7 +44,7 @@
> 
>   #ifdef HAVE_WAYLAND_PLATFORM
>   #include 
> -#include "wayland/wayland-egl/wayland-egl-backend.h"
> +#include "egl/wayland/wayland-egl/wayland-egl-backend.h"
>   /* forward declarations of protocol elements */
>   struct zwp_linux_dmabuf_v1;
>   #endif
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev

I sent a patch to fix this for meson as well, but I just added -I/src/egl. It
would be better if we picked one way and did that.

Dylan


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

[Mesa-dev] [PATCH 1/2] mesa: simplify MESA_GL_VERSION_OVERRIDE behavior of API override

[Marek Olšák]

From: Marek Olšák 

---
 docs/envvars.html   |  3 ++-
 src/mesa/main/version.c | 16 +---
 2 files changed, 7 insertions(+), 12 deletions(-)

diff --git a/docs/envvars.html b/docs/envvars.html
index ea42a50..3ef3ab1 100644
--- a/docs/envvars.html
+++ b/docs/envvars.html
@@ -92,22 +92,23 @@ glGetString(GL_VERSION) and possibly the GL API type.
  FC is an optional suffix that indicates a forward compatible context.
 This is only valid for versions = 3.0.
  GL versions  3.0 are set to a compatibility (non-Core) profile
  GL versions = 3.0, see below
  GL versions  3.0 are set to a Core profile
  Examples: 2.1, 3.0, 3.0FC, 3.1, 3.1FC
 
  2.1 - select a compatibility (non-Core) profile with GL version 2.1
  3.0 - select a compatibility (non-Core) profile with GL version 3.0
  3.0FC - select a Core+Forward Compatible profile with GL version 3.0
- 3.1 - select a Core profile with GL version 3.1
+ 3.1 - keep the same profile and set GL version 3.1
  3.1FC - select a Core+Forward Compatible profile with GL version 3.1
+ 3.1COMPAT - select a compatibility (non-Core) profile with GL version 3.1
 
  Mesa may not really implement all the features of the given version.
 (for developers only)
 
 MESA_GLES_VERSION_OVERRIDE - changes the value returned by
 glGetString(GL_VERSION) for OpenGL ES.
 
  The format should be MAJOR.MINOR
  Examples: 2.0, 3.0, 3.1
  Mesa may not really implement all the features of the given version.
diff --git a/src/mesa/main/version.c b/src/mesa/main/version.c
index a280690..9ad49db 100644
--- a/src/mesa/main/version.c
+++ b/src/mesa/main/version.c
@@ -133,48 +133,42 @@ create_version_string(struct gl_context *ctx, const char 
*prefix)
}
 }
 
 /**
  * Override the context's version and/or API type if the
  * environment variable MESA_GL_VERSION_OVERRIDE is set.
  *
  * Example uses of MESA_GL_VERSION_OVERRIDE:
  *
  * 2.1: select a compatibility (non-Core) profile with GL version 2.1
- * 3.0: select a compatibility (non-Core) profile with GL version 3.0
- * 3.0FC: select a Core+Forward Compatible profile with GL version 3.0
- * 3.1: select a Core profile with GL version 3.1
- * 3.1FC: select a Core+Forward Compatible profile with GL version 3.1
+ * X.Y: override GL version to X.Y without changing the profile
+ * X.YFC: select a Core+Forward Compatible profile with GL version X.Y
+ * X.YCOMPAT: select a Compatibility profile with GL version X.Y
  */
 bool
 _mesa_override_gl_version_contextless(struct gl_constants *consts,
   gl_api *apiOut, GLuint *versionOut)
 {
int version;
bool fwd_context, compat_context;
 
get_gl_override(*apiOut, , _context, _context);
 
if (version > 0) {
   *versionOut = version;
 
-  /* If the API is a desktop API, adjust the context flags.  We may also
-   * need to modify the API depending on the version.  For example, Mesa
-   * does not support a GL 3.3 compatibility profile.
-   */
+  /* Modify the API and context flags as needed. */
   if (*apiOut == API_OPENGL_CORE || *apiOut == API_OPENGL_COMPAT) {
  if (version >= 30 && fwd_context) {
 *apiOut = API_OPENGL_CORE;
 consts->ContextFlags |= GL_CONTEXT_FLAG_FORWARD_COMPATIBLE_BIT;
- } else if (version >= 31 && !compat_context) {
-*apiOut = API_OPENGL_CORE;
- } else {
+ } else if (compat_context) {
 *apiOut = API_OPENGL_COMPAT;
  }
   }
 
   return true;
}
return false;
 }
 
 void
-- 
2.7.4

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

[Mesa-dev] [PATCH 2/2] mesa: adjust incorrect comment in texture_buffer_range

[Marek Olšák]

From: Marek Olšák 

---
 src/mesa/main/teximage.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index 928e50d..c3f769d 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -5451,22 +5451,22 @@ texture_buffer_range(struct gl_context *ctx,
  struct gl_texture_object *texObj,
  GLenum internalFormat,
  struct gl_buffer_object *bufObj,
  GLintptr offset, GLsizeiptr size,
  const char *caller)
 {
GLintptr oldOffset = texObj->BufferOffset;
GLsizeiptr oldSize = texObj->BufferSize;
mesa_format format;
 
-   /* NOTE: ARB_texture_buffer_object has interactions with
-* the compatibility profile that are not implemented.
+   /* NOTE: ARB_texture_buffer_object might not be supported in
+* the compatibility profile.
 */
if (!_mesa_has_ARB_texture_buffer_object(ctx) &&
!_mesa_has_OES_texture_buffer(ctx)) {
   _mesa_error(ctx, GL_INVALID_OPERATION,
   "%s(ARB_texture_buffer_object is not"
   " implemented for the compatibility profile)", caller);
   return;
}
 
if (texObj->HandleAllocated) {
-- 
2.7.4

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

Re: [Mesa-dev] [RFC] radeonsi: guard against indexbuf not being set

[Marek Olšák]

If index_size > 0, indexbuf should always be non-NULL. This is a bug
somewhere else.

Marek

On Mon, Mar 5, 2018 at 4:42 PM, Roman Gilg  wrote:
> This is a RFC because I don't really know what I'm doing here. But we
> have this problem with AMD and KWin already for quite a long time and
> I hope it can be fixed now.
>
> I followed the debug output and tried this guard. On my system this
> fixed the issue with Alt+Tab crashing KWin. Still this might be not
> the right solution to the problem.
>
> According to git-blame 330d0607 was the last time this condition was touched.
>
> On Mon, Mar 5, 2018 at 10:31 PM, Roman Gilg  wrote:
>> Fixes crashes of clients when index_size != 0, but there was no indexbuf
>> set in si_draw_vbo.
>>
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103234
>>
>> Signed-off-by: Roman Gilg 
>> ---
>>  src/gallium/drivers/radeonsi/si_state_draw.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/src/gallium/drivers/radeonsi/si_state_draw.c 
>> b/src/gallium/drivers/radeonsi/si_state_draw.c
>> index ad470fd..e53da38 100644
>> --- a/src/gallium/drivers/radeonsi/si_state_draw.c
>> +++ b/src/gallium/drivers/radeonsi/si_state_draw.c
>> @@ -680,7 +680,7 @@ static void si_emit_draw_packets(struct si_context *sctx,
>> }
>>
>> /* draw packet */
>> -   if (index_size) {
>> +   if (index_size && indexbuf) {
>> if (index_size != sctx->last_index_size) {
>> unsigned index_type;
>>
>> --
>> 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] [PATCH 3/3] radeonsi/nir: call ac_lower_indirect_derefs()

[Marek Olšák]

On Sun, Mar 4, 2018 at 8:09 PM, Timothy Arceri  wrote:
> Fixes piglit tests:
> tests/spec/glsl-1.50/execution/variable-indexing/gs-input-array-vec3-index-rd.shader_test
> tests/spec/glsl-1.50/execution/geometry/max-input-components.shader_test
> ---
>  src/gallium/drivers/radeonsi/si_compute.c   | 2 +-
>  src/gallium/drivers/radeonsi/si_shader.h| 2 +-
>  src/gallium/drivers/radeonsi/si_shader_nir.c| 4 +++-
>  src/gallium/drivers/radeonsi/si_state_shaders.c | 2 +-
>  4 files changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/src/gallium/drivers/radeonsi/si_compute.c 
> b/src/gallium/drivers/radeonsi/si_compute.c
> index e9b6127115..d135a09add 100644
> --- a/src/gallium/drivers/radeonsi/si_compute.c
> +++ b/src/gallium/drivers/radeonsi/si_compute.c
> @@ -107,7 +107,7 @@ static void si_create_compute_state_async(void *job, int 
> thread_index)
> sel.nir = program->ir.nir;
>
> si_nir_scan_shader(sel.nir, );
> -   si_lower_nir();
> +   si_lower_nir(, program->compiler_ctx_state.chip_class);

program->screen->chip_class, and patch 2 can be dropped.

> }
>
>
> diff --git a/src/gallium/drivers/radeonsi/si_shader.h 
> b/src/gallium/drivers/radeonsi/si_shader.h
> index 28f6e6bc4e..23f9d20e19 100644
> --- a/src/gallium/drivers/radeonsi/si_shader.h
> +++ b/src/gallium/drivers/radeonsi/si_shader.h
> @@ -674,7 +674,7 @@ void si_nir_scan_shader(const struct nir_shader *nir,
>  void si_nir_scan_tess_ctrl(const struct nir_shader *nir,
>const struct tgsi_shader_info *info,
>struct tgsi_tessctrl_info *out);
> -void si_lower_nir(struct si_shader_selector *sel);
> +void si_lower_nir(struct si_shader_selector *sel, enum chip_class 
> chip_class);
>
>  /* Inline helpers. */
>
> diff --git a/src/gallium/drivers/radeonsi/si_shader_nir.c 
> b/src/gallium/drivers/radeonsi/si_shader_nir.c
> index fc709d8546..3d538be4cf 100644
> --- a/src/gallium/drivers/radeonsi/si_shader_nir.c
> +++ b/src/gallium/drivers/radeonsi/si_shader_nir.c
> @@ -665,7 +665,7 @@ void si_nir_scan_shader(const struct nir_shader *nir,
>   * selector is created.
>   */
>  void
> -si_lower_nir(struct si_shader_selector* sel)
> +si_lower_nir(struct si_shader_selector* sel, enum chip_class chip_class)
>  {
> /* Adjust the driver location of inputs and outputs. The state tracker
>  * interprets them as slots, while the ac/nir backend interprets them
> @@ -715,6 +715,8 @@ si_lower_nir(struct si_shader_selector* sel)
> };
> NIR_PASS_V(sel->nir, nir_lower_subgroups, _options);
>
> +   ac_lower_indirect_derefs(sel->nir, chip_class);

With sel->screen->chip_class, si_lower_nir doesn't need the chip_class
parameter.

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

[Mesa-dev] [PATCH] android: anv: add libmesa_intel_dev static dependency

[Mauro Rossi]

Fixes the following building errors:

external/mesa/src/intel/vulkan/anv_device.c:300: error: undefined reference to 
'gen_get_pci_device_id_override'
external/mesa/src/intel/vulkan/anv_device.c:312: error: undefined reference to 
'gen_get_device_name'
external/mesa/src/intel/vulkan/anv_device.c:313: error: undefined reference to 
'gen_get_device_info'
clang.real: error: linker command failed with exit code 1 (use -v to see 
invocation)

Fixes: 272bef0601a "intel: Split gen_device_info out into libintel_dev"
---
 src/intel/Android.vulkan.mk | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/intel/Android.vulkan.mk b/src/intel/Android.vulkan.mk
index 419d560b0c..0ec0d78a2f 100644
--- a/src/intel/Android.vulkan.mk
+++ b/src/intel/Android.vulkan.mk
@@ -300,6 +300,7 @@ LOCAL_WHOLE_STATIC_LIBRARIES := \
libmesa_blorp \
libmesa_compiler \
libmesa_intel_common \
+   libmesa_intel_dev \
libmesa_vulkan_common \
libmesa_anv_gen7 \
libmesa_anv_gen75 \
-- 
2.15.1

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

Re: [Mesa-dev] [PATCH 1/2] gallium: Add a util_blitter path for using a custom VS and FS.

[Marek Olšák]

Reviewed-by: Marek Olšák 

Marek

On Fri, Mar 2, 2018 at 4:51 PM, Eric Anholt  wrote:
> Like the r600 paths to use other custom states, we pass in a couple of
> parameters to customize the innards of the blitter.  It's up to the caller
> to wrap other state necessary for its shaders (for example, constant
> buffers for the uniforms the shader uses).
> ---
>  src/gallium/auxiliary/util/u_blitter.c | 64 
> ++
>  src/gallium/auxiliary/util/u_blitter.h |  5 +++
>  2 files changed, 69 insertions(+)
>
> diff --git a/src/gallium/auxiliary/util/u_blitter.c 
> b/src/gallium/auxiliary/util/u_blitter.c
> index 98c3ac5df3af..4748627fc523 100644
> --- a/src/gallium/auxiliary/util/u_blitter.c
> +++ b/src/gallium/auxiliary/util/u_blitter.c
> @@ -129,6 +129,8 @@ struct blitter_context_priv
> unsigned dst_width;
> unsigned dst_height;
>
> +   void *custom_vs;
> +
> bool has_geometry_shader;
> bool has_tessellation;
> bool has_layered;
> @@ -2564,3 +2566,65 @@ void util_blitter_custom_color(struct blitter_context 
> *blitter,
> util_blitter_restore_render_cond(blitter);
> util_blitter_unset_running_flag(blitter);
>  }
> +
> +static void *get_custom_vs(struct blitter_context *blitter)
> +{
> +   struct blitter_context_priv *ctx = (struct blitter_context_priv*)blitter;
> +
> +   return ctx->custom_vs;
> +}
> +
> +/**
> + * Performs a custom blit to the destination surface, using the VS and FS
> + * provided.
> + *
> + * Used by vc4 for the 8-bit linear-to-tiled blit.
> + */
> +void util_blitter_custom_shader(struct blitter_context *blitter,
> +struct pipe_surface *dstsurf,
> +void *custom_vs, void *custom_fs)
> +{
> +   struct blitter_context_priv *ctx = (struct blitter_context_priv*)blitter;
> +   struct pipe_context *pipe = ctx->base.pipe;
> +   struct pipe_framebuffer_state fb_state;
> +
> +   ctx->custom_vs = custom_vs;
> +
> +   assert(dstsurf->texture);
> +   if (!dstsurf->texture)
> +  return;
> +
> +   /* check the saved state */
> +   util_blitter_set_running_flag(blitter);
> +   blitter_check_saved_vertex_states(ctx);
> +   blitter_check_saved_fragment_states(ctx);
> +   blitter_check_saved_fb_state(ctx);
> +   blitter_disable_render_cond(ctx);
> +
> +   /* bind states */
> +   pipe->bind_blend_state(pipe, ctx->blend[PIPE_MASK_RGBA][0]);
> +   pipe->bind_depth_stencil_alpha_state(pipe, ctx->dsa_keep_depth_stencil);
> +   pipe->bind_fs_state(pipe, custom_fs);
> +   pipe->set_sample_mask(pipe, (1ull << MAX2(1, 
> dstsurf->texture->nr_samples)) - 1);
> +
> +   /* set a framebuffer state */
> +   fb_state.width = dstsurf->width;
> +   fb_state.height = dstsurf->height;
> +   fb_state.nr_cbufs = 1;
> +   fb_state.cbufs[0] = dstsurf;
> +   fb_state.zsbuf = 0;
> +   pipe->set_framebuffer_state(pipe, _state);
> +   pipe->set_sample_mask(pipe, ~0);
> +
> +   blitter_set_common_draw_rect_state(ctx, false);
> +   blitter_set_dst_dimensions(ctx, dstsurf->width, dstsurf->height);
> +   blitter->draw_rectangle(blitter, ctx->velem_state, get_custom_vs,
> +   0, 0, dstsurf->width, dstsurf->height,
> +   0, 1, UTIL_BLITTER_ATTRIB_NONE, NULL);
> +
> +   util_blitter_restore_vertex_states(blitter);
> +   util_blitter_restore_fragment_states(blitter);
> +   util_blitter_restore_fb_state(blitter);
> +   util_blitter_restore_render_cond(blitter);
> +   util_blitter_unset_running_flag(blitter);
> +}
> diff --git a/src/gallium/auxiliary/util/u_blitter.h 
> b/src/gallium/auxiliary/util/u_blitter.h
> index dba773906aef..9e945983baac 100644
> --- a/src/gallium/auxiliary/util/u_blitter.h
> +++ b/src/gallium/auxiliary/util/u_blitter.h
> @@ -384,6 +384,11 @@ void util_blitter_custom_resolve_color(struct 
> blitter_context *blitter,
> void *custom_blend,
> enum pipe_format format);
>
> +/* Used by vc4 for 8/16-bit linear-to-tiled blits */
> +void util_blitter_custom_shader(struct blitter_context *blitter,
> +struct pipe_surface *dstsurf,
> +void *custom_vs, void *custom_fs);
> +
>  /* The functions below should be used to save currently bound constant state
>   * objects inside a driver. The objects are automatically restored at the end
>   * of the util_blitter_{clear, copy_region, fill_region} functions and then
> --
> 2.16.2
>
> ___
> 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] tizonia egl build fail

[Andy Furniss]

make[5]: Entering directory 
'/mnt/sdc1/Gits/mesa/src/gallium/state_trackers/omx/tizonia'

  CC   h264dprc.lo
In file included from h264dprc.c:45:0:
../../../../../src/egl/drivers/dri2/egl_dri2.h:47:10: fatal error: 
wayland/wayland-egl/wayland-egl-backend.h: No such file or directory

 #include "wayland/wayland-egl/wayland-egl-backend.h"
  ^~~
compilation terminated.


below will fix the build - no idea if it breaks anything else/is sane.

diff --git a/src/egl/drivers/dri2/egl_dri2.h 
b/src/egl/drivers/dri2/egl_dri2.h

index d36d02c3c4..3459216917 100644
--- a/src/egl/drivers/dri2/egl_dri2.h
+++ b/src/egl/drivers/dri2/egl_dri2.h
@@ -44,7 +44,7 @@

 #ifdef HAVE_WAYLAND_PLATFORM
 #include 
-#include "wayland/wayland-egl/wayland-egl-backend.h"
+#include "egl/wayland/wayland-egl/wayland-egl-backend.h"
 /* forward declarations of protocol elements */
 struct zwp_linux_dmabuf_v1;
 #endif
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] ac/nir: fix potential issues when scanning flat_shaded_mask

[Marek Olšák]

On Tue, Mar 6, 2018 at 10:58 AM, Samuel Pitoiset
 wrote:
> As far as I understand, this might overflow and shifted by one
> if for example, gl_PrimitiveID is used with flat generic varyings.
>
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/amd/common/ac_nir_to_llvm.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
> index ea51c3a54a..d4fdb8e8f4 100644
> --- a/src/amd/common/ac_nir_to_llvm.c
> +++ b/src/amd/common/ac_nir_to_llvm.c
> @@ -5545,6 +5545,7 @@ handle_fs_inputs(struct radv_shader_context *ctx,
> nir_foreach_variable(variable, >inputs)
> handle_fs_input_decl(ctx, variable);
>
> +   uint64_t flat_shaded_mask = 0;
> unsigned index = 0;
>
> if (ctx->shader_info->info.ps.uses_input_attachments ||
> @@ -5564,8 +5565,8 @@ handle_fs_inputs(struct radv_shader_context *ctx,
> interp_fs_input(ctx, index, interp_param, 
> ctx->abi.prim_mask,
> inputs);
>
> -   if (!interp_param)
> -   ctx->shader_info->fs.flat_shaded_mask |= 1u 
> << index;
> +   if (i >= VARYING_SLOT_VAR0 && !interp_param)
> +   flat_shaded_mask |= 1u << i;

1ull

Marek

> ++index;
> } else if (i == VARYING_SLOT_POS) {
> for(int i = 0; i < 3; ++i)
> @@ -5575,7 +5576,9 @@ handle_fs_inputs(struct radv_shader_context *ctx,
>   ctx->abi.frag_pos[3]);
> }
> }
> +
> ctx->shader_info->fs.num_interp = index;
> +   ctx->shader_info->fs.flat_shaded_mask = flat_shaded_mask >> 
> VARYING_SLOT_VAR0;
> ctx->shader_info->fs.input_mask = ctx->input_mask >> 
> VARYING_SLOT_VAR0;
>
> if (ctx->shader_info->info.needs_multiview_view_index)
> --
> 2.16.2
>
> ___
> 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 2/3] meson: use relative paths in megadriver symlinks

[Greg V]

e.g. libvdpau_radeonsi.so(.1(.0)) were pointing to the absolute
build-time path of libvdpau_radeonsi.so.1.0.0, which caused trouble
when packaging the libraries.
---
 bin/install_megadrivers.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bin/install_megadrivers.py b/bin/install_megadrivers.py
index 86bfa35918..ce947b4332 100755
--- a/bin/install_megadrivers.py
+++ b/bin/install_megadrivers.py
@@ -58,7 +58,7 @@ def main():
 while ext != '.so':
 if os.path.exists(name):
 os.unlink(name)
-os.symlink(driver, name)
+os.symlink(os.path.relpath(driver), name)
 name, ext = os.path.splitext(name)
 finally:
 os.chdir(ret)
-- 
2.16.2

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

[Mesa-dev] [PATCH 3/3] meson: make GLX_USE_TLS optional

[Greg V]

FreeBSD builds Mesa with --disable-glx-tls in autotools because:
https://github.com/dumbbell/test-tls-initial-exec

Add the equivalent option to Meson.
---
 meson.build   | 5 -
 meson_options.txt | 6 ++
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/meson.build b/meson.build
index e71f4ddd73..1c4293d464 100644
--- a/meson.build
+++ b/meson.build
@@ -329,7 +329,10 @@ if with_egl and not (with_platform_drm or 
with_platform_surfaceless)
   endif
 endif
 
-pre_args += '-DGLX_USE_TLS'
+if get_option('glx-tls')
+  pre_args += '-DGLX_USE_TLS'
+endif
+
 if with_glx != 'disabled'
   if not (with_platform_x11 and with_any_opengl)
 if with_glx == 'auto'
diff --git a/meson_options.txt b/meson_options.txt
index 7fafe2deaa..eaf23f6988 100644
--- a/meson_options.txt
+++ b/meson_options.txt
@@ -280,6 +280,12 @@ option(
   value : 'avx,avx2',
   description : 'Comma delemited swr architectures. choices : avx,avx2,knl,skx'
 )
+option(
+  'glx-tls',
+  type : 'boolean',
+  value : true,
+  description : 'Enable thread-local storage in GLX and EGL'
+)
 option(
   'tools',
   type : 'string',
-- 
2.16.2

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

[Mesa-dev] [PATCH 1/3] meson: Use system_has_kms_drm in default driver selection

[Greg V]

---
 meson.build | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/meson.build b/meson.build
index d68460231c..e71f4ddd73 100644
--- a/meson.build
+++ b/meson.build
@@ -87,6 +87,8 @@ if (with_gles1 or with_gles2) and not with_opengl
   error('building OpenGL ES without OpenGL is not supported.')
 endif
 
+system_has_kms_drm = ['openbsd', 'netbsd', 'freebsd', 'dragonfly', 
'linux'].contains(host_machine.system())
+
 with_dri = false
 with_dri_i915 = false
 with_dri_i965 = false
@@ -96,7 +98,7 @@ with_dri_nouveau = false
 with_dri_swrast = false
 _drivers = get_option('dri-drivers')
 if _drivers == 'auto'
-  if host_machine.system() == 'linux'
+  if system_has_kms_drm
 # TODO: PPC, Sparc
 if ['x86', 'x86_64'].contains(host_machine.cpu_family())
   _drivers = 'i915,i965,r100,r200,nouveau'
@@ -139,7 +141,7 @@ with_gallium_virgl = false
 with_gallium_swr = false
 _drivers = get_option('gallium-drivers')
 if _drivers == 'auto'
-  if host_machine.system() == 'linux'
+  if system_has_kms_drm
 # TODO: PPC, Sparc
 if ['x86', 'x86_64'].contains(host_machine.cpu_family())
   _drivers = 'r300,r600,radeonsi,nouveau,virgl,svga,swrast'
@@ -179,7 +181,7 @@ with_amd_vk = false
 with_any_vk = false
 _vulkan_drivers = get_option('vulkan-drivers')
 if _vulkan_drivers == 'auto'
-  if host_machine.system() == 'linux'
+  if system_has_kms_drm
 if host_machine.cpu_family().startswith('x86')
   _vulkan_drivers = 'amd,intel'
 else
@@ -217,8 +219,6 @@ if with_dri_i915 or with_gallium_i915
   dep_libdrm_intel = dependency('libdrm_intel', version : '>= 2.4.75')
 endif
 
-system_has_kms_drm = ['openbsd', 'netbsd', 'freebsd', 'dragonfly', 
'linux'].contains(host_machine.system())
-
 if host_machine.system() == 'darwin'
   with_dri_platform = 'apple'
 elif ['windows', 'cygwin'].contains(host_machine.system())
-- 
2.16.2

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

[Mesa-dev] [PATCH 0/3] Meson patches for FreeBSD

[Greg V]

Hi! Here's a few more patches that let me successfully build, package 
and install fully working Meson-built Mesa-git on my FreeBSD box.

Greg V (3):
  meson: Use system_has_kms_drm in default driver selection
  meson: use relative paths in megadriver symlinks
  meson: make GLX_USE_TLS optional

 bin/install_megadrivers.py |  2 +-
 meson.build| 15 +--
 meson_options.txt  |  6 ++
 3 files changed, 16 insertions(+), 7 deletions(-)

-- 
2.16.2

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

Re: [Mesa-dev] [PATCH] dri_util: when overriding, always reset the core version

[Marek Olšák]

On Mon, Mar 5, 2018 at 7:33 AM, Tapani Pälli  wrote:
> Hi;
>
> On 03/02/2018 03:25 PM, Andres Gomez wrote:
>>
>> This way we won't fail when validating just because we may have a non
>> overriden core version that is lower than the requested one, even when
>> the compat version is high enough.
>
>
> Do I understand correctly that this happens because when version asked is >
> 3.2 then we always do core context, even when overriding to compat profile?

No. 3.2COMPAT will set both core and compat version limits to 3.2.

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

Re: [Mesa-dev] [PATCH 3/3] mesa: add documentation for COMPAT suffix for MESA_GL_VERSION_OVERRIDE

[Marek Olšák]

Patches 2 & 3:

Reviewed-by: Marek Olšák 

Marek

On Fri, Mar 2, 2018 at 8:02 AM, Andres Gomez  wrote:
> Fixes: 2599b92eb97 ("mesa: allow forcing >=3.1 compatibility contexts
> with MESA_GL_VERSION_OVERRIDE")
>
> Cc: Marek Olšák 
> Cc: Jordan Justen 
> Cc: Ian Romanick 
> Cc: Eric Engestrom 
> Cc: Emil Velikov 
> Signed-off-by: Andres Gomez 
> ---
>  docs/envvars.html   | 6 --
>  src/mesa/main/version.c | 1 +
>  2 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/docs/envvars.html b/docs/envvars.html
> index 4ea5670b78d..7306d9136ef 100644
> --- a/docs/envvars.html
> +++ b/docs/envvars.html
> @@ -88,12 +88,13 @@ This is a work-around for that.
>  MESA_GL_VERSION_OVERRIDE - changes the value returned by
>  glGetString(GL_VERSION) and possibly the GL API type.
>  
> - The format should be MAJOR.MINOR[FC]
> + The format should be MAJOR.MINOR[FC|COMPAT]
>   FC is an optional suffix that indicates a forward compatible context.
>  This is only valid for versions = 3.0.
> + COMPAT is an optional suffix that indicates a compatibility context.
>   GL versions = 3.1 are set to a compatibility (non-Core) profile
>   GL versions  3.1 are set to a Core profile
> - Examples: 2.1, 3.0, 3.1, 3.1FC, 3.2, 3.2FC
> + Examples: 2.1, 3.0, 3.1, 3.1FC, 3.2, 3.2FC, 3.2COMPAT
>  
>   2.1 - select a compatibility (non-Core) profile with GL version 2.1
>   3.0 - select a compatibility (non-Core) profile with GL version 3.0
> @@ -101,6 +102,7 @@ This is only valid for versions = 3.0.
>   3.1FC - select a Core+Forward Compatible profile with GL version 3.1
>   3.2 - select a Core profile with GL version 3.2
>   3.2FC - select a Core+Forward Compatible profile with GL version 3.2
> + 3.2COMPAT - select a compatibility (non-Core) profile with GL version 
> 3.2
>  
>   Mesa may not really implement all the features of the given version.
>  (for developers only)
> diff --git a/src/mesa/main/version.c b/src/mesa/main/version.c
> index 6a0894f5155..6aeb9a4348a 100644
> --- a/src/mesa/main/version.c
> +++ b/src/mesa/main/version.c
> @@ -145,6 +145,7 @@ create_version_string(struct gl_context *ctx, const char 
> *prefix)
>   * 3.1FC: select a Core+Forward Compatible profile with GL version 3.1
>   * 3.2: select a Core profile with GL version 3.2
>   * 3.2FC: select a Core+Forward Compatible profile with GL version 3.2
> + * 3.2COMPAT: select a compatibility (non-Core) profile with GL version 3.2
>   *
>   * Example uses of MESA_GL_VERSION_OVERRIDE:
>   *
> --
> 2.15.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] mesa: override to GL core API only when >= 3.2

[Marek Olšák]

HI Andres,

Thanks for pointing this out. Instead of yours, I'll send my own patch
that removes the version check completely.

Marek

On Fri, Mar 2, 2018 at 8:02 AM, Andres Gomez  wrote:
> a0c8b49284e enabled the OpenGL 3.1 compat profile. Hence, when setting
> MESA_GL_VERSION_OVERRIDE=3.1 we want to keep the compat profile, as it
> already happens with <= 3.0.
>
> Additionally, update and add some extra comments on the overriding
> function.
>
> Fixes: a0c8b49284e ("mesa: enable OpenGL 3.1 with ARB_compatibility")
>
> Cc: Marek Olšák 
> Cc: Jordan Justen 
> Cc: Ian Romanick 
> Cc: Eric Engestrom 
> Cc: Emil Velikov 
> Signed-off-by: Andres Gomez 
> ---
>  docs/envvars.html   | 12 ++--
>  src/mesa/main/version.c |  7 ---
>  2 files changed, 10 insertions(+), 9 deletions(-)
>
> diff --git a/docs/envvars.html b/docs/envvars.html
> index ea42a50779b..4ea5670b78d 100644
> --- a/docs/envvars.html
> +++ b/docs/envvars.html
> @@ -91,16 +91,16 @@ glGetString(GL_VERSION) and possibly the GL API type.
>   The format should be MAJOR.MINOR[FC]
>   FC is an optional suffix that indicates a forward compatible context.
>  This is only valid for versions = 3.0.
> - GL versions  3.0 are set to a compatibility (non-Core) profile
> - GL versions = 3.0, see below
> - GL versions  3.0 are set to a Core profile
> - Examples: 2.1, 3.0, 3.0FC, 3.1, 3.1FC
> + GL versions = 3.1 are set to a compatibility (non-Core) profile
> + GL versions  3.1 are set to a Core profile
> + Examples: 2.1, 3.0, 3.1, 3.1FC, 3.2, 3.2FC
>  
>   2.1 - select a compatibility (non-Core) profile with GL version 2.1
>   3.0 - select a compatibility (non-Core) profile with GL version 3.0
> - 3.0FC - select a Core+Forward Compatible profile with GL version 3.0
> - 3.1 - select a Core profile with GL version 3.1
> + 3.1 - select a compatibility (non-Core) profile with GL version 3.1
>   3.1FC - select a Core+Forward Compatible profile with GL version 3.1
> + 3.2 - select a Core profile with GL version 3.2
> + 3.2FC - select a Core+Forward Compatible profile with GL version 3.2
>  
>   Mesa may not really implement all the features of the given version.
>  (for developers only)
> diff --git a/src/mesa/main/version.c b/src/mesa/main/version.c
> index a28069054d3..5184ebd8fdb 100644
> --- a/src/mesa/main/version.c
> +++ b/src/mesa/main/version.c
> @@ -141,9 +141,10 @@ create_version_string(struct gl_context *ctx, const char 
> *prefix)
>   *
>   * 2.1: select a compatibility (non-Core) profile with GL version 2.1
>   * 3.0: select a compatibility (non-Core) profile with GL version 3.0
> - * 3.0FC: select a Core+Forward Compatible profile with GL version 3.0
> - * 3.1: select a Core profile with GL version 3.1
> + * 3.1: select a compatibility (non-Core) profile with GL version 3.1
>   * 3.1FC: select a Core+Forward Compatible profile with GL version 3.1
> + * 3.2: select a Core profile with GL version 3.2
> + * 3.2FC: select a Core+Forward Compatible profile with GL version 3.2
>   */
>  bool
>  _mesa_override_gl_version_contextless(struct gl_constants *consts,
> @@ -165,7 +166,7 @@ _mesa_override_gl_version_contextless(struct gl_constants 
> *consts,
>   if (version >= 30 && fwd_context) {
>  *apiOut = API_OPENGL_CORE;
>  consts->ContextFlags |= GL_CONTEXT_FLAG_FORWARD_COMPATIBLE_BIT;
> - } else if (version >= 31 && !compat_context) {
> + } else if (version >= 32 && !compat_context) {
>  *apiOut = API_OPENGL_CORE;
>   } else {
>  *apiOut = API_OPENGL_COMPAT;
> --
> 2.15.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] draw: simplify (and correct) aaline fallback (v2)

[Roland Scheidegger]

Am 06.03.2018 um 21:52 schrieb Brian Paul:
> Looks good.  That certainly does simplify things.  Two minor suggestions
> below.
> 
> In any case, for both, Reviewed-by: Brian Paul 
> 
> On 03/06/2018 01:34 PM, srol...@vmware.com wrote:
>> From: Roland Scheidegger 
>>
>> The motivation actually was to get rid of the additional tex
>> instruction, since that requires the draw fallback code to intercept
>> all sampler / view calls (even if the fallback is never hit).
>> Basically, the idea is to use coverage of the pixel to calculate
>> the alpha value, and coverage is simply based on the distance
>> to the center of the line (in both line direction, which is useful
>> for wide lines, as well as perpendicular to the line).
>> This is much closer to what hw supporting this natively actually does.
>> It also fixes an issue with line width not quite being correct, as
>> well as endpoints getting stretched too far (in line direction) with
>> wide lines, which is apparent with mesa demo line-width.
>> (For llvmpipe, it would probably make sense to do something like this
>> directly when drawing lines, since rendering two tris is twice as
>> expensive as a line, but it would need some changes with state
>> management.)
>> Since we're no longer relying on mipmapping to get the alpha value,
>> we also don't need to draw 3 rects (6 tris), one is sufficient.
>>
>> There's still issues (as before):
>> - quite sure it's not correct without half_pixel_center, but can't test
>> this with GL.
>> - aaline + line stipple is incorrect (evident with line-width demo).
>> Looking at the spec the stipple pattern should actually be based on
>> distance (not just dx or dy for x/y major lines as without aa).
>> - outputs (other than pos + the one used for line aa) should be
>> reinterpolated since we actually increase line length by half a pixel
>> (but there's no tests which would care).
>>
>> v2: simplify the math (should be equivalent), don't need immediate
>> ---
>>   src/gallium/auxiliary/draw/draw_pipe_aaline.c | 504
>> +-
>>   1 file changed, 100 insertions(+), 404 deletions(-)
>>



>> diff --git a/src/gallium/auxiliary/draw/draw_pipe_aaline.c
>> b/src/gallium/auxiliary/draw/draw_pipe_aaline.c
>> index a859dbc..591e2a3 100644
>> @@ -210,49 +155,29 @@ aa_transform_prolog(struct
>> tgsi_transform_context *ctx)
>>  struct aa_transform_context *aactx = (struct aa_transform_context
>> *) ctx;
>>  uint i;
>>   -   STATIC_ASSERT(sizeof(aactx->samplersUsed) * 8 >=
>> PIPE_MAX_SAMPLERS);
>> -
>> -   /* find free sampler */
>> -   aactx->freeSampler = free_bit(aactx->samplersUsed);
>> -   if (aactx->freeSampler < 0 || aactx->freeSampler >=
>> PIPE_MAX_SAMPLERS)
>> -  aactx->freeSampler = PIPE_MAX_SAMPLERS - 1;
>>    /* find two free temp regs */
>> -   for (i = 0; i < 32; i++) {
>> +   for (i = 0; i < 64; i++) {
>>     if ((aactx->tempsUsed & (1 << i)) == 0) {
>>     /* found a free temp */
>>     if (aactx->colorTemp < 0)
>>    aactx->colorTemp  = i;
>> -  else if (aactx->texTemp < 0)
>> - aactx->texTemp  = i;
>> +  else if (aactx->aaTemp < 0)
>> + aactx->aaTemp  = i;
>>     else
>>    break;
>>     }
>>  }
> 
> The loop could probably be eliminated and replaced with a couple
> ffsll(~tempsUsed) calls.
Right.


>>   @@ -266,13 +191,41 @@ aa_transform_epilog(struct
>> tgsi_transform_context *ctx)
>>  struct aa_transform_context *aactx = (struct aa_transform_context
>> *) ctx;
>>    if (aactx->colorOutput != -1) {
>> -  /* insert texture sampling code for antialiasing. */
>> -
>> -  /* TEX texTemp, input_coord, sampler, 2D */
>> -  tgsi_transform_tex_inst(ctx,
>> -  TGSI_FILE_TEMPORARY, aactx->texTemp,
>> -  TGSI_FILE_INPUT, aactx->maxInput + 1,
>> -  TGSI_TEXTURE_2D, aactx->freeSampler);
>> +  struct tgsi_full_instruction inst;
>> +  /* insert distance-based coverage code for antialiasing. */
>> +
>> +  /* saturate(linewidth - fabs(interpx), linelength -
>> fabs(interpz) */
>> +  inst = tgsi_default_full_instruction();
>> +  inst.Instruction.Saturate = true;
>> +  inst.Instruction.Opcode = TGSI_OPCODE_ADD;
>> +  inst.Instruction.NumDstRegs = 1;
>> +  tgsi_transform_dst_reg([0], TGSI_FILE_TEMPORARY,
>> + aactx->aaTemp, TGSI_WRITEMASK_XZ);
>> +  inst.Instruction.NumSrcRegs = 2;
>> +  tgsi_transform_src_reg([1], TGSI_FILE_INPUT,
>> aactx->maxInput + 1,
>> + TGSI_SWIZZLE_X, TGSI_SWIZZLE_X,
>> + TGSI_SWIZZLE_Z, TGSI_SWIZZLE_Z);
>> +  tgsi_transform_src_reg([0], TGSI_FILE_INPUT,
>> aactx->maxInput + 1,
>> + TGSI_SWIZZLE_Y, TGSI_SWIZZLE_Y,
>> + TGSI_SWIZZLE_W, TGSI_SWIZZLE_W);
>> +  inst.Src[1].Register.Absolute = 

Re: [Mesa-dev] [PATCH 1/2] draw: simplify (and correct) aaline fallback (v2)

[Brian Paul]

Looks good.  That certainly does simplify things.  Two minor suggestions 
below.


In any case, for both, Reviewed-by: Brian Paul 

On 03/06/2018 01:34 PM, srol...@vmware.com wrote:

From: Roland Scheidegger 

The motivation actually was to get rid of the additional tex
instruction, since that requires the draw fallback code to intercept
all sampler / view calls (even if the fallback is never hit).
Basically, the idea is to use coverage of the pixel to calculate
the alpha value, and coverage is simply based on the distance
to the center of the line (in both line direction, which is useful
for wide lines, as well as perpendicular to the line).
This is much closer to what hw supporting this natively actually does.
It also fixes an issue with line width not quite being correct, as
well as endpoints getting stretched too far (in line direction) with
wide lines, which is apparent with mesa demo line-width.
(For llvmpipe, it would probably make sense to do something like this
directly when drawing lines, since rendering two tris is twice as
expensive as a line, but it would need some changes with state
management.)
Since we're no longer relying on mipmapping to get the alpha value,
we also don't need to draw 3 rects (6 tris), one is sufficient.

There's still issues (as before):
- quite sure it's not correct without half_pixel_center, but can't test
this with GL.
- aaline + line stipple is incorrect (evident with line-width demo).
Looking at the spec the stipple pattern should actually be based on
distance (not just dx or dy for x/y major lines as without aa).
- outputs (other than pos + the one used for line aa) should be
reinterpolated since we actually increase line length by half a pixel
(but there's no tests which would care).

v2: simplify the math (should be equivalent), don't need immediate
---
  src/gallium/auxiliary/draw/draw_pipe_aaline.c | 504 +-
  1 file changed, 100 insertions(+), 404 deletions(-)

diff --git a/src/gallium/auxiliary/draw/draw_pipe_aaline.c 
b/src/gallium/auxiliary/draw/draw_pipe_aaline.c
index a859dbc..591e2a3 100644
--- a/src/gallium/auxiliary/draw/draw_pipe_aaline.c
+++ b/src/gallium/auxiliary/draw/draw_pipe_aaline.c
@@ -1,6 +1,6 @@
  /**
   *
- * Copyright 2007 VMware, Inc.
+ * Copyright 2007-2018 VMware, Inc.
   * All Rights Reserved.
   *
   * Permission is hereby granted, free of charge, to any person obtaining a
@@ -26,7 +26,7 @@
   **/
  
  /**

- * AA line stage:  AA lines are converted to texture mapped triangles.
+ * AA line stage:  AA lines are converted triangles (with extra generic)
   *
   * Authors:  Brian Paul
   */
@@ -40,7 +40,6 @@
  #include "util/u_format.h"
  #include "util/u_math.h"
  #include "util/u_memory.h"
-#include "util/u_sampler.h"
  
  #include "tgsi/tgsi_transform.h"

  #include "tgsi/tgsi_dump.h"
@@ -55,19 +54,6 @@
  
  
  /**

- * Size for the alpha texture used for antialiasing
- */
-#define TEXTURE_SIZE_LOG2  5   /* 32 x 32 */
-
-/**
- * Max texture level for the alpha texture used for antialiasing
- *
- * Don't use the 1x1 and 2x2 mipmap levels.
- */
-#define MAX_TEXTURE_LEVEL  (TEXTURE_SIZE_LOG2 - 2)
-
-
-/**
   * Subclass of pipe_shader_state to carry extra fragment shader info.
   */
  struct aaline_fragment_shader
@@ -75,8 +61,7 @@ struct aaline_fragment_shader
 struct pipe_shader_state state;
 void *driver_fs;
 void *aaline_fs;
-   uint sampler_unit;
-   int generic_attrib;  /**< texcoord/generic used for texture */
+   int generic_attrib;  /**< generic used for distance */
  };
  
  
@@ -89,26 +74,16 @@ struct aaline_stage
  
 float half_line_width;
  
-   /** For AA lines, this is the vertex attrib slot for the new texcoords */

-   uint tex_slot;
+   /** For AA lines, this is the vertex attrib slot for new generic */
+   uint coord_slot;
 /** position, not necessarily output zero */
 uint pos_slot;
  
-   void *sampler_cso;

-   struct pipe_resource *texture;
-   struct pipe_sampler_view *sampler_view;
-   uint num_samplers;
-   uint num_sampler_views;
-
  
 /*

  * Currently bound state
  */
 struct aaline_fragment_shader *fs;
-   struct {
-  void *sampler[PIPE_MAX_SAMPLERS];
-  struct pipe_sampler_view *sampler_views[PIPE_MAX_SHADER_SAMPLER_VIEWS];
-   } state;
  
 /*

  * Driver interface/override functions
@@ -117,15 +92,6 @@ struct aaline_stage
  const struct pipe_shader_state *);
 void (*driver_bind_fs_state)(struct pipe_context *, void *);
 void (*driver_delete_fs_state)(struct pipe_context *, void *);
-
-   void (*driver_bind_sampler_states)(struct pipe_context *,
-  enum pipe_shader_type, unsigned,
-  unsigned, void **);
-
-   void 

[Mesa-dev] [PATCH 2/2] draw: fix line stippling with aa lines

[sroland]

From: Roland Scheidegger 

In contrast to non-aa, where stippling is based on either dx or dy
(depending on if it's a x or y major line), stippling is based on
actual distance with smooth lines, so adjust for this.

(It looks like there's some minor artifacts with mesa demos
line-sample with wide lines, I think there might be some issues
with wide lines and very short line segments (when the original
line segment length is below half a pixel) but it may be related
to aa lines rather than stippling.)
---
 src/gallium/auxiliary/draw/draw_pipe_stipple.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/src/gallium/auxiliary/draw/draw_pipe_stipple.c 
b/src/gallium/auxiliary/draw/draw_pipe_stipple.c
index 3a84d6c..8fa8274 100644
--- a/src/gallium/auxiliary/draw/draw_pipe_stipple.c
+++ b/src/gallium/auxiliary/draw/draw_pipe_stipple.c
@@ -50,6 +50,7 @@ struct stipple_stage {
float counter;
uint pattern;
uint factor;
+   bool smooth;
 };
 
 
@@ -136,9 +137,15 @@ stipple_line(struct draw_stage *stage, struct prim_header 
*header)
float dx = x0 > x1 ? x0 - x1 : x1 - x0;
float dy = y0 > y1 ? y0 - y1 : y1 - y0;
 
-   float length = MAX2(dx, dy);
+   float length;
int i;
 
+   if (stipple->smooth) {
+  length = sqrtf(dx*dx + dy*dy);
+   } else {
+  length = MAX2(dx, dy);
+   }
+
if (header->flags & DRAW_PIPE_RESET_STIPPLE)
   stipple->counter = 0;
 
@@ -205,6 +212,7 @@ stipple_first_line(struct draw_stage *stage,
 
stipple->pattern = draw->rasterizer->line_stipple_pattern;
stipple->factor = draw->rasterizer->line_stipple_factor + 1;
+   stipple->smooth = draw->rasterizer->line_smooth;
 
stage->line = stipple_line;
stage->line(stage, header);
-- 
2.7.4

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

[Mesa-dev] [PATCH 1/2] draw: simplify (and correct) aaline fallback (v2)

[sroland]

From: Roland Scheidegger 

The motivation actually was to get rid of the additional tex
instruction, since that requires the draw fallback code to intercept
all sampler / view calls (even if the fallback is never hit).
Basically, the idea is to use coverage of the pixel to calculate
the alpha value, and coverage is simply based on the distance
to the center of the line (in both line direction, which is useful
for wide lines, as well as perpendicular to the line).
This is much closer to what hw supporting this natively actually does.
It also fixes an issue with line width not quite being correct, as
well as endpoints getting stretched too far (in line direction) with
wide lines, which is apparent with mesa demo line-width.
(For llvmpipe, it would probably make sense to do something like this
directly when drawing lines, since rendering two tris is twice as
expensive as a line, but it would need some changes with state
management.)
Since we're no longer relying on mipmapping to get the alpha value,
we also don't need to draw 3 rects (6 tris), one is sufficient.

There's still issues (as before):
- quite sure it's not correct without half_pixel_center, but can't test
this with GL.
- aaline + line stipple is incorrect (evident with line-width demo).
Looking at the spec the stipple pattern should actually be based on
distance (not just dx or dy for x/y major lines as without aa).
- outputs (other than pos + the one used for line aa) should be
reinterpolated since we actually increase line length by half a pixel
(but there's no tests which would care).

v2: simplify the math (should be equivalent), don't need immediate
---
 src/gallium/auxiliary/draw/draw_pipe_aaline.c | 504 +-
 1 file changed, 100 insertions(+), 404 deletions(-)

diff --git a/src/gallium/auxiliary/draw/draw_pipe_aaline.c 
b/src/gallium/auxiliary/draw/draw_pipe_aaline.c
index a859dbc..591e2a3 100644
--- a/src/gallium/auxiliary/draw/draw_pipe_aaline.c
+++ b/src/gallium/auxiliary/draw/draw_pipe_aaline.c
@@ -1,6 +1,6 @@
 /**
  *
- * Copyright 2007 VMware, Inc.
+ * Copyright 2007-2018 VMware, Inc.
  * All Rights Reserved.
  *
  * Permission is hereby granted, free of charge, to any person obtaining a
@@ -26,7 +26,7 @@
  **/
 
 /**
- * AA line stage:  AA lines are converted to texture mapped triangles.
+ * AA line stage:  AA lines are converted triangles (with extra generic)
  *
  * Authors:  Brian Paul
  */
@@ -40,7 +40,6 @@
 #include "util/u_format.h"
 #include "util/u_math.h"
 #include "util/u_memory.h"
-#include "util/u_sampler.h"
 
 #include "tgsi/tgsi_transform.h"
 #include "tgsi/tgsi_dump.h"
@@ -55,19 +54,6 @@
 
 
 /**
- * Size for the alpha texture used for antialiasing
- */
-#define TEXTURE_SIZE_LOG2  5   /* 32 x 32 */
-
-/**
- * Max texture level for the alpha texture used for antialiasing
- *
- * Don't use the 1x1 and 2x2 mipmap levels.
- */
-#define MAX_TEXTURE_LEVEL  (TEXTURE_SIZE_LOG2 - 2)
-
-
-/**
  * Subclass of pipe_shader_state to carry extra fragment shader info.
  */
 struct aaline_fragment_shader
@@ -75,8 +61,7 @@ struct aaline_fragment_shader
struct pipe_shader_state state;
void *driver_fs;
void *aaline_fs;
-   uint sampler_unit;
-   int generic_attrib;  /**< texcoord/generic used for texture */
+   int generic_attrib;  /**< generic used for distance */
 };
 
 
@@ -89,26 +74,16 @@ struct aaline_stage
 
float half_line_width;
 
-   /** For AA lines, this is the vertex attrib slot for the new texcoords */
-   uint tex_slot;
+   /** For AA lines, this is the vertex attrib slot for new generic */
+   uint coord_slot;
/** position, not necessarily output zero */
uint pos_slot;
 
-   void *sampler_cso;
-   struct pipe_resource *texture;
-   struct pipe_sampler_view *sampler_view;
-   uint num_samplers;
-   uint num_sampler_views;
-
 
/*
 * Currently bound state
 */
struct aaline_fragment_shader *fs;
-   struct {
-  void *sampler[PIPE_MAX_SAMPLERS];
-  struct pipe_sampler_view *sampler_views[PIPE_MAX_SHADER_SAMPLER_VIEWS];
-   } state;
 
/*
 * Driver interface/override functions
@@ -117,15 +92,6 @@ struct aaline_stage
 const struct pipe_shader_state *);
void (*driver_bind_fs_state)(struct pipe_context *, void *);
void (*driver_delete_fs_state)(struct pipe_context *, void *);
-
-   void (*driver_bind_sampler_states)(struct pipe_context *,
-  enum pipe_shader_type, unsigned,
-  unsigned, void **);
-
-   void (*driver_set_sampler_views)(struct pipe_context *,
-enum pipe_shader_type shader,
-unsigned start, unsigned count,
-struct pipe_sampler_view **);
 };
 
 
@@ -136,41 +102,27 

Re: [Mesa-dev] [PATCH 18/22] i965/fs: Add infrastructure for generating CSEL instructions.

[Matt Turner]

On Tue, Mar 6, 2018 at 11:28 AM, Ian Romanick  wrote:
> On 03/06/2018 11:24 AM, Matt Turner wrote:
>> On Tue, Mar 6, 2018 at 11:22 AM, Ian Romanick  wrote:
>>> On 03/05/2018 04:40 PM, Matt Turner wrote:
 On Fri, Feb 23, 2018 at 3:56 PM, Ian Romanick  wrote:
> From: Kenneth Graunke 
>
> v2 (idr): Don't allow CSEL with a non-float src2.
>
> v3 (idr): Add CSEL to fs_inst::flags_written.  Suggested by Matt.

 brw_disassemble_inst
 fs_visitor::dump_instruction
 vec4_instruction:writes_flag
 vec4_visitor::dump_instruction
>>>
>>> Do we need to update vec4 code?  This instruction is BDW+, and we don't
>>> use the vec4 backend for anything on those platforms... and this
>>> optimization is FS-only.
>>
>> Not strictly necessary, but those conditions are checking the same
>> thing so I'd keep them in sync.
>
> Ok.  How can I test various dump_instruction and brw_disassemble_inst paths?

brw_disassemble_inst() is called when we use INTEL_DEBUG=fs,vs,gs,etc
to disassemble individual instructions. INTEL_DEBUG=... on a shader
with csel without the change to brw_disassemble_inst should print
csel.cmod.f0, and with the change should just print csel.cmod.

dump_instructions() prints the backend IR and is used for debugging
optimization passes. INTEL_DEBUG=optimizer will write out text files
after each optimization pass that makes progress. The change will
prevent the .f0 from being printed, like in brw_disassemble_inst().

We don't want to print .f0 because it doesn't write (or even use!) .f0.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC] Mesa 17.3.x release problems and process improvements

[Ilia Mirkin]

On Tue, Mar 6, 2018 at 2:34 PM, Emil Velikov  wrote:
> So while others explore ways of improving the testing, let me propose
> a few ideas for improving the actual releasing process.
>
>
>  - Making the current state always visible - have a web page, git
>branch and other ways for people to see which patches are picked,
>require backports, etc.

Yes please! A git branch that's available (and force-pushed freely)
before the "you're screwed" announcement is going to help clear a lot
of things up.

>
>  - Per team maintainer - each team has person (a few people) to check,
>coordinate and remind people for high priority bugs and backports.

Yes! I think this role is highly necessary, but not for the reasons
you outline here. My main issue thus far with the stable release
process has been that I don't appear to have any control over what
patches are included in a particular release. Reasons for rejection
have varied from "well, there will be another release in 2+ weeks" to
"this patch doesn't fit some arbitrary criterion".

What I'd like to propose is a system where the team maintainer is able
to request any particular patch to be included in a stable release (as
long as it's done by a certain pre-announced deadline, which happens
*after* the initial release nominations email). If a release manager
disagrees, they can make that disagreement known, but it's ultimately
up to the team maintainer for driver code. If it's in shared code
(i.e. not driver-specific - winsys, core mesa, state trackers used by
multiple drivers), the override would be 1 additional team maintainer
acking, and conversely any team maintainer would be able to nak it (so
the condition in case of disagreement would be at least 2 team
maintainers in favor, and 0 against).

As you may know, I've stopped tagging things for stable since a while
back since it seems completely pointless - nothing I can do to
actually cause a patch to be included in a release. Telling people to
just use HEAD seems way more reliable. I'm not particularly happy with
this arrangement, but it's at least supportable.

Hopefully others here agree with me. Otherwise I'll just go back to
doing what I'm doing (and perhaps my contribution level has dropped
sufficiently to not worry about it).

Cheers,

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

[Mesa-dev] [PATCH 3/5] meson: Re-add auto option for omx

[Dylan Baker]

This re-adds the auto option for omx, without it we default to tizonia
and the build fails almost immediately, this is especially obnoxious
those building a driver that doesn't support the OMX state tracker to
begin with.

CC: Gurkirpal Singh 
Fixes: bb5e27fab6087a5c1528a5faf507acce700e883c
   ("st/omx/bellagio: Rename st and target directories")
Signed-off-by: Dylan Baker 
---
 meson.build| 67 --
 meson_options.txt  |  4 +-
 src/gallium/meson.build|  2 +-
 src/gallium/state_trackers/omx/meson.build | 18 
 4 files changed, 56 insertions(+), 35 deletions(-)

diff --git a/meson.build b/meson.build
index dd2fa603829..c85afdecee9 100644
--- a/meson.build
+++ b/meson.build
@@ -464,42 +464,63 @@ endif
 
 _omx = get_option('gallium-omx')
 if not system_has_kms_drm
-  if _omx != 'disabled'
-error('OMX state tracker can only be built on unix-like OSes.')
-  else
+  if ['auto', 'disabled'].contains(_omx)
 _omx = 'disabled'
+  else
+error('OMX state tracker can only be built on unix-like OSes.')
   endif
 elif not (with_platform_x11 or with_platform_drm)
-  if _omx != 'disabled'
-error('OMX state tracker requires X11 or drm platform support.')
-  else
+  if ['auto', 'disabled'].contains(_omx)
 _omx = 'disabled'
+  else
+error('OMX state tracker requires X11 or drm platform support.')
   endif
 elif not (with_gallium_r600 or with_gallium_radeonsi or with_gallium_nouveau)
-  if _omx != 'disabled'
-error('OMX state tracker requires at least one of the following gallium 
drivers: r600, radeonsi, nouveau.')
-  else
+  if ['auto', 'disabled'].contains(_omx)
 _omx = 'disabled'
+  else
+error('OMX state tracker requires at least one of the following gallium 
drivers: r600, radeonsi, nouveau.')
   endif
 endif
-with_gallium_omx = _omx != 'disabled'
-gallium_omx = _omx
+with_gallium_omx = _omx
 dep_omx = []
 dep_omx_other = []
-if gallium_omx == 'bellagio'
+if with_gallium_omx == 'bellagio' or with_gallium_omx == 'auto'
   pre_args += '-DENABLE_ST_OMX_BELLAGIO'
-  dep_omx = dependency('libomxil-bellagio')
-elif gallium_omx == 'tizonia'
-  pre_args += '-DENABLE_ST_OMX_TIZONIA'
-  dep_omx = dependency('libtizonia', version : '>= 0.10.0')
-  dep_omx_other = [
-dependency('libtizplatform'),
-dependency('tizilheaders')
-  ]
+  dep_omx = dependency(
+'libomxil-bellagio', required : with_gallium_omx == 'bellagio'
+  )
+  if dep_omx.found()
+with_gallium_omx = 'bellagio'
+  endif
+endif
+if with_gallium_omx == 'tizonia' or with_gallium_omx == 'auto'
+  if not (with_dri and with_egl)
+if with_gallium_omx == 'tizonia'
+  error('OMX-Tizonia state tracker requires dri and egl')
+else
+  with_gallium_omx == 'disabled'
+endif
+  else
+pre_args += '-DENABLE_ST_OMX_TIZONIA'
+dep_omx = dependency(
+  'libtizonia', version : '>= 0.10.0',
+  required : with_gallium_omx == 'tizonia',
+)
+dep_omx_other = [
+  dependency('libtizplatform', required : with_gallium_omx == 'tizonia'),
+  dependency('tizilheaders', required : with_gallium_omx == 'tizonia'),
+]
+if dep_omx.found() and dep_omx_other[0].found() and 
dep_omx_other[1].found()
+  with_gallium_omx = 'tizonia'
+else
+  with_gallium_omx = 'disabled'
+endif
+  endif
 endif
 
 omx_drivers_path = get_option('omx-libs-path')
-if with_gallium_omx
+if with_gallium_omx != 'disabled'
   # Figure out where to put the omx driver.
   # FIXME: this could all be vastly simplified by adding a 'defined_variable'
   # argument to meson's get_pkgconfig_variable method.
@@ -1193,8 +1214,8 @@ if with_platform_x11
 dep_xxf86vm = dependency('xxf86vm', required : false)
   endif
   if (with_any_vk or with_glx == 'dri' or
-   (with_gallium_vdpau or with_gallium_xvmc or with_gallium_omx or
-with_gallium_xa))
+   (with_gallium_vdpau or with_gallium_xvmc or with_gallium_va or
+with_gallium_omx != 'disabled'))
 dep_xcb = dependency('xcb')
 dep_x11_xcb = dependency('x11-xcb')
   endif
diff --git a/meson_options.txt b/meson_options.txt
index 50ae19685e7..a573290b774 100644
--- a/meson_options.txt
+++ b/meson_options.txt
@@ -90,8 +90,8 @@ option(
 option(
   'gallium-omx',
   type : 'combo',
-  value : 'tizonia',
-  choices : ['disabled', 'bellagio', 'tizonia'],
+  value : 'auto',
+  choices : ['auto', 'disabled', 'bellagio', 'tizonia'],
   description : 'enable gallium omx state tracker.',
 )
 option(
diff --git a/src/gallium/meson.build b/src/gallium/meson.build
index d3cbb76d94d..108234ad322 100644
--- a/src/gallium/meson.build
+++ b/src/gallium/meson.build
@@ -170,7 +170,7 @@ if with_gallium_xvmc
   subdir('state_trackers/xvmc')
   subdir('targets/xvmc')
 endif
-if with_gallium_omx
+if with_gallium_omx != 'disabled'
   subdir('state_trackers/omx')
   subdir('targets/omx')
 endif
diff --git 

[Mesa-dev] [PATCH 4/5] meson: Use include directory variables instead of traversing

[Dylan Baker]

Signed-off-by: Dylan Baker 
---
 src/egl/meson.build|  5 -
 src/gallium/state_trackers/dri/meson.build |  2 ++
 src/gallium/state_trackers/omx/meson.build | 12 +---
 src/gbm/meson.build|  2 +-
 4 files changed, 12 insertions(+), 9 deletions(-)

diff --git a/src/egl/meson.build b/src/egl/meson.build
index 36cd33ac08b..6537e4bdee6 100644
--- a/src/egl/meson.build
+++ b/src/egl/meson.build
@@ -18,10 +18,13 @@
 # OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
 # SOFTWARE.
 
+inc_egl = include_directories('.', 'main')
+inc_egl_dri2 = include_directories('drivers/dri2')
+
 c_args_for_egl = []
 link_for_egl = []
 deps_for_egl = []
-incs_for_egl = [inc_include, inc_src, include_directories('main')]
+incs_for_egl = [inc_include, inc_src, inc_egl]
 
 files_egl = files(
   'main/eglapi.c',
diff --git a/src/gallium/state_trackers/dri/meson.build 
b/src/gallium/state_trackers/dri/meson.build
index b99314ebf61..dfc37fcd81c 100644
--- a/src/gallium/state_trackers/dri/meson.build
+++ b/src/gallium/state_trackers/dri/meson.build
@@ -18,6 +18,8 @@
 # OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
 # SOFTWARE.
 
+inc_st_dri = include_directories('.')
+
 files_libdri = files(
   'dri_context.c',
   'dri_context.h',
diff --git a/src/gallium/state_trackers/omx/meson.build 
b/src/gallium/state_trackers/omx/meson.build
index b0c71a895ff..dd803f679fa 100644
--- a/src/gallium/state_trackers/omx/meson.build
+++ b/src/gallium/state_trackers/omx/meson.build
@@ -51,13 +51,11 @@ files_omx += files(
 inc_st_omx = [
   inc_st_omx,
   inc_dri_common,
-  include_directories('../../state_trackers/dri'),
-  include_directories('../../../egl/drivers/dri2'),
-  include_directories('../../../egl/main'),
-  include_directories('../../../egl'),
-  include_directories('../../../gbm/backends/dri'),
-  include_directories('../../../gbm/main'),
-  include_directories('../../../loader')
+  inc_loader,
+  inc_gbm,
+  inc_st_dri,
+  inc_egl,
+  inc_egl_dri2,
 ]
 dep_st_omx = [dep_st_omx, dep_omx_other, dep_libdrm]
 endif
diff --git a/src/gbm/meson.build b/src/gbm/meson.build
index 13fa3a1f84c..7a60868783c 100644
--- a/src/gbm/meson.build
+++ b/src/gbm/meson.build
@@ -18,7 +18,7 @@
 # OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
 # SOFTWARE.
 
-inc_gbm = include_directories('.', 'backends/dri')
+inc_gbm = include_directories('.', 'main', 'backends/dri')
 
 files_gbm = files(
   'main/backend.c',
-- 
2.16.2

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

[Mesa-dev] [PATCH 1/5] meson: combine state trackers and target if blocks

[Dylan Baker]

This is needed later since tizonia requires dri

Signed-off-by: Dylan Baker 
---
 src/gallium/meson.build | 28 +++-
 1 file changed, 7 insertions(+), 21 deletions(-)

diff --git a/src/gallium/meson.build b/src/gallium/meson.build
index 7f49c285992..d3cbb76d94d 100644
--- a/src/gallium/meson.build
+++ b/src/gallium/meson.build
@@ -138,27 +138,6 @@ if with_gallium_virgl
 else
   driver_virgl = declare_dependency()
 endif
-if with_gallium_vdpau
-  subdir('state_trackers/vdpau')
-endif
-if with_gallium_xvmc
-  subdir('state_trackers/xvmc')
-endif
-if with_gallium_omx
-  subdir('state_trackers/omx')
-endif
-if with_gallium_va
-  subdir('state_trackers/va')
-endif
-if with_gallium_xa
-  subdir('state_trackers/xa')
-endif
-if with_gallium_st_nine
-  subdir('state_trackers/nine')
-endif
-if with_platform_haiku
-  subdir('state_trackers/hgl')
-endif
 if with_gallium_opencl
   # TODO: this isn't really clover specific, but ATM clover is the only
   # consumer
@@ -184,24 +163,31 @@ if with_glx == 'gallium-xlib'
   subdir('targets/libgl-xlib')
 endif
 if with_gallium_vdpau
+  subdir('state_trackers/vdpau')
   subdir('targets/vdpau')
 endif
 if with_gallium_xvmc
+  subdir('state_trackers/xvmc')
   subdir('targets/xvmc')
 endif
 if with_gallium_omx
+  subdir('state_trackers/omx')
   subdir('targets/omx')
 endif
 if with_gallium_va
+  subdir('state_trackers/va')
   subdir('targets/va')
 endif
 if with_gallium_xa
+  subdir('state_trackers/xa')
   subdir('targets/xa')
 endif
 if with_platform_haiku
+  subdir('state_trackers/hgl')
   subdir('targets/haiku-softpipe')
 endif
 if with_gallium_st_nine
+  subdir('state_trackers/nine')
   subdir('targets/d3dadapter9')
 endif
 # TODO: tests
-- 
2.16.2

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

[Mesa-dev] [PATCH 5/5] meson: Fix indent in omx meson.build

[Dylan Baker]

Signed-off-by: Dylan Baker 
---
 src/gallium/state_trackers/omx/meson.build | 64 +++---
 1 file changed, 32 insertions(+), 32 deletions(-)

diff --git a/src/gallium/state_trackers/omx/meson.build 
b/src/gallium/state_trackers/omx/meson.build
index dd803f679fa..382bf2ed23b 100644
--- a/src/gallium/state_trackers/omx/meson.build
+++ b/src/gallium/state_trackers/omx/meson.build
@@ -22,42 +22,42 @@ inc_st_omx = [inc_common]
 dep_st_omx = [dep_omx, dep_x11_xcb, dep_xcb, dep_xcb_dri2, dep_xcb_dri3]
 
 files_omx = files(
-   'vid_dec_common.c',
-   'vid_dec_h264_common.c',
-   'vid_enc_common.c',
-   'vid_omx_common.c'
+  'vid_dec_common.c',
+  'vid_dec_h264_common.c',
+  'vid_enc_common.c',
+  'vid_omx_common.c'
 )
 
 if with_gallium_omx == 'bellagio'
-files_omx += files(
-  'bellagio/entrypoint.c',
-  'bellagio/vid_dec.c',
-  'bellagio/vid_dec_mpeg12.c',
-  'bellagio/vid_dec_h264.c',
-  'bellagio/vid_dec_h265.c',
-  'bellagio/vid_enc.c'
-)
+  files_omx += files(
+'bellagio/entrypoint.c',
+'bellagio/vid_dec.c',
+'bellagio/vid_dec_mpeg12.c',
+'bellagio/vid_dec_h264.c',
+'bellagio/vid_dec_h265.c',
+'bellagio/vid_enc.c'
+  )
 elif with_gallium_omx == 'tizonia'
-files_omx += files(
-  'tizonia/entrypoint.c',
-'tizonia/h264d.c',
-'tizonia/h264dprc.c',
-'tizonia/h264dinport.c',
-'tizonia/h264e.c',
-'tizonia/h264eprc.c',
-'tizonia/h264einport.c',
-'tizonia/h264eoutport.c'
-)
-inc_st_omx = [
-  inc_st_omx,
-  inc_dri_common,
-  inc_loader,
-  inc_gbm,
-  inc_st_dri,
-  inc_egl,
-  inc_egl_dri2,
-]
-dep_st_omx = [dep_st_omx, dep_omx_other, dep_libdrm]
+  files_omx += files(
+'tizonia/entrypoint.c',
+ 'tizonia/h264d.c',
+ 'tizonia/h264dprc.c',
+ 'tizonia/h264dinport.c',
+ 'tizonia/h264e.c',
+ 'tizonia/h264eprc.c',
+ 'tizonia/h264einport.c',
+ 'tizonia/h264eoutport.c'
+  )
+  inc_st_omx = [
+inc_st_omx,
+inc_dri_common,
+inc_loader,
+inc_gbm,
+inc_st_dri,
+inc_egl,
+inc_egl_dri2,
+  ]
+  dep_st_omx = [dep_st_omx, dep_omx_other, dep_libdrm]
 endif
 
 libomx_st = static_library(
-- 
2.16.2

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

[Mesa-dev] [PATCH 0/5] Fix meson omx compilation

[Dylan Baker]

This fixes a couple of problems with the meson build support for the
recent omx tizonia integration, namely that it breaks a lot of
previously working meson configurations.

The biggest change in here is the reintroduction of the 'auto' flag to
-Dgallium-omx. This allows configurations that lack tizonia, or that
otherwise can't build the omx tracker (i965, and gallium drivers other
than r600, radeon, or nouveau) to build without intervention.

This also fixes some style things, but those are pretty trivial.

Dylan Baker (5):
  meson: combine state trackers and target if blocks
  meson: fix tizonia compilation
  meson: Re-add auto option for omx
  meson: Use include directory variables instead of traversing
  meson: Fix indent in omx meson.build

 meson.build| 67 +++--
 meson_options.txt  |  4 +-
 src/egl/meson.build|  5 ++-
 src/gallium/meson.build| 30 -
 src/gallium/state_trackers/dri/meson.build |  2 +
 src/gallium/state_trackers/omx/meson.build | 69 +++---
 src/gbm/meson.build|  2 +-
 7 files changed, 95 insertions(+), 84 deletions(-)

-- 
2.16.2

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

[Mesa-dev] [PATCH 2/5] meson: fix tizonia compilation

[Dylan Baker]

It needs to have src/egl in it's includes as well.

Signed-off-by: Dylan Baker 
---
 src/gallium/state_trackers/omx/meson.build | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/gallium/state_trackers/omx/meson.build 
b/src/gallium/state_trackers/omx/meson.build
index 84e5631d257..9470468d753 100644
--- a/src/gallium/state_trackers/omx/meson.build
+++ b/src/gallium/state_trackers/omx/meson.build
@@ -54,6 +54,7 @@ inc_st_omx = [
   include_directories('../../state_trackers/dri'),
   include_directories('../../../egl/drivers/dri2'),
   include_directories('../../../egl/main'),
+  include_directories('../../../egl'),
   include_directories('../../../gbm/backends/dri'),
   include_directories('../../../gbm/main'),
   include_directories('../../../loader')
-- 
2.16.2

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

Re: [Mesa-dev] [PATCH 3/3] i965/tex_image: Avoid the ASTC LDR workaround on gen9lp

[Nanley Chery]

On Tue, Mar 06, 2018 at 12:22:40AM -0800, Kenneth Graunke wrote:
> On Monday, March 5, 2018 2:07:55 PM PST Nanley Chery wrote:
> > Both the internal documentation and the results of testing this in the
> > CI suggest that this is unnecessary. Add the fixes tag because this
> > reduces an internal benchmark's startup time significantly. Eero
> > reported that a less optimal version of this patch reduced the startup
> > time of the benchmark by about 14 seconds.
> > 
> > Fixes: 710b1d2e665 "i965/tex_image: Flush certain subnormal ASTC channel 
> > values"
> > Cc: Eero Tamminen 
> > Cc: Scott D Phillips 
> > ---
> >  src/mesa/drivers/dri/i965/intel_tex_image.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/src/mesa/drivers/dri/i965/intel_tex_image.c 
> > b/src/mesa/drivers/dri/i965/intel_tex_image.c
> > index e25bc9a0c08..a0408b304d5 100644
> > --- a/src/mesa/drivers/dri/i965/intel_tex_image.c
> > +++ b/src/mesa/drivers/dri/i965/intel_tex_image.c
> > @@ -927,7 +927,7 @@ intelCompressedTexSubImage(struct gl_context *ctx, 
> > GLuint dims,
> >  !_mesa_is_srgb_format(gl_format);
> > struct brw_context *brw = (struct brw_context*) ctx;
> > const struct gen_device_info *devinfo = >screen->devinfo;
> > -   if (devinfo->gen == 9 && is_linear_astc)
> > +   if (devinfo->gen == 9 && !gen_device_info_is_9lp(devinfo) && 
> > is_linear_astc)
> >flush_astc_denorms(ctx, dims, texImage,
> >   xoffset, yoffset, zoffset,
> >   width, height, depth);
> > 
> 
> I don't know how to review this, really, but it sounds very plausible
> that they would have fixed that bug on gen9lp.  If it doesn't regress
> any tests, then:
> 
> Acked-by: Kenneth Graunke 
> 

Thanks! 

> This begs the question, though - is it just Skylake that needs the
> denorm flushing hack?  What about Kabylake or Coffeelake?  
> 

The results of the Jenkins jobs, nchery/281 and mesa_custom/3672, show
that all big-core gen9 platforms need it. 

-Nanley

> --Ken


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

Re: [Mesa-dev] Requesting Guidance for EVoC Application

[Christian König]

Hi Khilan,

sorry that is probably my fault.  The Task "Implement Remaining 
presentation features in the VDPAU state tracker" was already done by a 
Student in 2016/2017. I've just forgot to update the page.


Since you have experience with image processing you could still look 
into some other video codec related work.


Anything you are particular interest in?

Regards,
Christian.

Am 06.03.2018 um 16:12 schrieb Khilan Ravani:

Sir/Mam,

I am a sophomore student pursuing Computer Science and Engineering 
(C.S.E) from Indian Institute of Information Technology, Vadodara. I 
am well adapt with concepts of Deep Learning, Medical Image Processing 
& AI and am currently working on a few research topics in the same 
domain. I came across your organization while searching some 
interesting Opensource projects/internships and would love to know 
more about it.


I am particularly interested in the project : *" Implement Remaining 
presentation features in the VDPAU state tracker"*since it is the one 
in line with my research interests. I have adequate experience in 
machine learning and Signal / Image processing and am currently 
pursuing some research problems in Satellite Imaging (Hyper-spectral 
data analysis) and processing SAR images.


I do possess the required programming skills (C++, OpenCV, Python, 
Tensorflow, Keras (CUDA framework), Watson API, Matlab) as well as the 
exposure to open source platforms such as github and would like to 
request you to please guide me with the further process for writing a 
proposal.


Hope to hear from you soon,

Thank You,
Yours Sincerely,
Khilan Ravani.



___
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] [RFC] Mesa 17.3.x release problems and process improvements

[Emil Velikov]

Hi Ken, all,

As you may know, a few Mesa 17.3.x releases went out with some nasty
bugs.

Some were due to lack of basic coverage, while others required fairly
complex test setups. Ones that are currently not available or feasible
in an automated manner.

Additionally, with the increased pace of development some nominated
patches require non-trivial changes or depend on others patches that
are not nominated.

While nearly all of the non-trivial nominations receive a reply from a
release manager, it's possible to miss some or their respective reply.

Furthermore the pre-release announcement email is, albeit concise,
still fairly long. Thus making it easy to miss specific details.


So while others explore ways of improving the testing, let me propose
a few ideas for improving the actual releasing process.


 - Making the current state always visible - have a web page, git
   branch and other ways for people to see which patches are picked,
   require backports, etc.

It will allow an interactive view and testing from anyone at any point
in time. To implement that we could explore Patchwork or Gitlab.


 - Per team maintainer - each team has person (a few people) to check,
   coordinate and remind people for high priority bugs and backports.

This will help us in two ways: a) some bugs have more weight than
externally visible, b) the informal poke while sharing a cup of coffee
is more welcoming than reminders over email/IRC.


A few other ideas that were also came to mind:

 - Round robin - where me/Igalia team will check for outstanding
   patches, backports, etc.

 - Have two distinct emails - an announcement and a second RFC that
   lists the rejected patches and ones with outstanding backports


Obviously, the above suggestions are with my release manager hat on.

So any corrections, alternative suggestions and general nods of
approval would be greatly appreciated.


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

Re: [Mesa-dev] [PATCH 18/22] i965/fs: Add infrastructure for generating CSEL instructions.

[Ian Romanick]

On 03/06/2018 11:24 AM, Matt Turner wrote:
> On Tue, Mar 6, 2018 at 11:22 AM, Ian Romanick  wrote:
>> On 03/05/2018 04:40 PM, Matt Turner wrote:
>>> On Fri, Feb 23, 2018 at 3:56 PM, Ian Romanick  wrote:
 From: Kenneth Graunke 

 v2 (idr): Don't allow CSEL with a non-float src2.

 v3 (idr): Add CSEL to fs_inst::flags_written.  Suggested by Matt.
>>>
>>> brw_disassemble_inst
>>> fs_visitor::dump_instruction
>>> vec4_instruction:writes_flag
>>> vec4_visitor::dump_instruction
>>
>> Do we need to update vec4 code?  This instruction is BDW+, and we don't
>> use the vec4 backend for anything on those platforms... and this
>> optimization is FS-only.
> 
> Not strictly necessary, but those conditions are checking the same
> thing so I'd keep them in sync.

Ok.  How can I test various dump_instruction and brw_disassemble_inst paths?

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

Re: [Mesa-dev] [PATCH 18/22] i965/fs: Add infrastructure for generating CSEL instructions.

[Matt Turner]

On Tue, Mar 6, 2018 at 11:22 AM, Ian Romanick  wrote:
> On 03/05/2018 04:40 PM, Matt Turner wrote:
>> On Fri, Feb 23, 2018 at 3:56 PM, Ian Romanick  wrote:
>>> From: Kenneth Graunke 
>>>
>>> v2 (idr): Don't allow CSEL with a non-float src2.
>>>
>>> v3 (idr): Add CSEL to fs_inst::flags_written.  Suggested by Matt.
>>
>> brw_disassemble_inst
>> fs_visitor::dump_instruction
>> vec4_instruction:writes_flag
>> vec4_visitor::dump_instruction
>
> Do we need to update vec4 code?  This instruction is BDW+, and we don't
> use the vec4 backend for anything on those platforms... and this
> optimization is FS-only.

Not strictly necessary, but those conditions are checking the same
thing so I'd keep them in sync.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 18/22] i965/fs: Add infrastructure for generating CSEL instructions.

[Ian Romanick]

On 03/05/2018 04:40 PM, Matt Turner wrote:
> On Fri, Feb 23, 2018 at 3:56 PM, Ian Romanick  wrote:
>> From: Kenneth Graunke 
>>
>> v2 (idr): Don't allow CSEL with a non-float src2.
>>
>> v3 (idr): Add CSEL to fs_inst::flags_written.  Suggested by Matt.
> 
> brw_disassemble_inst
> fs_visitor::dump_instruction
> vec4_instruction:writes_flag
> vec4_visitor::dump_instruction

Do we need to update vec4 code?  This instruction is BDW+, and we don't
use the vec4 backend for anything on those platforms... and this
optimization is FS-only.

> should all be updated similarly.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 20/22] i965/vec4: Relax writemask condition in CSE

[Ian Romanick]

On 03/05/2018 02:50 PM, Kenneth Graunke wrote:
> On Friday, February 23, 2018 3:56:05 PM PST Ian Romanick wrote:
>> From: Ian Romanick 
>>
>> If the previously seen instruction generates more fields than the new
>> instruction, still allow CSE to happen.  This doesn't do much, but it
>> also enables a couple more shaders in the next patch.  It helped quite a
>> bit in another change series that I have (at least for now) abandoned.
>>
>> No changes on Skylake, Broadwell, Iron Lake or GM45.
> 
> Skylake and Broadwell sort of go without saying, they don't use this
> compiler :)
> 
> It might be worth leaving some kind of comment (or renaming variables?)
> in instructions_match() to indicate that 'a' is the generating
> expression and 'b' is the second instance...since it's no longer
> exactly symmetrical.

I thought about that... I just couldn't come up with any names that I
actually liked.  Do you have any favorites? :)

> Either way,
> Reviewed-by: Kenneth Graunke 



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

[Mesa-dev] [PATCH] draw: simplify (and correct) aaline fallback

[sroland]

From: Roland Scheidegger 

The motivation actually was to get rid of the additional tex
instruction, since that requires the draw fallback code to intercept
all sampler / view calls (even if the fallback is never hit).
Basically, the idea is to use coverage of the pixel to calculate
the alpha value, and coverage is simply based on the distance
to the center of the line (in both line direction, which is useful
for wide lines, as well as perpendicular to the line).
This is much closer to what hw supporting this natively actually does.
It also fixes an issue with line width not quite being correct, as
well as endpoints getting stretched too far (in line direction) with
wide lines, which is apparent with mesa demo line-width.
(For llvmpipe, it would probably make sense to do something like this
directly when drawing lines, since rendering two tris is twice as
expensive as a line, but it would need some changes with state
management.)
Since we're no longer relying on mipmapping to get the alpha value,
we also don't need to draw 3 rects (6 tris), one is sufficient.

There's still issues (as before):
- quite sure it's not correct without half_pixel_center, but can't test
this with GL.
- aaline + line stipple is incorrect (evident with line-width demo).
Looking at the spec the stipple pattern should actually be based on
distance (not just dx or dy for x/y major lines as without aa).
- outputs (other than pos + the one used for line aa) should be
reinterpolated since we actually increase line length by half a pixel
(but there's no tests which would care).
---
 src/gallium/auxiliary/draw/draw_pipe_aaline.c | 532 +++---
 1 file changed, 131 insertions(+), 401 deletions(-)

diff --git a/src/gallium/auxiliary/draw/draw_pipe_aaline.c 
b/src/gallium/auxiliary/draw/draw_pipe_aaline.c
index a859dbc..b490a50 100644
--- a/src/gallium/auxiliary/draw/draw_pipe_aaline.c
+++ b/src/gallium/auxiliary/draw/draw_pipe_aaline.c
@@ -1,6 +1,6 @@
 /**
  *
- * Copyright 2007 VMware, Inc.
+ * Copyright 2007-2018 VMware, Inc.
  * All Rights Reserved.
  *
  * Permission is hereby granted, free of charge, to any person obtaining a
@@ -26,7 +26,7 @@
  **/
 
 /**
- * AA line stage:  AA lines are converted to texture mapped triangles.
+ * AA line stage:  AA lines are converted triangles (with extra generic)
  *
  * Authors:  Brian Paul
  */
@@ -40,7 +40,6 @@
 #include "util/u_format.h"
 #include "util/u_math.h"
 #include "util/u_memory.h"
-#include "util/u_sampler.h"
 
 #include "tgsi/tgsi_transform.h"
 #include "tgsi/tgsi_dump.h"
@@ -55,19 +54,6 @@
 
 
 /**
- * Size for the alpha texture used for antialiasing
- */
-#define TEXTURE_SIZE_LOG2  5   /* 32 x 32 */
-
-/**
- * Max texture level for the alpha texture used for antialiasing
- *
- * Don't use the 1x1 and 2x2 mipmap levels.
- */
-#define MAX_TEXTURE_LEVEL  (TEXTURE_SIZE_LOG2 - 2)
-
-
-/**
  * Subclass of pipe_shader_state to carry extra fragment shader info.
  */
 struct aaline_fragment_shader
@@ -75,8 +61,7 @@ struct aaline_fragment_shader
struct pipe_shader_state state;
void *driver_fs;
void *aaline_fs;
-   uint sampler_unit;
-   int generic_attrib;  /**< texcoord/generic used for texture */
+   int generic_attrib;  /**< generic used for distance */
 };
 
 
@@ -89,26 +74,16 @@ struct aaline_stage
 
float half_line_width;
 
-   /** For AA lines, this is the vertex attrib slot for the new texcoords */
-   uint tex_slot;
+   /** For AA lines, this is the vertex attrib slot for new generic */
+   uint coord_slot;
/** position, not necessarily output zero */
uint pos_slot;
 
-   void *sampler_cso;
-   struct pipe_resource *texture;
-   struct pipe_sampler_view *sampler_view;
-   uint num_samplers;
-   uint num_sampler_views;
-
 
/*
 * Currently bound state
 */
struct aaline_fragment_shader *fs;
-   struct {
-  void *sampler[PIPE_MAX_SAMPLERS];
-  struct pipe_sampler_view *sampler_views[PIPE_MAX_SHADER_SAMPLER_VIEWS];
-   } state;
 
/*
 * Driver interface/override functions
@@ -117,15 +92,6 @@ struct aaline_stage
 const struct pipe_shader_state *);
void (*driver_bind_fs_state)(struct pipe_context *, void *);
void (*driver_delete_fs_state)(struct pipe_context *, void *);
-
-   void (*driver_bind_sampler_states)(struct pipe_context *,
-  enum pipe_shader_type, unsigned,
-  unsigned, void **);
-
-   void (*driver_set_sampler_views)(struct pipe_context *,
-enum pipe_shader_type shader,
-unsigned start, unsigned count,
-struct pipe_sampler_view **);
 };
 
 
@@ -136,41 +102,38 @@ struct aaline_stage
  */
 struct aa_transform_context {

[Mesa-dev] [Bug 104654] r600/sb: Alien Isolation GPU lock

[bugzilla-daemon]

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

Alex Deucher  changed:

   What|Removed |Added

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

-- 
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 08/29] nir/format_convert: Add linear <-> sRGB helpers

[Pohjolainen, Topi]

On Tue, Mar 06, 2018 at 09:53:03AM -0800, Jason Ekstrand wrote:
> On Sat, Mar 3, 2018 at 11:57 PM, Pohjolainen, Topi <
> topi.pohjolai...@gmail.com> wrote:
> 
> > On Fri, Jan 26, 2018 at 05:59:37PM -0800, Jason Ekstrand wrote:
> > > ---
> > >  src/compiler/nir/nir_format_convert.h | 26 ++
> > >  1 file changed, 26 insertions(+)
> >
> > I don't what is the official reference for the formulas and I just took
> > what
> > google gave me first. There was discussion about the cutoff point between
> > linear and curved. I got the impression that what you chose below
> > (open-ended: 0 <= linear < 0.0031308f and 0 <= linear < 0.04045f instead of
> > close-ended) was more "correct". Just thought I check that anyway (that you
> > chose that on purpose).
> >
> 
> I did some digging.  Everyone agrees that it's supposed to be <= 0.04045
> for sRGB -> linear.  For linear -> sRGB, it's a bit more confused.  OpenGL
> 4.5, OpenGL ES 3.2, and the WSI chapter of Vulkan 1.0 all say < 0.0031308
> but the Khronos data format spec, the W3C spec it references, and Wikipedia
> all say <= 0.0031308.  I've sent an e-mail off to Andrew Garrard, the
> author of the data format spec, to see if he can shed some light on it.  In
> any case, no 8-bit UNORM value will ever hit this corner case, so I don't
> think it matters in practice.  In the mean time, I've adjusted the  NIR
> helpers to match the OpenGL [ES] convention for both formulas.

Great, thanks for checking it!

> 
> 
> > Reviewed-by: Topi Pohjolainen 
> >
> > >
> > > diff --git a/src/compiler/nir/nir_format_convert.h
> > b/src/compiler/nir/nir_format_convert.h
> > > index e09c955..07618dc 100644
> > > --- a/src/compiler/nir/nir_format_convert.h
> > > +++ b/src/compiler/nir/nir_format_convert.h
> > > @@ -104,3 +104,29 @@ nir_format_pack_uint(nir_builder *b, nir_ssa_def
> > *color,
> > > return nir_format_pack_uint_unmasked(b, nir_iand(b, color,
> > mask_imm),
> > >  bits, num_components);
> > >  }
> > > +
> > > +static inline nir_ssa_def *
> > > +nir_format_linear_to_srgb(nir_builder *b, nir_ssa_def *c)
> > > +{
> > > +   nir_ssa_def *linear = nir_fmul(b, c, nir_imm_float(b, 12.92f));
> > > +   nir_ssa_def *curved =
> > > +  nir_fsub(b, nir_fmul(b, nir_imm_float(b, 1.055f),
> > > +  nir_fpow(b, c, nir_imm_float(b, 1.0 /
> > 2.4))),
> > > +  nir_imm_float(b, 0.055f));
> > > +
> > > +   return nir_fsat(b, nir_bcsel(b, nir_flt(b, c, nir_imm_float(b,
> > 0.0031308f)),
> > > +   linear, curved));
> > > +}
> > > +
> > > +static inline nir_ssa_def *
> > > +nir_format_srgb_to_linear(nir_builder *b, nir_ssa_def *c)
> > > +{
> > > +   nir_ssa_def *linear = nir_fdiv(b, c, nir_imm_float(b, 12.92f));
> > > +   nir_ssa_def *curved =
> > > +  nir_fpow(b, nir_fdiv(b, nir_fadd(b, c, nir_imm_float(b, 0.055f)),
> > > +  nir_imm_float(b, 1.055f)),
> > > +  nir_imm_float(b, 2.4f));
> > > +
> > > +   return nir_fsat(b, nir_bcsel(b, nir_flt(b, c, nir_imm_float(b,
> > 0.04045f)),
> > > +   linear, curved));
> > > +}
> > > --
> > > 2.5.0.400.gff86faf
> > >
> > > ___
> > > mesa-dev mailing list
> > > mesa-dev@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> >
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 08/29] nir/format_convert: Add linear <-> sRGB helpers

[Jason Ekstrand]

On Sat, Mar 3, 2018 at 11:57 PM, Pohjolainen, Topi <
topi.pohjolai...@gmail.com> wrote:

> On Fri, Jan 26, 2018 at 05:59:37PM -0800, Jason Ekstrand wrote:
> > ---
> >  src/compiler/nir/nir_format_convert.h | 26 ++
> >  1 file changed, 26 insertions(+)
>
> I don't what is the official reference for the formulas and I just took
> what
> google gave me first. There was discussion about the cutoff point between
> linear and curved. I got the impression that what you chose below
> (open-ended: 0 <= linear < 0.0031308f and 0 <= linear < 0.04045f instead of
> close-ended) was more "correct". Just thought I check that anyway (that you
> chose that on purpose).
>

I did some digging.  Everyone agrees that it's supposed to be <= 0.04045
for sRGB -> linear.  For linear -> sRGB, it's a bit more confused.  OpenGL
4.5, OpenGL ES 3.2, and the WSI chapter of Vulkan 1.0 all say < 0.0031308
but the Khronos data format spec, the W3C spec it references, and Wikipedia
all say <= 0.0031308.  I've sent an e-mail off to Andrew Garrard, the
author of the data format spec, to see if he can shed some light on it.  In
any case, no 8-bit UNORM value will ever hit this corner case, so I don't
think it matters in practice.  In the mean time, I've adjusted the  NIR
helpers to match the OpenGL [ES] convention for both formulas.


> Reviewed-by: Topi Pohjolainen 
>
> >
> > diff --git a/src/compiler/nir/nir_format_convert.h
> b/src/compiler/nir/nir_format_convert.h
> > index e09c955..07618dc 100644
> > --- a/src/compiler/nir/nir_format_convert.h
> > +++ b/src/compiler/nir/nir_format_convert.h
> > @@ -104,3 +104,29 @@ nir_format_pack_uint(nir_builder *b, nir_ssa_def
> *color,
> > return nir_format_pack_uint_unmasked(b, nir_iand(b, color,
> mask_imm),
> >  bits, num_components);
> >  }
> > +
> > +static inline nir_ssa_def *
> > +nir_format_linear_to_srgb(nir_builder *b, nir_ssa_def *c)
> > +{
> > +   nir_ssa_def *linear = nir_fmul(b, c, nir_imm_float(b, 12.92f));
> > +   nir_ssa_def *curved =
> > +  nir_fsub(b, nir_fmul(b, nir_imm_float(b, 1.055f),
> > +  nir_fpow(b, c, nir_imm_float(b, 1.0 /
> 2.4))),
> > +  nir_imm_float(b, 0.055f));
> > +
> > +   return nir_fsat(b, nir_bcsel(b, nir_flt(b, c, nir_imm_float(b,
> 0.0031308f)),
> > +   linear, curved));
> > +}
> > +
> > +static inline nir_ssa_def *
> > +nir_format_srgb_to_linear(nir_builder *b, nir_ssa_def *c)
> > +{
> > +   nir_ssa_def *linear = nir_fdiv(b, c, nir_imm_float(b, 12.92f));
> > +   nir_ssa_def *curved =
> > +  nir_fpow(b, nir_fdiv(b, nir_fadd(b, c, nir_imm_float(b, 0.055f)),
> > +  nir_imm_float(b, 1.055f)),
> > +  nir_imm_float(b, 2.4f));
> > +
> > +   return nir_fsat(b, nir_bcsel(b, nir_flt(b, c, nir_imm_float(b,
> 0.04045f)),
> > +   linear, curved));
> > +}
> > --
> > 2.5.0.400.gff86faf
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 20/29] intel/isl/format: Add field locations informations to channel_layout

[Jason Ekstrand]

On Tue, Mar 6, 2018 at 9:46 AM, Pohjolainen, Topi <
topi.pohjolai...@gmail.com> wrote:

> On Tue, Mar 06, 2018 at 09:11:18AM -0800, Jason Ekstrand wrote:
> > On Tue, Mar 6, 2018 at 1:54 AM, Pohjolainen, Topi <
> > topi.pohjolai...@gmail.com> wrote:
> >
> > > On Fri, Jan 26, 2018 at 05:59:49PM -0800, Jason Ekstrand wrote:
> > > >  class Format(object):
> > > > @@ -160,7 +163,14 @@ class Format(object):
> > > >  self.l = Channel(line[9])
> > > >  self.i = Channel(line[10])
> > > >  self.p = Channel(line[11])
> > > > -self.order = line[12]
> > > > +
> > > > +# Set the start bit value for each channel
> > > > +order = line[12].strip()
> > >
> > > You aren't setting "self.order" anymore?
> > >
> >
> > No.  Nothing was using it.  It doesn't really matter to me whether we
> store
> > it in the Format object or not.
>
> So it is not really needed in the previous patch then?
>

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

[Mesa-dev] [Bug 105371] r600_shader_from_tgsi - GPR limit exceeded - shader requires 360 registers

[bugzilla-daemon]

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

Bug ID: 105371
   Summary: r600_shader_from_tgsi - GPR limit exceeded - shader
requires 360 registers
   Product: Mesa
   Version: git
  Hardware: Other
   URL: https://www.shadertoy.com/view/Xs2fWD
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: gw.foss...@gmail.com
QA Contact: mesa-dev@lists.freedesktop.org

The shader fails because it uses an excessive number of arrays and temporary
registers, so that even the spill code that landed recently can't handle it. 

Applying 

 https://patchwork.freedesktop.org/series/37991/ and 
 https://patchwork.freedesktop.org/series/39471/

fixes the bug.

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

Re: [Mesa-dev] [PATCH 20/29] intel/isl/format: Add field locations informations to channel_layout

[Pohjolainen, Topi]

On Tue, Mar 06, 2018 at 09:11:18AM -0800, Jason Ekstrand wrote:
> On Tue, Mar 6, 2018 at 1:54 AM, Pohjolainen, Topi <
> topi.pohjolai...@gmail.com> wrote:
> 
> > On Fri, Jan 26, 2018 at 05:59:49PM -0800, Jason Ekstrand wrote:
> > > ---
> > >  src/intel/isl/gen_format_layout.py | 16 +---
> > >  src/intel/isl/isl.h|  1 +
> > >  2 files changed, 14 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/src/intel/isl/gen_format_layout.py
> > b/src/intel/isl/gen_format_layout.py
> > > index 535f38c..633498b 100644
> > > --- a/src/intel/isl/gen_format_layout.py
> > > +++ b/src/intel/isl/gen_format_layout.py
> > > @@ -76,7 +76,7 @@ isl_format_layouts[] = {
> > >  % for mask in ['r', 'g', 'b', 'a', 'l', 'i', 'p']:
> > ><% channel = getattr(format, mask, None) %>\\
> > >% if channel.type is not None:
> > > -.${mask} = { ISL_${channel.type}, ${channel.size} },
> > > +.${mask} = { ISL_${channel.type}, ${channel.start},
> > ${channel.size} },
> > >% else:
> > >  .${mask} = {},
> > >% endif
> > > @@ -139,7 +139,10 @@ class Channel(object):
> > >  else:
> > >  grouped = self._splitter.match(line)
> > >  self.type = self._types[grouped.group('type')].upper()
> > > -self.size = grouped.group('size')
> > > +self.size = int(grouped.group('size'))
> > > +
> > > +# Default the start big to -1
> >
> >bit
> >
> > > +self.start = -1;
> > >
> > >
> > >  class Format(object):
> > > @@ -160,7 +163,14 @@ class Format(object):
> > >  self.l = Channel(line[9])
> > >  self.i = Channel(line[10])
> > >  self.p = Channel(line[11])
> > > -self.order = line[12]
> > > +
> > > +# Set the start bit value for each channel
> > > +order = line[12].strip()
> >
> > You aren't setting "self.order" anymore?
> >
> 
> No.  Nothing was using it.  It doesn't really matter to me whether we store
> it in the Format object or not.

So it is not really needed in the previous patch then?

> 
> 
> > > +bit = 0
> > > +for c in order:
> > > +chan = getattr(self, c)
> > > +chan.start = bit;
> > > +bit = bit + chan.size
> > >
> > >  # alpha doesn't have a colorspace of it's own.
> > >  self.colorspace = line[13].strip().upper()
> > > diff --git a/src/intel/isl/isl.h b/src/intel/isl/isl.h
> > > index 277998f..04d0f0b 100644
> > > --- a/src/intel/isl/isl.h
> > > +++ b/src/intel/isl/isl.h
> > > @@ -975,6 +975,7 @@ struct isl_extent4d {
> > >
> > >  struct isl_channel_layout {
> > > enum isl_base_type type;
> > > +   uint8_t start_bit; /**< Bit at which this channel starts */
> > > uint8_t bits; /**< Size in bits */
> > >  };
> > >
> > > --
> > > 2.5.0.400.gff86faf
> > >
> > > ___
> > > mesa-dev mailing list
> > > mesa-dev@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> >
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 104654] r600/sb: Alien Isolation GPU lock

[bugzilla-daemon]

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

--- Comment #12 from Gert Wollny  ---
This has been fixed in git as of 
c7cadcbda47537d474eea52b9e77e57ef9287f9b

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

[Mesa-dev] [PATCH] mesa/st/glsl_to_tgsi: Properly resolve life times for simple if/else + use constructs

[Gert Wollny]

In constructs like 

  while (foo)  {
...
if (a) {
   ...
   if (b)
 foo = ...
   else
 foo = ...
   x = foo;
   ...
}
 ...
  }

currently the live range estimation extends the live range of t unnecessarily 
to the whole loop because it was not detected that t is only read in the 
"if (a)" scope that encloses the "if (b)/else" constructs where t is written 
in both branches. 

This patch corrects the minimal live range estimation and adds an according 
unit test for this case.

Signed-off-by: Gert Wollny 
---
 .../state_tracker/st_glsl_to_tgsi_temprename.cpp   | 14 +
 .../tests/test_glsl_to_tgsi_lifetime.cpp   | 23 ++
 2 files changed, 37 insertions(+)

diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi_temprename.cpp 
b/src/mesa/state_tracker/st_glsl_to_tgsi_temprename.cpp
index 6921a643b7..047bd9c7e1 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi_temprename.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi_temprename.cpp
@@ -741,6 +741,20 @@ void temp_comp_access::record_else_write(const prog_scope& 
scope)
  } else {
 current_unpaired_if_write_scope = nullptr;
  }
+ /* Promote the first write scope to the enclosing scope because the
+  * current IF/ELSE pair is now irrelevant for the analysis. This is
+  * needed to obtain the minimum live range for t in constructs like:
+  * {
+  *var t;
+  *if (a)
+  *  t = ...
+  *else
+  *  t = ...
+  *x = t;
+  *...
+  * }
+  */
+ first_write_scope = scope.parent();
 
  /* If some parent is IF/ELSE and in a loop then propagate the
   * write to that scope. Otherwise the write is unconditional
diff --git a/src/mesa/state_tracker/tests/test_glsl_to_tgsi_lifetime.cpp 
b/src/mesa/state_tracker/tests/test_glsl_to_tgsi_lifetime.cpp
index acebfb8293..464e46e44b 100644
--- a/src/mesa/state_tracker/tests/test_glsl_to_tgsi_lifetime.cpp
+++ b/src/mesa/state_tracker/tests/test_glsl_to_tgsi_lifetime.cpp
@@ -794,6 +794,29 @@ TEST_F(LifetimeEvaluatorExactTest, 
WriteInIfElseBranchSecondIfInLoop)
run (code, temp_lt_expect({{-1,-1}, {2,9}}));
 }
 
+/*
+  Test for write in IF and ELSE and read in enclosing IF in loop.
+*/
+
+TEST_F(LifetimeEvaluatorExactTest, DeeplyNestedinLoop)
+{
+   const vector code = {
+  { TGSI_OPCODE_BGNLOOP },
+  {   TGSI_OPCODE_UIF, {}, {in0}, {}},
+  { TGSI_OPCODE_FSEQ, {1}, {in1,in2}, {}},
+  { TGSI_OPCODE_UIF, {}, {1}, {}},
+  {   TGSI_OPCODE_MOV, {2}, {in1}, {}},
+  { TGSI_OPCODE_ELSE },
+  {   TGSI_OPCODE_MOV, {2}, {in2}, {}},
+  { TGSI_OPCODE_ENDIF },
+  { TGSI_OPCODE_MOV, {3}, {2}, {}},
+  {   TGSI_OPCODE_ENDIF },
+  {   TGSI_OPCODE_ADD, {out0}, {3, in1}, {}},
+  { TGSI_OPCODE_ENDLOOP }
+   };
+   run (code, temp_lt_expect({{-1,-1}, {2,3}, {4, 8}, {0,11}}));
+}
+
 /** Regression test for bug #104803,
  *  Read and write in if/else path outside loop and later read in conditional
  *  within a loop. The first write is to be considered the dominant write.
-- 
2.16.1

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

Re: [Mesa-dev] [PATCH 2/5] i965/miptree: Use cpu tiling/detiling when mapping

[Nanley Chery]

On Tue, Mar 06, 2018 at 08:01:47AM -0800, Scott D Phillips wrote:
> Jason Ekstrand  writes:
> 
> > On Mon, Mar 5, 2018 at 11:39 AM, Nanley Chery  wrote:
> >
> >> On Tue, Jan 09, 2018 at 11:16:59PM -0800, Scott D Phillips wrote:
> >> > Rename the (un)map_gtt functions to (un)map_map (map by
> >> > returning a map) and add new functions (un)map_tiled_memcpy that
> >> > return a shadow buffer populated with the intel_tiled_memcpy
> >> > functions.
> >>
> >> Could you mention some of the rationale?
> 
> One is that gtt maps cannot detile the newer Yf and Ys layouts. Not sure
> if Jason or Ken know other reasons. I think we suspected some
> performance difference, but I didn't really see any with well formed
> bulk uploads or downloads.
> 

The first reason is plenty in my opinion.

> >> > ---
> >> >  src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 95
> >> ---
> >> >  1 file changed, 86 insertions(+), 9 deletions(-)
> >> >
> >> > diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> >> b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> >> > index ead0c359c0..7a90dafa1e 100644
> >> > --- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> >> > +++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> >> > @@ -31,6 +31,7 @@
> >> >  #include "intel_image.h"
> >> >  #include "intel_mipmap_tree.h"
> >> >  #include "intel_tex.h"
> >> > +#include "intel_tiled_memcpy.h"
> >> >  #include "intel_blit.h"
> >> >  #include "intel_fbo.h"
> >> >
> >> > @@ -3031,10 +3032,10 @@ intel_miptree_unmap_raw(struct intel_mipmap_tree
> >> *mt)
> >> >  }
> >> >
> >> >  static void
> >> > -intel_miptree_map_gtt(struct brw_context *brw,
> >> > -   struct intel_mipmap_tree *mt,
> >> > -   struct intel_miptree_map *map,
> >> > -   unsigned int level, unsigned int slice)
> >> > +intel_miptree_map_map(struct brw_context *brw,
> >> > +  struct intel_mipmap_tree *mt,
> >> > +  struct intel_miptree_map *map,
> >> > +  unsigned int level, unsigned int slice)
> >> >  {
> >> > unsigned int bw, bh;
> >> > void *base;
> >> > @@ -3052,7 +3053,7 @@ intel_miptree_map_gtt(struct brw_context *brw,
> >> > y /= bh;
> >> > x /= bw;
> >> >
> >> > -   base = intel_miptree_map_raw(brw, mt, map->mode);
> >> > +   base = intel_miptree_map_raw(brw, mt, map->mode | MAP_RAW);
> >> >
> >> > if (base == NULL)
> >> >map->ptr = NULL;
> >> > @@ -3078,11 +3079,80 @@ intel_miptree_map_gtt(struct brw_context *brw,
> >> >  }
> >> >
> >> >  static void
> >> > -intel_miptree_unmap_gtt(struct intel_mipmap_tree *mt)
> >> > +intel_miptree_unmap_map(struct intel_mipmap_tree *mt)
> >> >  {
> >> > intel_miptree_unmap_raw(mt);
> >> >  }
> >> >
> >> > +/* Compute extent parameters for use with tiled_memcpy functions.
> >> > + * xs are in units of bytes and ys are in units of strides. */
> >> > +static inline void
> >> > +tile_extents(struct intel_mipmap_tree *mt, struct intel_miptree_map
> >> *map,
> >> > + unsigned int level, unsigned int slice, unsigned int *x1,
> >> > + unsigned int *x2, unsigned int *y1, unsigned int *y2)
> >>
> >> It would be nice to give these variables units:
> >> x1_B, y1_el, etc.
> 
> Sure, will do
> 
> >> > +{
> >> > +   unsigned int block_width, block_height, block_bytes;
> >> > +   unsigned int x0_el, y0_el;
> >> > +
> >> > +   _mesa_get_format_block_size(mt->format, _width,
> >> _height);
> >> > +   block_bytes = _mesa_get_format_bytes(mt->format);
> >>
> >> block_bytes == mt->cpp (in theory anyways)
> 
> Ok, will change to that
> 
> >> > +
> >> > +   assert(map->x % block_width == 0);
> >> > +   assert(map->y % block_height == 0);
> >> > +
> >> > +   intel_miptree_get_image_offset(mt, level, slice, _el, _el);
> >> > +   *x1 = (map->x / block_width + x0_el) * block_bytes;
> >> > +   *y1 = map->y / block_height + y0_el;
> >> > +   *x2 = *x1 + DIV_ROUND_UP(map->w, block_width) * block_bytes;
> >> > +   *y2 = *y1 + DIV_ROUND_UP(map->h, block_height);
> >> > +}
> >> > +
> >> > +static void
> >> > +intel_miptree_map_tiled_memcpy(struct brw_context *brw,
> >> > +   struct intel_mipmap_tree *mt,
> >> > +   struct intel_miptree_map *map,
> >> > +   unsigned int level, unsigned int slice)
> >> > +{
> >> > +   unsigned int x1, x2, y1, y2;
> >> > +   tile_extents(mt, map, level, slice, , , , );
> >> > +   map->stride = _mesa_format_row_stride(mt->format, map->w);
> >> > +   map->buffer = map->ptr = malloc(map->stride * (y2 - y1));
> >>
> >> Using _mesa_align_malloc should improve memory accesses for our 128bit
> >> formats.
> >>
> >> We should probably also assert(map->ptr) or throw a GL_OUT_OF_MEMORY
> >> error if the alloc fails.
> 
> Good suggestions, will do that
> 
> >> > +
> >> > +   if (!(map->mode & GL_MAP_INVALIDATE_RANGE_BIT)) {
> >> > +  

Re: [Mesa-dev] [PATCH 20/29] intel/isl/format: Add field locations informations to channel_layout

[Jason Ekstrand]

On Tue, Mar 6, 2018 at 1:54 AM, Pohjolainen, Topi <
topi.pohjolai...@gmail.com> wrote:

> On Fri, Jan 26, 2018 at 05:59:49PM -0800, Jason Ekstrand wrote:
> > ---
> >  src/intel/isl/gen_format_layout.py | 16 +---
> >  src/intel/isl/isl.h|  1 +
> >  2 files changed, 14 insertions(+), 3 deletions(-)
> >
> > diff --git a/src/intel/isl/gen_format_layout.py
> b/src/intel/isl/gen_format_layout.py
> > index 535f38c..633498b 100644
> > --- a/src/intel/isl/gen_format_layout.py
> > +++ b/src/intel/isl/gen_format_layout.py
> > @@ -76,7 +76,7 @@ isl_format_layouts[] = {
> >  % for mask in ['r', 'g', 'b', 'a', 'l', 'i', 'p']:
> ><% channel = getattr(format, mask, None) %>\\
> >% if channel.type is not None:
> > -.${mask} = { ISL_${channel.type}, ${channel.size} },
> > +.${mask} = { ISL_${channel.type}, ${channel.start},
> ${channel.size} },
> >% else:
> >  .${mask} = {},
> >% endif
> > @@ -139,7 +139,10 @@ class Channel(object):
> >  else:
> >  grouped = self._splitter.match(line)
> >  self.type = self._types[grouped.group('type')].upper()
> > -self.size = grouped.group('size')
> > +self.size = int(grouped.group('size'))
> > +
> > +# Default the start big to -1
>
>bit
>
> > +self.start = -1;
> >
> >
> >  class Format(object):
> > @@ -160,7 +163,14 @@ class Format(object):
> >  self.l = Channel(line[9])
> >  self.i = Channel(line[10])
> >  self.p = Channel(line[11])
> > -self.order = line[12]
> > +
> > +# Set the start bit value for each channel
> > +order = line[12].strip()
>
> You aren't setting "self.order" anymore?
>

No.  Nothing was using it.  It doesn't really matter to me whether we store
it in the Format object or not.


> > +bit = 0
> > +for c in order:
> > +chan = getattr(self, c)
> > +chan.start = bit;
> > +bit = bit + chan.size
> >
> >  # alpha doesn't have a colorspace of it's own.
> >  self.colorspace = line[13].strip().upper()
> > diff --git a/src/intel/isl/isl.h b/src/intel/isl/isl.h
> > index 277998f..04d0f0b 100644
> > --- a/src/intel/isl/isl.h
> > +++ b/src/intel/isl/isl.h
> > @@ -975,6 +975,7 @@ struct isl_extent4d {
> >
> >  struct isl_channel_layout {
> > enum isl_base_type type;
> > +   uint8_t start_bit; /**< Bit at which this channel starts */
> > uint8_t bits; /**< Size in bits */
> >  };
> >
> > --
> > 2.5.0.400.gff86faf
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 22/29] intel/isl: Add format conversion code

[Jason Ekstrand]

On Tue, Mar 6, 2018 at 5:06 AM, Pohjolainen, Topi <
topi.pohjolai...@gmail.com> wrote:

> On Fri, Jan 26, 2018 at 05:59:51PM -0800, Jason Ekstrand wrote:
> > This adds helpers to ISL to convert an isl_color_value to and from
> > binary data encoded with a given isl_format.  The conversion is done
> > using ISL's built-in format introspection so it's fairly slow as format
> > conversions go but it should be fine for a single pixel value.  In
> > particular, we can use this to convert clear colors.
> >
> > As a side-effect, we now rely on the sRGB helpers in libmesautil so we
> > need to tweak the build system a bit.  All prior uses of src/util in ISL
> > were header-only.
> > ---
> >  src/intel/Makefile.compiler.am |   2 +-
> >  src/intel/Makefile.isl.am  |   1 +
> >  src/intel/isl/isl.h|   7 ++
> >  src/intel/isl/isl_format.c | 214 ++
> +++
> >  src/intel/isl/meson.build  |   2 +-
> >  5 files changed, 224 insertions(+), 2 deletions(-)
> >
> > diff --git a/src/intel/Makefile.compiler.am b/src/intel/
> Makefile.compiler.am
> > index 45e7a6c..d5b9920 100644
> > --- a/src/intel/Makefile.compiler.am
> > +++ b/src/intel/Makefile.compiler.am
> > @@ -49,8 +49,8 @@ TEST_LIBS = \
> >   compiler/libintel_compiler.la \
> >   common/libintel_common.la \
> >   $(top_builddir)/src/compiler/nir/libnir.la \
> > - $(top_builddir)/src/util/libmesautil.la \
> >   $(top_builddir)/src/intel/isl/libisl.la \
> > + $(top_builddir)/src/util/libmesautil.la \
> >   $(PTHREAD_LIBS) \
> >   $(DLOPEN_LIBS)
> >
> > diff --git a/src/intel/Makefile.isl.am b/src/intel/Makefile.isl.am
> > index 31273af..8e2cf20 100644
> > --- a/src/intel/Makefile.isl.am
> > +++ b/src/intel/Makefile.isl.am
> > @@ -78,6 +78,7 @@ TESTS += $(check_PROGRAMS)
> >  isl_tests_isl_surf_get_image_offset_test_LDADD = \
> >   common/libintel_common.la \
> >   isl/libisl.la \
> > + $(top_builddir)/src/util/libmesautil.la \
> >   -lm
> >
> >  # 
> 
> > diff --git a/src/intel/isl/isl.h b/src/intel/isl/isl.h
> > index 04d0f0b..4806c0c 100644
> > --- a/src/intel/isl/isl.h
> > +++ b/src/intel/isl/isl.h
> > @@ -1535,6 +1535,13 @@ enum isl_format isl_format_rgb_to_rgba(enum
> isl_format rgb) ATTRIBUTE_CONST;
> >  enum isl_format isl_format_rgb_to_rgbx(enum isl_format rgb)
> ATTRIBUTE_CONST;
> >  enum isl_format isl_format_rgbx_to_rgba(enum isl_format rgb)
> ATTRIBUTE_CONST;
> >
> > +void isl_color_value_pack(const union isl_color_value *value,
> > +  enum isl_format format,
> > +  uint32_t *data_out);
> > +void isl_color_value_unpack(union isl_color_value *value,
> > +enum isl_format format,
> > +const uint32_t *data_in);
> > +
> >  bool isl_is_storage_image_format(enum isl_format fmt);
> >
> >  enum isl_format
> > diff --git a/src/intel/isl/isl_format.c b/src/intel/isl/isl_format.c
> > index 46af175..793c84b 100644
> > --- a/src/intel/isl/isl_format.c
> > +++ b/src/intel/isl/isl_format.c
> > @@ -24,8 +24,17 @@
> >  #include 
> >
> >  #include "isl.h"
> > +#include "isl_priv.h"
> >  #include "common/gen_device_info.h"
> >
> > +#include "main/macros.h" /* Needed for MAX3 and MAX2 for format_rgb9e5
> */
> > +#include "util/format_srgb.h"
> > +#include "util/format_rgb9e5.h"
> > +#include "util/format_r11g11b10f.h"
> > +
> > +/* Header-only format conversion include */
> > +#include "main/format_utils.h"
> > +
> >  struct surface_format_info {
> > bool exists;
> > uint8_t sampling;
> > @@ -806,3 +815,208 @@ isl_format_rgbx_to_rgba(enum isl_format rgbx)
> >return rgbx;
> > }
> >  }
> > +
> > +static inline void
> > +pack_channel(const union isl_color_value *value, unsigned i,
> > + const struct isl_channel_layout *layout,
> > + enum isl_colorspace colorspace,
> > + uint32_t data_out[4])
> > +{
> > +   if (layout->type == ISL_VOID)
> > +  return;
> > +
> > +   if (colorspace == ISL_COLORSPACE_SRGB)
> > +  assert(layout->type == ISL_UNORM);
> > +
> > +   uint32_t packed;
> > +   switch (layout->type) {
> > +   case ISL_UNORM:
> > +  if (colorspace == ISL_COLORSPACE_SRGB) {
> > + if (layout->bits == 8) {
> > +packed = util_format_linear_float_to_
> srgb_8unorm(value->f32[i]);
> > + } else {
> > +float srgb = util_format_linear_to_srgb_
> float(value->f32[i]);
> > +packed = _mesa_float_to_unorm(srgb, layout->bits);
> > + }
> > +  } else {
> > + packed = _mesa_float_to_unorm(value->f32[i], layout->bits);
> > +  }
> > +  break;
> > +   case ISL_SNORM:
> > +  packed = _mesa_float_to_snorm(value->f32[i], layout->bits);
> > +  break;
> > +   case ISL_SFLOAT:
> > +  assert(layout->bits == 16 || layout->bits == 32);
> > +  if (layout->bits == 16) 

Re: [Mesa-dev] [PATCH 2/3] i965/extensions: Enable ASTC HDR on CannonLake

[Nanley Chery]

On Tue, Mar 06, 2018 at 12:20:58AM -0800, Kenneth Graunke wrote:
> On Monday, March 5, 2018 2:07:54 PM PST Nanley Chery wrote:
> > Cc: Rafael Antognolli 
> > ---
> >  src/mesa/drivers/dri/i965/intel_extensions.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/src/mesa/drivers/dri/i965/intel_extensions.c 
> > b/src/mesa/drivers/dri/i965/intel_extensions.c
> > index 73a6c73f537..c451f6cf749 100644
> > --- a/src/mesa/drivers/dri/i965/intel_extensions.c
> > +++ b/src/mesa/drivers/dri/i965/intel_extensions.c
> > @@ -297,7 +297,7 @@ intelInitExtensions(struct gl_context *ctx)
> >ctx->Extensions.ARB_post_depth_coverage = true;
> > }
> >  
> > -   if (gen_device_info_is_9lp(devinfo))
> > +   if (devinfo->gen == 10 || gen_device_info_is_9lp(devinfo))
> >ctx->Extensions.KHR_texture_compression_astc_hdr = true;
> >  
> > if (devinfo->gen >= 6)
> > 
> 
> What about Icelake?  Shouldn't this be gen >= 10 || gen9lp?

There's a lot of churn with this feature unfortunately. As far as I can
tell, this isn't available on IceLake. If you follow the link trail
(below) in the BSpec, you'll come a cross a note and some links
explaining the situation.

Memory Data Formats » Common Surface Formats »
Compressed Surface Formats » Adaptive Scalable Texture Compression (ASTC) [CHV,
SKL+] » ASTC Fundamentals CHV, SKL+ » Background [CHV, SKL+]

-Nanley

> 
> --Ken


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

Re: [Mesa-dev] [PATCH 4/4] glxinfo/wglinfo: improve GL_ARB_imaging query code

[Roland Scheidegger]

Am 06.03.2018 um 17:10 schrieb Emil Velikov:
> On 5 March 2018 at 16:53, Brian Paul  wrote:
>> Print GL_MAX_CONVOLUTION_WIDTH, HEIGHT on separate lines.
>> Print GL_MAX_COLOR_MATRIX_STACK_DEPTH in same section.
>> ---
>>  src/xdemos/glinfo_common.c | 13 -
>>  1 file changed, 8 insertions(+), 5 deletions(-)
>>
>> diff --git a/src/xdemos/glinfo_common.c b/src/xdemos/glinfo_common.c
>> index f84d1a4..508fce1 100644
>> --- a/src/xdemos/glinfo_common.c
>> +++ b/src/xdemos/glinfo_common.c
>> @@ -464,7 +464,6 @@ print_limits(const char *extensions, const char 
>> *oglstring, int version,
>>{ 1, GL_MAX_ATTRIB_STACK_DEPTH, "GL_MAX_ATTRIB_STACK_DEPTH", NULL },
>>{ 1, GL_MAX_CLIENT_ATTRIB_STACK_DEPTH, 
>> "GL_MAX_CLIENT_ATTRIB_STACK_DEPTH", NULL },
>>{ 1, GL_MAX_CLIP_PLANES, "GL_MAX_CLIP_PLANES", NULL },
>> -  { 1, GL_MAX_COLOR_MATRIX_STACK_DEPTH, 
>> "GL_MAX_COLOR_MATRIX_STACK_DEPTH", "GL_ARB_imaging" },
>>{ 1, GL_MAX_ELEMENTS_VERTICES, "GL_MAX_ELEMENTS_VERTICES", NULL },
>>{ 1, GL_MAX_ELEMENTS_INDICES, "GL_MAX_ELEMENTS_INDICES", NULL },
>>{ 1, GL_MAX_EVAL_ORDER, "GL_MAX_EVAL_ORDER", NULL },
>> @@ -716,12 +715,16 @@ print_limits(const char *extensions, const char 
>> *oglstring, int version,
>>
>> /* these don't fit into the above mechanism, unfortunately */
>> if (extension_supported("GL_ARB_imaging", extensions)) {
>> +  GLint d;
>> +  printf("  GL_ARB_imaging:\n");
> 
> With the small suggestions, the series is
> Reviewed-by: Emil Velikov 
> 
> Aside:
> Mesa is not exposing the extension, even though it seems implemented.
> A dummy_true entry in src/mesa/main/extensions_table.h should be all
> that's needed.
> 

Nope, it's unimplemented. It's a bit of a special case I suppose because
you can't remove the entry points. Lots of strange bits in that
extension (of course mesa kept the additional blend stuff which
initially also was part of it).
This was the discussion:
https://lists.freedesktop.org/archives/mesa-dev/2010-September/003110.html
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/4] glxinfo/wglinfo: print (110) instead of empty line

[Brian Paul]

On 03/06/2018 09:08 AM, Emil Velikov wrote:

On 5 March 2018 at 16:53, Brian Paul  wrote:

The GL_SHADING_LANGUAGE_VERSION query returns an empty string for
GLSL 1.10.  Instead of printing an empty line, print (110).

Bugzilla: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.freedesktop.org_show-5Fbug.cgi-3Fid-3D105285=DwIBaQ=uilaK90D4TOVoH58JNXRgQ=Ie7_encNUsqxbSRbqbNgofw0ITcfE8JKfaUjIQhncGA=SeMJ7Rmpro7NP7xkPthj8oIWoE7QH6szrRoKqHZAvMU=pMGOSB57UdZ8ZCyUWc76s_qXA45ehYIcptpcgMy5m00=
---
  src/xdemos/glinfo_common.c | 11 +--
  1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/src/xdemos/glinfo_common.c b/src/xdemos/glinfo_common.c
index 57dccc8..f84d1a4 100644
--- a/src/xdemos/glinfo_common.c
+++ b/src/xdemos/glinfo_common.c
@@ -745,8 +745,15 @@ print_limits(const char *extensions, const char 
*oglstring, int version,
glGetIntegerv(GL_NUM_SHADING_LANGUAGE_VERSIONS, );
printf("GL_NUM_SHADING_LANGUAGE_VERSIONS = %d\n", n);
for (i = 0; i < n; i++) {
- printf("  %s\n", (const char *)
-extfuncs->GetStringi(GL_SHADING_LANGUAGE_VERSION, i));
+ const char *lang = (const char *)
+extfuncs->GetStringi(GL_SHADING_LANGUAGE_VERSION, i);
+ if (lang[0] == 0) {
+/* The empty string is really GLSL 1.10.  Instead of
+ * printing an empty line, print (110).
+ */
+lang = "(110)";
+ }

 From a quick search I cannot spot where the spec says the above.


OpenGL 4.3 compatibility spec, page 628, middle of page: "An empty 
string indicates support for OpenGL Shading Language 1.10, which did not 
include the #version compiler directive."



Yet again, the wiki says some contradicting things (wrt 1.00) relative
to the spec.

Namely:
"if an implementation exposes support for GLSL 1.00 (through
ARB_shading_language_100), then it will return an empty string ("")."
[1]

I'd add a some note/xxx about the extension and merge the patch.


Will do.

Thanks for reviewing.

-Brian



-Emil

[1] 
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.khronos.org_opengl_wiki_GLAPI_glGetString=DwIBaQ=uilaK90D4TOVoH58JNXRgQ=Ie7_encNUsqxbSRbqbNgofw0ITcfE8JKfaUjIQhncGA=SeMJ7Rmpro7NP7xkPthj8oIWoE7QH6szrRoKqHZAvMU=VIepdF3DvKvPbxlpSleDeVxe3UFKjaoSbNWCpEGkcPQ=
[2] 
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.khronos.org_registry_OpenGL_extensions_ARB_ARB-5Fshading-5Flanguage-5F100.txt=DwIBaQ=uilaK90D4TOVoH58JNXRgQ=Ie7_encNUsqxbSRbqbNgofw0ITcfE8JKfaUjIQhncGA=SeMJ7Rmpro7NP7xkPthj8oIWoE7QH6szrRoKqHZAvMU=E_AwFrxPF9kExRDgdYWNu4ItDhBcFTbb4Yy0xdsXuYg=



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

Re: [Mesa-dev] [PATCH 4/4] glxinfo/wglinfo: improve GL_ARB_imaging query code

[Emil Velikov]

On 6 March 2018 at 16:10, Emil Velikov  wrote:

> Mesa is not exposing the extension, even though it seems implemented.
> A dummy_true entry in src/mesa/main/extensions_table.h should be all
> that's needed.
>
Actually it seems like it was removed with commit
907a6734fcd427a6ac6fe5fcfbeac5d6054d82ae
There's no explicit ack/r-b on the patch but I'd assume others were on
board with it.

Regardless, the topic is orthogonal to the glxinfo/wglinfo fixes ;-)
-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 4/4] glxinfo/wglinfo: improve GL_ARB_imaging query code

[Emil Velikov]

On 5 March 2018 at 16:53, Brian Paul  wrote:
> Print GL_MAX_CONVOLUTION_WIDTH, HEIGHT on separate lines.
> Print GL_MAX_COLOR_MATRIX_STACK_DEPTH in same section.
> ---
>  src/xdemos/glinfo_common.c | 13 -
>  1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/src/xdemos/glinfo_common.c b/src/xdemos/glinfo_common.c
> index f84d1a4..508fce1 100644
> --- a/src/xdemos/glinfo_common.c
> +++ b/src/xdemos/glinfo_common.c
> @@ -464,7 +464,6 @@ print_limits(const char *extensions, const char 
> *oglstring, int version,
>{ 1, GL_MAX_ATTRIB_STACK_DEPTH, "GL_MAX_ATTRIB_STACK_DEPTH", NULL },
>{ 1, GL_MAX_CLIENT_ATTRIB_STACK_DEPTH, 
> "GL_MAX_CLIENT_ATTRIB_STACK_DEPTH", NULL },
>{ 1, GL_MAX_CLIP_PLANES, "GL_MAX_CLIP_PLANES", NULL },
> -  { 1, GL_MAX_COLOR_MATRIX_STACK_DEPTH, 
> "GL_MAX_COLOR_MATRIX_STACK_DEPTH", "GL_ARB_imaging" },
>{ 1, GL_MAX_ELEMENTS_VERTICES, "GL_MAX_ELEMENTS_VERTICES", NULL },
>{ 1, GL_MAX_ELEMENTS_INDICES, "GL_MAX_ELEMENTS_INDICES", NULL },
>{ 1, GL_MAX_EVAL_ORDER, "GL_MAX_EVAL_ORDER", NULL },
> @@ -716,12 +715,16 @@ print_limits(const char *extensions, const char 
> *oglstring, int version,
>
> /* these don't fit into the above mechanism, unfortunately */
> if (extension_supported("GL_ARB_imaging", extensions)) {
> +  GLint d;
> +  printf("  GL_ARB_imaging:\n");

With the small suggestions, the series is
Reviewed-by: Emil Velikov 

Aside:
Mesa is not exposing the extension, even though it seems implemented.
A dummy_true entry in src/mesa/main/extensions_table.h should be all
that's needed.

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

[Mesa-dev] [PATCH] ac/nir: do not emit unnecessary null exports in fragment shaders

[Samuel Pitoiset]

Null exports should only be needed when no other exports are
emitted. This removes a bunch of 'exp null off, off, off, off done vm'.

Affected games are Dota 2 and Wolfenstein 2, not sure if that
really helps, but code size is decreasing there.

Polaris10:
Totals from affected shaders:
SGPRS: 8216 -> 8216 (0.00 %)
VGPRS: 7072 -> 7072 (0.00 %)
Spilled SGPRs: 0 -> 0 (0.00 %)
Spilled VGPRs: 0 -> 0 (0.00 %)
Code Size: 454968 -> 453896 (-0.24 %) bytes
Max Waves: 772 -> 772 (0.00 %)

Signed-off-by: Samuel Pitoiset 
---
 src/amd/common/ac_nir_to_llvm.c | 98 ++---
 1 file changed, 52 insertions(+), 46 deletions(-)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index ea51c3a54a..c370c80ec7 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -6484,67 +6484,73 @@ handle_tcs_outputs_post(struct radv_shader_context *ctx)
write_tess_factors(ctx);
 }
 
-static bool
-si_export_mrt_color(struct radv_shader_context *ctx,
-   LLVMValueRef *color, unsigned index, bool is_last,
-   struct ac_export_args *args)
-{
-   /* Export */
-   si_llvm_init_export_args(ctx, color, 0xf,
-V_008DFC_SQ_EXP_MRT + index, args);
-
-   if (is_last) {
-   args->valid_mask = 1; /* whether the EXEC mask is valid */
-   args->done = 1; /* DONE bit */
-   } else if (!args->enabled_channels)
-   return false; /* unnecessary NULL export */
-
-   return true;
-}
+struct radv_ps_exports {
+   unsigned num;
+   struct ac_export_args args[10];
+};
 
 static void
 radv_export_mrt_z(struct radv_shader_context *ctx,
  LLVMValueRef depth, LLVMValueRef stencil,
- LLVMValueRef samplemask)
+ LLVMValueRef samplemask, struct radv_ps_exports *exp)
 {
struct ac_export_args args;
 
ac_export_mrt_z(>ac, depth, stencil, samplemask, );
 
-   ac_build_export(>ac, );
+   memcpy(>args[exp->num++], , sizeof(args));
 }
 
 static void
 handle_fs_outputs_post(struct radv_shader_context *ctx)
 {
-   unsigned index = 0;
LLVMValueRef depth = NULL, stencil = NULL, samplemask = NULL;
-   struct ac_export_args color_args[8];
+   struct radv_ps_exports exp = {};
+   struct ac_export_args args[8];
+   int last_color_export = -1;
+   int last_non_null = -1;
+   unsigned colors_written;
+
+   /* Find the last written color export. */
+   colors_written = ctx->output_mask >> FRAG_RESULT_DATA0;
+   if (!ctx->shader_info->info.ps.writes_z &&
+   !ctx->shader_info->info.ps.writes_stencil &&
+   !ctx->shader_info->info.ps.writes_sample_mask) {
+   last_color_export = util_last_bit(colors_written) - 1;
+   }
+
+   /* Get the export arguments, and find the last non-null color export. */
+   for (unsigned mrt = 0; mrt < 8; mrt++) {
+   unsigned index = mrt + FRAG_RESULT_DATA0;
+   LLVMValueRef color[4];
+
+   if (!(colors_written & (1 << mrt)))
+   continue;
 
-   for (unsigned i = 0; i < AC_LLVM_MAX_OUTPUTS; ++i) {
-   LLVMValueRef values[4];
-   bool last = false;
+   for (unsigned chan = 0; chan < 4; chan++) {
+   color[chan] =
+   ac_to_float(>ac,
+   radv_load_output(ctx, index, chan));
+   }
 
-   if (!(ctx->output_mask & (1ull << i)))
-   continue;
+   si_llvm_init_export_args(ctx, color, 0xf,
+V_008DFC_SQ_EXP_MRT + mrt, [mrt]);
+   if (args[mrt].enabled_channels)
+   last_non_null = mrt;
+   }
 
-   if (i < FRAG_RESULT_DATA0)
+   /* Emit all exports. */
+   for (unsigned mrt = 0; mrt < 8; mrt++) {
+   if (!(colors_written & (1 << mrt)))
continue;
 
-   for (unsigned j = 0; j < 4; j++)
-   values[j] = ac_to_float(>ac,
-   radv_load_output(ctx, i, j));
+   if (last_color_export != -1 && last_non_null == mrt) {
+   args[mrt].valid_mask = 1; /* whether the EXEC mask is 
valid */
+   args[mrt].done = 1; /* DONE bit */
+   } else if (!args[mrt].enabled_channels)
+   continue; /* unnecessary NULL export */
 
-   if (!ctx->shader_info->info.ps.writes_z &&
-   !ctx->shader_info->info.ps.writes_stencil &&
-   !ctx->shader_info->info.ps.writes_sample_mask)
-   last = ctx->output_mask <= ((1ull << (i + 1)) - 1);
-
-   bool ret = si_export_mrt_color(ctx, values,
-   

Re: [Mesa-dev] [PATCH 1/4] glxinfo/wglinfo: remove print_shader_limits() code

[Emil Velikov]

On 5 March 2018 at 16:53, Brian Paul  wrote:
> And add queries of GL 2.0 limits.  All the VS, FS, GS limits which were
> reported with print_shader_limits() are also covered by the GL 2.0 and
> 3.2 queries.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105285
> ---
>  src/xdemos/glinfo_common.c | 89 
> ++
>  1 file changed, 11 insertions(+), 78 deletions(-)
>
> diff --git a/src/xdemos/glinfo_common.c b/src/xdemos/glinfo_common.c
> index 3668026..7ffbeac 100644
> --- a/src/xdemos/glinfo_common.c
> +++ b/src/xdemos/glinfo_common.c
> @@ -378,74 +378,6 @@ struct token_name
>  };
>
>
> -static void
> -print_shader_limit_list(const struct token_name *lim)
> -{
> -   GLint max[1];
> -   unsigned i;
> -
> -   for (i = 0; lim[i].token; i++) {
> -  glGetIntegerv(lim[i].token, max);
> -  if (glGetError() == GL_NO_ERROR) {
> -printf("%s = %d\n", lim[i].name, max[0]);
> -  }
> -   }
> -}
> -
> -
> -/**
> - * Print interesting limits for vertex/fragment shaders.
> - */
> -static void
> -print_shader_limits(GLenum target)
> -{
> -   static const struct token_name vertex_limits[] = {
> -  { GL_MAX_VERTEX_UNIFORM_COMPONENTS_ARB, 
> "GL_MAX_VERTEX_UNIFORM_COMPONENTS_ARB" },
> -  { GL_MAX_VARYING_FLOATS_ARB, "GL_MAX_VARYING_FLOATS_ARB" },
> -  { GL_MAX_VERTEX_ATTRIBS_ARB, "GL_MAX_VERTEX_ATTRIBS_ARB" },
> -  { GL_MAX_TEXTURE_IMAGE_UNITS_ARB, "GL_MAX_TEXTURE_IMAGE_UNITS_ARB" },
> -  { GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS_ARB, 
> "GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS_ARB" },
> -  { GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS_ARB, 
> "GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS_ARB" },
> -  { GL_MAX_TEXTURE_COORDS_ARB, "GL_MAX_TEXTURE_COORDS_ARB" },
> -  { GL_MAX_VERTEX_OUTPUT_COMPONENTS  , "GL_MAX_VERTEX_OUTPUT_COMPONENTS  
> " },
> -  { (GLenum) 0, NULL }
> -   };
> -   static const struct token_name fragment_limits[] = {
> -  { GL_MAX_FRAGMENT_UNIFORM_COMPONENTS_ARB, 
> "GL_MAX_FRAGMENT_UNIFORM_COMPONENTS_ARB" },
> -  { GL_MAX_TEXTURE_COORDS_ARB, "GL_MAX_TEXTURE_COORDS_ARB" },
> -  { GL_MAX_TEXTURE_IMAGE_UNITS_ARB, "GL_MAX_TEXTURE_IMAGE_UNITS_ARB" },
> -  { GL_MAX_FRAGMENT_INPUT_COMPONENTS , "GL_MAX_FRAGMENT_INPUT_COMPONENTS 
> " },
> -  { (GLenum) 0, NULL }
> -   };
> -   static const struct token_name geometry_limits[] = {
> -  { GL_MAX_GEOMETRY_UNIFORM_COMPONENTS, 
> "GL_MAX_GEOMETRY_UNIFORM_COMPONENTS" },
> -  { GL_MAX_GEOMETRY_TEXTURE_IMAGE_UNITS, 
> "GL_MAX_GEOMETRY_TEXTURE_IMAGE_UNITS" },
> -  { GL_MAX_GEOMETRY_OUTPUT_VERTICES  , "GL_MAX_GEOMETRY_OUTPUT_VERTICES  
> " },
> -  { GL_MAX_GEOMETRY_TOTAL_OUTPUT_COMPONENTS, 
> "GL_MAX_GEOMETRY_TOTAL_OUTPUT_COMPONENTS" },
> -  { GL_MAX_GEOMETRY_INPUT_COMPONENTS , "GL_MAX_GEOMETRY_INPUT_COMPONENTS 
> " },
> -  { GL_MAX_GEOMETRY_OUTPUT_COMPONENTS, 
> "GL_MAX_GEOMETRY_OUTPUT_COMPONENTS" },
> -  { (GLenum) 0, NULL }
> -   };
> -
> -   switch (target) {
> -   case GL_VERTEX_SHADER:
> -  printf("GL_VERTEX_SHADER_ARB:\n");
> -  print_shader_limit_list(vertex_limits);
> -  break;
> -
> -   case GL_FRAGMENT_SHADER:
> -  printf("GL_FRAGMENT_SHADER_ARB:\n");
> -  print_shader_limit_list(fragment_limits);
> -  break;
> -
> -   case GL_GEOMETRY_SHADER:
> -  printf("GL_GEOMETRY_SHADER:\n");
> -  print_shader_limit_list(geometry_limits);
> -  break;
> -   }
> -}
> -
> -
>  /**
>   * Print interesting limits for vertex/fragment programs.
>   */
> @@ -627,7 +559,17 @@ print_limits(const char *extensions, const char 
> *oglstring, int version,
>{ 1, GL_MAX_TESS_EVALUATION_OUTPUT_COMPONENTS, 
> "GL_MAX_TESS_EVALUATION_OUTPUT_COMPONENTS", "GL_ARB_tessellation_shader" },
>{ 1, GL_MAX_COMBINED_TESS_EVALUATION_UNIFORM_COMPONENTS, 
> "GL_MAX_COMBINED_TESS_EVALUATION_UNIFORM_COMPONENTS", 
> "GL_ARB_tessellation_shader" },
>  #endif
> -
> +#if defined(GL_VERSION_2_0)
Normally we'd want this and other similar guards removed, with local
fall-back definitions when applicable.
As-is the old build server will produce glxinfo w/o support for
feature X and at runtime user will not see X even when the driver
supports it.

Not an actual issue with these, so meh ;-)
-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/4] glxinfo/wglinfo: print (110) instead of empty line

[Emil Velikov]

On 5 March 2018 at 16:53, Brian Paul  wrote:
> The GL_SHADING_LANGUAGE_VERSION query returns an empty string for
> GLSL 1.10.  Instead of printing an empty line, print (110).
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105285
> ---
>  src/xdemos/glinfo_common.c | 11 +--
>  1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/src/xdemos/glinfo_common.c b/src/xdemos/glinfo_common.c
> index 57dccc8..f84d1a4 100644
> --- a/src/xdemos/glinfo_common.c
> +++ b/src/xdemos/glinfo_common.c
> @@ -745,8 +745,15 @@ print_limits(const char *extensions, const char 
> *oglstring, int version,
>glGetIntegerv(GL_NUM_SHADING_LANGUAGE_VERSIONS, );
>printf("GL_NUM_SHADING_LANGUAGE_VERSIONS = %d\n", n);
>for (i = 0; i < n; i++) {
> - printf("  %s\n", (const char *)
> -extfuncs->GetStringi(GL_SHADING_LANGUAGE_VERSION, i));
> + const char *lang = (const char *)
> +extfuncs->GetStringi(GL_SHADING_LANGUAGE_VERSION, i);
> + if (lang[0] == 0) {
> +/* The empty string is really GLSL 1.10.  Instead of
> + * printing an empty line, print (110).
> + */
> +lang = "(110)";
> + }
From a quick search I cannot spot where the spec says the above.
Yet again, the wiki says some contradicting things (wrt 1.00) relative
to the spec.

Namely:
"if an implementation exposes support for GLSL 1.00 (through
ARB_shading_language_100), then it will return an empty string ("")."
[1]

I'd add a some note/xxx about the extension and merge the patch.

-Emil

[1] https://www.khronos.org/opengl/wiki/GLAPI/glGetString
[2] 
https://www.khronos.org/registry/OpenGL/extensions/ARB/ARB_shading_language_100.txt
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v3 7/7] i965: ASTC5x5 workaround logic for blorp

[Jason Ekstrand]

On Tue, Feb 27, 2018 at 1:30 AM,  wrote:

> From: Kevin Rogovin 
>
> Signed-off-by: Kevin Rogovin 
> ---
>  src/mesa/drivers/dri/i965/genX_blorp_exec.c |  5 +
>  src/mesa/drivers/dri/i965/intel_tex_image.c | 16 
>  2 files changed, 17 insertions(+), 4 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/genX_blorp_exec.c
> b/src/mesa/drivers/dri/i965/genX_blorp_exec.c
> index 062171a..b7c35e9 100644
> --- a/src/mesa/drivers/dri/i965/genX_blorp_exec.c
> +++ b/src/mesa/drivers/dri/i965/genX_blorp_exec.c
> @@ -230,6 +230,11 @@ genX(blorp_exec)(struct blorp_batch *batch,
> struct gl_context *ctx = >ctx;
> bool check_aperture_failed_once = false;
>
> +   if (brw->astc5x5_wa.blorp_sampling_from_astc5x5) {
> +  gen9_set_astc5x5_wa_mode(brw, BRW_ASTC5x5_WA_MODE_HAS_ASTC5x5);
> +   } else {
> +  gen9_set_astc5x5_wa_mode(brw, BRW_ASTC5x5_WA_MODE_HAS_AUX);
> +   }
> /* Flush the sampler and render caches.  We definitely need to flush
> the
>  * sampler cache so that we get updated contents from the render cache
> for
>  * the glBlitFramebuffer() source.  Also, we are sometimes warned in
> the
> diff --git a/src/mesa/drivers/dri/i965/intel_tex_image.c
> b/src/mesa/drivers/dri/i965/intel_tex_image.c
> index e25bc9a..38967fb 100644
> --- a/src/mesa/drivers/dri/i965/intel_tex_image.c
> +++ b/src/mesa/drivers/dri/i965/intel_tex_image.c
> @@ -824,10 +824,18 @@ intel_get_tex_sub_image(struct gl_context *ctx,
> DBG("%s\n", __func__);
>
> if (_mesa_is_bufferobj(ctx->Pack.BufferObj)) {
> -  if (intel_gettexsubimage_blorp(brw, texImage,
> - xoffset, yoffset, zoffset,
> - width, height, depth, format, type,
> - pixels, >Pack))
> +  bool blorp_success;
> +
> +  brw->astc5x5_wa.blorp_sampling_from_astc5x5 =
> + (texImage->TexFormat == MESA_FORMAT_RGBA_ASTC_5x5 ||
> +  texImage->TexFormat == MESA_FORMAT_SRGB8_ALPHA8_ASTC_5x5);
> +  blorp_success = intel_gettexsubimage_blorp(brw, texImage,
> + xoffset, yoffset,
> zoffset,
> + width, height, depth,
> + format, type, pixels,
> + >Pack);
> +  brw->astc5x5_wa.blorp_sampling_from_astc5x5 = false;
> +  if (blorp_success)
>

Let's keep all of the code for detecting whether or not BLORP needs and
implementing it together in BLORP.  We can just as easily detect ASTC5x5
there as here.


>   return;
>
>perf_debug("%s: fallback to CPU mapping in PBO case\n", __func__);
> --
> 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] [PATCH v3 4/7] i965: prevent using auxilary buffers when an astc5x5 texture is present

[Jason Ekstrand]

On Tue, Feb 27, 2018 at 1:30 AM,  wrote:

> From: Kevin Rogovin 
>
> Signed-off-by: Kevin Rogovin 
> ---
>  src/mesa/drivers/dri/i965/brw_draw.c | 20
> ++--
>  src/mesa/drivers/dri/i965/brw_wm_surface_state.c |  7 +--
>  2 files changed, 23 insertions(+), 4 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_draw.c
> b/src/mesa/drivers/dri/i965/brw_draw.c
> index 0241035..34f4de3 100644
> --- a/src/mesa/drivers/dri/i965/brw_draw.c
> +++ b/src/mesa/drivers/dri/i965/brw_draw.c
> @@ -392,6 +392,8 @@ mark_textures_used_for_txf(BITSET_WORD *used_for_txf,
>   *
>   * Resolve the depth buffer's HiZ buffer, resolve the depth buffer of each
>   * enabled depth texture, and flush the render cache for any dirty
> textures.
> + * In addition, if the ASTC5x5 workaround is needed and if ASTC5x5
> textures
> + * are present, resolve textures so that auxilary buffers are not needed.
>   */
>  void
>  brw_predraw_resolve_inputs(struct brw_context *brw, bool rendering,
> @@ -445,10 +447,14 @@ brw_predraw_resolve_inputs(struct brw_context *brw,
> bool rendering,
>   "for sampling");
>}
>
> +  const bool astc_disables_aux = (brw->astc5x5_wa.required &&
> + brw->astc5x5_wa.texture_astc5x5_present &&
> + tex_obj->mt->aux_usage != ISL_AUX_USAGE_NONE);
> +
>intel_miptree_prepare_texture(brw, tex_obj->mt, view_format,
>  min_level, num_levels,
>  min_layer, num_layers,
> -false);
> +astc_disables_aux);
>
>/* If any programs are using it with texelFetch, we may need to
> also do
> * a prepare with an sRGB format to ensure texelFetch works
> "properly".
> @@ -460,7 +466,7 @@ brw_predraw_resolve_inputs(struct brw_context *brw,
> bool rendering,
>  intel_miptree_prepare_texture(brw, tex_obj->mt, txf_format,
>min_level, num_levels,
>min_layer, num_layers,
> -  false);
> +  astc_disables_aux);
>   }
>}
>
> @@ -496,6 +502,16 @@ brw_predraw_resolve_inputs(struct brw_context *brw,
> bool rendering,
>   }
>}
> }
> +
> +   /* if an ASTC5x5 is present when we need the workaround, then
> +* the above has made sure that the textures have been resolved
> +* so that they do not need an auxilary buffer, so we clear
> +* texture_with_auxilary_present
> +*/
> +   if (brw->astc5x5_wa.required &&
> +   brw->astc5x5_wa.texture_astc5x5_present) {
> +  brw->astc5x5_wa.texture_with_auxilary_present = false;
> +   }
>  }
>
>  static void
> 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 23bf5a2..505e2bf 100644
> --- a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> +++ b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> @@ -441,7 +441,8 @@ swizzle_to_scs(GLenum swizzle, bool need_green_to_blue)
> return (need_green_to_blue && scs == HSW_SCS_GREEN) ? HSW_SCS_BLUE :
> scs;
>  }
>
> -static void brw_update_texture_surface(struct gl_context *ctx,
> +static void
> +brw_update_texture_surface(struct gl_context *ctx,
> unsigned unit,
> uint32_t *surf_offset,
> bool for_gather,
> @@ -581,7 +582,9 @@ static void brw_update_texture_surface(struct
> gl_context *ctx,
>obj->Target == GL_TEXTURE_CUBE_MAP_ARRAY)
>   view.usage |= ISL_SURF_USAGE_CUBE_BIT;
>
> -  enum isl_aux_usage aux_usage =
> +  bool disable_aux = brw->astc5x5_wa.required &&
> + brw->astc5x5_wa.texture_astc5x5_present;
>

I think we can replace texture_astc5x5_present with mode == HAS_ASTC5x5.
For that matter, as long as we never set the mode when the workaround is
not enabled, we don't even need to check whether or not it is required.


> +  enum isl_aux_usage aux_usage = (disable_aux) ? ISL_AUX_USAGE_NONE :
>   intel_miptree_texture_aux_usage(brw, mt, format);
>
>brw_emit_surface_state(brw, mt, mt->target, view, aux_usage,
> --
> 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] [PATCH 1/3] i965/mipmap_tree: Don't allocate CCS when emulating ETC support

[Nanley Chery]

On Tue, Mar 06, 2018 at 12:19:39AM -0800, Kenneth Graunke wrote:
> On Monday, March 5, 2018 2:07:53 PM PST Nanley Chery wrote:
> > ---
> >  src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 8 
> >  1 file changed, 4 insertions(+), 4 deletions(-)
> > 
> > diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c 
> > b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> > index c6213b21629..8586968fd6f 100644
> > --- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> > +++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> > @@ -205,11 +205,11 @@ intel_miptree_supports_ccs(struct brw_context *brw,
> > if (devinfo->gen < 8 && (mip_mapped || arrayed))
> >return false;
> >  
> > -   /* There's no point in using an MCS buffer if the surface isn't in a
> > -* renderable format.
> > -*/
> > -   if (!brw->mesa_format_supports_render[mt->format])
> > +   /* There's no need for an MCS buffer if the surface isn't renderable. */
> > +   if (!brw->mesa_format_supports_render[mt->format] ||
> > +   (mt->etc_format != MESA_FORMAT_NONE)) {
> >return false;
> > +   }
> >  
> > return true;
> >  }
> > 
> 
> I'm confused...we only emulate ETC on Gen < 8.  CCS_E only exists on
> Gen >= 9.  CCS_D does exsit on Gen7-7.5...but I thought we deferred
> CCS_D allocations until the first fast clear...and I don't think it's
> possible to bind an ETC texture as a render target for clearing anyway.
> Maybe ClearTexture but I have my doubts there, too...

Oh, you're right. It's never allocated. I saw that were were setting the
aux_usage to CCS_D and assumed the allocation. I'll send a v2.

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

Re: [Mesa-dev] [PATCH 2/5] i965/miptree: Use cpu tiling/detiling when mapping

[Scott D Phillips]

Jason Ekstrand  writes:

> On Mon, Mar 5, 2018 at 11:39 AM, Nanley Chery  wrote:
>
>> On Tue, Jan 09, 2018 at 11:16:59PM -0800, Scott D Phillips wrote:
>> > Rename the (un)map_gtt functions to (un)map_map (map by
>> > returning a map) and add new functions (un)map_tiled_memcpy that
>> > return a shadow buffer populated with the intel_tiled_memcpy
>> > functions.
>>
>> Could you mention some of the rationale?

One is that gtt maps cannot detile the newer Yf and Ys layouts. Not sure
if Jason or Ken know other reasons. I think we suspected some
performance difference, but I didn't really see any with well formed
bulk uploads or downloads.

>> > ---
>> >  src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 95
>> ---
>> >  1 file changed, 86 insertions(+), 9 deletions(-)
>> >
>> > diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
>> b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
>> > index ead0c359c0..7a90dafa1e 100644
>> > --- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
>> > +++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
>> > @@ -31,6 +31,7 @@
>> >  #include "intel_image.h"
>> >  #include "intel_mipmap_tree.h"
>> >  #include "intel_tex.h"
>> > +#include "intel_tiled_memcpy.h"
>> >  #include "intel_blit.h"
>> >  #include "intel_fbo.h"
>> >
>> > @@ -3031,10 +3032,10 @@ intel_miptree_unmap_raw(struct intel_mipmap_tree
>> *mt)
>> >  }
>> >
>> >  static void
>> > -intel_miptree_map_gtt(struct brw_context *brw,
>> > -   struct intel_mipmap_tree *mt,
>> > -   struct intel_miptree_map *map,
>> > -   unsigned int level, unsigned int slice)
>> > +intel_miptree_map_map(struct brw_context *brw,
>> > +  struct intel_mipmap_tree *mt,
>> > +  struct intel_miptree_map *map,
>> > +  unsigned int level, unsigned int slice)
>> >  {
>> > unsigned int bw, bh;
>> > void *base;
>> > @@ -3052,7 +3053,7 @@ intel_miptree_map_gtt(struct brw_context *brw,
>> > y /= bh;
>> > x /= bw;
>> >
>> > -   base = intel_miptree_map_raw(brw, mt, map->mode);
>> > +   base = intel_miptree_map_raw(brw, mt, map->mode | MAP_RAW);
>> >
>> > if (base == NULL)
>> >map->ptr = NULL;
>> > @@ -3078,11 +3079,80 @@ intel_miptree_map_gtt(struct brw_context *brw,
>> >  }
>> >
>> >  static void
>> > -intel_miptree_unmap_gtt(struct intel_mipmap_tree *mt)
>> > +intel_miptree_unmap_map(struct intel_mipmap_tree *mt)
>> >  {
>> > intel_miptree_unmap_raw(mt);
>> >  }
>> >
>> > +/* Compute extent parameters for use with tiled_memcpy functions.
>> > + * xs are in units of bytes and ys are in units of strides. */
>> > +static inline void
>> > +tile_extents(struct intel_mipmap_tree *mt, struct intel_miptree_map
>> *map,
>> > + unsigned int level, unsigned int slice, unsigned int *x1,
>> > + unsigned int *x2, unsigned int *y1, unsigned int *y2)
>>
>> It would be nice to give these variables units:
>> x1_B, y1_el, etc.

Sure, will do

>> > +{
>> > +   unsigned int block_width, block_height, block_bytes;
>> > +   unsigned int x0_el, y0_el;
>> > +
>> > +   _mesa_get_format_block_size(mt->format, _width,
>> _height);
>> > +   block_bytes = _mesa_get_format_bytes(mt->format);
>>
>> block_bytes == mt->cpp (in theory anyways)

Ok, will change to that

>> > +
>> > +   assert(map->x % block_width == 0);
>> > +   assert(map->y % block_height == 0);
>> > +
>> > +   intel_miptree_get_image_offset(mt, level, slice, _el, _el);
>> > +   *x1 = (map->x / block_width + x0_el) * block_bytes;
>> > +   *y1 = map->y / block_height + y0_el;
>> > +   *x2 = *x1 + DIV_ROUND_UP(map->w, block_width) * block_bytes;
>> > +   *y2 = *y1 + DIV_ROUND_UP(map->h, block_height);
>> > +}
>> > +
>> > +static void
>> > +intel_miptree_map_tiled_memcpy(struct brw_context *brw,
>> > +   struct intel_mipmap_tree *mt,
>> > +   struct intel_miptree_map *map,
>> > +   unsigned int level, unsigned int slice)
>> > +{
>> > +   unsigned int x1, x2, y1, y2;
>> > +   tile_extents(mt, map, level, slice, , , , );
>> > +   map->stride = _mesa_format_row_stride(mt->format, map->w);
>> > +   map->buffer = map->ptr = malloc(map->stride * (y2 - y1));
>>
>> Using _mesa_align_malloc should improve memory accesses for our 128bit
>> formats.
>>
>> We should probably also assert(map->ptr) or throw a GL_OUT_OF_MEMORY
>> error if the alloc fails.

Good suggestions, will do that

>> > +
>> > +   if (!(map->mode & GL_MAP_INVALIDATE_RANGE_BIT)) {
>> > +  char *src = intel_miptree_map_raw(brw, mt, map->mode | MAP_RAW);
>> > +  src += mt->offset;
>> > +
>> > +  tiled_to_linear(x1, x2, y1, y2, map->ptr, src, map->stride,
>> > +  mt->surf.row_pitch, brw->has_swizzling,
>> mt->surf.tiling,
>> > +  memcpy);
>> > +
>> > +  intel_miptree_unmap_raw(mt);
>> > +   }
>> > +}

Re: [Mesa-dev] [PATCH v3 3/7] i965: set ASTC5x5 workaround texture type tracking on texture validate

[Jason Ekstrand]

I don't really like this being in texture validation.  It has nothing to do
with texture validation.  Instead, we should put it in
brw_predraw_resolve_inputs and do it as a pre-pass.  This would let us
store astc5x5_present as a local variable.  Also, I don't think we need
texture_with_auxiliary_present for anything since our solution is to
resolve those.

On Tue, Feb 27, 2018 at 1:30 AM,  wrote:

> From: Kevin Rogovin 
>
> Signed-off-by: Kevin Rogovin 
> ---
>  src/mesa/drivers/dri/i965/intel_tex_validate.c | 15 +++
>  1 file changed, 15 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/i965/intel_tex_validate.c
> b/src/mesa/drivers/dri/i965/intel_tex_validate.c
> index eaa60ba..2bf6c65 100644
> --- a/src/mesa/drivers/dri/i965/intel_tex_validate.c
> +++ b/src/mesa/drivers/dri/i965/intel_tex_validate.c
> @@ -179,6 +179,8 @@ brw_validate_textures(struct brw_context *brw)
> struct gl_context *ctx = >ctx;
> const int max_enabled_unit = ctx->Texture._MaxEnabledTexImageUnit;
>
> +   brw->astc5x5_wa.texture_astc5x5_present = false;
> +   brw->astc5x5_wa.texture_with_auxilary_present = false;
> for (int unit = 0; unit <= max_enabled_unit; unit++) {
>struct gl_texture_object *tex_obj = ctx->Texture.Unit[unit]._
> Current;
>
> @@ -194,5 +196,18 @@ brw_validate_textures(struct brw_context *brw)
>
>intel_update_max_level(tex_obj, sampler);
>intel_finalize_mipmap_tree(brw, tex_obj);
> +
> +  /* ASTC5x5 workaround needs to know if textures in use have
> +   * auxilary in buffers and/or a texture in use is ASTC5x5
> +   */
> +  struct intel_texture_object *tex = intel_texture_object(tex_obj);
> +  struct intel_mipmap_tree *mt = tex->mt;
> +  if (mt && mt->aux_usage != ISL_AUX_USAGE_NONE) {
> + brw->astc5x5_wa.texture_with_auxilary_present = true;
> +  }
> +  if (tex->_Format == MESA_FORMAT_RGBA_ASTC_5x5 ||
> +  tex->_Format == MESA_FORMAT_SRGB8_ALPHA8_ASTC_5x5) {
> + brw->astc5x5_wa.texture_astc5x5_present = true;
> +  }
> }
>  }
> --
> 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] [PATCH v3 2/7] i965: restore diable_aux argument to intel_miptree_prepare_texture()

[Jason Ekstrand]

We took it out with good reason... I'd rather we do something similar to
what we did for render targets and just pass aux usage directly from
brw_predraw_resolve_inputs to brw_wm_surface_state through the context.

On Tue, Feb 27, 2018 at 1:30 AM,  wrote:

> From: Kevin Rogovin 
>
> Signed-off-by: Kevin Rogovin 
> ---
>  src/mesa/drivers/dri/i965/brw_draw.c  | 9 ++---
>  src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 5 +++--
>  src/mesa/drivers/dri/i965/intel_mipmap_tree.h | 3 ++-
>  3 files changed, 11 insertions(+), 6 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_draw.c
> b/src/mesa/drivers/dri/i965/brw_draw.c
> index 299e7f9..0241035 100644
> --- a/src/mesa/drivers/dri/i965/brw_draw.c
> +++ b/src/mesa/drivers/dri/i965/brw_draw.c
> @@ -447,7 +447,8 @@ brw_predraw_resolve_inputs(struct brw_context *brw,
> bool rendering,
>
>intel_miptree_prepare_texture(brw, tex_obj->mt, view_format,
>  min_level, num_levels,
> -min_layer, num_layers);
> +min_layer, num_layers,
> +false);
>
>/* If any programs are using it with texelFetch, we may need to
> also do
> * a prepare with an sRGB format to ensure texelFetch works
> "properly".
> @@ -458,7 +459,8 @@ brw_predraw_resolve_inputs(struct brw_context *brw,
> bool rendering,
>   if (txf_format != view_format) {
>  intel_miptree_prepare_texture(brw, tex_obj->mt, txf_format,
>min_level, num_levels,
> -  min_layer, num_layers);
> +  min_layer, num_layers,
> +  false);
>   }
>}
>
> @@ -530,7 +532,8 @@ brw_predraw_resolve_framebuffer(struct brw_context
> *brw,
>   if (irb) {
>  intel_miptree_prepare_texture(brw, irb->mt,
> irb->mt->surf.format,
>irb->mt_level, 1,
> -  irb->mt_layer,
> irb->layer_count);
> +  irb->mt_layer, irb->layer_count,
> +  false);
>   }
>}
> }
> diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> index c6213b2..dbd9f7a 100644
> --- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> +++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> @@ -2648,9 +2648,10 @@ intel_miptree_prepare_texture(struct brw_context
> *brw,
>struct intel_mipmap_tree *mt,
>enum isl_format view_format,
>uint32_t start_level, uint32_t num_levels,
> -  uint32_t start_layer, uint32_t num_layers)
> +  uint32_t start_layer, uint32_t num_layers,
> +  bool disable_aux)
>  {
> -   enum isl_aux_usage aux_usage =
> +   enum isl_aux_usage aux_usage = (disable_aux) ? ISL_AUX_USAGE_NONE :
>intel_miptree_texture_aux_usage(brw, mt, view_format);
> bool clear_supported = aux_usage != ISL_AUX_USAGE_NONE;
>
> diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
> b/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
> index 07c8580..ee72309 100644
> --- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
> +++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
> @@ -642,7 +642,8 @@ intel_miptree_prepare_texture(struct brw_context *brw,
>struct intel_mipmap_tree *mt,
>enum isl_format view_format,
>uint32_t start_level, uint32_t num_levels,
> -  uint32_t start_layer, uint32_t num_layers);
> +  uint32_t start_layer, uint32_t num_layers,
> +  bool disable_aux);
>  void
>  intel_miptree_prepare_image(struct brw_context *brw,
>  struct intel_mipmap_tree *mt);
> --
> 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] [PATCH v3 1/7] i965: define astx5x5 workaround infrastructure

[Jason Ekstrand]

On Tue, Feb 27, 2018 at 1:30 AM,  wrote:

> From: Kevin Rogovin 
>
> Gen9 GPU's suffer from a HW bug where the GPU will hang if
> the GPU accesses a texture with a an auxilary buffer and
> an ASTC5x5 texture without having a pipeline cs stall (and
> texture cache flush) between such accesses. This patch
> creates the infrastucture to track such potential texture
> accesses and to issue the required pipeline stalls.
>
> Signed-off-by: Kevin Rogovin 
> ---
>  src/mesa/drivers/dri/i965/Makefile.sources|  1 +
>  src/mesa/drivers/dri/i965/brw_context.c   |  6 +
>  src/mesa/drivers/dri/i965/brw_context.h   | 24 ++
>  src/mesa/drivers/dri/i965/gen9_astc5x5_wa.c   | 36
> +++
>  src/mesa/drivers/dri/i965/intel_batchbuffer.c |  1 +
>  src/mesa/drivers/dri/i965/meson.build |  1 +
>  6 files changed, 69 insertions(+)
>  create mode 100644 src/mesa/drivers/dri/i965/gen9_astc5x5_wa.c
>
> diff --git a/src/mesa/drivers/dri/i965/Makefile.sources
> b/src/mesa/drivers/dri/i965/Makefile.sources
> index 2f349aa..20f7dee 100644
> --- a/src/mesa/drivers/dri/i965/Makefile.sources
> +++ b/src/mesa/drivers/dri/i965/Makefile.sources
> @@ -78,6 +78,7 @@ i965_FILES = \
> gen7_urb.c \
> gen8_depth_state.c \
> gen8_multisample_state.c \
> +gen9_astc5x5_wa.c \
> hsw_queryobj.c \
> hsw_sol.c \
> intel_batchbuffer.c \
> diff --git a/src/mesa/drivers/dri/i965/brw_context.c
> b/src/mesa/drivers/dri/i965/brw_context.c
> index ea1c78d..a6e95b2 100644
> --- a/src/mesa/drivers/dri/i965/brw_context.c
> +++ b/src/mesa/drivers/dri/i965/brw_context.c
> @@ -1058,6 +1058,12 @@ brwCreateContext(gl_api api,
> if (ctx->Extensions.INTEL_performance_query)
>brw_init_performance_queries(brw);
>
> +   brw->astc5x5_wa.required = (devinfo->gen == 9);
> +   brw->astc5x5_wa.mode = BRW_ASTC5x5_WA_MODE_NONE;
> +   brw->astc5x5_wa.texture_astc5x5_present = false;
> +   brw->astc5x5_wa.texture_with_auxilary_present = false;
> +   brw->astc5x5_wa.blorp_sampling_from_astc5x5 = false;
> +
> vbo_use_buffer_objects(ctx);
> vbo_always_unmap_buffers(ctx);
>
> diff --git a/src/mesa/drivers/dri/i965/brw_context.h
> b/src/mesa/drivers/dri/i965/brw_context.h
> index 050b656..5fe0b29 100644
> --- a/src/mesa/drivers/dri/i965/brw_context.h
> +++ b/src/mesa/drivers/dri/i965/brw_context.h
> @@ -166,6 +166,12 @@ enum brw_cache_id {
> BRW_MAX_CACHE
>  };
>
> +enum brw_astc5x5_wa_mode_t {
> +   BRW_ASTC5x5_WA_MODE_NONE,
> +   BRW_ASTC5x5_WA_MODE_HAS_ASTC5x5,
> +   BRW_ASTC5x5_WA_MODE_HAS_AUX,
> +};
> +
>  enum brw_state_id {
> /* brw_cache_ids must come first - see brw_program_cache.c */
> BRW_STATE_URB_FENCE = BRW_MAX_CACHE,
> @@ -1296,6 +1302,19 @@ struct brw_context
>  */
> enum isl_aux_usage draw_aux_usage[MAX_DRAW_BUFFERS];
>
> +   /* Certain GEN's have a hardware bug where the sampler hangs if it
> attempts
> +* to access auxilary buffers and an ASTC5x5 compressed buffer. The
> workaround
> +* is to make sure that the texture cache is cleared between such
> accesses
> +* and that such accesses have a command streamer stall between them.
> +*/
> +   struct {
> +  bool required;
>

I would rather have a helper function in brw_draw near where we implement
the workaround than having a boolean in brw_context.  That way the code to
detect the need for the workaround is near the implementation of the
workaround.


> +  enum brw_astc5x5_wa_mode_t mode;
> +  bool texture_astc5x5_present;
> +  bool texture_with_auxilary_present;
> +  bool blorp_sampling_from_astc5x5;
>

This is quite a bit more infastructure than we really need in brw_context.
All we reall need is the enum.  The rest just enables us to spread the
workaround throughout the entire driver which is a bad thing.  Most of my
comments will focus on this theme.


> +   } astc5x5_wa;
> +
> __DRIcontext *driContext;
> struct intel_screen *screen;
>  };
> @@ -1729,6 +1748,11 @@ void brw_query_internal_format(struct gl_context
> *ctx, GLenum target,
> GLenum internalFormat, GLenum pname,
> GLint *params);
>
> +/* gen9_astc5x5_wa.c */
> +void gen9_set_astc5x5_wa_mode(struct brw_context *brw,
> + enum brw_astc5x5_wa_mode_t mode);
> +void gen9_astc5x5_perform_wa(struct brw_context *brw);
> +
>  #ifdef __cplusplus
>  }
>  #endif
> diff --git a/src/mesa/drivers/dri/i965/gen9_astc5x5_wa.c
> b/src/mesa/drivers/dri/i965/gen9_astc5x5_wa.c
> new file mode 100644
> index 000..d3efd05
> --- /dev/null
> +++ b/src/mesa/drivers/dri/i965/gen9_astc5x5_wa.c
> @@ -0,0 +1,36 @@
> +#include "brw_context.h"
> +#include "brw_defines.h"
> +#include "intel_mipmap_tree.h"
> +
> +void
> +gen9_set_astc5x5_wa_mode(struct brw_context *brw,
> + enum brw_astc5x5_wa_mode_t 

[Mesa-dev] [PATCH] ac/nir: fix potential issues when scanning flat_shaded_mask

[Samuel Pitoiset]

As far as I understand, this might overflow and shifted by one
if for example, gl_PrimitiveID is used with flat generic varyings.

Signed-off-by: Samuel Pitoiset 
---
 src/amd/common/ac_nir_to_llvm.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index ea51c3a54a..d4fdb8e8f4 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -5545,6 +5545,7 @@ handle_fs_inputs(struct radv_shader_context *ctx,
nir_foreach_variable(variable, >inputs)
handle_fs_input_decl(ctx, variable);
 
+   uint64_t flat_shaded_mask = 0;
unsigned index = 0;
 
if (ctx->shader_info->info.ps.uses_input_attachments ||
@@ -5564,8 +5565,8 @@ handle_fs_inputs(struct radv_shader_context *ctx,
interp_fs_input(ctx, index, interp_param, 
ctx->abi.prim_mask,
inputs);
 
-   if (!interp_param)
-   ctx->shader_info->fs.flat_shaded_mask |= 1u << 
index;
+   if (i >= VARYING_SLOT_VAR0 && !interp_param)
+   flat_shaded_mask |= 1u << i;
++index;
} else if (i == VARYING_SLOT_POS) {
for(int i = 0; i < 3; ++i)
@@ -5575,7 +5576,9 @@ handle_fs_inputs(struct radv_shader_context *ctx,
  ctx->abi.frag_pos[3]);
}
}
+
ctx->shader_info->fs.num_interp = index;
+   ctx->shader_info->fs.flat_shaded_mask = flat_shaded_mask >> 
VARYING_SLOT_VAR0;
ctx->shader_info->fs.input_mask = ctx->input_mask >> VARYING_SLOT_VAR0;
 
if (ctx->shader_info->info.needs_multiview_view_index)
-- 
2.16.2

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

[Mesa-dev] [Bug 105285] Mesa-utils -8.4 - glxinfo report has a blank value in GL_NUM_SHADING_LANGUAGE_VERSIONS subsection and also the aligniment below 4.3 seems not correct

[bugzilla-daemon]

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

--- Comment #8 from Brian Paul  ---
Sorry, but I don't have much time to look at your app and determine why you're
not seeing GL_ARB_imaging in the core profile.

Any comments on the glx/wglinfo patch series?  If not, I'll push it in a day or
so.  Thanks.

-- 
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] Requesting Guidance for EVoC Application

[Khilan Ravani]

Sir/Mam,

I am a sophomore student pursuing Computer Science and Engineering (C.S.E)
from Indian Institute of Information Technology, Vadodara. I am well adapt
with concepts of Deep Learning, Medical Image Processing & AI and am
currently working on a few research topics in the same domain. I came
across your organization while searching some interesting Opensource
projects/internships and would love to know more about it.

I am particularly interested in the project : *" Implement Remaining
presentation features in the VDPAU state tracker"* since it is the one in
line with my research interests. I have adequate experience in machine
learning and Signal / Image processing and am currently pursuing some
research problems in Satellite Imaging (Hyper-spectral data analysis) and
processing SAR images.

I do possess the required programming skills (C++, OpenCV, Python,
Tensorflow, Keras (CUDA framework), Watson API, Matlab) as well as the
exposure to open source platforms such as github and would like to request
you to please guide me with the further process for writing a proposal.

Hope to hear from you soon,

Thank You,
Yours Sincerely,
Khilan Ravani.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 25/29] intel/blorp: Use nir_format_bitcast_uint_vec_unmasked

[Pohjolainen, Topi]

On Fri, Jan 26, 2018 at 05:59:54PM -0800, Jason Ekstrand wrote:
> ---
>  src/intel/blorp/blorp_blit.c | 57 
> +---
>  1 file changed, 16 insertions(+), 41 deletions(-)

Patches 24 and 25 are:

Reviewed-by: Topi Pohjolainen 

> 
> diff --git a/src/intel/blorp/blorp_blit.c b/src/intel/blorp/blorp_blit.c
> index 068436b..ea0687f 100644
> --- a/src/intel/blorp/blorp_blit.c
> +++ b/src/intel/blorp/blorp_blit.c
> @@ -871,49 +871,24 @@ bit_cast_color(struct nir_builder *b, nir_ssa_def 
> *color,
>  {
> assert(key->texture_data_type == nir_type_uint);
>  
> -   if (key->dst_bpc > key->src_bpc) {
> -  nir_ssa_def *u = nir_ssa_undef(b, 1, 32);
> -  nir_ssa_def *dst_chan[2] = { u, u };
> -  unsigned shift = 0;
> -  unsigned dst_idx = 0;
> -  for (unsigned i = 0; i < 4; i++) {
> - nir_ssa_def *shifted = nir_ishl(b, nir_channel(b, color, i),
> -nir_imm_int(b, shift));
> - if (shift == 0) {
> -dst_chan[dst_idx] = shifted;
> - } else {
> -dst_chan[dst_idx] = nir_ior(b, dst_chan[dst_idx], shifted);
> - }
> +   /* We don't actually know how many source channels we have and NIR will
> +* assert if the number of destination channels ends up being more than 4.
> +* Choose the largest number of source channels that won't over-fill a
> +* destination vec4.
> +*/
> +   const unsigned src_channels =
> +  MIN2(4, (4 * key->dst_bpc) / key->src_bpc);
> +   color = nir_channels(b, color, (1 << src_channels) - 1);
>  
> - shift += key->src_bpc;
> - if (shift >= key->dst_bpc) {
> -dst_idx++;
> -shift = 0;
> - }
> -  }
> +   color = nir_format_bitcast_uint_vec_unmasked(b, color, key->src_bpc,
> +key->dst_bpc);
>  
> -  return nir_vec4(b, dst_chan[0], dst_chan[1], u, u);
> -   } else {
> -  assert(key->dst_bpc < key->src_bpc);
> -
> -  nir_ssa_def *mask = nir_imm_int(b, ~0u >> (32 - key->dst_bpc));
> -
> -  nir_ssa_def *dst_chan[4];
> -  unsigned src_idx = 0;
> -  unsigned shift = 0;
> -  for (unsigned i = 0; i < 4; i++) {
> - dst_chan[i] = nir_iand(b, nir_ushr(b, nir_channel(b, color, 
> src_idx),
> -   nir_imm_int(b, shift)),
> -   mask);
> - shift += key->dst_bpc;
> - if (shift >= key->src_bpc) {
> -src_idx++;
> -shift = 0;
> - }
> -  }
> -
> -  return nir_vec4(b, dst_chan[0], dst_chan[1], dst_chan[2], dst_chan[3]);
> -   }
> +   /* Blorp likes to assume that colors are vec4s */
> +   nir_ssa_def *u = nir_ssa_undef(b, 1, 32);
> +   nir_ssa_def *chans[4] = { u, u, u, u };
> +   for (unsigned i = 0; i < color->num_components; i++)
> +  chans[i] = nir_channel(b, color, i);
> +   return nir_vec4(b, chans[0], chans[1], chans[2], chans[3]);
>  }
>  
>  static nir_ssa_def *
> -- 
> 2.5.0.400.gff86faf
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] PATH(s) to run Firefox with different Mesa versions

[Germano Massullo]

Thank you to all of you for the precious help!
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH RFC] radeonsi: Disable IEEE_MODE.

[Eric Engestrom]

On Monday, 2018-03-05 14:07:24 -0500, Jan Vesely wrote:
> On Mon, 2018-03-05 at 10:04 +, Eric Engestrom wrote:
> > On Saturday, 2018-03-03 18:35:02 -0500, Jan Vesely wrote:
> > > Neither GL nor CL nor SPIRV needs the IEEE handling of sNaNs.
> > > 
> > > Signed-off-by: Jan Vesely 
> > > ---
> > > This is the 3rd way to handle broken fmin/fmax in clover CL.
> > > It can be worked around in libclc (to not use
> > > llvm.fminnum/llvm.fmaxnum)[0]
> > > LLVM can be patched to not use IEEE_MODE[1]
> > > Or it can be fixed in the config reg in mesa.
> > > 
> > > The third option is arguably the worst (changes semantics of compiled
> > > code), but since the first two efforts have been stalled for months.
> > > Here's the third one.
> > > 
> > > Jan
> > > 
> > > [0] 
> > > http://lists.llvm.org/pipermail/libclc-dev/2017-November/thread.html#2692
> > > [1] https://reviews.llvm.org/D40514
> > > 
> > > 
> > >  src/gallium/drivers/radeonsi/si_compute.c | 8 
> > >  src/gallium/drivers/radeonsi/si_shader.c  | 6 +-
> > >  2 files changed, 13 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/src/gallium/drivers/radeonsi/si_compute.c 
> > > b/src/gallium/drivers/radeonsi/si_compute.c
> > > index 41927988cf..d0fcba485b 100644
> > > --- a/src/gallium/drivers/radeonsi/si_compute.c
> > > +++ b/src/gallium/drivers/radeonsi/si_compute.c
> > > @@ -70,6 +70,10 @@ static void code_object_to_config(const 
> > > amd_kernel_code_t *code_object,
> > > struct si_shader_config *out_config) {
> > >  
> > >   uint32_t rsrc1 = code_object->compute_pgm_resource_registers;
> > > + /* Disable IEEE mode. IEEE_MODE determines sNaN handling by fmin/fmax
> > > +  * instructions. Nothing wants the IEEE rules here.
> > > +  * Ideally LLVM would not emit this configuration. */
> > > + rsrc1 &= C_00B848_IEEE_MODE;
> > 
> > I don't know anything about this code, but this bit op looks odd to me;
> > I would expect to see either:
> > rsrc1 &= ~C_00B848_IEEE_MODE;
> 
> C_00B848_IEEE_MODE is defined as 0xFF7F, so it's already bit-
> negated.

Alright, looks reasonable then :)

> 
> Jan
> 
> > or:
> > rsrc1 |= C_00B848_IEEE_MODE;
> > 
> > >   uint32_t rsrc2 = code_object->compute_pgm_resource_registers >> 32;
> > >   out_config->num_sgprs = code_object->wavefront_sgpr_count;
> > >   out_config->num_vgprs = code_object->workitem_vgpr_count;
> > > @@ -137,6 +141,10 @@ static void si_create_compute_state_async(void *job, 
> > > int thread_index)
> > >   S_00B848_SGPRS((shader->config.num_sgprs - 1) / 8) |
> > >   S_00B848_DX10_CLAMP(1) |
> > >   S_00B848_FLOAT_MODE(shader->config.float_mode);
> > > + /* Disable IEEE mode. IEEE_MODE determines sNaN handling by
> > > +  * fmin/fmax instructions. Nothing wants the IEEE rules.
> > > +  * Ideally LLVM would not emit this configuration. */
> > > + shader->config.rsrc1 &= C_00B848_IEEE_MODE;
> > >  
> > >   shader->config.rsrc2 =
> > >   S_00B84C_USER_SGPR(user_sgprs) |
> > > diff --git a/src/gallium/drivers/radeonsi/si_shader.c 
> > > b/src/gallium/drivers/radeonsi/si_shader.c
> > > index 2a50b266f6..01bad71a4e 100644
> > > --- a/src/gallium/drivers/radeonsi/si_shader.c
> > > +++ b/src/gallium/drivers/radeonsi/si_shader.c
> > > @@ -5178,7 +5178,11 @@ void si_shader_binary_read_config(struct 
> > > ac_shader_binary *binary,
> > >   conf->num_sgprs = MAX2(conf->num_sgprs, 
> > > (G_00B028_SGPRS(value) + 1) * 8);
> > >   conf->num_vgprs = MAX2(conf->num_vgprs, 
> > > (G_00B028_VGPRS(value) + 1) * 4);
> > >   conf->float_mode =  G_00B028_FLOAT_MODE(value);
> > > - conf->rsrc1 = value;
> > > + /* Disable IEEE mode. IEEE_MODE determines sNaN
> > > +  * handling by fmin/fmax instructions.
> > > +  * Nothing wants the IEEE rules here.
> > > +  * Ideally LLVM would not emit this configuration. */
> > > + conf->rsrc1 = value & C_00B848_IEEE_MODE;
> > >   break;
> > >   case R_00B02C_SPI_SHADER_PGM_RSRC2_PS:
> > >   conf->lds_size = MAX2(conf->lds_size, 
> > > G_00B02C_EXTRA_LDS_SIZE(value));
> > > -- 
> > > 2.14.3
> > > 
> > > ___
> > > mesa-dev mailing list
> > > mesa-dev@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] PATH(s) to run Firefox with different Mesa versions

[Michel Dänzer]

On 2018-03-06 02:27 PM, Emil Velikov wrote:
> On 6 March 2018 at 12:57, Gert Wollny  wrote:
>> Am Dienstag, den 06.03.2018, 13:10 +0100 schrieb Germano Massullo:
>>> Il 06/03/2018 09:06, Gert Wollny ha scritto:
 Am Dienstag, den 06.03.2018, 01:10 +0100 schrieb Germano Massullo:
> Question: is LIBGL_DRIVERS_PATH enough to let Firefox use a
> different
> Mesa version?

 You will also need to set LIBGL_DRIVERS_PATH
>>>
>>> Maybe it is a typo? I already mentioned LIBGL_DRIVERS_PATH in my
>>> message
>> Sorry I kind of mixed that up, you should also set LD_LIBRARY_PATH to
>> use the mesa libraries related to the drivers. This will probably do:
>>
>> LD_LIBRARY_PATH= \
>> /home/user/mesa-dri-drivers-18.0.0-0.1.rc4.fc27.x86_64/usr/lib64
>>
> A few things that come to mind:
> 
> a) A 32/64 bit issue
> 
> For example: one is pointing to 32bit binaries, while 64bit ones are
> needed, or vice-versa.
> 
> Have _both_ present and use $LIB. The variable will expand accordingly
> - be that lib, lib32, lib64, lib/x86_64-linux-gnu or other
> 
> b) Missing/wrong dependency - libstdc++, llvm, other
> The debug hints below will help here.
> 
> 
> Note that the issue (one here or bugzilla) can be in either the
> frontend libraries or the backend DRI driver.
> 
> * For normal libraries - libGL/libEGL/libglapi, libgbm
> LD_LIBRARY_PATH=/some/chroot/usr/$LIB/
> to debug
> LD_DEBUG=libs
> 
> * For the backend DRI module - foo_dri.so
> LIBGL_DRIVERS_PATH=/some/chroot/usr/$LIB/dri
> to debug
> LIBGL_DEBUG=verbose

FWIW, I recommend using single quotes around $LIB:

LD_LIBRARY_PATH='/some/chroot/usr/$LIB/'
LIBGL_DRIVERS_PATH='/some/chroot/usr/$LIB/dri'

Otherwise the shell will substitute it with the wrong thing.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] freedreno: bump required libdrm version

[Eric Engestrom]

On Tuesday, 2018-03-06 12:00:52 +, Emil Velikov wrote:
> On 6 March 2018 at 09:34, Christian Gmeiner  
> wrote:
> > Fixes: 26a9321d0a "freedreno: add global_bindings state"
> >
> > Signed-off-by: Christian Gmeiner 
> > ---
> >  configure.ac | 2 +-
> >  meson.build  | 2 +-
> >  2 files changed, 2 insertions(+), 2 deletions(-)
> >
> Should cover the slip-up that Eric noticed yesterday [1].

Indeed :)
Reviewed-by: Eric Engestrom 

> Reviewed-by: Emil Velikov 
> 
> -Emil
> 
> [1] https://lists.freedesktop.org/archives/mesa-dev/2018-March/187673.html
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] freedreno: bump required libdrm version

[Rob Clark]

On Tue, Mar 6, 2018 at 4:34 AM, Christian Gmeiner
 wrote:
> Fixes: 26a9321d0a "freedreno: add global_bindings state"
>
> Signed-off-by: Christian Gmeiner 

/me puts on brown paper bag

Reviewed-by: Rob Clark 

> ---
>  configure.ac | 2 +-
>  meson.build  | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index d8093597dd..17c5363868 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -78,7 +78,7 @@ LIBDRM_AMDGPU_REQUIRED=2.4.90
>  LIBDRM_INTEL_REQUIRED=2.4.75
>  LIBDRM_NVVIEUX_REQUIRED=2.4.66
>  LIBDRM_NOUVEAU_REQUIRED=2.4.66
> -LIBDRM_FREEDRENO_REQUIRED=2.4.89
> +LIBDRM_FREEDRENO_REQUIRED=2.4.91
>  LIBDRM_ETNAVIV_REQUIRED=2.4.82
>
>  dnl Versions for external dependencies
> diff --git a/meson.build b/meson.build
> index bb6a835084..b32e1f66e7 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -1008,7 +1008,7 @@ if with_gallium_etnaviv
>dep_libdrm_etnaviv = dependency('libdrm_etnaviv', version : '>= 2.4.82')
>  endif
>  if with_gallium_freedreno
> -  dep_libdrm_freedreno = dependency('libdrm_freedreno', version : '>= 
> 2.4.89')
> +  dep_libdrm_freedreno = dependency('libdrm_freedreno', version : '>= 
> 2.4.91')
>  endif
>
>  llvm_modules = ['bitwriter', 'engine', 'mcdisassembler', 'mcjit']
> --
> 2.14.3
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] PATH(s) to run Firefox with different Mesa versions

[Emil Velikov]

On 6 March 2018 at 12:57, Gert Wollny  wrote:
> Am Dienstag, den 06.03.2018, 13:10 +0100 schrieb Germano Massullo:
>> Il 06/03/2018 09:06, Gert Wollny ha scritto:
>> > Am Dienstag, den 06.03.2018, 01:10 +0100 schrieb Germano Massullo:
>> > > Question: is LIBGL_DRIVERS_PATH enough to let Firefox use a
>> > > different
>> > > Mesa version?
>> >
>> > You will also need to set LIBGL_DRIVERS_PATH
>>
>> Maybe it is a typo? I already mentioned LIBGL_DRIVERS_PATH in my
>> message
> Sorry I kind of mixed that up, you should also set LD_LIBRARY_PATH to
> use the mesa libraries related to the drivers. This will probably do:
>
> LD_LIBRARY_PATH= \
> /home/user/mesa-dri-drivers-18.0.0-0.1.rc4.fc27.x86_64/usr/lib64
>
A few things that come to mind:

a) A 32/64 bit issue

For example: one is pointing to 32bit binaries, while 64bit ones are
needed, or vice-versa.

Have _both_ present and use $LIB. The variable will expand accordingly
- be that lib, lib32, lib64, lib/x86_64-linux-gnu or other

b) Missing/wrong dependency - libstdc++, llvm, other
The debug hints below will help here.


Note that the issue (one here or bugzilla) can be in either the
frontend libraries or the backend DRI driver.

* For normal libraries - libGL/libEGL/libglapi, libgbm
LD_LIBRARY_PATH=/some/chroot/usr/$LIB/
to debug
LD_DEBUG=libs

* For the backend DRI module - foo_dri.so
LIBGL_DRIVERS_PATH=/some/chroot/usr/$LIB/dri
to debug
LIBGL_DEBUG=verbose

I'd start with setting all of the above and getting things to run.
Next step is to track if it's a frontend or backend issue.

Note: ensure that the configure/build options haven't changed. Or
check that that their change isn't causing the bugzilla issue.

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

Re: [Mesa-dev] [PATCH] configure: remove unused AM_CONDITIONAL

[Eric Engestrom]

On Monday, 2018-03-05 18:15:24 +, Emil Velikov wrote:
> From: Emil Velikov 
> 
> Signed-off-by: Emil Velikov 

Reviewed-by: Eric Engestrom 

> ---
>  configure.ac | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/configure.ac b/configure.ac
> index d8093597dd0..0cfb0f7d851 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -451,7 +451,6 @@ if test "x$GCC_ATOMIC_BUILTINS_SUPPORTED" = x1; then
>  LIBATOMIC_LIBS="-latomic"
>  fi
>  fi
> -AM_CONDITIONAL([GCC_ATOMIC_BUILTINS_SUPPORTED], [test 
> x$GCC_ATOMIC_BUILTINS_SUPPORTED = x1])
>  AC_SUBST([LIBATOMIC_LIBS])
>  
>  dnl Check if host supports 64-bit atomics
> -- 
> 2.16.0
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev