[Mesa-dev] i965 query object tidying
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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.
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.
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.
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.
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
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
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
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.
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.
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.
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
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.
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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()
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
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
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
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
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
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
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
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.
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
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.
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.
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.
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.
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
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.
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.
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.
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.
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/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