Je souhaite afficher un triangle SANS OpenGL NI DirectX...

[case]

si justement il veux bénéficier de l'accélération matérielle mais sans passer par la couche logiciel, directx et open gl par exemple.
en gros il veux aller directement trifouiller le hardware...

bon courage a lui ,)

a ce sujet peut être qu'il faudrait qu'il zieute du coté des sources de pilotes linux pour se faire une idée du comment de l'adressage de la carte video , j'dis ca, je dis rien moi.

[Ollivier]

Je réécris ma demande au cas où le changement de page aurait enlevé la possibilité de me lire:

Désolé Ollivier, mais tu vas être très déçu. A notre époque il n'est plus possible de se passer de DirectX ou d'OpenGL sous Windows pour profiter de l'accélération matérielle, sauf à :


écrire son propre driver. Certains sources sont dispo, et ça fonctionne toujours de la même façon, avec des registres, mais c'est spécifique à une configuration.

@Djes

- Peux-tu poster ce genre de sources ici?
- Quelles configurations sont prises en compte par ces sources?

[djes]

Par configurations, j'entends le modèle de ta carte graphique et la version de ton OS. Pour la 2D, certaines cartes ont des capacités de remplissage, de blit, d'autres simplement d'affichage de ligne, certains OS gèrent tout ça en 2D, d'autres en 3D.
Pour les sources des pilotes, regarde sur cette page wiki qui mène à de petits trésors : http://en.wikipedia.org/wiki/Graphics_hardware_and_FOSS
Il s'agit de pilotes pour Linux, mais l'initialisation des registres serait la même sous windows (c'est adaptable, pour une bonne équipe!). Tous les constructeurs n'ont pas fourni de pilotes ni de documentation. ATI fait un effort là dessus.

[djes]

Tiens, un article qui vient d'être posté sur le forum anglais (pourtant ça date!) sur le retour au rendu software : http://arstechnica.com/gaming/news/2008 ... erview.ars

[Ollivier]

Bonjour Djes,

Tu as rajouté 2 posts avec chacun 1 lien:
1) Lien vers wiki.english
2) Lien vers interview.english

J'ai lu le deuxième lien. Cela étaye certaines de mes idées que j'ai pu trouver seul et que je remarque qu'elles sont prises au sérieux par des gens bien autrement différents de moi. C'est presque rassurant. ça concerne l'ensemble des techniques de représentation 3D. Donc, dans la vue d'ensemble, j'ai été intéressé.

Mais, sur le plan purement technique et concret, peut-être que l'interviewé a fait une erreur. C'est d'ailleurs la raison pour laquelle j'ai démarré ce sujet. Dans ce sujet-ci, il y a 3 solutions techniques. Et la mienne semble la plus rapide sans être vraiment au max.

Je pense que l'erreur que le gars a faite c'est de considérer que les processeurs graphiques évolueraient moins rapidement que les processeurs centraux, ce qui me semble faux, non?

Pour le lien vers wiki, j'essaierai de trouver du haut débit pour lire les sous-liens. En attendant, j'ai déjà découvert une subtilité sur ma carte graphique. Et les 2 grandes questions que je me pose, c'est:
1) Comment maîtriser cette subtilité?
2) Cette subtilité existe-t-elle sur les autres cartes graphiques par la même maîtrise?

