Re: [Mesa-dev] nir/i965: Source modifiers on vecN opcodes

[Thomas Helland]

2015-11-09 12:55 GMT+01:00 Iago Toral :
> Hi,
>
> Currently, NIR defines vecN operations as unsigned (integer). The fp64
> patches from Connor change this to float (I guess because we need to
> know the case where we are packing vectors of 64-bit floats). However,
> this makes it so that  nir_lower_source_to_mods turns this:
>
> vec1 ssa_2 = fmov -ssa_1.y
> vec3 ssa_3 = vec3 ssa_1, ssa_2, ssa_0
>
> into:
>
> vec3 ssa_2 = vec3 ssa_1, -ssa_1.y, ssa_0
>
> This only happens because the vec3 operation is defined as a float
> operation now, otherwise it would not try to do this. It is not clear to
> me if this is by design, I mean, have this kind of things only kick-in
> for float/int and define vecN operations as unsigned to avoid this for
> them.
>
> The problem comes later when we call nir_lower_vec_to_movs in the i965
> vec4 backend. That pass generates a separate MOV for each component in
> the vector, but to do that properly when a negate is involved it needs
> to know if this is a float or an integer operand, which it  does not
> know at this point. The current code always emits an imov, which won't
> work if the operand is a float.
>
> I can think of two solutions for this:
>
> 1) Change nir_lower_source_to_mods so it does not try to rewrite alu
> operations where a source comes from a fmov with a negate, or at least
> if the instruction we are trying to rewrite is a vecN operation (or
> maybe allow this in scalar mode only?)
>
> 2) In nir_lower_vec_to_movs, if a source is negated, check its
> parent_instr and try to guess its type from that (in this example, we
> would see it came from fmov and we can say it is a float and emit fmov
> instead of imov). Not sure if this would work in all possible scenarios
> though.
>

