GPUOpen/Commitment für Open-Source

[Achill]

Hallo, ich habe hier im 3dcenter noch keine News oder Thread zu dem Thema gesehen. Dabei scheint es eine sehr interessante und (imho) wichtige Initiative von AMD (auch besonders für AMD selbst) zu sein und könnte als "Antwort" zu NVs GW interpretiert werden.

Kurz: AMD wird voraussichtlich im Jan. 2016 ein ganzes Set an Source-Code, Tools, Beispielen, Bibliotheken, Dokumentation ... für DirectX und Vulkan raus bringen. Es zielt einerseits auf die Unterstützung zur Entwicklung für Spielen und anderseits auf den HPC Markt ab - Plattform-übergreifend und das ganze unter der sehr liberalen MIT Lizenz.

Es gibt viele gute Artikel im Netz dazu:
- http://www.computerbase.de/2015-12/amd-gpuopen-direkte-kontrolle-der-radeon-hardware-fuer-spieleentwickler/
- http://www.tomshardware.com/news/amd-gpuopen-open-source-development,30750.html
- http://www.anandtech.com/show/9853/amd-gpuopen-linux-open-source

Disclaimer: Nachfolgende Meinung ist natürlich hoch spekulativ / subjektiv. Falls es aber gute pro/contra Facts gibt, immer her damit mit vorzugsweise Quelle. Andere Meinungen sind auch gern Willkommen ... ;)

Was mich bei den Artikeln noch stört ist der Fakt, dass dort prim. der PC betrachtet wird und pro/contra Argumente meist aus diese Perspektive erbracht werden.
Das GPUOpen Programm sollte m.M.n. im viel größeren Rahmen und langfristig gesehen werden - und damit auch sein Potenzial / der Angriff auf NV:

1. Die GCN Architektur ist nicht nur im PC sondern auch in allen 3 aktuellen Konsolen aktuell Status Quo. Hier liegt eins der wirklich guten Potenziale das "gut laufende" Effekte/Elemente/Bibliotheken für Multi-Plattform-Spiele zur Anwendungen kommen und Aufgrund der Ausrichtung auch optimal geeignet sind. I.d.R. ist aktuell nicht die Performance auf dem PC kritisch sondern die auf den Konsolen. Shader, Effekte, Libs und Tools, die auf diese Plattformen zugeschnitten sind und wo der Entwickler volle Hoheit über den Quellcode inkl. Anpassung hat, sollten m.M. leicht angenommen werden. Ein leichte Portierung in Richtung PC muss natürlich gegeben sein damit die Sache rund wird, was jetzt durch DX12 und Vulkan sowie GCN gegeben sein sollte.
=> Für AMD könnte dieser Schritt auch entscheidend sein, um bei der nächsten Generation der Konsolen eine gute Position inne zu haben.

2. Mit der Unterstützung von Vulkan durch die zukünftigen Android-Versionen gibt es ein ganzen weiteren Markt inkl. vieler neuer Mitspieler wie Imagination Technologies, ARM, Qualcomm. Selbst wenn AMD hier nicht direkt konkuriert so jedoch NV. Dies könnte zu einer gewisse Bereitschaft zur Unterstützung von GPUOpen bei diesen Marktteilnehmer führen, da man sich sicherlich den Bestreben seitens NV bewusst ist in den Mobile-Markt zu kommen und GW auch hier ein Hebel für NV ist und eine Gefahr für die anderen Markteilnehmer - ähnlich wie AMD - und damit braucht man eine Antwort auf den Software-Part von NV. Darüber hinaus ist die MIT-Lizenz für die Software/Tools/Libs (muss sich noch zeigen wie was lizenziert ist) natürlich viel verträglicher mit Android und Tools die unter Linux laufen / können leicht angepasst werden.

Neben der verstärkten Initiative im Bereicht der Linux Open-Source Treiber ist dies ein weiter Schritt in die richtige Richtung (imho). Das brechen eines proprietären Monopoles (GW, OpenGL-Extensions, Treiber-Optimierungen, GPU-First-Entwicklung) kann nur durch die Substitution selbiger erfolgen und dabei möglichst viele ausgeschlossene Parteien mit ins Boot holen. Open-Source ist sicher ein Mittel der Wahl sowie einer offenen Kommunikation und einer offenen Community (soll ja GitHub werden).
1. Treiber-Optimierungen/OpenGL-Extensions => DX12/Vulkan aka Mantle im neuen Mantel ;)
2. Cuda/GW => HSA, Boltzmann Initiative, GPUOpen
3. GPU-First-Entwicklung => erledigt sich wenn 1. und 2. Erfolgreich sind bzw. bedarf dann größerer 'Spenden'

Ein guter aber wahrscheinlich auch subjektiver Blog-Eintrag in der Richtung:
- http://blog.mecheye.net/2015/12/why-im-excited-for-vulkan/

[Trunk]

So lange das Grafikkarten-BIOS nicht Open Source ist, hält sich AMDs commitment eher in Grenzen.
Was sie grad herausbringen ist Dokumentation und ein paar hilfe-tools.

Ja, immerhin mehr als nVidias Beitrag. Aber deren (nvidias) Treiber ist auch nicht 50% schlechter unter Linux als unter Windows. Und nvidia supported auch ältere Karten auf aktuellen Kerneln. Da ist es mir als Endnutzer herrlich egal ob die Software jetzt freie Quellen hat oder nicht.

Eine öffnung der APIs und Software-Bibliotheken zur Unterstützung der Hardware ist schon lange überfällig. Ich glaube nicht, dass AMD für ein paar Indie-Entwickler einen gepatchten treiber rausbringt, um 5% mehr FPS rauszuholen. Aber die Kunden erwarten natürlich auch vom Independent Dev ein flüssiges Spieleerlebnis.

Immerhin ein Schritt in die richtige Richtung.

[(del)]

Die Linux-Offenherzigkeit von AMD richtet sich aber wohl eher nicht primär an Daddler, dazu ist die Biosphäre viel zu exotisch und die Auswahl an Spielen zu überschaubar. Kohle verdient man im Pro-Bereich und Workstations und nicht in der Gaming-Nische unter Linux & Co. :)

AMD pusht aktuell mit der FirPro W4300 gehörig die Gruppe der Entry-Level- und Midrange-Workstation-Karten. Da kämen etwas mehr Aufgeschlossenheit + Performance gerade recht.

[iuno]

