Nueva8800GTS 512MB/ <300€!
-
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.
