Voir les contributions

Cette section vous permet de consulter les contributions (messages, sujets et fichiers joints) d'un utilisateur. Vous ne pourrez voir que les contributions des zones auxquelles vous avez accès.

Messages - xoofx

Pages: [1] 2 3 ... 25
1
Code / Re : Intro 64K en C#
« le: 19 Juillet 2016 à 18:05:31  »
Pire le .net en plus des metadatas embarque ce que j’appelle du code mort, si vous avez une classe ou des méthodes dans votre projet que vous n'utilisez pas, elles seront quand même incluses dans l’exécutable, pour un Exécutable 64Ko ça ne facilite pas la vie ... Je ne sais pas si il existe un outil pour supprimer le code mort ?
Bon je pense que je vais faire une croix sur le C# pour une intro ...

Il est possible de réduire la taille des assemblies et de supprimer le code mort, via par exemple ILMerge ou ILRepack couplé a Mono.Linker. C'est ce que j'avais utilisé à l'époque dans mes tests via un petit outil SharpPak que j'avais testé sur SharpDX.

C'est la méthode utilisée pour faire de la compilation AOT dans Xamarin (lorsque l'on dévelope une appli iOS). .NET Native (pour les applis UWP sous Windows) utilise une technique similaire mais le code n'est pas open-source.

2
Code / Re : Intro 64K en C#
« le: 14 Juillet 2016 à 09:29:45  »
Salut backlash,

J'ai étudié la question il y a quelques années et en fait, même s'il est possible de faire une intro 64k en C#, c'est beaucoup trop limitant pour l'utiliser, car in-fine ce serait bien moins efficace en terme d'escape/qualité/ratio compression qu'une intro en C.

En gros, tu perds énormément de place dans l'exécutable .NET d'origine avec les metadatas des assembly .NET (qui stocke dans le détail la signature de toutes les méthodes, classes, structs, enums, des assemblies et types référencés...etc.), même en utilisant des techniques d'optimisation des metadatas (link de plusieurs assemblies en un seul, obfuscation pour réduire la longueur des identifiants... etc.) couplés avec des compression classiques intro 64k (type kkrunchy).

J'avais pensé aussi à une solution hybride où le code exe (non .NET) contiendrait en fait du code C# minified avec un appel direct de la VM/host CLR, avec compilation d' un assembly .NET au démarrage... mais vu l'effort que cela aurait demandé, j'ai trouvé que cela ne valait pas le coup par rapport au travail qu'il faut déjà fournir pour développer une bonne intro 64k.

