| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
And some other fixes.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
r300g: Un-migrate r300_draw_render.
It'll make maintaining the SW TCL path easier.
|
|
|
|
| |
Fixes bug 24967.
|
|
|
|
|
| |
This should be the default setting.
See also 7d967b9b7c08aea2a471c5bf6aced8bfafdae874.
|
|
|
|
|
|
|
| |
No statistically significant performance difference at n=3 with either
openarena or my GL demo, but cutting program size seems like a good
thing to be doing for the hypothetical app that has a working set near
icache size.
|
| |
|
|
|
|
| |
This should fix issues with antialiased lines in GLSL.
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
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.
|
| |
| |
| |
| |
| |
| | |
The code was assuming ctx->DrawBuffer == ctx->ReadBuffer.
Passing the pixmap is simpler and better.
Fixes a potential segfault.
|
| | |
|
| |
| |
| |
| | |
Fixes bug 24949.
|