Dudas sobre sobre qué usa cpu y qué usa gráfica

currante007 escribió:Por ejemplo, juego al fifa 11:

-La navegación por los menús y el almacenamiento de datos: ¿cpu?
- Gráficos y frames dentro del partido: ¿gráfica?

oMega_2093 escribió:Pues el tema no es tan trivial. Ahora porque casi siempre renderizas por hardware, pero hace tiempo eran muy habituales los renderers por software. Es decir, que la parte gráfica la hacía la CPU.

Una CPU puede hacerlo todo (son procesadores de propósito general), pero atento. Un procesador como un Core i7 990X (6 núcleos) puede dar 100 GFLOPS (giga operaciones en coma flotante por segundo). Eso es un procesador de 1000 euros. Ahora, una gráfica que ahora mismo cuesta 100 euros, ofrece 2.5 TFLOPS (HD 5850).

La velocidad de una gráfica al realizar ese tipo de cálculos es bastante superior, y es el tipo de cálculos más habituales a la hora de dibujar gráficos (coma flotante --> vectores). Pero no quiere decir que la CPU no pueda hacerlo.

Ahora mismo como te dicen, cada vez se utilizan más las tarjetas gráficas en más áreas donde dan muy buenos resultados (edición y codificación de video, imagen, cálculos matemáticos...), aprovechándose de esto. Lo que tradicionalmente se reserva a la CPU son los cálculos lógicos y de enteros (de hecho hace tiempo una CPU no incorporaba un área dedicada a la coma flotante, cosa que ahora sí hacen).

Pero es bastante difuso. Una misma aplicación puede usar uno u otro para conseguir lo mismo sin que tú hagas nada ni te des cuenta. A priori no puedes saberlo cuando instalas el programa. Échale un ojo al artículo de aceleración por hardware y puedes continuar con el de GPGPU (enlazado en esa misma página) y otros relacionados.

Quizá puedes pensar que toda la matemática detrás del juego o aplicación la lleva el procesador: es quien dice dónde están los objetos, a qué velocidad se mueven, qué pasa si el objeto choca con otra cosa... Y es la gráfica la que a cada momento, con esos datos, dibuja por pantalla la escena que "piensa" el procesador. Pero dibujar una escena no es un trabajo sencillo, léase rasterización (vectores --> imagen plana).

Los menús tienen su parte gráfica (entradas de los menús, colores de cada cosa, posibles sombras, fondos...) y su parte lógica: una lista (array) de opciones, eventos cuando el jugador pulsa una tecla teniendo una opción seleccionada, cargar la lista de sub-opciones, cambiar de fondo... Y dibujarlo todo. Se complementan para que tú veas lo que ves por pantalla. Pero piensa que detrás de un simple menú, de una letra que se va moviendo por la pantalla, hay un montón de cálculos que hace la CPU y que la GPU recoge y dibuja muchas veces por segundo.

Sobre grabar con el FRAPS, el paso de la información de las imágenes que salen por pantalla al formato de video lo realiza la CPU. Emitir cualquier cosa online lo mismo: es todo lógica, cálculos... No hay que dibujar nada. Piensa que un video no son más que una sucesión de ceros y unos. Transmitir esto por los interfaces de red es trabajo de éstos y de la CPU.

Y sobre la RAM, es un escalón más en la jerarquía de memoria. Para realizar cálculos el procesador necesita datos, que tendrá (o no) almacenados en sus memorias internas (cachés de distintos niveles, actualmente hasta L3), pero si no los encuentra deberá buscarlos en la RAM, y si no están ahí es cuando hay que buscar en el disco duro (los procesos de carga).

Por lo tanto, todo esto depende íntegramente del juego, aplicación o incluso de qué estés haciendo en cada momento. Seguro que no es lo mismo un partido con 2 jugadores y sin público que uno con 22 y con miles de personas en las gradas. No hay que dibujar ni calcular lo mismo en ambas situaciones y en cambio ambas tienen lugar dentro de un juego de fútbol (es por poner un ejemplo, no sé si es bueno), ¿no?