Donc je ne conseille pas trop. En revanche, c'est parfait pour faire des démos d'autant que tu peux développer les tools avec (typiquement, les démos du groupe STILL par example sont en C#, ils ont même publié leur tool sur github https://github.com/framefield/tooll ). Et aujourd'hui avec CoreCLR, on peut développer des applis/demos .NET standalone cross-platform sans installation.

3
Code / Re : How to play sound in Shadertoy
« le: 10 Août 2014 à 13:16:19  »
Mais je ne comprends pas bien comment ca marche ! Est-ce que quelqu'un peut m'expliquer s'il vous plait ?

Hm ca dépend un peu de tes connaissances en génération classique de son... donc c'est difficile de te répondre avec le détail adéquat! Mais en gros:
- Le shader de shadertoy est appelé par sample, sachant qu'il y a normalement 44000 samples/second. Donc 1 pixel = 1 sample.
- Le point d’entrée d'un shader est la fonction:
vec2 mainSound( float time )

- Si tu veux générer un simple son mono 440Hz, tu peux par exemple coder ceci:
vec2 mainSound( float time )
{
     float value = 0.5* sin(2. * 3.14 * 440. * time);
     // left = right = son a 440Hz
     return vec2(value, value);
}

Ensuite, c'est juste une variation sur ce principe, en utilisant les classiques de la synthèse audio: synthèse additive, écho, noise, filtres...etc

Dans le détail, derrière (je n'ai pas regardé leur code mais c comme ça que j'aurais fait), ce "shader de son" est encapsulé dans un pixel shader classique et ils calculent ça sur une petite surface pour permettre une synchro avec pas trop de latences avec l'image (probablement entre 20-30ms, donc environ 1320 sample, donc une texture de 132x10 pixels par exemple).

4
Code / Re : Volumetric light ?
« le: 04 Novembre 2013 à 16:38:00  »
Je confirme que c'est plutot avec du raymarching que l'on fait ce genre d'effet. Il te faut une shadowmap (ou tout autre moyen pour detecter la forme du dessus, si c'est une forme simpliste, tu peux l'approximer directement par un distance field). Patapom avait ecrit un article sur le calcul des fonctions de scaterring (extinction, density, in-scaterring), mais j'ai l'impression que son wiki est down, mais bon, en bidouillant des constantes, y'a pas besoin de se prendre la tete avec ces fonctions.
Après, dans le cas spécifique de la vue que tu montre, tu peux effectivement simuler cette vue avec un simple radial blur, mais ptet que pour arriver a un resultat convaincant, il te faudra determiner a partir d’où dans l'image l'objet passe a des faces back-faces par rapport a la lumière (tu peux t'aider en samplant un normal/g-buffer par exemple)

5
Gfx / Re : R&D_Px-Ârt_Graindo
« le: 11 Août 2013 à 09:55:34  »
Bulle, laisse l’Océan récupérer de toute cette écume autour de toi et reviens nager doucement et paisiblement en Lui, l'Obsession est le grand courant qui te fait glisser en Lui. Laisse le résistant vaquer a ses petites obsessions, il ne souhaite que prendre tout l'espace et faire beaucoup de bruit  ;)

6
Code / Re : Compute shaders, quelques questions
« le: 18 Juillet 2013 à 15:41:27  »
Heu, question de noob mais comment on update ce putain de SDK ? Ou tout du moins le compilateur de shaders ?

Il te faut installer le Windows 8 SDK et tu trouveras ensuite les fxc.exe et autre d3dcompiler_46.dll dans les sous répertoires. A la difference du DirectX June 2010, tu peux/dois redistribuer d3dcompiler_46.dll avec ton appli (ou la partie qui compile si c du offline).

7
Code / Re : Compute shaders, quelques questions
« le: 18 Juillet 2013 à 14:23:13  »
Han mais t'as codé un bitonic et tu l'as même pas partagé alors que t'avais promis dans je sais plus quelle autre thread où on en parlait ? T'es une sorte de grosse ordure en fait ! ;D
Rhaf, désolé, c vrai que j'ai pas pris le temps, y'a tellement de truc a explorer et de choses a dire sur les choses que l'on a exploré, qu'a un certain moment, on partage moins que l'on explore, et ça s’amoncèle malheureusement...  :-[

Sinon j'ai une mauvaise nouvelle vis-à-vis des CS : j'ai écrit un code que le compilo a pas su générer correctement.
Pourtant c'est pas un code méga-complexe, il fait pas intervenir de synchros entre threads, pas de groupshared memory, rien. Chaque tread fait son p'tit bouzin, indépendamment des autres, elle s'occupe de son p'tit business et écrit le résultat dans sa target, pas de scatter rien. En gros, c'est quasiment l'équivalent d'un PS...
Bizarre pour quelques chose d'aussi direct... avec quelle version de fxc? Si tu prends le compilo du SDK de Windows 8, ils ont corriges quelques bugs du style dans les CS (ca doit etre d3dcompiler_46.dll). Celui du DirectX June 2010 (_44) commence a dater...

8
Code / Re : Compute shaders, quelques questions
« le: 18 Juillet 2013 à 10:54:50  »
Spécifiquement par rapport a D3D11, cette présentation "DirectCompute Performance" de AMD recommande pas mal de choses pour maximiser l'utilisation du GPU. Je dois avouer que ce n'est vraiment pas evident de trouver une seule info a un endroit sur ce sujet. Parfois tu peux trouver des astuces optims, comme par exemple récemment une série de tweets de Nick Thibieroz GCN Performances Tips

Tout d'abord, comment choisir le nombre de thread groups que l'ont va utiliser (paramètres de Dispatch() quoi)? Est-ce que par exemple si j'ai 80 shader cores sur ma AMD HD5470 (oui, c'est du très bas de gamme :-° ), je dois distribuer sur 80 groupes?

