Xshm te donne une position et une taille, donc il y a bien une copie a ce moment la.
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.
Si tu as un GPU discret (discrete GPU ?), c'est effectivement une bonne chose de ne pas reuploader toute ta fenetre et de t'appuyer sur un DMA pour faire la copie.
On est d'accord.
Par contre, si tu es sur la meme memoire, cas des SoC et de Intel, il vaudrait mieux completement eviter le DMA en accedant directement a la surface video. La plupart des SoC et Intel supporte de faire les operations depuis une surface non tile/compresse avec une faible perte de performance qui dans la pratique devient un gain du fait de l'absence de copie et de cas de rendu direct (pas de compositing, car fenetre au dessus ou plein ecran).
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. Du coup, c'est pas vraiment un System On Chip. Je suppose que tu fais un abus de langage SoC/puce.
Alors, je suppose que tu as dans l'idée d'avoir un compositeur software (pour une raison qui m'échappe). Tu veux donc pouvoir récupérer les données depuis le GPU. Dans le cas d'un GPU discret, tu dois récupérer le buffer depuis la VRAM en programmant la GART (soit en laissant le CPU accéder à la VRAM via la GART, soit en demandant au GPU de copier le buffer dans la RAM ce qui est bien plus performant!) puis tu peux faire ton compositing comme bon te semble mais avec une mémoire lente un processeur pas du tout parallèle. Dans le cas d'un GPU intel, le CPU peut directement bliter le buffer de l'application sur le framebuffer. Si l'application est en plein écran, elle peut directement rendre dans le framebuffer (attention à ne pas faire rendre toutes les applis dans le fb directement car sinon, on retrouve la merde de DRI1).
Cela dit, il faut une collaboration entre le driver GPU et le CPU pour pouvoir faire ça. 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).
Par contre, ton point sur Wayland m'ennuie. Je sais que la partie rendu soft n'est pas vraiment au point (quid d'une appli OpenGL avec un compositing software par exemple). Mais bon, dans le pire des cas, tu dois pouvoir utiliser l'api EGL en maintenant le rendu en soft pour obtenir le meme resultat, non ?
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?
[^] # 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é à 4.
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.
On est d'accord.
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. Du coup, c'est pas vraiment un System On Chip. Je suppose que tu fais un abus de langage SoC/puce.
Alors, je suppose que tu as dans l'idée d'avoir un compositeur software (pour une raison qui m'échappe). Tu veux donc pouvoir récupérer les données depuis le GPU. Dans le cas d'un GPU discret, tu dois récupérer le buffer depuis la VRAM en programmant la GART (soit en laissant le CPU accéder à la VRAM via la GART, soit en demandant au GPU de copier le buffer dans la RAM ce qui est bien plus performant!) puis tu peux faire ton compositing comme bon te semble mais avec une mémoire lente un processeur pas du tout parallèle. Dans le cas d'un GPU intel, le CPU peut directement bliter le buffer de l'application sur le framebuffer. Si l'application est en plein écran, elle peut directement rendre dans le framebuffer (attention à ne pas faire rendre toutes les applis dans le fb directement car sinon, on retrouve la merde de DRI1).
Cela dit, il faut une collaboration entre le driver GPU et le CPU pour pouvoir faire ça. 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 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?