env.CodeGenerate(
target = 'my_source.c',
script = 'my_generator.py',
source = ['input.txt', 'another.txt'],
command = 'python $SCRIPT $SOURCE > $TARGET'
)
It will take care generating all appropriate dependencies, including any
module imported by the generator script, and the respective .pyc file
side effects.
It's possible to call update_samplers() between the time a fragment shader
is bound and when a texture image is defined (such as glClear). This
fixes the case where we don't have a complete texture object yet.
Need to translate VERT_RESULT_PSIZ, BFC0, BFC1 to TGSI shader output slots
after all other attributes have been handled. This fixes a bug where
generic vertex program outputs (varying vars) could get mapped to the
same slot at point size or back-face colors.
If the 'shader' parameter is wrong, need to either generate GL_INVALID_VALUE
or GL_INVALID_OPERATION. It depends on whether 'shader' actually names a
'program' or is a totally unknown ID.
There might be other cases to fix...
cherry-picked from master
If the 'shader' parameter is wrong, need to either generate GL_INVALID_VALUE
or GL_INVALID_OPERATION. It depends on whether 'shader' actually names a
'program' or is a totally unknown ID.
There might be other cases to fix...
We have something similar in the X Server that covers X Server rendering, this
is the equivalent here for rendering to the front buffer. If we cared about
avoiding this at glFlush time, we could only do this when some actual
frontbuffer rendering had occurred.
Bug #16392.
The boolean that the server gives us for whether the region is tiled was
getting used as the enum for what tiling mode. Instead, guess the correct
tiling in screen setup.
Also, fix the Y-tiling pitch setup. The pitch to the next tile in Y is
32 scanlines, not 8.
This fixes a failure for cases like:
vec4 v;
v[1] *= 2.0;
The v[1] actually acts like a writemask, equivalent to v.y
The fix is a bit convoluted, but will do for now.
cherry-picked from master
This fixes a failure for cases like:
vec4 v;
v[1] *= 2.0;
The v[1] actually acts like a writemask, equivalent to v.y
The fix is a bit convoluted, but will do for now.