La subtilité en question c'est que je peux écrire à l'écran de 2 manières selon que j'écrive sur l'un ou l'autre buffers:
Sur le premier, l'accès est classique (pixels rangés de gauche à droite formant des lignes de haut en bas)
Sur le second buffer, je peux écrire par "tile" de 8x8 pixels (dans le tile, c'est rangé toujours de gauche à droite formant des lignes de haut en bas et les tiles sont eux-même rangés de gauche à droite formant des lignes de haut en bas)

A la volée... Tu connais cette subtilité? C'est plus ou moins standard ou pas?

[djes]

Je pense que l'erreur que le gars a faite c'est de considérer que les processeurs graphiques évolueraient moins rapidement que les processeurs centraux, ce qui me semble faux, non?

Ouch! Je ne suis pas doué pour la divination, je peux juste exprimer un avis en me basant sur mon expérience. Tant que les processus graphiques se limitaient à la conversion d'un signal numérique en un signal analogique, les capacités d'affichage étaient conditionnées par les limites de l'électronique, notamment le rafraichissement de la mémoire centrale qui devait correspondre au signal d'horloge de l'affichage. Il fallait que tout soit synchrone, le processeur, la mémoire, la carte graphique. Par la suite sont venus s'intercaler des processeurs spécialisés, et on a désynchronisé l'affichage et sa mémoire (qui est devenu spécialisée), et on a intercalé un bus. Dans ce schéma, le processeur est réduit au rôle de commandement.

Là où intervient une grande révolution, c'est à l'apparition des shaders, et du développement multi-processeurs. Apparemment, cela n'a pas vraiment bouleversé les choses, et à part quelques applications, on reste la plupart du temps dans un schéma classique assez linéaire. Sauf qu'en y regardant bien, le paradigme objet s'est développé en parallèle. Il y a donc une évolution de la pensée dans tous ces secteurs, mais le rapprochement n'est pas encore achevé.

Au niveau industriel, les délais de fabrication de nouvelles architectures sont assez longs, mais l'aspect technologique n'est pas tout : l'aspect commercial prime. A moins de vouloir faire une petite révolution dans le milieu pour s'imposer, les constructeurs essayent de proposer une technologie dans l'ère du temps, de façon à s'assurer une marge suffisante et à rentabiliser leurs investissements dans la recherche. Cela s'est confirmé (pour moi) avec l'abandon de Larabee par Intel : technologie trop en avance sur son temps. Pour moi il y a clairement une entente chez les constructeurs proc/graphique et on ne peut plus compter sur la concurrence pour changer les choses. Tout cela pour dire que l'évolution des secteurs processeur graphique/processeur central est intrinsèquement liée, et qu'on imagine mal une compagnie dédire son entente pour s'imposer. Cependant, je pense à plus ou moins long terme à une réunification.

L'avenir lointain, bien sûr, c'est un fonctionnement de plus en plus semblable aux modèles existant autour de nous, les plus évolués étant ceux de la nature, donc du cerveau (pas forcément celui humain qui n'est pas très bon dans certains domaines). On voit qu'à partir d'éléments semblables, chaque partie se développe et se spécialise. Le parallélisme repose non seulement sur des milliards de connexions dynamiques, mais sur des transmissions analogiques et donc hautement asynchrones et cumulables, tant en communication qu'en opérations. Sans compter tout ce qui reste à découvrir, notamment en effets "quantiques" et dont ne faisons qu'effleurer les possibilités. Le siège de la pensée lui-même (vaste sujet), est-il centré dans un secteur particulier? Apparemment, non, et tout me laisse à croire que la pensée va autant dans le siège de la mémoire visuelle que dans la vision instantanée, le tout en "3d", tant dans le temps que dans l'espace!

Pour résumer : évolution en parallèle, réunification par la parallélisation, dans un premier temps par de multiples étages de "démultiplication" (programme maître->threads->"shaders"->mémoire graphique) ; à terme parallélisation complète (programme maître -> liaison permanente (mais dynamique) entre objets "tâche", dont l'affichage)

Pour le lien vers wiki, j'essaierai de trouver du haut débit pour lire les sous-liens. En attendant, j'ai déjà découvert une subtilité sur ma carte graphique. Et les 2 grandes questions que je me pose, c'est:
1) Comment maîtriser cette subtilité?
2) Cette subtilité existe-t-elle sur les autres cartes graphiques par la même maîtrise?

La subtilité en question c'est que je peux écrire à l'écran de 2 manières selon que j'écrive sur l'un ou l'autre buffers:
Sur le premier, l'accès est classique (pixels rangés de gauche à droite formant des lignes de haut en bas)
Sur le second buffer, je peux écrire par "tile" de 8x8 pixels (dans le tile, c'est rangé toujours de gauche à droite formant des lignes de haut en bas et les tiles sont eux-même rangés de gauche à droite formant des lignes de haut en bas)

A la volée... Tu connais cette subtilité? C'est plus ou moins standard ou pas?

Comment as-tu découvert cette subtilité? Quelquefois Windows s'intercale par l'utilisation de formats bizarres. J'ai plus l'habitude des rangements dans le genre BGR vs RGB etc, mais tout est possible! Je me souviens du temps des cartes CGA Hercules, des consoles, C64, CPC etc avec leur affichage par caractère... On n'est jamais à l'abri des fantaisies d'un électronicien!

[Ollivier]

Salut!

L'avenir lointain, bien sûr, c'est un fonctionnement de plus en plus semblable aux modèles existant autour de nous, les plus évolués étant ceux de la nature, donc du cerveau (pas forcément celui humain qui n'est pas très bon dans certains domaines). On voit qu'à partir d'éléments semblables, chaque partie se développe et se spécialise. Le parallélisme repose non seulement sur des milliards de connexions dynamiques, mais sur des transmissions analogiques et donc hautement asynchrones et cumulables, tant en communication qu'en opérations. Sans compter tout ce qui reste à découvrir, notamment en effets "quantiques" et dont ne faisons qu'effleurer les possibilités. Le siège de la pensée lui-même (vaste sujet), est-il centré dans un secteur particulier? Apparemment, non, et tout me laisse à croire que la pensée va autant dans le siège de la mémoire visuelle que dans la vision instantanée, le tout en "3d", tant dans le temps que dans l'espace!

ça c'est une partie complètement inutile mais que j'aime complètement!

Comment as-tu découvert cette subtilité?

Ben, avec le code SSE que j'ai balancé plus tôt dans ce sujet. Pour le créer, j'ai été assez méthodique en y allant petit à petit, car, justement, ça partait un peu un quenouille, sans toutefois être complètement illogique.

J'ai l'impression qu'un traitement SSE c'est comme l'eau sous bonne pression et haut débit dans un tuyau de pompier. Et que Fred, a son insu, a défini un pompier particulier pour traiter la paire de buffers. Et que, vu que j'utilise un transfert SSE, le pompier change de main d'un buffer à l'autre. Sur un buffer, c'est "classique" et sur l'autre c'est "tilisé en 8x8".

Si c'est standard, je crois que je pourrais appeler cela une "véritable" accélération vidéo, les instructions de transfert de chaîne n'astreignant pas le CPU. Mais bon... C'est peut-être standard sur les GPU internes seulement, je n'en sais rien.

J'ai un GPU nommé VIA Chrome9 HC3 IGP interne avec 64méga partagés.

C'est dommage, je n'ai pas le temps de faire un code de suite pour te montrer. Juste récupère le chouilla de code que j'ai mis en dernier et réduis la boucle à seulement quelques pixels au lieu de tout l'écran: chez moi, c'est étrange. J'ai vraiment un accès mémoire différent selon le buffer traité...

[Ollivier]

Tiens, regarde! J'ai modif le code pour qu'on le voit. Si c'est trop rapide, augmente la valeur du délai dans la boucle, ou crée une sous-boucle si tu es en multi-core. (C'est sous Windows, je ne sais pas si ce code marche sous Linux).

Chez moi, le buffer "bleu" s'affiche par Tiles 8x8 alors que le buffer "rouge" s'affiche de manière "classique" (ligne par ligne).

(Attention, ça fait mal aux yeux...)

Code : Tout sélectionner

;
; ------------------------------------------------------------
;
;   PureBasic - Drawing via Direct Screen Access (DSA) 
;
;    (c) 2006 - Fantaisie Software
;
; ------------------------------------------------------------
;
; Note: disable the debugger to run at full speed !
;
; La note d'Olliv : ai modifié l'écriture VIDEO pour tester
; l'instruction SSE qui ne suffit malheureusement pas...
; * Ai ralenti pour observer les tiles 8x8

      ExamineDesktops()
      ScreenWidth  = DesktopWidth(0)
      ScreenHeight = DesktopHeight(0)
      ScreenDepth = DesktopDepth(0)

      InitSprite()
      InitKeyboard()

Structure Pixel
  Pixel.l
EndStructure

Procedure.f GSin(angle.f)
  ProcedureReturn Sin(angle*(2*3.14/360))
EndProcedure

; Pre-calculated values are faster than realtime calculated ones...
; ... so we save them in an array before starting gfx operations
Dim CosTable(ScreenWidth*2)
Dim ColorTable(255)

For i = 0 To ScreenWidth*2
  CosTable(i) = GSin(360*i/320)* 32 + 32
Next
OpenWindow(0,0,0,400,300,Str(ScreenWidth) + " x " + Str(ScreenHeight) + " x " + Str(ScreenDepth) , $CF0001)
StringGadget(1, 10, 10, 350, 24, "Fenêtre de déboguage (Alt+F4 pour fermer)")

If OpenScreen(ScreenWidth, ScreenHeight, 32, "PB Plasma")

  StartDrawing(ScreenOutput())
        Buffer1     = DrawingBuffer()             ; Get the start address of the screen buffer
        Pitch       = DrawingBufferPitch()        ; Get the length (in byte) took by one horizontal line
        PixelFormat = DrawingBufferPixelFormat()  ; Get the pixel format. 
  StopDrawing()
  FlipBuffers()
  StartDrawing(ScreenOutput())
        Buffer2     = DrawingBuffer()             ; Get the start address of the screen buffer
        Pitch       = DrawingBufferPitch()        ; Get the length (in byte) took by one horizontal line
        PixelFormat = DrawingBufferPixelFormat()  ; Get the pixel format. 
  StopDrawing()
  FlipBuffers()
  
*Alloc = AllocateMemory(32)
*Alloc + 15
*Alloc & ~15

For I = 0 To 15 Step 4
      PokeL(*Alloc + I, $FF007FFF)
Next

Define Count.L
Define Sourc.L = *Alloc  
Define Desti.L = Buffer1
Define Desti2.L

;Count = Pitch * ScreenHeight / 16     / 2 / 2
Count = 0

      Repeat
            Count + 1
            Delay(16)
            
            
            Flip ! 1
            If Flip
                  Desti = Buffer1
                  Desti2 = (Desti + Count * 16)
                  Desti3 = (Desti2 + Count * 16)
                  Desti4 = (Desti3 + Count * 16)
                  For I = 0 To 15 Step 4
                        PokeL(*Alloc + I, $FF007FFF)
                  Next
            Else
                  Desti = Buffer2
                  Desti2 = (Desti + Count * 16)
                  Desti3 = (Desti2 + Count * 16)
                  Desti4 = (Desti3 + Count * 16)
                  For I = 0 To 15 Step 4
                        PokeL(*Alloc + I, $FFFF0000)
                  Next
            EndIf
        

            !     Mov         ESI,        [v_Sourc]
            !     Movaps      XMM0,       [ESI]
            !     Movaps      XMM1,       [ESI]
            !     Movaps      XMM2,       [ESI]
            !     Movaps      XMM3,       [ESI]
            !     Mov         ECX,        [v_Count]
            !     Mov         EDI,        [v_Desti]
            !     Mov         EDX,        [v_Desti2]
            !     Mov         EAX,        [v_Desti3]
            !     Mov         EBX,        [v_Desti4]
            !Loop1:
            !     Movaps      [EDI],      XMM0
            !     Movaps      [EDX],      XMM1
            !     Movaps      [EAX],      XMM2
            !     Movaps      [EBX],      XMM3
            !     Add         EDI,        16
            !     Add         EDX,        16
            !     Add         EAX,        16
            !     Add         EBX,        16
            !     Dec         ECX
            !     Jnz         Loop1        

    
            ExamineKeyboard()
    
            FlipBuffers()
     
      Until KeyboardPushed(#PB_Key_Escape)
      
CloseScreen()
;SetWindowTitle(0, Str(Align) + " " + Str(PitchEqu) )
Repeat
Until WaitWindowEvent() = 16

Else
  MessageRequester("Error","Can't open the screen !",0)
EndIf

End

[djes]

Ici, ça ne le fait pas, même en changeant les valeurs du delay. J'ai modifié aussi cette ligne

Code : Tout sélectionner

If OpenScreen(ScreenWidth, ScreenHeight, 32, "PB Plasma", #PB_Screen_NoSynchronization)

De façon à mieux voir en direct l'opération d'écriture. On pourrait aussi utiliser le code de synchro que j'ai posté il y a quelques mois.
J'ai plusieurs idées pour ton affichage qui se fait par blocs, dont la première qui rejoint un peu la tienne :

• la taille des données balancées par le CPU et la capacité du bus ou du GPU n'est pas adéquate : comme le SSE est une sorte de mode "rafale", les données ne peuvent toutes être "digérées" d'un coup, peut être qu'il y a une microseconde de délai qui intervient tous les n pixels.
• le GPU qui gère par "paquets" les données qui lui arrivent, peut-être avec une sorte de mémoire tampon.
• un décalage d'alignement entre les données ; une microseconde de délai pourrait survenir pour procéder à un décalage des données pour les réaligner.

[Ollivier]

Ici, ça ne le fait pas

Ah! C'est intéressant ça. ça indique que ça n'est pas très standard. Et quel processeur graphique as-tu? Est-il interne?

[case]

le truc des blocs de 8x8 c'est pas rapport a la compression dxt ?


un truc de ce genre non ?

http://www.onversity.com/cgi-bin/progar ... =a0103#030

[djes]

Tiens, case, tu as peut-être mis le doigt dessus. DirectX intercepterait les appels à la mémoire graphique alors. Possible, surtout avec PB sous DX9, où tout est géré en 3D!
Sinon j'ai un E8400 avec une ATI Radeon HD 4600.

[Ollivier]

@Case

Oui, c'est intéressant ton article. Même si je comprends pas les tenants et les aboutissants pour l'instant.

[Ollivier]

J'ai trouvé cette page qui est bindée de noms de GPU et de fonctionnalités respectives (c'est suite à ton lien wiki graphic hardware) mais pas le moindre source et pas mal de pages qui ne s'ouvrent pas.

Quand tu parles des registres internes à une CG, tu n'as pas une page Internet qui en touche 2 mots sur un ou plusieurs modèles?

[djes]

http://www.osdever.net/papers/, là http://geezer.osdevbrasil.net/osd/graphics/index.htm
ou plus généralement sur http://forum.osdev.org