[Development] QtWebEngine on x86 without SSE2

Kevin Kofler kevin.kofler at chello.at
Wed Jan 20 05:05:23 CET 2016


Hi,

distribution packagers may be interested in this experimental patch:
http://pkgs.fedoraproject.org/cgit/rpms/qt5-qtwebengine.git/tree/qtwebengine-opensource-src-5.6.0-beta-no-sse2.patch
which should make QtWebEngine work on 32-bit x86 (i686) CPUs without SSE2
(and also without MMX nor SSE 1), while detecting SSE2 (and SSE 1 and MMX)
at runtime wherever possible. V8 is built as a shared library, twice (once
with the x87 backend and once with the SSE2 one), and the GNU/Linux
ld.so feature where it will automatically look under an sse2 subdirectory of
the rpath for a SSE2-enabled library on SSE2 machines is taken advantage of.

The floating-point issues in the media player that made Chromium upstream
require SSE2 should already be worked around by this upstream commit:
https://crrev.com/d2c745b13c93ecff5108bed57d8e052126715492
so x87 should really be fine again. If not, the fix would be to build
individual parts of the code with -ffloat-store.

I verified that this builds on GNU/Linux on i686, on x86_64 (where SSE2 is
part of the baseline and can thus be assumed safely) and on ARM (where SSE2
does not exist at all and so the patch should have no effect). I have not
done runtime testing yet.

I did not try other platforms yet. The dual V8 trick will not work on
platforms that do not have the same ld.so SSE2 feature, and my code that
handles the V8 trick also hardcodes the .so extension. So you would probably
have to remove those parts and just live with x87 V8.

Unfortunately, since this is an override of a deliberate upstream Chromium
decision and partly a cumulative revert of several upstream Chromium
commits, I do not expect this to be accepted upstream, ever.

        Kevin Kofler




More information about the Development mailing list