selbstverstaendlich, man muss aber auch mal ehrlich bleiben. die chancen dass gaming auf linux marktreif wird, sind so "gross" wie noch nie. nur dass das halt nicht in 1-2 jahren geht muss auch klar sein.
viel offenheit und "funktionierende" treiber wuerden daher auch spielern sehr helfen.
letztendlich ist diese veroeffentlichung aber auch nur ein teil des engagements. das gehoert alles zu einer langfristigen strategie, die letzten endes hoffentlich aufgeht. vielleicht sieht die allgemeine linux-situation ja schon mit arctic deutlich besser aus..

[-/\-CruNcher-/\-]

Naja die größe des AMD entwickelten stacks ist bei weitem nicht so Umfangreich wie bei Nvidia momentan wird ja meistens nur PostWorks + Shadowworks eingesetzt :)

Was das gegenstück zu dem angekündigten


When AMD launches GPUOpen this coming January, it plans to provide access to TressFX 3.0, GeometryFX, AOFX, ShadowFX, a handful of tools, the LiquidVR SDK, DirectX 11 and 12 code samples,

ist

Aber bei Nvidia ist da ja noch der ganze Physx part + zusätze die darauf aufbauen z.b Flameworks.

Allerdings machen eben diese Postworks sachen viel vom Overhead aus allen voran TXAA vor allem auch die Teile die nicht weiter für alte Hardware optimiert sind wie eben GeometryWorks (was man bei Unity dann gecancelt hat man kann es aber scheinbar doch aktivieren) nach dem dann PCCS (ShadowWorks) ist z.b eine sache die Haut meistens recht ordentlich rein für den minimalen visuellen Gewinn momentan was teils auch nicht als solcher wirklich wahrgenommen wird.

HBAO+ ist wiederum so eine sache da kann man sagen der Overhead ist momentan gerechtfertigt für den Gewinn. Der ganze overhead potentiert sich dann immer weiter mit GiWorks und HairWorks + FaceWorks pro frame ;)


So unwichtig sind die sachen da nicht schon alleine die Entlastung bei AO durch die ACEs pro frame durch die async runtime kann entscheidend sein zwischen flüssig und nicht flüssig :)

[samm]

Gute Initiative. Jetzt muss sie nach der Ankündigung nur noch richtig starten ;)

Wird der Softwarewelt definitiv gut tun, und regt zu Fantastereien an was diverse Wrapper & co. angeht - nie wieder Wine? Einfachere Nutzung von GPGPU in "normalen" Programmiersprachen? Ablösung von proprietärem CUDA-Code? Wird es Gameworks noch weiter obsolet machen, wenn jeder direkt die Effektbibliotheken einbinden und frei anpassen kann ohne Herstellerbindung?

[Achill]

@Format_C - ja, denke auch das unter Linux stärker die prof. Benutzer im Fokus stehen. Da der Vulkan-Treiber aber auch OS werden soll (noch nicht ganz bzw. zu wann entschieden) könnte es langfristig aber auch eine Vorbereitung für SteamOS sein?

@Trunk, die freien AMD Treiber sind ja für den Standard-User ausreichend (imho). Es funktioniert Power-Management, Standby und Hibernation sowie OpenGL bis v4.0 (je nach GPU-Generation) out of the Box, und - wie bei den Intel-Treibern - darf man nur nicht das aller neuste unter Linux einsetzen wollen. Sofern man auf eine stabile Distribution setzt, die entsprechende AMD/Intel Hardware direkt unterstützt, geht dies auch wirklich sehr zuverlässig. Eine stabile Distribution ist natürlich für Jeden etwas unterschiedlich definiert.
Sobald man jedoch portierte Windows Spiele unter Linux spielen möchte (mit OpenGL +4.2) braucht man jedoch die prop. Treiber von AMD/NV und hier hat NV die Nase bzgl. Performance vorn - weil sie schon eine ganze Zeit lang OpenGL getrieben haben (Extensions) und m.W. für OpenGL auch schon lange ein Unify-Treiber-Ansatz anwenden. Bei ATI war es m.W. so, dass am Anfang ein externe Firma den Linux-Treiber geschrieben hat..... In wie weit dies später geändert wurde, wieviel org. Quellcode übernommen wurde, wie weit der Windows- und Linux-Treiber jetzt zusammen geführt wurden, da habe ich keine Ahnung aber ich gehe doch von einer viel größeren Differenz als bei NV aus. NV hat OpenGL über Jahre gepushed, ob überhaupt AMD das aufholen kann bzw. wie lange es Dauern würde - k.a. - aber AMD wird das Aussitzen und dort Abseits von den OpenSource-Treibern oder von Optimierung für prof. Software nichts mehr machen.

@-/\-CruNcher-/\-, PhysX lässt sich natürlich nicht 1:1 austauschen - besonders im Verbund mit anderen GW-Modulen - eine Alternative (k.a. ob gut/schlecht) ist m.W. die Bullet-Physik-Engine (https://de.wikipedia.org/wiki/Bullet-Physik) und wird in Spielen, für Filme, Prof.Software, Game-Engines, Benchmarks (z.B. 3dmark11) eingesetzt und natürlich von der NASA :D ... Mit der Version 3.0 (noch in Entwicklung) passiert gerade auch eine komplette Integration einer OpenCL Pipline.
=> AMD müsste hier nicht liefern sondern nur Intigrieren und Synergien erzeugen hinsichtlich GPUOpen, spricht 1-2 Entwickler Vollzeit abstellen und Interagtion für die 3 wichtigen Game-Engines schaffen (CryEngine, Unity, UE) - dass würde m.M.n. viel bringen.
Bzgl. den Effekten gebe ich dir recht, es gibt einiges was viel Leistung kostet aber Visuell nicht im gleichen Verhältnis steht. Als Beispiel zeigt Star Citizen (egal wie man zu dem Spiel/Founding steht) recht eindrucksvoll, dass auch High-Poly ein sehr interessanter Weg ist.

@samm, ja - die Erzeugung der nötigen Traktion ist bei einen OS-Projekt oft keine leichte Aufgabe, es ist ja nicht so, dass man als Entwickler sich langweilt ... ;D
AMD muss m.M. Partner mit ins Boot holen und gleichzeitig irgendwie ein Anreiz für Geeks bieten, damit diese Early-Adopter werden und ihrerseits über soziale Mechanismen werben - läuft heute ja bei allen so. Etwas wie ein Google Summer-of-Code inkl. Community-Aufbau - mit einen sinnvollen Einsatz von Mitteln und transparenter Vor- und eigentlicher Wahl kann man ggf. Motivation schaffen das Leute sich beteidigen. Challenges sind auch ein gutes Mittel. Und und und ... die Frage ist, kann/will AMD das Leisten.

[iuno]

GPUOpen ist nicht mit Gameworks zu vergleichen

btw. es wuerde auch langsam mal Zeit werden, Januar ist bald durch ;) Naechste Woche gibt's was neues, wenn sie sich nicht verspaeten.

