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.

    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.

    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...

    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.

    [...] 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. ;)

    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.