Bonjour,

Continuant le développement de mon système d'exploitation en mode graphique VESA dont voici le sources (pas encore aboutie mais vous donnant un aperçu)

je désire savoir si les GPU avait leur propre code assembleur et comment était exécutes les shades des bibliotheques 3D (opengl)? avec un assembleur du CPU intel/AMD ?

deplus je désire savoir si une carte d'acquisition national instrument NI est exploitable en C++? et non en labview avec son runtime affreux sous licence

merci d'avance

@+

-
Edité par charly33 16 octobre 2017 à 1:05:40

personne?

Salut... 

Je suis pas sur de ce que je vais dire... Mais il me semble que NVIDIA a sa propre biblio comme tu dis... DirectX ??

Je ne connait pas AMD  

Team VERT désolé 

Et  pour t'a 2e questions je ne pourrais pas t'aider en tout cas bonne chance pour ton projet !

mais quand on parle a la carte graphique ont lui écrit en assembleur intel ou elle ne sert qu'a faire des stockage de texture et modele 3D et calcul physique déja calculer ? la carte graphique est un pc dans un pc si je comprend bien?

Je pense que tu devrais te renseigner directement chez AMD ou NVDIA car c'est du haut niveau!

AMD se sert APU en gros processeur graphique qui gère une partie du fonctionnement pc et graphique!

Et je ne saurait pas en dire +

moi se que je voudrais réellement savoir c si en en HD ou VGA et pas en mode VESA le developpement d'un driver d'une carte grahique nécessite un o.s sur la carte graphique ou pas? tout ce fait en RAM sur le PC et est envoyer en mémoire sur le GPU ou comment sa marche autrement?

On communique avec la carte graphique en lui envoyant des commandes et des données par le bus PCI. Tu devrais commencer par implémenter ce protocole pour commencer (qui sert à plein d'autres choses).

charly33 a écrit:

je désire savoir si les GPU avait leur propre code assembleur et comment était exécutes les shades des bibliotheques 3D (opengl)? avec un assembleur du CPU intel/AMD ?

L'utilisateur (enfin ici le développeur donc) qui veut communiquer à la carte graphique (càd lui faire quelque chose d'utile comme afficher des objets 3D ou faire des calcul / compute), écrira son code en utilisant une API de haut niveau comme OpenGL, DirectX, Vulkan, etc.

Ces commandes OpenGL, DX, etc. peuvent être écrites dans n'importe quel langage (C, C++, Python, Java, etc.).

Les commandes OpenGL, DX, etc. sont interprétées par le pilote graphique qui va agir comme un véritable compilateur pour transformer ces commandes en commandes de bas niveau pour le GPU.

Une fois ces commandes compilées en quelque chose de compréhensible pour le GPU, elles sont envoyées via des appels systèmes à la carte graphique (généralement via le bus PCI).

-
Edité par Anonyme 4 novembre 2017 à 13:36:56

on écrit pas directement sur le bus pci on passe par la ram ex: 0xA0000 0xB8000 dite moi si ya un spécialiste dans le developpement d'os dans le coin sa m'arrangerai

lecbee> je vois mais sa veux dire que le GPU a son propre langage ou a un langage commun avec mon processeur CPU?

charly33 a écrit:

on écrit pas directement sur le bus pci on passe par la ram ex: 0xA0000 0xB8000 dite moi si ya un spécialiste dans le developpement d'os dans le coin sa m'arrangerai

Sauf que non, ça se sont des modes assez obsolètes (VGA) où on n'utilise aucun mode d'accélération graphique. Mais oui, on va souvent utiliser des memory-mapped devices (ça ne veut pas dire qu'on passe par la RAM cependant).

concrètement il n'y a que deux façon d’interagir avec la machine par les instruction in out du CPU et la ram avec des adressage pour les IRQ non?

charly33 a écrit:

les instruction in out du CPU

Ce qu'on appele port-mapped I/O. Cette technique a l'avantage d'être isolée de l'espace mémoire principal.

charly33 a écrit:

la ram

Non, c'est du memory-mapped I/O.

Quand on parle de memory-mapped I/O, memory signifie qu'on va utiliser le même bus d'adresses et de données que la mémoire centrale, pas qu'on va écrire sur la RAM (ce serait catastrophique au niveau de la performance et de la cohérence de certaines opérations).

C'est comme si, dans un modèle simplifié, un décodeur branché sur le bus d'adresses se chargerait de rediriger les écritures vers le bon device, ou vers la RAM.

-
Edité par Mad scientist 11 novembre 2017 à 23:58:01

tu veux dire que l'espace d'adresse adressable en 0xb8000 (adresse physique) est un espace hors mémoire ram?

Si des registres ou la mémoire d'un autre device est mappé dessus (ce qui est le cas, à priori), oui.