Commit graph

9 commits

Author SHA1 Message Date
Mauro Rossi
3341429d74 android: broadcom/genxml: fix collision with intel/genxml header-gen macro
Fixes the following building error, happening when building both intel and broadcom:

Gen Header: libmesa_broadcom_genxml_32 <= v3d_packet_v21_pack.h
FAILED: gen/STATIC_LIBRARIES/libmesa_broadcom_genxml_intermediates/broadcom/cle/v3d_packet_v21_pack.h
/bin/bash -c "python external/mesa/src/broadcom/cle/gen_pack_header.py \
external/mesa/src/broadcom/cle/v3d_packet_v21.xml \
> gen/STATIC_LIBRARIES/libmesa_broadcom_genxml_intermediates/broadcom/cle/v3d_packet_v21_pack.h"
Traceback (most recent call last):
  File "external/mesa/src/broadcom/cle/gen_pack_header.py", line 626, in <module>
    p = Parser(sys.argv[2])
IndexError: list index out of range

header-gen macro is already defined by Intel genxml building rules
and the existing header-gen does not have the $(PRIVATE_VER) argument,
infact the bash command line logged in the building error is missing
exactly $(PRIVATE_VER) argument

Renaming the macro as pack-header-gen in src/broadcom/Android.genxml.mk
solves the building error, another possible way is to keep the gen rules
commands expanded and not use the macros.

Fixes: 7f80a9ff13 ("vc4: Introduce XML-based packet header generation like Intel's.")
Cc: "18.2" <mesa-stable@lists.freedesktop.org>
Acked-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Signed-off-by: Mauro Rossi <issor.oruam@gmail.com>
2018-09-15 09:14:33 +02:00
Eric Anholt
38172dcba9 v3d: Merge the V3D 4.1 and 4.2 XML into V3D 3.3'x XML.
The XML ends up noisier if you're only looking at one version, but from
the diffstat there's obvious wins in terms of deduplication.  This will
get even more significant if we ever support 3.2 or 4.0.
2018-06-29 13:36:28 -07:00
Eric Anholt
6f7ad7ed11 v3d: Pass the version being generated to the pack generator script.
It turns out that most V3D versions change very few packets, so keeping
separate copies of the XML per version makes changing the XML a pain as
you have to replicate your changes to each one.  This is the start of
changing it so that one XML can generate headers for multiple versions.
2018-06-29 13:36:28 -07:00
Eric Anholt
96d3e8f134 broadcom/vc5: Add XML for V3D 4.2. 2018-01-27 18:57:58 +11:00
Eric Anholt
de60ea4432 Android: Attempt to fix broadcom build after vc5 changes. 2018-01-27 18:03:58 +11:00
Eric Anholt
a727e03360 broadcom/genxml: Add V3D 3.3 packet definitions.
This will be used by the new vc5 gallium driver, and a future Vulkan
driver.
2017-08-18 12:54:13 -07:00
Eric Anholt
5b102160ae broadcom/genxml: Introduce a V3D packet/struct decoder.
This is copied from Intel's XML decoder, modified to handle V3D's
byte-oriented packets.

v2: Squash in robher's fixes for Android
2017-07-25 14:44:52 -07:00
Rob Herring
7a7a84c8db Android: Fix vc4 build since XML changes.
Since commit 7f80a9ff13 ("vc4: Introduce XML-based packet header
generation like Intel's."), the vc4 build on Android is broken:

out/target/product/linaro_x86_64/gen/STATIC_LIBRARIES/libmesa_broadcom_genxml_intermediates/broadcom/cle/v3d_packet_v21_pack.h:12:10: fatal error: 'v3d_packet_helpers.h' file not found
external/mesa3d/src/gallium/drivers/vc4/vc4_cl_dump.c:28:10: fatal error: 'vc4_packet.h' file not found

The path of the generated header needs to be fixed since we build out of
tree.

Acked-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Rob Herring <robh@kernel.org>
2017-07-12 16:47:10 -05:00
Eric Anholt
7f80a9ff13 vc4: Introduce XML-based packet header generation like Intel's.
I really liked this idea, as it should help with management of packet
parsing tools like the CL dump.  The python script is forked off of theirs
because our packets are byte-based instead of dwords, and the changes to
do so while avoiding performance regressions due to unaligned accesses
were quite invasive.

v2: Fix Android.mk paths, drop shebang for python script, fix overlap
    detection.

Acked-by: Jason Ekstrand <jason@jlekstrand.net>
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
Tested-by: Rob Herring <robh@kernel.org>
2017-06-30 12:25:45 -07:00