A priori, un shader core peut prendre en charge plusieurs thread group, mais pour l'instant, un thread group ne peut a se repartir entre plusieurs shader core (ca pourrait changer a l'avenir).

Dans le même genre, comment choisir le nombre de threads par groupe? A ce que je crois savoir (mais je sais pas trop en fait) lorsque un thread est bloqué par l'attente de l'arrivée de données pas dans le cache local, le gpu passe à un autre thread (j'ai vu le terme wavefront souvent, mais je ne sais plus ce que c'est). Donc il faudrait en mettre un certain nombre, mais combien?

Cela dépend beaucoup du hardware (et pareil, les nouvelles générations type GCN de AMD peuvent aussi changer la donne), mais jusqu’à présent, la règle était d'utiliser un multiple de 32 threads pour NVidia et 64 threads pour AMD. J'ai plus souvent utilise 256, voire 512. A chaque fois, idéalement, il faudrait que tu testes cela sur different HW, quitte même a avoir different config pour different HW, et supreme ideal, d'avoir un systeme qui mesure les options en bootstrap avant de selectionner la version optimale pour l'HW en cours d'utilisation.

Mon but final serait de faire un compute shader pour gérer la mise à jour de particules, puis qu'il fasse un tri selon la profondeur des particules (car ces particules sont ensuite étendues en des cubes, et je veux minimiser le pixel overdraw). Quelqu'un a déjà fait dans le truc et aurait des conseils spécifiques?

