Sobre el tearing:
https://www.raspberrypi.org/forums/view ... p?t=246291El tal jamesh, ingeniero y moderador, dijo en marzo esto:
We currently do not know how to fix it, and are actually quite busy in some other areas.
En abril le comentaron que desactivando el Compositor la cosa mejoraba (aunque no soluciona), a lo que añadió:
Interesting. We've not had time to investigate the tearing yet, but this is a good pointer. Thanks!
... y ya a finales de agosto ha dicho lo siguiente:
If we knew how to fix it easily it would already be fixed. It's not as simple as "sync updates to vsync".
We are spending most dev time in this area on the KMS driver, which should work fine in this respect. Fixing the older legacy stuff would be a waste at this stage.
Sobre soporte para Vulkan...
En julio ya
se mostró funcionando, aunque se comentaba que todos los esfuerzos están siendo dedicados a que funcione como debe, no que sea rápido. Cuando esto ocurra, ya se meterán en optimizaciones:
Right now our main focus for the driver is working on features, targetting a compliant Vulkan 1.0 driver. Having said so, now that we both support a good range of features and can run non-basic applications, we have devoted some time to analyze if there were clear points where we could improve the performance. Among these we implemented:
1. A buffer object (BO) cache: internally we are allocating and freeing really often buffer objects for basically the same tasks, so there are a constant need of buffers of the same size. Such allocation/free require a DRM call, so we implemented a BO cache (based on the existing for the OpenGL driver) so freed BOs would be added to a cache, and reused if a new BO is allocated with the same size.
2. New code paths for buffer to image copies.
Y así está la cosa. Todo a medias... Por su parte RetroPie parece que se está
actualizando a 64 bits, lo cual le dará un empujoncito al rendimiento también, pero no se cuanto tardarán. Según BuZz, Administrador del sitio, puede haber algunos problemas y habrá que trabajar en ello:
Some emulators could also run slower. Although ones that may already be full speed. Due to having Arm 32bit neon optimisations which can't be used without rewriting for aarch64.
Btw I saw the comment on the bugtracker. I've not yet gone through the experimental packages. I'm aware some stuff isn't working