| 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_wm_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_wm_state.c
|
| 6c355cca9149e43850cf27f2d0821fab1e7a69f5 |
|
26-Jun-2012 |
Paul Berry <stereotype441@gmail.com> |
i965/msaa: Set KILL_ENABLE when GL_ALPHA_TO_COVERAGE enabled.
i965 hardware needs to be informed of situations in which it's
possible for pixels (or samples) to be discarded for reasons other
than depth/stencil testing (e.g. due to an explicit "discard" in the
fragment shader). One of these situations is when
GL_ALPHA_TO_COVERAGE is enabled, since that can cause samples to be
discarded by the color calculator when the pixel's alpha value is less
than 1.0.
Without this patch, GL_ALPHA_TO_COVERAGE does not take effect on depth
buffers.
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
/external/mesa3d/src/mesa/drivers/dri/i965/gen7_wm_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_wm_state.c
|
| 29362875f2613ad87abe7725ce3c56c36d16cf9b |
|
25-Apr-2012 |
Eric Anholt <eric@anholt.net> |
i965/gen6+: Add support for GL_ARB_blend_func_extended.
v2: Add support for gen6, and don't turn it on if blending is
disabled. (fixes GPU hang), and note it in docs/GL3.txt
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
/external/mesa3d/src/mesa/drivers/dri/i965/gen7_wm_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_wm_state.c
|
| a23dcc18e71e905da117d14b5d56c4e49c66ab79 |
|
20-Oct-2011 |
Kenneth Graunke <kenneth@whitecape.org> |
i965: Fill in Sample Mask in Haswell's 3DSTATE_PS.
We only need one sample, since we don't support multisampling yet.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
/external/mesa3d/src/mesa/drivers/dri/i965/gen7_wm_state.c
|
| 1b3a199097190a0bf857eb17c12949fa2b456d9b |
|
23-Sep-2011 |
Kenneth Graunke <kenneth@whitecape.org> |
i965: Update max VS/PS threads shift offsets for Haswell.
These now start at bit 23 instead of bit 24/25.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
/external/mesa3d/src/mesa/drivers/dri/i965/gen7_wm_state.c
|
| 5a7942c2f1e3af4daedd92c1ddf21fa6a0e4e752 |
|
15-Feb-2012 |
Eric Anholt <eric@anholt.net> |
i965: Rename the original binding table to mention that it's the WM now.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
/external/mesa3d/src/mesa/drivers/dri/i965/gen7_wm_state.c
|
| 71d71d5e891570e8516c65471939a2ebdc07282a |
|
15-Feb-2012 |
Eric Anholt <eric@anholt.net> |
i965: Compute required barycentric interp modes once at FS compile time.
Improves VS state change microbenchmark performance 1.78817% +/-
0.556878% (n=25).
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
/external/mesa3d/src/mesa/drivers/dri/i965/gen7_wm_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_wm_state.c
|
| b527dd65c830a2b008816cf390d5be906e29bb23 |
|
15-Nov-2011 |
Ian Romanick <ian.d.romanick@intel.com> |
mesa: Track fixed-function fragment shader as a shader
Previously the fixed-function fragment shader was tracked as a
gl_program. This means that it shows up in the driver as a Mesa IR
program instead of as a GLSL IR program. If a driver doesn't generate
Mesa IR from the GLSL IR, that program is empty. If the program is
empty there is either no rendering or a GPU hang.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
/external/mesa3d/src/mesa/drivers/dri/i965/gen7_wm_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_wm_state.c
|
| 7cb40da7a55e8f81f4e2138845087eb1e0310bc1 |
|
08-Jan-2012 |
Kenneth Graunke <kenneth@whitecape.org> |
i965: Re-sync outdated comments about Gen6+ push constants.
In f3e9ccb3b, I renamed gen6_upload_wm_constants to
gen6_upload_wm_push_constants, but neglected to update this comment.
I don't think there ever was a gen7_prepare_wm_constants function; it
was probably a search and replace error. Of course, "prepare" functions
died a while back as well.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
/external/mesa3d/src/mesa/drivers/dri/i965/gen7_wm_state.c
|
| 647b890e7d2fe628812017fd10a6a68fa9e4da8b |
|
08-Jan-2012 |
Kenneth Graunke <kenneth@whitecape.org> |
i965: Update dirty bit comments for the gen7_ps_state atom.
CACHE_NEW_SAMPLER doesn't cover max_wm_threads, but it does cover
brw->sampler.count. BRW_NEW_PS_BINDING_TABLE is obvious, but it's
probably worth adding a comment anyway.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
/external/mesa3d/src/mesa/drivers/dri/i965/gen7_wm_state.c
|
| f497906ec0c01ec714d77bfcc2f0a38da5dafcc2 |
|
08-Jan-2012 |
Kenneth Graunke <kenneth@whitecape.org> |
i965: Remove BRW_NEW_CURBE_OFFSETS dirty bit from Gen7 atoms.
The BRW_NEW_CURBE_OFFSETS dirty bit is only flagged by the
brw_curbe_offsets state atom which is only used on Gen4-5.
Since it's never flagged, there's no reason to depend on it.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
/external/mesa3d/src/mesa/drivers/dri/i965/gen7_wm_state.c
|
| 74d7ef0961b3aace03aea88944155272ac341b59 |
|
08-Jan-2012 |
Kenneth Graunke <kenneth@whitecape.org> |
i965: Remove BRW_NEW_URB_FENCE dirty bit from Gen6+ atoms.
The BRW_NEW_URB_FENCE dirty bit is only flagged by the
brw_recalculate_urb_fence state atom which isn't used on Gen6+.
Since it's never flagged, there's no reason to depend on it.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
/external/mesa3d/src/mesa/drivers/dri/i965/gen7_wm_state.c
|
| 37240d2132d25588ad05ae5394c237f45d8ad881 |
|
08-Jan-2012 |
Kenneth Graunke <kenneth@whitecape.org> |
i965: Actually enable SIMD16 dispatch on Ivybridge.
Commit acf82657f4d607e4477f03752613d42f239e4bd3 supposedly enabled
SIMD16 dispatch, but neglected to set the "16 Pixel Dispatch Enable"
bit, so nothing actually got enabled.
Furthermore, it neglected to set up the Dispatch GRF Start Register for
kernel 2, which is the SIMD16 program.
Increases performance in Nexuiz by ~15% at 800x600 (n=3).
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_wm_state.c
|
| dca6a28a14f22d77273d79d44f57b0d853c0242d |
|
31-Oct-2011 |
Mathias Fröhlich <Mathias.Froehlich@web.de> |
mesa: Make gl_program::InputsRead 64 bits.
Make gl_program::InputsRead a 64 bits bitfield.
Adapt the intel and radeon driver to handle a 64 bits
InputsRead value.
Signed-off-by: Mathias Froehlich <Mathias.Froehlich@web.de>
Reviewed-by: Eric Anholt <eric@anholt.net>
/external/mesa3d/src/mesa/drivers/dri/i965/gen7_wm_state.c
|
| 32dfa6e5ef3d1fb703ec34942c55408be22e7ec3 |
|
28-Oct-2011 |
Kenneth Graunke <kenneth@whitecape.org> |
i965: Move and rename "wm sampler" fields to just "sampler".
brw_wm_samplers actually enables any active samplers regardless of what
pipeline stage is using them, so it doesn't make much sense for it to be
WM-specific. So, rename it to "brw_samplers."
To properly generalize it, move sampler_count and sampler_offset from
brw_context::wm to a new brw_context::sampler that can be shared without
looking strange.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
/external/mesa3d/src/mesa/drivers/dri/i965/gen7_wm_state.c
|
| e7c29c5de82f6de3d30ed1143d9672dd2e25f0e7 |
|
31-Oct-2011 |
Kenneth Graunke <kenneth@whitecape.org> |
i965: Use a single binding table for all pipeline stages.
Although the hardware supports separate binding tables for each pipeline
stage, we don't see much advantage over a single shared table.
Consider the contents of the binding table:
- Textures (16)
- Draw buffers (8)
- Pull constant buffers (1 for VS, 1 for WM)
OpenGL's texture bindings are global: the same set of textures is
available to all shader targets. So our binding table entries for
textures would be exactly the same in every table.
There are only two pull constant buffers (not many), and although draw
buffers aren't interesting to the VS, it shouldn't hurt to have them in
the table. The hardware supports up to 254 binding table entries, and
we currently only use 26.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
/external/mesa3d/src/mesa/drivers/dri/i965/gen7_wm_state.c
|
| 6ba9090ea05e817bd38c1fcc63c53168b16593c7 |
|
01-Nov-2011 |
Kenneth Graunke <kenneth@whitecape.org> |
i965: Use 0 for the number of binding table entries in 3DSTATE_(VS|WM).
These fields control how many entries the hardware prefetches into the
state cache, so they only impact performance, not correctness. However,
it's not clear how to use this in a way that's beneficial.
According to the documentation, kernels "using a large number" of
entries may wish to program this to zero to avoid thrashing the cache;
it's unclear how many is too many. Also, Ironlake's WM was missing this
feature entirely---the count had to be zero.
The dirty bit tracking to handle this complicates the surface state
and binding table setup; removing it should simplify things and make
future refactoring easier. So just set 0 for the number of entries
rather than trying to compute and track it.
Appears to have no impact on Nexuiz and OpenArena on Sandybridge.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
/external/mesa3d/src/mesa/drivers/dri/i965/gen7_wm_state.c
|
| f40c6b2a992f3ca796826a47743c0c80232d7ab2 |
|
08-Oct-2011 |
Paul Berry <stereotype441@gmail.com> |
i965/gen6+: Switch GLSL from ALT to IEEE floating point mode
i965 graphics hardware has two floating point modes: ALT and IEEE. In
ALT mode, floating-point operations never generate infinities or NaNs,
and MOV instructions translate infinities and NaNs to finite values.
In IEEE mode, infinities and NaNs behave as specified in the IEEE 754
spec.
Previously, we used ALT mode for all vertex and fragment programs,
whether they were GLSL programs or ARB programs. The GLSL spec is
sufficiently vague about how infs and nans are to be handled that it
was unclear whether this mode was compliant with the GLSL 1.30 spec or
not, and it made it very difficult to test the isinf() and isnan()
functions.
This patch changes i965 GLSL programs to use IEEE floating-point mode,
which is clearly compliant with GLSL 1.30's inf/nan requirements. In
addition to making the Piglit isinf and isnan tests pass, this paves
the way for future support of the ARB_shader_precision extension.
Unfortunately we still have to use ALT floating-point mode when
executing ARB programs, because those programs require 0^0 == 1, and
i965 hardware generates 0^0 == NaN in IEEE mode.
Fixes piglit tests "isinf-and-isnan fs_fbo", "isinf-and-isnan vs_fbo",
and {fs,vs}-{isinf,isnan}-{vec2,vec3,vec4}.
/external/mesa3d/src/mesa/drivers/dri/i965/gen7_wm_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_wm_state.c
|
| e04bdeae82797dbdcf6f544a997a4626fdfd4aee |
|
22-Oct-2011 |
Paul Berry <stereotype441@gmail.com> |
i965/gen6+: Parameterize barycentric interpolation modes.
This patch modifies the fragment shader back-end so that instead of
using a single delta_x/delta_y register pair to store barycentric
coordinates, it uses an array of such register pairs, one for each
possible intepolation mode.
When setting up the WM, we intstruct it to only provide the
barycentric coordinates that are actually needed by the fragment
shader--that is computed by brw_compute_barycentric_interp_modes().
Currently this function returns just
BRW_WM_PERSPECTIVE_PIXEL_BARYCENTRIC, because this is the only
interpolation mode we support. However, that will change in a later
patch.
Reviewed-by: Eric Anholt <eric@anholt.net>
/external/mesa3d/src/mesa/drivers/dri/i965/gen7_wm_state.c
|
| db6dd6d88fdc4361193dd063e4f150f01a104faa |
|
24-Oct-2011 |
Kenneth Graunke <kenneth@whitecape.org> |
i965: Rename (vs|wm)_max_threads to max_(vs|wm)_threads for consistency.
The inconsistency between vs_max_threads and max_vs_entries was rather
annoying. I could never seem to remember which one was reversed, which
made it harder to find quickly. "Max __ Threads" seems more natural.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
/external/mesa3d/src/mesa/drivers/dri/i965/gen7_wm_state.c
|
| 6e160d01f2c6667cba89e5fa806f9e4b01ca8ced |
|
19-Oct-2011 |
Kenneth Graunke <kenneth@whitecape.org> |
i965: Remove copy and pasted gen7_wm_constants state atom.
Now that this is identical to gen6_wm_constants, just use that instead.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
/external/mesa3d/src/mesa/drivers/dri/i965/gen7_wm_state.c
|
| b293b3cbb19bc4db8d9801c2f1160f98299481d0 |
|
19-Oct-2011 |
Kenneth Graunke <kenneth@whitecape.org> |
i965: Use AUB_TRACE_WM_CONSTANTS in gen7_prepare_wm_push_constants.
This makes it match gen6_prepare_wm_push_constants. For some reason, it
had been using AUB_TRACE_NO_TYPE.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
/external/mesa3d/src/mesa/drivers/dri/i965/gen7_wm_state.c
|
| 314c2574ff6e562a6cfc5fb84980f092e495a948 |
|
07-Aug-2011 |
Eric Anholt <eric@anholt.net> |
i965: Add remaining scratch space setup emit to unit states.
/external/mesa3d/src/mesa/drivers/dri/i965/gen7_wm_state.c
|
| a070d5f363e99b0f846d555e9ca3a74ec807fdc0 |
|
04-May-2011 |
Eric Anholt <eric@anholt.net> |
i965/vs: Start adding support for uniforms
There's no clever packing here, no pull constants, and no array support.
/external/mesa3d/src/mesa/drivers/dri/i965/gen7_wm_state.c
|
| d375df220fae47f38944c4832bcbd5f5d568884c |
|
23-Jun-2011 |
Eric Anholt <eric@anholt.net> |
i965: Add a type argument to brw_state_batch().
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>
/external/mesa3d/src/mesa/drivers/dri/i965/gen7_wm_state.c
|
| 57b57f6d1c3689a3a44222cb169bfd3e3142a68d |
|
09-Jul-2011 |
Kenneth Graunke <kenneth@whitecape.org> |
i965/gen7: Remove gratuitous dirty flags from WM and PS state.
Commit b46dc45ceef3deb17ba2b0b4300eeb93e9cf7833 claimed that
NEW_POLYGONSTIPPLE is gratuitous, but somehow just changed comments
and whitespace instead of actually removing the flag.
While we're at it, 3DSTATE_PS doesn't appear to need NEW_LINE or
NEW_POLYGON either (those are in 3DSTATE_WM). Also, 3DSTATE_WM
doesn't appear to need BRW_NEW_NR_WM_SURFACES or BRW_NEW_CURBE_OFFSETS
either (those are in 3DSTATE_PS).
NOTE: This is a candidate for the 7.11 branch.
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
/external/mesa3d/src/mesa/drivers/dri/i965/gen7_wm_state.c
|
| b46dc45ceef3deb17ba2b0b4300eeb93e9cf7833 |
|
16-Jun-2011 |
Eric Anholt <eric@anholt.net> |
i965/gen6+: Correct gratuitous dependency on NEW_POLYGONSTIPPLE.
That flag is for the contents of the stipple, not the enable flag.
/external/mesa3d/src/mesa/drivers/dri/i965/gen7_wm_state.c
|
| 416a698b3c727c6db9902ac20053da73bb4b59c2 |
|
16-Jun-2011 |
Eric Anholt <eric@anholt.net> |
i965/gen6+: Add a missing state flag for WM constants.
/external/mesa3d/src/mesa/drivers/dri/i965/gen7_wm_state.c
|
| c173541d9769d41a85cc899bc49699a3587df4bf |
|
27-Apr-2011 |
Eric Anholt <eric@anholt.net> |
i965: Use state streaming on programs, and state base address on gen5+.
There will be a little bit of thrashing of the program cache BO as the
cache warms up, but once the application is in steady state, this
reduces relocations on gen5 and later.
On my T420 laptop, cairogl firefox-talos-gfx performance improves 2.6%
+/- 1.3% (n=6). No statistically significant performance difference
on nexuiz (n=5).
/external/mesa3d/src/mesa/drivers/dri/i965/gen7_wm_state.c
|
| acf82657f4d607e4477f03752613d42f239e4bd3 |
|
06-Jun-2011 |
Kenneth Graunke <kenneth@whitecape.org> |
i965/gen7: Enable SIMD16 fragment shader dispatch.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
/external/mesa3d/src/mesa/drivers/dri/i965/gen7_wm_state.c
|
| bc08d4ebb832769aacb4aecaaf1e490f97c53d65 |
|
09-Feb-2011 |
Kenneth Graunke <kenneth@whitecape.org> |
i965: Upload sampler state pointers on Ivybridge.
Since we currently only support sampling in the fragment shader, we only
bother to emit the PS variant. In the future we'll need to emit others.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
/external/mesa3d/src/mesa/drivers/dri/i965/gen7_wm_state.c
|
| 706dbf85f15d42c320481dabe2a3db0c2cbbebb8 |
|
22-Feb-2011 |
Kenneth Graunke <kenneth@whitecape.org> |
i965: Upload binding table pointers on Ivybridge.
Ivybridge uses per-stage commands to update binding table pointers.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
/external/mesa3d/src/mesa/drivers/dri/i965/gen7_wm_state.c
|
| a924d69b57a82c02f2d4fba3fc0b31bf6a4f744e |
|
03-Feb-2011 |
Kenneth Graunke <kenneth@whitecape.org> |
i965: Initial Ivybridge WM/PS state setup.
Copied from gen6_wm_state.c.
The main change from Sandybridge seems to be that 3DSTATE_WM was split
into two separate state packet commands: 3DSTATE_WM and 3DSTATE_PS.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
/external/mesa3d/src/mesa/drivers/dri/i965/gen7_wm_state.c
|