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 555f0a8818
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 seems the code that set up the FB_WRITE message was incomplete in this
case. The number of payload registers was wrong and that caused a hang.
It would be good to have a second set of eyes take a look at this...
This was used to handle both variable declarations and references to variables.
Instead, just do storage allocation and assignment for declarations and
references, respectively.
This is a step toward better var/uniform allocation (only allocate storage
for vars/uniforms that are actually referenced by the code).