oMega_2093 escribió:Pues el tema no es tan trivial. Ahora porque casi siempre renderizas por hardware, pero hace tiempo eran muy habituales los renderers por software. Es decir, que la parte gráfica la hacía la CPU.

Una CPU puede hacerlo todo (son procesadores de propósito general), pero atento. Un procesador como un Core i7 990X (6 núcleos) puede dar 100 GFLOPS (giga operaciones en coma flotante por segundo). Eso es un procesador de 1000 euros. Ahora, una gráfica que ahora mismo cuesta 100 euros, ofrece 2.5 TFLOPS (HD 5850).

La velocidad de una gráfica al realizar ese tipo de cálculos es bastante superior, y es el tipo de cálculos más habituales a la hora de dibujar gráficos (coma flotante --> vectores). Pero no quiere decir que la CPU no pueda hacerlo.

Ahora mismo como te dicen, cada vez se utilizan más las tarjetas gráficas en más áreas donde dan muy buenos resultados (edición y codificación de video, imagen, cálculos matemáticos...), aprovechándose de esto. Lo que tradicionalmente se reserva a la CPU son los cálculos lógicos y de enteros (de hecho hace tiempo una CPU no incorporaba un área dedicada a la coma flotante, cosa que ahora sí hacen).

Pero es bastante difuso. Una misma aplicación puede usar uno u otro para conseguir lo mismo sin que tú hagas nada ni te des cuenta. A priori no puedes saberlo cuando instalas el programa. Échale un ojo al artículo de aceleración por hardware y puedes continuar con el de GPGPU (enlazado en esa misma página) y otros relacionados.

Quizá puedes pensar que toda la matemática detrás del juego o aplicación la lleva el procesador: es quien dice dónde están los objetos, a qué velocidad se mueven, qué pasa si el objeto choca con otra cosa... Y es la gráfica la que a cada momento, con esos datos, dibuja por pantalla la escena que "piensa" el procesador. Pero dibujar una escena no es un trabajo sencillo, léase rasterización (vectores --> imagen plana).

Los menús tienen su parte gráfica (entradas de los menús, colores de cada cosa, posibles sombras, fondos...) y su parte lógica: una lista (array) de opciones, eventos cuando el jugador pulsa una tecla teniendo una opción seleccionada, cargar la lista de sub-opciones, cambiar de fondo... Y dibujarlo todo. Se complementan para que tú veas lo que ves por pantalla. Pero piensa que detrás de un simple menú, de una letra que se va moviendo por la pantalla, hay un montón de cálculos que hace la CPU y que la GPU recoge y dibuja muchas veces por segundo.

Sobre grabar con el FRAPS, el paso de la información de las imágenes que salen por pantalla al formato de video lo realiza la CPU. Emitir cualquier cosa online lo mismo: es todo lógica, cálculos... No hay que dibujar nada. Piensa que un video no son más que una sucesión de ceros y unos. Transmitir esto por los interfaces de red es trabajo de éstos y de la CPU.

Y sobre la RAM, es un escalón más en la jerarquía de memoria. Para realizar cálculos el procesador necesita datos, que tendrá (o no) almacenados en sus memorias internas (cachés de distintos niveles, actualmente hasta L3), pero si no los encuentra deberá buscarlos en la RAM, y si no están ahí es cuando hay que buscar en el disco duro (los procesos de carga).

Por lo tanto, todo esto depende íntegramente del juego, aplicación o incluso de qué estés haciendo en cada momento. Seguro que no es lo mismo un partido con 2 jugadores y sin público que uno con 22 y con miles de personas en las gradas. No hay que dibujar ni calcular lo mismo en ambas situaciones y en cambio ambas tienen lugar dentro de un juego de fútbol (es por poner un ejemplo, no sé si es bueno), ¿no?

oMega_2093 escribió:Vaya, gracias ¿te ha servido? Lo importante es que te haya aclarado algo.

oMega_2093 escribió:Pues el tema no es tan trivial. Ahora porque casi siempre renderizas por hardware, pero hace tiempo eran muy habituales los renderers por software. Es decir, que la parte gráfica la hacía la CPU.

