| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I missed this in the boolean -> enum conversion. C cheerfully casts
false -> 0 -> UNKNOWN_RING. On Gen4-5, this causes the render ring
prelude hook to get called in the middle of the batch, which is crazy.
BRW_BATCH_STRUCT is not used on Gen6+.
Fixes regressions since 395a32717df494353703f3581edcd3ba380f16d6
("i965: Introduce an UNKNOWN_RING state.").
Fixes "fips -v glxgears" on Ironlake.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit a4bf7f6b6e612626c4e4fc21507ac213a7ba4b00.
It breaks occlusion queries on Gen4-5. Doing this right will likely
require larger changes, which should be done at a future date.
Some Piglit tests still passed due to other bugs; fixing those revealed
this problem.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I guarded half of the callers to start/stop_oa_counters with generation
checks, but missed the other half (which were added later). OACONTROL
doesn't exist on Ironlake, so we better not write it. Also, there's no
need---Ironlake's performance counters are always running.
This patch moves the generation checks into start/stop_oa_counters,
rather than requiring the caller to do them.
Fixes assertion failures in Piglit's AMD_performance_monitor/measure.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The BSpec states that the aligment for the non-msrt clear rectangle must
be doubled; the BSpec does not restricit the workaround to specific
hardware.
Commit 9a1a67b applied the workaround to Haswell GT3. Commit 8b659ce
expanded the workaround to all Haswell variants. This commit expands it
to all hardware.
No Piglit regressions on Ivybridge 0x0166. No fixes either.
I know no Ivybridge nor Baytrail bug related to this workaround.
However, the BSpec says the extra alignment is required, so let's do it.
v2: Apply to all hardware, not just gen7.
CC: "9.2, 10.0" <[email protected]>
CC: Anuj Phogat <[email protected]>
Reviewed-by: Paul Berry <[email protected]>
Signed-off-by: Chad Versace <[email protected]>
|
|
|
|
|
|
|
|
|
| |
MI_STORE_REGISTER_MEM has to take a 48-bit address, so the existing code
doesn't work. But supposedly Broadwell has a register whitelist and
just works out of the box anyway, so there's no need to check.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Gen7 sampler state code still works. Increasing the alignment to
64 bytes makes bit 5 zero, which is good because it's now reserved.
Since we don't use the new filter bits, we can leave those as zero too,
which means we don't need to update the code to update the pointer.
(We probably should anyway, for clarity, but alas, another day.)
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
The documentation is really hard to follow, but apparently a 32-bit x
32-bit multiply just works without the MACH macro. The macro apparently
is only necessary to get the full 64-bit value.
Fixes Piglit tests [vf]s-op-mult-int-int.shader_test.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
| |
Like Haswell, we do this in SURFACE_STATE rather than shader
workarounds.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Broadwell doesn't support a surface vertical alignment of 2. It only
supports VALIGN_4, VALIGN_8, or VALIGN_16. I chose 4 since it's the
least wasteful.
v2: Replace my comment with a better one from Eric. Move Broadwell
checks earlier so it's more obvious that "return 2" won't be hit.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
We need to SEND from a GRF, and we can only obtain those prior to
register allocation.
This allows us to do pull constant loads without the MRF hack.
v2: Reword comments (suggested by Paul).
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Paul Berry <[email protected]>
|
|
|
|
|
|
|
|
| |
SEND can't deal with swizzles, source modifiers, and so on. This should
avoid problems with VS pull constant loads on Broadwell.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Pre-patch, the workaround was applied to only HSW GT3. However, the
workaround also fixes render corruption on the HSW GT1 Chromebook,
codenamed Falco.
Also, update the BSpec quote that discusses the workaround to reflect
the latest BSpec.
The BSpec states that the workaround is required for Ivybridge and
Baytrail as well as Haswell. But, we apply the workaround to only
Haswell because (a) we suspect that is the only hardware where it is
actually required and (b) we haven't yet validated the workaround for
the other hardware.
CC: "9.2, 10.0" <[email protected]>
CC: Anuj Phogat <[email protected]>
OTC-Tracker: CHRMOS-812
Reviewed-by: Paul Berry <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
Signed-off-by: Chad Versace <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On gen6, multisamble resolve blits use the SAMPLE message to blend
together the 4 samples for each texel. For some reason, SAMPLE
doesn't blend together the proper samples when the source format is
L32_FLOAT or I32_FLOAT, resulting in blocky artifacts.
To work around this problem, sample from the source surface using
R32_FLOAT. This shouldn't affect rendering correctness, because when
doing these resolve blits, the destination format is R32_FLOAT, so the
channel replication done by L32_FLOAT and I32_FLOAT is unnecessary.
Fixes piglit tests on Sandy Bridge:
- spec/ARB_texture_float/multisample-formats 2 GL_ARB_texture_float
- spec/ARB_texture_float/multisample-formats 4 GL_ARB_texture_float
No piglit regressions on Sandy Bridge.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70601
Cc: Kenneth Graunke <[email protected]>
Cc: [email protected]
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
__DRI2_ROBUSTNESS is not enabled
Only allow __DRI_CTX_FLAG_ROBUST_BUFFER_ACCESS in brwCreateContext if
intelInitScreen2 also enabled __DRI2_ROBUSTNESS (thereby enabling
GLX_ARB_create_context).
This fixes a regression in the piglit test
"glx/GLX_ARB_create_context/invalid flag"
v2: Remove commented debug code. Noticed by Jordan.
Signed-off-by: Ian Romanick <[email protected]>
Reported-by: Paul Berry <[email protected]>
Reviewed-by: Jordan Justen <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
Cc: "10.0" <[email protected]>
|
|
|
|
|
|
|
| |
This reverts commit 195994fe4cd851f4aed7fe32697f94c4188a96c8.
It wasn't sent to the list, Ken didn't review it, and it breaks
shader-db.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In brw_update_renderbuffer_surfaces(), if there are no color draw
buffers, we always set up a null render target at surface index 0 so we
have something to use with the FB write marking the end of thread.
However, when we recently began computing surface indexes dynamically,
we failed to reserve space for it. This meant that the first texture
would be assigned surface index 0, and our closing FB write would
clobber the texture.
Fixes Piglit's EXT_packed_depth_stencil/fbo-blit-d24s8 test on Gen4-5,
which regressed as of commit 4e5306453da6a1c076309e543ec92d999e02f67a
("i965/fs: Dynamically set up the WM binding table offsets.")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70605
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Chris Forbes <[email protected]>
Tested-by: lu hua <[email protected]>
Cc: "10.0" [email protected]
|
|
|
|
| |
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
| |
Now that we have dynamic binding tables there's no good reason anymore
to expose so few atomic counter buffers. Increase it to 16.
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The previous commit fixes a bug wherein we would incorrectly refer to
stale geometry shader prog_data when no geometry shader was active.
This patch reduces the likelihood of that sort of bug occurring in the
future by setting prog_data to NULL whenever there is no GS program.
Cc: [email protected]
Reviewed-by: Eric Anholt <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, in brw_gs_upload_binding_table(), we checked whether
brw->gs.prog_data was NULL in order to determine whether a geometry
shader was active. This didn't work: brw->gs.prog_data starts off as
NULL, but it is set to non-NULL when a geometry shader program is
built, and then never set to NULL again. As a result, if we called
brw_gs_upload_binding_table() while there was no geometry shader
active, but a geometry shader had previously been active, it would
refer to a stale (and possibly freed) prog_data structure.
This patch fixes the problem by modifying
brw_gs_upload_binding_table() to use the proper technique to determine
whether a geometry shader is active: by checking whether
brw->geometry_program is NULL.
This fixes the crash reported in comment 2 of bug 71870 (the incorrect
rendering remains, however).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71870
Cc: [email protected]
Reviewed-by: Chris Forbes <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
| |
Signed-off-by: Ian Romanick <[email protected]>
Reported-by: Zhenyu Wang <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
Cc: "10.0" <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rather than always advertising the extension but failing to create a
context with reset notifiction, just don't advertise it. I don't know
why it didn't occur to me to do it this way in the first place.
NOTE: Kristian requested that I provide a follow-up for master that
dynamically generates the list of DRI extensions instead of selected
between two hardcoded lists.
Signed-off-by: Ian Romanick <[email protected]>
Suggested-by: Kristian Høgsberg <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Kristian Høgsberg <[email protected]>
Cc: "10.0" <[email protected]>
|
|
|
|
|
|
|
|
|
| |
libdrm 2.4.48 has been released.
This reverts commit bd4596efac2b783b789392a222da909efcd0fd3b.
Reviewed-by: Matt Turner <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The fast tiled texture upload code does not compile with GCC 4.8's -Og
optimization flag.
memcpy() has the always_inline attribute set. This poses a problem,
since {x,y}tile_copy_faster calls it indirectly via {x,y}tile_copy,
and {x,y}tile_copy normally aren't inlined at -Og.
Using __attribute__((flatten)) tells GCC to inline every function call
inside the function, which I believe was the author's intent.
Fix suggested by Alexander Monakov.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
Reviewed-by: Chad Versace <[email protected]>
Cc: [email protected]
|
|
|
|
|
|
|
|
|
|
|
| |
.. and mark them off on the extensions list as done.
V2: Enable only if pipelined register writes work.
V3: Also update relnotes
Signed-off-by: Chris Forbes <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
| |
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
| |
Signed-off-by: Chris Forbes <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Just prior to emitting the 3DPRIMITIVE command, we load each of the
indirect registers. The values loaded are either from offsets into the
current indirect BO, or constant zero if the parameter is not used for
this draw.
Enabling use of the indirect registers is done by turning on a bit in
the first dword of the 3DPRIMITIVE command itself.
V3: - Deduplicate the common part of both indexed and nonindexed indirect
setup.
- Just refer to the indirect bo out of the context directly.
V4: - Fix bo reference to specify the range we care about.
Signed-off-by: Chris Forbes <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
| |
- MMIO registers for draw parameters
- New bit in 3DPRIMITIVE command to enable indirection
Signed-off-by: Chris Forbes <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Split from patch implementing ARB_draw_indirect.
v2: Const-qualify the struct gl_buffer_object *indirect argument.
v3: Fix up some more draw calls for new argument.
v4: Fix up rebase conflicts in i965.
v5: Undo const-qualification
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
| |
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Chris Forbes <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
| |
DEBUG_IOCTL comes from i965, and is about to be removed. Both defines
have the same value (4).
Signed-off-by: Chris Forbes <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Alex Deucher <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Jordan Justen <[email protected]>
Reviewed-by: Paul Berry <[email protected]>
|
|
|
|
|
| |
Reviewed-by: Ian Romanick <[email protected]>
Tested-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I recently made us try two different things that tried to reduce register
pressure so that we would be more likely to allocate successfully. But
now that we have the logic for trying two, we can make the first thing we
try be the normal, not-prioritizing-register-pressure heuristic.
This means one less scheduling pass in the common case of that heuristic
not producing spills, plus the best schedule we know how to produce, if
that one happens to succeed. This is important, because our register
allocation produces a lot of possibly avoidable dependencies for the
post-register-allocation schedule, despite ra_set_allocate_round_robin().
GLB2.7: 1.04127% +/- 0.732461% fps improvement (n=31)
nexuiz: No difference (n=5)
lightsmark: 0.838512% +/- 0.300147% fps improvement (n=86)
minecraft apitrace: No difference (n=15)
Reviewed-by: Jordan Justen <[email protected]>
|
|
|
|
|
|
|
|
|
| |
I think I was thinking of the batch command packet cache when I pasted
this in, but this counter is only used for dumping out streamed state for
INTEL_DEBUG=batch and for putting annotations in our aub files.
Cc: "10.0" <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit 2f89662 added the driconf option 'clamp_max_samples'. In that
commit, the option did not alter the context version. The neglect to
alter the context version is a fatal issue for some apps.
For example, consider running Chromium with clamp_max_samples=0.
Pre-patch, Mesa creates a GL 3.0 context but clamps GL_MAX_SAMPLES to
0. This violates the GL 3.0 spec, which requires GL_MAX_SAMPLES >= 4.
The spec violation causes WebGL context creation to fail in many
scenarios because Chromium correctly assumes that a GL 3.0 context
supports at least 4 samples.
Since the driconf option was introduced largely for Chromium, the issue
really needs fixing.
This patch fixes calculation of the context version to respect the
post-clamped value of GL_MAX_SAMPLES. This in turn fixes WebGL on
Chromium when clamp_max_samples=0.
Reviewed-by: Kenneth Graunke <[email protected]>
Signed-off-by: Chad Versace <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
clamp_max_samples() and intel_quantize_num_samples() each maintained
their own list of which MSAA modes the hardware supports. This patch
removes the duplication by making intel_quantize_num_samples() use the
same list as clamp_max_samples(), the list maintained in
brw_supported_msaa_modes().
By removing the duplication, we prevent the scenario where someone
updates one list but forgets to update the other.
Move function `brw_context.c:static brw_supported_msaa_modes()` to
`intel_screen.c:(non-static) intel_supported_msaa_modes()` and patch
intel_quantize_num_samples() to use the list returned by that function.
Reviewed-by: Kenneth Graunke <[email protected]>
Signed-off-by: Chad Versace <[email protected]>
|
|
|
|
|
|
|
|
| |
This simplifies the loop logic in a subsqequent patch that refactors
intel_quantize_num_samples() to use brw_supported_msaa_modes().
Reviewed-by: Kenneth Graunke <[email protected]>
Signed-off-by: Chad Versace <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes MSVC build.
meta.c(2411) : error C2143: syntax error : missing ';' before 'type'
meta.c(2411) : error C2143: syntax error : missing ')' before 'type'
meta.c(2411) : error C2065: 'layer' : undeclared identifier
meta.c(2411) : error C2059: syntax error : ')'
meta.c(2411) : error C2143: syntax error : missing ';' before '{'
meta.c(2413) : error C2065: 'layer' : undeclared identifier
meta.c(2415) : error C2065: 'layer' : undeclared identifier
Signed-off-by: Vinson Lee <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
From section 4.4.7 (Layered Framebuffers) of the GLSL 3.2 spec:
When the Clear or ClearBuffer* commands are used to clear a
layered framebuffer attachment, all layers of the attachment are
cleared.
This patch fixes the fast depth clear path.
Fixes piglit test "spec/!OpenGL 3.2/layered-rendering/clear-depth".
Cc: "10.0" <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
Reviewed-by: Jordan Justen <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
From section 4.4.7 (Layered Framebuffers) of the GLSL 3.2 spec:
When the Clear or ClearBuffer* commands are used to clear a
layered framebuffer attachment, all layers of the attachment are
cleared.
This patch fixes the blorp clear path for color buffers.
Fixes piglit test "spec/!OpenGL 3.2/layered-rendering/clear-color".
Cc: "10.0" <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
Reviewed-by: Jordan Justen <[email protected]>
|
|
|
|
|
|
|
| |
Cc: "10.0" <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
Reviewed-by: Jordan Justen <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
From section 4.4.7 (Layered Framebuffers) of the GLSL 3.2 spec:
When the Clear or ClearBuffer* commands are used to clear a
layered framebuffer attachment, all layers of the attachment are
cleared.
This patch fixes meta clears to properly clear all layers of a layered
framebuffer attachment. We accomplish this by adding a geometry
shader to the meta clear program which sets gl_Layer to a uniform
value. When clearing a layered framebuffer, we execute in a loop,
setting the uniform to point to each layer in turn.
Cc: "10.0" <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
Reviewed-by: Jordan Justen <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In order to properly clear layered framebuffers, we need to know how
many layers they have. The easiest way to do this is to record it in
the gl_framebuffer struct when we check framebuffer completeness.
This patch replaces the gl_framebuffer::Layered boolean with a
gl_framebuffer::NumLayers integer, which is 0 if the framebuffer is
not layered, and equal to the number of layers otherwise.
v2: Remove gl_framebuffer::Layered and make gl_framebuffer::NumLayers
always have a defined value. Fix factor of 6 error in the number of
layers in a cube map array.
Cc: "10.0" <[email protected]>
Reviewed-by: Chris Forbes <[email protected]>
Reviewed-by: Jordan Justen <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Unfortunately, our hardware only has one set of aggregating performance
counters shared between all 3D programs, and their values are not saved
or restored by hardware contexts. Also, at least on Sandybridge and
Ivybridge, the counters lose their values if the GPU goes to sleep.
To work around both of these problems, we have to snapshot the
performance counters at the beginning and end of each batch, similar to
how we handle query objects on platforms that don't support hardware
contexts. I call these "bookend" snapshots.
Since there can be multiple performance monitors active at a time, we
store the bookend snapshots in a global BO, shared by all monitors.
For monitors that span multiple batches, acquiring results involves
adding up three segments:
BeginPerfMonitor --> End of Batch 1 ("head")
Start of Batch 2 --> End of Batch 2
... ("middle")
Start of Batch N-1 --> End of Batch N-1
Start of Batch N --> EndPerfMonitor ("tail")
Monitors that refer to bookend BO snapshots are considered "unresolved".
We delay resolving them (and adding up deltas to obtain the results) as
long as possible to avoid blocking on mapping monitor->oa_bo.
We can also run out of space in the bookend BO, at which point we have
to resolve all unresolved monitors. Then we can throw away the
snapshots and begin writing at the beginning of the buffer.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In order to use the Observability Architecture effectively, we'll need
to take snapshots of the OA counters via MI_REPORT_PERF_COUNT at the
start and end of each batch.
Experimentation reveals that we need to flush before and after each
MI_REPORT_PERF_COUNT to get working values. For simplicitly, I chose to
use intel_batchbuffer_emit_mi_flush(), which unfortunately expands to
triple pipe controls on Sandybridge.
We may want to start computing per-generation reserved batch space to
avoid the insanity of Sandybridge's PIPE_CONTROL cost. That said, much
of this cost existed before I rewrote the query object support to use
hardware contexts, so it's at least not entirely new.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Currently, this only considers the monitor start and end snapshots.
This is woefully insufficient, but allows me to add a bunch of the
infrastructure now and flesh it out later.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|