SHM ne nécessite pas de copie en soit. C'est juste du partage de pages mémoire physiques. Du coup, je suis pas sûr de saisir ce que tu veux dire.
Vu que tu travailles plutot avec des GPU discret, la copie dont je parle se fait a coup de DMA dans ce cas la et est effectivement impossible a eviter sur ces GPU.
C'est assez étonnant d'entendre parler de SoC Intel car la mémoire est toujours séparée, tout comme le chipset et les deux sont toujours indispensable.
Hum, en fait, je n'ai jamais regarde en detail les i7 et i5 avec GPU integre, mais de ce que j'ai compris sur leur SoC, tu partage le meme controleur memoire. Certe tu dois negocier avec le GPU pour mapper la memoire dans l'adresse space du CPU. Mais cela devient directement accessible et ne genere pas de copie quand tu "unmap" ta memoire pour la rendre de nouveau utilisable par le GPU. Tu peux donc avoir ton rendu software qui va cycler sur un certain nombre de buffer directement utilisable par le GPU. Je n'ai pas travaille assez longtemps sur SoC Intel pour etre sur du comportement, mais sur SoC Qualcom et Samsung, tu as clairement ce comportement. Je soupsonne que c'est le cas pour toutes les SoC qui supporte Android.
Mais au fond, tu veux en venir où? Ce que tu proposes est sous optimal dans pratiquement tous les cas, et ne change rien dans d'autres (GPU avec mémoire partagée only).
C'est clairement sous optimal avec un GPU discret, donc il faut forcement garde le chemin avec xshm pour ce cas la. Pour les GPU a memoire partage, tu gagnes une copie memoire, ce qui a un impact direct sur les performances et se repercute principalement sur la consomation de la batterie (Le hard moderne tenant facilement les 60fps, c'est surtout la batterie qui montre les soucis de performance). Ce qui est logique, car toute operation que tu ne fais pas, ne consome pas de batterie :-) D'un point de vue difference, une stack X qui fait du xshm vs Android consomme plus de batterie aux environs de 30% (Mais ce chiffre dependra de ce que tu benchmark bienentendu).
C'est parfaitement possible de mixer le rendu logiciel et hardware. Cela dit, avoir une appli accélérée mais un compositeur software, ça me semble stupide. Tu as un cas en tête?
Parce que la majorite des drivers OpenGL ne sont pas capable de tenir un mois sans cracher en faisant du compositing ? Je n'ai besoin de basculer mon compositeur en OpenGL que lorsque je fais du multiscreen. Et j'economise aussi de la batterie a reste en soft quand je code, car au lieu de redessiner tout l'ecran, il ne met a jour qu'un tout petit coin. Mais vu que je fais souvent de l'OpenGL, c'est pas mal de pouvoir quand meme avoir ce cas qui marche… Et ca, c'est sur un desktop, sur une tablette ou un telephone, le cas se presente encore plus frequement (consomation eleve de memoire du au context OpenGL, switch de context entre le compositeur et l'appli qui n'est pas forcement un moment joyeux, …).
Sinon de nos jours, c'est les GPU discrets qui sont en "voit" de disparition face au GPU a memoire integre. Comparer le nombre de Linux dans un cas et dans l'autre est d'ailleur assez vite fait ! Plus d'un million sont active par jour avec une memoire partage… Et Wayland ainsi que le futur de Linux se trouve dans ce domaine la, donc il faut que ce cas soit optimisable.
[^] # Re: Compiz ne migrera pas vers Wayland
Posté par cedric . En réponse à la dépêche Petites brèves autour de Wayland. Évalué à 3.
Vu que tu travailles plutot avec des GPU discret, la copie dont je parle se fait a coup de DMA dans ce cas la et est effectivement impossible a eviter sur ces GPU.
Hum, en fait, je n'ai jamais regarde en detail les i7 et i5 avec GPU integre, mais de ce que j'ai compris sur leur SoC, tu partage le meme controleur memoire. Certe tu dois negocier avec le GPU pour mapper la memoire dans l'adresse space du CPU. Mais cela devient directement accessible et ne genere pas de copie quand tu "unmap" ta memoire pour la rendre de nouveau utilisable par le GPU. Tu peux donc avoir ton rendu software qui va cycler sur un certain nombre de buffer directement utilisable par le GPU. Je n'ai pas travaille assez longtemps sur SoC Intel pour etre sur du comportement, mais sur SoC Qualcom et Samsung, tu as clairement ce comportement. Je soupsonne que c'est le cas pour toutes les SoC qui supporte Android.
C'est clairement sous optimal avec un GPU discret, donc il faut forcement garde le chemin avec xshm pour ce cas la. Pour les GPU a memoire partage, tu gagnes une copie memoire, ce qui a un impact direct sur les performances et se repercute principalement sur la consomation de la batterie (Le hard moderne tenant facilement les 60fps, c'est surtout la batterie qui montre les soucis de performance). Ce qui est logique, car toute operation que tu ne fais pas, ne consome pas de batterie :-) D'un point de vue difference, une stack X qui fait du xshm vs Android consomme plus de batterie aux environs de 30% (Mais ce chiffre dependra de ce que tu benchmark bienentendu).
Parce que la majorite des drivers OpenGL ne sont pas capable de tenir un mois sans cracher en faisant du compositing ? Je n'ai besoin de basculer mon compositeur en OpenGL que lorsque je fais du multiscreen. Et j'economise aussi de la batterie a reste en soft quand je code, car au lieu de redessiner tout l'ecran, il ne met a jour qu'un tout petit coin. Mais vu que je fais souvent de l'OpenGL, c'est pas mal de pouvoir quand meme avoir ce cas qui marche… Et ca, c'est sur un desktop, sur une tablette ou un telephone, le cas se presente encore plus frequement (consomation eleve de memoire du au context OpenGL, switch de context entre le compositeur et l'appli qui n'est pas forcement un moment joyeux, …).
Sinon de nos jours, c'est les GPU discrets qui sont en "voit" de disparition face au GPU a memoire integre. Comparer le nombre de Linux dans un cas et dans l'autre est d'ailleur assez vite fait ! Plus d'un million sont active par jour avec une memoire partage… Et Wayland ainsi que le futur de Linux se trouve dans ce domaine la, donc il faut que ce cas soit optimisable.