Lo que el anfitrión debe proporcionar — y lo que la documentación no promete
Los destinos de ejecución oficiales son Windows y Linux x86-64. La selección gráfica necesita Vulkan 1.1 más colas de gráficos y cómputo y presentación de swapchain. Un número de versión Vulkan no significa que un título corra. No hay un mínimo universal documentado de RAM o GPU para cada juego. Esta página cita USAGE.md, BUILD.md y README de boykopovar/AnyPS5. No afirma que un título sea jugable.
v0.1.3 · Contenido ensamblado el 22 oct 2026 a partir del USAGE.md actual de main (Input and conversion, esquema de ejecución, GPU selection), BUILD.md (Relinker only, Requirements) y README, más los mismos archivos en la etiqueta v0.1.3. No es una prueba en el anfitrión.
Sistema operativo del anfitrión
README y BUILD.md describen una herramienta que porta ejecutables a Linux y Windows. Los títulos convertidos necesitan bibliotecas de sistema construidas para el SO de destino y un anfitrión x86-64 compatible. El modo solo-relinker no construye esas bibliotecas.
Los GitHub Releases oficiales envían bibliotecas anfitrionas solo para Linux y Windows. Haz coincidir el relinker y las bibliotecas con una etiqueta y un SO. Un relinker de Windows con bibliotecas de Linux es un esquema fallido, no una prueba de especificaciones del anfitrión.
Gráficos: Vulkan 1.1 es un filtro de dispositivo
USAGE.md: el juego corre en el primer dispositivo Vulkan 1.1 con colas de gráficos y cómputo y presentación de swapchain, prefiriendo una GPU discreta a una integrada. Esa es la regla de selección documentada. Cumplir Vulkan 1.1 no establece que los shaders, las rutas de memoria o la jugabilidad de un título funcionen.
Define ANYPS5_GPU a una parte de un nombre de dispositivo, sin distinguir mayúsculas. Los nombres se imprimen al arrancar en las líneas Physical device candidate. Cuando ningún dispositivo usable contiene el texto, el arranque falla y el error lista los nombres.
Un dispositivo Vulkan listado aún puede fallar después. USAGE señala que el Paquete de compatibilidad de OpenCL, OpenGL y Vulkan de Windows puede instalar Mesa Dozen, que expone dispositivos D3D12 a través de Vulkan; algunos controladores D3D12 pueden fallar mientras el cargador Vulkan enumera adaptadores. README: el recompilador de shaders produce SPIR-V. Un número de versión, o una línea candidata, no es un informe Playable.
Extensiones de CPU
USAGE.md: los títulos corren de forma nativa, así que la CPU del anfitrión necesita las extensiones de la CPU Zen 2 de la PS5 que el código compilado usa sin comprobar, entre ellas AVX2, FMA, F16C, BMI1, BMI2, LZCNT y MOVBE.
En Linux y Windows un título convertido registra las extensiones de la CPU del anfitrión al arrancar y se detiene antes de ejecutar cualquier código del título, nombrando la CPU y las extensiones ausentes, si falta alguna. Esa parada es un límite de la CPU del anfitrión, no un archivo de juego que falte.
Anfitriones Intel y --to-intel
USAGE.md: añade --to-intel para anfitriones Intel, o --to-rosetta para Rosetta. Un título que corre bajo Rosetta en Apple silicon se religa con --macos --to-rosetta.
La opción --to-intel convierte instrucciones AMD admitidas en el ejecutable y los módulos incluidos. Instrucciones no admitidas o stubs de conversión inalcanzables causan un error (salida 2 del relinker).
relinker --windows --to-intel source/input.elf app.exe
--to-intel reescribe instrucciones específicas de AMD encontradas en esos archivos. No puede traducir instrucciones AMD que un título genera en tiempo de ejecución, así que esos títulos requieren un anfitrión AMD. La conversión no es una ruta AMD generada en tiempo de ejecución. Registra la CPU y las opciones de conversión con el informe; no asumas que cada máquina x86-64 puede ejecutar la misma salida.
Memoria: límite de commit, no un suelo universal de RAM
USAGE.md no publica una cifra mínima de RAM o VRAM que todos los títulos deban cumplir. El uso de memoria depende del título y de lo que mapea. Un fallo de asignación no es automáticamente «RAM física insuficiente».
En Windows, la memoria directa (sceKernelAllocateDirectMemory, hasta 13824 MiB por título) se hace commit cuando el título la mapea, no cuando la asigna o usa sus páginas por primera vez. El límite de commit del sistema — memoria instalada más tamaño del archivo de paginación, el segundo valor de Committed en el Administrador de tareas — debe cubrir la memoria directa mapeada junto con el resto de memoria en commit. Si no, sceKernelMapDirectMemory lanza. Amplía el archivo de paginación o cierra otras aplicaciones. Esa cifra de 13824 MiB es un techo documentado por título, no una especificación de PC recomendada.
En Linux, cuando el controlador Vulkan importa memoria dma-buf (no el controlador propietario NVIDIA), la memoria directa compartida se importa a través de /dev/udmabuf, y el usuario que ejecuta el juego necesita acceso de lectura y escritura. Sin acceso, el arranque puede imprimir [gpu] open /dev/udmabuf: Permission denied y esos rangos se copian en lugar de importarse. Eso es un permiso de nodo de dispositivo, no un suelo de RAM.
No inventes un único mínimo «8 GB / 16 GB / RTX …» para todos los títulos. Cita el error de mapeo, el límite de commit o la línea /dev/udmabuf, el nombre de la GPU y la etiqueta de lanzamiento.
Herramientas de compilación desde el código (solo si compilas)
La mayoría de la gente debería quedarse en el par zip oficial de GitHub. Compilar es opcional. Cuando compiles, usa el BUILD.md que vino con ese árbol: las versiones de abajo son lo que documentan el main actual y v0.1.3 hoy, y pueden cambiar.
Solo-relinker: CMake, un compilador C++20 y una herramienta de build. Python 3.9 o más reciente activa las pruebas Python. Este modo construye en Linux, Windows y macOS, incluido Apple silicon. No construye las bibliotecas anfitrionas que un título convertido aún necesita.
Requisitos de la compilación completa nombrados en el main actual y en v0.1.3: x86-64, Git, CMake 3.22.1 o más reciente, Ninja, C++20. Abre BUILD.md para los paquetes Linux (GCC/G++, cabeceras SDL X11/Wayland/audio, etc.). Con BUILD_TESTING=OFF por defecto, cmake --build no produce las bibliotecas parcheadas; el paso explícito --target libs es obligatorio.
Compilación completa de Windows en el main actual: MinGW-w64 GCC x86-64 con hilos POSIX. El compilador debe proporcionar excepciones DWARF con -fno-asynchronous-unwind-tables, o excepciones SEH para funciones System V ABI. BUILD.md nombra WinLibs GCC 15.2.0 (x86_64-ucrt-posix-seh, lanzamiento 15.2.0posix-14.0.0-ucrt-r7) y MSYS2 UCRT64 GCC 16.2.0-6. Tras --target libs, copia libgcc_s_seh-1.dll, libstdc++-6.dll y libwinpthread-1.dll junto a las bibliotecas parcheadas. Los zips de lanzamiento ya las contienen.
BUILD.md en la etiqueta v0.1.3 nombra solo MinGW-w64 GCC 15.2.0 (WinLibs x86_64-ucrt-posix-seh, lanzamiento 15.2.0posix-14.0.0-ucrt-r7) como actualmente admitido para la compilación completa de Windows. Si compilas esa etiqueta, sigue ese archivo, no la lista de herramientas posterior del main.
Las versiones de la cadena de herramientas pueden cambiar. Esta página no congela un pin eterno de GCC de Windows. El conversor web del navegador es una herramienta de conversión (los archivos se quedan en el dispositivo); no sustituye las reglas de GPU y CPU del anfitrión Windows o Linux de arriba.
Haz coincidir el informe con el zip de lanzamiento
Una nota de compatibilidad solo es tan buena como el entorno que nombra. Registra la etiqueta oficial (o el commit que compilaste), el SO, los nombres de GPU y controlador de Physical device candidate, y las opciones de conversión (--windows, --to-intel, --macos y el resto).
README y BUILD.md: la compilación solo-relinker corre en macOS, incluido Apple silicon. USAGE.md: --macos escribe Mach-O x86-64, que corre bajo Rosetta en Apple silicon; --to-rosetta baja instrucciones que Rosetta no tiene. Los lanzamientos oficiales siguen enviando bibliotecas anfitrionas solo para Linux y Windows. Una compilación solo-relinker que pasa, o una conversión Mach-O, es un experimento de conversión — no un requisito de runtime de juegos en Mac y no es Playable. Los forks comunitarios de runtime macOS son experimentos separados, no activos de lanzamiento oficiales.
Las cabeceras Vulkan usadas para compilar un self-build no son el mismo hecho que un controlador anfitrión probado. Cita la etiqueta del zip o el commit. No subas la etapa de un título a partir de una lista de comprobación del anfitrión.
Después de esta página
Si el anfitrión coincide con el SO, las extensiones de CPU y el filtro de dispositivo Vulkan documentados, sigue convirtiendo un ELF limpio y organizando app / libs / app0. Una ventana no es jugabilidad. El 126 o 193 de Windows, un lanzamiento de límite de commit o un dispositivo Vulkan ausente se quedan en la guía de solución de problemas.
Descarga: par zip oficial · Instalación: dos archivos y esquema de carpetas · Compilar desde el código: relinker vs runtime completo · Solución de problemas: 193, 126, límites del anfitrión
No afirmes
- Un mínimo universal de RAM, VRAM o modelo de GPU que todos los títulos deban cumplir.
- Que Vulkan 1.1, o una línea Physical device candidate, significa que un título corre o es Playable.
- Que --to-intel traduce instrucciones AMD que un título genera en tiempo de ejecución.
- Que los lanzamientos oficiales exigen o admiten un runtime de juegos en Mac.
- Que el audio de Linux está corregido en v0.1.3.
- Que la etapa de compatibilidad de un título cambió porque se marcó la lista de comprobación del anfitrión.
Fuentes originales
- USAGE.md en el main actual (Input and conversion, esquema de ejecución, GPU selection)
- USAGE.md en la etiqueta v0.1.3
- BUILD.md en el main actual (Relinker only, Requirements)
- BUILD.md en la etiqueta v0.1.3
- README en el main actual (porte Linux/Windows, solo-relinker en macOS)
- README en la etiqueta v0.1.3
Abrir los GitHub Releases oficialesCuáles son los dos archivos