Exploration de la Technologie GS de la PlayStation 2

Introduction à paraLLEl-GS

En 2020,j’ai développé paraLLEl-RDP,un projet visant à implémenter le RDP de la Nintendo 64 en utilisant Vulkan. Ce projet a été rapide et précis, avec une prise en charge supplémentaire du suréchantillonnage. Je suis satisfait du résultat final. Cependant, l’idée d’appliquer une approche similaire à la PlayStation 2 (PS2) m’a toujours intrigué. Jusqu’à présent,GSdx était l’unique solution disponible depuis deux décennies.

Historique des Implémentations

Il est importent de noter que paraLLEl-GS n’est pas le premier projet d’implémentation par calcul pour le GS de la PS2. Une tentative avait été faite en 2014 avec OpenCL, mais elle n’a jamais abouti et ne semble plus être accessible dans les dépôts actuels.

Comparaison entre N64 et PS2

La justification pour utiliser des shaders de calcul sur PS2 est moins convaincante que pour N64. angrylion était extrêmement lent et N64 exigeait une précision élevée où l’accélération matérielle via les API graphiques entraînait des compromis significatifs. En revanche, PCSX2 dispose d’un moteur logiciel bien optimisé ainsi qu’un moteur graphique solide ; cependant, cela ne signifie pas qu’il soit exempt de problèmes.

Mon principal objectif ici est simplement « parce que je peux ». J’avais déjà un projet qui réalisait une rasterisation générique par shader compute et j’ai pensé qu’il serait possible d’adapter cela pour prendre en charge le rendu PS2.

Collaboration et Défis Techniques

Je n’ai pas travaillé seul sur ce projet ; mon collègue Runar Heyer a joué un rôle crucial au début en étudiant minutieusement la PS2 à partir de diverses ressources et en développant un prototype initial tout en adaptant Vulkan GLSL pour émuler l’ombrage spécifique à la PS2. Nous avons rencontré plusieurs obstacles lors du débogage des jeux qui ont mis notre travail sur pause pendant un certain temps jusqu’à ce que je retrouve suffisamment d’énergie mentale pour avancer.ma compréhension du GS repose principalement sur les découvertes faites par Runar ainsi que mes propres observations lors du débogage des jeux. Le moteur logiciel GSdx ne semble pas être parfaitement précis au niveau matériel ; nous avons donc souvent dû remettre nos hypothèses en question lors des comparaisons avec sa sortie graphique.

Aperçu Général du GS

Caractéristiques Clés

Le Graphics Synthesizer (GS) est réputé pour son incroyable capacité à traiter les pixels avec un taux pouvant théoriquement dépasser le milliard par seconde dès l’an 2000 ! Bien que sa mémoire vidéo soit limitée (4 Mo), il a été conçu pour permettre un flux continu grâce aux divers moteurs DMA disponibles.

Pipeline Pixelaire : Simplicité Étrange

Le pipeline pixelier du GS se distingue par sa simplicité relative comparée au RDP de N64 : il utilise une seule texture ainsi qu’un unique cycle combinatoire contrairement aux deux étapes présentes dans N64 qui nécessitaient plus de complexité dans leur gestion graphique.

Problèmes Spécifiques

• Mélange au-delà de 1.0 : Le système traite certaines valeurs comme supérieures à celles normalement acceptées.
• Tests alpha : utilisés comme pseudo-stencils peuvent compliquer considérablement les opérations sans mélange programmable.
• Mélange conditionnel : Permettre ou non le mélange selon certaines conditions peut devenir complexe sans support adéquat.

Ces particularités rendent difficile l’émulation fidèle via les API graphiques traditionnelles tout en nécessitant une attention particulière lors du développement d’une solution efficace comme paraLLEl-GS.

Détails Techniques Sur L’Implémentation

Pipeline Graphique

avant d’aborder le suivi des pages mémoire VRAM, il est essentiel d’établir clairement comment chaque étape doit interagir :

1. Synchroniser la copie CPU vers GPU
2. Télécharger les données vers VRAM
3. Mettre à jour le cache CLUT depuis VRAM
4. unswitcher VRAM vers VkImages exploitables
5. effectuer le rendu
6. Synchroniser retour vers CPU si nécessaire

Cette séquence permet aux développeurs d’optimiser leurs performances tout en gérant efficacement toutes interactions potentielles entre ces différentes étapes critiques dans leur pipeline graphique.

Suivi Des Pages Mémoire

