| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
| |
Replace the distinct struct gl_client_array members in gl_array_object by
an array of gl_client_arrays indexed by VERT_ATTRIB_*.
Renumber the vertex attributes slightly to keep the old semantics of the
distinct array members. Make use of the upper 32 bits in VERT_BIT_*.
Update all occurances of the distinct struct members with the array
equivalents.
Signed-off-by: Mathias Froehlich <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Make gl_program::InputsRead a 64 bits bitfield.
Adapt the intel and radeon driver to handle a 64 bits
InputsRead value.
Signed-off-by: Mathias Froehlich <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
If alpha test is enabled and there's no color buffers we still need the
fragment shader to emit a color.
v2: add _NEW_COLOR flag in _mesa_update_state_locked()
Fixes piglit fbo-alphatest-nocolor-ff failures with Gallium drivers.
Reviewed-by: Eric Anholt <[email protected]>
Tested-by: Eric Anholt <[email protected]> (i965)
|
|
|
|
|
|
|
|
|
|
| |
When there is no ARB_vertex_program program enabled, the Current
pointer points at a default program, so we were always using
VERTEX_PROGRAM_TWO_SIDE, even for fixed function lighting.
Fixes piglit two-sided-lighting*
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
| |
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
| |
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
| |
The 965 driver was ignoring the VERTEX_PROGRAM_TWO_SIDE flag and only
looking at fixed-function state.
|
|
|
|
|
|
|
|
|
|
| |
Since GL_EXT_blend_logic_op is removed, _LogicOpEnabled and
ColorLogicOpEnabled always have the same value.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Roland Scheidegger <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
| |
A change in sampleBuffers affects the final enable value.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Squashed commit of the following:
Author: Marek Olšák <[email protected]>
mesa: fix getteximage so that it doesn't clamp values
mesa: update the compute_version function
mesa: add display list support for ARB_color_buffer_float
mesa: fix glGet query with GL_ALPHA_TEST_REF and ARB_color_buffer_float
commit b2f6ddf907935b2594d2831ddab38cf57a1729ce
Author: Luca Barbieri <[email protected]>
Date: Tue Aug 31 16:50:57 2010 +0200
mesa: document known possible deviations from ARB_color_buffer_float
commit 5458935be800c1b19d1c9d1569dc4fa30a97e8b8
Author: Luca Barbieri <[email protected]>
Date: Tue Aug 24 21:54:56 2010 +0200
mesa: expose GL_ARB_color_buffer_float
commit aef5c3c6be6edd076e955e37c80905bc447f8a82
Author: Luca Barbieri <[email protected]>
Date: Thu Aug 26 18:12:34 2010 +0200
mesa, mesa/st: handle read color clamping properly
(I'll squash the st/mesa part to a separate commit. -Marek)
We set IMAGE_CLAMP_BIT in the caller based on _ClampReadColor, where
the operation mandates it.
TODO: did I get the set of operations mandating it right?
commit 3a9cb5e59b676b6148c50907ce6eef5441677e36
Author: Luca Barbieri <[email protected]>
Date: Thu Aug 26 18:09:41 2010 +0200
mesa: respect color clamping in texenv programs (v2)
Changes in v2:
- Fix attributes other than vertex color sometimes getting clamped
commit de26f9e47e886e176aab6e5a2c3d4481efb64362
Author: Luca Barbieri <[email protected]>
Date: Thu Aug 26 18:05:53 2010 +0200
mesa: restore color clamps on glPopAttrib
commit a55ac3c300c189616627c05d924c40a8b55bfafa
Author: Luca Barbieri <[email protected]>
Date: Thu Aug 26 18:04:26 2010 +0200
mesa: clamp color queries if and only if fragment clamping is enabled
commit 9940a3e31c2fb76cc3d28b15ea78dde369825107
Author: Luca Barbieri <[email protected]>
Date: Wed Aug 25 00:00:16 2010 +0200
mesa: introduce derived _ClampXxxColor state resolving FIXED_ONLY
To do this, we make ClampColor call FLUSH_VERTICES with the appropriate
_NEW flag.
We introduce _NEW_FRAG_CLAMP since fragment clamping has wide-ranging
effects, despite being in the Color attrib group.
This may be easily changed by s/_NEW_FRAG_CLAMP/_NEW_COLOR/g
commit 6244c446e3beed5473b4e811d10787e4019f59d6
Author: Luca Barbieri <[email protected]>
Date: Thu Aug 26 17:58:24 2010 +0200
mesa: add unclamped color parameters
|
| |
|
|
|
|
|
| |
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 <[email protected]>
|
| |
|
|
|
|
|
|
|
|
| |
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 <[email protected]> (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.
|