This repository has been archived by the owner on Jan 7, 2023. It is now read-only.
Building enhancement #115
Closed
Building enhancement #115
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Tapani Pälli <[email protected]> Reviewed-by: Jordan Justen <[email protected]> (cherry picked from commit a3c366c)
Otherwise with VNDK enabled we fail linking: src/gallium/targets/dri/Android.mk: error: gallium_dri (native:vendor) should not link to libbacktrace.vendor (native:vndk_private) Option makes it possible to use libbacktrace only when VNDK is not enabled. Signed-off-by: Tapani Pälli <[email protected]> Reviewed-by: Jordan Justen <[email protected]> (cherry picked from commit 5e52184)
Some of the header file locations are changed between Android versions (when VNDK is used), patch makes sure we get all the required headers. v2: cleanups, put SDK version checks in all places (Tapani) Signed-off-by: Tapani Pälli <[email protected]> Signed-off-by: Chen Lin Z <[email protected]> Tested-by: Clayton Craft <[email protected]> Acked-by: Eric Engestrom <[email protected]> (cherry picked from commit 791198a)
In Android O, MESA needs to statically link libexpat so that it's in same VNDK namespace. v2: apply change also to anv driver (Tapani) v3: use += in anv change (Eric Engestrom) Change-Id: I82b0be5c817c21e734dfdf5bfb6a9aa1d414ab33 Signed-off-by: Kishore Kadiyala <[email protected]> Signed-off-by: Tapani Pälli <[email protected]> Reviewed-by: Eric Engestrom <[email protected]> (cherry picked from commit e1d8057)
Signed-off-by: Qiming Shi <[email protected]> Signed-off-by: Mingwei Wang <[email protected]> Signed-off-by: jenny.q.cao <[email protected]> Signed-off-by: Kishore Kadiyala <[email protected]> Signed-off-by: Chen Lin Z <[email protected]>
Improves performance of graphics tests significantly. Signed-off-by: Yogesh Marathe <[email protected]> Acked-by: Tapani Pälli <[email protected]>
The HWC Vulkan backend needs to be able to sample from source images, so for
now enable that for all users of vkCreateDmaBufImageINTEL. We can revert
this patch once we land support for VK_MESAX_external_image_dma_buf, which
allows the application to fill the 'usage' field.
Jira: IAHWC-40
Test: Enable Vulkan backend of IA-Hardware-Composer and try kmscube.
The cube should be visible and animated, but at this time there is
severe flickering.
Signed-off-by: Kevin Strasser <[email protected]>
Acked-by: Tapani Pälli <[email protected]>
UPSTREAM: nir: add option to use scaling factor when sampling planes YUV lowering Patch adds nir_lower_tex_options as parameter to sample_plane so that we don't need to extend nir_tex_instr for this. Signed-off-by: Tapani Pälli <[email protected]> Reviewed-by: Lionel Landwerlin <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]> (cherry picked from commit 19a85a7) UPSTREAM: dri: add P010, P012, P016 for 10bit/12bit/16bit YUV420 formats Signed-off-by: Tapani Pälli <[email protected]> Signed-off-by: Lin Johnson <[email protected]> Reviewed-by: Lionel Landwerlin <[email protected]> (cherry picked from commit 722f96b) UPSTREAM: intel/compiler: add scale_factors to sampler_prog_key_data Patch propagates given scale_factors to lowering options. Signed-off-by: Tapani Pälli <[email protected]> Reviewed-by: Lionel Landwerlin <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]> (cherry picked from commit 3da858a) UPSTREAM: i965: add P0x formats and propagate required scaling factors Signed-off-by: Tapani Pälli <[email protected]> Signed-off-by: Lin Johnson <[email protected]> Reviewed-by: Lionel Landwerlin <[email protected]> (cherry picked from commit 2a2e69f) UPSTREAM: i965: remove scaling factors from P010, P012 Patch removes scaling factors introduced in 2a2e69f but leaves option to use scaling in place as it could be useful with other upcoming YUV formats. We did this scaling because ffmpeg was shifting channel bits down, however it seems this is not the right place as compositor wants to flip same buffers directly to display as well and therefore bitshifting needs to be done by the client when receiving frame from ffmpeg. Now P0x formats are treated the same, e.g. P010 is same as P016 but with lower 6 bits set to zeros. Fixes: 2a2e69f "i965: add P0x formats and propagate required scaling factors" Signed-off-by: Tapani Pälli <[email protected]> Reviewed-by: Lionel Landwerlin <[email protected]> (cherry picked from commit 3b41175)
Add those definition in dri2_interface.h and in intel_screen.c This will make P010 formats be sampleable in OpenGL Signed-off-by: Lin Johnson <[email protected]> [strassek: Paired down as much of the patch has gone upstream] Signed-off-by: Kevin Strasser <[email protected]>
This is needed in case we want to use mmap with dma-buf and write into the buffer in CPU side. This is useful when layers are rendered using software and we will either need to scan or texture from these layers. Check: https://patchwork.freedesktop.org/patch/56380/ Signed-off-by: Kalyan Kondapally <[email protected]>
…d termination EGL thread cleanup conformance tests could run out of memory as the contexts were not freed even though the application requested to have them deleted. This was caused by the fact that the contexts were still current on their threads when delete was called and (in order not to block any potential pending renders) they were just marked for delete. Fix this by calling eglReleaseThread on thread termination. This is safe to do even if this was already called by the application since, according to the EGL 1.5 spec, eglReleaseThread can be called multiple times without error. Fixes: dEQP-EGL.functional.thread_cleanup.multi_context_* dEQP-EGL.functional.robustness.create_context.query_robust_access
To avoid blocking other EGL calls, release the display mutex before calling update_buffers(), which will call droid_window_dequeue_buffer(). This patch fixes some failure cases in android graphics cts test. Signed-off-by: Min He <[email protected]> Signed-off-by: Chenglei Ren <[email protected]>
This fixes crash due to NULL window when swap interval is set for pbuffer surface. Jira: 61995 Test: CtsDisplayTestCases pass Signed-off-by: samiuddi <[email protected]> (am from https://patchwork.freedesktop.org/patch/235697/)
Signed-off-by: Kalyan Kondapally <[email protected]>
GLSL ES 320 technically allows #line to have arbitrary expression trees
rather than integer literal constants, unlike the C and C++ preprocessor.
This is likely a completely unused feature that does not make sense.
However, Android irritatingly mandates this useless behavior, so this
patch implements a hack to try and support it.
We handle a single expression:
#line <line number expression>
but we avoid handling the double expression:
#line <line number expression> <source string expression>
because this is an ambiguous grammar. Instead, we handle the case that
wraps both in parenthesis, which is actually well defined:
#line (<line number expression>) (<source string expression>)
With this change following tests pass:
dEQP-GLES3.functional.shaders.preprocessor.builtin.line_expression_vertex
dEQP-GLES3.functional.shaders.preprocessor.builtin.line_expression_fragment
dEQP-GLES3.functional.shaders.preprocessor.builtin.line_and_file_expression_vertex
dEQP-GLES3.functional.shaders.preprocessor.builtin.line_and_file_expression_fragment
Signed-off-by: Tapani Pälli <[email protected]>
Signed-off-by: Kenneth Graunke <[email protected]>
BUG=b:33352633
BUG=b:33247335
TEST=affected tests passing on CTS 7.1_r1 sentry
Change-Id: I7afbbb386bd4a582e3f241014a83eaccad1d50d9
Reviewed-on: https://chromium-review.googlesource.com/427305
Tested-by: Haixia Shi <[email protected]>
Reviewed-by: Ilja H. Friedel <[email protected]>
Commit-Queue: Haixia Shi <[email protected]>
Trybot-Ready: Haixia Shi <[email protected]>
GPA requires a null renderer query which disables all rendering. This feels fairly at odds with the spirit of the INTEL_performance_query extension. Note: Considering the INTEL_blackhole_render implementation(https://www. khronos.org/registry/OpenGL/extensions/INTEL/INTEL_blackhole_render .txt, https://patchwork.freedesktop.org/series/40035/)need test case changes, and also need time to review in upstream, we keep this patch firstly for urgent project milestone. Test: Pass mdapi test_GfxDrv_DriverAcceptance test case GfxDrv_DriverAcceptanceQuery.GL_NULL_HARDWARE and has no reg issue Signed-off-by: Landwerlin, Lionel <[email protected]>
This change makes following test pass: dEQP-VK.api.info.device.extensions Originally-from: Tapani Pälli <[email protected]> Test: [CTS 9.0_r8] dEQP-VK.api.info.device.extensions Signed-off-by: Kevin Strasser <[email protected]>
(cover letter https://patchwork.freedesktop.org/series/51006/) FROMLIST: i965: SIMD32 heuristics debug flag Added a new DEBUG_HEUR32 flag to INTEL_DEBUG flags for enabling SIMD32 selection heuristics. (am from https://patchwork.freedesktop.org/patch/256764/) FROMLIST: i965: SIMD32 heuristics control data Added a new structure for holding SIMD32 heuristics control data. The control data itself will be fetched from drirc. (am from https://patchwork.freedesktop.org/patch/256806/) FROMLIST: i965: SIMD32 heuristics control data from drirc To be able to test the heuristics with different parameters, they can be controlled via environment variables through drirc. (am from https://patchwork.freedesktop.org/patch/256788/) FROMLIST: mesa: Helper functions for counting set bits in a mask (am from https://patchwork.freedesktop.org/patch/256765/) FROMLIST: i965/fs: Save the instruction count of each dispatch width The SIMD32 selection heuristics will use this information for deciding whether SIMD32 shaders should be used. (am from https://patchwork.freedesktop.org/patch/256793/) FROMLIST: i965/fs: SIMD32 selection heuristic based on grouped texture fetches The function goes through the compiled shader and checks how many grouped texture fetches there are. This is a simple heuristic which gets rid of most of the regressions when enabling SIMD32 shaders but still retains some of the benefits. (am from https://patchwork.freedesktop.org/patch/256798/) FROMLIST: i965/fs: Enable all SIMD32 heuristics There are three simple heuristics for SIMD32 shader enabling: - How many MRTs does the shader write into? - How many grouped texture fetches does the shader have? - How many instructions does the SIMD32 shader have compared to the SIMD16 shader? For testing purposes, the heuristics can be controlled via these environment variables: simd32_heuristic_mrt_check - Enables MRT write check - Default: true simd32_heuristic_max_mrts - How many MRT writes the heuristic allows - Default: 1 simd32_heuristic_grouped_check - Enables grouped texture fetch check - Default: true simd32_heuristic_grouped_sends - How many grouped texture fetches the heuristic allows - Default: 6 simd32_heuristic_inst_check - Enables SIMD32 vs. SIMD16 instruction count check - Default: true simd32_heuristic_inst_ratio - SIMD32 vs. SIMD16 instruction count ratio the heuristic allows - Default: 2.3 SIMD32 shaders will not be compiled also when SIMD16 compilation fails or spills. (am from https://patchwork.freedesktop.org/patch/256766/)
This is needed to be in agreement with spec requirements: KhronosGroup/OpenGL-API#46 Piers Daniell: "We discussed this in the OpenGL/ES working group meeting and agreed that eliminating unused elements from the interface block array is not desirable. There is no statement in the spec that this takes place and it would be highly implementation dependent if it happens. If the application has an "interface" in the shader they need to match up with the API it would be quite confusing to have the binding point get compacted. So the answer is no, the binding points aren't affected by unused elements in the interface block array." Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109532 Reported-By: Ilia Mirkin <[email protected]> Signed-off-by: Andrii Simiklit <[email protected]> TEST=[CTS 9.0r6} dEQP-GLES31.functional.ssbo.layout.random.all_per_block_buffers#18 (am from https://gitlab.freedesktop.org/mesa/mesa/merge_requests/332) Signed-off-by: Kevin Strasser <[email protected]>
…of ssbo/ubo This is needed to fix these tests: piglit.spec.arb_shader_storage_buffer_object.compiler.unused-array-element_frag piglit.spec.arb_shader_storage_buffer_object.compiler.unused-array-element_comp Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109532 Reported-By: Ilia Mirkin <[email protected]> Signed-off-by: Andrii Simiklit <[email protected]> TEST=[CTS 9.0r6} dEQP-GLES31.functional.ssbo.layout.random.all_per_block_buffers#18 (am from https://gitlab.freedesktop.org/mesa/mesa/merge_requests/332) Signed-off-by: Kevin Strasser <[email protected]>
… build The libmesa_anv_gen* modules require anv_extensions.h, patch makes sure it gets generated as a dependency before building them. Signed-off-by: Chenglei Ren <[email protected]> Reviewed-by: Tapani Pälli <[email protected]> Cc: <[email protected]> (cherry picked from commit 13b38ca)
The AOSP master build system has started to police the use of non-hermetic tools from the system PATH. The Mesa project was using xgettext and other tools which are not part of the standard Android host build tools, and are therefore not allowed. This ban is now being enforced. To work around this problem, introduce prebuilt-intermediates for xmlpool based on the current source tree. Bug: 116125577 Change-Id: Ica53192b4c5495550ce5d6b49510b5984cedd4be Signed-off-by: Alistair Strachan <[email protected]>
While building Android for dragonboards, the build fails since it can't find the generated file format_srgb.c. To work around this problem, introduce prebuilt-intermediates for format_srgb.c from the current source tree. Change-Id: I4c96e040f6b7c633ccf7f3b34c742a7fb6ee6592 Signed-off-by: Sumit Semwal <[email protected]>
…e files
commit 092675ffa035 ("mesa3d: dragonboards: add format_srgb.c
to prebuilts") overrides the list of locally generated source
files(LOCAL_GENERATED_SOURCES) and we run into following build
error:
external/mesa3d/src/util/xmlpool.h:103:10: fatal error: 'xmlpool/options.h' file not found
Currently in src/util/Android.mk, LOCAL_GENERATED_SOURCES list
is populated as -->
LOCAL_GENERATED_SOURCES := $(UTIL_GENERATED_SOURCES)
LOCAL_GENERATED_SOURCES += $(MESA_DRI_OPTIONS_H)
LOCAL_GENERATED_SOURCES := $(MESA_FORMAT_SRGB_C)
The last assignment ":=" effectively overrides the existing
LOCAL_GENERATED_SOURCES list including MESA_DRI_OPTIONS_H,
hence causing xmlpool/options.h file not found build error.
We fix the build by populating the LOCAL_GENERATED_SOURCES as:
LOCAL_GENERATED_SOURCES := $(UTIL_GENERATED_SOURCES)
LOCAL_GENERATED_SOURCES := $(MESA_DRI_OPTIONS_H)
LOCAL_GENERATED_SOURCES += $(MESA_FORMAT_SRGB_C)
As for UTIL_GENERATED_SOURCES, since AOSP master build system
has started to police the use of non-hermetic tools from the
system PATH, see commit 5e0738226596 ("Add prebuilt-intermediates
for xmlpool) for reference, it is highly unlikely that we are
going to use UTIL_GENERATED_SOURCES ever agin. So it is safe to
assume and keep overriding the list of those util generated
source files, at least for now.
Change-Id: I173037f9303c849533037ac0abd09faf9544ce80
Signed-off-by: Amit Pundir <[email protected]>
sysopenci
reviewed
May 31, 2019
|
The pre-built change is huge! I will try to sync with Android Guys, and add mako and other tool to Android building system, and check if we could wa the pre-built file issues. |
Agreed, I think it's going to be painful and I don't see the reasons why this is change is being made, it would be good if you can figure out reasons for this. |
|
Thanks @tpalli. As suggested by you, maybe 'binary driver' is a good idea for us. In fact, I just synced with AOSP guy, and he also accepted this. I will figure out how to add 'binary driver' to the tree. :) |
Please also ask about the reasoning here. I saw 'non-hermetic tools' mentioned in one of the commits, which does not seem to make sense. Ideally the driver should build as is. It's good for Chrome OS so there should not be reason why it's not good for Android. Have they discussed with Chrome folks about these changes? |
Hmm, it does introduce a number of possible issues for both developers and maintainers. i.e. if you want to try out a patch from upstream you will now have to always check if you need to regen these files. That being said, I don't necessarily want to stray too far from aosp, or treat mesa a special case. If there is any possibility of retaining the ability to auto-generate files for at least -eng builds I would prefer that. @renchenglei For now can you share the steps a maintainer would have to follow in order to generate and commit the intermediate files?
Do you mean prebuilding the driver and making it available somewhere, and having it just download/install during build? Again, that would make it difficult for developers trying to figure out how to actually make changes.
Maybe Google are doing more static analysis on native code in aosp. I'd like to hear the rationale on this too.
It'll be interesting to see how this gets resolved in ARC++. |
I agree but this would seem the easiest way to keep consistent with the upstream tree. We could also try creating a separate build target that only creates all the generated files and somehow create a Android compatible tree with that, not sure how feasible this is though. |
|
Thanks @tpalli and @strassek for the suggestion. It will be much better to generate the library. Then we would have one flag to trigger build with pre-built library(make flashfiles INTEL_PREBUILT=true -j8). For developers, we would follow the build rule as it is now. |
|
Something like this: |
|
Close this PR, as we have one much better on #119 |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Please don't merge this patch set. I put them here for discussion!
On latest Android, google has enhanced its build system. Currently we have many broken rules in mesa project, like implicit rules, using forbidden host tools, etc.
See internal Jira Ticket:
OAM-80644
OAM-80463
OAM-80307
Qiming help shared some of Google internal fix for those issue:
https://android-review.googlesource.com/c/platform/external/mesa3d/+/706190 (Part of merged on upstream)
https://android-review.googlesource.com/c/platform/external/mesa3d/+/720960 (Still not included)
https://android-review.googlesource.com/c/platform/external/mesa3d/+/761950 (Included as BSP diff)
https://android-review.googlesource.com/c/platform/external/mesa3d/+/761951 (Included in this patch set)
https://android-review.googlesource.com/c/platform/external/mesa3d/+/786337 (Included in this patch set)
https://android-review.googlesource.com/c/platform/external/mesa3d/+/858424 (Included in this patch set)
Besides above changes, we also encounter many building issue, which is related with python module not included. In previous, it will check and use host python module. But with the building enhancement, it is forbidden now. So many file generated during building will report python issue. I have checked the Google source(under external/mesa3d), they pre-generated those files and put them in source code.
This will be terrible for us, if we follow Google's method, we have to deal with those files everytime when we do rebase.
ImportError: No module named mako.template
ImportError: No module named _elementtree