History log of /external/mesa3d/src/mesa/drivers/dri/i965/gen7_sf_state.c
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
dddc5df5192931f40da4f9a4a3b7b59438bc908a 02-Feb-2013 Kenneth Graunke <kenneth@whitecape.org> i965: Fix the SF Vertex URB Read Length calculation for Gen7 platforms.

Ivybridge doesn't appear to have the same errata as Sandybridge; no
corruption was observed by setting it to more than the minimal correct
value. It's possible that we were simply lucky, since the URB entries
are 1024-bit on Ivybridge vs. 512-bit Sandybridge. Or perhaps the
underlying hardware issue is fixed.

Either way, we may as well program the minimum value since it's now
readily available, likely to be more efficient, and possibly more
correct.

v2: Use GEN7_SBE_* defines rather than GEN6_SF_*. (A copy and paste
mistake.) They're the same, but using the right names is better.

Reviewed-by: Paul Berry <stereotype441@gmail.com>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
(cherry picked from commit 44aa2e15f692965be76229e67f919bf967fc7d67)
/external/mesa3d/src/mesa/drivers/dri/i965/gen7_sf_state.c
2de8874ec37bfc548de2e16bbefa51341e25d340 02-Feb-2013 Kenneth Graunke <kenneth@whitecape.org> i965: Compute the maximum SF source attribute.

The maximum SF source attribute is necessary to compute the Vertex URB
read length properly, which will be done in the next commit.

Reviewed-by: Paul Berry <stereotype441@gmail.com>
Tested-by: Martin Steigerwald <martin@lichtvoll.de>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
(cherry picked from commit 5e9bc7bd1290b0c34be90e9a0b8298ebe4b4b131)
/external/mesa3d/src/mesa/drivers/dri/i965/gen7_sf_state.c
a3d2e3e061f219edc684e46b4c27d3fbcf322c18 29-Nov-2012 Kenneth Graunke <kenneth@whitecape.org> i965: Add missing _NEW_BUFFERS dirty bit in Gen7 SBE state.

This is needed to compute render_to_fbo. It even has the comment.

NOTE: This is a candidate for stable branches.

Reviewed-by: Eric Anholt <eric@anholt.net>
(cherry picked from commit bd87441ac028068f422e2c96b39f93644a0f246f)
/external/mesa3d/src/mesa/drivers/dri/i965/gen7_sf_state.c
ba36bd0375d89e78e3c2ffb923b9ba7af0e4bfb9 08-Nov-2012 Kenneth Graunke <kenneth@whitecape.org> i965: Fix AA Line Distance Mode in 3DSTATE_SF on Ivybridge.

We were accidentally setting bit 14 in DWord 2 (which is Reserved/MBZ)
rather than bit 14 in DWord 3 (which is AA Line Distance Mode).

There's also no reason to ever set it to legacy mode; the bit is only
used when drawing antialiased lines anyway. Set it unconditionally.

NOTE: This is a candidate for stable branches.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
(cherry picked from commit e639385064663ba401544de5dbd463fa7f6cce2d)
/external/mesa3d/src/mesa/drivers/dri/i965/gen7_sf_state.c
97fc89c6cbaa3b5ef7f678d2dc2c7d5bbba05315 27-Jul-2012 Paul Berry <stereotype441@gmail.com> i965/msaa: Treat GL_SAMPLES=1 as equivalent to GL_SAMPLES=0.

EXT_framebuffer_multisample is a required subpart of
ARB_framebuffer_object, which means that we must support it even on
platforms that don't support MSAA. Fortunately
EXT_framebuffer_multisample allows for this by allowing GL_MAX_SAMPLES
to be set to 1.

This leads to a tricky quirk in the GL spec: since
GlRenderbufferStorageMultisamples() accepts any value for its
"samples" parameter up to and including GL_MAX_SAMPLES, that means
that on platforms that don't support MSAA, GL_SAMPLES is allowed to be
set to either 0 or 1. On platforms that do support MSAA, GL_SAMPLES=1
is not used; 0 means no MSAA, and 2 or higher means MSAA.

