Los bits de las consolas (y PCs)

sacker

RPV: Qué son los "bits" de una consola? Que significa que una consola sea de 16 bits? De cuántos bits son las consolas/procesadores actuales?

Versión normal: A raíz del hilo de nuestros primeros videojuegos, estaba yo haciendo un remember tecnológico de las consolas desde los 80/90, y hay algo que no me acaba de quedar claro: al principio, las generaciones de consolas las marcaban los "bits". Master System de 8 bits, SNES/MegaDrive de 16 bits, la Play con 32, Nintendo64 con 64, Play2/DreamCast con 128...

A qué se refieren con que la consola es de 8 bits? al bus de datos? al bus de direcciones? al tamaño de las instrucciones? a todos? tampoco creo que todas las consolas compartan arquitectura...

A partir de la generación de PS3 se deja de hablar de los bits que tiene. Cuantos tiene? porqué dejó de ser relevante?

Y juntando con el mundo PC... cuantos "bits" tiene un procesador actual? Está claro que 64 la mayoría, pero 64 bits de qué? tamaño de las instrucciones, de los registros, de los buses (de qué bus)?

Si alguien tiene la bondad de explicármelo, que no escatime en tecnicismos, ejemplos de arquitecturas o lo que haga falta si le es necesario, no me voy a asustar.

Muchas gracias!

MegalomaniaC

64 bits de los procesadores indica el tamaño de la instruccion / registro que puede ejecutar. En consolas es lo mismo.

Siempre se hablaba en el salto generacional como bien dices por Bits, pero tambien importaba el hardware interno, solo que no se publicitaba como ahora. Lo que pasa que antes la aceleracion grafica era mediante hardware, esto es como si coges el Half life o el Quake II y les quitas openGL / Direct 3D, se ve todo a cuadritos mal procesados:

Software:

OpenGL:

Por lo que la potencia de la GPU no importaba tanto, se hacia todo por calculos de CPU, entonces el tamaño de las instrucciones importaba mucho.

Luego se evoluciono hacia arquitecturas nuevas como actualmente, basadas en procesadores sobremesa con x64-86, o Xbox360 (arquitectura PPC de IBM). Antes, todo era mas propio, cada consola tenia su chisme, hoy en dia todo tiende mas a parecerse al PC en terminos de hardware. Al fin y al cabo es normal, donde evolucionan las GPUs y tal es en el PC.

1 1 respuesta
sacker

#2 con OpenGL/Directx te refieres a que el procesado de los gráficos lo hace la GPU y por "Hardware" se encargaba todo la CPU?

entonces entiendo que hasta PS2 se aumentó el tamaño de las instrucciones y registros hasta 128 bits para que el procesador pudiera manejar más datos a la vez, y con PS3/X360 se dio un "paso atrás" a procesadores de 32/64 bits dejando la "potencia gráfica" en manos de una GPU potente aparte, y buscando la estandarización con las CPU's de los PC's, voy bien?

1 respuesta
MegalomaniaC

#3 Se podria decir si. Las APIs (D3D, OGL) se comenzaron a masificar con Xbox y PS2, PS2 usaba OGL y Xbox D3D (microsoft j3j3)

No es que se diera un paso atras, se dividio la tarea. Hay que avanzar y una cosa ya no podia procesar todo del mismo tipo al complicarse las texturas tanto.

No es que se busque la estandarizacion, de hecho lo de esta gen es nuevo (que ps4 y durango usen cpus amd x64 de "escritorio" ), lo han hecho, yo creo, por que xbox360 usaba arquitectura de PPC facil de comprender y programar para ella los juegos era facil, de ahi que todo fueran ports de X360 a ps3 y PC. El Cell de sony era potente pero un cagarro para entender.

Entonces, ahora se simplifica mas.

1 1 respuesta
sacker

#4 ok ok, pues ya me hago una idea de lo que hablan (de lo que leo, mejor dicho)

así que los registros/bus de direcciones de un i5 por ejemplo tienen 64 bits de ancho, pero el bus de datos? he hecho una primera búsqueda y veo velocidades pero no el ancho de los buses y demás. Igual es que lo tienen "escondido" estos datos de los procesadores actuales o que no lo he buscado bien xD

