[Mesa-dev] i965 query object tidying

2013-02-28 Thread Kenneth Graunke
I'm hoping to add support for doing the transform feedback queries in
hardware, rather than software counters (as geometry shaders will break
the CPU-side counting.)

Before I could do that, I had to make the query object code a bit more
understandable, and eliminate globals specific to occlusion queries.

I think it's a lot easier to follow now.  A second series will do the
actual new hardware counter support.

No piglit or es3conform regressions on Ivybridge.  No regressions in
oglconform's occlusion_query and occlusion_query2 tests.

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


[Mesa-dev] [PATCH 01/10] mesa: Add a new QueryCounter() hook for TIMESTAMP queries.

2013-02-28 Thread Kenneth Graunke
In OpenGL, most queries record statistics about operations performed
between a defined beginning and ending point.  However, TIMESTAMP
queries are different: they immediately return a single value, and there
is no start/stop mechanism.

Previously, Mesa implemented TIMESTAMP queries by calling EndQuery
without first calling BeginQuery.  Apparently this is DirectX
convention, and Gallium followed suit.  I personally find the asymmetry
jarring, however---having BeginQuery and EndQuery handle a different set
of enum values looks like a bug.  It's also a bit confusing to mix the
one-shot query with the start/stop model.

So, add a new QueryCounter driver hook for implementing TIMESTAMP.  For
now, fall back to EndQuery to support drivers that don't do the new
mechanism.

Signed-off-by: Kenneth Graunke 
---
 src/mesa/main/dd.h   |  1 +
 src/mesa/main/queryobj.c | 11 ---
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/src/mesa/main/dd.h b/src/mesa/main/dd.h
index 9c818cc..198b9b5 100644
--- a/src/mesa/main/dd.h
+++ b/src/mesa/main/dd.h
@@ -638,6 +638,7 @@ struct dd_function_table {
struct gl_query_object * (*NewQueryObject)(struct gl_context *ctx, GLuint 
id);
void (*DeleteQuery)(struct gl_context *ctx, struct gl_query_object *q);
void (*BeginQuery)(struct gl_context *ctx, struct gl_query_object *q);
+   void (*QueryCounter)(struct gl_context *ctx, struct gl_query_object *q);
void (*EndQuery)(struct gl_context *ctx, struct gl_query_object *q);
void (*CheckQuery)(struct gl_context *ctx, struct gl_query_object *q);
void (*WaitQuery)(struct gl_context *ctx, struct gl_query_object *q);
diff --git a/src/mesa/main/queryobj.c b/src/mesa/main/queryobj.c
index d0c5a25..f0db740 100644
--- a/src/mesa/main/queryobj.c
+++ b/src/mesa/main/queryobj.c
@@ -486,9 +486,14 @@ _mesa_QueryCounter(GLuint id, GLenum target)
q->Result = 0;
q->Ready = GL_FALSE;
 
-   /* QueryCounter is implemented using EndQuery without BeginQuery
-* in drivers. This is actually Direct3D and Gallium convention. */
-   ctx->Driver.EndQuery(ctx, q);
+   if (ctx->Driver.QueryCounter) {
+  ctx->Driver.QueryCounter(ctx, q);
+   } else {
+  /* QueryCounter is implemented using EndQuery without BeginQuery
+   * in drivers. This is actually Direct3D and Gallium convention.
+   */
+  ctx->Driver.EndQuery(ctx, q);
+   }
 }
 
 
-- 
1.8.1.4

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


[Mesa-dev] [PATCH 02/10] i965: Implement the new QueryCounter() hook.

2013-02-28 Thread Kenneth Graunke
This moves the GL_TIMESTAMP handling out of EndQuery.

Signed-off-by: Kenneth Graunke 
---
 src/mesa/drivers/dri/i965/brw_queryobj.c | 27 +--
 1 file changed, 21 insertions(+), 6 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_queryobj.c 
b/src/mesa/drivers/dri/i965/brw_queryobj.c
index cd9c848..0310479 100644
--- a/src/mesa/drivers/dri/i965/brw_queryobj.c
+++ b/src/mesa/drivers/dri/i965/brw_queryobj.c
@@ -307,12 +307,6 @@ brw_end_query(struct gl_context *ctx, struct 
gl_query_object *q)
struct brw_query_object *query = (struct brw_query_object *)q;
 
switch (query->Base.Target) {
-   case GL_TIMESTAMP:
-  drm_intel_bo_unreference(query->bo);
-  query->bo = drm_intel_bo_alloc(intel->bufmgr, "timer query",
-4096, 4096);
-  /* FALLTHROUGH */
-
case GL_TIME_ELAPSED_EXT:
   write_timestamp(intel, query->bo, 1);
   break;
@@ -468,6 +462,26 @@ brw_emit_query_end(struct brw_context *brw)
brw->query.index++;
 }
 
+/**
+ * Driver hook for glQueryCounter().
+ *
+ * This handles GL_TIMESTAMP queries, which perform a pipelined read of the
+ * current GPU time.  This is unlike GL_TIME_ELAPSED, which measures the
+ * time while the query is active.
+ */
+static void
+brw_query_counter(struct gl_context *ctx, struct gl_query_object *q)
+{
+   struct intel_context *intel = intel_context(ctx);
+   struct brw_query_object *query = (struct brw_query_object *) q;
+
+   assert(q->Target == GL_TIMESTAMP);
+
+   drm_intel_bo_unreference(query->bo);
+   query->bo = drm_intel_bo_alloc(intel->bufmgr, "timestamp query", 4096, 
4096);
+   write_timestamp(intel, query->bo, 1);
+}
+
 static uint64_t
 brw_get_timestamp(struct gl_context *ctx)
 {
@@ -490,6 +504,7 @@ void brw_init_queryobj_functions(struct dd_function_table 
*functions)
functions->DeleteQuery = brw_delete_query;
functions->BeginQuery = brw_begin_query;
functions->EndQuery = brw_end_query;
+   functions->QueryCounter = brw_query_counter;
functions->CheckQuery = brw_check_query;
functions->WaitQuery = brw_wait_query;
functions->GetTimestamp = brw_get_timestamp;
-- 
1.8.1.4

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


[Mesa-dev] [PATCH 03/10] i965: Write TIMESTAMP query values into the first buffer element.

2013-02-28 Thread Kenneth Graunke
For timestamp queries, we just write a single value to a BO.  The
natural place to write that is element 0, so we should do that.

Previously, we wrote it into element 1 (the second slot) leaving
element 0 filled with garbage.

Signed-off-by: Kenneth Graunke 
---
 src/mesa/drivers/dri/i965/brw_queryobj.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_queryobj.c 
b/src/mesa/drivers/dri/i965/brw_queryobj.c
index 0310479..c6ed8e2 100644
--- a/src/mesa/drivers/dri/i965/brw_queryobj.c
+++ b/src/mesa/drivers/dri/i965/brw_queryobj.c
@@ -179,12 +179,11 @@ brw_queryobj_get_results(struct gl_context *ctx,
   * The low 32 bits rolls over in ~343 seconds.  Our 36-bit result
   * rolls over every ~69 seconds.
   */
-query->Base.Result = 80 * (results[1] & 0x);
+query->Base.Result = 80 * (results[0] & 0x);
  query->Base.Result &= (1ull << 36) - 1;
   } else {
-query->Base.Result = 1000 * (results[1] >> 32);
+query->Base.Result = 1000 * (results[0] >> 32);
   }
-
   break;
 
case GL_SAMPLES_PASSED_ARB:
@@ -479,7 +478,7 @@ brw_query_counter(struct gl_context *ctx, struct 
gl_query_object *q)
 
drm_intel_bo_unreference(query->bo);
query->bo = drm_intel_bo_alloc(intel->bufmgr, "timestamp query", 4096, 
4096);
-   write_timestamp(intel, query->bo, 1);
+   write_timestamp(intel, query->bo, 0);
 }
 
 static uint64_t
-- 
1.8.1.4

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


[Mesa-dev] [PATCH 04/10] i965: Add a pile of comments to brw_queryobj.c.

2013-02-28 Thread Kenneth Graunke
This code was really difficult to follow, for a number of reasons:

- Queries were handled in four different ways (TIMESTAMP writes a single
  value, TIME_ELAPSED writes a single pair of values, occlusion queries
  write pairs of values for the start and end of each batch, and other
  queries are done entirely in software.  It turns out that there are
  very good reasons each query is handled the way it is, but
  insufficient comments explaining the rationale.

- It wasn't immediately obvious which functions were driver hooks
  and which were helper functions.  For example, brw_query_begin() is
  a driver hook that implements glBeginQuery() for all query types, but
  the similarly named brw_emit_query_begin() is a helper function that's
  only relevant for occlusion queries.

Extra explanatory comments should save me and others from constantly
having to ask how this code works and why various query types are
handled differently.

Signed-off-by: Kenneth Graunke 
---
 src/mesa/drivers/dri/i965/brw_queryobj.c | 159 +++
 1 file changed, 143 insertions(+), 16 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_queryobj.c 
b/src/mesa/drivers/dri/i965/brw_queryobj.c
index c6ed8e2..f02d051 100644
--- a/src/mesa/drivers/dri/i965/brw_queryobj.c
+++ b/src/mesa/drivers/dri/i965/brw_queryobj.c
@@ -34,11 +34,6 @@
  * fragments that passed the depth test, or the hardware timer.  They are
  * appropriately synced with the stage of the pipeline for our extensions'
  * needs.
- *
- * To avoid getting samples from another context's rendering in our results,
- * we capture the counts at the start and end of every batchbuffer while the
- * query is active, and sum up the differences.  (We should do so for
- * GL_TIME_ELAPSED as well, but don't).
  */
 #include "main/imports.h"
 
@@ -48,6 +43,9 @@
 #include "intel_batchbuffer.h"
 #include "intel_reg.h"
 
+/**
+ * Emit PIPE_CONTROLs to write the current GPU timestamp into a buffer.
+ */
 static void
 write_timestamp(struct intel_context *intel, drm_intel_bo *query_bo, int idx)
 {
@@ -90,6 +88,9 @@ write_timestamp(struct intel_context *intel, drm_intel_bo 
*query_bo, int idx)
}
 }
 
+/**
+ * Emit PIPE_CONTROLs to write the PS_DEPTH_COUNT register into a buffer.
+ */
 static void
 write_depth_count(struct intel_context *intel, drm_intel_bo *query_bo, int idx)
 {
@@ -129,7 +130,9 @@ write_depth_count(struct intel_context *intel, drm_intel_bo 
*query_bo, int idx)
}
 }
 
-/** Waits on the query object's BO and totals the results for this query */
+/**
+ * Wait on the query object's BO and calculate the final result.
+ */
 static void
 brw_queryobj_get_results(struct gl_context *ctx,
 struct brw_query_object *query)
