Zu der letzten Meldung über AMDs Vega-20-Chip als (terminlich weit vor dem Rest liegenden) Vorboten der 7nm-Grafikkarten gab es die sicherlich berechtigte Kritik, das unsere Taktraten- und Rechenleistungs-Prognose zu diesem HPC-Grafikchip sehr defensiv aka zu niedrig ausgefallen ist. Zwar wurde hierfür schon mit einer Taktraten von 1700 MHz gerechnet, für den Sprung von der 14nm- auf die deutlich kleinere 7nm-Fertigung ist dies ausgehend von real vielleicht 1500 MHz Chiptakt bei den Vega-10-basierenden Grafikkarten allerdings eher wenig. Eingerechnet wurde hierbei unsererseits der Punkt, das die Vega-Generation eben für die 14nm-Fertigung gedacht war, damit kein ganz so hoher Takt unter der 7nm-Fertigung erreichbar erscheint wie vergleichsweise bei einer Grafikchip-Architektur, welche grundsätzlich für die 7nm-Fertigung ersonnen wurde. Trotzdem ist der kalkulierte Taktratensprung vielleicht doch zu klein, gerade da AMD bei Vega 20 ziemlich sicher nicht mehr Shader-Einheiten verbauen wird – und somit viel Platz in der kolportierten Chipfläche von ~300mm² zur Verfügung steht, um mehr Massentransistoren zugunsten höherer Taktraten zu verbauen.

Zudem sollten die automatischen Effekte der 7nm-Fertigung den Stromverbrauch effekt herunterdrücken, womit AMD bei Vega 20 nicht wie bei den Radeon RX Vega Grafikkarten in das Problem kommen sollte, die real anliegenden Taktraten wegen zu hoher Chiptemperaturen oder/und eines zu hohen Stromverbrauchs reduzieren zu müssen. Derzeit bietet unser Forum grob 2000 MHz als gute Taktraten-Schätzung für den Vega-20-Chip an, welche durchaus als erreichbar erscheint. Daneben gibt es vereinzelt sogar noch höhere Schätzungen, ergo sind jene 2000 MHz sicherlich noch nicht am oberen Ende der Erwartungen angesiedelt. Nichtsdestotrotz muß AMD auch diese 2000 MHz Chiptakt erst einmal erreichen – und bei der AMD-Historie an nicht erreichten Taktraten darf man diesbezüglich durchaus vorsichtig sein. Schafft AMD hingegen diese Taktrate bei Vega 20, dann winkt eine FP32-Rechenleistung von satten 16 TFlops, was leicht mehr als bei nVidias Titan V wäre. Für AMD wäre dies durchaus eine sinnvolle Zielsetzung, denn der Vega-20-Chip muß nachfolgend wohl noch einige Zeit im HPC-Segment durchhalten, ehe jener durch einen 7nm-Chip speziell für HPC-Bedürfnisse abgelöst wird.

Bei der PC Games Hardware sowie dem TechSpot hat man sich die Grafikkarten-Performance unter "Strange Brigade" angesehen, dem Koop-Ballerspiel von Rebellion, welches unter anderem Teil von AMDs aktuellem Spielebundle ist. Das Spiel auf Basis von Rebellions hauseigener Asura-Engine bietet mit DirectX 12 und Vulkan gleich zwei LowLevel-APIs zur Auswahl an, wobei DirectX 12 auf nVidia-Grafikkarten generell schneller ist und Vulkan nur auf AMD-Grafikkarten teilweise minimal vorn liegt. Aufgrund generell maßvoller Hardware-Anforderungen (trotz sehenswerter Optikqualität) werden bei Spitzen-Grafikkarten unter der FullHD-Auflösung schnell Frameraten von bis zu 200 fps erreicht, für im Schnitt 50 fps reichen dagegen schon Radeon R9 280 oder GeForce GTX 960 aus. Unter der WQHD-Auflösung erhöht sich dies auf Radeon R9 390 oder GeForce GTX 970, unter der UltraHD-Auflösung dann auf Radeon R9 Nano oder GeForce GTX 980 Ti. Das Spiel hat eine gewisse AMD-Neigung, AMD-Grafikkarten kommen durch die Bank weg etwas besser weg als im allgemeinen Performance-Bild.