[Troyan]

Ist online: http://gpuopen.com/

Vielleicht kann jemand die TressFX 3.0 Version compilieren und zur Verfügung stellen. Wäre klasse.

[fondness]

Ein bisschen Info: It’s Time to Open up the GPU
http://gpuopen.com/radeon-compute-the-open-path-forward/
http://gpuopen.com/welcometogpuopen/

HIP ist auch schon dabei, also der CUDA-Converter aus der Boltzmann Initiative:
http://gpuopen.com/compute-product/hip-convert-cuda-to-portable-c-code/
http://gpuopen.com/hip-to-be-squared-an-introductory-hip-tutorial/

[iuno]

Ist mir zu viel alles nochmal hochzuladen. klone das Projekt und kopier dann die binaries rein:
TressFX.zip (http://www.file-upload.net/download-11250988/TressFX.zip.html)

Optisch so "roh" nicht besonders eindrucksvoll, aber man bekommt mal einen Ueberblick ueber die Parameter fuer Rendering/Simulation und deren Auswirkungen.

[fondness]

Vielleicht kann jemand die TressFX 3.0 Version compilieren und zur Verfügung stellen. Wäre klasse.

Ich nehme an dich interessiert der Viewer? Kompiliert mit VS 2015, x64 release Build:
https://www.dropbox.com/s/ldwc4rvdud9bg3h/TressFX-master.zip?dl=0

[Troyan]

Ja, danke. :up:

[iuno]

Mich wundert etwas, dass sie mit LiquidVR noch so in DX11 investiert haben. "Async compute" und der multi-GPU Modus...

[fondness]

Mich wundert etwas, dass sie mit LiquidVR noch so in DX11 investiert haben. "Async compute" und der multi-GPU Modus...

DX12 gibt es eben erst wenige Monate.

[aufkrawall]

Wow, AMD hat diesmal nicht zu viel versprochen. Nice!

[Troyan]

Nach den ganzen Talks wieviel effizienter TressFX 3.0 gegenüber 2.x wäre, frage ich mich, wo genau man besser wäre.
Meine GTX980TI läuft beim Öffnen des Viewers mit 1500Mhz, 99% Auslastung und hat einen Stromverbrauch von 66%. Der Speicherverbrauch ist auch weiterhin so abartig hoch - 1,8GB...
Renderzeit bei 240k Haaren mit je 8 Eckpunkte ist 2,5ms für die Haare.
TressFX 2.2 verhält sich genau gleich...

Nur mal zum Vergleich zum Hairworks-Viewer 1.1.1 (aktuellste Version):
Meine GTX980TI läuft beim Öffnen des Viewers mit 1100Mhz, 25% Auslastung und hat einen Stromverbrauch von 52%. Der Speicherverbrauch liegt bei 900MB.
Renderzeit bei 240k Haaren mit je 10 Eckpunkte ist 2,3ms für die Haare.

[aufkrawall]

Ich hab die Runtimes installiert. Hat jemand eine Idee, warum der Viewer trotzdem nicht starten möchte?

[Kartenlehrling]

Verfügbar: 28. Januar

Dieses Spiel wird in ungefähr 1 Tag und 21 Stunden freigeschaltet


Bald wissen wir es genau.

[-/\-CruNcher-/\-]

Hehe was sofort auffällt das Website Design in einer Linie mit dem Crimson UI ;)

AMDs NVAPI Counterpart :)

http://gpuopen.com/gaming-product/amd-gpu-services-ags-library/

[iuno]

Ich hab die Runtimes installiert. Hat jemand eine Idee, warum der Viewer trotzdem nicht starten möchte?
Welche runtimes meinst du?
Was passiert denn?

Hehe was sofort auffällt das Website Design in einer Linie mit dem Crimson UI
Ja, das ist ein nettes Detail

[Locuza]

Welche runtimes meinst du?
Was passiert denn?
Die VC 2015 runtime.
Vermutlich passiert einfach nichts.


Ja, das ist ein nettes Detail
Es sieht schick aus, bedienen tut es sich aber schrecklich.

[aufkrawall]

Die VC 2015 runtime.
Vermutlich passiert einfach nichts.

Ja, genau. :redface:

[iuno]

Es sieht schick aus, bedienen tut es sich aber schrecklich.
Ich habe nicht das neue Design allgemein gelobt, sondern die Konsistenz.
Davon ab finde ich es nicht so schlimm. Waere die Transparenz nicht so uebertrieben, waere es naturlich besser. Und es ist halt nur was fuer Mausschubser.
Ja, genau. :redface:
KA, kannst es ja mal mit meinen binaries versuchen, ich hab mit vs2013 gebaut.

[aufkrawall]

Geht auch nicht. Muss man etwa nicht nur das Runtime, sondern aus irgendeinem Grund auch VS selbst installiert haben?

[iuno]

Ich kann es mir nicht vorstellen, ergibt auch keinen Sinn.
Ist halt auch bloed wenn gar keine Meldung kommt :rolleyes: Waere aber interessant zu wissen, kommst du an eine vs Lizenz 12-15 ran?

[aufkrawall]

Leider nicht. Na ja, sei es drum.

[-/\-CruNcher-/\-]

AMDs Viewer crashed hier sofort innerhalb der Kernelbase :D

[iuno]

AMDs Viewer crashed hier sofort innerhalb der Kernelbase :D

Aha :ugly:

Habe mal geschaut wer schon darüber berichtet hat und etwas amüsantes gefunden: AMD hat - wie schon im Dezember angekündigt - den Quellcode der Radeon-Grafiktreiber veröffentlicht (gequellöffnet?) und ruft nun alle ProgrammiererInnen dazu auf, ihren Code besser an Radeon-Grafikkarten anzupassen
http://de.engadget.com/2016/01/27/amd-offnet-grafiktreiber

[Screemer]

ach du meine fresse. engadget wird immer besser :D

€dit: hab mir das kompilat von fondness gezogen und die vs c++ runtime installiert und der viewer startet auch nicht.

€dit: auch die von iuno mit vs2013 kompilierten binaries laufen nicht.

[Unicous]

Es gibt bereits ein Projekt, dass CUDA in OpenCL umgewandelt hat.

http://finance.yahoo.com/news/amd-gpuopen-fuels-seismic-supercomputing-140000049.html

