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
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.
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>
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.
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>
Mip-mapped 3D textures are not arrays of 2D layers
with a mip-map layout like 2D textures, therefore we
cannot use image_nr == depth for them.
Making use of "volume tiling" modes now, the allowed
modes are 0xZY where Z <= 5 and y <= 5.
