Upload pixels pour rendu soft

[ponce]

Bon voilà, j'aimerais bien faire du rendu soft et je me demande par quel moyen envoyer les pixels le plus rapidement possible.

- OpenGL PBO
- glDrawPixels ou glTexImage2D
- un objet DirectX 9 qui servirait à ça
- GDI ou GDI+ ou SDL ou SFML
- WPF
- un rendu hard DirectShow avec le décodeur de la CG
- ?

Il faudrait dans l'idéal que ça marche vite en 1920x1080
Est-ce que quelqu'un sait quelque chose là dessus ? (sur IRC on m'a dit dx9 mais j'aimerais avoir d'autres avis)
A votre avis ca serait quoi le plus rapide et surtout qui stalle pas toute la carte ?
Est-ce que c'est même possible ?

[ponce]

fquake utilise DirectDraw
http://users.skynet.be/fquake/

EDIT: apparemment cette librairie (par le mec de gafferongames) est faite exprès pour ça
http://code.google.com/p/pixeltoaster/

[latortue]

pixeltoaster est effectivement "la suite" de TinyPTC qui elle aussi était destinée à l'affichage de pixels.

[krabob]

 en rendu software avec le CPU, et des gros bitmap avec des grosse résolution en RGB, fait surtout gaffe aux caches: dés qu'un bitmap dépasse une taille de cache, les perfos s'effondrent. rendre "tuille par tuile" différentes parties du bitmap (ou barre horizontale par barre horizontale ), une fois pour toute par frame est une bonne idée.
 Faire plusieurs passes de "layer" sur tout le bitmap: pas glop en cpu.

[romain]

Yeep! PixelToaster c'est pas mal, c'est juste un framebuffer comme à l'ancienne Et puis c'est multi-plateforme.

[ponce]

En fouillant un peu, je vais rester sur SDL 1.2 qui a un rendu DirectDraw et un autre GDI, on peut overrider la sélection avec une variable d'environnement.

@krabob: effectivement je compte essayer quelque chose en une passe, après ça serait des updates de tout le buffer à chaque frame. Celà dit, rendre en tilé devrait aider les caches en effet.

Dans l'idéal j'aimerais générer voire uploader les pixels en espace couleur pas RGB avec chroma subsamplée pour prendre moins de place.

[LittleWhite]

On pourra voir le résultat ? Car je suis un peu étonné sur ce que vous voulez faire (et je n'ai pas vraiment compris le pourquoi).

[ponce]

Quand ça sera fini.

[krnl]

- glDrawPixels: A oublier, y'a rien de pire, meme avec une resolution de 320x240 ca rame
- glTexImage2D: Personnellement, j'ai jamais eu de soucis particulier avec, apres j'ai pas tenté de pousser les perfs a l'extreme
- SDL: De meme
- GDI: C'est pas trop mal pour un simple affichage mais c'est tres vite limite, alors en 1920x1080, j'ose meme pas imaginer.
- TinyPTC: J'en avait beaucoup entendu parler a l'epoque, on me l'avait conseillé en tant qu'alternative de GDI mais jamais testé.

[ponce]

Note pour SDL: placer la variable SDL_VIDEODRIVER à "directx" permet d'avoir un back-end Direct Draw 5 (OOOOLD ), de base desactivé, qui donne un avantage marginal mais bon.

En fait j'ai l'impression que SDL accelère en hard que si on crée une surface SDL_HARDWARE, en fullscreen, avec ce driver là.

Ce que j'ai fait pour le moment c'est threader le rendu soft pour faire juste un memcpy dans le buffer de l'écran quand il faut, du coup c'est pas trop le bottleneck. Pas encore testé les overlay YUV hardware avc le driver "directx", en tout cas en soft ça n'avait pas vraiment d'avantage.

[LittleWhite]

Vous parlez de quelle version de la SDL, la 1.2 ou 1.3 ?

[maracuja]

a mon avis la 1.2 car la 1.3 utilise directgraphics non?

[ponce]

Oui 1.2.14.

[nystep]

Je me demandais bêtement si simplement un glTexSubImage2D ça passerai niveau perfs? J'avoue que je ne sais pas trop, je n'ai jamais codé de streaming de texture/video donc...   

[ponce]

Surement que si, après c'est comme pour les VBO, difficile de savoir quand c'est double-bufferisé.