We're going to try to reorder the scalar ops of a vector instr
to accomodate swizzles that would otherwise require us to emit
to an additional TEMP first (like MOV R0.xy, R0.zx).
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>