J'essaye de réaliser quelque chose de similaire en partageant un context OpenGL entre plusieurs clients. (pour un jeu)
J'ai tout d'abord deux choix qui s'offrent à moi:

• intercepter tous les calls opengl et les regrouper dans une liste à envoyer à la fin de chaque frame (et donc laisser les autres clients les exécuter ensuite également)
• Faire un screenshot à chaque frame et l'envoyer aux clients

Etant donné la complexité de la première méthode je suis actuellement en train de faire des tests avec la seconde, actuellement j'arrive à obtenir ce screenshot en 2-5ms, puis +3/4ms pour la compression Zstd et +4ms pour la décompression, ce qui me fait en tout ~14ms de délai, est-ce raisonnable sachant que je souhaite délivrer 60 fps ? En y rajoutant le ping ça me parait injouable...

Comment fonctionne les services déjà existants ? J'entends parler de compression vidéo (H.264) mais que contient cette vidéo ? La frame précédente et celle nouvellement générée ? Ce qui voudrait dire un décalage de minimum 1 frame entre le serveur et clients ?

Etant donné que je souhaite intégrer cette fonctionnalité, je peux très bien me concentrer sur la première méthode en récupérant toutes les instructions OpenGL que je renvoie aux clients, est-ce plus logique étant donné ce que je souhaite en faire ? (Je suppose que ça demanderait aussi moins de bandwidth, ce qui m'arrange)

J'aurais plutôt dû employer le terme "cloud gaming" mais vous avez compris

bah le jeu tourne entierement sur une machine de amazon. et la sortoe video est streame avec de la compression. en l'occurence ils ne prennent pas une screenshpt. ils envoie directement le framebuffer sur le reseau avec de la compression.

Le 03 mai 2019 à 13:24:07 godrik a écrit :
bah le jeu tourne entierement sur une machine de amazon. et la sortoe video est streame avec de la compression. en l'occurence ils ne prennent pas une screenshpt. ils envoie directement le framebuffer sur le reseau avec de la compression.

Huum je vois, après il y a d'autres services comme celui de parsec ( https://blog.parsecgaming.com/description-of-parsec-technology-b2738dcc3842 ) fonctionnant cette fois-ci sans machine extérieure, utilisant une API windows.

Dans mon cas n'y a-t-il pas une méthode viable ne nécessitant pas de toucher à l'OS ni à chaque famille de GPU ?
Que penser de mes deux idées présentées plus haut ?

Ca veut dire quoi faire du cloud gaming sur ta machine localement?
Ce dont tu parles, c'est VNC essentiellment, sans quelquechose de plus bas niveau, tu va avoir une latence eleve et un haut cout en bande passante.

Le 03 mai 2019 à 14:49:09 godrik a écrit :
Ca veut dire quoi faire du cloud gaming sur ta machine localement?
Ce dont tu parles, c'est VNC essentiellment, sans quelquechose de plus bas niveau, tu va avoir une latence eleve et un haut cout en bande passante.

C'est ça, sauf que je vise une simple fenêtre ayant un context OpenGL, après concernant le haut coût en bande passante c'est déjà le cas avec des services comme Shadow (l'ayant testé), pour la latence je demande justement des conseils pour la réduire le plus possible

shadow fait de la compression a la vole et DMA le framebuffer directment de la carte graphique.

screen+compression+réseau+décompression+affichage c'est beaucoup trop cher en latence, et faire une vidéo à partir de screenshots (pris a 30FPS donc ?) c'est difficilement réalisable a mon avis.
Tu peux déjà voir ce que ça donne en repartant des sources d'un logiciel de streaming (https://github.com/obsproject/obs-studio par exemple ?) qui doit être déjà relativement optimisé mais je suis quand même pas certain que la latence soit acceptable.

Nan les logiciels de streaming ne cherchent pas a avoir une bonne latence. Si tu as une latence de 2 secondes, ce n'est pas la fin du monde pour les gens qui regardent.

Le 03 mai 2019 à 16:23:42 dark_drow a écrit :
screen+compression+réseau+décompression+affichage c'est beaucoup trop cher en latence, et faire une vidéo à partir de screenshots (pris a 30FPS donc ?) c'est difficilement réalisable a mon avis.
Tu peux déjà voir ce que ça donne en repartant des sources d'un logiciel de streaming (https://github.com/obsproject/obs-studio par exemple ?) qui doit être déjà relativement optimisé mais je suis quand même pas certain que la latence soit acceptable.

Il existe déjà des services proposant ce genre de service, comme le partage d'écran discord ou parsec cité au dessus.

Je me suis dit qu'étant donné que je partage uniquement une fenêtre que j'ai moi-même et non pas nécessairement tout l'écran, il serait possible d'obtenir de meilleurs performances que ces deux services. (Je pense donc que la meilleure solution est d'intercepter toutes les instructions OpenGL et de les exécuter sur tous les clients)

screen+compression+réseau+décompression+affichage

J'avais déjà essayé, en utilisation CPU ça peut vite devenir monstre sur la bécane aussi...

Je me suis dit qu'étant donné que je partage uniquement une fenêtre que j'ai moi-même et non pas nécessairement tout l'écran, il serait possible d'obtenir de meilleurs performances que ces deux services.

Ca doit etre possible de configurer les outils pourqu'ils n'envoient qu'une fenetre plutot que tout l'ecran. Les compositeurs ont pousse ala creation de frame buffer par fenetre. Donc il suffit de n'envoyer que ca.

(Je pense donc que la meilleure solution est d'intercepter toutes les instructions OpenGL et de les exécuter sur tous les clients)

Probablement pas. C'est la difference entre les formats raster et vectoriel. Dans certains context les representations vectoriels sont plus simple.(C'est pour ca que pour plein d'application, X11 est bien plus rapide que VNC.)
Mais dans le contexte d'un jeu video, j'en doute fortement. Une image du jeu, c'est peut etre 4k*2k*32bit. Ca fait une image de 32Mo non compresse. Apres compression probablement de l'ordre de 2Mo.
Le format vectoriel n'est pas compressible, et il te force a envoyer tous les VBO et companie. Et ca fait clairement plus de 32Mo.
Alors oui, tu pourrait envoyer les VBO a l'avance et ne pas reenvoyer ce qui ne change pas, mais c'est difficile a savoir, et ca demanderait probablement dereecrire l'application.