Online-Abo
  • Login
  • Registrieren
Games World
      • Von Cleriker PCGH-Community-Veteran(in)
        Deinen post verstehe ich nicht. Worauf beziehst du dich und was meinst du?
      • Von 45thFuchs Software-Overclocker(in)
        Tun wir doch alle ,auch wenn es manchmal schlecht ist .
      • Von Cleriker PCGH-Community-Veteran(in)
        Danke für die Antwort.
      • Von Locuza Lötkolbengott/-göttin
        Zitat von Cleriker
        Hm... also wenn ac dort aktiviert wird rechnet Pascal so wie GCN parallel die Aufgaben weg und Maxwell nacheinander, richtig? So wie ich das verstehe ist die Art und Weise wie AC berechnet wird nicht direkt vorgegeben, sondern es ist den engine Entwicklern, sowie der Hardware überlassen. Demnach wäre das dann völlig legitim.
        Sollte hingegen DX12 Genau und das entsprechende featurelevel Genau dafür gedacht sein es parallel abzuarbeiten, dann wäre die Funktion es einzuschalten ja überflüssig. Im Ergebnis sollte dann eine direkte Vergleichvarkeit nicht gegeben werden. Beispielsweise wenn Maxwell getestet werden soll, sollte der Benchmark die Funktion nicht freigeben, sondern es ausgrauen, als deaktiviert und dies irgendwo beim Ergebnis ersichtlich sein.
        Ansonsten wäre es genau so witzlos als würden wir eine Karte in 1080p und eine andere in 1440p direkt miteinander vergleichen und danach behaupten, erstere ist schneller.
        Eine korrekte Antwort auf die Frage ist komplex zu formulieren.
        Zur Vereinfachung, ja die Aufgaben werden je nach Hardware "parallel" ausgeführt, bei anderer dagegen eher nacheinander.
        Die DX12 Spezifikation schreibt nicht vor wie Multiengine (Async Compute) berechnet werden muss, die Fähigkeiten der Hardware entscheiden darüber, wie es effektiv ausgeführt wird.

        Vielleicht hilft ein CPU-Beispiel.
        Du programmierst eine Anwendung die bis zu 4 Threads ausführen kann, du hast einen Schalter eingebaut der die Verteilung auf mehrere CPU-Kerne erlaubt und einmal der die Verteilung ausmacht und nur immer einen Thread freigibt.
        Wenn du eine CPU hast die nur einen Kern hat, dann wird das so oder so nacheinander ausgeführt, der Schalter die Verteilung auszumachen wird einfach nichts bewirken.
        So ähnlich ist der Fall hier.

        Zitat von openSUSE
        Sorry aber das ist so nicht richtig. Das was Microsoft beschreibt ist was der Engine Entwickler tun kann, also der Engine Entwickler kann die Queues Nutzen wie er will zB: priorisiert oder nicht priorisiert , parallel oder nicht parallel oder aber alles einfach nur in die 3D Queue usw usw
        Aber auf keinen Fall darf der Treiber dies eigenmächtig tun, das wäre ja ein "vollkommenes Desaster" -ups.
        [...]
        Der Entwickler kann natürlich machen was er will, aber er hat am Ende keine direkte Kontrolle über die Ausführung davon.
        Wenn die Hardware die Queues nicht "parallel" ausführen kann, dann kann sie es natürlich nicht und es ist egal ob die Anwendung Multiengine mit 20 Queues verwendet.

        Du hast meinen Text vielleicht so verstanden, dass der Treiber eigenständig die Command-Queues definiert, wobei das theoretisch vermutlich auch möglich wäre.
        Aber aus Sicherheitsgründen bezüglich korrekter Ergebnisse und/oder wegen dem Aufwand würde das vermutlich kein Hersteller machen.
      • Von openSUSE Komplett-PC-Aufrüster(in)
        Zitat von Locuza
        ...
        Man definiert hier welchen Queue-Typen man haben möchte, GFX, Compute oder Copy und fühlt diese dann mit den entsprechenden Befehlslisten auf.
        Ein Synchronisationsmechanismus wird verwendet um im Programmverlauf anzugeben, ab wann die zusätzlichen Queues zum Einsatz kommen und ab wann sie beendet werden.
        Es gibt noch die Möglichkeit die Priorität anzugeben, falls bestimmte Berechnungen und ihre Ergebnisse früher gewünscht sind.

        Das ist auch schon praktisch das ganze Software-Konstrukt, dass einem allerdings keine Garantie darüber gibt, ob die Hardware die Anweisung genau so konsumiert wie man sich das vorstellt, da die Spezifikation in der Hinsicht der Hardware nichts vorschreibt.
        Die Hardware könnte die Queues parallel bearbeiten, sie könnte allerdings auch das ganze nacheinander forcieren, die Hardware kann auf die angegebene Priorität achten, sie kann das aber auch ignorieren.
        Der Knackpunkt ist einfach das dies eine Software-Abstraktion ist, die unter jeder Hardware funktionieren muss, aber keine Vorschriften darüber macht wie genau.
        Als Entwickler muss man sich deswegen bezüglich der Hardware erkundigen und Testläufe unternehmen, ob der Programmcode auch in der Praxis effizient ausgeführt wird.
        ...
        Sorry aber das ist so nicht richtig. Das was Microsoft beschreibt ist was der Engine Entwickler tun kann, also der Engine Entwickler kann die Queues Nutzen wie er will zB: priorisiert oder nicht priorisiert , parallel oder nicht parallel oder aber alles einfach nur in die 3D Queue usw usw
        Aber auf keinen Fall darf der Treiber dies eigenmächtig tun, das wäre ja ein "vollkommenes Desaster" -ups.

        Microsoft adressiert damit den"Konsumenten/Entwickler" der API und nicht die Treiber/HardwareHersteller.

        EDIT
        Zitat von Locuza

        PS: Der 3DMark Time Spy lässt übrigens einige Einstellungen zu, z.B. den Tessellation-Faktor, Mutliengine (Async Compute) ein oder aus, AF-Grad und mehr:
        Not Found - Legit Reviews ...
        Und ist in der Disziplin mit das beste was ich an Optimierung in Sachen Tessellation je gesehen habe, echt Hut ab dafür.
  • Print / Abo
    Apps
    PC Games Hardware 01/2017 PC Games 12/2016 PC Games MMore 01/2016 play³ 01/2017 Games Aktuell 12/2016 buffed 12/2016 XBG Games 11/2016
    PCGH Magazin 01/2017 PC Games 12/2016 PC Games MMORE Computec Kiosk On the Run! Birdies Run
article
1201886
DirectX 12
3DMark Time Spy: Futuremark erklärt die Asynchronous-Compute-Implementierung [Update]
Der Benchmark-Entwickler Futuremark steht nach der Veröffentlichung des Time-Spy-Benchmarks vielerorts in der Kritik. Die Ergebnisse würden in keiner Weise die Performance widerspiegeln, wie man sie in den wenigen bisherigen DirectX-12-Spielen beobachten könne. Vor allem die Asynchronous-Compute-Implementierung sorgt für Diskussionsstoff.
http://www.pcgameshardware.de/DirectX-12-Software-255525/News/3DMark-Time-Spy-Asynchronous-Compute-Kritik-1201886/
20.07.2016
http://www.pcgameshardware.de/screenshots/medium/2016/07/3DMark-Time-Spy-screenshot-4-pcgh_b2teaser_169.jpg
3dmark,futuremark,amd,radeon,directx 12,geforce,nvidia
news