Posts by GrandAdmiralThrawn

Kurzfassung:

Das ist ein Softwareproblem in x265.

Lange Fassung:

Hier ist der Grund folgender: x265 (obwohl primär für MS Windows entwickelt) läuft auf Linux und auch auf UNIX deutlich schneller als auf Windows. Das läßt sich auch an anderen Ergebnissen ablesen, wo die gleiche Hardware auf Windows und auf Linux getestet wurde, z.B. zu sehen anhand der Ergebnisse von [Bromart] oder auch derer von [exxe]. Leider gibt es noch keine Direktvergleiche mit Intel CPUs, aber da wird's ähnlich aussehen.

Nachdem wir bei Plattformen mit sehr vielen Kernen gesehen haben, daß es zu Problemen mit der CPU Auslastung unter Nutzung der NUMA Funktionalität von Windows kommen kann nehme ich an, daß x265 mit den Linux und UNIX Thread Schedulern besser "kann" als mit dem von Windows. Daher empfehle ich so ab 32 oder mehr logischen CPU lieber unter Linux zu benchen als unter Windows. Denn ab dieser Anzahl kommt es zu Problemen, wo die CPU gar nicht mehr richtig ausgelastet werden kann (wo es also noch schlimmer wird).

Weiters sei angemerkt, daß Ergebnisse unter Windows Server 2003, Server 2008 (nicht R2), sowie XP x64 und Vista nochmals einen Tick schlechter ausfallen, weil der Fallbackcode für diese Plattformen langsamer läuft, als der moderne Code für Windows 7 und höher. Aber auch Windows ≥7 ist eben langsamer als *NIX.

Diese Eigenheit betrifft x265 spezifisch, x264 ist hiervon nicht betroffen. Leider haben sich die x265 Entwickler entschlossen, Teile des Thread Schedulings selbst in die Hand zu nehmen, was ggf. nicht unbedingt die allerbeste Idee gewesen sein dürfte.

Er treibt sich ja hin und wieder trotzdem noch hier herum? Er hat zumindest diese Woche ein Ergebnis zum x265 Bench eingeschickt. Also ihn kannst sicher zumindest per PM fragen, der sollte sich schon sehr gut auskennen, denke ich auch.

Sowas gibt's. Aber du mußt halt schaun, ob das Ding selbst in Hardware kodiert (zu H.264/AVC in der Regel), oder ob die Host CPU das machen muß. Da isses schon wichtig daß man vorab prüft, ob die Maschine das wirklich schafft, wenn das Encoding in Software passieren soll, anstatt per ASIC Chip im Grabber.

Zur Sicherheit würde ich da drauf schauen, daß ein Hardware-Encoder eingebaut ist, wo möglich.

7.4% schneller nur durch ein bißchen mehr RAM-Takt. Überrascht mich immer wieder, daß der doch recht CPU-intensive x265 Encoder so mit der Speicherperformance mitskaliert. Das war beim x264 noch nicht annähernd so ausgeprägt, auch auf den Ryzen Plattformen nicht.

Ist halt denke ich auch nicht ganz billig.

Das kann ich mir nicht anschauen. Hättest den Fokus nicht fixieren können? Das macht einen ja komplett irre...

Daß es nicht direkt am Rechner geht (Encoding, Durchsatz usw.) wäre ja noch klar, aber Framegrabber ftw...

Schaut aber grafisch echt top aus! Stellenweise kommt mir da wieder der gute alte Begriff "photorealistisch" in den Sinn. Zumindest bei ein paar der Shots.

Ah ok, sie haben einfach den EDuke32 Port genommen. Alles klar. Wußte nicht, daß da dieselben Leute dahinter stehen. So isses natürlich einfacher. EDuke32 lief ja Mal fast überall (auch auf meinem XP x64), wird wahrscheinlich mittlerweile nicht mehr so sein. Also die fertigen Kompilate zumindest nicht? Muß da Mal wieder einen Blick drauf werfen, hatte ja Duke Nukem 3D nochmals komplett mit EDuke32 Portierung durchgespielt hier, der alten Zeiten wegen, nur halt mit Politur drüber.