FWIW method 2) was the method I chose when I needed to do something
similar for my range analysis pass. However, my intended solution (that
didn't get fully completed) was to implement such a thing in NIR, that
would check all operations we didn't know the type of, not just movs.

I did this the following way; check if all sources have the same type,
if they do then this gives us the type. If this fails then try to deduce the
type from the places where the result is used. This order was chosen
as it is safest to traverse upwards when deducing information.
This would then be incorporated in a nir_get_type_for_alu function.

It went something like this.

nir_get_type_for_alu()
{
   switch(alu-op)
   case "op_we're_sure_of":
  return type;

type = get_type_from_sources();

if (type != nir_type_none )
  return type;

type = get_type_from_uses();

if (type != nir_type_none )
  return type;

panic();
}

get_type_from_source() and get_type_from_dest()
would then call nir_get_type_for_alu() recursively.

This might not be very pretty, but thought I'd share my take on it.

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

Re: [Mesa-dev] [RFC PATCH 00/40] Rework/consolidate the pipe-loader business

[Rob Clark]

On Mon, Nov 9, 2015 at 8:30 AM, Emil Velikov  wrote:
> On 30 October 2015 at 17:57, Emil Velikov  wrote:
>> On 19 October 2015 at 18:41, Emil Velikov  wrote:
>>> On 19 October 2015 at 17:07, Brian Paul  wrote:
>>

 I'm not too familiar with this code or these changes but I'm wondering how
 much of chance there is of this breaking any driver/target builds.

 For example, is there a chance of breaking the VMware driver or Windows
 builds?  I don't have time to test this series here ATM, but I guess I 
 could
 later this week.

>>> Afaics the Windows builds are unaffected. On the  svga/vmwgfx front,
>>> (of the top of my head) I'd say - 1-2% chance that things have
>>> regressed (due to git rebase fallouts, as spotted with the missing
>>> winsys->destroy).
>>>
>>> But in all means please do give them a bash. These can wait a week or
>>> so (but hopefully less than a month).
>>>
>> Hi Brian,
>> I suspect you did not have the time to test the series, have you ? As
>> we've got some patches that conflict with this, I'm wondering if I
>> should respin things (+ drop the sw_winsys rework as mentioned) or if
>> I should chill for another week or so.
>>
>>
>> Rob,
>> Considering how unhappy you were with the with the current state of
>> things (bth neither was I, but you can see why I haven't bothered
>> earlier), can you please take a look and/or test. You will still need
>> the "WIP: gallium: introduce load_pipe_screen()" on top, for Android.
>>
>> The lot can be found in branch pipe-loader-redux at
>> https://github.com/evelikov/Mesa/
>>
> Guys anyone ?
>
> I'm not asking for anyone to review the patches, although a ACK/NACK
> and/or test on your platforms will be greatly appreciated.

yeah, I'm interested in this patchset.. sorry, been busy on other
things so didn't yet have a chance to rebase my android build
(although I am also interested in moving drm_gralloc into mesa tree)..

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

Re: [Mesa-dev] [PATCH] RFC: llvmpipe map scene buffers outside thread. (v2)

[Roland Scheidegger]

Am 09.11.2015 um 05:19 schrieb Dave Airlie:
> From: Dave Airlie 
> 
> There might be a reason we do this inside the thread, but I'm not aware of it
> yet, move stuff around and see if this jogs anyone's memory.
> 
> Doing this outside the thread at least with front buffer rendering avoids
> problems with XGetImage failing in the thread and deadlocking, now things
> crash, which is a lot nicer from a piglit point of view.
> 
> v2: map outside rast mutex, so if we fail XGetImage the fail paths
> don't deadlock
> ---
>  src/gallium/drivers/llvmpipe/lp_scene.c | 21 -
>  src/gallium/drivers/llvmpipe/lp_scene.h |  5 +++--
>  src/gallium/drivers/llvmpipe/lp_setup.c |  1 +
>  3 files changed, 20 insertions(+), 7 deletions(-)
> 
> diff --git a/src/gallium/drivers/llvmpipe/lp_scene.c 
> b/src/gallium/drivers/llvmpipe/lp_scene.c
> index 2441b3c..1a6fe5c 100644
> --- a/src/gallium/drivers/llvmpipe/lp_scene.c
> +++ b/src/gallium/drivers/llvmpipe/lp_scene.c
> @@ -147,7 +147,7 @@ lp_scene_bin_reset(struct lp_scene *scene, unsigned x, 
> unsigned y)
>  
>  
>  void
> -lp_scene_begin_rasterization(struct lp_scene *scene)
> +lp_scene_map_buffers(struct lp_scene *scene)
>  {
> const struct pipe_framebuffer_state *fb = >fb;
> int i;
> @@ -200,16 +200,20 @@ lp_scene_begin_rasterization(struct lp_scene *scene)
> }
>  }
>  
> -
> +void
> +lp_scene_begin_rasterization(struct lp_scene *scene)
> +{
> +   scene->started = true;
> +}
>  
>  
>  /**
>   * Free all the temporary data in a scene.
>   */
> -void
> -lp_scene_end_rasterization(struct lp_scene *scene )
> +static void
> +lp_scene_unmap_buffers(struct lp_scene *scene )
>  {
> -   int i, j;
> +   int i;
>  
> /* Unmap color buffers */
> for (i = 0; i < scene->fb.nr_cbufs; i++) {
> @@ -232,7 +236,14 @@ lp_scene_end_rasterization(struct lp_scene *scene )
>zsbuf->u.tex.first_layer);
>scene->zsbuf.map = NULL;
> }
> +}
>  
> +void
> +lp_scene_end_rasterization(struct lp_scene *scene )
> +{
> +   int i, j;
> +   lp_scene_unmap_buffers(scene);
> +   scene->started = false;
> /* Reset all command lists:
>  */
> for (i = 0; i < scene->tiles_x; i++) {
> diff --git a/src/gallium/drivers/llvmpipe/lp_scene.h 
> b/src/gallium/drivers/llvmpipe/lp_scene.h
> index b1464bb..7ed38c9 100644
> --- a/src/gallium/drivers/llvmpipe/lp_scene.h
> +++ b/src/gallium/drivers/llvmpipe/lp_scene.h
> @@ -178,6 +178,7 @@ struct lp_scene {
>  
> struct cmd_bin tile[TILES_X][TILES_Y];
> struct data_block_list data;
> +   boolean started;
Is this just for debug? Doesn't look like it's ever read.

>  };
>  
>  
> @@ -405,8 +406,8 @@ lp_scene_begin_rasterization(struct lp_scene *scene);
>  void
>  lp_scene_end_rasterization(struct lp_scene *scene );
>  
> -
> -
> +void
> +lp_scene_map_buffers(struct lp_scene *scene);
>  
>  
>  #endif /* LP_BIN_H */
> diff --git a/src/gallium/drivers/llvmpipe/lp_setup.c 
> b/src/gallium/drivers/llvmpipe/lp_setup.c
> index 1778b13..481dfb1 100644
> --- a/src/gallium/drivers/llvmpipe/lp_setup.c
> +++ b/src/gallium/drivers/llvmpipe/lp_setup.c
> @@ -163,6 +163,7 @@ lp_setup_rasterize_scene( struct lp_setup_context *setup )
>  
> if (setup->last_fence)
>setup->last_fence->issued = TRUE;
> +   lp_scene_map_buffers(scene);
>  
> pipe_mutex_lock(screen->rast_mutex);
>  
> 

At some point map/unmap was actually done per-tile (hence inside
rasterization) because of the swizzled rendering (so, only affected
tiles were swizzled if they weren't already) - that's at least my
recollection...
I suspect it doesn't need to be done inside the thread nowadays. Of
course, we don't really do a "real" map/unmap for anything except winsys
buffers (and btw, we only ever unmap winsys buffers for rendering, but
not for texturing, so there's bugs in this area).
Also, because we don't actually do any work when rasterization is
running (see the comment in lp_setup_rasterize_scene()) there's probably
quite some things which don't really matter if they are done inside
rasterize thread or not anyway... Albeit that's something which should
eventually be fixed...

Roland


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

Re: [Mesa-dev] [PATCH] freedreno: expose GLSL 140 and fake MSAA for GL3.0/3.1 support

[Ilia Mirkin]

A few points to note here:

(a) We're obviously faking MSAA support here -- not actually
supporting the 4x MSAA that GL 3.0 requires (although the HW does
support that)
(b) We're only exposing 4 MRT's -- that is a HW limit. I guess one
could do something with a second per-tile runthrough for the
additional MRTs. This might complicate matters for e.g. transform
feedback and atomics.
(c) It appears that gl_ClipVertex is still broken (but that's a GL2
feature) -- should be emulatable same way gl_ClipDistance is.

Outside of those points we do end up with a mostly conformant GL
implementation. There are a few minor additional items, like the
polygon offset not enableable based on polygon mode, and probably a
few others.

I think in spite of that it's reasonable to enable GL3/3.1 for freedreno/a3xx.

  -ilia

On Sun, Nov 8, 2015 at 12:29 AM, Ilia Mirkin  wrote:
> Signed-off-by: Ilia Mirkin 
> ---
>  src/gallium/drivers/freedreno/freedreno_screen.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/drivers/freedreno/freedreno_screen.c 
> b/src/gallium/drivers/freedreno/freedreno_screen.c
> index 8529f86..9d2cd31 100644
> --- a/src/gallium/drivers/freedreno/freedreno_screen.c
> +++ b/src/gallium/drivers/freedreno/freedreno_screen.c
> @@ -177,6 +177,7 @@ fd_screen_get_param(struct pipe_screen *pscreen, enum 
> pipe_cap param)
> case PIPE_CAP_TEXTURE_HALF_FLOAT_LINEAR:
> case PIPE_CAP_CONDITIONAL_RENDER:
> case PIPE_CAP_CONDITIONAL_RENDER_INVERTED:
> +   case PIPE_CAP_FAKE_SW_MSAA:
> return is_a3xx(screen) || is_a4xx(screen);
>
> case PIPE_CAP_TEXTURE_BUFFER_OFFSET_ALIGNMENT:
> @@ -206,7 +207,7 @@ fd_screen_get_param(struct pipe_screen *pscreen, enum 
> pipe_cap param)
> case PIPE_CAP_GLSL_FEATURE_LEVEL:
> if (glsl120)
> return 120;
> -   return is_ir3(screen) ? 130 : 120;
> +   return is_ir3(screen) ? 140 : 120;
>
> /* Unsupported features. */
> case PIPE_CAP_TGSI_FS_COORD_ORIGIN_LOWER_LEFT:
> @@ -221,7 +222,6 @@ fd_screen_get_param(struct pipe_screen *pscreen, enum 
> pipe_cap param)
> case PIPE_CAP_TGSI_VS_LAYER_VIEWPORT:
> case PIPE_CAP_MAX_TEXTURE_GATHER_COMPONENTS:
> case PIPE_CAP_TEXTURE_GATHER_SM5:
> -   case PIPE_CAP_FAKE_SW_MSAA:
> case PIPE_CAP_TEXTURE_QUERY_LOD:
> case PIPE_CAP_SAMPLE_SHADING:
> case PIPE_CAP_TEXTURE_GATHER_OFFSETS:
> --
> 2.4.10
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] st/omx: straighten get/put_screen

[Emil Velikov]

The current code is busted in a number of ways.

 - initially checks for omx_display (rather than omx_screen), which may
or may not be around.
 - blindly feeds the empty env variable string to loader_open_device()
 - reads the env variable every time get_screen is called
 - the latter manifests into memory leaks, and other issues as one sets
the variable between two get_screen calls.

Additionally it cleans up a couple of extra bits
 - drops unneeded set/check of omx_display.
 - make the teardown (put_screen) order was not symmetrical to the setup
(get_screen)

Cc: Leo Liu 
Signed-off-by: Emil Velikov 
---

Leo, feel free to point out if I'm loosing the plot and some of these 
don't hold true.

-Emil

 src/gallium/state_trackers/omx/entrypoint.c | 35 -
 1 file changed, 19 insertions(+), 16 deletions(-)

diff --git a/src/gallium/state_trackers/omx/entrypoint.c 
b/src/gallium/state_trackers/omx/entrypoint.c
index 7df90b1..f99a620 100644
--- a/src/gallium/state_trackers/omx/entrypoint.c
+++ b/src/gallium/state_trackers/omx/entrypoint.c
@@ -33,6 +33,7 @@
 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -73,28 +74,32 @@ int omx_component_library_Setup(stLoaderComponentType 
**stComponents)
 
 struct vl_screen *omx_get_screen(void)
 {
+   static bool first_time = true;
pipe_mutex_lock(omx_lock);
 
-   if (!omx_display) {
-  omx_render_node = debug_get_option("OMX_RENDER_NODE", NULL);
-  if (!omx_render_node) {
- omx_display = XOpenDisplay(NULL);
- if (!omx_display)
-goto error;
-  }
-   }
-
if (!omx_screen) {
+  if (first_time) {
+ omx_render_node = debug_get_option("OMX_RENDER_NODE", NULL);
+ if (omx_render_node && *omx_render_node == '\0')
+omx_render_node = NULL;
+
+ first_time = false;
+  }
   if (omx_render_node) {
  drm_fd = loader_open_device(omx_render_node);
  if (drm_fd < 0)
 goto error;
+
  omx_screen = vl_drm_screen_create(drm_fd);
  if (!omx_screen) {
 close(drm_fd);
 goto error;
  }
   } else {
+ omx_display = XOpenDisplay(NULL);
+ if (!omx_display)
+goto error;
+
  omx_screen = vl_screen_create(omx_display, 0);
  if (!omx_screen) {
 XCloseDisplay(omx_display);
@@ -117,16 +122,14 @@ void omx_put_screen(void)
 {
pipe_mutex_lock(omx_lock);
if ((--omx_usecount) == 0) {
-  if (!omx_render_node) {
- vl_screen_destroy(omx_screen);
- if (omx_display)
-XCloseDisplay(omx_display);
-  } else {
- close(drm_fd);
+  if (omx_render_node) {
  vl_drm_screen_destroy(omx_screen);
+ close(drm_fd);
+  } else {
+ vl_screen_destroy(omx_screen);
+ XCloseDisplay(omx_display);
   }
   omx_screen = NULL;
-  omx_display = NULL;
}
pipe_mutex_unlock(omx_lock);
 }
-- 
2.6.2

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

Re: [Mesa-dev] [PATCH V2 01/12] glsl: simplify interface block stream qualifier validation

[Samuel Iglesias Gonsálvez]

Reviewed-by: Samuel Iglesias Gonsálvez 

On 08/11/15 23:34, Timothy Arceri wrote:
> From: Timothy Arceri 
> 
> Qualifiers on member variables are redundent all we need to do
> if check if it matches the stream associated with the block and
> throw an error if its not.
> 
> Cc: Samuel Iglesias Gonsalvez 
> Cc: Emil Velikov 
> ---
>  src/glsl/ast_to_hir.cpp   | 27 +--
>  src/glsl/nir/glsl_types.h | 10 +-
>  2 files changed, 14 insertions(+), 23 deletions(-)
> 
> diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
> index 0306530..5a22820 100644
> --- a/src/glsl/ast_to_hir.cpp
> +++ b/src/glsl/ast_to_hir.cpp
> @@ -5964,8 +5964,19 @@ ast_process_structure_or_interface_block(exec_list 
> *instructions,
>   fields[i].sample = qual->flags.q.sample ? 1 : 0;
>   fields[i].patch = qual->flags.q.patch ? 1 : 0;
>  
> - /* Only save explicitly defined streams in block's field */
> - fields[i].stream = qual->flags.q.explicit_stream ? qual->stream : 
> -1;
> + /* From Section 4.4.2.3 (Geometry Outputs) of the GLSL 4.50 spec:
> +  *
> +  *   "A block member may be declared with a stream identifier, but
> +  *   the specified stream must match the stream associated with the
> +  *   containing block."
> +  */
> + if (qual->flags.q.explicit_stream &&
> + qual->stream != layout->stream) {
> +_mesa_glsl_error(, state, "stream layout qualifier on "
> + "interface block member `%s' does not match "
> + "the interface block (%d vs %d)",
> + fields[i].name, qual->stream, layout->stream);
> + }
>  
>   if (qual->flags.q.row_major || qual->flags.q.column_major) {
>  if (!qual->flags.q.uniform && !qual->flags.q.buffer) {
> @@ -6267,18 +6278,6 @@ ast_interface_block::hir(exec_list *instructions,
>  
> state->struct_specifier_depth--;
>  
> -   for (unsigned i = 0; i < num_variables; i++) {
> -  if (fields[i].stream != -1 &&
> -  (unsigned) fields[i].stream != this->layout.stream) {
> - _mesa_glsl_error(, state,
> -  "stream layout qualifier on "
> -  "interface block member `%s' does not match "
> -  "the interface block (%d vs %d)",
> -  fields[i].name, fields[i].stream,
> -  this->layout.stream);
> -  }
> -   }
> -
> if (!redeclaring_per_vertex) {
>validate_identifier(this->block_name, loc, state);
>  
> diff --git a/src/glsl/nir/glsl_types.h b/src/glsl/nir/glsl_types.h
> index 52ca826..1f17ad5 100644
> --- a/src/glsl/nir/glsl_types.h
> +++ b/src/glsl/nir/glsl_types.h
> @@ -829,13 +829,6 @@ struct glsl_struct_field {
> unsigned patch:1;
>  
> /**
> -* For interface blocks, it has a value if this variable uses multiple 
> vertex
> -* streams (as in ir_variable::stream). -1 otherwise.
> -*/
> -   int stream;
> -
> -
> -   /**
>  * Image qualifiers, applicable to buffer variables defined in shader
>  * storage buffer objects (SSBOs)
>  */
> @@ -847,8 +840,7 @@ struct glsl_struct_field {
>  
> glsl_struct_field(const struct glsl_type *_type, const char *_name)
>: type(_type), name(_name), location(-1), interpolation(0), 
> centroid(0),
> -sample(0), matrix_layout(GLSL_MATRIX_LAYOUT_INHERITED), patch(0),
> -stream(-1)
> +sample(0), matrix_layout(GLSL_MATRIX_LAYOUT_INHERITED), patch(0)
> {
>/* empty */
> }
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC PATCH 00/40] Rework/consolidate the pipe-loader business

[Emil Velikov]

On 30 October 2015 at 17:57, Emil Velikov  wrote:
> On 19 October 2015 at 18:41, Emil Velikov  wrote:
>> On 19 October 2015 at 17:07, Brian Paul  wrote:
>
>>>
>>> I'm not too familiar with this code or these changes but I'm wondering how
>>> much of chance there is of this breaking any driver/target builds.
>>>
>>> For example, is there a chance of breaking the VMware driver or Windows
>>> builds?  I don't have time to test this series here ATM, but I guess I could
>>> later this week.
>>>
>> Afaics the Windows builds are unaffected. On the  svga/vmwgfx front,
>> (of the top of my head) I'd say - 1-2% chance that things have
>> regressed (due to git rebase fallouts, as spotted with the missing
>> winsys->destroy).
>>
>> But in all means please do give them a bash. These can wait a week or
>> so (but hopefully less than a month).
>>
> Hi Brian,
> I suspect you did not have the time to test the series, have you ? As
> we've got some patches that conflict with this, I'm wondering if I
> should respin things (+ drop the sw_winsys rework as mentioned) or if
> I should chill for another week or so.
>
>
> Rob,
> Considering how unhappy you were with the with the current state of
> things (bth neither was I, but you can see why I haven't bothered
> earlier), can you please take a look and/or test. You will still need
> the "WIP: gallium: introduce load_pipe_screen()" on top, for Android.
>
> The lot can be found in branch pipe-loader-redux at
> https://github.com/evelikov/Mesa/
>
Guys anyone ?

I'm not asking for anyone to review the patches, although a ACK/NACK
and/or test on your platforms will be greatly appreciated.

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

Re: [Mesa-dev] soft/llvmpipe front buffer access and piglit regressions

[Roland Scheidegger]

Am 09.11.2015 um 04:44 schrieb Dave Airlie:
> So it appears my patch to enable front buffer access on soft/llvmpipe
> causes some piglit regressions. However these are due to piglit having
> undefined behaviour where it doesn't create a window but has tests
> requiring a front buffer. The new code does an XGetImage on the front
> buffer and when it fails all sorts of bad things tend to happen. I
> don't think there is a way to check if we have a window mapped inside
> Mesa to avoid this path.
> 
> swrast suffers from the same failure pattern in a number of tests when
> run with -auto.
> 
> I'm not sure what to do here, the patch is making the driver
> conformant and is fixing a missing
> feature being used by OpenGL apps (gtk).
> 
> I can probably make it fail more gracefully (llvmpipe deadlocks on the
> Xlib error path inside it's rasteriser threads), but I'm not sure I
> want to go back to the old behaviour just to satisfy piglit's
> requirement to do undefined things.
> 

I don't really understand all this interface stuff, however it feels
wrong to me that we have to care in the driver for something which you
say is totally bogus. Couldn't that be handled outside? Albeit I don't
really understand what exactly happens in the first place.

Roland


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

Re: [Mesa-dev] [RFCv2 03/13] nir: allow pre-resolved sampler uniform locations

[Rob Clark]

On Sun, Nov 8, 2015 at 7:58 PM, Timothy Arceri  wrote:
> On Sun, 2015-11-08 at 15:12 -0500, Rob Clark wrote:
>> From: Rob Clark 
>>
>> With TGSI, the ir_variable::data.location gets fixed up to be a stage
>> local location (rather than program global).  In this case we need to
>> skip the UniformStorage[location] lookup.
>> ---
>>  src/glsl/nir/nir_lower_samplers.c | 23 ---
>>  1 file changed, 16 insertions(+), 7 deletions(-)
>>
>> diff --git a/src/glsl/nir/nir_lower_samplers.c
>> b/src/glsl/nir/nir_lower_samplers.c
>> index 5df79a6..d99ba4c 100644
>> --- a/src/glsl/nir/nir_lower_samplers.c
>> +++ b/src/glsl/nir/nir_lower_samplers.c
>> @@ -130,14 +130,18 @@ lower_sampler(nir_tex_instr *instr, const struct
>> gl_shader_program *shader_progr
>>instr->sampler_array_size = array_elements;
>> }
>>
>> -   if (location > shader_program->NumUniformStorage - 1 ||
>> -   !shader_program->UniformStorage[location].opaque[stage].active) {
>> -  assert(!"cannot return a sampler");
>> -  return;
>> -   }
>> +   if (!shader_program) {
>> +  instr->sampler_index = location;
>> +   } else {
>> +  if (location > shader_program->NumUniformStorage - 1 ||
>> +  !shader_program->UniformStorage[location].opaque[stage].active) {
>> + assert(!"cannot return a sampler");
>> + return;
>> +  }
>>
>> -   instr->sampler_index +=
>> -  shader_program->UniformStorage[location].opaque[stage].index;
>> +  instr->sampler_index =
>> + shader_program->UniformStorage[location].opaque[stage].index;
>
> Hi Rob,
>
> This will break arrays as instr->sampler_index is increamented inside
>  calc_sampler_offsets()

oh, whoops, I didn't notice that.. ok, that part is easy enough to fix..

> calc_sampler_offsets() also modifies the value of location is this what you
> want? I would assume not as we are counting uniforms not just samplers here.

hmm, tbh I'm not entirely sure..  offhand, what piglit's should I
check?  I guess it would be easier to debug if it worked correctly
with glsl_to_tgsi, but I guess I could try to get the non-indirect
case working..

BR,
-R

> The other thing to note is that glsl to tgsi doesn't handle indirects on
> structs or arrays of arrays correctly (Ilia was trying to fix this).
>
> Tim
>
>
>
>> +   }
>>
>> instr->sampler = NULL;
>>  }
>> @@ -177,6 +181,11 @@ lower_impl(nir_function_impl *impl, const struct
>> gl_shader_program *shader_progr
>> nir_foreach_block(impl, lower_block_cb, );
>>  }
>>
>> +/* Call with a null 'shader_program' if uniform locations are
>
> uniform locations -> sampler indices?
>
>> + * already local to the shader, ie. skipping the
>> + * shader_program->UniformStorage[location].opaque[stage].index
>> + * lookup
>> + */
>>  void
>>  nir_lower_samplers(nir_shader *shader,
>> const struct gl_shader_program *shader_program)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 01/13] st/va: trivial cleanup

[Emil Velikov]

Drop the temporary variable and fold the two conditional.

Signed-off-by: Emil Velikov 
---
 src/gallium/state_trackers/va/context.c | 11 ++-
 1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/src/gallium/state_trackers/va/context.c 
b/src/gallium/state_trackers/va/context.c
index 98c4104..04ca2f2 100644
--- a/src/gallium/state_trackers/va/context.c
+++ b/src/gallium/state_trackers/va/context.c
@@ -102,7 +102,6 @@ PUBLIC VAStatus
 VA_DRIVER_INIT_FUNC(VADriverContextP ctx)
 {
vlVaDriver *drv;
-   int drm_fd;
struct drm_state *drm_info;
 
if (!ctx)
@@ -126,19 +125,13 @@ VA_DRIVER_INIT_FUNC(VADriverContextP ctx)
case VA_DISPLAY_DRM:
case VA_DISPLAY_DRM_RENDERNODES: {
   drm_info = (struct drm_state *) ctx->drm_state;
-  if (!drm_info) {
- FREE(drv);
- return VA_STATUS_ERROR_INVALID_PARAMETER;
-  }
-
-  drm_fd = drm_info->fd;
 
-  if (drm_fd < 0) {
+  if (!drm_info || drm_info->fd < 0) {
  FREE(drv);
  return VA_STATUS_ERROR_INVALID_PARAMETER;
   }
 
-  drv->vscreen = vl_drm_screen_create(drm_fd);
+  drv->vscreen = vl_drm_screen_create(drm_info->fd);
   if (!drv->vscreen)
  goto error_screen;
   }
-- 
2.6.2

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

[Mesa-dev] [PATCH 13/13] auxiliary/vl/dri2: coding style fixes

[Emil Velikov]

Rewrap long(ish) lines, add space between struct foo and *.

Trivial or bikeshedding you decide.

Signed-off-by: Emil Velikov 
---
 src/gallium/auxiliary/vl/vl_winsys.h |  2 +-
 src/gallium/auxiliary/vl/vl_winsys_dri.c | 54 +++-
 2 files changed, 34 insertions(+), 22 deletions(-)

diff --git a/src/gallium/auxiliary/vl/vl_winsys.h 
b/src/gallium/auxiliary/vl/vl_winsys.h
index 7d3c941..1af7653 100644
--- a/src/gallium/auxiliary/vl/vl_winsys.h
+++ b/src/gallium/auxiliary/vl/vl_winsys.h
@@ -63,7 +63,7 @@ struct vl_screen
struct pipe_loader_device *dev;
 };
 
-struct vl_screen*
+struct vl_screen *
 vl_dri2_screen_create(Display *display, int screen);
 
 struct vl_screen *
diff --git a/src/gallium/auxiliary/vl/vl_winsys_dri.c 
b/src/gallium/auxiliary/vl/vl_winsys_dri.c
index 098b9a9..e0683a5 100644
--- a/src/gallium/auxiliary/vl/vl_winsys_dri.c
+++ b/src/gallium/auxiliary/vl/vl_winsys_dri.c
@@ -73,26 +73,27 @@ struct vl_dri_screen
int64_t last_ust, ns_frame, last_msc, next_msc;
 };
 
-static const unsigned int attachments[1] = { 
XCB_DRI2_ATTACHMENT_BUFFER_BACK_LEFT };
+static const unsigned attachments[1] = { XCB_DRI2_ATTACHMENT_BUFFER_BACK_LEFT 
};
 
 static void vl_dri2_screen_destroy(struct vl_screen *vscreen);
 
 static void
-vl_dri2_handle_stamps(struct vl_dri_screen* scrn,
+vl_dri2_handle_stamps(struct vl_dri_screen *scrn,
   uint32_t ust_hi, uint32_t ust_lo,
   uint32_t msc_hi, uint32_t msc_lo)
 {
int64_t ust = uint64_t)ust_hi) << 32) | ust_lo) * 1000;
int64_t msc = (((uint64_t)msc_hi) << 32) | msc_lo;
 
-   if (scrn->last_ust && scrn->last_msc && (ust > scrn->last_ust) && (msc > 
scrn->last_msc))
+   if (scrn->last_ust && (ust > scrn->last_ust) &&
+   scrn->last_msc && (msc > scrn->last_msc))
   scrn->ns_frame = (ust - scrn->last_ust) / (msc - scrn->last_msc);
 
scrn->last_ust = ust;
scrn->last_msc = msc;
 }
 
-static xcb_dri2_get_buffers_reply_t*
+static xcb_dri2_get_buffers_reply_t *
 vl_dri2_get_flush_reply(struct vl_dri_screen *scrn)
 {
xcb_dri2_wait_sbc_reply_t *wait_sbc_reply;
@@ -122,7 +123,7 @@ vl_dri2_flush_frontbuffer(struct pipe_screen *screen,
   unsigned level, unsigned layer,
   void *context_private, struct pipe_box *sub_box)
 {
-   struct vl_dri_screen *scrn = (struct vl_dri_screen*)context_private;
+   struct vl_dri_screen *scrn = (struct vl_dri_screen *)context_private;
uint32_t msc_hi, msc_lo;
 
assert(screen);
@@ -134,9 +135,11 @@ vl_dri2_flush_frontbuffer(struct pipe_screen *screen,
msc_hi = scrn->next_msc >> 32;
msc_lo = scrn->next_msc & 0x;
 
-   scrn->swap_cookie = xcb_dri2_swap_buffers_unchecked(scrn->conn, 
scrn->drawable, msc_hi, msc_lo, 0, 0, 0, 0);
+   scrn->swap_cookie = xcb_dri2_swap_buffers_unchecked(scrn->conn, 
scrn->drawable,
+   msc_hi, msc_lo, 0, 0, 
0, 0);
scrn->wait_cookie = xcb_dri2_wait_sbc_unchecked(scrn->conn, scrn->drawable, 
0, 0);
-   scrn->buffers_cookie = xcb_dri2_get_buffers_unchecked(scrn->conn, 
scrn->drawable, 1, 1, attachments);
+   scrn->buffers_cookie = xcb_dri2_get_buffers_unchecked(scrn->conn, 
scrn->drawable,
+ 1, 1, attachments);
 
scrn->flushed = true;
scrn->current_buffer = !scrn->current_buffer;
@@ -175,7 +178,7 @@ vl_dri2_set_drawable(struct vl_dri_screen *scrn, Drawable 
drawable)
 static struct pipe_resource *
 vl_dri2_screen_texture_from_drawable(struct vl_screen *vscreen, void *drawable)
 {
-   struct vl_dri_screen *scrn = (struct vl_dri_screen*)vscreen;
+   struct vl_dri_screen *scrn = (struct vl_dri_screen *)vscreen;
 
struct winsys_handle dri2_handle;
struct pipe_resource template, *tex;
@@ -244,7 +247,8 @@ vl_dri2_screen_texture_from_drawable(struct vl_screen 
*vscreen, void *drawable)
template.bind = PIPE_BIND_RENDER_TARGET;
template.flags = 0;
 
-   tex = scrn->base.pscreen->resource_from_handle(scrn->base.pscreen, 
, _handle);
+   tex = scrn->base.pscreen->resource_from_handle(scrn->base.pscreen, 
,
+  _handle);
free(reply);
 
return tex;
@@ -253,7 +257,7 @@ vl_dri2_screen_texture_from_drawable(struct vl_screen 
*vscreen, void *drawable)
 static struct u_rect *
 vl_dri2_screen_get_dirty_area(struct vl_screen *vscreen)
 {
-   struct vl_dri_screen *scrn = (struct vl_dri_screen*)vscreen;
+   struct vl_dri_screen *scrn = (struct vl_dri_screen *)vscreen;
assert(scrn);
return >dirty_areas[scrn->current_buffer];
 }
@@ -261,7 +265,7 @@ vl_dri2_screen_get_dirty_area(struct vl_screen *vscreen)
 static uint64_t
 vl_dri2_screen_get_timestamp(struct vl_screen *vscreen, void *drawable)
 {
-   struct vl_dri_screen *scrn = (struct vl_dri_screen*)vscreen;
+   struct vl_dri_screen *scrn = (struct vl_dri_screen *)vscreen;

[Mesa-dev] [PATCH 07/13] st/omx: use the vl_screen dispatch

[Emil Velikov]

Signed-off-by: Emil Velikov 
---
 src/gallium/state_trackers/omx/entrypoint.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/src/gallium/state_trackers/omx/entrypoint.c 
b/src/gallium/state_trackers/omx/entrypoint.c
index d369cec..883a2a1 100644
--- a/src/gallium/state_trackers/omx/entrypoint.c
+++ b/src/gallium/state_trackers/omx/entrypoint.c
@@ -122,14 +122,13 @@ void omx_put_screen(void)
 {
pipe_mutex_lock(omx_lock);
if ((--omx_usecount) == 0) {
-  if (omx_render_node) {
- vl_drm_screen_destroy(omx_screen);
+  omx_screen->destroy(omx_screen);
+  omx_screen = NULL;
+
+  if (omx_render_node)
  close(drm_fd);
-  } else {
- vl_screen_destroy(omx_screen);
+  else
  XCloseDisplay(omx_display);
-  }
-  omx_screen = NULL;
}
pipe_mutex_unlock(omx_lock);
 }
-- 
2.6.2

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

[Mesa-dev] [PATCH 06/13] auxiliary/vl/dri2: setup the dispatch

[Emil Velikov]

Signed-off-by: Emil Velikov 
---

This commit might cause some build warnings, all of which are handled 
with the next commit(s).

-Emil

 src/gallium/auxiliary/vl/vl_winsys.h |  4 ++--
 src/gallium/auxiliary/vl/vl_winsys_dri.c | 19 +--
 2 files changed, 15 insertions(+), 8 deletions(-)

diff --git a/src/gallium/auxiliary/vl/vl_winsys.h 
b/src/gallium/auxiliary/vl/vl_winsys.h
index 29da320..5390f72 100644
--- a/src/gallium/auxiliary/vl/vl_winsys.h
+++ b/src/gallium/auxiliary/vl/vl_winsys.h
@@ -66,13 +66,13 @@ struct vl_screen
 void vl_screen_destroy(struct vl_screen *vscreen);
 
 struct pipe_resource*
-vl_screen_texture_from_drawable(struct vl_screen *vscreen, Drawable drawable);
+vl_screen_texture_from_drawable(struct vl_screen *vscreen, void *drawable);
 
 struct u_rect *
 vl_screen_get_dirty_area(struct vl_screen *vscreen);
 
 uint64_t
-vl_screen_get_timestamp(struct vl_screen *vscreen, Drawable drawable);
+vl_screen_get_timestamp(struct vl_screen *vscreen, void *drawable);
 
 void
 vl_screen_set_next_timestamp(struct vl_screen *vscreen, uint64_t stamp);
diff --git a/src/gallium/auxiliary/vl/vl_winsys_dri.c 
b/src/gallium/auxiliary/vl/vl_winsys_dri.c
index 46f5816..12f7887 100644
--- a/src/gallium/auxiliary/vl/vl_winsys_dri.c
+++ b/src/gallium/auxiliary/vl/vl_winsys_dri.c
@@ -171,7 +171,7 @@ vl_dri2_set_drawable(struct vl_dri_screen *scrn, Drawable 
drawable)
 }
 
 struct pipe_resource*
-vl_screen_texture_from_drawable(struct vl_screen *vscreen, Drawable drawable)
+vl_screen_texture_from_drawable(struct vl_screen *vscreen, void *drawable)
 {
struct vl_dri_screen *scrn = (struct vl_dri_screen*)vscreen;
 
@@ -185,11 +185,12 @@ vl_screen_texture_from_drawable(struct vl_screen 
*vscreen, Drawable drawable)
 
assert(scrn);
 
-   vl_dri2_set_drawable(scrn, drawable);
+   vl_dri2_set_drawable(scrn, (Drawable)drawable);
reply = vl_dri2_get_flush_reply(scrn);
if (!reply) {
   xcb_dri2_get_buffers_cookie_t cookie;
-  cookie = xcb_dri2_get_buffers_unchecked(scrn->conn, drawable, 1, 1, 
attachments);
+  cookie = xcb_dri2_get_buffers_unchecked(scrn->conn, (Drawable)drawable,
+  1, 1, attachments);
   reply = xcb_dri2_get_buffers_reply(scrn->conn, cookie, NULL);
}
if (!reply)
@@ -256,7 +257,7 @@ vl_screen_get_dirty_area(struct vl_screen *vscreen)
 }
 
 uint64_t
-vl_screen_get_timestamp(struct vl_screen *vscreen, Drawable drawable)
+vl_screen_get_timestamp(struct vl_screen *vscreen, void *drawable)
 {
struct vl_dri_screen *scrn = (struct vl_dri_screen*)vscreen;
xcb_dri2_get_msc_cookie_t cookie;
@@ -264,9 +265,9 @@ vl_screen_get_timestamp(struct vl_screen *vscreen, Drawable 
drawable)
 
assert(scrn);
 
-   vl_dri2_set_drawable(scrn, drawable);
+   vl_dri2_set_drawable(scrn, (Drawable)drawable);
if (!scrn->last_ust) {
-  cookie = xcb_dri2_get_msc_unchecked(scrn->conn, drawable);
+  cookie = xcb_dri2_get_msc_unchecked(scrn->conn, (Drawable)drawable);
   reply = xcb_dri2_get_msc_reply(scrn->conn, cookie, NULL);
 
   if (reply) {
@@ -397,6 +398,12 @@ vl_dri2_screen_create(Display *display, int screen)
if (!scrn->base.pscreen)
   goto release_pipe;
 
+   scrn->base.destroy = vl_screen_destroy;
+   scrn->base.texture_from_drawable = vl_screen_texture_from_drawable;
+   scrn->base.get_dirty_area = vl_screen_get_dirty_area;
+   scrn->base.get_timestamp = vl_screen_get_timestamp;
+   scrn->base.set_next_timestamp = vl_screen_set_next_timestamp;
+   scrn->base.get_private = vl_screen_get_private;
scrn->base.pscreen->flush_frontbuffer = vl_dri2_flush_frontbuffer;
vl_compositor_reset_dirty_area(>dirty_areas[0]);
vl_compositor_reset_dirty_area(>dirty_areas[1]);
-- 
2.6.2

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

[Mesa-dev] [PATCH 04/13] auxiliary/vl/drm: setup the dispatch

[Emil Velikov]

Signed-off-by: Emil Velikov 
---
 src/gallium/auxiliary/vl/vl_winsys_drm.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/src/gallium/auxiliary/vl/vl_winsys_drm.c 
b/src/gallium/auxiliary/vl/vl_winsys_drm.c
index 1167fcf..2ebf20c 100644
--- a/src/gallium/auxiliary/vl/vl_winsys_drm.c
+++ b/src/gallium/auxiliary/vl/vl_winsys_drm.c
@@ -59,6 +59,12 @@ vl_drm_screen_create(int fd)
   return NULL;
}
 
+   vscreen->destroy = vl_drm_screen_destroy;
+   vscreen->texture_from_drawable = NULL;
+   vscreen->get_dirty_area = NULL;
+   vscreen->get_timestamp = NULL;
+   vscreen->set_next_timestamp = NULL;
+   vscreen->get_private = NULL;
return vscreen;
 }
 
-- 
2.6.2

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

[Mesa-dev] [PATCH 10/13] st/vdpau: use the vl_screen dispatch

[Emil Velikov]

Signed-off-by: Emil Velikov 
---
 src/gallium/state_trackers/vdpau/device.c   |  4 ++--
 src/gallium/state_trackers/vdpau/presentation.c | 18 +-
 2 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/src/gallium/state_trackers/vdpau/device.c 
b/src/gallium/state_trackers/vdpau/device.c
index 8fda388..c70cc6e 100644
--- a/src/gallium/state_trackers/vdpau/device.c
+++ b/src/gallium/state_trackers/vdpau/device.c
@@ -136,7 +136,7 @@ no_handle:
 no_resource:
dev->context->destroy(dev->context);
 no_context:
-   vl_screen_destroy(dev->vscreen);
+   dev->vscreen->destroy(dev->vscreen);
 no_vscreen:
FREE(dev);
 no_dev:
@@ -227,7 +227,7 @@ vlVdpDeviceFree(vlVdpDevice *dev)
vl_compositor_cleanup(>compositor);
pipe_sampler_view_reference(>dummy_sv, NULL);
dev->context->destroy(dev->context);
-   vl_screen_destroy(dev->vscreen);
+   dev->vscreen->destroy(dev->vscreen);
FREE(dev);
vlDestroyHTAB();
 }
diff --git a/src/gallium/state_trackers/vdpau/presentation.c 
b/src/gallium/state_trackers/vdpau/presentation.c
index e533037..e7f387e 100644
--- a/src/gallium/state_trackers/vdpau/presentation.c
+++ b/src/gallium/state_trackers/vdpau/presentation.c
@@ -186,7 +186,8 @@ vlVdpPresentationQueueGetTime(VdpPresentationQueue 
presentation_queue,
   return VDP_STATUS_INVALID_HANDLE;
 
pipe_mutex_lock(pq->device->mutex);
-   *current_time = vl_screen_get_timestamp(pq->device->vscreen, pq->drawable);
+   *current_time = pq->device->vscreen->get_timestamp(pq->device->vscreen,
+  (void *)pq->drawable);
pipe_mutex_unlock(pq->device->mutex);
 
return VDP_STATUS_OK;
@@ -214,6 +215,7 @@ vlVdpPresentationQueueDisplay(VdpPresentationQueue 
presentation_queue,
 
struct vl_compositor *compositor;
struct vl_compositor_state *cstate;
+   struct vl_screen *vscreen;
 
pq = vlGetDataHTAB(presentation_queue);
if (!pq)
@@ -226,15 +228,16 @@ vlVdpPresentationQueueDisplay(VdpPresentationQueue 
presentation_queue,
pipe = pq->device->context;
compositor = >device->compositor;
cstate = >cstate;
+   vscreen = pq->device->vscreen;
 
pipe_mutex_lock(pq->device->mutex);
-   tex = vl_screen_texture_from_drawable(pq->device->vscreen, pq->drawable);
+   tex = vscreen->texture_from_drawable(vscreen, (void *)pq->drawable);
if (!tex) {
   pipe_mutex_unlock(pq->device->mutex);
   return VDP_STATUS_INVALID_HANDLE;
}
 
-   dirty_area = vl_screen_get_dirty_area(pq->device->vscreen);
+   dirty_area = vscreen->get_dirty_area(vscreen);
 
memset(_templ, 0, sizeof(surf_templ));
surf_templ.format = tex->format;
@@ -267,12 +270,9 @@ vlVdpPresentationQueueDisplay(VdpPresentationQueue 
presentation_queue,
   vl_compositor_render(cstate, compositor, surf_draw, dirty_area, true);
}
 
-   vl_screen_set_next_timestamp(pq->device->vscreen, 
earliest_presentation_time);
-   pipe->screen->flush_frontbuffer
-   (
-  pipe->screen, tex, 0, 0,
-  vl_screen_get_private(pq->device->vscreen), NULL
-   );
+   vscreen->set_next_timestamp(vscreen, earliest_presentation_time);
+   pipe->screen->flush_frontbuffer(pipe->screen, tex, 0, 0,
+   vscreen->get_private(vscreen), NULL);
 
pipe->screen->fence_reference(pipe->screen, >fence, NULL);
pipe->flush(pipe, >fence, 0);
-- 
2.6.2

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

[Mesa-dev] [PATCH 11/13] auxiliary/vl/drm: hide internal functions

[Emil Velikov]

As of last commit everyone is using the vl_screen dispatch, thus we can
hide this function from the headers and make it static.

Signed-off-by: Emil Velikov 
---
 src/gallium/auxiliary/vl/vl_winsys.h | 3 ---
 src/gallium/auxiliary/vl/vl_winsys_drm.c | 7 +--
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/src/gallium/auxiliary/vl/vl_winsys.h 
b/src/gallium/auxiliary/vl/vl_winsys.h
index 5390f72..8be4692 100644
--- a/src/gallium/auxiliary/vl/vl_winsys.h
+++ b/src/gallium/auxiliary/vl/vl_winsys.h
@@ -86,7 +86,4 @@ vl_dri2_screen_create(Display *display, int screen);
 struct vl_screen *
 vl_drm_screen_create(int fd);
 
-void
-vl_drm_screen_destroy(struct vl_screen *vscreen);
-
 #endif
diff --git a/src/gallium/auxiliary/vl/vl_winsys_drm.c 
b/src/gallium/auxiliary/vl/vl_winsys_drm.c
index b9efc9a..c96187b 100644
--- a/src/gallium/auxiliary/vl/vl_winsys_drm.c
+++ b/src/gallium/auxiliary/vl/vl_winsys_drm.c
@@ -34,7 +34,10 @@
 #include "util/u_memory.h"
 #include "vl/vl_winsys.h"
 
-struct vl_screen*
+static void
+vl_drm_screen_destroy(struct vl_screen *vscreen);
+
+struct vl_screen *
 vl_drm_screen_create(int fd)
 {
struct vl_screen *vscreen;
@@ -72,7 +75,7 @@ error:
return NULL;
 }
 
-void
+static void
 vl_drm_screen_destroy(struct vl_screen *vscreen)
 {
assert(vscreen);
-- 
2.6.2

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

[Mesa-dev] [PATCH 08/13] st/va: use the vl_screen dispatch

[Emil Velikov]

Signed-off-by: Emil Velikov 
---
 src/gallium/state_trackers/va/context.c | 10 ++
 src/gallium/state_trackers/va/picture.c |  2 +-
 src/gallium/state_trackers/va/surface.c | 13 ++---
 3 files changed, 9 insertions(+), 16 deletions(-)

diff --git a/src/gallium/state_trackers/va/context.c 
b/src/gallium/state_trackers/va/context.c
index 0709dfb..f0051e5 100644
--- a/src/gallium/state_trackers/va/context.c
+++ b/src/gallium/state_trackers/va/context.c
@@ -175,10 +175,7 @@ error_htab:
drv->pipe->destroy(drv->pipe);
 
 error_pipe:
-   if (ctx->display_type == VA_DISPLAY_GLX || ctx->display_type == 
VA_DISPLAY_X11)
-  vl_screen_destroy(drv->vscreen);
-   else
-  vl_drm_screen_destroy(drv->vscreen);
+   drv->vscreen->destroy(drv->vscreen);
 
 error_screen:
FREE(drv);
@@ -315,10 +312,7 @@ vlVaTerminate(VADriverContextP ctx)
vl_compositor_cleanup_state(>cstate);
vl_compositor_cleanup(>compositor);
drv->pipe->destroy(drv->pipe);
-   if (ctx->display_type == VA_DISPLAY_GLX || ctx->display_type == 
VA_DISPLAY_X11)
-  vl_screen_destroy(drv->vscreen);
-   else
-  vl_drm_screen_destroy(drv->vscreen);
+   drv->vscreen->destroy(drv->vscreen);
handle_table_destroy(drv->htab);
FREE(drv);
 
diff --git a/src/gallium/state_trackers/va/picture.c 
b/src/gallium/state_trackers/va/picture.c
index 5e7841a..a37a9b7 100644
--- a/src/gallium/state_trackers/va/picture.c
+++ b/src/gallium/state_trackers/va/picture.c
@@ -763,7 +763,7 @@ handleVAProcPipelineParameterBufferType(vlVaDriver *drv, 
vlVaContext *context, v
dst_rect.x1 = pipeline_param->output_region->x + 
pipeline_param->output_region->width;
dst_rect.y1 = pipeline_param->output_region->y + 
pipeline_param->output_region->height;
 
-   dirty_area = vl_screen_get_dirty_area(drv->vscreen);
+   dirty_area = drv->vscreen->get_dirty_area(drv->vscreen);
 
vl_compositor_clear_layers(>cstate);
vl_compositor_set_buffer_layer(>cstate, >compositor, 0, 
src_surface->buffer, _rect, NULL, VL_COMPOSITOR_WEAVE);
diff --git a/src/gallium/state_trackers/va/surface.c 
b/src/gallium/state_trackers/va/surface.c
index 589d686..c052c8f 100644
--- a/src/gallium/state_trackers/va/surface.c
+++ b/src/gallium/state_trackers/va/surface.c
@@ -229,6 +229,7 @@ vlVaPutSurface(VADriverContextP ctx, VASurfaceID 
surface_id, void* draw, short s
struct pipe_screen *screen;
struct pipe_resource *tex;
struct pipe_surface surf_templ, *surf_draw;
+   struct vl_screen *vscreen;
struct u_rect src_rect, *dirty_area;
struct u_rect dst_rect = {destx, destx + destw, desty, desty + desth};
VAStatus status;
@@ -242,17 +243,18 @@ vlVaPutSurface(VADriverContextP ctx, VASurfaceID 
surface_id, void* draw, short s
   return VA_STATUS_ERROR_INVALID_SURFACE;
 
screen = drv->pipe->screen;
+   vscreen = drv->vscreen;
 
if(surf->fence) {
   screen->fence_finish(screen, surf->fence, PIPE_TIMEOUT_INFINITE);
   screen->fence_reference(screen, >fence, NULL);
}
 
-   tex = vl_screen_texture_from_drawable(drv->vscreen, (Drawable)draw);
+   tex = vscreen->texture_from_drawable(vscreen, draw);
if (!tex)
   return VA_STATUS_ERROR_INVALID_DISPLAY;
 
-   dirty_area = vl_screen_get_dirty_area(drv->vscreen);
+   dirty_area = vscreen->get_dirty_area(vscreen);
 
memset(_templ, 0, sizeof(surf_templ));
surf_templ.format = tex->format;
@@ -276,11 +278,8 @@ vlVaPutSurface(VADriverContextP ctx, VASurfaceID 
surface_id, void* draw, short s
if (status)
   return status;
 
-   screen->flush_frontbuffer
-   (
-  screen, tex, 0, 0,
-  vl_screen_get_private(drv->vscreen), NULL
-   );
+   screen->flush_frontbuffer(screen, tex, 0, 0,
+ vscreen->get_private(vscreen), NULL);
 
screen->fence_reference(screen, >fence, NULL);
drv->pipe->flush(drv->pipe, >fence, 0);
-- 
2.6.2

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

[Mesa-dev] [PATCH 03/13] auxiliary/vl: add dispatch table

[Emil Velikov]

As mentioned previously, it will allow us to use different vl backend in
a generic way from either video state-tracker.

Signed-off-by: Emil Velikov 
---
 src/gallium/auxiliary/vl/vl_winsys.h | 17 +
 1 file changed, 17 insertions(+)

diff --git a/src/gallium/auxiliary/vl/vl_winsys.h 
b/src/gallium/auxiliary/vl/vl_winsys.h
index 9aa65ad..29da320 100644
--- a/src/gallium/auxiliary/vl/vl_winsys.h
+++ b/src/gallium/auxiliary/vl/vl_winsys.h
@@ -42,6 +42,23 @@ struct pipe_loader_device;
 
 struct vl_screen
 {
+   void (*destroy)(struct vl_screen *vscreen);
+
+   struct pipe_resource *
+   (*texture_from_drawable)(struct vl_screen *vscreen, void *drawable);
+
+   struct u_rect *
+   (*get_dirty_area)(struct vl_screen *vscreen);
+
+   uint64_t
+   (*get_timestamp)(struct vl_screen *vscreen, void *drawable);
+
+   void
+   (*set_next_timestamp)(struct vl_screen *vscreen, uint64_t stamp);
+
+   void *
+   (*get_private)(struct vl_screen *vscreen);
+
struct pipe_screen *pscreen;
struct pipe_loader_device *dev;
 };
-- 
2.6.2

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

[Mesa-dev] [PATCH 02/13] auxiliary/vl: rename vl_screen_create to vl_dri2_screen_create

[Emil Velikov]

In a preparation of having proper multiplatform/backend handling in VL.

With follow up commits we'll introduce a dispatch within vl_screen
similar to the one in pipe_screen. This way any VL state-tracker can
overate seemlessly, considering the backend/platform is properly setup.

Signed-off-by: Emil Velikov 
---
 src/gallium/auxiliary/vl/vl_winsys.h| 6 +++---
 src/gallium/auxiliary/vl/vl_winsys_dri.c| 2 +-
 src/gallium/state_trackers/omx/entrypoint.c | 2 +-
 src/gallium/state_trackers/va/context.c | 2 +-
 src/gallium/state_trackers/vdpau/device.c   | 2 +-
 src/gallium/state_trackers/xvmc/context.c   | 2 +-
 6 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/src/gallium/auxiliary/vl/vl_winsys.h 
b/src/gallium/auxiliary/vl/vl_winsys.h
index df01917..9aa65ad 100644
--- a/src/gallium/auxiliary/vl/vl_winsys.h
+++ b/src/gallium/auxiliary/vl/vl_winsys.h
@@ -46,9 +46,6 @@ struct vl_screen
struct pipe_loader_device *dev;
 };
 
-struct vl_screen*
-vl_screen_create(Display *display, int screen);
-
 void vl_screen_destroy(struct vl_screen *vscreen);
 
 struct pipe_resource*
@@ -67,6 +64,9 @@ void*
 vl_screen_get_private(struct vl_screen *vscreen);
 
 struct vl_screen*
+vl_dri2_screen_create(Display *display, int screen);
+
+struct vl_screen *
 vl_drm_screen_create(int fd);
 
 void
diff --git a/src/gallium/auxiliary/vl/vl_winsys_dri.c 
b/src/gallium/auxiliary/vl/vl_winsys_dri.c
index 3b1b87f..46f5816 100644
--- a/src/gallium/auxiliary/vl/vl_winsys_dri.c
+++ b/src/gallium/auxiliary/vl/vl_winsys_dri.c
@@ -306,7 +306,7 @@ get_xcb_screen(xcb_screen_iterator_t iter, int screen)
 }
 
 struct vl_screen*
-vl_screen_create(Display *display, int screen)
+vl_dri2_screen_create(Display *display, int screen)
 {
struct vl_dri_screen *scrn;
const xcb_query_extension_reply_t *extension;
diff --git a/src/gallium/state_trackers/omx/entrypoint.c 
b/src/gallium/state_trackers/omx/entrypoint.c
index f99a620..d369cec 100644
--- a/src/gallium/state_trackers/omx/entrypoint.c
+++ b/src/gallium/state_trackers/omx/entrypoint.c
@@ -100,7 +100,7 @@ struct vl_screen *omx_get_screen(void)
  if (!omx_display)
 goto error;
 
- omx_screen = vl_screen_create(omx_display, 0);
+ omx_screen = vl_dri2_screen_create(omx_display, 0);
  if (!omx_screen) {
 XCloseDisplay(omx_display);
 goto error;
diff --git a/src/gallium/state_trackers/va/context.c 
b/src/gallium/state_trackers/va/context.c
index 04ca2f2..0709dfb 100644
--- a/src/gallium/state_trackers/va/context.c
+++ b/src/gallium/state_trackers/va/context.c
@@ -118,7 +118,7 @@ VA_DRIVER_INIT_FUNC(VADriverContextP ctx)
   return VA_STATUS_ERROR_UNIMPLEMENTED;
case VA_DISPLAY_GLX:
case VA_DISPLAY_X11:
-  drv->vscreen = vl_screen_create(ctx->native_dpy, ctx->x11_screen);
+  drv->vscreen = vl_dri2_screen_create(ctx->native_dpy, ctx->x11_screen);
   if (!drv->vscreen)
  goto error_screen;
   break;
diff --git a/src/gallium/state_trackers/vdpau/device.c 
b/src/gallium/state_trackers/vdpau/device.c
index 31c9505..8fda388 100644
--- a/src/gallium/state_trackers/vdpau/device.c
+++ b/src/gallium/state_trackers/vdpau/device.c
@@ -63,7 +63,7 @@ vdp_imp_device_create_x11(Display *display, int screen, 
VdpDevice *device,
 
pipe_reference_init(>reference, 1);
 
-   dev->vscreen = vl_screen_create(display, screen);
+   dev->vscreen = vl_dri2_screen_create(display, screen);
if (!dev->vscreen) {
   ret = VDP_STATUS_RESOURCES;
   goto no_vscreen;
diff --git a/src/gallium/state_trackers/xvmc/context.c 
b/src/gallium/state_trackers/xvmc/context.c
index 4702b44..07b33e4 100644
--- a/src/gallium/state_trackers/xvmc/context.c
+++ b/src/gallium/state_trackers/xvmc/context.c
@@ -229,7 +229,7 @@ Status XvMCCreateContext(Display *dpy, XvPortID port, int 
surface_type_id,
   return BadAlloc;
 
/* TODO: Reuse screen if process creates another context */
-   vscreen = vl_screen_create(dpy, scrn);
+   vscreen = vl_dri2_screen_create(dpy, scrn);
 
if (!vscreen) {
   XVMC_MSG(XVMC_ERR, "[XvMC] Could not create VL screen.\n");
-- 
2.6.2

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

[Mesa-dev] [PATCH 12/13] auxiliary/vl/dri2: hide internal functions

[Emil Velikov]

Analogous to previous commit. While we're here prefix all functions
identically -> vl_dri2_foo

Signed-off-by: Emil Velikov 
---
 src/gallium/auxiliary/vl/vl_winsys.h | 17 ---
 src/gallium/auxiliary/vl/vl_winsys_dri.c | 37 +---
 2 files changed, 20 insertions(+), 34 deletions(-)

diff --git a/src/gallium/auxiliary/vl/vl_winsys.h 
b/src/gallium/auxiliary/vl/vl_winsys.h
index 8be4692..7d3c941 100644
--- a/src/gallium/auxiliary/vl/vl_winsys.h
+++ b/src/gallium/auxiliary/vl/vl_winsys.h
@@ -63,23 +63,6 @@ struct vl_screen
struct pipe_loader_device *dev;
 };
 
-void vl_screen_destroy(struct vl_screen *vscreen);
-
-struct pipe_resource*
-vl_screen_texture_from_drawable(struct vl_screen *vscreen, void *drawable);
-
-struct u_rect *
-vl_screen_get_dirty_area(struct vl_screen *vscreen);
-
-uint64_t
-vl_screen_get_timestamp(struct vl_screen *vscreen, void *drawable);
-
-void
-vl_screen_set_next_timestamp(struct vl_screen *vscreen, uint64_t stamp);
-
-void*
-vl_screen_get_private(struct vl_screen *vscreen);
-
 struct vl_screen*
 vl_dri2_screen_create(Display *display, int screen);
 
diff --git a/src/gallium/auxiliary/vl/vl_winsys_dri.c 
b/src/gallium/auxiliary/vl/vl_winsys_dri.c
index 12f7887..098b9a9 100644
--- a/src/gallium/auxiliary/vl/vl_winsys_dri.c
+++ b/src/gallium/auxiliary/vl/vl_winsys_dri.c
@@ -75,6 +75,8 @@ struct vl_dri_screen
 
 static const unsigned int attachments[1] = { 
XCB_DRI2_ATTACHMENT_BUFFER_BACK_LEFT };
 
+static void vl_dri2_screen_destroy(struct vl_screen *vscreen);
+
 static void
 vl_dri2_handle_stamps(struct vl_dri_screen* scrn,
   uint32_t ust_hi, uint32_t ust_lo,
@@ -170,8 +172,8 @@ vl_dri2_set_drawable(struct vl_dri_screen *scrn, Drawable 
drawable)
scrn->drawable = drawable;
 }
 
-struct pipe_resource*
-vl_screen_texture_from_drawable(struct vl_screen *vscreen, void *drawable)
+static struct pipe_resource *
+vl_dri2_screen_texture_from_drawable(struct vl_screen *vscreen, void *drawable)
 {
struct vl_dri_screen *scrn = (struct vl_dri_screen*)vscreen;
 
@@ -248,16 +250,16 @@ vl_screen_texture_from_drawable(struct vl_screen 
*vscreen, void *drawable)
return tex;
 }
 
-struct u_rect *
-vl_screen_get_dirty_area(struct vl_screen *vscreen)
+static struct u_rect *
+vl_dri2_screen_get_dirty_area(struct vl_screen *vscreen)
 {
struct vl_dri_screen *scrn = (struct vl_dri_screen*)vscreen;
assert(scrn);
return >dirty_areas[scrn->current_buffer];
 }
 
-uint64_t
-vl_screen_get_timestamp(struct vl_screen *vscreen, void *drawable)
+static uint64_t
+vl_dri2_screen_get_timestamp(struct vl_screen *vscreen, void *drawable)
 {
struct vl_dri_screen *scrn = (struct vl_dri_screen*)vscreen;
xcb_dri2_get_msc_cookie_t cookie;
@@ -279,8 +281,8 @@ vl_screen_get_timestamp(struct vl_screen *vscreen, void 
*drawable)
return scrn->last_ust;
 }
 
-void
-vl_screen_set_next_timestamp(struct vl_screen *vscreen, uint64_t stamp)
+static void
+vl_dri2_screen_set_next_timestamp(struct vl_screen *vscreen, uint64_t stamp)
 {
struct vl_dri_screen *scrn = (struct vl_dri_screen*)vscreen;
assert(scrn);
@@ -290,8 +292,8 @@ vl_screen_set_next_timestamp(struct vl_screen *vscreen, 
uint64_t stamp)
   scrn->next_msc = 0;
 }
 
-void*
-vl_screen_get_private(struct vl_screen *vscreen)
+static void *
+vl_dri2_screen_get_private(struct vl_screen *vscreen)
 {
return vscreen;
 }
@@ -398,12 +400,12 @@ vl_dri2_screen_create(Display *display, int screen)
if (!scrn->base.pscreen)
   goto release_pipe;
 
-   scrn->base.destroy = vl_screen_destroy;
-   scrn->base.texture_from_drawable = vl_screen_texture_from_drawable;
-   scrn->base.get_dirty_area = vl_screen_get_dirty_area;
-   scrn->base.get_timestamp = vl_screen_get_timestamp;
-   scrn->base.set_next_timestamp = vl_screen_set_next_timestamp;
-   scrn->base.get_private = vl_screen_get_private;
+   scrn->base.destroy = vl_dri2_screen_destroy;
+   scrn->base.texture_from_drawable = vl_dri2_screen_texture_from_drawable;
+   scrn->base.get_dirty_area = vl_dri2_screen_get_dirty_area;
+   scrn->base.get_timestamp = vl_dri2_screen_get_timestamp;
+   scrn->base.set_next_timestamp = vl_dri2_screen_set_next_timestamp;
+   scrn->base.get_private = vl_dri2_screen_get_private;
scrn->base.pscreen->flush_frontbuffer = vl_dri2_flush_frontbuffer;
vl_compositor_reset_dirty_area(>dirty_areas[0]);
vl_compositor_reset_dirty_area(>dirty_areas[1]);
@@ -433,7 +435,8 @@ free_screen:
return NULL;
 }
 
-void vl_screen_destroy(struct vl_screen *vscreen)
+static void
+vl_dri2_screen_destroy(struct vl_screen *vscreen)
 {
struct vl_dri_screen *scrn = (struct vl_dri_screen*)vscreen;
 
-- 
2.6.2

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

[Mesa-dev] [PATCH 09/13] st/xvmc: use the vl_screen dispatch

[Emil Velikov]

Signed-off-by: Emil Velikov 
---
 src/gallium/state_trackers/xvmc/context.c | 10 +-
 src/gallium/state_trackers/xvmc/surface.c | 13 ++---
 2 files changed, 11 insertions(+), 12 deletions(-)

diff --git a/src/gallium/state_trackers/xvmc/context.c 
b/src/gallium/state_trackers/xvmc/context.c
index 07b33e4..a6991ab 100644
--- a/src/gallium/state_trackers/xvmc/context.c
+++ b/src/gallium/state_trackers/xvmc/context.c
@@ -240,7 +240,7 @@ Status XvMCCreateContext(Display *dpy, XvPortID port, int 
surface_type_id,
pipe = vscreen->pscreen->context_create(vscreen->pscreen, vscreen, 0);
if (!pipe) {
   XVMC_MSG(XVMC_ERR, "[XvMC] Could not create VL context.\n");
-  vl_screen_destroy(vscreen);
+  vscreen->destroy(vscreen);
   FREE(context_priv);
   return BadAlloc;
}
@@ -258,7 +258,7 @@ Status XvMCCreateContext(Display *dpy, XvPortID port, int 
surface_type_id,
if (!context_priv->decoder) {
   XVMC_MSG(XVMC_ERR, "[XvMC] Could not create VL decoder.\n");
   pipe->destroy(pipe);
-  vl_screen_destroy(vscreen);
+  vscreen->destroy(vscreen);
   FREE(context_priv);
   return BadAlloc;
}
@@ -267,7 +267,7 @@ Status XvMCCreateContext(Display *dpy, XvPortID port, int 
surface_type_id,
   XVMC_MSG(XVMC_ERR, "[XvMC] Could not create VL compositor.\n");
   context_priv->decoder->destroy(context_priv->decoder);
   pipe->destroy(pipe);
-  vl_screen_destroy(vscreen);
+  vscreen->destroy(vscreen);
   FREE(context_priv);
   return BadAlloc;
}
@@ -277,7 +277,7 @@ Status XvMCCreateContext(Display *dpy, XvPortID port, int 
surface_type_id,
   vl_compositor_cleanup(_priv->compositor);
   context_priv->decoder->destroy(context_priv->decoder);
   pipe->destroy(pipe);
-  vl_screen_destroy(vscreen);
+  vscreen->destroy(vscreen);
   FREE(context_priv);
   return BadAlloc;
}
@@ -332,7 +332,7 @@ Status XvMCDestroyContext(Display *dpy, XvMCContext 
*context)
vl_compositor_cleanup_state(_priv->cstate);
vl_compositor_cleanup(_priv->compositor);
context_priv->pipe->destroy(context_priv->pipe);
-   vl_screen_destroy(context_priv->vscreen);
+   context_priv->vscreen->destroy(context_priv->vscreen);
FREE(context_priv);
context->privData = NULL;
 
diff --git a/src/gallium/state_trackers/xvmc/surface.c 
b/src/gallium/state_trackers/xvmc/surface.c
index 15eae59..199712b 100644
--- a/src/gallium/state_trackers/xvmc/surface.c
+++ b/src/gallium/state_trackers/xvmc/surface.c
@@ -355,6 +355,7 @@ Status XvMCPutSurface(Display *dpy, XvMCSurface *surface, 
Drawable drawable,
struct pipe_context *pipe;
struct vl_compositor *compositor;
struct vl_compositor_state *cstate;
+   struct vl_screen *vscreen;
 
XvMCSurfacePrivate *surface_priv;
XvMCContextPrivate *context_priv;
@@ -386,9 +387,10 @@ Status XvMCPutSurface(Display *dpy, XvMCSurface *surface, 
Drawable drawable,
pipe = context_priv->pipe;
compositor = _priv->compositor;
cstate = _priv->cstate;
+   vscreen = context_priv->vscreen;
 
-   tex = vl_screen_texture_from_drawable(context_priv->vscreen, drawable);
-   dirty_area = vl_screen_get_dirty_area(context_priv->vscreen);
+   tex = vscreen->texture_from_drawable(vscreen, (void *)drawable);
+   dirty_area = vscreen->get_dirty_area(vscreen);
 
memset(_templ, 0, sizeof(surf_templ));
surf_templ.format = tex->format;
@@ -444,11 +446,8 @@ Status XvMCPutSurface(Display *dpy, XvMCSurface *surface, 
Drawable drawable,
 
XVMC_MSG(XVMC_TRACE, "[XvMC] Submitted surface %p for display. Pushing to 
front buffer.\n", surface);
 
-   pipe->screen->flush_frontbuffer
-   (
-  pipe->screen, tex, 0, 0,
-  vl_screen_get_private(context_priv->vscreen), NULL
-   );
+   pipe->screen->flush_frontbuffer(pipe->screen, tex, 0, 0,
+   vscreen->get_private(vscreen), NULL);
 
if(dump_window == -1) {
   dump_window = debug_get_num_option("XVMC_DUMP", 0);
-- 
2.6.2

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

[Mesa-dev] [PATCH 00/13] auxiliary/vl: winsys' galore

[Emil Velikov]

Hi all,

Inspired by the resent interest in alternative vl winsys, I've decided 
to rework the winsys into a traditional gallium fashion.

Namely: add the destroy() and other functions into struct vl_screen. 
This will allow users (state-trackers) to call the 
vl_foo_screen_create() entry point and do the rest in a generic manner.

It will also ease the introduction of other winsys (dri3, wayland, 
android anyone ?) into the module. As a follow up one can even remove 
the static linking to xcb and friends, with a dlopen/dlsym combo.

The lot can be found in branch 'hello-vl' at
https://github.com/evelikov/mesa

Comments, suggestions and bikeshed wars are welcome.

Emil

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

[Mesa-dev] [PATCH 05/13] auxiliary/vl/drm: use a label for the error path

[Emil Velikov]

... just like every other place in gallium.

Signed-off-by: Emil Velikov 
---
 src/gallium/auxiliary/vl/vl_winsys_drm.c | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/src/gallium/auxiliary/vl/vl_winsys_drm.c 
b/src/gallium/auxiliary/vl/vl_winsys_drm.c
index 2ebf20c..b9efc9a 100644
--- a/src/gallium/auxiliary/vl/vl_winsys_drm.c
+++ b/src/gallium/auxiliary/vl/vl_winsys_drm.c
@@ -49,15 +49,11 @@ vl_drm_screen_create(int fd)
if (pipe_loader_drm_probe_fd(>dev, dup(fd))) {
   vscreen->pscreen =
  pipe_loader_create_screen(vscreen->dev, PIPE_SEARCH_DIR);
-  if (!vscreen->pscreen)
- pipe_loader_release(>dev, 1);
}
 #endif
 
-   if (!vscreen->pscreen) {
-  FREE(vscreen);
-  return NULL;
-   }
+   if (!vscreen->pscreen)
+  goto error;
 
vscreen->destroy = vl_drm_screen_destroy;
vscreen->texture_from_drawable = NULL;
@@ -66,6 +62,14 @@ vl_drm_screen_create(int fd)
vscreen->set_next_timestamp = NULL;
vscreen->get_private = NULL;
return vscreen;
+
+error:
+#if !GALLIUM_STATIC_TARGETS
+   if (vscreen->dev)
+  pipe_loader_release(>dev, 1);
+#endif // !GALLIUM_STATIC_TARGETS
+   FREE(vscreen);
+   return NULL;
 }
 
 void
-- 
2.6.2

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

Re: [Mesa-dev] [PATCH 4/7] i965/fs: Use image_format_info for doing image_load_store workarounds

[Chad Versace]

On Wed 04 Nov 2015, Jason Ekstrand wrote:
> ---
>  .../drivers/dri/i965/brw_fs_surface_builder.cpp| 157 
> ++---
>  1 file changed, 106 insertions(+), 51 deletions(-)
> 
> diff --git a/src/mesa/drivers/dri/i965/brw_fs_surface_builder.cpp 
> b/src/mesa/drivers/dri/i965/brw_fs_surface_builder.cpp
> index 31ecb5b..d841ffe 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs_surface_builder.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs_surface_builder.cpp
> @@ -22,6 +22,9 @@
>   */
>  
>  #include "brw_fs_surface_builder.h"
> +#include "intel_mipmap_tree.h"
> +#include "brw_state.h"
> +#include "brw_image_load_store.h"
>  #include "brw_fs.h"
>  
>  using namespace brw;
> @@ -192,32 +195,80 @@ namespace {
> * Return the per-channel bitfield widths for a given image format.
> */
>inline color_u
> -  get_bit_widths(mesa_format format)
> +  get_bit_widths(uint32_t brw_format)
>{
> - return color_u(_mesa_get_format_bits(format, GL_RED_BITS),
> -_mesa_get_format_bits(format, GL_GREEN_BITS),
> -_mesa_get_format_bits(format, GL_BLUE_BITS),
> -_mesa_get_format_bits(format, GL_ALPHA_BITS));
> + return color_u(brw_image_format_info[brw_format].red_bits,
> +brw_image_format_info[brw_format].green_bits,
> +brw_image_format_info[brw_format].blue_bits,
> +brw_image_format_info[brw_format].alpha_bits);
>}
>  
>/**
> * Return the per-channel bitfield shifts for a given image format.
> */
>inline color_u
> -  get_bit_shifts(mesa_format format)
> +  get_bit_shifts(uint32_t brw_format)
>{
> - const color_u widths = get_bit_widths(format);
> + const color_u widths = get_bit_widths(brw_format);
>   return color_u(0, widths.r, widths.r + widths.g,
>  widths.r + widths.g + widths.b);
>}
>  
> +  inline unsigned
> +  get_format_bytes(uint32_t brw_format)
> +  {
> + return (brw_image_format_info[brw_format].red_bits +
> + brw_image_format_info[brw_format].green_bits +
> + brw_image_format_info[brw_format].blue_bits +
> + brw_image_format_info[brw_format].alpha_bits) / 8;

For general formats, this calculation is wrong. I assume this function
is used only for RGBA-formats, though, which makes the function correct.

I have the same comment for other hunks in this patch too.

> +  }
> +
> +  inline unsigned
> +  get_format_num_components(uint32_t brw_format)
> +  {
> + if (brw_image_format_info[brw_format].green_bits == 0) {
> +return 1;
> + } else if (brw_image_format_info[brw_format].blue_bits == 0) {
> +return 2;
> + } else {
> +return 4;
> + }

This function needs a case for alpha. Either

} else if (brw_image_format_info[brw_format].alpha_bits == 0) {
return 3;
}

or

} else {
assert(brw_image_format_info[brw_format].alpha_bits > 0);
return 4;
}


The rest of the patch looked good to me.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] soft/llvmpipe front buffer access and piglit regressions

[Dave Airlie]

On 10 November 2015 at 06:36, Brian Paul  wrote:
> On 11/09/2015 01:15 PM, Dave Airlie wrote:
>>
>> On 10 November 2015 at 00:30, Roland Scheidegger 
>> wrote:
>>>
>>> Am 09.11.2015 um 04:44 schrieb Dave Airlie:

 So it appears my patch to enable front buffer access on soft/llvmpipe
 causes some piglit regressions. However these are due to piglit having
 undefined behaviour where it doesn't create a window but has tests
 requiring a front buffer. The new code does an XGetImage on the front
 buffer and when it fails all sorts of bad things tend to happen. I
 don't think there is a way to check if we have a window mapped inside
 Mesa to avoid this path.

 swrast suffers from the same failure pattern in a number of tests when
 run with -auto.

 I'm not sure what to do here, the patch is making the driver
 conformant and is fixing a missing
 feature being used by OpenGL apps (gtk).

 I can probably make it fail more gracefully (llvmpipe deadlocks on the
 Xlib error path inside it's rasteriser threads), but I'm not sure I
 want to go back to the old behaviour just to satisfy piglit's
 requirement to do undefined things.

>>>
>>> I don't really understand all this interface stuff, however it feels
>>> wrong to me that we have to care in the driver for something which you
>>> say is totally bogus. Couldn't that be handled outside? Albeit I don't
>>> really understand what exactly happens in the first place.
>>
>>
>> Well the bug is piglit runs tests without mapping the window. On DRI2
>> this works as we have the fake front buffer, so reading the front doesn't
>> require content on the screen. However it's really undefined behaviour for
>> GL.
>>
>> Now with drisw you use GetImage/PutImage to get things from the real front
>> buffer. However if the window is never mapped, these will return BadMatch,
>> and things fall over. However we have real apps wanting proper front
>> buffer
>> interactions, and we have piglit wanting the undefined behaviour.
>
>
> The old xlib/swrast code has an X error handler to catch failing XGetImage
> calls.  We probably need something like that.  See xm_buffer.c's
> xmesa_MapRenderbuffer().

The DRI swrast driver on the other hand doesn't. Granted it also fails all these
tests with XGetImage.The question is whether using an error handler is prone
to all sorts of race conditions and other problems, I'm guessing it would be.

>
> It also sounds like the piglit tests in question need to be fixed somehow.

It's all of piglit, see the nvidia guys talking about pixel ownership as well.
piglit executes tests in a undefined environment with -auto wrt OpenGL,
it works for us now on DRI2.

Granted even with that fixed, some tests do fail, due to tests alpha channel
on the front buffer, which we sort of lose when we use Put/GetImage from
what I can see.

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

[Mesa-dev] [Bug 92869] OpenGL ES 3.0 context creation failure

[bugzilla-daemon]

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

--- Comment #2 from Gustaf Ullberg  ---
Thanks José,

Interesting to see that you have been working on this already. So, what is the
current status? Is the patch ready to be merged after some testing or is it
controversial or incomplete in any way?

If "only testing remains" I'll be happy to try to help out.

-- 
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
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFCv2 03/13] nir: allow pre-resolved sampler uniform locations

[Timothy Arceri]

On Mon, 2015-11-09 at 07:43 -0500, Rob Clark wrote:
> On Sun, Nov 8, 2015 at 7:58 PM, Timothy Arceri 
> wrote:
> > On Sun, 2015-11-08 at 15:12 -0500, Rob Clark wrote:
> > > From: Rob Clark 
> > > 
> > > With TGSI, the ir_variable::data.location gets fixed up to be a stage
> > > local location (rather than program global).  In this case we need to
> > > skip the UniformStorage[location] lookup.
> > > ---
> > >  src/glsl/nir/nir_lower_samplers.c | 23 ---
> > >  1 file changed, 16 insertions(+), 7 deletions(-)
> > > 
> > > diff --git a/src/glsl/nir/nir_lower_samplers.c
> > > b/src/glsl/nir/nir_lower_samplers.c
> > > index 5df79a6..d99ba4c 100644
> > > --- a/src/glsl/nir/nir_lower_samplers.c
> > > +++ b/src/glsl/nir/nir_lower_samplers.c
> > > @@ -130,14 +130,18 @@ lower_sampler(nir_tex_instr *instr, const struct
> > > gl_shader_program *shader_progr
> > >instr->sampler_array_size = array_elements;
> > > }
> > > 
> > > -   if (location > shader_program->NumUniformStorage - 1 ||
> > > -   !shader_program->UniformStorage[location].opaque[stage].active)
> > > {
> > > -  assert(!"cannot return a sampler");
> > > -  return;
> > > -   }
> > > +   if (!shader_program) {
> > > +  instr->sampler_index = location;
> > > +   } else {
> > > +  if (location > shader_program->NumUniformStorage - 1 ||
> > > +  !shader_program
> > > ->UniformStorage[location].opaque[stage].active) {
> > > + assert(!"cannot return a sampler");
> > > + return;
> > > +  }
> > > 
> > > -   instr->sampler_index +=
> > > -  shader_program->UniformStorage[location].opaque[stage].index;
> > > +  instr->sampler_index =
> > > + shader_program->UniformStorage[location].opaque[stage].index;
> > 
> > Hi Rob,
> > 
> > This will break arrays as instr->sampler_index is increamented inside
> >  calc_sampler_offsets()
> 
> oh, whoops, I didn't notice that.. ok, that part is easy enough to fix..
> 
> > calc_sampler_offsets() also modifies the value of location is this what
> > you
> > want? I would assume not as we are counting uniforms not just samplers
> > here.
> 
> hmm, tbh I'm not entirely sure..  offhand, what piglit's should I
> check? 

tests/spec/arb_gpu_shader5/execution/sampler_array_indexing

Contains the tests you probably want to try out.

>  I guess it would be easier to debug if it worked correctly
> with glsl_to_tgsi, but I guess I could try to get the non-indirect
> case working..
> 
> BR,
> -R
> 
> > The other thing to note is that glsl to tgsi doesn't handle indirects on
> > structs or arrays of arrays correctly (Ilia was trying to fix this).
> > 
> > Tim
> > 
> > 
> > 
> > > +   }
> > > 
> > > instr->sampler = NULL;
> > >  }
> > > @@ -177,6 +181,11 @@ lower_impl(nir_function_impl *impl, const struct
> > > gl_shader_program *shader_progr
> > > nir_foreach_block(impl, lower_block_cb, );
> > >  }
> > > 
> > > +/* Call with a null 'shader_program' if uniform locations are
> > 
> > uniform locations -> sampler indices?
> > 
> > > + * already local to the shader, ie. skipping the
> > > + * shader_program->UniformStorage[location].opaque[stage].index
> > > + * lookup
> > > + */
> > >  void
> > >  nir_lower_samplers(nir_shader *shader,
> > > const struct gl_shader_program *shader_program)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Can't get OpenGL 3.x inside VMware Workstation 12 (Ubuntu guest)

[Brian Paul]

On 11/09/2015 05:01 PM, Valera Rozuvan wrote:

Hi,

I have been trying to follow the instructions from the page
http://www.mesa3d.org/vmware-guest.html . My host OS is Windows 7, which
has OpenGL 4.3 and DX11, my Guest OS is Ubuntu 15.10 with custom Linux
kernel 4.3. Please see detailed output from various host Ubuntu
subsystems at http://pastebin.com/Kukct9Xn . Also, I have dual GPU:
Intel(R) HD Graphics 4600 and NVIDIA GeForce GT 750M.

I have followed all of the instructions, but sill get OpenGL 2.1. What
else can I try?

By the way, on the page http://www.mesa3d.org/vmware-guest.html the step:

sudo cp 00-vmwgfx.rules /etc/udev/rules.d

can't be completed, because the file 00-vmwgfx.rules is not in the
vmwgfx folder. I got this file from
http://sourceforge.net/p/thinstation/thinstation-5/ci/c9c66d2e93fed90fa0c985df93adf3e66522bda5/tree/ts/5.2/packages/systemd/build/extra/etc/udev/rules.d/00-vmwgfx.rules
. Is this acceptable?


I need to update the docs.  The 00-vmwgfx.rules file is no longer needed.




Also, the command "sudo depmod -ae" complains about improper command
line options.


depmod -a should be enough.




Any input on my problem will be very welcome!


After running depmod, you probably need to update the initramfs with: 
'sudo update-initramfs -u'


-Brian

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

Re: [Mesa-dev] [PATCH 2/7] radeonsi: set the DISABLE_WR_CONFIRM flag on CI-VI as well

[Michel Dänzer]

On 09.11.2015 06:45, Marek Olšák wrote:
> From: Marek Olšák 
> 
> I missed this in commit c3e527f93d4281ad6e2ca165eaf6ff588e4faefa
> radeonsi: only enable write confirmation on the last CP DMA packet
> ---
>  src/gallium/drivers/radeonsi/si_cp_dma.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/src/gallium/drivers/radeonsi/si_cp_dma.c 
> b/src/gallium/drivers/radeonsi/si_cp_dma.c
> index 7b8c6d0..55d423a 100644
> --- a/src/gallium/drivers/radeonsi/si_cp_dma.c
> +++ b/src/gallium/drivers/radeonsi/si_cp_dma.c
> @@ -64,7 +64,7 @@ static void si_emit_cp_dma_copy_buffer(struct si_context 
> *sctx,
>   radeon_emit(cs, src_va >> 32);  /* SRC_ADDR_HI [31:0] */
>   radeon_emit(cs, dst_va);/* DST_ADDR_LO [31:0] */
>   radeon_emit(cs, dst_va >> 32);  /* DST_ADDR_HI [31:0] */
> - radeon_emit(cs, size | raw_wait);   /* COMMAND [29:22] | 
> BYTE_COUNT [20:0] */
> + radeon_emit(cs, size | wr_confirm |raw_wait);   /* COMMAND 
> [29:22] | BYTE_COUNT [20:0] */

Missing space after "|". With that fixed, this patch is

Reviewed-by: Michel Dänzer 


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

Re: [Mesa-dev] [PATCH v3] gallium/hud: control visibility at startup and runtime.

[Jimmy Berry]

On Mon, Nov 9, 2015 at 11:28 AM, Brian Paul  wrote:
> On 11/07/2015 09:05 PM, Jimmy Berry wrote:
>>
>> - env GALLIUM_HUD_VISIBLE: control default visibility
>> - env GALLIUM_HUD_SIGNAL_TOGGLE: toggle visibility via signal
>> ---
>>   docs/envvars.html   |  6 ++
>>   src/gallium/auxiliary/hud/hud_context.c | 28
>> 
>>   2 files changed, 34 insertions(+)
>>
>> diff --git a/docs/envvars.html b/docs/envvars.html
>> index bdfe999..530bbb7 100644
>> --- a/docs/envvars.html
>> +++ b/docs/envvars.html
>> @@ -179,6 +179,12 @@ Mesa EGL supports different sets of environment
>> variables.  See the
>>   GALLIUM_HUD - draws various information on the screen, like
>> framerate,
>>   cpu load, driver statistics, performance counters, etc.
>>   Set GALLIUM_HUD=help and run e.g. glxgears for more info.
>> +GALLIUM_HUD_VISIBLE - control default visibility, defaults to true.
>> +GALLIUM_HUD_TOGGLE_SIGNAL - toggle visibility via user specified
>> signal.
>> +Especially useful to toggle hud at specific points of application and
>> +disable for unencumbered viewing the rest of the time. For example,
>> set
>> +GALLIUM_HUD_VISIBLE to false and GALLIUM_HUD_SIGNAL_TOGGLE to 10
>> (SIGUSR1).
>> +Use kill -10  to toggle the hud as desired.
>>   GALLIUM_LOG_FILE - specifies a file for logging all errors,
>> warnings, etc.
>>   rather than stderr.
>>   GALLIUM_PRINT_OPTIONS - if non-zero, print all the Gallium
>> environment
>> diff --git a/src/gallium/auxiliary/hud/hud_context.c
>> b/src/gallium/auxiliary/hud/hud_context.c
>> index ffe30b8..31e55cd 100644
>> --- a/src/gallium/auxiliary/hud/hud_context.c
>> +++ b/src/gallium/auxiliary/hud/hud_context.c
>> @@ -33,6 +33,7 @@
>>* Set GALLIUM_HUD=help for more info.
>>*/
>>
>> +#include 
>>   #include 
>>
>>   #include "hud/hud_context.h"
>> @@ -51,6 +52,8 @@
>>   #include "tgsi/tgsi_text.h"
>>   #include "tgsi/tgsi_dump.h"
>>
>> +/* Control the visibility of all HUD contexts */
>> +static boolean huds_visible = TRUE;
>>
>>   struct hud_context {
>>  struct pipe_context *pipe;
>> @@ -95,6 +98,11 @@ struct hud_context {
>>  } text, bg, whitelines;
>>   };
>>
>> +static void
>> +signal_visible_handler(int sig, siginfo_t *siginfo, void *context)
>> +{
>> +   huds_visible = !huds_visible;
>> +}
>>
>>   static void
>>   hud_draw_colored_prims(struct hud_context *hud, unsigned prim,
>> @@ -441,6 +449,9 @@ hud_draw(struct hud_context *hud, struct pipe_resource
>> *tex)
>>  struct hud_pane *pane;
>>  struct hud_graph *gr;
>>
>> +   if (!huds_visible)
>> +  return;
>> +
>>  hud->fb_width = tex->width0;
>>  hud->fb_height = tex->height0;
>>  hud->constants.two_div_fb_width = 2.0f / hud->fb_width;
>> @@ -1125,6 +1136,10 @@ hud_create(struct pipe_context *pipe, struct
>> cso_context *cso)
>>  struct pipe_sampler_view view_templ;
>>  unsigned i;
>>  const char *env = debug_get_option("GALLIUM_HUD", NULL);
>> +   long signo = debug_get_num_option("GALLIUM_HUD_TOGGLE_SIGNAL", 0);
>> +   boolean sig_handled = FALSE;
>> +   struct sigaction action = {};
>> +   huds_visible = debug_get_bool_option("GALLIUM_HUD_VISIBLE", TRUE);
>>
>>  if (!env || !*env)
>> return NULL;
>> @@ -1267,6 +1282,19 @@ hud_create(struct pipe_context *pipe, struct
>> cso_context *cso)
>>
>>  LIST_INITHEAD(>pane_list);
>>
>> +   /* setup sig handler once for all hud contexts */
>> +   if (!sig_handled) {
>> +  action.sa_sigaction = _visible_handler;
>> +  action.sa_flags = SA_SIGINFO;
>> +
>> +  if (signo < 1 || signo >= NSIG)
>> + fprintf(stderr, "gallium_hud: invalid signal %ld\n", signo);
>> +  else if (sigaction(signo, , NULL) < 0)
>> + fprintf(stderr, "gallium_hud: unable to set handler for signal
>> %ld\n", signo);
>
>
> Can you put a fflush(stderr) call here?  Windows doesn't always immediately
> flush stdout/stderr output to the terminal.

Just directly after both of the conditions? See v6.

>
> -Brian
>
>
>> +
>> +  sig_handled = TRUE;
>> +   }
>> +
>>  hud_parse_env_var(hud, env);
>>  return hud;
>>   }
>>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 4/7] i965/fs: Use image_format_info for doing image_load_store workarounds

[Jason Ekstrand]

On Mon, Nov 9, 2015 at 2:24 PM, Chad Versace  wrote:
> On Wed 04 Nov 2015, Jason Ekstrand wrote:
>> ---
>>  .../drivers/dri/i965/brw_fs_surface_builder.cpp| 157 
>> ++---
>>  1 file changed, 106 insertions(+), 51 deletions(-)
>>
>> diff --git a/src/mesa/drivers/dri/i965/brw_fs_surface_builder.cpp 
>> b/src/mesa/drivers/dri/i965/brw_fs_surface_builder.cpp
>> index 31ecb5b..d841ffe 100644
>> --- a/src/mesa/drivers/dri/i965/brw_fs_surface_builder.cpp
>> +++ b/src/mesa/drivers/dri/i965/brw_fs_surface_builder.cpp
>> @@ -22,6 +22,9 @@
>>   */
>>
>>  #include "brw_fs_surface_builder.h"
>> +#include "intel_mipmap_tree.h"
>> +#include "brw_state.h"
>> +#include "brw_image_load_store.h"
>>  #include "brw_fs.h"
>>
>>  using namespace brw;
>> @@ -192,32 +195,80 @@ namespace {
>> * Return the per-channel bitfield widths for a given image format.
>> */
>>inline color_u
>> -  get_bit_widths(mesa_format format)
>> +  get_bit_widths(uint32_t brw_format)
>>{
>> - return color_u(_mesa_get_format_bits(format, GL_RED_BITS),
>> -_mesa_get_format_bits(format, GL_GREEN_BITS),
>> -_mesa_get_format_bits(format, GL_BLUE_BITS),
>> -_mesa_get_format_bits(format, GL_ALPHA_BITS));
>> + return color_u(brw_image_format_info[brw_format].red_bits,
>> +brw_image_format_info[brw_format].green_bits,
>> +brw_image_format_info[brw_format].blue_bits,
>> +brw_image_format_info[brw_format].alpha_bits);
>>}
>>
>>/**
>> * Return the per-channel bitfield shifts for a given image format.
>> */
>>inline color_u
>> -  get_bit_shifts(mesa_format format)
>> +  get_bit_shifts(uint32_t brw_format)
>>{
>> - const color_u widths = get_bit_widths(format);
>> + const color_u widths = get_bit_widths(brw_format);
>>   return color_u(0, widths.r, widths.r + widths.g,
>>  widths.r + widths.g + widths.b);
>>}
>>
>> +  inline unsigned
>> +  get_format_bytes(uint32_t brw_format)
>> +  {
>> + return (brw_image_format_info[brw_format].red_bits +
>> + brw_image_format_info[brw_format].green_bits +
>> + brw_image_format_info[brw_format].blue_bits +
>> + brw_image_format_info[brw_format].alpha_bits) / 8;
>
> For general formats, this calculation is wrong. I assume this function
> is used only for RGBA-formats, though, which makes the function correct.
>
> I have the same comment for other hunks in this patch too.
>
>> +  }
>> +
>> +  inline unsigned
>> +  get_format_num_components(uint32_t brw_format)
>> +  {
>> + if (brw_image_format_info[brw_format].green_bits == 0) {
>> +return 1;
>> + } else if (brw_image_format_info[brw_format].blue_bits == 0) {
>> +return 2;
>> + } else {
>> +return 4;
>> + }
>
> This function needs a case for alpha. Either

Actually, it doesn't...  All of the brw_fs_surface_builder code
assumes image formats which are all power-of-two so RGB isn't valid.
Maybe I should say something?
--Jason

> } else if (brw_image_format_info[brw_format].alpha_bits == 0) {
> return 3;
> }
>
> or
>
> } else {
> assert(brw_image_format_info[brw_format].alpha_bits > 0);
> return 4;
> }
>
>
> The rest of the patch looked good to me.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 0/3] Fix racy full-vector writes for v[i].x

[Jason Ekstrand]

On Mon, Nov 9, 2015 at 3:52 PM, Ian Romanick  wrote:
> On 11/04/2015 03:55 PM, Jason Ekstrand wrote:
>> Here's some shader-db  numbers:
>>
>> total instructions in shared programs: 6236146 -> 6255385 (0.31%)
>> instructions in affected programs: 203629 -> 222868 (9.45%)
>> helped:118
>> HURT:  1989
>> GAINED:18
>> LOST:  0
>
> I recall from off-line discussions that many (almost all?) of the really
> hurt shaders were vertex shaders that we no longer getting benefit from
> the vectorizer pass.  How hard would be it be to modify the lowering
> pass to have an option to only lower SSBOs and other memories that
> actually need the early lowering?  We could then lower those early, do
> the vectorizing, the lower the others late (as we do now).
>
> I know we really want a NIR vectorizer, but I think that's a bigger
> project than we want to tackle right now.  If we think this stop-gap
> could be implemented quickly enough, maybe we should do that for now
> instead.

I believe this has all been fixed in v2.

>> We should probably look into that.
>>
>>
>> On Wed, Nov 4, 2015 at 3:33 PM, Kristian Høgsberg Kristensen
>>  wrote:
>>> This little series fixes a problem where we lower
>>>
>>>   v[i] = s
>>>
>>> to
>>>
>>>   v = vector_insert(v, s, i)
>>>
>>> turning a component write into a full vector write. This used to be
>>> ok, since none of this was visible to other threads.  Now with SSBOs
>>> (and compute shader SLM and tesselation outputs) this rewrite is racy
>>> and we have to handle this different in case the vector is in globally
>>> visible storage.
>>>
>>> Kristian Høgsberg Kristensen (3):
>>>   glsl: Drop exec_list argument to lower_ubo_reference
>>>   glsl: Lower UBO and SSBO access in glsl linker
>>>   glsl: Use array deref for access to vector components
>>>
>>>  src/glsl/Makefile.sources  |   1 +
>>>  src/glsl/ast_array_index.cpp   |   5 +-
>>>  src/glsl/ast_function.cpp  |  24 ++-
>>>  src/glsl/ast_to_hir.cpp|  43 
>>>  src/glsl/ir_optimization.h |   3 +-
>>>  src/glsl/ir_validate.cpp   |   7 +-
>>>  src/glsl/linker.cpp|  10 +++
>>>  src/glsl/lower_ubo_reference.cpp   |  18 -
>>>  src/glsl/lower_vector_derefs.cpp   | 104 
>>> +
>>>  src/glsl/opt_dead_code_local.cpp   |   2 +
>>>  src/mesa/drivers/dri/i965/brw_link.cpp |   2 -
>>>  src/mesa/drivers/dri/i965/brw_shader.cpp   |   2 +
>>>  src/mesa/main/mtypes.h |   2 +
>>>  src/mesa/state_tracker/st_extensions.c |   1 +
>>>  src/mesa/state_tracker/st_glsl_to_tgsi.cpp |   1 -
>>>  15 files changed, 151 insertions(+), 74 deletions(-)
>>>  create mode 100644 src/glsl/lower_vector_derefs.cpp
>>>
>>> --
>>> 2.6.2
>>>
>>> ___
>>> mesa-dev mailing list
>>> mesa-dev@lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v6] gallium/hud: control visibility at startup and runtime.

[Jimmy Berry]

- env GALLIUM_HUD_VISIBLE: control default visibility
- env GALLIUM_HUD_SIGNAL_TOGGLE: toggle visibility via signal
---

Added fflush(stderr) per request.

 docs/envvars.html   |  6 ++
 src/gallium/auxiliary/hud/hud_context.c | 29 +
 2 files changed, 35 insertions(+)

diff --git a/docs/envvars.html b/docs/envvars.html
index bdfe999..530bbb7 100644
--- a/docs/envvars.html
+++ b/docs/envvars.html
@@ -179,6 +179,12 @@ Mesa EGL supports different sets of environment variables. 
 See the
 GALLIUM_HUD - draws various information on the screen, like framerate,
 cpu load, driver statistics, performance counters, etc.
 Set GALLIUM_HUD=help and run e.g. glxgears for more info.
+GALLIUM_HUD_VISIBLE - control default visibility, defaults to true.
+GALLIUM_HUD_TOGGLE_SIGNAL - toggle visibility via user specified signal.
+Especially useful to toggle hud at specific points of application and
+disable for unencumbered viewing the rest of the time. For example, set
+GALLIUM_HUD_VISIBLE to false and GALLIUM_HUD_SIGNAL_TOGGLE to 10 (SIGUSR1).
+Use kill -10  to toggle the hud as desired.
 GALLIUM_LOG_FILE - specifies a file for logging all errors, warnings, etc.
 rather than stderr.
 GALLIUM_PRINT_OPTIONS - if non-zero, print all the Gallium environment
diff --git a/src/gallium/auxiliary/hud/hud_context.c 
b/src/gallium/auxiliary/hud/hud_context.c
index ffe30b8..a055480 100644
--- a/src/gallium/auxiliary/hud/hud_context.c
+++ b/src/gallium/auxiliary/hud/hud_context.c
@@ -33,6 +33,7 @@
  * Set GALLIUM_HUD=help for more info.
  */
 
+#include 
 #include 
 
 #include "hud/hud_context.h"
@@ -51,6 +52,8 @@
 #include "tgsi/tgsi_text.h"
 #include "tgsi/tgsi_dump.h"
 
+/* Control the visibility of all HUD contexts */
+static boolean huds_visible = TRUE;
 
 struct hud_context {
struct pipe_context *pipe;
@@ -95,6 +98,11 @@ struct hud_context {
} text, bg, whitelines;
 };
 
+static void
+signal_visible_handler(int sig, siginfo_t *siginfo, void *context)
+{
+   huds_visible = !huds_visible;
+}
 
 static void
 hud_draw_colored_prims(struct hud_context *hud, unsigned prim,
@@ -441,6 +449,9 @@ hud_draw(struct hud_context *hud, struct pipe_resource *tex)
struct hud_pane *pane;
struct hud_graph *gr;
 
+   if (!huds_visible)
+  return;
+
hud->fb_width = tex->width0;
hud->fb_height = tex->height0;
hud->constants.two_div_fb_width = 2.0f / hud->fb_width;
@@ -1125,6 +1136,10 @@ hud_create(struct pipe_context *pipe, struct cso_context 
*cso)
struct pipe_sampler_view view_templ;
unsigned i;
const char *env = debug_get_option("GALLIUM_HUD", NULL);
+   unsigned signo = debug_get_num_option("GALLIUM_HUD_TOGGLE_SIGNAL", 0);
+   static boolean sig_handled = FALSE;
+   struct sigaction action = {};
+   huds_visible = debug_get_bool_option("GALLIUM_HUD_VISIBLE", TRUE);
 
if (!env || !*env)
   return NULL;
@@ -1267,6 +1282,20 @@ hud_create(struct pipe_context *pipe, struct cso_context 
*cso)
 
LIST_INITHEAD(>pane_list);
 
+   /* setup sig handler once for all hud contexts */
+   if (!sig_handled && signo != 0) {
+  action.sa_sigaction = _visible_handler;
+  action.sa_flags = SA_SIGINFO;
+
+  if (signo >= NSIG)
+ fprintf(stderr, "gallium_hud: invalid signal %u\n", signo);
+  else if (sigaction(signo, , NULL) < 0)
+ fprintf(stderr, "gallium_hud: unable to set handler for signal %u\n", 
signo);
+  fflush(stderr);
+
+  sig_handled = TRUE;
+   }
+
hud_parse_env_var(hud, env);
return hud;
 }
-- 
2.6.2

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

Re: [Mesa-dev] nir/i965: Source modifiers on vecN opcodes

[Connor Abbott]

On Mon, Nov 9, 2015 at 10:41 AM, Jason Ekstrand  wrote:
>
> On Nov 9, 2015 7:24 AM, "Connor Abbott"  wrote:
>>
>> On Mon, Nov 9, 2015 at 6:55 AM, Iago Toral  wrote:
>> > Hi,
>> >
>> > Currently, NIR defines vecN operations as unsigned (integer). The fp64
>> > patches from Connor change this to float (I guess because we need to
>> > know the case where we are packing vectors of 64-bit floats). However,
>> > this makes it so that  nir_lower_source_to_mods turns this:
>> >
>> > vec1 ssa_2 = fmov -ssa_1.y
>> > vec3 ssa_3 = vec3 ssa_1, ssa_2, ssa_0
>> >
>> > into:
>> >
>> > vec3 ssa_2 = vec3 ssa_1, -ssa_1.y, ssa_0
>> >
>> > This only happens because the vec3 operation is defined as a float
>> > operation now, otherwise it would not try to do this. It is not clear to
>> > me if this is by design, I mean, have this kind of things only kick-in
>> > for float/int and define vecN operations as unsigned to avoid this for
>> > them.
>> >
>> > The problem comes later when we call nir_lower_vec_to_movs in the i965
>> > vec4 backend. That pass generates a separate MOV for each component in
>> > the vector, but to do that properly when a negate is involved it needs
>> > to know if this is a float or an integer operand, which it  does not
>> > know at this point. The current code always emits an imov, which won't
>> > work if the operand is a float.
>> >
>> > I can think of two solutions for this:
>> >
>> > 1) Change nir_lower_source_to_mods so it does not try to rewrite alu
>> > operations where a source comes from a fmov with a negate, or at least
>> > if the instruction we are trying to rewrite is a vecN operation (or
>> > maybe allow this in scalar mode only?)
>> >
>> > 2) In nir_lower_vec_to_movs, if a source is negated, check its
>> > parent_instr and try to guess its type from that (in this example, we
>> > would see it came from fmov and we can say it is a float and emit fmov
>> > instead of imov). Not sure if this would work in all possible scenarios
>> > though.
>> >
>> > Opinions?
>> >
>> > Iago
>> >
>> > ___
>> > mesa-dev mailing list
>> > mesa-dev@lists.freedesktop.org
>> > http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>
>> The only reason I changed vecN to produce floats is to avoid producing
>> 64-bit integer instructions, which at one point the constant folding
>> infrastructure couldn't support (but now it can), so you can just
>> revert the change. Ofc the i965 backend won't be able to express this
>> directly, but for now you can silently change 64-bit integers to
>> floats and assert that they only happen in things that copy data
>> around.
>
> I would tend to agree.  We could also make it unsigned so no source
> modifiers ever make sense.  Meh.

Oh yeah, I meant assert that we don't get e.g. a 64-bit iadd, so we
remember to fix that later. When we get support for real 64-bit
integers, we'll have to only map nir_type_int64/uint64 to DF on gen7.

>
> If we did want to keep vecN float, the thing to do would be to make
> vec_to_move lower it to fmovs rather than imovs.  But, like Connor said,
> just asserting no source modifiers for th 64-bit version in the backend is
> probably best.
>
> --Jason
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] st/omx: straighten get/put_screen

[Emil Velikov]

On 9 November 2015 at 15:22, Liu, Leo  wrote:
>>-Original Message-
>>From: Emil Velikov [mailto:emil.l.veli...@gmail.com]
>>Sent: Monday, November 09, 2015 8:17 AM
>>To: mesa-dev@lists.freedesktop.org
>>Cc: emil.l.veli...@gmail.com; Liu, Leo
>>Subject: [PATCH] st/omx: straighten get/put_screen
>>
>>The current code is busted in a number of ways.
>>
>> - initially checks for omx_display (rather than omx_screen), which may or may
>>not be around.
>> - blindly feeds the empty env variable string to loader_open_device()
>
> Should be treating empty string as one of incorrect string, which result in 
> failing open.
> Because user's intention is to use to env, if they put the empty string, here 
> should be getting failed.
>
I was leaning that the "check for empty string" approach was "the gallium way".
Although on second look the opposite seems to be more common, so
consider it gone.

Btw. did any of the issues outlined became obvious with my previous
comments or am I too subtle ? Or you did not consider them something
worth the hassle ?

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

[Mesa-dev] [PATCH 3/3] nvc0: add ARB_clear_texture support

[Ilia Mirkin]

Signed-off-by: Ilia Mirkin 
---
 docs/GL3.txt|  2 +-
 docs/relnotes/11.1.0.html   |  1 +
 src/gallium/drivers/nouveau/nvc0/nvc0_screen.c  |  2 +-
 src/gallium/drivers/nouveau/nvc0/nvc0_surface.c | 82 +
 4 files changed, 85 insertions(+), 2 deletions(-)

diff --git a/docs/GL3.txt b/docs/GL3.txt
index 7abdcd8..da0ffca 100644
--- a/docs/GL3.txt
+++ b/docs/GL3.txt
@@ -177,7 +177,7 @@ GL 4.4, GLSL 4.40:
 
   GL_MAX_VERTEX_ATTRIB_STRIDE  DONE (all drivers)
   GL_ARB_buffer_storageDONE (i965, nv50, nvc0, 
r600, radeonsi)
-  GL_ARB_clear_texture DONE (i965) (gallium - 
in progress, VMware)
+  GL_ARB_clear_texture DONE (i965, nvc0)
   GL_ARB_enhanced_layouts  in progress (Timothy)
   - compile-time constant expressions  in progress
   - explicit byte offsets for blocks   in progress
diff --git a/docs/relnotes/11.1.0.html b/docs/relnotes/11.1.0.html
index 11fbdff..33fd0b8 100644
--- a/docs/relnotes/11.1.0.html
+++ b/docs/relnotes/11.1.0.html
@@ -46,6 +46,7 @@ Note: some of the new features are only available with 
certain drivers.
 
 GL_ARB_arrays_of_arrays on i965
 GL_ARB_blend_func_extended on freedreno (a3xx)
+GL_ARB_clear_texture on nvc0
 GL_ARB_copy_image on nv50, nvc0, radeonsi
 GL_ARB_gpu_shader_fp64 on r600 for Cypress/Cayman/Aruba chips
 GL_ARB_gpu_shader5 on r600 for Evergreen and later chips
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
index f2e3bf0..fbeec7f 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
@@ -182,6 +182,7 @@ nvc0_screen_get_param(struct pipe_screen *pscreen, enum 
pipe_cap param)
case PIPE_CAP_COPY_BETWEEN_COMPRESSED_AND_PLAIN_FORMATS:
case PIPE_CAP_FORCE_PERSAMPLE_INTERP:
case PIPE_CAP_SHAREABLE_SHADERS:
+   case PIPE_CAP_CLEAR_TEXTURE:
   return 1;
case PIPE_CAP_SEAMLESS_CUBE_MAP_PER_TEXTURE:
   return (class_3d >= NVE4_3D_CLASS) ? 1 : 0;
@@ -204,7 +205,6 @@ nvc0_screen_get_param(struct pipe_screen *pscreen, enum 
pipe_cap param)
case PIPE_CAP_VERTEXID_NOBASE:
case PIPE_CAP_RESOURCE_FROM_USER_MEMORY:
case PIPE_CAP_DEVICE_RESET_STATUS_QUERY:
-   case PIPE_CAP_CLEAR_TEXTURE:
   return 0;
 
case PIPE_CAP_VENDOR_ID:
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_surface.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_surface.c
index 5f47bad..3ae9943 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_surface.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_surface.c
@@ -319,6 +319,8 @@ nvc0_clear_render_target(struct pipe_context *pipe,
   PUSH_DATA(push, dst->u.tex.first_layer + sf->depth);
   PUSH_DATA(push, mt->layer_stride >> 2);
   PUSH_DATA(push, dst->u.tex.first_layer);
+
+  IMMED_NVC0(push, NVC0_3D(MULTISAMPLE_MODE), mt->ms_mode);
} else {
   if (res->base.target == PIPE_BUFFER) {
  PUSH_DATA(push, 262144);
@@ -540,6 +542,7 @@ nvc0_clear_depth_stencil(struct pipe_context *pipe,
PUSH_DATA (push, (unk << 16) | (dst->u.tex.first_layer + sf->depth));
BEGIN_NVC0(push, NVC0_3D(ZETA_BASE_LAYER), 1);
PUSH_DATA (push, dst->u.tex.first_layer);
+   IMMED_NVC0(push, NVC0_3D(MULTISAMPLE_MODE), mt->ms_mode);
 
BEGIN_NIC0(push, NVC0_3D(CLEAR_BUFFERS), sf->depth);
for (z = 0; z < sf->depth; ++z) {
@@ -550,6 +553,84 @@ nvc0_clear_depth_stencil(struct pipe_context *pipe,
nvc0->dirty |= NVC0_NEW_FRAMEBUFFER;
 }
 
+static void
+nvc0_clear_texture(struct pipe_context *pipe,
+   struct pipe_resource *res,
+   unsigned level,
+   const struct pipe_box *box,
+   const void *data)
+{
+   struct nv50_miptree *mt = nv50_miptree(res);
+   struct nv50_surface sf = {{{0}}};
+
+   assert(res->target != PIPE_BUFFER);
+
+   sf.base.texture = res;
+   sf.base.format = res->format;
+   sf.base.u.tex.first_layer = box->z;
+   sf.base.u.tex.last_layer = box->depth;
+   sf.base.u.tex.level = level;
+   sf.base.width = sf.width = res->width0 << mt->ms_x;
+   sf.base.height = sf.height = res->height0 << mt->ms_y;
+   sf.depth = box->depth;
+   sf.offset = mt->level[level].offset;
+
+   if (util_format_is_depth_or_stencil(res->format)) {
+  float depth = 0;
+  uint8_t stencil = 0;
+  unsigned clear = 0;
+  const struct util_format_description *desc =
+ util_format_description(res->format);
+
+  if (util_format_has_depth(desc)) {
+ clear |= PIPE_CLEAR_DEPTH;
+ desc->unpack_z_float(, 0, data, 0, 1, 1);
+  }
+  if (util_format_has_stencil(desc)) {
+ clear |= PIPE_CLEAR_STENCIL;
+ desc->unpack_s_8uint(, 0, data, 0, 1, 1);
+  }
+  nvc0_clear_depth_stencil(pipe, , clear, depth, stencil,
+  

[Mesa-dev] [Bug 90264] [Regression, bisected] Tooltip corruption in Chrome

[bugzilla-daemon]

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

--- Comment #56 from Antoine Labour  ---
(In reply to Furkan from comment #54)
> Quoted from the Chromium bug report page:
> 
> "I disabled use_virtualized_gl_contexts on non-nvidia drivers in the latest
> build of chromium"
> 
> I don't know what that does, but it looks like a workaround.

enabling use_virtualized_gl_contexts was originally a workaround for some other
drivers. We originally enabled it everywhere, but it uncovered this issue, so
we disabled it on drivers that don't absolutely need it.

Whichever way you take it, various drivers from different vendors are
inconsistent and we have to workaround some and/or others.

-- 
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
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2/3] st/mesa: implement ARB_clear_texture

[Ilia Mirkin]

Signed-off-by: Ilia Mirkin 
---
 src/mesa/state_tracker/st_cb_texture.c | 29 +
 src/mesa/state_tracker/st_extensions.c |  1 +
 2 files changed, 30 insertions(+)

diff --git a/src/mesa/state_tracker/st_cb_texture.c 
b/src/mesa/state_tracker/st_cb_texture.c
index d4c916e..62f149a 100644
--- a/src/mesa/state_tracker/st_cb_texture.c
+++ b/src/mesa/state_tracker/st_cb_texture.c
@@ -1873,6 +1873,34 @@ st_TextureView(struct gl_context *ctx,
return GL_TRUE;
 }
 
+static void
+st_ClearTexSubImage(struct gl_context *ctx,
+struct gl_texture_image *texImage,
+GLint xoffset, GLint yoffset, GLint zoffset,
+GLsizei width, GLsizei height, GLsizei depth,
+const GLvoid *clearValue)
+{
+   static const char zeros[16] = {0};
+   struct st_texture_image *stImage = st_texture_image(texImage);
+   struct pipe_resource *pt = stImage->pt;
+   struct st_context *st = st_context(ctx);
+   struct pipe_context *pipe = st->pipe;
+   unsigned level = texImage->Level;
+   struct pipe_box box;
+
+   if (!pt)
+  return;
+
+   u_box_3d(xoffset, yoffset, zoffset + texImage->Face,
+width, height, depth, );
+   if (texImage->TexObject->Immutable) {
+  level += texImage->TexObject->MinLevel;
+  box.z += texImage->TexObject->MinLayer;
+   }
+
+   pipe->clear_texture(pipe, pt, level, , clearValue ? clearValue : zeros);
+}
+
 void
 st_init_texture_functions(struct dd_function_table *functions)
 {
@@ -1904,4 +1932,5 @@ st_init_texture_functions(struct dd_function_table 
*functions)
 
functions->AllocTextureStorage = st_AllocTextureStorage;
functions->TextureView = st_TextureView;
+   functions->ClearTexSubImage = st_ClearTexSubImage;
 }
diff --git a/src/mesa/state_tracker/st_extensions.c 
b/src/mesa/state_tracker/st_extensions.c
index 03b4b97..315082b 100644
--- a/src/mesa/state_tracker/st_extensions.c
+++ b/src/mesa/state_tracker/st_extensions.c
@@ -455,6 +455,7 @@ void st_init_extensions(struct pipe_screen *screen,
static const struct st_extension_cap_mapping cap_mapping[] = {
   { o(ARB_base_instance),PIPE_CAP_START_INSTANCE   
},
   { o(ARB_buffer_storage),   
PIPE_CAP_BUFFER_MAP_PERSISTENT_COHERENT   },
+  { o(ARB_clear_texture),PIPE_CAP_CLEAR_TEXTURE
},
   { o(ARB_color_buffer_float),   PIPE_CAP_VERTEX_COLOR_UNCLAMPED   
},
   { o(ARB_copy_image),   
PIPE_CAP_COPY_BETWEEN_COMPRESSED_AND_PLAIN_FORMATS },
   { o(ARB_depth_clamp),  PIPE_CAP_DEPTH_CLIP_DISABLE   
},
-- 
2.4.10

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

[Mesa-dev] [Bug 90264] [Regression, bisected] Tooltip corruption in Chrome

[bugzilla-daemon]

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

--- Comment #55 from Antoine Labour  ---
(In reply to paviluf from comment #52)
> I don't know if you are aware but there is a similar bug in chromium that as
> been fixed.
> https://code.google.com/p/chromium/issues/detail?id=442111

Yeah, that bug cross-links here.

-- 
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
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 90264] [Regression, bisected] Tooltip corruption in Chrome

[bugzilla-daemon]

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

--- Comment #53 from James Jones  ---
I'll be out of the office for the next 2-3 weeks.

For Vulkan issues, talk to Damien Leone (dle...@nvidia.com)

For EGL issues, talk to Daniel Kartch (dkar...@nvidia.com)

---
This email message is for the sole use of the intended recipient(s) and may
contain
confidential information.  Any unauthorized review, use, disclosure or
distribution
is prohibited.  If you are not the intended recipient, please contact the
sender by
reply email and destroy all copies of the original message.
---

-- 
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
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH shader-db 1/3] split-to-files: deal with minimum versions, other shader types

[Matt Turner]

I think Ken has some hacks in Mesa to dump shaders, so we don't use
this script very much any more. Feel free to commit this in any case.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH shader-db 1/3] split-to-files: deal with minimum versions, other shader types

[Matt Turner]

On Mon, Nov 9, 2015 at 10:46 AM, Ilia Mirkin  wrote:
> I used this script in conjunction with ST_DUMP_SHADERS. What other way is 
> there?

Some local hack and we should probably finish and upstream.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 90264] [Regression, bisected] Tooltip corruption in Chrome

[bugzilla-daemon]

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

--- Comment #52 from pavi...@yahoo.fr ---
I don't know if you are aware but there is a similar bug in chromium that as
been fixed.
https://code.google.com/p/chromium/issues/detail?id=442111

-- 
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
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 90264] [Regression, bisected] Tooltip corruption in Chrome

[bugzilla-daemon]

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

--- Comment #54 from Furkan  ---
Quoted from the Chromium bug report page:

"I disabled use_virtualized_gl_contexts on non-nvidia drivers in the latest
build of chromium"

I don't know what that does, but it looks like a workaround.

-- 
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
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC PATCH shader-db 1/2] run: don't expect incoming message to contain a newline

[Matt Turner]

On Sun, Nov 8, 2015 at 8:53 PM, Ilia Mirkin  wrote:
> It seems a bit odd to expect a debug message to contain a newline --
> what if you wanted to include something *after* the message, for
> example. It makes more sense for the code actually printing to have the
> newline rather than the string being passed around.

Yep, makes sense.

Reviewed-by: Matt Turner 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC PATCH shader-db 2/2] run: request a debug context

[Matt Turner]

On Sun, Nov 8, 2015 at 8:53 PM, Ilia Mirkin  wrote:
> st/mesa only prints messages in a debug context. Without always enabling
> the message generation, I don't see a way to hook into the glEnable() to
> turn it on/off.
> ---
>  run.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/run.c b/run.c
> index 73e468d..1d8d3b1 100644
> --- a/run.c
> +++ b/run.c
> @@ -417,6 +417,7 @@ main(int argc, char **argv)
>  EGL_CONTEXT_OPENGL_CORE_PROFILE_BIT_KHR,
>  EGL_CONTEXT_MAJOR_VERSION_KHR, 3,
>  EGL_CONTEXT_MINOR_VERSION_KHR, 2,
> +EGL_CONTEXT_FLAGS_KHR, EGL_CONTEXT_OPENGL_DEBUG_BIT_KHR,
>  EGL_NONE
>  };
>  EGLContext core_ctx = eglCreateContext(egl_dpy, cfg, EGL_NO_CONTEXT,

Is this a limitation of st/mesa, or am I using the KHR_debug API
incorrectly? It's my understanding that you can get KHR_debug messages
without a debug context by calling glEnable(GL_DEBUG_OUTPUT), and it
looks like this is supported by the KHR_debug spec.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH shader-db 1/3] split-to-files: deal with minimum versions, other shader types

[Ilia Mirkin]

I used this script in conjunction with ST_DUMP_SHADERS. What other way is there?

On Mon, Nov 9, 2015 at 1:36 PM, Matt Turner  wrote:
> I think Ken has some hacks in Mesa to dump shaders, so we don't use
> this script very much any more. Feel free to commit this in any case.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] st/omx: straighten get/put_screen

[Liu, Leo]

>-Original Message-
>From: Emil Velikov [mailto:emil.l.veli...@gmail.com]
>Sent: Monday, November 09, 2015 1:34 PM
>To: Liu, Leo
>Cc: mesa-dev@lists.freedesktop.org
>Subject: Re: [PATCH] st/omx: straighten get/put_screen
>
>On 9 November 2015 at 15:22, Liu, Leo  wrote:
>>>-Original Message-
>>>From: Emil Velikov [mailto:emil.l.veli...@gmail.com]
>>>Sent: Monday, November 09, 2015 8:17 AM
>>>To: mesa-dev@lists.freedesktop.org
>>>Cc: emil.l.veli...@gmail.com; Liu, Leo
>>>Subject: [PATCH] st/omx: straighten get/put_screen
>>>
>>>The current code is busted in a number of ways.
>>>
>>> - initially checks for omx_display (rather than omx_screen), which
>>>may or may not be around.
>>> - blindly feeds the empty env variable string to loader_open_device()
>>
>> Should be treating empty string as one of incorrect string, which result in 
>> failing
>open.
>> Because user's intention is to use to env, if they put the empty string, here
>should be getting failed.
>>
>I was leaning that the "check for empty string" approach was "the gallium way".
>Although on second look the opposite seems to be more common, so consider it
>gone.
>
Sound good.

>Btw. did any of the issues outlined became obvious with my previous comments
>or am I too subtle ? Or you did not consider them something worth the hassle ?
>
I am with you. Perfection is always better.

Thanks,
Leo

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

Re: [Mesa-dev] [RFC PATCH shader-db 2/2] run: request a debug context

[Ilia Mirkin]

On Mon, Nov 9, 2015 at 1:35 PM, Matt Turner  wrote:
> On Sun, Nov 8, 2015 at 8:53 PM, Ilia Mirkin  wrote:
>> st/mesa only prints messages in a debug context. Without always enabling
>> the message generation, I don't see a way to hook into the glEnable() to
>> turn it on/off.
>> ---
>>  run.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/run.c b/run.c
>> index 73e468d..1d8d3b1 100644
>> --- a/run.c
>> +++ b/run.c
>> @@ -417,6 +417,7 @@ main(int argc, char **argv)
>>  EGL_CONTEXT_OPENGL_CORE_PROFILE_BIT_KHR,
>>  EGL_CONTEXT_MAJOR_VERSION_KHR, 3,
>>  EGL_CONTEXT_MINOR_VERSION_KHR, 2,
>> +EGL_CONTEXT_FLAGS_KHR, EGL_CONTEXT_OPENGL_DEBUG_BIT_KHR,
>>  EGL_NONE
>>  };
>>  EGLContext core_ctx = eglCreateContext(egl_dpy, cfg, EGL_NO_CONTEXT,
>
> Is this a limitation of st/mesa, or am I using the KHR_debug API
> incorrectly? It's my understanding that you can get KHR_debug messages
> without a debug context by calling glEnable(GL_DEBUG_OUTPUT), and it
> looks like this is supported by the KHR_debug spec.

But I don't want to be generating the debug info in my driver for no
reason. For example I have a timing-type debug message which gets the
current time (to report how long a sync fence wait takes). This is a
non-free operation that I want to avoid if no one's looking.

I can see this both ways... perhaps the more expensive messages should
be keyed on whether it's a debug context and the compiler message
should always be reported. Or perhaps we can just create a debug
context here and be done with it.

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

Re: [Mesa-dev] [RFC PATCH shader-db 2/2] run: request a debug context

[Matt Turner]

On Mon, Nov 9, 2015 at 10:46 AM, Ilia Mirkin  wrote:
> On Mon, Nov 9, 2015 at 1:35 PM, Matt Turner  wrote:
>> On Sun, Nov 8, 2015 at 8:53 PM, Ilia Mirkin  wrote:
>>> st/mesa only prints messages in a debug context. Without always enabling
>>> the message generation, I don't see a way to hook into the glEnable() to
>>> turn it on/off.
>>> ---
>>>  run.c | 1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff --git a/run.c b/run.c
>>> index 73e468d..1d8d3b1 100644
>>> --- a/run.c
>>> +++ b/run.c
>>> @@ -417,6 +417,7 @@ main(int argc, char **argv)
>>>  EGL_CONTEXT_OPENGL_CORE_PROFILE_BIT_KHR,
>>>  EGL_CONTEXT_MAJOR_VERSION_KHR, 3,
>>>  EGL_CONTEXT_MINOR_VERSION_KHR, 2,
>>> +EGL_CONTEXT_FLAGS_KHR, EGL_CONTEXT_OPENGL_DEBUG_BIT_KHR,
>>>  EGL_NONE
>>>  };
>>>  EGLContext core_ctx = eglCreateContext(egl_dpy, cfg, EGL_NO_CONTEXT,
>>
>> Is this a limitation of st/mesa, or am I using the KHR_debug API
>> incorrectly? It's my understanding that you can get KHR_debug messages
>> without a debug context by calling glEnable(GL_DEBUG_OUTPUT), and it
>> looks like this is supported by the KHR_debug spec.
>
> But I don't want to be generating the debug info in my driver for no
> reason. For example I have a timing-type debug message which gets the
> current time (to report how long a sync fence wait takes). This is a
> non-free operation that I want to avoid if no one's looking.

Huh, looks like we do quite a bit of work before we throw the message
away. We could probably make that process a lot simpler.

> I can see this both ways... perhaps the more expensive messages should
> be keyed on whether it's a debug context and the compiler message
> should always be reported. Or perhaps we can just create a debug
> context here and be done with it.

I guess you can determine that based on
DEBUG_SEVERITY_{HIGH,MEDIUM,LOW,NOTIFICATION}?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC PATCH shader-db 2/2] run: request a debug context

[Ilia Mirkin]

On Mon, Nov 9, 2015 at 1:56 PM, Matt Turner  wrote:
> On Mon, Nov 9, 2015 at 10:46 AM, Ilia Mirkin  wrote:
>> On Mon, Nov 9, 2015 at 1:35 PM, Matt Turner  wrote:
>>> On Sun, Nov 8, 2015 at 8:53 PM, Ilia Mirkin  wrote:
 st/mesa only prints messages in a debug context. Without always enabling
 the message generation, I don't see a way to hook into the glEnable() to
 turn it on/off.
 ---
  run.c | 1 +
  1 file changed, 1 insertion(+)

 diff --git a/run.c b/run.c
 index 73e468d..1d8d3b1 100644
 --- a/run.c
 +++ b/run.c
 @@ -417,6 +417,7 @@ main(int argc, char **argv)
  EGL_CONTEXT_OPENGL_CORE_PROFILE_BIT_KHR,
  EGL_CONTEXT_MAJOR_VERSION_KHR, 3,
  EGL_CONTEXT_MINOR_VERSION_KHR, 2,
 +EGL_CONTEXT_FLAGS_KHR, EGL_CONTEXT_OPENGL_DEBUG_BIT_KHR,
  EGL_NONE
  };
  EGLContext core_ctx = eglCreateContext(egl_dpy, cfg, EGL_NO_CONTEXT,
>>>
>>> Is this a limitation of st/mesa, or am I using the KHR_debug API
>>> incorrectly? It's my understanding that you can get KHR_debug messages
>>> without a debug context by calling glEnable(GL_DEBUG_OUTPUT), and it
>>> looks like this is supported by the KHR_debug spec.
>>
>> But I don't want to be generating the debug info in my driver for no
>> reason. For example I have a timing-type debug message which gets the
>> current time (to report how long a sync fence wait takes). This is a
>> non-free operation that I want to avoid if no one's looking.
>
> Huh, looks like we do quite a bit of work before we throw the message
> away. We could probably make that process a lot simpler.
>
>> I can see this both ways... perhaps the more expensive messages should
>> be keyed on whether it's a debug context and the compiler message
>> should always be reported. Or perhaps we can just create a debug
>> context here and be done with it.
>
> I guess you can determine that based on
> DEBUG_SEVERITY_{HIGH,MEDIUM,LOW,NOTIFICATION}?

There's no driver notification about that (that I'm aware). Should there be?

I don't really see how that can work, since I think you're supposed to
be able to have multiple ones in a group. But I'm new to that API...
if there's a driver hook that I missed or variable I should be looking
at, please educate :)

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

Re: [Mesa-dev] [PATCH v3] gallium/hud: control visibility at startup and runtime.

[Brian Paul]

On 11/07/2015 09:05 PM, Jimmy Berry wrote:

- env GALLIUM_HUD_VISIBLE: control default visibility
- env GALLIUM_HUD_SIGNAL_TOGGLE: toggle visibility via signal
---
  docs/envvars.html   |  6 ++
  src/gallium/auxiliary/hud/hud_context.c | 28 
  2 files changed, 34 insertions(+)

diff --git a/docs/envvars.html b/docs/envvars.html
index bdfe999..530bbb7 100644
--- a/docs/envvars.html
+++ b/docs/envvars.html
@@ -179,6 +179,12 @@ Mesa EGL supports different sets of environment variables. 
 See the
  GALLIUM_HUD - draws various information on the screen, like framerate,
  cpu load, driver statistics, performance counters, etc.
  Set GALLIUM_HUD=help and run e.g. glxgears for more info.
+GALLIUM_HUD_VISIBLE - control default visibility, defaults to true.
+GALLIUM_HUD_TOGGLE_SIGNAL - toggle visibility via user specified signal.
+Especially useful to toggle hud at specific points of application and
+disable for unencumbered viewing the rest of the time. For example, set
+GALLIUM_HUD_VISIBLE to false and GALLIUM_HUD_SIGNAL_TOGGLE to 10 (SIGUSR1).
+Use kill -10  to toggle the hud as desired.
  GALLIUM_LOG_FILE - specifies a file for logging all errors, warnings, etc.
  rather than stderr.
  GALLIUM_PRINT_OPTIONS - if non-zero, print all the Gallium environment
diff --git a/src/gallium/auxiliary/hud/hud_context.c 
b/src/gallium/auxiliary/hud/hud_context.c
index ffe30b8..31e55cd 100644
--- a/src/gallium/auxiliary/hud/hud_context.c
+++ b/src/gallium/auxiliary/hud/hud_context.c
@@ -33,6 +33,7 @@
   * Set GALLIUM_HUD=help for more info.
   */

+#include 
  #include 

  #include "hud/hud_context.h"
@@ -51,6 +52,8 @@
  #include "tgsi/tgsi_text.h"
  #include "tgsi/tgsi_dump.h"

+/* Control the visibility of all HUD contexts */
+static boolean huds_visible = TRUE;

  struct hud_context {
 struct pipe_context *pipe;
@@ -95,6 +98,11 @@ struct hud_context {
 } text, bg, whitelines;
  };

+static void
+signal_visible_handler(int sig, siginfo_t *siginfo, void *context)
+{
+   huds_visible = !huds_visible;
+}

  static void
  hud_draw_colored_prims(struct hud_context *hud, unsigned prim,
@@ -441,6 +449,9 @@ hud_draw(struct hud_context *hud, struct pipe_resource *tex)
 struct hud_pane *pane;
 struct hud_graph *gr;

+   if (!huds_visible)
+  return;
+
 hud->fb_width = tex->width0;
 hud->fb_height = tex->height0;
 hud->constants.two_div_fb_width = 2.0f / hud->fb_width;
@@ -1125,6 +1136,10 @@ hud_create(struct pipe_context *pipe, struct cso_context 
*cso)
 struct pipe_sampler_view view_templ;
 unsigned i;
 const char *env = debug_get_option("GALLIUM_HUD", NULL);
+   long signo = debug_get_num_option("GALLIUM_HUD_TOGGLE_SIGNAL", 0);
+   boolean sig_handled = FALSE;
+   struct sigaction action = {};
+   huds_visible = debug_get_bool_option("GALLIUM_HUD_VISIBLE", TRUE);

 if (!env || !*env)
return NULL;
@@ -1267,6 +1282,19 @@ hud_create(struct pipe_context *pipe, struct cso_context 
*cso)

 LIST_INITHEAD(>pane_list);

+   /* setup sig handler once for all hud contexts */
+   if (!sig_handled) {
+  action.sa_sigaction = _visible_handler;
+  action.sa_flags = SA_SIGINFO;
+
+  if (signo < 1 || signo >= NSIG)
+ fprintf(stderr, "gallium_hud: invalid signal %ld\n", signo);
+  else if (sigaction(signo, , NULL) < 0)
+ fprintf(stderr, "gallium_hud: unable to set handler for signal 
%ld\n", signo);


Can you put a fflush(stderr) call here?  Windows doesn't always 
immediately flush stdout/stderr output to the terminal.


-Brian


+
+  sig_handled = TRUE;
+   }
+
 hud_parse_env_var(hud, env);
 return hud;
  }



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

Re: [Mesa-dev] [PATCH shader-db 2/3] run: work with tessellation shaders

[Matt Turner]

Reviewed-by: Matt Turner 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH shader-db 3/3] nv-report: initial checkin for nouveau

[Matt Turner]

Feel free to commit!
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/4] i965: Introduce a INDIRECT_THREAD_PAYLOAD_MOV opcode.

[Jason Ekstrand]

Given the fact that we have multiple possible uses for such an opcode,
I've been wondering if it wouldn't be better to simply have a
SHADER_OPCODE_INDIRECT_MOV opcode that works on pretty much any
register type.  Given that they all get lowered away to HW_REG before
the end, the emit code wouldn't have to do anything special.  This
could simply be an INDIRECT_MOV with an ATTR source while my uniform
opcode would use a UNIFORM source.  If we did this, we would have to
have the immediate "range" argument be in bytes, but that's not a huge
deal.

On Sat, Nov 7, 2015 at 9:03 PM, Kenneth Graunke  wrote:
> The geometry and tessellation control shader stages both read from
> multiple URB entries (one per vertex).  The thread payload contains
> several URB handles which reference these separate memory segments.
>
> In GLSL, these inputs are represented as per-vertex arrays; the
> outermost array index selects which vertex's inputs to read.  This
> array index does not necessarily need to be constant.
>
> To handle that, we need to use indirect addressing on GRFs to select
> which of the thread payload registers has the appropriate URB handle.
> (This is before we can even think about applying the pull model!)
>
> This patch introduces a new opcode which performs a MOV from a
> source using VxH indirect addressing (which allows each of the 8
> SIMD channels to select distinct data.)  It also marks a whole
> segment of the payload as "used", so the register allocator recognizes
> the read and avoids reusing those registers.
>
> Signed-off-by: Kenneth Graunke 
> ---
>  src/mesa/drivers/dri/i965/brw_defines.h   | 11 
>  src/mesa/drivers/dri/i965/brw_fs.h|  4 +++
>  src/mesa/drivers/dri/i965/brw_fs_cse.cpp  |  1 +
>  src/mesa/drivers/dri/i965/brw_fs_generator.cpp| 32 
> +++
>  src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp | 10 +++
>  src/mesa/drivers/dri/i965/brw_shader.cpp  |  2 ++
>  6 files changed, 60 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_defines.h 
> b/src/mesa/drivers/dri/i965/brw_defines.h
> index 6433cff..288d8b2 100644
> --- a/src/mesa/drivers/dri/i965/brw_defines.h
> +++ b/src/mesa/drivers/dri/i965/brw_defines.h
> @@ -1264,6 +1264,17 @@ enum opcode {
>  * Calculate the high 32-bits of a 32x32 multiply.
>  */
> SHADER_OPCODE_MULH,
> +
> +   /**
> +* A SIMD8 VxH indirect addressed MOV from the thread payload.
> +*
> +* This can be used to select GS or TCS input URB handles.
> +*
> +* Source 0: Immediate offset in bytes (UD immediate).
> +* Source 1: Indirect offset in bytes (UD GRF).
> +* Source 2: Number of registers that could be indirectly addressed.
> +*/
> +   SHADER_OPCODE_INDIRECT_THREAD_PAYLOAD_MOV,
>  };
>
>  enum brw_urb_write_flags {
> diff --git a/src/mesa/drivers/dri/i965/brw_fs.h 
> b/src/mesa/drivers/dri/i965/brw_fs.h
> index 8a93b56..fb70f0c 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs.h
> +++ b/src/mesa/drivers/dri/i965/brw_fs.h
> @@ -526,6 +526,10 @@ private:
>   struct brw_reg offset,
>   struct brw_reg value);
>
> +   void generate_indirect_thread_payload_mov(struct brw_reg dst,
> + struct brw_reg imm_byte_offset,
> + struct brw_reg 
> indirect_byte_offset);
> +
> bool patch_discard_jumps_to_fb_writes();
>
> const struct brw_compiler *compiler;
> diff --git a/src/mesa/drivers/dri/i965/brw_fs_cse.cpp 
> b/src/mesa/drivers/dri/i965/brw_fs_cse.cpp
> index 3a28c8d..699baab 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs_cse.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs_cse.cpp
> @@ -78,6 +78,7 @@ is_expression(const fs_visitor *v, const fs_inst *const 
> inst)
> case FS_OPCODE_LINTERP:
> case SHADER_OPCODE_FIND_LIVE_CHANNEL:
> case SHADER_OPCODE_BROADCAST:
> +   case SHADER_OPCODE_INDIRECT_THREAD_PAYLOAD_MOV:
>return true;
> case SHADER_OPCODE_RCP:
> case SHADER_OPCODE_RSQ:
> diff --git a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp 
> b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
> index e207a77..7d51c0e 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
> @@ -368,6 +368,33 @@ fs_generator::generate_fb_write(fs_inst *inst, struct 
> brw_reg payload)
>  }
>
>  void
> +fs_generator::generate_indirect_thread_payload_mov(struct brw_reg dst,
> +   struct brw_reg 
> imm_byte_offset_reg,
> +   struct brw_reg 
> indirect_byte_offset)
> +{
> +   assert(imm_byte_offset_reg.type == BRW_REGISTER_TYPE_UD);
> +   assert(imm_byte_offset_reg.file == BRW_IMMEDIATE_VALUE);
> +   assert(indirect_byte_offset.type == BRW_REGISTER_TYPE_UD);
> +   

[Mesa-dev] [PATCH 1/3] gallium: add PIPE_CAP_CLEAR_TEXTURE and clear_texture prototype

[Ilia Mirkin]

Signed-off-by: Ilia Mirkin 
---
 src/gallium/docs/source/context.rst  |  4 
 src/gallium/docs/source/screen.rst   |  2 ++
 src/gallium/drivers/freedreno/freedreno_screen.c |  1 +
 src/gallium/drivers/i915/i915_screen.c   |  1 +
 src/gallium/drivers/ilo/ilo_screen.c |  1 +
 src/gallium/drivers/llvmpipe/lp_screen.c |  1 +
 src/gallium/drivers/nouveau/nv30/nv30_screen.c   |  1 +
 src/gallium/drivers/nouveau/nv50/nv50_screen.c   |  1 +
 src/gallium/drivers/nouveau/nvc0/nvc0_screen.c   |  1 +
 src/gallium/drivers/r300/r300_screen.c   |  1 +
 src/gallium/drivers/r600/r600_pipe.c |  1 +
 src/gallium/drivers/radeonsi/si_pipe.c   |  1 +
 src/gallium/drivers/softpipe/sp_screen.c |  1 +
 src/gallium/drivers/svga/svga_screen.c   |  1 +
 src/gallium/drivers/vc4/vc4_screen.c |  1 +
 src/gallium/drivers/virgl/virgl_screen.c |  1 +
 src/gallium/include/pipe/p_context.h | 10 ++
 src/gallium/include/pipe/p_defines.h |  1 +
 18 files changed, 31 insertions(+)

diff --git a/src/gallium/docs/source/context.rst 
b/src/gallium/docs/source/context.rst
index dbc0877..9a32716 100644
--- a/src/gallium/docs/source/context.rst
+++ b/src/gallium/docs/source/context.rst
@@ -227,6 +227,10 @@ is is also possible to only clear one or the other part). 
While it is only
 possible to clear one surface at a time (which can include several layers),
 this surface need not be bound to the framebuffer.
 
+``clear_texture`` clears a non-PIPE_BUFFER resource's specified level
+and bounding box with a clear value provided in that resource's native
+format.
+
 ``clear_buffer`` clears a PIPE_BUFFER resource with the specified clear value
 (which may be multiple bytes in length). Logically this is a memset with a
 multi-byte element value starting at offset bytes from resource start, going
diff --git a/src/gallium/docs/source/screen.rst 
b/src/gallium/docs/source/screen.rst
index 168f90e..cec4dee 100644
--- a/src/gallium/docs/source/screen.rst
+++ b/src/gallium/docs/source/screen.rst
@@ -281,6 +281,8 @@ The integer capabilities:
 * ``PIPE_CAP_COPY_BETWEEN_COMPRESSED_AND_PLAIN_FORMATS``:
   Whether copying between compressed and plain formats is supported where
   a compressed block is copied to/from a plain pixel of the same size.
+* ``PIPE_CAP_CLEAR_TEXTURE``: Whether `clear_texture` will be
+  available in contexts.
 
 
 .. _pipe_capf:
diff --git a/src/gallium/drivers/freedreno/freedreno_screen.c 
b/src/gallium/drivers/freedreno/freedreno_screen.c
index 2369a10..8e3519a 100644
--- a/src/gallium/drivers/freedreno/freedreno_screen.c
+++ b/src/gallium/drivers/freedreno/freedreno_screen.c
@@ -239,6 +239,7 @@ fd_screen_get_param(struct pipe_screen *pscreen, enum 
pipe_cap param)
case PIPE_CAP_FORCE_PERSAMPLE_INTERP:
case PIPE_CAP_SHAREABLE_SHADERS:
case PIPE_CAP_COPY_BETWEEN_COMPRESSED_AND_PLAIN_FORMATS:
+   case PIPE_CAP_CLEAR_TEXTURE:
return 0;
 
case PIPE_CAP_MAX_VIEWPORTS:
diff --git a/src/gallium/drivers/i915/i915_screen.c 
b/src/gallium/drivers/i915/i915_screen.c
index 2d2fd37..a5b1618 100644
--- a/src/gallium/drivers/i915/i915_screen.c
+++ b/src/gallium/drivers/i915/i915_screen.c
@@ -253,6 +253,7 @@ i915_get_param(struct pipe_screen *screen, enum pipe_cap 
cap)
case PIPE_CAP_FORCE_PERSAMPLE_INTERP:
case PIPE_CAP_SHAREABLE_SHADERS:
case PIPE_CAP_COPY_BETWEEN_COMPRESSED_AND_PLAIN_FORMATS:
+   case PIPE_CAP_CLEAR_TEXTURE:
   return 0;
 
case PIPE_CAP_MAX_DUAL_SOURCE_RENDER_TARGETS:
diff --git a/src/gallium/drivers/ilo/ilo_screen.c 
b/src/gallium/drivers/ilo/ilo_screen.c
index 888f7aa..cfa2fb4 100644
--- a/src/gallium/drivers/ilo/ilo_screen.c
+++ b/src/gallium/drivers/ilo/ilo_screen.c
@@ -475,6 +475,7 @@ ilo_get_param(struct pipe_screen *screen, enum pipe_cap 
param)
case PIPE_CAP_FORCE_PERSAMPLE_INTERP:
case PIPE_CAP_SHAREABLE_SHADERS:
case PIPE_CAP_COPY_BETWEEN_COMPRESSED_AND_PLAIN_FORMATS:
+   case PIPE_CAP_CLEAR_TEXTURE:
   return 0;
 
case PIPE_CAP_VENDOR_ID:
diff --git a/src/gallium/drivers/llvmpipe/lp_screen.c 
b/src/gallium/drivers/llvmpipe/lp_screen.c
index d1c50ae..9f5e737 100644
--- a/src/gallium/drivers/llvmpipe/lp_screen.c
+++ b/src/gallium/drivers/llvmpipe/lp_screen.c
@@ -300,6 +300,7 @@ llvmpipe_get_param(struct pipe_screen *screen, enum 
pipe_cap param)
case PIPE_CAP_FORCE_PERSAMPLE_INTERP:
case PIPE_CAP_SHAREABLE_SHADERS:
case PIPE_CAP_COPY_BETWEEN_COMPRESSED_AND_PLAIN_FORMATS:
+   case PIPE_CAP_CLEAR_TEXTURE:
   return 0;
}
/* should only get here on unhandled cases */
diff --git a/src/gallium/drivers/nouveau/nv30/nv30_screen.c 
b/src/gallium/drivers/nouveau/nv30/nv30_screen.c
index f9e74b1..d4bfc50 100644
--- a/src/gallium/drivers/nouveau/nv30/nv30_screen.c
+++ b/src/gallium/drivers/nouveau/nv30/nv30_screen.c
@@ -173,6 +173,7 @@ 

[Mesa-dev] [PATCH 0/3] gallium: add ARB_clear_texture infrastructure

[Ilia Mirkin]

This is basically a resend of a series I wrote over a year ago. I
don't remember what we hated about it last time, but I'm tempted not
to look. This seems pretty reasonably to me now.

A refactoring opportunity exists to remove ->clear_render_target and
->clear_depth_stencil, but... that can be done later.

Note that for nvc0 I still have to keep separate paths for
color/stencil, which is a bit unfortunate, but the hardware complains
otherwise.

Ilia Mirkin (3):
  gallium: add PIPE_CAP_CLEAR_TEXTURE and clear_texture prototype
  st/mesa: implement ARB_clear_texture
  nvc0: add ARB_clear_texture support

 docs/GL3.txt |  2 +-
 docs/relnotes/11.1.0.html|  1 +
 src/gallium/docs/source/context.rst  |  4 ++
 src/gallium/docs/source/screen.rst   |  2 +
 src/gallium/drivers/freedreno/freedreno_screen.c |  1 +
 src/gallium/drivers/i915/i915_screen.c   |  1 +
 src/gallium/drivers/ilo/ilo_screen.c |  1 +
 src/gallium/drivers/llvmpipe/lp_screen.c |  1 +
 src/gallium/drivers/nouveau/nv30/nv30_screen.c   |  1 +
 src/gallium/drivers/nouveau/nv50/nv50_screen.c   |  1 +
 src/gallium/drivers/nouveau/nvc0/nvc0_screen.c   |  1 +
 src/gallium/drivers/nouveau/nvc0/nvc0_surface.c  | 82 
 src/gallium/drivers/r300/r300_screen.c   |  1 +
 src/gallium/drivers/r600/r600_pipe.c |  1 +
 src/gallium/drivers/radeonsi/si_pipe.c   |  1 +
 src/gallium/drivers/softpipe/sp_screen.c |  1 +
 src/gallium/drivers/svga/svga_screen.c   |  1 +
 src/gallium/drivers/vc4/vc4_screen.c |  1 +
 src/gallium/drivers/virgl/virgl_screen.c |  1 +
 src/gallium/include/pipe/p_context.h | 10 +++
 src/gallium/include/pipe/p_defines.h |  1 +
 src/mesa/state_tracker/st_cb_texture.c   | 29 +
 src/mesa/state_tracker/st_extensions.c   |  1 +
 23 files changed, 145 insertions(+), 1 deletion(-)

-- 
2.4.10

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

Re: [Mesa-dev] [PATCH v2 shader-db] report.py: rework and update for cycle info

[Matt Turner]

On Fri, Oct 30, 2015 at 10:49 AM, Connor Abbott  wrote:
> Ping. I just pushed the corresponding mesa patch to master yesterday,
> so I'd like to get this landed in shader-db soon.

Acked-by: Matt Turner 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] glsl: Drop exec_list argument to lower_ubo_reference

[Iago Toral]

Reviewed-by: Iago Toral Quiroga 

On Wed, 2015-11-04 at 15:33 -0800, Kristian Høgsberg Kristensen wrote:
> We always pass in shader->ir and we already pass in the shader, so just
> drop the exec_list. Most passes either take just a exec_list or a
> shader, so this seems more consistent.
> 
> Signed-off-by: Kristian Høgsberg Kristensen 
> ---
>  src/glsl/ir_optimization.h | 2 +-
>  src/glsl/lower_ubo_reference.cpp   | 4 ++--
>  src/mesa/drivers/dri/i965/brw_link.cpp | 2 +-
>  src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 2 +-
>  4 files changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/src/glsl/ir_optimization.h b/src/glsl/ir_optimization.h
> index ce5c492..6d19a6c 100644
> --- a/src/glsl/ir_optimization.h
> +++ b/src/glsl/ir_optimization.h
> @@ -124,7 +124,7 @@ bool lower_const_arrays_to_uniforms(exec_list 
> *instructions);
>  bool lower_clip_distance(gl_shader *shader);
>  void lower_output_reads(unsigned stage, exec_list *instructions);
>  bool lower_packing_builtins(exec_list *instructions, int op_mask);
> -void lower_ubo_reference(struct gl_shader *shader, exec_list *instructions);
> +void lower_ubo_reference(struct gl_shader *shader);
>  void lower_packed_varyings(void *mem_ctx,
> unsigned locations_used, ir_variable_mode mode,
> unsigned gs_input_vertices, gl_shader *shader);
> diff --git a/src/glsl/lower_ubo_reference.cpp 
> b/src/glsl/lower_ubo_reference.cpp
> index 57a242b..24806ac 100644
> --- a/src/glsl/lower_ubo_reference.cpp
> +++ b/src/glsl/lower_ubo_reference.cpp
> @@ -1270,7 +1270,7 @@ lower_ubo_reference_visitor::visit_enter(ir_call *ir)
>  } /* unnamed namespace */
>  
>  void
> -lower_ubo_reference(struct gl_shader *shader, exec_list *instructions)
> +lower_ubo_reference(struct gl_shader *shader)
>  {
> lower_ubo_reference_visitor v(shader);
>  
> @@ -1281,6 +1281,6 @@ lower_ubo_reference(struct gl_shader *shader, exec_list 
> *instructions)
>  */
> do {
>v.progress = false;
> -  visit_list_elements(, instructions);
> +  visit_list_elements(, shader->ir);
> } while (v.progress);
>  }
> diff --git a/src/mesa/drivers/dri/i965/brw_link.cpp 
> b/src/mesa/drivers/dri/i965/brw_link.cpp
> index fc9bee4..f1e3860 100644
> --- a/src/mesa/drivers/dri/i965/brw_link.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_link.cpp
> @@ -157,7 +157,7 @@ process_glsl_ir(gl_shader_stage stage,
>   _mesa_shader_stage_to_abbrev(shader->Stage));
> }
>  
> -   lower_ubo_reference(shader, shader->ir);
> +   lower_ubo_reference(shader);
>  
> bool progress;
> do {
> diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp 
> b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
> index f481e89..ca00930 100644
> --- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
> +++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
> @@ -5822,7 +5822,7 @@ st_link_shader(struct gl_context *ctx, struct 
> gl_shader_program *prog)
>   (!ctx->Const.NativeIntegers ? INT_DIV_TO_MUL_RCP : 
> 0) |
>   (options->EmitNoSat ? SAT_TO_CLAMP : 0));
>  
> -  lower_ubo_reference(prog->_LinkedShaders[i], ir);
> +  lower_ubo_reference(prog->_LinkedShaders[i]);
>do_vec_index_to_cond_assign(ir);
>lower_vector_insert(ir, true);
>lower_quadop_vector(ir, false);


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

Re: [Mesa-dev] [PATCH 2/3] glsl: Lower UBO and SSBO access in glsl linker

[Iago Toral]

On Wed, 2015-11-04 at 15:33 -0800, Kristian Høgsberg Kristensen wrote:
> All GLSL IR consumers run this lowering pass so we can move it to the
> linker. This moves the pass up quite a bit, but that's the point: it
> needs to run before we throw away information about per-component vector
> access.
> 
> Signed-off-by: Kristian Høgsberg Kristensen 
> ---
>  src/glsl/linker.cpp| 8 
>  src/mesa/drivers/dri/i965/brw_link.cpp | 2 --
>  src/mesa/drivers/dri/i965/brw_shader.cpp   | 2 ++
>  src/mesa/main/mtypes.h | 2 ++
>  src/mesa/state_tracker/st_extensions.c | 1 +
>  src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 1 -
>  6 files changed, 13 insertions(+), 3 deletions(-)
> 
> diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
> index c35d87a..ea6a3f3 100644
> --- a/src/glsl/linker.cpp
> +++ b/src/glsl/linker.cpp
> @@ -4449,6 +4449,14 @@ link_shaders(struct gl_context *ctx, struct 
> gl_shader_program *prog)
>  
> /* FINISHME: Assign fragment shader output locations. */
>  
> +   for (unsigned i = 0; i < MESA_SHADER_STAGES; i++) {
> +  if (prog->_LinkedShaders[i] == NULL)
> +  continue;
> +
> +  if (ctx->Const.ShaderCompilerOptions[i].LowerBufferInterfaceBlocks)
> + lower_ubo_reference(prog->_LinkedShaders[i]);
> +   }
> +

It probably makes more sense to rewrite this loop as:

if (ctx->Const.ShaderCompilerOptions[i].LowerBufferInterfaceBlocks) {
   for (unsigned i = 0; i < MESA_SHADER_STAGES; i++) {
  if (prog->_LinkedShaders[i] != NULL)
 lower_ubo_reference(prog->_LinkedShaders[i]);
   }
}

With that change, and assuming that this change is not responsible for
the shader-db regressions posted by Jason:

Reviewed-by: Iago Toral Quiroga 

>  done:
> for (unsigned i = 0; i < MESA_SHADER_STAGES; i++) {
>free(shader_list[i]);
> diff --git a/src/mesa/drivers/dri/i965/brw_link.cpp 
> b/src/mesa/drivers/dri/i965/brw_link.cpp
> index f1e3860..2991173 100644
> --- a/src/mesa/drivers/dri/i965/brw_link.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_link.cpp
> @@ -157,8 +157,6 @@ process_glsl_ir(gl_shader_stage stage,
>   _mesa_shader_stage_to_abbrev(shader->Stage));
> }
>  
> -   lower_ubo_reference(shader);
> -
> bool progress;
> do {
>progress = false;
> diff --git a/src/mesa/drivers/dri/i965/brw_shader.cpp 
> b/src/mesa/drivers/dri/i965/brw_shader.cpp
> index 4ea297a..5adc986 100644
> --- a/src/mesa/drivers/dri/i965/brw_shader.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_shader.cpp
> @@ -148,6 +148,8 @@ brw_compiler_create(void *mem_ctx, const struct 
> brw_device_info *devinfo)
>   compiler->glsl_compiler_options[i].EmitNoIndirectSampler = true;
>  
>compiler->glsl_compiler_options[i].NirOptions = nir_options;
> +
> +  compiler->glsl_compiler_options[i].LowerBufferInterfaceBlocks = true;
> }
>  
> return compiler;
> diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
> index d6c1eb8..800ad81 100644
> --- a/src/mesa/main/mtypes.h
> +++ b/src/mesa/main/mtypes.h
> @@ -2874,6 +2874,8 @@ struct gl_shader_compiler_options
>  */
> GLboolean OptimizeForAOS;
>  
> +   GLboolean LowerBufferInterfaceBlocks; /**< Lower UBO and SSBO access to 
> intrinsics. */
> +
> const struct nir_shader_compiler_options *NirOptions;
>  };
>  
> diff --git a/src/mesa/state_tracker/st_extensions.c 
> b/src/mesa/state_tracker/st_extensions.c
> index bd7cbcc..bbb9027 100644
> --- a/src/mesa/state_tracker/st_extensions.c
> +++ b/src/mesa/state_tracker/st_extensions.c
> @@ -254,6 +254,7 @@ void st_init_limits(struct pipe_screen *screen,
>
> PIPE_SHADER_CAP_MAX_UNROLL_ITERATIONS_HINT);
>  
>options->LowerClipDistance = true;
> +  options->LowerBufferInterfaceBlocks = true;
> }
>  
> c->LowerTessLevel = true;
> diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp 
> b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
> index ca00930..9ee6f8f 100644
> --- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
> +++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
> @@ -5822,7 +5822,6 @@ st_link_shader(struct gl_context *ctx, struct 
> gl_shader_program *prog)
>   (!ctx->Const.NativeIntegers ? INT_DIV_TO_MUL_RCP : 
> 0) |
>   (options->EmitNoSat ? SAT_TO_CLAMP : 0));
>  
> -  lower_ubo_reference(prog->_LinkedShaders[i]);
>do_vec_index_to_cond_assign(ir);
>lower_vector_insert(ir, true);
>lower_quadop_vector(ir, false);


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

Re: [Mesa-dev] nir/i965: Source modifiers on vecN opcodes

[Connor Abbott]

On Mon, Nov 9, 2015 at 6:55 AM, Iago Toral  wrote:
> Hi,
>
> Currently, NIR defines vecN operations as unsigned (integer). The fp64
> patches from Connor change this to float (I guess because we need to
> know the case where we are packing vectors of 64-bit floats). However,
> this makes it so that  nir_lower_source_to_mods turns this:
>
> vec1 ssa_2 = fmov -ssa_1.y
> vec3 ssa_3 = vec3 ssa_1, ssa_2, ssa_0
>
> into:
>
> vec3 ssa_2 = vec3 ssa_1, -ssa_1.y, ssa_0
>
> This only happens because the vec3 operation is defined as a float
> operation now, otherwise it would not try to do this. It is not clear to
> me if this is by design, I mean, have this kind of things only kick-in
> for float/int and define vecN operations as unsigned to avoid this for
> them.
>
> The problem comes later when we call nir_lower_vec_to_movs in the i965
> vec4 backend. That pass generates a separate MOV for each component in
> the vector, but to do that properly when a negate is involved it needs
> to know if this is a float or an integer operand, which it  does not
> know at this point. The current code always emits an imov, which won't
> work if the operand is a float.
>
> I can think of two solutions for this:
>
> 1) Change nir_lower_source_to_mods so it does not try to rewrite alu
> operations where a source comes from a fmov with a negate, or at least
> if the instruction we are trying to rewrite is a vecN operation (or
> maybe allow this in scalar mode only?)
>
> 2) In nir_lower_vec_to_movs, if a source is negated, check its
> parent_instr and try to guess its type from that (in this example, we
> would see it came from fmov and we can say it is a float and emit fmov
> instead of imov). Not sure if this would work in all possible scenarios
> though.
>
> Opinions?
>
> Iago
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev

The only reason I changed vecN to produce floats is to avoid producing
64-bit integer instructions, which at one point the constant folding
infrastructure couldn't support (but now it can), so you can just
revert the change. Ofc the i965 backend won't be able to express this
directly, but for now you can silently change 64-bit integers to
floats and assert that they only happen in things that copy data
around.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] st/omx: straighten get/put_screen

[Liu, Leo]

>-Original Message-
>From: Emil Velikov [mailto:emil.l.veli...@gmail.com]
>Sent: Monday, November 09, 2015 8:17 AM
>To: mesa-dev@lists.freedesktop.org
>Cc: emil.l.veli...@gmail.com; Liu, Leo
>Subject: [PATCH] st/omx: straighten get/put_screen
>
>The current code is busted in a number of ways.
>
> - initially checks for omx_display (rather than omx_screen), which may or may
>not be around.
> - blindly feeds the empty env variable string to loader_open_device()

Should be treating empty string as one of incorrect string, which result in 
failing open.
Because user's intention is to use to env, if they put the empty string, here 
should be getting failed.

Either way:
Reviewed-by: Leo Liu 

Regards,
Leo

> - reads the env variable every time get_screen is called
> - the latter manifests into memory leaks, and other issues as one sets the
>variable between two get_screen calls.
>
>Additionally it cleans up a couple of extra bits
> - drops unneeded set/check of omx_display.
> - make the teardown (put_screen) order was not symmetrical to the setup
>(get_screen)
>
>Cc: Leo Liu 
>Signed-off-by: Emil Velikov 
>---
>
>Leo, feel free to point out if I'm loosing the plot and some of these don't 
>hold
>true.
>
>-Emil
>
> src/gallium/state_trackers/omx/entrypoint.c | 35 -
> 1 file changed, 19 insertions(+), 16 deletions(-)
>
>diff --git a/src/gallium/state_trackers/omx/entrypoint.c
>b/src/gallium/state_trackers/omx/entrypoint.c
>index 7df90b1..f99a620 100644
>--- a/src/gallium/state_trackers/omx/entrypoint.c
>+++ b/src/gallium/state_trackers/omx/entrypoint.c
>@@ -33,6 +33,7 @@
>
> #include 
> #include 
>+#include 
>
> #include 
>
>@@ -73,28 +74,32 @@ int
>omx_component_library_Setup(stLoaderComponentType **stComponents)
>
> struct vl_screen *omx_get_screen(void)
> {
>+   static bool first_time = true;
>pipe_mutex_lock(omx_lock);
>
>-   if (!omx_display) {
>-  omx_render_node = debug_get_option("OMX_RENDER_NODE", NULL);
>-  if (!omx_render_node) {
>- omx_display = XOpenDisplay(NULL);
>- if (!omx_display)
>-goto error;
>-  }
>-   }
>-
>if (!omx_screen) {
>+  if (first_time) {
>+ omx_render_node = debug_get_option("OMX_RENDER_NODE", NULL);
>+ if (omx_render_node && *omx_render_node == '\0')
>+omx_render_node = NULL;
>+
>+ first_time = false;
>+  }
>   if (omx_render_node) {
>  drm_fd = loader_open_device(omx_render_node);
>  if (drm_fd < 0)
> goto error;
>+
>  omx_screen = vl_drm_screen_create(drm_fd);
>  if (!omx_screen) {
> close(drm_fd);
> goto error;
>  }
>   } else {
>+ omx_display = XOpenDisplay(NULL);
>+ if (!omx_display)
>+goto error;
>+
>  omx_screen = vl_screen_create(omx_display, 0);
>  if (!omx_screen) {
> XCloseDisplay(omx_display); @@ -117,16 +122,14 @@ void
>omx_put_screen(void)  {
>pipe_mutex_lock(omx_lock);
>if ((--omx_usecount) == 0) {
>-  if (!omx_render_node) {
>- vl_screen_destroy(omx_screen);
>- if (omx_display)
>-XCloseDisplay(omx_display);
>-  } else {
>- close(drm_fd);
>+  if (omx_render_node) {
>  vl_drm_screen_destroy(omx_screen);
>+ close(drm_fd);
>+  } else {
>+ vl_screen_destroy(omx_screen);
>+ XCloseDisplay(omx_display);
>   }
>   omx_screen = NULL;
>-  omx_display = NULL;
>}
>pipe_mutex_unlock(omx_lock);
> }
>--
>2.6.2

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

Re: [Mesa-dev] nir/i965: Source modifiers on vecN opcodes

[Jason Ekstrand]

On Nov 9, 2015 7:24 AM, "Connor Abbott"  wrote:
>
> On Mon, Nov 9, 2015 at 6:55 AM, Iago Toral  wrote:
> > Hi,
> >
> > Currently, NIR defines vecN operations as unsigned (integer). The fp64
> > patches from Connor change this to float (I guess because we need to
> > know the case where we are packing vectors of 64-bit floats). However,
> > this makes it so that  nir_lower_source_to_mods turns this:
> >
> > vec1 ssa_2 = fmov -ssa_1.y
> > vec3 ssa_3 = vec3 ssa_1, ssa_2, ssa_0
> >
> > into:
> >
> > vec3 ssa_2 = vec3 ssa_1, -ssa_1.y, ssa_0
> >
> > This only happens because the vec3 operation is defined as a float
> > operation now, otherwise it would not try to do this. It is not clear to
> > me if this is by design, I mean, have this kind of things only kick-in
> > for float/int and define vecN operations as unsigned to avoid this for
> > them.
> >
> > The problem comes later when we call nir_lower_vec_to_movs in the i965
> > vec4 backend. That pass generates a separate MOV for each component in
> > the vector, but to do that properly when a negate is involved it needs
> > to know if this is a float or an integer operand, which it  does not
> > know at this point. The current code always emits an imov, which won't
> > work if the operand is a float.
> >
> > I can think of two solutions for this:
> >
> > 1) Change nir_lower_source_to_mods so it does not try to rewrite alu
> > operations where a source comes from a fmov with a negate, or at least
> > if the instruction we are trying to rewrite is a vecN operation (or
> > maybe allow this in scalar mode only?)
> >
> > 2) In nir_lower_vec_to_movs, if a source is negated, check its
> > parent_instr and try to guess its type from that (in this example, we
> > would see it came from fmov and we can say it is a float and emit fmov
> > instead of imov). Not sure if this would work in all possible scenarios
> > though.
> >
> > Opinions?
> >
> > Iago
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
> The only reason I changed vecN to produce floats is to avoid producing
> 64-bit integer instructions, which at one point the constant folding
> infrastructure couldn't support (but now it can), so you can just
> revert the change. Ofc the i965 backend won't be able to express this
> directly, but for now you can silently change 64-bit integers to
> floats and assert that they only happen in things that copy data
> around.

I would tend to agree.  We could also make it unsigned so no source
modifiers ever make sense.  Meh.

If we did want to keep vecN float, the thing to do would be to make
vec_to_move lower it to fmovs rather than imovs.  But, like Connor said,
just asserting no source modifiers for th 64-bit version in the backend is
probably best.

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

Re: [Mesa-dev] [PATCH 3/3] nvc0: add ARB_clear_texture support

[Samuel Pitoiset]

On 11/09/2015 09:03 PM, Ilia Mirkin wrote:

On Mon, Nov 9, 2015 at 2:58 PM, Samuel Pitoiset
 wrote:



On 11/09/2015 07:40 PM, Ilia Mirkin wrote:


Signed-off-by: Ilia Mirkin 
---
   docs/GL3.txt|  2 +-
   docs/relnotes/11.1.0.html   |  1 +
   src/gallium/drivers/nouveau/nvc0/nvc0_screen.c  |  2 +-
   src/gallium/drivers/nouveau/nvc0/nvc0_surface.c | 82
+
   4 files changed, 85 insertions(+), 2 deletions(-)

diff --git a/docs/GL3.txt b/docs/GL3.txt
index 7abdcd8..da0ffca 100644
--- a/docs/GL3.txt
+++ b/docs/GL3.txt
@@ -177,7 +177,7 @@ GL 4.4, GLSL 4.40:

 GL_MAX_VERTEX_ATTRIB_STRIDE  DONE (all
drivers)
 GL_ARB_buffer_storageDONE (i965, nv50,
nvc0, r600, radeonsi)
-  GL_ARB_clear_texture DONE (i965)
(gallium - in progress, VMware)
+  GL_ARB_clear_texture DONE (i965, nvc0)
 GL_ARB_enhanced_layouts  in progress
(Timothy)
 - compile-time constant expressions  in progress
 - explicit byte offsets for blocks   in progress
diff --git a/docs/relnotes/11.1.0.html b/docs/relnotes/11.1.0.html
index 11fbdff..33fd0b8 100644
--- a/docs/relnotes/11.1.0.html
+++ b/docs/relnotes/11.1.0.html
@@ -46,6 +46,7 @@ Note: some of the new features are only available with
certain drivers.
   
   GL_ARB_arrays_of_arrays on i965
   GL_ARB_blend_func_extended on freedreno (a3xx)
+GL_ARB_clear_texture on nvc0
   GL_ARB_copy_image on nv50, nvc0, radeonsi
   GL_ARB_gpu_shader_fp64 on r600 for Cypress/Cayman/Aruba chips
   GL_ARB_gpu_shader5 on r600 for Evergreen and later chips
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
index f2e3bf0..fbeec7f 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
@@ -182,6 +182,7 @@ nvc0_screen_get_param(struct pipe_screen *pscreen,
enum pipe_cap param)
  case PIPE_CAP_COPY_BETWEEN_COMPRESSED_AND_PLAIN_FORMATS:
  case PIPE_CAP_FORCE_PERSAMPLE_INTERP:
  case PIPE_CAP_SHAREABLE_SHADERS:
+   case PIPE_CAP_CLEAR_TEXTURE:
 return 1;
  case PIPE_CAP_SEAMLESS_CUBE_MAP_PER_TEXTURE:
 return (class_3d >= NVE4_3D_CLASS) ? 1 : 0;
@@ -204,7 +205,6 @@ nvc0_screen_get_param(struct pipe_screen *pscreen,
enum pipe_cap param)
  case PIPE_CAP_VERTEXID_NOBASE:
  case PIPE_CAP_RESOURCE_FROM_USER_MEMORY:
  case PIPE_CAP_DEVICE_RESET_STATUS_QUERY:
-   case PIPE_CAP_CLEAR_TEXTURE:
 return 0;

  case PIPE_CAP_VENDOR_ID:
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_surface.c
b/src/gallium/drivers/nouveau/nvc0/nvc0_surface.c
index 5f47bad..3ae9943 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_surface.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_surface.c
@@ -319,6 +319,8 @@ nvc0_clear_render_target(struct pipe_context *pipe,
 PUSH_DATA(push, dst->u.tex.first_layer + sf->depth);
 PUSH_DATA(push, mt->layer_stride >> 2);
 PUSH_DATA(push, dst->u.tex.first_layer);
+
+  IMMED_NVC0(push, NVC0_3D(MULTISAMPLE_MODE), mt->ms_mode);
  } else {
 if (res->base.target == PIPE_BUFFER) {
PUSH_DATA(push, 262144);
@@ -540,6 +542,7 @@ nvc0_clear_depth_stencil(struct pipe_context *pipe,
  PUSH_DATA (push, (unk << 16) | (dst->u.tex.first_layer + sf->depth));
  BEGIN_NVC0(push, NVC0_3D(ZETA_BASE_LAYER), 1);
  PUSH_DATA (push, dst->u.tex.first_layer);
+   IMMED_NVC0(push, NVC0_3D(MULTISAMPLE_MODE), mt->ms_mode);

  BEGIN_NIC0(push, NVC0_3D(CLEAR_BUFFERS), sf->depth);
  for (z = 0; z < sf->depth; ++z) {
@@ -550,6 +553,84 @@ nvc0_clear_depth_stencil(struct pipe_context *pipe,
  nvc0->dirty |= NVC0_NEW_FRAMEBUFFER;
   }

+static void
+nvc0_clear_texture(struct pipe_context *pipe,
+   struct pipe_resource *res,
+   unsigned level,
+   const struct pipe_box *box,
+   const void *data)
+{
+   struct nv50_miptree *mt = nv50_miptree(res);
+   struct nv50_surface sf = {{{0}}};



I'm just curious about this, does '= {}' is not enough?


I wanted to be *really* sure it got initialized... figured 3 sets was enough :)

But seriously -- allegedly some compilers don't like that. I can't be
bothered to check on the actual situation, so I'm including the 0 in
there. And gcc wanted more {} since the first field was a struct whose
first field was a struct, etc.


Okay, I think it's *really* initialized. :)
But maybe, a memset() call could be better (really doesn't matter).

Anyway, I'm not quite familiar with that part of the driver to add a Rb 
but it looks fine. I hope you did a full piglit run this time. ;)




   -ilia


___
mesa-dev mailing list

Re: [Mesa-dev] [PATCH 1/7] i965/fs_surface_builder: Explicitly handle FORMAT_NONE in num_image_coordinates

[Chad Versace]

On Wed 04 Nov 2015, Jason Ekstrand wrote:
> Previously, we were relying on has_matching_typed_format returning true for
> MESA_FORMAT_NONE which, in turn, relied on _mesa_get_format_bytes returning
> 1 for MESA_FORMAT_NONE.  All of this is extremely non-obvious.  Instead,
> this commit makes us handle it explicitly.
> ---
>  src/mesa/drivers/dri/i965/brw_fs_surface_builder.cpp | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/src/mesa/drivers/dri/i965/brw_fs_surface_builder.cpp 
> b/src/mesa/drivers/dri/i965/brw_fs_surface_builder.cpp
> index 534d849..31ecb5b 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs_surface_builder.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs_surface_builder.cpp
> @@ -409,6 +409,7 @@ namespace {
>* reads want the array index to be at the Z component.
>*/
>   const bool array_index_at_z =
> +format != MESA_FORMAT_NONE &&
>  !image_format_info::has_matching_typed_format(
> bld.shader->devinfo, format);
>   const unsigned zero_dims =


Knowing nothing about the implicit assumptions you discovered that
relied on _mesa_get_format_bytes(MESA_FORMAT_NONE) => 1, the patch is
still looks like an improvement to me.

Acked-by: Chad Versace 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/7] i965: Add a variant of lower_mesa_image_format that takes native formats

[Chad Versace]

On Wed 04 Nov 2015, Jason Ekstrand wrote:
> Eventually, we'll switch over to this new function and delete the old one
> completely.  However, duplicating it both makes the transition smoother and
> allows us to assert that they are the same.
> 
> While we're at it, we start a new file for collecting the various bits of
> the image_load_store workarounds.
> ---
>  src/mesa/drivers/dri/i965/Makefile.sources   |   2 +
>  src/mesa/drivers/dri/i965/brw_image_load_store.c | 138 
> +++
>  src/mesa/drivers/dri/i965/brw_image_load_store.h |  38 +++
>  src/mesa/drivers/dri/i965/brw_wm_surface_state.c |  10 +-
>  4 files changed, 186 insertions(+), 2 deletions(-)
>  create mode 100644 src/mesa/drivers/dri/i965/brw_image_load_store.c
>  create mode 100644 src/mesa/drivers/dri/i965/brw_image_load_store.h

My mind became numb when reviewing the sed job. Everything looked
correct, though, until I became bored.

Reviewed-by: Chad Versace 

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

Re: [Mesa-dev] [PATCH 3/3] nvc0: add ARB_clear_texture support

[Samuel Pitoiset]

On 11/09/2015 07:40 PM, Ilia Mirkin wrote:

Signed-off-by: Ilia Mirkin 
---
  docs/GL3.txt|  2 +-
  docs/relnotes/11.1.0.html   |  1 +
  src/gallium/drivers/nouveau/nvc0/nvc0_screen.c  |  2 +-
  src/gallium/drivers/nouveau/nvc0/nvc0_surface.c | 82 +
  4 files changed, 85 insertions(+), 2 deletions(-)

diff --git a/docs/GL3.txt b/docs/GL3.txt
index 7abdcd8..da0ffca 100644
--- a/docs/GL3.txt
+++ b/docs/GL3.txt
@@ -177,7 +177,7 @@ GL 4.4, GLSL 4.40:

GL_MAX_VERTEX_ATTRIB_STRIDE  DONE (all drivers)
GL_ARB_buffer_storageDONE (i965, nv50, 
nvc0, r600, radeonsi)
-  GL_ARB_clear_texture DONE (i965) (gallium - 
in progress, VMware)
+  GL_ARB_clear_texture DONE (i965, nvc0)
GL_ARB_enhanced_layouts  in progress (Timothy)
- compile-time constant expressions  in progress
- explicit byte offsets for blocks   in progress
diff --git a/docs/relnotes/11.1.0.html b/docs/relnotes/11.1.0.html
index 11fbdff..33fd0b8 100644
--- a/docs/relnotes/11.1.0.html
+++ b/docs/relnotes/11.1.0.html
@@ -46,6 +46,7 @@ Note: some of the new features are only available with 
certain drivers.
  
  GL_ARB_arrays_of_arrays on i965
  GL_ARB_blend_func_extended on freedreno (a3xx)
+GL_ARB_clear_texture on nvc0
  GL_ARB_copy_image on nv50, nvc0, radeonsi
  GL_ARB_gpu_shader_fp64 on r600 for Cypress/Cayman/Aruba chips
  GL_ARB_gpu_shader5 on r600 for Evergreen and later chips
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
index f2e3bf0..fbeec7f 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
@@ -182,6 +182,7 @@ nvc0_screen_get_param(struct pipe_screen *pscreen, enum 
pipe_cap param)
 case PIPE_CAP_COPY_BETWEEN_COMPRESSED_AND_PLAIN_FORMATS:
 case PIPE_CAP_FORCE_PERSAMPLE_INTERP:
 case PIPE_CAP_SHAREABLE_SHADERS:
+   case PIPE_CAP_CLEAR_TEXTURE:
return 1;
 case PIPE_CAP_SEAMLESS_CUBE_MAP_PER_TEXTURE:
return (class_3d >= NVE4_3D_CLASS) ? 1 : 0;
@@ -204,7 +205,6 @@ nvc0_screen_get_param(struct pipe_screen *pscreen, enum 
pipe_cap param)
 case PIPE_CAP_VERTEXID_NOBASE:
 case PIPE_CAP_RESOURCE_FROM_USER_MEMORY:
 case PIPE_CAP_DEVICE_RESET_STATUS_QUERY:
-   case PIPE_CAP_CLEAR_TEXTURE:
return 0;

 case PIPE_CAP_VENDOR_ID:
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_surface.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_surface.c
index 5f47bad..3ae9943 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_surface.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_surface.c
@@ -319,6 +319,8 @@ nvc0_clear_render_target(struct pipe_context *pipe,
PUSH_DATA(push, dst->u.tex.first_layer + sf->depth);
PUSH_DATA(push, mt->layer_stride >> 2);
PUSH_DATA(push, dst->u.tex.first_layer);
+
+  IMMED_NVC0(push, NVC0_3D(MULTISAMPLE_MODE), mt->ms_mode);
 } else {
if (res->base.target == PIPE_BUFFER) {
   PUSH_DATA(push, 262144);
@@ -540,6 +542,7 @@ nvc0_clear_depth_stencil(struct pipe_context *pipe,
 PUSH_DATA (push, (unk << 16) | (dst->u.tex.first_layer + sf->depth));
 BEGIN_NVC0(push, NVC0_3D(ZETA_BASE_LAYER), 1);
 PUSH_DATA (push, dst->u.tex.first_layer);
+   IMMED_NVC0(push, NVC0_3D(MULTISAMPLE_MODE), mt->ms_mode);

 BEGIN_NIC0(push, NVC0_3D(CLEAR_BUFFERS), sf->depth);
 for (z = 0; z < sf->depth; ++z) {
@@ -550,6 +553,84 @@ nvc0_clear_depth_stencil(struct pipe_context *pipe,
 nvc0->dirty |= NVC0_NEW_FRAMEBUFFER;
  }

+static void
+nvc0_clear_texture(struct pipe_context *pipe,
+   struct pipe_resource *res,
+   unsigned level,
+   const struct pipe_box *box,
+   const void *data)
+{
+   struct nv50_miptree *mt = nv50_miptree(res);
+   struct nv50_surface sf = {{{0}}};


I'm just curious about this, does '= {}' is not enough?


+
+   assert(res->target != PIPE_BUFFER);
+
+   sf.base.texture = res;
+   sf.base.format = res->format;
+   sf.base.u.tex.first_layer = box->z;
+   sf.base.u.tex.last_layer = box->depth;
+   sf.base.u.tex.level = level;
+   sf.base.width = sf.width = res->width0 << mt->ms_x;
+   sf.base.height = sf.height = res->height0 << mt->ms_y;
+   sf.depth = box->depth;
+   sf.offset = mt->level[level].offset;
+
+   if (util_format_is_depth_or_stencil(res->format)) {
+  float depth = 0;
+  uint8_t stencil = 0;
+  unsigned clear = 0;
+  const struct util_format_description *desc =
+ util_format_description(res->format);
+
+  if (util_format_has_depth(desc)) {
+ clear |= PIPE_CLEAR_DEPTH;
+ desc->unpack_z_float(, 0, data, 0, 1, 1);
+  }
+  if (util_format_has_stencil(desc)) {
+ clear |= 

Re: [Mesa-dev] [PATCH 3/3] nvc0: add ARB_clear_texture support

[Ilia Mirkin]

On Mon, Nov 9, 2015 at 2:58 PM, Samuel Pitoiset
 wrote:
>
>
> On 11/09/2015 07:40 PM, Ilia Mirkin wrote:
>>
>> Signed-off-by: Ilia Mirkin 
>> ---
>>   docs/GL3.txt|  2 +-
>>   docs/relnotes/11.1.0.html   |  1 +
>>   src/gallium/drivers/nouveau/nvc0/nvc0_screen.c  |  2 +-
>>   src/gallium/drivers/nouveau/nvc0/nvc0_surface.c | 82
>> +
>>   4 files changed, 85 insertions(+), 2 deletions(-)
>>
>> diff --git a/docs/GL3.txt b/docs/GL3.txt
>> index 7abdcd8..da0ffca 100644
>> --- a/docs/GL3.txt
>> +++ b/docs/GL3.txt
>> @@ -177,7 +177,7 @@ GL 4.4, GLSL 4.40:
>>
>> GL_MAX_VERTEX_ATTRIB_STRIDE  DONE (all
>> drivers)
>> GL_ARB_buffer_storageDONE (i965, nv50,
>> nvc0, r600, radeonsi)
>> -  GL_ARB_clear_texture DONE (i965)
>> (gallium - in progress, VMware)
>> +  GL_ARB_clear_texture DONE (i965, nvc0)
>> GL_ARB_enhanced_layouts  in progress
>> (Timothy)
>> - compile-time constant expressions  in progress
>> - explicit byte offsets for blocks   in progress
>> diff --git a/docs/relnotes/11.1.0.html b/docs/relnotes/11.1.0.html
>> index 11fbdff..33fd0b8 100644
>> --- a/docs/relnotes/11.1.0.html
>> +++ b/docs/relnotes/11.1.0.html
>> @@ -46,6 +46,7 @@ Note: some of the new features are only available with
>> certain drivers.
>>   
>>   GL_ARB_arrays_of_arrays on i965
>>   GL_ARB_blend_func_extended on freedreno (a3xx)
>> +GL_ARB_clear_texture on nvc0
>>   GL_ARB_copy_image on nv50, nvc0, radeonsi
>>   GL_ARB_gpu_shader_fp64 on r600 for Cypress/Cayman/Aruba chips
>>   GL_ARB_gpu_shader5 on r600 for Evergreen and later chips
>> diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
>> b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
>> index f2e3bf0..fbeec7f 100644
>> --- a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
>> +++ b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
>> @@ -182,6 +182,7 @@ nvc0_screen_get_param(struct pipe_screen *pscreen,
>> enum pipe_cap param)
>>  case PIPE_CAP_COPY_BETWEEN_COMPRESSED_AND_PLAIN_FORMATS:
>>  case PIPE_CAP_FORCE_PERSAMPLE_INTERP:
>>  case PIPE_CAP_SHAREABLE_SHADERS:
>> +   case PIPE_CAP_CLEAR_TEXTURE:
>> return 1;
>>  case PIPE_CAP_SEAMLESS_CUBE_MAP_PER_TEXTURE:
>> return (class_3d >= NVE4_3D_CLASS) ? 1 : 0;
>> @@ -204,7 +205,6 @@ nvc0_screen_get_param(struct pipe_screen *pscreen,
>> enum pipe_cap param)
>>  case PIPE_CAP_VERTEXID_NOBASE:
>>  case PIPE_CAP_RESOURCE_FROM_USER_MEMORY:
>>  case PIPE_CAP_DEVICE_RESET_STATUS_QUERY:
>> -   case PIPE_CAP_CLEAR_TEXTURE:
>> return 0;
>>
>>  case PIPE_CAP_VENDOR_ID:
>> diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_surface.c
>> b/src/gallium/drivers/nouveau/nvc0/nvc0_surface.c
>> index 5f47bad..3ae9943 100644
>> --- a/src/gallium/drivers/nouveau/nvc0/nvc0_surface.c
>> +++ b/src/gallium/drivers/nouveau/nvc0/nvc0_surface.c
>> @@ -319,6 +319,8 @@ nvc0_clear_render_target(struct pipe_context *pipe,
>> PUSH_DATA(push, dst->u.tex.first_layer + sf->depth);
>> PUSH_DATA(push, mt->layer_stride >> 2);
>> PUSH_DATA(push, dst->u.tex.first_layer);
>> +
>> +  IMMED_NVC0(push, NVC0_3D(MULTISAMPLE_MODE), mt->ms_mode);
>>  } else {
>> if (res->base.target == PIPE_BUFFER) {
>>PUSH_DATA(push, 262144);
>> @@ -540,6 +542,7 @@ nvc0_clear_depth_stencil(struct pipe_context *pipe,
>>  PUSH_DATA (push, (unk << 16) | (dst->u.tex.first_layer + sf->depth));
>>  BEGIN_NVC0(push, NVC0_3D(ZETA_BASE_LAYER), 1);
>>  PUSH_DATA (push, dst->u.tex.first_layer);
>> +   IMMED_NVC0(push, NVC0_3D(MULTISAMPLE_MODE), mt->ms_mode);
>>
>>  BEGIN_NIC0(push, NVC0_3D(CLEAR_BUFFERS), sf->depth);
>>  for (z = 0; z < sf->depth; ++z) {
>> @@ -550,6 +553,84 @@ nvc0_clear_depth_stencil(struct pipe_context *pipe,
>>  nvc0->dirty |= NVC0_NEW_FRAMEBUFFER;
>>   }
>>
>> +static void
>> +nvc0_clear_texture(struct pipe_context *pipe,
>> +   struct pipe_resource *res,
>> +   unsigned level,
>> +   const struct pipe_box *box,
>> +   const void *data)
>> +{
>> +   struct nv50_miptree *mt = nv50_miptree(res);
>> +   struct nv50_surface sf = {{{0}}};
>
>
> I'm just curious about this, does '= {}' is not enough?

I wanted to be *really* sure it got initialized... figured 3 sets was enough :)

But seriously -- allegedly some compilers don't like that. I can't be
bothered to check on the actual situation, so I'm including the 0 in
there. And gcc wanted more {} since the first field was a struct whose
first field was a struct, etc.

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

Re: [Mesa-dev] [PATCH 0/3] gallium: add ARB_clear_texture infrastructure

[Roland Scheidegger]

Am 09.11.2015 um 19:40 schrieb Ilia Mirkin:
> This is basically a resend of a series I wrote over a year ago. I
> don't remember what we hated about it last time, but I'm tempted not
> to look. This seems pretty reasonably to me now.
I guess I wasn't entirely happy with yet another clear method... Still,
looks reasonable...

> 
> A refactoring opportunity exists to remove ->clear_render_target and
> ->clear_depth_stencil, but... that can be done later.
You could remove clear_render_target but not clear_depth_stencil, as the
latter allows clearing only depth or stencil.

Roland


> 
> Note that for nvc0 I still have to keep separate paths for
> color/stencil, which is a bit unfortunate, but the hardware complains
> otherwise.
> 
> Ilia Mirkin (3):
>   gallium: add PIPE_CAP_CLEAR_TEXTURE and clear_texture prototype
>   st/mesa: implement ARB_clear_texture
>   nvc0: add ARB_clear_texture support
> 
>  docs/GL3.txt |  2 +-
>  docs/relnotes/11.1.0.html|  1 +
>  src/gallium/docs/source/context.rst  |  4 ++
>  src/gallium/docs/source/screen.rst   |  2 +
>  src/gallium/drivers/freedreno/freedreno_screen.c |  1 +
>  src/gallium/drivers/i915/i915_screen.c   |  1 +
>  src/gallium/drivers/ilo/ilo_screen.c |  1 +
>  src/gallium/drivers/llvmpipe/lp_screen.c |  1 +
>  src/gallium/drivers/nouveau/nv30/nv30_screen.c   |  1 +
>  src/gallium/drivers/nouveau/nv50/nv50_screen.c   |  1 +
>  src/gallium/drivers/nouveau/nvc0/nvc0_screen.c   |  1 +
>  src/gallium/drivers/nouveau/nvc0/nvc0_surface.c  | 82 
> 
>  src/gallium/drivers/r300/r300_screen.c   |  1 +
>  src/gallium/drivers/r600/r600_pipe.c |  1 +
>  src/gallium/drivers/radeonsi/si_pipe.c   |  1 +
>  src/gallium/drivers/softpipe/sp_screen.c |  1 +
>  src/gallium/drivers/svga/svga_screen.c   |  1 +
>  src/gallium/drivers/vc4/vc4_screen.c |  1 +
>  src/gallium/drivers/virgl/virgl_screen.c |  1 +
>  src/gallium/include/pipe/p_context.h | 10 +++
>  src/gallium/include/pipe/p_defines.h |  1 +
>  src/mesa/state_tracker/st_cb_texture.c   | 29 +
>  src/mesa/state_tracker/st_extensions.c   |  1 +
>  23 files changed, 145 insertions(+), 1 deletion(-)
> 

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

Re: [Mesa-dev] [PATCH 3/3] nvc0: add ARB_clear_texture support

[Samuel Pitoiset]

On 11/09/2015 09:14 PM, Ilia Mirkin wrote:

On Mon, Nov 9, 2015 at 3:13 PM, Samuel Pitoiset
 wrote:



On 11/09/2015 09:03 PM, Ilia Mirkin wrote:


On Mon, Nov 9, 2015 at 2:58 PM, Samuel Pitoiset
 wrote:




On 11/09/2015 07:40 PM, Ilia Mirkin wrote:



Signed-off-by: Ilia Mirkin 
---
docs/GL3.txt|  2 +-
docs/relnotes/11.1.0.html   |  1 +
src/gallium/drivers/nouveau/nvc0/nvc0_screen.c  |  2 +-
src/gallium/drivers/nouveau/nvc0/nvc0_surface.c | 82
+
4 files changed, 85 insertions(+), 2 deletions(-)

diff --git a/docs/GL3.txt b/docs/GL3.txt
index 7abdcd8..da0ffca 100644
--- a/docs/GL3.txt
+++ b/docs/GL3.txt
@@ -177,7 +177,7 @@ GL 4.4, GLSL 4.40:

  GL_MAX_VERTEX_ATTRIB_STRIDE  DONE (all
drivers)
  GL_ARB_buffer_storageDONE (i965,
nv50,
nvc0, r600, radeonsi)
-  GL_ARB_clear_texture DONE (i965)
(gallium - in progress, VMware)
+  GL_ARB_clear_texture DONE (i965,
nvc0)
  GL_ARB_enhanced_layouts  in progress
(Timothy)
  - compile-time constant expressions  in progress
  - explicit byte offsets for blocks   in progress
diff --git a/docs/relnotes/11.1.0.html b/docs/relnotes/11.1.0.html
index 11fbdff..33fd0b8 100644
--- a/docs/relnotes/11.1.0.html
+++ b/docs/relnotes/11.1.0.html
@@ -46,6 +46,7 @@ Note: some of the new features are only available with
certain drivers.

GL_ARB_arrays_of_arrays on i965
GL_ARB_blend_func_extended on freedreno (a3xx)
+GL_ARB_clear_texture on nvc0
GL_ARB_copy_image on nv50, nvc0, radeonsi
GL_ARB_gpu_shader_fp64 on r600 for Cypress/Cayman/Aruba
chips
GL_ARB_gpu_shader5 on r600 for Evergreen and later chips
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
index f2e3bf0..fbeec7f 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
@@ -182,6 +182,7 @@ nvc0_screen_get_param(struct pipe_screen *pscreen,
enum pipe_cap param)
   case PIPE_CAP_COPY_BETWEEN_COMPRESSED_AND_PLAIN_FORMATS:
   case PIPE_CAP_FORCE_PERSAMPLE_INTERP:
   case PIPE_CAP_SHAREABLE_SHADERS:
+   case PIPE_CAP_CLEAR_TEXTURE:
  return 1;
   case PIPE_CAP_SEAMLESS_CUBE_MAP_PER_TEXTURE:
  return (class_3d >= NVE4_3D_CLASS) ? 1 : 0;
@@ -204,7 +205,6 @@ nvc0_screen_get_param(struct pipe_screen *pscreen,
enum pipe_cap param)
   case PIPE_CAP_VERTEXID_NOBASE:
   case PIPE_CAP_RESOURCE_FROM_USER_MEMORY:
   case PIPE_CAP_DEVICE_RESET_STATUS_QUERY:
-   case PIPE_CAP_CLEAR_TEXTURE:
  return 0;

   case PIPE_CAP_VENDOR_ID:
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_surface.c
b/src/gallium/drivers/nouveau/nvc0/nvc0_surface.c
index 5f47bad..3ae9943 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_surface.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_surface.c
@@ -319,6 +319,8 @@ nvc0_clear_render_target(struct pipe_context *pipe,
  PUSH_DATA(push, dst->u.tex.first_layer + sf->depth);
  PUSH_DATA(push, mt->layer_stride >> 2);
  PUSH_DATA(push, dst->u.tex.first_layer);
+
+  IMMED_NVC0(push, NVC0_3D(MULTISAMPLE_MODE), mt->ms_mode);
   } else {
  if (res->base.target == PIPE_BUFFER) {
 PUSH_DATA(push, 262144);
@@ -540,6 +542,7 @@ nvc0_clear_depth_stencil(struct pipe_context *pipe,
   PUSH_DATA (push, (unk << 16) | (dst->u.tex.first_layer +
sf->depth));
   BEGIN_NVC0(push, NVC0_3D(ZETA_BASE_LAYER), 1);
   PUSH_DATA (push, dst->u.tex.first_layer);
+   IMMED_NVC0(push, NVC0_3D(MULTISAMPLE_MODE), mt->ms_mode);

   BEGIN_NIC0(push, NVC0_3D(CLEAR_BUFFERS), sf->depth);
   for (z = 0; z < sf->depth; ++z) {
@@ -550,6 +553,84 @@ nvc0_clear_depth_stencil(struct pipe_context *pipe,
   nvc0->dirty |= NVC0_NEW_FRAMEBUFFER;
}

+static void
+nvc0_clear_texture(struct pipe_context *pipe,
+   struct pipe_resource *res,
+   unsigned level,
+   const struct pipe_box *box,
+   const void *data)
+{
+   struct nv50_miptree *mt = nv50_miptree(res);
+   struct nv50_surface sf = {{{0}}};




I'm just curious about this, does '= {}' is not enough?



I wanted to be *really* sure it got initialized... figured 3 sets was
enough :)

But seriously -- allegedly some compilers don't like that. I can't be
bothered to check on the actual situation, so I'm including the 0 in
there. And gcc wanted more {} since the first field was a struct whose
first field was a struct, etc.



Okay, I think it's *really* initialized. :)
But maybe, a memset() call could be better (really doesn't matter).


Should be functionally equivalent, but less verbose.


Sure.





Anyway, 

Re: [Mesa-dev] soft/llvmpipe front buffer access and piglit regressions

[Dave Airlie]

On 10 November 2015 at 00:30, Roland Scheidegger  wrote:
> Am 09.11.2015 um 04:44 schrieb Dave Airlie:
>> So it appears my patch to enable front buffer access on soft/llvmpipe
>> causes some piglit regressions. However these are due to piglit having
>> undefined behaviour where it doesn't create a window but has tests
>> requiring a front buffer. The new code does an XGetImage on the front
>> buffer and when it fails all sorts of bad things tend to happen. I
>> don't think there is a way to check if we have a window mapped inside
>> Mesa to avoid this path.
>>
>> swrast suffers from the same failure pattern in a number of tests when
>> run with -auto.
>>
>> I'm not sure what to do here, the patch is making the driver
>> conformant and is fixing a missing
>> feature being used by OpenGL apps (gtk).
>>
>> I can probably make it fail more gracefully (llvmpipe deadlocks on the
>> Xlib error path inside it's rasteriser threads), but I'm not sure I
>> want to go back to the old behaviour just to satisfy piglit's
>> requirement to do undefined things.
>>
>
> I don't really understand all this interface stuff, however it feels
> wrong to me that we have to care in the driver for something which you
> say is totally bogus. Couldn't that be handled outside? Albeit I don't
> really understand what exactly happens in the first place.

Well the bug is piglit runs tests without mapping the window. On DRI2
this works as we have the fake front buffer, so reading the front doesn't
require content on the screen. However it's really undefined behaviour for GL.

Now with drisw you use GetImage/PutImage to get things from the real front
buffer. However if the window is never mapped, these will return BadMatch,
and things fall over. However we have real apps wanting proper front buffer
interactions, and we have piglit wanting the undefined behaviour.

I think I'll decide in favour of the former, but it might be a bit of a shock to
people who run piglit runs and things start regressing.

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

Re: [Mesa-dev] [PATCH] i965/skl/gt4: Fix URB programming restriction.

[Ben Widawsky]

On Mon, Nov 09, 2015 at 11:50:25AM -0800, Kenneth Graunke wrote:
> On Saturday, November 07, 2015 08:40:51 AM Ben Widawsky wrote:
> > On Fri, Nov 06, 2015 at 07:29:18PM -0800, Kenneth Graunke wrote:
> > > On Friday, November 06, 2015 06:12:27 PM Ben Widawsky wrote:
> > > > The comment in the code details the restriction. Thanks to Ken for 
> > > > having a very
> > > > helpful conversation with me, and spotting the blurb in the link I sent 
> > > > him :P.
> > > > 
> > > > There are still stability problems for me on GT4, but this definitely 
> > > > helps with
> > > > some of the failures.
> > > > 
> > > > Cc: Kenneth Graunke 
> > > > Cc: Jordan Justen 
> > > > Cc: mesa-sta...@lists.freedesktop.org (if the original gt4 patch goes 
> > > > to stable)
> > > > ---
> > > > 
> > > > Sarah, you should check this on KBL.
> > > > Cc: Sarah Sharp 
> > > > ---
> > > >  src/mesa/drivers/dri/i965/brw_device_info.c | 8 
> > > >  1 file changed, 8 insertions(+)
> > > > 
> > > > diff --git a/src/mesa/drivers/dri/i965/brw_device_info.c 
> > > > b/src/mesa/drivers/dri/i965/brw_device_info.c
> > > > index 2ebc084..6117fd3 100644
> > > > --- a/src/mesa/drivers/dri/i965/brw_device_info.c
> > > > +++ b/src/mesa/drivers/dri/i965/brw_device_info.c
> > > > @@ -337,6 +337,14 @@ static const struct brw_device_info 
> > > > brw_device_info_skl_gt3 = {
> > > >  
> > > >  static const struct brw_device_info brw_device_info_skl_gt4 = {
> > > > GEN9_FEATURES, .gt = 4,
> > > > +   /* From the docs:
> > > > +*   URB is limited to 1008KB due to programming restrictions. This 
> > > > is not a
> > > > +*   restriction of the L3 implementation, but of the FF and other 
> > > > clients.
> > > > +*   Therefore, in a GT4 implementation it is possible for the 
> > > > programmed
> > > > +*   allocation of the L3 data array to provide 3*384KB=1152MB 
> > > > [sic] for URB,
> > > > +*   but only 1008KB of this will be used.
> > > > +*/
> > > 
> > > We should at least say which page/section this comes from (the section
> > > name exists in the Broadwell PRM, so it's not particularly secret).
> > > 
> > > Please put the text in quotes too.  My suggested formatting:
> > > 
> > >/* From the "L3 Allocation and Programming" documentation:
> > > *
> > > * "URB is limited to 1008KB due to programming restrictions.  This
> > > *  is not a restriction of the L3 implementation, but of the FF and
> > > *  other clients.  Therefore, in a GT4 implementation it is
> > > *  possible for the programmed allocation of the L3 data array to
> > > *  provide 3*384KB=1152MB [sic] for URB, but only 1008KB of this
> > > *  will be used."
> > > */
> > > 
> > > Regardless,
> > > Reviewed-by: Kenneth Graunke 
> > > 
> > 
> > Thanks! I had no idea it was in the BDW PRMs.
> 
> You can change "1152MB [sic]" to "1152KB" as they've fixed the docs :)
> 
> --Ken

That was fast. I'm working on the next hang before I push this, but I will
update it locally now.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 0/3] gallium: add ARB_clear_texture infrastructure

[Ilia Mirkin]

On Mon, Nov 9, 2015 at 3:29 PM, Roland Scheidegger  wrote:
> Am 09.11.2015 um 21:12 schrieb Ilia Mirkin:
>> On Mon, Nov 9, 2015 at 3:07 PM, Roland Scheidegger  
>> wrote:
>>> Am 09.11.2015 um 19:40 schrieb Ilia Mirkin:
 This is basically a resend of a series I wrote over a year ago. I
 don't remember what we hated about it last time, but I'm tempted not
 to look. This seems pretty reasonably to me now.
>>> I guess I wasn't entirely happy with yet another clear method... Still,
>>> looks reasonable...
>>
>> Yeah, I'm not madly in love with it either, but the various
>> functionality just isn't accessible otherwise. Internally the nvc0 and
>> nv50 impls reuse the clear_render_target/clear_depth_stencil
>> functions, but that's not generically possible since we have to be
>> able to clear non-renderable formats.
>>
>> I guess an alternative here is to say that we can redefine the format
>> of a surface to basically what I do in the nvc0 patch, I can move that
>> logic from nvc0 to st/mesa.
> I think if you don't have the rt, there's really not much point to
> redefine the surface format for clearing.

OK, so then we're stuck with the way I implemented it then. Unless
there are other suggestions. The requirement is to be able to clear
arbitrary textures with arbitrary texel data.

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

Re: [Mesa-dev] [PATCH 03/10] i965/skl: Enable fast color clears on SKL

[Chad Versace]

On Tue 03 Nov 2015, Ben Widawsky wrote:
> On Fri, Oct 16, 2015 at 04:10:02PM -0700, Chad Versace wrote:
> > But this patch doesn't enable fast clears! The reverts in pathches 6 and
> > 7 need to be folded into this patch, otherwise the patch does not do
> > what it claims.
> > 
> > Also, you can't enable fast clears before patches 4 and 5 without 
> > introducing
> > regressions. Patches 4 and 5 must precede this patch.
> > 
> 
> I did mention this in a later patch. I should have at least added that comment
> here as well and probably changed the short summary. To repeat what I had 
> there
> though, I really liked having the differing SKL functionality be split out in
> the separate patches and couldn't do it in my earlier patches because I didn't
> have the tiny one liners that you added for strictly disabling the fast 
> clears.
> I still prefer having these split out, and I consider that a pretty strong
> distinction given that I usually opt for fewer patches.
> 
> I've modified this locally to summarize the above. I haven't read your review
> comments for the patches after this yet. It's likely that you noticed this, 
> and
> we can continue the discussion there.

The commit subject says "Enable fast color clears on Skylake", but this
patch doesn't actually enable them. It's not until the revert in patch
7 that they're actually enabled.

The commit subject needs to reflect what the patch actually does.
Claiming it enables fast color clears creates a misleading git history.

> 
> > On Tue 13 Oct 2015, Ben Widawsky wrote:
> > > Based on a patch originally from Kristian. Skylake has extended 
> > > capabilities
> > > with regard to fast clears, but that is saved for another patch.
> > > 
> > > The same effect could be acheived with the following, however I think the 
> > > way
> > > I've done it is more in line with how the docs explain it.
> > > --- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> > > +++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> > > @@ -150,9 +150,13 @@ intel_get_non_msrt_mcs_alignment(struct brw_context 
> > > *brw,
> > >/* In release builds, fall through */
> > > case I915_TILING_Y:
> > >*width_px = 32 / mt->cpp;
> > > -  *height = 4;
> > > +  if (brw->gen >= 9)
> > > + *height = 2;
> > > +  else
> > > + *height = 4;
> > > 
> > > Signed-off-by: Ben Widawsky 
> > > ---
> > >  src/mesa/drivers/dri/i965/brw_meta_fast_clear.c | 54 
> > > +
> > >  src/mesa/drivers/dri/i965/gen8_surface_state.c  | 34 
> > >  src/mesa/drivers/dri/i965/intel_mipmap_tree.c   |  9 +
> > >  src/mesa/drivers/dri/i965/intel_mipmap_tree.h   |  7 +++-
> > >  4 files changed, 78 insertions(+), 26 deletions(-)


> > > diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c 
> > > b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> > > index b6e3520..32f0ff7 100644
> > > --- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> > > +++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> > > @@ -192,6 +192,12 @@ intel_tiling_supports_non_msrt_mcs(struct 
> > > brw_context *brw, unsigned tiling)
> > >   *
> > >   * - MCS buffer for non-MSRT is supported only for RT formats 32bpp,
> > >   *   64bpp, and 128bpp.
> > > + *
> > > + * From the Skylake documentation, it is made clear that X-tiling is no 
> > > longer
> > > + * supported:
> > > + *
> > > + * - MCS and Lossless compression is supported for 
> > > TiledY/TileYs/TileYf
> > > + * non-MSRTs only.
> > >   */
> > >  static bool
> > >  intel_miptree_supports_non_msrt_fast_clear(struct brw_context *brw,
> > > @@ -1485,6 +1491,9 @@ intel_miptree_alloc_non_msrt_mcs(struct brw_context 
> > > *brw,
> > > intel_get_non_msrt_mcs_alignment(mt, _width_px, _height);
> > > unsigned width_divisor = block_width_px * 4;
> > > unsigned height_divisor = block_height * 8;
> > 
> > > +   if (brw->gen >= 9)
> > > +  height_divisor /= 2;
> > > +
> > 
> > This hunk really needs a comment. Please explain why Skylake's MCS is
> > twice as tall as previous generations'.
> > 
> 
> To my knowledge we've yet to actually articulate in a comment what the MCS
> buffer's layout is (perhaps I just don't see it). Therefore I am uncertain 
> what
> comment I could provide here which isn't obvious from the code. I had a
> different path to finding this than you did which I believe gives me some bias
> (I just needed a reminder that divisor needs to be halved instead of doubled 
> to
> obtain twice the height).
> 
> If you suggest something, I will happily add it.

/* The Skylake MCS is twice as tall as the Broadwell MCS.
 *
 * In pre-Skylake, each bit in the MCS contained the state of 2 cachelines
 * in the main surface. In Skylake, it's two bits.  The extra bit
 * doubles the MCS height, not width, because in Skylake the MCS is always
 * Y-tiled.
 */

> 
> > > unsigned mcs_width =
> > >ALIGN(mt->logical_width0, width_divisor) / width_divisor;
> 

Re: [Mesa-dev] [PATCH 9/9] i965: Check accumulator restrictions.

[Matt Turner]

On Tue, Nov 3, 2015 at 11:53 PM, Kenneth Graunke  wrote:
> On Wednesday, October 21, 2015 03:58:17 PM Matt Turner wrote:
>> ---
>>  src/mesa/drivers/dri/i965/brw_eu_validate.c | 244 
>> 
>>  1 file changed, 244 insertions(+)
>>
>> diff --git a/src/mesa/drivers/dri/i965/brw_eu_validate.c 
>> b/src/mesa/drivers/dri/i965/brw_eu_validate.c
>> index eb57962..3d16f90 100644
>> --- a/src/mesa/drivers/dri/i965/brw_eu_validate.c
>> +++ b/src/mesa/drivers/dri/i965/brw_eu_validate.c
>> @@ -54,6 +54,16 @@ cat(struct string *dest, const struct string src)
>>}  \
>> } while(0)
>>
>> +#define CHECK(func) \
>> +   do { \
>> +  struct string __msg = func; \
>> +  if (__msg.str) { \
>> + cat(_msg, __msg); \
>> + free(__msg.str); \
>> + valid = false; \
>> +  } \
>> +   } while (0)
>> +
>>  static bool
>>  src0_is_null(const struct brw_device_info *devinfo, const brw_inst *inst)
>>  {
>> @@ -68,6 +78,42 @@ src1_is_null(const struct brw_device_info *devinfo, const 
>> brw_inst *inst)
>>brw_inst_src1_da_reg_nr(devinfo, inst) == BRW_ARF_NULL;
>>  }
>>
>> +static bool
>> +dst_is_accumulator(const struct brw_device_info *devinfo, const brw_inst 
>> *inst)
>> +{
>> +   return brw_inst_dst_reg_file(devinfo, inst) == 
>> BRW_ARCHITECTURE_REGISTER_FILE &&
>> +  brw_inst_dst_da_reg_nr(devinfo, inst) == BRW_ARF_ACCUMULATOR;
>> +}
>> +
>> +static bool
>> +src0_is_accumulator(const struct brw_device_info *devinfo, const brw_inst 
>> *inst)
>> +{
>> +   return brw_inst_src0_reg_file(devinfo, inst) == 
>> BRW_ARCHITECTURE_REGISTER_FILE &&
>> +  brw_inst_src0_da_reg_nr(devinfo, inst) == BRW_ARF_ACCUMULATOR;
>> +}
>> +
>> +static bool
>> +src1_is_accumulator(const struct brw_device_info *devinfo, const brw_inst 
>> *inst)
>> +{
>> +   return brw_inst_src1_reg_file(devinfo, inst) == 
>> BRW_ARCHITECTURE_REGISTER_FILE &&
>> +  brw_inst_src1_da_reg_nr(devinfo, inst) == BRW_ARF_ACCUMULATOR;
>> +}
>> +
>> +static bool
>> +is_integer(enum brw_reg_type type)
>> +{
>> +   return type == BRW_REGISTER_TYPE_UD ||
>> +  type == BRW_REGISTER_TYPE_D ||
>> +  type == BRW_REGISTER_TYPE_UW ||
>> +  type == BRW_REGISTER_TYPE_W ||
>> +  type == BRW_REGISTER_TYPE_UB ||
>> +  type == BRW_REGISTER_TYPE_B ||
>> +  type == BRW_REGISTER_TYPE_V ||
>> +  type == BRW_REGISTER_TYPE_UV ||
>> +  type == BRW_REGISTER_TYPE_UQ ||
>> +  type == BRW_REGISTER_TYPE_Q;
>> +}
>> +
>>  enum gen {
>> GEN4  = (1 << 0),
>> GEN45 = (1 << 1),
>> @@ -83,40 +129,66 @@ enum gen {
>>  #define GEN_GE(gen) (~((gen) - 1) | gen)
>>  #define GEN_LE(gen) (((gen) - 1) | gen)
>>
>> +enum acc {
>> +   ACC_NO_RESTRICTIONS = 0,
>> +   ACC_GEN_DEPENDENT = (1 << 0),
>> +   ACC_NO_EXPLICIT_SOURCE = (1 << 1),
>> +   ACC_NO_EXPLICIT_DESTINATION = (1 << 2),
>> +   ACC_NO_IMPLICIT_DESTINATION = (1 << 3),
>> +   ACC_NO_DESTINATION = ACC_NO_EXPLICIT_DESTINATION |
>> +ACC_NO_IMPLICIT_DESTINATION,
>> +   ACC_NO_ACCESS = ACC_NO_EXPLICIT_SOURCE |
>> +   ACC_NO_DESTINATION,
>> +   ACC_NO_SOURCE_MODIFIER = (1 << 4),
>> +   ACC_NO_INTEGER_SOURCE = (1 << 5),
>> +   ACC_IMPLICIT_WRITE_REQUIRED = (1 << 6),
>> +   ACC_NOT_BOTH_SOURCE_AND_DESTINATION = (1 << 7),
>> +};
>> +
>>  struct inst_info {
>> enum gen gen;
>> +   enum acc acc;
>>  };
>>
>>  static const struct inst_info inst_info[128] = {
>> [BRW_OPCODE_ILLEGAL] = {
>>.gen = GEN_ALL,
>> +  .acc = ACC_NO_ACCESS,
>> },
>> [BRW_OPCODE_MOV] = {
>>.gen = GEN_ALL,
>> +  .acc = ACC_NOT_BOTH_SOURCE_AND_DESTINATION,
>> },
>> [BRW_OPCODE_SEL] = {
>>.gen = GEN_ALL,
>> +  .acc = ACC_GEN_DEPENDENT,
>> },
>> [BRW_OPCODE_MOVI] = {
>>.gen = GEN_GE(GEN45),
>> +  .acc = ACC_NO_EXPLICIT_SOURCE,
>> },
>> [BRW_OPCODE_NOT] = {
>>.gen = GEN_ALL,
>> +  .acc = ACC_NO_SOURCE_MODIFIER,
>> },
>> [BRW_OPCODE_AND] = {
>>.gen = GEN_ALL,
>> +  .acc = ACC_NO_SOURCE_MODIFIER,
>> },
>> [BRW_OPCODE_OR] = {
>>.gen = GEN_ALL,
>> +  .acc = ACC_NO_SOURCE_MODIFIER,
>> },
>> [BRW_OPCODE_XOR] = {
>>.gen = GEN_ALL,
>> +  .acc = ACC_NO_SOURCE_MODIFIER,
>> },
>> [BRW_OPCODE_SHR] = {
>>.gen = GEN_ALL,
>> },
>> [BRW_OPCODE_SHL] = {
>>.gen = GEN_ALL,
>> +  .acc = ACC_NO_DESTINATION,
>> },
>> /* BRW_OPCODE_DIM / BRW_OPCODE_SMOV */
>> /* Reserved - 11 */
>> @@ -126,63 +198,81 @@ static const struct inst_info inst_info[128] = {
>> /* Reserved - 13-15 */
>> [BRW_OPCODE_CMP] = {
>>.gen = GEN_ALL,
>> +  .acc = ACC_GEN_DEPENDENT,
>> },
>> [BRW_OPCODE_CMPN] = {
>>.gen = GEN_ALL,
>> +  .acc = ACC_GEN_DEPENDENT,
>> },
>> [BRW_OPCODE_CSEL] = {
>>.gen = GEN_GE(GEN8),
>> },
>> 

Re: [Mesa-dev] [PATCH 0/3] gallium: add ARB_clear_texture infrastructure

[Ilia Mirkin]

On Mon, Nov 9, 2015 at 3:07 PM, Roland Scheidegger  wrote:
> Am 09.11.2015 um 19:40 schrieb Ilia Mirkin:
>> This is basically a resend of a series I wrote over a year ago. I
>> don't remember what we hated about it last time, but I'm tempted not
>> to look. This seems pretty reasonably to me now.
> I guess I wasn't entirely happy with yet another clear method... Still,
> looks reasonable...

Yeah, I'm not madly in love with it either, but the various
functionality just isn't accessible otherwise. Internally the nvc0 and
nv50 impls reuse the clear_render_target/clear_depth_stencil
functions, but that's not generically possible since we have to be
able to clear non-renderable formats.

I guess an alternative here is to say that we can redefine the format
of a surface to basically what I do in the nvc0 patch, I can move that
logic from nvc0 to st/mesa.

I can redo it if that assumption is OK with everyone (potentially
conditioned on PIPE_CAP_SAMPLER_VIEW_TARGET aka ARB_texture_view...)

>
>>
>> A refactoring opportunity exists to remove ->clear_render_target and
>> ->clear_depth_stencil, but... that can be done later.
> You could remove clear_render_target but not clear_depth_stencil, as the
> latter allows clearing only depth or stencil.
>
> Roland
>
>
>>
>> Note that for nvc0 I still have to keep separate paths for
>> color/stencil, which is a bit unfortunate, but the hardware complains
>> otherwise.
>>
>> Ilia Mirkin (3):
>>   gallium: add PIPE_CAP_CLEAR_TEXTURE and clear_texture prototype
>>   st/mesa: implement ARB_clear_texture
>>   nvc0: add ARB_clear_texture support
>>
>>  docs/GL3.txt |  2 +-
>>  docs/relnotes/11.1.0.html|  1 +
>>  src/gallium/docs/source/context.rst  |  4 ++
>>  src/gallium/docs/source/screen.rst   |  2 +
>>  src/gallium/drivers/freedreno/freedreno_screen.c |  1 +
>>  src/gallium/drivers/i915/i915_screen.c   |  1 +
>>  src/gallium/drivers/ilo/ilo_screen.c |  1 +
>>  src/gallium/drivers/llvmpipe/lp_screen.c |  1 +
>>  src/gallium/drivers/nouveau/nv30/nv30_screen.c   |  1 +
>>  src/gallium/drivers/nouveau/nv50/nv50_screen.c   |  1 +
>>  src/gallium/drivers/nouveau/nvc0/nvc0_screen.c   |  1 +
>>  src/gallium/drivers/nouveau/nvc0/nvc0_surface.c  | 82 
>> 
>>  src/gallium/drivers/r300/r300_screen.c   |  1 +
>>  src/gallium/drivers/r600/r600_pipe.c |  1 +
>>  src/gallium/drivers/radeonsi/si_pipe.c   |  1 +
>>  src/gallium/drivers/softpipe/sp_screen.c |  1 +
>>  src/gallium/drivers/svga/svga_screen.c   |  1 +
>>  src/gallium/drivers/vc4/vc4_screen.c |  1 +
>>  src/gallium/drivers/virgl/virgl_screen.c |  1 +
>>  src/gallium/include/pipe/p_context.h | 10 +++
>>  src/gallium/include/pipe/p_defines.h |  1 +
>>  src/mesa/state_tracker/st_cb_texture.c   | 29 +
>>  src/mesa/state_tracker/st_extensions.c   |  1 +
>>  23 files changed, 145 insertions(+), 1 deletion(-)
>>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 0/7] i965: Use native formats in fs_surface_builder

[Chad Versace]

On Wed 04 Nov 2015, Jason Ekstrand wrote:
> This little patch series converts fs_surface_builder to use native formats
> for doing all of its image_load_store workaround tricks.  If you're willing
> to take as an axiom that we want to not link the backend compiler against
> core mesa, this leaves us with three options:
> 
>  1) Pull mesa_format.h and friends into util
>  2) Use GL enums in fs_surface_builder
>  3) Use native formats in fs_surface_builder
> 
> The first option is a lot of code-shuffling and it's not clear how much
> benifit it would have.  We may want to do it eventually so that gallium and
> core mesa can share format conversion code, but I don't want to go down
> that rabbit-trail right now.
> 
> At first glance, the second and third options look approximately
> equivalent.  However, we don't really want to use GL enums in
> brw_lower_image_format because it's shared by the compiler and the state
> setup code and using GL enums in state setup is kind of gross.  With that
> in mind, I settled on native formats.

I agree. Option 3 is the obvious winner. Use hardware-native formats.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] soft/llvmpipe front buffer access and piglit regressions

[Brian Paul]

On 11/09/2015 01:15 PM, Dave Airlie wrote:

On 10 November 2015 at 00:30, Roland Scheidegger  wrote:

Am 09.11.2015 um 04:44 schrieb Dave Airlie:

So it appears my patch to enable front buffer access on soft/llvmpipe
causes some piglit regressions. However these are due to piglit having
undefined behaviour where it doesn't create a window but has tests
requiring a front buffer. The new code does an XGetImage on the front
buffer and when it fails all sorts of bad things tend to happen. I
don't think there is a way to check if we have a window mapped inside
Mesa to avoid this path.

swrast suffers from the same failure pattern in a number of tests when
run with -auto.

I'm not sure what to do here, the patch is making the driver
conformant and is fixing a missing
feature being used by OpenGL apps (gtk).

I can probably make it fail more gracefully (llvmpipe deadlocks on the
Xlib error path inside it's rasteriser threads), but I'm not sure I
want to go back to the old behaviour just to satisfy piglit's
requirement to do undefined things.



I don't really understand all this interface stuff, however it feels
wrong to me that we have to care in the driver for something which you
say is totally bogus. Couldn't that be handled outside? Albeit I don't
really understand what exactly happens in the first place.


Well the bug is piglit runs tests without mapping the window. On DRI2
this works as we have the fake front buffer, so reading the front doesn't
require content on the screen. However it's really undefined behaviour for GL.

Now with drisw you use GetImage/PutImage to get things from the real front
buffer. However if the window is never mapped, these will return BadMatch,
and things fall over. However we have real apps wanting proper front buffer
interactions, and we have piglit wanting the undefined behaviour.


The old xlib/swrast code has an X error handler to catch failing 
XGetImage calls.  We probably need something like that.  See 
xm_buffer.c's xmesa_MapRenderbuffer().


It also sounds like the piglit tests in question need to be fixed somehow.

-Brian




I think I'll decide in favour of the former, but it might be a bit of a shock to
people who run piglit runs and things start regressing.

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



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

Re: [Mesa-dev] [PATCH 04/10] i965/skl: skip fast clears for certain surface formats

[Chad Versace]

On Tue 03 Nov 2015, Ben Widawsky wrote:
> On Fri, Oct 16, 2015 at 04:05:22PM -0700, Chad Versace wrote:
> > On Tue 13 Oct 2015, Ben Widawsky wrote:
> > > Initially I had this planned as a patch to be squashed in to the enabling 
> > > patch
> > > because there is no point enabling fast clears without this. However, Chad
> > > merged a patch which disables fast clears on gen9 explicitly, and so I 
> > > can hide
> > > this behind the revert of that patch. This is a nice I really wanted this 
> > > patch
> > > as a distinct patch for review. This is a new, weird, and poorly 
> > > documented
> > > restriction for SKL. (In fact, I am still not 100% certain the 
> > > restriction is
> > > entirely necessary, but there are around 30 piglit regressions without 
> > > this).
> > > 
> > > SKL adds compressible render targets and as a result mutates some of the
> > > programming for fast clears and resolves. There is a new internal surface 
> > > type
> > > called the CCS. The old AUX_MCS bit becomes AUX_CCS_D. "The Auxiliary 
> > > surface is
> > > a CCS (Color Control Surface) with compression disabled or an MCS with
> > > compression enabled, depending on number of multisamples. MCS (Multisample
> > > Control Surface) is a special type of CCS."
> > > 
> > > Signed-off-by: Ben Widawsky 
> > > ---
> > >  src/mesa/drivers/dri/i965/brw_context.h |  1 +
> > >  src/mesa/drivers/dri/i965/brw_surface_formats.c | 27 
> > > +
> > >  src/mesa/drivers/dri/i965/gen8_surface_state.c  |  8 ++--
> > >  src/mesa/drivers/dri/i965/intel_mipmap_tree.c   |  3 +++
> > >  4 files changed, 37 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/src/mesa/drivers/dri/i965/brw_context.h 
> > > b/src/mesa/drivers/dri/i965/brw_context.h
> > > index e59478a..32b8250 100644
> > > --- a/src/mesa/drivers/dri/i965/brw_context.h
> > > +++ b/src/mesa/drivers/dri/i965/brw_context.h
> > > @@ -1546,6 +1546,7 @@ struct brw_context
> > >  
> > > uint32_t render_target_format[MESA_FORMAT_COUNT];
> > > bool format_supported_as_render_target[MESA_FORMAT_COUNT];
> > > +   bool losslessly_compressable[MESA_FORMAT_COUNT];
> > 
> > I agree with Neil. It's a shame to increase the context size for static
> > information. And there is already a static array in
> > brw_surface_formats.c for exactly this type of information.
> 
> As I said in the mail with Neil, the formats aren't static and change per 
> GEN. I
> could do the base formats which are shared by all Gens, but I think you still
> end up needing something like this. Or did I misunderstand what is being asked
> of me?

One of us misunderstood each other, but I don't know who.

The table in brw_surface_formats.c does contain per-gen information. The
table lists, for each surface format and surface format capability, the
first gen that supports the capability.

So, you can avoid fattening brw_context by adding a new column in the
brw_surface_formats table for losslessly_compressable, then setting each
item in the column to either X (no gen supports the capability) or 90
(Skylake).

Is there some reason why this wouldn't work?

> 
> > >  
> > > /* Interpolation modes, one byte per vue slot.
> > >  * Used Gen4/5 by the clip|sf|wm stages. Ignored on Gen6+.
> > > diff --git a/src/mesa/drivers/dri/i965/brw_surface_formats.c 
> > > b/src/mesa/drivers/dri/i965/brw_surface_formats.c
> > > index 97fff60..d706ecc 100644
> > > --- a/src/mesa/drivers/dri/i965/brw_surface_formats.c
> > > +++ b/src/mesa/drivers/dri/i965/brw_surface_formats.c
> > > @@ -693,6 +693,33 @@ brw_init_surface_formats(struct brw_context *brw)
> > >}
> > > }
> > >  
> > > +   if (brw->gen >= 9) {
> > > +  brw->losslessly_compressable[MESA_FORMAT_RGBA_FLOAT32] = true;
> > > +  brw->losslessly_compressable[MESA_FORMAT_RGBA_SINT32] = true;
> > > +  brw->losslessly_compressable[MESA_FORMAT_RGBA_UINT32] = true;
> > > +  brw->losslessly_compressable[MESA_FORMAT_RGBA_UNORM16] = true;
> > > +  brw->losslessly_compressable[MESA_FORMAT_RGBA_SNORM16] = true;
> > > +  brw->losslessly_compressable[MESA_FORMAT_RGBA_SINT16] = true;
> > > +  brw->losslessly_compressable[MESA_FORMAT_RGBA_UINT16] = true;
> > > +  brw->losslessly_compressable[MESA_FORMAT_RGBA_FLOAT16] = true;
> > > +  brw->losslessly_compressable[MESA_FORMAT_RG_FLOAT32] = true;
> > > +  brw->losslessly_compressable[MESA_FORMAT_RG_SINT32] = true;
> > > +  brw->losslessly_compressable[MESA_FORMAT_RG_UINT32] = true;
> > > +  brw->losslessly_compressable[MESA_FORMAT_RGBX_FLOAT16] = true;
> > > +  brw->losslessly_compressable[MESA_FORMAT_B8G8R8A8_UNORM] = true;
> > > +  brw->losslessly_compressable[MESA_FORMAT_R8G8B8A8_UNORM] = true;
> > > +  brw->losslessly_compressable[MESA_FORMAT_R8G8B8A8_SNORM] = true;
> > > +  brw->losslessly_compressable[MESA_FORMAT_RGBA_SINT8] = true;
> > > +  brw->losslessly_compressable[MESA_FORMAT_RGBA_UINT8] = true;
> > > 

Re: [Mesa-dev] [PATCH] i965/skl/gt4: Fix URB programming restriction.

[Kenneth Graunke]

On Saturday, November 07, 2015 08:40:51 AM Ben Widawsky wrote:
> On Fri, Nov 06, 2015 at 07:29:18PM -0800, Kenneth Graunke wrote:
> > On Friday, November 06, 2015 06:12:27 PM Ben Widawsky wrote:
> > > The comment in the code details the restriction. Thanks to Ken for having 
> > > a very
> > > helpful conversation with me, and spotting the blurb in the link I sent 
> > > him :P.
> > > 
> > > There are still stability problems for me on GT4, but this definitely 
> > > helps with
> > > some of the failures.
> > > 
> > > Cc: Kenneth Graunke 
> > > Cc: Jordan Justen 
> > > Cc: mesa-sta...@lists.freedesktop.org (if the original gt4 patch goes to 
> > > stable)
> > > ---
> > > 
> > > Sarah, you should check this on KBL.
> > > Cc: Sarah Sharp 
> > > ---
> > >  src/mesa/drivers/dri/i965/brw_device_info.c | 8 
> > >  1 file changed, 8 insertions(+)
> > > 
> > > diff --git a/src/mesa/drivers/dri/i965/brw_device_info.c 
> > > b/src/mesa/drivers/dri/i965/brw_device_info.c
> > > index 2ebc084..6117fd3 100644
> > > --- a/src/mesa/drivers/dri/i965/brw_device_info.c
> > > +++ b/src/mesa/drivers/dri/i965/brw_device_info.c
> > > @@ -337,6 +337,14 @@ static const struct brw_device_info 
> > > brw_device_info_skl_gt3 = {
> > >  
> > >  static const struct brw_device_info brw_device_info_skl_gt4 = {
> > > GEN9_FEATURES, .gt = 4,
> > > +   /* From the docs:
> > > +*   URB is limited to 1008KB due to programming restrictions. This 
> > > is not a
> > > +*   restriction of the L3 implementation, but of the FF and other 
> > > clients.
> > > +*   Therefore, in a GT4 implementation it is possible for the 
> > > programmed
> > > +*   allocation of the L3 data array to provide 3*384KB=1152MB [sic] 
> > > for URB,
> > > +*   but only 1008KB of this will be used.
> > > +*/
> > 
> > We should at least say which page/section this comes from (the section
> > name exists in the Broadwell PRM, so it's not particularly secret).
> > 
> > Please put the text in quotes too.  My suggested formatting:
> > 
> >/* From the "L3 Allocation and Programming" documentation:
> > *
> > * "URB is limited to 1008KB due to programming restrictions.  This
> > *  is not a restriction of the L3 implementation, but of the FF and
> > *  other clients.  Therefore, in a GT4 implementation it is
> > *  possible for the programmed allocation of the L3 data array to
> > *  provide 3*384KB=1152MB [sic] for URB, but only 1008KB of this
> > *  will be used."
> > */
> > 
> > Regardless,
> > Reviewed-by: Kenneth Graunke 
> > 
> 
> Thanks! I had no idea it was in the BDW PRMs.

You can change "1152MB [sic]" to "1152KB" as they've fixed the docs :)

--Ken


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

Re: [Mesa-dev] [PATCH 3/3] nvc0: add ARB_clear_texture support

[Ilia Mirkin]

On Mon, Nov 9, 2015 at 3:13 PM, Samuel Pitoiset
 wrote:
>
>
> On 11/09/2015 09:03 PM, Ilia Mirkin wrote:
>>
>> On Mon, Nov 9, 2015 at 2:58 PM, Samuel Pitoiset
>>  wrote:
>>>
>>>
>>>
>>> On 11/09/2015 07:40 PM, Ilia Mirkin wrote:


 Signed-off-by: Ilia Mirkin 
 ---
docs/GL3.txt|  2 +-
docs/relnotes/11.1.0.html   |  1 +
src/gallium/drivers/nouveau/nvc0/nvc0_screen.c  |  2 +-
src/gallium/drivers/nouveau/nvc0/nvc0_surface.c | 82
 +
4 files changed, 85 insertions(+), 2 deletions(-)

 diff --git a/docs/GL3.txt b/docs/GL3.txt
 index 7abdcd8..da0ffca 100644
 --- a/docs/GL3.txt
 +++ b/docs/GL3.txt
 @@ -177,7 +177,7 @@ GL 4.4, GLSL 4.40:

  GL_MAX_VERTEX_ATTRIB_STRIDE  DONE (all
 drivers)
  GL_ARB_buffer_storageDONE (i965,
 nv50,
 nvc0, r600, radeonsi)
 -  GL_ARB_clear_texture DONE (i965)
 (gallium - in progress, VMware)
 +  GL_ARB_clear_texture DONE (i965,
 nvc0)
  GL_ARB_enhanced_layouts  in progress
 (Timothy)
  - compile-time constant expressions  in progress
  - explicit byte offsets for blocks   in progress
 diff --git a/docs/relnotes/11.1.0.html b/docs/relnotes/11.1.0.html
 index 11fbdff..33fd0b8 100644
 --- a/docs/relnotes/11.1.0.html
 +++ b/docs/relnotes/11.1.0.html
 @@ -46,6 +46,7 @@ Note: some of the new features are only available with
 certain drivers.

GL_ARB_arrays_of_arrays on i965
GL_ARB_blend_func_extended on freedreno (a3xx)
 +GL_ARB_clear_texture on nvc0
GL_ARB_copy_image on nv50, nvc0, radeonsi
GL_ARB_gpu_shader_fp64 on r600 for Cypress/Cayman/Aruba
 chips
GL_ARB_gpu_shader5 on r600 for Evergreen and later chips
 diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
 b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
 index f2e3bf0..fbeec7f 100644
 --- a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
 +++ b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
 @@ -182,6 +182,7 @@ nvc0_screen_get_param(struct pipe_screen *pscreen,
 enum pipe_cap param)
   case PIPE_CAP_COPY_BETWEEN_COMPRESSED_AND_PLAIN_FORMATS:
   case PIPE_CAP_FORCE_PERSAMPLE_INTERP:
   case PIPE_CAP_SHAREABLE_SHADERS:
 +   case PIPE_CAP_CLEAR_TEXTURE:
  return 1;
   case PIPE_CAP_SEAMLESS_CUBE_MAP_PER_TEXTURE:
  return (class_3d >= NVE4_3D_CLASS) ? 1 : 0;
 @@ -204,7 +205,6 @@ nvc0_screen_get_param(struct pipe_screen *pscreen,
 enum pipe_cap param)
   case PIPE_CAP_VERTEXID_NOBASE:
   case PIPE_CAP_RESOURCE_FROM_USER_MEMORY:
   case PIPE_CAP_DEVICE_RESET_STATUS_QUERY:
 -   case PIPE_CAP_CLEAR_TEXTURE:
  return 0;

   case PIPE_CAP_VENDOR_ID:
 diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_surface.c
 b/src/gallium/drivers/nouveau/nvc0/nvc0_surface.c
 index 5f47bad..3ae9943 100644
 --- a/src/gallium/drivers/nouveau/nvc0/nvc0_surface.c
 +++ b/src/gallium/drivers/nouveau/nvc0/nvc0_surface.c
 @@ -319,6 +319,8 @@ nvc0_clear_render_target(struct pipe_context *pipe,
  PUSH_DATA(push, dst->u.tex.first_layer + sf->depth);
  PUSH_DATA(push, mt->layer_stride >> 2);
  PUSH_DATA(push, dst->u.tex.first_layer);
 +
 +  IMMED_NVC0(push, NVC0_3D(MULTISAMPLE_MODE), mt->ms_mode);
   } else {
  if (res->base.target == PIPE_BUFFER) {
 PUSH_DATA(push, 262144);
 @@ -540,6 +542,7 @@ nvc0_clear_depth_stencil(struct pipe_context *pipe,
   PUSH_DATA (push, (unk << 16) | (dst->u.tex.first_layer +
 sf->depth));
   BEGIN_NVC0(push, NVC0_3D(ZETA_BASE_LAYER), 1);
   PUSH_DATA (push, dst->u.tex.first_layer);
 +   IMMED_NVC0(push, NVC0_3D(MULTISAMPLE_MODE), mt->ms_mode);

   BEGIN_NIC0(push, NVC0_3D(CLEAR_BUFFERS), sf->depth);
   for (z = 0; z < sf->depth; ++z) {
 @@ -550,6 +553,84 @@ nvc0_clear_depth_stencil(struct pipe_context *pipe,
   nvc0->dirty |= NVC0_NEW_FRAMEBUFFER;
}

 +static void
 +nvc0_clear_texture(struct pipe_context *pipe,
 +   struct pipe_resource *res,
 +   unsigned level,
 +   const struct pipe_box *box,
 +   const void *data)
 +{
 +   struct nv50_miptree *mt = nv50_miptree(res);
 +   struct nv50_surface sf = {{{0}}};
>>>
>>>
>>>
>>> I'm just curious about this, does '= {}' is not enough?
>>
>>
>> I wanted to be *really* sure it got initialized... 

Re: [Mesa-dev] [PATCH 3/7] i965: Add an image format metadata array

[Chad Versace]

On Wed 04 Nov 2015, Jason Ekstrand wrote:
> This little data structure and associated array contains all of the image
> format metadata needed for doing image_load_store work-arounds.  This way
> we can pull metadata from within the i965 driver without having to go out
> to core mesa for it.  It is a bit of duplication with what we have in core
> mesa but it's limited enough that it's easily verified and not a big deal.
> ---
>  src/mesa/drivers/dri/i965/brw_image_load_store.c | 45 
> 
>  src/mesa/drivers/dri/i965/brw_image_load_store.h | 20 +++
>  2 files changed, 65 insertions(+)
> 
> diff --git a/src/mesa/drivers/dri/i965/brw_image_load_store.c 
> b/src/mesa/drivers/dri/i965/brw_image_load_store.c
> index 4876041..b78d6b2 100644
> --- a/src/mesa/drivers/dri/i965/brw_image_load_store.c
> +++ b/src/mesa/drivers/dri/i965/brw_image_load_store.c
> @@ -26,6 +26,51 @@
>  #include "brw_defines.h"
>  #include "brw_image_load_store.h"
>  
> +#define IF(r, g, b, a, dt, f) \
> +   [BRW_SURFACEFORMAT_##f] = { true, r, g, b, a, BRW_IMAGE_FORMAT_##dt },
> +const struct brw_image_format_info brw_image_format_info[] = {
> +   IF( 8,  0,  0,  0, UNORM, R8_UNORM)
> +   IF( 8,  0,  0,  0, SNORM, R8_SNORM)
> +   IF( 8,  0,  0,  0,  UINT, R8_UINT)
> +   IF( 8,  0,  0,  0,  SINT, R8_SINT)
> +   IF( 8,  8,  0,  0, UNORM, R8G8_UNORM)

Reviewed-by: Chad Versace 

One small nit... Place the table's key in the rightmost column looks
very wrong to me. My eyes strongly desire the key in the leftmost
column.

Anyway, leftmost or rightmost, my rb still stands.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 0/3] gallium: add ARB_clear_texture infrastructure

[Roland Scheidegger]

Am 09.11.2015 um 21:12 schrieb Ilia Mirkin:
> On Mon, Nov 9, 2015 at 3:07 PM, Roland Scheidegger  wrote:
>> Am 09.11.2015 um 19:40 schrieb Ilia Mirkin:
>>> This is basically a resend of a series I wrote over a year ago. I
>>> don't remember what we hated about it last time, but I'm tempted not
>>> to look. This seems pretty reasonably to me now.
>> I guess I wasn't entirely happy with yet another clear method... Still,
>> looks reasonable...
> 
> Yeah, I'm not madly in love with it either, but the various
> functionality just isn't accessible otherwise. Internally the nvc0 and
> nv50 impls reuse the clear_render_target/clear_depth_stencil
> functions, but that's not generically possible since we have to be
> able to clear non-renderable formats.
> 
> I guess an alternative here is to say that we can redefine the format
> of a surface to basically what I do in the nvc0 patch, I can move that
> logic from nvc0 to st/mesa.
I think if you don't have the rt, there's really not much point to
redefine the surface format for clearing.

Roland


> 
> I can redo it if that assumption is OK with everyone (potentially
> conditioned on PIPE_CAP_SAMPLER_VIEW_TARGET aka ARB_texture_view...)
> 
>>
>>>
>>> A refactoring opportunity exists to remove ->clear_render_target and
>>> ->clear_depth_stencil, but... that can be done later.
>> You could remove clear_render_target but not clear_depth_stencil, as the
>> latter allows clearing only depth or stencil.
>>
>> Roland
>>
>>
>>>
>>> Note that for nvc0 I still have to keep separate paths for
>>> color/stencil, which is a bit unfortunate, but the hardware complains
>>> otherwise.
>>>
>>> Ilia Mirkin (3):
>>>   gallium: add PIPE_CAP_CLEAR_TEXTURE and clear_texture prototype
>>>   st/mesa: implement ARB_clear_texture
>>>   nvc0: add ARB_clear_texture support
>>>
>>>  docs/GL3.txt |  2 +-
>>>  docs/relnotes/11.1.0.html|  1 +
>>>  src/gallium/docs/source/context.rst  |  4 ++
>>>  src/gallium/docs/source/screen.rst   |  2 +
>>>  src/gallium/drivers/freedreno/freedreno_screen.c |  1 +
>>>  src/gallium/drivers/i915/i915_screen.c   |  1 +
>>>  src/gallium/drivers/ilo/ilo_screen.c |  1 +
>>>  src/gallium/drivers/llvmpipe/lp_screen.c |  1 +
>>>  src/gallium/drivers/nouveau/nv30/nv30_screen.c   |  1 +
>>>  src/gallium/drivers/nouveau/nv50/nv50_screen.c   |  1 +
>>>  src/gallium/drivers/nouveau/nvc0/nvc0_screen.c   |  1 +
>>>  src/gallium/drivers/nouveau/nvc0/nvc0_surface.c  | 82 
>>> 
>>>  src/gallium/drivers/r300/r300_screen.c   |  1 +
>>>  src/gallium/drivers/r600/r600_pipe.c |  1 +
>>>  src/gallium/drivers/radeonsi/si_pipe.c   |  1 +
>>>  src/gallium/drivers/softpipe/sp_screen.c |  1 +
>>>  src/gallium/drivers/svga/svga_screen.c   |  1 +
>>>  src/gallium/drivers/vc4/vc4_screen.c |  1 +
>>>  src/gallium/drivers/virgl/virgl_screen.c |  1 +
>>>  src/gallium/include/pipe/p_context.h | 10 +++
>>>  src/gallium/include/pipe/p_defines.h |  1 +
>>>  src/mesa/state_tracker/st_cb_texture.c   | 29 +
>>>  src/mesa/state_tracker/st_extensions.c   |  1 +
>>>  23 files changed, 145 insertions(+), 1 deletion(-)
>>>
>>

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

[Mesa-dev] [PATCH] i965: Print force_writemask_all in dump_instructions().

[Kenneth Graunke]

Signed-off-by: Kenneth Graunke 
---
 src/mesa/drivers/dri/i965/brw_fs.cpp   | 3 +++
 src/mesa/drivers/dri/i965/brw_vec4.cpp | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp 
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index b2b7762..8185355 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -4774,6 +4774,9 @@ fs_visitor::dump_instruction(backend_instruction 
*be_inst, FILE *file)
 
fprintf(file, " ");
 
+   if (inst->force_writemask_all)
+  fprintf(file, "NoMask ");
+
if (dispatch_width == 16 && inst->exec_size == 8) {
   if (inst->force_sechalf)
  fprintf(file, "2ndhalf ");
diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp 
b/src/mesa/drivers/dri/i965/brw_vec4.cpp
index e52114a..4e6fd2f 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4.cpp
@@ -1589,6 +1589,9 @@ vec4_visitor::dump_instruction(backend_instruction 
*be_inst, FILE *file)
  fprintf(file, ", ");
}
 
+   if (inst->force_writemask_all)
+  fprintf(file, " NoMask ");
+
fprintf(file, "\n");
 }
 
-- 
2.6.2

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

[Mesa-dev] [Bug 91888] EGL Wayland software rendering no longer work after regression

[bugzilla-daemon]

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

--- Comment #5 from Giulio Camuffo  ---
(In reply to Daniel Stone from comment #2)
> I think that commit is a a red herring. 0x3098 is
> EGL_CONTEXT_CLIENT_VERSION, and Mesa has recently gained more strictness:
>  if ((api != EGL_OPENGL_ES_API &&
>  (!dpy->Extensions.KHR_create_context || api !=
> EGL_OPENGL_API))) {
>err = EGL_BAD_ATTRIBUTE;
>break;
>  }
> 
> I suspect QWaylandGLContext is missing eglBindAPI(EGL_OPENGL_ES_API) before
> context creation.

Nope, it does call it:
http://code.qt.io/cgit/qt/qtwayland.git/tree/src/hardwareintegration/client/wayland-egl/qwaylandglcontext.cpp#n278

I also noticed that i can reproduce this with LIBGL_ALWAYS_SOFTWARE=1, but not
when running on i965.

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

[Mesa-dev] [PATCH 1/8] r600: geometry shader gsvs itemsize workaround

[Dave Airlie]

From: Dave Airlie 

On some chips the GSVS itemsize needs to be aligned to a cacheline size.

This only applies to some of the r600 family chips.

Signed-off-by: Dave Airlie 
---
 src/gallium/drivers/r600/r600_state.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/src/gallium/drivers/r600/r600_state.c 
b/src/gallium/drivers/r600/r600_state.c
index 1be3e1b..a803603 100644
--- a/src/gallium/drivers/r600/r600_state.c
+++ b/src/gallium/drivers/r600/r600_state.c
@@ -2660,6 +2660,9 @@ void r600_update_vs_state(struct pipe_context *ctx, 
struct r600_pipe_shader *sha
S_02881C_USE_VTX_VIEWPORT_INDX(rshader->vs_out_viewport);
 }
 
+#define RV610_GSVS_ALIGN 32
+#define R600_GSVS_ALIGN 16
+
 void r600_update_gs_state(struct pipe_context *ctx, struct r600_pipe_shader 
*shader)
 {
struct r600_context *rctx = (struct r600_context *)ctx;
@@ -2669,6 +2672,23 @@ void r600_update_gs_state(struct pipe_context *ctx, 
struct r600_pipe_shader *sha
unsigned gsvs_itemsize =
(cp_shader->ring_item_sizes[0] * 
shader->selector->gs_max_out_vertices) >> 2;
 
+   /* some r600s needs gsvs itemsize aligned to cacheline size
+  this was fixed in rs780 and above. */
+   switch (rctx->b.family) {
+   case CHIP_RV610:
+   gsvs_itemsize = align(gsvs_itemsize, RV610_GSVS_ALIGN);
+   break;
+   case CHIP_R600:
+   case CHIP_RV630:
+   case CHIP_RV670:
+   case CHIP_RV620:
+   case CHIP_RV635:
+   gsvs_itemsize = align(gsvs_itemsize, R600_GSVS_ALIGN);
+   break;
+   default:
+   break;
+   }
+
r600_init_command_buffer(cb, 64);
 
/* VGT_GS_MODE is written by r600_emit_shader_stages */
-- 
2.1.0

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

[Mesa-dev] r600 geometry shader workarounds

[Dave Airlie]

I've had these sitting locally and heiko on #dri-devel found
they fixed some issues for him.

Marek provided me with some errata and this is the results of
implementing them.

It is nearly all fixes for r600 era hw.

Dave.

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

[Mesa-dev] [PATCH 6/8] r600: SMX returns CONTEXT_DONE early workaround

[Dave Airlie]

From: Dave Airlie 

streamout, gs rings bug on certain r600s, requires a wait idle
before each surface sync.

Signed-off-by: Dave Airlie 
---
 src/gallium/drivers/r600/r600_hw_context.c   |  4 
 src/gallium/drivers/r600/r600_pipe.h |  1 +
 src/gallium/drivers/r600/r600_state_common.c | 11 +++
 3 files changed, 16 insertions(+)

diff --git a/src/gallium/drivers/r600/r600_hw_context.c 
b/src/gallium/drivers/r600/r600_hw_context.c
index 2a181dc..a28d43e 100644
--- a/src/gallium/drivers/r600/r600_hw_context.c
+++ b/src/gallium/drivers/r600/r600_hw_context.c
@@ -227,6 +227,10 @@ void r600_flush_emit(struct r600_context *rctx)
  S_0085F0_DEST_BASE_0_ENA(1);
}
 
+   /* Workaround for SMX flushing issue on some R6xx. */
+   if (rctx->b.flags & (R600_CONTEXT_SMX_CONTEXT_DONE_FLUSH))
+   radeon_set_config_reg(cs, R_008040_WAIT_UNTIL, 
S_008040_WAIT_3D_IDLE(1));
+
if (cp_coher_cntl) {
cs->buf[cs->cdw++] = PKT3(PKT3_SURFACE_SYNC, 3, 0);
cs->buf[cs->cdw++] = cp_coher_cntl;   /* CP_COHER_CNTL */
diff --git a/src/gallium/drivers/r600/r600_pipe.h 
b/src/gallium/drivers/r600/r600_pipe.h
index 5a4ad9e..bbc0e68 100644
--- a/src/gallium/drivers/r600/r600_pipe.h
+++ b/src/gallium/drivers/r600/r600_pipe.h
@@ -57,6 +57,7 @@
 #define R600_CONTEXT_WAIT_3D_IDLE  (R600_CONTEXT_PRIVATE_FLAG << 9)
 #define R600_CONTEXT_WAIT_CP_DMA_IDLE  (R600_CONTEXT_PRIVATE_FLAG << 
10)
 #define R600_CONTEXT_GS_EXTRA_FLUSH(R600_CONTEXT_PRIVATE_FLAG << 
11)
+#define R600_CONTEXT_SMX_CONTEXT_DONE_FLUSH(R600_CONTEXT_PRIVATE_FLAG << 
12)
 
 /* the number of CS dwords for flushing and drawing */
 #define R600_MAX_FLUSH_CS_DWORDS   16
diff --git a/src/gallium/drivers/r600/r600_state_common.c 
b/src/gallium/drivers/r600/r600_state_common.c
index 7d0c98f..bc7adba 100644
--- a/src/gallium/drivers/r600/r600_state_common.c
+++ b/src/gallium/drivers/r600/r600_state_common.c
@@ -1584,6 +1584,17 @@ static void r600_draw_vbo(struct pipe_context *ctx, 
const struct pipe_draw_info
r600_mark_atom_dirty(rctx, >cb_misc_state.atom);
}
 
+   /* SMX returns CONTEXT_DONE too early workaround */
+   if (rctx->b.family == CHIP_R600 ||
+   rctx->b.family == CHIP_RV610 ||
+   rctx->b.family == CHIP_RV630 ||
+   rctx->b.family == CHIP_RV635) {
+   /* if we have gs shader or streamout
+  we need to do a wait idle after every draw */
+   if (rctx->gs_shader || rctx->b.streamout.streamout_enabled)
+   rctx->b.flags |= R600_CONTEXT_SMX_CONTEXT_DONE_FLUSH;
+   }
+
/* ES ring rolling over at EOP */
if (rctx->b.chip_class == R600) {
/* GS scenario G - emit event initiator SQ_NON_EVENT */
-- 
2.1.0

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

[Mesa-dev] [PATCH 2/8] r600: rv670 use at least 16es/gs threads

[Dave Airlie]

From: Dave Airlie 

This is specified in the docs for rv670 to work properly.

Signed-off-by: Dave Airlie 
---
 src/gallium/drivers/r600/r600_state.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/src/gallium/drivers/r600/r600_state.c 
b/src/gallium/drivers/r600/r600_state.c
index a803603..541cf93 100644
--- a/src/gallium/drivers/r600/r600_state.c
+++ b/src/gallium/drivers/r600/r600_state.c
@@ -2213,10 +2213,11 @@ void r600_init_atom_start_cs(struct r600_context *rctx)
num_temp_gprs = 4;
num_gs_gprs = 0;
num_es_gprs = 0;
-   num_ps_threads = 136;
-   num_vs_threads = 48;
-   num_gs_threads = 4;
-   num_es_threads = 4;
+   /* use limits 40 VS and at least 16 ES/GS */
+   num_ps_threads = 120;
+   num_vs_threads = 40;
+   num_gs_threads = 16;
+   num_es_threads = 16;
num_ps_stack_entries = 40;
num_vs_stack_entries = 40;
num_gs_stack_entries = 32;
-- 
2.1.0

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

[Mesa-dev] [PATCH 5/8] r600: add alu + cf nop to copy shader on r600

[Dave Airlie]

From: Dave Airlie 

SB suggests we do this for r600, so lets do it,
for the copy shader.

Signed-off-by: Dave Airlie 
---
 src/gallium/drivers/r600/r600_shader.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/src/gallium/drivers/r600/r600_shader.c 
b/src/gallium/drivers/r600/r600_shader.c
index 6646a7e..0e7c0e8 100644
--- a/src/gallium/drivers/r600/r600_shader.c
+++ b/src/gallium/drivers/r600/r600_shader.c
@@ -1608,6 +1608,16 @@ static int generate_gs_copy_shader(struct r600_context 
*rctx,
cshader->shader.ring_item_sizes[ring] = ocnt * 16;
}
 
+   /* bc adds nops - copy it */
+   if (ctx.bc->chip_class == R600) {
+   memset(, 0, sizeof(struct r600_bytecode_alu));
+   alu.op = ALU_OP0_NOP;
+   alu.last = 1;
+   r600_bytecode_add_alu(ctx.bc, );
+
+   r600_bytecode_add_cfinst(ctx.bc, CF_OP_NOP);
+   }
+
/* export vertex data */
/* XXX factor out common code with r600_shader_from_tgsi ? */
for (i = 0; i < ocnt; ++i) {
-- 
2.1.0

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

[Mesa-dev] [PATCH 3/8] r600: do SQ flush ES ring rolling workaround

[Dave Airlie]

From: Dave Airlie 

Need to insert a SQ_NON_EVENT when ever geometry
shaders are enabled.

Signed-off-by: Dave Airlie 
---
 src/gallium/drivers/r600/r600_hw_context.c   | 5 +
 src/gallium/drivers/r600/r600_pipe.h | 1 +
 src/gallium/drivers/r600/r600_state_common.c | 7 +++
 src/gallium/drivers/r600/r600d.h | 1 +
 4 files changed, 14 insertions(+)

diff --git a/src/gallium/drivers/r600/r600_hw_context.c 
b/src/gallium/drivers/r600/r600_hw_context.c
index 6f11366..2a181dc 100644
--- a/src/gallium/drivers/r600/r600_hw_context.c
+++ b/src/gallium/drivers/r600/r600_hw_context.c
@@ -122,6 +122,11 @@ void r600_flush_emit(struct r600_context *rctx)
}
}
 
+   if (rctx->b.flags & R600_CONTEXT_GS_EXTRA_FLUSH) {
+   cs->buf[cs->cdw++] = PKT3(PKT3_EVENT_WRITE, 0, 0);
+   cs->buf[cs->cdw++] = EVENT_TYPE(EVENT_TYPE_SQ_NON_EVENT);
+   }
+
if (rctx->b.flags & R600_CONTEXT_PS_PARTIAL_FLUSH) {
cs->buf[cs->cdw++] = PKT3(PKT3_EVENT_WRITE, 0, 0);
cs->buf[cs->cdw++] = EVENT_TYPE(EVENT_TYPE_PS_PARTIAL_FLUSH) | 
EVENT_INDEX(4);
diff --git a/src/gallium/drivers/r600/r600_pipe.h 
b/src/gallium/drivers/r600/r600_pipe.h
index 520b03f..5a4ad9e 100644
--- a/src/gallium/drivers/r600/r600_pipe.h
+++ b/src/gallium/drivers/r600/r600_pipe.h
@@ -56,6 +56,7 @@
 #define R600_CONTEXT_PS_PARTIAL_FLUSH  (R600_CONTEXT_PRIVATE_FLAG << 8)
 #define R600_CONTEXT_WAIT_3D_IDLE  (R600_CONTEXT_PRIVATE_FLAG << 9)
 #define R600_CONTEXT_WAIT_CP_DMA_IDLE  (R600_CONTEXT_PRIVATE_FLAG << 
10)
+#define R600_CONTEXT_GS_EXTRA_FLUSH(R600_CONTEXT_PRIVATE_FLAG << 
11)
 
 /* the number of CS dwords for flushing and drawing */
 #define R600_MAX_FLUSH_CS_DWORDS   16
diff --git a/src/gallium/drivers/r600/r600_state_common.c 
b/src/gallium/drivers/r600/r600_state_common.c
index 178005a..7d0c98f 100644
--- a/src/gallium/drivers/r600/r600_state_common.c
+++ b/src/gallium/drivers/r600/r600_state_common.c
@@ -1584,6 +1584,13 @@ static void r600_draw_vbo(struct pipe_context *ctx, 
const struct pipe_draw_info
r600_mark_atom_dirty(rctx, >cb_misc_state.atom);
}
 
+   /* ES ring rolling over at EOP */
+   if (rctx->b.chip_class == R600) {
+   /* GS scenario G - emit event initiator SQ_NON_EVENT */
+   if (rctx->gs_shader)
+   rctx->b.flags |= R600_CONTEXT_GS_EXTRA_FLUSH;
+   }
+
/* Emit states. */
r600_need_cs_space(rctx, ib.user_buffer ? 5 : 0, TRUE);
r600_flush_emit(rctx);
diff --git a/src/gallium/drivers/r600/r600d.h b/src/gallium/drivers/r600/r600d.h
index 6bba88c..b0db226 100644
--- a/src/gallium/drivers/r600/r600d.h
+++ b/src/gallium/drivers/r600/r600d.h
@@ -130,6 +130,7 @@
 #define EVENT_TYPE_SAMPLE_STREAMOUTSTATS   0x20
 #define EVENT_TYPE_FLUSH_AND_INV_DB_META   0x2c /* supported on r700+ */
 #define EVENT_TYPE_VGT_FLUSH   0x24
+#define EVENT_TYPE_SQ_NON_EVENT0x26
 #define EVENT_TYPE_FLUSH_AND_INV_CB_META   46 /* supported on r700+ */
 #defineEVENT_TYPE(x)   ((x) << 0)
 #defineEVENT_INDEX(x)  ((x) << 8)
-- 
2.1.0

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

[Mesa-dev] [PATCH 4/8] r600: workaround empty geom shader.

[Dave Airlie]

From: Dave Airlie 

We need to emit at least one cut/emit in every
geometry shader, the easiest workaround it to
stick a single CUT at the top of each geom shader.

Signed-off-by: Dave Airlie 
---
 src/gallium/drivers/r600/r600_shader.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/src/gallium/drivers/r600/r600_shader.c 
b/src/gallium/drivers/r600/r600_shader.c
index fc6335a..6646a7e 100644
--- a/src/gallium/drivers/r600/r600_shader.c
+++ b/src/gallium/drivers/r600/r600_shader.c
@@ -2205,6 +2205,11 @@ static int r600_shader_from_tgsi(struct r600_context 
*rctx,
if (ctx.type == TGSI_PROCESSOR_GEOMETRY) {
struct r600_bytecode_alu alu;
int r;
+
+   /* GS thread with no output workaround - emit a cut at 
start of GS */
+   if (ctx.bc->chip_class == R600)
+   r600_bytecode_add_cfinst(ctx.bc, 
CF_OP_CUT_VERTEX);
+
for (j = 0; j < 4; j++) {
memset(, 0, sizeof(struct 
r600_bytecode_alu));
alu.op = ALU_OP1_MOV;
-- 
2.1.0

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

[Mesa-dev] [PATCH 8/8] r600: set mega fetch count to 16 for gs copy shader

[Dave Airlie]

From: Dave Airlie 

Seems like MFC should be set for this shader.

Signed-off-by: Dave Airlie 
---
 src/gallium/drivers/r600/r600_shader.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/gallium/drivers/r600/r600_shader.c 
b/src/gallium/drivers/r600/r600_shader.c
index 80922bf..c8eb03f 100644
--- a/src/gallium/drivers/r600/r600_shader.c
+++ b/src/gallium/drivers/r600/r600_shader.c
@@ -1549,6 +1549,7 @@ static int generate_gs_copy_shader(struct r600_context 
*rctx,
vtx.op = FETCH_OP_VFETCH;
vtx.buffer_id = R600_GS_RING_CONST_BUFFER;
vtx.fetch_type = SQ_VTX_FETCH_NO_INDEX_OFFSET;
+   vtx.mega_fetch_count = 16;
vtx.offset = out->ring_offset;
vtx.dst_gpr = out->gpr;
vtx.src_gpr = 0;
-- 
2.1.0

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

[Mesa-dev] [PATCH 7/8] r600: increment ring index after emit vertex not before.

[Dave Airlie]

From: Dave Airlie 

The docs say we should send the emit after the ring writes,
so lets do that and not have an ALU in between.

Signed-off-by: Dave Airlie 
---
 src/gallium/drivers/r600/r600_shader.c | 42 +++---
 1 file changed, 24 insertions(+), 18 deletions(-)

diff --git a/src/gallium/drivers/r600/r600_shader.c 
b/src/gallium/drivers/r600/r600_shader.c
index 0e7c0e8..80922bf 100644
--- a/src/gallium/drivers/r600/r600_shader.c
+++ b/src/gallium/drivers/r600/r600_shader.c
@@ -1788,6 +1788,27 @@ static int generate_gs_copy_shader(struct r600_context 
*rctx,
return r600_bytecode_build(ctx.bc);
 }
 
+static int emit_inc_ring_offset(struct r600_shader_ctx *ctx, int idx, bool ind)
+{
+   if (ind) {
+   struct r600_bytecode_alu alu;
+   int r;
+
+   memset(, 0, sizeof(struct r600_bytecode_alu));
+   alu.op = ALU_OP2_ADD_INT;
+   alu.src[0].sel = ctx->gs_export_gpr_tregs[idx];
+   alu.src[1].sel = V_SQ_ALU_SRC_LITERAL;
+   alu.src[1].value = ctx->gs_out_ring_offset >> 4;
+   alu.dst.sel = ctx->gs_export_gpr_tregs[idx];
+   alu.dst.write = 1;
+   alu.last = 1;
+   r = r600_bytecode_add_alu(ctx->bc, );
+   if (r)
+   return r;
+   }
+   return 0;
+}
+
 static int emit_gs_ring_writes(struct r600_shader_ctx *ctx, const struct 
pipe_stream_output_info *so, int stream, bool ind)
 {
struct r600_bytecode_output output;
@@ -1854,23 +1875,6 @@ static int emit_gs_ring_writes(struct r600_shader_ctx 
*ctx, const struct pipe_st
r600_bytecode_add_output(ctx->bc, );
}
 
-   if (ind) {
-   /* get a temp and add the ring offset to the next vertex base 
in the shader */
-   struct r600_bytecode_alu alu;
-   int r;
-
-   memset(, 0, sizeof(struct r600_bytecode_alu));
-   alu.op = ALU_OP2_ADD_INT;
-   alu.src[0].sel = ctx->gs_export_gpr_tregs[effective_stream];
-   alu.src[1].sel = V_SQ_ALU_SRC_LITERAL;
-   alu.src[1].value = ctx->gs_out_ring_offset >> 4;
-   alu.dst.sel = ctx->gs_export_gpr_tregs[effective_stream];
-   alu.dst.write = 1;
-   alu.last = 1;
-   r = r600_bytecode_add_alu(ctx->bc, );
-   if (r)
-   return r;
-   }
++ctx->gs_next_vertex;
return 0;
 }
@@ -7758,8 +7762,10 @@ static int tgsi_gs_emit(struct r600_shader_ctx *ctx)
emit_gs_ring_writes(ctx, ctx->gs_stream_output_info, stream, 
TRUE);
 
r = r600_bytecode_add_cfinst(ctx->bc, ctx->inst_info->op);
-   if (!r)
+   if (!r) {
ctx->bc->cf_last->count = stream; // Count field for 
CUT/EMIT_VERTEX indicates which stream
+   return emit_inc_ring_offset(ctx, stream, TRUE);
+   }
return r;
 }
 
-- 
2.1.0

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

Re: [Mesa-dev] [PATCH 01/23] i965: Silence unused parameter warnings in get_buffer_rect

[Anuj Phogat]

On Mon, Nov 9, 2015 at 4:56 PM, Ian Romanick  wrote:
> From: Ian Romanick 
>
> brw_meta_fast_clear.c: In function 'get_buffer_rect':
> brw_meta_fast_clear.c:318:37: warning: unused parameter 'brw' 
> [-Wunused-parameter]
>  get_buffer_rect(struct brw_context *brw, struct gl_framebuffer *fb,
>  ^
> brw_meta_fast_clear.c:319:44: warning: unused parameter 'irb' 
> [-Wunused-parameter]
>  struct intel_renderbuffer *irb, struct rect *rect)
> ^
>
> Signed-off-by: Ian Romanick 
> ---
>  src/mesa/drivers/dri/i965/brw_meta_fast_clear.c | 7 +++
>  1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_meta_fast_clear.c 
> b/src/mesa/drivers/dri/i965/brw_meta_fast_clear.c
> index 69fe7b4..12e7c32 100644
> --- a/src/mesa/drivers/dri/i965/brw_meta_fast_clear.c
> +++ b/src/mesa/drivers/dri/i965/brw_meta_fast_clear.c
> @@ -314,8 +314,7 @@ get_fast_clear_rect(struct gl_framebuffer *fb,
>  }
>
>  static void
> -get_buffer_rect(struct brw_context *brw, struct gl_framebuffer *fb,
> -struct intel_renderbuffer *irb, struct rect *rect)
> +get_buffer_rect(const struct gl_framebuffer *fb, struct rect *rect)
>  {
> rect->x0 = fb->_Xmin;
> rect->x1 = fb->_Xmax;
> @@ -526,12 +525,12 @@ brw_meta_fast_clear(struct brw_context *brw, struct 
> gl_framebuffer *fb,
>
>case REP_CLEAR:
>   rep_clear_buffers |= 1 << index;
> - get_buffer_rect(brw, fb, irb, _rect);
> + get_buffer_rect(fb, _rect);
>   break;
>
>case PLAIN_CLEAR:
>   plain_clear_buffers |= 1 << index;
> - get_buffer_rect(brw, fb, irb, _rect);
> + get_buffer_rect(fb, _rect);
>   continue;
>}
> }
> --
> 2.1.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reviewed-by: Anuj Phogat 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 92869] OpenGL ES 3.0 context creation failure

[bugzilla-daemon]

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

Jose Fonseca  changed:

   What|Removed |Added

 CC||chad.vers...@intel.com,
   ||i...@freedesktop.org,
   ||jfons...@vmware.com

--- Comment #1 from Jose Fonseca  ---
At one point I tried to fix this.  See:

  http://cgit.freedesktop.org/~jrfonseca/mesa/commit/?h=es2_profile

  http://lists.freedesktop.org/archives/mesa-dev/2015-April/082010.html

but I don't usually develop this part of Mesa, and fixing the issue turned out
to be trickier than I had foreseen, yet I didn't have time to test it properly,
so I had to give up..

-- 
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
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 92278] Black screen in War Thunder

[bugzilla-daemon]

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

--- Comment #10 from komin...@gmail.com ---
worked with
MESA_GL_VERSION_OVERRIDE=4.1COMPAT ~/.steam/steam/steamapps/common/War\
Thunder/launcher

-- 
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
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 6/7] i965/fs_surface_builder: Work in terms of native formats

[Chad Versace]

On Wed 04 Nov 2015, Jason Ekstrand wrote:
> ---
>  src/mesa/drivers/dri/i965/brw_fs_nir.cpp |  7 ---
>  src/mesa/drivers/dri/i965/brw_fs_surface_builder.cpp | 14 ++
>  src/mesa/drivers/dri/i965/brw_fs_surface_builder.h   |  4 ++--
>  3 files changed, 12 insertions(+), 13 deletions(-)

I applied patches 1-6 to master and closely searched for instances of
brw_format misused as a mesa_format and vice-versa, and found none. So
patch 6 LGTM.
Reviewed-by: Chad Versace 

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

[Mesa-dev] [PATCH] st/mesa: Destroy buffer object's mutex.

[Jose Fonseca]

Ideally we should have a _mesa_cleanup_buffer_object function in
src/mesa/bufferobj.c so that the destruction logic resided in a single
place.
---
 src/mesa/state_tracker/st_cb_bufferobjects.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/mesa/state_tracker/st_cb_bufferobjects.c 
b/src/mesa/state_tracker/st_cb_bufferobjects.c
index 8afd336..5d20b26 100644
--- a/src/mesa/state_tracker/st_cb_bufferobjects.c
+++ b/src/mesa/state_tracker/st_cb_bufferobjects.c
@@ -83,6 +83,7 @@ st_bufferobj_free(struct gl_context *ctx, struct 
gl_buffer_object *obj)
if (st_obj->buffer)
   pipe_resource_reference(_obj->buffer, NULL);
 
+   mtx_destroy(_obj->Base.Mutex);
free(st_obj->Base.Label);
free(st_obj);
 }
-- 
2.5.0

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

[Mesa-dev] [Bug 92877] Add support for libglvnd

[bugzilla-daemon]

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

Bug ID: 92877
   Summary: Add support for libglvnd
   Product: Mesa
   Version: unspecified
  Hardware: Other
   URL: http://lists.freedesktop.org/archives/mesa-dev/2015-Se
ptember/095856.html
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Other
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: matts...@gmail.com
QA Contact: mesa-dev@lists.freedesktop.org
CC: emil.l.veli...@gmail.com, i...@freedesktop.org

We'd like Mesa to support libglvnd. Hopefully this will allow us to get rid of
our API dispatch code in Mesa.

Follow-on work (in libglvnd) includes supporting EGL and OpenGL ES and using
the Khronos XML to generate the API entry points.

-- 
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
http://lists.freedesktop.org/mailman/listinfo/mesa-dev