Cela laisse supposer que tout le savoir du fabricant réside dans son pilote.
Non, mon argument est que compte tenu du fait que les pilotes emulent un grand nombre de fonctions, il est beaucoup plus simple de comprendre ce que font les différents appels matériels.
Ce n'est donc pas avec que l'on va voler la technologie du fabricant.
Comme les APIs sont émulés en utilisant de facon simpliste des fonctions plus évoluées, ca aide au contraire beaucoup a comprendre l'ensemble du pipeline et sa compisition.
Il me paraît évident qu'une équipe avec des connaissances à jour, spécialisée en cartes graphiques, et focalisée sur ce sujet précis peut faire de même et obtenir très vite de très bons résultats.
Le gros problème des cartes graphiques est qu'elles sont faites pour fonctionner en DSP, soit donc efectuer plusieurs opérations simultanément (bon en fait souvent plusieurs fois la même opération, bien que les shaders ait pas mal changé la donne a ce niveau). Toute personne qui ayant le code source s'est amusé a faire un débuggage d'un programme qu'il connaissait et dont il avait le source sait a quel point le multithreading peut être usant. Suivre le déroulement d'un programme sur plus de 4 threads en simultané demande des capacités zen et un nivau de concentration assez énorme.
Une fois que l'on sait ca, il est assez facile de se rendre compte que surveiller 16 pipelines de 8 instructions doubles en DSP (donc 256 opérations simultanées sur la puce) d'après des bribes de pilotes et un affichage a l'écran c'est assez violent a faire quand même. Si on ajoute à celà que l'instruction "simple" de lookup texture peut être utilisé soit pour connaitre la valeur d'un pixel de facon a afficher la texture, soit pour servir de map d'éclairage, soit pour initialiser des shaders on comprend que ca fait beaucoup de tests et de spéculations pour pas grand chose niveau résultat.
Il est tout-à-fait possible pour un fondeur de puces de procéder à la rétro-ingéniérie physique d'un circuit déjà intégré !
J'ai joué a celà sur des puces 8 bits aussi. Mais une fois de plus on parle ici de puces de plus de 50 millions de transistor, gravées au plus fin, réparties sur 8 a 16 couches en recto verso. Il faut donc les ouvrir sans rein casser, les éplucher feuille a feuille (toujours sans rien casser) et ensuite les transmettre a une photographe spécialiste dans uen salle blanche d'indice monstrueux pour qu'il fasse l'inverse de ce qui marche déjà moyennement(yields de 10% pour les processeurs "simples") a savoir faire un cliché grand taille des lamelles qu'on lui donne. Rein que cette dernière étape, au prix de l'heure de mobilisation de salle blanche risque d'être très couteux très vite.
Ces arguments sont valables pour des secteurs de pointes comme les cartes graphiques par exemple, pas pour d'autres périphériques telles que les imprimantes, souris, etc.
Je dirais même plus, ces arguments ne sont valables que pour les périphériques ne pouvant physiquement pas bénificier d'une interface unifiée pour les accès et les appels matériels. C'est a dire a peu de chose près : les cartes graphiques et les carte sd'aquisition multistandards haut de gamme. Même une carte son très haut de gamme qui fournit 4 interface type wave et une interface midi en accès matériel n'a pas vraiment besoin de jouer les chochottes par rapport au contenu de son driver de toute facon c'est une norme ! On a juste besoin de connaitre l'adresse et éventuellement l'interruption a appeler pour que ca marche. Le code est souvent déjà écrit.
Cela se faisait avant !
Tout a fait. J'ai encore le schéma de montage complet de la vieille télé de mes parents. Mais pour être exact tout le monde le faisait avant, aujourd'hui plus personne ne le fait. Il s'agirait donc de convaincre TOUS les intervenants du monde des cartes graphiques de relacher les sources de leurs pilotes le même jour a la même heure pour qu'ils acceptent. Bien entendu il faudrait aussi qu'il y ait un moyen de vérifier que les sources relachées sont complètes, a jour et compilent. Ca va être dur...
[^] # Re: C'est une excellente chose
Posté par Jerome Herman . En réponse à la dépêche Une pétition pour obtenir des pilotes ATI de meilleure qualité. Évalué à 10.
Non, mon argument est que compte tenu du fait que les pilotes emulent un grand nombre de fonctions, il est beaucoup plus simple de comprendre ce que font les différents appels matériels.
Ce n'est donc pas avec que l'on va voler la technologie du fabricant.
Comme les APIs sont émulés en utilisant de facon simpliste des fonctions plus évoluées, ca aide au contraire beaucoup a comprendre l'ensemble du pipeline et sa compisition.
Il me paraît évident qu'une équipe avec des connaissances à jour, spécialisée en cartes graphiques, et focalisée sur ce sujet précis peut faire de même et obtenir très vite de très bons résultats.
Le gros problème des cartes graphiques est qu'elles sont faites pour fonctionner en DSP, soit donc efectuer plusieurs opérations simultanément (bon en fait souvent plusieurs fois la même opération, bien que les shaders ait pas mal changé la donne a ce niveau). Toute personne qui ayant le code source s'est amusé a faire un débuggage d'un programme qu'il connaissait et dont il avait le source sait a quel point le multithreading peut être usant. Suivre le déroulement d'un programme sur plus de 4 threads en simultané demande des capacités zen et un nivau de concentration assez énorme.
Une fois que l'on sait ca, il est assez facile de se rendre compte que surveiller 16 pipelines de 8 instructions doubles en DSP (donc 256 opérations simultanées sur la puce) d'après des bribes de pilotes et un affichage a l'écran c'est assez violent a faire quand même. Si on ajoute à celà que l'instruction "simple" de lookup texture peut être utilisé soit pour connaitre la valeur d'un pixel de facon a afficher la texture, soit pour servir de map d'éclairage, soit pour initialiser des shaders on comprend que ca fait beaucoup de tests et de spéculations pour pas grand chose niveau résultat.
Il est tout-à-fait possible pour un fondeur de puces de procéder à la rétro-ingéniérie physique d'un circuit déjà intégré !
J'ai joué a celà sur des puces 8 bits aussi. Mais une fois de plus on parle ici de puces de plus de 50 millions de transistor, gravées au plus fin, réparties sur 8 a 16 couches en recto verso. Il faut donc les ouvrir sans rein casser, les éplucher feuille a feuille (toujours sans rien casser) et ensuite les transmettre a une photographe spécialiste dans uen salle blanche d'indice monstrueux pour qu'il fasse l'inverse de ce qui marche déjà moyennement(yields de 10% pour les processeurs "simples") a savoir faire un cliché grand taille des lamelles qu'on lui donne. Rein que cette dernière étape, au prix de l'heure de mobilisation de salle blanche risque d'être très couteux très vite.
Ces arguments sont valables pour des secteurs de pointes comme les cartes graphiques par exemple, pas pour d'autres périphériques telles que les imprimantes, souris, etc.
Je dirais même plus, ces arguments ne sont valables que pour les périphériques ne pouvant physiquement pas bénificier d'une interface unifiée pour les accès et les appels matériels. C'est a dire a peu de chose près : les cartes graphiques et les carte sd'aquisition multistandards haut de gamme. Même une carte son très haut de gamme qui fournit 4 interface type wave et une interface midi en accès matériel n'a pas vraiment besoin de jouer les chochottes par rapport au contenu de son driver de toute facon c'est une norme ! On a juste besoin de connaitre l'adresse et éventuellement l'interruption a appeler pour que ca marche. Le code est souvent déjà écrit.
Cela se faisait avant !
Tout a fait. J'ai encore le schéma de montage complet de la vieille télé de mes parents. Mais pour être exact tout le monde le faisait avant, aujourd'hui plus personne ne le fait. Il s'agirait donc de convaincre TOUS les intervenants du monde des cartes graphiques de relacher les sources de leurs pilotes le même jour a la même heure pour qu'ils acceptent. Bien entendu il faudrait aussi qu'il y ait un moyen de vérifier que les sources relachées sont complètes, a jour et compilent. Ca va être dur...
Kha