Seguro que podemos. Existe un hardware como ese: placas base de doble CPU.
Y lo hacemos en el lado del servidor. ¿Crees que el servidor para algo como un fragmento de WoW se ejecuta en una sola CPU multinúcleo? No lo es
Pero estás preguntando sobre los juegos de escritorio.
- ¿Qué debo saber antes de ordenar una PC para juegos personalizada? ¿Qué hacen todas las partes y cuán importante es el papel de cada parte?
- ¿Cómo maneja una PC los archivos eliminados?
- ¿Qué videojuegos consideras los más significativos e influyentes para la historia de los juegos? Por qué ?
- ¿Cuáles son algunas fuentes que enseñan cómo interactuar directamente con el hardware en una PC IBM?
- ¿Quitar el disco óptico de los portátiles mejora mucho la duración de la batería?
Supongo que ya comprende la diferencia entre estar vinculado a la CPU y la GPU. Si no, ese sería un buen punto de partida para tu google-fu.
Entonces, si tiene un juego que está vinculado a la CPU (ya sea porque dejó caer la resolución lo suficientemente baja o agregó gpus adicionales en crossfire o sli), entonces ahora qué.
Hay dos formas diferentes desde la perspectiva de la programación de juegos:
Versión 1: el juego ejecuta el bucle principal tan rápido como puede y descarga datos a la gpu cuando se hace.
Versión 2: el juego tiene una velocidad de fotogramas objetivo y tiempo de pads para mantenerlo en esa zona.
Así que supongamos que tenemos un juego en el primero. Supongamos un FPS objetivo de 30 aunque eso se sienta feo y lento. Esto le brinda 33 ms para calcular todo lo que debe hacerse.
Eso puede parecer una tonelada de tiempo, pero realmente no lo es. En la actualidad, la mayoría de los motores de juegos están basados en componentes porque la composición de los objetos se ve más limpia y se crean matrices de componentes para la iteración, lo que aumenta la eficiencia de la caché. Y aquí es donde llegamos a las cosas buenas.
Una CPU multinúcleo comparte caché, generalmente el L2 y el L3, mientras que cada núcleo tiene su propio L1, pero diferentes series de procesadores hacen las cosas de manera diferente. Cuando tiene varias CPU físicas, cada una con núcleos, necesita obtener todas las cosas de la memoria a la segunda CPU y luego obtener el resultado nuevamente en la memoria y luego a la CPU principal para que pueda usarse en el siguiente paso .
Ejemplo fácil: tengo un juego con 100,000 bolas en movimiento. Cada objeto de bola tiene suficiente información para manejar su movimiento, por lo que podría volcar 50k en una CPU y 50k en la otra y es el doble de rápido. Pero cuando ocurre una colisión, si alguien en cpu1 debería golpear a alguien en cpu2. Como no están compartiendo caché, no hay una forma rápida de verificar esto, por lo que tengo que validar desde ram para cada operación, ahora termina siendo mucho más lento en tiempo total porque me estoy moviendo de caché a ram.
Sí, hay toneladas de técnicas para resolver ese problema específico y hacer que los tiempos sean sólidos. Pero terminas teniendo que hacer un montón de trabajo más programándolo para muy poco beneficio para el usuario final. ¿Le importará al jugador que pueda tener 100,000 bolas en lugar de 10,000? ¿Mejorará el juego?
Hay muy pocos juegos que en realidad están vinculados a la CPU. La fortaleza enana me viene a la mente. Minecraft probablemente también lo sea, pero el juego está limitado internamente, por lo que es más difícil de ver. La mayoría de las veces perfilas el juego y arreglas cualquier problema que esté causando problemas. Reduce la cantidad de cosas que necesita procesamiento. Usted divide las cosas que no puede reducir y las distribuye en unos pocos cuadros. Caché los resultados. Hace una actualización de LOD para objetos distantes. Te mueves tanto como puedas a la gpu (suponiendo que tu gpu tenga ciclos libres).
