Discussion :

[Kromagg]

Bonjour

Je cherche un librairie (C/C++) pour faire des opérations asynchrones sur les fichiers, si possible multi-plateforme (Windows et Linux minimum)

Merci bien
Kromagg

[Neckara]

Bonjour,

bibliothèque*

C/C++

Il faut te décider C ou C++ ?

Sinon
http://lmgtfy.com/?q=asynchronous+files+C%2B%2B

[Kromagg]

bibliothèque*

Oui désolé c'est l'habitude du mot anglais, mauvaise traduction^^

Il faut te décider C ou C++ ?

Je voulais dire par là en C ou C++, peu importe.

Et la recherche google n'a rien donnée de concluant puisque je n'ai trouvé aucune bibliothèques multi-plateforme. C'est donc pour ça que je poste sur ce forum

[Neckara]

Si j'ai bien lu, boost::asio permet de faire de la lecture aynchrone de fichier sous Windows (?) mais sous Linux, la lecture sera synchrone (car cela n'aurait pas de sens sous Linux).

Sinon, on trouve des codes ci-et-là, un simple #ifdef et le tour est joué.

EDIT : tu as aussi AIO pour Linux.


Après pourquoi veux-tu faire de la lecture de fichier asynchrone?

[Médinoc]

Si j'ai bien lu, boost::asio permet de faire de la lecture aynchrone de fichier sous Windows (?) mais sous Linux, la lecture sera synchrone (car cela n'aurait pas de sens sous Linux).

Pourquoi cela n'aurait-il pas de sens?

[Neckara]

Pourquoi cela n'aurait-il pas de sens?

Je ne sais plus exactement mais grosso-modo, si j'ai bien compris ce qui était dit :
- les lectures sont très "rapides" ;
- on a très souvent besoin d'attendre la fin de la lecture avant de continuer à exécuter la suite des instructions ;
- et il y a une histoire avec le kernel Linux.

Pour ces raisons là, la lecture asynchrone n'est pas vraiment utile sous Linux ce qui a été un frein à l'ajout complet de la lecture asynchrone dans boost.

Je crois que cela devait être dans un sujet de stackoverflow dans les premiers liens de la recherche que j'ai posté plus haut.

Après, je ne fais que reporter ce que j'ai cru comprendre.

[imperio]

@Neckara: je trouve bizarre ce que tu dis sur le coup ou alors je ne dois pas avoir la meme definition du mot asynchrone que toi...

Prenons par exemple une ecriture de donnee asynchrone sur un fichier, elle devrait en toute logique se faire sans ralentir l'execution du programme puisqu'elle serait executee en parallele du thread principal. N'est-ce pas la le but de l'asynchronisme ?

Je ne sais plus exactement mais grosso-modo, si j'ai bien compris ce qui était dit :
- les lectures sont très "rapides" ;

Cette affirmation me parait fausse puisque la vitesse de lecture / ecriture d'un fichier depend surtout du materiel sur lequel il est stocke ! Sur un SSD ca sera en effet tres rapide mais pour le reste ca peut causer de grosse latence.

- on a très souvent besoin d'attendre la fin de la lecture avant de continuer à exécuter la suite des instructions ;

Pas necessairement. Une fois de plus prenons un exemple : un jeu video tourne, tu te balades et tu as besoin de charger une nouvelle texture (tres lourde). Tu ne vas pas stopper le jeu pendant ce temps-la, ce serait inconcevable !

- et il y a une histoire avec le kernel Linux.

La je crois qu'il va te falloir etre plus precis.

[Neckara]

Cette affirmation me parait fausse puisque la vitesse de lecture / ecriture d'un fichier depend surtout du materiel sur lequel il est stocke !

Cela dépend aussi des optimisations qui peuvent être fait sur le code.
Après, comme je l'ai dit, je ne fais que rapporter ce que j'ai lu.

Pas necessairement. Une fois de plus prenons un exemple : un jeu video tourne, tu te balades et tu as besoin de charger une nouvelle texture (tres lourde). Tu ne vas pas stopper le jeu pendant ce temps-la, ce serait inconcevable !

C'est pour cela qu'on utilise des threads et des écrans de chargements.

La je crois qu'il va te falloir etre plus precis.

Essaye de retrouver le post car j'ai pas tout compris

[Médinoc]

on a très souvent besoin d'attendre la fin de la lecture avant de continuer à exécuter la suite des instructions

Justement, la lecture asynchrone, c'est pour quand on n'en a pas besoin. Quand on a besoin du résultat tout de suite, on fait une lecture synchrone.