Jo, ich denke auch daß die meisten Retro-Spieler heutzutage an sich keine Retromaschinen mehr laufen haben. Man will halt wohl in der Nostalgie schwelgen, hat aber nur moderne Rechner rumstehen.

Wobei man sagen muß, bei der Build Engine?! Da muß es doch ein gehöriger Mehraufwand gewesen sein, die Engine auf 64-bit zu portieren und mit einem völlig neuen Renderer auszustatten, anstatt einfach die alten, bestehenden Tools zu verwenden, mit denen das eh auch alles geht. Also so gesehen muß man doch extra einiges an Geld und Arbeit investiert haben damit die Engine nicht mehr auf alten Rechnern läuft.

Aber stellenweise war das wohl nötig, weil die alten Build Games waren alle DOS? War das so? Duke Nukem 3D, Redneck Rampage, Blood 1, usw..

Hat die antike Build Engine etwa wirklich soviel Weiterentwicklung in Sachen Tools & Editoren erfahren dürfen?!

Und wenn ja... sind die Tools frei?

Mir war der Build Editor damals immer zu kompliziert, was den Levelbau anging. Dagegen waren die besseren Doom Leveleditoren wie der DEEP deutlich simpler, das ging weitaus schneller von der Hand als Build Level zu bauen...

Aber das allein sagt noch nichts aus, hmm. Ich denke eine bessere Map konnte ich für Doom II in ca. 3-6 Tagen mit allen Details und Probespielen fertigstellen. Bei der Build hätte ich da wohl einen Monat gebraucht...

Vielen Dank! Durch diese Einsendung habe ich grade bemerkt, daß sich mein Webserver irgendwie unterwegs erhängt hat.

Ich sollte mein Service Availability Skript Mal aufmöbeln, damit es auch einen hängenden (und nicht nur einen getöteten) Prozeß erkennt...

Wenn das die gute alte Build Engine ist, dann eher nicht, weil die kann an sich nicht Mal D3D/OpenGL. Also brauchst auch keinen 3D Beschleuniger, das müßte per se auch auf einer s3 ViRGE oder einer Matrox Mystique oder sonstwas noch älterem laufen...

"Eigentlich".

