| Age | Commit message (Collapse) | Author |
|---|
|
This reverts commit 7cb87dffce2c7a37f960f3a865cf92fd193dd8c5.
There were regressions (Bug #35244) and more review has been requested.
|
|
gl_shader_program"
This reverts commit b4452c3baad6e0379eeb7f22f2e51d13999e1323.
|
|
This is like how we track FragmentProgram._Current for the computed
ARB fragment program for fixed function texenv, but this gives direct
access to the gl_shader_program for drivers to codegen from, skipping
ARB_fp.
|
|
This is a step towards providing a direct route for drivers accepting
GLSL IR for codegen. Perhaps more importantly, it runs the fixed
function fragment program through the GLSL IR optimization. Having
seen how easy it is to make ugly fixed function texenv code that can
do unnecessary work, this may improve real applicatinos.
|
|
and rename them.
|
|
We don't need to call bind_arrays in the vbo module if the states
which the function depends on are not dirty.
|
|
DD_POINT_SIZE was broken for quite some time, and the only driver (r200) relying
on this no longer needs it.
Both DD_POINT_SIZE and DD_LINE_WIDTH have no users left outside of debugging
output, hence instead of fixing DD_POINT_SIZE setting just drop both of them -
there was a plan to remove tricaps flags entirely at some point.
|
|
The assumption is that all stages are the same program or that
varyings are passed between stages using built-in varyings.
|
|
|
|
All the state that effects the program should be in the key.
This didn't help with bug 28169 but is a good fix anyway.
NOTE: this is a low-priority candidate for the 7.8 branch. In practice,
this issue might never be hit.
|
|
laying down the foundation for everything and implementing most of the
stuff.
linking, gl_VerticesIn and multidimensional inputs are left.
|
|
|
|
It uses ctx->VertexProgram._Current.
Signed-off-by: Brian Paul <brianp@vmware.com>
|
|
|
|
Eric added some new code to check if offset < obj_size before computing
_MaxElement but my original code was still present afterward and it
clobbered the _MaxElement value.
Not sure if this came from a bad merge or what.
|
|
|
|
As shown in mfeatures.h, this allows users of pixel.h to work without
knowing if the feature is available.
|
|
|
|
Funny thing is I annotated this dependency in
e5f63c403b767f9974e8eb5d412c012b8a69287f, but didn't actually use it.
|
|
The _TriangleCaps bit is deprecated, not updated when we require, and
is set based on state that hasn't been updated at that point in
_mesa_update_state_locked().
Fixes incorrect clear color in glsl/twoside.c with meta_clear_tris.
|
|
I started looking into why _NEW_ARRAY punishes us, and while annotating
dependencies noticed that a bunch of dependencies were missing.
|
|
Otherwise, a pointer greater than the size would underflow and give a large
maximum element.
Reviewed-by: Brian Paul <brianp@vmware.com> (previous version)
|
|
|
|
|
|
|
|
This value is per array object.
|
|
Used to be done in the glVertex/Normal/Color/etc/Pointer() calls but
if the VBO was reallocated the size could change.
New _NEW_BUFFER_OBJECT state flag.
|
|
|
|
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.
|
|
This fixes a regression in fbotest1 on 915, where a transition from
color+vertex array enabled to texcoord0+vertex array enabled wouldn't trigger
program update on the second _mesa_update_state of DrawArrays, and we'd sample
a constant texcoord of 0,0,0,1 instead of the array.
The double state update in DrawArrays from
1680ef869625dc1fe9cf481b180382a34e0738e7 still needs fixing.
|
|
A bit of refactoring with an eye toward ES2 and GL 3.1
|
|
When a hw driver fell back to swrast, swrast wasn't always getting informed
of program changes. When fixed function is translated into shaders, flags
like _NEW_LIGHT, _NEW_TEXTURE, etc. should really signal _NEW_PROGRAM.
In this case, swrast wasn't seeing _NEW_PROGRAM when new fragment shaders
were generated.
|
|
Only true if stenciling is enabled, and there's a stencil buffer.
|
|
This is the big merge of the gallium-0.2 branch into master.
gallium-master-merge was just the staging area for it.
Both gallium-0.2 and gallium-master-merge are considered closed now.
Conflicts:
progs/demos/Makefile
src/mesa/main/state.c
src/mesa/main/texenvprogram.c
|
|
This fixes a regression introduced in 46ae1abbac6837d051c10b2e8b57eab3d4958ff4
Break program validation into two steps, do part before texture state
validation and do the rest after:
1. Determine Vertex/Fragment _Enabled state.
2. Update texture state.
3. Determine pointers to current Vertex/Fragment programs (which may involve
generating new "fixed-function" programs).
See comments in the code for more details of the dependencies.
|
|
consistant with other flags
|
|
Program state needs to be updated before texture state since the later depends
on the former.
Fixes piglit texgen failure. The second time through the modes (press 't'
three times) we disable the fragment program and return to conventional texture
mode. State validation failed here because update_texture() saw stale fragment
program state.
|
|
There was a note in state.c about _Active deserving to die, and there were
potential issues with it due to i965 forgetting to set _UseTexEnvProgram.
Removing both simplifies things.
Reviewed-by: Brian Paul <brianp@vmware.com>
|
|
There was a note in state.c about _Active deserving to die, and there were
potential issues with it due to i965 forgetting to set _UseTexEnvProgram.
Removing both simplifies things.
Reviewed-by: Brian Paul <brianp@vmware.com>
|
|
The subsequent if/else cases always call _mesa_reference_fragprog() anyway.
|
|
The subsequent if/else cases always call _mesa_reference_fragprog() anyway.
|
|
|
|
|
|
Conflicts:
src/mesa/main/context.c
|
|
Patch provide by Keith.
Used in state tracker by DrawPixels to indicate that the state tracker (driver)
is using its own vertex program. This prevents the texenvprogram code from
replacing conventional shader inputs with state vars.
Fixes glDraw/CopyPixels regressions.
|
|
Conflicts:
src/mesa/glapi/descrip.mms
src/mesa/shader/grammar/descrip.mms
|
|
Conflicts:
src/gallium/auxiliary/gallivm/instructionssoa.cpp
src/gallium/auxiliary/gallivm/soabuiltins.c
src/gallium/auxiliary/rtasm/rtasm_x86sse.c
src/gallium/auxiliary/rtasm/rtasm_x86sse.h
src/mesa/main/texenvprogram.c
src/mesa/shader/arbprogparse.c
src/mesa/shader/prog_statevars.c
src/mesa/state_tracker/st_draw.c
src/mesa/vbo/vbo_exec_draw.c
|
|
Also, fix up some comments to be doxygen style.
|
|
Keep track of enabled/active vertex attributes.
Keep track of potential vertex program outputs.
When generating fragment program, replace references to fragment attributes
which are effectively non-varying and non-computed passthrough attributes with
references to the new CURRENT_ATTRIB tracked state value.
Only downside is slight ugliness in VBO code where we need to validate state
twice in succession.
|
|
|
