| Age | Commit message (Collapse) | Author |
|---|
|
No difference, but a little more understandable.
|
|
Will be handy for bounds checking later...
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Makes no real difference, but more consistant.
|
|
two)
The semantics are a little different for shaders vs. fixed-function when
trying to use an incomplete texture. The fallback texture returning
(0,0,0,1) should only be used with shaders. For fixed function, the texture
unit is truly disabled/ignored.
Fixes glean fbo test regression.
|
|
This reverts commit a0edbfb28fb2e670c657d52190a7e8b1ccf4f46e.
This patch didn't completely fix the problem. The next patch will.
|
|
The semantics are a little different for shaders vs. fixed-function when
trying to use an incomplete texture. The fallback texture returning
(0,0,0,1) should only be used with shaders.
Fixes glean fbo test regression.
|
|
The semantics are a little different for shaders vs. fixed-function when
trying to use an incomplete texture. The fallback texture returning
(0,0,0,1) should only be used with shaders.
Fixes glean fbo test regression.
|
|
|
|
Add a new flag mvp_with_dp4 in the context, and use that to switch
both ffvertex.c and programopt.c vertex transformation code to
either DP4 or MUL/MAD implementations.
|
|
This is a quick fix for z fighting in quake4 caused by the mismatch
between vertex transformation here and in the position_invarient code.
Full fix would be to make this driver-tunable and adjust both
position_invarient and ffvertex_prog.c code to respect driver
preferences.
|
|
Since GL_READ_BUFFER is historically part of the gl_pixel_attrib group
it made sense to signal changes with _NEW_PIXEL. But now with FBOs it's
also part of the framebuffer state.
Now _NEW_PIXEL strictly indicates pixels transfer state changes.
This change avoids framebuffer state validation when any random bit of
pixel-transfer state is set.
DRI drivers updated too: don't check _NEW_COLOR when updating framebuffer
state. I think that was just copied from the Xlib driver because we care
about dither enable/disable state there.
|
|
|
|
We need to make sure the framebuffer state is up to date to make sure we
read pixels from the right buffer when doing a texture image copy.
|
|
|
|
When a GLSL sampler reads from an incomplete texture it should
return (0,0,0,1). Instead of jumping through hoops in all the drivers
to make this happen, just create/install a fallback texture with those
texel values.
Fixes piglit/fp-incomplete-tex on i965 and more importantly, fixes some
GPU lockups when trying to sample from missing surfaces. If a binding
table entry is NULL, it seems that sampling sometimes works, but not
always (lockup).
Todo: create a fallback texture for each type of texture target?
|
|
|
|
|
|
Already doing this for driver.flush()
|
|
snprintf not directly available on Windows.
|
|
As of commit 23ad86cfb91c294ce85a3116d4b825aaa3988a6e all messages go
through output_if_debug().
Add new parameter to output_if_debug() to indicate whether to emit a newline.
_mesa_warning() and _mesa_error() calls should not end their strings with \n.
_mesa_debug() calls should end their text with \n.
|
|
|
|
Call FLUSH_VERTICES() in _mesa_Histogram().
No need to signal _NEW_PIXEL in ResetHistogram(), ResetMinmax().
|
|
|
|
Calling _mesa_dump_textures() deleted the textures... oops!!!
|
|
Need to do this to ensure vbo code unmaps its buffers before calling
the driver, which may be sitting on top of a memory manager which
objects to firing commands from a mapped buffer.
|
|
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.
|
|
There's really no need for two negation fields. This came from the
GL_NV_fragment_program extension. The new, unified Negate bitfield applies
after the absolute value step.
|
|
|
|
|
|
|
|
If the walk callback called _mesa_HashRemove() we'd deadlock.
|
|
|
|
For testing, it's very useful to be able to test on a debug build,
while suppressing the debug messages (messages that are by default
suppressed in a release build), in order to see the same behavior
that users of release builds will see.
For example, the "piglit" test suite will flag an error on
programs that produce unexpected output, which means that a
debug build will always fail due to the extra debug messages.
This change introduces a new value to the MESA_DEBUG
environment variable. In a debug build, explicitly setting MESA_DEBUG
to "0" will suppress all debug messages (both from _mesa_debug() and
from _mesa_warning()). (The former behavior was that debug
messages were never suppressed in debug builds.)
Behavior of non-debug builds has not changed. In such a build,
_mesa_debug() messages are always suppressed, and _mesa_warning()
messages will be suppressed unless MESA_DEBUG is set *to any value*.
|
|
|
|
|
