demo26 d'ExtGraph... - Page 1

Salut à tous !

Certains d'entre vous se souviennent peut-être que j'ai fait un programme kernel-based (si si !), à l'origine pour faire un bench ExtGraph / graphlib. Il est kernel-based, parce qu'utiliser un loader de lib dynamique kernel-based pour programme AMS native (il me semble que PpHd a fait ça pour je ne sais plus quel programme) n'est pas une solution très satisfaisante pour un petit bench de quelques kilo-octets.

A une époque, j'avais perdu le source et les binaires, et ce gros vilain de Flanker n'en avait pas gardé de copie - honte éternelle à lui pour ne pas avoir gardé une copie du morceau historique que constitue un programme kernel-based de TICT, non mais - mais j'ai fini par retrouver le source à un endroit où je ne m'y attendais pas, et je l'ai ajouté dans les demos d'ExtGraph, pour ne pas le perdre.

Depuis que je l'ai retrouvé, le source a subi des modifications. Je ne sais plus quelle en est l'étendue exacte, mais je sais que j'ai ajouté l'infrastructure pour faire un bench, aussi juste que possible, de Genlib. Il faut que les mêmes fonctions soient testées, mais s'il y a lieu de prendre en compte des spécificités de Genlib (c'est probable), il faut les prendre en compte.
Les modifs n'ont jamais été finies, par manque de temps et de connaissance de Genlib.

Je souhaiterais "finir" ce programme, et notamment résoudre notamment une bonne fois pour toutes, un problème de headers pour la compilation de ce programme, écrit en pur assembleur, syntaxe A68k.
En tête de ce programme (les releases officielles sont tellement dépassées que seul le SVN est valide, http://opensvn.csie.org/ExtGraph/trunk ), j'ai marqué:

; INCLUDE "os.h"
; The header in PreOS, recommended for kernel-based programming by PpHd ("os.h is outdated").
; I don't care whether it is supported by Kevin or not.
INCLUDE "tios.h"

Le commentaire reste à peu près valable, mais y a-t-il eu des progrès entre tios.h et os.h pendant les 11-12 mois où je n'ai pas participé à la communauté (c'est beau de rêver, mais pourquoi pas...) ?

D'autre part, pourriez-vous me faire le code d'un bench aussi équitable que possible de Genlib (ce qui peut conduire à modifier le code du reste du bench, y compris l'ajout de grayscale et/ou doublebuffering - si besoin est, ExtGraph contient une routine de grayscale qui alloue toujours deux plans consécutifs dans la mémoire, même sur HW1) ? Attention, il ne faut quand même pas que ça prenne trop de temps à écrire et que ça soit au détriment de vos propres projets intéressants
Pour le moment, on reste sur le feature set déjà présent, mais je suis ouvert aux suggestions (on en discutera en public ici).

Je me fiche qu'au bout du compte, ExtGraph soit plus rapide ou moins rapide que Genlib. Genlib, disposant de fonctions optimisées pour le grayscale, peut très bien être plus rapide qu'ExtGraph, où il faut (peut-être - il y a plus de fonctions bi-plan que dans les releases précédentes) lancer deux fois la même fonction mono-plan pour obtenir le résultat voulu, ce qui aura un coût en termes de performance. Je ne ferai pas de news spéciale indiquant les performances relatives des libs

A noter qu'à un moment, demo26 ne tournait pas sur PedroM:
; We need AMS 2.xx due to push_ulong_to_integer, which defacto prevents
; PedroM from running this program, until PpHd implements that function.
cmpi.l #$4E4,-4(a5)
blt _end
tst.l $4E4*4(a5)
beq _end
Je ne sais pas si cette fonction manque toujours, mais elle est facile à implémenter.



Merci de m'avoir lu jusqu'au bout (bah oui, on ne se refait pas, les posts où j'ai quelque chose à dire sont toujours aussi longs ) !

Welcome back Lionel ^^

Content de voir que tu vas bien

(par contre je peut pas trop t'aider pour #0...)

J'pourrai pas t'aider sur ce coup-là, mais comme ./2 : WB Lionel

Merci

En tout cas :

Lionel Debroux :
Le commentaire reste à peu près valable, mais y a-t-il eu des progrès entre tios.h et os.h pendant les 11-12 mois où je n'ai pas participé à la communauté (c'est beau de rêver, mais pourquoi pas...) ?

Vu l'activitée de la communauté depuis ce temps, je pense pouvoir dire que cela n'a pas du tout evolué sur ce point... c'est malheureux a dire mais bon...

Oui, je me suis rendu compte que l'activité avait baissé...

>We need AMS 2.xx due to push_ulong_to_integer, which defacto prevents
> PedroM from running this program, until PpHd implements that function.

Aucune idée. Je me rappelle plus.


>Le commentaire reste à peu près valable, mais y a-t-il eu des progrès entre tios.h et os.h pendant les 11-12 mois où je n'ai pas participé à la communauté (c'est beau de rêver, mais pourquoi pas...) ?

Je crois pas.

Et c'est depuis quand que c'est sous LGPL ?

ExtGraph est sous licence duale LGPL/ancienne licence ("faire n'importe quoi avec le source, mais pas dans des programmes commerciaux - et please give credit, même si ce n'est pas obligaoire") depuis des mois, mais seulement dans le trunk SVN.
Aucune version releasée officiellement n'est sous LGPL (mais c'est pas grave, car aucune version releasée officiellement n'est supportée, vu l'énorme différence trunk/Beta 4-1).