Una CPU puede hacerlo todo (son procesadores de propósito general), pero atento. Un procesador como un Core i7 990X (6 núcleos) puede dar 100 GFLOPS (giga operaciones en coma flotante por segundo). Eso es un procesador de 1000 euros. Ahora, una gráfica que ahora mismo cuesta 100 euros, ofrece 2.5 TFLOPS (HD 5850).

La velocidad de una gráfica al realizar ese tipo de cálculos es bastante superior, y es el tipo de cálculos más habituales a la hora de dibujar gráficos (coma flotante --> vectores). Pero no quiere decir que la CPU no pueda hacerlo.

Ahora mismo como te dicen, cada vez se utilizan más las tarjetas gráficas en más áreas donde dan muy buenos resultados (edición y codificación de video, imagen, cálculos matemáticos...), aprovechándose de esto. Lo que tradicionalmente se reserva a la CPU son los cálculos lógicos y de enteros (de hecho hace tiempo una CPU no incorporaba un área dedicada a la coma flotante, cosa que ahora sí hacen).

Pero es bastante difuso. Una misma aplicación puede usar uno u otro para conseguir lo mismo sin que tú hagas nada ni te des cuenta. A priori no puedes saberlo cuando instalas el programa. Échale un ojo al artículo de aceleración por hardware y puedes continuar con el de GPGPU (enlazado en esa misma página) y otros relacionados.

Quizá puedes pensar que toda la matemática detrás del juego o aplicación la lleva el procesador: es quien dice dónde están los objetos, a qué velocidad se mueven, qué pasa si el objeto choca con otra cosa... Y es la gráfica la que a cada momento, con esos datos, dibuja por pantalla la escena que "piensa" el procesador. Pero dibujar una escena no es un trabajo sencillo, léase rasterización (vectores --> imagen plana).

Los menús tienen su parte gráfica (entradas de los menús, colores de cada cosa, posibles sombras, fondos...) y su parte lógica: una lista (array) de opciones, eventos cuando el jugador pulsa una tecla teniendo una opción seleccionada, cargar la lista de sub-opciones, cambiar de fondo... Y dibujarlo todo. Se complementan para que tú veas lo que ves por pantalla. Pero piensa que detrás de un simple menú, de una letra que se va moviendo por la pantalla, hay un montón de cálculos que hace la CPU y que la GPU recoge y dibuja muchas veces por segundo.

Sobre grabar con el FRAPS, el paso de la información de las imágenes que salen por pantalla al formato de video lo realiza la CPU. Emitir cualquier cosa online lo mismo: es todo lógica, cálculos... No hay que dibujar nada. Piensa que un video no son más que una sucesión de ceros y unos. Transmitir esto por los interfaces de red es trabajo de éstos y de la CPU.

Y sobre la RAM, es un escalón más en la jerarquía de memoria. Para realizar cálculos el procesador necesita datos, que tendrá (o no) almacenados en sus memorias internas (cachés de distintos niveles, actualmente hasta L3), pero si no los encuentra deberá buscarlos en la RAM, y si no están ahí es cuando hay que buscar en el disco duro (los procesos de carga).

Por lo tanto, todo esto depende íntegramente del juego, aplicación o incluso de qué estés haciendo en cada momento. Seguro que no es lo mismo un partido con 2 jugadores y sin público que uno con 22 y con miles de personas en las gradas. No hay que dibujar ni calcular lo mismo en ambas situaciones y en cambio ambas tienen lugar dentro de un juego de fútbol (es por poner un ejemplo, no sé si es bueno), ¿no?

oMega_2093 escribió:...

currante007 escribió:no sé si era la manera correcta de hacerlo... he reportado su mensaje pero alegando que debería ser un post it. Creo que la he liado, porque reportar creo que implica directamente algo negativo xD

oMega_2093 escribió:Pues el tema no es tan trivial. Ahora porque casi siempre renderizas por hardware, pero hace tiempo eran muy habituales los renderers por software. Es decir, que la parte gráfica la hacía la CPU.

Una CPU puede hacerlo todo (son procesadores de propósito general), pero atento. Un procesador como un Core i7 990X (6 núcleos) puede dar 100 GFLOPS (giga operaciones en coma flotante por segundo). Eso es un procesador de 1000 euros. Ahora, una gráfica que ahora mismo cuesta 100 euros, ofrece 2.5 TFLOPS (HD 5850).