J'ai fait juste un petit moteur de particules en D3D11, avec update et tri en compute shaders, et l'affichage des particules en utilisant le GS juste pour afficher des quads a partir des positions des particules. Pour l'update, il est possible qu'une version PS soit plus efficace, mais je trouve ca tellement pratique de pouvoir utiliser une struct sans avoir a jongler avec plusieurs MRT que je n'ai pas passe du temps a optimiser cette partie. Pour le sorting, j'ai utilise un custom algo de bitonic sort, a posteriori assez similaire a celui du DirectX SDK, ptet un peu plus performant tout en évitant la transposition, mais peut etre qu'en utilisant la transposition en plus, j'aurais pu gagner un peu plus (de mémoire des résultats, tri de 1 millions de particules autour 7-8ms sur une GTX 560). Meme en utilisant une struct pour la particule, il faut essayer de packer les fields et a occuper un minimum de place (idéalement inférieur a 64 bytes de ce que j'avais pu lire qq part? ), ce qui oblige souvent a utiliser des halfs et a packer les infos dans des ints.

Dans tous les cas, il faut vraiment mesurer les perfs a chaque étapes de l'algo et voir ou tu perds du temps (en utilisant des query timestamp GPU pour avoir des chiffres un peu plus precis que juste du time per frame). Utiliser des outils comme NVidia NSight pour diagnostiquer comment les threads se dispatchent aide beaucoup.

9
Code / Re : [OpenGL] – Geometry shader comme tessellateur
« le: 07 Avril 2013 à 03:17:51  »
Ces triangles, il faut bien les sortir de quelque part. Donc soit faire tourner sur CPU une fonction qui tesselle les 6 faces de base d’un cube, et qui envoie tout ça dans un shader, soit sur GPU, et dans ce cas là la meilleure solution (pour OpenGL) est bien évidemment les TCS / TES.
Encore une fois, la suggestion que j'ai propose n'est pas pour faire de la tesselation en temps-reel, mais pour faire semblant d'avoir une tesselation avec du hardware D3D9, donc oui biensur, il faut préparer tout sur le CPU avant d'envoyer tout ça au GPU, comme on le ferait pour le mesh initial. Une fois que c'est sur le GPU, on laisse le vertex shader modifier ces "points de tesselations".

Bon enfin, de toute facon, si tu peux utiliser les TCS/TES, c'est évidemment beaucoup plus adaptés.

10
Code / Re : [OpenGL] – Geometry shader comme tessellateur
« le: 06 Avril 2013 à 16:26:26  »
Même pas sûr que tu puisses générer plus de 32 ou  64 vertices dans le GS, c'est vraiment pas fait pour ça...  :(
En D3D10, c'est 1024 scalaires max en output, donc pour 32/64, tu peux pas avoir plus de 8/4 float4 attributes, ce qui peut être suffisant dans bien des cas qd même... mais bon, vraiment, quand en d3d11 on a access au ComputeShader et autres HS/DS, les GS, ben a part pour faire des point sprites, y'a plus trop d’intérêts...

11
Code / Re : [OpenGL] – Geometry shader comme tessellateur
« le: 06 Avril 2013 à 13:30:47  »
Et bien j’utilisais le GS pour générer des vertices, ce qui n’est pas possible sur VS.
Oui, j'avais bien compris.  ;) Ce que je suggérais, c'est de faire semblant de "générer" des vertices avec le VS, technique qui peut être valable dans certains cas: prend un cube avec 6 faces, qui est en fait constitue d''un million de triangles, avec des attributs identiques sur les faces, tu peux modifier a volonté ces vertices pour donner l'illusion qu'ils apparaissent au fur et a mesure...etc.  Une chose est sure est qu'1M de vertices sur le VS seront plus performant que 10,000 vertices et x100 dans le GS.

12
Code / Re : [OpenGL] – Geometry shader comme tessellateur
« le: 06 Avril 2013 à 06:25:51  »
Comme dit Patapom, si t'as seule contrainte pour ne pas utiliser la tesselation Domain/Hull shaders c'est la crainte que ca ne tourne pas sur une machine de compo, toutes les machines de compos (depuis au moins plus d'1 an) ont des cartes qui supportent D3D11 et OpenGL4.x avec les derniers drivers, le plus souvent c'est des cartes NVidia, donc souvent encore plus laxistes sur OpenGL (meme si je recommande qd meme de tester sur ATI), donc oui, fonce sur 4.x, t'embettes pas avec le GS (et pour une solution VS, well, rien sur le CPU, tu fais tout dans le vertex shader, en deplacant les vertices que tu veux deplacer, ou en les laissant flats si tu veux pas montrer la tesselation, a moins que tu fasses un rendu wireframe, et la ouai, c moins possible)

13
Code / Re : [OpenGL] – Geometry shader comme tessellateur
« le: 05 Avril 2013 à 16:20:50  »
D’expérience, le GS est vraiment lent des que ca dépasse quelques vertices (en fait plutot souvent tout juste bon pour faire des points sprites/quad expansions, pas plus), voir "A trip through the Graphics Pipeline 2011, part 10" ou plus explicitement dit dans la FAQ D3D10 du Geometry Shader "No. The geometry shader should NOT be used for tessellation. ". Bref, le GS est un vrai goulot d’étranglement dans le rendu, sous exploitant complètement le GPU.  Bourriner sur le vertex shader est souvent bien plus payant, je vérifierais les performances avant de me lancer sur une solution VS-GS en la confrontant avec une solution pure VS (si ca s'applique dans ton cas).

14
Code / Re : C'est officiel : je comprends rien aux GPUs !
« le: 08 Mars 2013 à 14:55:20  »
Sinon les D3DPERF_BeginEvent c'est dans D3D9.H, c'est pas grave ? Faut linker avec D3D9.LIB ? Y a pas de version pour les autres DX ?
Pas de soucis, ca fera juste une dependance sur d3d9.dll (que tu peux virer en Release). Il y a de nouvelles fonctions dispo en D3D11.1 (uniquement sur Win8 or un Win7 avec un update IE10/SP1 trucmuche), mais je ne pense pas que ca fonctionne avec NSight (il n'a pas ete mis a jours depuis le 11.1 et ne marche pas non plus sous VS2012), alors que les D3DPERF fonctionnent avec tous les profilers (Intel GPU, GPUPerfStudio, NSight, VS2012 Graphics Profiler, PIX)

15
Code / Re : C'est officiel : je comprends rien aux GPUs !
« le: 08 Mars 2013 à 13:46:11  »
Serieux Patapom, prends le temps d'utiliser NSight aulieu de perdre ton temps en conjectures, tu peux voir clairement les chemins critiques, les decoupages des micro-taches sur les shadercores, le temps exact sur GPU pour chacun des pass, pour peu que tu encadres ton code avec des D3DPERF_BeginEvent/D3DPERF_EndEvent/D3DPERF_SetMarker et tu auras un visuel direct de tout ton arbre de rendu, et tu pourras identifier clairement les parties.

Pages: [1] 2 3 ... 25