C'est pour cela qu'on utilise des threads

Traduction: Si on veut de la lecture asynchrone, on peut la faire soi-même.
Bien que techniquement vrai, ce n'est pas forcément la solution optimale (duplication de code, réinvention de roues, etc.)

[Kromagg]

En fait je travaille sur un projet de jeux vidéos 2D, j'aimerai pour commencer reproduire le premier niveau de l'excellent Jazz Jack Rabbit 2 qui a bercé une partie mon enfance Et j'ai justement besoin de la lecture asynchrone pour charger le décors des niveau au fur et à mesure que le joueur progresse. J'ai pensé à développer mon système à base de thread mais pourquoi réinventer la roue.

Est-ce que le couple std::async/std::future pourrait faire l'affaire pour ce type de tâche ?

[jblecanard]

Est-ce que le couple std::async/std::future pourrait faire l'affaire pour ce type de tâche ?

Très certainement !

[koala01]

Salut,

En fait je travaille sur un projet de jeux vidéos 2D, j'aimerai pour commencer reproduire le premier niveau de l'excellent Jazz Jack Rabbit 2 qui a bercé une partie mon enfance Et j'ai justement besoin de la lecture asynchrone pour charger le décors des niveau au fur et à mesure que le joueur progresse.

Je ne me souviens plus vraiment du jeu, mais est-ce vraiment nécessaire

Dans la plupart des jeux 2D, l'ensemble du niveau n'est qu'une composition basée un ensemble relativement limité de "briques de base".

Par "brique de base", j'entends bien sur les différents éléments du décors qui défile (et même, dans une certaine mesure, les différents méchants vilains pas beaux qui viennent t'embêter régulièrement )

Une fois que tu as chargé ces "briques de base", que ce soit sous la forme de "tuiles" en jpeg ou sous la forme de dessin vectoriel + texture, "tout ce qu'il faut faire", c'est être en mesure d'indiquer quelle brique va à quel emplacement dans le décors.

Pour peu que tu sois en mesure d'identifier clairement chaque brique de base (par exemple, au travers d'un indice de tableau), tout ton niveau peut donc se résumer en une grande matrice de n ligne et de m colonnes qui correspondent respectivement à la hauteur et à la largeur de l'intégralité du niveau envisagé et dont la correspondant à une position x, y correspond à la brique de base qu'il faut afficher pour cette position.

Tu peux donc mettre énormément d'informations dans un espace particulièrement réduit et ton niveau peut très certainement être chargé "en entier" en mémoire, surtout quand on voit les capacités actuelles des PC en la matière

Dés lors, n'as tu pas l'impression de te faire du mal pour rien en essayant d'utiliser la lecture asynchrone

Maintenant, je ne dis pas que tu te fais du mal pour rien, je dis juste que tu risques ou que tu as de grandes chances de le faire

J'ai pensé à développer mon système à base de thread mais pourquoi réinventer la roue.

Si l'idée du thread est très certainement bonne, si tu ne devrais en effet pas avoir à réinventer la roue, je ne suis pas sur du tout que tu aies réellement besoin d'utiliser cette idée dans le contexte dans lequel tu te trouves (cf la première partie de ma réponse )

Ma réponse n'apporte évidemment pas de solution à ton problème de lecture asynchrone, mais elle a pour but de t'ouvrir peut être d'autres pistes de réflexion qui te permettront -- qui sait -- de ne pas en avoir besoin

[moldavi]

Bonjour.

Je confirme le message de koala01. On charge tous les éléments du niveau une seul fois au début.

Le faire en court de route, c'est exposer le joueur à de bon petits lags sympas.

Sous DirectX par exemple, on va utiliser des textures compressées au format DDS, afin de pouvoir charger la mémoire GPU au maximum.

Je dirai que la piste des textures compressées est à envisager avant le chargement asynchrone.

[therwald]

bonjour
[vraie question inside]
Et faire le chargement du niveau 2 en temps masqué arrivé à un certain stade du niveau 1 pour éviter une trop grosse pause, c'est pas envisageable?

[koala01]

bonjour
[vraie question inside]
Et faire le chargement du niveau 2 en temps masqué arrivé à un certain stade du niveau 1 pour éviter une trop grosse pause, c'est pas envisageable?

Bien sur que c'est envisageable!

Mais cela ne nécessite toujours pas la lecture asynchrone

