diff options
author | Jacobo Aragunde Pérez <jaragunde@igalia.com> | 2019-08-27 11:04:27 +0200 |
---|---|---|
committer | Jacobo Aragunde Pérez <jaragunde@igalia.com> | 2019-08-30 11:40:14 +0000 |
commit | 01df7ca4100aa8913a5b33c9cc5d6b8b0f6c8e05 (patch) | |
tree | 654c219bae4ef1360bb1d99f0eb19de06abef72e /meta-html5-framework/recipes-wam/chromium/chromium68 | |
parent | d656495e536f0fefcbfde84599afd79b40aa3c88 (diff) |
chromium68: remove downstream backports
Bump revision to include:
* 3169198 [BACKPORT] skia: Build skcms with -mfp16-format=ieee on GCC ARM builds
* 6aa7e63 [BACKPORT] libavcodec: Remove dynamic relocs from h264idct_neon.S
These patches were being kept in the recipe, but there is no need for
that now.
Bug-AGL: SPEC-2506
Bug-AGL: SPEC-2514
Change-Id: I7dcd221c7f4fc179f2e686c8cc4eb619917ad9ab
Signed-off-by: Jacobo Aragunde Pérez <jaragunde@igalia.com>
(cherry picked from commit ca764441c712804d00562f838a4ef00c881750e9)
Diffstat (limited to 'meta-html5-framework/recipes-wam/chromium/chromium68')
2 files changed, 0 insertions, 167 deletions
diff --git a/meta-html5-framework/recipes-wam/chromium/chromium68/0001-libavcodec-Remove-dynamic-relocs-from-h264idct_neon..patch b/meta-html5-framework/recipes-wam/chromium/chromium68/0001-libavcodec-Remove-dynamic-relocs-from-h264idct_neon..patch deleted file mode 100644 index a522c771..00000000 --- a/meta-html5-framework/recipes-wam/chromium/chromium68/0001-libavcodec-Remove-dynamic-relocs-from-h264idct_neon..patch +++ /dev/null @@ -1,107 +0,0 @@ -From 67e9e0337185f05a0d8d362473e63d8a9dfdebed Mon Sep 17 00:00:00 2001 -From: Manoj Gupta <manojgupta@google.com> -Date: Thu, 27 Dec 2018 11:06:26 -0800 -Subject: [PATCH] libavcodec: Remove dynamic relocs from h264idct_neon.S - -Some of the assembly functions e.g. ff_h264_idct_dc_add_neon -has code like: - movrel x14, X(ff_h264_idct_add_neon) - -Linker cannot resolve them fully at link time and emits GOT -relocations. -Use explicit labels instead so that no dynamic relocations are -needed at all. - -BUG=chromium:917919 -TEST=lld complains are fixed. - -Change-Id: Ie533a10aab1fe3834300599ce650d3673a674f4e -Reviewed-on: https://chromium-review.googlesource.com/c/1390286 -Reviewed-by: Frank Liberato <liberato@chromium.org> ---- - libavcodec/aarch64/h264idct_neon.S | 20 ++++++++++++-------- - 1 file changed, 12 insertions(+), 8 deletions(-) - -diff --git a/src/third_party/ffmpeg/libavcodec/aarch64/h264idct_neon.S b/src/third_party/ffmpeg/libavcodec/aarch64/h264idct_neon.S -index 825ec49f8c6d..7de44205d39a 100644 ---- a/src/third_party/ffmpeg/libavcodec/aarch64/h264idct_neon.S -+++ b/src/third_party/ffmpeg/libavcodec/aarch64/h264idct_neon.S -@@ -23,6 +23,7 @@ - #include "neon.S" - - function ff_h264_idct_add_neon, export=1 -+.L_ff_h264_idct_add_neon: - ld1 {v0.4H, v1.4H, v2.4H, v3.4H}, [x1] - sxtw x2, w2 - movi v30.8H, #0 -@@ -77,6 +78,7 @@ function ff_h264_idct_add_neon, export=1 - endfunc - - function ff_h264_idct_dc_add_neon, export=1 -+.L_ff_h264_idct_dc_add_neon: - sxtw x2, w2 - mov w3, #0 - ld1r {v2.8H}, [x1] -@@ -106,8 +108,8 @@ function ff_h264_idct_add16_neon, export=1 - mov w9, w3 // stride - movrel x7, scan8 - mov x10, #16 -- movrel x13, X(ff_h264_idct_dc_add_neon) -- movrel x14, X(ff_h264_idct_add_neon) -+ movrel x13, .L_ff_h264_idct_dc_add_neon -+ movrel x14, .L_ff_h264_idct_add_neon - 1: mov w2, w9 - ldrb w3, [x7], #1 - ldrsw x0, [x5], #4 -@@ -133,8 +135,8 @@ function ff_h264_idct_add16intra_neon, export=1 - mov w9, w3 // stride - movrel x7, scan8 - mov x10, #16 -- movrel x13, X(ff_h264_idct_dc_add_neon) -- movrel x14, X(ff_h264_idct_add_neon) -+ movrel x13, .L_ff_h264_idct_dc_add_neon -+ movrel x14, .L_ff_h264_idct_add_neon - 1: mov w2, w9 - ldrb w3, [x7], #1 - ldrsw x0, [x5], #4 -@@ -160,8 +162,8 @@ function ff_h264_idct_add8_neon, export=1 - add x5, x1, #16*4 // block_offset - add x9, x2, #16*32 // block - mov w19, w3 // stride -- movrel x13, X(ff_h264_idct_dc_add_neon) -- movrel x14, X(ff_h264_idct_add_neon) -+ movrel x13, .L_ff_h264_idct_dc_add_neon -+ movrel x14, .L_ff_h264_idct_add_neon - movrel x7, scan8, 16 - mov x10, #0 - mov x11, #16 -@@ -263,6 +265,7 @@ endfunc - .endm - - function ff_h264_idct8_add_neon, export=1 -+.L_ff_h264_idct8_add_neon: - movi v19.8H, #0 - sxtw x2, w2 - ld1 {v24.8H, v25.8H}, [x1] -@@ -326,6 +329,7 @@ function ff_h264_idct8_add_neon, export=1 - endfunc - - function ff_h264_idct8_dc_add_neon, export=1 -+.L_ff_h264_idct8_dc_add_neon: - mov w3, #0 - sxtw x2, w2 - ld1r {v31.8H}, [x1] -@@ -375,8 +379,8 @@ function ff_h264_idct8_add4_neon, export=1 - mov w2, w3 - movrel x7, scan8 - mov w10, #16 -- movrel x13, X(ff_h264_idct8_dc_add_neon) -- movrel x14, X(ff_h264_idct8_add_neon) -+ movrel x13, .L_ff_h264_idct8_dc_add_neon -+ movrel x14, .L_ff_h264_idct8_add_neon - 1: ldrb w9, [x7], #4 - ldrsw x0, [x5], #16 - ldrb w9, [x4, w9, UXTW] --- -2.21.0 - diff --git a/meta-html5-framework/recipes-wam/chromium/chromium68/0001-skia-Build-skcms-with-mfp16-format-ieee-on-GCC-ARM-b.patch b/meta-html5-framework/recipes-wam/chromium/chromium68/0001-skia-Build-skcms-with-mfp16-format-ieee-on-GCC-ARM-b.patch deleted file mode 100644 index 22f50266..00000000 --- a/meta-html5-framework/recipes-wam/chromium/chromium68/0001-skia-Build-skcms-with-mfp16-format-ieee-on-GCC-ARM-b.patch +++ /dev/null @@ -1,60 +0,0 @@ -From a01fb357a1ce755834779c905a14c3376e1a6239 Mon Sep 17 00:00:00 2001 -From: Raphael Kubo da Costa <raphael.kubo.da.costa@intel.com> -Date: Tue, 17 Jul 2018 11:56:52 +0000 -Subject: [PATCH] skia: Build skcms with -mfp16-format=ieee on GCC ARM builds - -skcms' Transform_inl.h assumes support for 16-bit floating point in the -__ARM_FP macro means the __fp16 (and corresponding SIMD data type) is -present. - -While this is currently true for LLVM, which always sets the equivalent of -GCC's -mfp16-format=ieee internally on ARM builds, GCC explicitly needs that -option to be specified in order to enable support for __fp16. Doing so -allows GCC ARM builds to proceed without the following error: - - ../../third_party/skia/third_party/skcms/src/Transform_inl.h: In function 'F_from_Half_': - ../../third_party/skia/third_party/skcms/src/Transform_inl.h:101:72: error: 'float16x4_t' undeclared (first use in this function); did you mean 'float32x4_t'? - SI ATTR F NS(F_from_Half_(U16 half)) { return vcvt_f32_f16((float16x4_t)half); } - ^~~~~~~~~~~ - float32x4_t - ../../third_party/skia/third_party/skcms/src/Transform_inl.h:101:72: note: each undeclared identifier is reported only once for each function it appears in - ../../third_party/skia/third_party/skcms/src/Transform_inl.h:101:84: error: expected ')' before 'half' - SI ATTR F NS(F_from_Half_(U16 half)) { return vcvt_f32_f16((float16x4_t)half); } - ^~~~ - ) - ../../third_party/skia/third_party/skcms/src/Transform_inl.h: In function 'Half_from_F_': - ../../third_party/skia/third_party/skcms/src/Transform_inl.h:102:5: error: can't convert a value of type 'int' to vector type '__vector(4) short unsigned int' which has different size - SI ATTR U16 NS(Half_from_F_(F f)) { return (U16)vcvt_f16_f32( f); } - ^~ - -Bug: 819294 -Change-Id: Ib7417fb9bdc6bd93553084053ba69f9d3409b112 -Reviewed-on: https://chromium-review.googlesource.com/1138251 -Reviewed-by: Florin Malita <fmalita@chromium.org> -Commit-Queue: Raphael Kubo da Costa (CET) <raphael.kubo.da.costa@intel.com> -Cr-Commit-Position: refs/heads/master@{#575608} ---- - src/skia/BUILD.gn | 7 +++++++ - 1 file changed, 7 insertions(+) - -diff --git a/src/skia/BUILD.gn b/src/skia/BUILD.gn -index 294b9ac16..6efada326 100644 ---- a/src/skia/BUILD.gn -+++ b/src/skia/BUILD.gn -@@ -242,6 +242,13 @@ source_set("skcms") { - ] - } - -+ # LLVM automatically sets the equivalent of GCC's -mfp16-format=ieee on ARM -+ # builds by default, while GCC itself does not. We need it to enable support -+ # for half-precision floating point data types used by SKCMS on ARM. -+ if (is_linux && !is_clang && current_cpu == "arm") { -+ cflags += [ "-mfp16-format=ieee" ] -+ } -+ - public = [ - "//third_party/skia/third_party/skcms/skcms.h", - ] --- -2.11.0 - |