AMD today announced that CGG, a pioneering global geophysical services and equipment company, has deployed AMD FirePro™ S9150 server GPUs to accelerate its geoscience oil and gas research efforts, harnessing more than 1 PetaFLOPS of GPU processing power. Employing AMD's HPC GPU Computing software tools available on GPUOpen.com, CGG rapidly converted its in-house Nvidia CUDA code to OpenCL™ for seismic data processing running on an AMD FirePro™ S9150 GPU production cluster, enabling fast, cost-effective GPU-powered research.

[M4xw0lf]

Es gibt bereits ein Projekt, dass CUDA in OpenCL umgewandelt hat.

http://finance.yahoo.com/news/amd-gpuopen-fuels-seismic-supercomputing-140000049.html
Not bad.

[deekey777]

Sie haben ihren Cuda-Code mit Hilfe der GPUOpen-Initiative "rapidly" in OpenCL-Code umgewandelt. Und?

Was hat das gebracht? Sie können jetzt AMD-GPUs einsetzen (ist ja logisch), vielleicht konnten sie so günstiger von Teslas auf FirePros umsteigen.

Interessanter ist doch, wie viel sie an FLOPs dadurch gewonnen haben. Oder noch besser: Wie gut oder schlecht wäre das Ergebnis, wenn sie den OpenCL-Code auf Teslas ausführen würden?

[Achill]

Sie haben ihren Cuda-Code mit Hilfe der GPUOpen-Initiative "rapidly" in OpenCL-Code umgewandelt. Und?


Zwischen dem Versprechen, dass ein (Open-Source) Tool etwas liefert und dem praktisch Test an einen nicht trivialen Problem können ohne weiteres Welten liegen.


Was hat das gebracht? Sie können jetzt AMD-GPUs einsetzen (ist ja logisch), vielleicht konnten sie so günstiger von Teslas auf FirePros umsteigen.


Wie wäre es mit:
- Kein Vendor-Lock
- Wahlmöglichkeit (und besser Ausschreibbar) bei Anbietern
- Zugriff auf math. OpenCL Bibliotheken (von AMD)
- Effizienter hinsichtlich MFLOPS/W


Interessanter ist doch, wie viel sie an FLOPs dadurch gewonnen haben. Oder noch besser: Wie gut oder schlecht wäre das Ergebnis, wenn sie den OpenCL-Code auf Teslas ausführen würden?


Mir ist nicht bekannt, dass OpenCL schneller ist als CUDA auf NV-HW. Meine erste naive Argumentation wäre die Analogy Richtung Mantle, CUDA is im Vergleich zu OpenCL für NV was Mantle ist/war für AMD - eine API die NV optimal an die eigene HW anpassen kann ohne Rücksicht auf einen gemeinsamen Nenner von mehreren IHVs nehmen zu müssen.

[iuno]

Die beiden folgenden Punkte wurden ja auch genannt:
- Effizienz (FLOPS/Watt)
- mehr Speicher bei FirePROs

NV Hardware war mit OpenCL eher langsamer als mit CUDA. Ich glaube aber nicht, dass es ganz aktuelle Infos dazu gibt. Wenn man Compute mit NV macht, macht man es eh in CUDA.

[Unicous]

Digital Extremes nutzt bei Warframe bereits Tootle, den Mesh Optimizer von AMD.

https://twitter.com/sj_sinclair/status/703070366558789632

[-/\-CruNcher-/\-]

Gpu Open ist nicht das einzigste interessnnte AMD baut auch kontinuierlich ihre eigenen tools weiter aus nicht nur Tootle es gab auch enorme Verbesserungen bei altbekantem :)

Z.b beim Compressonator der supportet nun unter anderem endlich BC7 und ASTC und inkludiert sogar einen Metric Viewer + SSIM Analyse :)

Ein Rename wurde auch spendiert da man nun alles unter einem namen vereint hat für GCN "AMD Compress" :)

http://developer.amd.com/community/blog/2016/03/03/amd-compress-2-2-delivers/

Es gibt noch keine Compares zwischen AMD Compress, Intel Texture Works und Nvidias Texture Tools aber die kommen sicherlich noch ;)

[samm]

Auch wenn es so klingt, als würde es die Nutzung von Cuda zementieren in dem Zusammenhang und zumindest laut dieser Quelle ohne AMD's Input entstanden ist:
OctaneRenderer CUDA auf AMD, Intel, ....
http://venturebeat.com/2016/03/09/otoy-breakthrough-lets-game-developers-run-the-best-graphics-software-across-platforms/

[iuno]

reverse-engineering? Was macht das jetzt genau? run-time compilation von CUDA in OpenCL-byte-code? Geht fuer mich aus dem Artikel nicht hervor.
Natuerlich waere es besser, man wuerde gleich in OpenCL bauen.
Nvidia’s CUDA language is superior and enables much richer graphics software
aha

[d2kx]

AMD GPUOpen @ GDC 2016

http://i.imgur.com/xXeP3id.gif

Ich denke, im Laufe der kommenden Woche wird es deutlicher als jemals zuvor, warum wir alle profitieren, wenn wissenschaftliche Anwendungen und Spiele gleichermaßen auf _wirklich_ offenen Code setzen und warum proprietäre BlobWerke ein Irrweg sind.

Und warum Vulkan & DX12 nicht die einzigen spannenden Entwicklungen darstellen.

[iuno]

OT? Sprichst du vom stream executor oder kommt da nochmal was von AMD?
dreister teaser :ugly:

[fondness]

H0yrzjEReX8

Y0oBFeFUG4w

[fondness]

Optimizing the Graphics Pipeline with Compute
http://www.frostbite.com/2016/03/optimizing-the-graphics-pipeline-with-compute/

GDC Präsentation von DICE

[iuno]

oberes Video (mit DICE) bei 01:03:
I'm especially looking forward to the HLSL extensions, because they allow us to use a more console-like access to the hardware.
Was meint der damit und warum?

[fondness]

GPUOpen soll für Spieleentwickler mehrere Vorteile bringen – das wird unter der offiziellen Bezeichnung „GPUOpen Gaming“ laufen. So möchte AMD diesen die Möglichkeit geben, Radeon-Grafikkarten eher wie eine aktuelle Konsole (Xbox One und PlayStation 4) programmieren zu können. AMD wird entsprechende Tools zum Download bereitstellen, die Low-Level-Zugriff auf die Graphics-Core-Next-Architektur geben – deutlich mehr als DirectX 12 und Vulkan ermöglichen. Der Hersteller spricht von „Direct Access“ zur GPU. Als Beispiel hat Nicolas Thibieroz, Senior Manager für ISV-Engineering bei AMD, Asynchronous Shaders genannt. Das Feature kann mit Hilfe von DirectX 12 und Vulkan zwar genutzt werden, erlaubt dem Entwickler aber nur einen geringen Einfluss auf die dafür bei AMD-Grafikkarten wichtigen ACE-Einheiten. Durch das entsprechende GPUOpen-Tool soll der Entwickler dagegen vollen Zugriff auf die Einheiten haben und dann die optimale Performance aus den Radeon-Grafikkarten herausholen können.

