Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
affichage à l'écran en C
Salut à tous.
J'aimerais savoir comment faire de l'affichage à l'écran.
Par exemple, sous linux, comment dessiner quelque chose à l'écran ?
ps: je sais dessiner via opengl, je cherches plus bas niveau et plus manuelle, comprendre le fonctionnement, les possibilités, etc.
Regarde du cote de la libX, je ne crois pas qu'il y ait une lib plus bas niveau pour faire du graphisme. Apres il ne te reste qu'a regarder son code source.
Merci.
Je connais (l'existence de) libX (xlib) qui appartient à Xorg dont sdl, gtk, etc fonctionnent dessus.
J'ai ouvert ce sujet pour savoir le fonctionnement, pour éviter à devoir regarder les codes sources et faire copie/colle des libs existant.
J'ai eu l'idée de voir les tutos d'assembleur qui font de l'affichage en utilisant vesa, je vais poursuivre mes recherches sur vesa.
ça dépend ce que tu appelle bas niveau ?
Pour moi dans le graphisme c'est faire du pixel par pixel et la pas mal de lib permet de le faire.
Si c'est plus pour savoir comment fonctionne linux et comment il gère fenetrage/affichage en dessous , libX me semble approprié , mais t'aura une connaissance low level que de linux.
Tu parle de vesa , il faut savoir que le bas - niveau est limité sur les OS actuel t'aura pas accès directement au matériel , donc il faudra passé par OS obligatoirement , mais a une ancienne époque en toucher effectivement directement en assembleur les pixel a écran.
J'utilises linux, et voudrais que sa marche sous linux.
Le but est de pouvoir gérér tout l'écran et dessiner mon propre contenu.
Faire une bibliothèque graphique, qui dessine des points, lignes, etc.
Au niveau le plus bas, quel que soit le système d'exploitation, on trace des choses à l'écran en écrivant directement dans la mémoire vidéo. Autrement dit, chaque octet que tu vas déposer dans une certaine portion du plan mémoire va automatiquement se traduire par un artefact à l'écran. Sur PC, à l'époque du mode réel en 16 bits et du mode texte, c'était à partir de B800:0000 puis, en VGA, de A000:0000.
Seulement, à partir du SVGA, les standards ont divergé avec la diversification des fabricants de carte et des périphériques d'affichage (les moniteurs) ainsi qu'avec le bus PCI qui permet aujourd'hui de mapper la carte n'importe où en mémoire, ce qui est une bonne chose. Il n'empêche que tu vas devoir passer par le pilote de ta carte vidéo pour t'y retrouver et, donc, par une interface unifiée proposée par ton O.S.
X-Window est effectivement une infrastructure qui, dans ses propres basses couches, s'appuie sur un pilote vidéo défini dans le fichier de configuration. Si tu veux t'en affranchir, tu peux utiliser le frame buffer proposé par le noyau Linux.
Si j'ai bien compris, il existe un fichier de "framebuffer" qui est le contenu de se qui sera afficher à l'écran.
Ce réel "framebuffer" se situe dans la carte graphique, mais celui qui se trouve dans le système est juste un alias qui pointe dessus ?
Donc:
code C -> framebuffer(carte graphique) -> écran
J'aimerais savoir, comment se passe quand on utilise l'opengl.
J'essaye de différencier l'utilisation cpu et gpu.
À l'ancienne époque, il semblerait que tout reposait sur le cpu.
Maintenant c'est la carte graphique qui se charge.
Donc ici, j'aimerais clarifié la différence de fonctionnement.
Est-ce que la carte graphique fait les calcules via le GPU soit même et envoie directement le résultat à l'écran.
ou
Elle fait les calcules puis envoie à l'ordinateur -> dans le "framebuffer" -> qui lui est après renvoyer directement à l'écran.
C'est un peu flou pour moi.
En tous cas, moi je veux m'en passer de l'opengl et tous ces fonctionnalités que fournis la carte graphique.
Je veux faire moi même le dessin, et m'appuyer sur le gpu pour les grosses calcules si nécessaire.
Toute éclairsissement sera la bienvenu.
L'explication est simple: OpenGL n'affiche pas, il calculeEnvoyé par kripteks
EGL
Ah c'est comme je le pensais (enfin presque).
Donc, si on s'en passe d'opengl, on peut alors faire de cet manière:
- faire ses propres fonctions pour dessiner
- utiliser le gpu pour les calcules
- renvoyer le résultat final à l'écran
?
Qu'appelle tu propre fonction pour dessiner ? genre dessiner une image ? une ligne ect ,alors oui tu peux le faire en software c'est ce que fait pas mal de librairie graphique software (allegro , SDL).
Après si tu passe avec opengl t'aura pas trop le choix niveau calcul , il sera orienté calcul de rendu 3D , et c'est le GPU qui s'en occupe , mais tu fera pas tout les calcul 3D , par exemple ce jeu Alone in the dark , faisait tout les calcul 3D en CPU (et en assembleur mais c'est une autre histoire) ,et donc le programmeur ici doit coder tout les calcul 3D , alors que avec opengl , une part du travail est mâché (justement parce que il le fait niveau matériel plus rapide) , les anciennes console 2D ou 3D , c’était la même chose il avait toujours une accélération matériel ( a cause d'un CPU pas très puissant).
Bref pour répondre dans tout les cas en envoie le résultat final a écran opengl ou pas
C'est là que je veux en venir.
Soit on a le software.
Soit le hardware, avec opengl.
Je me disais, s'il serait possible de faire avec le hardware mais sans opengl en couplant le code C et le code (de la carte graphique pour faire les calcules via GPU).
Pour cela je m'intéresse à la possibilité d'afficher directement et l'utilisation puissance GPU.
On gros tu veux utiliser ta carte graphique pour faire les calculs ? , il y a CUDA pour ça.
Après j'ai impression que tu pense qu'il faut obligatoirement utiliser la carte graphique pour faire des graphisme ou un rendu a écran, ce qui n'est évidement pas le cas .
Ben pour les performances c'est 'relative' , les processeurs CPU actuel sont assez puissants , en tout cas pour la 2D , pour la 3D il faudrait coder de manière très optimiser et se limiter niveau polygone , je sais que la psone utiliser des short niveau calcul (et non des floats) , du coup ça doit augmenter pas mal les performances.
Je penses utiliser OpenCL.
On parle télément de haut niveau à cet époque, qu'on commence à tout oublié et/ou mélangé le dessous du capot.Après j'ai impression que tu pense qu'il faut obligatoirement utiliser la carte graphique pour faire des graphisme ou un rendu a écran, ce qui n'est évidement pas le cas .
Heuresement que j'avais (un peu) suivis des cours sur l'assembleur, et dont une partie était sur l'affichage, ce qui me donnais un avis sur le fonctionnement.
En tous cas pour mon cas je vais devoir: code C + OpenCL -> framebuffer
Je met résolu, merci pour vos aides.
Un système d'affichage vidéo, au niveau le plus fondamental qui soit, c'est tout simplement… de la mémoire vive.
La seule différence avec la RAM ordinaire dont tu as l'habitude est qu'un automate électronique se charge de la lire automatiquement en boucle quand le micro-processeur n'accapare pas le bus pour son propre usage. La valeur de chaque octet lu depuis cette mémoire va être automatiquement traduite en une série de petits signaux qui vont être directement envoyés au canon à électrons de ton moniteur, ou ce qui en tient lieu puisque plus personne ne travaille encore sur des écrans cathodiques aujourd'hui. Plus l'octet suivant est lu et sera traduit à son tour en les mêmes petits signaux, qui formeront les pixels d'à côté.
Enfin, ça, ça a été vrai longtemps sur les 8 et 16 bits, ainsi que sur les PC de première génération. Jusqu'alors, la mémoire vidéo n'était qu'une portion (fixe) de la mémoire centrale de l'ordinateur. Aujourd'hui, c'est un peu plus sophistiqué mais guère plus sur ce plan-là. La principale différence est que la mémoire vidéo se trouve maintenant sur un bus propre pour ne pas ralentir le reste du système et qu'elle est adaptée aux performances de la carte qui l'embarque, performances qui augmentent toujours plus car c'est un enjeu industriel, pour le plus grand plaisir des gamers.
Il en reste que même aujourd'hui, le simple fait de déposer une valeur dans cette mémoire suffit à modifier ce qui est affiché à l'écran, sans avoir besoin d'envoyer un quelconque « ordre » pour effectuer le rendu.
Le GPU, maintenant, est en principe facultatif, quoiqu'incontournable à notre époque. Il s'agit d'un micro-processeur annexe, monté sur la carte graphique, très simplifié dans les opérations qu'il est capable d'effectuer mais beaucoup plus rapide ! Il est donc possible de le programmer une fois pour qu'il fasse lui-même les modifications en mémoire vidéo qui étaient jusque là effectuées directement par le CPU. Ce qui est intéressant, c'est que les opérations nécessaires à la gestion de la 3D sont des opérations mathématiques assez communes en sciences mais auxquelles un micro-processeur n'est pas spécialement plus adapté qu'à d'autres tâches.
Les « GPGPU » intéressent donc beaucoup les scientifiques car ils leur apportent à peu de frais une puissance de calcul qui était réservée autrefois aux supercalculateurs. Acheter une dizaine de cartes vidéos dernier cri reste moins cher et plus rapide, puisqu'on les trouve dans l'hypermarché et que leur prix est adapté au grand public.
C'est un peu plus subtil que cela. OpenGL est avant tout une norme et une interface. En 2D, les choses sont assez simple. En 3D, par contre, il est assez délicat d'expliquer ce que l'on veut faire. Par exemple, on utilise fréquemment des matrices là où l'on se contente de simples coordonnées quand on travaille en 2D. En ce sens, OpenGL est une sorte de langage, bien ficelé, qui vaut le coup d'être appris mais qui demande quand même un investissement. Le rendu peut ensuite être effectué via différentes technologies. Elle peut être entièrement logicielle avec Mesa, par exemple. C'est lent, ça ne te permettra jamais de jouer à un jeu vidéo en temps réel, mais l'image sera quand même produite.
L'avantage est que puisque cette interface est populaire, les fabricants de carte peuvent produire un pilote qui exploitent le GPU en coulisses et auquel on dialogue en OpenGL en façade. À ce moment, le fait de mettre en place cette carte dans sa machine permet directement, ou presque, aux programmes d'obtenir un rendu immédiat sans avoir à changer quoi que ce soit. Comme les performances de ce pilote sont un point critique et c'est également le travail d'ingénieurs développement expérimentés, les fabricants se font un peu tirer l'oreille pour ouvrir les spécifications de leur carte.
Ce qui nous amène à ce que tu veux faire : si tu veux te passer d'OpenGL (et de CUDA), il faudra piloter le GPU directement. C'est très stimulant mais c'est également très difficile, ce sera différent pour CHACUNE des cartes graphiques sur lesquelles tu vas travailler, et tu vas traverser le désert avant d'obtenir un semblant de documentation pour la puce que tu essaies d'exploiter. C'est d'ailleurs ce qui était à l'origine du gros coup de colère de Linus Torvalds envers nVidia (le fameux « F**k You »).
OpenCL permet justement de palier ce problème il me semble.
D'où mon interet à vouloir l'utiliser.
Répondre avec citation
Partager