summaryrefslogtreecommitdiffstats
path: root/src/mesa/drivers/dri/i965/gen6_depthstencil.c
Commit message (Collapse)AuthorAgeFilesLines
* i965: Delete brw_state_flags::cache and related code.Kenneth Graunke2014-12-021-1/+0
| | | | | | | | | It's been merged into brw_state_flags::brw for simplicity and efficiency. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Kristian Høgsberg <krh@bitplanet.net> Reviewed-by: Matt Turner <mattst88@gmail.com>
* i965: Alphabetize brw_tracked_state flags and use a consistent style.Kenneth Graunke2014-11-291-2/+5
| | | | | | | | | | | | | | | | Most of the dirty flags were listed in some arbitrary order. Some used bonus parenthesis. Some put multiple flags on one line, others put one per line. Some used tabs instead of spaces...but only on some lines. This patch settles on one flag per line, in alphabetical order, using spaces instead of tabs, and sheds the unnecessary parentheses. Sorting was mostly done with vim's visual block feature and !sort, although I alphabetized short lists by hand; it was pretty manual. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Kristian Høgsberg <krh@bitplanet.net> Reviewed-by: Matt Turner <mattst88@gmail.com>
* 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 <kenneth@whitecape.org> Acked-by: Chris Forbes <chrisf@ijw.co.nz> Acked-by: Paul Berry <stereotype441@gmail.com> Acked-by: Anuj Phogat <anuj.phogat@gmail.com>
* i965: Move intel_context::gen and gt fields to brw_context.Kenneth Graunke2013-07-091-2/+1
| | | | | | | | | | 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 <kenneth@whitecape.org> Acked-by: Chris Forbes <chrisf@ijw.co.nz> Acked-by: Paul Berry <stereotype441@gmail.com> Acked-by: Anuj Phogat <anuj.phogat@gmail.com>
* intel: Stop doing special _NEW_STENCIL state flagging on drawbuffers.Eric Anholt2013-06-251-1/+1
| | | | | | | | 2/3 packets depending on Stencil._Enabled already checked for _NEW_BUFFERS, so just add _NEW_BUFFERS to the remaining one. Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* i965: Emit the depth/stencil state pointer directly, not via atoms.Kenneth Graunke2013-06-111-2/+18
| | | | | | | | | | | | | | | | | | | | | See two commits ago for the rationale. This allows us to delete the whole gen7_cc_state.c file. This does move these commands before the depth stall flushes from brw_emit_depthbuffer, which may be a problem. The documentation for 3DSTATE_DEPTH_BUFFER mentions that depth stall flushes are required before changing any depth/stencil buffer state, but explicitly lists 3DSTATE_DEPTH_BUFFER, 3DSTATE_HIER_DEPTH_BUFFER, 3DSTATE_STENCIL_BUFFER, and 3DSTATE_CLEAR_PARAMS. It does not mention this particular packet (_3DSTATE_DEPTH_STENCIL_STATE_POINTERS). No observed Piglit regressions on Sandybridge or Ivybridge. Together with the last two commits, this makes a cairo-gl benchmark faster by 0.324552% +/- 0.258355% on Ivybridge. No statistically significant change on Sandybridge. (Thanks to Eric for the numbers.) Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
* i965: Use ctx->Stencil._WriteEnabled in DEPTH_STENCIL_STATE.Kenneth Graunke2013-04-041-5/+1
| | | | | | | | This is the same computation as the _WriteEnabled flag, so we may as well use it. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Paul Berry <stereotype441@gmail.com>
* i965: Rewrite the HiZ opChad Versace2012-02-071-7/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The HiZ op was implemented as a meta-op. This patch reimplements it by emitting a special HiZ batch. This fixes several known bugs, and likely a lot of undiscovered ones too. ==== Why the HiZ meta-op needed to die ==== The HiZ op was implemented as a meta-op, which caused lots of trouble. All other meta-ops occur as a result of some GL call (for example, glClear and glGenerateMipmap), but the HiZ meta-op was special. It was called in places that Mesa (in particular, the vbo and swrast modules) did not expect---and were not prepared for---state changes to occur (for example: glDraw; glCallList; within glBegin/End blocks; and within swrast_prepare_render as a result of intel_miptree_map). In an attempt to work around these unexpected state changes, I added two hooks in i965: - A hook for glDraw, located in brw_predraw_resolve_buffers (which is called in the glDraw path). This hook detected if a predraw resolve meta-op had occurred, and would hackishly repropagate some GL state if necessary. This ensured that the meta-op state changes would not intefere with the vbo module's subsequent execution of glDraw. - A hook for glBegin, implemented by brwPrepareExecBegin. This hook resolved all buffers before entering a glBegin/End block, thus preventing an infinitely recurring call to vbo_exec_FlushVertices. The vbo module calls vbo_exec_FlushVertices to flush its vertex queue in response to GL state changes. Unfortunately, these hooks were not sufficient. The meta-op state changes still interacted badly with glPopAttrib (as discovered in bug 44927) and with swrast rendering (as discovered by debugging gen6's swrast fallback for glBitmap). I expect there are more undiscovered bugs. Rather than play whack-a-mole in a minefield, the sane approach is to replace the HiZ meta-op with something safer. ==== How it was killed ==== This patch consists of several logical components: 1. Rewrite the HiZ op by replacing function gen6_resolve_slice with gen6_hiz_exec and gen7_hiz_exec. The new functions do not call a meta-op, but instead manually construct and emit a batch to "draw" the HiZ op's rectangle primitive. The new functions alter no GL state. 2. Add fields to brw_context::hiz for the new HiZ op. 3. Emit a workaround flush when toggling 3DSTATE_VS.VsFunctionEnable. 4. Kill all dead HiZ code: - the function gen6_resolve_slice - the dirty flag BRW_NEW_HIZ - the dead fields in brw_context::hiz - the state packet manipulation triggered by the now removed brw_context::hiz::op - the meta-op workaround in brw_predraw_resolve_buffers (discussed above) - the meta-op workaround brwPrepareExecBegin (discussed above) Note: This is a candidate for the 8.0 branch. Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Acked-by: Paul Berry <stereotype441@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43327 Reported-by: xunx.fang@intel.com Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44927 Reported-by: chao.a.chen@intel.com Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
* i965: Add missing _NEW_BUFFERS dirty bit to Gen6+ DEPTH_STENCIL atoms.Kenneth Graunke2012-01-091-1/+1
| | | | | | | | | | This brings the dirty bits in line with the comments. This does /not/ need to be cherry-picked to stable branches because the access requiring _NEW_BUFFERS was added in master as part of HiZ. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Eric Anholt <eric@anholt.net>
* i965: Don't depth test the fake depthbuffer when one isn't present.Eric Anholt2011-11-291-1/+6
| | | | | | | | | | | | For the non-separate-stencil-only case, we've been using a NULL surface for depth, so we didn't have to care. However, to support separate stencil with no depthbuffer, we have to make the depth surface non-NULL or the stencil test always fails thanks to separate stencil inheriting the surface type of depth. Fixes hiz-depth-stencil-test-d0-s8. Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
* i965/gen6: Manipulate state batches for HiZ meta-ops [v4]Chad Versace2011-11-221-3/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | A lot of the state manipulation is handled by the meta-op state setup. However, some batches need manual intervention. v2: Do not special-case the 3DSTATE_DEPTH_STENCIL.Depth_Test_Enable bit for HiZ in gen6_upload_depth_stencil(). The HiZ meta-op sets ctx->Depth.Test, just read the value from that. v3: Add a new dirty flag, BRW_STATE_HIZ, for brw_tracked_state. Flag it immediately before and after executing the HiZ operation in gen6_resolve_slice(). Add the flag to the the dirty bits for the following state packets: gen6_clip_state gen6_depth_stencil_state gen6_sf_state gen6_wm_state v4: - Add BRW_NEW_STATE_HIZ to the dirty bit table in brw_state_upload.c. This is needed for INTEL_DEBUG=state. - Align brw dirty bit for gen6_depth_stencil_state. Reviewed-by: Eric Anholt <eric@anholt.net> Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
* i965/gen6: Move setup of CC state batches to emit time.Eric Anholt2011-10-291-2/+2
| | | | | | | | | | This is part of a series trying to eliminate the separate prepare() hook in state upload. The prepare() hook existed to support the check_aperture in between calculating state updates and setting up the batch, but there should be no reason for that any more. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Acked-by: Paul Berry <stereotype441@gmail.com>
* i965: Add a type argument to brw_state_batch().Eric Anholt2011-07-111-1/+2
| | | | | | | | | I want to make brw_state_dump.c handle more than just the last statechange, so I want to keep track of what's in the batch state. By using AUB file numbering for most of these packets, this may be reusable for aub dumping. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* i965/gen6: Move the depth/stencil state to state streaming.Eric Anholt2011-04-291-112/+42
| | | | Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* Drop GLcontext typedef and use struct gl_context insteadKristian Høgsberg2010-10-131-1/+1
|
* intel: Change dri_bo_* to drm_intel_bo* to consistently use new API.Eric Anholt2010-06-081-3/+3
| | | | | The slightly less mechanical change of converting the emit_reloc calls will follow.
* i965: Remove unnecessary headers.Vinson Lee2010-02-251-4/+0
|
* i965: Start adding support for the Sandybridge CC unit.Eric Anholt2010-02-251-0/+169