| Age | Commit message (Collapse) | Author |
|---|
|
This drops support for get_src_reg_imm in these, but the prospect of getting
brw_wm_pass*.c onto our GLSL path is well worth some temporary pain.
|
|
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.
|
|
something is broken so disabled for now
|
|
instead of lots of very small transfers, one larger is a lot better
for performance
|
|
|
|
easier to split, accumulate and batch those
|
|
|
|
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.
|
|
This fixes the dead code elimination to work on the particular code
mentioned in the previous commit.
|
|
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.
|
|
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.
|
|
|
|
This keeps the individual state files from having to export their
structures for brw_state_cache initialization.
|
|
I fixed it properly as of 7216679c1998b49ff5b08e6b43f8d5779415bf54.
|
|
Otherwise, we could lose track of rendering to that image, which could
easily happen during mipmap generation.
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
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
|
|
|
|
_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.
|
|
be kept
|
|
This reverts commit 93dae6761bc90bbd43b450d2673620ec189b2c7a.
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.
|
|
Fixes bug 24949.
|
|
fixes bug 24953.
|
|
Used in Quake3.
|
|
|
|
|
|
first step on our way to batching
|
|
The code was assuming ctx->DrawBuffer == ctx->ReadBuffer.
Passing the pixmap is simpler and better.
Fixes a potential segfault.
|
|
Fixes bug 24946.
This regression came from 8df699b3bb1aa05b633f05b121d09d812c86a22d.
|
|
It is a valid and tested combination on D3D9.
|
|
|
|
|
|
Signed-off-by: Corbin Simpson <MostAwesomeDude@gmail.com>
|
|
Signed-off-by: Corbin Simpson <MostAwesomeDude@gmail.com>
|
|
Suggested by Joakim Sindholt.
Also, put flushing of colorbuffers _before_ the framebuffer state setup,
suggested by docs.
Signed-off-by: Corbin Simpson <MostAwesomeDude@gmail.com>
|
|
Signed-off-by: Corbin Simpson <MostAwesomeDude@gmail.com>
|
|
|
|
Conflicts:
src/mesa/drivers/windows/gdi/mesa.def
|
|
The exec->vtx.inputs[] array was being written past its end. This was
clobbering the following vbo_exec_context::eval state. Probably not noticed
since evaluators and immediate mode rendering don't happen at the same time.
Fixed the loop in vbo_exec_vtx_init().
Changed the size of the vbo_exec_context::vtx.arrays[] array.
Added a bunch of debug-build assertions.
Issue found by Vinson Lee.
|
|
|
|
|
|
|
|
performance optimization
|
