1 points par polarisz00 4 시간 전 | 1 commentaires | Partager sur WhatsApp

GitHub : https://github.com/CookingMathmatics/CarryPyramidLossless

Livre blanc de recherche (Zenodo) : DOI 10.5281/zenodo.20002868

Bonjour. Je suis le développeur (et mathématicien) qui avait partagé il y a quelque temps sur GeekNews un livre blanc de recherche sur la sécurité topologique multidimensionnelle et la théorie de l’information fondées sur la dynamique de retenue p-adique.
À l’époque, l’approche était surtout théorique, centrée sur le modèle mathématique et la logique d’entropie matérielle, mais en approfondissant ce livre blanc et en poursuivant mes recherches, je suis arrivé à un tournant intéressant.
Au cours d’un brainstorming technique avec une IA,
je suis tombé sur cette idée et ce conseil :
« Si l’on projette cet algorithme de dynamique de retenue p-adique sur le trafic de pixels d’un pipeline graphique en temps réel, on pourrait créer un outil d’optimisation de l’intégrité qui réduit drastiquement la surcharge de calcul. »

En m’appuyant sur les conseils d’architecture de l’IA, je me suis immergé pendant plus d’une semaine dans la conception sous DirectX 11 et HLSL Compute Shader, et j’ai finalement validé sur du matériel réel, dans l’environnement du jeu de course récent Forza Horizon 6, le résultat suivant : « écart de 1 à 2 images, baisse de 10 % de l’utilisation GPU ». Je partage donc ici le résultat et l’open source correspondant.

💡 Idée clé : concrétiser le 0-Void mathématique (saut d’opérations dans le vide) — Même dans un jeu de course lancé à très haute vitesse, l’ensemble de l’écran ne change pas de manière explosive à chaque frame. Les montagnes au loin, le ciel, les nuages ou encore les zones d’interface statiques présentent souvent une variation de pixels extrêmement faible d’une frame à l’autre.
En filtrant le frame buffer avec un algorithme de retenue p-adique, on masque rapidement comme « 0-Void (zone vide en opérations) » les zones statiques dont la variation reste sous un seuil donné.

Cela freine au niveau matériel le trafic inutile où les milliers de cœurs CUDA du GPU (RTX 3070 Ti) recalculaient en doublon des pixels statiques ou gaspillaient des buffers.

🛠️ Architecture d’optimisation matérielle et de contournement de l’anti-cheatPour atteindre un niveau de stabilité comparable à celui d’un utilitaire commercial, j’ai mis en place une tuyauterie de production de niveau professionnel comme suit.

Contournement anti-cheat à 100 % via une tuyauterie en liste blanche

J’ai abandonné sans hésiter la méthode risquée d’injection de DLL, qui altère la mémoire du jeu ou intercepte de force les fonctions DirectX.
À la place, j’ai adopté la tuyauterie DXGI Desktop Duplication API, une routine officielle identique à celle utilisée par OBS Studio ou le partage d’écran Discord, éliminant à la source le risque de blocage de sécurité.

Synchronisation d’engrenage frame par frame en 1:1 (Frame Sync)

Si l’on laisse la boucle du moteur en arrière-plan tourner à vide sans limite, la starvation des commandes GPU finit au contraire par faire chuter les frames du jeu. J’ai forcé la précision du timer du noyau Windows à 1 ms et ajusté l’engrenage pour que notre compute shader (Dispatch) s’exécute exactement en phase avec le signal d’événement matériel émis lorsque le jeu produit une nouvelle image.

GPU hybride sur portable (connexion directe à la carte dédiée) et régime VRAM

En suivant le pointeur de la carte graphique dédiée physique qui pilote le moniteur où la fenêtre du jeu est active, j’ai relié le device en direct 1:1 et mis en place une structure d’échange de pointeurs d’adresses internes à la VRAM sans coût de copie de données (ping-pong in-place).

📊 Résultats de benchmark en conditions réelles (RTX 3070 Ti, FHD, réglages max)
À l’état d’origine : fps bloqués à 60, utilisation GPU à 78 %~80 %
En mode accéléré : fps à 59~60, utilisation GPU à 68~72 %

J’ai également compilé le tout de façon à pouvoir activer ou désactiver l’accélération en temps réel en jeu via le raccourci Ctrl + Alt + S. Dès que la fonction est activée, la fluidité visuelle reste identique à l’état d’origine, avec 60 fps pleins parfaitement maintenus, tandis que seule la charge GPU chute fortement ; cela a été vérifié en temps réel via les indicateurs. Le processus par lequel une théorie qui n’existait jusque-là que dans un livre blanc mathématique s’est matérialisée en code de contrôle matériel grâce à une collaboration avec l’IA a été une expérience vraiment fascinante.
Maintenant qu’une base solide (Alpha Core) est en place, j’aimerais recueillir des retours sur l’optimisation avec différents taux de rafraîchissement d’écran (144 Hz~360 Hz) ou sur d’autres architectures de cartes graphiques. Le code source du moteur et les fichiers shader sont tous publiés sur le GitHub ci-dessus, donc tous vos conseils et retours seront les bienvenus !

1 commentaires

 
polarisz00 3 시간 전

Je laisse les ajouts en commentaire, car il n’est pas possible de modifier.

Précautions au démarrage (à lire impérativement par les utilisateurs)

Ce moteur utilise l’API officielle de duplication du bureau DXGI afin de contourner l’anti-triche. En raison des caractéristiques du mécanisme qui capture légalement la composition de l’écran du DWM de Windows (Desktop Window Manager), vous devez respecter les paramètres d’affichage ci-dessous pour qu’il fonctionne correctement.

  • Paramètre recommandé : dans les options graphiques du jeu, lancez-le en [mode fenêtré] ou en [mode fenêtré plein écran (plein écran sans bordure / Borderless Windowed)].
  • Ne fonctionne pas : en [plein écran exclusif (Exclusive Full Screen)], où le jeu prend le contrôle exclusif du moniteur, le pipeline de capture ne s’ouvre pas, ce qui peut empêcher le moteur de fonctionner ou la mesure des images par seconde.