So liegt beispielsweise die Radeon RX Vega 64 regelmäßig vor der GeForce GTX 1080 sowie die Radeon RX 580 8GB leicht vor der GeForce GTX 1060 6GB, daneben laufen die Fuji-basierten Grafikkarten Radeon R9 Nano, Fury & Fury X unter Strange Brigade generell sehr gut mit. Als Grafikkartenspeicher-Menge werden bis zur WQHD-Auflösung 4 GB und für die UltraHD-Auflösung 6 GB empfohlen, um auf der sicheren Seite zu sein – in den Benchmarks ist dieser Effekt nicht direkt zu sehen, da bei zu wenig Grafikkartenspeicher einfach das Texturenstreaming Lücken läßt, aber eben nicht auf die Framerate schlägt. Wer hier dennoch noch zuviel fps hat, kann zudem mittels des Spiel-eigenen Supersamplings eine noch höhere Bildqualität anstreben. Die CPU-Performance spielt dagegen augenscheinlich keine echte Rolle, wenn selbst ein FX-8350 @ 4.5 GHz nahezu durchgehend über 100 fps erreicht. Abschließend hat man sich bei WCCF Tech noch die CrossFire-Performance des Spiels angesehen, welche eine erstklassige CrossFire-Skalierung des Titels aufzeigt. Vollkommen zu Recht wurde von der PCGH somit die "tadellose" Optimierung des Spiels zugunsten hoher Frameraten und eines flüssigen Spielgenusses gelobt.

Heise warnen vor einer neuen Malware-Kampagne, bei welcher der Verschlüsselungstrojaner "Gandcrab" sowohl Lücken in Adobes Flash als auch in Windows selber zu nutzen versucht. Beide Lücken wurden bereits geschlossen (bei Adobe allerdings erst mit der allerneuesten Flash-Version), so daß sicherheitsbewußte Anwender hiervor bereits geschützt sind. Das spannende an der Attacke ist somit eher der konkrete Verbreitungsweg von "Gandcrab" – da man sich diesen Verschlüsselungstrojaner direkt beim Surfen einfangen kann. Bisher kamen Verschlüsselungstrojaner eher über den Weg des eMail-Anhangs, während die Methode über die Einbindung in Webseiten (bzw. zumeist in Werbung auf Webseiten) zwar denkbar war, aber doch viel seltener genutzt wurde. Dies erhöht vor allem das gefühlte Risiko, denn gegen eine Attacke ausgehend von einer besuchten Webseite kann man sich nicht aktiv schützen – während dagegen die goldene Regel, nicht jeden eMail-Anhang bedenkenlos zu öffnen, inzwischen allgemeinbekannt ist. Laut den tiefergehenden Erläuterungen bei FireEye läuft die Attacke letztlich darauf hinausläuft, das (auf einem nicht gepatchten Computer) über eine verseuchte Webseite ein vbs-Skript auf den PC des Opfers geladen und dort ausgeführt wird.

Dieser vergleichsweise "billige" Trick läßt sich allerdings auch auf einem vollkommen ungepatchten System problemlos verhindern, indem man schlicht die Scripting-Funktionalität des Windows-Betriebssystems abschaltet, wie früher schon zum Fall von "Locky" erklärt. Dann könnte der Benutzer auch auf einem ungepatchten System manuell auf das (gefährliche) vbs-Skript klicken – das Betriebssystem würde dessen Ausführung mit entsprechender Fehlermeldung schlicht abweisen. Erstaunlich, das diese einfache Möglichkeit des Malware-Schutzes – welche ja dann auch bei neuen, bislang noch ungepatchten Lücken zuverlässig hilft – immer noch so wenig thematisiert wird. Sicherlich benötigen Programmierer etc. teilweise die Skripting-Fähigkeiten von Windows, aber beim Normalanwender ist diese Funktionalität nicht nur bedeutungslos, sondern eben sogar faktisch gefährlich. Es kann daher nur empfohlen werden, Skipting-Fähigkeiten generell so weit wie möglich zu deaktivieren – wie beschrieben in Windows, Adobe & Office. Auch Schadprogramme gehen halt zumeist den einfachstmöglichen Weg – und scheitern dann an dieser (unerwarteten) Barriere, auch ganz ohne Virenschutz und ganz ohne Sicherheitsupdates.