La velocidad de una gráfica al realizar ese tipo de cálculos es bastante superior, y es el tipo de cálculos más habituales a la hora de dibujar gráficos (coma flotante --> vectores). Pero no quiere decir que la CPU no pueda hacerlo.

Ahora mismo como te dicen, cada vez se utilizan más las tarjetas gráficas en más áreas donde dan muy buenos resultados (edición y codificación de video, imagen, cálculos matemáticos...), aprovechándose de esto. Lo que tradicionalmente se reserva a la CPU son los cálculos lógicos y de enteros (de hecho hace tiempo una CPU no incorporaba un área dedicada a la coma flotante, cosa que ahora sí hacen).

Pero es bastante difuso. Una misma aplicación puede usar uno u otro para conseguir lo mismo sin que tú hagas nada ni te des cuenta. A priori no puedes saberlo cuando instalas el programa. Échale un ojo al artículo de aceleración por hardware y puedes continuar con el de GPGPU (enlazado en esa misma página) y otros relacionados.

Quizá puedes pensar que toda la matemática detrás del juego o aplicación la lleva el procesador: es quien dice dónde están los objetos, a qué velocidad se mueven, qué pasa si el objeto choca con otra cosa... Y es la gráfica la que a cada momento, con esos datos, dibuja por pantalla la escena que "piensa" el procesador. Pero dibujar una escena no es un trabajo sencillo, léase rasterización (vectores --> imagen plana).

Los menús tienen su parte gráfica (entradas de los menús, colores de cada cosa, posibles sombras, fondos...) y su parte lógica: una lista (array) de opciones, eventos cuando el jugador pulsa una tecla teniendo una opción seleccionada, cargar la lista de sub-opciones, cambiar de fondo... Y dibujarlo todo. Se complementan para que tú veas lo que ves por pantalla. Pero piensa que detrás de un simple menú, de una letra que se va moviendo por la pantalla, hay un montón de cálculos que hace la CPU y que la GPU recoge y dibuja muchas veces por segundo.

Sobre grabar con el FRAPS, el paso de la información de las imágenes que salen por pantalla al formato de video lo realiza la CPU. Emitir cualquier cosa online lo mismo: es todo lógica, cálculos... No hay que dibujar nada. Piensa que un video no son más que una sucesión de ceros y unos. Transmitir esto por los interfaces de red es trabajo de éstos y de la CPU.

Y sobre la RAM, es un escalón más en la jerarquía de memoria. Para realizar cálculos el procesador necesita datos, que tendrá (o no) almacenados en sus memorias internas (cachés de distintos niveles, actualmente hasta L3), pero si no los encuentra deberá buscarlos en la RAM, y si no están ahí es cuando hay que buscar en el disco duro (los procesos de carga).

Por lo tanto, todo esto depende íntegramente del juego, aplicación o incluso de qué estés haciendo en cada momento. Seguro que no es lo mismo un partido con 2 jugadores y sin público que uno con 22 y con miles de personas en las gradas. No hay que dibujar ni calcular lo mismo en ambas situaciones y en cambio ambas tienen lugar dentro de un juego de fútbol (es por poner un ejemplo, no sé si es bueno), ¿no?

oMega_2093 escribió:Pues el tema no es tan trivial. Ahora porque casi siempre renderizas por hardware, pero hace tiempo eran muy habituales los renderers por software. Es decir, que la parte gráfica la hacía la CPU.

Una CPU puede hacerlo todo (son procesadores de propósito general), pero atento. Un procesador como un Core i7 990X (6 núcleos) puede dar 100 GFLOPS (giga operaciones en coma flotante por segundo). Eso es un procesador de 1000 euros. Ahora, una gráfica que ahora mismo cuesta 100 euros, ofrece 2.5 TFLOPS (HD 5850).

La velocidad de una gráfica al realizar ese tipo de cálculos es bastante superior, y es el tipo de cálculos más habituales a la hora de dibujar gráficos (coma flotante --> vectores). Pero no quiere decir que la CPU no pueda hacerlo.

