| Age | Commit message (Collapse) | Author |
|---|
|
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
|
|
Signed-off-by: Brian Paul <brianp@vmware.com>
|
|
Seems INDX_OFFSET doesn't work properly on some cards,
so change back to immediate mode indices. Seems to only
affect DRI1. Needs more investigation.
Rework and clean up the draw functions.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
|
|
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
|
|
|
|
|
|
Signed-off-by: Brian Paul <brianp@vmware.com>
|
|
It's not sampling based so its results are biased towards functions called
many times.
|
|
For example, we would like to have a predicate and texture token
in one instruction to do predicated texture sampling.
|