In other words, GL_SAMPLES needs to be interpreted as follows:
=0 no MSAA (possible on all platforms)
=1 no MSAA (only possible on platforms where MSAA unsupported)
>1 MSAA (only possible on platforms where MSAA supported)

This patch modifies all MSAA-related code to choose between
multisampling and single-sampling based on the condition (GL_SAMPLES >
1) instead of (GL_SAMPLES > 0) so that GL_SAMPLES=1 will be treated as
"no MSAA".

Note that since GL_SAMPLES=1 implies GL_SAMPLE_BUFFERS=1, we can no
longer use GL_SAMPLE_BUFFERS to distinguish between MSAA and non-MSAA
rendering.

Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
/external/mesa3d/src/mesa/drivers/dri/i965/gen7_sf_state.c
691c55f3560e5b8b9db9ecd2c089f13b41ec684f 10-Jul-2012 Paul Berry <stereotype441@gmail.com> i965/msaa: Control multisampling behaviour via the visual.

Previously, we used the number of samples in draw buffer 0 to
determine whether to set up the 3D pipeline for multisampling. Using
the visual is cleaner, and has the benefit of working properly when
there is no color buffer.

Fixes all piglit tests "EXT_framebuffer_multisample/no-color" on Gen7.
On Gen6, the "depth-computed" variants of these tests still fail; this
will be addresed in a later patch.

Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
/external/mesa3d/src/mesa/drivers/dri/i965/gen7_sf_state.c
cde6544ad7cbc0f4567d294e4d2ac4214199c6ec 16-Jun-2012 Paul Berry <stereotype441@gmail.com> i965/msaa: Only do multisample rasterization if GL_MULTISAMPLE enabled.

From the GL 3.0 spec (p.116):

"Multisample rasterization is enabled or disabled by calling
Enable or Disable with the symbolic constant MULTISAMPLE."

Elsewhere in the spec, where multisample rasterization is described
(sections 3.4.3, 3.5.4, and 3.6.6), the following text is consistently
used:

"If MULTISAMPLE is enabled, and the value of SAMPLE_BUFFERS is
one, then..."

So, in other words, disabling GL_MULTISAMPLE should prevent
multisample rasterization from occurring, even if the draw framebuffer
is multisampled. This patch implements that behaviour by setting the
WM and SF stage's "multisample rasterization mode" to
MSRAST_ON_PATTERN only when the draw framebuffer is multisampled *and*
GL_MULTISAMPLE is enabled.

Fixes piglit test spec/EXT_framebuffer_multisample/enable-flag.

Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
/external/mesa3d/src/mesa/drivers/dri/i965/gen7_sf_state.c
19e9b24626c2b9d7abef054d57bb2a52106c545b 30-Apr-2012 Paul Berry <stereotype441@gmail.com> i965/gen6: Initial implementation of MSAA.

This patch enables MSAA for Gen6, by modifying intel_mipmap_tree to
understand multisampled buffers, adapting the rendering pipeline setup
to enable multisampled rendering, and adding multisample resolve
operations to brw_blorp_blit.cpp. Some preparation work is also
included for Gen7, but it is not yet enabled.

MSAA support is still fairly preliminary. In particular, the
following are not yet supported:
- Fully general blits between MSAA and non-MSAA buffers.
- Formats other than RGBA8, DEPTH24, and STENCIL8.
- Centroid interpolation.
- Coverage parameters (glSampleCoverage, GL_SAMPLE_ALPHA_TO_COVERAGE,
GL_SAMPLE_ALPHA_TO_ONE, GL_SAMPLE_COVERAGE, GL_SAMPLE_COVERAGE_VALUE,
GL_SAMPLE_COVERAGE_INVERT).

Fixes piglit tests "EXT_framebuffer_multisample/accuracy" on
i965/Gen6.

