Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
Possibly performance may improve by setting it to the last instruction that
writes result.position, rather than the last instruction in the vertex program.
|
|
|
|
|
|
I believe there are still bugs with all polygon offset types. The point and line
types may need to be handled specially, too.
This shouldn't break anything because it just enabled the occlusion control bits
for polygon offset.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Thanks to Panagiotis Papadakos for reporting it.
|
|
Need to turn off FRAG_BIT_COL0 in swrast->_ActiveAttribMask when doing
glRead/CopyPixels to prevent the user's colors from getting overwritten
when a fragment program is active.
This was happening in the DRI drivers when MaintainTexEnv program was
used (the texenv fragment program was enabled when _swrast_DrawPixels was
called).
This still isn't an ideal solution, but fixes things for now.
|
|
|
|
|
|
It's OK to use _TexEnvProgram regardless of the texture state, but if fog
is also enabled, the fragment program is lacking the actual fog computation
so fogging doesn't appear.
Fixing this might involve a new _MaintainFogProgram field and related code.
For now, just disable the _TexEnvProgram and let swrast handle everything.
|
|
|
|
problem)
|
|
|
|
|
|
|
|
a goto
|
|
|
|
|
|
|
|
|
|
|
|
state validation/update.
Note that we're still temporarily skipping the test for an active fragment
program. Need to fix shadow2D() ...
|
|
|
|
|
|
|
|
|
|
This fixes the depth-peel regression reported by Brad King.
|
|
an app issue, not a mesa bug.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The ARB_fp (and other assembly-level fragment program specs) say that the
depth comparison function is always GL_NONE in fragment program mode.
|
|
|