Quelle config PC pour la photo. Proposition de cahier des charges
121 réponses
Fred le Barbu
Bonjour,
décidément, que de temps à attendre devant le PC lorque qu'on est en train
de à classer, "développer", corriger, diffuser, imprimer, -bref traiter- ses
photos numériques (remarquez, c'était bien pire dans la chambre noire, du
temps ingrat de l'argentique) !
Je n'ai pas très envie de changer de soft et mon PC n'est plus dans sa
première jeunesse (Athlon XP 2600+, 1 Go, avec une CG sur bus AGP2 et des
disques ATA): c'est lui que je songe à remplacer. (au fait vais-je vraiment
pouvoir trouver beaucoup beaucoup plus eficace ?)
Je souhaite utiliser Lightroom et Photoshop notamment. Mon APN est un 10 MP
qui me donne des RAW 12 bits. Je garde environ 3000 photos chaque année, en
déclenchant 3 fois plus. sans parler de scans, d'environ 12 MP 16 bits.
La question est quelle configuration acheter ?
J'ai essayé de contribuer à ce sujet en tentant de rédiger un petit cahier
des charges. Vous parait-il cohérent et complet ? Quels sont les éléments
critiques à privilégier ? Quelles sont les références des composants
matériels qui y répondent ?
Ce qui me parait critique:
1. Visualiser rapidement les photos les unes après les autres => disque
rapide + transfert vers carte mère rapide + CPU rapide + bus carte graphique
rapide ?
2. Pouvoir zoomer, dézoomer rapidement sur plusieurs photos à la suite, par
exemple pour évaluer la netteté de plusieurs photos => gros CPU ? mémoire
vive rapide + grosse capacité ?
3. Pouvoir visualiser rapidement l'effet de telle ou telle correction sur la
photo (par exemple dans le menu développement de lightroom) => gros CPU ?
mémoire vive rapide ?
4. Grosse capacité de stockage, fiable (le format raw prend de la place +
avec Toshop j'ai fréquemment des fichier de 200 Mo) => un gros disque ou
plusieurs moins gros ?
Mais aussi:
5. Des traitements par lots pas trop lents (mais là, c'est moins important,
car on peut aller faire autre chose pendant que ça mouline) => gros CPU ?
6. Un bon affichage (je ne pense pas changer mon écran 1280x1024 pour le
moment, mais quand ça sera abordable, j'achèterai un écran capable
d'afficher 4 ou 5 Mpixels), j'ai une sonde de calibration. La carte
graphique a-t-elle un influence sur la qualité de l'affichage ?
7. Possibilité d'ajouter un petit écran (le petit pour les menus, le grand
pour les images plein écran). Au fait, est-ce que c'est une bonne idée ?
8. Des capacités de sauvegarde => Là, j'ai l'impression qu'on est dans le
difficile. j'aurai tendance à penser à un autre gros disque, externe ou non,
mais bon, c'est cher et "peu évolutif"
9. Du silence ! Existe-t-il des alim silencieuses mais abordables ?
10. La configuration devrait être basée sur des standards qui ont un peu
d'avenir pour pouvoir faire évoluer le PC quand il y en aura besoin
11. Et bien sûr, tout le reste indispensable aujourd'hui: ethernet, Wifi,
plein de USB, etc ?
12. Avec un petit plus (mais ça n'a rien à voir avec notre sujet): un bon
convertisseur numérique /analogique audio pour une restitution de la musique
de bonne qualité.
Remarque: je ne pense pas utile d'acheter le top du top hyper cher. Sauf
peut-être si les derniers composants sortis permettent vraiment de franchir
une marche importante. Et encore, il suffit souvent de patienter quelques
mois qu'ils se démocratisent.
Questions complémentaires probablement utiles pour répondre au cahier des
charges précédant:
La puissance de la carte graphique a-t-elle un impact ? (vitesse et quantité
de mémoire)
Lightroom exploite-t-il le multicore (quelles versions de LR) ?
Lightroom exploite-t-il le 64 bits (quelles versions de LR) ?
Pour l'OS: XP ou Vista ?
J'ajoute que je compte -à priori- assembler le PC (ou le faire assembler) à
partir des éléments répondant à mon besoin spécifique.
Donc, selon vous:
quel processeur ?
quelle RAM (et quantité)
quelle carte mère ?
quel disque (vitesse, marque, capacité)
quelle carte graphique ?
et aussi:
quel alim, quel boitier, quel moyen de sauvegarde, etc...
Merci d'avoir pris le temps de lire ce long message.
Et merci de vos réponses, qui intéresseront un grand nombre de photographes.
Ben j'ai des collègues qui ont au moins implémenté le décodage sur des procs qui n'ont pas de flottants :)
se faire en virgule fixe le jpg..
c'est quoi la "virgule fixe" ?
http://fr.wikipedia.org/wiki/Virgule_fixe
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
Sylvain SF <sylvain@boiteaspam.info> wrote:
FiLH wrote on 13/06/2008 21:14:
il me semblait que ça pouvait
source ? implémentation de référence ?
Ben j'ai des collègues qui ont au moins implémenté le décodage sur des
procs qui n'ont pas de flottants :)
se faire en virgule fixe le jpg..
c'est quoi la "virgule fixe" ?
http://fr.wikipedia.org/wiki/Virgule_fixe
FiLH
--
Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire
une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle.
Roland Barthes.
http://www.filh.org
Ben j'ai des collègues qui ont au moins implémenté le décodage sur des procs qui n'ont pas de flottants :)
se faire en virgule fixe le jpg..
c'est quoi la "virgule fixe" ?
http://fr.wikipedia.org/wiki/Virgule_fixe
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
Sylvain SF
FiLH wrote on 14/06/2008 09:38:
Sylvain SF wrote:
FiLH wrote on 13/06/2008 21:14:
il me semblait que ça pouvait source ? implémentation de référence ?
Ben j'ai des collègues qui ont au moins implémenté le décodage sur des procs qui n'ont pas de flottants :)
comme des ASIC, (mini)DSP ou circuits dédiés d'ASP ?
merci pour ces cas évidents mais le fil parle: d'utiliser le GPU d'une carte graphique plus ou moins évolué (plutôt plus) à la place du CPU (32 ou 64 bits, multi-core, mutli-ALU, multi-FPU).
se faire en virgule fixe le jpg.. c'est quoi la "virgule fixe" ?
http://fr.wikipedia.org/wiki/Virgule_fixe
et tu l'as lu ? cet encodage des flottants existe depuis +20 ans, il est toujours utilisé par les tous petits procs mais n'est utilisé par aucun proc. de PC et à ma connaissance aucun GPU qui utilise tous un format IEEE - certains vieux mini utlisent encore un format à eux mais ils sont tout aussi hors sujet dans cette discussion GPU vs CPU.
Sylvain.
FiLH wrote on 14/06/2008 09:38:
Sylvain SF <sylvain@boiteaspam.info> wrote:
FiLH wrote on 13/06/2008 21:14:
il me semblait que ça pouvait
source ? implémentation de référence ?
Ben j'ai des collègues qui ont au moins implémenté le décodage sur des
procs qui n'ont pas de flottants :)
comme des ASIC, (mini)DSP ou circuits dédiés d'ASP ?
merci pour ces cas évidents mais le fil parle: d'utiliser le GPU d'une
carte graphique plus ou moins évolué (plutôt plus) à la place du CPU
(32 ou 64 bits, multi-core, mutli-ALU, multi-FPU).
se faire en virgule fixe le jpg..
c'est quoi la "virgule fixe" ?
http://fr.wikipedia.org/wiki/Virgule_fixe
et tu l'as lu ? cet encodage des flottants existe depuis +20 ans,
il est toujours utilisé par les tous petits procs mais n'est utilisé
par aucun proc. de PC et à ma connaissance aucun GPU qui utilise tous
un format IEEE - certains vieux mini utlisent encore un format à eux
mais ils sont tout aussi hors sujet dans cette discussion GPU vs CPU.
il me semblait que ça pouvait source ? implémentation de référence ?
Ben j'ai des collègues qui ont au moins implémenté le décodage sur des procs qui n'ont pas de flottants :)
comme des ASIC, (mini)DSP ou circuits dédiés d'ASP ?
merci pour ces cas évidents mais le fil parle: d'utiliser le GPU d'une carte graphique plus ou moins évolué (plutôt plus) à la place du CPU (32 ou 64 bits, multi-core, mutli-ALU, multi-FPU).
se faire en virgule fixe le jpg.. c'est quoi la "virgule fixe" ?
http://fr.wikipedia.org/wiki/Virgule_fixe
et tu l'as lu ? cet encodage des flottants existe depuis +20 ans, il est toujours utilisé par les tous petits procs mais n'est utilisé par aucun proc. de PC et à ma connaissance aucun GPU qui utilise tous un format IEEE - certains vieux mini utlisent encore un format à eux mais ils sont tout aussi hors sujet dans cette discussion GPU vs CPU.
Sylvain.
Sylvain SF
François Jouve wrote on 14/06/2008 00:45:
source ? implémentation de référence ?
J'avais un gros doute vu ce que je savais de la norme jpg, mais comme tu me semblais tellement sûr de toi... En fait je viens de regarder les sources de la libjpeg http://freshmeat.net/projects/libjpeg/
Pas le moindre "double" !
vraiment ?
refais une recherche de "FAST_FLOAT", moi je trouve plus de 50 occurences.
sauf hard spécifique (ASIC) qui imposerait une algorithmie et un codage spécifiques, les diviseurs des table DCT sont toujours en flottant.
Sylvain.
François Jouve wrote on 14/06/2008 00:45:
source ? implémentation de référence ?
J'avais un gros doute vu ce que je savais de la norme jpg,
mais comme tu me semblais tellement sûr de toi...
En fait je viens de regarder les sources de la libjpeg
http://freshmeat.net/projects/libjpeg/
Pas le moindre "double" !
vraiment ?
refais une recherche de "FAST_FLOAT", moi je trouve plus de 50
occurences.
sauf hard spécifique (ASIC) qui imposerait une algorithmie et un codage
spécifiques, les diviseurs des table DCT sont toujours en flottant.
J'avais un gros doute vu ce que je savais de la norme jpg, mais comme tu me semblais tellement sûr de toi... En fait je viens de regarder les sources de la libjpeg http://freshmeat.net/projects/libjpeg/
Pas le moindre "double" !
vraiment ?
refais une recherche de "FAST_FLOAT", moi je trouve plus de 50 occurences.
sauf hard spécifique (ASIC) qui imposerait une algorithmie et un codage spécifiques, les diviseurs des table DCT sont toujours en flottant.
Sylvain.
François Jouve
Sylvain SF wrote:
François Jouve wrote on 14/06/2008 00:45:
source ? implémentation de référence ?
J'avais un gros doute vu ce que je savais de la norme jpg, mais comme tu me semblais tellement sûr de toi... En fait je viens de regarder les sources de la libjpeg http://freshmeat.net/projects/libjpeg/
Pas le moindre "double" !
vraiment ?
refais une recherche de "FAST_FLOAT", moi je trouve plus de 50 occurences.
Difficile d'admettre ses erreurs :) Donc FAST_FLOAT peut être une float ou un double selon que le compilo va plus vite avec l'un ou l'autre. C'est juste pour rendre plus efficace la librairie et en aucun cas pour des problèmes de précision des calculs :
/* FAST_FLOAT should be either float or double, whichever is done faster * by your compiler. (Note that this type is only used in the floating point * DCT routines, so it only matters if you've defined DCT_FLOAT_SUPPORTED.) * Typically, float is faster in ANSI C compilers, while double is faster in * pre-ANSI compilers (because they insist on converting to double anyway). * The code below therefore chooses float if we have ANSI-style prototypes. */
Aucun problème donc pour utiliser un GPU qui ne travaille qu'en simple précision.
Que va-t-il trouver comme argument de mauvaise foi maintenant ?
-- F.J.
Sylvain SF wrote:
François Jouve wrote on 14/06/2008 00:45:
source ? implémentation de référence ?
J'avais un gros doute vu ce que je savais de la norme jpg,
mais comme tu me semblais tellement sûr de toi...
En fait je viens de regarder les sources de la libjpeg
http://freshmeat.net/projects/libjpeg/
Pas le moindre "double" !
vraiment ?
refais une recherche de "FAST_FLOAT", moi je trouve plus de 50
occurences.
Difficile d'admettre ses erreurs :)
Donc FAST_FLOAT peut être une float ou un double selon
que le compilo va plus vite avec l'un ou l'autre.
C'est juste pour rendre plus efficace la librairie
et en aucun cas pour des problèmes de précision des
calculs :
/* FAST_FLOAT should be either float or double, whichever is done faster
* by your compiler. (Note that this type is only used in the floating
point
* DCT routines, so it only matters if you've defined DCT_FLOAT_SUPPORTED.)
* Typically, float is faster in ANSI C compilers, while double is
faster in
* pre-ANSI compilers (because they insist on converting to double anyway).
* The code below therefore chooses float if we have ANSI-style prototypes.
*/
Aucun problème donc pour utiliser un GPU qui ne travaille
qu'en simple précision.
Que va-t-il trouver comme argument de mauvaise foi maintenant ?
J'avais un gros doute vu ce que je savais de la norme jpg, mais comme tu me semblais tellement sûr de toi... En fait je viens de regarder les sources de la libjpeg http://freshmeat.net/projects/libjpeg/
Pas le moindre "double" !
vraiment ?
refais une recherche de "FAST_FLOAT", moi je trouve plus de 50 occurences.
Difficile d'admettre ses erreurs :) Donc FAST_FLOAT peut être une float ou un double selon que le compilo va plus vite avec l'un ou l'autre. C'est juste pour rendre plus efficace la librairie et en aucun cas pour des problèmes de précision des calculs :
/* FAST_FLOAT should be either float or double, whichever is done faster * by your compiler. (Note that this type is only used in the floating point * DCT routines, so it only matters if you've defined DCT_FLOAT_SUPPORTED.) * Typically, float is faster in ANSI C compilers, while double is faster in * pre-ANSI compilers (because they insist on converting to double anyway). * The code below therefore chooses float if we have ANSI-style prototypes. */
Aucun problème donc pour utiliser un GPU qui ne travaille qu'en simple précision.
Que va-t-il trouver comme argument de mauvaise foi maintenant ?
-- F.J.
Ofnuts
Sylvain SF wrote:
et tu l'as lu ? cet encodage des flottants existe depuis +20 ans, il est toujours utilisé par les tous petits procs mais n'est utilisé par aucun proc. de PC et à ma connaissance aucun GPU qui utilise tous un format IEEE - certains vieux mini utlisent encore un format à eux mais ils sont tout aussi hors sujet dans cette discussion GPU vs CPU.
Heu, la "virgule fixe" c'est juste une facon d'interpréter les bits, si je peux dire, mais quand on cause additions/multiplication, ça se fait avec un bête ALU qui sait traiter les entiers (si possible en 64 bits, mais on fait aussi en 32). Après, bien sûr, les instruction qu'on rencontre habituellement sur les ALU pour nombre flottants (trigo, log, exp, racine, puissance) sont rarement implémentées sur les ALU classiques pour entiers ce qui limite assez vite l'exercice, mais d'un autre côté, la restriction sur l'étendue des valeurs imposée par l'utilisation de virgule fixe fait qu'on ne s'en sert pas tant que çà (hors trigo).
-- Bertrand
Sylvain SF wrote:
et tu l'as lu ? cet encodage des flottants existe depuis +20 ans,
il est toujours utilisé par les tous petits procs mais n'est utilisé
par aucun proc. de PC et à ma connaissance aucun GPU qui utilise tous
un format IEEE - certains vieux mini utlisent encore un format à eux
mais ils sont tout aussi hors sujet dans cette discussion GPU vs CPU.
Heu, la "virgule fixe" c'est juste une facon d'interpréter les bits, si
je peux dire, mais quand on cause additions/multiplication, ça se fait
avec un bête ALU qui sait traiter les entiers (si possible en 64 bits,
mais on fait aussi en 32). Après, bien sûr, les instruction qu'on
rencontre habituellement sur les ALU pour nombre flottants (trigo, log,
exp, racine, puissance) sont rarement implémentées sur les ALU
classiques pour entiers ce qui limite assez vite l'exercice, mais d'un
autre côté, la restriction sur l'étendue des valeurs imposée par
l'utilisation de virgule fixe fait qu'on ne s'en sert pas tant que çà
(hors trigo).
et tu l'as lu ? cet encodage des flottants existe depuis +20 ans, il est toujours utilisé par les tous petits procs mais n'est utilisé par aucun proc. de PC et à ma connaissance aucun GPU qui utilise tous un format IEEE - certains vieux mini utlisent encore un format à eux mais ils sont tout aussi hors sujet dans cette discussion GPU vs CPU.
Heu, la "virgule fixe" c'est juste une facon d'interpréter les bits, si je peux dire, mais quand on cause additions/multiplication, ça se fait avec un bête ALU qui sait traiter les entiers (si possible en 64 bits, mais on fait aussi en 32). Après, bien sûr, les instruction qu'on rencontre habituellement sur les ALU pour nombre flottants (trigo, log, exp, racine, puissance) sont rarement implémentées sur les ALU classiques pour entiers ce qui limite assez vite l'exercice, mais d'un autre côté, la restriction sur l'étendue des valeurs imposée par l'utilisation de virgule fixe fait qu'on ne s'en sert pas tant que çà (hors trigo).
-- Bertrand
Sylvain SF
François Jouve wrote on 14/06/2008 15:45:
Difficile d'admettre ses erreurs :) Donc FAST_FLOAT peut être une float ou un double selon que le compilo va plus vite avec l'un ou l'autre. C'est juste pour rendre plus efficace la librairie et en aucun cas pour des problèmes de précision des calculs
non plutôt pour jouer sur le compromis temps / précision. un calcul en float aura moins de précision mais JPG étant une conversion destructive on peut s'autoriser cette perte.
* Typically, float is faster in ANSI C compilers, while double is * faster in pre-ANSI compilers (because they insist on converting * to double anyway).
ce point n'est plus tout à fait vrai, ce n'est pas tant le compilo que le CPU (les FPU du CPU) qui fait les calculs en précision supérieure aux types manipulés; et leur vitesse est aujourd'hui assez comparable en float ou double.
Aucun problème donc pour utiliser un GPU qui ne travaille qu'en simple précision.
Que va-t-il trouver comme argument de mauvaise foi maintenant ?
oh mais aucun pourquoi ?
Sylvain.
François Jouve wrote on 14/06/2008 15:45:
Difficile d'admettre ses erreurs :)
Donc FAST_FLOAT peut être une float ou un double selon
que le compilo va plus vite avec l'un ou l'autre.
C'est juste pour rendre plus efficace la librairie
et en aucun cas pour des problèmes de précision des
calculs
non plutôt pour jouer sur le compromis temps / précision.
un calcul en float aura moins de précision mais JPG étant
une conversion destructive on peut s'autoriser cette perte.
* Typically, float is faster in ANSI C compilers, while double is
* faster in pre-ANSI compilers (because they insist on converting
* to double anyway).
ce point n'est plus tout à fait vrai, ce n'est pas tant le compilo
que le CPU (les FPU du CPU) qui fait les calculs en précision
supérieure aux types manipulés; et leur vitesse est aujourd'hui
assez comparable en float ou double.
Aucun problème donc pour utiliser un GPU qui ne travaille
qu'en simple précision.
Que va-t-il trouver comme argument de mauvaise foi maintenant ?
Difficile d'admettre ses erreurs :) Donc FAST_FLOAT peut être une float ou un double selon que le compilo va plus vite avec l'un ou l'autre. C'est juste pour rendre plus efficace la librairie et en aucun cas pour des problèmes de précision des calculs
non plutôt pour jouer sur le compromis temps / précision. un calcul en float aura moins de précision mais JPG étant une conversion destructive on peut s'autoriser cette perte.
* Typically, float is faster in ANSI C compilers, while double is * faster in pre-ANSI compilers (because they insist on converting * to double anyway).
ce point n'est plus tout à fait vrai, ce n'est pas tant le compilo que le CPU (les FPU du CPU) qui fait les calculs en précision supérieure aux types manipulés; et leur vitesse est aujourd'hui assez comparable en float ou double.
Aucun problème donc pour utiliser un GPU qui ne travaille qu'en simple précision.
Que va-t-il trouver comme argument de mauvaise foi maintenant ?
oh mais aucun pourquoi ?
Sylvain.
see
houba <@lacave.net> wrote:
Adobe a livré Photoshop (CS4?), son produit phare et développé *prioritairement* pour vista64 (reléguant ainsi Apple au second plan), en bêta depuis début avril 2008 et il est prévu qu'il sera finalisé/RTMisé en ~Oct 2008.
Photoshop CS4 ne sera 64 bits que pour Windows. Il ne s'agit pas d'une priorité donné à Windows mais est justifié par un travail de réécriture important obligatoire pour passer en 64 bits sur Apple (Changement de l'interface de programmation Carbon (qui n'est pas disponible en 64bits) vers Cocoa ce qui implique au passage un changement du langage de programmation de C++ à Objective C).
Cette contrainte est due à un choix technique de la part de Apple. -- Bruno http://errance.lirano.net (photographies)
houba <@lacave.net> wrote:
Adobe a livré Photoshop (CS4?), son produit phare et développé
*prioritairement* pour vista64 (reléguant ainsi Apple au second plan),
en bêta depuis début avril 2008 et il est prévu qu'il sera
finalisé/RTMisé en ~Oct 2008.
Photoshop CS4 ne sera 64 bits que pour Windows. Il ne s'agit pas d'une
priorité donné à Windows mais est justifié par un travail de réécriture
important obligatoire pour passer en 64 bits sur Apple (Changement de
l'interface de programmation Carbon (qui n'est pas disponible en 64bits)
vers Cocoa ce qui implique au passage un changement du langage de
programmation de C++ à Objective C).
Cette contrainte est due à un choix technique de la part de Apple.
--
Bruno
http://errance.lirano.net (photographies)
Adobe a livré Photoshop (CS4?), son produit phare et développé *prioritairement* pour vista64 (reléguant ainsi Apple au second plan), en bêta depuis début avril 2008 et il est prévu qu'il sera finalisé/RTMisé en ~Oct 2008.
Photoshop CS4 ne sera 64 bits que pour Windows. Il ne s'agit pas d'une priorité donné à Windows mais est justifié par un travail de réécriture important obligatoire pour passer en 64 bits sur Apple (Changement de l'interface de programmation Carbon (qui n'est pas disponible en 64bits) vers Cocoa ce qui implique au passage un changement du langage de programmation de C++ à Objective C).
Cette contrainte est due à un choix technique de la part de Apple. -- Bruno http://errance.lirano.net (photographies)
filh
Sylvain SF wrote:
FiLH wrote on 14/06/2008 09:38:
Sylvain SF wrote:
FiLH wrote on 13/06/2008 21:14:
il me semblait que ça pouvait source ? implémentation de référence ?
Ben j'ai des collègues qui ont au moins implémenté le décodage sur des procs qui n'ont pas de flottants :)
comme des ASIC, (mini)DSP ou circuits dédiés d'ASP ?
merci pour ces cas évidents mais le fil parle: d'utiliser le GPU d'une carte graphique plus ou moins évolué (plutôt plus) à la place du CPU (32 ou 64 bits, multi-core, mutli-ALU, multi-FPU).
Je parlais juste de ce que tu disais sur la compression jpg...
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
Sylvain SF <sylvain@boiteaspam.info> wrote:
FiLH wrote on 14/06/2008 09:38:
Sylvain SF <sylvain@boiteaspam.info> wrote:
FiLH wrote on 13/06/2008 21:14:
il me semblait que ça pouvait
source ? implémentation de référence ?
Ben j'ai des collègues qui ont au moins implémenté le décodage sur des
procs qui n'ont pas de flottants :)
comme des ASIC, (mini)DSP ou circuits dédiés d'ASP ?
merci pour ces cas évidents mais le fil parle: d'utiliser le GPU d'une
carte graphique plus ou moins évolué (plutôt plus) à la place du CPU
(32 ou 64 bits, multi-core, mutli-ALU, multi-FPU).
Je parlais juste de ce que tu disais sur la compression jpg...
FiLH
--
Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire
une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle.
Roland Barthes.
http://www.filh.org
il me semblait que ça pouvait source ? implémentation de référence ?
Ben j'ai des collègues qui ont au moins implémenté le décodage sur des procs qui n'ont pas de flottants :)
comme des ASIC, (mini)DSP ou circuits dédiés d'ASP ?
merci pour ces cas évidents mais le fil parle: d'utiliser le GPU d'une carte graphique plus ou moins évolué (plutôt plus) à la place du CPU (32 ou 64 bits, multi-core, mutli-ALU, multi-FPU).
Je parlais juste de ce que tu disais sur la compression jpg...
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
Sylvain SF
FiLH wrote on 14/06/2008 22:41:
Je parlais juste de ce que tu disais sur la compression jpg...
certes oui, mais on a dérivé.
j'ai cité l'encodage JPG comme un simple exemple d'algo pouvant (le plus souvent) nécessiter des opérations flottantes, juste pour dire qu'un GPU qui ne supporterait que des opérations en simple précision (et ce point ne me semble pas tout à fait sur) ne permettra pas de tout faire, ou plus factuellement, qu'il peut être intéressant de composer avec sans prétendre qu'il soit ni indispensable, ni la solution à tout.
tu as raison d'indiquer qu'un codage est possible sans float, et généralement plusieurs algos, chacun avec ses contraintes, sont possibles pour la plupart des problèmes; il ne faudrait pas pour autant que le fait qu'un ASIC avec ALU seul puisse encoder en JPG "démontre" qu'il soit possible de tout faire avec un GPU (à force de dérive justement).
Sylvain.
FiLH wrote on 14/06/2008 22:41:
Je parlais juste de ce que tu disais sur la compression jpg...
certes oui, mais on a dérivé.
j'ai cité l'encodage JPG comme un simple exemple d'algo pouvant
(le plus souvent) nécessiter des opérations flottantes, juste
pour dire qu'un GPU qui ne supporterait que des opérations en
simple précision (et ce point ne me semble pas tout à fait sur)
ne permettra pas de tout faire, ou plus factuellement, qu'il
peut être intéressant de composer avec sans prétendre qu'il
soit ni indispensable, ni la solution à tout.
tu as raison d'indiquer qu'un codage est possible sans float,
et généralement plusieurs algos, chacun avec ses contraintes,
sont possibles pour la plupart des problèmes; il ne faudrait
pas pour autant que le fait qu'un ASIC avec ALU seul puisse
encoder en JPG "démontre" qu'il soit possible de tout faire
avec un GPU (à force de dérive justement).
Je parlais juste de ce que tu disais sur la compression jpg...
certes oui, mais on a dérivé.
j'ai cité l'encodage JPG comme un simple exemple d'algo pouvant (le plus souvent) nécessiter des opérations flottantes, juste pour dire qu'un GPU qui ne supporterait que des opérations en simple précision (et ce point ne me semble pas tout à fait sur) ne permettra pas de tout faire, ou plus factuellement, qu'il peut être intéressant de composer avec sans prétendre qu'il soit ni indispensable, ni la solution à tout.
tu as raison d'indiquer qu'un codage est possible sans float, et généralement plusieurs algos, chacun avec ses contraintes, sont possibles pour la plupart des problèmes; il ne faudrait pas pour autant que le fait qu'un ASIC avec ALU seul puisse encoder en JPG "démontre" qu'il soit possible de tout faire avec un GPU (à force de dérive justement).
Sylvain.
Erwan David
Sylvain SF écrivait :
c'est quoi la "virgule fixe" ?
Tu travailes en entiers sur une unité n foid plus petite que l'unité réelle. Par exemple dans le monde bancaire on travaille beaucoup avec des entiers qui représente des millièmes, 10 000 èmes ou 100 000 èmes d'unité monétaire
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Sylvain SF <sylvain@boiteaspam.info> écrivait :
c'est quoi la "virgule fixe" ?
Tu travailes en entiers sur une unité n foid plus petite que l'unité
réelle.
Par exemple dans le monde bancaire on travaille beaucoup avec des
entiers qui représente des millièmes, 10 000 èmes ou 100 000 èmes
d'unité monétaire
--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé
Tu travailes en entiers sur une unité n foid plus petite que l'unité réelle. Par exemple dans le monde bancaire on travaille beaucoup avec des entiers qui représente des millièmes, 10 000 èmes ou 100 000 èmes d'unité monétaire
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
