Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
A Tale of Two Samsungs: ARM vs. Qualcomm in Android Graphics (medium.com/afd_icl)
14 points by gregorymichael on Jan 17, 2018 | hide | past | favorite | 4 comments


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://rog.asus.com/forum/showthread.php?97715-GL553VD-Driv...


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.


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.


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: