Discussion :

[europium]

Bonjour,

j'ai un problème quand je veux allouer une texture sur la carte graphique, alors que la mémoire graphique est VIDE.
Certe la texture est 3d et assez grosse, mais elle tient sans problème sur la carte et je suis capable de l'afficher quand ma RAM est vide.

Par contre si ma RAM est un peu chargée, impossible d'allouer la texture sur la carte graphique : "mémoire insuffisante".

En quoi la RAM est nécessaire pour allouer la texture sur la carte graphique ?
Est-ce qu'opengl essaie d'allouer un gros bloc de mémoire contigue ?
Mais dans ce cas, comment l'erreur est gérée par opengl et pas par le système lui-même ?
Je précise que mon buffer qui représente l'image est déjà présent en RAM (forcément).

Il y a un truc que je ne pige pas, quelqu'un aurait une idée ?

-- pium

[LittleWhite]

Bonjour,

Il faut savoir que pour les textures, les constructeurs imposent des limitations de tailles ( que l'on peut connaitre dynamiquement avec un glGet() ).
Si vous dépasser cette limitation, je ne serai pas étonné que vous ayez une erreur GL_OUT_OF_MEMORY
De plus, avant de passer la texture à la carte graphique, il faut l'avoir en RAM ( chargement à partir d'un fichier ) et après on entraine le transfert avec glTexImageXD()
( Une fois le transfert terminé on peut supprimer ).

alors que la mémoire graphique est VIDE.

Faudra me dire comment vous faites pour savoir ça...

[europium]

Bonjour,

Il faut savoir que pour les textures, les constructeurs imposent des limitations de tailles ( que l'on peut connaitre dynamiquement avec un glGet() ).
Si vous dépasser cette limitation, je ne serai pas étonné que vous ayez une erreur GL_OUT_OF_MEMORY.

Je suis capable de charger et d'afficher ma texture sans problème quand la RAM n'est pas trop chargée.

De plus, avant de passer la texture à la carte graphique, il faut l'avoir en RAM ( chargement à partir d'un fichier ) et après on entraine le transfert avec glTexImageXD()
( Une fois le transfert terminé on peut supprimer ).

Mon image est déjà en RAM.

Faudra me dire comment vous faites pour savoir ça...

Vide dans le sens où mon programme n'a rien chargé dedans, après le reste (OS entre autre) bien sûr que je ne sais pas. Tout ce que je sais c'est que si je libère de la RAM (ou que je n'alloue pas grand chose avant), ô magie, la texture se charge. (la même texture avec le même code, etc...)

Que fait OpenGL avec la RAM ???

-- pium

[AuraHxC]

Faudra me dire comment vous faites pour savoir ça...

Avec cuda : cudaMemGetInfo (size_t* free, size_t* total) :p
Bon je sais c'est que pour Nvidia/CUDA mais bon, j'avais envie de le dire :p

[LeGreg]

Bonjour,

j'ai un problème quand je veux allouer une texture sur la carte graphique, alors que la mémoire graphique est VIDE.
Certe la texture est 3d et assez grosse, mais elle tient sans problème sur la carte et je suis capable de l'afficher quand ma RAM est vide.

Par contre si ma RAM est un peu chargée, impossible d'allouer la texture sur la carte graphique : "mémoire insuffisante".

En quoi la RAM est nécessaire pour allouer la texture sur la carte graphique ?
Est-ce qu'opengl essaie d'allouer un gros bloc de mémoire contigue ?
Mais dans ce cas, comment l'erreur est gérée par opengl et pas par le système lui-même ?
Je précise que mon buffer qui représente l'image est déjà présent en RAM (forcément).

Il y a un truc que je ne pige pas, quelqu'un aurait une idée ?

-- pium

Quelle taille la texture ? Quelle est la taille de la mémoire système RAM occupée par le programme ?
Si le programme consomme beaucoup de RAM, genre > 1,5Go et qu'il est compilé en mode 32 bits d'adressage , alors il risque d'atteindre la limite de l'adressage x86-32bits non étendu. Et donc toute grosse allocation derrière va échouer.

Le truc c'est que même si au final une texture va atterrir en mémoire vidéo (qui n'est pas forcément distincte de la mémoire système RAM physique sur les cartes intégrées même si ça n'a pas d'influence sur ce problème), l'OS ou le driver ou le runtime vont parfois devoir allouer un espace d'adressage utilisateur pour le backingstore, l'accès CPU, et j'en passe. Et donc certaines ressources peuvent consommer de l'espace d'adressage réduisant la limite des 2GB sur système Windows 32 bits.

Mais dans ce cas, comment l'erreur est gérée par opengl et pas par le système lui-même ?

Même si c'est le système qui gère c'est bien OpenGL qui doit remonter l'erreur. Comment verrais-tu ça sinon ??

LeGreg

[europium]

Avec cuda : cudaMemGetInfo (size_t* free, size_t* total) :p

je ne connaissais pas ça, intéressant, je vais jeter un oeil.

Quelle taille la texture ? Quelle est la taille de la mémoire système RAM occupée par le programme ?
Si le programme consomme beaucoup de RAM, genre > 1,5Go et qu'il est compilé en mode 32 bits d'adressage , alors il risque d'atteindre la limite de l'adressage x86-32bits non étendu. Et donc toute grosse allocation derrière va échouer.

Le truc c'est que même si au final une texture va atterrir en mémoire vidéo (qui n'est pas forcément distincte de la mémoire système RAM physique sur les cartes intégrées même si ça n'a pas d'influence sur ce problème), l'OS ou le driver ou le runtime vont parfois devoir allouer un espace d'adressage utilisateur pour le backingstore, l'accès CPU, et j'en passe. Et donc certaines ressources peuvent consommer de l'espace d'adressage réduisant la limite des 2GB sur système Windows 32 bits.

En effet je suis aux limites en RAM, mais je ne m'attendais pas à ce qu'OpenGL en utilise quand je cherche à allouer une texture sur la carte video alors que celle-ci est déjà en RAM, je suis déçu !!

Même si c'est le système qui gère c'est bien OpenGL qui doit remonter l'erreur. Comment verrais-tu ça sinon ??

bah en général si tu fais un malloc ou new et qu'il n'y a pas assez de mémoire, ca plante brutalement, mais c'est vrai qu'il y a peut-être moyen de 'catcher' l'erreur et de ne pas faire planter.

Bon ben merci pour les indications, et je vais essayer de trouver une autre solution.

-- pium

[LeGreg]

bah en général si tu fais un malloc ou new et qu'il n'y a pas assez de mémoire, ca plante brutalement, mais c'est vrai qu'il y a peut-être moyen de 'catcher' l'erreur et de ne pas faire planter.

Euh.. si le programme plante méchamment c'est que le programmeur n'a pas fait son boulot..

[LeGreg]

En effet je suis aux limites en RAM, mais je ne m'attendais pas à ce qu'OpenGL en utilise quand je cherche à allouer une texture sur la carte video alors que celle-ci est déjà en RAM, je suis déçu !!

Passe en 64 bits, plein de softs professionnels ont fait le passage déjà.

Sinon si la texture n'est utilisé que par OpenGL ça ne sert à rien de conserver une copie dans tes propres allocations.

Sinon je ne sais pas pour OpenGL mais sous DirectX/Vista, il suffit d'allouer une texture dans le pool default sans les flags "cpu writable" pour que l'OS n'alloue pas l'espace d'adressage pour le backing store. (c'était un "bug/feature" de Vista avant le premier patch sp1). Sous DirectX/XP ça dépend de la version du driver mais ça devrait être le cas pour des drivers de bonne qualité. Pour les textures managed par contre pas d'espoir (c'est l'intérêt et l'inconvénient du "managed").

Par défaut je crois que les textures opengl sont managed.. je ne sais pas si l'API est prévue pour passer outre. Si ce n'est pas le cas, la solution c'est
1- réduire ton empreinte de ton côté (si tu as une texture complète dupliquée dans tes allocations utilisateurs, c'est un gaspillage énorme, il faut allouer une petite surface de transfert à la demande). éviter les mappings de fichiers etc..
2- passer à Direct3D pour bénéficier de l'absence de backing store sur les textures non managed.
3- passer à un mode d'adressage 64 bits.

LeGreg

[europium]

Passe en 64 bits, plein de softs professionnels ont fait le passage déjà.

j'y pense, le pb c'est que j'utilise une lib statique non compilée en 64 bits...

Sinon si la texture n'est utilisé que par OpenGL ça ne sert à rien de conserver une copie dans tes propres allocations.

bien sûr :-)

Sinon je ne sais pas pour OpenGL mais sous DirectX/Vista, il suffit d'allouer une texture dans le pool default sans les flags "cpu writable" pour que l'OS n'alloue pas l'espace d'adressage pour le backing store. (c'était un "bug/feature" de Vista avant le premier patch sp1). Sous DirectX/XP ça dépend de la version du driver mais ça devrait être le cas pour des drivers de bonne qualité. Pour les textures managed par contre pas d'espoir (c'est l'intérêt et l'inconvénient du "managed").

Par défaut je crois que les textures opengl sont managed.. je ne sais pas si l'API est prévue pour passer outre. Si ce n'est pas le cas, la solution c'est
1- réduire ton empreinte de ton côté (si tu as une texture complète dupliquée dans tes allocations utilisateurs, c'est un gaspillage énorme, il faut allouer une petite surface de transfert à la demande). éviter les mappings de fichiers etc..
2- passer à Direct3D pour bénéficier de l'absence de backing store sur les textures non managed.
3- passer à un mode d'adressage 64 bits.

LeGreg

justement je découvre que opengl alloue des trucs en parrallèle des textures, et que glDeleteTextures ne les détruit pas avec la texture elle-même.
Moi je suis sur Qt et par contre j'ai l'impression que QGLWidget::deleteTexture les détuits bien. Avec cette dernière fonction pour détruire mes textures précédement allouées, j'ai réussit à gagner les pouièmes de RAM qui me manquait, mais galère...
Je vais voir si je peux dire à opengl de ne pas allouer des "backing store", mais ca sert à quoi ces trucs ?