| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|\ |
|
| |
| |
| |
| |
| |
| | |
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.
|
| | |
|
|\ \ |
|
| | | |
|
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
|
| | |
|
|/ |
|
|
|
|
| |
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*.
|
| |
|
| |
|
|
|
|
|
|
| |
This format is layered on MESA_FORMAT_RGB888 so the component order is
actually BGR.
Fixes glean pixelFormat failures.
|
| |
|
|
|
|
|
| |
It was only set to GL_TRUE in one place where it isn't really needed
(glGetTexImage(sRGB format)).
|
|
|
|
| |
For luminance, we add R+G+B and it seems we should always clamp in case.
|
| |
|
| |
|
|
|
|
|
| |
EyeDirection -> SpotDirection
_NormDirection -> _NormSpotDirection
|
|
|
|
|
| |
In glLight() we're only supposed to transform the direction by the modelview
matrix, not normalized it too.
|
| |
|
|
|
|
|
|
|
|
|
| |
premature return in TexParameterf caused mesa to never call Driver.TexParameter
breaking drivers relying on this (fix bug #20966).
While here, also fix using ctx->ErrorValue when deciding to call
Driver.TexParameter. Errors are sticky and uncleared errors thus would cause
this to no longer get called. Since we thus need return value of
set_tex_parameter[if] can also optimize this to only call when value changed.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Use MAX_COMBINER_TERMS instead of 4.
Rename some vars.
Update comments.
|
|
|
|
|
| |
The code's cleaner and a step toward supporting float-valued texture sampling.
Some optimizations for common cases can be added and re-enabled...
|
|
|
|
|
|
|
|
|
| |
A shader program may consist of multiple shaders (source code units).
If we find there are unresolved functions after compiling the unit that
defines main(), we'll concatenate all the respective vertex or fragment
shaders then recompile.
This isn't foolproof but should work in most cases.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes an issue when compiling glCallList() into another display list
when the mode is GL_COMPILE_AND_EXECUTE.
Before, the call to glCallList() called _mesa_save_CallList() which called
neutral_CallList() which then called _mesa_save_CallList() again. In the
end, the parent display list contained two calls to the child display list
instead of one.
Let's be on the lookout for regressions caused by this change for a while
before we cherry-pick this elsewhere.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The 'dots' register wasn't getting properly un-negated and un-swizzled
after emitting the code for back-face lighting. So, if more than one
light source was enabled, the specular exponent for the next light source
was wrong.
During execution we were evaluating pow(x, y) where y was negative instead
of positive. This led to the outcome being zero or NaN.
This fixes the occasional black triangles seen in isosurf when hacked to
enable two-sided lighting.
|
| |
|
| |
|