[Mesa-dev] [Bug 72335] Requesting git commit access to mesa

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

  Attachment #90291|0   |1
is obsolete||

--- Comment #2 from Timothy Arceri  ---
Created attachment 90292
  --> https://bugs.freedesktop.org/attachment.cgi?id=90292&action=edit
PGP key

-- 
You are receiving this mail because:
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 72335] Requesting git commit access to mesa

[bugzilla-daemon]

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

--- Comment #1 from Timothy Arceri  ---
Created attachment 90291
  --> https://bugs.freedesktop.org/attachment.cgi?id=90291&action=edit
Whoops this is the SSH key other attachment was PGP

-- 
You are receiving this mail because:
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 72335] New: Requesting git commit access to mesa

[bugzilla-daemon]

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

  Priority: medium
Bug ID: 72335
  Assignee: mesa-dev@lists.freedesktop.org
   Summary: Requesting git commit access to mesa
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: t_arc...@yahoo.com.au
  Hardware: Other
Status: NEW
   Version: unspecified
 Component: Other
   Product: Mesa

Created attachment 90290
  --> https://bugs.freedesktop.org/attachment.cgi?id=90290&action=edit
ssh pub key

I would like to request commit access to Mesa for the primary purposes of
not having to hassle people to commit my reviewed patches. I've had a number of
patches committed to the project over the past few months.

-- 
You are receiving this mail because:
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] glsl: Remove unreachable error message

[Timothy Arceri]

On Wed, 2013-12-04 at 14:32 -0800, Ian Romanick wrote:
> On 11/20/2013 03:41 AM, Timothy Arceri wrote:
> > Left over from bug #34376.
> 
> I think this shader hits this error message:
> 
> #version 120
> 
> int x[];
> 
> void foo() { x[3] = 2; }
> 
> int x[] = int[2](1,2);
> 
> do_assignment is also used for initializers.  Initializers can be used
> to (explicitly) size arrays, and arrays declared without an explicit
> size can be redeclared with an explicit size.

Thanks Ian, mark this down as a newbie mistake I failed to recognise
this type of scenario would cause max_array_access to be set, although
its now obvious when I think about it. 

I guess this is a good candidate for a piglit test to help spot
regressions with the ARB_arrays_of_arrays work. I've already submitted
one test for the same reason [1] would it be better to save a bunch of
these tests up and submit them as a series or is it fine to submit them
one by one?