Un défi majeur réside dans la gestion efficace des dangers potentiels liés aux lectures/écritures simultanées dans VRAM étant donné ses limitations strictes (seulement 4 Mo). Pour y remédier :

• Chaque page contient son propre état concernant les écritures/lectures pendantes.
• Les textures sont alignées tous les 256 octets afin minimiser toute fausse alerte durant ces opérations critiques.

bien que développer paraLLEl-GS ait présenté son lot défis techniques complexes liés spécifiquement aux caractéristiques uniques du hardware PS2 , cette aventure enrichissante ouvre également plusieurs perspectives intéressantes quant aux futures possibilités offertes par cette technologie fascinante!

Gestion des textures et optimisation des performances

La gestion efficace des textures est essentielle pour garantir une performance optimale dans les jeux vidéo. cela implique de prendre en compte les masques d’écriture/lecture et la structure de bloc, ce qui est crucial pour éviter les problèmes de performance.

Cas particuliers à considérer

il existe plusieurs scénarios où des faux positifs peuvent survenir en raison du fonctionnement des textures. Étant donné que les textures sont souvent dimensionnées selon le format POT (Power of two), il n’est pas rare qu’une texture de 512×448 soit traitée comme une texture de 512×512. Idéalement, la zone inutilisée devrait être exclue avec REGION_CLAMP, mais cela n’est pas toujours respecté dans tous les jeux. Une cible de rendu pourrait occuper ces pages non utilisées. Tant que les coordonnées UV du jeu ne s’étendent pas dans cette zone rouge inutilisée, il n’y a pas de risques, mais cela complique considérablement le suivi.

Pour contourner ce problème, nous choisissons d’ignorer tout risque potentiel dans cette zone rouge et espérons qu’un jeu ne s’appuie pas sur des comportements imprévus qui pourraient lui être favorables.

Mise à jour par lots du CLUT

Afin d’optimiser le processus d’importation des textures, il est également nécessaire d’effectuer la mise à jour du CLUT (Color Look-Up Table) par lots. Pour ce faire, nous utilisons 1024 copies du CLUT sous forme d’un tampon circulaire contenant plusieurs instantanés.

Un groupe de travail parcourt ces mises à jour et les écrit dans un SSBO (Shader Storage Buffer Object). J’ai déjà mis en œuvre un système similaire pour la mise à jour TMEM (Texture Memory) sur N64 où TMEM était instancié. Heureusement, la mise à jour du CLUT est beaucoup plus simple que celle du TMEM.

shared uint tmp_clut[512];

// ...

// Copie depuis l'instance précédente pour permettre
// un remplacement partiel d'une entrée CLUT
uint read_index=registers.read_index * CLUT_SIZE_16;
tmp_clut[gl_LocalInvocationIndex]=
    uint(clut16.data[read_index]);
tmp_clut[gl_LocalInvocationIndex + 256u]=
    uint(clut16.data[read_index + 256u]);
barrière();