@@ -142,6 +145,10 @@ brw_queryobj_get_results(struct gl_context *ctx,
if (query->bo == NULL)
   return;
 
+   /* If the application has requested the query result, but this batch is
+* still contributing to it, flush it now so it'll become available as
+* soon as possible.
+*/
if (drm_intel_bo_references(intel->batch.bo, query->bo))
   intel_batchbuffer_flush(intel);
 
@@ -155,6 +162,9 @@ brw_queryobj_get_results(struct gl_context *ctx,
results = query->bo->virtual;
switch (query->Base.Target) {
case GL_TIME_ELAPSED_EXT:
+  /* The query BO contains the starting and ending timestamps.
+   * Subtract the two and convert to nanoseconds.
+   */
   if (intel->gen >= 6)
 query->Base.Result += 80 * (results[1] - results[0]);
   else
@@ -162,6 +172,7 @@ brw_queryobj_get_results(struct gl_context *ctx,
   break;
 
case GL_TIMESTAMP:
+  /* The query BO contains a single timestamp value in results[0]. */
   if (intel->gen >= 6) {
  /* Our timer is a clock that increments every 80ns (regardless of
   * other clock scaling in the system).  The timestamp register we can
@@ -187,7 +198,16 @@ brw_queryobj_get_results(struct gl_context *ctx,
   break;
 
case GL_SAMPLES_PASSED_ARB:
-  /* Map and count the pixels from the current query BO */
+  /* Loop over pairs of values from the BO, which are the PS_DEPTH_COUNT
+   * value at the start and end of the batchbuffer.  Subtract them to
+   * get the number of fragments which passed the depth test in each
+   * individual batch, and add those differences up to get the number
+   * of fragments for the entire query.
+   *
+   * Note that query->Base.Result may already be non-zero.  We may have
+   * run out of space in the query's BO and allocated a new one.  If so,
+   * this function was already called to accumulate the results so far.
+   */
   for (i = query->first_index; i <= query->last_index; i++) {
 query->Base.Result += results[i * 2 + 1] - results[i * 2];
   }
@@ -195,7 +215,9 @@ brw_queryobj_get_results(struct gl_context *ctx,
 
case GL_ANY_SAMPLES_PASSED:
case GL_ANY_SAMPLES_PASSED_CONSERVATIVE:
-

[Mesa-dev] [PATCH 05/10] i965: Remove brw_query_object::first_index field as it's always 0.

2013-02-28 Thread Kenneth Graunke
brw->query.index is initialized to 0 just a few lines before it's
copied to first_index.

Presumably the idea here was to reuse the query BO for subsequent
queries of the same type, but since that doesn't happen, there's no need
to have the extra code complexity.

Signed-off-by: Kenneth Graunke 
---
 src/mesa/drivers/dri/i965/brw_context.h  | 3 +--
 src/mesa/drivers/dri/i965/brw_queryobj.c | 6 ++
 2 files changed, 3 insertions(+), 6 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_context.h 
b/src/mesa/drivers/dri/i965/brw_context.h
index c173e49..b8a017d 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -728,8 +728,7 @@ struct brw_query_object {
 
/** Last query BO associated with this query. */
drm_intel_bo *bo;
-   /** First index in bo with query data for this object. */
-   int first_index;
+
/** Last index in bo with query data for this object. */
int last_index;
 };
diff --git a/src/mesa/drivers/dri/i965/brw_queryobj.c 
b/src/mesa/drivers/dri/i965/brw_queryobj.c
index f02d051..c520f7b 100644
--- a/src/mesa/drivers/dri/i965/brw_queryobj.c
+++ b/src/mesa/drivers/dri/i965/brw_queryobj.c
@@ -208,7 +208,7 @@ brw_queryobj_get_results(struct gl_context *ctx,
* run out of space in the query's BO and allocated a new one.  If so,
* this function was already called to accumulate the results so far.
*/
-  for (i = query->first_index; i <= query->last_index; i++) {
+  for (i = 0; i <= query->last_index; i++) {
 query->Base.Result += results[i * 2 + 1] - results[i * 2];
   }
   break;
@@ -218,7 +218,7 @@ brw_queryobj_get_results(struct gl_context *ctx,
   /* If the starting and ending PS_DEPTH_COUNT from any of the batches
* differ, then some fragments passed the depth test.
*/
-  for (i = query->first_index; i <= query->last_index; i++) {
+  for (i = 0; i <= query->last_index; i++) {
 if (results[i * 2 + 1] != results[i * 2]) {
 query->Base.Result = GL_TRUE;
 break;
@@ -330,7 +330,6 @@ brw_begin_query(struct gl_context *ctx, struct 
gl_query_object *q)
*/
   drm_intel_bo_unreference(query->bo);
   query->bo = NULL;
-  query->first_index = -1;
   query->last_index = -1;
 
   brw->query.obj = query;
@@ -558,7 +557,6 @@ brw_emit_query_begin(struct brw_context *brw)
   }
   drm_intel_bo_reference(brw->query.bo);
   query->bo = brw->query.bo;
-  query->first_index = brw->query.index;
}
query->last_index = brw->query.index;
brw->query.begin_emitted = true;
-- 
1.8.1.4

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


[Mesa-dev] [PATCH 07/10] i965: Unify query object BO reallocation code.

2013-02-28 Thread Kenneth Graunke
If we haven't allocated a BO yet, we need to do that.  Or, if there
isn't enough room to write another pair of values, we need to gather up
the existing results and start a new one.  This is simple enough.

However, the old code was awkwardly split into two blocks, with a
write_depth_count() placed in the middle.  The new depth count isn't
relevant to gathering the old BO's data, so that can go after the
reallocation is done.  With the two blocks adjacent, we can merge them.

Signed-off-by: Kenneth Graunke 
---
 src/mesa/drivers/dri/i965/brw_queryobj.c | 21 ++---
 1 file changed, 10 insertions(+), 11 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_queryobj.c 
b/src/mesa/drivers/dri/i965/brw_queryobj.c
index 9a366c3..064c8eb 100644
--- a/src/mesa/drivers/dri/i965/brw_queryobj.c
+++ b/src/mesa/drivers/dri/i965/brw_queryobj.c
@@ -532,10 +532,19 @@ brw_emit_query_begin(struct brw_context *brw)
 */
if (brw->query.bo == NULL ||
query->last_index * 2 + 1 >= 4096 / sizeof(uint64_t)) {
+
+  if (query->bo != NULL) {
+ /* The old query BO did not have enough space, so we allocated a new
+  * one.  Gather the results so far (adding up the differences) and
+  * release the old BO.
+  */
+brw_queryobj_get_results(ctx, query);
+  }
   drm_intel_bo_unreference(brw->query.bo);
   brw->query.bo = NULL;
 
   brw->query.bo = drm_intel_bo_alloc(intel->bufmgr, "query", 4096, 1);
+  drm_intel_bo_reference(brw->query.bo);
 
   /* Fill the buffer with zeroes.  This is probably superfluous. */
   drm_intel_bo_map(brw->query.bo, true);
@@ -543,21 +552,11 @@ brw_emit_query_begin(struct brw_context *brw)
   drm_intel_bo_unmap(brw->query.bo);
 
   query->last_index = 0;
+  query->bo = brw->query.bo;
}
 
write_depth_count(intel, brw->query.bo, query->last_index * 2);
 
-   if (query->bo != brw->query.bo) {
-  if (query->bo != NULL) {
- /* The old query BO did not have enough space, so we allocated a new
-  * one.  Gather the results so far (adding up the differences) and
-  * release the old BO.
-  */
-brw_queryobj_get_results(ctx, query);
-  }
-  drm_intel_bo_reference(brw->query.bo);
-  query->bo = brw->query.bo;
-   }
brw->query.begin_emitted = true;
 }
 
-- 
1.8.1.4

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


[Mesa-dev] [PATCH 06/10] i965: Use query->last_index instead of the global brw->query.index.

2013-02-28 Thread Kenneth Graunke
Since we already have an index in the brw_query_object, there's no need
to also keep a global variable that shadows it.

Plus, if we ever add support for more types of queries that still need
the per-batch before/after treatment we do for occlusion queries, we
won't be able to use a single global variable.  In contrast, per-query
object variables will work fine.

Signed-off-by: Kenneth Graunke 
---
 src/mesa/drivers/dri/i965/brw_context.h  |  1 -
 src/mesa/drivers/dri/i965/brw_queryobj.c | 12 ++--
 2 files changed, 6 insertions(+), 7 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_context.h 
b/src/mesa/drivers/dri/i965/brw_context.h
index b8a017d..32d17a3 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -1044,7 +1044,6 @@ struct brw_context
struct {
   struct brw_query_object *obj;
   drm_intel_bo *bo;
-  int index;
   bool begin_emitted;
} query;
 
diff --git a/src/mesa/drivers/dri/i965/brw_queryobj.c 
b/src/mesa/drivers/dri/i965/brw_queryobj.c
index c520f7b..9a366c3 100644
--- a/src/mesa/drivers/dri/i965/brw_queryobj.c
+++ b/src/mesa/drivers/dri/i965/brw_queryobj.c
@@ -531,7 +531,7 @@ brw_emit_query_begin(struct brw_context *brw)
 * buffer's results momentarily.
 */
if (brw->query.bo == NULL ||
-   brw->query.index * 2 + 1 >= 4096 / sizeof(uint64_t)) {
+   query->last_index * 2 + 1 >= 4096 / sizeof(uint64_t)) {
   drm_intel_bo_unreference(brw->query.bo);
   brw->query.bo = NULL;
 
@@ -542,10 +542,10 @@ brw_emit_query_begin(struct brw_context *brw)
   memset((char *)brw->query.bo->virtual, 0, 4096);
   drm_intel_bo_unmap(brw->query.bo);
 
-  brw->query.index = 0;
+  query->last_index = 0;
}
 
-   write_depth_count(intel, brw->query.bo, brw->query.index * 2);
+   write_depth_count(intel, brw->query.bo, query->last_index * 2);
 
if (query->bo != brw->query.bo) {
   if (query->bo != NULL) {
@@ -558,7 +558,6 @@ brw_emit_query_begin(struct brw_context *brw)
   drm_intel_bo_reference(brw->query.bo);
   query->bo = brw->query.bo;
}
-   query->last_index = brw->query.index;
brw->query.begin_emitted = true;
 }
 
@@ -571,14 +570,15 @@ void
 brw_emit_query_end(struct brw_context *brw)
 {
struct intel_context *intel = &brw->intel;
+   struct brw_query_object *query = brw->query.obj;
 
if (!brw->query.begin_emitted)
   return;
 
-   write_depth_count(intel, brw->query.bo, brw->query.index * 2 + 1);
+   write_depth_count(intel, brw->query.bo, query->last_index * 2 + 1);
 
brw->query.begin_emitted = false;
-   brw->query.index++;
+   query->last_index++;
 }
 
 /**
-- 
1.8.1.4

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


[Mesa-dev] [PATCH 08/10] i965: Turn if (query->bo) into an assertion.

2013-02-28 Thread Kenneth Graunke
The code a few lines above calls brw_emit_query_begin() if !query->bo,
and that creates query->bo.  So it should always be non-NULL.

Signed-off-by: Kenneth Graunke 
---
 src/mesa/drivers/dri/i965/brw_queryobj.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_queryobj.c 
b/src/mesa/drivers/dri/i965/brw_queryobj.c
index 064c8eb..c8492d0 100644
--- a/src/mesa/drivers/dri/i965/brw_queryobj.c
+++ b/src/mesa/drivers/dri/i965/brw_queryobj.c
@@ -404,12 +404,12 @@ brw_end_query(struct gl_context *ctx, struct 
gl_query_object *q)
  brw_emit_query_begin(brw);
   }
 
-  if (query->bo) {
-brw_emit_query_end(brw);
+  assert(query->bo);
 
-drm_intel_bo_unreference(brw->query.bo);
-brw->query.bo = NULL;
-  }
+  brw_emit_query_end(brw);
+
+  drm_intel_bo_unreference(brw->query.bo);
+  brw->query.bo = NULL;
 
   brw->query.obj = NULL;
 
-- 
1.8.1.4

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


[Mesa-dev] [PATCH 09/10] i965: Replace the global brw->query.bo variable with query->bo.

2013-02-28 Thread Kenneth Graunke
Again, eliminating a global variable in favor of a per-query object
variable will help in a future where we have more queries in hardware.

Personally, I find this clearer: there's just the query object's BO,
rather than two variables that usually shadow each other.

Signed-off-by: Kenneth Graunke 
---
 src/mesa/drivers/dri/i965/brw_context.h  |  1 -
 src/mesa/drivers/dri/i965/brw_queryobj.c | 22 +++---
 2 files changed, 7 insertions(+), 16 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_context.h 
b/src/mesa/drivers/dri/i965/brw_context.h
index 32d17a3..8560e30 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -1043,7 +1043,6 @@ struct brw_context
 
struct {
   struct brw_query_object *obj;
-  drm_intel_bo *bo;
   bool begin_emitted;
} query;
 
diff --git a/src/mesa/drivers/dri/i965/brw_queryobj.c 
b/src/mesa/drivers/dri/i965/brw_queryobj.c
index c8492d0..d80f624 100644
--- a/src/mesa/drivers/dri/i965/brw_queryobj.c
+++ b/src/mesa/drivers/dri/i965/brw_queryobj.c
@@ -408,9 +408,6 @@ brw_end_query(struct gl_context *ctx, struct 
gl_query_object *q)
 
   brw_emit_query_end(brw);
 
-  drm_intel_bo_unreference(brw->query.bo);
-  brw->query.bo = NULL;
-
   brw->query.obj = NULL;
 
   intel->stats_wm--;
@@ -530,8 +527,7 @@ brw_emit_query_begin(struct brw_context *brw)
 * If not, create a new one of the same size; we'll gather the existing
 * buffer's results momentarily.
 */
-   if (brw->query.bo == NULL ||
-   query->last_index * 2 + 1 >= 4096 / sizeof(uint64_t)) {
+   if (!query->bo || query->last_index * 2 + 1 >= 4096 / sizeof(uint64_t)) {
 
   if (query->bo != NULL) {
  /* The old query BO did not have enough space, so we allocated a new
@@ -540,22 +536,18 @@ brw_emit_query_begin(struct brw_context *brw)
   */
 brw_queryobj_get_results(ctx, query);
   }
-  drm_intel_bo_unreference(brw->query.bo);
-  brw->query.bo = NULL;
 
-  brw->query.bo = drm_intel_bo_alloc(intel->bufmgr, "query", 4096, 1);
-  drm_intel_bo_reference(brw->query.bo);
+  query->bo = drm_intel_bo_alloc(intel->bufmgr, "query", 4096, 1);
 
   /* Fill the buffer with zeroes.  This is probably superfluous. */
-  drm_intel_bo_map(brw->query.bo, true);
-  memset((char *)brw->query.bo->virtual, 0, 4096);
-  drm_intel_bo_unmap(brw->query.bo);
+  drm_intel_bo_map(query->bo, true);
+  memset((char *) query->bo->virtual, 0, 4096);
+  drm_intel_bo_unmap(query->bo);
 
   query->last_index = 0;
-  query->bo = brw->query.bo;
}
 
-   write_depth_count(intel, brw->query.bo, query->last_index * 2);
+   write_depth_count(intel, query->bo, query->last_index * 2);
 
brw->query.begin_emitted = true;
 }
@@ -574,7 +566,7 @@ brw_emit_query_end(struct brw_context *brw)
if (!brw->query.begin_emitted)
   return;
 
-   write_depth_count(intel, brw->query.bo, query->last_index * 2 + 1);
+   write_depth_count(intel, query->bo, query->last_index * 2 + 1);
 
brw->query.begin_emitted = false;
query->last_index++;
-- 
1.8.1.4

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


[Mesa-dev] [PATCH 10/10] i965: Pull query BO reallocation out into a helper function.

2013-02-28 Thread Kenneth Graunke
We'll want to reuse this for non-occlusion queries in the future.

Plus, it's a single logical task, so having it as a helper function
clarifies the code somewhat.

Signed-off-by: Kenneth Graunke 
---
 src/mesa/drivers/dri/i965/brw_queryobj.c | 56 +++-
 1 file changed, 33 insertions(+), 23 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_queryobj.c 
b/src/mesa/drivers/dri/i965/brw_queryobj.c
index d80f624..9a38be1 100644
--- a/src/mesa/drivers/dri/i965/brw_queryobj.c
+++ b/src/mesa/drivers/dri/i965/brw_queryobj.c
@@ -489,6 +489,38 @@ static void brw_check_query(struct gl_context *ctx, struct 
gl_query_object *q)
 }
 
 /**
+ * Ensure there query's BO has enough space to store a new pair of values.
+ *
+ * If not, gather the existing BO's results and create a new buffer of the
+ * same size.
+ */
+static void
+ensure_bo_has_space(struct gl_context *ctx, struct brw_query_object *query)
+{
+   struct intel_context *intel = intel_context(ctx);
+
+   if (!query->bo || query->last_index * 2 + 1 >= 4096 / sizeof(uint64_t)) {
+
+  if (query->bo != NULL) {
+ /* The old query BO did not have enough space, so we allocated a new
+  * one.  Gather the results so far (adding up the differences) and
+  * release the old BO.
+  */
+brw_queryobj_get_results(ctx, query);
+  }
+
+  query->bo = drm_intel_bo_alloc(intel->bufmgr, "query", 4096, 1);
+
+  /* Fill the buffer with zeroes.  This is probably superfluous. */
+  drm_intel_bo_map(query->bo, true);
+  memset((char *) query->bo->virtual, 0, 4096);
+  drm_intel_bo_unmap(query->bo);
+
+  query->last_index = 0;
+   }
+}
+
+/**
  * Record the PS_DEPTH_COUNT value (for occlusion queries) just before
  * primitive drawing.
  *
@@ -523,29 +555,7 @@ brw_emit_query_begin(struct brw_context *brw)
if (!query || brw->query.begin_emitted)
   return;
 
-   /* Ensure the buffer has enough space to store a new pair of values.
-* If not, create a new one of the same size; we'll gather the existing
-* buffer's results momentarily.
-*/
-   if (!query->bo || query->last_index * 2 + 1 >= 4096 / sizeof(uint64_t)) {
-
-  if (query->bo != NULL) {
- /* The old query BO did not have enough space, so we allocated a new
-  * one.  Gather the results so far (adding up the differences) and
-  * release the old BO.
-  */
-brw_queryobj_get_results(ctx, query);
-  }
-
-  query->bo = drm_intel_bo_alloc(intel->bufmgr, "query", 4096, 1);
-
-  /* Fill the buffer with zeroes.  This is probably superfluous. */
-  drm_intel_bo_map(query->bo, true);
-  memset((char *) query->bo->virtual, 0, 4096);
-  drm_intel_bo_unmap(query->bo);
-
-  query->last_index = 0;
-   }
+   ensure_bo_has_space(ctx, query);
 
write_depth_count(intel, query->bo, query->last_index * 2);
 
-- 
1.8.1.4

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


Re: [Mesa-dev] [PATCH 5/5] r600g: always map uninitialized buffer range as unsynchronized

2013-02-28 Thread Marek Olšák
TF2 doesn't use CP DMA with this patch at all, so I'm not seeing any
issue obviously. This patch is an optimization, not a workaround. It
also doesn't affect CP DMA in any way. It only detects when a buffer
range can be mapped without the CPU-GPU synchronization, which is the
most efficient way of mapping a buffer (no GEM_WAIT_IDLE, no temporary
staging resource, no copying in buffer_unmap).

CP DMA is still probably not reliable with 6xx/7xx, but we won't be
able to use TF2 anymore to test it.

Marek

On Thu, Feb 28, 2013 at 12:46 AM, Alex Deucher  wrote:
> On Wed, Feb 27, 2013 at 6:11 PM, Marek Olšák  wrote:
>> Any driver can implement this simple and efficient optimization.
>> Team Fortress 2 hits it always. The DISCARD_RANGE codepath is not even used
>> with TF2 anymore, so we avoid a ton of useless buffer copies.
>
> With this patch applied are you still seeing issues any issues with CP
> DMA?  If not maybe we can leave it enabled for 6xx/7xx.
>
> Alex
>
>> ---
>>  src/gallium/drivers/r600/evergreen_hw_context.c |3 +++
>>  src/gallium/drivers/r600/evergreen_state.c  |4 
>>  src/gallium/drivers/r600/r600.h |   11 +++
>>  src/gallium/drivers/r600/r600_buffer.c  |   17 +
>>  src/gallium/drivers/r600/r600_hw_context.c  |6 ++
>>  src/gallium/drivers/r600/r600_state_common.c|4 
>>  6 files changed, 45 insertions(+)
>>
>> diff --git a/src/gallium/drivers/r600/evergreen_hw_context.c 
>> b/src/gallium/drivers/r600/evergreen_hw_context.c
>> index b0f64b4..f81d7f3 100644
>> --- a/src/gallium/drivers/r600/evergreen_hw_context.c
>> +++ b/src/gallium/drivers/r600/evergreen_hw_context.c
>> @@ -241,4 +241,7 @@ void evergreen_dma_copy(struct r600_context *rctx,
>> src_offset += csize << shift;
>> size -= csize;
>> }
>> +
>> +   util_range_add(&rdst->valid_buffer_range, dst_offset,
>> +  dst_offset + size);
>>  }
>> diff --git a/src/gallium/drivers/r600/evergreen_state.c 
>> b/src/gallium/drivers/r600/evergreen_state.c
>> index 38f83e9..4a41c28 100644
>> --- a/src/gallium/drivers/r600/evergreen_state.c
>> +++ b/src/gallium/drivers/r600/evergreen_state.c
>> @@ -1376,6 +1376,10 @@ void evergreen_init_color_surface_rat(struct 
>> r600_context *rctx,
>>  * elements. */
>> surf->cb_color_dim = pipe_buffer->width0;
>>
>> +   /* Set the buffer range the GPU will have access to: */
>> +   util_range_add(&r600_resource(pipe_buffer)->valid_buffer_range,
>> +  0, pipe_buffer->width0);
>> +
>> surf->cb_color_cmask = surf->cb_color_base;
>> surf->cb_color_cmask_slice = 0;
>> surf->cb_color_fmask = surf->cb_color_base;
>> diff --git a/src/gallium/drivers/r600/r600.h 
>> b/src/gallium/drivers/r600/r600.h
>> index d018ebb..15196f7 100644
>> --- a/src/gallium/drivers/r600/r600.h
>> +++ b/src/gallium/drivers/r600/r600.h
>> @@ -28,6 +28,7 @@
>>
>>  #include "../../winsys/radeon/drm/radeon_winsys.h"
>>  #include "util/u_double_list.h"
>> +#include "util/u_range.h"
>>  #include "util/u_transfer.h"
>>
>>  #define R600_ERR(fmt, args...) \
>> @@ -50,6 +51,16 @@ struct r600_resource {
>>
>> /* Resource state. */
>> unsigneddomains;
>> +
>> +   /* The buffer range which is initialized (with a write transfer,
>> +* streamout, DMA, or as a random access target). The rest of
>> +* the buffer is considered invalid and can be mapped unsynchronized.
>> +*
>> +* This allows unsychronized mapping of a buffer range which hasn't
>> +* been used yet. It's for applications which forget to use
>> +* the unsynchronized map flag and expect the driver to figure it 
>> out.
>> + */
>> +   struct util_range   valid_buffer_range;
>>  };
>>
>>  #define R600_BLOCK_MAX_BO  32
>> diff --git a/src/gallium/drivers/r600/r600_buffer.c 
>> b/src/gallium/drivers/r600/r600_buffer.c
>> index da6e529..8080611 100644
>> --- a/src/gallium/drivers/r600/r600_buffer.c
>> +++ b/src/gallium/drivers/r600/r600_buffer.c
>> @@ -34,6 +34,7 @@ static void r600_buffer_destroy(struct pipe_screen *screen,
>>  {
>> struct r600_resource *rbuffer = r600_resource(buf);
>>
>> +   util_range_destroy(&rbuffer->valid_buffer_range);
>> pb_reference(&rbuffer->buf, NULL);
>> FREE(rbuffer);
>>  }
>> @@ -98,6 +99,14 @@ static void *r600_buffer_transfer_map(struct pipe_context 
>> *ctx,
>>
>> assert(box->x + box->width <= resource->width0);
>>
>> +   /* See if the buffer range being mapped has never been initialized,
>> +* in which case it can be mapped unsynchronized. */
>> +   if (!(usage & PIPE_TRANSFER_UNSYNCHRONIZED) &&
>> +   usage & PIPE_TRANSFER_WRITE &&
>> +   !util_ranges_intersect(&rbuffer->valid_buffer_range, box->x, 
>> box->x + box->width)) {
>> +   usage |= PIPE_TRANSFER

Re: [Mesa-dev] [PATCH 4/5] gallium/util: add helper code for 1D integer range

2013-02-28 Thread Marek Olšák
On Thu, Feb 28, 2013 at 12:50 AM, Brian Paul  wrote:
> On 02/27/2013 04:11 PM, Marek Olšák wrote:
>>
>> ---
>>   src/gallium/auxiliary/util/u_range.h |   91
>> ++
>>   1 file changed, 91 insertions(+)
>>   create mode 100644 src/gallium/auxiliary/util/u_range.h
>>
>> diff --git a/src/gallium/auxiliary/util/u_range.h
>> b/src/gallium/auxiliary/util/u_range.h
>> new file mode 100644
>> index 000..ae9cc37
>> --- /dev/null
>> +++ b/src/gallium/auxiliary/util/u_range.h
>> @@ -0,0 +1,91 @@
>> +/*
>> + * Copyright 2013 Marek Olšák
>> + *
>> + * Permission is hereby granted, free of charge, to any person obtaining
>> a
>> + * copy of this software and associated documentation files (the
>> "Software"),
>> + * to deal in the Software without restriction, including without
>> limitation
>> + * on the rights to use, copy, modify, merge, publish, distribute, sub
>> + * license, and/or sell copies of the Software, and to permit persons to
>> whom
>> + * the Software is furnished to do so, subject to the following
>> conditions:
>> + *
>> + * The above copyright notice and this permission notice (including the
>> next
>> + * paragraph) shall be included in all copies or substantial portions of
>> the
>> + * Software.
>> + *
>> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
>> EXPRESS OR
>> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
>> MERCHANTABILITY,
>> + * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT
>> SHALL
>> + * THE AUTHOR(S) AND/OR THEIR SUPPLIERS BE LIABLE FOR ANY CLAIM,
>> + * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
>> + * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR
>> THE
>> + * USE OR OTHER DEALINGS IN THE SOFTWARE. */
>> +
>> +/**
>> + * @file
>> + * 1D integer range, capable of the union and intersection operations.
>> + *
>> + * It only maintains a single interval which is extended when the union
>> is
>> + * done. This implementation is partially thread-safe (readers are not
>> + * protected by a lock).
>> + *
>> + * @author Marek Olšák
>> + */
>> +
>> +#ifndef U_RANGE_H
>> +#define U_RANGE_H
>> +
>> +#include "os/os_thread.h"
>
>
> #include "pipe/p_compiler.h" for completeness?

That's included by os_thread.h already.

>
>
>
>> +
>> +struct util_range {
>> +   unsigned start; /* inclusive */
>> +   unsigned end; /* exclusive */
>> +
>> +   /* for the range to be consistent with multiple contexts: */
>> +   pipe_mutex write_mutex;
>> +};
>
>
> 3-space indentation?

Ah yes. I originally developed the code in r600g, which uses tabs.

>
>
>
>> +
>> +
>> +static INLINE void
>> +util_range_set_empty(struct util_range *range)
>> +{
>> +   range->start = ~0;
>> +   range->end = 0;
>> +}
>
>
> Would a util_range_is_empty() function be useful?

I don't need it at the moment. It can be added once someone needs it.

>
>
>
>> +
>> +/* This is like a union of two sets. */
>> +static INLINE void
>> +util_range_add(struct util_range *range, unsigned start, unsigned end)
>> +{
>> +   if (start<  range->start || end>  range->end) {
>> +   pipe_mutex_lock(range->write_mutex);
>> +   if (start<  range->start)
>> +   range->start = start;
>> +   if (end>  range->end)
>> +   range->end = end;
>
>
> How about:
>range->start = MIN2(range->start, start);
>range->end = MAX2(range->end, end);

Looks nicer, alright.

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


Re: [Mesa-dev] [PATCH 3/5] Bug fix: skip padding in get_called_parameter_string

2013-02-28 Thread Kenneth Graunke

On 02/27/2013 04:58 PM, Eric Anholt wrote:

From: Paul Berry 

This bug is currently benign, since get_called_parameter_string() is
currently only used for functions that return true for
glx_function.has_different_protocol(), and none of those functions
include padding.  However, in order to implement marshalling of GL API
functions, we'll need to use get_called_parameter_string() far more
often.
---
  src/mapi/glapi/gen/gl_XML.py |2 ++
  1 file changed, 2 insertions(+)

diff --git a/src/mapi/glapi/gen/gl_XML.py b/src/mapi/glapi/gen/gl_XML.py
index 227e9fc..3bbc794 100644
--- a/src/mapi/glapi/gen/gl_XML.py
+++ b/src/mapi/glapi/gen/gl_XML.py
@@ -802,6 +802,8 @@ class gl_function( gl_item ):
  comma = ""

  for p in self.parameterIterator():
+if p.is_padding:
+continue
  p_string = p_string + comma + p.name
  comma = ", "


Patches 1-3 are:
Reviewed-by: Kenneth Graunke 

but need a proper prefix in the commit message (i.e. "mesa:")

I don't know how the counter mechanism works, so I don't feel qualified 
to review 4 and 5.


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


[Mesa-dev] [Bug 61415] Clover ignores --with-opencl-libdir path

2013-02-28 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=61415

Francisco Jerez  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---
 CC||matts...@gmail.com

--- Comment #9 from Francisco Jerez  ---
(In reply to comment #7)
> Please could you clarify what libraries should be installed into this
> directory? 
> 
> I was building i965 r600g and clover all together and wasn't seeing anything
> in there

Looking through the commit logs, this seems to have broken it:

> commit 45270fb0fd1abd7619933c2845f9dc74cdfbe6fd
> Author: Matt Turner 
> Date:   Thu Sep 13 10:45:01 2012 -0700
> 
> targets/pipe-loader: Convert to automake
> 

After this commit the PIPE_INSTALL_DIR environment variable is ignored and pipe
libraries are installed unconditionally into "$(libdir)/gallium-pipe" (which
seems OK by itself but it breaks the expected behaviour of the
"--with-opencl-libdir" configure option). A possible solution would be to
rename this option to "--with-pipe-libdir" (or something similar) and fix
"targets/pipe-loader/Makefile.am" to take it into account correctly.

Reopening and adding Matt to the CC list.

-- 
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] r600g: status of my work on the shader optimization

2013-02-28 Thread Henri Verbeet
All the Wine D3D tests now (3931289ab5fc7c7e2ab46e6316e55adc19ec3cfc)
pass for me on Cayman. I may be able to do some more testing later,
and do e.g. a piglit run.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] r600g: status of my work on the shader optimization

2013-02-28 Thread Sebastien Caty
On February 28, 2013 12:19:30 PM Vadim Girlin wrote:
> > Do you still need some piglit test on rv790 hardware? I've also tried
> > running Serious Sam 3 with the standard, llvm and your optimized backend
> > and SS3 finally manages to not be a slideshow above the lowest settings.
> > Great improvement but unfortunately there is some graphic corruption. Let
> > me know what you need, I'm willing to test!
> 
> Make sure that you have recent patches, some problems with R7xx chips
> were fixed yesterday. 

Indeed, updated to commit 3931289ab5fc7c7e2ab46e6316e55adc19ec3cfc and things 
looks better, but also now much more funnier.

http://steamcommunity.com/sharedfiles/filedetails/?id=129994352
http://steamcommunity.com/sharedfiles/filedetails/?id=129994334

> Then please check if there are any regressions
> with piglit tests (as compared to the piglit results with R600_SB=0). If
> there are regressions, send me the shader dumps printed when you run the
> regressed tests with "R600_SB_DUMP=3 R600_DUMP_SHADERS=2". If you could
> also figure out the failing shader in each case (as described in [1]),
> this will help to spot the problem. Also you might want to check if
> there are any problems with some other more simple and/or open-source
> applications, so that it will be easier for me to reproduce the issue
> (if it's not r7xx-specific). One more way to help me with debugging your
> issue with SS3 is to use apitrace to create the minimal trace that
> reproduces it (again, if only it's not r7xx-specific, so that it may be
> reproduced with my evergreen card, otherwise you could try to apply the
> method [1] to locate the guilty shader and send me the shader dump).
> Anyway, it's better to start with piglit - it's usually a lot easier to
> debug any issues with a small and simple apps such as the piglit tests.


Ok I'll start with piglit first, SS3 intro gave me 353 shaders.

> Vadim
> 
> [1]: see section "Regression debugging" at
>   http://people.freedesktop.org/~vadimg/r600-sb.html
> 
> >> Vadim
> > 
> > ___
> > 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 5/5] r600g: always map uninitialized buffer range as unsynchronized

2013-02-28 Thread Alex Deucher
On Thu, Feb 28, 2013 at 4:05 AM, Marek Olšák  wrote:
> TF2 doesn't use CP DMA with this patch at all, so I'm not seeing any
> issue obviously. This patch is an optimization, not a workaround. It
> also doesn't affect CP DMA in any way. It only detects when a buffer
> range can be mapped without the CPU-GPU synchronization, which is the
> most efficient way of mapping a buffer (no GEM_WAIT_IDLE, no temporary
> staging resource, no copying in buffer_unmap).
>
> CP DMA is still probably not reliable with 6xx/7xx, but we won't be
> able to use TF2 anymore to test it.

Well, it's possible there are hardware issues with it, but CP DMA has
been around since r100 and from what I can tell internally, it's
pretty reliable.  I think the issue with TF2 were more circumstantial,
due to the combination of state and buffers (even streamout failed to
work correctly in those circumstances).  Maybe a env var to
selectively enable it?  I'm not pressed either way, just seems a shame
not to use it.

Alex

>
> Marek
>
> On Thu, Feb 28, 2013 at 12:46 AM, Alex Deucher  wrote:
>> On Wed, Feb 27, 2013 at 6:11 PM, Marek Olšák  wrote:
>>> Any driver can implement this simple and efficient optimization.
>>> Team Fortress 2 hits it always. The DISCARD_RANGE codepath is not even used
>>> with TF2 anymore, so we avoid a ton of useless buffer copies.
>>
>> With this patch applied are you still seeing issues any issues with CP
>> DMA?  If not maybe we can leave it enabled for 6xx/7xx.
>>
>> Alex
>>
>>> ---
>>>  src/gallium/drivers/r600/evergreen_hw_context.c |3 +++
>>>  src/gallium/drivers/r600/evergreen_state.c  |4 
>>>  src/gallium/drivers/r600/r600.h |   11 +++
>>>  src/gallium/drivers/r600/r600_buffer.c  |   17 +
>>>  src/gallium/drivers/r600/r600_hw_context.c  |6 ++
>>>  src/gallium/drivers/r600/r600_state_common.c|4 
>>>  6 files changed, 45 insertions(+)
>>>
>>> diff --git a/src/gallium/drivers/r600/evergreen_hw_context.c 
>>> b/src/gallium/drivers/r600/evergreen_hw_context.c
>>> index b0f64b4..f81d7f3 100644
>>> --- a/src/gallium/drivers/r600/evergreen_hw_context.c
>>> +++ b/src/gallium/drivers/r600/evergreen_hw_context.c
>>> @@ -241,4 +241,7 @@ void evergreen_dma_copy(struct r600_context *rctx,
>>> src_offset += csize << shift;
>>> size -= csize;
>>> }
>>> +
>>> +   util_range_add(&rdst->valid_buffer_range, dst_offset,
>>> +  dst_offset + size);
>>>  }
>>> diff --git a/src/gallium/drivers/r600/evergreen_state.c 
>>> b/src/gallium/drivers/r600/evergreen_state.c
>>> index 38f83e9..4a41c28 100644
>>> --- a/src/gallium/drivers/r600/evergreen_state.c
>>> +++ b/src/gallium/drivers/r600/evergreen_state.c
>>> @@ -1376,6 +1376,10 @@ void evergreen_init_color_surface_rat(struct 
>>> r600_context *rctx,
>>>  * elements. */
>>> surf->cb_color_dim = pipe_buffer->width0;
>>>
>>> +   /* Set the buffer range the GPU will have access to: */
>>> +   util_range_add(&r600_resource(pipe_buffer)->valid_buffer_range,
>>> +  0, pipe_buffer->width0);
>>> +
>>> surf->cb_color_cmask = surf->cb_color_base;
>>> surf->cb_color_cmask_slice = 0;
>>> surf->cb_color_fmask = surf->cb_color_base;
>>> diff --git a/src/gallium/drivers/r600/r600.h 
>>> b/src/gallium/drivers/r600/r600.h
>>> index d018ebb..15196f7 100644
>>> --- a/src/gallium/drivers/r600/r600.h
>>> +++ b/src/gallium/drivers/r600/r600.h
>>> @@ -28,6 +28,7 @@
>>>
>>>  #include "../../winsys/radeon/drm/radeon_winsys.h"
>>>  #include "util/u_double_list.h"
>>> +#include "util/u_range.h"
>>>  #include "util/u_transfer.h"
>>>
>>>  #define R600_ERR(fmt, args...) \
>>> @@ -50,6 +51,16 @@ struct r600_resource {
>>>
>>> /* Resource state. */
>>> unsigneddomains;
>>> +
>>> +   /* The buffer range which is initialized (with a write transfer,
>>> +* streamout, DMA, or as a random access target). The rest of
>>> +* the buffer is considered invalid and can be mapped 
>>> unsynchronized.
>>> +*
>>> +* This allows unsychronized mapping of a buffer range which hasn't
>>> +* been used yet. It's for applications which forget to use
>>> +* the unsynchronized map flag and expect the driver to figure it 
>>> out.
>>> + */
>>> +   struct util_range   valid_buffer_range;
>>>  };
>>>
>>>  #define R600_BLOCK_MAX_BO  32
>>> diff --git a/src/gallium/drivers/r600/r600_buffer.c 
>>> b/src/gallium/drivers/r600/r600_buffer.c
>>> index da6e529..8080611 100644
>>> --- a/src/gallium/drivers/r600/r600_buffer.c
>>> +++ b/src/gallium/drivers/r600/r600_buffer.c
>>> @@ -34,6 +34,7 @@ static void r600_buffer_destroy(struct pipe_screen 
>>> *screen,
>>>  {
>>> struct r600_resource *rbuffer = r600_resource(buf);
>>>
>>> +   util_range_destroy(&rbuffer->valid_buffer_range);
>>> pb_refer

[Mesa-dev] [Bug 61455] Feature request: implement wglMakeContextCurrentARB in Gallium

2013-02-28 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=61455

José Fonseca  changed:

   What|Removed |Added

 CC||bri...@vmware.com,
   ||jfons...@vmware.com

--- Comment #1 from José Fonseca  ---
This sort of WGL extensions are quite tricky to get implemented right, because
we have to workaround Microsoft OpenGL runtime and cheat it.

Could you provide a simple test case for this?

-- 
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 61366] oprofilejit should be included in the list of LLVM components required

2013-02-28 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=61366

José Fonseca  changed:

   What|Removed |Added

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

--- Comment #1 from José Fonseca  ---
Commited. Thanks.

commit 2506b035031d6022fec0465bffac8eedd43de0f9
Author: Adam Sampson 
Date:   Thu Feb 28 15:35:11 2013 +

autotools: oprofilejit should be included in the list of LLVM components
required

NOTE: This is a candidate for the stable branch.

Signed-off-by: José Fonseca 

-- 
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 61299] LLVM 3.2 fails to link with Mesa 9.0.2 on Windows; missing link libraries

2013-02-28 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=61299

José Fonseca  changed:

   What|Removed |Added

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

--- Comment #3 from José Fonseca  ---
Pushed. Thanks.

commit efd8311a54a945953d5372dded0d6f88349bf58b
Author: Keith Kriewall 
Date:   Thu Feb 28 15:40:02 2013 +

scons: Fix Windows build with LLVM 3.2

Fixes fdo bug 61299

NOTE: This is a candidate for the stable branches.

Signed-off-by: José Fonseca 

-- 
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 60706] [llvmpipe] piglit fbo-blending-formats GL_EXT_texture_snorm regression with llvm-3.3svn

2013-02-28 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=60706

José Fonseca  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Assignee|mesa-dev@lists.freedesktop. |srol...@vmware.com
   |org |
 CC||jfons...@vmware.com

--- Comment #5 from José Fonseca  ---
This has been fixed upstream. Thanks Roland, Vinson.

-- 
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 5/5] r600g: always map uninitialized buffer range as unsynchronized

2013-02-28 Thread Marek Olšák
On Thu, Feb 28, 2013 at 4:26 PM, Alex Deucher  wrote:
> On Thu, Feb 28, 2013 at 4:05 AM, Marek Olšák  wrote:
>> TF2 doesn't use CP DMA with this patch at all, so I'm not seeing any
>> issue obviously. This patch is an optimization, not a workaround. It
>> also doesn't affect CP DMA in any way. It only detects when a buffer
>> range can be mapped without the CPU-GPU synchronization, which is the
>> most efficient way of mapping a buffer (no GEM_WAIT_IDLE, no temporary
>> staging resource, no copying in buffer_unmap).
>>
>> CP DMA is still probably not reliable with 6xx/7xx, but we won't be
>> able to use TF2 anymore to test it.
>
> Well, it's possible there are hardware issues with it, but CP DMA has
> been around since r100 and from what I can tell internally, it's
> pretty reliable.  I think the issue with TF2 were more circumstantial,
> due to the combination of state and buffers (even streamout failed to
> work correctly in those circumstances).  Maybe a env var to
> selectively enable it?  I'm not pressed either way, just seems a shame
> not to use it.

IIRC, this the status of the various methods and their reliability:

R600:
streamout - garbled screen with TF2
CP DMA - never enabled due to issues
async DMA - never enabled due to issues

R700:
streamout - garbled screen with TF2
CP DMA - garbled screen with TF2
async DMA - works

Evergreen:
streamout - works
CP DMA - works
async DMA - works

Considering that TF2 is fixed with this patch, I'll discard the patch
disallowing DISCARD_RANGE handling on r6xx and the patch disallowing
CP DMA on r7xx.

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


Re: [Mesa-dev] [PATCH 5/5] r600g: always map uninitialized buffer range as unsynchronized

2013-02-28 Thread Alex Deucher
On Thu, Feb 28, 2013 at 11:11 AM, Marek Olšák  wrote:
> On Thu, Feb 28, 2013 at 4:26 PM, Alex Deucher  wrote:
>> On Thu, Feb 28, 2013 at 4:05 AM, Marek Olšák  wrote:
>>> TF2 doesn't use CP DMA with this patch at all, so I'm not seeing any
>>> issue obviously. This patch is an optimization, not a workaround. It
>>> also doesn't affect CP DMA in any way. It only detects when a buffer
>>> range can be mapped without the CPU-GPU synchronization, which is the
>>> most efficient way of mapping a buffer (no GEM_WAIT_IDLE, no temporary
>>> staging resource, no copying in buffer_unmap).
>>>
>>> CP DMA is still probably not reliable with 6xx/7xx, but we won't be
>>> able to use TF2 anymore to test it.
>>
>> Well, it's possible there are hardware issues with it, but CP DMA has
>> been around since r100 and from what I can tell internally, it's
>> pretty reliable.  I think the issue with TF2 were more circumstantial,
>> due to the combination of state and buffers (even streamout failed to
>> work correctly in those circumstances).  Maybe a env var to
>> selectively enable it?  I'm not pressed either way, just seems a shame
>> not to use it.
>
> IIRC, this the status of the various methods and their reliability:
>
> R600:
> streamout - garbled screen with TF2
> CP DMA - never enabled due to issues
> async DMA - never enabled due to issues
>
> R700:
> streamout - garbled screen with TF2
> CP DMA - garbled screen with TF2
> async DMA - works
>
> Evergreen:
> streamout - works
> CP DMA - works
> async DMA - works
>
> Considering that TF2 is fixed with this patch, I'll discard the patch
> disallowing DISCARD_RANGE handling on r6xx and the patch disallowing
> CP DMA on r7xx.

Sounds good.  Any objections to enabling CP DMA on 6xx via my previous
patch set?

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


[Mesa-dev] [PATCH] attrib: push/pop FRAGMENT_PROGRAM_ARB state

2013-02-28 Thread Jordan Justen
This requirement was added by ARB_fragment_program

When the Steam overlay is enabled, this fixes:
* Menu corruption with the Puddle game
* The screen going black on Rochard when
  the Steam overlay is accessed

NOTE: This is a candidate for the 9.0 and 9.1 branches.

Signed-off-by: Jordan Justen 
---
 src/mesa/main/attrib.c |   12 
 1 file changed, 12 insertions(+)

diff --git a/src/mesa/main/attrib.c b/src/mesa/main/attrib.c
index a951283..6d91534 100644
--- a/src/mesa/main/attrib.c
+++ b/src/mesa/main/attrib.c
@@ -130,6 +130,9 @@ struct gl_enable_attrib
GLboolean VertexProgramPointSize;
GLboolean VertexProgramTwoSide;
 
+   /* GL_ARB_fragment_program */
+   GLboolean FragmentProgram;
+
/* GL_ARB_point_sprite / GL_NV_point_sprite */
GLboolean PointSprite;
GLboolean FragmentShaderATI;
@@ -316,6 +319,10 @@ _mesa_PushAttrib(GLbitfield mask)
   attr->VertexProgram = ctx->VertexProgram.Enabled;
   attr->VertexProgramPointSize = ctx->VertexProgram.PointSizeEnabled;
   attr->VertexProgramTwoSide = ctx->VertexProgram.TwoSideEnabled;
+
+  /* GL_ARB_fragment_program */
+  attr->FragmentProgram = ctx->FragmentProgram.Enabled;
+
   save_attrib_data(&head, GL_ENABLE_BIT, attr);
 
   /* GL_ARB_framebuffer_sRGB / GL_EXT_framebuffer_sRGB */
@@ -607,6 +614,11 @@ pop_enable_group(struct gl_context *ctx, const struct 
gl_enable_attrib *enable)
enable->VertexProgramTwoSide,
GL_VERTEX_PROGRAM_TWO_SIDE_ARB);
 
+   /* GL_ARB_fragment_program */
+   TEST_AND_UPDATE(ctx->FragmentProgram.Enabled,
+   enable->FragmentProgram,
+   GL_FRAGMENT_PROGRAM_ARB);
+
/* GL_ARB_framebuffer_sRGB / GL_EXT_framebuffer_sRGB */
TEST_AND_UPDATE(ctx->Color.sRGBEnabled, enable->sRGBEnabled,
GL_FRAMEBUFFER_SRGB);
-- 
1.7.10.4

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


Re: [Mesa-dev] [PATCH] attrib: push/pop FRAGMENT_PROGRAM_ARB state

2013-02-28 Thread Brian Paul

On 02/28/2013 09:29 AM, Jordan Justen wrote:

This requirement was added by ARB_fragment_program

When the Steam overlay is enabled, this fixes:
* Menu corruption with the Puddle game
* The screen going black on Rochard when
   the Steam overlay is accessed

NOTE: This is a candidate for the 9.0 and 9.1 branches.

Signed-off-by: Jordan Justen
---
  src/mesa/main/attrib.c |   12 
  1 file changed, 12 insertions(+)

diff --git a/src/mesa/main/attrib.c b/src/mesa/main/attrib.c
index a951283..6d91534 100644
--- a/src/mesa/main/attrib.c
+++ b/src/mesa/main/attrib.c
@@ -130,6 +130,9 @@ struct gl_enable_attrib
 GLboolean VertexProgramPointSize;
 GLboolean VertexProgramTwoSide;

+   /* GL_ARB_fragment_program */
+   GLboolean FragmentProgram;
+
 /* GL_ARB_point_sprite / GL_NV_point_sprite */
 GLboolean PointSprite;
 GLboolean FragmentShaderATI;
@@ -316,6 +319,10 @@ _mesa_PushAttrib(GLbitfield mask)
attr->VertexProgram = ctx->VertexProgram.Enabled;
attr->VertexProgramPointSize = ctx->VertexProgram.PointSizeEnabled;
attr->VertexProgramTwoSide = ctx->VertexProgram.TwoSideEnabled;
+
+  /* GL_ARB_fragment_program */
+  attr->FragmentProgram = ctx->FragmentProgram.Enabled;
+
save_attrib_data(&head, GL_ENABLE_BIT, attr);

/* GL_ARB_framebuffer_sRGB / GL_EXT_framebuffer_sRGB */
@@ -607,6 +614,11 @@ pop_enable_group(struct gl_context *ctx, const struct 
gl_enable_attrib *enable)
 enable->VertexProgramTwoSide,
 GL_VERTEX_PROGRAM_TWO_SIDE_ARB);

+   /* GL_ARB_fragment_program */
+   TEST_AND_UPDATE(ctx->FragmentProgram.Enabled,
+   enable->FragmentProgram,
+   GL_FRAGMENT_PROGRAM_ARB);
+
 /* GL_ARB_framebuffer_sRGB / GL_EXT_framebuffer_sRGB */
 TEST_AND_UPDATE(ctx->Color.sRGBEnabled, enable->sRGBEnabled,
 GL_FRAMEBUFFER_SRGB);


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


Re: [Mesa-dev] [PATCH] Fix build of swrast only without libdrm

2013-02-28 Thread Matt Turner
On Thu, Feb 28, 2013 at 3:58 AM, Daniel Martin  wrote:
>
> Signed-off-by: Daniel Martin 
> ---
> There's a small logic error preventing mesa to be build with swrast only
> and not having libdrm.
>
>  configure.ac |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index 5701f8a..aa1b38a 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -1089,7 +1089,7 @@ if test "x$enable_dri" = xyes; then
>  fi
>
>  # if we are building any dri driver other than swrast or using the dri 
> state tracker ...
> -if test -n "$DRI_DIRS" -a x"$DRI_DIRS" != xswrast || test "x$enable_dri" 
> = xyes; then
> +if test -n "$DRI_DIRS" -a x"$DRI_DIRS" != xswrast && test "x$enable_dri" 
> = xyes; then

While modifying this line of code, please change '&& test' to -a.

(mesa patches to go mesa-dev, not dri-devel)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [Bug 61455] Feature request: implement wglMakeContextCurrentARB in Gallium

2013-02-28 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=61455

--- Comment #2 from Keith Kriewall  ---
The mesa demo wincopy uses glMakeContextCurrent.  If you need a test case
beyond this, please let me know.

-- 
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 61455] Feature request: implement wglMakeContextCurrentARB in Gallium

2013-02-28 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=61455

--- Comment #3 from José Fonseca  ---
mesademos/src/xdemos/wincopy.c is an X11 sample, not WGL.  And to test this I'd
really need a wglMakeContextCurrentARB.

Please note that, spite the similarties between glXMakeContextCurrent and
wglMakeContextCurrentARB the implementation of these are miles apart.

A port of wincopy.c to WGL should be fine though.

-- 
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 61455] Feature request: implement wglMakeContextCurrentARB in Gallium

2013-02-28 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=61455

--- Comment #4 from Keith Kriewall  ---
OK, we'll look at porting wincopy to Windows, or writing another test
application.  We're booked up for several days, but I'll get it to you ASAP.

-- 
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 1/4] i965: Fix fulsim assertion failures by aligning HiZ ops to 8x4.

2013-02-28 Thread Eric Anholt
Chad Versace  writes:

> On 02/27/2013 11:39 AM, Eric Anholt wrote:
>> Chad Versace  writes:
>> 
>>> On 02/26/2013 11:15 PM, Eric Anholt wrote:
 I have some debug of HiZ rendering that looks like some rendering is not
 landing in my HiZ buffer.  Unfortunately, fulsim choking on us violating
 hiz rendering rules was preventing me from using it as a debug aid.

 Once we get things reliable, we'll also be able to take advantage of this
 to get fast clears on modes like 1366x768.
 ---
  src/mesa/drivers/dri/i965/brw_blorp.cpp |   10 ++
  1 file changed, 10 insertions(+)

 diff --git a/src/mesa/drivers/dri/i965/brw_blorp.cpp 
 b/src/mesa/drivers/dri/i965/brw_blorp.cpp
 index 5f72b5d..49dcacb 100644
 --- a/src/mesa/drivers/dri/i965/brw_blorp.cpp
 +++ b/src/mesa/drivers/dri/i965/brw_blorp.cpp
 @@ -181,6 +181,16 @@ brw_hiz_op_params::brw_hiz_op_params(struct 
 intel_mipmap_tree *mt,
 this->hiz_op = op;
  
 depth.set(mt, level, layer);
 +
 +   /* HiZ operations require alignment to 8x4.  Our depth and hiz 
 miplevels
 +* should have their start offsets aligned to that (except for a bug on
 +* non-Z16) so we won't draw into a neighboring miplevel, and we 
 allocate
 +* memory aligned to pages (128bytesx32), so we won't draw into memory 
 not
 +* owned by our miptree.
 +*/
 +   depth.width = ALIGN(depth.width, 8);
 +   depth.height = ALIGN(depth.height, 4);
 +
>>>
>>> This should be moved into the brw_hiz_op_params() constructor.
>> 
>> That's where this is.  Were you thinking of a version that was posted in
>> my tree at one point instead?
>
> No, I was talking with my foot in my mouth. :/
>
> I meant it should be set by call to depth.set() above, which is
> brw_blorp_mip_info::set(), like this:
>
>this->width = ALIGN(mt->level[level].width, 8);
>this->height = ALIGN(mt->level[level].height, 4);
>
> The responsibility of setting brw_blorp_mip_info fields should
> belong to that method.

I disagree -- you only want this behavior for HiZ ops on depth/stencil,
not blorp ops in general (like blits with color buffers).


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


Re: [Mesa-dev] [PATCH 05/10] i965: Remove brw_query_object::first_index field as it's always 0.

2013-02-28 Thread Eric Anholt
Kenneth Graunke  writes:

> brw->query.index is initialized to 0 just a few lines before it's
> copied to first_index.
>
> Presumably the idea here was to reuse the query BO for subsequent
> queries of the same type, but since that doesn't happen, there's no need
> to have the extra code complexity.

Yeah, that was the idea.  Only, you also want to avoid keeping the old
query buffer in use for any longer after the old query had ended, or
you'll introduce extra latency on the query results.  So I'm happy to
see this garbage collected now.

(For any other reviewers trying to confirm the assertion that we don't
reuse, it's the drm_intel_bo_unreference(brw->query.bo) in
brw_end_query())

Reviewed-by: Eric Anholt 


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


Re: [Mesa-dev] [PATCH 10/10] i965: Pull query BO reallocation out into a helper function.

2013-02-28 Thread Eric Anholt
Kenneth Graunke  writes:

> We'll want to reuse this for non-occlusion queries in the future.
>
> Plus, it's a single logical task, so having it as a helper function
> clarifies the code somewhat.
>
> Signed-off-by: Kenneth Graunke 
> ---
>  src/mesa/drivers/dri/i965/brw_queryobj.c | 56 
> +++-
>  1 file changed, 33 insertions(+), 23 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_queryobj.c 
> b/src/mesa/drivers/dri/i965/brw_queryobj.c
> index d80f624..9a38be1 100644
> --- a/src/mesa/drivers/dri/i965/brw_queryobj.c
> +++ b/src/mesa/drivers/dri/i965/brw_queryobj.c
> @@ -489,6 +489,38 @@ static void brw_check_query(struct gl_context *ctx, 
> struct gl_query_object *q)
>  }
>  
>  /**
> + * Ensure there query's BO has enough space to store a new pair of values.
> + *
> + * If not, gather the existing BO's results and create a new buffer of the
> + * same size.
> + */
> +static void
> +ensure_bo_has_space(struct gl_context *ctx, struct brw_query_object *query)
> +{
> +   struct intel_context *intel = intel_context(ctx);
> +
> +   if (!query->bo || query->last_index * 2 + 1 >= 4096 / sizeof(uint64_t)) {
> +
> +  if (query->bo != NULL) {
> + /* The old query BO did not have enough space, so we allocated a new
> +  * one.  Gather the results so far (adding up the differences) and
> +  * release the old BO.
> +  */
> +  brw_queryobj_get_results(ctx, query);
> +  }
> +
> +  query->bo = drm_intel_bo_alloc(intel->bufmgr, "query", 4096, 1);
> +
> +  /* Fill the buffer with zeroes.  This is probably superfluous. */
> +  drm_intel_bo_map(query->bo, true);
> +  memset((char *) query->bo->virtual, 0, 4096);
> +  drm_intel_bo_unmap(query->bo);

Pretty sure the char * is totally superfluous.  This isn't c++ here.
That and the tab comment I'd be happy to see just resolved in this
commit.

I've now reviewed the rest of the series, and I'm looking forward to it
landing.


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


Re: [Mesa-dev] [PATCH 04/10] i965: Add a pile of comments to brw_queryobj.c.

2013-02-28 Thread Eric Anholt
Kenneth Graunke  writes:

> This code was really difficult to follow, for a number of reasons:
>
> - Queries were handled in four different ways (TIMESTAMP writes a single
>   value, TIME_ELAPSED writes a single pair of values, occlusion queries
>   write pairs of values for the start and end of each batch, and other
>   queries are done entirely in software.  It turns out that there are
>   very good reasons each query is handled the way it is, but
>   insufficient comments explaining the rationale.
>
> - It wasn't immediately obvious which functions were driver hooks
>   and which were helper functions.  For example, brw_query_begin() is
>   a driver hook that implements glBeginQuery() for all query types, but
>   the similarly named brw_emit_query_begin() is a helper function that's
>   only relevant for occlusion queries.
>
> Extra explanatory comments should save me and others from constantly
> having to ask how this code works and why various query types are
> handled differently.
>
> Signed-off-by: Kenneth Graunke 
> ---
>  src/mesa/drivers/dri/i965/brw_queryobj.c | 159 
> +++
>  1 file changed, 143 insertions(+), 16 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_queryobj.c 
> b/src/mesa/drivers/dri/i965/brw_queryobj.c
> index c6ed8e2..f02d051 100644
> --- a/src/mesa/drivers/dri/i965/brw_queryobj.c
> +++ b/src/mesa/drivers/dri/i965/brw_queryobj.c

> -/** Waits on the query object's BO and totals the results for this query */
> +/**
> + * Wait on the query object's BO and calculate the final result.
> + */
>  static void
>  brw_queryobj_get_results(struct gl_context *ctx,
>struct brw_query_object *query)
> @@ -142,6 +145,10 @@ brw_queryobj_get_results(struct gl_context *ctx,
> if (query->bo == NULL)
>return;
>  
> +   /* If the application has requested the query result, but this batch is
> +* still contributing to it, flush it now so it'll become available as
> +* soon as possible.
> +*/

It's not really about "as soon as possible", it's "so those results will
be present when mapped" -- mapping doesn't batch flush on its own, since
libdrm is unaware of batchbuffers.

Other than that, patches up to this are:

Reviewed-by: Eric Anholt 


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


Re: [Mesa-dev] [PATCH 07/10] i965: Unify query object BO reallocation code.

2013-02-28 Thread Eric Anholt
Kenneth Graunke  writes:

> If we haven't allocated a BO yet, we need to do that.  Or, if there
> isn't enough room to write another pair of values, we need to gather up
> the existing results and start a new one.  This is simple enough.
>
> However, the old code was awkwardly split into two blocks, with a
> write_depth_count() placed in the middle.  The new depth count isn't
> relevant to gathering the old BO's data, so that can go after the
> reallocation is done.  With the two blocks adjacent, we can merge them.
>
> Signed-off-by: Kenneth Graunke 
> ---
>  src/mesa/drivers/dri/i965/brw_queryobj.c | 21 ++---
>  1 file changed, 10 insertions(+), 11 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_queryobj.c 
> b/src/mesa/drivers/dri/i965/brw_queryobj.c
> index 9a366c3..064c8eb 100644
> --- a/src/mesa/drivers/dri/i965/brw_queryobj.c
> +++ b/src/mesa/drivers/dri/i965/brw_queryobj.c
> @@ -532,10 +532,19 @@ brw_emit_query_begin(struct brw_context *brw)
>  */
> if (brw->query.bo == NULL ||
> query->last_index * 2 + 1 >= 4096 / sizeof(uint64_t)) {
> +
> +  if (query->bo != NULL) {
> + /* The old query BO did not have enough space, so we allocated a new
> +  * one.  Gather the results so far (adding up the differences) and
> +  * release the old BO.
> +  */
> +  brw_queryobj_get_results(ctx, query);

Take this opportunity to nuke an indentation tab? :)

Other than that, reviewed.


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


Re: [Mesa-dev] [PATCH 02/10] build: Get rid of SRC_DIRS

2013-02-28 Thread Eric Anholt
Matt Turner  writes:
> diff --git a/configure.ac b/configure.ac
> index 9178355..f25d488 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -732,6 +732,7 @@ if test "x$enable_glx" = xyes -a \
>  enable_glx=no
>  fi
>  
> +AM_CONDITIONAL(HAVE_GLX, test "x$enable_glx" = xyes)

Looks like we'll start building src/glx for the enable_xlib_glx case,
which we shouldn't.

>  echo ""
> -if echo "$SRC_DIRS" | grep 'gallium' >/dev/null 2>&1; then
> +if test -n "x$with_gallium_drivers"; then

won't test -n always be true, because of the x?

On src/Makefile.am removal:

I'm convinced that automake doesn't actually support nonrecursive make
for non-toy projects -- the dependency tracking has major issues for
same-named files in different directories, and files moving between
directories.  As such, I don't think that incrementally moving towards
nonrecursive makes much sense -- the build performance difference is
hardly measurable, and it just makes it less obvious which Makefile.am
you should go looking in to find the build stuff you want to edit.

On the other hand, I'm so glad to see progress towards make distcheck
that I'll go along with src/Makefile.am removal. :)


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


[Mesa-dev] [PATCH] Fix build of swrast only without libdrm

2013-02-28 Thread Daniel Martin

Signed-off-by: Daniel Martin 
---
There's a small logic error preventing mesa to be build with swrast only
and not having libdrm.

v2: "|| test" replaced by "-a"

 configure.ac | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index 5f95a78..7852595 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1095,7 +1095,7 @@ if test "x$enable_dri" = xyes; then
 fi
 
 # if we are building any dri driver other than swrast or using the dri 
state tracker ...
-if test -n "$DRI_DIRS" -a x"$DRI_DIRS" != xswrast || test "x$enable_dri" = 
xyes; then
+if test -n "$DRI_DIRS" -a x"$DRI_DIRS" != xswrast -a "x$enable_dri" = 
xyes; then
 # ... libdrm is required
 if test "x$have_libdrm" != xyes; then
 AC_MSG_ERROR([DRI drivers requires libdrm >= $LIBDRM_REQUIRED])
-- 
1.8.1.4

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


Re: [Mesa-dev] [PATCH] attrib: push/pop FRAGMENT_PROGRAM_ARB state

2013-02-28 Thread Kenneth Graunke

On 02/28/2013 08:29 AM, Jordan Justen wrote:

This requirement was added by ARB_fragment_program

When the Steam overlay is enabled, this fixes:
* Menu corruption with the Puddle game
* The screen going black on Rochard when
   the Steam overlay is accessed

NOTE: This is a candidate for the 9.0 and 9.1 branches.

Signed-off-by: Jordan Justen 
---
  src/mesa/main/attrib.c |   12 
  1 file changed, 12 insertions(+)

diff --git a/src/mesa/main/attrib.c b/src/mesa/main/attrib.c
index a951283..6d91534 100644
--- a/src/mesa/main/attrib.c
+++ b/src/mesa/main/attrib.c
@@ -130,6 +130,9 @@ struct gl_enable_attrib
 GLboolean VertexProgramPointSize;
 GLboolean VertexProgramTwoSide;

+   /* GL_ARB_fragment_program */
+   GLboolean FragmentProgram;
+
 /* GL_ARB_point_sprite / GL_NV_point_sprite */
 GLboolean PointSprite;
 GLboolean FragmentShaderATI;
@@ -316,6 +319,10 @@ _mesa_PushAttrib(GLbitfield mask)
attr->VertexProgram = ctx->VertexProgram.Enabled;
attr->VertexProgramPointSize = ctx->VertexProgram.PointSizeEnabled;
attr->VertexProgramTwoSide = ctx->VertexProgram.TwoSideEnabled;
+
+  /* GL_ARB_fragment_program */
+  attr->FragmentProgram = ctx->FragmentProgram.Enabled;
+
save_attrib_data(&head, GL_ENABLE_BIT, attr);

/* GL_ARB_framebuffer_sRGB / GL_EXT_framebuffer_sRGB */
@@ -607,6 +614,11 @@ pop_enable_group(struct gl_context *ctx, const struct 
gl_enable_attrib *enable)
 enable->VertexProgramTwoSide,
 GL_VERTEX_PROGRAM_TWO_SIDE_ARB);

+   /* GL_ARB_fragment_program */
+   TEST_AND_UPDATE(ctx->FragmentProgram.Enabled,
+   enable->FragmentProgram,
+   GL_FRAGMENT_PROGRAM_ARB);
+
 /* GL_ARB_framebuffer_sRGB / GL_EXT_framebuffer_sRGB */
 TEST_AND_UPDATE(ctx->Color.sRGBEnabled, enable->sRGBEnabled,
 GL_FRAMEBUFFER_SRGB);



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


Re: [Mesa-dev] [PATCH 1/4] i965: Fix fulsim assertion failures by aligning HiZ ops to 8x4.

2013-02-28 Thread Kenneth Graunke

On 02/28/2013 09:08 AM, Eric Anholt wrote:

Chad Versace  writes:


On 02/27/2013 11:39 AM, Eric Anholt wrote:

Chad Versace  writes:


On 02/26/2013 11:15 PM, Eric Anholt wrote:

I have some debug of HiZ rendering that looks like some rendering is not
landing in my HiZ buffer.  Unfortunately, fulsim choking on us violating
hiz rendering rules was preventing me from using it as a debug aid.

Once we get things reliable, we'll also be able to take advantage of this
to get fast clears on modes like 1366x768.
---
  src/mesa/drivers/dri/i965/brw_blorp.cpp |   10 ++
  1 file changed, 10 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/brw_blorp.cpp 
b/src/mesa/drivers/dri/i965/brw_blorp.cpp
index 5f72b5d..49dcacb 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp.cpp
+++ b/src/mesa/drivers/dri/i965/brw_blorp.cpp
@@ -181,6 +181,16 @@ brw_hiz_op_params::brw_hiz_op_params(struct 
intel_mipmap_tree *mt,
 this->hiz_op = op;

 depth.set(mt, level, layer);
+
+   /* HiZ operations require alignment to 8x4.  Our depth and hiz miplevels
+* should have their start offsets aligned to that (except for a bug on
+* non-Z16) so we won't draw into a neighboring miplevel, and we allocate
+* memory aligned to pages (128bytesx32), so we won't draw into memory not
+* owned by our miptree.
+*/
+   depth.width = ALIGN(depth.width, 8);
+   depth.height = ALIGN(depth.height, 4);
+


This should be moved into the brw_hiz_op_params() constructor.


That's where this is.  Were you thinking of a version that was posted in
my tree at one point instead?


No, I was talking with my foot in my mouth. :/

I meant it should be set by call to depth.set() above, which is
brw_blorp_mip_info::set(), like this:

this->width = ALIGN(mt->level[level].width, 8);
this->height = ALIGN(mt->level[level].height, 4);

The responsibility of setting brw_blorp_mip_info fields should
belong to that method.


I disagree -- you only want this behavior for HiZ ops on depth/stencil,
not blorp ops in general (like blits with color buffers).


My vote is with Eric on this one.  I wrote an identical patch, and put 
it in brw_hiz_op_params for that very reason.


However, in order for this to not break horribly, don't you need to edit 
the intel/brw_tex_layout code to actually pad the buffer to have that 
extra width?  Otherwise you could access outside the buffer (and I 
could've sworn I actually hit that case while trying this).


I believe Chad has patches to do that...
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 1/4] i965: Fix fulsim assertion failures by aligning HiZ ops to 8x4.

2013-02-28 Thread Chad Versace
On 02/28/2013 11:01 AM, Kenneth Graunke wrote:
> On 02/28/2013 09:08 AM, Eric Anholt wrote:
>> Chad Versace  writes:
>>
>>> On 02/27/2013 11:39 AM, Eric Anholt wrote:
 Chad Versace  writes:

> On 02/26/2013 11:15 PM, Eric Anholt wrote:
>> I have some debug of HiZ rendering that looks like some rendering is not
>> landing in my HiZ buffer.  Unfortunately, fulsim choking on us violating
>> hiz rendering rules was preventing me from using it as a debug aid.
>>
>> Once we get things reliable, we'll also be able to take advantage of this
>> to get fast clears on modes like 1366x768.
>> ---
>>   src/mesa/drivers/dri/i965/brw_blorp.cpp |   10 ++
>>   1 file changed, 10 insertions(+)
>>
>> diff --git a/src/mesa/drivers/dri/i965/brw_blorp.cpp
>> b/src/mesa/drivers/dri/i965/brw_blorp.cpp
>> index 5f72b5d..49dcacb 100644
>> --- a/src/mesa/drivers/dri/i965/brw_blorp.cpp
>> +++ b/src/mesa/drivers/dri/i965/brw_blorp.cpp
>> @@ -181,6 +181,16 @@ brw_hiz_op_params::brw_hiz_op_params(struct
>> intel_mipmap_tree *mt,
>>  this->hiz_op = op;
>>
>>  depth.set(mt, level, layer);
>> +
>> +   /* HiZ operations require alignment to 8x4.  Our depth and hiz 
>> miplevels
>> +* should have their start offsets aligned to that (except for a bug 
>> on
>> +* non-Z16) so we won't draw into a neighboring miplevel, and we 
>> allocate
>> +* memory aligned to pages (128bytesx32), so we won't draw into 
>> memory
>> not
>> +* owned by our miptree.
>> +*/
>> +   depth.width = ALIGN(depth.width, 8);
>> +   depth.height = ALIGN(depth.height, 4);
>> +
>
> This should be moved into the brw_hiz_op_params() constructor.

 That's where this is.  Were you thinking of a version that was posted in
 my tree at one point instead?
>>>
>>> No, I was talking with my foot in my mouth. :/
>>>
>>> I meant it should be set by call to depth.set() above, which is
>>> brw_blorp_mip_info::set(), like this:
>>>
>>> this->width = ALIGN(mt->level[level].width, 8);
>>> this->height = ALIGN(mt->level[level].height, 4);
>>>
>>> The responsibility of setting brw_blorp_mip_info fields should
>>> belong to that method.
>>
>> I disagree -- you only want this behavior for HiZ ops on depth/stencil,
>> not blorp ops in general (like blits with color buffers).
> 
> My vote is with Eric on this one.  I wrote an identical patch, and put it in
> brw_hiz_op_params for that very reason.
> 
> However, in order for this to not break horribly, don't you need to edit the
> intel/brw_tex_layout code to actually pad the buffer to have that extra 
> width? 
> Otherwise you could access outside the buffer (and I could've sworn I actually
> hit that case while trying this).
> 
> I believe Chad has patches to do that...

Eric, you're right.

I agree with Ken on the padding issue, and I do have patches for it.
I'm doing a full piglit run now, and will submit them if the results look good.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 6/9] i965/fs: Use the LRP instruction for ir_triop_lrp when possible.

2013-02-28 Thread Matt Turner
On Tue, Feb 26, 2013 at 9:51 AM, Kenneth Graunke  wrote:
>> diff --git a/src/mesa/drivers/dri/i965/brw_shader.cpp
>> b/src/mesa/drivers/dri/i965/brw_shader.cpp
>> index 9ab18cc..6965d72 100644
>> --- a/src/mesa/drivers/dri/i965/brw_shader.cpp
>> +++ b/src/mesa/drivers/dri/i965/brw_shader.cpp
>> @@ -156,7 +156,7 @@ brw_link_shader(struct gl_context *ctx, struct
>> gl_shader_program *shProg)
>>  SUB_TO_ADD_NEG |
>>  EXP_TO_EXP2 |
>>  LOG_TO_LOG2 |
>> -LRP_TO_ARITH);
>> +(stage == MESA_SHADER_FRAGMENT ? 0 :
>> LRP_TO_ARITH));
>
>
> Doesn't this need to include a gen check as well?  Perhaps:

Not really, since emit_lrp() has a gen check (and has to have it,
since emit_lrp() will be used for fragment program's OPCODE_LRP). For
GLSL, do we gain anything by lowering LRP on gen < 6 in the compiler
vs the backend, or vice versa?

> const int lrp_to_arith = 0;
> if (intel->gen < 6 || stage != MESA_SHADER_FRAGMENT)
> lrp_to_arith = LRP_TO_ARITH;
>
> then use lrp_to_arith here.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 4/9] glsl: Optimize ir_triop_lrp(x, y, a) with a = 0.0f or 1.0f

2013-02-28 Thread Matt Turner
On Tue, Feb 26, 2013 at 10:31 AM, Ian Romanick  wrote:
> On 02/19/2013 05:03 PM, Matt Turner wrote:
>>
>> ---
>>   src/glsl/opt_algebraic.cpp |   16 +---
>>   1 files changed, 13 insertions(+), 3 deletions(-)
>>
>> diff --git a/src/glsl/opt_algebraic.cpp b/src/glsl/opt_algebraic.cpp
>> index 75948db..952941e 100644
>> --- a/src/glsl/opt_algebraic.cpp
>> +++ b/src/glsl/opt_algebraic.cpp
>> @@ -186,12 +186,12 @@
>> ir_algebraic_visitor::swizzle_if_required(ir_expression *expr,
>>   ir_rvalue *
>>   ir_algebraic_visitor::handle_expression(ir_expression *ir)
>>   {
>> -   ir_constant *op_const[2] = {NULL, NULL};
>> -   ir_expression *op_expr[2] = {NULL, NULL};
>> +   ir_constant *op_const[3] = {NULL, NULL, NULL};
>> +   ir_expression *op_expr[3] = {NULL, NULL, NULL};
>>  ir_expression *temp;
>>  unsigned int i;
>>
>> -   assert(ir->get_num_operands() <= 2);
>> +   assert(ir->get_num_operands() <= 3);
>
>
> Doesn't this part of the change have to occur before other patches in this
> series?  What happens if you run piglit on the commit just before this?  I'd
> prefer bisects not hit spurious failures.

Not strictly necessary, I don't think, since all backends are lowering
LRP at this point. I could be wrong about the order of things though.
Anyway still a good idea.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [Bug 61361] Version mismatch error. This is libtool 2.4.2, but the definition of this LT_INIT comes from libtool 2.2.8.

2013-02-28 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=61361

--- Comment #3 from Andreas Boll  ---
Could you try to build from git?

-- 
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] [PATCH 0/4] Fix geometry shaders in the draw module

2013-02-28 Thread Zack Rusin
This is a merge of Bryan's gs patches plus some work on top of them
that fixes the known issues with geometry shaders in the draw module.
I had to fix the llvm paths in the "account for separate shader objects"
commit because it broke them.
With this both softpipe and llvmpipe have working geometry shaders.

Bryan Cain (3):
  draw/gs: fix allocation of buffer for GS output vertices
  draw: account for separate shader objects in geometry shader code
  draw: use geometry shader info in clip_init_state if appropriate

Zack Rusin (1):
  draw/llvm: fix inputs to the geometry shader

 src/gallium/auxiliary/draw/draw_gs.c   |   32 +---
 src/gallium/auxiliary/draw/draw_gs.h   |2 ++
 src/gallium/auxiliary/draw/draw_llvm.c |   15 ++---
 src/gallium/auxiliary/draw/draw_pipe_clip.c|   15 +
 .../auxiliary/draw/draw_pt_fetch_shade_pipeline.c  |1 +
 .../draw/draw_pt_fetch_shade_pipeline_llvm.c   |2 ++
 6 files changed, 52 insertions(+), 15 deletions(-)

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


[Mesa-dev] [PATCH 1/4] draw/gs: fix allocation of buffer for GS output vertices

2013-02-28 Thread Zack Rusin
From: Bryan Cain 

Before, it accounted for the size of the vertices but not the other fields
in the vertex_header struct, which caused memory corruption.

Reviewed-by: Zack Rusin 
---
 src/gallium/auxiliary/draw/draw_gs.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/gallium/auxiliary/draw/draw_gs.c 
b/src/gallium/auxiliary/draw/draw_gs.c
index 5c55523..2ce1a2a 100644
--- a/src/gallium/auxiliary/draw/draw_gs.c
+++ b/src/gallium/auxiliary/draw/draw_gs.c
@@ -401,7 +401,8 @@ int draw_geometry_shader_run(struct draw_geometry_shader 
*shader,
output_verts->vertex_size = input_verts->vertex_size;
output_verts->stride = input_verts->vertex_size;
output_verts->verts =
-  (struct vertex_header *)MALLOC(input_verts->vertex_size *
+  (struct vertex_header *)MALLOC(sizeof(struct vertex_header) +
+ input_verts->vertex_size *
  num_in_primitives *
  shader->max_output_vertices);
 
-- 
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 2/4] draw: account for separate shader objects in geometry shader code

2013-02-28 Thread Zack Rusin
From: Bryan Cain 

The geometry shader code seems to have been originally written with the
assumptions that there are the same number of VS outputs as GS outputs and
that VS outputs are in the same order as their corresponding GS inputs. Since
TGSI uses separate shader objects, these are both wrong assumptions. This
was causing several valid vertex/geometry shader combinations to either render
incorrectly or trigger an assertion.

Conflicts:
src/gallium/auxiliary/draw/draw_gs.c

Signed-off-by: Zack Rusin 
---
 src/gallium/auxiliary/draw/draw_gs.c   |   31 +---
 src/gallium/auxiliary/draw/draw_gs.h   |2 ++
 .../auxiliary/draw/draw_pt_fetch_shade_pipeline.c  |1 +
 .../draw/draw_pt_fetch_shade_pipeline_llvm.c   |2 ++
 4 files changed, 32 insertions(+), 4 deletions(-)

diff --git a/src/gallium/auxiliary/draw/draw_gs.c 
b/src/gallium/auxiliary/draw/draw_gs.c
index 2ce1a2a..5247917 100644
--- a/src/gallium/auxiliary/draw/draw_gs.c
+++ b/src/gallium/auxiliary/draw/draw_gs.c
@@ -148,6 +148,22 @@ void draw_delete_geometry_shader(struct draw_context *draw,
FREE(dgs);
 }
 
+static INLINE int
+draw_gs_get_input_index(int semantic, int index,
+const struct tgsi_shader_info *input_info)
+{
+   int i;
+   const ubyte *input_semantic_names = input_info->output_semantic_name;
+   const ubyte *input_semantic_indices = input_info->output_semantic_index;
+   for (i = 0; i < PIPE_MAX_SHADER_OUTPUTS; i++) {
+  if (input_semantic_names[i] == semantic &&
+  input_semantic_indices[i] == index)
+ return i;
+   }
+   debug_assert(0);
+   return -1;
+}
+
 /*#define DEBUG_OUTPUTS 1*/
 static INLINE void
 draw_geometry_fetch_outputs(struct draw_geometry_shader *shader,
@@ -228,6 +244,10 @@ static void draw_fetch_gs_input(struct 
draw_geometry_shader *shader,
 machine->Inputs[idx].xyzw[3].f[prim_idx] =
(float)shader->in_prim_idx;
  } else {
+vs_slot = draw_gs_get_input_index(
+shader->info.input_semantic_name[slot],
+shader->info.input_semantic_index[slot],
+shader->input_info);
 #if DEBUG_INPUTS
 debug_printf("\tSlot = %d, vs_slot = %d, idx = %d:\n",
  slot, vs_slot, idx);
@@ -381,12 +401,14 @@ int draw_geometry_shader_run(struct draw_geometry_shader 
*shader,
  const unsigned 
constants_size[PIPE_MAX_CONSTANT_BUFFERS], 
  const struct draw_vertex_info *input_verts,
  const struct draw_prim_info *input_prim,
+ const struct tgsi_shader_info *input_info,
  struct draw_vertex_info *output_verts,
  struct draw_prim_info *output_prims )
 {
const float (*input)[4] = (const float (*)[4])input_verts->verts->data;
unsigned input_stride = input_verts->vertex_size;
-   unsigned vertex_size = input_verts->vertex_size;
+   unsigned num_outputs = shader->info.num_outputs;
+   unsigned vertex_size = sizeof(struct vertex_header) + num_outputs * 4 * 
sizeof(float);
struct tgsi_exec_machine *machine = shader->machine;
unsigned num_input_verts = input_prim->linear ?
   input_verts->count :
@@ -398,11 +420,11 @@ int draw_geometry_shader_run(struct draw_geometry_shader 
*shader,
 
shader->max_output_vertices)
 * num_in_primitives;
 
-   output_verts->vertex_size = input_verts->vertex_size;
-   output_verts->stride = input_verts->vertex_size;
+   output_verts->vertex_size = vertex_size;
+   output_verts->stride = output_verts->vertex_size;
output_verts->verts =
   (struct vertex_header *)MALLOC(sizeof(struct vertex_header) +
- input_verts->vertex_size *
+ output_verts->vertex_size *
  num_in_primitives *
  shader->max_output_vertices);
 
@@ -426,6 +448,7 @@ int draw_geometry_shader_run(struct draw_geometry_shader 
*shader,
shader->in_prim_idx = 0;
shader->input_vertex_stride = input_stride;
shader->input = input;
+   shader->input_info = input_info;
FREE(shader->primitive_lengths);
shader->primitive_lengths = MALLOC(max_out_prims * sizeof(unsigned));
 
diff --git a/src/gallium/auxiliary/draw/draw_gs.h 
b/src/gallium/auxiliary/draw/draw_gs.h
index bfac02c..5d10d0d 100644
--- a/src/gallium/auxiliary/draw/draw_gs.h
+++ b/src/gallium/auxiliary/draw/draw_gs.h
@@ -64,6 +64,7 @@ struct draw_geometry_shader {
unsigned in_prim_idx;
unsigned input_vertex_stride;
const float (*input)[4];
+   const struct tgsi_shader_info *input_info;
 };
 
 /*
@@ -76,6 +77,7 @@ int draw_geometry_shader_run(struct draw_geometry_shader 
*shader,
   

[Mesa-dev] [PATCH 3/4] draw: use geometry shader info in clip_init_state if appropriate

2013-02-28 Thread Zack Rusin
From: Bryan Cain 


Reviewed-by: Zack Rusin 
---
 src/gallium/auxiliary/draw/draw_pipe_clip.c |   15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/src/gallium/auxiliary/draw/draw_pipe_clip.c 
b/src/gallium/auxiliary/draw/draw_pipe_clip.c
index 3110809..eeaaf41 100644
--- a/src/gallium/auxiliary/draw/draw_pipe_clip.c
+++ b/src/gallium/auxiliary/draw/draw_pipe_clip.c
@@ -40,6 +40,7 @@
 #include "draw_vs.h"
 #include "draw_pipe.h"
 #include "draw_fs.h"
+#include "draw_gs.h"
 
 
 /** Set to 1 to enable printing of coords before/after clipping */
@@ -596,8 +597,10 @@ clip_init_state( struct draw_stage *stage )
 {
struct clip_stage *clipper = clip_stage( stage );
const struct draw_vertex_shader *vs = stage->draw->vs.vertex_shader;
+   const struct draw_geometry_shader *gs = stage->draw->gs.geometry_shader;
const struct draw_fragment_shader *fs = stage->draw->fs.fragment_shader;
uint i;
+   struct tgsi_shader_info *vs_info = gs ? &gs->info : &vs->info;
 
/* We need to know for each attribute what kind of interpolation is
 * done on it (flat, smooth or noperspective).  But the information
@@ -640,16 +643,16 @@ clip_init_state( struct draw_stage *stage )
 
clipper->num_flat_attribs = 0;
memset(clipper->noperspective_attribs, 0, 
sizeof(clipper->noperspective_attribs));
-   for (i = 0; i < vs->info.num_outputs; i++) {
+   for (i = 0; i < vs_info->num_outputs; i++) {
   /* Find the interpolation mode for a specific attribute
*/
   int interp;
 
   /* If it's gl_{Front,Back}{,Secondary}Color, pick up the mode
* from the array we've filled before. */
-  if (vs->info.output_semantic_name[i] == TGSI_SEMANTIC_COLOR ||
-  vs->info.output_semantic_name[i] == TGSI_SEMANTIC_BCOLOR) {
- interp = indexed_interp[vs->info.output_semantic_index[i]];
+  if (vs_info->output_semantic_name[i] == TGSI_SEMANTIC_COLOR ||
+  vs_info->output_semantic_name[i] == TGSI_SEMANTIC_BCOLOR) {
+ interp = indexed_interp[vs_info->output_semantic_index[i]];
   } else {
  /* Otherwise, search in the FS inputs, with a decent default
   * if we don't find it.
@@ -658,8 +661,8 @@ clip_init_state( struct draw_stage *stage )
  interp = TGSI_INTERPOLATE_PERSPECTIVE;
  if (fs) {
 for (j = 0; j < fs->info.num_inputs; j++) {
-   if (vs->info.output_semantic_name[i] == 
fs->info.input_semantic_name[j] &&
-   vs->info.output_semantic_index[i] == 
fs->info.input_semantic_index[j]) {
+   if (vs_info->output_semantic_name[i] == 
fs->info.input_semantic_name[j] &&
+   vs_info->output_semantic_index[i] == 
fs->info.input_semantic_index[j]) {
   interp = fs->info.input_interpolate[j];
   break;
}
-- 
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 4/4] draw/llvm: fix inputs to the geometry shader

2013-02-28 Thread Zack Rusin
We can't clip and viewport transform the vertices before we let
the geometry shader process them. Lets make sure the generated
vertex shader has both disabled if geometry shader is present.

Signed-off-by: Zack Rusin 
---
 src/gallium/auxiliary/draw/draw_llvm.c |   15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/src/gallium/auxiliary/draw/draw_llvm.c 
b/src/gallium/auxiliary/draw/draw_llvm.c
index 8e46687..ff38a11 100644
--- a/src/gallium/auxiliary/draw/draw_llvm.c
+++ b/src/gallium/auxiliary/draw/draw_llvm.c
@@ -1176,11 +1176,16 @@ draw_llvm_generate(struct draw_llvm *llvm, struct 
draw_llvm_variant *variant,
LLVMValueRef outputs[PIPE_MAX_SHADER_OUTPUTS][TGSI_NUM_CHANNELS];
LLVMValueRef fetch_max;
struct lp_build_sampler_soa *sampler = 0;
-   LLVMValueRef ret, clipmask_bool_ptr;
-   const boolean bypass_viewport = variant->key.bypass_viewport;
-   const boolean enable_cliptest = variant->key.clip_xy || 
-   variant->key.clip_z  ||
-   variant->key.clip_user;
+   LLVMValueRef ret, clipmask_bool_ptr;   
+   const struct draw_geometry_shader *gs = draw->gs.geometry_shader;
+   /* If geometry shader is present we need to skip both the viewport
+* transformation and clipping otherwise the inputs to the geometry
+* shader will be incorrect.
+*/
+   const boolean bypass_viewport = gs || variant->key.bypass_viewport;
+   const boolean enable_cliptest = !gs && (variant->key.clip_xy || 
+   variant->key.clip_z  ||
+   variant->key.clip_user);
LLVMValueRef variant_func;
const unsigned pos = draw_current_shader_position_output(llvm->draw);
const unsigned cv = draw_current_shader_clipvertex_output(llvm->draw);
-- 
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 4/9] glsl: Optimize ir_triop_lrp(x, y, a) with a = 0.0f or 1.0f

2013-02-28 Thread Kenneth Graunke

On 02/28/2013 11:33 AM, Matt Turner wrote:

On Tue, Feb 26, 2013 at 10:31 AM, Ian Romanick  wrote:

On 02/19/2013 05:03 PM, Matt Turner wrote:


---
   src/glsl/opt_algebraic.cpp |   16 +---
   1 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/src/glsl/opt_algebraic.cpp b/src/glsl/opt_algebraic.cpp
index 75948db..952941e 100644
--- a/src/glsl/opt_algebraic.cpp
+++ b/src/glsl/opt_algebraic.cpp
@@ -186,12 +186,12 @@
ir_algebraic_visitor::swizzle_if_required(ir_expression *expr,
   ir_rvalue *
   ir_algebraic_visitor::handle_expression(ir_expression *ir)
   {
-   ir_constant *op_const[2] = {NULL, NULL};
-   ir_expression *op_expr[2] = {NULL, NULL};
+   ir_constant *op_const[3] = {NULL, NULL, NULL};
+   ir_expression *op_expr[3] = {NULL, NULL, NULL};
  ir_expression *temp;
  unsigned int i;

-   assert(ir->get_num_operands() <= 2);
+   assert(ir->get_num_operands() <= 3);



Doesn't this part of the change have to occur before other patches in this
series?  What happens if you run piglit on the commit just before this?  I'd
prefer bisects not hit spurious failures.


Not strictly necessary, I don't think, since all backends are lowering
LRP at this point. I could be wrong about the order of things though.
Anyway still a good idea.


It is necessary - do_common_optimization occurs prior to linking, during 
linking, and after linking.  Backends don't get involved until link 
time, so at least the first optimization pass happens prior to any lowering.


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


Re: [Mesa-dev] [PATCH 6/9] i965/fs: Use the LRP instruction for ir_triop_lrp when possible.

2013-02-28 Thread Kenneth Graunke

On 02/28/2013 11:20 AM, Matt Turner wrote:

On Tue, Feb 26, 2013 at 9:51 AM, Kenneth Graunke  wrote:

diff --git a/src/mesa/drivers/dri/i965/brw_shader.cpp
b/src/mesa/drivers/dri/i965/brw_shader.cpp
index 9ab18cc..6965d72 100644
--- a/src/mesa/drivers/dri/i965/brw_shader.cpp
+++ b/src/mesa/drivers/dri/i965/brw_shader.cpp
@@ -156,7 +156,7 @@ brw_link_shader(struct gl_context *ctx, struct
gl_shader_program *shProg)
  SUB_TO_ADD_NEG |
  EXP_TO_EXP2 |
  LOG_TO_LOG2 |
-LRP_TO_ARITH);
+(stage == MESA_SHADER_FRAGMENT ? 0 :
LRP_TO_ARITH));



Doesn't this need to include a gen check as well?  Perhaps:


Not really, since emit_lrp() has a gen check (and has to have it,
since emit_lrp() will be used for fragment program's OPCODE_LRP). For
GLSL, do we gain anything by lowering LRP on gen < 6 in the compiler
vs the backend, or vice versa?


Oh yeah, I didn't realize you made emit_lrp() handle both the LRP 
instruction and the raw math.  So you're okay as is.


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


Re: [Mesa-dev] [PATCH 0/4] Fix geometry shaders in the draw module

2013-02-28 Thread Brian Paul

On 02/28/2013 02:20 PM, Zack Rusin wrote:

This is a merge of Bryan's gs patches plus some work on top of them
that fixes the known issues with geometry shaders in the draw module.
I had to fix the llvm paths in the "account for separate shader objects"
commit because it broke them.
With this both softpipe and llvmpipe have working geometry shaders.

Bryan Cain (3):
   draw/gs: fix allocation of buffer for GS output vertices
   draw: account for separate shader objects in geometry shader code
   draw: use geometry shader info in clip_init_state if appropriate

Zack Rusin (1):
   draw/llvm: fix inputs to the geometry shader

  src/gallium/auxiliary/draw/draw_gs.c   |   32 +---
  src/gallium/auxiliary/draw/draw_gs.h   |2 ++
  src/gallium/auxiliary/draw/draw_llvm.c |   15 ++---
  src/gallium/auxiliary/draw/draw_pipe_clip.c|   15 +
  .../auxiliary/draw/draw_pt_fetch_shade_pipeline.c  |1 +
  .../draw/draw_pt_fetch_shade_pipeline_llvm.c   |2 ++
  6 files changed, 52 insertions(+), 15 deletions(-)



LGTM.
Reviewed-by: Brian Paul 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH V4 11/19] mesa: support multisample textures in framebuffer completeness check

2013-02-28 Thread Eric Anholt
Chris Forbes  writes:

> - sample count must be the same on all attachments
> - fixedsamplepositions must be the same on all attachments
> (renderbuffers have fixedsamplepositions=true implicitly; only
> multisample textures can choose to have it false)
>
> V2: - fix wrapping to 80 columns, debug message, fix for state moving
>   from texobj to image.
> - stencil texturing tweaks tidied up and folded in here.
>
> V3: - Removed silly stencil hacks entirely; the extension doesn't
>   actually make stencil-only textures legal at all.
> - Moved sample count / fixed sample locations checks into
>   existing attachment-type-specific blocks, as suggested by Eric
>
> V4: - Removed stencil hacks which were missed in V3 (thanks Eric)
> - Don't move the declaration of texImg; only required pre-V3.

Reviewed-by: Eric Anholt 


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


Re: [Mesa-dev] [PATCH 0/4] Fix issue with overriding GL to 3.2 and GLSL to 1.50

2013-02-28 Thread Eric Anholt
Jordan Justen  writes:

> Using MESA_GL_VERSION_OVERRIDE=3.2 and
> MESA_GLSL_VERSION_OVERRIDE=150 currently fails with piglit's
> shader_runner. For a GLSL 1.50 test, shader_runner wants to
> create a 3.2 core profile for a 1.50 test, but that was not
> working. Also, the compiler would assert during initialization
> if the version override was 1.50.

Reviewed-by: Eric Anholt 


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


Re: [Mesa-dev] [PATCH V4 15/19] i965: take the target into account for Gen7 MSAA modes

2013-02-28 Thread Eric Anholt
Chris Forbes  writes:

> Gen7 has an erratum affecting the ld_mcs message, making it unsafe to
> use when the surface doesn't have an associated MCS.
>
> From the Ivy Bridge PRM, Vol4 Part1 p77 ("MCS Enable"):
>
>"If this field is disabled and the sampling engine 
>message is issued on this surface, the MCS surface may be
>accessed. Software must ensure that the surface is defined
>to avoid GTT errors."
>
> To allow the shader to treat all surfaces uniformly, force UMS if the
> surface is to be used as a multisample texture, even if CMS would have
> been possible.
>
> V3: - Quoted erratum text
>
> Signed-off-by: Chris Forbes 
> ---
>  src/mesa/drivers/dri/intel/intel_mipmap_tree.c | 22 +++---
>  1 file changed, 19 insertions(+), 3 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/intel/intel_mipmap_tree.c 
> b/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
> index 139bf0e..e22c7a0 100644
> --- a/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
> +++ b/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
> @@ -72,7 +72,7 @@ target_to_target(GLenum target)
>   * created, based on the chip generation and the surface type.
>   */
>  static enum intel_msaa_layout
> -compute_msaa_layout(struct intel_context *intel, gl_format format)
> +compute_msaa_layout(struct intel_context *intel, gl_format format, GLenum 
> target)
>  {
> /* Prior to Gen7, all MSAA surfaces used IMS layout. */
> if (intel->gen < 7)
> @@ -101,7 +101,23 @@ compute_msaa_layout(struct intel_context *intel, 
> gl_format format)
>   assert(intel->gen == 7);
>   return INTEL_MSAA_LAYOUT_UMS;
>} else {
> - return INTEL_MSAA_LAYOUT_CMS;
> + /* For now, if we're going to be texturing from this surface,
> +  * force UMS, so that the shader doesn't have to do different things
> +  * based on whether there's a multisample control surface needing 
> sampled first.
> +  * We can't just blindly read the MCS surface in all cases because:
> +  *
> +  * From the Ivy Bridge PRM, Vol4 Part1 p77 ("MCS Enable"):
> +  *
> +  *If this field is disabled and the sampling engine  
> message
> +  *is issued on this surface, the MCS surface may be accessed. 
> Software
> +  *must ensure that the surface is defined to avoid GTT errors.
> +  */
> + if (target == GL_TEXTURE_2D_MULTISAMPLE ||
> +   target == GL_TEXTURE_2D_MULTISAMPLE_ARRAY) {
> +return INTEL_MSAA_LAYOUT_UMS;

The second "target ==" line ought to line up with the first.  Other than
that, it gets my review, and I'm ready for this series to land.


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


[Mesa-dev] RFC: enforcing gallium resource bind flags

2013-02-28 Thread Roland Scheidegger
Hi,

there is some sloppy usage of bind flags in the opengl state tracker
(that is, resources get used for things which they didn't have the bind
flag set).
We'd really like to enforce these flags to be honored but it doesn't
really work (ok llvmpipe so far would only really care about sampler
view, color render target, depth/stencil - see also
c8eb2d0e829d0d2aea6a982620da0d3cfb5982e2).

Currently it looks like there's at least two issues with those bind
flags in the opengl state tracker (for these bind flags only, there are
almost certainly more).
1) for textures, the state tracker will always try to allocate resources
with both sampler_view and render_target (or depth/stencil) bind flags.
However it will drop these flags for resources where this isn't
supported. This is all right, however when we try to render to such
resources, the surface will be created regardless (but it won't get used
as it will fail framebuffer validation which checks the attachments and
specifically tests if the format is a renderable format). I guess this
could be fixed (seems a bit backward, it might be possible to just look
at the resource bind flags to decide if we create a surface or not, and
we shouldn't need to check the format later - if we've got the bind flag
we know we can create a surface and hence render to).

2) a far more difficult problem seem to be buffers. While piglit doesn't
hit it (I modified the tbo test to hit this) it is possible to create
buffers with any target and later bind to anything. So the state tracker
has no knowledge at all what a buffer will eventually get used for
(other than the hint when it was first created), and it seems
unreasonable to just set all possible bind flags all the time. But then
still enforcing bind flags later would require the state tracker to
recreate the resource (with more bind flags) and copy over the old
contents, which sounds very bad too.

So any ideas?

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


[Mesa-dev] [PATCH 00/12] intel: A collection pre-hiz patches

2013-02-28 Thread Chad Versace
This series lives on my 'hiz-pre' branch.

I have a large hiz series brewing for Haswell.  To make review easier,
I decided to post some preliminary patches first rather than posting the hiz
patch bomb all at once.  If you'd prefer that I shelve this series until I'm
ready to submit the hiz series in its entirety, just let me know.

FYI, hiz hasn't been enabled on Haswell yet because some clumsiness in our
driver hangs the GPU.

Essentially, this patch series does two things:
  patches 1-7:  Lays the groundwork so that we can selectively disable hiz for
  individual miptree images that hang the gpu.

  patches 8-12: In preparation for emitting 8x4 aligned rectangle primitives, 
  add extra padding to hiz and depth miptrees.

Refactors are sprinkled into this series.  In some places, I found it
necessary to clean up the code before I could sufficiently understand it
to confidently make changes.

No regressions against mesa-master-809fdc211, piglit-99055b7, Ivybridge
0x0126.

Chad Versace (12):
  intel: Fix an instance of mixed tabs and spaces
  intel: Add field intel_mipmap_slice::has_hiz
  intel: Add accessor functions for intel_miptree_slice::has_hiz
  i965: Add level,layer members to brw_blorp_mip_info
  i965: Change signature of brw_get_depthstencil_tile_masks
  i965: Fix typo in doxygen hyperlink
  intel: Replace checks for hiz_mt with has_hiz accessors
  intel: Refactor selection of miptree tiling
  intel: Refactor selection of miptree's internal formats
  i965: Push stencil alignment w/a down to brw_miptree_layout()
  intel: Document intel_mipmap_tree::total_width,total_height
  i965: Add padding to depth and hiz miptrees

 src/mesa/drivers/dri/i965/brw_blorp.cpp|   4 +-
 src/mesa/drivers/dri/i965/brw_blorp.h  |  10 ++
 src/mesa/drivers/dri/i965/brw_clear.c  |   2 +-
 src/mesa/drivers/dri/i965/brw_context.h|  10 ++
 src/mesa/drivers/dri/i965/brw_draw.c   |   2 +-
 src/mesa/drivers/dri/i965/brw_misc_state.c |  26 +++-
 src/mesa/drivers/dri/i965/brw_tex_layout.c |  25 
 src/mesa/drivers/dri/i965/gen6_blorp.cpp   |   5 +-
 src/mesa/drivers/dri/i965/gen7_blorp.cpp   |   5 +-
 src/mesa/drivers/dri/intel/intel_fbo.c |   7 +
 src/mesa/drivers/dri/intel/intel_fbo.h |   3 +
 src/mesa/drivers/dri/intel/intel_mipmap_tree.c | 191 ++---
 src/mesa/drivers/dri/intel/intel_mipmap_tree.h |  24 +++-
 13 files changed, 221 insertions(+), 93 deletions(-)

-- 
1.8.1.2

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


[Mesa-dev] [PATCH 01/12] intel: Fix an instance of mixed tabs and spaces

2013-02-28 Thread Chad Versace
Fix a line to use only spaces. All adjacent lines were using spaces.  This
fixes weird indentation.

Signed-off-by: Chad Versace 
---
 src/mesa/drivers/dri/intel/intel_mipmap_tree.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/mesa/drivers/dri/intel/intel_mipmap_tree.c 
b/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
index e150501..2b66240 100644
--- a/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
@@ -496,7 +496,7 @@ intel_miptree_create_for_renderbuffer(struct intel_context 
*intel,
bool ok;
 
mt = intel_miptree_create(intel, GL_TEXTURE_2D, format, 0, 0,
-width, height, depth, true, num_samples,
+ width, height, depth, true, num_samples,
  false /* force_y_tiling */);
if (!mt)
   goto fail;
@@ -864,7 +864,7 @@ intel_miptree_alloc_mcs(struct intel_context *intel,
 
 bool
 intel_miptree_alloc_hiz(struct intel_context *intel,
-   struct intel_mipmap_tree *mt,
+struct intel_mipmap_tree *mt,
 GLuint num_samples)
 {
assert(mt->hiz_mt == NULL);
-- 
1.8.1.2

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


[Mesa-dev] [PATCH 02/12] intel: Add field intel_mipmap_slice::has_hiz

2013-02-28 Thread Chad Versace
Performing a hiz operation with an ill-aligned rectangle primitive causes
GPU hanges on some hardware.  Later patches will disable hiz on individual
slices to avoid such hangs.

However, this patch introduces no behavioral change.  If `mt->hiz_mt` is
set, then this sets `has_hiz` for all slices in the miptree.

Signed-off-by: Chad Versace 
---
 src/mesa/drivers/dri/intel/intel_mipmap_tree.c |  2 ++
 src/mesa/drivers/dri/intel/intel_mipmap_tree.h | 12 
 2 files changed, 14 insertions(+)

diff --git a/src/mesa/drivers/dri/intel/intel_mipmap_tree.c 
b/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
index 2b66240..11726ac 100644
--- a/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
@@ -887,6 +887,8 @@ intel_miptree_alloc_hiz(struct intel_context *intel,
struct intel_resolve_map *head = &mt->hiz_map;
for (int level = mt->first_level; level <= mt->last_level; ++level) {
   for (int layer = 0; layer < mt->level[level].depth; ++layer) {
+ mt->level[level].slice[layer].has_hiz = true;
+
 head->next = malloc(sizeof(*head->next));
 head->next->prev = head;
 head->next->next = NULL;
diff --git a/src/mesa/drivers/dri/intel/intel_mipmap_tree.h 
b/src/mesa/drivers/dri/intel/intel_mipmap_tree.h
index 2070be7..ed2ecc4 100644
--- a/src/mesa/drivers/dri/intel/intel_mipmap_tree.h
+++ b/src/mesa/drivers/dri/intel/intel_mipmap_tree.h
@@ -141,6 +141,18 @@ struct intel_mipmap_level
* intel_miptree_map/unmap on this slice.
*/
   struct intel_miptree_map *map;
+
+  /**
+   * \brief Is hiz enabled for this slice?
+   *
+   * If `mt->level[l].slice[s].has_hiz` is true, then there exists a
+   * corresponding hiz slice at `mt->hiz_mt->level[l].slice[s]`.
+   *
+   * Performing a hiz operation with an ill-aligned rectangle primitive
+   * causes a GPU hang on some hardware. We selectively enable hiz on
+   * individual slices in order avoid such hangs.
+   */
+  bool has_hiz;
} *slice;
 };
 
-- 
1.8.1.2

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


[Mesa-dev] [PATCH 03/12] intel: Add accessor functions for intel_miptree_slice::has_hiz

2013-02-28 Thread Chad Versace
Add two new functions:
  intel_miptree_slice_has_hiz
  intel_renderbuffer_has_hiz

These functions are not yet used.

Signed-off-by: Chad Versace 
---
 src/mesa/drivers/dri/intel/intel_fbo.c | 7 +++
 src/mesa/drivers/dri/intel/intel_fbo.h | 3 +++
 src/mesa/drivers/dri/intel/intel_mipmap_tree.c | 9 +
 src/mesa/drivers/dri/intel/intel_mipmap_tree.h | 5 +
 4 files changed, 24 insertions(+)

diff --git a/src/mesa/drivers/dri/intel/intel_fbo.c 
b/src/mesa/drivers/dri/intel/intel_fbo.c
index 9a9bb9f..72b03c9 100644
--- a/src/mesa/drivers/dri/intel/intel_fbo.c
+++ b/src/mesa/drivers/dri/intel/intel_fbo.c
@@ -925,6 +925,13 @@ intel_renderbuffer_set_needs_downsample(struct 
intel_renderbuffer *irb)
   irb->mt->need_downsample = true;
 }
 
+bool
+intel_renderbuffer_has_hiz(struct intel_renderbuffer *irb)
+{
+   return irb->mt &&
+  intel_miptree_slice_has_hiz(irb->mt, irb->mt_level, irb->mt_layer);
+}
+
 void
 intel_renderbuffer_set_needs_hiz_resolve(struct intel_renderbuffer *irb)
 {
diff --git a/src/mesa/drivers/dri/intel/intel_fbo.h 
b/src/mesa/drivers/dri/intel/intel_fbo.h
index ce744bf..27638c0 100644
--- a/src/mesa/drivers/dri/intel/intel_fbo.h
+++ b/src/mesa/drivers/dri/intel/intel_fbo.h
@@ -166,6 +166,9 @@ intel_get_rb_region(struct gl_framebuffer *fb, GLuint 
attIndex);
 void
 intel_renderbuffer_set_needs_downsample(struct intel_renderbuffer *irb);
 
+bool
+intel_renderbuffer_has_hiz(struct intel_renderbuffer *irb);
+
 void
 intel_renderbuffer_set_needs_hiz_resolve(struct intel_renderbuffer *irb);
 
diff --git a/src/mesa/drivers/dri/intel/intel_mipmap_tree.c 
b/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
index 11726ac..ee7e94a 100644
--- a/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
@@ -903,6 +903,15 @@ intel_miptree_alloc_hiz(struct intel_context *intel,
return true;
 }
 
+bool
+intel_miptree_slice_has_hiz(struct intel_mipmap_tree *mt,
+uint32_t level,
+uint32_t layer)
+{
+   intel_miptree_check_level_layer(mt, level, layer);
+   return mt->level[level].slice[layer].has_hiz;
+}
+
 void
 intel_miptree_slice_set_needs_hiz_resolve(struct intel_mipmap_tree *mt,
  uint32_t level,
diff --git a/src/mesa/drivers/dri/intel/intel_mipmap_tree.h 
b/src/mesa/drivers/dri/intel/intel_mipmap_tree.h
index ed2ecc4..bc55e26 100644
--- a/src/mesa/drivers/dri/intel/intel_mipmap_tree.h
+++ b/src/mesa/drivers/dri/intel/intel_mipmap_tree.h
@@ -533,6 +533,11 @@ intel_miptree_alloc_hiz(struct intel_context *intel,
struct intel_mipmap_tree *mt,
 GLuint num_samples);
 
+bool
+intel_miptree_slice_has_hiz(struct intel_mipmap_tree *mt,
+uint32_t level,
+uint32_t layer);
+
 void
 intel_miptree_slice_set_needs_hiz_resolve(struct intel_mipmap_tree *mt,
   uint32_t level,
-- 
1.8.1.2

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


[Mesa-dev] [PATCH 04/12] i965: Add level, layer members to brw_blorp_mip_info

2013-02-28 Thread Chad Versace
These will later be used to determine if hiz is enabled for the given
slice via intel_miptree_slice_has_hiz().

Signed-off-by: Chad Versace 
---
 src/mesa/drivers/dri/i965/brw_blorp.cpp |  2 ++
 src/mesa/drivers/dri/i965/brw_blorp.h   | 10 ++
 2 files changed, 12 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/brw_blorp.cpp 
b/src/mesa/drivers/dri/i965/brw_blorp.cpp
index 5f72b5d..88a1a82 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp.cpp
+++ b/src/mesa/drivers/dri/i965/brw_blorp.cpp
@@ -50,6 +50,8 @@ brw_blorp_mip_info::set(struct intel_mipmap_tree *mt,
intel_miptree_check_level_layer(mt, level, layer);
 
this->mt = mt;
+   this->level = level;
+   this->layer = layer;
this->width = mt->level[level].width;
this->height = mt->level[level].height;
 
diff --git a/src/mesa/drivers/dri/i965/brw_blorp.h 
b/src/mesa/drivers/dri/i965/brw_blorp.h
index 79a3f3a..595528b 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp.h
+++ b/src/mesa/drivers/dri/i965/brw_blorp.h
@@ -69,6 +69,16 @@ public:
struct intel_mipmap_tree *mt;
 
/**
+* The miplevel to be used.
+*/
+   uint32_t level;
+
+   /**
+* Layer of the miplevel to be used.
+*/
+   uint32_t layer;
+
+   /**
 * Width of the miplevel to be used.  For surfaces using
 * INTEL_MSAA_LAYOUT_IMS, this is measured in samples, not pixels.
 */
-- 
1.8.1.2

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


[Mesa-dev] [PATCH 05/12] i965: Change signature of brw_get_depthstencil_tile_masks

2013-02-28 Thread Chad Versace
Add two new parameters, 'level' and 'layer'. A later patch will pass the
new parameters to intel_miptree_slice_has_hiz().

Signed-off-by: Chad Versace 
---
 src/mesa/drivers/dri/i965/brw_context.h|  2 ++
 src/mesa/drivers/dri/i965/brw_misc_state.c | 19 ---
 src/mesa/drivers/dri/i965/gen6_blorp.cpp   |  5 -
 src/mesa/drivers/dri/i965/gen7_blorp.cpp   |  5 -
 4 files changed, 26 insertions(+), 5 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_context.h 
b/src/mesa/drivers/dri/i965/brw_context.h
index c173e49..4d18152 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -1129,6 +1129,8 @@ bool brwCreateContext(int api,
  * brw_misc_state.c
  */
 void brw_get_depthstencil_tile_masks(struct intel_mipmap_tree *depth_mt,
+ uint32_t depth_level,
+ uint32_t depth_layer,
  struct intel_mipmap_tree *stencil_mt,
  uint32_t *out_tile_mask_x,
  uint32_t *out_tile_mask_y);
diff --git a/src/mesa/drivers/dri/i965/brw_misc_state.c 
b/src/mesa/drivers/dri/i965/brw_misc_state.c
index 1024c42..862083a 100644
--- a/src/mesa/drivers/dri/i965/brw_misc_state.c
+++ b/src/mesa/drivers/dri/i965/brw_misc_state.c
@@ -267,9 +267,13 @@ brw_depthbuffer_format(struct brw_context *brw)
  * This returns the worst-case mask of the low bits that have to go into the
  * packet.  If the 3 buffers don't agree on the drawing offset ANDed with this
  * mask, then we're in trouble.
+ *
+ * If \a depth_mt is null, the \a depth_level and \a depth_layer are ignored.
  */
 void
 brw_get_depthstencil_tile_masks(struct intel_mipmap_tree *depth_mt,
+uint32_t depth_level,
+uint32_t depth_layer,
 struct intel_mipmap_tree *stencil_mt,
 uint32_t *out_tile_mask_x,
 uint32_t *out_tile_mask_y)
@@ -337,16 +341,25 @@ brw_workaround_depthstencil_alignment(struct brw_context 
*brw)
bool rebase_stencil = false;
struct intel_renderbuffer *depth_irb = intel_get_renderbuffer(fb, 
BUFFER_DEPTH);
struct intel_renderbuffer *stencil_irb = intel_get_renderbuffer(fb, 
BUFFER_STENCIL);
-   struct intel_mipmap_tree *depth_mt = NULL;
+   struct intel_mipmap_tree *depth_mt;
+   uint32_t depth_level, depth_layer;
struct intel_mipmap_tree *stencil_mt = get_stencil_miptree(stencil_irb);
uint32_t tile_x = 0, tile_y = 0, stencil_tile_x = 0, stencil_tile_y = 0;
uint32_t stencil_draw_x = 0, stencil_draw_y = 0;
 
-   if (depth_irb)
+   if (depth_irb) {
   depth_mt = depth_irb->mt;
+  depth_level = depth_irb->mt_level;
+  depth_layer = depth_irb->mt_layer;
+   } else {
+  depth_mt = NULL;
+  depth_layer = 0;
+  depth_level = 0;
+   }
 
uint32_t tile_mask_x, tile_mask_y;
-   brw_get_depthstencil_tile_masks(depth_mt, stencil_mt,
+   brw_get_depthstencil_tile_masks(depth_mt, depth_level, depth_layer,
+   stencil_mt,
&tile_mask_x, &tile_mask_y);
 
if (depth_irb) {
diff --git a/src/mesa/drivers/dri/i965/gen6_blorp.cpp 
b/src/mesa/drivers/dri/i965/gen6_blorp.cpp
index 3834ae2..29b45aa 100644
--- a/src/mesa/drivers/dri/i965/gen6_blorp.cpp
+++ b/src/mesa/drivers/dri/i965/gen6_blorp.cpp
@@ -828,7 +828,10 @@ gen6_blorp_emit_depth_stencil_config(struct brw_context 
*brw,
uint32_t draw_y = params->depth.y_offset;
uint32_t tile_mask_x, tile_mask_y;
 
-   brw_get_depthstencil_tile_masks(params->depth.mt, NULL,
+   brw_get_depthstencil_tile_masks(params->depth.mt,
+   params->depth.level,
+   params->depth.layer,
+   NULL /*stencil_mt*/,
&tile_mask_x, &tile_mask_y);
 
/* 3DSTATE_DEPTH_BUFFER */
diff --git a/src/mesa/drivers/dri/i965/gen7_blorp.cpp 
b/src/mesa/drivers/dri/i965/gen7_blorp.cpp
index 21caa0a..1a19dd4 100644
--- a/src/mesa/drivers/dri/i965/gen7_blorp.cpp
+++ b/src/mesa/drivers/dri/i965/gen7_blorp.cpp
@@ -584,7 +584,10 @@ gen7_blorp_emit_depth_stencil_config(struct brw_context 
*brw,
uint32_t tile_mask_x, tile_mask_y;
 
if (params->depth.mt) {
-  brw_get_depthstencil_tile_masks(params->depth.mt, NULL,
+  brw_get_depthstencil_tile_masks(params->depth.mt,
+  params->depth.level,
+  params->depth.layer,
+  NULL /*stencil_mt*/,
   &tile_mask_x, &tile_mask_y);
}
 
-- 
1.8.1.2

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


[Mesa-dev] [PATCH 06/12] i965: Fix typo in doxygen hyperlink

2013-02-28 Thread Chad Versace
s/brw_state_upload/brw_upload_state/

Found because the link was broken.

Signed-off-by: Chad Versace 
---
 src/mesa/drivers/dri/i965/brw_draw.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/brw_draw.c 
b/src/mesa/drivers/dri/i965/brw_draw.c
index 2c2b826..ceadff9 100644
--- a/src/mesa/drivers/dri/i965/brw_draw.c
+++ b/src/mesa/drivers/dri/i965/brw_draw.c
@@ -436,7 +436,7 @@ static bool brw_try_draw_prims( struct gl_context *ctx,
 
intel_prepare_render(intel);
 
-   /* This workaround has to happen outside of brw_state_upload() because it
+   /* This workaround has to happen outside of brw_upload_state() because it
 * may flush the batchbuffer for a blit, affecting the state flags.
 */
brw_workaround_depthstencil_alignment(brw);
-- 
1.8.1.2

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


[Mesa-dev] [PATCH 07/12] intel: Replace checks for hiz_mt with has_hiz accessors

2013-02-28 Thread Chad Versace
That is, replace checks like `hiz_mt != NULL` with
`intel_miptree_slice_has_hiz(...)` where appropriate. This is necessary
because a later patch will selectively disable hiz on individual miptree
slices, and therefore `hiz_mt != NULL` will no longer be a valid
indicator.

This produces no behaviorial change because, currently, if a hiz miptree
is present then hiz is enabled for all slices in the tree.

Signed-off-by: Chad Versace 
---
 src/mesa/drivers/dri/i965/brw_blorp.cpp| 2 +-
 src/mesa/drivers/dri/i965/brw_clear.c  | 2 +-
 src/mesa/drivers/dri/i965/brw_context.h| 8 
 src/mesa/drivers/dri/i965/brw_misc_state.c | 7 +++
 src/mesa/drivers/dri/intel/intel_mipmap_tree.c | 8 ++--
 5 files changed, 15 insertions(+), 12 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_blorp.cpp 
b/src/mesa/drivers/dri/i965/brw_blorp.cpp
index 88a1a82..f889a33 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp.cpp
+++ b/src/mesa/drivers/dri/i965/brw_blorp.cpp
@@ -186,7 +186,7 @@ brw_hiz_op_params::brw_hiz_op_params(struct 
intel_mipmap_tree *mt,
x1 = depth.width;
y1 = depth.height;
 
-   assert(mt->hiz_mt != NULL);
+   assert(intel_miptree_slice_has_hiz(mt, level, layer));
 
switch (mt->format) {
case MESA_FORMAT_Z16:   depth_format = BRW_DEPTHFORMAT_D16_UNORM; break;
diff --git a/src/mesa/drivers/dri/i965/brw_clear.c 
b/src/mesa/drivers/dri/i965/brw_clear.c
index 53d8e54..b2acf74 100644
--- a/src/mesa/drivers/dri/i965/brw_clear.c
+++ b/src/mesa/drivers/dri/i965/brw_clear.c
@@ -112,7 +112,7 @@ brw_fast_clear_depth(struct gl_context *ctx)
if (intel->gen < 6)
   return false;
 
-   if (!mt->hiz_mt)
+   if (!intel_renderbuffer_has_hiz(depth_irb))
   return false;
 
/* We only handle full buffer clears -- otherwise you'd have to track 
whether
diff --git a/src/mesa/drivers/dri/i965/brw_context.h 
b/src/mesa/drivers/dri/i965/brw_context.h
index 4d18152..5092294 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -1086,6 +1086,14 @@ struct brw_context
struct {
   struct intel_mipmap_tree *depth_mt;
   struct intel_mipmap_tree *stencil_mt;
+
+  /**
+   * This is set only when hiz is enabled for the attached depthbuffer.
+   * Note that, in some cases, hiz is disabled for the depthbuffer
+   * despite the presence of a hiz miptree (intel_miptree_mt::hiz_mt).
+   *
+   * \see intel_renderbuffer_has_hiz()
+   */
   struct intel_mipmap_tree *hiz_mt;
 
   /* Inter-tile (page-aligned) byte offsets. */
diff --git a/src/mesa/drivers/dri/i965/brw_misc_state.c 
b/src/mesa/drivers/dri/i965/brw_misc_state.c
index 862083a..9650987 100644
--- a/src/mesa/drivers/dri/i965/brw_misc_state.c
+++ b/src/mesa/drivers/dri/i965/brw_misc_state.c
@@ -284,10 +284,9 @@ brw_get_depthstencil_tile_masks(struct intel_mipmap_tree 
*depth_mt,
   intel_region_get_tile_masks(depth_mt->region,
   &tile_mask_x, &tile_mask_y, false);
 
-  struct intel_mipmap_tree *hiz_mt = depth_mt->hiz_mt;
-  if (hiz_mt) {
+  if (intel_miptree_slice_has_hiz(depth_mt, depth_level, depth_layer)) {
  uint32_t hiz_tile_mask_x, hiz_tile_mask_y;
- intel_region_get_tile_masks(hiz_mt->region,
+ intel_region_get_tile_masks(depth_mt->hiz_mt->region,
  &hiz_tile_mask_x, &hiz_tile_mask_y, 
false);
 
  /* Each HiZ row represents 2 rows of pixels */
@@ -527,7 +526,7 @@ brw_workaround_depthstencil_alignment(struct brw_context 
*brw)
  depth_irb->draw_x & ~tile_mask_x,
  depth_irb->draw_y & ~tile_mask_y,
  false);
-  if (depth_mt->hiz_mt) {
+  if (intel_renderbuffer_has_hiz(depth_irb)) {
  brw->depthstencil.hiz_mt = depth_mt->hiz_mt;
  brw->depthstencil.hiz_offset =
 intel_region_get_aligned_offset(depth_mt->region,
diff --git a/src/mesa/drivers/dri/intel/intel_mipmap_tree.c 
b/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
index ee7e94a..0a90de2 100644
--- a/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
@@ -917,9 +917,7 @@ intel_miptree_slice_set_needs_hiz_resolve(struct 
intel_mipmap_tree *mt,
  uint32_t level,
  uint32_t layer)
 {
-   intel_miptree_check_level_layer(mt, level, layer);
-
-   if (!mt->hiz_mt)
+   if (!intel_miptree_slice_has_hiz(mt, level, layer))
   return;
 
intel_resolve_map_set(&mt->hiz_map,
@@ -932,9 +930,7 @@ intel_miptree_slice_set_needs_depth_resolve(struct 
intel_mipmap_tree *mt,
 uint32_t level,
 uint32_t layer)
 {
-   intel_miptree_check_level_layer(mt, level, layer);
-
-   if (!mt->hiz_mt)
+   if (!int

[Mesa-dev] [PATCH 08/12] intel: Refactor selection of miptree tiling

2013-02-28 Thread Chad Versace
This patch (1) extracts from intel_miptree_create() the spaghetti logic
that selects the tiling format, (2) rewrites that spaghetti into a lucid
form, and (3) moves it to a new function, intel_miptree_choose_tiling().
No behavioral change.

As a bonus, it is now evident that the force_y_tiling parameter to
intel_miptree_create() does not really force Y tiling.

Signed-off-by: Chad Versace 
---
 src/mesa/drivers/dri/intel/intel_mipmap_tree.c | 90 +++---
 1 file changed, 54 insertions(+), 36 deletions(-)

diff --git a/src/mesa/drivers/dri/intel/intel_mipmap_tree.c 
b/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
index 0a90de2..ce07abf 100644
--- a/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
@@ -281,6 +281,57 @@ intel_miptree_create_layout(struct intel_context *intel,
return mt;
 }
 
+/**
+ * \brief Helper function for intel_miptree_create().
+ */
+static uint32_t
+intel_miptree_choose_tiling(struct intel_context *intel,
+gl_format format,
+uint32_t width0,
+uint32_t num_samples,
+bool force_y_tiling)
+{
+
+   if (format == MESA_FORMAT_S8) {
+  /* The stencil buffer is W tiled. However, we request from the kernel a
+   * non-tiled buffer because the GTT is incapable of W fencing.
+   */
+  return I915_TILING_NONE;
+   }
+
+   if (!intel->use_texture_tiling || _mesa_is_format_compressed(format))
+  return I915_TILING_NONE;
+
+   if (force_y_tiling)
+  return I915_TILING_Y;
+
+   if (num_samples > 1) {
+  /* From p82 of the Sandy Bridge PRM, dw3[1] of SURFACE_STATE ("Tiled
+   * Surface"):
+   *
+   *   [DevSNB+]: For multi-sample render targets, this field must be
+   *   1. MSRTs can only be tiled.
+   *
+   * Our usual reason for preferring X tiling (fast blits using the
+   * blitting engine) doesn't apply to MSAA, since we'll generally be
+   * downsampling or upsampling when blitting between the MSAA buffer
+   * and another buffer, and the blitting engine doesn't support that.
+   * So use Y tiling, since it makes better use of the cache.
+   */
+  return I915_TILING_Y;
+   }
+
+   GLenum base_format = _mesa_get_format_base_format(format);
+   if (intel->gen >= 4 &&
+   (base_format == GL_DEPTH_COMPONENT ||
+base_format == GL_DEPTH_STENCIL_EXT))
+  return I915_TILING_Y;
+
+   if (width0 >= 64)
+  return I915_TILING_X;
+
+   return I915_TILING_NONE;
+}
 
 struct intel_mipmap_tree *
 intel_miptree_create(struct intel_context *intel,
@@ -296,8 +347,6 @@ intel_miptree_create(struct intel_context *intel,
  bool force_y_tiling)
 {
struct intel_mipmap_tree *mt;
-   uint32_t tiling = I915_TILING_NONE;
-   GLenum base_format;
gl_format tex_format = format;
gl_format etc_format = MESA_FORMAT_NONE;
GLuint total_width, total_height;
@@ -336,35 +385,6 @@ intel_miptree_create(struct intel_context *intel,
}
 
etc_format = (format != tex_format) ? tex_format : MESA_FORMAT_NONE;
-   base_format = _mesa_get_format_base_format(format);
-
-   if (num_samples > 1) {
-  /* From p82 of the Sandy Bridge PRM, dw3[1] of SURFACE_STATE ("Tiled
-   * Surface"):
-   *
-   *   [DevSNB+]: For multi-sample render targets, this field must be
-   *   1. MSRTs can only be tiled.
-   *
-   * Our usual reason for preferring X tiling (fast blits using the
-   * blitting engine) doesn't apply to MSAA, since we'll generally be
-   * downsampling or upsampling when blitting between the MSAA buffer
-   * and another buffer, and the blitting engine doesn't support that.
-   * So use Y tiling, since it makes better use of the cache.
-   */
-  force_y_tiling = true;
-   }
-
-   if (intel->use_texture_tiling && !_mesa_is_format_compressed(format)) {
-  if (intel->gen >= 4 &&
- (base_format == GL_DEPTH_COMPONENT ||
-  base_format == GL_DEPTH_STENCIL_EXT))
-tiling = I915_TILING_Y;
-  else if (force_y_tiling) {
- tiling = I915_TILING_Y;
-  } else if (width0 >= 64)
-tiling = I915_TILING_X;
-   }
-
mt = intel_miptree_create_layout(intel, target, format,
  first_level, last_level, width0,
  height0, depth0,
@@ -381,15 +401,13 @@ intel_miptree_create(struct intel_context *intel,
total_height = mt->total_height;
 
if (format == MESA_FORMAT_S8) {
-  /* The stencil buffer is W tiled. However, we request from the kernel a
-   * non-tiled buffer because the GTT is incapable of W fencing.  So round
-   * up the width and height to match the size of W tiles (64x64).
-   */
-  tiling = I915_TILING_NONE;
+  /* Align to size of W tile, 64x64. */
   total_width = ALIGN(total_width, 64);
   total_height = ALIGN(total_height, 6

[Mesa-dev] [PATCH 09/12] intel: Refactor selection of miptree's internal formats

2013-02-28 Thread Chad Versace
Extract from intel_miptree_create() the logic for selecting
intel_mipmap_tree::format and ::etc_format into a new function,
intel_miptree_select_formats(). No behavioral change.

Now, intel_miptree_create() is short enough to be understandable.

Signed-off-by: Chad Versace 
---
 src/mesa/drivers/dri/intel/intel_mipmap_tree.c | 72 --
 1 file changed, 44 insertions(+), 28 deletions(-)

diff --git a/src/mesa/drivers/dri/intel/intel_mipmap_tree.c 
b/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
index ce07abf..e3eae11 100644
--- a/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
@@ -333,59 +333,75 @@ intel_miptree_choose_tiling(struct intel_context *intel,
return I915_TILING_NONE;
 }
 
-struct intel_mipmap_tree *
-intel_miptree_create(struct intel_context *intel,
-GLenum target,
-gl_format format,
-GLuint first_level,
-GLuint last_level,
-GLuint width0,
-GLuint height0,
-GLuint depth0,
-bool expect_accelerated_upload,
- GLuint num_samples,
- bool force_y_tiling)
+/**
+ * \brief Helper function for intel_miptree_create().
+ *
+ * The \a orig_format is that passed to intel_miptree_create().
+ */
+static void
+intel_miptree_select_formats(gl_format orig_format,
+ gl_format *mt_format,
+ gl_format *etc_format)
 {
-   struct intel_mipmap_tree *mt;
-   gl_format tex_format = format;
-   gl_format etc_format = MESA_FORMAT_NONE;
-   GLuint total_width, total_height;
-
-   switch (format) {
+   switch (orig_format) {
case MESA_FORMAT_ETC1_RGB8:
-  format = MESA_FORMAT_RGBX_REV;
+  *mt_format = MESA_FORMAT_RGBX_REV;
   break;
case MESA_FORMAT_ETC2_RGB8:
-  format = MESA_FORMAT_RGBX_REV;
+  *mt_format = MESA_FORMAT_RGBX_REV;
   break;
case MESA_FORMAT_ETC2_SRGB8:
case MESA_FORMAT_ETC2_SRGB8_ALPHA8_EAC:
case MESA_FORMAT_ETC2_SRGB8_PUNCHTHROUGH_ALPHA1:
-  format = MESA_FORMAT_SARGB8;
+  *mt_format = MESA_FORMAT_SARGB8;
   break;
case MESA_FORMAT_ETC2_RGBA8_EAC:
case MESA_FORMAT_ETC2_RGB8_PUNCHTHROUGH_ALPHA1:
-  format = MESA_FORMAT_RGBA_REV;
+  *mt_format = MESA_FORMAT_RGBA_REV;
   break;
case MESA_FORMAT_ETC2_R11_EAC:
-  format = MESA_FORMAT_R16;
+  *mt_format = MESA_FORMAT_R16;
   break;
case MESA_FORMAT_ETC2_SIGNED_R11_EAC:
-  format = MESA_FORMAT_SIGNED_R16;
+  *mt_format = MESA_FORMAT_SIGNED_R16;
   break;
case MESA_FORMAT_ETC2_RG11_EAC:
-  format = MESA_FORMAT_GR1616;
+  *mt_format = MESA_FORMAT_GR1616;
   break;
case MESA_FORMAT_ETC2_SIGNED_RG11_EAC:
-  format = MESA_FORMAT_SIGNED_GR1616;
+  *mt_format = MESA_FORMAT_SIGNED_GR1616;
   break;
default:
   /* Non ETC1 / ETC2 format */
+  *mt_format = orig_format;
   break;
}
 
-   etc_format = (format != tex_format) ? tex_format : MESA_FORMAT_NONE;
-   mt = intel_miptree_create_layout(intel, target, format,
+   if (*mt_format == orig_format)
+  *etc_format = MESA_FORMAT_NONE;
+   else
+  *etc_format = orig_format;
+}
+
+struct intel_mipmap_tree *
+intel_miptree_create(struct intel_context *intel,
+ GLenum target,
+ gl_format format,
+ GLuint first_level,
+ GLuint last_level,
+ GLuint width0,
+ GLuint height0,
+ GLuint depth0,
+ bool expect_accelerated_upload,
+ GLuint num_samples,
+ bool force_y_tiling)
+{
+   struct intel_mipmap_tree *mt;
+   GLuint total_width, total_height;
+   gl_format mt_format, etc_format;
+
+   intel_miptree_select_formats(format, &mt_format, &etc_format);
+   mt = intel_miptree_create_layout(intel, target, mt_format,
  first_level, last_level, width0,
  height0, depth0,
  false, num_samples);
-- 
1.8.1.2

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


[Mesa-dev] [PATCH 10/12] i965: Push stencil alignment w/a down to brw_miptree_layout()

2013-02-28 Thread Chad Versace
Miptree creation has a workaround for separate stencil buffers.  After the
layout is created, we override the tiling to I915_NONE and align it 64x64,
the size of a W-tile.

Before this patch, the workaround occurs in an odd place:
intel_miptree_create(). After brw_miptree_layout() creates the layout,
intel_miptree_create() overrides the tiling and alignment as needed.

Rather than override something after it has been set, it's safer to just
set it correctly in the first place. To do that, this patch pushes down
the workaround into brw_miptree_layout().

Signed-off-by: Chad Versace 
---
 src/mesa/drivers/dri/i965/brw_tex_layout.c |  7 +++
 src/mesa/drivers/dri/intel/intel_mipmap_tree.c | 14 ++
 2 files changed, 9 insertions(+), 12 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_tex_layout.c 
b/src/mesa/drivers/dri/i965/brw_tex_layout.c
index 1428396..633e598 100644
--- a/src/mesa/drivers/dri/i965/brw_tex_layout.c
+++ b/src/mesa/drivers/dri/i965/brw_tex_layout.c
@@ -184,6 +184,13 @@ brw_miptree_layout(struct intel_context *intel, struct 
intel_mipmap_tree *mt)
   }
   break;
}
+
+   if (mt->format == MESA_FORMAT_S8) {
+  /* Align to the size of a W tile, 64x64. */
+  mt->total_width = ALIGN(mt->total_width, 64);
+  mt->total_height = ALIGN(mt->total_height, 64);
+   }
+
DBG("%s: %dx%dx%d\n", __FUNCTION__,
mt->total_width, mt->total_height, mt->cpp);
 }
diff --git a/src/mesa/drivers/dri/intel/intel_mipmap_tree.c 
b/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
index e3eae11..77923d7 100644
--- a/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
@@ -397,7 +397,6 @@ intel_miptree_create(struct intel_context *intel,
  bool force_y_tiling)
 {
struct intel_mipmap_tree *mt;
-   GLuint total_width, total_height;
gl_format mt_format, etc_format;
 
intel_miptree_select_formats(format, &mt_format, &etc_format);
@@ -413,23 +412,14 @@ intel_miptree_create(struct intel_context *intel,
   return NULL;
}
 
-   total_width = mt->total_width;
-   total_height = mt->total_height;
-
-   if (format == MESA_FORMAT_S8) {
-  /* Align to size of W tile, 64x64. */
-  total_width = ALIGN(total_width, 64);
-  total_height = ALIGN(total_height, 64);
-   }
-
uint32_t tiling = intel_miptree_choose_tiling(intel, format, width0,
  num_samples, force_y_tiling);
mt->etc_format = etc_format;
mt->region = intel_region_alloc(intel->intelScreen,
   tiling,
   mt->cpp,
-  total_width,
-  total_height,
+  mt->total_width,
+  mt->total_height,
   expect_accelerated_upload);
mt->offset = 0;
 
-- 
1.8.1.2

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


[Mesa-dev] [PATCH 12/12] i965: Add padding to depth and hiz miptrees

2013-02-28 Thread Chad Versace
There exist alignment restrictions for the rectangle primitive emitted
during hiz operations. This patch pads the miptree to prevent a correctly
aligned rectangle from writing to out-of-bounds memory.

We do not currently emit a correctly aligned rectangle, though. That
arrives in a later patch.

Signed-off-by: Chad Versace 
---
 src/mesa/drivers/dri/i965/brw_tex_layout.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/brw_tex_layout.c 
b/src/mesa/drivers/dri/i965/brw_tex_layout.c
index 633e598..aea42e8 100644
--- a/src/mesa/drivers/dri/i965/brw_tex_layout.c
+++ b/src/mesa/drivers/dri/i965/brw_tex_layout.c
@@ -189,6 +189,24 @@ brw_miptree_layout(struct intel_context *intel, struct 
intel_mipmap_tree *mt)
   /* Align to the size of a W tile, 64x64. */
   mt->total_width = ALIGN(mt->total_width, 64);
   mt->total_height = ALIGN(mt->total_height, 64);
+   } else if (intel->vtbl.is_hiz_depth_format(intel, mt->format)) {
+  /* There exists alignment restrictions for the rectangle primitive
+   * emitted during hiz operations. Pad the miptree to prevent the
+   * rectangle from writing to out-of-bounds memory.
+   *
+   * From the Ivybridge PRM, Vol 2 Part 1 Section 11.5.3.1 Depth Buffer
+   * Clear:
+   *
+   * If Number of Multisamples is NUMSAMPLES_1, the rectangle must be
+   * aligned to an 8x4 pixel block relative to the upper left corner
+   * of the depth buffer, and contain an integer number of these pixel
+   * blocks, and all 8x4 pixels must be lit.
+   *
+   * The PRM continues by saying that, for 4 samples, the rectangle must
+   * be aligned to 4x2 pixels. For 8 samples, 2x2 pixels.
+   */
+  mt->total_width = ALIGN(mt->total_width, 8);
+  mt->total_height = ALIGN(mt->total_height, 4);
}
 
DBG("%s: %dx%dx%d\n", __FUNCTION__,
-- 
1.8.1.2

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


[Mesa-dev] [PATCH 11/12] intel: Document intel_mipmap_tree::total_width, total_height

2013-02-28 Thread Chad Versace
I had to use a debugger to deduce what total_width/height really were.
This patch is for the benefit of those who come after so they don't have
to dig as hard.

Signed-off-by: Chad Versace 
---
 src/mesa/drivers/dri/intel/intel_mipmap_tree.h | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/intel/intel_mipmap_tree.h 
b/src/mesa/drivers/dri/intel/intel_mipmap_tree.h
index bc55e26..1c852ff 100644
--- a/src/mesa/drivers/dri/intel/intel_mipmap_tree.h
+++ b/src/mesa/drivers/dri/intel/intel_mipmap_tree.h
@@ -265,7 +265,12 @@ struct intel_mipmap_tree
 */
enum intel_msaa_layout msaa_layout;
 
-   /* Derived from the above:
+   /**
+* The total physical size of the miptree, including all levels, slices,
+* and padding.
+*
+* \see physical_width0
+* \see physical_height0
 */
GLuint total_width;
GLuint total_height;
-- 
1.8.1.2

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


[Mesa-dev] [Bug 61640] New: Mesa demos render black without a window manager present

2013-02-28 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=61640

  Priority: medium
Bug ID: 61640
  Assignee: mesa-dev@lists.freedesktop.org
   Summary: Mesa demos render black without a window manager
present
  Severity: minor
Classification: Unclassified
OS: All
  Reporter: kenn...@whitecape.org
  Hardware: Other
Status: NEW
   Version: git
 Component: Demos
   Product: Mesa

Some Mesa demos, such as "gloss", render black when running under X without a
window manager.  With freeglut, the Reshape() function is apparently never
called, which is what sets up the frustum and such.  Presumably this is because
there isn't a window manager to provide a ConfigureNotify event.

Notably, Mark Kilgard's glut does call the Reshape() function.  

However, it seems like Mesa demos should probably set up their initial frustum
and such.

-- 
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 46376] render error when run glsl demo or mesa demo with X

2013-02-28 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=46376

Kenneth Graunke  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |NOTOURBUG
 Depends on||61640

--- Comment #7 from Kenneth Graunke  ---
I managed to bisect this down to:

commit 9a7f84d6b28e180ef79349b36de9a5d58a1e2dc9
Author: José Fonseca 
Date:   Thu Jul 14 17:28:52 2011 +0100

Squashed commit of the following:
...

which is the commit that removed Mark Kilgard's GLUT from the Mesa tree.  After
that, building Mesa no longer built libglut.  This meant that the demos started
running with your distro-provided libglut, which is typically freeglut (not
Kilgard's GLUT).

With freeglut and no window manager, the Mesa demos never get their Reshape()
function called, so their initial frustum and such never get set.  (Kilgard's
GLUT did cause Reshape() to get called.)  However, I don't believe this is a
bug; I believe freeglut's behavior is valid.

I've filed #61640 against Mesa demos; they should probably be enhanced to set
up their initial state and not rely on Reshape() getting automatically called. 
This is just generally a good idea.

In the meantime, I would just run with a window manager.  Closing this as
NOTOURBUG as it's a bug in the demos (or possibly freeglut), but not an actual
Mesa regression.

-- 
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 61640] Mesa demos render black without a window manager present

2013-02-28 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=61640

Kenneth Graunke  changed:

   What|Removed |Added

 Blocks||46376

-- 
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 46376] render error when run glsl demo or mesa demo with X

2013-02-28 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=46376

--- Comment #8 from Brian Paul  ---
(In reply to comment #7)
> I managed to bisect this down to:
> 
> commit 9a7f84d6b28e180ef79349b36de9a5d58a1e2dc9
> Author: José Fonseca 
> Date:   Thu Jul 14 17:28:52 2011 +0100
> 
> Squashed commit of the following:
> ...
> 
> which is the commit that removed Mark Kilgard's GLUT from the Mesa tree. 
> After that, building Mesa no longer built libglut.  This meant that the
> demos started running with your distro-provided libglut, which is typically
> freeglut (not Kilgard's GLUT).
> 
> With freeglut and no window manager, the Mesa demos never get their
> Reshape() function called, so their initial frustum and such never get set. 
> (Kilgard's GLUT did cause Reshape() to get called.)  However, I don't
> believe this is a bug; I believe freeglut's behavior is valid.
> 
> I've filed #61640 against Mesa demos; they should probably be enhanced to
> set up their initial state and not rely on Reshape() getting automatically
> called.  This is just generally a good idea.

I believe this is a freeglut bug.  Kilgard's GLUT came first and the behaviour
of window reshaping is documented here:
http://www.opengl.org/resources/libraries/glut/spec3/node48.html#SECTION00083000

according to that, the reshape function should always get called at least once
when the window first appears.

-- 
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 0/4] Fix issue with overriding GL to 3.2 and GLSL to 1.50

2013-02-28 Thread Kenneth Graunke

On 02/22/2013 11:27 AM, Jordan Justen wrote:

Using MESA_GL_VERSION_OVERRIDE=3.2 and
MESA_GLSL_VERSION_OVERRIDE=150 currently fails with piglit's
shader_runner. For a GLSL 1.50 test, shader_runner wants to
create a 3.2 core profile for a 1.50 test, but that was not
working. Also, the compiler would assert during initialization
if the version override was 1.50.

Jordan Justen (4):
   glsl: allow GLSL compiler version to be overridden to 1.50
   mesa version: add _mesa_get_gl_version_override
   intel: update max versions based on MESA_GL_VERSION_OVERRIDE
   intel: Enable __DRI_API_OPENGL_CORE api with dri2 contexts

  src/glsl/builtin_variables.cpp|2 +
  src/glsl/glsl_types.cpp   |1 +
  src/mesa/drivers/dri/intel/intel_screen.c |   12 
  src/mesa/main/version.c   |   94 -
  src/mesa/main/version.h   |3 +
  5 files changed, 85 insertions(+), 27 deletions(-)


Series seems good to me.  This should also eliminate a lot of the 
terrible hacks I've had to do to get 3.2 stuff running.


For the series:
Reviewed-by: Kenneth Graunke 

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


[Mesa-dev] [PATCH 1/2] gallivm: add support for texel offsets for ordinary texturing.

2013-02-28 Thread sroland
From: Roland Scheidegger 

This was previously only handled for texelFetch (much easier).
Depending on the wrap mode this works slightly differently (for somewhat
efficient implementation), hence have to do that separately in all roughly
137 places - it is easy if we use fixed point coords for wrapping, however
some wrapping modes are near impossible with fixed point (the repeat stuff)
hence we have to normalize the offsets if we can't do the wrapping in
unnormalized space (which is a division which is slow but should still be
much better than the alternative, which would be integer modulo for wrapping
which is just unusable). This should still give accurate results in all
cases that really matter, though it might be not quite conformant behavior
for some apis (but we have much worse problems there anyway even without
using offsets).
(Untested, no piglit test.)
---
 src/gallium/auxiliary/gallivm/lp_bld_sample_aos.c |  130 +++-
 src/gallium/auxiliary/gallivm/lp_bld_sample_aos.h |1 +
 src/gallium/auxiliary/gallivm/lp_bld_sample_soa.c |  132 +
 3 files changed, 210 insertions(+), 53 deletions(-)

diff --git a/src/gallium/auxiliary/gallivm/lp_bld_sample_aos.c 
b/src/gallium/auxiliary/gallivm/lp_bld_sample_aos.c
index bddff2c..16d5718 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_sample_aos.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_sample_aos.c
@@ -64,9 +64,11 @@
  * for scaled integer texcoords.
  * \param block_length  is the length of the pixel block along the
  *  coordinate axis
- * \param coord  the incoming texcoord (s,t,r or q) scaled to the texture size
+ * \param coord  the incoming texcoord (s,t or r) scaled to the texture size
+ * \param coord_f  the incoming texcoord (s,t or r) as float vec
  * \param length  the texture size along one dimension
  * \param stride  pixel stride along the coordinate axis (in bytes)
+ * \param offset  the texel offset along the coord axis
  * \param is_pot  if TRUE, length is a power of two
  * \param wrap_mode  one of PIPE_TEX_WRAP_x
  * \param out_offset  byte offset for the wrapped coordinate
@@ -79,6 +81,7 @@ lp_build_sample_wrap_nearest_int(struct 
lp_build_sample_context *bld,
  LLVMValueRef coord_f,
  LLVMValueRef length,
  LLVMValueRef stride,
+ LLVMValueRef offset,
  boolean is_pot,
  unsigned wrap_mode,
  LLVMValueRef *out_offset,
@@ -97,6 +100,11 @@ lp_build_sample_wrap_nearest_int(struct 
lp_build_sample_context *bld,
   else {
  struct lp_build_context *coord_bld = &bld->coord_bld;
  LLVMValueRef length_f = lp_build_int_to_float(coord_bld, length);
+ if (offset) {
+offset = lp_build_int_to_float(coord_bld, offset);
+offset = lp_build_div(coord_bld, offset, length_f);
+coord_f = lp_build_add(coord_bld, coord_f, offset);
+ }
  coord = lp_build_fract_safe(coord_bld, coord_f);
  coord = lp_build_mul(coord_bld, coord, length_f);
  coord = lp_build_itrunc(coord_bld, coord);
@@ -126,8 +134,9 @@ lp_build_sample_wrap_nearest_int(struct 
lp_build_sample_context *bld,
 /**
  * Build LLVM code for texture coord wrapping, for nearest filtering,
  * for float texcoords.
- * \param coord  the incoming texcoord (s,t,r or q)
+ * \param coord  the incoming texcoord (s,t or r)
  * \param length  the texture size along one dimension
+ * \param offset  the texel offset along the coord axis
  * \param is_pot  if TRUE, length is a power of two
  * \param wrap_mode  one of PIPE_TEX_WRAP_x
  * \param icoord  the texcoord after wrapping, as int
@@ -136,6 +145,7 @@ static void
 lp_build_sample_wrap_nearest_float(struct lp_build_sample_context *bld,
LLVMValueRef coord,
LLVMValueRef length,
+   LLVMValueRef offset,
boolean is_pot,
unsigned wrap_mode,
LLVMValueRef *icoord)
@@ -145,6 +155,12 @@ lp_build_sample_wrap_nearest_float(struct 
lp_build_sample_context *bld,
 
switch(wrap_mode) {
case PIPE_TEX_WRAP_REPEAT:
+  if (offset) {
+ /* this is definitely not ideal for POT case */
+ offset = lp_build_int_to_float(coord_bld, offset);
+ offset = lp_build_div(coord_bld, offset, length);
+ coord = lp_build_add(coord_bld, coord, offset);
+  }
   /* take fraction, unnormalize */
   coord = lp_build_fract_safe(coord_bld, coord);
   coord = lp_build_mul(coord_bld, coord, length);
@@ -156,6 +172,10 @@ lp_build_sample_wrap_nearest_float(struct 
lp_build_sample_context *bld,
  /* scale coord to length */
  coord = lp_build_mul(coord_bl

[Mesa-dev] [PATCH 2/2] llvmpipe: bump glsl version to 130

2013-02-28 Thread sroland
From: Roland Scheidegger 

texel offsets should have been the last missing feature (not sure
if anything is actually missing for 140). In any case we still
don't do OpenGL 3.0 (missing MSAA which will be difficult,
plus EXT_packed_float, ARB_depth_buffer_float and EXT_framebuffer_sRGB).
---
 src/gallium/drivers/llvmpipe/lp_screen.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/llvmpipe/lp_screen.c 
b/src/gallium/drivers/llvmpipe/lp_screen.c
index 05bbca5..aab13b3 100644
--- a/src/gallium/drivers/llvmpipe/lp_screen.c
+++ b/src/gallium/drivers/llvmpipe/lp_screen.c
@@ -195,7 +195,7 @@ llvmpipe_get_param(struct pipe_screen *screen, enum 
pipe_cap param)
case PIPE_CAP_VERTEX_COLOR_CLAMPED:
   return 1;
case PIPE_CAP_GLSL_FEATURE_LEVEL:
-  return 120;
+  return 130;
case PIPE_CAP_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION:
   return 0;
case PIPE_CAP_COMPUTE:
-- 
1.7.9.5

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


[Mesa-dev] [PATCH] i965: Link i965_dri.so with C++ linker.

2013-02-28 Thread Frank Henigman
Force C++ linking of i965_dri.so by adding a dummy C++ source file.
---
 src/mesa/drivers/dri/i965/Makefile.am | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/mesa/drivers/dri/i965/Makefile.am 
b/src/mesa/drivers/dri/i965/Makefile.am
index dc140df..77670ef 100644
--- a/src/mesa/drivers/dri/i965/Makefile.am
+++ b/src/mesa/drivers/dri/i965/Makefile.am
@@ -62,6 +62,7 @@ TEST_LIBS = \
../common/libdri_test_stubs.la
 
 i965_dri_la_SOURCES =
+nodist_EXTRA_i965_dri_la_SOURCES = dummy2.cpp
 i965_dri_la_LIBADD = $(COMMON_LIBS)
 i965_dri_la_LDFLAGS = -module -avoid-version -shared
 
-- 
1.8.1.3

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


Re: [Mesa-dev] [PATCH] i965: Link i965_dri.so with C++ linker.

2013-02-28 Thread Matt Turner
On Thu, Feb 28, 2013 at 6:21 PM, Frank Henigman  wrote:
> Force C++ linking of i965_dri.so by adding a dummy C++ source file.
> ---
>  src/mesa/drivers/dri/i965/Makefile.am | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/src/mesa/drivers/dri/i965/Makefile.am 
> b/src/mesa/drivers/dri/i965/Makefile.am
> index dc140df..77670ef 100644
> --- a/src/mesa/drivers/dri/i965/Makefile.am
> +++ b/src/mesa/drivers/dri/i965/Makefile.am
> @@ -62,6 +62,7 @@ TEST_LIBS = \
> ../common/libdri_test_stubs.la
>
>  i965_dri_la_SOURCES =
> +nodist_EXTRA_i965_dri_la_SOURCES = dummy2.cpp
>  i965_dri_la_LIBADD = $(COMMON_LIBS)
>  i965_dri_la_LDFLAGS = -module -avoid-version -shared
>
> --
> 1.8.1.3

Oh god build systems are so broken. Seriously, why isn't automake able
to recognize that linking a convenience library with C++ code in it
into another library that it needs to do it with the C++ linker?
Presumably you were seeing some undefined references. Which ones?

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


[Mesa-dev] [Bug 61647] New: [llvmpipe] lp_texture.c:580:llvmpipe_create_surface: Assertion `pt->bind & ((1 << 0) | (1 << 1))' failed.

2013-02-28 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=61647

  Priority: medium
Bug ID: 61647
  Assignee: mesa-dev@lists.freedesktop.org
   Summary: [llvmpipe] lp_texture.c:580:llvmpipe_create_surface:
Assertion `pt->bind & ((1 << 0) | (1 << 1))' failed.
  Severity: critical
Classification: Unclassified
OS: Linux (All)
  Reporter: v...@freedesktop.org
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: git
 Component: Other
   Product: Mesa

mesa: 4154ac066f2cdeddfe934884b59c8f1ff393545d (master)

Run piglit test getteximage-formats init-by-rendering.

$ ./bin/getteximage-formats init-by-rendering -auto
Using test set: Core formats
The textures will be initialized by rendering to them using glDrawPixels.
getteximage-formats failure: format: GL_ALPHA, level 1 at pixel(369, 103)
 Expected (0.203922, 0.203922, 0.203922, 0.240292)
 Found (0.40, 0.40, 0.40, 0.00)
Tolerance (0.25, 0.25, 0.25, 0.031250)
getteximage-formats failure: format: GL_ALPHA, level 2 at pixel(421, 71)
 Expected (0.203922, 0.203922, 0.203922, 0.240292)
 Found (0.40, 0.40, 0.40, 0.00)
Tolerance (0.25, 0.25, 0.25, 0.031250)
getteximage-formats failure: format: GL_LUMINANCE, level 1 at pixel(369, 103)
 Expected (0.992157, 0.00, 0.00, 1.00)
 Found (0.00, 0.00, 0.00, 1.00)
Tolerance (0.031250, 0.25, 0.25, 0.25)
getteximage-formats failure: format: GL_LUMINANCE, level 2 at pixel(421, 71)
 Expected (0.992157, 0.00, 0.00, 1.00)
 Found (0.00, 0.00, 0.00, 1.00)
Tolerance (0.031250, 0.25, 0.25, 0.25)
getteximage-formats failure: format: GL_INTENSITY, level 1 at pixel(369, 103)
 Expected (0.987512, 0.003137, 0.003137, 0.984375)
 Found (0.00, 0.00, 0.00, 1.00)
Tolerance (0.031250, 0.25, 0.25, 0.031250)
getteximage-formats failure: format: GL_INTENSITY, level 2 at pixel(421, 71)
 Expected (0.987512, 0.003137, 0.003137, 0.984375)
 Found (0.00, 0.00, 0.00, 1.00)
Tolerance (0.031250, 0.25, 0.25, 0.031250)
getteximage-formats failure: format: GL_ALPHA4, level 1 at pixel(369, 103)
 Expected (0.203922, 0.203922, 0.203922, 0.240292)
 Found (0.40, 0.40, 0.40, 0.00)
Tolerance (0.25, 0.25, 0.25, 0.031250)
getteximage-formats failure: format: GL_ALPHA4, level 2 at pixel(421, 71)
 Expected (0.203922, 0.203922, 0.203922, 0.240292)
 Found (0.40, 0.40, 0.40, 0.00)
Tolerance (0.25, 0.25, 0.25, 0.031250)
getteximage-formats failure: format: GL_ALPHA8, level 1 at pixel(369, 103)
 Expected (0.203922, 0.203922, 0.203922, 0.240292)
 Found (0.40, 0.40, 0.40, 0.00)
Tolerance (0.25, 0.25, 0.25, 0.031250)
getteximage-formats failure: format: GL_ALPHA8, level 2 at pixel(421, 71)
 Expected (0.203922, 0.203922, 0.203922, 0.240292)
 Found (0.40, 0.40, 0.40, 0.00)
Tolerance (0.25, 0.25, 0.25, 0.031250)
getteximage-formats failure: format: GL_LUMINANCE4, level 1 at pixel(369, 103)
 Expected (0.992157, 0.00, 0.00, 1.00)
 Found (0.00, 0.00, 0.00, 1.00)
Tolerance (0.031250, 0.25, 0.25, 0.25)
getteximage-formats failure: format: GL_LUMINANCE4, level 2 at pixel(421, 71)
 Expected (0.992157, 0.00, 0.00, 1.00)
 Found (0.00, 0.00, 0.00, 1.00)
Tolerance (0.031250, 0.25, 0.25, 0.25)
getteximage-formats failure: format: GL_LUMINANCE8, level 1 at pixel(369, 103)
 Expected (0.992157, 0.00, 0.00, 1.00)
 Found (0.00, 0.00, 0.00, 1.00)
Tolerance (0.031250, 0.25, 0.25, 0.25)
getteximage-formats failure: format: GL_LUMINANCE8, level 2 at pixel(421, 71)
 Expected (0.992157, 0.00, 0.00, 1.00)
 Found (0.00, 0.00, 0.00, 1.00)
Tolerance (0.031250, 0.25, 0.25, 0.25)
getteximage-formats failure: format: GL_INTENSITY4, level 1 at pixel(369, 103)
 Expected (0.987512, 0.003137, 0.003137, 0.984375)
 Found (0.00, 0.00, 0.00, 1.00)
Tolerance (0.031250, 0.25, 0.25, 0.031250)
getteximage-formats failure: format: GL_INTENSITY4, level 2 at pixel(421, 71)
 Expected (0.987512, 0.003137, 0.003137, 0.984375)
 Found (0.00, 0.00, 0.00, 1.00)
Tolerance (0.031250, 0.25, 0.25, 0.031250)
getteximage-formats failure: format: GL_INTENSITY8, level 1 at pixel(369, 103)
 Expected (0.987512, 0.003137, 0.003137, 0.984375)
 Found (0.00, 0.00, 0.00, 1.00)
Tolerance (0.031250, 0.25, 0.25, 0.031250)
getteximage-formats failure: format: GL_INTENSITY8, level 2 at pixel(421, 71)
 Expected (0.987512, 0.003137, 0.003137, 0.984375)
 Found (0.00, 0.00, 0.00, 1.00)
Tolerance (0.031250, 0.25, 0.25, 0.031250)
gett

Re: [Mesa-dev] [PATCH 1/4] i965: Fix fulsim assertion failures by aligning HiZ ops to 8x4.

2013-02-28 Thread Eric Anholt
Chad Versace  writes:

> On 02/28/2013 11:01 AM, Kenneth Graunke wrote:
>> On 02/28/2013 09:08 AM, Eric Anholt wrote:
>>> Chad Versace  writes:
>>>
 On 02/27/2013 11:39 AM, Eric Anholt wrote:
> Chad Versace  writes:
>
>> On 02/26/2013 11:15 PM, Eric Anholt wrote:
>>> I have some debug of HiZ rendering that looks like some rendering is not
>>> landing in my HiZ buffer.  Unfortunately, fulsim choking on us violating
>>> hiz rendering rules was preventing me from using it as a debug aid.
>>>
>>> Once we get things reliable, we'll also be able to take advantage of 
>>> this
>>> to get fast clears on modes like 1366x768.
>>> ---
>>>   src/mesa/drivers/dri/i965/brw_blorp.cpp |   10 ++
>>>   1 file changed, 10 insertions(+)
>>>
>>> diff --git a/src/mesa/drivers/dri/i965/brw_blorp.cpp
>>> b/src/mesa/drivers/dri/i965/brw_blorp.cpp
>>> index 5f72b5d..49dcacb 100644
>>> --- a/src/mesa/drivers/dri/i965/brw_blorp.cpp
>>> +++ b/src/mesa/drivers/dri/i965/brw_blorp.cpp
>>> @@ -181,6 +181,16 @@ brw_hiz_op_params::brw_hiz_op_params(struct
>>> intel_mipmap_tree *mt,
>>>  this->hiz_op = op;
>>>
>>>  depth.set(mt, level, layer);
>>> +
>>> +   /* HiZ operations require alignment to 8x4.  Our depth and hiz 
>>> miplevels
>>> +* should have their start offsets aligned to that (except for a 
>>> bug on
>>> +* non-Z16) so we won't draw into a neighboring miplevel, and we 
>>> allocate
>>> +* memory aligned to pages (128bytesx32), so we won't draw into 
>>> memory
>>> not
>>> +* owned by our miptree.
>>> +*/
>>> +   depth.width = ALIGN(depth.width, 8);
>>> +   depth.height = ALIGN(depth.height, 4);
>>> +
>>
>> This should be moved into the brw_hiz_op_params() constructor.
>
> That's where this is.  Were you thinking of a version that was posted in
> my tree at one point instead?

 No, I was talking with my foot in my mouth. :/

 I meant it should be set by call to depth.set() above, which is
 brw_blorp_mip_info::set(), like this:

 this->width = ALIGN(mt->level[level].width, 8);
 this->height = ALIGN(mt->level[level].height, 4);

 The responsibility of setting brw_blorp_mip_info fields should
 belong to that method.
>>>
>>> I disagree -- you only want this behavior for HiZ ops on depth/stencil,
>>> not blorp ops in general (like blits with color buffers).
>> 
>> My vote is with Eric on this one.  I wrote an identical patch, and put it in
>> brw_hiz_op_params for that very reason.
>> 
>> However, in order for this to not break horribly, don't you need to edit the
>> intel/brw_tex_layout code to actually pad the buffer to have that extra 
>> width? 
>> Otherwise you could access outside the buffer (and I could've sworn I 
>> actually
>> hit that case while trying this).
>> 
>> I believe Chad has patches to do that...
>
> Eric, you're right.
>
> I agree with Ken on the padding issue, and I do have patches for it.
> I'm doing a full piglit run now, and will submit them if the results look 
> good.

The padding is not an issue currently, as noted in the comment.
However, if we ever do linear buffers it would become an issue, so it
makes sense to put something in.


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


[Mesa-dev] [PATCH] llvmpipe: bump glsl version to 140

2013-02-28 Thread sroland
From: Roland Scheidegger 

texel offsets should have been the last missing feature (not sure
if anything is actually missing for 140). In any case we still
don't do OpenGL 3.0 (missing MSAA which will be difficult,
plus EXT_packed_float, ARB_depth_buffer_float and EXT_framebuffer_sRGB).

v2: bump to 140 instead - we have everything except we crash when not writing
to gl_Position (but softpipe crashes as well) so let's just say this is a bug
instead. Also (by Dave Airlie's suggestion) update llvm-todo.txt.
---
 src/gallium/docs/llvm-todo.txt   |   16 +---
 src/gallium/drivers/llvmpipe/lp_screen.c |2 +-
 2 files changed, 6 insertions(+), 12 deletions(-)

diff --git a/src/gallium/docs/llvm-todo.txt b/src/gallium/docs/llvm-todo.txt
index a5a8c1a..02b4b62 100644
--- a/src/gallium/docs/llvm-todo.txt
+++ b/src/gallium/docs/llvm-todo.txt
@@ -4,18 +4,12 @@ TODO covering gallivm/llvmpipe
 Goal: GL3.0 support in llvmpipe
 ---
 
-TXQ opcode support - airlied WIP
-TXF opcode support.
-Integer texture fetch support
-Integer renderbuffer support
-Vertex ID support.
-EXT_transform_feedback support - airlied WIP
-clip distance support - airlied WIP
-vertex clip support - airlied WIP
-EXT_texture_array support - Jakob WIP
+EXT_packed_float support.
+ARB_depth_buffer_float support.
+EXT_framebuffer_sRGB support.
+MSAA support.
+
 
 Goal: extension parity with softpipe:
 -
-GL3.0 support.
-EXT_timer_query - airlied posted a patch
 
diff --git a/src/gallium/drivers/llvmpipe/lp_screen.c 
b/src/gallium/drivers/llvmpipe/lp_screen.c
index 05bbca5..aab13b3 100644
--- a/src/gallium/drivers/llvmpipe/lp_screen.c
+++ b/src/gallium/drivers/llvmpipe/lp_screen.c
@@ -195,7 +195,7 @@ llvmpipe_get_param(struct pipe_screen *screen, enum 
pipe_cap param)
case PIPE_CAP_VERTEX_COLOR_CLAMPED:
   return 1;
case PIPE_CAP_GLSL_FEATURE_LEVEL:
-  return 120;
+  return 130;
case PIPE_CAP_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION:
   return 0;
case PIPE_CAP_COMPUTE:
-- 
1.7.9.5

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


[Mesa-dev] [Bug 61647] [llvmpipe] lp_texture.c:580:llvmpipe_create_surface: Assertion `pt->bind & ((1 << 0) | (1 << 1))' failed.

2013-02-28 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=61647

--- Comment #1 from Roland Scheidegger  ---
Yes, those new assertions essentially catch state tracker bugs. Maybe I should
just disable them for the time being - in this case the state tracker is smart
enough to actually not use the surface but it still creates 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


[Mesa-dev] [Bug 61647] [llvmpipe] lp_texture.c:580:llvmpipe_create_surface: Assertion `pt->bind & ((1 << 0) | (1 << 1))' failed.

2013-02-28 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=61647

Vinson Lee  changed:

   What|Removed |Added

 CC||srol...@vmware.com
   Keywords||regression

--- Comment #2 from Vinson Lee  ---
c8eb2d0e829d0d2aea6a982620da0d3cfb5982e2 is the first bad commit
commit c8eb2d0e829d0d2aea6a982620da0d3cfb5982e2
Author: Roland Scheidegger 
Date:   Thu Feb 28 01:25:24 2013 +0100

llvmpipe: check buffers in llvmpipe_is_resource_referenced.

Now that buffers can be used as textures or render targets
make sure they aren't skipped.

Fix suggested by Jose Fonseca.

v2: added a couple of assertions so we can actually guarantee
we check the resources and don't skip them. Also added some comments
that this is actually a lie due to the way the opengl buffer api works.

:04 04 433342731ec1897b776bb1ea286814110adff12e
9e52a970fa152e4d71d294065089988820b6 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 61361] Version mismatch error. This is libtool 2.4.2, but the definition of this LT_INIT comes from libtool 2.2.8.

2013-02-28 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=61361

--- Comment #4 from Dennis Heuer  ---
works, but can't run the checks because I have an r200 with no shaders! is the
check configurable?

-- 
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 61361] Version mismatch error. This is libtool 2.4.2, but the definition of this LT_INIT comes from libtool 2.2.8.

2013-02-28 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=61361

--- Comment #5 from Matt Turner  ---
(In reply to comment #4)
> works, but can't run the checks because I have an r200 with no shaders! is
> the check configurable?

huh?

-- 
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] llvmpipe: bump glsl version to 140

2013-02-28 Thread Andreas Boll
2013/3/1  :
> From: Roland Scheidegger 
>
> texel offsets should have been the last missing feature (not sure
> if anything is actually missing for 140). In any case we still
> don't do OpenGL 3.0 (missing MSAA which will be difficult,
> plus EXT_packed_float, ARB_depth_buffer_float and EXT_framebuffer_sRGB).
>
> v2: bump to 140 instead - we have everything except we crash when not writing
> to gl_Position (but softpipe crashes as well) so let's just say this is a bug
> instead. Also (by Dave Airlie's suggestion) update llvm-todo.txt.
> ---
>  src/gallium/docs/llvm-todo.txt   |   16 +---
>  src/gallium/drivers/llvmpipe/lp_screen.c |2 +-
>  2 files changed, 6 insertions(+), 12 deletions(-)
>
> diff --git a/src/gallium/docs/llvm-todo.txt b/src/gallium/docs/llvm-todo.txt
> index a5a8c1a..02b4b62 100644
> --- a/src/gallium/docs/llvm-todo.txt
> +++ b/src/gallium/docs/llvm-todo.txt
> @@ -4,18 +4,12 @@ TODO covering gallivm/llvmpipe
>  Goal: GL3.0 support in llvmpipe
>  ---
>
> -TXQ opcode support - airlied WIP
> -TXF opcode support.
> -Integer texture fetch support
> -Integer renderbuffer support
> -Vertex ID support.
> -EXT_transform_feedback support - airlied WIP
> -clip distance support - airlied WIP
> -vertex clip support - airlied WIP
> -EXT_texture_array support - Jakob WIP
> +EXT_packed_float support.
> +ARB_depth_buffer_float support.
> +EXT_framebuffer_sRGB support.
> +MSAA support.
> +
>
>  Goal: extension parity with softpipe:
>  -
> -GL3.0 support.
> -EXT_timer_query - airlied posted a patch
>
> diff --git a/src/gallium/drivers/llvmpipe/lp_screen.c 
> b/src/gallium/drivers/llvmpipe/lp_screen.c
> index 05bbca5..aab13b3 100644
> --- a/src/gallium/drivers/llvmpipe/lp_screen.c
> +++ b/src/gallium/drivers/llvmpipe/lp_screen.c
> @@ -195,7 +195,7 @@ llvmpipe_get_param(struct pipe_screen *screen, enum 
> pipe_cap param)
> case PIPE_CAP_VERTEX_COLOR_CLAMPED:
>return 1;
> case PIPE_CAP_GLSL_FEATURE_LEVEL:
> -  return 120;
> +  return 130;
  ^^^
I think you forgot to update this line in v2. Should be 140.

> case PIPE_CAP_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION:
>return 0;
> case PIPE_CAP_COMPUTE:
> --
> 1.7.9.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