@niñodepapaIncluso en esas reviews que citas la Fury X está rindiendo no menos de lo que "debe", pues estarás de acuerdo en que en términos generales la 980 Ti es superior, y más si hablamos de juegos DX11 como es el caso. De todas formas, ¿no ves cuanto menos extraño que la 980 Ti en ambos casos sólo le saque entr un 20% y menos de eso a la 980 normal? Puede ser por cpudependencia, pero aún así es cuanto menos extraño en un juego con carga gráfica tan clara.
Sea como sea, ahí tienes a las 290 básicas ganando a la 970 (guru3d) etc, si tal la review de ¿computerbase, quizás? se desmarca de la de guru3D y de la que yo puse, pues sus resultados están más alejados de la de guru3D que ésta de la que yo puse (o por lo menos se carga más el escalonamiento de gráficas).
Sea como sea, el juego es notable por rendir bien en todas las plataformas, por mucho gameworks que monte. Si prefieres ponemos gráficas de Primal donde en teoría es más acusado aún el derive hacia arquitecturas de AMD (simple coincidencia de qué efectos priman en dicho juego).
Pero mejor que hablar de eso te digo algo más directo:
¿Sabes quién lleva el tema de relaciones comerciales, PR, etc, ahora mismo en AMD y el área de gráficas sobre todo?
Roy Taylor.
El mismo que trabajó en un puesto similar antes en nvidia:
https://www.linkedin.com/in/roytaylorY el creador de conceptos como el famoso TWIMTBP. Ahora también se le añade el tema de Gaming Evolved de AMD. Mismo pollo, mismo tipo de trabajo, mismo tipo de técnicas. De hecho misma agresividad (en parte eso le buscó problemas en nvidia en su momento, por sus relaciones con alguna prensa no tan positivas como debiera).
Es que no falla, niñodepapa. Que les van la marcha a ambas marcas.
![[carcajad]](/images/smilies/nuevos/risa_ani2.gif "carcajada")
@paconanEl 3570K llegó de una forma un tanto enrevesada, básicamente un colega quería una cpu lo más barata posible para gaming y con presupuesto muy limitado, le busqué 2500K pero cuando por fin decidió renovar no había en ese momento en el mercado. Sí 3570k pero se salía de presupuesto un poco, así que le ofrecí mi cpu al precio de "saldo" y más bajo al que le había encontrado un 2500K y yo puse la diferencia por el 3570K. Un gasto muy pequeño aunque sea para un salto también muy modesto en cpu.
A mí no me cae la breva de encontrarme nunca cpus de OCs de ensueño, al igual que las gpus, las maxwell no me pasan de 1500 MHz por sistema (excepto una 960, y por los pelos, y van 3 GTX 970), las kepler no me pasaban ni llegaban a 1300 ni en csueños, y las cpus siempre cuento con intentar lograr OCs "del pueblo", los asegurados, porque mi mítica suerte dicta que soñar con OCs excelentes no se cumple, que sería romper una racha de muchos años y eso no puede ser...
![[+risas]](/images/smilies/nuevos/risa_ani3.gif "más risas")
Hombre, la Pascal me alcanza puntas de 2139 MHz aunque se estabiliza después a 2088 sostenidos en juegos y ya "calentados" los motores. Que no es mal Oc, pero ya están ahí las memorias Micron para compensar y que no me "emocione" demasiado... (XD)
Los mejores OCs los saqué con un e4300 y un Q6600, y aún así tampoco fueron OCs de los más altos en cada tipo de cpu (pero sí por lo menos tirando a buenos). Antes con AMD me salían aún peores, y con los siguientes intel, bien pero lejos de esos 5 GHz.
ismarub escribió:@wwwendigo . Por no citar un tocho de madre y señor mío, me interesa que explicaras mejor lo de las command_list y el battlefield1.
Por mi parte he descubierto que tengo menos cpu-dependencia con gráficas radeon que con nvidia, cuando en el resto de juegos es al revés. Con una nvidia el procesador se arrastra mucho más que con una radeon a similares parámetros (cuello de cpu).
¿No funciona el driver optimizado de dx11 en el btf1 en las nvidia?.
Las command_list son una función que permite empaquetar una lista de drawcalls independientes entre sí en una única llamada al API pero que permite repartir cada drawcall (que sí, de por sí también son llamadas al API) para ser atendida por un core distinto, esto es, es la única forma de hacer llamadas a D3D11 usando multihilo.
El tema no es con BF1, sino más bien con los BF en general, seguro que en BF3 y si no me equivoco también en BF4 se evitaban su uso porque reprsentaban un perjuicio en el rendimiento comparado a simplemente llamar al API con cada llamada una a una seriadas en un mismo hilo.
Claro, eso pasaba con el driver de AMD, y creo que al principo del driver DX11 con nvidia tampoco iba fina esta característica del API, pero se podía ver sobre el asunto en el desarrollo de BF3:
Aquí hay muchas publicaciones técnicas de DICE sobre estos temas:
http://www.frostbite.com/topics/publications/Y en concreto en ésta se habla del tema del instanciado y además de las command lists en concreto (página 33 y 34):
http://www.frostbite.com/2011/04/direct ... lefield-3/Y de la "utopía" que era por falta de drivers con calidad en este área (lo que no decían es que era sobre todo con una marca concreta, pero claro... qué van a decir con un pase de diapositivas que ponían en eventos donde tanto DICE como AMD hablaban juntos...
![[qmparto]](/images/smilies/net_quemeparto.gif "Que me parto!")
).
Después ya con BF4 como que hablan directamente de Mantle, y ya más tarde ni eso, así que seguramente al final no usarían las command lists de DX11 en su motor.
¿Porqué tira más de cpu en las nvidia que en las AMD? Ni idea, no debería ser así, el driver optimizado evidentemente funciona, sólo hay uno con las optimizaciones ya realizadas, pero por lo que sea no baja el consumo de cpu. Tampoco hay que olvidar que una cpu con un juego no sólo se dedica a gestionar llamadas al API/driver, hace muchas más cosas como físicas, IA, I/Os etc. Ahora, que esto debería ser igual en un sistema con gráfica AMD y otro igual con gráfica nvidia, así que el porqué tira más de cpu, ni idea. Lo único es que AMD juega con ventaja con este juego por las razones históricas que les llevan a probar mucho más en hard de AMD éste y la implementación de efectos desde DICE en sus juegos básicamente consultando cualquier duda con AMD, es posible que simplemente esté en general el juego muy adaptado a las AMD y eso conlleve incluso cosas como se note hasta en la carga del driver (quién sabe, quizás algún efecto usando gpgpu se tiene que procesar desde o almacenar datos en el sistema principal con las nvidia por algún problema puntual de funcionamiento y gestión de recursos, y esto lleve a mayor consumo de cpu).
Realmente no lo sé, sólo que el juego no tiene el mismo rodaje con las nvidia y el driver está "menos preparado" que el de AMD, que lleva desde el comienzo del desarrollo siendo uña y carne con DICE (como lleva siendo normal desde como poco BF:BC2, sino antes). Aún hay que dar gracias que nvidia tenga acceso y comunicación con DICE desde unos meses antes del lanzamiento, aunque dudo que tenga la misma influencia que AMD en las técnicas implementadas en dicho motor, por las razones históricas esgrimidas.
) pero no es cierto, son claramente "proAMD" (por razones históricas de colaboración entre AMD y DICE, no es ya por Mantle, sino por el uso o no de características de distintas APIs como D3D según conveniera, un ejemplo rápido, la negativa a usar en el motor de DICE de las command lists de DX11 por supuestos problemas de rendimiento (con AMD, realmente) cuando representaría algo útil a la larga y que por lo menos sí beneficiaría a la mayoría del mercado que usa nvidia, no estoy hablando de implementar forzosamente las command lists, sino de crear dos paths de ejecución si éstas eran nocivas para AMD, pero no se hizo y adivina porqué).
yo tengo Nvidia y va bien con todos ellos, cuando he tenido AMD no he podido decir lo mismo de los que usan GameWorks.
![[looco]](/images/smilies/nuevos2/borracho.gif "loco")
(a más ya me falta RL o hacerle el delid) 