Pour ton bench, le truc qui fausse un peu les données, c'est que genlib gère les niveaux de gris toute seule, ce qui n'est pas le cas d'extgraph qui laisse le choix de la lib de niveaux de gris à l'utilisateur... Donc si tu utilises extgraph + tigcclib tu n'auras probablement pas les même résultats que si tu utilises extgraph + grib (par exemple ).

Cela dit, il me semble que PpHd avait écrit un bench qui doit être dans un des packs de genlib...
[edit] Après vérification, le bench (c'était un bench genlib/extgraph/xlib) n'est plus dans la dernière version de genlib...

[HS]
En parlant de benchs, quelqu'un aurait un bench de routines on-calc assez fiable parce-que les seuls que j'ai trouvé jusqu'à present ne sont que de l'ordre 0.05s et donc pas suffisement precis pour des "petites" routines ? #pourvu_que_ca_existe#
[/HS]

Un bench de routines on-calc ? C'est-à-dire ?

Oh bah pas un truc tres compliqué mais un truc du genre ticktest qui calcule a 0.05s pres le temps qu'a mis un programme a s'executer
Sauf que là ce serait plutot un ordre de 0.001s dont j'aurait besoin
Sinon il doit bien y avoir une méthode pour faire ca dans mon source en "encadrant" directement la routine concernée mais là je crois que qu'il me faudrai developper un tit truc adapté pour mon cas A moins que ca ai deja été fait #trilovereve#

tu auras une précision meilleure en exécutant ton code plusieurs fois
genre tu exécute 1000 fois (avec une boucle, par exemple), tu tu divises le temps par 1000 ; ça devrait te donner une estimation plus précise qu'en n'exécutant qu'une seule fois

Ah ouais pas bete j'y avait pas pensé
Bah c'est la solution la plus simple, la plus rapide et la plus precise alors je prend ^^
Merci encore Et dsl pour le HS

Il y a plusieurs solutions envisageables (et combinables) pour faire des timers assez précis:
* moyenner les résultats sur plusieurs exécutions / exécuter de nombreuses fois. Simple et efficace
* le taux de l'AI5 est programmable jusqu'à 8 KHz (c'est ce qu'utilise PolySnd).
* l'AI1 est à 256 Hz assez précis sur HW2, mais sa fréquence est mal définie et peu précise sur HW1.

De toute façon, il ne faut pas regarder les valeurs à deux chiffres après la virgule, même en prenant des valeurs précises: les réglages de reset (0xCC sur 0x600017 sur une HW2 et je ne sais plus quel multiplieur ailleurs) donnent une AI5 à 19.32 Hz sur HW2 (le calcul sur HW1 se fait de la même façon). Si on prend 20 Hz, on commet une erreur de plusieurs pourcents. La valeur 0xCE donne un timer dix fois plus proche de 20 Hz (~20.07 Hz).
Pour des processus qui se passent plusieurs milliers de fois par seconde (type routine de sprite), seuls les deux chiffres de gauche (milliers, centaines) sont _vraiment_ significatifs. Pour des processus qui se passent quelques dizaines de fois par seconde, les chiffres après la virgule n'ont pas grande importance.

Ah vi effectivement j'viens de voir ca... Les unités c'est meme pas la peine d'en parler ca oscille tout le temps
Merci Lionel pour la precision

Rassurez-vous, Kevin lit toujours les forums concurrents... Voir le nouveau message dans:
http://p080.ezboard.com/ftichessteamhqfrm5.showMessage?topicID=3176.topic

Naturellement, personne ne pourra aller dire le contraire là-bas, puisque le topic est fermé
[EDIT: il ne peut d'ailleurs pas venir poster ici non plus, mais il a fait ce qu'il faut pour...]

Il me semble que j'avais eu des problèmes avec os.h, mais je ne sais plus quoi, ça date... [EDIT: Je ne pense pas que je me serais amusé à changer de header aussi facilement si je n'avais pas eu de problèmes, car il me semble que ça nécessite de réécrire des trucs dans le code.

Ajouter les définitions des ROM_CALLs AMS 2.xx dans le header tios.h est trivial, mais il se peut qu'il y ait une raison pour que ça n'ait pas été fait.
]