te lo pregunto por si lo sabes así al vuelo, me encanta aprender cosas de estas :)

y muchas muchas gracias por aclararme todo eso!

1 respuesta
r2d2rigo

Lo que pasa que antes el procesado grafico era mediante software

Precisamente se llama aceleracion grafica porque se hace por un componente de hardware dedicado, la GPU.

2 respuestas
MegalomaniaC

#5 El ancho de banda de Sandy por ejemplo es de 256 bits, el tamaño maximo de la instruccion 64.

Y ah, lo que dice #6 que no te he dicho antes, todo lo hacia el procesador, el procesado de las texturas no lo hacia ningun software si no el procesador en si.

1 respuesta
sacker

#7 256 bits, así que usa un bus de datos bastante más extenso que el de instrucciones. Lógico. Buscaré si puedo un diagrama completo de la arquitectura de un Sandy a ver : )

Sobre lo que dice #6 , como realmente todo va por hardware al final (obvious), supongo que se refiere en su frase a que el procesado del apartado gráfico no lo hacía ningún hardware dedicado, si no el procesador, tirando de rutina de software para manejar toda la parte gráfica y de efectos (creo que lo llamaban "procesado por software" en los juegos viejos en que se podía elegir).

Y procesado por hardware ya se referirá a un procesado que se hace por un pipeline con elementos específicos para cada tarea gráfica (iluminación, clipping, AA, etc), que es lo que hace una GPU of course. No #6 ?

2 respuestas
r2d2rigo

#8 lo has clavado.

MegalomaniaC

#8 Eso es, por eso te he puesto la foto del Quake II en OGL y Software, se ve claramente el nivel de texturizado pobre en Software.

2 respuestas
r2d2rigo

#10 que sigues llamando al modo software hardware, que ya te lo dije en #6!

1 respuesta
sacker

#10 lo que tu llamas D3D, OGL es el renderizado "por hardware" (por hardware específico vamos, lo que comento en #8), y lo que llamas Hardware en los juegos lo llamaban "por software", porque el procesador hacía los cálculos gráficos sin tener hardware específico para ello (lo hacía ejecutando rutinas de software que se encargaban de ello de una forma mucho menos eficiente claro).

Todo va por hardware al final claro, pero la "terminología" en los juegos antiguos me parece que es así, como dice r2d2rigo. En cualquier caso, todos tenemos claro como funciona la cosa, que era el objetivo del hilo :si:

1 respuesta
MegalomaniaC

#11 Ups, ando a mil cosas xD

#14 #12 Si si ya lo se, que no puedo estar a todo y me lio xD

Alu

Siempre se ha dicho por software (pre gpu) y por hardware (post gpu) Mega, ahí te has colado xD

1 respuesta
Kaiserlau

articulo interesante en relaccion al hilo
OpenGL vs DirectX: 1 – 0
http://www.unixmen.com/opengl-vs-directx-1-0/
[copy pasteo 1 parrafo hay mas]
Today, Valve Linux Team posted a great article called “Faster Zombies“. They are trying to develop a Linux version of LFD2 using OpenGL and Linux kernel instead of Direct3D and Windows. So, they modified the game for OpenGL and Linux kernel and optimized the drivers; the result was shocking. The most part of the code was taken from Mac OS and after some modification the result was quite impressive: 315 FPS

The cause . . .

“This experience lead to the question: why does an OpenGL version of our game run faster than Direct3D on Windows 7? It appears that it’s not related to multitasking overhead. We have been doing some fairly close analysis and it comes down to a few additional microseconds overhead per batch in Direct3D which does not affect OpenGL on Windows. Now that we know the hardware is capable of more performance, we will go back and figure out how to mitigate this effect under Direct3D.“

. . . and effect:

“After this work, Left 4 Dead 2 is running at 315 FPS on Linux. That the Linux version runs faster than the Windows version (270.6) seems a little counter-intuitive, given the greater amount of time we have spent on the Windows version. However, it does speak to the underlying efficiency of the kernel and OpenGL. “

que seria de la industria sin valve xD

1 respuesta
sacker

#15 Direct3D tira rendimiento a la basura en cada ciclo... bien hecho xD

Usuarios habituales

  • sacker
  • Kaiserlau
  • Alu
  • MegalomaniaC
  • r2d2rigo