Et puis, cela pourrait éventuellement poser des problèmes si le zero a encore l'occasion de mourir entre le moment où tu décides de charger le niveau suivant et le moment où il y arrive.

La solution est peut être viable, mais il s'agit de prendre tous les aspects que cela peut impliquer en compte

[Médinoc]

Mais cela ne nécessite toujours pas la lecture asynchrone prise en charge par l'OS au lieu de lecture asynchrone faite toi même

Corrigé pour toi.

Le chargement "à l'avance" du niveau suivant ne peut être fait qu'en asynchrone. Mais ça peut être fait en asynchronisant soi-même (en faisant une lecture synchrone sur un autre thread) sans nécessiter que l'OS asynchronise pour toi.

[moldavi]

Bonjour.

bonjour
[vraie question inside]
Et faire le chargement du niveau 2 en temps masqué arrivé à un certain stade du niveau 1 pour éviter une trop grosse pause, c'est pas envisageable?

Et bien si le premier niveau occupe 75 % de la mémoire graphique et que le deuxième niveau aussi, cela fera 150% d'occupation mémoire. Ce qui n'est pas possible...

On pourrait toujours charger 25%. Mais le problème pourra être le lag. Si le jeu en cours d'utilisation prends 80% de la bande passante qui relie la mémoire vive à la mémoire GPU. Il ne reste que 20% pour charger les 25% de mémoire GPU. Si le processus asynchrone utilise plus de 20%, il y aura du lag. Et je pense qu'il y aura quand même du lag sur pas mal d'architecture.

Et comme tout cela peut dépendre de plein de choses, pour être compatible multi-GPU, cela va demander beaucoup de travail. Mais pourquoi pas...

Sous DirectX, le multithreading GPU est arrivé depuis Vista. C'est plutôt jeune comme concept.

Donc mon conseil, lorsqu'un jeu est cours d'utilisation, il faut éviter d'en rajouter à moins de savoir ce que l'on fait, donc de l'avoir éprouver sur beaucoup d'architecture différente.

[Neckara]

Et bien si le premier niveau occupe 75 % de la mémoire graphique et que le deuxième niveau aussi, cela fera 150% d'occupation mémoire. Ce qui n'est pas possible...

Bien sûr que c'est possible.
Tout ça grâce à cette merveilleuse invention qu'est la mémoire SWAP .

Après si on utilise toute la RAM + toute la mémoire SWAP, il est temps de se poser des questions...

Après pour le reste, je ne suis pas très calé en GPU mais si on a des écrans de chargements dans les jeux pros (et sans utiliser de tiles), je pense qu'il y a une très bonne raison. S'ils pouvaient s'en passer facilement, ce serait fait depuis très longtemps je pense.

[moldavi]

Bonjour Neckara.

Bien sûr que c'est possible.
Tout ça grâce à cette merveilleuse invention qu'est la mémoire SWAP .

Ce n'est pas bien de jouer avec les mots

Le swap est un Fake qui te fais croire que tout est en mémoire GPU. Sauf que tu n'as plus la main au niveau optimisation. Cela risque de swapper dans tous les sens.

Sous DirectX tu as la "Memory Managed". En gros s'il n'y a pas assez de place en mémoire GPU, ce sera en mémoire vive. Mais quand les shaders/textures sont utilisés, ils montent dans la mémoire GPU, au besoin. C'est un processus incontrôlable et source de lags.

Si les temps de chargement des niveau 1 et 2 sont de 15 secondes, de toute façon que tu swap ou pas, il faudra 15 secondes. A un moment les ressources doivent se trouver dans la mémoire GPU. Donc qu'elle est l'intérêt de charger le niveau 2 vers la fin du niveau 1, puisque tu n'échappera pas à ces 15 secondes. Avec le risque de faire lagger le niveau 1, et pour gagner quoi. 2 secondes sur 15...

De plus le risque, c'est que l'API décide de mettre les ressources de ton niveau 2 à la place de quelques ressources du niveau 1, qui ne sont pas utilisées depuis un moment. Malheureusement si une de ces ressources vient à être nécessaire, ça va re-swapper. Plutôt téméraire comme approche.

[Neckara]

Ah moi je pensais juste chargement en mémoire : lecture du fichier pour mettre en mémoire vive.

Après, encore faut-il que ce soit le GPU et non le chipset graphique qui soit utilisé etc... Après... Je ne peux pas vraiment dire grand chose de plus, je ne suis vraiment pas calé dans ce domaine et je pense que tu dois t'y connaître un peu mieux que moi .