When we concatenate shaders to do our form of poor-man linking, if there's
multiple #version directives, preprocessing fails. This change disables
the extra #version directives by changing the first two chars to //.
This should help with some Wine issues such as bug 23946.
1D tile span support for depth/stencil/color/textures
Z and stencil buffers are always tiled, so this fixes
sw access to Z and stencil buffers. color and textures
are currently linear, but this adds span support when we
implement 1D tiling.
This fixes the text in progs/demos/engine and progs/tests/z*
This fixes the compilation errors reported in bug 23945 but someone more
familiar with the code should review for correctness and close the bug
report.
Should be easier to read and work with than the older ways of emitting
TGSI tokens.
Also, emit simpler TGSI than previously:
- translate away source and dest extended modifiers
- translate away the SWZ opcode
Src/Dst aliasing (aka SOA dependencies) requires some care to ensure
intermediate results do not overwrite yet-to-be read source registers.
This change ensures that MOV/SWZ handle this correctly, which is poor but
no worse than the current tgsi_exec.c path. Remove the fallback as there
is nothing to be gained correctness-wise between the two implementations now.
Fixing this properly looks like a bit of work in this code, but might be
easily achieved by sending destination writes to temporary storage.
Previously ureg would always call the driver's create-shader function. This
allows the caller the opportunity to hold onto the tokens if it needs to
reuse them, eg. to create an internal draw shader.
Unless we're cross compiling, the HOST_CFLAGS should be the same as the
normal CFLAGS. This allows the x86 and x86_64 asm to be built correctly
with a native compiler using -m32/-m64.
Signed-off-by: Dan Nicholson <dbn.lists@gmail.com>
Individual texture images have a stride, but textures as a whole do not.
There are still pieces of code which are confused about this, but the core of
the confusion is hopefully gone.
Signed-off-by: Nicolai Hähnle <nhaehnle@gmail.com>
Previously, it was trying to mess around with the varying's
WM setup data to produce a result. Along with not actually working when
passed a varying, this wouldn't work if you did dFd[xy]() on a temporary.
Instead, just calculate the derivative using the neighbors in the subspan.
