| Age | Commit message (Collapse) | Author |
|---|
|
This was changed between GL 1.0 and 1.1. Mesa still had the 1.0 behaviour.
|
|
|
|
|
|
There was a note in state.c about _Active deserving to die, and there were
potential issues with it due to i965 forgetting to set _UseTexEnvProgram.
Removing both simplifies things.
Reviewed-by: Brian Paul <brianp@vmware.com>
|
|
On Windows snprintf is renamed as _snprintf.
(cherry picked from commit f8f9a1b620d31d1a59855fd502caed325d4a324f)
|
|
(cherry picked from commit d14d494dcda3d80ec2cf452551c680ffb432e306)
|
|
|
|
#19390)
|
|
|
|
|
|
The max texture coord units is still 8. All the fixed-function paths are
still limited to 8 too. But GLSL shaders can use more samplers now.
Note that some texcoord-related data structures are declared to be 16
elements in size rather than 8. This just simplifies the code in a few
places; the extra elements aren't accessible to the user.
These changes haven't been extensively tested yet, but sanity checking has
been done.
It should be possible to increase the max image units/samplers to 32 without
doing anything special. Beyond that we'll need longer bitfields in a few
places.
|
|
|
|
Previously 3D textures were mipmapped using multiple passed through
the 2D mipmap generation code. This had 3 disadvantages. First, the
extra passes were slow. Second, this required the allocation of a
temporary buffer to hold intermediate data. Third, and most
important, the extra passes caused loss of additional bits due to
integer division / bit-shifting.
With this change, our mipmapgen conformance test passes for
non-compressed texture formats.
|
|
|
|
|
|
Note how if:
x + width == xmax + 0: width -= 0
x + width == xmax + 1: width -= 0
x + width == xmax + 2: width -= 1
So, the function was clipping to [xmin, xmax+1), not [xmin, xmax) like it was
supposed to. Same for ymax.
|
|
The subsequent if/else cases always call _mesa_reference_fragprog() anyway.
|
|
|
|
|
|
It is possible for applications to specify any texture base level,
including trivially invalid values (i.e., 47000000). When an app
specifies an invalide base level, we should gracefully disable the
texture instead of accessing memory outside the gl_texture_object.
This fixes an occasional segfault in one of our conformance tests.
|
|
The ctx->Driver.GenerateMipmap() hook only expects cubemap face enums, not
CUBE_MAP_ARB, so walk all faces when we encounter that. Fixes oglconform
fbo.c segfault with both swrast and i965 drivers.
|
|
|
|
|
|
|
|
These arrays will indicate per-input or per-output options for vertex/fragment
programs such as centroid-sampling and invariance.
|
|
texture comparison logic is bypassed if the currently bound texture is not
a depth/depth_stencil texture.
|
|
This fixes glReadPixels(GL_LUMINANCE, GL_FLOAT)/glGetTexImage(GL_LUMINANCE, GL_FLOAT) issue
on fixed-point color buffers.
|
|
|
|
Dots is re-used if more than one light is enabled. Previously
the negate flag of dots may affect next light.
|
|
This fixes a lighting issue when drawing a bitmap.
|
|
|
|
than the python generators
Specifically:
#include "glapitable.h" in src/mesa/main/glapi/dispatch.h
Call _mesa_bsearch() in src/mesa/main/enums.c.
|
|
See bug 18445.
When getting array results, __glXReadReply() always reads a multiple of
four bytes. This can cause writing to invalid memory when 'n' is not a
multiple of four.
Special-case the glAreTexturesResident() functions now.
To fix the bug, we use a temporary buffer that's a multiple of four bytes
in length.
NOTE: this commit also reverts part of commit 919ec22ecf72aa163e1b97d8c7381002131ed32c
(glx/x11: Added some #ifdef GLX_DIRECT_RENDERING protection) which
directly edited the indirect.c file rather than the python generator!
I'm not repairing that issue at this time.
|
|
|
|
|
|
|
|
|
|
|
|
The texImage->Width/Height fields will have the post-convolution width/height.
|
|
Do it after initial error checking, after we know the texture's internal format.
|
|
|
|
Makes things consistant with the code in teximage.c.
We only want to apply convolution to color formats (not depth/index formats)
|
|
|
|
If we shift bytes into the texel word (or use the PACK_COLOR_8888 macro),
we don't have to worry about big vs. little endian. See comments about
texel formats in texformat.h.
Remove an unneeded/incorrect else-if clause that produced wrong results
on big-endian systems.
|
|
|
|
|
|
|
|
|
|
|
|
|
