| 61d0b9f52c6be4a4a64c30ea3a2a93ef8260c67b |
|
26-Jul-2012 |
Kenneth Graunke <kenneth@whitecape.org> |
intel: Make the length for PIPE_CONTROL explicit.
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 <daniel.vetter@ffwll.ch>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Eric Anholt <eric@anholt.net>
/external/mesa3d/src/mesa/drivers/dri/i965/gen6_vs_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/gen6_vs_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/gen6_vs_state.c
|
| 51b1d412ec5d0699d182b895daacb3b78da328ad |
|
28-Oct-2011 |
Kenneth Graunke <kenneth@whitecape.org> |
i965: Put a proper sampler count in 3DSTATE_VS.
See similar code for 3DSTATE_WM.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
/external/mesa3d/src/mesa/drivers/dri/i965/gen6_vs_state.c
|
| f3e9ccb3bcd174a0b55cae6f9c56835145558e89 |
|
04-Nov-2011 |
Kenneth Graunke <kenneth@whitecape.org> |
i965: Rename gen6_*_constants tracked state atoms to "push_constants".
When reading the "brw_wm_constants" and "gen6_wm_constants" atoms
side-by-side, I initially failed to notice the crucial difference:
the Gen6 atoms are for Push Constants, while brw_wm_constants handles
Pull Constants. (Gen4/5 Push Constants are handled by "brw_curbe.")
Renaming these should clarify the code and save me from constant
confusion over the fact that "gen6_wm_constants" isn't just a newer
version of "brw_wm_constants."
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/gen6_vs_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/gen6_vs_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/gen6_vs_state.c
|
| 9015969e6e9ce38d183e77a633f1d55117e07b26 |
|
22-Oct-2011 |
Eric Anholt <eric@anholt.net> |
i965: Move push constants setup to emit() time.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Acked-by: Paul Berry <stereotype441@gmail.com>
/external/mesa3d/src/mesa/drivers/dri/i965/gen6_vs_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/gen6_vs_state.c
|
| 3cc0a7be23ab603ed40d602595f673a44e079885 |
|
21-Oct-2011 |
Kenneth Graunke <kenneth@whitecape.org> |
i965: Apply post-sync non-zero workaround to homebrew workaround.
In commit 3e5d3626, Eric added a homebrew workaround to fix GPU hangs in
the Mesa "engine" demo and oglc's api-texcoord test.
Unfortunately, his PIPE_CONTROL contains a Depth Stall, which
necessitates the post-sync non-zero workaround,
Fixes GPU hangs in Civilization 4, PlaneShift, and 3DMMES.
Hopefully Heroes of Newerth as well, though I haven't tested that.
NOTE: This is candidate for the 7.11 branch.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=40324
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41096
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-and-tested-by: Eric Anholt <eric@anholt.net>
/external/mesa3d/src/mesa/drivers/dri/i965/gen6_vs_state.c
|
| 7a4fee71aa74f0e73cf6141c08ba1d536f20cd17 |
|
10-Oct-2011 |
Paul Berry <stereotype441@gmail.com> |
i965 Gen6+: De-compact clip plane constants for old VS backend.
In commit 018ea68d8780ab5baeef0b8122b8410e5e55ae6d, when I
de-compacted clip planes on Gen6+, I updated both the old and new VS
back-ends to reflect the change in how clip planes are stored, but I
failed to change the code in gen6_vs_state.c that uploads clip plane
constants when using the old VS back-end.
As a result, if the set of enabled clip planes wasn't contiguous
starting with 0, then clipping would not occur properly. This patch
corrects gen6_vs_state.c to upload clip plane constants in the new
de-compacted form.
This only affects the old VS back-end (which is used for
fixed-function and ARB vertex programs, not for GLSL vertex shaders).
Fixes Piglit test fixed-clip-enables.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41603
Reviewed-by: Eric Anholt <eric@anholt.net>
/external/mesa3d/src/mesa/drivers/dri/i965/gen6_vs_state.c
|
| d912669034eb7bf5c162358a7a574ec7a4c963c7 |
|
26-Sep-2011 |
Paul Berry <stereotype441@gmail.com> |
i965 Gen6: Implement gl_ClipVertex.
This patch implements proper support for gl_ClipVertex by causing the
new VS backend to populate the clip distance VUE slots using
VERT_RESULT_CLIP_VERTEX when appropriate, and by using the
untransformed clip planes in ctx->Transform.EyeUserPlane rather than
the transformed clip planes in ctx->Transform._ClipUserPlane when a
GLSL-based vertex shader is in use.
When not using a GLSL-based vertex shader, we use
ctx->Transform._ClipUserPlane (which is what we used prior to this
patch). This ensures that clipping is still performed correctly for
fixed function and ARB vertex programs. A new function,
brw_select_clip_planes() is used to determine whether to use
_ClipUserPlane or EyeUserPlane, so that the logic for making this
decision is shared between the new and old vertex shaders.
Fixes the following Piglit tests on i965 Gen6:
- vs-clip-vertex-const-accept
- vs-clip-vertex-const-reject
- vs-clip-vertex-different-from-position
- vs-clip-vertex-equal-to-position
- vs-clip-vertex-homogeneity
- vs-clip-based-on-position
- vs-clip-based-on-position-homogeneity
- clip-plane-transformation clipvert_pos
- clip-plane-transformation pos_clipvert
- clip-plane-transformation pos
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chad Versace <chad@chad-versace.us>
/external/mesa3d/src/mesa/drivers/dri/i965/gen6_vs_state.c
|
| e7da40afe84349a640fe15e3af408a0dfe880e85 |
|
24-Sep-2011 |
Paul Berry <stereotype441@gmail.com> |
i965 new VS: don't share clip plane constants in pre-GEN6
In pre-GEN6, when using clip planes, both the vertex shader and the
clipper need access to the client-supplied clip planes, since the
vertex shader needs them to set the clip flags, and the clipper needs
them to determine where to insert new vertices.
With the old VS backend, we used a clever optimization to avoid
placing duplicate copies of these planes in the CURBE: we used the
same block of memory for both the clipper and vertex shader constants,
with the clip planes at the front of it, and then we instructed the
clipper to read just the initial part of this block containing the
clip planes.
This optimization was tricky, of dubious value, and not completely
working in the new VS backend, so I've removed it. Now, when using
the new VS backend, separate parts of the CURBE are used for the
clipper and the vertex shader. Note that this doesn't affect the
number of push constants available to the vertex shader, it simply
causes the CURBE to occupy a few more bytes of URB memory.
The old VS backend is unaffected. GEN6+, which does clipping entirely
in hardware, is also unaffected.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
/external/mesa3d/src/mesa/drivers/dri/i965/gen6_vs_state.c
|
| d9cb683f81b5daefda2f8599b4ba0365cc6f009a |
|
02-Sep-2011 |
Paul Berry <stereotype441@gmail.com> |
i965: Don't upload clip planes when gl_ClipDistance is in use.
When the vertex shader writes to gl_ClipDistance, we do clipping based
on clip distances rather than user clip planes, so don't waste push
constant space storing user clip planes that won't be used.
Reviewed-by: Eric Anholt <eric@anholt.net>
/external/mesa3d/src/mesa/drivers/dri/i965/gen6_vs_state.c
|
| 55b7fbb70ffc1f4def5c3ded63c3ef569e693731 |
|
19-Aug-2011 |
Eric Anholt <eric@anholt.net> |
i965: Use native integer uniforms when the new VS backend is in use.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
/external/mesa3d/src/mesa/drivers/dri/i965/gen6_vs_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/gen6_vs_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/gen6_vs_state.c
|
| 3e5d36267d8c9536490c902f785137a7fa0637fc |
|
20-Jul-2011 |
Eric Anholt <eric@anholt.net> |
i965: Apply a homebrew workaround for GPU hang in OGLC api-texcoord.
The behavior of flushes in the hardware is a maze of twisty passages,
and strangely the VS constants appear to be loaded during a pipeline
flush instead of at the time of the packet emit according to the
simulator. On moving the STATE_BASE_ADDRESS packet to where it really
needed to live (in order for data loads by other packets to be
correct), we sometimes no longer got a flush between those packets
where we apparently needed it. This replicates the flushes implied by
a STATE_BASE_ADDRESS update, fixing the GPU hangs in OGLC and the
"engine" demo.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=36821
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=39257
Tested-by: Keith Packard <keithp@keithp.com> (bzflag and etracer fixed)
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
/external/mesa3d/src/mesa/drivers/dri/i965/gen6_vs_state.c
|
| a1226bcd20a582146f1848cc0af8145c53b0ecbc |
|
08-Jul-2011 |
Eric Anholt <eric@anholt.net> |
i965/gen6: Add state dumping for the VS constants.
This is quite a bit of spam, but I think it's useful to have in a full
INTEL_DEBUG=batch dump. And a lot of this spam on glxgears is just
because we're awful at handling our constants :/
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
/external/mesa3d/src/mesa/drivers/dri/i965/gen6_vs_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/gen6_vs_state.c
|
| 911768700ed63c937bfcc75ec9afcfd1aa66f690 |
|
16-Jun-2011 |
Eric Anholt <eric@anholt.net> |
i965/gen6: Remove state flagging on BRW_NEW_CURBE_OFFSETS.
That flag was leftover from gen4, where brw_curbe.c is choosing ranges
of the CURBE space for constants to live in, and the unit state tells
where to load them from. That's not the case on gen6 -- we don't set
this flag (since constants aren't in the URB), nor do we have any
state like that to upload.
/external/mesa3d/src/mesa/drivers/dri/i965/gen6_vs_state.c
|
| 7d4d6082403bef750375cbff5cbb709e1fd30715 |
|
16-Jun-2011 |
Eric Anholt <eric@anholt.net> |
i965/gen6: Add missing state flag for VS push constants.
It was already annotated up above and everything.
/external/mesa3d/src/mesa/drivers/dri/i965/gen6_vs_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/gen6_vs_state.c
|
| a82a43e8d99e1715dd11c9c091b5ab734079b6a6 |
|
23-Apr-2011 |
Eric Anholt <eric@anholt.net> |
i965/gen6: Use the dynamic state base address to reduce relocations.
Now that all the dynamic state is streamed through the top of the
batchbuffer, we can cut out many of our relocations to that state by
using the base address.
Improves 3DMMES taiji performance 3.3% +/- 0.4% (n=15).
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
/external/mesa3d/src/mesa/drivers/dri/i965/gen6_vs_state.c
|
| 32cc0c9d8de343f699e80e7e416ea0d7e3121a42 |
|
22-Apr-2011 |
Eric Anholt <eric@anholt.net> |
i965/gen6: Stream the VS push constants.
Improves 3DMMES taiji demo performance by 10.1% +/- 0.9% (n=15).
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
/external/mesa3d/src/mesa/drivers/dri/i965/gen6_vs_state.c
|
| 904b8ba1bb604b2eaaa22f7f074d236011fe213f |
|
29-Mar-2011 |
Eric Anholt <eric@anholt.net> |
i965: Fix the VS thread limits for GT1, and clarify the WM limits on both.
/external/mesa3d/src/mesa/drivers/dri/i965/gen6_vs_state.c
|
| 6c324777a685d28d0a81d23157e4863240552999 |
|
01-Mar-2011 |
Zou Nan hai <nanhai.zou@intel.com> |
i965: bump VS thread number to 60 on SNB
Signed-off-by: Zou Nan hai <nanhai.zou@intel.com>
/external/mesa3d/src/mesa/drivers/dri/i965/gen6_vs_state.c
|
| e31defc825ee94f1d1092e277954abad7097c552 |
|
04-Jan-2011 |
Kenneth Graunke <kenneth@whitecape.org> |
i965: Rename various gen6 #defines to match the documentation.
This should make it easier to cross-reference the code and hardware
documentation, as well as clear up any confusion on whether constants
like CMD_3D_WM_STATE mean WM_STATE (pre-gen6) or 3DSTATE_WM (gen6+).
This does not rename any pre-gen6 defines.
/external/mesa3d/src/mesa/drivers/dri/i965/gen6_vs_state.c
|
| c52adfc2e1d130effea940e75690897eb5d3ceaa |
|
16-Dec-2010 |
Eric Anholt <eric@anholt.net> |
i965: Set the alternative floating point mode on gen6 VS and WM.
This matches how we did the math instructions pre-gen6, though it
applies to non-math as well.
Fixes vp1-LIT test 2 (degenerate case: 0 ^ 0 -> 1)
/external/mesa3d/src/mesa/drivers/dri/i965/gen6_vs_state.c
|
| 05e534e6c4395269b1ca3a9694a1f437363dd186 |
|
09-Dec-2010 |
Eric Anholt <eric@anholt.net> |
i965: Drop push-mode reladdr constant loading and always use constant_map.
This eases the gen6 implementation, which can only handle up to 32
registers of constants, while likely not penalizing real apps using
reladdr since all of those I've seen also end up hitting the pull
constant buffer. On gen6, the constant map means that simple NV VPs
fit under the 32-reg limit and now succeed. Fixes around 10 testcases.
/external/mesa3d/src/mesa/drivers/dri/i965/gen6_vs_state.c
|
| 65972f992f2b5505cc568a3fa29254e8d25c3042 |
|
10-Nov-2010 |
Zhenyu Wang <zhenyuw@linux.intel.com> |
Revert "i965: VS use SPF mode on sandybridge for now"
This reverts commit 9c39a9fcb2c76897e9b5aff68ce197a411c4e25c.
Remove VS SPF mode, conditional instruction works for VS now.
/external/mesa3d/src/mesa/drivers/dri/i965/gen6_vs_state.c
|
| b271445e3731a512425fa28f20579e8af48bbfa2 |
|
29-Oct-2010 |
Eric Anholt <eric@anholt.net> |
i965: Upload required gen6 VS push constants even when using pull constants.
Matches pre-gen6, and fixes glsl-vs-large-uniform-array.
/external/mesa3d/src/mesa/drivers/dri/i965/gen6_vs_state.c
|
| e30a3e7aa09c373c0a02df555d090693718f0fe8 |
|
27-Oct-2010 |
Eric Anholt <eric@anholt.net> |
i965: Add user clip planes support to gen6.
Fixes piglit user-clip, and compiz desktop switching when dragging a
window and using just 2 desktops. Bug #30446.
/external/mesa3d/src/mesa/drivers/dri/i965/gen6_vs_state.c
|
| 2595589f1df351895bc5b1a92f19e995a19da15b |
|
19-Oct-2010 |
Eric Anholt <eric@anholt.net> |
i965: Remove the gen6 emit_mi_flushes I sprinkled around the driver.
These were for debugging in bringup. Now that relatively complicated
apps are working, they haven't helped debug anything in quite a while.
/external/mesa3d/src/mesa/drivers/dri/i965/gen6_vs_state.c
|
| f9995b30756140724f41daf963fa06167912be7f |
|
12-Oct-2010 |
Kristian Høgsberg <krh@bitplanet.net> |
Drop GLcontext typedef and use struct gl_context instead
/external/mesa3d/src/mesa/drivers/dri/i965/gen6_vs_state.c
|
| 9c39a9fcb2c76897e9b5aff68ce197a411c4e25c |
|
17-Sep-2010 |
Zhenyu Wang <zhenyuw@linux.intel.com> |
i965: VS use SPF mode on sandybridge for now
Until conditional instructions were fixed, use SPF mode instead for now.
/external/mesa3d/src/mesa/drivers/dri/i965/gen6_vs_state.c
|
| ec2b92f98c2e7f161521b447cc1d9a36bce3707c |
|
11-Jun-2010 |
Brian Paul <brianp@vmware.com> |
mesa: rename src/mesa/shader/ to src/mesa/program/
/external/mesa3d/src/mesa/drivers/dri/i965/gen6_vs_state.c
|
| edc8a99d1dc9963f61c3ecb5fdf481efae359ce4 |
|
20-Mar-2010 |
Eric Anholt <eric@anholt.net> |
i965: Enable VS on SNB.
It appears that the thing that was killing VS threads was the
gratuitous NOP that replaced the gratuitous jump from OPCODE_END to
the nearby OPCODE_END implementation. With that gone, we can move on
to the rest of the pipeline.
/external/mesa3d/src/mesa/drivers/dri/i965/gen6_vs_state.c
|
| bb35000b4b6dfe60048b2f5d60bc102c4a7fd791 |
|
05-Mar-2010 |
Eric Anholt <eric@anholt.net> |
intel: Remove non-kernel-exec-fencing support.
Shaves 60k off the driver from removing the broken spans code. This
means we now require 2.6.29, which seems fair given that it's a year
old and we've removed support for non-KMS already in the last release
of 2D.
/external/mesa3d/src/mesa/drivers/dri/i965/gen6_vs_state.c
|
| c76d4db25260dd68684bf784efacd7323c7cab8b |
|
26-Feb-2010 |
Vinson Lee <vlee@vmware.com> |
i965: Remove unnecessary headers.
/external/mesa3d/src/mesa/drivers/dri/i965/gen6_vs_state.c
|
| 078e7b62f69658e40aedea59cf6f005162a29f83 |
|
24-Feb-2010 |
Eric Anholt <eric@anholt.net> |
i965: Emit SNB FF unit state after the unit's push constants.
There's a BUN for the WM unit that says WM_STATE must immediately
follow PS_CONSTANTS, which this addresses. Presumably other units are
roughly the same, too.
/external/mesa3d/src/mesa/drivers/dri/i965/gen6_vs_state.c
|
| 2ab3bf2fa37042386a2d50f60b1d0e32e26b91c2 |
|
25-Jan-2010 |
Eric Anholt <eric@anholt.net> |
i965: Re-disable the VS.
There's stuff that needs to happen in the ISA before we can play with
actually executing anything in the VS.
/external/mesa3d/src/mesa/drivers/dri/i965/gen6_vs_state.c
|
| 70be48dff6bb68c61285641e4d976bfd53e0f00c |
|
29-Jan-2010 |
Eric Anholt <eric@anholt.net> |
i965: Untested Sandybridge SF setup.
/external/mesa3d/src/mesa/drivers/dri/i965/gen6_vs_state.c
|
| d971375bc1872cb2d95a710e3d62f5b037fbe7f7 |
|
29-Jan-2010 |
Eric Anholt <eric@anholt.net> |
i965: Giant pile of flushing to track down SNB bringup issues.
This should go away before we push the code.
/external/mesa3d/src/mesa/drivers/dri/i965/gen6_vs_state.c
|
| ff3997904ab988824e744fdbecde6eb79d9bf40f |
|
04-Dec-2009 |
Eric Anholt <eric@anholt.net> |
i965: Reconnect the index/vertex setup.
/external/mesa3d/src/mesa/drivers/dri/i965/gen6_vs_state.c
|
| 8485e100b81d5cf44cde7af0c7feb79a32bf3dd0 |
|
04-Dec-2009 |
Eric Anholt <eric@anholt.net> |
i965: Try uploading SNB VS constants.
/external/mesa3d/src/mesa/drivers/dri/i965/gen6_vs_state.c
|
| eda1b50aa10031aeb07071f59fed93304b2fe2ca |
|
04-Dec-2009 |
Eric Anholt <eric@anholt.net> |
i965: Try turning on the VS.
/external/mesa3d/src/mesa/drivers/dri/i965/gen6_vs_state.c
|
| 98f9666f04eed9ae873fdea20c4c4b9db6cead84 |
|
04-Dec-2009 |
Eric Anholt <eric@anholt.net> |
i965: Get vp-tri batchbuffers running (no rendering).
/external/mesa3d/src/mesa/drivers/dri/i965/gen6_vs_state.c
|
| ba882d7827e5526e99c9d5c453d56c5e029c7476 |
|
16-Nov-2009 |
Eric Anholt <eric@anholt.net> |
i965: Add untested Sandybridge passthrough VS setup.
/external/mesa3d/src/mesa/drivers/dri/i965/gen6_vs_state.c
|