for (uint i=0; i 

Une optimisation potentielle consiste à paralléliser la mise à jour du CLUT lors des mises à jour couleur / bpp 32 bits car rien ne sera préservé entre itérations précédentes ; cependant, le temps requis pour mettre à jour le CLUT reste minime.

Dématérialisation des textures depuis VRAM

Sous Vulkan, nous pouvons simplement allouer une nouvelle VkImage et l’allouer depuis VkDeviceMemory avant de l’alimenter avec un shader compute.

L’utilisation des constantes spécialisées Vulkan permet également une spécialisation facile au format texture tout en simplifiant considérablement toute logique liée au swizzling.

Mise en place et binning triangulaire

Tout comme paraLLEl-RDP, paraLLEl-GS fonctionne comme un moteur graphique basé sur tuiles. Avant que le binning puisse avoir lieu, il faut préparer correctement chaque triangle avec ses attributs fournis sous forme de trois tableaux distincts :

Positionnement

struct VertexPosition {
    ivec2 pos;
    float z; // Devrait être uint pour Z 32 bits.
    int padding; // Espace libre ?
};

Attributs par sommet

struct VertexAttribute {
    vec2 st;
    float q;
    uint rgba; // unpackUnorm4x8
    float fog; // surabondant mais serait devenu padding.};

Binning efficace

Chaque bloc NxN reçoit un tableau contenant jusqu’à u16 indices primitifs destinés au shading.

Le nombre maximal primitif par passe peut atteindre jusqu’à 64k primitives ; c’est suffisant pour gérer efficacement la plupart des jeux PS2.

Les dimensions NxN sont généralement fixées entre 32×32 ou ajustées dynamiquement selon la charge géométrique.En raison de l’état sans état tant lors du binning que lors de l’établissement triangulaire , ces deux étapes peuvent être regroupées afin d’éviter trop nombreux obstacles inutiles.

L’ubershaders : Un changement clé

Une différence majeure entre N64 et PS2 réside dans leur capacité respective : alors que N64 privilégie une approche spécialisée permettant aux shaders rasterisés d’écrire directement couleur/pixel/profondeur/couverture etc., PS2 permet quant-à-lui une approche plus directe grâce aux capacités supérieures offertes par son architecture GPU.

Cela signifie qu’il devient possible ici aussi bien grâce aux techniques bindless réduisant ainsi considérablement toute complexité texturale rencontrée auparavant sur N64.

En conclusion , bien gérer toutes ces étapes permettra non seulement améliorer significativement votre expérience utilisateur mais aussi optimiser vos performances globales !

Optimisation des performances graphiques dans les émulateurs

Dans le domaine de l’émulation, la gestion des textures et des rendus est cruciale pour garantir une expérience fluide. Les ajustements apportés aux décalages UV sont essentiels pour optimiser les performances. En effet, il est impératif que ces décalages se situent dans une plage spécifique afin d’assurer un rendu précis et rapide.

Gestion efficace des retours de texture

lorsqu’on utilise le mode de retour couleur basé sur les pixels, il est important d’indiquer que le passage de rendu a bien utilisé un retour de texture.Cela permet d’optimiser la gestion des ressources graphiques en évitant une surcharge inutile.

En pratique, cela signifie qu’il faut réduire considérablement le nombre de barrières lors du rendu. Par exemple, au lieu d’avoir plus de 500 barrières sans optimisation, on peut s’en sortir avec seulement 18 grâce à ces ajustements stratégiques.

Toughés rencontrées avec certains jeux

Certaines scènes peuvent révéler des cas particuliers intéressants concernant l’échantillonnage. Par exemple, dans l’introduction du jeu MGS2 (Metal Gear Solid 2), on observe comment un effet camouflage utilise son propre tampon image comme texture tout en posant des questions sur le comportement du cache.

L’absence de barrières ici pourrait sembler problématique ; cependant, cela fonctionne plutôt bien par rapport à un moteur graphique logiciel traditionnel.

Ajustement dynamique selon les besoins

Lorsque nous sommes en mode où la texture pointe directement vers le tampon image, il devient nécessaire d’assouplir légèrement la gestion des risques pour éviter une surcharge excessive qui pourrait nuire aux performances globales. Bien que cela puisse sembler risqué pour certains effets visuels comme celui observé dans « tales of Abyss », cette approche reste viable tant qu’elle respecte certaines conditions spécifiques.

Mise à l’épreuve : Shadow of teh Colossus

L’un des tests les plus exigeants jusqu’à présent a été « Shadow of the Colossus ». Même lors de l’introduction du jeu avec une précision maximale au niveau du mélange graphique sur PCSX2 à seulement 2x upscale, nous avons constaté que la performance pouvait chuter jusqu’à 24 FPS ! Cela souligne combien ce titre peut être exigeant même avec un traitement normalisé.

Pénurie CPU et optimisations nécessaires

Avec un anti-aliasing x8 activé sur paraLLEl-GS, bien que les résultats soient encore satisfaisants en termes de performance globale, il devient évident qu’une partie significative du traitement reste dépendante du CPU lors du traitement géométrique.L’optimisation continue du code processeur n’a pas encore été priorisée mais demeure essentielle pour améliorer cette situation complexe où chaque primitive doit être gérée efficacement face aux risques potentiels qui surgissent constamment.

Avenir technologique : Vers quoi se diriger ?

Actuellement, tester ces optimisations passe principalement par l’utilisation de dumps GS (Graphics Synthesizer). un patch hack permettant d’extraire une trace brute GS via PCSX2 existe déjà ; néanmoins, intégrer ce processus directement dans un émulateur serait bénéfique pour offrir aux utilisateurs finaux une expérience améliorée et plus accessible.

Toutefois, étant donné la complexité immense liée à la bibliothèque PS2 ainsi que le nombre élevé potentiel d’erreurs non détectées durant mes tests personnels limités jusqu’ici , je suis ravi que paraLLEl-GS soit devenu ma méthode privilégiée pour jouer aux jeux PS2 – mission accomplie ! Cette technologie pourrait également séduire ceux qui souhaitent revivre l’expérience classique programmée sur PS2 sous forme moderne grâce à sa nature autonome adaptée au développement ancien .