Autant que je reponde, j'aime trop les trolls, je suis comme ca je peux pas m'en empecher :)
Atombios ne pose aucun probleme point de vue 3D/2D ou acceleration. Atombios est uniquement utilisee pour le mode setting ou pour la configuration du GPU (nombre de ligne PCIE, economie d'energie ...). Autrement dit atombios n'interviens dans aucun code critique. ie rien qui doit tourner ultra vite, si le modesetting prend 50ms au lieux de 10ms personne ne verra la difference, on change pas constament de mode video.
Le probleme majeurs des drivers radeon c'est l'architecture meme du materiel. En gros pour resumer, sur les cartes nvidia il y a des espaces d'addressage par channel ce qui permet de controller les zones memoires auxquelles le GPU peut acceder. Pour radeon c'est un unique espace d'addressage ce qui implique que les commandes du GPU peuvent etre utilisees pour acceder a toute la memoire, y compris toute la memoire system s'il n'y a pas d'iommu proprement configure (aujourd'hui a ma connaissance toutes les iommu sont configurees en passthrough a cause de tous leurs bugs).
Du coup pour avoir un semblant de securite le driver radeon dans le noyau linux analyse les commandes de l'userspace avant de l'envoye au GPU. Dc l'userspace prend du temps CPU a construire un buffer commande et le kernel prend du temps a analyser se buffer de commandes.
Ce n'est pas l'unique explication, en plus de ce point, la cs ioctl (que j'ai eu la mauvaise idee de creer) a un certain nombre de limitation, nombre de dw que l'on peut envoyer par appel, relocation ... Tout cela conduit a des bottleneck a droite a gauche.
Enfin r600g, une fois encore c'est moi qui est eu la bonne idee des mauvaises decisions je suis tres fort pour ca ! :o) r600g a ete concu selon le modele des constants states. J'etais jeune et innocent ! Je decouvrais le monde. Je peux vous le dire aujourd'hui il y a pas plus mauvais design que les constants state dans le driver si l'api que vous accelerez n'a pas de constant state. Hors c'est quoi donc qu'on accelere ? OpenGL ! Qui n'est pas concu du tout mais alors pas du tout pour les constants state (je ne mentione pas ici de l'extension qui va dans ce sens car qd bien meme celle ci serait integre pour les futures version d'opengl on aura encore pour une tripote d'annee des apps gl qui n'en tireront pas partie).
Rajoutez a cela que gallium aussi a prit le chemin des constant state et vous rajoutez une mauvaise decisions sur une autre mauvaises decisions ! Au final le driver r600g passe enormement de temps a construire chaque command buffer (plus que le driver nouveau qui a ete mieux concu sur ce point). r300g s'en sort bien aussi, un petit nombre de developpeur a passer bcp de temps a l'optimiser.
Bon, pamplemouse sur la cerise (sisi ca peut tenir) r600g ne tire pas partie de fonction comme l'hyperz ou le fast clearing (alors que nouvau tire partie de fonctionalite equivalente). Par ailleurs le ddx aussi joue probablement un role mineur dans la diff de performance.
Voila, sur ce je repart prendre de nouvelle mauvaise decisions le tout pour aguicher des jolies troll.
[^] # Re: nouveau driver
Posté par glisse . En réponse à la dépêche Effervescence autour de la pile graphique libre. Évalué à 10.
Autant que je reponde, j'aime trop les trolls, je suis comme ca je peux pas m'en empecher :)
Atombios ne pose aucun probleme point de vue 3D/2D ou acceleration. Atombios est uniquement utilisee pour le mode setting ou pour la configuration du GPU (nombre de ligne PCIE, economie d'energie ...). Autrement dit atombios n'interviens dans aucun code critique. ie rien qui doit tourner ultra vite, si le modesetting prend 50ms au lieux de 10ms personne ne verra la difference, on change pas constament de mode video.
Le probleme majeurs des drivers radeon c'est l'architecture meme du materiel. En gros pour resumer, sur les cartes nvidia il y a des espaces d'addressage par channel ce qui permet de controller les zones memoires auxquelles le GPU peut acceder. Pour radeon c'est un unique espace d'addressage ce qui implique que les commandes du GPU peuvent etre utilisees pour acceder a toute la memoire, y compris toute la memoire system s'il n'y a pas d'iommu proprement configure (aujourd'hui a ma connaissance toutes les iommu sont configurees en passthrough a cause de tous leurs bugs).
Du coup pour avoir un semblant de securite le driver radeon dans le noyau linux analyse les commandes de l'userspace avant de l'envoye au GPU. Dc l'userspace prend du temps CPU a construire un buffer commande et le kernel prend du temps a analyser se buffer de commandes.
Ce n'est pas l'unique explication, en plus de ce point, la cs ioctl (que j'ai eu la mauvaise idee de creer) a un certain nombre de limitation, nombre de dw que l'on peut envoyer par appel, relocation ... Tout cela conduit a des bottleneck a droite a gauche.
Enfin r600g, une fois encore c'est moi qui est eu la bonne idee des mauvaises decisions je suis tres fort pour ca ! :o) r600g a ete concu selon le modele des constants states. J'etais jeune et innocent ! Je decouvrais le monde. Je peux vous le dire aujourd'hui il y a pas plus mauvais design que les constants state dans le driver si l'api que vous accelerez n'a pas de constant state. Hors c'est quoi donc qu'on accelere ? OpenGL ! Qui n'est pas concu du tout mais alors pas du tout pour les constants state (je ne mentione pas ici de l'extension qui va dans ce sens car qd bien meme celle ci serait integre pour les futures version d'opengl on aura encore pour une tripote d'annee des apps gl qui n'en tireront pas partie).
Rajoutez a cela que gallium aussi a prit le chemin des constant state et vous rajoutez une mauvaise decisions sur une autre mauvaises decisions ! Au final le driver r600g passe enormement de temps a construire chaque command buffer (plus que le driver nouveau qui a ete mieux concu sur ce point). r300g s'en sort bien aussi, un petit nombre de developpeur a passer bcp de temps a l'optimiser.
Bon, pamplemouse sur la cerise (sisi ca peut tenir) r600g ne tire pas partie de fonction comme l'hyperz ou le fast clearing (alors que nouvau tire partie de fonctionalite equivalente). Par ailleurs le ddx aussi joue probablement un role mineur dans la diff de performance.
Voila, sur ce je repart prendre de nouvelle mauvaise decisions le tout pour aguicher des jolies troll.