This is a quick-fix for the time being...
The per-face mipmap LOD computation was invalid at cube edges. In
mip_filter_nearest/linear() we were trying to compute LOD using
texcoords that were sometimes indexes into different cube faces.
The subtraction used to compute the partial derivatives basically
gave random values, so the LOD was unpredictable. This fix simply
uses the same cube face for all four pixels in the quad. The per-
face texcoords all reference the same cube face so the partial
deriviates are computed properly.
A more elaborate fix would involve computing the LOD at the same
time as we choose the cube faces. But for now, this solution works
well and allows the piglit/cubemap test to pass.
(cherry picked from commit 1ff9cd5079)
For GL_ARB_fragment_coord_conventions.
This only applies to gl_FragCoord and controls pixel center origin and
pixel center integer. For example:
layout (origin_upper_left, pixel_center_integer) varying vec4 gl_FragCoord;
This features introduces the idea of re-declaring variables with a changed
type. This may also apply to arrays in some cases but that's not
implemented at this time.
This fixes invalid calls to rastpos_point/line/tri() that can occur
when glRasterPos() is called while in feedback or selection mode.
(cherry picked from commit b3c7dc6ff2)
When our DLL is unloaded, even if we leave the data structures in memory
for sake of future calls, the MS CRT will destroy the heap. Instead we
make all calls no-ops by setting stw_dev to NULL.
Don't use pipe->draw_range_elements() if min_index=max_index=~0 since
that doesn't provide any useful info.
Also, implement the loop around pipe->draw_range_elements() when
nr_prims > 1.
we actually need to specify the formats for different attachements, otherwise
if the color buffer is 24bpp and the app asks for 16bpp depth buffer than
we end up fetching the depth from the drawable which is 24bpp and end up
creating the wrong depth buffer. use the new getBuffersWithFormat extension
to pass the depth correctly.
