| Age | Commit message (Collapse) | Author |
|---|
|
Initialize the shader's pragma settings before calling the compiler.
Added pragma "Ignore" fields to allow overriding the #pragma directives found
in shader source code.
|
|
It turns out some tests are sensitive to rounding vs. truncating when
converting float color values to integers in glReadPixels(). In particular,
this matters when the destination format is 5/6/5 or 4/4/4/4, etc.
|
|
|
|
|
|
|
|
|
|
|
|
This gets hit when glTexSubImage2D() is called with format==GL_DU8DV8_ATI.
|
|
|
|
|
|
|
|
If GL_AUX[123] are passed to glRead/DrawBuffer() when those buffers don't
exist, need to generate GL_INVALID_OPERATION, not GL_INVALID_ENUM.
This regression came from commit 555f0a88182e2b1af809b2d97abdac02814a2f28
|
|
The polygon stipple pattern, like the viewport and the
polygon face orientation, must be inverted on the i965
when rendering to a FBO (which itself has an inverted pixel
coordinate system compared to raw Mesa).
In addition, the polygon stipple offset, which orients
the stipple to the window system, disappears when rendering
to an FBO (because the window system offset doesn't apply,
and there's no associated FBO offset).
With these fixes, the conform triangle and polygon stipple
tests pass when rendering to texture.
|
|
|
|
|
|
add new entrypoints, new texture format, etc
translate in texenvprogram.c for drivers using the mesa-generated tex env
fragment program
also handled in swrast, but not tested (cannot work due to negative texel
results not handled correctly)
|
|
|
|
In the i965, the FBO coordinate system is inverted from the standard
OpenGL/Mesa coordinate system; that means that the viewport and the
polygon face orientation have to be inverted if rendering to a FBO.
The viewport was already being handled correctly; but polygon face
was not. This caused a conform failure when rendering to texture with
two-sided lighting enabled.
This fixes the problem in the i965 driver, and adds to the comment about
the gl_framebuffer "Name" field so that this isn't a surprise to other
driver writers.
|
|
|
|
|
|
It was only used in one place in swrast.
|
|
|
|
|
|
A bit of refactoring with an eye toward ES2 and GL 3.1
|
|
|
|
This was never fully fleshed out and hasn't been used.
|
|
|
|
Signed-off-by: Alan Coopersmith <alan.coopersmith@sun.com>
|
|
Useful for debugging to override an application's shader.
|
|
Otherwise two threads might think each made the refcount go zero.
|
|
Windows threads block if one over-unlocks them.
|
|
|
|
|
|
Namelly, FlushMappedBufferRange takes a subrange relative to the original
range.
|
|
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.
|
|
Conflicts:
scons/gallium.py
src/gallium/auxiliary/pipebuffer/pb_buffer_fenced.c
src/gallium/include/pipe/p_defines.h
src/mesa/vbo/vbo_exec_api.c
src/mesa/vbo/vbo_exec_draw.c
|
|
Will be needed in coming GL extensions (GL_map_buffer_range, GL 3.0).
Will be used by the vbo module to avoid reallocating vbo's at each
draw primitive call.
|
|
Provides notification to the VBO modules prior to the first immediate call.
Pairs with FlushVertices()
|
|
|
|
Another conditional can be avoided.
|
|
Need to clear the _ReallyEnabled field before possibly continuing the loop.
Also, set _Current pointer to NULL if the unit is no longer enabled.
Fixes piglit lodbias regression
|
|
Fixes piglit copytexsubimage regression.
|
|
For regular GL, we must have vertex positions in order to draw. But ES2
doesn't have that requirement (positions can be computed from any array
of data).
See bug 19911.
|
|
With FBOs one could enable stencil before a stencil buffer is later bound.
|
|
Only true if stenciling is enabled, and there's a stencil buffer.
|
|
This field should not include vertex textures. It indicates the coord
inputs for fragment / fixed-function processing.
|
|
|
|
We can avoid a few iterations this way.
|
|
|
|
Remove all references to aux buffers 1..3. Keep AUX0 around for now just
in case, but it'll probably go too someday. I don't know of any OpenGL
drivers since the IRIX days that support aux color buffers.
|