http://www.computerbase.de/2015-12/amd-gpuopen-direkte-kontrolle-der-radeon-hardware-fuer-spieleentwickler/

[iuno]

Und was soll HLSL mit low level zu tun haben? Verstehe ich nicht.
Mal davon abgesehen: warum soll man die command processors selbst programmieren wollen? Ich glaube auch irgendwie gerade nicht dran, dass das bei Konsolen Usus ist. Warum soll die Engine da auch mehr machen koennen als die pipes zu fuellen? das ueberkompliziert das ganze dann doch imho. Und vor allem geht hier natuerlich ganz ins negative Extrem was Portabilitaet angeht. :rolleyes: Da hilft auch nicht, dass die Tools open source sind. Sollten die grossen Studios wirklich auf dieses Niveau runter gehen, waere das echt Uebel

[Gipsel]

oberes Video (mit DICE) bei 01:03:

Was meint der damit und warum?Ergänzend zu dem Zitat von fondness:
Wenn man sich die oben verlinkte GDC-Präsentation von dem DICE-Menschen ansieht, benutzt er auch im Shadercode selber einige Funktionen, die nicht so ganz Standard sind (Lane-Swizzling, Ballot und solchen Kram), aber ganz offensichtlich z.B. auf der XBox über Intrinsics nutzbar sind (Kommentar in den Slides: "You could do a parallel reduction in LDS like all the cool kids do, or you could be even more awesome and do it with lane swizzling.").
Also vielleicht will er ja auch (herstellerspezifische) Intrinsics für HLSL, um die Möglichkeiten der Hardware direkter ausnutzen zu können. Denn wie auch er in seiner Zusammenfassung sagt, GCN hat von den Aspekten der µArchitektur/ISA eigentlich ein ziemlich gutes Design, was man dann natürlich auch mal vernünftig nutzen will.
Asynchronous compute is extremely powerful - be sure to schedule compute wavefronts alongside the rest of your frame, but don’t forget that you can overlap compute and graphics work on the same pipe, many developers do not realize this.
Remember that there are lots of cool GCN intrinsics available to optimize with. Grab a coffee, sit on a comfortable couch with your laptop, and read through the entire GCN instruction set documentation. You’ll find all sorts of crazy things you can exploit.
Das erinnert mich daran, wie beeindruckt ich mich schon vor Jahren von der GCN-ISA gezeigt habe.

[Schnoesel]

Also ich versteh davon ja echt nicht viel, nur das GCN wohl ein Haufen Potential bietet und AMD will das nutzbar machen, so weit so gut. Das einzige "Problem" das ich wie immer bei AMD sehe ist dass es auch genutzt werden sollte, sonst ist das alles ganz toll aber beim Nutzer kommt nix an. Gut dass sie wenigsten Dice mit an Bord haben aber ich hoffe doch inständig dass auch andere aufspringen und es dann mehr als nur Lippenbekenntnisse sind.

Hätte AMD mehr Marktanteil wäre der Druck dahinter wesentlich größer. Ohne Konsole wären sie bereits auf verlorenen Posten. Ich bin gespannt wie sich das Ganze entwickelt.

PS: Jetzt habe ich wieder Bock Dragon Age zu zocken :biggrin:

[Gipsel]

oberes Video (mit DICE) bei 01:03:

Was meint der damit und warum?
Sieht so aus, als hätte MS jetzt SM6 angekündigt, mit dem auch die oben erwähnten Instruktionen kommen sollen.
http://abload.de/img/0079dsn3.jpg
http://abload.de/img/009nls4y.jpg
Quelle (http://www.4gamer.net/games/033/G003329/20160317117/screenshot.html?num=007) von Kartenlehrling aus dem DX12-Thread gemopst.

[Achill]

Interessant finde ich dem dem Zusammenhand, das CLang/LLVM durch Teile des MS-DX-Stacks verwendet werden. Für mich eine neue Info, ggf. ist das aber auch nur bei DX12 an mir bisher vorbei gegangen.

http://i.imgur.com/EurtjkJ.jpg

http://i.imgur.com/gIhZ77C.jpg

http://i.imgur.com/gIhZ77C.jpg
Wenn LLVM verwendet wird, um eine IR (Intermediate Representation) der Shader zu erzeugen, welche in einem zweiten Schritt (zur Laufzeit?) auf die Zielarchitektur via Profile optimiert wird, so müsste der Code/das Profil/das Wissen bei Gallium3D / OpenCL im offenen Treiberstack wiederverwendbar sein oder?

[iuno]

Naja moeglicherweise schon, aber warum sollte man dort nicht gleich SPIR-V erzeugen statt DXIL?

[Achill]

Naja moeglicherweise schon, aber warum sollte man dort nicht gleich SPIR-V erzeugen statt DXIL?

Darum ging es mir gar nicht, sondern das die Profile/Logik/Erfahrung im letzen Schritt (IR -> OpCode / Nativer Code) gleich ist. Zwar unterscheiden sich die Compute/Shader-Sprachen immer etwas, der AST wird also immer etwas anders aussehen und auch die IR ist spezifisch, da aber alle Sprachen & IRs die gleiche Problem-Domäne beachern sollte es doch eine sehr hohe Ähnlichkeit geben.

Wie nennt man eigentlich das fertige Kompilat es Shaders für eine GPU (in der Endstufe)?

[iuno]

Weiss nicht, bei OpenCL wuerde man es Kernel nennen, das bezeichnet aber mehr das Programm und trifft auch auf die Fassung im Quellcode zu...

Ja, dass das Vorgehen angepasst wird, ist sicherlich nicht schlecht. Allerdings laueft es wohl eher anders herum, SPIR-V gibt es schon laenger und der Vulkan Stack muss das ja schon so machen. Kann natuerlich sein, dass wiederum know-how zurueckfliesst, aber viel erwarte ich mir da nicht

[Locuza]

http://32ipi028l5q82yhj72224m8j.wpengine.netdna-cdn.com/wp-content/uploads/2016/03/Unlocking_Game_Dev_with_OpenSource_GDC16.pdf

Ab Seite 46 wird es interessant, Shader-Erweiterungen von denen wenigstens DICE Gebrauch machen wird.

[fondness]

Wer es noch nicht gesehen hat, alle AMD Präsentationen der GDC auf GPUOpen:
http://gpuopen.com/gdc16-wrapup-presentations/

[Achill]

http://32ipi028l5q82yhj72224m8j.wpengine.netdna-cdn.com/wp-content/uploads/2016/03/Unlocking_Game_Dev_with_OpenSource_GDC16.pdf

Ab Seite 46 wird es interessant, Shader-Erweiterungen von denen wenigstens DICE Gebrauch machen wird.

Ich fand alle Folien sehr interessant und freue mich wenn dies bei GPUOpen verfügbar wird. Hoffe AMD hat/plant ein paar freie Ressourcen zur Betreuung der OpenSource Community abgestellt/abzustellen. Pull-Requests reviewen und dann mergen, auf Frage/Issues bei GitHub antworten, ...

Interessant ist m.E. auch GeometryFX, dass klingt sehr nach / ähnlich zu Optimizing the Graphics Pipeline with Compute (GDC 2016, DICE, Graham Wihlidal) (http://www.wihlidal.ca/Presentations/GDC_2016_Compute.pdf) was ich schon im DX12 Thread geschrieben habe.

[iuno]

https://avatars2.githubusercontent.com/u/16900649?v=3&s=400

ROC auf Github: https://github.com/RadeonOpenCompute

[iuno]

Nachdem letzte woche der compressonator (http://gpuopen.com/gaming-product/compressonator/) veroeffentlicht wurde, folgt jetzt FireRays 2.0 (http://gpuopen.com/firerays-2-0-open-sourcing-and-customizing-ray-tracing/).

Der primaere Einsatzzweck ist hier natuerlich nicht gaming, aber wer weiss, moeglicherweise findet eine Abwandlung davon doch mal den Weg in eine Engine, etwa wenn es darum geht, lightmaps zu erstellen, mit async compute? :ulol:

[Locuza]

GeometryFX hat ein Update auf 1.2 erhalten mit Cluster Culling:
http://gpuopen.com/geometryfx-1-2-cluster-culling/

Es war teilweise eine Inspirationsquelle für das Compute Triangle Culling was DICE präsentiert hat:
The final advancement, was when I met Matthäus Chajdas at AMD Munich, whom was also experimenting with compute triangle culling, now titled GeometryFX [20], and released open source as part of AMD GPUOpen. This sparked a great collaboration to push this technology further.
http://www.wihlidal.ca/Presentations/GDC_2016_Compute.pdf

Persönliches Highlight vom Update:
Besides the cluster culling, this update also incorporates a pull request from Intel which improves the handling of primitives culling the near plane. That’s it for today!

[iuno]

nice, genau so soll es doch sein :up:

[-/\-CruNcher-/\-]

Jede Firma sollte mal kurz zu boden gehen allerdings kann man sich ja auch fragen ob das überhaupt nötig war oder nur das jemand wie SU das Steuer übernimmt schon ausreichend *g*

[d2kx]

We are releasing TressFX 3.1. Our biggest update in this release is a new order-independent transparency (OIT) option we call “ShortCut”. We’ve also addressed some of the issues brought up by the community.

TressFX 3.1 (http://gpuopen.com/tressfx-3-1/)
AMD GPUOpen

[-/\-CruNcher-/\-]

Bin mal echt gespannt ob es mittlerweile ausführen wird und nicht sich schon vorher mit einem crash in der KERNELBASE.dll verabschiedet ;)

Gut von der KERNELBASE.dll jetzt in die MSVCR110.dll gerutscht aber immerhin ;)

oha beim 2nd execute gehts jetzt na ob da nicht Nvidias Shader Compiler einen kleinen hickup hatte ;)

Nice es geht endlich ich seh den Teddy (Tomb Raider Asset ?) :D


Ui das ganze Maximizen während im Hintergrund Firefox und Fallout 4 + Creation Engine Editor lief war keine gute idee scheinbar ;)

Crash in

d3d11.dll

Auch beim 2nd execute crash beim Maximizen das mal genauer anschauen ob es tatsächlich Load bedingt ist ;)

Wenigstens seh ich jetzt Finaly überhaupt was der Kernelbase.dll crash is also erstmal History :D

Schionmal stabiler geworden der Viewer unter Nvidia Config :)

Bedenkt man den gerade insgesamten System Load garnicht schlecht die perceptible latency für das was man sieht, wobei dieser verteilte Blur schon etwas komisch erscheint :)

http://i1.sendpic.org/t/xi/ximsaUGrfwSBsmc8un7LDV9mmqt.jpg (http://sendpic.org/view/1/i/kQoj4ZhranEs73BP02JKCLG0bek.png)

Das neue Maximize Crash verhalten werd ich mal Nvidia Treiber Technisch unter Beobachtung halten ;)

http://i1.sendpic.org/t/ni/niuvYoH00vPo316ifI72ZNB7MpV.jpg (http://sendpic.org/view/1/i/A51bYKqLQvCWE3cM7vqnSiTTUFg.png)

[Troyan]

GeometryFX hat ein Update auf 1.2 erhalten mit Cluster Culling:
http://gpuopen.com/geometryfx-1-2-cluster-culling/

Es war teilweise eine Inspirationsquelle für das Compute Triangle Culling was DICE präsentiert hat:

http://www.wihlidal.ca/Presentations/GDC_2016_Compute.pdf

Persönliches Highlight vom Update:

Weil mir langweilig war:
Geometry FX Off: 450 FPS
Geometry FX On: 315 FPS

Mit "-generate-geometry:true" brechen die Frames dann von 200 auf 20 ein.

Soviel zu "GPUOpen". :freak:

[Menace]

Soviel zu "GPUOpen". :freak:

Gott sei Dank hast Du das repräsentativ gegen getestet und das Ergebnis auch für die Zukunft extrapoliert. Somit können jetzt viele Ressourcen für sinnvollere Projekte (Gameswork?) gespart werden. Soviel zu "Troyan". :wink:

Im Ernst: Was benötigt man, um das selber am Rechner zu testen?

[-/\-CruNcher-/\-]

@Troyan :facepalm:

Neues Spielzeug ;)

https://github.com/GPUOpen-LibrariesAndSDKs/VkMBCNT/

[d2kx]