[1]
http://lists.freedesktop.org/archives/piglit/2013-December/008657.html 
> 
> > Signed-off-by: Timothy Arceri 
> > ---
> >  src/glsl/ast_to_hir.cpp | 7 ---
> >  1 file changed, 7 deletions(-)
> > 
> > diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
> > index 76b256c..adf10a0 100644
> > --- a/src/glsl/ast_to_hir.cpp
> > +++ b/src/glsl/ast_to_hir.cpp
> > @@ -813,13 +813,6 @@ do_assignment(exec_list *instructions, struct 
> > _mesa_glsl_parse_state *state,
> >  
> >  assert(var != NULL);
> >  
> > -if (var->max_array_access >= unsigned(rhs->type->array_size())) {
> > -   /* FINISHME: This should actually log the location of the RHS. */
> > -   _mesa_glsl_error(& lhs_loc, state, "array size must be > %u due to "
> > -"previous access",
> > -var->max_array_access);
> > -}
> > -
> >  var->type = glsl_type::get_array_instance(lhs->type->element_type(),
> >rhs->type->array_size());
> >  d->type = var->type;
> > 
> 


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

[Mesa-dev] [PATCH] glx: Use struct xshmfence* instead of int32_t*.

[Matt Turner]

---
 src/glx/dri3_glx.c  | 4 ++--
 src/glx/dri3_priv.h | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/glx/dri3_glx.c b/src/glx/dri3_glx.c
index b047cc8..1834c6d 100644
--- a/src/glx/dri3_glx.c
+++ b/src/glx/dri3_glx.c
@@ -676,7 +676,7 @@ dri3_alloc_render_buffer(struct glx_screen *glx_screen, 
Drawable draw,
xcb_connection_t *c = XGetXCBConnection(dpy);
xcb_pixmap_t pixmap;
xcb_sync_fence_t sync_fence;
-   int32_t *shm_fence;
+   struct xshmfence *shm_fence;
int buffer_fd, fence_fd;
int stride;
 
@@ -921,7 +921,7 @@ dri3_get_pixmap_buffer(__DRIdrawable *driDrawable,
struct dri3_screen   *psc;
xcb_connection_t *c;
xcb_sync_fence_t sync_fence;
-   int32_t  *shm_fence;
+   struct xshmfence *shm_fence;
int  fence_fd;
__DRIimage   *image_planar;
int  stride, offset;
diff --git a/src/glx/dri3_priv.h b/src/glx/dri3_priv.h
index c892800..efdc2ae 100644
--- a/src/glx/dri3_priv.h
+++ b/src/glx/dri3_priv.h
@@ -87,7 +87,7 @@ struct dri3_buffer {
 */
 
uint32_t sync_fence; /* XID of X SyncFence object */
-   int32_t  *shm_fence; /* pointer to xshmfence object */
+   struct xshmfence *shm_fence; /* pointer to xshmfence object */
GLbooleanbusy;   /* Set on swap, cleared on IdleNotify */
void *driverPrivate;
 
-- 
1.8.3.2

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

[Mesa-dev] [PATCH] swrast: fix readback regression since inversion fix

[Dave Airlie]

From: Dave Airlie 

This readback from the frontbuffer with swrast was broken, that bug
just made it more obviously broken, this fixes it by inverting the
sub image gets. Also fixes a few other piglits.

Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=72327
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=72325

(for 9.2 the patches this depends on were asked to be backported separately
 in an email).
Cc: "9.2" "10.0" mesa-sta...@lists.fedoraproject.org
Signed-off-by: Dave Airlie 
---
 src/mesa/drivers/dri/swrast/swrast.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/swrast/swrast.c 
b/src/mesa/drivers/dri/swrast/swrast.c
index 73dc5c4..0e1c530 100644
--- a/src/mesa/drivers/dri/swrast/swrast.c
+++ b/src/mesa/drivers/dri/swrast/swrast.c
@@ -402,7 +402,7 @@ swrast_map_renderbuffer(struct gl_context *ctx,
   stride = w * cpp;
   xrb->Base.Buffer = malloc(h * stride);
 
-  sPriv->swrast_loader->getImage(dPriv, x, y, w, h,
+  sPriv->swrast_loader->getImage(dPriv, x, rb->Height - y - h, w, h,
 (char *) xrb->Base.Buffer,
 dPriv->loaderPrivate);
 
-- 
1.8.3.1

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

Re: [Mesa-dev] [PATCH 7/7] i965/gen7+: Implement fast color clears for MSAA buffers.

[Kenneth Graunke]

On 12/04/2013 03:07 PM, Chad Versace wrote:
> On 12/04/2013 06:30 AM, Paul Berry wrote:
>> Fast color clears of MSAA buffers work just like fast color clears
>> with non-MSAA buffers, except that the alignment and scaledown
>> requirements are different.
>> ---
>>   src/mesa/drivers/dri/i965/brw_blorp_clear.cpp | 131
>> +-
>>   1 file changed, 87 insertions(+), 44 deletions(-)
>>
>> diff --git a/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp
>> b/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp
>> index ab472e6..4d03cbe 100644
>> --- a/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp
>> +++ b/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp
>> @@ -239,8 +239,7 @@
>> brw_blorp_clear_params::brw_blorp_clear_params(struct brw_context *brw,
>>  }
>>
>>  /* If we can do this as a fast color clear, do so. */
>> -   if (irb->mt->msaa_layout == INTEL_MSAA_LAYOUT_NONE &&
>> -   irb->mt->fast_clear_state != INTEL_FAST_CLEAR_STATE_NO_MCS &&
>> +   if (irb->mt->fast_clear_state != INTEL_FAST_CLEAR_STATE_NO_MCS &&
>>  !partial_clear && wm_prog_key.use_simd16_replicated_data &&
>>  is_color_fast_clear_compatible(brw, format,
>> &ctx->Color.ClearColor)) {
>> memset(push_consts, 0xff, 4*sizeof(float));
>> @@ -251,48 +250,92 @@
>> brw_blorp_clear_params::brw_blorp_clear_params(struct brw_context *brw,
>>  */
>> unsigned x_align, y_align, x_scaledown, y_scaledown;
>>
>> -  /* From the Ivy Bridge PRM, Vol2 Part1 11.7 "MCS Buffer for Render
>> -   * Target(s)", beneath the "Fast Color Clear" bullet (p327):
>> -   *
>> -   * Clear pass must have a clear rectangle that must follow
>> alignment
>> -   * rules in terms of pixels and lines as shown in the table
>> -   * below. Further, the clear-rectangle height and width
>> must be
>> -   * multiple of the following dimensions. If the height and
>> width of
>> -   * the render target being cleared do not meet these
>> requirements,
>> -   * an MCS buffer can be created such that it follows the
>> requirement
>> -   * and covers the RT.
>> -   *
>> -   * The alignment size in the table that follows is related to the
>> -   * alignment size returned by
>> intel_get_non_msrt_mcs_alignment(), but
>> -   * with X alignment multiplied by 16 and Y alignment multiplied
>> by 32.
>> -   */
>> -  intel_get_non_msrt_mcs_alignment(brw, irb->mt, &x_align,
>> &y_align);
>> -  x_align *= 16;
>> -  y_align *= 32;
>> -
>> -  /* From the Ivy Bridge PRM, Vol2 Part1 11.7 "MCS Buffer for Render
>> -   * Target(s)", beneath the "Fast Color Clear" bullet (p327):
>> -   *
>> -   * In order to optimize the performance MCS buffer (when
>> bound to 1X
>> -   * RT) clear similarly to MCS buffer clear for MSRT case,
>> clear rect
>> -   * is required to be scaled by the following factors in the
>> -   * horizontal and vertical directions:
>> -   *
>> -   * The X and Y scale down factors in the table that follows are
>> each
>> -   * equal to half the alignment value computed above.
>> -   */
>> -  x_scaledown = x_align / 2;
>> -  y_scaledown = y_align / 2;
>> -
>> -  /* From BSpec: 3D-Media-GPGPU Engine > 3D Pipeline > Pixel > Pixel
>> -   * Backend > MCS Buffer for Render Target(s) [DevIVB+] > Table
>> "Color
>> -   * Clear of Non-MultiSampled Render Target Restrictions":
>> -   *
>> -   *   Clear rectangle must be aligned to two times the number of
>> pixels in
>> -   *   the table shown below due to 16x16 hashing across the slice.
>> -   */
>> -  x_align *= 2;
>> -  y_align *= 2;
>> +  if (irb->mt->msaa_layout == INTEL_MSAA_LAYOUT_NONE) {
>> + /* From the Ivy Bridge PRM, Vol2 Part1 11.7 "MCS Buffer for
>> Render
>> +  * Target(s)", beneath the "Fast Color Clear" bullet (p327):
>> +  *
>> +  * Clear pass must have a clear rectangle that must follow
>> +  * alignment rules in terms of pixels and lines as shown
>> in the
>> +  * table below. Further, the clear-rectangle height and
>> width
>> +  * must be multiple of the following dimensions. If the
>> height
>> +  * and width of the render target being cleared do not
>> meet these
>> +  * requirements, an MCS buffer can be created such that it
>> +  * follows the requirement and covers the RT.
>> +  *
>> +  * The alignment size in the table that follows is related
>> to the
>> +  * alignment size returned by
>> intel_get_non_msrt_mcs_alignment(), but
>> +  * with X alignment multiplied by 16 and Y alignment
>> multiplied by 32.
>> +  */
>> + intel_get_non_msrt_mcs_alignment(brw, irb->mt, &x_align,
>> &y_align);
>> + x_align *= 16;
>> + y_align *= 32;
>> +
>> + /* From the Ivy Bridge PRM, Vol2 Part1 11.7 "MCS Buf

Re: [Mesa-dev] [PATCH 7/7] i965/gen7+: Implement fast color clears for MSAA buffers.

[Kenneth Graunke]

On 12/04/2013 06:30 AM, Paul Berry wrote:
> Fast color clears of MSAA buffers work just like fast color clears
> with non-MSAA buffers, except that the alignment and scaledown
> requirements are different.
> ---
>  src/mesa/drivers/dri/i965/brw_blorp_clear.cpp | 131 
> +-
>  1 file changed, 87 insertions(+), 44 deletions(-)
> 
> diff --git a/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp 
> b/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp
> index ab472e6..4d03cbe 100644
> --- a/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp
> @@ -239,8 +239,7 @@ brw_blorp_clear_params::brw_blorp_clear_params(struct 
> brw_context *brw,
> }
>  
> /* If we can do this as a fast color clear, do so. */
> -   if (irb->mt->msaa_layout == INTEL_MSAA_LAYOUT_NONE &&
> -   irb->mt->fast_clear_state != INTEL_FAST_CLEAR_STATE_NO_MCS &&
> +   if (irb->mt->fast_clear_state != INTEL_FAST_CLEAR_STATE_NO_MCS &&
> !partial_clear && wm_prog_key.use_simd16_replicated_data &&
> is_color_fast_clear_compatible(brw, format, &ctx->Color.ClearColor)) {
>memset(push_consts, 0xff, 4*sizeof(float));
> @@ -251,48 +250,92 @@ brw_blorp_clear_params::brw_blorp_clear_params(struct 
> brw_context *brw,
> */
>unsigned x_align, y_align, x_scaledown, y_scaledown;
>  
> -  /* From the Ivy Bridge PRM, Vol2 Part1 11.7 "MCS Buffer for Render
> -   * Target(s)", beneath the "Fast Color Clear" bullet (p327):
> -   *
> -   * Clear pass must have a clear rectangle that must follow 
> alignment
> -   * rules in terms of pixels and lines as shown in the table
> -   * below. Further, the clear-rectangle height and width must be
> -   * multiple of the following dimensions. If the height and width of
> -   * the render target being cleared do not meet these requirements,
> -   * an MCS buffer can be created such that it follows the 
> requirement
> -   * and covers the RT.
> -   *
> -   * The alignment size in the table that follows is related to the
> -   * alignment size returned by intel_get_non_msrt_mcs_alignment(), but
> -   * with X alignment multiplied by 16 and Y alignment multiplied by 32.
> -   */
> -  intel_get_non_msrt_mcs_alignment(brw, irb->mt, &x_align, &y_align);
> -  x_align *= 16;
> -  y_align *= 32;
> -
> -  /* From the Ivy Bridge PRM, Vol2 Part1 11.7 "MCS Buffer for Render
> -   * Target(s)", beneath the "Fast Color Clear" bullet (p327):
> -   *
> -   * In order to optimize the performance MCS buffer (when bound to 
> 1X
> -   * RT) clear similarly to MCS buffer clear for MSRT case, clear 
> rect
> -   * is required to be scaled by the following factors in the
> -   * horizontal and vertical directions:
> -   *
> -   * The X and Y scale down factors in the table that follows are each
> -   * equal to half the alignment value computed above.
> -   */
> -  x_scaledown = x_align / 2;
> -  y_scaledown = y_align / 2;
> -
> -  /* From BSpec: 3D-Media-GPGPU Engine > 3D Pipeline > Pixel > Pixel
> -   * Backend > MCS Buffer for Render Target(s) [DevIVB+] > Table "Color
> -   * Clear of Non-MultiSampled Render Target Restrictions":
> -   *
> -   *   Clear rectangle must be aligned to two times the number of pixels 
> in
> -   *   the table shown below due to 16x16 hashing across the slice.
> -   */
> -  x_align *= 2;
> -  y_align *= 2;
> +  if (irb->mt->msaa_layout == INTEL_MSAA_LAYOUT_NONE) {
> + /* From the Ivy Bridge PRM, Vol2 Part1 11.7 "MCS Buffer for Render
> +  * Target(s)", beneath the "Fast Color Clear" bullet (p327):
> +  *
> +  * Clear pass must have a clear rectangle that must follow
> +  * alignment rules in terms of pixels and lines as shown in the
> +  * table below. Further, the clear-rectangle height and width
> +  * must be multiple of the following dimensions. If the height
> +  * and width of the render target being cleared do not meet 
> these
> +  * requirements, an MCS buffer can be created such that it
> +  * follows the requirement and covers the RT.
> +  *
> +  * The alignment size in the table that follows is related to the
> +  * alignment size returned by intel_get_non_msrt_mcs_alignment(), 
> but
> +  * with X alignment multiplied by 16 and Y alignment multiplied by 
> 32.
> +  */
> + intel_get_non_msrt_mcs_alignment(brw, irb->mt, &x_align, &y_align);
> + x_align *= 16;
> + y_align *= 32;
> +
> + /* From the Ivy Bridge PRM, Vol2 Part1 11.7 "MCS Buffer for Render
> +  * Target(s)", beneath the "Fast Color Clear" bullet (p327):
> +  *
> +  * In order to optimize the performance MCS buffer (when bound 

Re: [Mesa-dev] [PATCH] mesa: Portably detect the availability of fpclassify.

[Ian Romanick]

On 11/20/2013 01:15 PM, Jonas 'Sortie' Termansen wrote:
> POSIX 2008 mandates fpclassify, FP_INFINITE, FP_NAN, FP_NORMAL, FP_SUBNORMAL,

And C99.

> and FP_ZERO are all macros and we can therefore detect them through simple
> preprocessor conditionals on compliant platforms. This avoids further growth
> of the current preprocessor list of platforms that has fpclassify. I retained
> the current platform list as I could not confirm whether all the currently
> supported platforms correctly declare all these as macros.
> ---
>  src/mesa/main/querymatrix.c |7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/src/mesa/main/querymatrix.c b/src/mesa/main/querymatrix.c
> index 19a8e92..4507343 100644
> --- a/src/mesa/main/querymatrix.c
> +++ b/src/mesa/main/querymatrix.c
> @@ -37,7 +37,12 @@
>  #define INT_TO_FIXED(x) ((GLfixed) ((x) << 16))
>  #define FLOAT_TO_FIXED(x) ((GLfixed) ((x) * 65536.0))
>  
> -#if defined(_MSC_VER)
> +#if defined(fpclassify) && defined(FP_INFINITE) && defined(FP_NAN) && \
> +defined(FP_NORMAL) && defined(FP_SUBNORMAL) && defined(FP_ZERO)
> +
> +/* fpclassify is available. */
> +
> +#elif defined(_MSC_VER)
>  #if _MSC_VER < 1800  /* Not required on VS2013 and above. */
>  /* Oddly, the fpclassify() function doesn't exist in such a form
>   * on MSVC.  This is an implementation using slightly different
> 

Shouldn't the other /* fpclassify is available. */ block (below) get
removed?  I think we could also get rid of the '#if _MSC_VER < 1800'
check as well, since the new '#if defined' block will already catch that
case.  That should probably be a separate patch, however.

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

Re: [Mesa-dev] [PATCH 7/7] i965/gen7+: Implement fast color clears for MSAA buffers.

[Anuj Phogat]

On Wed, Dec 4, 2013 at 6:30 AM, Paul Berry  wrote:
> Fast color clears of MSAA buffers work just like fast color clears
> with non-MSAA buffers, except that the alignment and scaledown
> requirements are different.
> ---
>  src/mesa/drivers/dri/i965/brw_blorp_clear.cpp | 131 
> +-
>  1 file changed, 87 insertions(+), 44 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp 
> b/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp
> index ab472e6..4d03cbe 100644
> --- a/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp
> @@ -239,8 +239,7 @@ brw_blorp_clear_params::brw_blorp_clear_params(struct 
> brw_context *brw,
> }
>
> /* If we can do this as a fast color clear, do so. */
> -   if (irb->mt->msaa_layout == INTEL_MSAA_LAYOUT_NONE &&
> -   irb->mt->fast_clear_state != INTEL_FAST_CLEAR_STATE_NO_MCS &&
> +   if (irb->mt->fast_clear_state != INTEL_FAST_CLEAR_STATE_NO_MCS &&
> !partial_clear && wm_prog_key.use_simd16_replicated_data &&
> is_color_fast_clear_compatible(brw, format, &ctx->Color.ClearColor)) {
>memset(push_consts, 0xff, 4*sizeof(float));
> @@ -251,48 +250,92 @@ brw_blorp_clear_params::brw_blorp_clear_params(struct 
> brw_context *brw,
> */
>unsigned x_align, y_align, x_scaledown, y_scaledown;
>
> -  /* From the Ivy Bridge PRM, Vol2 Part1 11.7 "MCS Buffer for Render
> -   * Target(s)", beneath the "Fast Color Clear" bullet (p327):
> -   *
> -   * Clear pass must have a clear rectangle that must follow 
> alignment
> -   * rules in terms of pixels and lines as shown in the table
> -   * below. Further, the clear-rectangle height and width must be
> -   * multiple of the following dimensions. If the height and width of
> -   * the render target being cleared do not meet these requirements,
> -   * an MCS buffer can be created such that it follows the 
> requirement
> -   * and covers the RT.
> -   *
> -   * The alignment size in the table that follows is related to the
> -   * alignment size returned by intel_get_non_msrt_mcs_alignment(), but
> -   * with X alignment multiplied by 16 and Y alignment multiplied by 32.
> -   */
> -  intel_get_non_msrt_mcs_alignment(brw, irb->mt, &x_align, &y_align);
> -  x_align *= 16;
> -  y_align *= 32;
> -
> -  /* From the Ivy Bridge PRM, Vol2 Part1 11.7 "MCS Buffer for Render
> -   * Target(s)", beneath the "Fast Color Clear" bullet (p327):
> -   *
> -   * In order to optimize the performance MCS buffer (when bound to 
> 1X
> -   * RT) clear similarly to MCS buffer clear for MSRT case, clear 
> rect
> -   * is required to be scaled by the following factors in the
> -   * horizontal and vertical directions:
> -   *
> -   * The X and Y scale down factors in the table that follows are each
> -   * equal to half the alignment value computed above.
> -   */
> -  x_scaledown = x_align / 2;
> -  y_scaledown = y_align / 2;
> -
> -  /* From BSpec: 3D-Media-GPGPU Engine > 3D Pipeline > Pixel > Pixel
> -   * Backend > MCS Buffer for Render Target(s) [DevIVB+] > Table "Color
> -   * Clear of Non-MultiSampled Render Target Restrictions":
> -   *
> -   *   Clear rectangle must be aligned to two times the number of pixels 
> in
> -   *   the table shown below due to 16x16 hashing across the slice.
> -   */
> -  x_align *= 2;
> -  y_align *= 2;
> +  if (irb->mt->msaa_layout == INTEL_MSAA_LAYOUT_NONE) {
> + /* From the Ivy Bridge PRM, Vol2 Part1 11.7 "MCS Buffer for Render
> +  * Target(s)", beneath the "Fast Color Clear" bullet (p327):
> +  *
> +  * Clear pass must have a clear rectangle that must follow
> +  * alignment rules in terms of pixels and lines as shown in the
> +  * table below. Further, the clear-rectangle height and width
> +  * must be multiple of the following dimensions. If the height
> +  * and width of the render target being cleared do not meet 
> these
> +  * requirements, an MCS buffer can be created such that it
> +  * follows the requirement and covers the RT.
> +  *
> +  * The alignment size in the table that follows is related to the
> +  * alignment size returned by intel_get_non_msrt_mcs_alignment(), 
> but
> +  * with X alignment multiplied by 16 and Y alignment multiplied by 
> 32.
> +  */
> + intel_get_non_msrt_mcs_alignment(brw, irb->mt, &x_align, &y_align);
> + x_align *= 16;
> + y_align *= 32;
> +
> + /* From the Ivy Bridge PRM, Vol2 Part1 11.7 "MCS Buffer for Render
> +  * Target(s)", beneath the "Fast Color Clear" bullet (p327):
> +  *
> +  * In order to optimize the performance MCS buffer (when bou

[Mesa-dev] [Bug 72327] [swrast] piglit glean pointSprite regression

[bugzilla-daemon]

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

Vinson Lee  changed:

   What|Removed |Added

Summary|[swrast] piglit glean   |[swrast] piglit glean
   |pointSprite regression  |pointSprite regression
   |(master)|

-- 
You are receiving this mail because:
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 72327] New: [swrast] piglit glean pointSprite regression (master)

[bugzilla-daemon]

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

  Priority: medium
Bug ID: 72327
  Keywords: regression
CC: airl...@freedesktop.org
  Assignee: mesa-dev@lists.freedesktop.org
   Summary: [swrast] piglit glean pointSprite regression (master)
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: v...@freedesktop.org
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: git
 Component: Other
   Product: Mesa

mesa: 314ccf69016d0025ce25113cc448159a3b10 (master)

$ ./bin/glean -t pointSprite --quick
Could not find any non-black pixels.
Primitive type: GL_POINTS
Coord Origin at: GL_UPPER_LEFT
PointSize: 1.85
Could not find any non-black pixels.
Primitive type: GL_POINTS
Coord Origin at: GL_LOWER_LEFT
PointSize: 1.85
pointSprite:  FAIL rgba8, db, z24, s8, win+pmap, id 33
5 tests passed, 2 tests failed.

a43b49dfb13dc7e6d2d6d7ceee892077038d7102 is the first bad commit
commit a43b49dfb13dc7e6d2d6d7ceee892077038d7102
Author: Dave Airlie 
Date:   Wed Nov 13 12:53:52 2013 +1000

mesa/swrast: fix inverted front buffer rendering with old-school swrast

I've no idea when this broke, but we have some people who wanted it fixed,
so here's my attempt.

reproducer, run readpix with swrast hit f, or run trival tri -sb things are
upside down, after this patch they aren't.

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

Cc: "
Signed-off-by: Dave Airlie 

:04 04 70e437e84fa67556a6469a8bf75277a6ec07e8a6
a307a4bc1dcb80aae42897ce27b7771dd8760f4f Msrc
bisect run success

-- 
You are receiving this mail because:
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 72326] New: [swrast] piglit glean pbo regression

[bugzilla-daemon]

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

  Priority: medium
Bug ID: 72326
  Keywords: regression
CC: airl...@freedesktop.org
  Assignee: mesa-dev@lists.freedesktop.org
   Summary: [swrast] piglit glean pbo regression
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: v...@freedesktop.org
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: git
 Component: Other
   Product: Mesa

mesa: 314ccf69016d0025ce25113cc448159a3b10 (master)

$ ./bin/glean -t pbo --quick
FAILURE: glDrawPixels failed (at tpbo.cpp:317)
  got (0, 1) = [0, 0, 0], should be [1, 1, 1]
Mesa: User error: GL_INVALID_OPERATION in glDrawPixels(invalid PBO access)
Mesa: User error: GL_INVALID_OPERATION in glReadPixels(out of bounds PBO
access)
pbo:  FAIL rgba8, db, z24, s8, win+pmap, id 33
7 tests passed, 1 tests failed.


a43b49dfb13dc7e6d2d6d7ceee892077038d7102 is the first bad commit
commit a43b49dfb13dc7e6d2d6d7ceee892077038d7102
Author: Dave Airlie 
Date:   Wed Nov 13 12:53:52 2013 +1000

mesa/swrast: fix inverted front buffer rendering with old-school swrast

I've no idea when this broke, but we have some people who wanted it fixed,
so here's my attempt.

reproducer, run readpix with swrast hit f, or run trival tri -sb things are
upside down, after this patch they aren't.

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

Cc: "
Signed-off-by: Dave Airlie 

:04 04 70e437e84fa67556a6469a8bf75277a6ec07e8a6
a307a4bc1dcb80aae42897ce27b7771dd8760f4f Msrc
bisect run success

-- 
You are receiving this mail because:
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 03/15] i965/cfg: Rework to make IF & ELSE blocks flow into ENDIF.

[Matt Turner]

On Wed, Dec 4, 2013 at 1:17 PM, Eric Anholt  wrote:
> Matt Turner  writes:
>
>> Previously we made the basic block following an ENDIF instruction a
>> successor of the basic blocks ending with IF and ELSE. The PRM says that
>> IF and ELSE instructions jump *to* the ENDIF, rather than over it.
>>
>> This should be immaterial to dataflow analysis, except for if, break,
>> endif sequences:
>>
>>START B1 <-B0 <-B9
>> 0x0100: cmp.g.f0(8) nullg15<8,8,1>F g4<0,1,0>F
>> 0x0110: (+f0) if(8) 0 0 null0xUD
>>END B1 ->B2 ->B4
>>START B2 <-B1
>>break
>> 0x0120: break(8) 0 0null0D
>>END B2 ->B10
>>START B3
>> 0x0130: endif(8) 2  null0x0002UD
>>END B3 ->B4
>>
>> The ENDIF block would have no parents, so dataflow analysis would
>> generate incorrect results, preventing copy propagation from eliminating
>> some instructions.
>>
>> This patch changes the CFG to make ENDIF start rather than end basic
>> blocks, so that it can be the jump target of the IF and ELSE
>> instructions.
>>
>> It helps three programs (including two fs8/fs16 pairs) and hurts a
>> single fs8/fs16 pair.
>>
>> total instructions in shared programs: 1561126 -> 1561066 (-0.00%)
>> instructions in affected programs: 983 -> 923 (-6.10%)
>>
>> More importantly, it allows copy propagation to handle more cases.
>> Disabling the register_coalesce() pass before this patch hurts 58
>> programs, while afterward it only hurts 11 programs.
>> ---
>>  src/mesa/drivers/dri/i965/brw_cfg.cpp | 46 
>> +--
>>  1 file changed, 33 insertions(+), 13 deletions(-)
>>
>> diff --git a/src/mesa/drivers/dri/i965/brw_cfg.cpp 
>> b/src/mesa/drivers/dri/i965/brw_cfg.cpp
>> index 548b458..83c3c34 100644
>> --- a/src/mesa/drivers/dri/i965/brw_cfg.cpp
>> +++ b/src/mesa/drivers/dri/i965/brw_cfg.cpp
>> @@ -133,10 +133,7 @@ cfg_t::create(void *parent_mem_ctx, exec_list 
>> *instructions)
>>
>>cur_if = cur;
>>cur_else = NULL;
>> -  /* Set up the block just after the endif.  Don't know when exactly
>> -   * it will start, yet.
>> -   */
>> -  cur_endif = new_block();
>> + cur_endif = NULL;
>>
>>/* Set up our immediately following block, full of "then"
>> * instructions.
>> @@ -149,26 +146,49 @@ cfg_t::create(void *parent_mem_ctx, exec_list 
>> *instructions)
>>break;
>>
>>case BRW_OPCODE_ELSE:
>> -  cur->add_successor(mem_ctx, cur_endif);
>> + cur_else = cur;
>>
>>next = new_block();
>>next->start = (backend_instruction *)inst->next;
>>cur_if->add_successor(mem_ctx, next);
>> -  cur_else = next;
>>
>>set_next_block(next);
>>break;
>>
>>case BRW_OPCODE_ENDIF: {
>> -  cur_endif->start = (backend_instruction *)inst->next;
>> -  cur->add_successor(mem_ctx, cur_endif);
>> -  set_next_block(cur_endif);
>> + backend_instruction *prev_inst = (backend_instruction *)inst->prev;
>> + switch (prev_inst->opcode) {
>> + case BRW_OPCODE_IF:
>> + case BRW_OPCODE_ELSE:
>> + case BRW_OPCODE_WHILE:
>> + case BRW_OPCODE_DO:
>> + case BRW_OPCODE_BREAK:
>> + case BRW_OPCODE_CONTINUE:
>> +/* New block was just created; use it. */
>> +cur_endif = cur;
>> +break;
>
> Instead of the opcode switch for this test, couldn't you just do "if
> cur->start == inst"?

Yes, that is better.

> Other than that, this series is:
>
> Reviewed-by: Eric Anholt 

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

Re: [Mesa-dev] [PATCH 7/7] i965/gen7+: Implement fast color clears for MSAA buffers.

[Chad Versace]

On 12/04/2013 06:30 AM, Paul Berry wrote:

Fast color clears of MSAA buffers work just like fast color clears
with non-MSAA buffers, except that the alignment and scaledown
requirements are different.
---
  src/mesa/drivers/dri/i965/brw_blorp_clear.cpp | 131 +-
  1 file changed, 87 insertions(+), 44 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp 
b/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp
index ab472e6..4d03cbe 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp
+++ b/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp
@@ -239,8 +239,7 @@ brw_blorp_clear_params::brw_blorp_clear_params(struct 
brw_context *brw,
 }

 /* If we can do this as a fast color clear, do so. */
-   if (irb->mt->msaa_layout == INTEL_MSAA_LAYOUT_NONE &&
-   irb->mt->fast_clear_state != INTEL_FAST_CLEAR_STATE_NO_MCS &&
+   if (irb->mt->fast_clear_state != INTEL_FAST_CLEAR_STATE_NO_MCS &&
 !partial_clear && wm_prog_key.use_simd16_replicated_data &&
 is_color_fast_clear_compatible(brw, format, &ctx->Color.ClearColor)) {
memset(push_consts, 0xff, 4*sizeof(float));
@@ -251,48 +250,92 @@ brw_blorp_clear_params::brw_blorp_clear_params(struct 
brw_context *brw,
 */
unsigned x_align, y_align, x_scaledown, y_scaledown;

-  /* From the Ivy Bridge PRM, Vol2 Part1 11.7 "MCS Buffer for Render
-   * Target(s)", beneath the "Fast Color Clear" bullet (p327):
-   *
-   * Clear pass must have a clear rectangle that must follow alignment
-   * rules in terms of pixels and lines as shown in the table
-   * below. Further, the clear-rectangle height and width must be
-   * multiple of the following dimensions. If the height and width of
-   * the render target being cleared do not meet these requirements,
-   * an MCS buffer can be created such that it follows the requirement
-   * and covers the RT.
-   *
-   * The alignment size in the table that follows is related to the
-   * alignment size returned by intel_get_non_msrt_mcs_alignment(), but
-   * with X alignment multiplied by 16 and Y alignment multiplied by 32.
-   */
-  intel_get_non_msrt_mcs_alignment(brw, irb->mt, &x_align, &y_align);
-  x_align *= 16;
-  y_align *= 32;
-
-  /* From the Ivy Bridge PRM, Vol2 Part1 11.7 "MCS Buffer for Render
-   * Target(s)", beneath the "Fast Color Clear" bullet (p327):
-   *
-   * In order to optimize the performance MCS buffer (when bound to 1X
-   * RT) clear similarly to MCS buffer clear for MSRT case, clear rect
-   * is required to be scaled by the following factors in the
-   * horizontal and vertical directions:
-   *
-   * The X and Y scale down factors in the table that follows are each
-   * equal to half the alignment value computed above.
-   */
-  x_scaledown = x_align / 2;
-  y_scaledown = y_align / 2;
-
-  /* From BSpec: 3D-Media-GPGPU Engine > 3D Pipeline > Pixel > Pixel
-   * Backend > MCS Buffer for Render Target(s) [DevIVB+] > Table "Color
-   * Clear of Non-MultiSampled Render Target Restrictions":
-   *
-   *   Clear rectangle must be aligned to two times the number of pixels in
-   *   the table shown below due to 16x16 hashing across the slice.
-   */
-  x_align *= 2;
-  y_align *= 2;
+  if (irb->mt->msaa_layout == INTEL_MSAA_LAYOUT_NONE) {
+ /* From the Ivy Bridge PRM, Vol2 Part1 11.7 "MCS Buffer for Render
+  * Target(s)", beneath the "Fast Color Clear" bullet (p327):
+  *
+  * Clear pass must have a clear rectangle that must follow
+  * alignment rules in terms of pixels and lines as shown in the
+  * table below. Further, the clear-rectangle height and width
+  * must be multiple of the following dimensions. If the height
+  * and width of the render target being cleared do not meet these
+  * requirements, an MCS buffer can be created such that it
+  * follows the requirement and covers the RT.
+  *
+  * The alignment size in the table that follows is related to the
+  * alignment size returned by intel_get_non_msrt_mcs_alignment(), but
+  * with X alignment multiplied by 16 and Y alignment multiplied by 32.
+  */
+ intel_get_non_msrt_mcs_alignment(brw, irb->mt, &x_align, &y_align);
+ x_align *= 16;
+ y_align *= 32;
+
+ /* From the Ivy Bridge PRM, Vol2 Part1 11.7 "MCS Buffer for Render
+  * Target(s)", beneath the "Fast Color Clear" bullet (p327):
+  *
+  * In order to optimize the performance MCS buffer (when bound to
+  * 1X RT) clear similarly to MCS buffer clear for MSRT case,
+  * clear rect is required to be scaled by the following factors
+  * in the horizontal and vertical dir

Re: [Mesa-dev] [PATCH 7/9] mesa: Fill out ARB_texture_view entry points

[Courtney Goeltzenleuchter]

It's come to my attention that Mesa's handling of GL_TEXTURE_BASE_LEVEL and
GL_TEXTURE_MAX_LEVEL in glTexParameter and glGetTexParameter may be
incorrect. The issue happens with the following sequence:

glTexStorage2D(GL_TEXTURE_2D, 4, GL_RGBA8, 128, 128);

glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_BASE_LEVEL, 5);

glGetTexParameter(GL_TEXTURE_2D, GL_TEXTURE_BASE_LEVEL, &n);

The key question is: What is the value of n?

Right now, the Mesa driver will clamp the glTexParameter call to the range
0 .. 3 (as specified by the TexStorage call) and n = 3 after the
GetTexParameter call. However, the value returned on the Intel Windows
driver and NVIDIA's Linux driver return 5. This has apparently been
discussed among Kronos members in bug: 9342 (
https://cvs.khronos.org/bugzilla/show_bug.cgi?id=9342) which I don't have
visibility of.

To match that behavior the texture object will likely need two BaseLevel
and MaxLevel attributes. One that's clamped and used locally and the other
that simply holds the set value as given by the application in the
glTexParameter call.

Thoughts?

Courtney


On Tue, Dec 3, 2013 at 4:30 PM, Courtney Goeltzenleuchter <
court...@lunarg.com> wrote:

>
>
>
> On Tue, Dec 3, 2013 at 4:28 PM, Brian Paul  wrote:
>
>> On 12/03/2013 02:56 PM, Courtney Goeltzenleuchter wrote:
>>
>>> Hi Brian,
>>>
>>> I've made all the recommended changes.
>>>
>>> I also added one, a test that the Driver.TextureView != NULL before
>>> calling. This lets me test the non DD functionality with the
>>> MESA_EXTENSION_OVERRIDE=+GL_ARB_texture_view
>>>
>>> I've also rebased to latest master (no changes required). Whole stream
>>> can be found at:
>>> https://github.com/courtney-lunarg/mesa/tree/texture_view-rc6
>>> >> //github.com/courtney-lunarg/mesa/tree/texture_view-rc6&k=
>>> oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=lGQMzzTgII0I7jefp2FHq7WtZ%
>>> 2BTLs8wadB%2BiIj9xpBY%3D%0A&m=StSJ4O%2Fa%2B9Zp%2FeTtJIDzJ1NxrKtDXrENaO%
>>> 2FoFA9gY1k%3D%0A&s=0439e3fc50d195734c13b4c5e22024
>>> f034c27b7e657c8f79e08993b98f117518>
>>>
>>>
>>> Let me know if you need me to post the patches to the mail list or not.
>>>
>>
>> The series LGTM.  Thanks.  Reviewed-by: Brian Paul 
>>
>> Do you need someone to push to master for you?
>
>
> Yes please!
>
>
>>
>>
>> -Brian
>>
>>
>
>
> --
> Courtney Goeltzenleuchter
> LunarG
>
>


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

[Mesa-dev] [Bug 72325] New: [swrast] piglit glean fbo regression

[bugzilla-daemon]

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

  Priority: medium
Bug ID: 72325
  Keywords: regression
CC: airl...@freedesktop.org
  Assignee: mesa-dev@lists.freedesktop.org
   Summary: [swrast] piglit glean fbo regression
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: v...@freedesktop.org
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: git
 Component: Other
   Product: Mesa

mesa: 314ccf69016d0025ce25113cc448159a3b10 (master)

$ ./bin/glean -t fbo --quick
GL_EXT_framebuffer_object is supported
GL_ARB_framebuffer_object is supported
  depth = 0, stencil = 0
  (0, 28) = [0.00, 0.00, 0.00], is expected to be[1.00,
0.00, 0.00]
FAILURE: Render to single texture failed (at tfbo.cpp:849)
  mode = 0
  depth = 0, stencil = 0
  (0, 28) = [0.00, 0.00, 0.00], is expected to be[1.00,
0.00, 0.00]
FAILURE: Render to multi texture failed (at tfbo.cpp:1051)
  depth = 1, stencil = 0
  (0, 28) = [0.00, 0.00, 0.00], is expected to be[1.00,
1.00, 1.00]
FAILURE: Render to depth texture failed (at tfbo.cpp:1154)
fbo:  FAIL rgba8, db, z24, s8, win+pmap, id 33
3 tests passed, 3 tests failed.

a43b49dfb13dc7e6d2d6d7ceee892077038d7102 is the first bad commit
commit a43b49dfb13dc7e6d2d6d7ceee892077038d7102
Author: Dave Airlie 
Date:   Wed Nov 13 12:53:52 2013 +1000

mesa/swrast: fix inverted front buffer rendering with old-school swrast

I've no idea when this broke, but we have some people who wanted it fixed,
so here's my attempt.

reproducer, run readpix with swrast hit f, or run trival tri -sb things are
upside down, after this patch they aren't.

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

Cc: "
Signed-off-by: Dave Airlie 

:04 04 70e437e84fa67556a6469a8bf75277a6ec07e8a6
a307a4bc1dcb80aae42897ce27b7771dd8760f4f Msrc
bisect run success

-- 
You are receiving this mail because:
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] glsl: Remove unreachable error message

[Ian Romanick]

On 11/20/2013 03:41 AM, Timothy Arceri wrote:
> Left over from bug #34376.

I think this shader hits this error message:

#version 120

int x[];

void foo() { x[3] = 2; }

int x[] = int[2](1,2);

do_assignment is also used for initializers.  Initializers can be used
to (explicitly) size arrays, and arrays declared without an explicit
size can be redeclared with an explicit size.

> Signed-off-by: Timothy Arceri 
> ---
>  src/glsl/ast_to_hir.cpp | 7 ---
>  1 file changed, 7 deletions(-)
> 
> diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
> index 76b256c..adf10a0 100644
> --- a/src/glsl/ast_to_hir.cpp
> +++ b/src/glsl/ast_to_hir.cpp
> @@ -813,13 +813,6 @@ do_assignment(exec_list *instructions, struct 
> _mesa_glsl_parse_state *state,
>  
>assert(var != NULL);
>  
> -  if (var->max_array_access >= unsigned(rhs->type->array_size())) {
> - /* FINISHME: This should actually log the location of the RHS. */
> - _mesa_glsl_error(& lhs_loc, state, "array size must be > %u due to "
> -  "previous access",
> -  var->max_array_access);
> -  }
> -
>var->type = glsl_type::get_array_instance(lhs->type->element_type(),
>  rhs->type->array_size());
>d->type = var->type;
> 

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

Re: [Mesa-dev] [PATCH] mesa: reduce memory used for short display lists

[Regis Perdreau]

unsubscribe

2013/12/4 Ian Romanick :
> On 11/24/2013 08:00 AM, Brian Paul wrote:
>> From: Brian Paul 
>>
>> Display lists allocate memory in chunks of 256 tokens (1KB) at a time.
>> If an app creates many short display lists or uses glXUseXFont() this
>> can waste quite a bit of memory.
>>
>> This patch uses realloc() to trim short lists and reduce the memory
>> used.
>>
>> Also, null/zero-out some list construction fields in _mesa_EndList().
>
> Reviewed-by: Ian Romanick 
>
>> ---
>>  src/mesa/main/dlist.c |   35 +++
>>  1 file changed, 35 insertions(+)
>>
>> diff --git a/src/mesa/main/dlist.c b/src/mesa/main/dlist.c
>> index d1e2035..cb40ff4 100644
>> --- a/src/mesa/main/dlist.c
>> +++ b/src/mesa/main/dlist.c
>> @@ -1067,6 +1067,37 @@ alloc_instruction(struct gl_context *ctx, OpCode 
>> opcode, GLuint nparams)
>>  }
>>
>>
>> +/**
>> + * Called by EndList to try to reduce memory used for the list.
>> + */
>> +static void
>> +trim_list(struct gl_context *ctx)
>> +{
>> +   /* If the list we're ending only has one allocated block of nodes/tokens
>> +* and its size isn't a full block size, realloc the block to use less
>> +* memory.  This is important for apps that create many small display
>> +* lists and apps that use glXUseXFont (many lists each containing one
>> +* glBitmap call).
>> +* Note: we currently only trim display lists that allocated one block
>> +* of tokens.  That hits the short list case which is what we're mainly
>> +* concerned with.  Trimming longer lists would involve traversing the
>> +* linked list of blocks.
>> +*/
>> +   struct gl_dlist_state *list = &ctx->ListState;
>> +
>> +   if ((list->CurrentList->Head == list->CurrentBlock) &&
>> +   (list->CurrentPos < BLOCK_SIZE)) {
>> +  /* There's only one block and it's not full, so realloc */
>> +  GLuint newSize = list->CurrentPos * sizeof(Node);
>> +  list->CurrentList->Head =
>> +  list->CurrentBlock = realloc(list->CurrentBlock, newSize);
>> +  if (!list->CurrentBlock) {
>> + _mesa_error(ctx, GL_OUT_OF_MEMORY, "glEndList");
>> +  }
>> +   }
>> +}
>> +
>> +
>>
>>  /*
>>   * Display List compilation functions
>> @@ -8242,6 +8273,8 @@ _mesa_EndList(void)
>>
>> (void) alloc_instruction(ctx, OPCODE_END_OF_LIST, 0);
>>
>> +   trim_list(ctx);
>> +
>> /* Destroy old list, if any */
>> destroy_list(ctx, ctx->ListState.CurrentList->Name);
>>
>> @@ -8255,6 +8288,8 @@ _mesa_EndList(void)
>>mesa_print_display_list(ctx->ListState.CurrentList->Name);
>>
>> ctx->ListState.CurrentList = NULL;
>> +   ctx->ListState.CurrentBlock = NULL;
>> +   ctx->ListState.CurrentPos = 0;
>> ctx->ExecuteFlag = GL_TRUE;
>> ctx->CompileFlag = GL_FALSE;
>>
>>
>
> ___
> 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] mesa: reduce memory used for short display lists

[Ian Romanick]

On 11/24/2013 08:00 AM, Brian Paul wrote:
> From: Brian Paul 
> 
> Display lists allocate memory in chunks of 256 tokens (1KB) at a time.
> If an app creates many short display lists or uses glXUseXFont() this
> can waste quite a bit of memory.
> 
> This patch uses realloc() to trim short lists and reduce the memory
> used.
> 
> Also, null/zero-out some list construction fields in _mesa_EndList().

Reviewed-by: Ian Romanick 

> ---
>  src/mesa/main/dlist.c |   35 +++
>  1 file changed, 35 insertions(+)
> 
> diff --git a/src/mesa/main/dlist.c b/src/mesa/main/dlist.c
> index d1e2035..cb40ff4 100644
> --- a/src/mesa/main/dlist.c
> +++ b/src/mesa/main/dlist.c
> @@ -1067,6 +1067,37 @@ alloc_instruction(struct gl_context *ctx, OpCode 
> opcode, GLuint nparams)
>  }
>  
>  
> +/**
> + * Called by EndList to try to reduce memory used for the list.
> + */
> +static void
> +trim_list(struct gl_context *ctx)
> +{
> +   /* If the list we're ending only has one allocated block of nodes/tokens
> +* and its size isn't a full block size, realloc the block to use less
> +* memory.  This is important for apps that create many small display
> +* lists and apps that use glXUseXFont (many lists each containing one
> +* glBitmap call).
> +* Note: we currently only trim display lists that allocated one block
> +* of tokens.  That hits the short list case which is what we're mainly
> +* concerned with.  Trimming longer lists would involve traversing the
> +* linked list of blocks.
> +*/
> +   struct gl_dlist_state *list = &ctx->ListState;
> +
> +   if ((list->CurrentList->Head == list->CurrentBlock) &&
> +   (list->CurrentPos < BLOCK_SIZE)) {
> +  /* There's only one block and it's not full, so realloc */
> +  GLuint newSize = list->CurrentPos * sizeof(Node);
> +  list->CurrentList->Head =
> +  list->CurrentBlock = realloc(list->CurrentBlock, newSize);
> +  if (!list->CurrentBlock) {
> + _mesa_error(ctx, GL_OUT_OF_MEMORY, "glEndList");
> +  }
> +   }
> +}
> +
> +
>  
>  /*
>   * Display List compilation functions
> @@ -8242,6 +8273,8 @@ _mesa_EndList(void)
>  
> (void) alloc_instruction(ctx, OPCODE_END_OF_LIST, 0);
>  
> +   trim_list(ctx);
> +
> /* Destroy old list, if any */
> destroy_list(ctx, ctx->ListState.CurrentList->Name);
>  
> @@ -8255,6 +8288,8 @@ _mesa_EndList(void)
>mesa_print_display_list(ctx->ListState.CurrentList->Name);
>  
> ctx->ListState.CurrentList = NULL;
> +   ctx->ListState.CurrentBlock = NULL;
> +   ctx->ListState.CurrentPos = 0;
> ctx->ExecuteFlag = GL_TRUE;
> ctx->CompileFlag = GL_FALSE;
>  
> 

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

[Mesa-dev] [Bug 72230] Unable to extract MesaLib-10.0.0.tar.{gz, bz2} with bsdtar

[bugzilla-daemon]

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

--- Comment #6 from Ian Romanick  ---
(In reply to comment #5)
> (In reply to comment #4)
> > Would it be possible to provide updated tarballs including this fix?
> 
> Doesn't seem worth it.

...because 10.0.1 will be along shortly.

-- 
You are receiving this mail because:
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] glsl: Remove unreachable error message

[Timothy Arceri]

Ping.

Just to clarify unsized arrays cannot be assigned so
var->max_array_access will always be 0 as redecorations are already
handled before this point by get_variable_being_redeclared()

This patch is needed as a cleanup for ARB_arrays_of_arrays work. I have
run all glsl piglit tests without regression.

Tim

On Wed, 2013-11-20 at 22:41 +1100, Timothy Arceri wrote:
> Left over from bug #34376.
> 
> Signed-off-by: Timothy Arceri 
> ---
>  src/glsl/ast_to_hir.cpp | 7 ---
>  1 file changed, 7 deletions(-)
> 
> diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
> index 76b256c..adf10a0 100644
> --- a/src/glsl/ast_to_hir.cpp
> +++ b/src/glsl/ast_to_hir.cpp
> @@ -813,13 +813,6 @@ do_assignment(exec_list *instructions, struct 
> _mesa_glsl_parse_state *state,
>  
>assert(var != NULL);
>  
> -  if (var->max_array_access >= unsigned(rhs->type->array_size())) {
> - /* FINISHME: This should actually log the location of the RHS. */
> - _mesa_glsl_error(& lhs_loc, state, "array size must be > %u due to "
> -  "previous access",
> -  var->max_array_access);
> -  }
> -
>var->type = glsl_type::get_array_instance(lhs->type->element_type(),
>  rhs->type->array_size());
>d->type = var->type;


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

Re: [Mesa-dev] [PATCH 03/15] i965/cfg: Rework to make IF & ELSE blocks flow into ENDIF.

[Eric Anholt]

Matt Turner  writes:

> Previously we made the basic block following an ENDIF instruction a
> successor of the basic blocks ending with IF and ELSE. The PRM says that
> IF and ELSE instructions jump *to* the ENDIF, rather than over it.
>
> This should be immaterial to dataflow analysis, except for if, break,
> endif sequences:
>
>START B1 <-B0 <-B9
> 0x0100: cmp.g.f0(8) nullg15<8,8,1>F g4<0,1,0>F
> 0x0110: (+f0) if(8) 0 0 null0xUD
>END B1 ->B2 ->B4
>START B2 <-B1
>break
> 0x0120: break(8) 0 0null0D
>END B2 ->B10
>START B3
> 0x0130: endif(8) 2  null0x0002UD
>END B3 ->B4
>
> The ENDIF block would have no parents, so dataflow analysis would
> generate incorrect results, preventing copy propagation from eliminating
> some instructions.
>
> This patch changes the CFG to make ENDIF start rather than end basic
> blocks, so that it can be the jump target of the IF and ELSE
> instructions.
>
> It helps three programs (including two fs8/fs16 pairs) and hurts a
> single fs8/fs16 pair.
>
> total instructions in shared programs: 1561126 -> 1561066 (-0.00%)
> instructions in affected programs: 983 -> 923 (-6.10%)
>
> More importantly, it allows copy propagation to handle more cases.
> Disabling the register_coalesce() pass before this patch hurts 58
> programs, while afterward it only hurts 11 programs.
> ---
>  src/mesa/drivers/dri/i965/brw_cfg.cpp | 46 
> +--
>  1 file changed, 33 insertions(+), 13 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_cfg.cpp 
> b/src/mesa/drivers/dri/i965/brw_cfg.cpp
> index 548b458..83c3c34 100644
> --- a/src/mesa/drivers/dri/i965/brw_cfg.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_cfg.cpp
> @@ -133,10 +133,7 @@ cfg_t::create(void *parent_mem_ctx, exec_list 
> *instructions)
>  
>cur_if = cur;
>cur_else = NULL;
> -  /* Set up the block just after the endif.  Don't know when exactly
> -   * it will start, yet.
> -   */
> -  cur_endif = new_block();
> + cur_endif = NULL;
>  
>/* Set up our immediately following block, full of "then"
> * instructions.
> @@ -149,26 +146,49 @@ cfg_t::create(void *parent_mem_ctx, exec_list 
> *instructions)
>break;
>  
>case BRW_OPCODE_ELSE:
> -  cur->add_successor(mem_ctx, cur_endif);
> + cur_else = cur;
>  
>next = new_block();
>next->start = (backend_instruction *)inst->next;
>cur_if->add_successor(mem_ctx, next);
> -  cur_else = next;
>  
>set_next_block(next);
>break;
>  
>case BRW_OPCODE_ENDIF: {
> -  cur_endif->start = (backend_instruction *)inst->next;
> -  cur->add_successor(mem_ctx, cur_endif);
> -  set_next_block(cur_endif);
> + backend_instruction *prev_inst = (backend_instruction *)inst->prev;
> + switch (prev_inst->opcode) {
> + case BRW_OPCODE_IF:
> + case BRW_OPCODE_ELSE:
> + case BRW_OPCODE_WHILE:
> + case BRW_OPCODE_DO:
> + case BRW_OPCODE_BREAK:
> + case BRW_OPCODE_CONTINUE:
> +/* New block was just created; use it. */
> +cur_endif = cur;
> +break;

Instead of the opcode switch for this test, couldn't you just do "if
cur->start == inst"?

Other than that, this series is:

Reviewed-by: Eric Anholt 


pgpsmYPhILiyM.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 72230] Unable to extract MesaLib-10.0.0.tar.{gz, bz2} with bsdtar

[bugzilla-daemon]

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

--- Comment #5 from Matt Turner  ---
(In reply to comment #4)
> Would it be possible to provide updated tarballs including this fix?

Doesn't seem worth it.

-- 
You are receiving this mail because:
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 7/7] i965/gen7+: Implement fast color clears for MSAA buffers.

[Chris Forbes]

+  } else {
+ /* From the Ivy Bridge PRM, Vol2 Part1 11.7 "MCS Buffer for Render
+  * Target(s)", beneath the "MSAA Compression" bugget (p326):

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

Re: [Mesa-dev] [PATCH] radeonsi: Remove some stale XXX / FIXME comments

[Marek Olšák]

Reviewed-by: Marek Olšák 

Marek

On Wed, Dec 4, 2013 at 5:38 AM, Michel Dänzer  wrote:
> From: Michel Dänzer 
>
> Signed-off-by: Michel Dänzer 
> ---
>  src/gallium/drivers/radeonsi/radeonsi_pipe.c   | 1 -
>  src/gallium/drivers/radeonsi/radeonsi_shader.c | 5 +
>  2 files changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/src/gallium/drivers/radeonsi/radeonsi_pipe.c 
> b/src/gallium/drivers/radeonsi/radeonsi_pipe.c
> index 0242a03..4aaa88f 100644
> --- a/src/gallium/drivers/radeonsi/radeonsi_pipe.c
> +++ b/src/gallium/drivers/radeonsi/radeonsi_pipe.c
> @@ -392,7 +392,6 @@ static int r600_get_param(struct pipe_screen* pscreen, 
> enum pipe_cap param)
>
> /* Render targets. */
> case PIPE_CAP_MAX_RENDER_TARGETS:
> -   /* FIXME some r6xx are buggy and can only do 4 */
> return 8;
>
> case PIPE_CAP_MAX_VIEWPORTS:
> diff --git a/src/gallium/drivers/radeonsi/radeonsi_shader.c 
> b/src/gallium/drivers/radeonsi/radeonsi_shader.c
> index 96cc1aa..88825bb 100644
> --- a/src/gallium/drivers/radeonsi/radeonsi_shader.c
> +++ b/src/gallium/drivers/radeonsi/radeonsi_shader.c
> @@ -281,7 +281,6 @@ static void declare_input_fs(
> attr_number = lp_build_const_int32(gallivm,
>
> shader->input[input_index].param_offset);
>
> -   /* XXX: Handle all possible interpolation modes */
> switch (decl->Interp.Interpolate) {
> case TGSI_INTERPOLATE_COLOR:
> if (si_shader_ctx->shader->key.ps.flatshade) {
> @@ -875,7 +874,7 @@ static void si_llvm_emit_streamout(struct 
> si_shader_context *shader)
> lp_build_endif(&if_ctx);
>  }
>
> -/* XXX: This is partially implemented for VS only at this point.  It is not 
> complete */
> +
>  static void si_llvm_emit_epilogue(struct lp_build_tgsi_context * bld_base)
>  {
> struct si_shader_context * si_shader_ctx = 
> si_shader_context(bld_base);
> @@ -1222,8 +1221,6 @@ handle_semantic:
>
> LLVMVoidTypeInContext(base->gallivm->context),
>last_args, 9);
> }
> -/* XXX: Look up what this function does */
> -/* ctx->shader->output[i].spi_sid = 
> r600_spi_sid(&ctx->shader->output[i]);*/
>  }
>
>  static const struct lp_build_tgsi_action txf_action;
> --
> 1.8.4.3
>
> ___
> 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] r600/llvm: Allow arbitrary amount of temps in tgsi to llvm

[Tom Stellard]

On Wed, Dec 04, 2013 at 03:11:16PM +0100, Vincent Lejeune wrote:
> ---
>  src/gallium/drivers/radeon/radeon_llvm.h   |  5 +++
>  .../drivers/radeon/radeon_setup_tgsi_llvm.c| 41 
> +++---
>  2 files changed, 42 insertions(+), 4 deletions(-)
> 
> diff --git a/src/gallium/drivers/radeon/radeon_llvm.h 
> b/src/gallium/drivers/radeon/radeon_llvm.h
> index 2cab6b0..6d84f44 100644
> --- a/src/gallium/drivers/radeon/radeon_llvm.h
> +++ b/src/gallium/drivers/radeon/radeon_llvm.h
> @@ -112,6 +112,11 @@ struct radeon_llvm_context {
>   LLVMValueRef outputs[RADEON_LLVM_MAX_OUTPUTS][TGSI_NUM_CHANNELS];
>   unsigned output_reg_count;
>  
> + /**
> +  * @brief system_values
> +  */

This comment is a little confusing, is it meant for the system_values
array?

> + LLVMValueRef *temps;
> + unsigned temps_count;
>   LLVMValueRef system_values[RADEON_LLVM_MAX_SYSTEM_VALUES];
>  
>   /*=== Private Members ===*/
> diff --git a/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c 
> b/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
> index 3bb01ec..c897b03 100644
> --- a/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
> +++ b/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
> @@ -184,7 +184,11 @@ emit_fetch(
>   break;
>  
>   case TGSI_FILE_TEMPORARY:
> - ptr = lp_get_temp_ptr_soa(bld, reg->Register.Index, swizzle);
> + if (false) {
> + ptr = lp_get_temp_ptr_soa(bld, reg->Register.Index, 
> swizzle);
> + break;
> + }

This is dead code.

> + ptr = ctx->temps[reg->Register.Index * TGSI_NUM_CHANNELS + 
> swizzle];
>   result = LLVMBuildLoad(builder, ptr, "");
>   break;
>  
> @@ -200,6 +204,13 @@ emit_fetch(
>   return bitcast(bld_base, type, result);
>  }
>  
> +static bool uses_temp_indirect_addressing(
> + struct lp_build_tgsi_context *bld_base)
> +{
> + struct lp_build_tgsi_soa_context *bld = lp_soa_context(bld_base);
> + return !(bld->indirect_files & (1 << TGSI_FILE_TEMPORARY));
> +}
> +
>  static LLVMValueRef fetch_system_value(
>   struct lp_build_tgsi_context * bld_base,
>   const struct tgsi_full_src_register *reg,
> @@ -234,7 +245,22 @@ static void emit_declaration(
>   case TGSI_FILE_TEMPORARY:
>   if (decl->Declaration.Array && decl->Array.ArrayID <= 
> RADEON_LLVM_MAX_ARRAYS)
>   ctx->arrays[decl->Array.ArrayID - 1] = decl->Range;
> - lp_emit_declaration_soa(bld_base, decl);
> + if (uses_temp_indirect_addressing(bld_base)) {
> + lp_emit_declaration_soa(bld_base, decl);
> + break;
> + }
> + unsigned first = decl->Range.First, last = decl->Range.Last;

You are mixing declarations and code here.

> + if (!ctx->temps_count) {
> + ctx->temps_count = 
> bld_base->info->file_max[TGSI_FILE_TEMPORARY] + 1;
> + ctx->temps = MALLOC(TGSI_NUM_CHANNELS * 
> ctx->temps_count * sizeof(LLVMValueRef));
> + }
> + for (unsigned idx = first; idx <= last; idx++) {
> + for (unsigned i = 0; i < TGSI_NUM_CHANNELS; i++) {
> + ctx->temps[idx * TGSI_NUM_CHANNELS + i] =
> + lp_build_alloca(bld_base->base.gallivm, 
> bld_base->base.vec_type,
> + "temp");
> + }
> + }
>   break;
>  
>   case TGSI_FILE_INPUT:
> @@ -284,6 +310,7 @@ emit_store(
>   const struct tgsi_opcode_info * info,
>   LLVMValueRef dst[4])
>  {
> + struct radeon_llvm_context * ctx = radeon_llvm_context(bld_base);
>   struct lp_build_tgsi_soa_context *bld = lp_soa_context(bld_base);
>   struct gallivm_state *gallivm = bld->bld_base.base.gallivm;
>   struct lp_build_context base = bld->bld_base.base;
> @@ -359,7 +386,10 @@ emit_store(
>   break;
>  
>   case TGSI_FILE_TEMPORARY:
> - temp_ptr = lp_get_temp_ptr_soa(bld, i + 
> range.First, chan_index);
> + if 
> (uses_temp_indirect_addressing(bld_base))
> + temp_ptr = 
> lp_get_temp_ptr_soa(bld, i + range.First, chan_index);
> + else
> + temp_ptr = ctx->temps[(i + 
> range.First) * TGSI_NUM_CHANNELS + chan_index];
>   break;
>  
>   default:
> @@ -377,7 +407,9 @@ emit_store(
>   break;
>  
>   case TGSI_FILE_TEMPORARY:
> - temp_ptr = lp_get_temp_ptr_soa(bld, 
> reg->Register.Index, chan_index);
> + 

Re: [Mesa-dev] [PATCH 1/2] r300/compiler/tests: Fix segfault

[Alex Deucher]

On Mon, Dec 2, 2013 at 9:46 PM, Tom Stellard  wrote:
> From: Tom Stellard 
>
> CC: "9.2" "10.0" 

For the series:

Reviewed-by: Alex Deucher 

> ---
>  .../r300/compiler/tests/radeon_compiler_regalloc_tests.c  | 11 
> +--
>  1 file changed, 5 insertions(+), 6 deletions(-)
>
> diff --git 
> a/src/gallium/drivers/r300/compiler/tests/radeon_compiler_regalloc_tests.c 
> b/src/gallium/drivers/r300/compiler/tests/radeon_compiler_regalloc_tests.c
> index 511596c..5306b08 100644
> --- a/src/gallium/drivers/r300/compiler/tests/radeon_compiler_regalloc_tests.c
> +++ b/src/gallium/drivers/r300/compiler/tests/radeon_compiler_regalloc_tests.c
> @@ -79,14 +79,13 @@ static void test_runner_rc_regalloc(
>
>  static void tex_1d_swizzle(struct test_result *result)
>  {
> -   struct radeon_compiler c;
> +   struct r300_fragment_program_compiler c;
>
> -   init_compiler(&c, RC_FRAGMENT_PROGRAM, 0, 0);
> -   struct r300_fragment_program_compiler *cc =
> -   (struct r300_fragment_program_compiler*)&c;
> -   cc->AllocateHwInputs = dummy_allocate_hw_inputs;
> +   memset(&c, 0, sizeof(c));
> +   init_compiler(&c.Base, RC_FRAGMENT_PROGRAM, 0, 0);
> +   c.AllocateHwInputs = dummy_allocate_hw_inputs;
>
> -   test_runner_rc_regalloc(result, &c, "regalloc_tex_1d_swizzle.test");
> +   test_runner_rc_regalloc(result, &c.Base, 
> "regalloc_tex_1d_swizzle.test");
>  }
>
>  unsigned radeon_compiler_regalloc_run_tests()
> --
> 1.8.1.5
>
> ___
> 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] mesa: reduce memory used for short display lists

[Brian Paul]

On Sun, Nov 24, 2013 at 9:00 AM, Brian Paul  wrote:

> From: Brian Paul 
>
> Display lists allocate memory in chunks of 256 tokens (1KB) at a time.
> If an app creates many short display lists or uses glXUseXFont() this
> can waste quite a bit of memory.
>
> This patch uses realloc() to trim short lists and reduce the memory
> used.
>
> Also, null/zero-out some list construction fields in _mesa_EndList().
> ---
>  src/mesa/main/dlist.c |   35 +++
>  1 file changed, 35 insertions(+)
>
> diff --git a/src/mesa/main/dlist.c b/src/mesa/main/dlist.c
> index d1e2035..cb40ff4 100644
> --- a/src/mesa/main/dlist.c
> +++ b/src/mesa/main/dlist.c
> @@ -1067,6 +1067,37 @@ alloc_instruction(struct gl_context *ctx, OpCode
> opcode, GLuint nparams)
>  }
>
>
> +/**
> + * Called by EndList to try to reduce memory used for the list.
> + */
> +static void
> +trim_list(struct gl_context *ctx)
> +{
> +   /* If the list we're ending only has one allocated block of
> nodes/tokens
> +* and its size isn't a full block size, realloc the block to use less
> +* memory.  This is important for apps that create many small display
> +* lists and apps that use glXUseXFont (many lists each containing one
> +* glBitmap call).
> +* Note: we currently only trim display lists that allocated one block
> +* of tokens.  That hits the short list case which is what we're mainly
> +* concerned with.  Trimming longer lists would involve traversing the
> +* linked list of blocks.
> +*/
> +   struct gl_dlist_state *list = &ctx->ListState;
> +
> +   if ((list->CurrentList->Head == list->CurrentBlock) &&
> +   (list->CurrentPos < BLOCK_SIZE)) {
> +  /* There's only one block and it's not full, so realloc */
> +  GLuint newSize = list->CurrentPos * sizeof(Node);
> +  list->CurrentList->Head =
> +  list->CurrentBlock = realloc(list->CurrentBlock, newSize);
> +  if (!list->CurrentBlock) {
> + _mesa_error(ctx, GL_OUT_OF_MEMORY, "glEndList");
> +  }
> +   }
> +}
> +
> +
>
>  /*
>   * Display List compilation functions
> @@ -8242,6 +8273,8 @@ _mesa_EndList(void)
>
> (void) alloc_instruction(ctx, OPCODE_END_OF_LIST, 0);
>
> +   trim_list(ctx);
> +
> /* Destroy old list, if any */
> destroy_list(ctx, ctx->ListState.CurrentList->Name);
>
> @@ -8255,6 +8288,8 @@ _mesa_EndList(void)
>mesa_print_display_list(ctx->ListState.CurrentList->Name);
>
> ctx->ListState.CurrentList = NULL;
> +   ctx->ListState.CurrentBlock = NULL;
> +   ctx->ListState.CurrentPos = 0;
> ctx->ExecuteFlag = GL_TRUE;
> ctx->CompileFlag = GL_FALSE;
>
> --
> 1.7.9.5
>
>
Ping.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/9] mesa: have old glColorTable functions generate GL_INVALID_OPERATION

[Ian Romanick]

On 12/04/2013 06:35 AM, Brian Paul wrote:
> On 11/23/2013 05:00 PM, Ian Romanick wrote:
>> Patches 1 through 6 and 9 are
>>
>> Reviewed-by: Ian Romanick .
>>
>> I actually wonder if in non-debug builds we should use function aliasing
>> (or similar) to use generic_noop for all these functions that just set
>> GL_INVALID_OPERATION.  That might be a good newbie project. :)
>>
>> I want to look at 7 and 8 a bit closer.
> 
> Ping.

Thanks for the reminder.  I had completely forgotten.  I don't care for
the 'n + POINTER_DWORDS' business in patch 7, but I don't have a better
suggestion either.  I don't think adding a second parameter to
alloc_instruction would be better.  /shrug/

Reviewed-by: Ian Romanick 

> -Brian

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

[Mesa-dev] [Bug 70766] Run-time link error in swrast_dri.so

[bugzilla-daemon]

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

--- Comment #5 from Andreas Hartmetz  ---
For completeness because I forgot to say it explicitly: Yes, I'm using cmake.
Also hello LLVM, if anybody sees this... that patch is important.

-- 
You are receiving this mail because:
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] radeonsi: Remove some stale XXX / FIXME comments

[Mario Rugiero]

Oh, OK then. I thought they maybe were there for a reason other than having
used the other driver as a base.


2013/12/4 Alex Deucher 

> On Wed, Dec 4, 2013 at 11:20 AM, Mario Rugiero  wrote:
> > May I ask if those fixmes are actually fixed? Otherwise, wouldn't it be
> > wiser to keep them pointing out this problems?
>
> They are no longer relevant or we'd leave them in.  The first hunk,
> for example, was just a copy and paste leftover from r600g.
>
> Alex
>
> >
> >
> > 2013/12/4 Alex Deucher 
> >>
> >> On Tue, Dec 3, 2013 at 11:38 PM, Michel Dänzer 
> wrote:
> >> > From: Michel Dänzer 
> >> >
> >> > Signed-off-by: Michel Dänzer 
> >>
> >> Reviewed-by: Alex Deucher 
> >>
> >>
> >> > ---
> >> >  src/gallium/drivers/radeonsi/radeonsi_pipe.c   | 1 -
> >> >  src/gallium/drivers/radeonsi/radeonsi_shader.c | 5 +
> >> >  2 files changed, 1 insertion(+), 5 deletions(-)
> >> >
> >> > diff --git a/src/gallium/drivers/radeonsi/radeonsi_pipe.c
> >> > b/src/gallium/drivers/radeonsi/radeonsi_pipe.c
> >> > index 0242a03..4aaa88f 100644
> >> > --- a/src/gallium/drivers/radeonsi/radeonsi_pipe.c
> >> > +++ b/src/gallium/drivers/radeonsi/radeonsi_pipe.c
> >> > @@ -392,7 +392,6 @@ static int r600_get_param(struct pipe_screen*
> >> > pscreen, enum pipe_cap param)
> >> >
> >> > /* Render targets. */
> >> > case PIPE_CAP_MAX_RENDER_TARGETS:
> >> > -   /* FIXME some r6xx are buggy and can only do 4 */
> >> > return 8;
> >> >
> >> > case PIPE_CAP_MAX_VIEWPORTS:
> >> > diff --git a/src/gallium/drivers/radeonsi/radeonsi_shader.c
> >> > b/src/gallium/drivers/radeonsi/radeonsi_shader.c
> >> > index 96cc1aa..88825bb 100644
> >> > --- a/src/gallium/drivers/radeonsi/radeonsi_shader.c
> >> > +++ b/src/gallium/drivers/radeonsi/radeonsi_shader.c
> >> > @@ -281,7 +281,6 @@ static void declare_input_fs(
> >> > attr_number = lp_build_const_int32(gallivm,
> >> >
> >> > shader->input[input_index].param_offset);
> >> >
> >> > -   /* XXX: Handle all possible interpolation modes */
> >> > switch (decl->Interp.Interpolate) {
> >> > case TGSI_INTERPOLATE_COLOR:
> >> > if (si_shader_ctx->shader->key.ps.flatshade) {
> >> > @@ -875,7 +874,7 @@ static void si_llvm_emit_streamout(struct
> >> > si_shader_context *shader)
> >> > lp_build_endif(&if_ctx);
> >> >  }
> >> >
> >> > -/* XXX: This is partially implemented for VS only at this point.  It
> is
> >> > not complete */
> >> > +
> >> >  static void si_llvm_emit_epilogue(struct lp_build_tgsi_context *
> >> > bld_base)
> >> >  {
> >> > struct si_shader_context * si_shader_ctx =
> >> > si_shader_context(bld_base);
> >> > @@ -1222,8 +1221,6 @@ handle_semantic:
> >> >
> >> > LLVMVoidTypeInContext(base->gallivm->context),
> >> >last_args, 9);
> >> > }
> >> > -/* XXX: Look up what this function does */
> >> > -/* ctx->shader->output[i].spi_sid =
> >> > r600_spi_sid(&ctx->shader->output[i]);*/
> >> >  }
> >> >
> >> >  static const struct lp_build_tgsi_action txf_action;
> >> > --
> >> > 1.8.4.3
> >> >
> >> > ___
> >> > 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

Re: [Mesa-dev] [PATCH] radeonsi: Remove some stale XXX / FIXME comments

[Alex Deucher]

On Wed, Dec 4, 2013 at 11:20 AM, Mario Rugiero  wrote:
> May I ask if those fixmes are actually fixed? Otherwise, wouldn't it be
> wiser to keep them pointing out this problems?

They are no longer relevant or we'd leave them in.  The first hunk,
for example, was just a copy and paste leftover from r600g.

Alex

>
>
> 2013/12/4 Alex Deucher 
>>
>> On Tue, Dec 3, 2013 at 11:38 PM, Michel Dänzer  wrote:
>> > From: Michel Dänzer 
>> >
>> > Signed-off-by: Michel Dänzer 
>>
>> Reviewed-by: Alex Deucher 
>>
>>
>> > ---
>> >  src/gallium/drivers/radeonsi/radeonsi_pipe.c   | 1 -
>> >  src/gallium/drivers/radeonsi/radeonsi_shader.c | 5 +
>> >  2 files changed, 1 insertion(+), 5 deletions(-)
>> >
>> > diff --git a/src/gallium/drivers/radeonsi/radeonsi_pipe.c
>> > b/src/gallium/drivers/radeonsi/radeonsi_pipe.c
>> > index 0242a03..4aaa88f 100644
>> > --- a/src/gallium/drivers/radeonsi/radeonsi_pipe.c
>> > +++ b/src/gallium/drivers/radeonsi/radeonsi_pipe.c
>> > @@ -392,7 +392,6 @@ static int r600_get_param(struct pipe_screen*
>> > pscreen, enum pipe_cap param)
>> >
>> > /* Render targets. */
>> > case PIPE_CAP_MAX_RENDER_TARGETS:
>> > -   /* FIXME some r6xx are buggy and can only do 4 */
>> > return 8;
>> >
>> > case PIPE_CAP_MAX_VIEWPORTS:
>> > diff --git a/src/gallium/drivers/radeonsi/radeonsi_shader.c
>> > b/src/gallium/drivers/radeonsi/radeonsi_shader.c
>> > index 96cc1aa..88825bb 100644
>> > --- a/src/gallium/drivers/radeonsi/radeonsi_shader.c
>> > +++ b/src/gallium/drivers/radeonsi/radeonsi_shader.c
>> > @@ -281,7 +281,6 @@ static void declare_input_fs(
>> > attr_number = lp_build_const_int32(gallivm,
>> >
>> > shader->input[input_index].param_offset);
>> >
>> > -   /* XXX: Handle all possible interpolation modes */
>> > switch (decl->Interp.Interpolate) {
>> > case TGSI_INTERPOLATE_COLOR:
>> > if (si_shader_ctx->shader->key.ps.flatshade) {
>> > @@ -875,7 +874,7 @@ static void si_llvm_emit_streamout(struct
>> > si_shader_context *shader)
>> > lp_build_endif(&if_ctx);
>> >  }
>> >
>> > -/* XXX: This is partially implemented for VS only at this point.  It is
>> > not complete */
>> > +
>> >  static void si_llvm_emit_epilogue(struct lp_build_tgsi_context *
>> > bld_base)
>> >  {
>> > struct si_shader_context * si_shader_ctx =
>> > si_shader_context(bld_base);
>> > @@ -1222,8 +1221,6 @@ handle_semantic:
>> >
>> > LLVMVoidTypeInContext(base->gallivm->context),
>> >last_args, 9);
>> > }
>> > -/* XXX: Look up what this function does */
>> > -/* ctx->shader->output[i].spi_sid =
>> > r600_spi_sid(&ctx->shader->output[i]);*/
>> >  }
>> >
>> >  static const struct lp_build_tgsi_action txf_action;
>> > --
>> > 1.8.4.3
>> >
>> > ___
>> > 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

Re: [Mesa-dev] [PATCH] radeonsi: Remove some stale XXX / FIXME comments

[Mario Rugiero]

May I ask if those fixmes are actually fixed? Otherwise, wouldn't it be
wiser to keep them pointing out this problems?


2013/12/4 Alex Deucher 

> On Tue, Dec 3, 2013 at 11:38 PM, Michel Dänzer  wrote:
> > From: Michel Dänzer 
> >
> > Signed-off-by: Michel Dänzer 
>
> Reviewed-by: Alex Deucher 
>
>
> > ---
> >  src/gallium/drivers/radeonsi/radeonsi_pipe.c   | 1 -
> >  src/gallium/drivers/radeonsi/radeonsi_shader.c | 5 +
> >  2 files changed, 1 insertion(+), 5 deletions(-)
> >
> > diff --git a/src/gallium/drivers/radeonsi/radeonsi_pipe.c
> b/src/gallium/drivers/radeonsi/radeonsi_pipe.c
> > index 0242a03..4aaa88f 100644
> > --- a/src/gallium/drivers/radeonsi/radeonsi_pipe.c
> > +++ b/src/gallium/drivers/radeonsi/radeonsi_pipe.c
> > @@ -392,7 +392,6 @@ static int r600_get_param(struct pipe_screen*
> pscreen, enum pipe_cap param)
> >
> > /* Render targets. */
> > case PIPE_CAP_MAX_RENDER_TARGETS:
> > -   /* FIXME some r6xx are buggy and can only do 4 */
> > return 8;
> >
> > case PIPE_CAP_MAX_VIEWPORTS:
> > diff --git a/src/gallium/drivers/radeonsi/radeonsi_shader.c
> b/src/gallium/drivers/radeonsi/radeonsi_shader.c
> > index 96cc1aa..88825bb 100644
> > --- a/src/gallium/drivers/radeonsi/radeonsi_shader.c
> > +++ b/src/gallium/drivers/radeonsi/radeonsi_shader.c
> > @@ -281,7 +281,6 @@ static void declare_input_fs(
> > attr_number = lp_build_const_int32(gallivm,
> >
>  shader->input[input_index].param_offset);
> >
> > -   /* XXX: Handle all possible interpolation modes */
> > switch (decl->Interp.Interpolate) {
> > case TGSI_INTERPOLATE_COLOR:
> > if (si_shader_ctx->shader->key.ps.flatshade) {
> > @@ -875,7 +874,7 @@ static void si_llvm_emit_streamout(struct
> si_shader_context *shader)
> > lp_build_endif(&if_ctx);
> >  }
> >
> > -/* XXX: This is partially implemented for VS only at this point.  It is
> not complete */
> > +
> >  static void si_llvm_emit_epilogue(struct lp_build_tgsi_context *
> bld_base)
> >  {
> > struct si_shader_context * si_shader_ctx =
> si_shader_context(bld_base);
> > @@ -1222,8 +1221,6 @@ handle_semantic:
> >
>  LLVMVoidTypeInContext(base->gallivm->context),
> >last_args, 9);
> > }
> > -/* XXX: Look up what this function does */
> > -/* ctx->shader->output[i].spi_sid =
> r600_spi_sid(&ctx->shader->output[i]);*/
> >  }
> >
> >  static const struct lp_build_tgsi_action txf_action;
> > --
> > 1.8.4.3
> >
> > ___
> > 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

Re: [Mesa-dev] [PATCH] radeonsi: Remove some stale XXX / FIXME comments

[Alex Deucher]

On Tue, Dec 3, 2013 at 11:38 PM, Michel Dänzer  wrote:
> From: Michel Dänzer 
>
> Signed-off-by: Michel Dänzer 

Reviewed-by: Alex Deucher 


> ---
>  src/gallium/drivers/radeonsi/radeonsi_pipe.c   | 1 -
>  src/gallium/drivers/radeonsi/radeonsi_shader.c | 5 +
>  2 files changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/src/gallium/drivers/radeonsi/radeonsi_pipe.c 
> b/src/gallium/drivers/radeonsi/radeonsi_pipe.c
> index 0242a03..4aaa88f 100644
> --- a/src/gallium/drivers/radeonsi/radeonsi_pipe.c
> +++ b/src/gallium/drivers/radeonsi/radeonsi_pipe.c
> @@ -392,7 +392,6 @@ static int r600_get_param(struct pipe_screen* pscreen, 
> enum pipe_cap param)
>
> /* Render targets. */
> case PIPE_CAP_MAX_RENDER_TARGETS:
> -   /* FIXME some r6xx are buggy and can only do 4 */
> return 8;
>
> case PIPE_CAP_MAX_VIEWPORTS:
> diff --git a/src/gallium/drivers/radeonsi/radeonsi_shader.c 
> b/src/gallium/drivers/radeonsi/radeonsi_shader.c
> index 96cc1aa..88825bb 100644
> --- a/src/gallium/drivers/radeonsi/radeonsi_shader.c
> +++ b/src/gallium/drivers/radeonsi/radeonsi_shader.c
> @@ -281,7 +281,6 @@ static void declare_input_fs(
> attr_number = lp_build_const_int32(gallivm,
>
> shader->input[input_index].param_offset);
>
> -   /* XXX: Handle all possible interpolation modes */
> switch (decl->Interp.Interpolate) {
> case TGSI_INTERPOLATE_COLOR:
> if (si_shader_ctx->shader->key.ps.flatshade) {
> @@ -875,7 +874,7 @@ static void si_llvm_emit_streamout(struct 
> si_shader_context *shader)
> lp_build_endif(&if_ctx);
>  }
>
> -/* XXX: This is partially implemented for VS only at this point.  It is not 
> complete */
> +
>  static void si_llvm_emit_epilogue(struct lp_build_tgsi_context * bld_base)
>  {
> struct si_shader_context * si_shader_ctx = 
> si_shader_context(bld_base);
> @@ -1222,8 +1221,6 @@ handle_semantic:
>
> LLVMVoidTypeInContext(base->gallivm->context),
>last_args, 9);
> }
> -/* XXX: Look up what this function does */
> -/* ctx->shader->output[i].spi_sid = 
> r600_spi_sid(&ctx->shader->output[i]);*/
>  }
>
>  static const struct lp_build_tgsi_action txf_action;
> --
> 1.8.4.3
>
> ___
> 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 1/9] mesa: have old glColorTable functions generate GL_INVALID_OPERATION

[Brian Paul]

On 11/23/2013 05:00 PM, Ian Romanick wrote:

Patches 1 through 6 and 9 are

Reviewed-by: Ian Romanick .

I actually wonder if in non-debug builds we should use function aliasing
(or similar) to use generic_noop for all these functions that just set
GL_INVALID_OPERATION.  That might be a good newbie project. :)

I want to look at 7 and 8 a bit closer.


Ping.

-Brian

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

Re: [Mesa-dev] [PATCH V2] Modified _mesa_align_free to have consistent behavior when dealing with NULL memory address.

[Brian Paul]

On 12/03/2013 09:50 PM, Siavash Eliasi wrote:

Revision 2:
- Avoiding compile error on MSVC and possible warnings on other compilers.
- Added comment regards passing NULL pointer being safe.
---
  src/mesa/main/imports.c| 14 +-
  src/mesa/math/m_matrix.c   | 13 +
  src/mesa/program/prog_parameter.c  |  3 +--
  src/mesa/state_tracker/st_cb_texture.c |  6 ++
  src/mesa/swrast/s_texture.c|  7 +++
  src/mesa/tnl/t_vertex.c|  6 ++
  src/mesa/vbo/vbo_exec_api.c|  9 -
  7 files changed, 26 insertions(+), 32 deletions(-)

diff --git a/src/mesa/main/imports.c b/src/mesa/main/imports.c
index 277e947..4afe156 100644
--- a/src/mesa/main/imports.c
+++ b/src/mesa/main/imports.c
@@ -168,6 +168,8 @@ _mesa_align_calloc(size_t bytes, unsigned long alignment)
   * \param ptr pointer to the memory to be freed.
   * The actual address to free is stored in the word immediately before the
   * address the client sees.
+ * Note that it is legal to pass NULL pointer to this function and will be
+ * handled accordingly.
   */
  void
  _mesa_align_free(void *ptr)
@@ -177,9 +179,11 @@ _mesa_align_free(void *ptr)
  #elif defined(_WIN32) && defined(_MSC_VER)
 _aligned_free(ptr);
  #else
-   void **cubbyHole = (void **) ((char *) ptr - sizeof(void *));
-   void *realAddr = *cubbyHole;
-   free(realAddr);
+   if (ptr) {
+  void **cubbyHole = (void **) ((char *) ptr - sizeof(void *));
+  void *realAddr = *cubbyHole;
+  free(realAddr);
+   }
  #endif /* defined(HAVE_POSIX_MEMALIGN) */
  }

@@ -199,8 +203,8 @@ _mesa_align_realloc(void *oldBuffer, size_t oldSize, size_t 
newSize,
 if (newBuf && oldBuffer && copySize > 0) {
memcpy(newBuf, oldBuffer, copySize);
 }
-   if (oldBuffer)
-  _mesa_align_free(oldBuffer);
+
+   _mesa_align_free(oldBuffer);
 return newBuf;
  #endif
  }
diff --git a/src/mesa/math/m_matrix.c b/src/mesa/math/m_matrix.c
index 2902315..274f969 100644
--- a/src/mesa/math/m_matrix.c
+++ b/src/mesa/math/m_matrix.c
@@ -1488,14 +1488,11 @@ _math_matrix_ctr( GLmatrix *m )
  void
  _math_matrix_dtr( GLmatrix *m )
  {
-   if (m->m) {
-  _mesa_align_free( m->m );
-  m->m = NULL;
-   }
-   if (m->inv) {
-  _mesa_align_free( m->inv );
-  m->inv = NULL;
-   }
+   _mesa_align_free( m->m );
+   m->m = NULL;
+
+   _mesa_align_free( m->inv );
+   m->inv = NULL;
  }

  /*@}*/
diff --git a/src/mesa/program/prog_parameter.c 
b/src/mesa/program/prog_parameter.c
index 4d9cf08..54531d2 100644
--- a/src/mesa/program/prog_parameter.c
+++ b/src/mesa/program/prog_parameter.c
@@ -83,8 +83,7 @@ _mesa_free_parameter_list(struct gl_program_parameter_list 
*paramList)
free((void *)paramList->Parameters[i].Name);
 }
 free(paramList->Parameters);
-   if (paramList->ParameterValues)
-  _mesa_align_free(paramList->ParameterValues);
+   _mesa_align_free(paramList->ParameterValues);
 free(paramList);
  }

diff --git a/src/mesa/state_tracker/st_cb_texture.c 
b/src/mesa/state_tracker/st_cb_texture.c
index faa9ee3..f33d3cf 100644
--- a/src/mesa/state_tracker/st_cb_texture.c
+++ b/src/mesa/state_tracker/st_cb_texture.c
@@ -175,10 +175,8 @@ st_FreeTextureImageBuffer(struct gl_context *ctx,
pipe_resource_reference(&stImage->pt, NULL);
 }

-   if (stImage->TexData) {
-  _mesa_align_free(stImage->TexData);
-  stImage->TexData = NULL;
-   }
+   _mesa_align_free(stImage->TexData);
+   stImage->TexData = NULL;
  }


diff --git a/src/mesa/swrast/s_texture.c b/src/mesa/swrast/s_texture.c
index 27803c5..c08a4e9 100644
--- a/src/mesa/swrast/s_texture.c
+++ b/src/mesa/swrast/s_texture.c
@@ -164,10 +164,9 @@ _swrast_free_texture_image_buffer(struct gl_context *ctx,
struct gl_texture_image *texImage)
  {
 struct swrast_texture_image *swImage = swrast_texture_image(texImage);
-   if (swImage->Buffer) {
-  _mesa_align_free(swImage->Buffer);
-  swImage->Buffer = NULL;
-   }
+
+   _mesa_align_free(swImage->Buffer);
+   swImage->Buffer = NULL;

 free(swImage->ImageSlices);
 swImage->ImageSlices = NULL;
diff --git a/src/mesa/tnl/t_vertex.c b/src/mesa/tnl/t_vertex.c
index c7a745e..8c4195e 100644
--- a/src/mesa/tnl/t_vertex.c
+++ b/src/mesa/tnl/t_vertex.c
@@ -546,10 +546,8 @@ void _tnl_free_vertices( struct gl_context *ctx )
struct tnl_clipspace *vtx = GET_VERTEX_STATE(ctx);
struct tnl_clipspace_fastpath *fp, *tmp;

-  if (vtx->vertex_buf) {
- _mesa_align_free(vtx->vertex_buf);
- vtx->vertex_buf = NULL;
-  }
+  _mesa_align_free(vtx->vertex_buf);
+  vtx->vertex_buf = NULL;

for (fp = vtx->fastpath ; fp ; fp = tmp) {
   tmp = fp->next;
diff --git a/src/mesa/vbo/vbo_exec_api.c b/src/mesa/vbo/vbo_exec_api.c
index 600398c..f3c41e0 100644
--- a/src/mesa/vbo/vbo_exec_api.c
+++ b/src/mesa/vbo/vbo_exec_api.c
@@ -989,11 +989,10 @@ void vbo_use_buffer_objects(struct

[Mesa-dev] [PATCH 5/7] i965/blorp: allow multisample blorp clears

[Paul Berry]

Previously, we didn't do multisample blorp clears because we couldn't
figure out how to get them to work.  The reason for this was because
we weren't setting the brw_blorp_params num_samples field consistently
with dst.num_samples.  Now that those two fields have been collapsed
down into one, we can do multisample blorp clears.

However, we need to do a few other pieces of bookkeeping to make them
work correctly in all circumstances:

- Since blorp clears may now operate on multisampled window system
  framebuffers, they need to call
  intel_renderbuffer_set_needs_downsample() to ensure that a
  downsample happens before buffer swap (or glReadPixels()).

- When clearing a layered multisample buffer attachment using UMS or
  CMS layout, we need to advance layer by multiples of num_samples
  (since each logical layer is associated with num_samples physical
  layers).

Note: we still don't do multisample fast color clears; more work needs
to be done to enable those.
---
 src/mesa/drivers/dri/i965/brw_blorp_clear.cpp | 31 +++
 1 file changed, 13 insertions(+), 18 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp 
b/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp
index ce6fcb2..308f49c 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp
+++ b/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp
@@ -239,7 +239,8 @@ brw_blorp_clear_params::brw_blorp_clear_params(struct 
brw_context *brw,
}
 
/* If we can do this as a fast color clear, do so. */
-   if (irb->mt->fast_clear_state != INTEL_FAST_CLEAR_STATE_NO_MCS &&
+   if (irb->mt->msaa_layout == INTEL_MSAA_LAYOUT_NONE &&
+   irb->mt->fast_clear_state != INTEL_FAST_CLEAR_STATE_NO_MCS &&
!partial_clear && wm_prog_key.use_simd16_replicated_data &&
is_color_fast_clear_compatible(brw, format, &ctx->Color.ClearColor)) {
   memset(push_consts, 0xff, 4*sizeof(float));
@@ -503,21 +504,6 @@ bool
 brw_blorp_clear_color(struct brw_context *brw, struct gl_framebuffer *fb,
   bool partial_clear)
 {
-   /* The constant color clear code doesn't work for multisampled surfaces, so
-* we need to support falling back to other clear mechanisms.
-* Unfortunately, our clear code is based on a bitmask that doesn't
-* distinguish individual color attachments, so we walk the attachments to
-* see if any require fallback, and fall back for all if any of them need
-* to.
-*/
-   for (unsigned buf = 0; buf < fb->_NumColorDrawBuffers; buf++) {
-  struct gl_renderbuffer *rb = fb->_ColorDrawBuffers[buf];
-  struct intel_renderbuffer *irb = intel_renderbuffer(rb);
-
-  if (irb && irb->mt->msaa_layout != INTEL_MSAA_LAYOUT_NONE)
- return false;
-   }
-
for (unsigned buf = 0; buf < fb->_NumColorDrawBuffers; buf++) {
   struct gl_renderbuffer *rb = fb->_ColorDrawBuffers[buf];
   struct intel_renderbuffer *irb = intel_renderbuffer(rb);
@@ -530,16 +516,25 @@ brw_blorp_clear_color(struct brw_context *brw, struct 
gl_framebuffer *fb,
  continue;
 
   if (fb->NumLayers > 0) {
- assert(fb->NumLayers == irb->mt->level[irb->mt_level].depth);
+ unsigned layer_multiplier =
+(irb->mt->msaa_layout == INTEL_MSAA_LAYOUT_UMS ||
+ irb->mt->msaa_layout == INTEL_MSAA_LAYOUT_CMS) ?
+irb->mt->num_samples : 1;
+ assert(fb->NumLayers * layer_multiplier ==
+irb->mt->level[irb->mt_level].depth);
  for (unsigned layer = 0; layer < fb->NumLayers; layer++) {
-if (!do_single_blorp_clear(brw, fb, rb, buf, partial_clear, layer))
+if (!do_single_blorp_clear(brw, fb, rb, buf, partial_clear,
+   layer * layer_multiplier)) {
return false;
+}
  }
   } else {
  unsigned layer = irb->mt_layer;
  if (!do_single_blorp_clear(brw, fb, rb, buf, partial_clear, layer))
 return false;
   }
+
+  intel_renderbuffer_set_needs_downsample(irb);
}
 
return true;
-- 
1.8.4.2

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

[Mesa-dev] [PATCH 7/7] i965/gen7+: Implement fast color clears for MSAA buffers.

[Paul Berry]

Fast color clears of MSAA buffers work just like fast color clears
with non-MSAA buffers, except that the alignment and scaledown
requirements are different.
---
 src/mesa/drivers/dri/i965/brw_blorp_clear.cpp | 131 +-
 1 file changed, 87 insertions(+), 44 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp 
b/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp
index ab472e6..4d03cbe 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp
+++ b/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp
@@ -239,8 +239,7 @@ brw_blorp_clear_params::brw_blorp_clear_params(struct 
brw_context *brw,
}
 
/* If we can do this as a fast color clear, do so. */
-   if (irb->mt->msaa_layout == INTEL_MSAA_LAYOUT_NONE &&
-   irb->mt->fast_clear_state != INTEL_FAST_CLEAR_STATE_NO_MCS &&
+   if (irb->mt->fast_clear_state != INTEL_FAST_CLEAR_STATE_NO_MCS &&
!partial_clear && wm_prog_key.use_simd16_replicated_data &&
is_color_fast_clear_compatible(brw, format, &ctx->Color.ClearColor)) {
   memset(push_consts, 0xff, 4*sizeof(float));
@@ -251,48 +250,92 @@ brw_blorp_clear_params::brw_blorp_clear_params(struct 
brw_context *brw,
*/
   unsigned x_align, y_align, x_scaledown, y_scaledown;
 
-  /* From the Ivy Bridge PRM, Vol2 Part1 11.7 "MCS Buffer for Render
-   * Target(s)", beneath the "Fast Color Clear" bullet (p327):
-   *
-   * Clear pass must have a clear rectangle that must follow alignment
-   * rules in terms of pixels and lines as shown in the table
-   * below. Further, the clear-rectangle height and width must be
-   * multiple of the following dimensions. If the height and width of
-   * the render target being cleared do not meet these requirements,
-   * an MCS buffer can be created such that it follows the requirement
-   * and covers the RT.
-   *
-   * The alignment size in the table that follows is related to the
-   * alignment size returned by intel_get_non_msrt_mcs_alignment(), but
-   * with X alignment multiplied by 16 and Y alignment multiplied by 32.
-   */
-  intel_get_non_msrt_mcs_alignment(brw, irb->mt, &x_align, &y_align);
-  x_align *= 16;
-  y_align *= 32;
-
-  /* From the Ivy Bridge PRM, Vol2 Part1 11.7 "MCS Buffer for Render
-   * Target(s)", beneath the "Fast Color Clear" bullet (p327):
-   *
-   * In order to optimize the performance MCS buffer (when bound to 1X
-   * RT) clear similarly to MCS buffer clear for MSRT case, clear rect
-   * is required to be scaled by the following factors in the
-   * horizontal and vertical directions:
-   *
-   * The X and Y scale down factors in the table that follows are each
-   * equal to half the alignment value computed above.
-   */
-  x_scaledown = x_align / 2;
-  y_scaledown = y_align / 2;
-
-  /* From BSpec: 3D-Media-GPGPU Engine > 3D Pipeline > Pixel > Pixel
-   * Backend > MCS Buffer for Render Target(s) [DevIVB+] > Table "Color
-   * Clear of Non-MultiSampled Render Target Restrictions":
-   *
-   *   Clear rectangle must be aligned to two times the number of pixels in
-   *   the table shown below due to 16x16 hashing across the slice.
-   */
-  x_align *= 2;
-  y_align *= 2;
+  if (irb->mt->msaa_layout == INTEL_MSAA_LAYOUT_NONE) {
+ /* From the Ivy Bridge PRM, Vol2 Part1 11.7 "MCS Buffer for Render
+  * Target(s)", beneath the "Fast Color Clear" bullet (p327):
+  *
+  * Clear pass must have a clear rectangle that must follow
+  * alignment rules in terms of pixels and lines as shown in the
+  * table below. Further, the clear-rectangle height and width
+  * must be multiple of the following dimensions. If the height
+  * and width of the render target being cleared do not meet these
+  * requirements, an MCS buffer can be created such that it
+  * follows the requirement and covers the RT.
+  *
+  * The alignment size in the table that follows is related to the
+  * alignment size returned by intel_get_non_msrt_mcs_alignment(), but
+  * with X alignment multiplied by 16 and Y alignment multiplied by 32.
+  */
+ intel_get_non_msrt_mcs_alignment(brw, irb->mt, &x_align, &y_align);
+ x_align *= 16;
+ y_align *= 32;
+
+ /* From the Ivy Bridge PRM, Vol2 Part1 11.7 "MCS Buffer for Render
+  * Target(s)", beneath the "Fast Color Clear" bullet (p327):
+  *
+  * In order to optimize the performance MCS buffer (when bound to
+  * 1X RT) clear similarly to MCS buffer clear for MSRT case,
+  * clear rect is required to be scaled by the following factors
+  * in the horizontal and vertical directions:
+  *
+  * The X and Y scal

[Mesa-dev] [PATCH 4/7] i965/blorp: Get rid of redundant num_samples blorp param.

[Paul Berry]

Previously, brw_blorp_params contained two fields for determining
sample count: num_samples (which determined the multisample
configuration of the rendering pipeline) and dst.num_samples (which
determined the multisample configuration of the render target
surface).  This was redundant, since both fields had to be set to the
same value to avoid rendering errors.

This patch eliminates num_samples to avoid future confusion.
---
 src/mesa/drivers/dri/i965/brw_blorp.cpp  | 1 -
 src/mesa/drivers/dri/i965/brw_blorp.h| 1 -
 src/mesa/drivers/dri/i965/brw_blorp_blit.cpp | 5 -
 src/mesa/drivers/dri/i965/gen6_blorp.cpp | 9 +
 src/mesa/drivers/dri/i965/gen7_blorp.cpp | 9 +
 5 files changed, 10 insertions(+), 15 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_blorp.cpp 
b/src/mesa/drivers/dri/i965/brw_blorp.cpp
index 791769a..ab3e75c 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp.cpp
+++ b/src/mesa/drivers/dri/i965/brw_blorp.cpp
@@ -162,7 +162,6 @@ brw_blorp_params::brw_blorp_params()
  depth_format(0),
  hiz_op(GEN6_HIZ_OP_NONE),
  fast_clear_op(GEN7_FAST_CLEAR_OP_NONE),
- num_samples(0),
  use_wm_prog(false)
 {
color_write_disable[0] = false;
diff --git a/src/mesa/drivers/dri/i965/brw_blorp.h 
b/src/mesa/drivers/dri/i965/brw_blorp.h
index 5163b52..1030e4e 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp.h
+++ b/src/mesa/drivers/dri/i965/brw_blorp.h
@@ -234,7 +234,6 @@ public:
brw_blorp_surface_info dst;
enum gen6_hiz_op hiz_op;
enum gen7_fast_clear_op fast_clear_op;
-   unsigned num_samples;
bool use_wm_prog;
brw_blorp_wm_push_constants wm_push_consts;
bool color_write_disable[4];
diff --git a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp 
b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
index a266143..51a3bef 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
+++ b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
@@ -2194,11 +2194,6 @@ brw_blorp_blit_params::brw_blorp_blit_params(struct 
brw_context *brw,
if (filter == GL_LINEAR && src.num_samples <= 1 && dst.num_samples <= 1)
   wm_prog_key.bilinear_filter = true;
 
-   /* The render path must be configured to use the same number of samples as
-* the destination buffer.
-*/
-   num_samples = dst.num_samples;
-
GLenum base_format = _mesa_get_format_base_format(src_mt->format);
if (base_format != GL_DEPTH_COMPONENT && /* TODO: what about depth/stencil? 
*/
base_format != GL_STENCIL_INDEX &&
diff --git a/src/mesa/drivers/dri/i965/gen6_blorp.cpp 
b/src/mesa/drivers/dri/i965/gen6_blorp.cpp
index 8fb8ca1..be6e6ff 100644
--- a/src/mesa/drivers/dri/i965/gen6_blorp.cpp
+++ b/src/mesa/drivers/dri/i965/gen6_blorp.cpp
@@ -664,7 +664,7 @@ gen6_blorp_emit_sf_config(struct brw_context *brw,
  1 << GEN6_SF_URB_ENTRY_READ_LENGTH_SHIFT |
  0 << GEN6_SF_URB_ENTRY_READ_OFFSET_SHIFT);
OUT_BATCH(0); /* dw2 */
-   OUT_BATCH(params->num_samples > 1 ? GEN6_SF_MSRAST_ON_PATTERN : 0);
+   OUT_BATCH(params->dst.num_samples > 1 ? GEN6_SF_MSRAST_ON_PATTERN : 0);
for (int i = 0; i < 16; ++i)
   OUT_BATCH(0);
ADVANCE_BATCH();
@@ -721,7 +721,7 @@ gen6_blorp_emit_wm_config(struct brw_context *brw,
   dw5 |= GEN6_WM_DISPATCH_ENABLE; /* We are rendering */
}
 
-   if (params->num_samples > 1) {
+   if (params->dst.num_samples > 1) {
   dw6 |= GEN6_WM_MSRAST_ON_PATTERN;
   if (prog_data && prog_data->persample_msaa_dispatch)
  dw6 |= GEN6_WM_MSDISPMODE_PERSAMPLE;
@@ -1034,8 +1034,9 @@ gen6_blorp_exec(struct brw_context *brw,
uint32_t wm_bind_bo_offset = 0;
 
uint32_t prog_offset = params->get_wm_prog(brw, &prog_data);
-   gen6_emit_3dstate_multisample(brw, params->num_samples);
-   gen6_emit_3dstate_sample_mask(brw, params->num_samples, 1.0, false, ~0u);
+   gen6_emit_3dstate_multisample(brw, params->dst.num_samples);
+   gen6_emit_3dstate_sample_mask(brw, params->dst.num_samples, 1.0, false,
+ ~0u);
gen6_blorp_emit_state_base_address(brw, params);
gen6_blorp_emit_vertices(brw, params);
gen6_blorp_emit_urb_config(brw, params);
diff --git a/src/mesa/drivers/dri/i965/gen7_blorp.cpp 
b/src/mesa/drivers/dri/i965/gen7_blorp.cpp
index 3368d41..583fd51 100644
--- a/src/mesa/drivers/dri/i965/gen7_blorp.cpp
+++ b/src/mesa/drivers/dri/i965/gen7_blorp.cpp
@@ -472,7 +472,7 @@ gen7_blorp_emit_sf_config(struct brw_context *brw,
   OUT_BATCH(_3DSTATE_SF << 16 | (7 - 2));
   OUT_BATCH(params->depth_format <<
 GEN7_SF_DEPTH_BUFFER_SURFACE_FORMAT_SHIFT);
-  OUT_BATCH(params->num_samples > 1 ? GEN6_SF_MSRAST_ON_PATTERN : 0);
+  OUT_BATCH(params->dst.num_samples > 1 ? GEN6_SF_MSRAST_ON_PATTERN : 0);
   OUT_BATCH(0);
   OUT_BATCH(0);
   OUT_BATCH(0);
@@ -528,7 +528,7 @@ gen7_blorp_emit_wm_config(struct brw_context *brw,
   dw1 |= GEN7_WM_DISPATCH_ENABLE; /* We are rendering */
}
 
-  if (params->num_samples > 1) {
+  if 

[Mesa-dev] [PATCH 0/7] i965/gen7+: MSAA fast color clears.

[Paul Berry]

This series extends the gen7+ fast color clear capability to work with
multisample (MSAA) buffers.

Patch 1 documents some conventions about layer counting that I had to
sleuth out in order to write patch 5.  Patch 2 fixes a pre-existing
bug that was previously inadequately piglit tested, but which would
otherwise have caused patch 5 to regress some piglit tests.  Patch 3
cleans up the enum that keeps track of fast clear state so that it can
be re-used for MSAA fast clears.  Patch 4 cleans up a redundant blorp
parameter that would have otherwise complicated patch 5.

Patch 5 enables blorp for multisample clears, using a slow path.
Patch 6 refactors the rectangle alignment/scaling code for blorp fast
clears so that adding multisample fast clears will be easy.  Finally,
patch 7 adds the multisample fast clear functionality.

This code is available in branch "msaa-fast-clear" of
https://github.com/stereotype441/mesa.git.

[PATCH 1/7] i965: Document conventions for counting layers in 2D multisample 
buffers.
[PATCH 2/7] i965: Don't try to use HW blitter for glCopyPixels() when 
multisampled.
[PATCH 3/7] i965/gen7+: Disentangle MSAA layout from fast clear state.
[PATCH 4/7] i965/blorp: Get rid of redundant num_samples blorp param.
[PATCH 5/7] i965/blorp: allow multisample blorp clears
[PATCH 6/7] i965/blorp: Refactor code for computing fast clear align/scaledown 
factors.
[PATCH 7/7] i965/gen7+: Implement fast color clears for MSAA buffers.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2/7] i965: Don't try to use HW blitter for glCopyPixels() when multisampled.

[Paul Berry]

The hardware blitter doesn't understand multisampled layouts, so
there's no way this could possibly succeed.
---
 src/mesa/drivers/dri/i965/intel_pixel_copy.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/intel_pixel_copy.c 
b/src/mesa/drivers/dri/i965/intel_pixel_copy.c
index 9dc5c15..8da02a0 100644
--- a/src/mesa/drivers/dri/i965/intel_pixel_copy.c
+++ b/src/mesa/drivers/dri/i965/intel_pixel_copy.c
@@ -102,6 +102,11 @@ do_blit_copypixels(struct gl_context * ctx,
   return false;
}
 
+   if (draw_irb->mt->num_samples > 1 || read_irb->mt->num_samples > 1) {
+  perf_debug("glCopyPixels() fallback: multisampled buffers\n");
+  return false;
+   }
+
if (ctx->_ImageTransferState) {
   perf_debug("glCopyPixels(): Unsupported image transfer state\n");
   return false;
-- 
1.8.4.2

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

[Mesa-dev] [PATCH 3/7] i965/gen7+: Disentangle MSAA layout from fast clear state.

[Paul Berry]

This patch renames the enum that's used to keep track of fast clear
state from "mcs_state" to "fast_clear_state", and it removes the enum
value INTEL_MCS_STATE_MSAA (which previously meant, "this is an MSAA
buffer, so we're not keeping track of fast clear state").  The only
real purpose that enum value was serving was to prevent us from trying
to do fast clear resolves on MSAA buffers, and it's just as easy to
prevent that by checking the buffer's msaa_layout.

This paves the way for implementing fast clears of MSAA buffers.
---
 src/mesa/drivers/dri/i965/brw_blorp_clear.cpp | 18 ++--
 src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 35 +++---
 src/mesa/drivers/dri/i965/intel_mipmap_tree.h | 42 +--
 3 files changed, 47 insertions(+), 48 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp 
b/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp
index 1904bde..ce6fcb2 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp
+++ b/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp
@@ -239,8 +239,8 @@ brw_blorp_clear_params::brw_blorp_clear_params(struct 
brw_context *brw,
}
 
/* If we can do this as a fast color clear, do so. */
-   if (irb->mt->mcs_state != INTEL_MCS_STATE_NONE && !partial_clear &&
-   wm_prog_key.use_simd16_replicated_data &&
+   if (irb->mt->fast_clear_state != INTEL_FAST_CLEAR_STATE_NO_MCS &&
+   !partial_clear && wm_prog_key.use_simd16_replicated_data &&
is_color_fast_clear_compatible(brw, format, &ctx->Color.ClearColor)) {
   memset(push_consts, 0xff, 4*sizeof(float));
   fast_clear_op = GEN7_FAST_CLEAR_OP_FAST_CLEAR;
@@ -460,10 +460,10 @@ do_single_blorp_clear(struct brw_context *brw, struct 
gl_framebuffer *fb,
  brw->state.dirty.brw |= BRW_NEW_SURFACES;
   }
 
-  /* If the buffer is already in INTEL_MCS_STATE_CLEAR, the clear is
-   * redundant and can be skipped.
+  /* If the buffer is already in INTEL_FAST_CLEAR_STATE_CLEAR, the clear
+   * is redundant and can be skipped.
*/
-  if (irb->mt->mcs_state == INTEL_MCS_STATE_CLEAR)
+  if (irb->mt->fast_clear_state == INTEL_FAST_CLEAR_STATE_CLEAR)
  return true;
 
   /* If the MCS buffer hasn't been allocated yet, we need to allocate
@@ -488,10 +488,10 @@ do_single_blorp_clear(struct brw_context *brw, struct 
gl_framebuffer *fb,
 
if (is_fast_clear) {
   /* Now that the fast clear has occurred, put the buffer in
-   * INTEL_MCS_STATE_CLEAR so that we won't waste time doing redundant
-   * clears.
+   * INTEL_FAST_CLEAR_STATE_CLEAR so that we won't waste time doing
+   * redundant clears.
*/
-  irb->mt->mcs_state = INTEL_MCS_STATE_CLEAR;
+  irb->mt->fast_clear_state = INTEL_FAST_CLEAR_STATE_CLEAR;
}
 
return true;
@@ -552,7 +552,7 @@ brw_blorp_resolve_color(struct brw_context *brw, struct 
intel_mipmap_tree *mt)
 
brw_blorp_rt_resolve_params params(brw, mt);
brw_blorp_exec(brw, ¶ms);
-   mt->mcs_state = INTEL_MCS_STATE_RESOLVED;
+   mt->fast_clear_state = INTEL_FAST_CLEAR_STATE_RESOLVED;
 }
 
 } /* extern "C" */
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c 
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
index 3889803..e6f926e 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
@@ -266,7 +266,7 @@ intel_miptree_create_layout(struct brw_context *brw,
mt->logical_width0 = width0;
mt->logical_height0 = height0;
mt->logical_depth0 = depth0;
-   mt->mcs_state = INTEL_MCS_STATE_NONE;
+   mt->fast_clear_state = INTEL_FAST_CLEAR_STATE_NO_MCS;
 
/* The cpp is bytes per (1, blockheight)-sized block for compressed
 * textures.  This is why you'll see divides by blockheight all over
@@ -612,12 +612,12 @@ intel_miptree_create(struct brw_context *brw,
}
 
/* If this miptree is capable of supporting fast color clears, set
-* mcs_state appropriately to ensure that fast clears will occur.
+* fast_clear_state appropriately to ensure that fast clears will occur.
 * Allocation of the MCS miptree will be deferred until the first fast
 * clear actually occurs.
 */
if (intel_is_non_msrt_mcs_buffer_supported(brw, mt))
-  mt->mcs_state = INTEL_MCS_STATE_RESOLVED;
+  mt->fast_clear_state = INTEL_FAST_CLEAR_STATE_RESOLVED;
 
return mt;
 }
@@ -713,12 +713,12 @@ intel_miptree_create_for_dri2_buffer(struct brw_context 
*brw,
singlesample_mt->region->name = region->name;
 
/* If this miptree is capable of supporting fast color clears, set
-* mcs_state appropriately to ensure that fast clears will occur.
+* fast_clear_state appropriately to ensure that fast clears will occur.
 * Allocation of the MCS miptree will be deferred until the first fast
 * clear actually occurs.
 */
if (intel_is_non_msrt_mcs_buffer_supported(brw, singlesample_mt))
-  singlesample_mt->mcs_state = INTEL_MCS_STATE_RESOLVED;
+ 

[Mesa-dev] [PATCH 6/7] i965/blorp: Refactor code for computing fast clear align/scaledown factors.

[Paul Berry]

This will make it easier to add fast color clear support to MSAA
buffers, since they have different alignment and scaling requirements.
---
 src/mesa/drivers/dri/i965/brw_blorp_clear.cpp | 42 +++
 1 file changed, 23 insertions(+), 19 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp 
b/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp
index 308f49c..ab472e6 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp
+++ b/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp
@@ -246,6 +246,11 @@ brw_blorp_clear_params::brw_blorp_clear_params(struct 
brw_context *brw,
   memset(push_consts, 0xff, 4*sizeof(float));
   fast_clear_op = GEN7_FAST_CLEAR_OP_FAST_CLEAR;
 
+  /* Figure out what the clear rectangle needs to be aligned to, and how
+   * much it needs to be scaled down.
+   */
+  unsigned x_align, y_align, x_scaledown, y_scaledown;
+
   /* From the Ivy Bridge PRM, Vol2 Part1 11.7 "MCS Buffer for Render
* Target(s)", beneath the "Fast Color Clear" bullet (p327):
*
@@ -261,23 +266,10 @@ brw_blorp_clear_params::brw_blorp_clear_params(struct 
brw_context *brw,
* alignment size returned by intel_get_non_msrt_mcs_alignment(), but
* with X alignment multiplied by 16 and Y alignment multiplied by 32.
*/
-  unsigned x_align, y_align;
   intel_get_non_msrt_mcs_alignment(brw, irb->mt, &x_align, &y_align);
   x_align *= 16;
   y_align *= 32;
 
-  /* From BSpec: 3D-Media-GPGPU Engine > 3D Pipeline > Pixel > Pixel
-   * Backend > MCS Buffer for Render Target(s) [DevIVB+] > Table "Color
-   * Clear of Non-MultiSampled Render Target Restrictions":
-   *
-   *   Clear rectangle must be aligned to two times the number of pixels in
-   *   the table shown below due to 16x16 hashing across the slice.
-   */
-  x0 = ROUND_DOWN_TO(x0, 2 * x_align);
-  y0 = ROUND_DOWN_TO(y0, 2 * y_align);
-  x1 = ALIGN(x1, 2 * x_align);
-  y1 = ALIGN(y1, 2 * y_align);
-
   /* From the Ivy Bridge PRM, Vol2 Part1 11.7 "MCS Buffer for Render
* Target(s)", beneath the "Fast Color Clear" bullet (p327):
*
@@ -289,12 +281,24 @@ brw_blorp_clear_params::brw_blorp_clear_params(struct 
brw_context *brw,
* The X and Y scale down factors in the table that follows are each
* equal to half the alignment value computed above.
*/
-  unsigned x_scaledown = x_align / 2;
-  unsigned y_scaledown = y_align / 2;
-  x0 /= x_scaledown;
-  y0 /= y_scaledown;
-  x1 /= x_scaledown;
-  y1 /= y_scaledown;
+  x_scaledown = x_align / 2;
+  y_scaledown = y_align / 2;
+
+  /* From BSpec: 3D-Media-GPGPU Engine > 3D Pipeline > Pixel > Pixel
+   * Backend > MCS Buffer for Render Target(s) [DevIVB+] > Table "Color
+   * Clear of Non-MultiSampled Render Target Restrictions":
+   *
+   *   Clear rectangle must be aligned to two times the number of pixels in
+   *   the table shown below due to 16x16 hashing across the slice.
+   */
+  x_align *= 2;
+  y_align *= 2;
+
+  /* Do the alignment and scaledown. */
+  x0 = ROUND_DOWN_TO(x0,  x_align) / x_scaledown;
+  y0 = ROUND_DOWN_TO(y0, y_align) / y_scaledown;
+  x1 = ALIGN(x1, x_align) / x_scaledown;
+  y1 = ALIGN(y1, y_align) / y_scaledown;
}
 }
 
-- 
1.8.4.2

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

[Mesa-dev] [PATCH 1/7] i965: Document conventions for counting layers in 2D multisample buffers.

[Paul Berry]

The "layer" parameters used in blorp, and the
intel_renderbuffer::mt_layer field, represent a physical layer rather
than a logical layer.  This is important for 2D multisample arrays on
Gen7+ because the UMS and CMS multisample layouts use N physical
layers to represent each logical layer, where N is the number of
samples.

Also add an assertion to blorp to help catch bugs if we fail to follow
these conventions.
---
 src/mesa/drivers/dri/i965/brw_blorp.cpp  | 9 +
 src/mesa/drivers/dri/i965/brw_blorp.h| 5 +
 src/mesa/drivers/dri/i965/brw_blorp_blit.cpp | 8 
 src/mesa/drivers/dri/i965/intel_fbo.h| 5 +
 4 files changed, 27 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/brw_blorp.cpp 
b/src/mesa/drivers/dri/i965/brw_blorp.cpp
index 6b3600d..791769a 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp.cpp
+++ b/src/mesa/drivers/dri/i965/brw_blorp.cpp
@@ -54,6 +54,15 @@ void
 brw_blorp_mip_info::set(struct intel_mipmap_tree *mt,
 unsigned int level, unsigned int layer)
 {
+   /* Layer is a physical layer, so if this is a 2D multisample array texture
+* using INTEL_MSAA_LAYOUT_UMS or INTEL_MSAA_LAYOUT_CMS, then it had better
+* be a multiple of num_samples.
+*/
+   if (mt->msaa_layout == INTEL_MSAA_LAYOUT_UMS ||
+   mt->msaa_layout == INTEL_MSAA_LAYOUT_CMS) {
+  assert(layer % mt->num_samples == 0);
+   }
+
intel_miptree_check_level_layer(mt, level, layer);
 
this->mt = mt;
diff --git a/src/mesa/drivers/dri/i965/brw_blorp.h 
b/src/mesa/drivers/dri/i965/brw_blorp.h
index 85bf099..5163b52 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp.h
+++ b/src/mesa/drivers/dri/i965/brw_blorp.h
@@ -85,6 +85,11 @@ public:
/**
 * The 2D layer within the miplevel. Combined, level and layer define the
 * 2D miptree slice to use.
+*
+* Note: if mt is a 2D multisample array texture on Gen7+ using
+* INTEL_MSAA_LAYOUT_UMS or INTEL_MSAA_LAYOUT_CMS, layer is the physical
+* layer holding sample 0.  So, for example, if mt->num_samples == 4, then
+* logical layer n corresponds to layer == 4*n.
 */
uint32_t layer;
 
diff --git a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp 
b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
index 9c48eac..a266143 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
+++ b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
@@ -123,6 +123,14 @@ find_miptree(GLbitfield buffer_bit, struct 
intel_renderbuffer *irb)
return mt;
 }
 
+
+/**
+ * Note: if the src (or dst) is a 2D multisample array texture on Gen7+ using
+ * INTEL_MSAA_LAYOUT_UMS or INTEL_MSAA_LAYOUT_CMS, src_layer (dst_layer) is
+ * the physical layer holding sample 0.  So, for example, if
+ * src_mt->num_samples == 4, then logical layer n corresponds to src_layer ==
+ * 4*n.
+ */
 void
 brw_blorp_blit_miptrees(struct brw_context *brw,
 struct intel_mipmap_tree *src_mt,
diff --git a/src/mesa/drivers/dri/i965/intel_fbo.h 
b/src/mesa/drivers/dri/i965/intel_fbo.h
index a198301..447611f 100644
--- a/src/mesa/drivers/dri/i965/intel_fbo.h
+++ b/src/mesa/drivers/dri/i965/intel_fbo.h
@@ -63,6 +63,11 @@ struct intel_renderbuffer
 *
 * For renderbuffers not created with glFramebufferTexture*(), mt_level and
 * mt_layer are 0.
+*
+* Note: for a 2D multisample array texture on Gen7+ using
+* INTEL_MSAA_LAYOUT_UMS or INTEL_MSAA_LAYOUT_CMS, mt_layer is the physical
+* layer holding sample 0.  So, for example, if mt->num_samples == 4, then
+* logical layer n corresponds to mt_layer == 4*n.
 */
unsigned int mt_level;
unsigned int mt_layer;
-- 
1.8.4.2

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

Re: [Mesa-dev] [Mesa-stable] [PATCH 2/2] mesa: don't leak performance monitors on context destroy

[Kenneth Graunke]

On 11/29/2013 02:52 AM, Ilia Mirkin wrote:
> Signed-off-by: Ilia Mirkin 
> Cc: "10.0" 
> ---
> 
> Found with valgrind. Don't have the hardware to test a real implementation,
> but with nv50 it seemed to work in that valgrind was no longer marking the
> hash table as leaked.

Reviewed-by: Kenneth Graunke 

and pushed - thanks!

I agree that this is a candidate for 10.0, since it fixes a memory leak
in core Mesa code...even though no driver exposes
AMD_performance_monitor on 10.0 (due to last minute reverts).

Alternatively, one could simply revert the rest of
AMD_performance_monitor from 10.0.  Up to the stable maintainers.

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

[Mesa-dev] [PATCH] r600/llvm: Allow arbitrary amount of temps in tgsi to llvm

[Vincent Lejeune]

---
 src/gallium/drivers/radeon/radeon_llvm.h   |  5 +++
 .../drivers/radeon/radeon_setup_tgsi_llvm.c| 41 +++---
 2 files changed, 42 insertions(+), 4 deletions(-)

diff --git a/src/gallium/drivers/radeon/radeon_llvm.h 
b/src/gallium/drivers/radeon/radeon_llvm.h
index 2cab6b0..6d84f44 100644
--- a/src/gallium/drivers/radeon/radeon_llvm.h
+++ b/src/gallium/drivers/radeon/radeon_llvm.h
@@ -112,6 +112,11 @@ struct radeon_llvm_context {
LLVMValueRef outputs[RADEON_LLVM_MAX_OUTPUTS][TGSI_NUM_CHANNELS];
unsigned output_reg_count;
 
+   /**
+* @brief system_values
+*/
+   LLVMValueRef *temps;
+   unsigned temps_count;
LLVMValueRef system_values[RADEON_LLVM_MAX_SYSTEM_VALUES];
 
/*=== Private Members ===*/
diff --git a/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c 
b/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
index 3bb01ec..c897b03 100644
--- a/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
+++ b/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
@@ -184,7 +184,11 @@ emit_fetch(
break;
 
case TGSI_FILE_TEMPORARY:
-   ptr = lp_get_temp_ptr_soa(bld, reg->Register.Index, swizzle);
+   if (false) {
+   ptr = lp_get_temp_ptr_soa(bld, reg->Register.Index, 
swizzle);
+   break;
+   }
+   ptr = ctx->temps[reg->Register.Index * TGSI_NUM_CHANNELS + 
swizzle];
result = LLVMBuildLoad(builder, ptr, "");
break;
 
@@ -200,6 +204,13 @@ emit_fetch(
return bitcast(bld_base, type, result);
 }
 
+static bool uses_temp_indirect_addressing(
+   struct lp_build_tgsi_context *bld_base)
+{
+   struct lp_build_tgsi_soa_context *bld = lp_soa_context(bld_base);
+   return !(bld->indirect_files & (1 << TGSI_FILE_TEMPORARY));
+}
+
 static LLVMValueRef fetch_system_value(
struct lp_build_tgsi_context * bld_base,
const struct tgsi_full_src_register *reg,
@@ -234,7 +245,22 @@ static void emit_declaration(
case TGSI_FILE_TEMPORARY:
if (decl->Declaration.Array && decl->Array.ArrayID <= 
RADEON_LLVM_MAX_ARRAYS)
ctx->arrays[decl->Array.ArrayID - 1] = decl->Range;
-   lp_emit_declaration_soa(bld_base, decl);
+   if (uses_temp_indirect_addressing(bld_base)) {
+   lp_emit_declaration_soa(bld_base, decl);
+   break;
+   }
+   unsigned first = decl->Range.First, last = decl->Range.Last;
+   if (!ctx->temps_count) {
+   ctx->temps_count = 
bld_base->info->file_max[TGSI_FILE_TEMPORARY] + 1;
+   ctx->temps = MALLOC(TGSI_NUM_CHANNELS * 
ctx->temps_count * sizeof(LLVMValueRef));
+   }
+   for (unsigned idx = first; idx <= last; idx++) {
+   for (unsigned i = 0; i < TGSI_NUM_CHANNELS; i++) {
+   ctx->temps[idx * TGSI_NUM_CHANNELS + i] =
+   lp_build_alloca(bld_base->base.gallivm, 
bld_base->base.vec_type,
+   "temp");
+   }
+   }
break;
 
case TGSI_FILE_INPUT:
@@ -284,6 +310,7 @@ emit_store(
const struct tgsi_opcode_info * info,
LLVMValueRef dst[4])
 {
+   struct radeon_llvm_context * ctx = radeon_llvm_context(bld_base);
struct lp_build_tgsi_soa_context *bld = lp_soa_context(bld_base);
struct gallivm_state *gallivm = bld->bld_base.base.gallivm;
struct lp_build_context base = bld->bld_base.base;
@@ -359,7 +386,10 @@ emit_store(
break;
 
case TGSI_FILE_TEMPORARY:
-   temp_ptr = lp_get_temp_ptr_soa(bld, i + 
range.First, chan_index);
+   if 
(uses_temp_indirect_addressing(bld_base))
+   temp_ptr = 
lp_get_temp_ptr_soa(bld, i + range.First, chan_index);
+   else
+   temp_ptr = ctx->temps[(i + 
range.First) * TGSI_NUM_CHANNELS + chan_index];
break;
 
default:
@@ -377,7 +407,9 @@ emit_store(
break;
 
case TGSI_FILE_TEMPORARY:
-   temp_ptr = lp_get_temp_ptr_soa(bld, 
reg->Register.Index, chan_index);
+   if (uses_temp_indirect_addressing(bld_base))
+   break;
+   temp_ptr = ctx->temps[ TGSI_NUM_CHANNELS * 
reg->Register.Index + chan_index];
break;
 
default:
@@ -1392,4 +1424,5 @@ void rad

Re: [Mesa-dev] [PATCH] winsys/radeon: set/get the scanout flag with the tiling ioctls

[Marek Olšák]

I wanted to keep the old behavior for R600, because it doesn't have
the issue as far as I know.

Marek

On Wed, Dec 4, 2013 at 5:16 AM, Michel Dänzer  wrote:
> On Fre, 2013-11-29 at 19:08 +0100, Marek Olšák wrote:
>> From: Marek Olšák 
>>
>> If we assume that all buffers allocated by the DDX are scanout, a new flag
>> that says "this is not scanout" has to be added to support the non-scanout
>> buffers and maintain backward compatibility.
>>
>> This fixes bad rendering on Wayland.
>>
>> The flag is defined as:
>>   #define RADEON_TILING_R600_NO_SCANOUT   RADEON_TILING_SWAP_16BIT
>>
>> AFAIK, RADEON_TILING_SWAP_16BIT is not used on SI.
>
> Is it used on >= R600? If not, might it make sense to use the new flag
> as of R600?
>
> Either way though,
>
> 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

[Mesa-dev] [PATCH 5/5] glsl: modify ir_clone to use memcpy

[Tapani Pälli]

Patch copies the whole data structure at once instead of
assigning individual variables.

Signed-off-by: Tapani Pälli 
---
 src/glsl/ir_clone.cpp | 22 +++---
 1 file changed, 3 insertions(+), 19 deletions(-)

diff --git a/src/glsl/ir_clone.cpp b/src/glsl/ir_clone.cpp
index d98ed95..66e4690 100644
--- a/src/glsl/ir_clone.cpp
+++ b/src/glsl/ir_clone.cpp
@@ -50,26 +50,10 @@ ir_variable::clone(void *mem_ctx, struct hash_table *ht) 
const
   memcpy(var->max_ifc_array_access, this->max_ifc_array_access,
  this->interface_type->length * sizeof(unsigned));
}
-   var->data.read_only = this->data.read_only;
-   var->data.centroid = this->data.centroid;
-   var->data.invariant = this->data.invariant;
-   var->data.interpolation = this->data.interpolation;
-   var->data.location = this->data.location;
-   var->data.index = this->data.index;
-   var->data.binding = this->data.binding;
-   var->data.atomic.buffer_index = this->data.atomic.buffer_index;
-   var->data.atomic.offset = this->data.atomic.offset;
+
+   memcpy(&var->data, &this->data, sizeof(var->data));
+
var->warn_extension = this->warn_extension;
-   var->data.origin_upper_left = this->data.origin_upper_left;
-   var->data.pixel_center_integer = this->data.pixel_center_integer;
-   var->data.explicit_location = this->data.explicit_location;
-   var->data.explicit_index = this->data.explicit_index;
-   var->data.explicit_binding = this->data.explicit_binding;
-   var->data.has_initializer = this->data.has_initializer;
-   var->data.depth_layout = this->data.depth_layout;
-   var->data.assigned = this->data.assigned;
-   var->data.how_declared = this->data.how_declared;
-   var->data.used = this->data.used;
 
var->num_state_slots = this->num_state_slots;
if (this->state_slots) {
-- 
1.8.3.1

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

[Mesa-dev] [PATCH 3/5] glsl: move variables in to ir_variable::data, part II

[Tapani Pälli]

This patch moves following bitfields in to the data structure:

explicit_location, explicit_index, explicit_binding,
has_initializer, is_unmatched_generic_inout, location_frac

Signed-off-by: Tapani Pälli 
---
 src/glsl/ast_to_hir.cpp  | 12 ++---
 src/glsl/builtin_variables.cpp   |  6 +--
 src/glsl/ir.cpp  |  6 +--
 src/glsl/ir.h| 80 ++--
 src/glsl/ir_clone.cpp|  8 +--
 src/glsl/ir_validate.cpp |  2 +-
 src/glsl/link_uniform_initializers.cpp   |  2 +-
 src/glsl/link_varyings.cpp   | 16 +++---
 src/glsl/linker.cpp  | 38 ++---
 src/glsl/lower_named_interface_blocks.cpp|  2 +-
 src/glsl/lower_packed_varyings.cpp   |  2 +-
 src/glsl/opt_dead_builtin_varyings.cpp   |  4 +-
 src/glsl/tests/builtin_variable_test.cpp | 30 +--
 src/glsl/tests/invalidate_locations_test.cpp | 60 ++---
 14 files changed, 134 insertions(+), 134 deletions(-)

diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index bff5a47..7847720 100644
--- a/src/glsl/ast_to_hir.cpp
+++ b/src/glsl/ast_to_hir.cpp
@@ -2112,7 +2112,7 @@ validate_explicit_location(const struct 
ast_type_qualifier *qual,
mode_string(var),
   _mesa_glsl_shader_target_name(state->target));
} else {
-  var->explicit_location = true;
+  var->data.explicit_location = true;
 
   /* This bit of silliness is needed because invalid explicit locations
* are supposed to be flagged during linking.  Small negative values
@@ -2143,7 +2143,7 @@ validate_explicit_location(const struct 
ast_type_qualifier *qual,
 _mesa_glsl_error(loc, state,
  "explicit index may only be 0 or 1");
  } else {
-var->explicit_index = true;
+var->data.explicit_index = true;
 var->index = qual->index;
  }
   }
@@ -2312,13 +2312,13 @@ apply_type_qualifier_to_variable(const struct 
ast_type_qualifier *qual,
 
if (qual->flags.q.explicit_binding &&
validate_binding_qualifier(state, loc, var, qual)) {
-  var->explicit_binding = true;
+  var->data.explicit_binding = true;
   var->binding = qual->binding;
}
 
if (var->type->contains_atomic()) {
   if (var->data.mode == ir_var_uniform) {
- if (var->explicit_binding) {
+ if (var->data.explicit_binding) {
 unsigned *offset = &state->atomic_counter_offsets[var->binding];
 
 if (*offset % ATOMIC_COUNTER_SIZE)
@@ -2664,7 +2664,7 @@ process_initializer(ir_variable *var, ast_declaration 
*decl,
 initializer_type = rhs->type;
 
   var->constant_initializer = rhs->constant_expression_value();
-  var->has_initializer = true;
+  var->data.has_initializer = true;
 
   /* If the declared variable is an unsized array, it must inherrit
* its full type from the initializer.  A declaration such as
@@ -5111,7 +5111,7 @@ ast_interface_block::hir(exec_list *instructions,
   * the UBO declaration itself doesn't get an ir_variable unless it
   * has an instance name.  This is ugly.
   */
- var->explicit_binding = this->layout.flags.q.explicit_binding;
+ var->data.explicit_binding = this->layout.flags.q.explicit_binding;
  var->binding = this->layout.binding;
 
  state->symbols->add_variable(var);
diff --git a/src/glsl/builtin_variables.cpp b/src/glsl/builtin_variables.cpp
index b1ea128..e92728b 100644
--- a/src/glsl/builtin_variables.cpp
+++ b/src/glsl/builtin_variables.cpp
@@ -455,8 +455,8 @@ builtin_variable_generator::add_variable(const char *name,
}
 
var->location = slot;
-   var->explicit_location = (slot >= 0);
-   var->explicit_index = 0;
+   var->data.explicit_location = (slot >= 0);
+   var->data.explicit_index = 0;
 
/* Once the variable is created an initialized, add it to the symbol table
 * and add the declaration to the IR stream.
@@ -523,7 +523,7 @@ builtin_variable_generator::add_const(const char *name, int 
value)
 ir_var_auto, -1);
var->constant_value = new(var) ir_constant(value);
var->constant_initializer = new(var) ir_constant(value);
-   var->has_initializer = true;
+   var->data.has_initializer = true;
return var;
 }
 
diff --git a/src/glsl/ir.cpp b/src/glsl/ir.cpp
index 4f9b88a..c6ba7c9 100644
--- a/src/glsl/ir.cpp
+++ b/src/glsl/ir.cpp
@@ -1589,10 +1589,10 @@ ir_variable::ir_variable(const struct glsl_type *type, 
const char *name,
this->ir_type = ir_type_variable;
this->type = type;
this->name = ralloc_strdup(this, name);
-   this->explicit_location = false;
-   this->has_initializer = false;
+   this->data.explicit_location = false;
+   this->data.has_initializer = false;
this->location = -1;
-  

[Mesa-dev] [PATCH 1/5] glsl: introduce data section to ir_variable

[Tapani Pälli]

Data section helps serialization and cloning of a ir_variable. This
patch includes the helper bits used for read only ir_variables.

Signed-off-by: Tapani Pälli 
---
 src/glsl/ast_function.cpp |  2 +-
 src/glsl/ast_to_hir.cpp   | 28 ++--
 src/glsl/builtin_variables.cpp|  4 ++--
 src/glsl/ir.cpp   | 14 --
 src/glsl/ir.h | 22 +-
 src/glsl/ir_clone.cpp |  6 +++---
 src/glsl/ir_print_visitor.cpp |  4 ++--
 src/glsl/ir_reader.cpp|  4 ++--
 src/glsl/ir_set_program_inouts.cpp|  2 +-
 src/glsl/link_varyings.cpp| 18 +-
 src/glsl/linker.cpp   |  4 ++--
 src/glsl/lower_named_interface_blocks.cpp |  2 +-
 src/glsl/lower_packed_varyings.cpp|  2 +-
 src/glsl/opt_cse.cpp  |  2 +-
 src/glsl/opt_function_inlining.cpp|  2 +-
 src/glsl/tests/builtin_variable_test.cpp  |  2 +-
 src/mesa/drivers/dri/i965/brw_fs.cpp  |  4 ++--
 17 files changed, 64 insertions(+), 58 deletions(-)

diff --git a/src/glsl/ast_function.cpp b/src/glsl/ast_function.cpp
index 6423759..8202116 100644
--- a/src/glsl/ast_function.cpp
+++ b/src/glsl/ast_function.cpp
@@ -157,7 +157,7 @@ verify_parameter_modes(_mesa_glsl_parse_state *state,
 if (var)
var->assigned = true;
 
-if (var && var->read_only) {
+if (var && var->data.read_only) {
_mesa_glsl_error(&loc, state,
 "function parameter '%s %s' references the "
 "read-only variable '%s'",
diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index 43cf497..db0f8c6 100644
--- a/src/glsl/ast_to_hir.cpp
+++ b/src/glsl/ast_to_hir.cpp
@@ -776,7 +776,7 @@ do_assignment(exec_list *instructions, struct 
_mesa_glsl_parse_state *state,
  non_lvalue_description);
 error_emitted = true;
   } else if (lhs->variable_referenced() != NULL
-&& lhs->variable_referenced()->read_only) {
+&& lhs->variable_referenced()->data.read_only) {
  _mesa_glsl_error(&lhs_loc, state,
   "assignment to read-only variable '%s'",
   lhs->variable_referenced()->name);
@@ -2168,17 +2168,17 @@ apply_type_qualifier_to_variable(const struct 
ast_type_qualifier *qual,
  "`invariant' after being used",
  var->name);
   } else {
-var->invariant = 1;
+var->data.invariant = 1;
   }
}
 
if (qual->flags.q.constant || qual->flags.q.attribute
|| qual->flags.q.uniform
|| (qual->flags.q.varying && (state->target == fragment_shader)))
-  var->read_only = 1;
+  var->data.read_only = 1;
 
if (qual->flags.q.centroid)
-  var->centroid = 1;
+  var->data.centroid = 1;
 
if (qual->flags.q.attribute && state->target != vertex_shader) {
   var->type = glsl_type::error_type;
@@ -2272,16 +2272,16 @@ apply_type_qualifier_to_variable(const struct 
ast_type_qualifier *qual,
   switch (state->target) {
   case vertex_shader:
 if (var->mode == ir_var_shader_out)
-   var->invariant = true;
+   var->data.invariant = true;
 break;
   case geometry_shader:
 if ((var->mode == ir_var_shader_in)
  || (var->mode == ir_var_shader_out))
-   var->invariant = true;
+   var->data.invariant = true;
 break;
   case fragment_shader:
 if (var->mode == ir_var_shader_in)
-   var->invariant = true;
+   var->data.invariant = true;
 break;
   }
}
@@ -2647,9 +2647,9 @@ process_initializer(ir_variable *var, ast_declaration 
*decl,
}
 
if (rhs && !rhs->type->is_error()) {
-  bool temp = var->read_only;
+  bool temp = var->data.read_only;
   if (type->qualifier.flags.q.constant)
-var->read_only = false;
+var->data.read_only = false;
 
   /* Never emit code to initialize a uniform.
*/
@@ -2688,7 +2688,7 @@ process_initializer(ir_variable *var, ast_declaration 
*decl,
*/
   var->type = initializer_type;
 
-  var->read_only = temp;
+  var->data.read_only = temp;
}
 
return result;
@@ -2856,7 +2856,7 @@ ast_declarator_list::hir(exec_list *instructions,
 "`invariant' after being used",
 earlier->name);
 } else {
-   earlier->invariant = true;
+   earlier->data.invariant = true;
 }
   }
 
@@ -2866,7 +2866,7 @@ ast_declarator_list::hir(exec_list *instructions,
}
 
assert(this->type != NULL);
-   assert(!this->invariant);
+   assert(!this->data.invariant);
 
/* The type specifier may contain a structure definition.  Process that
 * before any of 

[Mesa-dev] [PATCH 0/5] ir_variable data container

[Tapani Pälli]

Hi;

This series change ir_variable to include a data container for bitfields and 
other variables. This helps in variable cloning and serialization, it makes 
serialization easier but also much more maintainable.

I divided the moving of variables as multiple patches to not exceed maximum 
patch size limitation and make it more readable. I've verified individual 
patches by running make and make check between patches. I tested that gallium 
builds ok. I'm not able to run full Piglit suite now (getting file IO errors 
from Python ..) but all the tests I run manually show no regressions. Will try
to get full Piglit run working.

Here is a tree with patches on top:
http://cgit.freedesktop.org/~tpalli/mesa/log/?h=ir_changes

This branch includes 'automatic shader program cache' implementation that 
benefits from having the structure in ir_variable serialization code which is 
more compact and robus than previously:

http://cgit.freedesktop.org/~tpalli/mesa/log/?h=automatic_cache3
(note, contains also many of the fixes Paul Berry proposed for the caching)

My plan is to change some of the other structures too before actual cache 
implementation and this is the starting point.


Tapani Pälli (5):
  glsl: introduce data section to ir_variable
  glsl: move variables in to ir_variable::data, part I
  glsl: move variables in to ir_variable::data, part II
  glsl: move variables in to ir_variable::data, part III
  glsl: modify ir_clone to use memcpy

 src/glsl/ast_array_index.cpp   |   8 +-
 src/glsl/ast_function.cpp  |  16 +-
 src/glsl/ast_to_hir.cpp| 208 ++---
 src/glsl/builtin_variables.cpp |  24 +-
 src/glsl/ir.cpp|  52 ++--
 src/glsl/ir.h  | 340 +++--
 src/glsl/ir_clone.cpp  |  26 +-
 src/glsl/ir_constant_expression.cpp|   2 +-
 src/glsl/ir_function.cpp   |   2 +-
 src/glsl/ir_print_visitor.cpp  |   6 +-
 src/glsl/ir_reader.cpp |  28 +-
 src/glsl/ir_set_program_inouts.cpp |  28 +-
 src/glsl/ir_validate.cpp   |  10 +-
 src/glsl/link_atomics.cpp  |  20 +-
 src/glsl/link_functions.cpp|   8 +-
 src/glsl/link_interface_blocks.cpp |  12 +-
 src/glsl/link_uniform_initializers.cpp |   6 +-
 src/glsl/link_uniforms.cpp |  20 +-
 src/glsl/link_varyings.cpp |  84 ++---
 src/glsl/linker.cpp| 124 
 src/glsl/lower_clip_distance.cpp   |  18 +-
 src/glsl/lower_named_interface_blocks.cpp  |  20 +-
 src/glsl/lower_output_reads.cpp|   2 +-
 src/glsl/lower_packed_varyings.cpp |  20 +-
 src/glsl/lower_ubo_reference.cpp   |   2 +-
 src/glsl/lower_variable_index_to_cond_assign.cpp   |   2 +-
 src/glsl/opt_array_splitting.cpp   |   4 +-
 src/glsl/opt_constant_folding.cpp  |   4 +-
 src/glsl/opt_constant_propagation.cpp  |   4 +-
 src/glsl/opt_constant_variable.cpp |   4 +-
 src/glsl/opt_copy_propagation.cpp  |   4 +-
 src/glsl/opt_copy_propagation_elements.cpp |   4 +-
 src/glsl/opt_cse.cpp   |   2 +-
 src/glsl/opt_dead_builtin_varyings.cpp |  22 +-
 src/glsl/opt_dead_code.cpp |  10 +-
 src/glsl/opt_dead_code_local.cpp   |   2 +-
 src/glsl/opt_flip_matrices.cpp |   4 +-
 src/glsl/opt_function_inlining.cpp |  14 +-
 src/glsl/opt_structure_splitting.cpp   |   4 +-
 src/glsl/opt_tree_grafting.cpp |  10 +-
 src/glsl/tests/builtin_variable_test.cpp   |  98 +++---
 src/glsl/tests/invalidate_locations_test.cpp   |  96 +++---
 src/mesa/drivers/dri/i965/brw_fs.cpp   |  14 +-
 src/mesa/drivers/dri/i965/brw_fs_fp.cpp|   6 +-
 .../drivers/dri/i965/brw_fs_vector_splitting.cpp   |   2 +-
 src/mesa/drivers/dri/i965/brw_fs_visitor.cpp   |  36 +--
 src/mesa/drivers/dri/i965/brw_shader.cpp   |   2 +-
 src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp  |   2 +-
 src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp |  20 +-
 src/mesa/drivers/dri/i965/brw_vec4_vs_visitor.cpp  |   2 +-
 src/mesa/main/ff_fragment_shader.cpp   |   8 +-
 src/mesa/main/shader_query.cpp |  36 +--
 src/mesa/program/ir_to_mesa.cpp|  24 +-
 src/mesa/state_tracker/st_glsl_to_tgsi.cpp |  30 +-
 54 files changed, 775 insertions(+), 781 deletions(-)

-- 
1.8.3.1

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