v2:
- In intel_alloc_renderbuffer_storage(), quantize the requested number
of samples to the next higher sample count supported by the
hardware. This ensures that a query of GL_SAMPLES will return the
correct value. It also ensures that MSAA is fully disabled on Gen7
for now (since Gen7 MSAA support doesn't work yet).
- When reading from a non-MSAA surface, ensure that s_is_zero is true
so that we won't try to read from a nonexistent sample.
/external/mesa3d/src/mesa/drivers/dri/i965/gen7_sf_state.c
4433b0302d0aa9dc61002e8bb4fd1b752b0be338 20-Apr-2012 Brian Paul <brianp@vmware.com> intel: use _mesa_is_winsys/user_fbo() helpers

Reviewed-by: Eric Anholt <eric@anholt.net>
/external/mesa3d/src/mesa/drivers/dri/i965/gen7_sf_state.c
b4410ac3944ee30bbf5455e3e649b73f559a7d38 24-Sep-2011 Kenneth Graunke <kenneth@whitecape.org> i965: Set Line Stipple enable bit in 3DSTATE_SF for Haswell.

Apparently this needs to be the same as in 3DSTATE_WM.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
/external/mesa3d/src/mesa/drivers/dri/i965/gen7_sf_state.c
f0cecd43d6b6d3f5def3fd43b9c95baaf3be9b16 13-Feb-2012 Eric Anholt <eric@anholt.net> i965: Move VUE map computation to once at VS compile time.

With this and the previous patch, 640x480 nexuiz is running 0.169118%
+/- 0.0863696% faster (n=121). On a VS state change microbenchmark,
performance is increased 8.28645% +/- 0.460478% (n=52).

v2: Fix CACHE_NEW_VS comment.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
/external/mesa3d/src/mesa/drivers/dri/i965/gen7_sf_state.c
9f3d3216cf25d8ffed4d72fbce6feacbc2990e4b 13-Feb-2012 Eric Anholt <eric@anholt.net> i965: Make the userclip flag for the VUE map come from VS prog data.

This reduces recomputation of state based on non-clipping-related
transform changes, and is a step toward removing VUE map
recomputation.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
/external/mesa3d/src/mesa/drivers/dri/i965/gen7_sf_state.c
7b36c68ba6899c7f30fd56b7ef07a78b027771ac 26-Jan-2012 Chad Versace <chad.versace@linux.intel.com> i965: Rewrite the HiZ op

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>
/external/mesa3d/src/mesa/drivers/dri/i965/gen7_sf_state.c
eaf360e5bffc5630789367020252cd12fe586177 20-Jan-2012 Yuanhan Liu <yuanhan.liu@linux.intel.com> i965: fix inverted point sprite origin when rendering to FBO

When rendering to FBO, rendering is inverted. At the same time, we would
also make sure the point sprite origin is inverted. Or, we will get an
inverted result correspoinding to rendering to the default winsys FBO.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44613

NOTE: This is a candidate for stable release branches.

v2: add the simliar logic to ivb, too (comments from Ian)
simplify the logic operation (comments from Brian)

v3: pick a better comment from Eric
use != for the logic instead of ^ (comments from Ian)

Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
/external/mesa3d/src/mesa/drivers/dri/i965/gen7_sf_state.c
06ad9adcb031b97af2ce9cd22b919b8befcec43b 22-Dec-2011 Chad Versace <chad.versace@linux.intel.com> i965/gen7: Enable HiZ

This patch modifies all batches needed for HiZ. The batch length for
3DSTATE_HIER_DEPTH_BUFFER is also corrected from 4 to 3.

Performance +6.7% on Citybench.
num-frames: 400
resolution: 1918x1031
avg-hiz-off: 127.90 fps
avg-hiz-on: 136.50 fps
kernel: git://people.freedesktop.org/~anholt/linux.git branch=gen7-reset-sol sha=23360e4

Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
/external/mesa3d/src/mesa/drivers/dri/i965/gen7_sf_state.c
a48cc138a8b7c55f8d12796677e081c2b2085f48 09-Jan-2012 Kenneth Graunke <kenneth@whitecape.org> i965: Fix zeroing of unused attributes in 3DSTATE_SBE.

This brings the code in sync with gen6_sf_state.c; presumably the
mistake was a botched rebase on initial Ivybridge bring-up patches.

Found by diffing batch buffer dumps and noticing the random values.
Thanks to Eric for catching the obvious mistake.

NOTE: This is a candidate for the 7.11 branch.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
/external/mesa3d/src/mesa/drivers/dri/i965/gen7_sf_state.c
ef034f109427f1a8d31dbe10beed825881130f6b 09-Jan-2012 Kenneth Graunke <kenneth@whitecape.org> i965: Annotate the use of _NEW_PROGRAM in Gen6+ SF state atoms.

The dirty bit was already correctly in place, but there was no comment.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
/external/mesa3d/src/mesa/drivers/dri/i965/gen7_sf_state.c
60343b67f7741bba8ca086f4b5431e68e58c75a2 09-Jan-2012 Kenneth Graunke <kenneth@whitecape.org> i965: Add missing _NEW_PROGRAM dirty bit to the gen7_sbe_state atom.

According to a comment in gen6_sf_state, calls to get_attr_override need
both _NEW_PROGRAM and _NEW_LIGHT. Since Gen7 reuses the same function,
the same dirty bits should apply.

NOTE: This is a candidate for the 7.11 branch.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
/external/mesa3d/src/mesa/drivers/dri/i965/gen7_sf_state.c
d84a180417d1eabd680554970f1eaaa93abcd41e 17-Nov-2011 Eric Anholt <eric@anholt.net> i965: Base HW depth format setup based on MESA_FORMAT, not bpp.

This will make handling new formats (like actually exposing Z32F)
easier and more reliable.

v2: Remove the check for hiz buffer -- the MESA_FORMAT should really
be giving us the value we want even for hiz.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
/external/mesa3d/src/mesa/drivers/dri/i965/gen7_sf_state.c
5aa96286e7e1a5380673eb75e8653616b48751fd 22-Oct-2011 Paul Berry <stereotype441@gmail.com> i965/gen6+: Add support for noperspective interpolation.

This required the following changes:

- WM setup now makes the appropriate set of barycentric coordinates
(perspective vs. noperspective) available to the fragment shader,
based on whether the shader requires perspective interpolation,
noperspective interpolation, both, or neither.

- The fragment shader backend now uses the appropriate set of
barycentric coordiantes when interpolating, based on the
interpolation mode returned by
ir_variable::determine_interpolation_mode().

- SF setup now uses gl_fragment_program::InterpQualifier to determine
which attributes are to be flat shaded (as opposed to the old logic,
which only flat shaded colors).

- CLIP setup now ensures that the clipper outputs non-perspective
barycentric coordinates when they are needed by the fragment shader.

Fixes the remaining piglit tests of interpolation qualifiers that were
failing:
- interpolation-flat-*-smooth-none
- interpolation-flat-other-flat-none
- interpolation-noperspective-*
- interpolation-smooth-gl_*Color-flat-*

Reviewed-by: Eric Anholt <eric@anholt.net>
/external/mesa3d/src/mesa/drivers/dri/i965/gen7_sf_state.c
18e2e19b07b312c978dfbb6d336f69fa84b3ffe2 27-Sep-2011 Paul Berry <stereotype441@gmail.com> i965: Make brw_compute_vue_map's userclip dependency a boolean.

Previously, brw_compute_vue_map required an argument indicating the
number of clip planes in use, but all it did with it was check if it
was nonzero.

This patch changes brw_compute_vue_map to take a boolean instead.
This allows us to avoid some unnecessary recompilation of the Gen4/5
GS and SF threads.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
/external/mesa3d/src/mesa/drivers/dri/i965/gen7_sf_state.c
c163072197b56e76b656cc472bbe6df650cf11ba 28-Sep-2011 Paul Berry <stereotype441@gmail.com> mesa: Create _mesa_bitcount_64() to replace i965's brw_count_bits()

The i965 driver already had a function to count bits in a 64-bit uint
(brw_count_bits()), but it was buggy (it only counted the bottom 32
bits) and it was clumsy (it had a strange and broken fallback for
non-GCC-like compilers, which fortunately was never used). Since Mesa
already has a _mesa_bitcount() function, it seems better to just
create a _mesa_bitcount_64() function rather than special-case this in
the i965 driver.

This patch creates the new _mesa_bitcount_64() function and rewrites
all of the old brw_count_bits() calls to refer to it.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
/external/mesa3d/src/mesa/drivers/dri/i965/gen7_sf_state.c
2a6d43204024bc47df9bf5f7803d62d4d9580ab5 04-Sep-2011 Paul Berry <stereotype441@gmail.com> i965: Allow clip distances to be read back in fragment shaders.

Previously, we conditionally set up the SF pipline stage with a
urb_entry_read_offset of 2 when clipping was in use, and 1 otherwise,
causing the clip distance VUE slots to be skipped if present. This
was an extremely minor savings (it saved the SF unit from reading 2
vec4s out of the URB, but it didn't affect any computation, since we
only instruct the SF unit to perform interpolation on VUE slots that
are actually used by the fragment shader).

GLSL 1.30 requires an interpolated version of gl_ClipDistance to be
available for reading in the fragment shader, so we need the SF's
urb_entry_read_offset to be 1 when the fragment shader reads from
gl_ClipDistance.

This patch just unconditionally sets the urb_entry_read_offset to 1 in
all cases; this is sufficient to make gl_ClipDistance available to the
fragment shader when it is needed, and the performance loss should be
negligible when it isn't.

Reviewed-by: Eric Anholt <eric@anholt.net>
/external/mesa3d/src/mesa/drivers/dri/i965/gen7_sf_state.c
cd6b8421cac2df89dc6365ce368232e461caffcd 06-Sep-2011 Yuanhan Liu <yuanhan.liu@linux.intel.com> i965: fix the constant interp bitmask for flat mode

Fix the constant interpolation enable bit mask for flat light mode.
FRAG_BIT_COL0 attribute bit might be 0, in which case we need to
shift one more bit right.

This would fix the oglc specularColor test fail on both Sandybridge and
Ivybridge.

v2: move the constant interp bitmask setup code into for(; attr <
FRAG_ATTRIB_MAX; attr++) loop suggested by Eric.

Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com>
/external/mesa3d/src/mesa/drivers/dri/i965/gen7_sf_state.c
447c488d77ea9710e0ffc238953917189d3000c7 09-Sep-2011 Eric Anholt <eric@anholt.net> i965/gen6+: Respect the VERTEX_PROGRAM_TWO_SIDE flag for shaders.

Fixes piglit:
vertex-program-two-side enabled front back front2 back2
vertex-program-two-side enabled front back
vertex-program-two-side enabled front2 back2
/external/mesa3d/src/mesa/drivers/dri/i965/gen7_sf_state.c
becd54eedb26ec9076e6f5f98f485861b3e13a90 03-Sep-2011 Paul Berry <stereotype441@gmail.com> i965: Remove two_side_color from brw_compute_vue_map().

Since we now lay out the VUE the same way regardless of whether
two-sided color is enabled, brw_compute_vue_map() no longer needs to
know whether two-sided color is enabled. This allows the two-sided
color flag to be removed from the clip, GS, and VS keys, so that fewer
GPU programs need to be recompiled when turning two-sided color on and
off.

Reviewed-by: Eric Anholt <eric@anholt.net>
/external/mesa3d/src/mesa/drivers/dri/i965/gen7_sf_state.c
9660e3b788227de4aa15c42c5bbd48b85ad46d24 31-Aug-2011 Paul Berry <stereotype441@gmail.com> i965: SF: Change gen{6,7}_sf_state.c to compute URB read length based on VUE map.

Reviewed-by: Eric Anholt <eric@anholt.net>
/external/mesa3d/src/mesa/drivers/dri/i965/gen7_sf_state.c
fc60a07d88e57bc51b153888181d11d3a0ca7d7f 31-Aug-2011 Paul Berry <stereotype441@gmail.com> i965: SF: Move outputs_written to a local variable for clarity.

Reviewed-by: Eric Anholt <eric@anholt.net>
/external/mesa3d/src/mesa/drivers/dri/i965/gen7_sf_state.c
2d909f431c67d0c8c5075dc40f2901076c5bc48b 30-Aug-2011 Paul Berry <stereotype441@gmail.com> i965: SF: New implementation of get_attr_override using the VUE map.

This patch changes get_attr_override() (which computes the
relationship between vertex shader outputs and fragment shader inputs)
to use the VUE map.

Reviewed-by: Eric Anholt <eric@anholt.net>
/external/mesa3d/src/mesa/drivers/dri/i965/gen7_sf_state.c
186e37c75454965e1a58298e878a9585f4866749 30-Jun-2011 Kenneth Graunke <kenneth@whitecape.org> i965/gen7: Add support for gl_PointCoord.

This is exactly analogous to Eric's Gen6 change in commit
6861a701772eac3a6a7d3136d03efa7ac7e5c026. His explanation:

"This is just like PointSprite overrides, but it's always on for that
attribute."

Fixes glsl-fs-pointcoord and gtf/point_sprites.

Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>

NOTE: This is a candidate for the 7.11 branch.
/external/mesa3d/src/mesa/drivers/dri/i965/gen7_sf_state.c
147d0102952b7c0b16906c08da2ae447ec68185a 30-Jun-2011 Kenneth Graunke <kenneth@whitecape.org> i965/gen7: Fix point sprite texture coordinate overrides.

This is exactly analogous to Eric's Gen6 change in commit
f304bb8a5d040d99db47a65813d216d11c66fb47. His explanation:

"We were assuming that the input attribute n to the FS was
FRAG_ATTRIB_TEXn, which happened to be true often enough for our
testcases."

Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>

NOTE: This is a candidate for the 7.11 branch.
/external/mesa3d/src/mesa/drivers/dri/i965/gen7_sf_state.c
5edb3ddf4191b31b4a4e43a85fe1bfbd62a8cb17 30-Jun-2011 Kenneth Graunke <kenneth@whitecape.org> i965/gen7: Refactor SF setup a bit to handle overrides in one place.

This is exactly analogous to Eric's Gen6 change in commit
e7280b16d634e1f434bebbce83996b3d30d0419c.

Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>

NOTE: This is a candidate for the 7.11 branch.
/external/mesa3d/src/mesa/drivers/dri/i965/gen7_sf_state.c
a98dd64af750fb6dae54b2dc02e0c5a3711156af 13-May-2011 Eric Anholt <eric@anholt.net> i965: Stop caching the combined depth/stencil region in brw_context.c.

This was going to get in the way of separate depth/stencil (which
wants to know about both, and whether they are the same rb), and also
wasn't a sufficient flag for the fix in the following commit.
/external/mesa3d/src/mesa/drivers/dri/i965/gen7_sf_state.c
8c8985bdd714f43a96ce922a7c0284d50aec3d1a 09-Apr-2011 Kenneth Graunke <kenneth@whitecape.org> i965: Add depth buffer support on Ivybridge.

This also disables the HiZ and separate stencil buffers. We still need
to implement stencil.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
/external/mesa3d/src/mesa/drivers/dri/i965/gen7_sf_state.c
7d608d0c331c101088273655708965fb9f1be56e 05-Jan-2011 Kenneth Graunke <kenneth@whitecape.org> i965: Initial Ivybridge SF/SBE state setup.

Copied from gen6_sf_state.c.

The main change from Sandybridge seems to be that 3DSTATE_SF was split
into two separate state packet commands: 3DSTATE_SF and 3DSTATE_SBE
("setup backend"). The bit-offsets are even the same - only the DWords
numbers have shuffled around a bit.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
/external/mesa3d/src/mesa/drivers/dri/i965/gen7_sf_state.c