Nueva8800GTS 512MB/ <300€!
-
Las CPUs cada vez son menos importantes para renderizar los juegos. DX10 acentúa aún más eso con sus nuevas funciones. Las CPUs se encargaran cada vez menos del apartado gráfico y se utilizaran principalmente para la IA y sonido.
Programar un juego en multihilo (otro tipo de aplicaciones es más "sencillo") es bastante complicado ya que en tiempo real son muchas cosas las que a la vez han de sincronizarse (colisiones, gráficos, sonidos, físicas, eventos, etc) y si un por ejemplo un core se retrasa en un cálculo te arriesgas a que todo el rendimiento que podrías haber ganado al dividir las tareas se vaya al tarste. Las CPUs Heterogéneas podrían mejorar eso, pero aún falta para que las veamos…En cuanto a que las CPUs son más complejas... creo que no es así Istarion. Una GPU tiene más componentes internos y externos que una CPU. Pero no soy ingeniero y no sé el porque las gráficas evolucionan mucho más que las CPUs jejeje alguna explicación tendrá jejeje.
Y sobre las nueva GTS… tras el nuevo disipador oficial de nVIDIA para las 8800GT (el de ventilador de 75mm), la GTS sería la 3ª revisión de la GT... no veo un salto como para sacar un nuevo modelo que rinde como una 8800GT OC. Me esperaba una cosa más parecida a la 8800Ultra aunque viendo las velocidades de funcionamiento era de esperar. Habrá que esperar a la Serie 9 para cambiar de GPU...
La ATI 38xx tampoco me terminan de convencer ya que en algunos juegos rinde muy bien pero en otro rinden mucho menos que las nVIDIA.Saludos
-
Volviendo al tema, comparto la opinión de Istarion y añadir que las ati 38x0 cada vez me gustan mas :).
Pues acabo de ver en las noticias de N3D una HD3850 con 512 MB "DDR4" xD Yo creo que todavía falta por ver que sorpresas nos darán las jodias HD3800.
En parte me alegro que Amd/Ati saque unos beneficios decentes, por que esta la pobre de capa caída.
Además, he leído que ahora mismo Amd cuesta menos que lo que costo la compra de Ati… joder
Si…la verdad...tu eres el culpable... :mad: de estar 2 semanas sin ordenador... :mad: me debes 60 euros...cuando quieres que te diga la cuenta donde ingresarlos???? :risitas: :risitas: :risitas:
Jaja
Pues de momento te diré que ahora mismo voy a ver al chico que me compra la 6600GT. Con lo que saco te debería todavía 15 € 
Por cierto, ayer la desmonte el disipa y le puse pasta térmica del curro en condiciones, y descubrí, que cuando la llevaron a RMA le cambiaron el Core encima todavía se veían restos del soldador por el PCB.
Joder, o sea que me cargué la GPU y la cambiaron… hay que reconocer que los de Leadtek se portan
P.D: ya esta vendida... dime tu numero de cuenta
Ya tengo 125€ reunidillos, casi tengo para una HD 3850 xDPD: También es cierto que los DX10 merman un burrada el rendimiento para las mejoras que ofrecen y por eso se requiere de gráficas más potentes y no tanto de CPUs más potentes.
La pena es que no se potencie también el OpenGL, que parece que todo es DX 10. Y no digo que fuera malo, eh? Quizás el problema es que cada vez se programa mas a toida prisa y sin pulir el código.
Como si se quisiera fabrican en una cadena de montaje
Si el DX 10 y el DX 9.0, o el Open GL se le sacara rendimiento, podríamos ver unos juegos muchos más optimizados, complejos y con muchas mas novedades.
Quizás el Open GL este mejor aprovechado, pero menos implementado.Saludos!!
-
OpenGL suele estar bien implementado porque normalmente sólo lo usa Carmak… y es uno de los mejores programadores de juegos del mundo jejejeje. El problema de OpenGL es más "complicado". DX te da más facilidades (aunque en el 10 ha desaparecido el Direct Input y Direct Sound 3D) y por ejemplo al portar juegos a Xbox no tienes que reprogramar tanto XDD.
Aunque está claro que las prisas a la hora de desarrollar un juego suelen probocar que el rendimiento no sea tan bueno como podría, muchas veces tampoco se pueden hacer milagros y si queremos HDR, iluminación y sombras en tiempo real, texturas de 2o 4k, texturas volumétricas, modelos con miles de polígonos, físicas realistas, sonido real envolvente, IA avanzada.... suelen pedir más máquina de la que nos gustaría.
Saludos
-
Pues acabo de ver en las noticias de N3D una HD3850 con 512 MB "DDR4" xD Yo creo que todavía falta por ver que sorpresas nos darán las jodias HD3800.
En parte me alegro que Amd/Ati saque unos beneficios decentes, por que esta la pobre de capa caída.
Además, he leído que ahora mismo Amd cuesta menos que lo que costo la compra de Ati… joderJaja
Pues de momento te diré que ahora mismo voy a ver al chico que me compra la 6600GT. Con lo que saco te debería todavía 15 €
Por cierto, ayer la desmonte el disipa y le puse pasta térmica del curro en condiciones, y descubrí, que cuando la llevaron a RMA le cambiaron el Core encima todavía se veían restos del soldador por el PCB.
Joder, o sea que me cargué la GPU y la cambiaron... hay que reconocer que los de Leadtek se portanP.D: ya esta vendida... dime tu numero de cuenta
Ya tengo 125€ reunidillos, casi tengo para una HD 3850 xDLa pena es que no se potencie también el OpenGL, que parece que todo es DX 10. Y no digo que fuera malo, eh? Quizás el problema es que cada vez se programa mas a toida prisa y sin pulir el código.
Como si se quisiera fabrican en una cadena de montaje
Si el DX 10 y el DX 9.0, o el Open GL se le sacara rendimiento, podríamos ver unos juegos muchos más optimizados, complejos y con muchas mas novedades.
Quizás el Open GL este mejor aprovechado, pero menos implementado.Saludos!!
Por cuando has vendido la 6600 GT, a que tengo aki tirada una C3D y nadie me dice na…algun comprador??? me han dicho que va mas que la GTS 512 G92
-
Por cuando has vendido la 6600 GT, a que tengo aki tirada una C3D y nadie me dice na…algun comprador??? me han dicho que va mas que la GTS 512 G92
Jaja, si, tira mas que la 8800GTS nueva xD Pues 45€ que tengo en el bolsillo ya
A si que, dala matarile, que como tardes mas en venderla, te toca pagar por que se la lleven. -
Las CPUs cada vez son menos importantes para renderizar los juegos. DX10 acentúa aún más eso con sus nuevas funciones. Las CPUs se encargaran cada vez menos del apartado gráfico y se utilizaran principalmente para la IA y sonido.
Programar un juego en multihilo (otro tipo de aplicaciones es más "sencillo") es bastante complicado ya que en tiempo real son muchas cosas las que a la vez han de sincronizarse (colisiones, gráficos, sonidos, físicas, eventos, etc) y si un por ejemplo un core se retrasa en un cálculo te arriesgas a que todo el rendimiento que podrías haber ganado al dividir las tareas se vaya al tarste. Las CPUs Heterogéneas podrían mejorar eso, pero aún falta para que las veamos…A ver por partes, las cpus se encargan cada vez menos del apartado grafico en parte, porque a pesar de que las graficas cada vez hacen mas cosas, es la cpu quien les dice que han de hacer. Y como quieras hacer muchas cosas "distintas" por frame, tendras que decirle mas cosas, asi que es posible que sean menos importantes para "mandar instrucciones" (que no renderizar :p) porque se suelen centrar en evitar hacer tantas llamadas a la grafica, haciendo pocas y mandando mucha mas informacion. Pero aun asi, si tienes que mandar mas instrucciones vas a tener el mismo problema… no se hasta que punto se esta llegando a esto, yo creo que por ahora no existe este problema, pero es algo que puede que surja, pues por ahora los c2d van a reinar una buena temporadita, sin casi incrementos ni mejoras exceptuando el paso a 45nm y un poco mas de clock...
Lo de programar un juego en multihilo es una movida, esta claro. Lo que hacen a veces es centrarse solo en hacer algun modulo multihilo y si no se ha acabado el calculo a tiempo se desecha perdiendo precision, pero nada mas (en la fisica se puede usar para añadir mas calidad a los calculos).
Lo que yo me referia solo a la parte de renderizado, ahora mismo no se que pasa si haces dos renders a la vez... aunque pensandolo me lo temo, simplemente seria como tener 1 render, en el que se van intercalando las instrucciones, de tal manera que puede que tengas fallos en la imagen porque haces llamadas incoherentes y todo eso... uhm se tendria que sincronizar para que el trabajo de un core no machacara el del otro, con lo que me temo que no se puede hacer... cuando una cpu le pasa algo a la grafica, la grafica esta "bloqueada", con lo que el otro core nunca podra hacer nada... es como un embudo, solo pasa una instruccion a la vez.
Con lo que definitivamente la unica manera de evitar que la cpu haga cuello de botella es haciendo que sea mas rapido, o dedicar un solo core a las optimizaciones de renderizado, para minimizar el numero de cosas a renderizar, y que las que se dibujen se hagan a una calidad optima.En cuanto a que las CPUs son más complejas… creo que no es así Istarion. Una GPU tiene más componentes internos y externos que una CPU. Pero no soy ingeniero y no sé el porque las gráficas evolucionan mucho más que las CPUs jejeje alguna explicación tendrá jejeje.
SaludosLa verdad que no estoy seguro de que es mas complejo, pero yo pensaba que es mas complejo hacer cpus que graficas, mas que nada porque las graficas son algo mas especifico, que ademas "solo" tienen que cumplir las especificaciones de las APIs de programacion grafica, y cuando se saca una nueva version "solo" tienes que incluir las nuevas funciones. Todo lo demas son añadidos de las empresas por marketing, por necesidad del publico o cosas asi (pure video, etc.)… Pero vamos yo no se mucho de electronica (por no decir nada), y no se la complejidad de cpus ni de graficas
Y sobre las nueva GTS… tras el nuevo disipador oficial de nVIDIA para las 8800GT (el de ventilador de 75mm), la GTS sería la 3ª revisión de la GT... no veo un salto como para sacar un nuevo modelo que rinde como una 8800GT OC. Me esperaba una cosa más parecida a la 8800Ultra aunque viendo las velocidades de funcionamiento era de esperar. Habrá que esperar a la Serie 9 para cambiar de GPU...
La ATI 38xx tampoco me terminan de convencer ya que en algunos juegos rinde muy bien pero en otro rinden mucho menos que las nVIDIA.Saludos
Ya, a mi tambien me ha decepcionado la gts. Sin embargo, rinde a la par que una ultra, y por la mitad. Aunque no sea nada nuevo (ya habiamos visto ese rendimiento hace mucho tiempo de mano de las ultras), vale la mitad, es significativo
Madre mia soy el señor de los tochos xDDD
Intel Xeon E3 1231v3 @ 3.4Ghz / 16GB DDR3 2133Mhz 11-11-11 / R290 PRO / Samsung 970 Evo 500GB / Samsung 840 250GB / 2xHDD / Netway 700w
-
Pues si Istarion, la HD3850 también es mi favorita ahora y como las HD3870 bajen un poco…
Pues acabo de ver en las noticias de N3D una HD3850 con 512 MB "DDR4" xD Yo creo que todavía falta por ver que sorpresas nos darán las jodias HD3800.
En parte me alegro que Amd/Ati saque unos beneficios decentes, por que esta la pobre de capa caída.
Además, he leído que ahora mismo Amd cuesta menos que lo que costo la compra de Ati… joderY cada vez me gustan mas, mas y mas, y mucho maaaaaaas :risitas: :risitas:
-
Pues si Istarion, la HD3850 también es mi favorita ahora y como las HD3870 bajen un poco…
Y cada vez me gustan mas, mas y mas, y mucho maaaaaaas :risitas: :risitas:
Hombre, si esperamos después de Navidad, seguro que bajan de precio cosa tonta, por no decir, Drivers mas puliditos, etc.
Yo menos de la HD3870 no pienso mirar. Y mira que en Izarmicro tiene una HD3850 de 512MB modelo de HIS estupenda.
De todos modos, ese mismo modelo, pero en la HD3870, entonces si se me hace la boca agua.Saludos!!
P.D: joe, debo ser de los pocos que no piensa en la 8800GT xD aunque reconozco que como bajen de precio estas…ufff, será difícil elegir, eh? Por que tiran muy muy bien.
-
Cuando utilicé la palabra renderizar no me refería a que la CPU sea la que lo hace, ya que a no ser que sea render por software es siempre la GPU la que pinta las imágenes en pantalla.
DX10 y sus nuevos efectos no hacen que la gráfica dependa más de la CPU, al contrario, y lo que se pretende con los V&P Shaders es hacer cada vez más independiente la GPU de la CPU de forma que las transformaciones se realicen en la GPU y no en la CPU por ejemplo. El T&L fué el primer salto en este sentido.
El problema de las "llamadas" no tiene que ver con la GPU, ahi es la CPU la que se satura. Existen motores gráficos que por unas razones u otras realizan muchas llamadas al API ya sea porque no indexan, porque pintan la imagen en varias pasadas o por lo que sea, que este a su vez manda a la CPU u otros que no usan (o lo hacen poco) los Shaders y realizan más calculos en la CPU. Ese tipo de motores son más dependientes de la CPU (engine Doom 3 o HL2 por ejemplo). En esos pasa lo contrario de lo que sucede con Crysis por ejemplo, la gráfica va "sobrada" y es la CPU la que no da a basto, determinando en un mayor porcentaje de lo habitual el rendimiento del engine.
Pero vamos que normalmente es la GPU la que determina que un juego funcione bien o mal.En cuanto a que la GTS 65nm es como una Ultra… aún no he visto un review que diga eso... y menos a altas resoluciones. Que la Ultra sea muy cara y grande estoy deacuerdo, pero que la GTS rinda igual, sea más pequeña y cueste la mitad no me parece que sea cierto.
Saludos
-
Cuando utilicé la palabra renderizar no me refería a que la CPU sea la que lo hace, ya que a no ser que sea render por software es siempre la GPU la que pinta las imágenes en pantalla.
Era porque inducia a confusiones
DX10 y sus nuevos efectos no hacen que la gráfica dependa más de la CPU, al contrario, y lo que se pretende con los V&P Shaders es hacer cada vez más independiente la GPU de la CPU de forma que las transformaciones se realicen en la GPU y no en la CPU por ejemplo. El T&L fué el primer salto en este sentido.
Uhm creo que no me he explicado muy bien… Lo que queria decir es que por mas independencia que le des a las instrucciones de renderizado, de tal manera que la cpu haga las minimas llamadas, si metes mas efectos/modelos/shaders o lo que sea, vas a tener que hacer mas llamadas necesariamente. Ese es el "problema" que veo. Es decir, poniendo un ejemplo irreal, si cada siguiente parte de un juego duplica las llamadas a una api, y el procesador no duplica su rendimiento, llegara a hacer cuello de botella. Esto es a lo que me referia :sisi: (si bien la evolucion de los juegos no creo que sea asi, es un ejemplo exagerado para que quede claro).
El problema de las "llamadas" no tiene que ver con la GPU, ahi es la CPU la que se satura. Existen motores gráficos que por unas razones u otras realizan muchas llamadas al API ya sea porque no indexan, porque pintan la imagen en varias pasadas o por lo que sea, que este a su vez manda a la CPU u otros que no usan (o lo hacen poco) los Shaders y realizan más calculos en la CPU. Ese tipo de motores son más dependientes de la CPU (engine Doom 3 o HL2 por ejemplo). En esos pasa lo contrario de lo que sucede con Crysis por ejemplo, la gráfica va "sobrada" y es la CPU la que no da a basto, determinando en un mayor porcentaje de lo habitual el rendimiento del engine.
Pero vamos que normalmente es la GPU la que determina que un juego funcione bien o mal.No entiendo lo que quieres decir a que mande a la CPU los shaders :S
El resto del parrafo es lo que habia comentado
aunque creo que lo he vuelto a explicar mal :vayatela:Las llamadas a una API saturan al procesador, pero tambien llenan el bus de datos de la grafica (pcie/agp), y hacen que esta trabaje (si bien hay llamadas mas o menos "costosas" para la grafica). Es decir, el problema esta en que tanto la cpu como la grafica estan "bloqueados" mientras haces una llamada, y cuando acabas de hacerla, ya tienes la cpu liberada, y le puedes pasar mas datos a la grafica. De esta manera aunque tengas otro procesador, no podras hacer otra llamada a la vez, porque el bus de datos esta ocupado transfiriendo informacion.
Esto era lo que queria decir, espero que haya quedado un poco mas claro ahora que estoy de un patoso… :nono:
@ManuHard:En cuanto a que la GTS 65nm es como una Ultra… aún no he visto un review que diga eso... y menos a altas resoluciones. Que la Ultra sea muy cara y grande estoy deacuerdo, pero que la GTS rinda igual, sea más pequeña y cueste la mitad no me parece que sea cierto.
Tienes razon, me he columpiado :muerto: . Solo me habia fijado en resoluciones interesantes para la mayoria de los mortales como bien dice Neptunno, alrededor de 1280x1024 o maximo 1600x1200 :rollani: que ahi si que tira de coña la gts
-
Wuenas de nuevo
Era porque inducia a confusiones
jejeje si… puede que lo explicara mal :risitas:
Uhm creo que no me he explicado muy bien… Lo que queria decir es que por mas independencia que le des a las instrucciones de renderizado, de tal manera que la cpu haga las minimas llamadas, si metes mas efectos/modelos/shaders o lo que sea, vas a tener que hacer mas llamadas necesariamente. Ese es el "problema" que veo. Es decir, poniendo un ejemplo irreal, si cada siguiente parte de un juego duplica las llamadas a una api, y el procesador no duplica su rendimiento, llegara a hacer cuello de botella. Esto es a lo que me referia :sisi: (si bien la evolucion de los juegos no creo que sea asi, es un ejemplo exagerado para que quede claro).
No necesariamente. Las nuevas funciones gráficas muchas veces se idean no para lograr mejores gráficos si no para ser independiestes de la CPU. DX10.1 por ejemplo es otro salto más en ese aspecto. Se intenta que todo se haga dentro de la gráfica y que la CPU únicamente se encarge de mandarle a la gráfica las transformaciones de vértices. Aunque con DX10.1 incluso algunas transformaciones ya se llevan a cabo en el interior de la GPU dependiendo de como se programe el motor. Aunque también es cierto que hay tanta cantidad de polígonos por frame en juegos como Crysis que aunque la CPU no haga nada más que eso le es ya suficiente jejeje.
Además una GPU es mucho más potente en cálculos matemáticos con lo que tener una CPU por medio solo relentiza el proceso de renderizar imágenes 3D. Las gráficas multinúcleo y con caché integrada al estilo de las CPU creo que serán el primer paso.No entiendo lo que quieres decir a que mande a la CPU los shaders :S
El resto del parrafo es lo que habia comentado aunque creo que lo he vuelto a explicar mal :vayatela:Las llamadas a una API saturan al procesador, pero tambien llenan el bus de datos de la grafica (pcie/agp), y hacen que esta trabaje (si bien hay llamadas mas o menos "costosas" para la grafica). Es decir, el problema esta en que tanto la cpu como la grafica estan "bloqueados" mientras haces una llamada, y cuando acabas de hacerla, ya tienes la cpu liberada, y le puedes pasar mas datos a la grafica. De esta manera aunque tengas otro procesador, no podras hacer otra llamada a la vez, porque el bus de datos esta ocupado transfiriendo informacion.
Esto era lo que queria decir, espero que haya quedado un poco mas claro ahora que estoy de un patoso… :nono:jeejje lo puse un poco liado la verdad. Sólo me referia a que la hay motores gráficos que hacen muchas llamadas al API y que ese se las manda a la CPU para procesarlas. Sólo eso :muerto:
Tú puedes mandar llamadas al API y por consiguiente a la CPU y ésta no se "bloquea" mientras le queden MHz "libres" jejeje. Sin por cada llamada la CPU no pudiera continuar con otra hasta que no la terminara los juegos no funcionarían :risitas:
Tienes razon, me he columpiado :muerto: . Solo me habia fijado en resoluciones interesantes para la mayoria de los mortales como bien dice Neptunno, alrededor de 1280x1024 o maximo 1600x1200 :rollani: que ahi si que tira de coña la gts
jejeje que me digas que es una GTX es más realista y que con OC altito la supera casi siempre o siempre también, pero una Ultra no es
. Pero esta claro que por el precio está muy bien. Pero no se ha de engañar nadie que nos estan vendiendo tecnología "antigua" y que además ni una Ultra mueve el Crysis a alto detalle con lo que son buenas tarjetas pero no van sobradas pensando en el futuro.Saludos!
-
Pues eso, se esperaban a 330-360e, pero hoy he preguntado en pccomponentes y están a 294 y 299€!
Os dejo los links por si os interesan:
http://www.pccomponentes.com/POINT_OF_VIEW_GEFORCE_8800GTS_512MB_GDDR3_PCI_E___MOTO_GP_07.html
http://www.pccomponentes.com/XFX_GEFORCE_8800GTS_512MB_GDDR3_PCI_E.htmlSalu2!
El primer link no funciona ya, ¿lo has arreglado tú? Hay que ver como son las cosas, registrado en diciembre y con 29 mensajes que, 20 de ellos, son publicidad :resaca:
¿A dónde vamos a ir a parar para que pccomponentes venda? :nono:
-
Tachan!!!!! ya la tengo!!!! bueno, primero viciar y luego comentare…esta va por ti neptunno!!!!
-
El primer link no funciona ya, ¿lo has arreglado tú? Hay que ver como son las cosas, registrado en diciembre y con 29 mensajes que, 20 de ellos, son publicidad :resaca:
¿A dónde vamos a ir a parar para que pccomponentes venda? :nono:
La verdad que no se si este hombre habra venido para hacer publicidad. Quizas era lo que el decia, una tienda barata que le ha dado buenos resultados, ahora bien si te acabas de registrar y por todo dices que es la leche, estas mermando tu credibilidad :rollani:
Bueno extrayendo lo bueno de este (ex)forero, por lo menos ha generado una discusion muy interesante :sisi:No necesariamente. Las nuevas funciones gráficas muchas veces se idean no para lograr mejores gráficos si no para ser independiestes de la CPU. DX10.1 por ejemplo es otro salto más en ese aspecto. Se intenta que todo se haga dentro de la gráfica y que la CPU únicamente se encarge de mandarle a la gráfica las transformaciones de vértices. Aunque con DX10.1 incluso algunas transformaciones ya se llevan a cabo en el interior de la GPU dependiendo de como se programe el motor. Aunque también es cierto que hay tanta cantidad de polígonos por frame en juegos como Crysis que aunque la CPU no haga nada más que eso le es ya suficiente jejeje.
Además una GPU es mucho más potente en cálculos matemáticos con lo que tener una CPU por medio solo relentiza el proceso de renderizar imágenes 3D. Las gráficas multinúcleo y con caché integrada al estilo de las CPU creo que serán el primer paso.Si bueno, la mayoria de las extensiones (yo suelo hablar de Opengl que es con lo que he programado :p) se suelen usar para evitar hacer llamadas o soportar nuevos efectos; por ejemplo, los "point sprites" te evitan hacer 3 llamadas, que parecen poca cosa, pero si has de renderizar 2.000 estrellas, estas evitando 6.000 llamadas, es algo considerable. Igual con los Vertex Buffer Objects, que haces una llamada y pasas un monton de informacion a la tarjeta grafica, en vez de ir pasando vertice a vertice…
Ahora bien, las transformaciones sobre los vertices se hacen todas en la grafica (lo de T&L es eso, Transformation and Lighting). Puedes hacer calculos geometricos en la cpu, pero es absurdo ya que es mas lenta que la gpu y al final vas a tener que pasar igualmente esa informacion a la grafica.
@ManuHard:jeejje lo puse un poco liado la verdad. Sólo me referia a que la hay motores gráficos que hacen muchas llamadas al API y que ese se las manda a la CPU para procesarlas. Sólo eso :muerto:
Tú puedes mandar llamadas al API y por consiguiente a la CPU y ésta no se "bloquea" mientras le queden MHz "libres" jejeje. Sin por cada llamada la CPU no pudiera continuar con otra hasta que no la terminara los juegos no funcionarían :risitas:
Uhmm, aqui hay un batiburrillo de ideas. Es decir, la cpu hace llamadas a la API, y esta se encarga de pasarle la informacion a la gpu, pero usando el procesador (y pasando por el bus de datos).
Por cada llamada la CPU no puede continuar con otra hasta que no termine! es decir, cuando llamas "glBegin(GL_TRIANGLES);" le dices a la grafica "ey que voy a dibujar triangulos", y esa informacion pasa por el bus de datos hasta llegar a la grafica, que se queda "esperando" a que le digas que deje de dibujar. Luego pasas los vertices que quieras (puedes dibujar varios triangulos, y si pasas menos de 3 vertices simplemente se deshechan), y cuando acabas llamas a "glEnd();", que le dice a la grafica que deje de dibujar.Torrada sobre el pipeline de una grafica (basado en el Libro Rojo de OpenGL, gratuito hasta la version 1.1 de OGL ;D )
Estos triangulos pasan por toda la "pipeline" de la grafica, quien la coloca donde toca (transformaciones geometricas), se generan las coordenadas de texturas, se calcula la iluminacion por hardware sobre cada vertice (los lightmaps NO ocurren aqui, la mayoria de los juegos tienen esta iluminacion deshabilitada), genera el "contorno" de la primitiva, la recorta si no cabe en pantalla, aplica la proyeccion que tenemos activada (perspectiva u ortogonal), y finalmente la colocacion que tendra en el viewport (la ventana del juego) y la profunidad de la primitva.
Aun asi no tenemos nada dibujado en la pantalla, pasamos a la fase de "Fragment Operations" segun la define OpenGL. Aqui es donde se pasa a crear los "fragmentos" (pixels) que luego se volcaran a la pantalla. Todavia suceden operaciones en la grafica, como los conocidos pixel/fragment shaders (es lo mismo), y tambien otras operaciones mas arcaicas de cuando no habia shaders, como los buffers de acumulacion, los "stencil" buffers, el fog, el test del buffer de profundidad (se dibuja lo mas cercano a la pantalla; al estar aqui es mejor no enviar nada a la grafica que vaya a estar detras de una pared, porque asi no tienes que dibujarlo y luego descartar todos los calculos) y la texturizacion, para acabar con el blending, dithering y demas operaciones. Finalmente esto se vuelca en un buffer donde pasaran a ser "pixels" realmente, y de este buffer se volcara a la pantalla.
Los vertex shaders suceden por el principio, donde las transformaciones de vertices.Fin de la torrada :mudo:
Dios como torro la oreja; bueno al grano, la cpu hace las llamadas a la API, y esta se encarga de decirle a la grafica lo que quieres dibujar (simplificando). La cpu mientras "habla" con la grafica esta bloqueada, vemos este efecto en cuanto un juego pega tirones y va lento, es causado porque los comandos que le enviamos (la cpu) a la grafica son demasiados, y esta es incapaz de hacerlo a tiempo. Por ello esta mas tiempo del necesario procesando informacion, y baja el numero de fps.
Es por esto que cuando en los juegos hay explosiones pegan tirones y bajadas de fps, porque aparecen muchas llamadas nuevas a la grafica, y si esta no es lo suficientemente rapida, tarda mas en renderizar el frame :sisi:
Acabando (ya era hora!!) con un ejemplo irreal! pero para aclarar las cosas:
sin explosiones: 1M triangulos, 60fps
con explosiones y nuevos bichos: 1'2M triangulos, 45fps
Repito los numeros estan al "tun tun", pero es para hacernos a la idea que he explicado (bastante mal, hoy vuelvo a estar espeso :muerto: ) -
jajaja que tochos más didacticos
Saludos makina -
Pues la verdad leyendo lo que puse ayer parece que hay un tocho que sobra un poco
lo que pasa que era para aclararme porque tenia alguna duda. De hecho sigo con dudas :vayatela:, hay una parte del proceso que no acabo de comprender; en internet hay mucha informacion sobre programacion y todo eso, pero la parte basica de como funciona todo no veo nada :nono:No se muy bien que ocurre cuando tu haces una llamada de opengl (o directx). Creo que es algo asi como lo que sigue (aunque si se pasara kynes seguramente nos lo aclaraba todo en un momento :p):
Haces una llamada opengl (pongamos glVertex3f(…);), esta llamada esta en una libreria dinamica (.dll en windows), que a su vez hace una llamada (o encapsula) al driver de la tarjeta grafica para la misma funcion (pongamos que si fuera ati se llamara ATIvertex(...) ), y esta funcion incluida en los drivers simplemente tiene instrucciones para pasarle a "x" direccion de memoria de la tarjeta grafica "y" datos (el vertice), algo asi. Entonces la grafica cuando le dices "glEnd" se pone a trabajar con los datos que tiene, recorriendo todo el pipeline hasta que se queda en el buffer. La ultima llamada que haces es la de "swapear" los buffers (intercambiarlos, lo tipico del doble buffer para volcar a la pantalla sin parpadeos) y el de la grafica se vuelca en pantalla, obteniendo la imagen deseada...Creo que viene a ser algo asi, el problema que para estas cosas es dificil encontrar informacion, y si supiera un poco de electronica seguramente sabria mas acerca del funcionamiento interno de las graficas, algo que me interesa pero de lo que no tengo ni idea
y seguramente me aclararia limitaciones y demas cosas.Intel Xeon E3 1231v3 @ 3.4Ghz / 16GB DDR3 2133Mhz 11-11-11 / R290 PRO / Samsung 970 Evo 500GB / Samsung 840 250GB / 2xHDD / Netway 700w
-
Hola soy nuevo y recientemente he consegido una EVGA 8800gts g92 512
os pongo la review que hize por si os interesa viene con algo de oc de serie
http://www.nextgpu.com/index.php?op…27&topic=1696.0
un saludo
personalmente creo que una 8800gt tiene mejor calidad/precio pero visto el stock cogi esta.
pero pasara lo mismo con estas GTS XD hay que decidirse rapido.
SIRIKer está en línea Sumar reputación a SIRIKer Editar/Borrar post -
Hola SIRIKer, en primer lugar bienvenido a hardlimit, segundo, supongo que el link correcto es http://www.nextgpu.com/index.php?option=com_smf&Itemid=27&topic=1696.0 y tercero, como puedes ver no se pueden poner imagenes en la firma
Una vez mas, bienvenido -
Hola SIRIKer, en primer lugar bienvenido a hardlimit, segundo, supongo que el link correcto es http://www.nextgpu.com/index.php?option=com_smf&Itemid=27&topic=1696.0 y tercero, como puedes ver no se pueden poner imagenes en la firma
Una vez mas, bienvenidopido perdon
no me moleste en leer las normas.
mia culpa
-
Pues la verdad leyendo lo que puse ayer parece que hay un tocho que sobra un poco
lo que pasa que era para aclararme porque tenia alguna duda. De hecho sigo con dudas :vayatela:, hay una parte del proceso que no acabo de comprender; en internet hay mucha informacion sobre programacion y todo eso, pero la parte basica de como funciona todo no veo nada :nono:No se muy bien que ocurre cuando tu haces una llamada de opengl (o directx). Creo que es algo asi como lo que sigue (aunque si se pasara kynes seguramente nos lo aclaraba todo en un momento :p):
Haces una llamada opengl (pongamos glVertex3f(…);), esta llamada esta en una libreria dinamica (.dll en windows), que a su vez hace una llamada (o encapsula) al driver de la tarjeta grafica para la misma funcion (pongamos que si fuera ati se llamara ATIvertex(...) ), y esta funcion incluida en los drivers simplemente tiene instrucciones para pasarle a "x" direccion de memoria de la tarjeta grafica "y" datos (el vertice), algo asi. Entonces la grafica cuando le dices "glEnd" se pone a trabajar con los datos que tiene, recorriendo todo el pipeline hasta que se queda en el buffer. La ultima llamada que haces es la de "swapear" los buffers (intercambiarlos, lo tipico del doble buffer para volcar a la pantalla sin parpadeos) y el de la grafica se vuelca en pantalla, obteniendo la imagen deseada...Creo que viene a ser algo asi, el problema que para estas cosas es dificil encontrar informacion, y si supiera un poco de electronica seguramente sabria mas acerca del funcionamiento interno de las graficas, algo que me interesa pero de lo que no tengo ni idea
y seguramente me aclararia limitaciones y demas cosas.Te he mandado un MP con el mail de mi brother, haber si te sirve. Esta malito (costipaillo) asi que si le escribes algo tardara unos dís en responderte.
Saludos!
PD: Bienvenido SIRIKer
vamos a hecharle un hojo a ese review.