Es gibt Diskussionen zu dem Thema, und die Schrauben werden langsam gelockert, was das Zeigen der Symbole in Kunstwerken wie Literatur (Fotografien) oder Filme anbelangt, solange sie den Nationalsozialistischen Faschismus nicht anpreisen. Daher konnte der Deutsche Release von New Kids Turbo Hakenkreuze offen zeigen. Soweit ich mich erinnern kann gelten Videospiele in Deutschland aber nicht als Kunstform (man korrigiere mich, wenn ich falsch läge, und daher ist es auf selbige nicht anwendbar.

There are discussions about just that, and the screws are being loosened in terms of showing the symbols in works of art, such as literature (photographs) or movies, as long as they don't promote national socialist facism. That's how the German release of New Kids Turbo could show swastikas openly. However, as far as I can remember, video games are not considered a form of art in Germany (correct me if I'm wrong), and that's why it doesn't apply to them.

Quote from SK1

[...] So gesehen gab es nur eine kurze Unterbrechung der Herstellung.

Das ist aber eine maßlose Untertreibung. Schau dir Mal an, was R&D sowie Fertigung heutzutage kosten. Da sprechen wir von Millarden, von KnowHow ganz zu schweigen. Und die dedizierten Karten mit Intel Chip waren damals schon viel zu schlecht, um konkurrieren zu können.

Eine Voodoo Graphics stampfst du noch einfach aus dem Boden, aber die verhält sich zu modernen GPUs auch wie ein hölzerner Rechenschieber zu einem i7.

Da hast du natürlich Recht, aber wenn man bedenkt wie Scheiße die GPUs im Vergleich zu nVidia und AMD sind, najo.. Das ist schon mehr als ein Steinwurf zum Highend.

Interessant, echt noch nie davon gehört. War wohl je nach Chipsatz ein mehr oder weniger problematisches Feature. Aber beim Athlon XP und dessen Plattformen kenne ich mich auch nicht aus.

S2 Disconnect? Kannte ich nicht. Dazu finde ich auch irgendwie nichts im Netz, was tut das genau?

Die Gerüchteküche dazu ist ja schon seit einer Weile aktiv. Ich glaube zwar kaum, daß Intel im diskreten GPU Markt für Spieler irgendwas sinnvolles wird vorstellen können, aber schauen wir halt Mal.

Als plötzlicher, großer Dritter in einen Markt platzen wollen, der eigentlich als fix und fertig zwischen AMD und nVidia aufgeteilt gilt?

Zumindest ein ganz kleines Bißchen gespannt bin ich ja doch drauf...

Jo. Auch der Umstand, daß du die Dinge auf einem viel niedrigeren Level betrachtest als ich. Aber für den Endverbraucher - wie Dennis - zählt das "Warum" letzten Endes wohl eher wenig. Der will Strom sparen, aber da wird er mit Windows 98 (und Me? Nicht sicher was Me kann) wohl keine besondere Freude haben, zumindest nicht im Auslieferungszustand.

Da wird ihm das hier helfen: [Rain.zip] (Version 2.0).

Athlon XP Prozessoren sollten im Übrigen bereits eine sparsame Implementierung von NOP haben, womit die NOP Schleifen von Win9x weniger schlimm wären. Das habe ich jetzt aber nur so im Netz gelesen, weiß also nicht, ob das tatsächlich zutrifft, und in welchem Ausmaß (hab' keinen Athlon XP). Bei Intel weiß ich nicht genau, ab welcher CPU Generation die Chips dahingehend intelligenter geworden sind.

Ganz alte CPUs mit nur einer Ausführungspipeline müßten unter Win9x idle sogar gleich heiß laufen wie unter echter Betriebslast, weil ein XCHG NOP in einer einfachen Pipeline wohl ähnlich viel Saft frißt wie ein ADD oder MUL. Aber das kann ich nicht wirklich testen.

Wäre jetzt witzig, schnell ein kleines Assemblyprogramm zu schreiben, das die CPU Kerne mit nichts als NOPs vollballert, um dann zu schauen wie sich der Code auf unterschiedlichen Systemen genau verhält.

Wenn du Last hast, passiert sowieso kein HLT auf modernen Systemen, klar wird er dann deutlich heißer. Bei Win9x wirst aber nur wenig Unterschied zwischen Last und Idle bemerken. Kannst wie gesagt leicht testen, indem du Win9x unter Idle mit CPUCool oder Rain testest, und Idle ohne eines dieser Tools. Und dann gibst ihm richtige Last zum Vergleich.

Dann wiederholst das Experiment mit einem NT Betriebssystem. Dann wirst du sehen, daß das Temperaturdelta ohne HLT vergleichsweise gering ausfällt, mit HLT aber wesentlich höher. Ein Win9x mit Rain sollte sich dann ca. gleich verhalten wie ein NT System by default. Also kühler im Idle und gleich unter Last.

Windows 98 müßte eine Kernel Tick Frequenz von 1000Hz haben, also die CPU wird 1000 Mal pro Sekunde per Interrupt geweckt, es passiert mindestens ein Kontext Switch, und dann wird entschieden, ob ein Prozess eine Zeitscheibe für die Ausführung bekommt oder ob nicht. Wenn nicht, looped das System über NOP Instruktionen (die erst mit späteren CPUs intelligenter geworden sind als XCHG EAX, EAX).

Alte MS Systeme hatten einen Tick von 100Hz, allerdings weiß ich jetzt nicht mehr ganz genau, mit welchem System die Tickrate angehoben wurde. Aber ich denke die 100Hz betreffen noch wesentlich ältere Systeme.