aboutsummaryrefslogtreecommitdiffstats
path: root/src/mesa/drivers/dri/i965/brw_queryobj.c
Commit message (Collapse)AuthorAgeFilesLines
* i965: Re-combine the Gen4-5 and Gen6+ write_depth_count functions.Kenneth Graunke2014-01-201-5/+7
| | | | | | | | | Now that we have a helper function that handles the PIPE_CONTROL variations between the various platforms, these are basically the same. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965: Create a helper function for emitting PIPE_CONTROL writes.Kenneth Graunke2014-01-201-44/+12
| | | | | | | | | | | | | | | | | | | There are a lot of places that use PIPE_CONTROL to write a value to a buffer (either an immediate write, TIMESTAMP, or PS_DEPTH_COUNT). Creating a single function to do this seems convenient. As part of this refactor, we now set the PPGTT/GTT selection bit correctly on Gen7+. Previously, we set bit 2 of DW2 on all platforms. This is correct for Sandybridge, but actually part of the address on Ivybridge and later! Broadwell will also increase the length of these packets by 1; with the refactoring, we should have to adjust that in substantially fewer places, giving us confidence that we've hit them all. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965: Create a helper function for emitting PIPE_CONTROL flushes.Kenneth Graunke2014-01-201-10/+3
| | | | | | | | | | | | | | | These days, we need to emit PIPE_CONTROL flushes all over the place. Being able to do that via a single function call seems convenient. Broadwell will also increase the length of these packets by 1; with the refactoring, we should have to do this in substantially fewer places. v2: Add back forgotten intel_emit_post_sync_nonzero_flush (caught by Eric Anholt). Drop unlikely() from BLT_RING check. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965: Delete duplicate write_timestamp function.Kenneth Graunke2014-01-101-5/+5
| | | | | | | | | | brw_queryobj.c needs a version of write_timestamp that works on all generations for the QueryCounter() driver hook. So there's no point in duplicating it in gen6_queryobj.c. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Chris Forbes <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965: Delete intel_context entirely.Kenneth Graunke2013-07-091-1/+1
| | | | | | | | | | This makes brw_context inherit directly from gl_context; that was the only thing left in intel_context. Signed-off-by: Kenneth Graunke <[email protected]> Acked-by: Chris Forbes <[email protected]> Acked-by: Paul Berry <[email protected]> Acked-by: Anuj Phogat <[email protected]>
* i965: Move intel_context::gen and gt fields to brw_context.Kenneth Graunke2013-07-091-18/+10
| | | | | | | | | | Most functions no longer use intel_context, so this patch additionally removes the local "intel" variables to avoid compiler warnings. Signed-off-by: Kenneth Graunke <[email protected]> Acked-by: Chris Forbes <[email protected]> Acked-by: Paul Berry <[email protected]> Acked-by: Anuj Phogat <[email protected]>
* i965: Move intel_context::perf_debug to brw_context.Kenneth Graunke2013-07-091-1/+1
| | | | | | | Signed-off-by: Kenneth Graunke <[email protected]> Acked-by: Chris Forbes <[email protected]> Acked-by: Paul Berry <[email protected]> Acked-by: Anuj Phogat <[email protected]>
* i965: Move intel_context::stats_wm to brw_context.Kenneth Graunke2013-07-091-2/+2
| | | | | | | Signed-off-by: Kenneth Graunke <[email protected]> Acked-by: Chris Forbes <[email protected]> Acked-by: Paul Berry <[email protected]> Acked-by: Anuj Phogat <[email protected]>
* i965: Move intel_context::batch to brw_context.Kenneth Graunke2013-07-091-2/+2
| | | | | | | Signed-off-by: Kenneth Graunke <[email protected]> Acked-by: Chris Forbes <[email protected]> Acked-by: Paul Berry <[email protected]> Acked-by: Anuj Phogat <[email protected]>
* i965: Move intel_context::hw_ctx to brw_context.Kenneth Graunke2013-07-091-3/+2
| | | | | | | Signed-off-by: Kenneth Graunke <[email protected]> Acked-by: Chris Forbes <[email protected]> Acked-by: Paul Berry <[email protected]> Acked-by: Anuj Phogat <[email protected]>
* i965: Move intel_context::bufmgr to brw_context.Kenneth Graunke2013-07-091-6/+6
| | | | | | | Signed-off-by: Kenneth Graunke <[email protected]> Acked-by: Chris Forbes <[email protected]> Acked-by: Paul Berry <[email protected]> Acked-by: Anuj Phogat <[email protected]>
* i965: Pass brw_context to functions rather than intel_context.Kenneth Graunke2013-07-091-9/+14
| | | | | | | | | | | | | | This makes brw_context available in every function that used intel_context. This makes it possible to start migrating fields from intel_context to brw_context. Surprisingly, this actually removes some code, as functions that use OUT_BATCH don't need to declare "intel"; they just use "brw." Signed-off-by: Kenneth Graunke <[email protected]> Acked-by: Chris Forbes <[email protected]> Acked-by: Paul Berry <[email protected]> Acked-by: Anuj Phogat <[email protected]>
* i965: Remove software geometry query code.Kenneth Graunke2013-05-211-52/+0
| | | | | | | | | | EXT_transform_feedback isn't yet supported on Gen4-5, so none of this query code is actually used. This also means we can remove some of the surrounding support code. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Paul Berry <[email protected]>
* i965: Rely on hardware contexts for query objects on Gen6+.Kenneth Graunke2013-05-201-71/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | Hardware contexts greatly simplify the query object code. The pipeline statistics counters get saved and restored with the context, which means that we don't need to worry about other workloads polluting them. This means that we can simply write a single pair of values (one at BeginQuery and one at EndQuery) rather than a series of pairs. This also means we don't need to worry about the BO getting full. We also don't need to delay BO allocation and starting snapshot until the first draw. The generation split here is a little off: technically, Ironlake can also support hardware contexts. However, the kernel currently doesn't, and even if it were to do so someday, we'd need to wait a while before bumping the kernel requirement to take advantage of it. v2: Incorporate Paul's feedback. - Clarify which functions are Gen4/5-only via assertions and comments. - Change how driver hook initialization happens. - Update comments. - Squash a bug fix from a later commit here where it belongs. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]> [v1] Acked-by: Paul Berry <[email protected]>
* mesa: don't flag _NEW_DEPTH in Begin/EndQuery if driver implements the functionsMarek Olšák2013-04-241-0/+2
| | | | | | | | | | | We don't want to set the flag for Gallium. I think only swrast needs the flag to be set for occlusion queries. v2: fix stats_wm updates in i965 Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965: Fix a mistake in the comments for software counters.Kenneth Graunke2013-04-221-2/+2
| | | | | | | The code doesn't set brw->query.obj to NULL, it sets query->bo to NULL. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965: Don't fill buffer with zeroes.Kenneth Graunke2013-03-061-6/+0
| | | | | | | | This was only necessary because our bounds checking was off by one, and thus we read an extra pair of values. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965: Fix off-by-one in query object result gathering.Kenneth Graunke2013-03-061-2/+2
| | | | | | | | | | | If we've written N pairs of values to the buffer, then last_index = N, but the values are 0 .. N-1. Thus, we need to use <, not <=. This worked anyway because we fill the buffer with zeroes, so we just added an extra (0 - 0) to our results. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965: Make perf_debug() output to GL_ARB_debug_output in a debug context.Eric Anholt2013-03-051-1/+1
| | | | | | | | I tried to ensure that performance in the non-debug case doesn't change (we still just check one condition up front), and I think the impact is small enough in the debug context case to warrant including all of it. Reviewed-by: Jordan Justen <[email protected]>
* i965: Pull query BO reallocation out into a helper function.Kenneth Graunke2013-03-011-23/+33
| | | | | | | | | 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 <[email protected]>
* i965: Replace the global brw->query.bo variable with query->bo.Kenneth Graunke2013-03-011-15/+7
| | | | | | | | | | 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 <[email protected]>
* i965: Turn if (query->bo) into an assertion.Kenneth Graunke2013-03-011-5/+5
| | | | | | | 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 <[email protected]>
* i965: Unify query object BO reallocation code.Kenneth Graunke2013-03-011-11/+10
| | | | | | | | | | | | | 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 <[email protected]>
* i965: Use query->last_index instead of the global brw->query.index.Kenneth Graunke2013-03-011-6/+6
| | | | | | | | | | | | 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 <[email protected]>
* i965: Remove brw_query_object::first_index field as it's always 0.Kenneth Graunke2013-03-011-4/+2
| | | | | | | | | | | 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 <[email protected]>
* i965: Add a pile of comments to brw_queryobj.c.Kenneth Graunke2013-03-011-16/+143
| | | | | | | | | | | | | | | | | | | | | | | | | | 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. v2: Incorporate Eric's feedback: change "as soon as possible" to "the results will be present when mapped." Signed-off-by: Kenneth Graunke <[email protected]>
* i965: Write TIMESTAMP query values into the first buffer element.Kenneth Graunke2013-03-011-4/+3
| | | | | | | | | | 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 <[email protected]>
* i965: Implement the new QueryCounter() hook.Kenneth Graunke2013-03-011-6/+21
| | | | | | This moves the GL_TIMESTAMP handling out of EndQuery. Signed-off-by: Kenneth Graunke <[email protected]>
* i965: Force even an empty query to flush all previous queries.Carl Worth2013-01-151-0/+17
| | | | | | | | | | | | | | | | | | The specification requires that query results are processed in order, (when one query result is returned, all previous query of the same type must also be available). The implementation was failing this requirement in the case of BeginQuery and EndQuery with no intervening drawing, (the result would be made available immediately without flushing previous queries). This fixes the following es3conform test: occlusion_query_query_order as well as the following piglit test: occlusion_query_order Reviewed-by: Ian Romanick <[email protected]>
* i965: Add support for GL_ANY_SAMPLES_PASSED_CONSERVATIVEIan Romanick2013-01-111-0/+3
| | | | | | | | We just treat this as an alias for GL_ANY_SAMPLES_PASSED. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Merge brw_prepare_query_begin() and brw_emit_query_begin().Eric Anholt2012-10-261-17/+6
| | | | | | | This is a leftover from when we had to split those two functions due to the separate BO validation step. Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Rename misleading "active" field of brw->query.Eric Anholt2012-10-261-4/+4
| | | | | | | | | "Active" is an already-used term for the query being between glBeginQuery() and glEndQuery(), while this is tracking whether the start of the packet pair for emitting state has been inserted into the current batchbuffer. Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Actually add support for GL_ANY_SAMPLES_PASSED from GL_ARB_oq2.Eric Anholt2012-10-221-0/+12
| | | | | | v2: Fix mangled sentence in the comment, and make the loop exit early. Reviewed-by: Ian Romanick <[email protected]> (v1)
* i965: Stop flushing the batch on timestamp queries, too.Eric Anholt2012-10-191-1/+0
| | | | | | | Given the usecase we have of trying to measure timestamps across individual draw calls, flushing will totally mess up what people are trying to measure. Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Don't flush the batch immediately on EndQuery.Eric Anholt2012-10-191-5/+14
| | | | | | | | | | | | | | | | The theory I had when I wrote the code was that you wanted to minimize latency on your queries because the app was going to ask soon. Only, it turns out that everybody batches up their queries and asks for the results later (often after the next SwapBuffers!), so this was a pessimization. Until now, I had no workload where it mattered enough to benchmark. Recently I started playing some Minecraft, which uses tons of queries to decide whether to render chunks of the terrain. For that app, avoiding the flush in the query-generation loop improves performance 22.7% +/- 4.7% (n=3) on an apitrace capture of it (confirmed in game by watching the fps meter found by pressing F3, 15/16 -> 20/21 fps). Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Rewrite the comment describing the query object support.Eric Anholt2012-08-261-10/+12
| | | | Reviewed-by: Kenneth Graunke <[email protected]>
* i965/gen6+: Add support for GL_ARB_timer_query.Eric Anholt2012-08-261-0/+50
| | | | | | Needs updated libdrm. Reviewed-by: Kenneth Graunke <[email protected]>
* intel: Add performance debug for some common GPU stalls.Eric Anholt2012-08-121-0/+6
| | | | | Reviewed-by: Jordan Justen <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Rework the extra flushes surrounding occlusion queries.Kenneth Graunke2012-08-081-7/+4
| | | | | | | | | | | | This removes the CS stall on Ivybridge. On Sandybridge, the depth stall needs to be preceded by a non-zero post-sync op, which requires a CS stall, which needs a stall at scoreboard. Emit the full workaround. Reviewed-by: Daniel Vetter <[email protected]> Cc: Eric Anholt <[email protected]> Signed-off-by: Kenneth Graunke <[email protected]>
* i965: Use 64-bit writes for occlusion queries.Kenneth Graunke2012-08-081-2/+3
| | | | | | | | | | | | | | | The hardware seems to use the length of the PIPE_CONTROL command to indicate whether the write is 64-bits or 32-bits. Which makes sense for immediate writes. Daniel discovered this by writing a pattern into the query object bo and noticing that the high 32-bits were left intact, even on those pipe control writes that seemingly worked. Signed-off-by: Daniel Vetter <[email protected]> Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965: Refactor depth count write PIPE_CONTROLs into a helper function.Kenneth Graunke2012-08-081-68/+43
| | | | | | | | | | This consolidates the complexity in one place, which is important because it's about to get even more complicated. Signed-off-by: Kenneth Graunke <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965: Emit a CS stall before timestamp writes.Kenneth Graunke2012-08-081-0/+14
| | | | | | | | | | This implements one of the Sandybridge PIPE_CONTROL workarounds. It doesn't appear to be required for Ivybridge. Signed-off-by: Kenneth Graunke <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965: Use 64-bit writes for timestamp queries.Kenneth Graunke2012-08-081-2/+3
| | | | | | | | | | | | | | | The hardware seems to use the length of the PIPE_CONTROL command to indicate whether the write is 64-bits or 32-bits. Which makes sense for immediate writes. Daniel discovered this by writing a pattern into the query object bo and noticing that the high 32-bits were left intact, even on those pipe control writes that seemingly worked. Signed-off-by: Daniel Vetter <[email protected]> Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965: Refactor timestamp write PIPE_CONTROLs into a helper function.Kenneth Graunke2012-08-081-50/+30
| | | | | | | | | This consolidates the complexity in one place, which is important because it's about to get even more complicated. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* intel: Make the length for PIPE_CONTROL explicit.Kenneth Graunke2012-08-081-10/+10
| | | | | | | | | | | | | | | | PIPE_CONTROL has variable length, depending upon generation and whether we want to do 32-bit or 64-bit data writes. Make it explicit, rather than hiding a length of 4 in the #define for _3DSTATE_PIPE_CONTROL. Generated by s/3DSTATE_PIPE_CONTROL/3DSTATE_PIPE_CONTROL | (4 - 2)/g. This is equivalent since the #define used to have | 2 in it. A grep through the sources shows that all instances have been converted, so it's safe to remove the | 2 from the #define. Signed-off-by: Daniel Vetter <[email protected]> Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965: fix transform feedback with primitive restartJordan Justen2012-07-021-0/+4
| | | | | | | | | | | | | | | | | When querying GL_PRIMITIVES_GENERATED, if primitive restart is also used, then take the software primitive restart path so GL_PRIMITIVES_GENERATED is returned correctly. GL_TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN is also updated since it will also affected by the same issue. As noted in brw_primitive_restart.c, with further work we should be able to move this situation back to a hardware handled path. Signed-off-by: Jordan Justen <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965 gen6: Implement transform feedback queries.Paul Berry2011-12-201-0/+48
| | | | | | | | | | | | | | | | | | | | This patch adds software-based PRIMITIVES_GENERATED and TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN queries that work by keeping track of the number of primitives that are sent down the pipeline, and adjusting as necessary to account for the way each primitive type is tessellated. In the long run we'll want to replace this with a hardware-based implementation, because the software approach won't work with geometry shaders or primitive restart. However, at the moment, we don't have the necessary kernel support to implement a hardware-based query (we would need the kernel to save GPU registers when context switching, so that drawing performed by another process doesn't get counted). Fixes Piglit tests EXT_transform_feedback/query-primitives_generated-* and EXT_transform_feedback/query-primitives-written-*. Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Convert if/else to switch statements in brw_queryobj.cPaul Berry2011-12-201-6/+30
| | | | | | | | | | | | | Previously, i965 only supported two query types: GL_TIME_ELAPSED_EXT and GL_SAMPLES_PASSED_ARB, and it distinguished between the two using if/else statements that compared query->Base.Target to GL_TIME_ELAPSED_EXT. This patch changes the if/else statements to switch statements so that we can add more query types without having to have a chain of else-ifs. Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Remove the validated BO list, now that it's unused.Eric Anholt2011-10-291-2/+0
| | | | | Reviewed-by: Kenneth Graunke <[email protected]> Acked-by: Paul Berry <[email protected]>
* intel: Convert from GLboolean to 'bool' from stdbool.h.Kenneth Graunke2011-10-181-8/+8
| | | | | | | | | | | | | | | | | I initially produced the patch using this bash command: for file in {intel,i915,i965}/*.{c,cpp,h}; do [ ! -h $file ] && sed -i 's/GLboolean/bool/g' $file && sed -i 's/GL_TRUE/true/g' $file && sed -i 's/GL_FALSE/false/g' $file; done Then I manually added #include <stdbool.h> to fix compilation errors, and converted a few functions back to GLboolean that were used in core Mesa's function pointer table to avoid "incompatible pointer" warnings. Finally, I cleaned up some whitespace issues introduced by the change. Signed-off-by: Kenneth Graunke <[email protected]> Acked-by: Chad Versace <[email protected]> Acked-by: Paul Berry <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-04 01:54:20 +0000