[Development] QtWebEngine on x86 without SSE2
Allan Sandfeld Jensen
kde at carewolf.com
Wed Jan 20 18:09:24 CET 2016
On Wednesday 20 January 2016, Kevin Kofler wrote:
> distribution packagers may be interested in this experimental patch:
> e-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:
> 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.
We made the same decision in Qt to not use X86 without SSE2 by default.
That it is linux only also doesn't bother me, SSE2 are already a hard
requirements for the OSX and Windows platforms we support. This is really only
an issue for Linux distros that have outdated minimum requirements.
Of course it might be might be easier to keep it as a distro patch only since
it looks like an original chromium patch ported to qtwebengine.
More information about the Development