i965: Share most of the WM functions between brw_wm_glsl.c and brw_wm_emit.c
The PINTERP code should be faster for brw_wm_glsl.c now since brw_wm_emit.c's
had been improved, and pixel_w should no longer stomp on a neighbor to dst.
i965: Collect GLSL src/dst regs up in generic code.
This matches brw_wm_emit.c, which we'll be using shortly. There's a
possible penalty here in that we'll allocate registers for unused channels,
since we aren't doing ref tracking like brw_wm_pass*.c does. However, my
measurements on GM965 don't show any for either OA or UT2004 with the GLSL
path forced.
mesa: Reduce the source channels considered in optimization passes.
Depending on the writemask or the opcode, we can often trim the source
channels considered used for dead code elimination. This saves actual
instructions on 965 in the non-GLSL path for glean glsl1, and cleans up
the writemasks of programs even further.
mesa: Add an optimization path to remove use of pointless MOVs.
GLSL code such as:
vec4 result = {0, 1, 0, 0};
gl_FragColor = result;
emits code like:
0: MOV TEMP[0], CONST[0];
1: MOV OUTPUT[1], TEMP[0];
and this replaces it with:
0: MOV TEMP[0], CONST[0];
1: MOV OUTPUT[1], CONST[0];
Even when the dead code eliminator fails to clean up a now-useless MOV
instruction (since it doesn't do live/dead ranges), this should at reduce
dependencies.
mesa: Fix up the remove_dead_code pass to operate on a channel basis.
This cleans up a bunch of instructions in GLSL programs to have limited
writemasks, which would translate to wins in shaders that hit the i965
brw_wm_glsl.c path by depending less on in-driver optimizations. It will
also help hit other optimization passes I'm looking at.
mesa: Attempt to pair up Driver.RenderTexture and FinishRenderTexture()
This is probably not 100% complete (bind vs unbind may still not pair up
exactly), but it should help out drivers which are relying on
FinishRenderTexture to be called when we're done rendering to a particular
texture level, not just when we're done rendering to the object at all.
This is the case for the one consumer of FinishRenderTexture() so far: the
gallium state tracker. Noticed when trying to make use of FRT() in the intel
driver.
intel: Use PIPE_CONTROL on gen4 hardware for doing pipeline flushing.
This should do all the things that MI_FLUSH did, but it can be pipelined
so that further rendering isn't blocked on the flush completion unless
necessary.
Make a convenient int for what chipset generation we're on.
gen2/3/4 are easier to say than "8xx, 915-945/g33/pineview, 965/g45/misc",
and compares on generation are often easier than stringing together a bunch
of chipset checks.
This should fix the memory leaks in the assembly parser without the
regressions.
The conflicts in program_lexer.l were related to changes in returning
strings between the branches (always return IDENTIFIER vs. returing
either IDENTIFIER or USED_IDENTIFIER).
The conflicts in program_parse.y were related to two changes in master
One change prints a variable name in an error message. The other
change adds outputVarSize to the OUTPUT_statement rule. The cause the
position of the IDENTIFIER to change from $2 to $3.
Conflicts:
src/mesa/shader/lex.yy.c
src/mesa/shader/program_lexer.l
src/mesa/shader/program_parse.tab.c
src/mesa/shader/program_parse.y
ARB prog parser: Release old program string in _mesa_parse_arb_{fragment,vertex}_program
The program structure passed to _mesa_parse_arb_program is just a
place holder. The stings that actually need to be released are only
known to the functions calling _mesa_parse_arb_program, so they should
be freed there.
This reverts commit 93dae6761b.
This change was completely broken when the parser uses multiple
strings in a single production. It would be nice if bug fixes could
initially land somewhere other than the stable branch.
Eric Anholt