Oui enfin les bench de Xlib son dépassé puisque la dernière version gérait le triple buffering qui bouste pas mal les performances.
Enfin c'était il y a longtemps (et ne me demandez pas ou est xlib j'en sais rien lol)

Tu parles de la technique qui consiste à échanger des pointeurs plutôt que recopier les plans ?

Nan, mais d'une technique qui utilise trois paires de plans plutôt que deux, ce qui évite d'attendre la synchro bêtement en ne faisant rien.

OK, on avait presque la même. il y avait donc une recopie dans sa technique : le plan prêt à être affiché était copié dans le buffer de la routine de NDG, qui lui-même était recopié dans l'écran par la routine. C'est ça ?

oui, la fonction de recopiage étant partagée avec la librairie ce qui évitait d'avoir 2 fois la même fonction (il en a fallu du temps pour que kk comprenne ca ).
Pour l'échange des pointeurs ca ne marchait que sur HW1 il me semble non?

Heu en plus je crois que cette technique la ct toi qui l'avait inventé dans graphx il me semble

oui j'ai des distants souvenirs d'avoir lu de longs trolls parce que jesaipluquelle lib recopiait les plans au lieu de faire du vrai triple buffering

ha le bon vieux temps, et le nombre de conneries qui ont été écritent

Oui c'est net

On ne saura jamais qui a inventé la technique en premier, mais je crois qu'on n'avait pas tout à fait la même : tu recopiais le buffer intermédiaire de XL dans le buffer de TIGCC me semble-t-il. GraphX traffiquait carrément la lib de TIGCC : la routine de TIGCC venait directement lire le plan intermédiaire de GX au lieu de lire son propre plan (GX faisait donc un simple échange (hack) de pointeurs au lieu d'une recopie).

Au final, aucune de nos deux libs n'a beaucoup été utilisée je crois. C'est très dommage, je trouve que notre idée de triple-buffering était assez géniale sur cette platerforme où le moindre gain de temps est bon à prendre.

heu non j'utilisai la même méthode que toi (et ce devait être toi qui me l'avait expliquée...).
En gros une copie par tiers vers lcdmem ce devait etre tout.

OK !

Perso, j'ai toujours trouvé que le triple buffering était une fausse bonne idée

Why ?
Ca enlevait le temps d'attente de la synchro et le temps de copie.