| Age | Commit message (Collapse) | Author |
|---|
|
Handle both NV vertex programs and NV vertex state programs passed to
glProgramStringARB.
|
|
|
|
If a fragment program only parameter was queried of a vertex program
(e.g., GL_MAX_PROGRAM_TEX_INDIRECTIONS_ARB) no error would be set and
a random value would be returned. This caused 'glxinfo -l' to show
the same values for GL_MAX_PROGRAM_ALU_INSTRUCTIONS_ARB,
GL_MAX_PROGRAM_TEX_INSTRUCTIONS_ARB, GL_MAX_PROGRAM_TEX_INDIRECTIONS_ARB,
GL_MAX_PROGRAM_NATIVE_ALU_INSTRUCTIONS_ARB,
GL_MAX_PROGRAM_NATIVE_TEX_INSTRUCTIONS_ARB,
GL_MAX_PROGRAM_NATIVE_TEX_INDIRECTIONS_ARB as for
GL_MAX_PROGRAM_ENV_PARAMETERS_ARB. This is confusing and incorrect.
|
|
|
|
Use MAX_VERTEX_GENERIC_ATTRIBS instead. No need for two #defines for
the same quantity.
|
|
|
|
|
|
Use _NEW_PROGRAM_CONSTANTS when changing constant/uniform buffer values.
Binding a new program/shader sets both _NEW_PROGRAM and _NEW_PROGRAM_CONSTANTS.
|
|
This state flag will be used to indicate that vertex/fragment program
constants have changed. _NEW_PROGRAM will be used to indicate changes
to the vertex/fragment shader itself, or misc related state.
_NEW_PROGRAM_CONSTANTS is also set whenever a program parameter that's
tracking GL state has changed. For example, if the projection matrix is
in the parameter list, calling glFrustum() will cause _NEW_PROGRAM_CONSTANTS
to be set. This will let to remove the need for dynamic state atoms in
some drivers.
For now, we still set _NEW_PROGRAM in all the places we used to. We'll no
longer set _NEW_PROGRAM in glUniform() after drivers/etc have been updated.
|
|
|
|
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
|
|
|
|
This is another step toward removing a whole bunch of -I flags from
the cc commands. Still need to address driver code...
|
|
No API-level functions now in program.c.
|
|
Wine intentionally tries some out-of-spec programs to test strictness, and
calling ProgramStringNotify on the results of a failed program parse resulted
in crashes in the 965 driver.
|
|
these should be the same functions (as per spec).
|
|
|
|
|
|
they can now apply to vertex programs.
|
|
|
|
|
|
|
|
OpenGL 2.0 function of the same name.
|
|
either GL_ARB_vertex_program or GL_ARB_fragment_program should enable this
extension as well.
|
|
"gl_" to match other structs.
|
|
and demos are also added.
Adding basic support to drivers should be as easy as just enabling the
extension, though thorough test would also be required.
|
|
which is actually handled
|
|
- use macros to access and modify render inputs bit-field;
- un-alias generic vertex attributes for ARB vertex calls;
- use MAX_VERTEX_PROGRAM_ATTRIBS (NV code) or MAX_VERTEX_ATTRIBS
(ARB code) in place of VERT_ATTRIB_MAX;
- define VERT_ATTRIB_GENERIC0..15 for un-aliased vertex
attributes for ARB_vertex_shader;
- fix generic attribute index range check in arbprogparse.c;
- interface GLSL varyings between vertex and fragment shader;
- use 64-bit optimised bitset (bitset.h) for render inputs;
|
|
arbprogparse.c and remove arbvertparse.[ch] and arbfragparse.[ch].
Clean up quite a bit of the arb parsing code.
Rewrite parser extension code to avoid a mess of string operations every
time the parser was used.
|
|
Based on patch by Ian (#4967) but also unify instruction opcodes.
|
|
temporaries, parameters, etc).
glGetProgramivARB() now returns all the right things.
Updated i915 and r300 code to initialize program native limits and
current program's native instruction/temporary/etc counts.
|
|
use 64-bit pointers and 32-bit longs. So, operations like casting pointers
to unsigned long and back to pointer won't work. glheader.h now
includes files to define uintptr_t, which should instead be used for
this sort of operation. It is an integer type that is the same size
as a pointer.
|
|
|
|
|
|
|
|
|