Ahora mismo como te dicen, cada vez se utilizan más las tarjetas gráficas en más áreas donde dan muy buenos resultados (edición y codificación de video, imagen, cálculos matemáticos...), aprovechándose de esto. Lo que tradicionalmente se reserva a la CPU son los cálculos lógicos y de enteros (de hecho hace tiempo una CPU no incorporaba un área dedicada a la coma flotante, cosa que ahora sí hacen).

Pero es bastante difuso. Una misma aplicación puede usar uno u otro para conseguir lo mismo sin que tú hagas nada ni te des cuenta. A priori no puedes saberlo cuando instalas el programa. Échale un ojo al artículo de aceleración por hardware y puedes continuar con el de GPGPU (enlazado en esa misma página) y otros relacionados.

Quizá puedes pensar que toda la matemática detrás del juego o aplicación la lleva el procesador: es quien dice dónde están los objetos, a qué velocidad se mueven, qué pasa si el objeto choca con otra cosa... Y es la gráfica la que a cada momento, con esos datos, dibuja por pantalla la escena que "piensa" el procesador. Pero dibujar una escena no es un trabajo sencillo, léase rasterización (vectores --> imagen plana).

Los menús tienen su parte gráfica (entradas de los menús, colores de cada cosa, posibles sombras, fondos...) y su parte lógica: una lista (array) de opciones, eventos cuando el jugador pulsa una tecla teniendo una opción seleccionada, cargar la lista de sub-opciones, cambiar de fondo... Y dibujarlo todo. Se complementan para que tú veas lo que ves por pantalla. Pero piensa que detrás de un simple menú, de una letra que se va moviendo por la pantalla, hay un montón de cálculos que hace la CPU y que la GPU recoge y dibuja muchas veces por segundo.

Sobre grabar con el FRAPS, el paso de la información de las imágenes que salen por pantalla al formato de video lo realiza la CPU. Emitir cualquier cosa online lo mismo: es todo lógica, cálculos... No hay que dibujar nada. Piensa que un video no son más que una sucesión de ceros y unos. Transmitir esto por los interfaces de red es trabajo de éstos y de la CPU.

Y sobre la RAM, es un escalón más en la jerarquía de memoria. Para realizar cálculos el procesador necesita datos, que tendrá (o no) almacenados en sus memorias internas (cachés de distintos niveles, actualmente hasta L3), pero si no los encuentra deberá buscarlos en la RAM, y si no están ahí es cuando hay que buscar en el disco duro (los procesos de carga).

Por lo tanto, todo esto depende íntegramente del juego, aplicación o incluso de qué estés haciendo en cada momento. Seguro que no es lo mismo un partido con 2 jugadores y sin público que uno con 22 y con miles de personas en las gradas. No hay que dibujar ni calcular lo mismo en ambas situaciones y en cambio ambas tienen lugar dentro de un juego de fútbol (es por poner un ejemplo, no sé si es bueno), ¿no?

anikilador_imperial escribió:Ahora soy yo el que tiene una duda...¿Porque al iniciar el FRAPS los juegos van peor que sin el? ._.

oMega_2093 escribió:Gracias por los comentarios, no esperaba que gustara tanto el post

anikilador_imperial escribió:Ahora soy yo el que tiene una duda...¿Porque al iniciar el FRAPS los juegos van peor que sin el? ._.

¿Te refieres a cuando grabas un video con FRAPS? ¿O al mero hecho de tener FRAPS corriendo y sólo marcando los frames por segundo?

En el primer caso está claro: el procesador debe capturar y convertir todas las imágenes que se muestran por pantalla (aunque puedes limitarlo, yo lo suelo poner a 25 fps), esto implica trabajo de procesador y de memoria, y también de disco duro: escritura de bastantes datos de forma continua. Los videos de FRAPS no son nada ligeros, y fuerzan al HDD a escribir bastantes datos.

Si te refieres a tener simplemente el FRAPS abierto y con los numeritos amarillos, pues no sabría decirte. Pierdes rendimiento porque hay que hacer más cosas que si no muestras los números, pero no deberías ni darte cuenta. En los equipos más cutres que he probado nunca he notado nada al usar FRAPS sin grabar :S