
A Tale of Two Samsungs: ARM vs. Qualcomm in Android Graphics - gregorymichael
https://medium.com/@afd_icl/a-tale-of-two-samsungs-arm-vs-qualcomm-in-android-graphics-c1c6f1eef828
======
Const-me
Hopefully, the problem will go away by itself, at least partially, in a couple
of years with the transition from GLES to Vulkan. I never liked GL’s decision
to compile shaders at runtime. A bytecode like in Direct3D or OpenCL/Vulkan or
Metal works better not only because runtime costs, but also because a
standard, and presumably higher-quality, compiler.

> An unfortunate side-effect of this is that developers of less popular apps
> must work around driver bugs to make their apps work on consumer devices.

Happens all the time on PC, and yes I did workaround the bugs. Here’s a couple
of bugs users have encountered, one for old Intel, another one for new nVidia:

[https://stackoverflow.com/q/43399487/126995](https://stackoverflow.com/q/43399487/126995)

[https://rog.asus.com/forum/showthread.php?97715-GL553VD-
Driv...](https://rog.asus.com/forum/showthread.php?97715-GL553VD-Driver-Power-
State-Failure-while-playing-certain-games)

~~~
kimixa
The /vast/ majority of these bugs will be in the optimiser and codegen - not
in the frontend parser. The bytecode provided in vulkan (and d3d) won't really
help with that.

~~~
Const-me
D3D optimizes a lot before producing the byte code, see /O0 - /O3 fxc.exe
switches.

I don’t have much experience with spir-v but I’d expect something similar for
Vulkan & OpenCL.

------
ris
So I have to wonder if they have tried their test suite on Mesa's drivers,
specifically the driver for (Qualcomm) Adreno. This could be very beneficial
CI for Mesa.

