On Lollipop, apparently stlport is gone and libcxx must be used instead.
We still support stlport when building on earlier android releases.
Signed-off-by: Chih-Wei Huang <cwhuang@linux.org.tw>
Reviewed-by: Eric Anholt <eric@anholt.net>
Based on the nice work of Paulo Sergio Travaglia <pstglia@gmail.com>.
The main modifications are:
- Include paths for LLVM header files and shared/static libraries
- Set C++ flag "c++11" to avoid compiling errors on LLVM header files
- Set defines for LLVM
- Add GALLIVM source files
- Changes path of libelf library for lollipop
Signed-off-by: Chih-Wei Huang <cwhuang@linux.org.tw>
Acked-by: Eric Anholt <eric@anholt.net>
Use the pre-defined macro es-gen to generate new added files
instead of writing new rules manually. The handmade rules
that may generate the files before the directory is created
result in such an error:
/bin/bash: out/target/product/x86/gen/STATIC_LIBRARIES/libmesa_st_mesa_intermediates/main/format_pack.c: No such file or directory
make: *** [out/target/product/x86/gen/STATIC_LIBRARIES/libmesa_st_mesa_intermediates/main/format_pack.c] Error 1
Signed-off-by: Chih-Wei Huang <cwhuang@linux.org.tw>
Reviewed-by: Eric Anholt <eric@anholt.net>
This avoids needing hardlinks between all of the DRI driver .so names,
since we're the only loader on the system.
v2: Add early exit on success (like previous block) and log message on
failure.
Signed-off-by: Chih-Wei Huang <cwhuang@linux.org.tw>
Reviewed-by: Eric Anholt <eric@anholt.net>
The Android gallium build used to use gallium_egl, which was removed back
in March. Instead, we will now use a normal Mesa libEGL loader with
dlopen()ing of a DRI module.
v2: add a clean step to rebuild all dri modules properly.
v3: Squish the 2 patches doing this together (change by anholt).
Signed-off-by: Chih-Wei Huang <cwhuang@linux.org.tw>
Reviewed-by: Eric Anholt <eric@anholt.net>
This single .so includes all of the enabled gallium drivers.
Signed-off-by: Chih-Wei Huang <cwhuang@linux.org.tw>
Reviewed-by: Eric Anholt <eric@anholt.net>
The include paths of libmesa_dri_common are also used by modules
that need libmesa_dri_common.
Signed-off-by: Chih-Wei Huang <cwhuang@linux.org.tw>
Reviewed-by: Eric Anholt <eric@anholt.net>
Previously the number needed to be divided by 4 to get the proper results. Now
the hardware does the right thing. Through experimentation it seems Braswell
(CHV) does also need the division by 4.
Fixes piglit test:
arb_pipeline_statistics_query-frag
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Previously, we just put the message for the EOT send as high in the file as
it would go. This is because the register pre-filling hardware will stop
all over the early registers in the file in preparation for the next thread
while you're still sending the last message. However, if something happens
to spill, then the MRF hack interferes with the EOT send message and, if
things aren't scheduled nicely, will stomp on it.
Cc: "10.5 10.6" <mesa-stable@lists.freedesktop.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90520
Reviewed-by: Neil Roberts <neil@linux.intel.com>
The explicit call to fs_builder::group() in emit_single_fb_write() is
required by the builder (otherwise the assertion in fs_builder::emit()
would fail) because the subsequent LOAD_PAYLOAD and FB_WRITE
instructions are in some cases emitted with a non-native execution
width. The previous code would always use the channel enables for the
first quarter, which is dubious but probably worked in practice
because FB writes are never emitted inside non-uniform control flow
and we don't pass the kill-pixel mask via predication in the cases
where we have to fall-back to SIMD8 writes.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Yes, it's incorrect to use the 0-th channel enable group
unconditionally without considering the execution and regioning
controls of the instruction that uses the spilled value, but it
matches the previous behaviour exactly, the builder just makes the
preexisting problem more obvious because emitting an instruction of
non-native SIMD width without having called .group() or .exec_all()
explicitly would have led to an assertion failure.
I'll fix the problem in a follow-up series, as the solution is going
to be non-trivial.
Reviewed-by: Matt Turner <mattst88@gmail.com>
This simplifies opt_peephole_sel() slightly by emitting the SEL
instructions immediately after they are created, what makes the
sel_inst and mov_imm_inst arrays unnecessary and will make it possible
to get rid of the explicit inserts when the pass is migrated to the IR
builder.
Reviewed-by: Matt Turner <mattst88@gmail.com>
LOAD_PAYLOAD instructions need the same treatment as any other
generator instructions, at least FB writes and typed surface messages
will need a payload built with non-zero execution controls.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Most of these fields affect the behaviour of the instruction, but
apparently we currently don't CSE the kind of instructions for which
these fields could make a difference in the VEC4 back-end. That's
likely to change soon though when we start using send-from-GRF for
texture sampling and surface access messages.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Most of these fields affect the behaviour of the instruction so it
could actually break the program if we CSE a pair of otherwise
matching instructions with different values of these fields.
Reviewed-by: Matt Turner <mattst88@gmail.com>
