| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
| |
Multiple item params are OK because we don't allow swizzles for them
(in case you do array access to hit their elements, for example). For
singles, though, using the swizzle can cut down on storage, we do want
to allow a swizzled use of another param.
Fixes OGLC texRect.c.
|
|
|
|
|
|
|
| |
va_list is a mutable iterator. When passed to a function it will likely
point to somewhere else.
This fixes segmentation fault in glean vertProg1 on Ubuntu 9.10.
|
| |
|
| |
|
|
|
|
| |
This reverts part of commit 298be2b028263b2c343a707662c6fbfa18293cb2
|
| |
|
| |
|
|
|
|
| |
This may break the SUNOS4 build, but it's no longer relevant.
|
|
|
|
|
|
|
|
| |
Signed-off-by: Alan Coopersmith <[email protected]>
Note sure why the compiler's -I paths aren't doing the job, but this is OK.
Signed-off-by: Brian Paul <[email protected]>
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
This function will search the constant parameters in an effort to re-use
constant slots. For example, {1,2,3,4} and {4,1,1,2} can be stored in
one constant slot and accessed with different swizzles. The swizzle info
must be propogated though the parsing code in a few places.
Fixes Piglit "vpfp-generic tests/shaders/generic/big-param.vpfp" failure.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a GLbitfield64 type and several macros to operate on 64-bit
fields. The OutputsWritten field of gl_program is changed to use that
type. This results in a fair amount of fallout in drivers that use
programs.
No changes are strictly necessary at this point as all bits used are
below the 32-bit boundary. Fairly soon several bits will be added for
clip distances written by a vertex shader. This will cause several
bits used for varyings to be pushed above the 32-bit boundary. This
will affect any drivers that support GLSL.
At this point, only the i965 driver has been modified to support this
eventuality.
I did this as a "squash" merge. There were several places through the
outputswritten64 branch where things were broken. I foresee this
causing difficulties later for bisecting. The history is still
available in the branch.
Conflicts:
src/mesa/drivers/dri/i965/brw_wm.h
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
|
| | |
|
|\|
| |
| |
| |
| |
| |
| | |
Conflicts:
src/mesa/shader/lex.yy.c
src/mesa/shader/program_lexer.l
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Anything that matched IDENTIFIER was strdup'ed and returned to the
parser. However, almost every case of IDENTIFIER in the parser just
dropped the returned string on the floor. Every swizzle string, every
option string, every use of a variable, etc. leaked memory.
Create a temporary buffer in the parser state (string_dumpster and
dumpster_size). Return strings from the lexer to the parser in the
buffer. Grow the buffer as needed. When the parser needs to keep a
string (i.e., delcaring a new variable), let it make a copy then.
The only leak that valgrind now detects is /occasionally/ the copy of
the program string in gl_program::String is leaked. I'm not seeing
how. :(
|
|\|
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
src/mesa/drivers/dri/intel/intel_fbo.c
src/mesa/drivers/dri/intel/intel_mipmap_tree.c
src/mesa/drivers/dri/intel/intel_mipmap_tree.h
src/mesa/drivers/dri/intel/intel_tex_copy.c
src/mesa/drivers/dri/intel/intel_tex_image.c
|
| |
| |
| |
| |
| |
| |
| |
| | |
Array indexes are invalid when >= the maximum, but array sizes are
only in valid when > the maximum. This prevented programs from
declaring a single maximum size array.
See the piglit vp-max-array test.
|
|\ \
| | |
| | |
| | |
| | | |
Conflicts:
src/mesa/shader/program_parse.tab.c
|
| |\|
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
src/mesa/shader/lex.yy.c
src/mesa/shader/program_parse.tab.c
src/mesa/shader/program_parse.tab.h
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Conditional write masks and the condition-code based KIL instruction
are all supported. The specific behavior of KIL in the following
shader may or may not match the behavior of other implementations:
!!ARBfp1.0
TEMP GT;
MOVC GT, fragment.texcoord[0];
KIL GT.x;
END
Should be it interpreted as 'KIL srcReg' or as 'KIL ccTest'? The
current parser will interpret it as 'KIL srcReg'.
|
| | |
| | |
| | |
| | |
| | | |
The lexer will return IDENTIFIER only when the name does not have an
associated symbol. Otherwise USED_IDENTIFIER is returned.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Adds support for declaring TEMP and OUTPUT variables as 'LONG' or
'SHORT' precision. The precision specifiers are parsed, but they are
currently ignored. Some support for this may be added in the future,
but neither Intel hardware nor, as far as I'm aware, Radeon hardware
support multiple precisions.
Also adds support for instruction precision ('X', 'H', and 'R')
suffixes and instruction condition code output ('C') suffix. This
results in a fairly major change to the lexer. Instructions are
matched with all the possible suffix strings. The suffix string are
then carved off by a context (i.e., which program mode and options are
set) aware parser that converts the suffixes to bits in
prog_instruction.
This could have been handled in the same way _SAT was originally
handled in the lexer, but it would have resulted in a very large lexer
with lots of opportunity for cut-and-paste errors.
|
| | |
| | |
| | |
| | |
| | | |
The new constructor copies fields from the prog_instruction that the
parser expects the lexer to set.
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | | |
ARBfp requires scalar constants have a '.x' suffix, but NVfp_option
does not. This shows up with instructions that require a scalar
parameter (e.g., COS).
|
| | | |
|
| | | |
|
| |/
|/| |
|
| |
| |
| |
| | |
Fixes compilation warnings with MSVC.
|
| |
| |
| |
| |
| | |
Fixes symbol collisions with typedefs in Microsoft headers.
Perhaps we should prefix/suffix all the lexer tokens to avoid this.
|
|/
|
|
|
|
| |
The optional array index should clearly be enclosed in square
brackets. This helps the oglconform test vp_binding.c get a bit
farther, but it still fails.
|
| |
|
|
|
|
|
|
| |
The commit "ARP prog parser: Implement the spec, not what makes sense"
broke the parsing of scalar constants. This commit reverts that part
of that commit. Now vp_swizzle.c passes.
|
| |
|
|
|
|
|
| |
The KIL instruction doesn't have a destination register, so
dereferencing dst in asm_instruction_ctor would cause a segfault.
|
| |
|
|
|
|
|
| |
Some debug code from the older stand-alone version of the assembler
was hanging around and needed to go.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
This isn't really tested yet as no drivers actually support this extension.
|
| |
|