The es1, es2 and gl state trackers include draw_pipe.h, which includes
the llvm headers if MESA_LLVM is true, so we also need to add the
llvm seachpaths.
Similarly, gallivm and other gallium drivers need LLVM_CFLAGS to build when enabled.
Also fix xorg drivers, they didn't include LDFLAGS.
Writing a compiler is time consuming and error prone in
order to allow r600g to further progress in the meantime
i wrote a simple tgsi assembler, it does stupid thing but
i would rather keep the code simple than having people
trying to optimize code it does.
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
If we bias x,y we still need to pass through z,w in case the shader
reads gl_FragCoord.z or .w.
Fixes fd.o bug 29183 (piglit glsl-bug-22603).
NOTE: This is a candidate for the 7.8 branch.
Also move some initialization from screen init to pre-init, now
that it is possible.
Also import a new vmwgfx drm (1.3) header.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
This makes it possible to prune modes already in pre-init.
We also keep these resources alive across server generations, and
they are implicitly closed on server exit.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Add a customizer callback just before initial config setting, so that the
customizer code can initialize the mode validator using the drm
file-descriptor.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
This has confused me twice now. It's a fixed width of 4 (usually a
region description of <4,4,1>), not 1. If it was 1, we'd have been
skipping all over register space.
The ARL value is increments of vec4 in the register file. But
PROGRAM_TEMPORARY or PROGRAM_INPUT are stored as vec4s interleaved
between the two verts being executed (thus a vec8 each), compared to
PROGRAM_STATE_VAR being packed vec4s.
Fixes:
glsl-vs-arrays-2
glsl-vs-mov-after-deref
(without regressing glsl-vs-arrays-3)
Otherwise, the second half isn't written, and we end up reading back
black.
Fixes the remaining junk drawn in glsl-max-varyings, and will likely
help with a number of large real-world shaders.
They go into the render cache, so while we don't care about their
contents after execution, failing to note them could cause the writes
to be flushed over important buffer contents later.
Vinson Lee