Il reste que le protocol X (Xlib ou Xcb) est toujours serialise dans une socket. Ok, il y a moins de requete dedans, si on n'utilise pas Xrender, mais ca n'empeche que le cout de la serialisation dans un socket est la. Une amelioration simple serait d'utiliser un buffer shm pour communiquer avec X et de n'envoyer dans la socket que l'index ou commence dans le buffer shm de la serie de commande X. Cela serait plus efficace a mon avis pour les communications locales. Je me demande d'ailleur, comment est implementer cette partie la du protocol Wayland, je crois que ca passe tout dans la socket.
Hmm, actuellement, les buffers ne sont pas copiés dans le cas de DRI2 et, pour les applis 2D, à priori, ils utilisent xshm. Ça permet de référencer/partager des buffers sans les copier. Dans Wayland, le même protocole existe (c'est même le seul chemin autorisé) et il ne faut pas espérer quel que soit d'autre.
le backend soft comprend le format du GPU
Ah ah, très très mauvaise idée :D Déjà, toute la VRAM n'est pas accessible au CPU. De deux, il y a des tonnes de formats de tilling et de compression. C'est chercher la merde que d'essayer de faire un accès CPU dessus. Et pour finir, c'est lent! Il vaut mieux utiliser les moteurs de copies asynchrones proposés par le GPU.
Tout ça pour dire, si tu fais un rendu CPU, y'a pas de problèmes, faut juste le faire des un BO référencé par la GART et il sera uploadé en VRAM par le compositeur si nécessaire.
[^] # Re: Compiz ne migrera pas vers Wayland
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Petites brèves autour de Wayland. Évalué à 9. Dernière modification le 15 janvier 2013 à 12:11.
Hmm, actuellement, les buffers ne sont pas copiés dans le cas de DRI2 et, pour les applis 2D, à priori, ils utilisent xshm. Ça permet de référencer/partager des buffers sans les copier. Dans Wayland, le même protocole existe (c'est même le seul chemin autorisé) et il ne faut pas espérer quel que soit d'autre.
Ah ah, très très mauvaise idée :D Déjà, toute la VRAM n'est pas accessible au CPU. De deux, il y a des tonnes de formats de tilling et de compression. C'est chercher la merde que d'essayer de faire un accès CPU dessus. Et pour finir, c'est lent! Il vaut mieux utiliser les moteurs de copies asynchrones proposés par le GPU.
Tout ça pour dire, si tu fais un rendu CPU, y'a pas de problèmes, faut juste le faire des un BO référencé par la GART et il sera uploadé en VRAM par le compositeur si nécessaire.