paconan escribió:WiiBoy escribió:paconan escribió:bueno pues parece que... nvidia va a dar soporte a maxwell 2.0 a los shaders asíncronos esos
http://www.noticias3d.com/noticia.asp?idnoticia=65745
ahora esperemos que empecemos a verlo en videojuegos y podamos disfrutar de la tecnología
lo gracioso de todo esto es que si no llega a ser por el juegecillo ese nadie se entera xd
maxwell 2.0 cuales son ? las 980 ?
son las 900s y la última titan...
las 750 son maxwell 1.0
a ver si más tarde se lo cascan a Kepler tb...
Mahigan escribió:
*This is a work in progress and should be viewed as such*
It's been several weeks since the Ashes of the Singularity benchmarks hit the PC Gaming scene and brought a new feature into our collective vocabulary. Throughout these past few weeks, there has been a lot of confusion and mis-information spreading throughout the web as a result of the rather complex nature of this topic. In an effort, to combat this misinformation, @GorillaSceptre asked if a new thread could be started in order to condense a lot of the information which has been gathered on the topic. This thread is my no means final. This thread is set to change as new information comes to light. If you have new information, feel free to bring it to the attention of the Overclock.net community as a whole by way of commenting on this thread.
As things stand right now, Sept 6, 2015, we're waiting for a new driver, from nVIDIA, to rectify an issue which has inhibited the Maxwell 2 series from supporting Asynchronous Compute. Both Oxide, the developer of the Ashes of the Singularity video game and benchmark, and nVIDIA are working hard to implement a fix to this issue. While we wait for this fix, lets take an opportunity to break down some misconceptions.
nVIDIA HyperQ
nVIDIA implement Asynchronous Compute through what nVIDIA calls "HyperQ". HyperQ is a hybrid solution which is part software scheduling and part hardware scheduling. While little information is available as it pertains to its implementation in nVIDIAs Maxwell/Maxwell 2 architecture, we've been able to piece together just how it works from various sources.
Now I'm certain many of you have seen this image floating around, as it pertains to Kepler's HyperQ implementation:
Warning: Spoiler! (Click to show)
Created with GIMP
What the image shows is a series of CPU Cores (indicated by blue squares) scheduling a series of tasks to another series of queues (indicated in black squares) which are then distributed to the various SMMs throughout the Maxwell 2 architecture. While this image is useful, it doesn't truly tell us what is going on. In order to figure out just what those black squares represent, we need to take a look at the nVIDIA Kepler White Papers. Within these white papers we find the HyperQ being defined as such:
Warning: Spoiler! (Click to show)
Based on this diagram we can infer that HyperQ works through two software components before tasks are scheduled to the hardware:
Grid Management Unit
Work Distributor
So far the scheduling works like this:
The developer sends the batch to the nVIDIA software driver
Within the nVIDIA software driver, the batch is held in a Grid Management Unit
The Grid Management Unit transfers 32 pending grids (32 Compute or 1 Graphic and 31 Compute) to the Work Distributor
The Work Distributor transfers the 32 Compute or 1 Graphic and 31 Compute tasks to the SMMs which are a hardware component withing the nVIDIA GPU.
The components within the SMMs which receive the tasks are called Asynchronous Warp Schedulers and they assign the tasks to available CUDA cores for processing.
Quote:
That's all fine and dandy but what about the extra CPU Overhead associated with scheduling in software?
While it is true that nVIDIAs HyperQ solution would incur a larger degree of CPU overhead, under DirectX12, than AMDs hardware scheduling implementation, it remains to be seen whether or not this will affect performance. It could very well affect performance on, say, a Core i3 or AMD FX processor but you don't see too many people pairing a powerful nVIDIA GeForce GTX 970/980/980 Ti with an under-powered CPU. If folks have the money to dish out on a powerful GPU, they tend to also have the money to dish out on a robust Quad Core processor (Core i5/i7 series).
Therefore there seems to be confusion as to what the "software scheduling'" means. It doesn't mean that Maxwell 2 will be doing compute tasks over the CPU. It means that there is a limitation added to the way nVIDIAs solution can execute tasks in parallel. It's all about what David Kanter was saying on preemption here (starts around 1:18:00 into the video):
Warning: Spoiler! (Click to show)
The main problem with nVIDIAs HyperQ implementation is in terms of preemption. It is in part due to the software scheduling aspect of nVIDIAs Maxwell 2 solution as well as the limitations, in terms of Not being able to execute a second compute task until the end of a draw call boundary (lag or latency being introduced) and lack of error verification, from the Asynchronous Warp Schedulers.
Example:
Say you have a graphic shader, in a frame, that is taking a particularly long time to complete, with Maxwell2, you have to wait for this graphic shader to complete before you can execute another task. If a graphic shader takes 16ms, you have to wait till it completes before executing another graphic or compute command. This is what is called "slow context switching". Every millisecond, brings down your FPS for that frame. Therefore if a graphic shader takes 16ms to execute, a compute task takes 20ms to execute and you've got a copy command taking 5 ms to execute, you end up with a frame which takes 41ms to execute. This introduces a delay, or lag/latency, between executions. While preemption wasn't important for DX11, and nVIDIA primarily designed their Kepler/Maxwell/Maxwell 2 architectures with DX11 in mind, it becomes quite important for DX12 Asynchronous Compute as well as VR.
Warning: Spoiler! (Click to show)
Quote:
Why is this different than GCN?
With GCN, you can execute tasks simultaneously (without a waiting period), the ACEs will also check for errors and re-issue, if needed, to correct an error. You don't need to wait for one task to complete before you work on the next. So say, on GCN, a Graphic shader task takes 16ms to execute, in that same 16ms you can execute many other tasks in parallel (like the compute and copy command above). Therefore your frame ends up taking only 16ms because you're executing several tasks in parallel. There's little to no latency or lag between executions because they execute like Hyper-threading (hence the benefits to the LiquidVR implementation).
Warning: Spoiler! (Click to show)
Quote:
What does this mean for gaming performance?
Developers need to be careful about how they program for Maxwell 2, if they aren't... then far too much latency will be added to a frame. This is true even once nVIDIA fix their driver issue. It's an architectural issue, not a software issue.
Quote:
It's architectural? How so?
Well that's all in how a context switch is performed in hardware. In order to understand this, we need to understand something about the Compute Units found in every GCN based Graphics card since Tahiti. We already know that a Compute Unit can hold several threads, executing in flight, at the same time. The maximum amount of simultaneous threads executed concurrently, per CU, is 2,560 (40 Wavefronts @ 64 Threads ea). GCN can, within one cycle, switch to and begin the execution of a different Wavefront . This allows the entire GCN GPU to perform both a Graphics and Compute task, simultaneously, with extremely low-latency being associated with switching between them. Idle CUs can be switched to a different task at a very fine grained level with a minimum performance penalty associated with the switch.
Warning: Spoiler! (Click to show)
Quote:
Well that's GCN's architecture... What about Maxwell 2 and that Slow Context Switching thing?
In terms of a Context Switch, Maxwell 2 can switch between a Compute and Graphics task in a coarse-grained fashion and pays a penalty (sometimes to the order of over a thousand cycles in worst case scenarios) for doing so. While Maxwell 2 excels at ordering tasks, based on priority, in a way which minimizes conflicts between Graphics and Compute tasks; Maxwell 2 doesn't necessarily gain a boost in performance from doing so. The reason for this is that Maxwell 2 takes a rather large hit when switching contexts. This is why it remains to be seen if Maxwell 2 will gain a performance boost from Asynchronous Compute. A developer would need to finely tune his/her code in order to derive any sort of performance benefits. From all the sources I've seen, Pascal will perhaps fix this problem (but wait and see as it could just be speculation). There is also evidence that Pascal will not fix this issue as you can see here (provided by @Vesku):
Warning: Spoiler! (Click to show)
Source here
nVIDIA may not have thought that the industry would jump on DX12 the way it is right now... pretty much every single title, in 2016, will be built around the DX12 API. We'll even get a few titles in a few months in 2015. What's worse is that the majority of titles, in 2015 and 2016, have partnered with AMD. We can therefore be quite certain that Asynchronous Compute will be implemented, for AMD GCN at least, throughout the majority of DX12 titles to arrive in 2015/2016.
Warning: Spoiler! (Click to show)
There is no underestimating nVIDIAs capacity to fix their driver. It will be fixed. As for the performance derived out of nVIDIAs HyperQ solution? Best to wait and see.
Rivroner escribió:Cuándo salen las Pascal ?
cheewaca escribió:Rivroner escribió:Cuándo salen las Pascal ?
No has leido el enlace, ¿no?. Pascal no tendrá soporte completo por hardware directx12.
Rivroner escribió:cheewaca escribió:Rivroner escribió:Cuándo salen las Pascal ?
No has leido el enlace, ¿no?. Pascal no tendrá soporte completo por hardware directx12.
Me lo he leído por encima, pon ese trozo en concreto por favor.
Pensaba que lo solucionarían mediante hardware ya directamente en Pascal, y en las actuales Maxwell 2.0 como mi 980 mediante software, no queda otra.
Sería de muy chapuzas que las Pascal no tuvieran ya todo lo de dx12 por hardware.
cheewaca escribió:Rivroner escribió:Cuándo salen las Pascal ?
No has leido el enlace, ¿no?. Pascal no tendrá soporte completo por hardware directx12.
Rivroner escribió:cheewaca escribió:Rivroner escribió:Cuándo salen las Pascal ?
No has leido el enlace, ¿no?. Pascal no tendrá soporte completo por hardware directx12.
Debo estar cegato, pero sigo sin encontrar donde dice que las Pascal no soportarán dx12 al completo.
Cuando puedas cítame el párrafo donde lo dice, gracias.
Mahigan escribió: Well that's GCN's architecture... What about Maxwell 2 and that Slow Context Switching thing?
In terms of a Context Switch, Maxwell 2 can switch between a Compute and Graphics task in a coarse-grained fashion and pays a penalty (sometimes to the order of over a thousand cycles in worst case scenarios) for doing so. While Maxwell 2 excels at ordering tasks, based on priority, in a way which minimizes conflicts between Graphics and Compute tasks; Maxwell 2 doesn't necessarily gain a boost in performance from doing so. The reason for this is that Maxwell 2 takes a rather large hit when switching contexts. This is why it remains to be seen if Maxwell 2 will gain a performance boost from Asynchronous Compute. A developer would need to finely tune his/her code in order to derive any sort of performance benefits. From all the sources I've seen, Pascal will perhaps fix this problem (but wait and see as it could just be speculation). There is also evidence that Pascal will not fix this issue as you can see here (provided by @Vesku):
Warning: Spoiler! (Click to show)
Source here
Rivroner escribió:Muchas gracias compañero, pues no molaría nada que eso fuera cierto al final.
De todas formas ya veremos como se comporta mi 980 en juegos nativos dx12 respecto a la 390x y la Fury.
Si hay que pasarse a Amd se pasa, de hecho yo era AMDero.
No le hago ascos a nada vamos.
EDITO: De propina.
https://youtu.be/Dnn0rgDaSro
silfredo escribió:Mira que el rumor MS compra a AMD no es nuevo, pero lo de las ultimas horas no es ni normal y eso que es un sabado
WiiBoy escribió:Yo veo bien que microsoft la compre le apoyara muchísimo y le dará una buena inyección de pasta en I+D ya veremos que pasa
WiiBoy escribió:Yo veo bien que microsoft la compre le apoyara muchísimo y le dará una buena inyección de pasta en I+D ya veremos que pasa
Zoltán Pozsonyi, productor Warhammer 40,000: Inquisitor Martyr escribió:DirectX 12 no es algo que te permita simplemente jugar con algunos efectos nuevos durante el desarrollo. Se trata más de un proceso grande y estructural que permite a los programadores muchas más oportunidades al ofrecer un acceso más sencillo y directo a la GPU. Esto implica que tendrán mucho más margen para implementar optimizaciones de rendimiento y agilizar el código; si eres capaz de exprimir más rendimiento de la GPU, esto se traduce en mejoras en la tasa de imágenes por segundo o en un contendio visual más atractivo en el juego. DX12 soporta shaders de cálculo asincrónico, lo cual nos permite, por ejemplo, usar un mayor número de efectos especiales y de una mayor calidad, así como efectos de post-procesado, y procesarlos de forma mucho más rápida (screen space ambient occlusion, screen space reflection, mejor calidad de shadow mapping, transculency, tone mappin
ROTOR escribió:silfredo escribió:Mira que el rumor MS compra a AMD no es nuevo, pero lo de las ultimas horas no es ni normal y eso que es un sabado
AMD siempre ha tenido muchas novias, sobre todo por su licencia X86, que no se puede traspasar que si, que se pueden hacer trapicheos empresariales, etc, etc.
Aunque AMD no esté en su mejor momento ni de lejos, no creo que le vaya tan mal, esta vendiendo las APU, GPU de consolas por 2 o 3 generaciones y eso le da una válvula de escape, con las GPU no vende tanto como Nvidia, pero tampoco está invirtiendo mucho ya que casi todos sus modelos son RE-re-fritos así que imagino que tendrán un buen margen.
Donde peor lo pasa en es la zona de CPU.
Yo hasta que no vea hechos no me creo nada.
Boris I escribió:A mi me parece que fumais kiffi muy bueno, porque semejantes flipadas por un bench totalmente partidista de una alpha de un estudio de tres al cuarto no es como para decir que NVIDIA no va a poder "ni competir". Es que ni con esos datos en la mano se ve que no puedan competir, como para saber como estara la situacion en pruebas reales. Y juzgar lo que va a pasar con unas tarjetas que aun faltan minimo 6 meses para salir al mercado por lo que diga un friki de un foro ingles es otra barbaridad.
A mi tres pitos me importa una marca u otra, tengo una 7850 y mas contento que para que, y cuando salgan las pascal ya valorare si me paso a NVIDIA o no.
RaulKO escribió:..
No obstante, pienso que aun es pronto para valorar la verdadera gravedad de este asunto, sobre todo hasta que se sepa el rendimiento en juegos de la "solución" que está implementando Nvidia, si bien oídas las explicaciones de como funcionarán en Amd, suena como que Nvidia deberá sacarse un milagro de la manga para poder competir. Claro que, si alguien puede sacar un milagro son ellos.
Y si no dan con la tecla, supongo que los que tenemos la Gtx 980 TI nos veremos obligados a cambiar de gráfica antes de lo esperado, tal vez en favor de una AMD...
Quien sabe, aún es pronto...
If other analysis confirms these figures, it implies that AMD’s GCN-based cards could have real staying power in the DX12 API. For the past few months, there’s been a great deal of chatter back and forth as users debated whether or not DX12 feature levels were likely to deliver significant performance advantages or disadvantages. These types of questions are always best answered by games, and the (very) early DX12 data is looking very solid for Team Red. The fact that the R9 390, at $329, outperforms a GTX 980 with an MSRP of ~$460, is a very nice feather in AMD’s cap.
As with Ashes of the Singularity, the usual caveats apply. These are pre-launch titles and early drivers on a still-young operating system. So far, however, the DX12 results we’ve seen have been very positive for AMD — lending credence to the company’s longstanding argument that GCN would fare well under the new API.
cheewaca escribió:Ya tenemos nuevo test bajo directx 12 de las gpus actuales:
Fable
http://www.extremetech.com/gaming/21483 ... -benchmark
Conclusión final:If other analysis confirms these figures, it implies that AMD’s GCN-based cards could have real staying power in the DX12 API. For the past few months, there’s been a great deal of chatter back and forth as users debated whether or not DX12 feature levels were likely to deliver significant performance advantages or disadvantages. These types of questions are always best answered by games, and the (very) early DX12 data is looking very solid for Team Red. The fact that the R9 390, at $329, outperforms a GTX 980 with an MSRP of ~$460, is a very nice feather in AMD’s cap.
As with Ashes of the Singularity, the usual caveats apply. These are pre-launch titles and early drivers on a still-young operating system. So far, however, the DX12 results we’ve seen have been very positive for AMD — lending credence to the company’s longstanding argument that GCN would fare well under the new API.
Parece ser que los rumores, benchs y tests previos no iban mal desencaminados y las GCN rinden bastante mejor en directx 12.
Un saludo
KailKatarn escribió:cheewaca escribió:Ya tenemos nuevo test bajo directx 12 de las gpus actuales:
Fable
http://www.extremetech.com/gaming/21483 ... -benchmark
Conclusión final:If other analysis confirms these figures, it implies that AMD’s GCN-based cards could have real staying power in the DX12 API. For the past few months, there’s been a great deal of chatter back and forth as users debated whether or not DX12 feature levels were likely to deliver significant performance advantages or disadvantages. These types of questions are always best answered by games, and the (very) early DX12 data is looking very solid for Team Red. The fact that the R9 390, at $329, outperforms a GTX 980 with an MSRP of ~$460, is a very nice feather in AMD’s cap.
As with Ashes of the Singularity, the usual caveats apply. These are pre-launch titles and early drivers on a still-young operating system. So far, however, the DX12 results we’ve seen have been very positive for AMD — lending credence to the company’s longstanding argument that GCN would fare well under the new API.
Parece ser que los rumores, benchs y tests previos no iban mal desencaminados y las GCN rinden bastante mejor en directx 12.
Un saludo
Lol, hay unos cuantos que deberían pasar a por su owned habitual. Aunque de momento quedan cosas por ver porque casi no se ve software y a ver como reacciona Nvidia.
KailKatarn escribió:cheewaca escribió:Ya tenemos nuevo test bajo directx 12 de las gpus actuales:
Fable
http://www.extremetech.com/gaming/21483 ... -benchmark
Conclusión final:If other analysis confirms these figures, it implies that AMD’s GCN-based cards could have real staying power in the DX12 API. For the past few months, there’s been a great deal of chatter back and forth as users debated whether or not DX12 feature levels were likely to deliver significant performance advantages or disadvantages. These types of questions are always best answered by games, and the (very) early DX12 data is looking very solid for Team Red. The fact that the R9 390, at $329, outperforms a GTX 980 with an MSRP of ~$460, is a very nice feather in AMD’s cap.
As with Ashes of the Singularity, the usual caveats apply. These are pre-launch titles and early drivers on a still-young operating system. So far, however, the DX12 results we’ve seen have been very positive for AMD — lending credence to the company’s longstanding argument that GCN would fare well under the new API.
Parece ser que los rumores, benchs y tests previos no iban mal desencaminados y las GCN rinden bastante mejor en directx 12.
Un saludo
Lol, hay unos cuantos que deberían pasar a por su owned habitual. Aunque de momento quedan cosas por ver porque casi no se ve software y a ver como reacciona Nvidia.
Bolo_assassin escribió:Este benchmark no vale para nada.
KailKatarn escribió:Bolo_assassin escribió:Este benchmark no vale para nada.
Claro, ninguno vale, eso ya lo tengo claro desde siempre. Sólo si favorece a nvidia o a intel pueden ser realidad.
Me sé la religión del forero español, no me olvido, no.
Bolo_assassin escribió:El 3D Mark tampoco valía,era mejor el 2011,pero claro ahora si vale.
TP S.A. escribió:Yo con todo esto solo saco una conclusión; larga vida a mi 7950!
KailKatarn escribió:Bolo_assassin escribió:El 3D Mark tampoco valía,era mejor el 2011,pero claro ahora si vale.
Tranquilo a mi me vale cualquier análisis, de cualquier marca siempre y cuando venga de páginas serias y reconocidas. Vamos, que me preocupa 0 quien gane, me preocupa más quien me de más por menos.
PD: una review llevando la contraria a otras 2:
Link: http://techreport.com/review/29090/fabl ... e-revealed
PD2: Otra más:
PD3: Otra más aún:
Ahora ya valen?
ROTOR escribió:Sigo esperando juegos.
Aunque interesante ver q a partir de 4c/8t no se aprecia aumento de rendimiento.
Dfx escribió:ROTOR escribió:Sigo esperando juegos.
Aunque interesante ver q a partir de 4c/8t no se aprecia aumento de rendimiento.
Se supone que DX12 esta optimizado para 6 hilos.
Esos tres ultimos benchmark, no tienen mucho sentido, las diferencias entre la 390X y la Fury X son casi ridiculas, de hecho en el test en LOW la 290X le pasa por delante, ahi falla algo por cojones, deberia haber entre un 15~25% de diferencia a favor de la fury X, lo mismo que se ve claramente entre la 980 y la 980ti
anikilador_imperial escribió:La 290/390 matando a la 980 esto va a ser muy gracioso.
KailKatarn escribió:anikilador_imperial escribió:La 290/390 matando a la 980 esto va a ser muy gracioso.
Queda mucho por ver y por demostrar aún pero vamos de momento si que sirve para que muchos aprieten el culo (y sigan comiendo owned tras owned) y eso ya es más que suficiente para echarse unas risas. Ay! estas marcas ... que malo es profesarles religiones y pasiones.
Medu75 escribió:Amén, yo cada vez que leo los comentarios, de verdad, que me da un poco de .