A major step toward enabling high-quality video streaming and recording, Advanced Media Framework (AMF) 1.3 is now open sourced, providing the structure for high quality video recording and live streaming. AMF 1.3 SDK will enable developers of Radeon™ graphics cards to create GPU-based game capture programs for high-quality multimedia streams on their favorite sites.

High-quality Advanced Media Framework streaming and recording API now open-sourced (https://community.amd.com/community/gaming/blog/2016/08/16/high-quality-advanced-media-framework-streaming-and-recording-api-now-open-sourced)
AMD.com

Advanced Media Framework (http://gpuopen.com/gaming-product/advanced-media-framework/)
GPUOpen.com

[deekey777]

Für Leute wie mich: http://www.golem.de/news/adavanced-media-framework-amd-legt-media-sdk-offen-1608-122781.html

Aber bringt das AMD überhaupt weiter? Sie konzentrieren sich anscheinend nur auf Livestreaming, aber vernünftige Software, die VCE nutzt, gibt es kaum. Und wenn doch, dann macht selbst kostenpflichtige Probleme.

[Kartenlehrling]

Da habe ich mich 5 Jahre mit rumgeschlagen,
ich bin froh das Intels Quicksync ein wirklich gutes Ergebniss abliefert.

[Achill]

Es gibt ein paar interessante Infos zu AMD TrueAudio Next and CU Reservation (http://gpuopen.com/amd-trueaudio-next-and-cu-reservation/) (2016-09-26).

Wusste nicht das TrueAudio Next eine OpenCL™ audio math library, die direkt auf den CUs der GPU ausgeführt wird und hier eine Reservierung von CUs möglich ist. Das ist im Vergleich zur Priorisierung von Task bei async. Ausführung nochmal eine ganz andere Interessant Sache, da es Real-Time-Systeme ermöglicht.

Die Andeutungen in Richtung von VR und Head Tracking mit HMDs, die auch in die Klasse "critical real-time" fallen, sprechen für diese Interpretation.

Damit ist die Fähigkeit von Async. Comp. der GCN Architektur nochmal in ein ganz anderes Licht gerückt (für mich) und ein ganz anderes Anwendungsgebiet erschlossen.

Ich frage mich, ob/warum das AMD im Automotiv-Bereich besser vermarkten (kann) - parallele Verarbeitung mit garantierter Verfügbarkeit ist Basis für jedes Echtzeitsystem.

[Skysnake]

Den Memory kannste dann aber noch immer nicht sicher ansprechen. Oder?

[Achill]

Den Memory kannste dann aber noch immer nicht sicher ansprechen. Oder?

Sicher hinsichtlich garantierter Bandbreite / Latenz / Menge oder Isolation? Ich kann zu all den Punkten nur spekulieren, darüber wird im Artikel nichts gesagt.

Menge & Isolation geht sicher über Treiber, Bandbreite & Latenz wird die Architektur vorgeben, wird evtl. nicht änderbar sein.

[Skysnake]

Ich meine Latenz und Bandbreite. Die können ja nicht fix sein, weil es eine geteilte Resource ist. Da kommts darauf an, was ansonsten auf der KArte/system so abgeht.

[iuno]

Das Bild ist von einer kleinen Präsentation über ROCm, noch nicht allzu alt. Interessant ist die Bestätigung, dass OpenCL künftig auch über den ROC Stack laufen soll, offenbar gibt es eine erste Demo im November. Vermutlich wies das auf der SC passieren, dazu gab es ja schon Gerüchte. Interessant auch, dass in diesem Zusammenhang FPGAs genannt werden. https://www.youtube.com/watch?v=LUAu4eywK5g

https://i.imgur.com/doD2VOy.jpg

Hat sich hier davon abgesehen eigentlich schon mal die rocm angeschaut?

[iuno]

Kleine Erinnerung: Kommende Woche findet in Salt Lake City die SC 2016 statt. AMD spricht dort ueber ROCm. Zudem gab es Geruechte, AMD wolle da irgendwas zu Vega zeigen, auch das mit dem FPGA wuerde zeitlich passen. Keine Ahnung ob was dran ist, aber vielleicht interessiert sich so oder so jemand dafuer
http://sc16.supercomputing.org/presentation/?id=exforum117&sess=sess240
http://sc16.supercomputing.org/presentation/?id=emt117&sess=sess246

[Skysnake]

Aus Amiland gibt es wohl ziemlich sicher war großes zu sehen ;)

[deekey777]

AMD @ SC16: Radeon Open Compute Platform (ROCm) 1.3 Released, Boltzmann Comes to Fruition (http://www.anandtech.com/show/10831/amd-sc16-rocm-13-released-boltzmann-realized)

Zuvieltextichnixlesen

[iuno]

ROCm gibt es jetzt ausserdem fuer Cavium ThunderX (ARM) und Power 8. Desweiteren gibt es OpenCL (war ja schon bekannt), Unterstuetzung fuer Virtualisierung (passthrough sowie docker) und wohl etwas mehr "gehippte" Software

Hier die Pressemitteilung: http://www.amd.com/en-us/press-releases/Pages/rocm-platform-2016nov14.aspx

[Skysnake]

Noch immer kein C und vor allem auch kein FORTRAN dabei. So lange das so ist, sehe ich da im HPC keinen durchschlagenden Erfolg. Es gibt insbesondere von FORTRAN Unmengen an altem Code und es wird auch noch mehr als genug neuer Code generiert.

[iuno]

Und du meinst bei den Kunden, die daran festhalten, ist ein Wechsel auf AMD wahrscheinlich?
Immerhin bekommen sie ja jetzt mal eine ordentliche Basis. HCC geht wohl größtenteils upstream in llvm ein. Nvidia wollte llvm mal um Fortran für deren gpus erweitern, was das ganze vereinfachen konnte... :D

[Skysnake]

Ja, da gibt es genug. FORTRAN lebt nämlich die Phylosophie, das man wenn dann maximal ein paar Compiler hints geben will und das wars dann auch. Dadurch wird MEINER! Meinung nach teils viel performance liegen gelassen, aber die Codes sind eben teils auch echte Monster.

Aber darum geht es nicht. Du kannst davon ausgehen, das bei den Centern 20-80% der Compute Time für FORTRAN Codes drauf geht. Warum sollten die jetzt AMD GPUs kaufen, wenn die Codes das dann GARANTIERT! nicht nutzen können?

Und ja, man kann C auch aus FORTRAN rufen, aber das machen die Leute nur sehr sehr sehr ungern. Und viele die FORTRAN können können kein C geschweige denn C++...

Das macht als AMD GPUs sehr uninteressant.

[iuno]

OK, interessant
Warum sollten die jetzt AMD GPUs kaufen, wenn die Codes das dann GARANTIERT! nicht nutzen können?
Das ist klar, ich frage aber ja genau andersherum: die haben wohl noch nie AMD benutzt und kein Interesse/keine Moeglichkeit die Software umzustellen. Warum sollen sie die Hardware wechseln, sobald AMD auch Fortran kann, wenn es bisher alles gut laeuft?
Sollte AMD nicht den Kunden eine Option anbieten, die mit neuen Projekten einsteigen? Die sehen dann dass es eben zu CUDA Alternativen gibt. Es kann AMD ja nicht darum gehen, den ganzen Markt zu uebernehmen sondern ueberhaupt erstmal irgendwo einen Fuss zu fassen. Die sind ja aktuell quasi nicht existent in dem Sektor

[Locuza]

Am 27. Februar bis zum 3. März findet die GDC wieder statt, AMD hat ihre Vorträge schon vorab gelistet:
http://gpuopen.com/gdc-2017-presentations/

Persönlich klingt die neue FEM Komponente interessant:
Real-Time Finite Element Method (FEM) and TressFX 4.0 combines two topics together. The first will cover a novel technique based on FEM to handle physics destruction and deformation. The second will detail the recent advancements done to the GPUOpen TressFX hair/fur simulation and rendering technology, in particular with regard to DirectX 12 support and collision handling via Signed Distance Fields.
We will introduce a new, open source simulation technology in development, and discuss improvements to TressFX. Our new technology is a real-time finite-element method (FEM) simulation system. Objects deform and fracture (destruction) according to physical material properties. TressFX 4 provides significant collision fidelity improvement at low cost through dynamic signed distance fields (SDF), and a new method for managing fast motion.

Ich hoffe AMD spricht sich hierbei besser mit ISVs ab, ansonsten endet das vermutlich wieder in vergeblicher Liebesmüh.

[Unicous]

So wie es aussieht sind sämtliche Sessions/Vorträge von der GDC verfügbar. (Ooops, also frei verfügbar sind nicht alle, bei einigen muss man sich immer noch auf der GDC-Seite registrieren)

http://gpuopen.com/gdc-2017-presentations/

[AintCoolName]

Die Seite wurde Redesigned und FidelityFX hat neue Features optimiert für RDNA bekommen:

https://gpuopen.com/introducing-our-new-fidelityfx-effects/

[DrFreaK666]

Die Seite wurde Redesigned und FidelityFX hat neue Features optimiert für RDNA bekommen:

https://gpuopen.com/introducing-our-new-fidelityfx-effects/

Schade dass das AO nicht erzwingbar ist

[Dampf]

Damit kann man Screen Space Reflections und SSAO also auf jedes Game anwenden? Das ist ja cool!

[Troyan]

Jede Engine hat heute schon SSAO und SSR implementiert. Das sind Standardfeatures. AMD hat nur eine x-te Variante von denen vorgestellt.

[AintCoolName]

Wichtiger als die Variante ist die Optimierung. Für die hat keiner Zeit, aber wenn ich die nur unter IF(RDNA) dann nimm das einbauen kann hilft das. Weil im Zweifel ist die andere Variante von Nvidia. Und wenn das Game dann im Benchmark läuft und AMD sich dann mit der Nvidia Variante quält (HBAO+) ist das nicht gut fürs AMD Marketing.

[gedi]

Jede Engine hat heute schon SSAO und SSR implementiert. Das sind Standardfeatures. AMD hat nur eine x-te Variante von denen vorgestellt.

Ähm - nö

[Dampf]

Jede Engine hat heute schon SSAO und SSR implementiert. Das sind Standardfeatures. AMD hat nur eine x-te Variante von denen vorgestellt.

Schon klar, ich meine damit kann man diese Techniken auf Spiele anwenden, die das noch nicht supportet haben. Z.B. alte Games.

[DrFreaK666]

Schon klar, ich meine damit kann man diese Techniken auf Spiele anwenden, die das noch nicht supportet haben. Z.B. alte Games.

Ich glaube das geht nicht

[Achill]

Mit dem Release von ROCm v3.5 [phoronix.com] (https://www.phoronix.com/scan.php?page=news_item&px=Radeon-ROCm-3.5-Released) [github.com] (https://github.com/RadeonOpenCompute/ROCm/releases/tag/rocm-3.5) für Linux gibt es jetzt u.a. als Neuerungen OpenCL 2.2 support und Verbesserungen an HIP. Support für Navi ist jedoch weiterhin nicht in Sicht .. :(

[aufkrawall]

Ich halte es für denkbar, dass das für zumindest Navi 1x wegen Consumer-Fokus auch nie der Fall sein wird.
Interessant wär, ob für Navi auch der Windows OpenCL-Treiber nun auf PAL aufgebaut ist bzw. der OCL-Treiber für Win & Lin identisch ist. Bei Intels NEO ist das btw. der Fall.

Edit: ROCm Support soll noch kommen:
https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1184064-radeon-rocm-3-5-released-with-new-features-but-still-no-navi-support/page2#post1184096

[Badesalz]

Gefällt mir. Schon alleine deswegen, weil die Grünen aktuell so halslaut für Mush-Shader (VRS) und 720p-content auf 4k (DLSS) trommeln.

Wogegen von den Roten nach RIS jetzt die zweite Sache kommt welche die Bildquali STEIGERT.
https://www.eveonline.com/de/article/qb3kew/sharpening-the-renderer

[aufkrawall]

RIS ist einfach nur CAS im Treiber...

[Badesalz]

Jein.
Mit RIS macht man Postprocessing für das gesamte Bild.

CAS kann aus der Engine heraus genutzt werden und da bzw. damit kann der Coder dann bestimmen, ob das grad nur für bestimmte Objekte oder nur für bestimmte Bildebenen wirkt.

Das ist also schonmal nicht sowas wie Vsync im Treiber anmachen vs. Vsync im Spiel anmachen...

Ob die Schärfungstechnik selbst identisch ist, KP. Man wird aber auch bedenken müssen, wenn man mit CAS rumspielt, daß die Leute auch mal RIS an haben. Der Effekt sollte sich ja nicht potenzieren.
Da mein ich, schaut man sich das nächste Woche auch genauer an :wink:

[gedi]

Der Antwort kann ich schonmal vorgreifen: Wenn CAS im Spiel nativ verfügbar ist (z.B F1 2019 oder SotTR) und aktiviert ist, scheint es so, dass RIS nicht mehr greift.

[Badesalz]

Ah ok. Danke :up: